Builtin functions for debugging


#1

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?


#2

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.


#3

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


#4

@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.


#5

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’.


#6

@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.


#7

it should be pretty easy

:slight_smile:


#8

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


#9

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.