NewCompiler load on PharoCore

>
> 2010/1/12 Miguel Enrique Cobá Martinez <[hidden email]>
>         El mar, 12-01-2010 a las 19:36 +0100, Lukas Renggli escribió:
>         > > Has NewCompiler teste on PharoCore?
>         >
>         > Jorge is working on it. It does not work on Pharo yet.
>        
>        
>         Ok, thanks, for the moment will omit the WriteBarrier on
>         NewCompiler in
>         the Metacello configuration for Magma.
>        
>         Thanks
>        
>        
>         >
>         > Lukas
>         >
>        
>         --
>         Miguel Cobá
>         http://miguel.leugim.com.mx
>        
>        
>         _______________________________________________
>        
>        
>         Pharo-project mailing list
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
>>
>> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> > Magma depends on NewCompiler ???
>>
>> No, WriteBarrier depends on NewCompiler.
>>
>> Magma can, at the explicit option of the user, turn on the
>> WriteBarrier option if the WriteBarrier package is present.
>> WriteBarrier used to be self-contained, later it became dependent on
>> NewCompiler.
>>
>> Unless the WriteBarrier option is switched on by the user, its
>> presence or absence in the image (as well as NewCompiler) has no
>> effect on Magma.
>>
>
> Thanks for the clarification Chris. It was strange for me that  as I used
> Magma a couple of times and I never installed WriteBarrier neither
> NewCompiler.
>
> Cheers
>
> Mariano
>
>
>>
>>  - Chris
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
> >
> >
> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
> >>
> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
> >> > Magma depends on NewCompiler ???
> >>
> >> No, WriteBarrier depends on NewCompiler.
> >>
> >> Magma can, at the explicit option of the user, turn on the
> >> WriteBarrier option if the WriteBarrier package is present.
> >> WriteBarrier used to be self-contained, later it became dependent on
> >> NewCompiler.
> >>
> >> Unless the WriteBarrier option is switched on by the user, its
> >> presence or absence in the image (as well as NewCompiler) has no
> >> effect on Magma.
> >>
> >
> > Thanks for the clarification Chris. It was strange for me that  as I used
> > Magma a couple of times and I never installed WriteBarrier neither
> > NewCompiler.
> >
> > Cheers
> >
> > Mariano
> >
> >
> >>
> >>  - Chris
> >>
> >> _______________________________________________
> >> Pharo-project mailing list
> >> [hidden email]
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2010/1/13 Lukas Renggli <[hidden email]>:
>>> Can someone clarify, why WriteBarrier depends on compiler (new
>>> compiler or old compiler - not really important).
>>> I just wonder what compiler functionality its depends on.
>>
>> WriteBarrier introduces something like immutable objects at the
>> language level by rewriting all state access in an anonymous subclass.
>> Having a compiler at hand certainly makes things simpler.
>>
> Hmm.. what about primitives , which mutating the state of receiver?
> Even worse, there are some, which mutating the state of argument(s).

