JSL 4.0

[#1]

Does it make sense to use the Scripters Club platform to discuss new and future enhancements to JSL? The aim would be to organize ideas, inform people about new features, and advertise future improvements.

Game Changers:

Expression Handling	9
Data table subscripting	13
Add-In Manager	2017
Python and R embedded	18

Cool/helpful new Features:

Graph dependent formulas (scoped formulas)  [@Graph, @Overlay, @X]	19
new Col aggregations Dif() and Lag() formula functions by column group (byVar argument)        dif() / lag() -> col at(), row() -> col sequence() Add dense ranking to Ranking Tie and Col Rank functions            col score() Col N Categories                                        col N unique() Group by - sooo useful!!! how about Interpolate?                                           col interpolate()	19
Get Unique Items        set unique()   - and other set ...() operations	19
optimized syntax highlighting in JSL editor    (find errors with commas, semicolons and brackets)
Expression Indexing: read and write access
JSL function to get the current status of modifier keys
Option or function to evaluate a custom column formula at once, or cache values between rows
Keyword arguments for functions
Comprehensive scripting index

nice to have:

JSL bit operations

[#2]

I don't know if multiple users can get write access to the list in the main post?

What improvements in JMP19 do you like the most?
What's missing?

Which approaches can be considered "game changers"?

[#3]

Regardless of whether you like it or not, it's unfortunate that the reaction speed when you click on it is a little slower than the previous version of 18. Of course, it depends on the PC specification, but I think there is a clear difference in reaction speed.

[#4]

Hi Hogi, is there a summary provided by JMP highlighting new JSL features for JMP19? I haven't read through any documentation yet, I'm still just poking around and testing 19.0.1 vs my previous installations (17.2 and 18.2).

On the add-in builder:

Over the last 10+ years, I developed a couple of add-in toolbars that had mostly custom icons (jpgs, etc) stored on a network drive. The way I coded it and set it up, JMP was fetching all those icons every time a JMP window was opened, because JMP needed to display the toolbars. By the time I realized what was causing the problem (was up to around 40 scripts), it could take several seconds to open up a JMP window. It happened so gradually because after the first year, i only added a new script once in a while.

Now, JMP19 has a new add-in builder that automatically includes the jsl and icon files as part of the add-in, so when a user installs it, the jsl and icon images will be copied to a local home folder but I've set it up so that JMP users (on 19+) can auto detect that add-in has been updated when their installation of JMP 'sees' an update to the server .jmpaddin file, and they will be prompted install the update when they restart JMP. The process is a bit different than my old method but it was the perfect fix at the perfect time... I just discovered root cause in the last couple months.  So it was really helpful for me, but I suspect mine is a pretty obscure case.  Though maybe not so obscure in this forum. Thanks to the JMP support team and the developers for helping with the fix.

Thanks,

Mike

[#5]

To my knowledge there are no release notes ("with all the details"),
just a general "overview":  JMP New Features and Release Notes 
and this page with information about security updates: https://www.jmp.com/en/company/trust-center 

This is why I thought it would be helpful to provide a brief overview here.
any comments and links to additional features are welcome.

[#6]

AddIns - 

Besides the standard "AddIn Builder" which is included in JMP, one can (SHOULD!!!)  use 
Add-In Manager     @Justin_Chilton  -> now via the Marketplace: Add-In Manager
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-C... 

New in JMP19: the update check which is directly included in JMP.
In previous versions, one could set up a similar functionality via UpdateCheck.jsl (from AddIn Manager).
Did somebody compare the speed of the 2 approaches?
e.g. for 40 AddIn update checks via UpdateCheck vs. the new Functionality?
Does the new function compare the file date - or some content?

btw: @mikedriscoll 
An interesting concept, very similar to your previous one:
Enterprise Add-in Management Strategies (2025-US-30MP-2576)      @MikeD_Anderson 
The important difference of the proposed concept:
The folder with the "current" version of the scripts (and icons?) is stored on a OneDrive/Sharepoint and available on the local system via a synchronized folder.

[#7]

I created my own update scripting based on the update stuff Justin originally included and haven't tested side by side with the new methods in 19. I will say that it may be faster via JMPs methods given they are looking at a source folder for an updated file, while Justin's methods (at least the ones I use) may lag depending on where the metdata master files live. From the couple times I've been prompted by JMP to udpate an addin in jmp19, it 'feels' as fast as what I already have implemented.

Since the new methods in 19 seem to basically be looking for new files in a location and not be tied to any builddate metatdata, while I like this approach in general, there is no real control on what constituts a 'source folder' ... for instance, if i drag an addin in from my downloads folder and it asks if i want to check for updates, it will list the downloads folder as the source to be checking. In addition, it doesn't separate between what may be prod vs test versions of an addin, and the "source" folder couldbe incorrect if a user checks for updates, but it was a test version installed from a different location.

I have requested here that we be allowed to codify these pieces (mostly for this thread since we briefly chatted on the other wish list item).

[#8]

@nathan-clark from what I see with JMP19's add-in builder, it is not quite like that. Unfortunately I don't have time at the moment to fully document my experience, but I'll quickly outline what I have. I am not an expert though. My goal was to fully replicate my old shared drive version, but in a different area using the JMP19 method.

Create an add-in using file->new->add in.
Set up the add-in by adding your scripts / icons. For mine, these are on a shared drive.
Have it automatically update files (in include files tab), and check for updates when JMP starts in General tab.
Save as to create a new .jmpaddin in an accessible location. Leave it there and have others install from that location.

Other JMP users will install from that location and their version of JMP will check that location to detect changes.

When you want to edit any files, open up the add-in builder / jmpaddin file so you are seeing the add in editor. then make your edits to the script. Then the 'save' button should appear visible in the add-in builder.  Or use save as and save the addin with the same name.  If you just drop an updated script file, or edit the jsl file and close it, and then later open the add-in builder, you won't see the save option. This  a bug that has been reported to the developer.

JMP users using older versions of JMP will need to update the add-in by reinstalling the .jmpaddin file. JMP19 users should be prompted to update the add-in if they installed it from the same location. I don't know what happens if we go emailing the .jmpaddin file... presumably JMP wouldn't know where to later check for updates.

[#9]

That makes sense @mikedriscoll. Unfortunately, that relies on JMPs implemenation of addin creation. I have way too many addins for that and now that we have them all managed via github, those mehods aren't scalable which is why I've requested the codifying of specifics in the addin.def file.

I think JMP19 is making some good strides for addin management, but long term more options need to be in place for the scale various people / organizations reach with addin management. And with a few updates from JMP, I believe I can start deprecating some of my current addin update infrastructure.

[#10]

I also see that some things may become easier in JMP 19 with regard to add-ins.

I like this way of developing my add-ins best:

• in an unzipped folder in my documents folder
• To install it, I open the .def file in JMP
• I edit the .jmpcust file in a text editor (this is a little tricky, but it works perfectly for me, as this is to be done not for the most changes at all)
• The menu items refer to scripts in this folder
• I can test/edit the scripts in this folder directly (which I find a big advantage, as I find copying and updating the files in .jmpaddin via the menu quite tedious, unnecessary, and error-prone).
• For deployment, I have a small PowerShell script that packs the add-in and moves it to a shared location for other users (and, by the way, creates a copy of the older version so that a rollback can be performed if problems arise).

[#11]

yes, I would like discussing about future enhancements etc. in Scripters club, i.e. this topic could be part of, but should not be the only topic. Thanks for the suggestion.