<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022 at 11:01 AM Johan Brichau <<a href="mailto:johan@yesplan.be">johan@yesplan.be</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"><div style="overflow-wrap: break-word;">Dale,<div><br></div><div>Looks great moving forward. Thanks for that.</div><div><div><br></div><div>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.</div><div>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). </div></div></div></blockquote><div>Okay ... <br></div><div><br></div><div>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 ... <br></div><div><br></div><div>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.<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 style="overflow-wrap: break-word;"><div><div><br></div><div>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.</div></div></div></blockquote><div>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 :)<br></div><div><br></div><div>[1] <a href="https://github.com/dalehenrich/superDoit/actions">https://github.com/dalehenrich/superDoit/actions</a></div><div>[2] <a href="https://github.com/dalehenrich/setup-superDoit">https://github.com/dalehenrich/setup-superDoit</a>  <br></div><div><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 style="overflow-wrap: break-word;"><div><div>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.</div></div></div></blockquote><div>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 :)   <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 style="overflow-wrap: break-word;"><div><div><br></div><div>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.</div><div>I did not look at Jadeite yet because I understand it requires Rowan?</div></div></div></blockquote><div>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 ...</div><div><br></div><div>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 :) <br></div><div><br></div><div>Dale<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 style="overflow-wrap: break-word;"><div><div><br></div><div><div>Johan</div><div><br><blockquote type="cite"><div>On 27 Dec 2022, at 18:27, Dale Henrichs <<a href="mailto:dale.henrichs@gemtalksystems.com" target="_blank">dale.henrichs@gemtalksystems.com</a>> wrote:</div><br><div><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" target="_blank">https://github.com/GsDevKit/GsDevKit_stones/tree/exp</a></div><div>[2] <a href="https://xdgbasedirectoryspecification.com/" target="_blank">https://xdgbasedirectoryspecification.com/</a></div><div>[4] <a href="https://github.com/dalehenrich/superDoit" target="_blank">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" target="_blank">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>
</div></blockquote></div><br></div></div></div></blockquote></div></div>