You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Patrick Mueller (Created) (JIRA)" <ji...@apache.org> on 2012/04/13 22:20:17 UTC
[jira] [Created] (CB-508) better diagnostic capabilities for
startup code
better diagnostic capabilities for startup code
-----------------------------------------------
Key: CB-508
URL: https://issues.apache.org/jira/browse/CB-508
Project: Apache Callback
Issue Type: New Feature
Components: CordovaJS
Reporter: Patrick Mueller
Assignee: Filip Maj
I just sent the day yesterday debugging the common-js modules on iOS, for the lifetime of when the script is loaded through when deviceready is fired.
*PAIN!*
Couple of things:
* there are still some lingering console.log() calls in code that gets run before deviceready
* even the new utils.alert() or whatever doesn't help here, as it can't do anything before deviceready
* we need to be able to diagnose issues when deviceready is never called
That last one is something I looked at yesterday. How do you "debug" your web app that isn't firing deviceready? Even tools like iWebInspector can't really help for issues that occur at startup - the time window is very small and there's A LOT OF SHIT going on.
We need to do something, but I don't have concrete ideas yet.
What I ended up doing yesterday was writing a small function {{HackLog(aMessage)}} which "logs" a message. Works anywhere, anytime. Logging the message means appending it to an array. :-) After a fixed timeout, I dump the contents of the log to the DOM in a <pre> (or whatever).
This sort of "log to the DOM" is a nice approach, because we usually do have a DOM available. The trick is to figure out how folks can enable this sort of thing, which you clearly don't want in production.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-508) better diagnostic capabilities for
startup code
Posted by "Patrick Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253771#comment-13253771 ]
Patrick Mueller commented on CB-508:
------------------------------------
If we end up doing some "instrumentation" - adding code - we could do this in the -debug.js files the build is currently building.
Kinds of instrumentation:
- supplying new versions of require()/define() to track module loading/requires
- hooking event handlers, to try/catch around them, and log when they're running
Could even go whole hog, and process the JS into instrumented JS via Uglify parsing/annotation. Prolly don't need to go to that level, yet.
> better diagnostic capabilities for startup code
> -----------------------------------------------
>
> Key: CB-508
> URL: https://issues.apache.org/jira/browse/CB-508
> Project: Apache Callback
> Issue Type: New Feature
> Components: CordovaJS
> Reporter: Patrick Mueller
> Assignee: Filip Maj
>
> I just sent the day yesterday debugging the common-js modules on iOS, for the lifetime of when the script is loaded through when deviceready is fired.
> *PAIN!*
> Couple of things:
> * there are still some lingering console.log() calls in code that gets run before deviceready
> * even the new utils.alert() or whatever doesn't help here, as it can't do anything before deviceready
> * we need to be able to diagnose issues when deviceready is never called
> That last one is something I looked at yesterday. How do you "debug" your web app that isn't firing deviceready? Even tools like iWebInspector can't really help for issues that occur at startup - the time window is very small and there's A LOT OF SHIT going on.
> We need to do something, but I don't have concrete ideas yet.
> What I ended up doing yesterday was writing a small function {{HackLog(aMessage)}} which "logs" a message. Works anywhere, anytime. Logging the message means appending it to an array. :-) After a fixed timeout, I dump the contents of the log to the DOM in a <pre> (or whatever).
> This sort of "log to the DOM" is a nice approach, because we usually do have a DOM available. The trick is to figure out how folks can enable this sort of thing, which you clearly don't want in production.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-508) better diagnostic capabilities for
startup code
Posted by "Filip Maj (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253934#comment-13253934 ]
Filip Maj commented on CB-508:
------------------------------
I would love adding the queue-of-logs to the -debug version of the file (and possibly feeding them into {{console.log}} once {{deviceready}} fires) - I think that's a great idea. It is, after all, a debug version.
One question that comes with this is: do we then "vendor" in the -debug versions into the platform repositories?
> better diagnostic capabilities for startup code
> -----------------------------------------------
>
> Key: CB-508
> URL: https://issues.apache.org/jira/browse/CB-508
> Project: Apache Callback
> Issue Type: New Feature
> Components: CordovaJS
> Reporter: Patrick Mueller
> Assignee: Filip Maj
>
> I just sent the day yesterday debugging the common-js modules on iOS, for the lifetime of when the script is loaded through when deviceready is fired.
> *PAIN!*
> Couple of things:
> * there are still some lingering console.log() calls in code that gets run before deviceready
> * even the new utils.alert() or whatever doesn't help here, as it can't do anything before deviceready
> * we need to be able to diagnose issues when deviceready is never called
> That last one is something I looked at yesterday. How do you "debug" your web app that isn't firing deviceready? Even tools like iWebInspector can't really help for issues that occur at startup - the time window is very small and there's A LOT OF SHIT going on.
> We need to do something, but I don't have concrete ideas yet.
> What I ended up doing yesterday was writing a small function {{HackLog(aMessage)}} which "logs" a message. Works anywhere, anytime. Logging the message means appending it to an array. :-) After a fixed timeout, I dump the contents of the log to the DOM in a <pre> (or whatever).
> This sort of "log to the DOM" is a nice approach, because we usually do have a DOM available. The trick is to figure out how folks can enable this sort of thing, which you clearly don't want in production.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-508) better diagnostic capabilities for
startup code
Posted by "Patrick Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254078#comment-13254078 ]
Patrick Mueller commented on CB-508:
------------------------------------
Writing the queued messages to the console log after {{deviceready}} make sense. But we still need an option to get the messages to the developer, if {{deviceready}} never fires - for whatever reason.
If "vendor" means "cp", then yes. :-) The common-js build currently builds a cordova-{platform}.js file AND a cordova-{platform}-debug.js file, so ... we can just copy the -debug.js version to the platforms as well. More ammunition for automating this vendor/copy process.
Another thing we could do is base the "debug" level of cordova off a pre-set variable - perhaps {{CordovaDebug = true}}, etc.
We might even want to use both a separate debug file AND a setting of some kind. The -debug.js version of the file could contain extra debug junk we wouldn't want to ship in the "released" version of the app. And we might use an external variable to indicate additional debug capabilities, such as dumping the messages into a div/pre in the DOM or something.
> better diagnostic capabilities for startup code
> -----------------------------------------------
>
> Key: CB-508
> URL: https://issues.apache.org/jira/browse/CB-508
> Project: Apache Callback
> Issue Type: New Feature
> Components: CordovaJS
> Reporter: Patrick Mueller
> Assignee: Filip Maj
>
> I just sent the day yesterday debugging the common-js modules on iOS, for the lifetime of when the script is loaded through when deviceready is fired.
> *PAIN!*
> Couple of things:
> * there are still some lingering console.log() calls in code that gets run before deviceready
> * even the new utils.alert() or whatever doesn't help here, as it can't do anything before deviceready
> * we need to be able to diagnose issues when deviceready is never called
> That last one is something I looked at yesterday. How do you "debug" your web app that isn't firing deviceready? Even tools like iWebInspector can't really help for issues that occur at startup - the time window is very small and there's A LOT OF SHIT going on.
> We need to do something, but I don't have concrete ideas yet.
> What I ended up doing yesterday was writing a small function {{HackLog(aMessage)}} which "logs" a message. Works anywhere, anytime. Logging the message means appending it to an array. :-) After a fixed timeout, I dump the contents of the log to the DOM in a <pre> (or whatever).
> This sort of "log to the DOM" is a nice approach, because we usually do have a DOM available. The trick is to figure out how folks can enable this sort of thing, which you clearly don't want in production.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira