Magma 1.4 on Pharo 1.4 and beyond

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Magma 1.4 on Pharo 1.4 and beyond

Chris Muller-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

Stuart Herring-2
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
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



_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

Chris Muller-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

mmimica
In reply to this post by Stuart Herring-2
On 6 January 2013 07:16, Stuart Herring <[hidden email]> wrote:
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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

Chris Muller-3
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

mmimica
On 6 January 2013 20:15, Chris Muller <[hidden email]> wrote:
> 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?


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
Reply | Threaded
Open this post in threaded view
|

Re: Magma 1.4 on Pharo 1.4 and beyond

Stuart Herring-2
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