>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
>> Can someone clarify, why WriteBarrier depends on compiler (new
>> compiler or old compiler - not really important).
>> I just wonder what compiler functionality its depends on.
>
> WriteBarrier uses the class BytecodeGenerator that is part of the
> package NewCompiler (that is currently on rewrite for the closure
> images). Why it need it and how it use it, I really don't know. I have
> only a vague idea of what WriteBarrier does, and as Mariano said, I use
> Magma but never used or activated the WriteBarrier functionality of it.
>
> Cheers
>>
>> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
>> >
>> >
>> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
>> >>
>> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> >> > Magma depends on NewCompiler ???
>> >>
>> >> No, WriteBarrier depends on NewCompiler.
>> >>
>> >> Magma can, at the explicit option of the user, turn on the
>> >> WriteBarrier option if the WriteBarrier package is present.
>> >> WriteBarrier used to be self-contained, later it became dependent on
>> >> NewCompiler.
>> >>
>> >> Unless the WriteBarrier option is switched on by the user, its
>> >> presence or absence in the image (as well as NewCompiler) has no
>> >> effect on Magma.
>> >>
>> >
>> > Thanks for the clarification Chris. It was strange for me that  as I used
>> > Magma a couple of times and I never installed WriteBarrier neither
>> > NewCompiler.
>> >
>> > Cheers
>> >
>> > Mariano
>> >
>> >
>> >>
>> >>  - Chris
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> A *much* better way to implement this is to support immutability in the VM
> (I know, I know, but all the code is available in the Newspeak VM), mark
> objects one wants to mark as dirty as immutable, catch the
> NoModificationError exception, and proceed after having made the object
> mutable and marked it dirty.  No creating hidden classes, no trying to get
> change class to work for compact classes, etc.  Just a simple VM-implemented
> write barrier that can also be used for a host of other things
> (object-database mapping, debugging, immutable literals etc).
>
> On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <[hidden email]> wrote:
>>
>> A great description of what WriteBarrier does and how it works can be
>> found in the WriteBarrier class-comment, itself.
>>
>> In a nutshell, when an object is added to a WriteBarrier, a subclass
>> is dynamically compiled for it, but not added to the Smalltalk
>> dictionary.  The name of the class is the same as its superclass but
>> with a '*' appended to it.
>>
>> After creating the subclass, WriteBarrier looks at all "definitions"
>> of each instance variable, and adds methods to override the methods in
>> its superclass.  The generated override checks the pre-state of the
>> instVar, calls super, then compares the post-state of the instVar to
>> the pre-state.
>>
>> If it changed, it signals so that the application (Magma) can mark it
>> dirty.
>>
>> So, it allows Magma to operate with a smaller readSet, which speeds up
>> the part of the commit process relating to detection of changed
>> objects for building the CommitPackage which is shipped off to the
>> server..
>>
>>  - Chris
>>
>> 2010/1/13 Miguel Enrique Cobá Martinez <[hidden email]>:
>> > El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
>> >> Can someone clarify, why WriteBarrier depends on compiler (new
>> >> compiler or old compiler - not really important).
>> >> I just wonder what compiler functionality its depends on.
>> >
>> > WriteBarrier uses the class BytecodeGenerator that is part of the
>> > package NewCompiler (that is currently on rewrite for the closure
>> > images). Why it need it and how it use it, I really don't know. I have
>> > only a vague idea of what WriteBarrier does, and as Mariano said, I use
>> > Magma but never used or activated the WriteBarrier functionality of it.
>> >
>> > Cheers
>> >>
>> >> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
>> >> >
>> >> >
>> >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> >> >> > Magma depends on NewCompiler ???
>> >> >>
>> >> >> No, WriteBarrier depends on NewCompiler.
>> >> >>
>> >> >> Magma can, at the explicit option of the user, turn on the
>> >> >> WriteBarrier option if the WriteBarrier package is present.
>> >> >> WriteBarrier used to be self-contained, later it became dependent on
>> >> >> NewCompiler.
>> >> >>
>> >> >> Unless the WriteBarrier option is switched on by the user, its
>> >> >> presence or absence in the image (as well as NewCompiler) has no
>> >> >> effect on Magma.
>> >> >>
>> >> >
>> >> > Thanks for the clarification Chris. It was strange for me that  as I
>> >> > used
>> >> > Magma a couple of times and I never installed WriteBarrier neither
>> >> > NewCompiler.
>> >> >
>> >> > Cheers
>> >> >
>> >> > Mariano
>> >> >
>> >> >
>> >> >>
>> >> >>  - Chris
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-project mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-project mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> > --
>> > Miguel Cobá
>> > http://miguel.leugim.com.mx
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Eliot Miranda wrote:
>> A *much* better way to implement this is to support immutability in the
>> VM (I know, I know, but all the code is available in the Newspeak VM),
>> mark objects one wants to mark as dirty as immutable, catch the
>> NoModificationError exception, and proceed after having made the object
>> mutable and marked it dirty.  No creating hidden classes, no trying to
>> get change class to work for compact classes, etc.  Just a simple
>> VM-implemented write barrier that can also be used for a host of other
>> things (object-database mapping, debugging, immutable literals etc).
>
> Since object dirtying is at the core of the product I work with, and
> I've worked extensively with both methods of implementing write barriers...
>
> I very strongly agree with Eliot. *So* much nicer a way to do this.
>

> Regards,
>
> -Martin
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>