Mac users! ‘Squinter’ utility for managing device, agent code and libraries


New version (b106):

Squinter now handles multi-line comments in code, and better supports the importing of non-library files. Libraries and other files can be imported using #import and/or #include (use which you prefer).

Squinter also supports the #define directive, eg.
#define __MULTIFILE_CONSTANT__ = 45.6

Because of the inclusion of any file (ie. not just libraries/classes) you can, for example, have a file ‘constants.h’ which lists your #defines and then #include or #import ‘constants.h’ into your agent and/or device source code files.

So if your device code contains

`#include "constants.h"

local myVar = __MULTIFILE_CONSTANT__;`

it will compile to

`local myVar = 45.6;`

Help should be working properly now too.


Hot on the heels (to squash a couple of irritating bugs that slipped through):


Further work yields:

Now with Sparkle support for in-app updates (and some bugs dealt with).


Now available via Sparkle: Squinter 1.0.111 (if you have an older version than 1.0.110, please update using the link in the comment above, and then select ‘Check for Updates…’ in the Squinter menu).


Now available via Sparkle: Squinter 1.0.112 (if you have an older version than 1.0.110, please update using this link, and then select ‘Check for Updates…’ in the Squinter menu).


  • You can now stream logs from multiple devices simultaneously
  • Logging devices are indicated in the 'Current Device' pop up and the device lists under each model in the 'Models -> Current Models' menu
  • The 'Devices' menu now has an 'Open Agent URL' command to call up the agent URL in your browser
  • Tooltips added to the toolbar items
  • Added 'Refresh model list' toolbar item
  • Updated BuildAPIAccess to 2.0.0

Bug Fixes

  • Fixed an incorrect 'Project Info' toolbar icon


Now available via Sparkle: Squinter 1.0.113 (if you have an older version than 1.0.110, please update using this link, and then select ‘Check for Updates…’ in the Squinter menu).


  • Colouring of multiple device log streams to aid readability
  • Agent URLs in the log (from 'Get Device Info') are clickable links
  • #imported files (ie. non-libraries) now saved in project
  • User is notified when local files and libraries are removed from source code

Bug Fixes

  • Displaying long code listings in the log doesn't invoke the beach ball
  • Fixed an issue in which #imported files were not being correctly listed
  • Fixed an issue in which a project was closed with unsaved changes, the user asked to save the changes first, but they were not being saved
  • Fixed an issue in which a project was closed with unsaved changes, but was not actually closing


Beginner’s mistake, maybe helpful for others. The import statement is of course not
#import </Users/[username]/Documents/ht16k33.class.nut/>
as initially stated, but
#import "/Users/[username]/Documents/ht16k33.class.nut"
At least in 1.0.115


Version 1.0.116 is out, if you’d care to click on ‘Check for Updates…’


Hi Smitty,

Having trouble importing files from a sub-directory i.e. #import “utilities/PushID.class.nut” or
#import “utilities\PushID.class.nut”

How do I need to be specifying this?

I notice if I set my working directory to match my project directory it’s OK, but this isn’t manageable because I have various Git projects in different directories so need a more modular solution.


Interesting, @Scribe. Thanks for the find: there’ll be a fix for this in 1.0.117, out shortly.


And 1.0.117 is out now!


Hi @smittytone, we have a new team member but their Squinter is unable to fetch a list of models, any idea? On my version I’m also unable to Upload compiled code anymore, the ‘Upload’ button remains greyed out even with a model and device selected, any ideas?


Unable to fetch models suggests and incorrect Build API key - what errors are being displayed?

Latter sounds like a bug, but I believe this was zapped by an earlier update. What version you running?


Hi! I see the same (can’t retrieve a list of models and devices) , but I wonder if it is down to my environment.

What is the expected behaviour if a) two installations of Squinter use the same API key, and b) if two different Electric Imp logins use the same key - both collaborating on the same projects?

Thanks in advance


a) Both should be able to get the model and device details. Squinter operates asynchronously, only getting data when it needs to, so both should be able to issue and receive requests for the same key.

b) That’s expected. The Build API key allows user A to see the models of account B by using a Build API key supplied by B.

Right now, Squinter doesn’t support multiple accounts, ie. multiple Build API keys, though this is on my to-do list. But you can easily paste in different API keys in the Preferences in order to access different accounts.


Thanks @smittytone , that definitely seems to clear up what should be seen - it’s just that for some reason, we’re having difficulty getting it to work. I user A in your example above. If I generate my own API keys, I can see all my devices. If user B generates an API key and I try to use it, I get:

Acquiring list of devices…
[WARNING] There are no devices listed on the server.
Getting a list of models from the server…
[WARNING] There are no models listed on the server.

I can swap back to my API key and see my devices again with no issues.

I’m working around it at the moment by keeping an IDE window open and using your ‘Copy code to clipboard’ function.

Is there anything I can provide in the way of logging, etc, that could help work out what is happening?



Hi @smittytone, I think I’ve found what was happening.

The key I got was generated by another collaborator, rather than the actual owner of the devices. What caused confusion is that When the collaborator tried the key, messages were generated in the log stating that no devices and models could be found, but when this happens, the ‘Current Device’ list isn’t updated to reflect that none are available, and was still showing a fully populated list related to the API key which had just been replaced.

The list was refreshed upon the next reload of Squinter, showing no devices available.

So it seems the simplest means to avoid confusion is to update the list whenever an API key is changed, but if an invalid key is used, or a key associated with no devices and models, the list is cleared.



Your earlier comment suggests this was a ‘wrong API key’ issue, and that seems to be borne out by your later experience.

I’ll update Squinter to refresh lists when the API key changes.



Yes - we thought it was the right key, but it was generated by the wrong user :slight_smile:

Thanks for your prompt replies and help with this!

The only issue I’m seeing now is that for some of my projects, the ‘Upload’ button is greyed out. I can switch my current project between two different projects, and watch as it greys out the compile button for one, but allows me to upload for the other.

I’ll try to dig in to what the difference is between the two…



Squinter now updated to 1.0.118. Select ‘Check for Updates’ in the Squinter menu