I've created an issue to track the project and started the port of
magritte-metamodel/magritte on my fork of the project. If you follow
along in Issue #105, I'll record progress in commits and comments on
the issue ...
> On 5/1/19 8:58 AM, dtrussardi(a)tiscali.it wrote:
>> Ciao Dale, thanks.
>> I have no great experience in managing this type of updates.
>> I had some considerations.
>>> I've looked at this a bit closer and I notice that you are
>>> referencing the magritte-metamodel/magritte and that project has
>>> not been ported to GLASS yet ... A quick way to tell if a
>>> particular project has been ported to GLASS is to look at the
>>> .travis.yml file and check to see if there are any GemStone
>>> versions being tested.
>>> The GsDevKit/Magrite3 was ported to GLASS and the test ran
>>> cleanly as of 3 years ago. The project hasn't been updated to
>>> SmalltalkCI and the last version tested was GemStone 3.3.1. I
>>> just triggered a new build to see where the project stands today
>>> - the travis run passed for GemStone 3.2.15 and 3.3.1 ...
>>> Moving forward, I would think the best bet would be to port the
>>> magritte-metamodel/magritte project to GLASS and GemStone 3.2.17,
>>> 3.3.9, and 3.3.9 ... I assume that Magritte has changed from the
>>> point where I forked Magritte 3.3.0 back in December of 2015 ...
>>> From the release history of GsDevKit/Magritte3, it looks like I
>>> ported 3.2.0, 3.3.0, 3.3.1, 3.3.2, and 3.4.2. the master branch is
>>> 3.4.2. I also got a start on 3.5.0, but didn't finish the port to
>>> the point where I merged to master ...
>>> I would think that updating GsDevKit/Magritte3 3.4.2 to support
>>> smalltalkCI and GemStone 3.4.3, would be pretty straightforward ...
>> I have no idea about it...... how should I proceed?
>>> The release history of magritte-metamodel/magritte indicates
>>> that 3.5.4 was released in January of this year ... I've launched
>>> another GsDevKit/Magritte3 travis run for branch version_350 to
>>> see what the state of the GLASS Magritte3.5.0 port is ...
>>> It lools like the Magritte 3.5.0 test passes so it is likely
>>> that we'll be able to merge the GsDevKit/Magritte3 work into the
>>> magritte-metamodel/magritte project ...
>>> I don't have full time to commit to doing this work, but barring
>>> any major surprises between Magritte 3.5.0 and Magritte 3.5.4 and
>>> later, it should only take a week or so of elapsed time for me to
>>> do the port ... if there are significant changes then all bets are
>>> off ...
>> But what do you mean? That you can port ( the GsDevKit/Magritte3
>> work into the magritte-metamodel/magritte project ) within a week?
> I don't have a lot of time to mess around with porting projects that
> no one will use, so there are two different routes that I can take:
What I have developed is based on Seaside and Magritte and for now I
am not able to review and change the reference base.
I would like and would be useful to continue in this direction.
> 1. Port GsDevKit/Magritte which is known to run on GemStone 3.3.x
> and will likely run on GemStone 3.4.3 without a lot of changes.
> Downside is that it is 4 years old and may not meet your
> requirements. Going this route is likely to take around a week
> elapsed time (not full time).
in this case, I don't know if feasible but: Set the development
environment based on Pharo 7.0.3 (it seems stable) and install
Magritte from ConfigurationOfMagritte3to the version compatible with
GsDevKit / Magritte.
If you tell me the relative ConfigurationOfMagritte3 versionof
GsDevKit / Magritte I can try to set the Pharo 7.0.3 environment in
> 2. Port magritte-metamodel/magritte to GemStone ... there are
> GemStone packages present, in the repository, but GemStone is not in
> the travis lineup, so the GemStone code has not been tested for a
> long time (maybe more than 4 years). Going this route will likely
> take a week (elapsed --- not full time) just to figure out how big of
> a job the port will be ...
> You are currently trying to use magritte-metamodel/magritte with
> Pharo 7.0.3, so it seems that the right answer is to spend time
> porting , magritte-metamodel/magritte to GemStone ... then you'll be
> using the same code base on Pharo and GemStone ... if there aren't
> significant changes to Magritte in the last 4 years then a couple of
> weeks would be a good guess ... and I can handle that ...
This seems to me the best solution.
That can be useful also for the porting of Pier (which if I remember
correctly is based on Magritte) ????
In this case I wonder if I can be useful?
> If this makes sense to you, then I will start work on the port
> tomorrow after I see your email:)
Magritte, Pier and Related Tools ...