File Not Found Error

Thanks for the quick response.

You are debugging a FILE_NOT_FOUND error, so it is impossible that this is related to your error.

No, I'm not getting file/line information in the stack trace in all cases where Symbol not found error is generated as I posted in an earlier post

Because, by convention, addresses are supposed to be shown as hexadecimal integers.

I wonder whose convention? I would have thought as a debugging tool, a decimal notation would be far more user friendly.

A while back I wrote a python script that took the path to api.debug.xml and then prompted for addresses to lookup and translate. With something like this you shouldn't care about the format of the data.

Sounds like a long-winded work around. I just plug the hex into a spreadsheet with HEX2DEC.

We'll have to run your test app on a device under a debugger to find out what is happening for sure.

OK, how do we progress that one? I have started a thread in the bugs forum where I have added further findings

Because, by convention, addresses are supposed to be shown as hexadecimal integers.

I wonder whose convention? I would have thought as a debugging tool, a decimal notation would be far more user friendly.

By the convention established by decades of computing and computer science.... Decimal is user-friendly, but hex is developer-friendly.

Memory addresses are shown as hexadecimal for the same legit reasons that hex is used in coding pervasively. It's not a random choice, The reason is that memory addresses (like many things to do with computers) are typically powers of 2, and hexadecimal is far better suited for dealing with powers of 2 compared to decimal. Binary is of course perfectly suited, but binary numbers are usually just too long for people to deal with.

You have a fixed, even number of hex digits of every group of binary digits (of even length). For example, an 8-bit number can be represented with a 2-digit hex value and a 32-bit integer/address can be represented with 8 digits of hex. A 64-bit address would be 16 digits. If you used decimal, that would be 3, 10 and 20 digits, and you would lose the ability to do certain calculations in your head. If you tell me you have a 32-bit unsigned integer, I can tell you the max value is 0xFFFFFFFF in hex, but for decimal I would have to convert it or look it up.

If you give me a number in hex like 0xABCD1234, I can tell you that the bytes are:
AB CD 12 34
(although the actual order of the bytes in memory, in a file, or on the network "wire" may be implementation-defined.)

If you give me a number in decimal like 3478237433, I can't split that up into bytes in my head.

It's also why hex editors (for editing non-textual data) display file addresses and data in hex. There's no reason you couldn't be editing data files in decimal or binary, except that hex is far more convenient.

That's also why CSS colour codes are hex (e.g. #00ff00 for green). So that you can specify a colour with one hex number that is always the same number of digits, and can easily be split up into R, G, B values. The alternative is to always deal with 3 numbers (decimal R, G and B values), which is far less convenient for devs.

Hex is just a compact, logical representation for many numbers to do with computing. For similar reasons, octal (base 8) is also used in some contexts, but far less frequently.

(Of course, some devs can go too far and use hex everywhere in their code, even in cases where decimal would make more sense, like when dealing with most enumerations and constants.)

Having said that, it would've been nice if debug.xml also had addresses in hex....

No, I'm not getting file/line information in the stack trace in all cases where Symbol not found error is generated...

Sorry... I meant to write *possible*, not *impossible*. The debug information is stored in the .PRG file. If the .PRG file can't be located for some reason, you'd get a FILE_NOT_FOUND error, and there would be no debug information.

Not reporting file/line information in the simulator is a totally different issue. I'm already working on that.

Sounds like a long-winded work around. I just plug the hex into a spreadsheet with HEX2DEC.

Perhaps, but my workaround doesn't require me to do a manual lookup for every address.

OK, how do we progress that one?

We wait until people are in the office and are given the opportunity to investigate. It is the weekend after all...

By the convention established by decades of computing and computer science.... Decimal is user-friendly, but hex is developer-friendly.

And there you have it: the schism between engineering and science, between Howard Wolowitz and Sheldon Cooper, or between Isambard Kingdom Brunel and Albert Einstein.

Who would have imagined, reading Garmin's gushy intro, that you'd need to be a computer scientist to wrangle MonkeyC to turn a practical idea into a working solution?

Your example of RCB is perhaps the only example that I have ever encountered of a "user friendly" use of hex, and I suspect that that is primarily to do with the challenge of representing a the 3D nature of colour (a pet subject of mine) in a single string.

Here are some random thoughts:

• IP addresses use decimal, MAC addresses use hex
  
• God gave us 10 fingers which we number from 1 to 10, not 16, numbered 0 to f.
  
• Application devs aren't computer scientists, we're software engineers
  
• A computer scientist may be able to recognise that 0x1009fb4c is greater than 0x1009f94c, but an engineer can't.
  

The references in the error messages may well be memory addresses, but for a dev trying to debug his code, they are simply a reference number that the scientists have been unable or unwilling to decode.

Having said that, it would've been nice if debug.xml also had addresses in hex....

I beg to differ. It would've been nice if the the error messages reported the module/line number directly, or failing that, provided the reference in decimal.

PS I had a similar discussion with Apple whose watch app error reporting also provides error code references in hex, but in their case, the problem is exacerbated by failing to reliably provide their equivalent of the debug.xml!

If the .PRG file can't be located for some reason, you'd get a FILE_NOT_FOUND error, and there would be no debug information.

I wouldn't have thought a dev could generate a FILE_NOT_FOUND error!

Not reporting file/line information in the simulator is a totally different issue. I'm already working on that.

Cool

Perhaps, but my workaround doesn't require me to do a manual lookup for every address.

will it run on a Mac? is it available to devs?

We wait until people are in the office and are given the opportunity to investigate. It is the weekend after all...

I'm in Sydney, 18 hrs ahead of you - it's Monday already! :p
I'll be expectantly checking my messages first thing in the morning.

r.485 Travis.ConnectIQ
I believe I may have stumbled onto the fix for the "File Not Found Error".
It was occurring while my device was in a "broken" state, characterised by the log messages from the F5 not being decoded to the module/Line No, just the memory address.
Since a deep reboot I'm getting module/line No. in my error reports and no more "File Not Found Error".

Guys… please stick back to the original issue ' File not found ' - as I have exactly same problem, from the stack data - I see - pointing to Storage.getValue(...).
In my case (this is a watchface) - it occurs roughtly every 3rd - 4th day (and Storage is used every minute - during full refresh) - so this gives error rate at level of 1/6000 - 0.016%

StachUman we've got a ticket tracking this issue and being worked. We try to sift through potential post hijacks and differentiate between original issues and separate where appropriate.

Thanks,
-Coleman

Guys… please stick back to the original issue ' File not found '

Sorry about the diversion, but that was a topic close to my heart

- as I have exactly same problem, from the stack data - I see - pointing to Storage.getValue(...).

On reviewing my notes about where the File Not Found Error was being generated when my watch was "broken", and the debugging after I rebooted the watch, in every case, the crash was due to executing Storage.getValue("...").toNumber() or Storage.getValue("...") <0 where thevalue was null. It appeared random and intermittent because of the way I was doing some HTTP calls.

To reiterate: Once I rebooted my watch, I have not had a single recurrence, prior to the reboot I was able to repro the error with ease.

To be safe, you want to change your code a bit. In the case of a null, toNumber() will cause a crash, so maybe something like

var i=Storage.toValue("...");
i =(i!=null) ? i.toNumber() : 0;