FeatureScript writers: Stop using println! And start using Report (New FeatureScript announcement)

jnewth_onshape

Actually, It's totally ok to continue using println!

But I wanted to introduce a new FeatureScript called Report that will help you control your featurescript notice area output. It's a bit hard to describe, so take a look at the HOWTO video below:

https://www.loom.com/share/1675f893610c4b09b2be446d53ffb3c5?sid=2c13d7c5-cd78-4449-8a13-583772e25596

Report lets you control which messages get reported to the Notices area via feature, making it much easier to debug your code. You can specify importance (info, debug, or warn), and you can "key" messages so that only certain key messages get reported. This is a lot simpler than having to remove all your println statements before shipping your feature!

Here's the document, which includes some helpful examples: https://cad.onshape.com/documents/2e41d9b14474514b465272af/v/906eb0d4ca75f78b4e3515f4/e/f6a2d12db7090f97b92d54ea

Let me know what you think in the comments.

jnewth_onshape

And a special thank you to @Evan_Reese for early review, feedback, and a cool icon! 

EvanReese

I'm excited to use this on my next feature development! I wanna also give credit to whoever made the Featurescript Notices icon at Onshape because I remixed it for this.

kevin_o_toole011

Sweet! It will be great to standardize on a common system of doing this.

One request: A simple FS function enableAllReports(). This lets an author get started writing with everything on by default (without needing to add an extra feature and navigate its UI), but then easily switch before shipping to only logging when needed.

jnewth_onshape

That's a good idea @kevin_o_toole011, I like it.

So the usage pattern would be:
1. start FS writing
2. add enableAllReports() in custom FS to turn everything on.
3. Eventually get around to adding a Report feature to the feature tree in the test part studio.
4. Remove the call to enableAllReports() (alternative: The Report feature itself ignores the directive if there is a report feature already active in the tree)

S1mon

For more info, @GregBrown did a video showing how he used the Report functionality.

https://www.youtube.com/watch?v=Vr9811KgqQQ

Caden_Armstrong

I like the idea, certainly helps to keep debug information hidden away but accessible for featurescripts pushed to production/users.

Is there a reason that its not part of the standard library?
Itd be a little bit easier to find if we just had to do an import(path:"onshape/std/report.fs", version:xxxx);

jnewth_onshape

@caden_armstrong
I thought about it but it didn't seem like a typical fit for the standard library. Perhaps we can reconsider, if people use it a lot.