[Glass] Issue_260

[Dale Henrichs]

On Mar 11 2021, at 9:06 pm, Jupiter Jones via Glass <glass at lists.gemtalksystems.com> wrote:
> Hi Dale,
>
> Is Issue_260 still current? I have time over the next few weeks to help make progress in something - would this be a good place to spend it?

Hello Jupiter,
I think it is pretty timely that you have time to work on issue #260[1] now, because about a month ago, I started thinking along the same lines ...
It's been a year or so since I kicked off issue_260 and not much has happened there ... I assume that most folks (including myself) had better things to do :) ...
The initial plan for issue_260 was to use st_launcher-based[2] scripts to drive topaz solo scripts to replace all of the 32-bit Pharo-based script. The topaz solo extent would have Rowan pre-loaded and I had created an extent based on 3.5.0 (IIRC) that's still available on github[3].
In the last year, I have written several st_launcher scripts in support of various development tasks for Rowan and I have not been happy with the utility of basing scripts on tonel class files. My basic problem is that while tonel class files ARE human readable, the format is a bit too verbose for my taste ... Don't get me wrong I really do love the fact that I can add support methods and instance variables to a script so that it is possible to refactor the mainline doit into a compact chunk of smalltalk code, but the extra structure that comes with the tonel class format adds extra noise to the file that gets in my way when reading code. Here is a simple error producing script from stlauncher[4] and a similar script in superdoit[5] and to my eyes the superdoit is easier to read. If you forego options and a usage section, the script[6] is much simpler than anything possible with st_launcher... Here's a sample[7] that illustrates the planned format/structure of a superdoit script.
Soooo I am thinking that moving forward the new scripts should be written using superdoit and separate classes in Rowan packages that are dynamically loaded into a solo extent that just contains Rowan pre-loaded.
I've got the basics of superdoit implemented, but not all of the sections are implemented yet ... but with the prospect of help on the horizon, I am close enough to be able to get the missing pieces functional.
At this point, we would want superdoit to work with 3.6.0 (the Rowan extent just needs a standard 3.6.0 product tree to run topaz solo). I've been doing development with 3.7.0 ... 3.6.0 is using an older version of Rowan and probably doesn't have all of things I'm using now (3.6.1 is using the same version of Rowan as 3.7.0, but it hasn't made it out the door yet), but I can supply you with an extent0.rowan.dbf for 3.6.0 that would work in the short term ...
You are already on the issue_260 team[8] so we can take this conversation to discussion list[9] on github to work out any additional details ... off the top of my head I will need to get the following things done before you are cleared for take off:
port superdoit to work with 3.6.0

last month I created the issue_260_2021 branch[10] where I intended to start setting up shop, so I just need to populate the branch with the artifacts needed to get started (basically the scripts from issue_260 branch[11] updated to reflect the new setup ...
extra credit for updating GsDevKit_home install scripts with new mac installation scripts ... this would be a good candidate for you to do as a first task while you wait for me to get things in order

The GsDevKit_launcher project is embedded in the issue_260 branch[12] ($GS_HOME/shared/repos/GsDevKit_launcher). This project was intended to be the place where the GsDevKit_home support classes were ported from Pharo ... in the st_launcher model the tonel class script files would be housed there as well ... so I would plan on porting the st_launcher scripts to superdoit scripts ... in doing this work myself, I'd know that superdoit was ready for use ...

If you're interested drop me a quick line and I will get busy getting things ready ...

In order to get you up to speed, once I've finished my work, it might make sense to use vnc/slack/cell(?) to do a bit of pair programming?
In the mean time you could bring up the devKitCommandLine pharo image (devKitCommandLine -D , then use the Pharo>>Pharo World Menu item on the tODE menu to browse the Pharo source) and browse the classes in the GsDevKit-CommandLIne, GsDevKit-SmalltalkCI-CommandLine, and GsDevKit-Tode-CommandLine packages to get an idea of what classes we'll need to port to GemStone ...
Dale
[1] https://github.com/GsDevKit/GsDevKit_home/issues/260
[2] https://github.com/dalehenrich/st_launcher

[3] https://github.com/GsDevKit/GsDevKit_home/releases/tag/v0.10.0
[4] https://github.com/dalehenrich/st_launcher/blob/masterV0.1/rowan/src/st_launcher-Scripts/StLauncher_Error.class.st
[5] https://github.com/dalehenrich/superDoit/blob/master/examples/simple/errorWithDebug.doit
[6] https://github.com/dalehenrich/superDoit/blob/master/examples/simple/error.doit
[7] https://github.com/dalehenrich/superDoit#executable-doit-with-methods-and-specs
[8] https://github.com/orgs/GsDevKit/teams/issue_260
[9] https://github.com/orgs/GsDevKit/teams/issue_260/discussions
[10] https://github.com/GsDevKit/GsDevKit_home/tree/issue_260_2021
[11] https://github.com/GsDevKit/GsDevKit_home/tree/issue_260
[12] https://github.com/GsDevKit/GsDevKit_home/tree/issue_260/shared/repos/GsDevKit_launcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20210312/63e07a8a/attachment.htm>