GemStone support

[dassi]

Following up the discussion on #144, I would like to rewarm the topic of getting the latest Magritte running on GemStone.

I am currently trying to get it run on GemStone, since I am porting a big application from Pharo to GemStone. My very first observations are:

• A minor issue for now is the tonel format, which I successfully could convert to filetree with T2F2T. Until we get tonel support in GemStone, that's a pragmatic solution, which can be automated.
• Also minor: Reimplementing MACompositeConflict>>isKindOf: is not allowed in GemStone. Sure enough, there could be a clean solution.
• But: A very big issue is the usage of Pharo traits, since GemStone can't do that (and probably never will?). There are not many traits used, but still the question arises, if it is a suboptimal decision to use traits? AFAIK there is no flattenTraits method anymore, as there used to be in earlier Pharos.

Magritte is such a nice library. I need it on GemStone, and if a successful port is doable for me, I would very much like to dig into. How are chances to port it to a single code base (like Seaside), instead of having forks? What challenges could there be? @dalehenrich what were your experiences?

(P.S. I'm aware of https://github.com/GsDevKit/Magritte3, but maybe it is to outdated to continue from there?)

[Ducasse]

Hi andreas We hope to have the time to work on tonel to ease the migration to GS. But you know how life is, we are not paid for that and we have a lot of other things to do. S.

[Ducasse]

You see also if we cannot use any of the cool features of Pharo (traits, first class instance variables, ...) then may be we should stop Pharo. No? This is why I always wanted to see if we can run completely Pharo on top of a GS VM but no money for that.

Now may be you should also ask around what people are using as object databases. There is a channel on discord about it.

[seandenigris]

I am interested in supporting GS, especially since it’s a great deployment target for Pharo, and have been corresponding regularly with @dalehenrich to keep that alive.

I’m glad to hear you worked around the Tonel issue. I assumed that would be the major roadblock.

Regarding Traits, the problem is that there is duplication and complexity that can be resolved with traits. As I have become pretty much the only maintainer, I have to economize my time and effort. I resisted Traits for a long time, but recently gave in and I’m pleased with the benefit. I think it should be possible to figure out how to flatten users and have separate packages for GS

[dalehenrich]

@dassi, I'm glad that you found T2F2T and it works for you ... it was intended to address this particular issue and if any issues pop up in it's use, please let me know and I will make it a top priority to address ...

@Ducasse, regarding traits and Pharo on top of Gs vm, the book is not closed on either of these issues, however, there are things that must come first and until Rowan is released it isn't practical to work on Pharo on top of Gs vm, but once Rowan is "out the door", Pharo on top of Gs vm will bubble to the top of my list :)

@seandenigris and @dassi, I am not familiar with the traits flattening process, but perhaps the flattening could be done during the creation of the filetree packages (part of T2F2T) ... If flattening can be reversed, then the filetree to tonel conversion could also restore the traits? ... I am definitely willing to teach Rowan to read/write traits definitions so that T2F2T could do the flattening and/or simply read and write the traits packages ...

So let me know if you want to head in this direction (and give me a pointer to the flattening technology) and I'll put it on my near term todo list ...

[seandenigris]

give me a pointer to the flattening technology

I've been nosing around the Pharo channels for this information. So far...

@estebanlm offered:

the script itself would be easy, something like:

tMethods := AClass methods select: [ :each | each origin = MyTrait ].
AClass removeTraitThisIsPseudocode: MyTrait.
tMethods do: [ :each | 
AClass compile: each sourceCode categorised: each category ].
"and the same for the class side"

To which @tesonep replied:

A possible Script, the refactoring is more complicated so it will take more time

{AClass} do: [ :aClass |
traitComposition := aClass traitComposition.
traitComposition methods.
aClass traitComposition: {} asTraitComposition.
aClass methods 
select: [ :each | each isFromTrait ]
thenDo: [ :each | aClass compile: each sourceCode classified: each category]    ].

Then @gcotelli reminded us that instVars will have to be handled for stateful traits and added:

I'm supposing method aliases are handled by using the Trait composition

That's all I have at the moment, but it gives us somewhere to start...

[dalehenrich]

@seandenigris, interesting ... it seems to me that if I teach Rowan to handle trait definitions, I should be able to flatten the traits on export in T2F2T, but reversing the flattening doesn't seem feasible/practical (at first blush).

I did a quick scan of the Magritte packages (using github) and didn't find an obvious Magritte trait definition (and class that uses traits) ... pointing me at one would give me an idea about I would need to do with Rowan definitions to do the expansion working with an in memory set of Rowan class definitions to do the expansion on the fly ...

@dassi, in the short term, rather than wait for me to figure out how to do traits expansion in Rowan/T2F2T, it will be quicker to:

1. flatten in pharo
2. write the flattened package to tonel
3. run T2F2T to generate filetree packages
4. undo the changes to the tonel packages

I think that I can teach Rowan about traits enough to do the flattening as part of T2F2T and even teach T2F2T to ignored the flattened packages on the filetree to tonel translation (which could be the real value add), but unless @dassi makes a compelling argument for T2F2T to be traits aware on the filetree to tonel translation I won't tackle this problem in the near term.

[seandenigris]

Magritte trait definition (and class that uses traits) ... pointing me at one would give me an idea about...

There is MATPropertyOwner, which is used by MAObject. That should exercise the implementation fairly well because it is a stateful trait. I can't remember if there are any traits that use aliasing, but IIRC all the other traits at the moment are UI related, which may not be relevant to GS.

Please keep me posted and reach out freely if I can help

[stale[bot]]

To limit bug bankruptcy (see https://www.joelonsoftware.com/2012/07/09/software-inventory/) this issue has been automatically marked as stale because it has not had any activity in 6 months. If no further activity occurs, it might be closed. If this issue remains important to you, please comment to reactivate the issue. Thank you for your contributions.

[dalehenrich]

Let's keep this puppy alive ... is there a way to tell the stale bot to leave this one alone?

[stale[bot]]

To limit bug bankruptcy (see https://www.joelonsoftware.com/2012/07/09/software-inventory/) this issue has been automatically marked as stale because it has not had any activity in 6 months. If no further activity occurs, it might be closed. If this issue remains important to you, please comment to reactivate the issue. Thank you for your contributions.

[dalehenrich]

Let's keep this puppy alive ... is there a way to tell the stale bot to leave this one alone?

[seandenigris]

Let's keep this puppy alive ... is there a way to tell the stale bot to leave this one alone?

IIUC correctly [1], adding the pinned label should prevent the stale bot from closing this again...

1. https://github.com/marketplace/stale