Step through debugging

Is there any change Garmin will get step through debugging sorted out on Eclipse?

It worked in a half-a... way for a while, though it was highly unreliable. It is now more reliable in the sense that it almost never works. I can enter breakpoints but then it says it is unable to set them or they don't break or program execution halts but with no indication as to where. Often the only way to get this feature to work is to close Eclipse and the simulator, restart, set the breakpoint from scratch. This works typically once. The simulator and or Eclipse often dies. You must get loads of crash reports and just ignore them. What happened to the hyperlinked error messages so that you don't have to trawl through lines of code. Line by line debugging is an essential feature and avoids having to create multiple debug println statements which without conditional compiling are a pain in the a... I feel I have regressed to my early embedded days, but actually this is worse. The lack of typing in Monkey C means that many issues only come to light at run time with little or no help from the compiler. Step through debugging is mandatory or productivity on anything remotely complex proceeds at a snail's pace.

I realize it must be programming hell endlessly implementing new features on a plethora of devices and I suspect you have grumpy SCRUM masters and terrible commercial managers. You do however need to put some effort into CIQ if you want developers, usually for no payment, to add value to your devices through CIQ apps. If you are still committed to CIQ app development you should at least make the process as simple and productive as possible.

If this was a commercial toolchain I would abandon it and move on to something else.

jim_m_58 over 4 years ago

First of all, you're posting in the wrong subforum. This is "showcase" where people can showcase their apps. You probably want this in the discussion forum.

I think the fact CIQ has been around since 2015 and there are thousands of successful apps in the store kind of disproves some of what you say. The way things are now seems to work for many. I have about 50 apps in the store, supporting devices from CIQ 1 to CIQ 3.2.

Are you new to CIQ? There is definitely a learning curve. And recall, the SDK Sim is just that - it's not a device emulator, where things occur on a real device that won't in the sim.

Are you trying to debug with cli or using Eclipse or VS Code? That makes a difference if I recall.

As far as typing, watch the videos from the conference that was held in Oct: https://forums.garmin.com/developer/garmin-developer-virtual-conference-2020/

Specifically the section on CIQ tools.

Dreuw over 4 years ago in reply to jim_m_58

That is a complacent reply. I also note the strategy of turning the criticism around with an implied criticism of the user.

No, I am not new to CIQ. My apps are prefixed with my nickname Drew so Drew's Intervals would be an example of one of my applications.

I am a retired doctor but worked as an embedded systems software engineer (for Dyson working on his robot vac) back in 2001 so in no way am I a newbie developer. I have grafted at the coal face debugging via a serial port and using conditionally compiled debug print statements. That was another era. I have also developed for iOS, Android and do web development in PHP and Javascript. Wear OS development is far quicker and easier despite a much greater degree of underlying complexity because of the great toolchain. In fact, it allowed me to reverse engineer your Java library method signatures for the Android mobile CIQ SDK which I needed because your documentation of this is just plain wrong.

Line by line debugging should be properly supported rather than merely paying lip service to it. A feature that does not work is not a feature.

The development tools for CIQ are poor and if there are good apps in the store I think it is because of the stirling efforts of the developer community in spite of these limitations.

jim_m_58 over 4 years ago in reply to Dreuw

When it comes to conditionals, have you looked at using annotations like debug and release?

https://developer.garmin.com/connect-iq/monkey-c/annotations/

And easy way to exclude debug code on release buids but include it for debug builds, etc.

developer.garmin.com/.../

Dreuw said:
In fact, it allowed me to reverse engineer your Java library method signatures for the Android mobile CIQ SDK which I needed because your documentation of this is just plain wrong.

Not my code. I don't work for Garmin. I'm just a retired programmer (started in the 1970's) that did things like device drivers and embedded systems for 40 years.. When I was doing embedded, one of the first tasks was to do the comm for on device debugging. That's something I wish was in CIQ. Debugging on the device itself.

Dreuw over 4 years ago in reply to jim_m_58

Sorry Jim. I thought you were on the payroll!

I don't think we had a simulator for our Robot and all debugging was via comm and the UART. Of course, with C, the compiler provides much more assistance and less time is spent actually testing code which of course was a good thing as it was a bit of a hassle. When debugging in Android Studio there is no perceptible difference to the user between using a simulated device or a real one other than speed of execution. Simulators should be of good fidelity and opting to use the linux kernel on my Mac only seems to improve the simulation speed. I think emulation is really only needed for real-time development.

I am never going to be persuaded that an absence of type is a good thing and all the run time testing in the world will not make up for its absence. The combinations/permutations of state will grow in a horribly non-linear way with increasing complexity. The best we can hope for is that the app works OK most of the time.

Thanks for the tip on annotations which seems to provide a way of conditional compilation. That looks useful in the absence of a debugging system that works.

flowstate over 4 years ago

Well, technically speaking, Monkey C has dynamic duck types, but I get what you mean. I think dynamic type systems are favored by users of modern scripting languages because there's less cognitive load, but of course there's other issues with that. There's a reason TypeScript exists...

The problem with using annotations for compile-time exclusions is that they can only be applied at the file/class variable level, and not on a per-line basis, so there can be a bit more RAM overhead associated with creating separate functions/classes for the code you want to run conditionally. (Or alternatively, additional dev overhead associated with creating redundant copies of large functions with just 1 or two differing lines per target).

That brings me to my main issue with Monkey C: on devices with very constrained RAM (16 KB to 32 KB of available memory for data fields, for low to midrange devices), every language feature comes at a cost.

I've gone to extremes to save memory by writing the worst possible code (from a readability + maintenance POV). e.g.

- Using hard-coded constants instead of enums (enums make your code bigger, because they're implemented with symbols and evaluated at run-time)

- Inlining functions by hand (the cost of having a one-liner function that's used in several places is greater than the overhead for copying and pasting that one-liner everywhere)

- Replacing class vars with global vars, and classes with static functions (with context passed in as an arg)

- Removing strings/enums from config and asking the user to enter numerical constants by hand (yes, Garmin Connect config property strings consume app memory, even if the app itself never needs to access them)

- Bit-packing static data into arrays of UInt32 (this one isn't so bad, except all of the bitshifts / constants are hardcoded or auto-generated)

etc.

A lot of it is basically stuff that I would never do professionally unless you put a gun to my head. But having developed on embedded systems myself, I definitely see how some techniques from lower-level languages like C can help save memory in Monkey C (which ironically is a lot more like JavaScript + Java.) It's just too bad that Monkey C isn't really suited for them. (e.g. no built-in inlining)

Anyway, since you asked about conditional compilation, I hacked together my own little system for line-by-line conditional compilation using the C preprocessor (#ifdef, etc.), to save the maximum amount of memory without duplicating code needlessly. It's not pretty but it helped me squeeze the most out of that limited 16 - 32 KB of RAM, without needlessly copying and pasting a bunch of code.

https://forums.garmin.com/developer/connect-iq/f/discussion/7733/solution-for-line-by-line-mc-conditional-compilation/1076183

Unfortunately it's an eclipse solution (but the bulk of it is a shell script + gcc).The only eclipse-specific part is the "auto-build" part which triggers the script. Shouldn't be too hard to port VS Code by using a custom task:

code.visualstudio.com/.../tasks