Builtin functions for debugging

Does Squirrel have any built-in functions to help debugging of code? Like python has the use of dir(), vars(), inspect modules

What would be the code if say I wanted to print out all the attributes of the hardware object?

Hi -

Imp Squirrel doesn’t include functions analogous to these Python modules, and currently it’s not possible examine objects like hardware in Squirrel except by querying them directly with

if (<name> in hardware) { ... } .

However, providing more general debug tools for Squirrel developers is something that a number of users have requested. So we are collecting a (rather long) list of proposed debug capabilities raised in our support channels, to consolidate, review and prioritise for a future release. I’ve added your specific request to this candidate list.

We’d be glad to hear from anyone with thoughts or ideas on the wider ‘Squirrel debug’ topic.

Harry, thanks for the response. Glad to know the team is actively working the issue.

@harryreiss

Hi Harry, there are a number of areas I’d like some more visibility on. I’d made a comment to Peter earlier about support an output pin on the device to provide a physical indication of CPU loading. That would be valuable.

Another ongoing problem for me is fragmentation. As I load more functionality in the device (particularly imp3s at this stage), I do get out-of-memory errors even when imp.getmemoryfree() is sitting between 15-20K free. This happens on devices with lots of discrete objects. It would be great to have a debug call that would give me a breakdown of the heap. I don’t need to see it in its fullest detail. A block of bits could be returned where each bit is set IF the corresponding 128bytes is allocated or partially allocated. 1 byte then represents 1K of heap space. This would help me understand if my actions are leading to a honeycomb of memory allocation.

Hi @coverdriven,

Many thanks for this feedback! I’ll add your requests to the list of candidate capabilities for review. Understanding heap memory usage in more detail – albeit different kinds of detail – has been a recurring theme among our customers and so is very likely to be among the first set of improvements implemented under this ‘epic’.

@harryreiss

Hi Harry, I can’t remember if I’d already asked for this. Has the team considered embedding a code coverage tool in a dev build of code? Since you have control of the IDE, it should be pretty easy to highlight as-yet unexecuted code, based on dev devices uploading coverage data.

it should be pretty easy

:slight_smile:

Always easy in the eyes of the person not actually responsible for doing it. :wink:

Thanks @coverdriven, I’ll add code coverage to the list of use cases. We’re still gathering requirements for this project, and there will come a stage where we have to prioritise and filter them, but I’ll make sure this is considered along with the others.