[Glass] Gemstone/S 3.7.0 / 3.7.1
Marten Felddtmann
m at feldtmann.online
Fri Apr 5 01:38:44 PDT 2024
Hello Dale,
what an information :-( ... but perhaps after using Gemstone/S for 8
years now its time for a summary about that time.
Starting with Gemstone/S eight years ago was based on three points:
* easy persistency, object-oriented (or better: heard lot of good things
about it)
* active database, database "kernel" development on a very high level
programming model
* Smalltalk
After 8 years the first two points are still strongly valid. My work
colleagues do not understand this or do not see this as main points. Its
not mainstream - that seems to be the major point. As I mentioned in my
Londoner Talk about Gemstone/S experiences, there is an opinion, that
working in a NON mainstream area is not worth per se (you may like that
or not, but I do now understand these people).
Smalltalk itself is not that important now for me, though I really love
the language and the possibility on the server side are great - so I see
it more as a database language in my case - but if I had to code in C#,
Python or other languages - it would not matter for me.
I tried to open it by going a clear API only oriented way with C#, Java,
Python, Javascript bindings - but it was not worth the time (to convince
the colleagues) , because my work was again NON mainstream. But it was
worth the time to get a better structure and better applications.
I've published now 8 customer applications over the last 8 years - all
based on Gemstone/S and the UI written completely in Javascript and all
stuff is API driven.
So, I've to go seven further years ... and its totally ok to say, that
after that the Gemstone/S experiences in my companies will be closed.
None of the applications I've written are cash cows ... so they could be
closed over the years.
So, what would I do differently now ?
* Stay with the core Gemstone/S kernel code as much as you can. This
source base is maintained and comes from one location
* Do not use other Pharo/Squeak/VAST,VisualWorks code in your
application unless you have ported it to Gemstone by yourself (this is
an aggressive statement)
* Do not use Github as the base for your source code loading sequence.
Do not reference projects on Github in your code.
* Use prebuilt images for your development (as the seaside and core
kernel delivered by GemtalkSystems in their product). For each new
release of Gemstone/S do this work ONCE and then that's it.
* Look for a good infrastructure to communication with other programming
languages
* Exercise the upgrade process. This has been proven to be the most
critical part in all Gemstone/S projects (perhaps due to the mistakes
mentioned above) so far.
* Look carefully about the license restrictions you get with Gemstone/S
licenses. The introduction licenses (with limitations especially CPU
usages) of Gemstone/S encourages a different programming model than a
full-blown license.
* Do not use Smalltalk in areas where it is not well suited, one point
is the UI. Look for other languages
* Now with care: Consider PostgreSQL and RabbitMQ as base parts of your
infrastructure. There are base interfaces from Gemstone available at
Github for that. They have not the quality of Gemstone/S product, but
they are doing their work and are isolated projects at Github.
*
And what would I not change ?
* The API way is pretty cool
* Think in other Programming Languages, use them in your projects - but
the mistakes mentioned above are also valid for projects in other languages.
So, throwing away Pharo32/64 bit out of GsDevKit* is the CORRECT
solution. I can understand you here. The base infrastructure for a
product should only depend on stuff, delivered by the product itself.
Due to the fact, that Gemstone/S is missing VERY MUCH in that area
(product area - backup scripts, update scripts, starting, stopping
scripts and so on), it was the best situation those days to join
GsDevKit_home to fill that gap. I do not use Seaside, I do not use tODE
- I mainly use DevKit for having a better infrastructure in maintaining
my applications.
The other point I use GsDevKit_home for is GLASS and its loading of all
the network stuff in ZInc* projects (despite the mistakes I mentioned
above), so one gets HTTPS and HTTPS support.
So, my option seems to be to stay with Gemstone/S 3.6.x branch over the
next years.
Marten
On 05.04.24 01:13, Dale Henrichs wrote:
> ***I inadvertantly left glass off my original reply ... resending to
> entire list***
> Marten,
>
> TL;DR:
> GsDevKit_home is not being maintained anymore.
>
> The heir apparent GsDevKit_stones is available but is not quite a
> complete replacement for the GsDevKit_home functionality... and is
> still under development.
>
> You can create/delete/start/stop stones and netldi with the current
> GsDevKit_stones.
>
> If you are brave/desperate and willing to give me constructive
> criticism (see the missing pieces section below), send me an email and
> I'll provide you with "getting started instructions".
>
> I wish I could say that I have a replacement solution for you, but if
> you look back through your emails, I sent mail 5 years ago that I was
> not going to be able keep GsDevKit_home working without help
> ... GsDevKit_home relies on a 32 bit Pharo image and support for 32
> bit executables has been slowly going away ... a few developers have
> stepped up to help, but the effort did not reach a satisfactory
> conclusion ...
>
> 3 years ago, I started work on superDoit[1] a scripting environment
> based on 64bit GemStone.
> I started superDoit with the intent that it would be a replacement for
> the 32 bit Pharo image in GsDevKit_home.
>
> 2 years ago, it became apparent that just replacing the 32 bit Pharo
> image with a superDoit script wasn't going to be feasible, so I
> started work on GsDevKit_stones[2].
>
> GsDevKit_stones is much simpler and more flexible than GsDevKit_stones
> and is "entirely" written in Smalltalk. It is based on a shared Rowan
> code library. GsDevKit_stones also leverages the new FileSystem
> support that has shown up in the recent releases of GemStone ...
>
> Of course the bad news in this story is that very little of the "code
> base" (mostly bash scripts) survives the transition from bash to
> smalltalk, so there has been a lot of work to do to rewrite the
> GsDevKIt_home scripts in superDoit.
>
> Most of the functionality present in GsDevKit_homes has been
> implemented in GsDevKit_stones scripts[3], but there are a few
> critical pieces still missing:
>
> 1. upgradeSeasideImage functionality
> 2. a way to "attach" GsDevKit_stones to an existing GsDevKit_home
> environment
> 3. a replacement for the tODE GUI
> 4. reviewing/improving help messages for the scripts, including an
> eye toward consistency of terminology across the various scripts
>
> The replacement for upgradeSeasideImage requires a fairly significant
> refactoring of the code used in the existing scripts.
>
> Attaching GsDevKit_stones should be a relatively easy project to put
> together using existing scripts, but until GsDevKit_stones is close
> ready for release it isn't necessary.
>
> The ultimate replacement for the tODE GUI will be a combination of
> Jadeite[4][5] and Rowan 3[6] ... Jadeite and Rowan are being developed
> internally but are not quite ready for release.
>
> With the release of 3.7.1, we shipped an experimental Rowan 3 extent
> that is suitable for use with GsDevKit_stones scripts ... not production.
>
> I personally have been using GsDevKit_stones in my work for the last
> year and as I mentioned before, GsDevKit_stones is being used by
> smalltalkCI[7] to drive the gemstone jobs for the last year as well ...
>
> If you are hurt by the lack of the32 bit tODE GUI ... yes there are
> some tODE GUI fans out there:). There is a rough workaround that might
> help ... send me email for details.
>
> Overall, I think that there are still some rough spots, and I can't
> promise that GsDevKit_stones won't undergo some major changes before
> it's ready for release...but it is the only alternative for you if you
> are experiencing 32 bit pharo image issues.
>
> I wish I had a better answer, but I cannot afford to spend time trying
> to fix 32 bit pharo related issues ... I think my time is better
> spent doing what I can to make progress on GsDevKit_stones ...
>
> Dale
> [1] https://github.com/dalehenrich/superDoit
> [2] https://github.com/GsDevKit/GsDevKit_stones
> [3] https://github.com/GsDevKit/GsDevKit_stones/tree/v2/bin
> [4] https://github.com/GemTalk/JadeiteForPharo
> [5] https://github.com/GemTalk/Jadeite
> [6] https://github.com/GemTalk/Rowan/tree/masterV3.2
> [7] https://github.com/hpi-swa/smalltalkCI
>
> On Wed, Apr 3, 2024 at 2:16 PM Marten Felddtmann via Glass
> <glass at lists.gemtalksystems.com> wrote:
>
> Hello,
>
> I would like to know, if 3.7.1 is supported by GsDevKit_home ...
>
> createStone gc371 3.7.1 - does not work and throws errors:
>
> =================
> GsDevKit script: startStone -b test371
> path: /datadisk/GsDevKit_home/bin/startStone
> =================
> /datadisk/GsDevKit_home/server/stones/test371/product/bin/waitstone[Info]:
> GemStone version '3.7.1'
> Network service
> !#dir:/datadisk/GsDevKit_home/server/stones/test371/logs#log:%N%P.log#server!test371
> is ready.
> stone test371 already running, to restart use -r option ::
> startStone -b test371
> Install tODE on stone: test371
> [02.04.2024 19:33:10.432 CEST]
> gci login: currSession 1 rpc gem processId 133239 socket 8
> [02.04.2024 19:33:10.506 CEST]
> gci login: currSession 1 rpc gem processId 133245 socket 8
> Error: while installing tODE on server: 'a ImproperOperation
> occurred (error 2085), Expected nil to be a Boolean.'
> TDTopezGemStoneClient(Object)>>error:
> TDTopezGemStoneClient>>installTodeBlock: in Block: [ :ex | ...
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [ self
> exceptionHandlerBlock cull: exception ]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> GsErrorNotification(Exception)>>signal
> TodeInstallSession(TodeSession)>>signalServerError:
> TodeInstallSession(GciSession)>>getNbResult
> TodeInstallSession(GciSession)>>getNbResult
> TodeInstallSession(GciSession)>>getNbResultAsOop
> TodeInstallSession(GciSession)>>rawExecuteStringNB:envId: in
> Block: [ ...
> BlockClosure>>ensure:
> Cursor>>showWhile:
> TodeInstallSession(GciSession)>>rawExecuteStringNB:envId:
> TodeInstallSession(GciSession)>>executeStringNB:envId:
> TDTopezGemStoneClient>>installTode: in Block: [ :installSession | ...
> TDTopezGemStoneClient>>installTodeBlock: in Block: [ installBlock
> value: installSession ]
> BlockClosure>>ensure:
> TDTopezGemStoneClient>>installTodeBlock: in Block:
> installTodeBlock: installBlock...
> BlockClosure>>on:do:
> TDTopezGemStoneClient>>installTodeBlock:
> TDTopezGemStoneClient>>installTode:
> TDShell>>executeLoadServer: in Block: [ ^ self topezClient
> installTode: options ]
> Dictionary>>at:ifPresent:ifAbsent:
> Dictionary>>at:ifAbsent:ifPresent:
> TDShell>>executeLoadServer:
> TDShell>>executeBuiltIn:
> TDShell>>evaluateCommand:batchMode:
> TDShell>>evaluate:batchMode: in Block: [ :command | result := self
> evaluateCommand: comma...etc...
> Error on or near line 99 :: devKitCommandLine loadTode test371 ::
> devKitCommandLine loadTode test371
> Error on or near line 55 :: todeLoad test371 :: todeLoad test371
> Error on or near line 220 :: createStone test371 3.7.1 ::
> createStone test371 3.7.1
>
>
>
>
>
> _______________________________________________
> 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/20240405/0e59b867/attachment-0001.htm>
More information about the Glass
mailing list