At DevCamp 2025, a few folks talked about the challenges of using puts while debugging. Its not really designed for that, so I thought I’d fix it and write a high performance logger for SketchUp.
Its called DevLog and it is pretty fast..
Short youtube video of DevLog in action
Let me know if you have any questions, feature requests.
The other thing that looks great about this is the dark background!
Extension available soon?
This should go into the native Sketchup, on both Mac and Windows.
The issue with puts is not just performance, but also the fact that, since the Qt migration, it has become asynchronous and has side effects on the tool we run (because it gives back control to UI and provokes view.refresh)
It awaits the Extension review AI…
WOW. Extension DENIED because new rules (?) require only using Ruby in Extensions, no binary code to do heavy lifting allowed.
Seems kinda dumb to me - and I guess means Vray, Enscape, and many other extensions will have to be removed from Extension Warehouse too. The whole point of having registered developers is so if an extension did do something nefarious, Trimble know who it is. This new rules seems to ignore this.
Second reason for denying DevLog was particularly special too: EM portal had autofilled the version to be 1.0.0 and DevLog code is 1.0 so it says version don’t match. Now in my book “1.0” has an implicit infinite number of zeros to the right that we dont write out - because that would be dumb - but apparently the automatic review system doesn’t understand numbers..
This has to be automated reviews going wrong right?
Sounds great Adam, hope it gets through soon 
First I have heard of this! What is the point of a “Live” C API then? And the examples of a SketchUp C extension in one of SketchUp’s GitHub repos?
ping @CraigTrickett
We have long had a problem with the EW and EM in SketchUp not knowing when a version is newer than what is installed into SketchUp. This is (was?) because the EW could only tell if the version in the warehouse was different than what is installed. This can (could?) lead to an older version overwriting a newer version of extensions.
It may be (I do not know truly) that they could be in the midst of an EW update that might require semantic version values. (Note, these are string values of numeric characters.)
There are some devs who have rejected semantic versions and created their own protocol, some involving revision letters. (Fredo comes to mind, but he posts his at SketchUcation.)
FYI, I have been repeatedly bugging them to add a timestamp line to the "extension_info.txt" file that would be the equivalent of:
"TIMESTAMP=#{Time.now.to_i}"
This file is written by the EW whenever it signs (and optionally encrypts) a RBZ extension archive. Integer comparison to determine what is newer should be quite simple and fast.