[Glass] Magritte on Gemstone install instructions

Iwan Vosloo via Glass glass at lists.gemtalksystems.com
Thu Sep 3 10:11:44 PDT 2015


On 03/09/2015 17:51, Dale Henrichs via Glass wrote:
> I'm sorry:) You haven't mentioned which version of GemStone you are 
> using or how long you have been using GemStone so I assumed that you 
> followed the instructions on the README[1] to install GemStone. I am 
> curious as to which version of GLASS/GemStone you are using. Are you 
> using Seaside?
Apologies Dale, we're on 3.2.6 on 64bit Linux and also Seaside 3.1.4. I 
worked with GemStone about 15 years ago... but that probably does not 
count all that much anymore :-). I have recently started working on an 
established project using this stack again (Seaside I know somewhat, but 
things like Magritte and Metacello are fairly new still).  What's 
happened here is that people often added methods (or changed methods) on 
infrastructural stuff like Magritte to get to a desired effect without 
necessarily understanding the frameworks in question and the impact of 
such changes. This is now a bit painful, so I am trying to get things 
back to the established versions out there... and will also bug this 
list with additions I'd rather contribute upstream than cobble together 
in the dark...

> To load Magritte into GemStone, the following expression should load 
> the latest 3.2 release of Magritte3 into the most recent version of 
> GLASS[2] running any version of GemStone:
>
>   Metacello new
>     configuration: 'Magritte3';
>     version: #release3.2;
>     repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main';
>     load: "The packages or groups that you are interested in"
>
Ah, great. Thanks. That confirms for me that we are using the correct 
repository, and that the bug I suspect really must exist.

> gsDevKitHome and tODE have been aimed at providing that kind of 
> support "out of the box" without gsDevKitHome each developer has had 
> to build their own supporting scripts.

I figured... We have a CI which builds stones and pharo images for us, 
we just fetch from there. So, if a developer wants to add something 
different you have to make it fit. Monticello seems to be the easiest 
way to deal with loading packages into a pre-existing image/stone - 
hence my focus there.

>> (Right now my priority is Magritte and making sure we give feedback 
>> re bugs and enhancements in the right place, and about the correct 
>> Magritte code base.)
> I used #release3.2 above, because I believe that it is functional 
> (unit tests passing), but if you are interested in using the latest 
> then perhaps #release3 (?) would be a better choice.

I checked releases 3.1, 3.2 and 3.5 and they all have the same problem. 
Magritte-Model adds:

NumberParser>>isNumber:
| stream |
     stream := aStringOrStream readStream.
     NumberParser parse: stream onError: [ ^ false ].
     ^ stream atEnd

Trouble is parse:onError: should be called on a subclass of NumberParser 
in GemStone as it eventually hits something that calls self 
subclassResponsibility. (Sorry, don't have the exact code in front of me 
now.)

But the bug baffles me: I wonder how others get past in on GemStone? 
Either I am missing something simple here or everyone does what we did: 
just supply our own method...

> If you are interested in learning about tODE I encourage you to use 
> the development branch of gsDevKitHome and follow these 
> instructions[3] (the earlier link was for the master branch of 
> gsDevKitHome). I have another structural change in the works 
> (separating out the tODE Client scripts/structure from the server) but 
> the basic functionality is pretty compete.
>
> Creating a tODE Pharo image is part of the installation process, so 
> the `installServer` script mentioned in the README[3] will create 
> everything for you including a running stone with tODE loaded...
>
> I will appreciate your feedback ... and I want to help where I can 
> with Magritte.

Thanks Dale, when not developing in Pharo we're using Gemtools and have 
all kinds of issues with it - I'd personally feel better if we can JUST 
stick to GemStone for dev as well. That's where my interest in tODE 
comes from.

Regards
- Iwan


-- 
Reahl, the Python only web framework: http://www.reahl.org



More information about the Glass mailing list