Issue 1058 - Merge of BlockContext and BlockClosure
Locked
Issue 1058 - Merge of BlockContext and BlockClosure
 
|
http://code.google.com/p/pharo/issues/detail?id=1058
Can this two classes be merged (the share 80% or more than methods and several are identical, maybe were copied) and then (assuming that the BlockClosure will be the enduring): Smalltalk at: #BlockContext put: BlockClosure This way several packages that extend BlockContext will work in the new closure vm, for example Magma. What are the pros/cons of this change? If feasible, will be marked as Milestone-1.0? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique Cobá Martinez
escribió: > http://code.google.com/p/pharo/issues/detail?id=1058 > > Can this two classes be merged (the share 80% or more than methods and > several are identical, maybe were copied) and then (assuming that the > BlockClosure will be the enduring): > > Smalltalk at: #BlockContext put: BlockClosure > > This way several packages that extend BlockContext will work in the new > closure vm, for example Magma. > > What are the pros/cons of this change? > > If feasible, will be marked as Milestone-1.0? Ramiro Diaz Trepat and Mariano Martínez Peck commented on the magma mailing list that they successfully loaded magma on a pharo image by copying the extensions added by magma to BlockContext to the class BlockClosure. It appear that the code worked ok. Maybe with this change it wouldn't be necessary to modify magma (Chris Muller should speak about this). That can be the case for a lot of packages and will ease the integration and "certification" of several packages on pharo. See: http://lists.squeakfoundation.org/pipermail/magma/2009-July/001321.html _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
BlockContext is not used anymore but is kept in the image for backward
compatibility for a while (so that packages like Seaside still load as they define extension methods on BlockContext). If there are missing methods in BlockClosure let us know. Adrian On Aug 10, 2009, at 08:24 , Miguel Enrique Cobá Martinez wrote: > El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique Cobá Martinez > escribió: >> http://code.google.com/p/pharo/issues/detail?id=1058 >> >> Can this two classes be merged (the share 80% or more than methods >> and >> several are identical, maybe were copied) and then (assuming that the >> BlockClosure will be the enduring): >> >> Smalltalk at: #BlockContext put: BlockClosure >> >> This way several packages that extend BlockContext will work in the >> new >> closure vm, for example Magma. >> >> What are the pros/cons of this change? >> >> If feasible, will be marked as Milestone-1.0? > > Ramiro Diaz Trepat and Mariano Martínez Peck commented on the magma > mailing list that they successfully loaded magma on a pharo image by > copying the extensions added by magma to BlockContext to the class > BlockClosure. It appear that the code worked ok. Maybe with this > change > it wouldn't be necessary to modify magma (Chris Muller should speak > about this). That can be the case for a lot of packages and will ease > the integration and "certification" of several packages on pharo. > > See: > > http://lists.squeakfoundation.org/pipermail/magma/2009-July/ > 001321.html > > > _______________________________________________ > 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 |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
sorry, I somehow missed the second part of your mail before replying ;)
Not sure if this is a good idea as it looks a bit like a monkey patch... Would it actually work with MC? Because the class name from the class definition of MC would still return 'BlockClosure', I assume. Adrian On Aug 10, 2009, at 08:42 , Adrian Lienhard wrote: > BlockContext is not used anymore but is kept in the image for backward > compatibility for a while (so that packages like Seaside still load as > they define extension methods on BlockContext). > > If there are missing methods in BlockClosure let us know. > > Adrian > > On Aug 10, 2009, at 08:24 , Miguel Enrique Cobá Martinez wrote: > >> El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique Cobá Martinez >> escribió: >>> http://code.google.com/p/pharo/issues/detail?id=1058 >>> >>> Can this two classes be merged (the share 80% or more than methods >>> and >>> several are identical, maybe were copied) and then (assuming that >>> the >>> BlockClosure will be the enduring): >>> >>> Smalltalk at: #BlockContext put: BlockClosure >>> >>> This way several packages that extend BlockContext will work in the >>> new >>> closure vm, for example Magma. >>> >>> What are the pros/cons of this change? >>> >>> If feasible, will be marked as Milestone-1.0? >> >> Ramiro Diaz Trepat and Mariano Martínez Peck commented on the magma >> mailing list that they successfully loaded magma on a pharo image by >> copying the extensions added by magma to BlockContext to the class >> BlockClosure. It appear that the code worked ok. Maybe with this >> change >> it wouldn't be necessary to modify magma (Chris Muller should speak >> about this). That can be the case for a lot of packages and will ease >> the integration and "certification" of several packages on pharo. >> >> See: >> >> http://lists.squeakfoundation.org/pipermail/magma/2009-July/ >> 001321.html >> >> >> _______________________________________________ >> 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 |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
In reply to this post by Miguel Cobá
2009/8/10 Miguel Enrique Cobá Martinez <[hidden email]>:
> Ramiro Diaz Trepat and Mariano Martínez Peck commented on the magma > mailing list that they successfully loaded magma on a pharo image by > copying the extensions added by magma to BlockContext to the class > BlockClosure. It appear that the code worked ok. Maybe with this change > it wouldn't be necessary to modify magma (Chris Muller should speak > about this). That can be the case for a lot of packages and will ease > the integration and "certification" of several packages on pharo. > Doing that allows Magma to _load_ but it fails all block related tests, so there's a bit more to it than that - serialization/deserialization is the issue. Also, there's a number of other issues when porting to Pharo. They're mostly all in the testing code, but being able to run the tests is pretty essential for a successful port. Regards, Stuart _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
In reply to this post by Miguel Cobá
2009/8/10 Miguel Enrique Cobá Martinez <[hidden email]> El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique Cobá Martinez Miguel: Actually I was talking about Glorp, not Magma ;) However, think I am not agree. In my case, Glorp has methods extensions (like *Glorp) in the BlockContext. But those methods were Glorp specific. So, the merge between BlockContext and BlockClosure has no sense. If there are messages in BlockContext that you need to be in BlockClosure but are closure related, then perhaps we can put them, as there were already some (I remember for example, argumentCount). This is a joke: Perhaps we can override the doesNotUndersand: in BlockClosure so that it delegates to BlockContext hahahahahah
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
In reply to this post by Miguel Cobá
On 10.08.2009, at 02:19, Miguel Enrique Cobá Martinez wrote: > http://code.google.com/p/pharo/issues/detail?id=1058 > > Can this two classes be merged (the share 80% or more than methods and > several are identical, maybe were copied) and then (assuming that the > BlockClosure will be the enduring): > > Smalltalk at: #BlockContext put: BlockClosure > > This way several packages that extend BlockContext will work in the > new > closure vm, for example Magma. > I don't think this is a good idea. BlockClosures are *not* contexts. So methods that are about the context part of BlockContext will fail. I think we should just keep BlockContext for backward-compatibility in 1.0. This way, people can load code and than check if the methods needs to go to MethodContext or BlockClosures. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
On Mon, Aug 10, 2009 at 8:40 AM, Marcus Denker<[hidden email]> wrote:
> > On 10.08.2009, at 02:19, Miguel Enrique Cobá Martinez wrote: > >> http://code.google.com/p/pharo/issues/detail?id=1058 >> >> Can this two classes be merged (the share 80% or more than methods and >> several are identical, maybe were copied) and then (assuming that the >> BlockClosure will be the enduring): >> >> Smalltalk at: #BlockContext put: BlockClosure >> >> This way several packages that extend BlockContext will work in the >> new >> closure vm, for example Magma. >> > > I don't think this is a good idea. BlockClosures are *not* contexts. > So methods > that are about the context part of BlockContext will fail. > > I think we should just keep BlockContext for backward-compatibility in > 1.0. This > way, people can load code and than check if the methods needs to go to > MethodContext > or BlockClosures. > > Marcus > > Ok, I assumed that like both classes share a lot of methods, they were mostly interchangeable. So by the responses, I think that this implies that changes will be neccesary to port packages that extend BlockContext to work in Pharo, while, at the same time, they must conserve the extensions to BlockContext. I imagine that given the closure integration in Squeak, this will force all the packages to use BlockClosure (or equivalent class) to update their packages. Miguel Cobá > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > 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 |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
What would be nice is to get a list of the methods that are missing in
BlockClosure. After the changes will not be only needed for pharo but also for Squeak since Squeak has blockclosure now Stef > > http://code.google.com/p/pharo/issues/detail?id=1058 >>> >>> Can this two classes be merged (the share 80% or more than methods >>> and >>> several are identical, maybe were copied) and then (assuming that >>> the >>> BlockClosure will be the enduring): >>> >>> Smalltalk at: #BlockContext put: BlockClosure >>> >>> This way several packages that extend BlockContext will work in the >>> new >>> closure vm, for example Magma. >>> >> >> I don't think this is a good idea. BlockClosures are *not* contexts. >> So methods >> that are about the context part of BlockContext will fail. >> >> I think we should just keep BlockContext for backward-compatibility >> in >> 1.0. This >> way, people can load code and than check if the methods needs to go >> to >> MethodContext >> or BlockClosures. >> >> Marcus >> >> > > Ok, I assumed that like both classes share a lot of methods, they were > mostly interchangeable. > So by the responses, I think that this implies that changes will be > neccesary to port packages that > extend BlockContext to work in Pharo, while, at the same time, they > must conserve the extensions to > BlockContext. > > I imagine that given the closure integration in Squeak, this will > force all the packages to use BlockClosure (or > equivalent class) to update their packages. > > Miguel Cobá > >> >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> 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 |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
This was already discussed some time ago in the thread
"BlockContextTest". Gabriel posted a list of methods and we discussed which ones should be copied to BlockClosure. Adrian On Aug 11, 2009, at 09:06 , Stéphane Ducasse wrote: > What would be nice is to get a list of the methods that are missing in > BlockClosure. > After the changes will not be only needed for pharo but also for > Squeak since Squeak has blockclosure now > > Stef > >> >> http://code.google.com/p/pharo/issues/detail?id=1058 >>>> >>>> Can this two classes be merged (the share 80% or more than methods >>>> and >>>> several are identical, maybe were copied) and then (assuming that >>>> the >>>> BlockClosure will be the enduring): >>>> >>>> Smalltalk at: #BlockContext put: BlockClosure >>>> >>>> This way several packages that extend BlockContext will work in the >>>> new >>>> closure vm, for example Magma. >>>> >>> >>> I don't think this is a good idea. BlockClosures are *not* contexts. >>> So methods >>> that are about the context part of BlockContext will fail. >>> >>> I think we should just keep BlockContext for backward-compatibility >>> in >>> 1.0. This >>> way, people can load code and than check if the methods needs to go >>> to >>> MethodContext >>> or BlockClosures. >>> >>> Marcus >>> >>> >> >> Ok, I assumed that like both classes share a lot of methods, they >> were >> mostly interchangeable. >> So by the responses, I think that this implies that changes will be >> neccesary to port packages that >> extend BlockContext to work in Pharo, while, at the same time, they >> must conserve the extensions to >> BlockContext. >> >> I imagine that given the closure integration in Squeak, this will >> force all the packages to use BlockClosure (or >> equivalent class) to update their packages. >> >> Miguel Cobá >> >>> >>> >>> -- >>> Marcus Denker - http://marcusdenker.de >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
OK so I did not get the ones that are missing for Glorp?
Stef On Aug 11, 2009, at 9:18 AM, Adrian Lienhard wrote: > This was already discussed some time ago in the thread > "BlockContextTest". Gabriel posted a list of methods and we discussed > which ones should be copied to BlockClosure. > > Adrian > > On Aug 11, 2009, at 09:06 , Stéphane Ducasse wrote: > >> What would be nice is to get a list of the methods that are missing >> in >> BlockClosure. >> After the changes will not be only needed for pharo but also for >> Squeak since Squeak has blockclosure now >> >> Stef >> >>> >>> http://code.google.com/p/pharo/issues/detail?id=1058 >>>>> >>>>> Can this two classes be merged (the share 80% or more than methods >>>>> and >>>>> several are identical, maybe were copied) and then (assuming that >>>>> the >>>>> BlockClosure will be the enduring): >>>>> >>>>> Smalltalk at: #BlockContext put: BlockClosure >>>>> >>>>> This way several packages that extend BlockContext will work in >>>>> the >>>>> new >>>>> closure vm, for example Magma. >>>>> >>>> >>>> I don't think this is a good idea. BlockClosures are *not* >>>> contexts. >>>> So methods >>>> that are about the context part of BlockContext will fail. >>>> >>>> I think we should just keep BlockContext for backward-compatibility >>>> in >>>> 1.0. This >>>> way, people can load code and than check if the methods needs to go >>>> to >>>> MethodContext >>>> or BlockClosures. >>>> >>>> Marcus >>>> >>>> >>> >>> Ok, I assumed that like both classes share a lot of methods, they >>> were >>> mostly interchangeable. >>> So by the responses, I think that this implies that changes will be >>> neccesary to port packages that >>> extend BlockContext to work in Pharo, while, at the same time, they >>> must conserve the extensions to >>> BlockContext. >>> >>> I imagine that given the closure integration in Squeak, this will >>> force all the packages to use BlockClosure (or >>> equivalent class) to update their packages. >>> >>> Miguel Cobá >>> >>>> >>>> >>>> -- >>>> Marcus Denker - http://marcusdenker.de >>>> PLEIAD Lab - Computer Science Department (DCC) - University of >>>> Chile >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
On Tue, Aug 11, 2009 at 6:28 AM, Stéphane Ducasse <[hidden email]> wrote: OK so I did not get the ones that are missing for Glorp? Sorry Stef I don't understood your question. Glorp uses some methods that wasn't in BlockCloure. At least, I remember one: argumentCount which was only a simple accesor. So, we put it in BlockClosure. Then, Glorp has extensions in BlockContext with category *Glorp that I had to copy them to BlockClosure, but those methods are Glorp specific and they are loaded only when you load the Glorp package. Best, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1058 - Merge of BlockContext and BlockClosure
|
|
ok I was confused then by the mail of miguel
Stef On Aug 11, 2009, at 3:26 PM, Mariano Martinez Peck wrote: > > > On Tue, Aug 11, 2009 at 6:28 AM, Stéphane Ducasse <[hidden email] > > wrote: > OK so I did not get the ones that are missing for Glorp? > > Sorry Stef I don't understood your question. Glorp uses some methods > that wasn't in BlockCloure. At least, I remember one: argumentCount > which was only a simple accesor. So, we put it in BlockClosure. > Then, Glorp has extensions in BlockContext with category *Glorp that > I had to copy them to BlockClosure, but those methods are Glorp > specific and they are loaded only when you load the Glorp package. > > Best, > > Mariano > > > > Stef > > On Aug 11, 2009, at 9:18 AM, Adrian Lienhard wrote: > > > This was already discussed some time ago in the thread > > "BlockContextTest". Gabriel posted a list of methods and we > discussed > > which ones should be copied to BlockClosure. > > > > Adrian > > > > On Aug 11, 2009, at 09:06 , Stéphane Ducasse wrote: > > > >> What would be nice is to get a list of the methods that are missing > >> in > >> BlockClosure. > >> After the changes will not be only needed for pharo but also for > >> Squeak since Squeak has blockclosure now > >> > >> Stef > >> > >>> > >>> http://code.google.com/p/pharo/issues/detail?id=1058 > >>>>> > >>>>> Can this two classes be merged (the share 80% or more than > methods > >>>>> and > >>>>> several are identical, maybe were copied) and then (assuming > that > >>>>> the > >>>>> BlockClosure will be the enduring): > >>>>> > >>>>> Smalltalk at: #BlockContext put: BlockClosure > >>>>> > >>>>> This way several packages that extend BlockContext will work in > >>>>> the > >>>>> new > >>>>> closure vm, for example Magma. > >>>>> > >>>> > >>>> I don't think this is a good idea. BlockClosures are *not* > >>>> contexts. > >>>> So methods > >>>> that are about the context part of BlockContext will fail. > >>>> > >>>> I think we should just keep BlockContext for backward- > compatibility > >>>> in > >>>> 1.0. This > >>>> way, people can load code and than check if the methods needs > to go > >>>> to > >>>> MethodContext > >>>> or BlockClosures. > >>>> > >>>> Marcus > >>>> > >>>> > >>> > >>> Ok, I assumed that like both classes share a lot of methods, they > >>> were > >>> mostly interchangeable. > >>> So by the responses, I think that this implies that changes will > be > >>> neccesary to port packages that > >>> extend BlockContext to work in Pharo, while, at the same time, > they > >>> must conserve the extensions to > >>> BlockContext. > >>> > >>> I imagine that given the closure integration in Squeak, this will > >>> force all the packages to use BlockClosure (or > >>> equivalent class) to update their packages. > >>> > >>> Miguel Cobá > >>> > >>>> > >>>> > >>>> -- > >>>> Marcus Denker - http://marcusdenker.de > >>>> PLEIAD Lab - Computer Science Department (DCC) - University of > >>>> Chile > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > > > _______________________________________________ > > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |