[Glass] Onwards with GsDevKit on Mac?

[Dale Henrichs]

On Tue, Dec 27, 2022 at 11:01 AM Johan Brichau <johan at yesplan.be> wrote:

> Dale,
>
> Looks great moving forward. Thanks for that.
>
> In the meantime, I almost have the GsDevKit_home issue_260_2021 branch
> running the solo superdoit scripts to setup stones on my AlmaLinux arm64
> virtual machine.
> Well.. at least, (create|start|stop|delete)Stone already correctly
> operates a (running) stone but I noticed some parts of the createStone
> script is indeed still calling the Pharo3 image (commands
> setupSmalltalkCIStone and todeLoad, at least).
>
Okay ...

setupRuntimeSmalltalkCIStoneNew is one of those overly complicated pharo
entryPoints (had to handcode script entrypoints back then and I assume that
when $smalltalkCIConfigPath is not specified, the normal createStone code
is executed ...

todeLoad is used to load tode ... it is also an optional part of
createStone and the createStone.solo script could actually conditionally
call todeLoad, etc. for GsDevKit_home compatibility.

>
> I’ll take a deeper look at the GsDevKit_stones. I like that it says it’s
> greatly simplified. And we need a replacement for running the GemStone
> tests in Github actions as well.
>
If you look at the superDoit actions[1], you'll see that I've already done
github actions using .solo/.stone scripts ... at this point in time, I
consider that implementation as "ancient" already and plan to revisit the
framework[2] sometime after the release of 3.7.0 (or 3.7.1 depending upon
timing) ... with 3.7.0 and FileSystemGs in the base, it will be practical
to write .solo/.stone scripts without using Rowan ... file monkey business
is very painful without FileSystem :)

[1] https://github.com/dalehenrich/superDoit/actions
[2] https://github.com/dalehenrich/setup-superDoit

But I will be trying to fix the missing parts of the issue_260_2021 at
> least and see if I can at least get some Seaside development stone running
> on my Mac with GsDevKit_home.
>
If we're that close it makes sense for you to be able to make progress
without waiting on GsDevKit_stones ... It will be a good test case for
GsDevKit_stones on the mac using GsDevKit_home compatibility :)

>
> I will be using Jade as the IDE since ToDE is 32-bit only, and I already
> tried Pharo on the ARM Windows, which got me nowhere.
> I did not look at Jadeite yet because I understand it requires Rowan?
>
Yes, Jadeite does require Rowan. Rowan and GLASS have yet to be introduced
to each other :)  ... I mentioned it because tODE is loaded as part of
"standard"  stone and tODE being in the image is integral to managing
loaded baselines and virtually all of the (batch) tests I run have tODE
loaded, so whether or not one uses the 32bit tODE GUI, I haven't done a lot
of work to disentangle tODE from GLASS and that work will be done when
Jadeite and Rowan are ready ... actually Jadeite and Rowan will not be
ready until there is a relatively smooth runway away from tODE ...

A slight disclaimer ... we do run Seaside/GLASS tests without tODE present
in the image, but the lack of code management tools in the image without
tODE present makes writing a completely independent test suite that
parallels the full set of projects currently tested with tODE in the image,
a daunting task:) The daunt will be dedaunted when Jadeite and Rowan come
on the scene :)

Dale

