• Hi All,

    I have experienced one of my Apps hanging every few days. The time freezes but a reload of the app (short button press). This got me thinking if there was a way to capture the console output when not connect via Bluetooth.

    The Settings/Utils/Debug option has three options: Hide, Show, Log.

    1. Hide means disabled
    2. Show displays the debug messages on the watch screen (i guess it has some use, but only if there is only a few messages)
    3. Log displays on the screen and logs to log.txt

    There is no option to log but not to show on the screen.
    Also it appears that the debug messages are the ones from the firmware.
    I have tested and it does not look like console.log('xxxx') output is sent to log.txt

    I think it would be really useful to have that happen so that output that would get displayed if connected to the IDE would get logged. Apprecaite that log.txt accumulates and this could be an issue if it consumes the storage - but it has to be the owners responsibility to enable/disable the logging as required.

    What do others think ?

  • I'd like that feature.

    (TLTR - sorry, may be off topic:)
    And I'm a real fan of privacy, but wouldn't be an additional log report feature be awesome?
    From the user point of view:
    In the settings of each registered app and in the general settings we could have a "send crash reports to author" (default=off). Then the watch could accumulate all console.log of each app (and the firmware) and send it to the correspondent developer once a day.
    From the developer point of view:
    An app could optionally register for this feature with an email address. Logs would be gathered on a server and the server would send it to the developers.

    I know, with the current eco system this sounds like science ficture, but wouldn't it be neat to see where useres are struggeling even befor they know?

  • Yes, being able to send error reports, or at least have the App Loader say 'we found an error, would you like to upload it' would be cool. It wouldn't be desperately hard to allow Espruino to write uncaught exceptions to a file - for instance it could just write the very last one that happened...

    However, in terms of logging...

    I have tested and it does not look like console.log('xxxx') output is sent to log.txt

    I just tried here, and messages from console.log do appear in the log. There are some caveats though:

    • If you're connected via BLE (eg to Gadgetbridge) then errors get sent there instead (you can 'view logs' in Gadgetbridge and see them)
    • If you connect via BLE and then disconnect, you have to reload before stuff appears in the log again (so long-press the button, or when you launch an app)

    I think this could be fixed reasonably easily, but even so if you're just debugging your app it's not too hard to work around.

    Chances are you won't need to log either - I bet when your app stops working it'll be because an exception was thrown

  • do appear in the log. There are some caveats though

    Ok, was not aware of that.

    I bet when your app stops working it'll be because an exception was thrown

    The problem is I have no idea when it fails, it hangs while I am asleep, I cant always remember to connect to the IDE to capture any output. It may not be my app that is the problem, it could be something else. I've not gone after the issue as it only happens infrequently. I suspect it is some sort of memory leak. I still think there might be issues with custom fonts being loaded, but its not yet proven.

    I think the ability for exceptions to go to log.txt would be very handy.
    Obviously privacy is an issue so it would have to be enabled by choice.

    We probably dont need full crash reporting (eg microsoft style) and general log (mostly rubbish) collecting, I think thats a bit OTT. I'm more in faviour of the 'keep it simple' design philosophy.

    Happy to log this as a feature request.

  • I think the ability for exceptions to go to log.txt would be very handy.

    Well, they do if your turn 'Settings/Utils/Debug' to log - sure, other print statements do go in there but generally apps don't randomly print data. If they do, it's probably something we should fix in the relevant app

  • @Gordon - I have done

    But see note in the comments as I am not sure I have covered all the bases correctly
    I still see output to the screen when I select the option to log only

  • Yes, I don't think that works - I made some changes to the PR though that might fix it

  • THats great. I have tested and looks like it works ! Full comments in the PR.

  • @Gordon - anything wrong with the PR ? Maybe you have been away ?

  • Just merged - there's been a bit of catch-up after FOSDEM

  • This seems to have got broken recently.
    Setting log=2 is now displaying and logging (ie the both setting).
    I have checked the settings app and bootupdate code and all seems well

    SO wondering if this is a firmware change. I am currently on 2v17, it last worked on 2v16.x
    Will have to try downgrading and a retest.

  • Ok, thanks - please keep me updated.

    I'm pretty sure nothing has changed there recently - when it was done there were 2 codepaths, one for Programmable:true and one for :false, so maybe if you had Programmable:false on your watch you might have run the different (possibly not as well tested) code?

  • Good point. Default is programmability = True. My tests were done with that. I have not changed it. Will investigate further as the ability to log without display is a useful feature.

  • I think everything is working fine. It is just that I had forgotten that when you connect through the IDE you get `> bluetooth' displayed on the screen regardless of the log setting and that whilst connected to the IDE the console.log output goes to the IDE and not to the log, this is why I was not seeing anything in the log when I viewed it through the IDE.

    I'm wanting to use this to track down a hang I get in the Lato clock when I am using lots of clock_info's. The hang is rare. I suspect it mostly happens when I been using the sunrise clock_info, but I dont yet have a provable test case. A short button reset causing the clock to reload and everything is fine again. Its as if the clock timer does not get restarted. I'm now trying out with simplest++ as that is smallest clock code that supports clock_info's.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Settings Utils/Debug, could it record console.log() output ?

Posted by Avatar for HughB @HughB