Detect simulator

maybe use the (:test) annotation ? or (:debug) which seems to be for that purpose, but I've not personaly test it !

Try this:

https://forums.garmin.com/forum/deve...ect-iq/157629-

The downside of such a solution (detect at runtime), is your debug code stays in the app and uses up code space, which can be a problem if you get close to the memory limit, especially on CIQ1 devices which have little memory.

The only solution that saves saves memory is to comment out or remove debug code when you build for a real device.

If you’re interested I have a solution for C-style conditional compilation elsewhere in the forums. It could easily be extended to switch between “release” and “debug” versions of your source code.

Tx. i will try somewhere next week

FlowState Yes I'm interested. However i could not find this in the forums. Do you have a link?

akamming Here you go. It should work on all platforms (Windows, OS X, Linux), but you need to install bash on Windows 10 (e.g. Ubuntu for Windows).
https://forums.garmin.com/forum/deve...al-compilation

To switch between debug and release, you could add/remove a define like BUILD_DEBUG to the target definition in generate.targets.

The downside of this solution is that you have to manually run a script every time you change source, as the CIQ plugin doesn't support pre/post-build steps. (Not sure if there's a way to add this in Eclipse.)

(I haven't put this on github because I don't have a full, working example to post.)

Also, I recommend changing the script so that it also processes *.mc-src files (see the comments). That way you can change your Eclipse settings so that .mc-src files are displayed in the Monkey C editor. Currently the script only processes *.src files, but that extension is too generic IMO.

(Unfortunately, Eclipse is unable to differentiate files based on two extensions, such as .mc.src, which is a bug that's been open for a few years.)

EDIT: I went ahead and changed the script, but you have to set the file association in Eclipse manually.

Why not use the debugger if you want to debug something?

I tend to use println calls when debugging, but rarely have more than a few at a time. I always have then on the far left, so they are easy to spot in the code, and when I don't need them, they stay in the code but are just commented out in the event they might be needed for something else. With most of my testing (a debug build in the sim), all are commented out.

On the other hand, I know folks that keep a few println calls in their production builds, usually for a strange issue or a new feature, or maybe something with a background process (when they crash, users see no indication on the watch, except some data can be stale/wrong). Unless the log/<appname>.txt file exists, there might be an impact in speed but, minor, and if a user reports a bug, they can just have them create the log file and get the data. I know of one app that has a special "debug" screen that is enabled with app settings, and if the user has a problem, they switch to that and just take a picture.

As to println - I'm not saying I never use println to quickly throw something out to the console as it's indeed a fast way to tell yourself something. When you're start doing this consistently it at recurring places in order to "test" something then you're using the wrong tool for the job at hand imho.

I'm not sure I want to guide you on this way as I don't want to promote println debugging, but I guess if I'd REALLY want to (to be clear: I don't want to) debug with println consistently at the same recurring places in my program I would probably set up a linked project with a inherited class in which I call my parent and do a println before and after... You'd need a bit of lead time to set it up this way, but once setup it would've the advantage I could run the println enhanced version in the sim and release the non-println version to the store, without the need to flick any other switches.

Even println statements can mess with your program timing or flow, so imagine what an actual breakpoint would do.

As to debugging program flow, be aware that a lot in connect iq happens asynchronously so people should stop thinking in procedural ways as at times there's no program flow at all...

One more thing I do actually use println statements consciously at places eg in my Data Lover watch face production code (see http://starttorun.info/data-lover at bottom) to actually let the users themselves debug if needed.

I do this because of the following reasons:
- it saves me saying the same thing over and over and let the user experience what I already know will be the likely reason of failure (no bluetooth, no running gcm, ...)
- it helps in error situations detecting firmware issues (eg the current gps drift on vivo3) and bugs in my app (eg missing characters in one of the fonts I use)

and maybe most importantly:
- I depend on 3rd party services which can fail at any time in a non-predictable manner

peterdedecker I can’t speak for anyone else but I’m not thinking procedurally at all, I understand that CIQ is event-based, but that doesn’t mean there isn’t a flow between events (like detecting a double tap). Admittedly “program flow” makes a lot less sense in this case, but sometimes timing is still important. Maybe a bad choice of words. I should’ve just said timing.

I agree that thinking procedurally is wrong for CIQ tho.

Anyway I think we’ve established that printlns are useful, and having said that, it’s nice to be able to control when they get added to your build. Personally I just comment them out or delete them when they are not needed. Would’ve been nice if there was a release vs debug annotation for ciq (please don’t tell me there is >_>) but as discussed ad nauseum elsewhere, that doesn’t help you for line by line optimization.

(Once all Garmin devices have 128kb minimum for data fields, maybe I will start writing beautiful, modular, object oriented code exclusively, but until then I will use my hideous conditional compilation and/or duplicate code for different targets, when necessary. I’ve actually saved memory by converting a simple class to a few global functions plus context array that gets passed in and returned. Writing nice code in Monkey C has lots of overhead.)

The inheritance solution sounds pretty and also sounds like it won’t work in every case like when you want to debug things in the middle of a function.

Even C# supports #if and #ifdef tho, despite scrapping all other uses of macros, for good reason.

Anyway all I can say is that pros of different ages, experience and skill levels seem to all prefer printlns in the real world, simply because it’s easier and faster than debugging. Then again it all depends on what you’re debugging. Debugging a website is easier than debugging an embedded system.

Otoh, many people use console.log for JavaScript instead of the debugger.... Using the debugger can actually interrupt certain things that console.log wouldn’t.