Magma 1.4 on Pharo 1.4 and beyond
Locked
Magma 1.4 on Pharo 1.4 and beyond
 
|
Hi Pharoers, below is a script which will load Magma 1.4 into Pharo
1.4. Proceed past the Warnings. After loading, you can run the tests by opening a Transcript and then executing: MagmaTestCase fullSuite maDebug Right now the tests immediately hit a snag due to an API factoring in Pharo 1.4 which moved some "vm" accessors out of "Smalltalk" and into "Smalltalk vm" but removing the "vm" prefix.. (sigh). There are also a couple of extension methods needed in Pharo so that MethodContexts can be serialized.. So, given that folks are already moving to 2.0 and there's already talk about Pharo 3.0 alpha, I think we've reached the point where the entire codebase should simply be forked for Pharo so that the code doesn't get too squirrely and with a proliferation of "-Squeak" and "-Pharo" packages. I'm looking for someone with experience with cross-dialect issues interested in getting Magma ported to Pharo. I would help from the Magma side, of course. - Chris | gofer | (Smalltalk hasClassNamed: #MaObject) ifFalse: [ "MaBase layer with tests" gofer := Gofer new squeaksource3: 'MaBase'. #('Collections-BTree-lr.73' 'BrpExtensions-cmm.11' 'Ma-Core-cmm.232' 'Ma-Collections-cmm.141' 'Ma-Ascii-Report-cmm.9' 'Ma-Statistics-cmm.28' 'Ma-Search-cmm.42' 'Ma-Serializer-Core-cmm.290' 'Ma-Serializer-Pharo-Core-cmm.1' 'Ma-Serializer-Tests-cmm.40') do: [ : each | gofer version: each ]. gofer load ]. "Load the Ma client server package" (Smalltalk hasClassNamed: #MaClientSocket) ifFalse: [ Gofer new squeaksource3: 'Ma-Client-Server' ; version: 'Ma-Client-Server-Core-cmm.225' ; version: 'Ma-Client-Server-Tester-cmm.157' ; load. "Include OSProcess to support tester launching of images." Gofer new squeaksource: 'OSProcess' ; version: 'OSProcess-dtl.66' ; load ]. "Magma client" (Smalltalk hasClassNamed: #MagmaSession) ifFalse: [ Gofer new squeaksource3: 'Magma' ; version: 'WriteBarrier-cmm.44' ; version: 'SOLHashTables-cmm.16' ; version: 'Magma-Client-cmm.642' ; load ]. "Magma server" (Smalltalk hasClassNamed: #MagmaServerConsole) ifFalse: [ Gofer new squeaksource3: 'Magma' ; version: 'Magma-Server-cmm.455' ; version: 'Magma-Tools-cmm.68' ; load ]. "Magma tester" (Smalltalk hasClassNamed: #MagmaTestCase) ifFalse: [Gofer new squeaksource3: 'Magma' ; version: 'Magma-Tester-cmm.406' ; version: 'Magma-Pharo-Tester-cmm.1' ; load] _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
Re: Magma 1.4 on Pharo 1.4 and beyond
|
|
Hi Cris,
I might be able to take it on. I don't have a huge amount of time, but I use Magma for most of my projects, so I'm likely to end up doing it for my own sake anyway (either that, or stop using it, and I don't want to do that, because it's spoilt me for most other methods of persistence) - I might as well share the result.
A fork probably would make the most sense - though given how well you've split it up, I'm imagining that the bulk of the packages would be able to stay untouched - it'd mostly be the serialization packages which add extension methods to classes that no longer exist, and the few that touch some of the more drastic changes like FileSystem that would require forking.
I've actually already been maintaining my own private Metacello configuration for Magma 1.3 that loads it on Pharo 1.3, 1.4 and 2.0 anyway.
BTW - it looks like you haven't copied Magma-Pharo-Tester from Squeaksource over to the Squeaksource 3 repository. Regards, Stuart
On 3 January 2013 06:31, Chris Muller <[hidden email]> wrote: Hi Pharoers, below is a script which will load Magma 1.4 into Pharo _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
Re: Magma 1.4 on Pharo 1.4 and beyond
|
|
Hey, that's great thanks a lot Stuart!
> A fork probably would make the most sense - though given how well you've > split it up, I'm imagining that the bulk of the packages would be able to > stay untouched - it'd mostly be the serialization packages which add > extension methods to classes that no longer exist, and the few that touch > some of the more drastic changes like FileSystem that would require forking. Yes, FileDirectory --> FileSystem as well as SystemChangeNotifier --> Announcements(?) are two areas that will need addressed for Pharo 2.0. > I've actually already been maintaining my own private Metacello > configuration for Magma 1.3 that loads it on Pharo 1.3, 1.4 and 2.0 anyway. Great, and once you get a Pharo config going I'll join the Metacello party for a -Squeak config; I guess Metacello is the best way to handle multiplatform projects. > BTW - it looks like you haven't copied Magma-Pharo-Tester from Squeaksource > over to the Squeaksource 3 repository. Ok, I copied it over. I've already started the Squeak fork by beginning to clean a couple of the methods that had case-logic depending on whether Squeak or Pharo. I'm not very experienced with multi-platform development what do you think is the best way to approach? I'm thinking we just maintain our own forks and consume fixes/enhancements from each other by merging them into our own fork by hand. I also added you as a developer to each of: http://ss3.gemstone.com/ss/MaBase http://ss3.gemstone.com/ss/Ma-Client-Server http://ss3.gemstone.com/ss/Magma Hmm, I'm trying to think whether Pharo-forked versions of the same packages should be colocated in the same repository or in a separate one? Let's coordinate our strategies before adding new packages. Thanks again. - Chris _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
|
|
In reply to this post by Stuart Herring-2
On 6 January 2013 07:16, Stuart Herring <[hidden email]> wrote:
Hi Cris, I'm also interesed in having it running on Pharo (currently on 1.4) but I just don't feel up to the task doing it by myself. I certally will do testing send complaints.
Hint: in Pharo 1.4 sending #class is not magic any more and it can be overriden, so proxies and write-barriers can be even more transparent. Milan Mimica http://sparklet.sf.net _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
Re: Magma 1.4 on Pharo 1.4 and beyond
|
|
> Hint: in Pharo 1.4 sending #class is not magic any more and it can be
> overriden, so proxies and write-barriers can be even more transparent. That's great I'd love to get rid of #maOriginalClass. Do you know how the "magic" was removed? _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
|
|
On 6 January 2013 20:15, Chris Muller <[hidden email]> wrote:
Object>>class "Primitive. Answer the object which is the receiver's class. Essential. See
Object documentation whatIsAPrimitive." <primitive: 111> self primitiveFailed
So the magic is still there, it's just that #class is not inlined by the VM any more and can be overriden. Which is great. Milan Mimica http://sparklet.sf.net _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
Re: Magma 1.4 on Pharo 1.4 and beyond
|
|
In reply to this post by Chris Muller-4
On 7 January 2013 05:07, Chris Muller <[hidden email]> wrote:
> > Ok, I copied it over. I've already started the Squeak fork by > beginning to clean a couple of the methods that had case-logic > depending on whether Squeak or Pharo. I'm not very experienced with > multi-platform development what do you think is the best way to > approach? I'm thinking we just maintain our own forks and consume > fixes/enhancements from each other by merging them into our own fork > by hand. > > I also added you as a developer to each of: > > http://ss3.gemstone.com/ss/MaBase > http://ss3.gemstone.com/ss/Ma-Client-Server > http://ss3.gemstone.com/ss/Magma Thanks! > > Hmm, I'm trying to think whether Pharo-forked versions of the same > packages should be colocated in the same repository or in a separate > one? Let's coordinate our strategies before adding new packages. > My feeling is separate repositories - at least until we get a full picture of how it's going to pan out. That should help keep confusion down. I'll probably have to experiment a bit to see what works - particularly with finding the easiest way to handle merging upstream changes from you. Regards, Stuart _______________________________________________ Magma mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/magma |
«
Return to Magma
|
1 view|%1 views
| Free forum by Nabble | Edit this page |