>
> Johan
>
> On 27 Dec 2022, at 18:27, Dale Henrichs <dale.henrichs at gemtalksystems.com>
> wrote:
>
> Johan,
>
> Regarding GsDevKit_stones[1], over the weekend I happened to be splashing
> around with adding support for using XDG Base Directory Specification[2]
> for a stones registry. The idea is that instead of porting the
> GsDevKit_home support code from Pharo to GemStone, that we'd  specify the
> information that was previously encoded in Pharo code and on disk in a
> registry .ston file located in a well-known location
> ($XDG_CONFIG_HOME/gsdevkit_stones/registry/<host-name>.ston) that looks
> something like the following:
>
> GDKStonesRegistry {
>>    "hostname" : "hostname",
>>    "stones" :  {
>>       "gs_363" : "$XDG_DATA_HOME/stones/gs_364.ston"
>>         },
>>    "sessions" : {
>>       "gs_363" : "$XDG_DATA_HOME/sessions/gs_364.ston"
>>         },
>>    "templates" : {
>>       "system.conf" : "$XDG_DATA_HOME/templates/system.conf",
>>       "gem.conf" : "$XDG_DATA_HOME/templates/gem.conf",
>>       "stone_spec.ston" : "$XDG_DATA_HOME/templates/stone.ston",
>>       "session_spec.ston" : "$XDG_DATA_HOME/templates/session.ston"
>>       }
>>    }
>>
>
> I think it would be relatively straightforward to write a set of
> createStone, deleteStone, startStone, stopStone, startNetldi and
> stopNetldi  .solo superDoit scripts[4]. My fist cut is planned to be a
> standalone framework with the create/delete/stop/start scripts and the
> registry that would support arbitrary stone directory structures ... then a
> second cut would be made to integrate the support of GsDevKit_home into
> GsDevKit_stones (replacing the use of the Pharo3 image in the various
> GsDevKit_home bash scripts) ...
>
> Settling on using XDG Base Directory Specification has basically settled
> the "where do i put things" question.Of course, I understand that the XDG
> Base Directory Specification is NOT supported on Mac, but it should be
> relatively straightforward to map XDG_CONFIG_HOME and XDG_DATA_HOME to Mac
> specific locations...I'd think?
>
> I'm hoping that GsDevKit_stones will be able to supplant GsDevKit_home
> moving forward. GsDevKit_home and tODE will fade away with Rowan and
> Jadeite (for Windows, Linux, and Mac) picking up the slack ....
>
> Since you and Jupiter last worked on the issue_260_2021 branch, we've
> included superDoit support in the product (as of 3.6.4) and a port of
> FileSystem to GemStone is planned to be included in 3.7.0. We've also been
> steadily improving GsHostProcess for running system exectubles ... so if we
> were to blow the dust off of issue_260_2021, we'd probably want to target
> 3.7.0 as the .solo script platform ...
>
> Finally, my inclination is to focus efforts on GsDevKit_stones (with a
> GsDevKit_home "bridge") ... Overall, the disk structure AND script
> structure of GsDevKit_home is way more complicated than it needs to be and
> I don't think that a one for one replacement of the GsDevKit Pharo image
> and $GS_HOME/bin scripts is worth the effort ... a lot of the logic that is
> distributed across multiple bash scripts and the Pharo image can be
> consolidated in a set of core support classes  that can be shared across
> multiple .solo scripts ...
>
> Dale
>
> [1] https://github.com/GsDevKit/GsDevKit_stones/tree/exp
> [2] https://xdgbasedirectoryspecification.com/
> [4] https://github.com/dalehenrich/superDoit
>
> On Tue, Dec 27, 2022 at 4:42 AM Johan Brichau via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Hi there,
>>
>> I recently started working on Apple M1 and this presents some challenges
>> moving forward with development for and using GemStone GLASS, both for the
>> open-source Seaside as well commercial projects.
>>
>> On my intel Mac, I used to use ToDE and GemTools (yes…) running inside a
>> Parallels Mojave VM to connect another Parallels VM with GsDevKit_home
>> running either Ubuntu 18 or Centos 7.9.
>> On my M1 laptop, I have Jade working on a Parallels virtual machine
>> running Windows ARM to connect to a Linux server running GemStone.
>>
>> As I prefer installing GemStone on a Linux VM instead of installing it
>> directly on my Mac, I am currently experimenting running the ARM version of
>> Alma Linux to get GsDevKit_home installed (with superdoit scripts in the
>> issue 260 branch, which will be necessary) and see where I can get from
>> there. It does not seem entirely impossible as I got some scripts adapted
>> from the CentOS version, though I need to get the issue_260_2021 branch
>> updated to later versions of superDoit to install a stone.
>> That is where I am now :-).
>>
>> At this point, I wanted to reach out to the community and hear what other
>> Mac users are doing?
>> I notice Dale got started on a simplified version of GsDevKit_home
>> (GsDevKit_stones) ? So maybe, given the unfinished state of the GsDevKit
>> issue 260 branches, this is a more likely direction to go?
>>
>> cheers
>> Johan
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20221227/7967cefa/attachment.htm>