<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Johan,</div><div><br></div>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:</div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">GDKStonesRegistry {
</div><div dir="ltr">   "hostname" : "hostname", <br></div><div dir="ltr">   "stones" :  { <br></div><div dir="ltr">      "gs_363" : "$XDG_DATA_HOME/stones/gs_364.ston" <br></div><div dir="ltr">        },</div><div dir="ltr">   "sessions" : { <br></div><div dir="ltr">      "gs_363" : "$XDG_DATA_HOME/sessions/gs_364.ston" <br></div><div dir="ltr">        }, <br></div><div dir="ltr">   "templates" : { <br></div><div dir="ltr">      "system.conf" : "$XDG_DATA_HOME/templates/system.conf", <br></div><div dir="ltr">      "gem.conf" : "$XDG_DATA_HOME/templates/gem.conf", <br></div><div dir="ltr">      "stone_spec.ston" : "$XDG_DATA_HOME/templates/stone.ston", <br></div><div dir="ltr">      "session_spec.ston" : "$XDG_DATA_HOME/templates/session.ston" <br></div><div dir="ltr">      } <br></div><div dir="ltr">   }</div></blockquote><div dir="ltr"><br><div>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) ... <br></div><div><br></div>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?</div><div dir="ltr"><br></div><div>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 .... <br></div><div dir="ltr"><div><br></div><div>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 ...</div><div><br></div><div>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 ...</div><div><br></div><div>Dale</div><div><br></div><div>[1] <a href="https://github.com/GsDevKit/GsDevKit_stones/tree/exp">https://github.com/GsDevKit/GsDevKit_stones/tree/exp</a></div><div>[2] <a href="https://xdgbasedirectoryspecification.com/">https://xdgbasedirectoryspecification.com/</a></div><div>[4] <a href="https://github.com/dalehenrich/superDoit">https://github.com/dalehenrich/superDoit</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022 at 4:42 AM Johan Brichau via Glass <<a href="mailto:glass@lists.gemtalksystems.com">glass@lists.gemtalksystems.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
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.<br>
<br>
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.<br>
On my M1 laptop, I have Jade working on a Parallels virtual machine running Windows ARM to connect to a Linux server running GemStone.<br>
<br>
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. <br>
That is where I am now :-).<br>
<br>
At this point, I wanted to reach out to the community and hear what other Mac users are doing?<br>
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?<br>
<br>
cheers<br>
Johan<br>
_______________________________________________<br>
Glass mailing list<br>
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank">Glass@lists.gemtalksystems.com</a><br>
<a href="https://lists.gemtalksystems.com/mailman/listinfo/glass" rel="noreferrer" target="_blank">https://lists.gemtalksystems.com/mailman/listinfo/glass</a><br>
</blockquote></div>