[Pharo-project] 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?
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/10 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>:
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
2009/8/10 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
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.
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
See:
http://lists.squeakfoundation.org/pipermail/magma/2009-July/001321.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Mon, Aug 10, 2009 at 8:40 AM, Marcus Denker<denker@acm.org> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Aug 11, 2009 at 6:28 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Adrian Lienhard -
Marcus Denker -
Mariano Martinez Peck -
Miguel Cobá -
Miguel Enrique Cobá Martinez
-
Stuart Herring -
Stéphane Ducasse