[Pharo-project] Best practices for overrides/extension methods with Monticello and correct packaging?
Hi: I was wondering what the standard approach is to package rather invasive changes to core classes. Currently, I have everything in extension methods that override the existing methods in my own package. However, the monticello package is not actually loadable. So, I cannot just load my stuff into a new image via monticello. For instance, I modify #basicNew/#basicNew:, the Parser, the Encoder classes, etc. With my changes, these things depend on my own classes being properly initialized in the image. What is the best way to get that into a loadable/bootstrapable state? Do I need to split up all the stuff into different packages according to dependencies and then make sure that I can load those different packages in a well defined order? Or is there anything to tell Monticello to be smarter about loading the stuff? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
if you look in the scripttloatder you can tell the MC that it should apply a list of package one after the other and not (by default collect all the classes and apply all the change together). Now another smart move is to think (if the license allows it) how you can push the hooks that you need to the community like that you are more customization and less override. Now part two, I hope that we will get a bootstrap working one of these days but for that we need to get time. Stef On Nov 7, 2011, at 11:29 PM, Stefan Marr wrote:
Hi:
I was wondering what the standard approach is to package rather invasive changes to core classes.
Currently, I have everything in extension methods that override the existing methods in my own package. However, the monticello package is not actually loadable. So, I cannot just load my stuff into a new image via monticello. For instance, I modify #basicNew/#basicNew:, the Parser, the Encoder classes, etc.
With my changes, these things depend on my own classes being properly initialized in the image.
What is the best way to get that into a loadable/bootstrapable state?
Do I need to split up all the stuff into different packages according to dependencies and then make sure that I can load those different packages in a well defined order?
Or is there anything to tell Monticello to be smarter about loading the stuff?
Thanks Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
For an example, have a look at the package Helvetia-Loader in http://source.lukas-renggli.ch/helvetia. It verifies the expected sytem, patches Monticello, bootstraps the quasiquoting, replaces the compiler and parser infrastructure in multiple steps, ... Lukas On Monday, 7 November 2011, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
if you look in the scripttloatder you can tell the MC that it should apply a list of package one after the other and not (by default collect all the classes and apply all the change together).
Now another smart move is to think (if the license allows it) how you can push the hooks that you need to the community like that you are more customization and less override. Now part two, I hope that we will get a bootstrap working one of these days but for that we need to get time.
Stef
On Nov 7, 2011, at 11:29 PM, Stefan Marr wrote:
Hi:
I was wondering what the standard approach is to package rather invasive changes to core classes.
Currently, I have everything in extension methods that override the existing methods in my own package. However, the monticello package is not actually loadable. So, I cannot just load my stuff into a new image via monticello. For instance, I modify #basicNew/#basicNew:, the Parser, the Encoder classes, etc.
With my changes, these things depend on my own classes being properly initialized in the image.
What is the best way to get that into a loadable/bootstrapable state?
Do I need to split up all the stuff into different packages according to dependencies and then make sure that I can load those different packages in a well defined order?
Or is there anything to tell Monticello to be smarter about loading the stuff?
Thanks Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
-- Lukas Renggli www.lukas-renggli.ch
Hi: On 07 Nov 2011, at 23:38, Stéphane Ducasse wrote:
if you look in the scripttloatder you can tell the MC that it should apply a list of package one after the other and not (by default collect all the classes and apply all the change together).
Hm, I currently have only one Monticello package. I don't put subpackages currently into different *mcz, but I guess that is the way to go. Thanks Lukas, but that looks like breaking a fly on the wheel. Don't need that kind of complexity just yet.
Now another smart move is to think (if the license allows it) how you can push the hooks that you need to the community like that you are more customization and less override. License: MIT... But, 50% of the stuff is to specific, I think.
The following would be a candidate for inclusion: ----- !Parser class methodsFor: '*Omni-Compiler-Kernel' stamp: 'StefanMarr 11/3/2011 21:40'! encoderClassFor: aCompiledMethod ^ aCompiledMethod isBlueBookCompiled ifTrue: [EncoderForV3] ifFalse: [EncoderForV3PlusClosures]! ! !CompiledMethod methodsFor: '*Omni-Compiler-Kernel' stamp: 'StefanMarr 11/3/2011 15:55'! methodNode "Return the parse tree that represents self" | aClass source | aClass := self methodClass. source := self getSourceFor: (self selector ifNil: [self defaultSelector]) in: aClass. ^(aClass parserClass new encoderClass: (aClass parserClass encoderClassFor: self); parse: source class: aClass) sourceText: source; yourself! ! ----- But for instance the following and similar changes aren't generally useful, and probably just an artifact of me being too lazy to do it right: !InstanceVariableNode methodsFor: '*Omni-code generation' stamp: 'StefanMarr 11/3/2011 14:20'! emitCodeForValue: stack encoder: encoder stack push: 1. encoder adjustParseStackForPushInstVar: stack. ^encoder genPushInstVar: index! ! !BytecodeEncoder methodsFor: '*Omni-bytecode generation' stamp: 'StefanMarr 11/3/2011 14:20'! adjustParseStackForPushInstVar: parseStack ^ parseStack! ! Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
if you want that markus get a look at them open a bug entry and write one sentence of description and put cs. STef On Nov 8, 2011, at 12:24 AM, Stefan Marr wrote:
Hi:
On 07 Nov 2011, at 23:38, Stéphane Ducasse wrote:
if you look in the scripttloatder you can tell the MC that it should apply a list of package one after the other and not (by default collect all the classes and apply all the change together).
Hm, I currently have only one Monticello package. I don't put subpackages currently into different *mcz, but I guess that is the way to go.
Thanks Lukas, but that looks like breaking a fly on the wheel. Don't need that kind of complexity just yet.
Now another smart move is to think (if the license allows it) how you can push the hooks that you need to the community like that you are more customization and less override. License: MIT... But, 50% of the stuff is to specific, I think.
The following would be a candidate for inclusion:
----- !Parser class methodsFor: '*Omni-Compiler-Kernel' stamp: 'StefanMarr 11/3/2011 21:40'! encoderClassFor: aCompiledMethod ^ aCompiledMethod isBlueBookCompiled ifTrue: [EncoderForV3] ifFalse: [EncoderForV3PlusClosures]! !
!CompiledMethod methodsFor: '*Omni-Compiler-Kernel' stamp: 'StefanMarr 11/3/2011 15:55'! methodNode "Return the parse tree that represents self" | aClass source | aClass := self methodClass. source := self getSourceFor: (self selector ifNil: [self defaultSelector]) in: aClass. ^(aClass parserClass new encoderClass: (aClass parserClass encoderClassFor: self); parse: source class: aClass) sourceText: source; yourself! ! -----
But for instance the following and similar changes aren't generally useful, and probably just an artifact of me being too lazy to do it right:
!InstanceVariableNode methodsFor: '*Omni-code generation' stamp: 'StefanMarr 11/3/2011 14:20'! emitCodeForValue: stack encoder: encoder stack push: 1. encoder adjustParseStackForPushInstVar: stack. ^encoder genPushInstVar: index! !
!BytecodeEncoder methodsFor: '*Omni-bytecode generation' stamp: 'StefanMarr 11/3/2011 14:20'! adjustParseStackForPushInstVar: parseStack ^ parseStack! !
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
participants (3)
-
Lukas Renggli -
Stefan Marr -
Stéphane Ducasse