[Glass] Onwards with GsDevKit on Mac?
Johan Brichau
johan at yesplan.be
Tue Dec 27 11:01:30 PST 2022
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).
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.
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.
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?
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 <https://github.com/GsDevKit/GsDevKit_stones/tree/exp>
> [2] https://xdgbasedirectoryspecification.com/ <https://xdgbasedirectoryspecification.com/>
> [4] https://github.com/dalehenrich/superDoit <https://github.com/dalehenrich/superDoit>
> On Tue, Dec 27, 2022 at 4:42 AM Johan Brichau via Glass <glass at lists.gemtalksystems.com <mailto: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 <mailto:Glass at lists.gemtalksystems.com>
> https://lists.gemtalksystems.com/mailman/listinfo/glass <https://lists.gemtalksystems.com/mailman/listinfo/glass>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20221227/68c76312/attachment-0001.htm>
More information about the Glass
mailing list