[Glass] SafelyPerformBlockRequiringAbort error when running Seaside

Dale Henrichs dale.henrichs at gemtalksystems.com
Thu Feb 20 10:25:29 PST 2020

The GsDevKit/Seaside31 repository was originally created (in 2013) 
because Seaside development was not available on Github (until 2015). A 
little over a year ago[1], I decided to start recommending that the 
official SeasidSt github repository[2] be used instead of 
GsDevKit/Seaside31 and in concert with that I stopped updating the 
baseline for GsDevKit/Seaside31. My last update was last April[3]. If 
you look at the travis build history[4], you'll see that the last time a 
travis build ran green was 3 years ago[5]. Up until last April, the 
GsDevKit/Seaside31 builds were tested by internal builds on a regular 

Sooo, I would recommend that you switch to using SeasidSt/Seaside, but 
if that is too big of a job to take on - the current version of 
SeasidSt/Seaside is 3.4.0[6] and GsDevKit/Seaside31 is still at 3.1, so 
it wouldn't necessarily be an easy migration, you could update the 
baseline, using this commit as reference[7], since that's when I added 
3.4 to the lineup and it is very likely that that is all that is needed 
... I'm reluctant to update the GsDevKit/Seaside31repository, since it 
doesn't use SmalltalkCI and SeasidSt/Seaside is the Seaside repository 
of record ...

I see that SeasidSt/Seaside has a tag for 3.1.3[8], but that version 
also would need to have it's baseline updated and it seems that 
Travis-CI support was added after the 3.1.3 release ....

In the short term it looks like your best bet would be to add 3.5.x to 
the GsDevKit/Seaside31 baseline and then run the tests ... when I added 
3.4 to the baseline it looks like it wasn't necessary to update the 
Seaside code base (most of the gemstone version specific changes get 
made in GLASS1 and that is consistently maintained), so that will likely 
be all that is necessary for you to move forward....

In the longer term, if you (and others?) expect to continue using 
Seaside 3.1 for the foreseeable future, it would be worth adding 
travis-ci support to 3.1.3 on SeasideSt/Seaside ... and it would be 
useful to get Johan and Philippe involved in a discussion on how that 
would be done ...  a 3.1.3 branch could be created where the travis 
support could be added and the baseline changes for later versions of 
GemStone  could b managed.

I don't have a lot of free time right now, but I could help folks work 
through any kinks in the process that might run into ...


[2] https://github.com/SeasideSt/Seaside
[4] https://travis-ci.org/GsDevKit/Seaside31/builds
[5] https://travis-ci.org/GsDevKit/Seaside31/builds/257455740
[6] https://github.com/SeasideSt/Seaside/releases
[8] https://github.com/SeasideSt/Seaside/releases/tag/v3.1.3
On 2/19/20 2:22 PM, BrunoBB via Glass wrote:
> Dale,
> I tryed again in a fresh installation (without my packages only Seaside) and
> the same error.
> To install Seaside:
> Gofer new
>    package: 'GsUpgrader-Core';
>    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';
>    load.
> (Smalltalk at: #GsUpgrader) upgradeGrease.
> GsDeployer deploy: [
>    Metacello new
>      baseline: 'Seaside3';
>      repository: 'github://GsDevKit/Seaside31:gs_master/repository';
>      onLock: [:ex | ex honor];
>      load: 'CI' ].
> You are right the class WARetryHttpRequest is not present neither
> Seaside-GemStone320-Core package.
> The package is present locally at:
> /home/gemstone/GsDevKit_home/server/stones/devKit_351s/logs/github-cache/GsDevKit/Seaside31/gs_master/GsDevKit-Seaside31-b166df7/repository/Seaside-GemStone320-Core.package/
> Not sure what other information you will need...
> Tomorrow morning i will try everything from the scratch again (going home
> now :)
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass

More information about the Glass mailing list