June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiling a method taking wrong source

by Guillermo Polito

Mmm, maybe I'm using an old image. Let me check, thanks! On Sun, Jun 19, 2011 at 4:17 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > This is a bug introduced by the TextEditor changes. I thought it was > fixed in the latest Pharo 1.2.1? > > Lukas > > On 19 June 2011 20:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Well, replacing: > > > > self logMethodSource: text forMethodWithNode: methodAndNode > > inCategory: category withStamp: changeStamp notifying: > > requestor. > > > > by > > > > self logMethodSource: methodAndNode node printString forMethodWithNode: > > methodAndNode > > inCategory: category withStamp: changeStamp notifying: > > requestor. > > > > Works well :). But for sure I smell I'm doing something veeery wrong :S > > > > Has it something to do with using a mutable text instead of a string? > > > > On Sun, Jun 19, 2011 at 3:32 PM, Guillermo Polito > > <guillermopolito(a)gmail.com> wrote: > >> > >> Hi, I have a simple snippet of code which says: > >> > >> someObject class compile: aMethod classified: someCategory notifying: > >> aRequestor. > >> > >> where aRequestor is a PluggableTextMorph. > >> > >> Actually, when I try to compile a method with a temp var, letting the > >> compiler notify me when a temp var is needed, I always see the final > >> CompiledMethod with the wrong source. For example, compiling > >> > >> someMethod > >> ^someTemp > >> > >> Is correctly updated to be > >> > >> someMethod > >> | someTemp | > >> ^someTemp > >> > >> But, after the compilation process, when I get the compiled method > source, > >> It just have > >> > >> someMethod > >> ^someTemp > >> > >> > >> Debugging, I ended up in > >> > >> ClassDescriptioncompile: text classified: category withStamp: > changeStamp > >> notifying: requestor logSource: logSource > >> | methodAndNode | > >> methodAndNode := self compile: text asString classified: category > >> notifying: requestor > >> trailer: self defaultMethodTrailer ifFail: > >> [^nil]. > >> logSource ifTrue: [ > >> self logMethodSource: text forMethodWithNode: methodAndNode > >> inCategory: category withStamp: changeStamp notifying: > >> requestor. > >> ]. > >> self addAndClassifySelector: methodAndNode selector withMethod: > >> methodAndNode > >> method inProtocol: category notifying: requestor. > >> self instanceSide noteCompilationOf: methodAndNode selector meta: > self > >> isClassSide. > >> ^ methodAndNode selector > >> > >> Which is saving as the CompiledMethod source, the original text, not the > >> one which was changed in the PluggableTextMorph and compiled in the > >> methodAndNode object. > >> > >> > >> Well, I was looking how the Browser works, and I didn't realize the > >> difference... Can someone enlight me? > >> > >> Thanks, > >> Guille > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

June 19, 2011

Re: [Pharo-project] Compiling a method taking wrong source

by Lukas Renggli

This is a bug introduced by the TextEditor changes. I thought it was fixed in the latest Pharo 1.2.1? Lukas On 19 June 2011 20:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Well, replacing: > > self logMethodSource: text forMethodWithNode: methodAndNode > Â Â Â Â Â Â Â Â Â inCategory: category withStamp: changeStamp notifying: > requestor. > > by > > self logMethodSource: methodAndNode node printString forMethodWithNode: > methodAndNode > Â Â Â Â Â Â Â Â Â inCategory: category withStamp: changeStamp notifying: > requestor. > > Works well :).Â But for sure I smell I'm doing something veeery wrong :S > > Has it something to do with using a mutable text instead of a string? > > On Sun, Jun 19, 2011 at 3:32 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> Hi, I have a simple snippet of code which says: >> >> someObject class compile: aMethod classified: someCategory notifying: >> aRequestor. >> >> where aRequestor is a PluggableTextMorph. >> >> Actually, when I try to compile a method with a temp var, letting the >> compiler notify me when a temp var is needed, I always see the final >> CompiledMethod with the wrong source.Â For example, compiling >> >> someMethod >> Â ^someTemp >> >> Is correctly updated to be >> >> someMethod >> Â | someTemp | >> Â ^someTemp >> >> But, after the compilation process, when I get the compiled method source, >> It just have >> >> someMethod >> Â ^someTemp >> >> >> Debugging, I ended up in >> >> ClassDescriptioncompile: text classified: category withStamp: changeStamp >> notifying: requestor logSource: logSource >> Â Â Â | methodAndNode | >> Â Â Â methodAndNode := self compile: text asString classified: category >> notifying: requestor >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â trailer: self defaultMethodTrailer ifFail: >> [^nil]. >> Â Â Â logSource ifTrue: [ >> Â Â Â Â Â Â self logMethodSource: text forMethodWithNode: methodAndNode >> Â Â Â Â Â Â Â Â Â inCategory: category withStamp: changeStamp notifying: >> requestor. >> Â Â Â ]. >> Â Â Â self addAndClassifySelector: methodAndNode selector withMethod: >> methodAndNode >> Â Â Â Â Â Â method inProtocol: category notifying: requestor. >> Â Â Â self instanceSide noteCompilationOf: methodAndNode selector meta: self >> isClassSide. >> Â Â Â ^ methodAndNode selector >> >> Which is saving as the CompiledMethod source, the original text, not the >> one which was changed in the PluggableTextMorph and compiled in the >> methodAndNode object. >> >> >> Well, I was looking how the Browser works, and I didn't realize the >> difference...Â Can someone enlight me? >> >> Thanks, >> Guille > > -- Lukas Renggli www.lukas-renggli.ch

June 19, 2011

Re: [Pharo-project] Compiling a method taking wrong source

by Guillermo Polito

Well, replacing: self logMethodSource: *text* forMethodWithNode: methodAndNode inCategory: category withStamp: changeStamp notifying: requestor. by self logMethodSource: *methodAndNode node printString* forMethodWithNode: methodAndNode inCategory: category withStamp: changeStamp notifying: requestor. Works well :). But for sure I smell I'm doing something veeery wrong :S Has it something to do with using a mutable text instead of a string? On Sun, Jun 19, 2011 at 3:32 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi, I have a simple snippet of code which says: > > *someObject class compile: aMethod classified: someCategory notifying: > aRequestor.* > > where aRequestor is a PluggableTextMorph. > > Actually, when I try to compile a method with a temp var, letting the > compiler notify me when a temp var is needed, I always see the final > CompiledMethod with the wrong source. For example, compiling > > someMethod > ^someTemp > > Is correctly updated to be > > someMethod > | someTemp | > ^someTemp > > But, after the compilation process, when I get the compiled method source, > It just have > > someMethod > ^someTemp > > > Debugging, I ended up in > > ClassDescriptioncompile: *text* classified: category withStamp: > changeStamp notifying: requestor logSource: logSource > | methodAndNode | > methodAndNode := self compile: text asString classified: category > notifying: requestor > trailer: self defaultMethodTrailer ifFail: > [^nil]. > logSource ifTrue: [ > self logMethodSource: *text* forMethodWithNode: methodAndNode > inCategory: category withStamp: changeStamp notifying: > requestor. > ]. > self addAndClassifySelector: methodAndNode selector withMethod: > methodAndNode > method inProtocol: category notifying: requestor. > self instanceSide noteCompilationOf: methodAndNode selector meta: self > isClassSide. > ^ methodAndNode selector > > Which is saving as the CompiledMethod source, the original text, not the > one which was changed in the PluggableTextMorph and compiled in the > methodAndNode object. > > > Well, I was looking how the Browser works, and I didn't realize the > difference... Can someone enlight me? > > Thanks, > Guille >

June 19, 2011

[Pharo-project] Compiling a method taking wrong source

by Guillermo Polito

Hi, I have a simple snippet of code which says: *someObject class compile: aMethod classified: someCategory notifying: aRequestor.* where aRequestor is a PluggableTextMorph. Actually, when I try to compile a method with a temp var, letting the compiler notify me when a temp var is needed, I always see the final CompiledMethod with the wrong source. For example, compiling someMethod ^someTemp Is correctly updated to be someMethod | someTemp | ^someTemp But, after the compilation process, when I get the compiled method source, It just have someMethod ^someTemp Debugging, I ended up in ClassDescriptioncompile: *text* classified: category withStamp: changeStamp notifying: requestor logSource: logSource | methodAndNode | methodAndNode := self compile: text asString classified: category notifying: requestor trailer: self defaultMethodTrailer ifFail: [^nil]. logSource ifTrue: [ self logMethodSource: *text* forMethodWithNode: methodAndNode inCategory: category withStamp: changeStamp notifying: requestor. ]. self addAndClassifySelector: methodAndNode selector withMethod: methodAndNode method inProtocol: category notifying: requestor. self instanceSide noteCompilationOf: methodAndNode selector meta: self isClassSide. ^ methodAndNode selector Which is saving as the CompiledMethod source, the original text, not the one which was changed in the PluggableTextMorph and compiled in the methodAndNode object. Well, I was looking how the Browser works, and I didn't realize the difference... Can someone enlight me? Thanks, Guille

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

On Jun 19, 2011, at 4:24 PM, Tudor Girba wrote: > Hi, > > Sounds good. > > Is there a coordinated effort for Morphic improvements? Not that I know. What we will try is to - review changes proposed by fernando - write some text of widgets and clean the system with ben Stef > > Cheers, > Doru > > > On 18 Jun 2011, at 14:59, StÃ©phane Ducasse wrote: > >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > >

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Tudor Girba

Hi, Sounds good. Is there a coordinated effort for Morphic improvements? Cheers, Doru On 18 Jun 2011, at 14:59, StÃ©phane Ducasse wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Alexandre Bergel

> Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 1.3 and it works. I got ashamed by the amount of options in the menu, but I managed to find how to load a configuration and a version, jeje. I currently suspended my work on the browser. Unfortunately, I do not have much resources to allocate on it right now. Alexandre > > Cheers, > Guille > > On Sun, Jun 19, 2011 at 7:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: > > > Hi, > > > > I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. > > Yes yes yes but :) we should have a set of tools that are working together and we should not be responsible of making sure that all the possible combination work. > I would like to get a process (as I mentioned in the other mail) > seed + MetacelloSpec + modification => seed' + MetacelloSpec' > > and that we are able to build hudson that takes > aSeed + a spec > => run all the tests + run all the quality check > > Right now we have > seed + list of package + modification => seed' + list of package' > > and we get in trouble when we modify seed parts that influence external package > > so what we want is to have > seed + metacello = the minimal tools that we need to be efficient modifying seed > for me > OB Engine > Shout > O/Ecompletion > > Stef > > > > > > -- Pavel > > > > > > > > 18.6.2011 v 22:29, Guillermo Polito <guillermopolito(a)gmail.com>: > > > >> Hi Stef! > >> > >> do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). > >> I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? > >> > >> Guille > >> > >> On Sat, Jun 18, 2011 at 9:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys > >> > >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > >> > >> - load FileSystem > >> -> so that we can start to integrate and improve the fileSystem API > >> > >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > >> > >> - Ring > >> -> so that we can start to integrate it > >> > >> - Fuel > >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > >> > >> - I want Opal in 1.4 too. > >> > >> - continue to remove StringHolder hierarchy > >> > >> - Morphic improvements > >> > >> Comments are welcomed. > >> > >> Stef > >> > >> > >> > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Hilaire Fernandes

Le 19/06/2011 08:10, Yanni Chiu a Ã©crit : > +1 > > Me too - I never use full Pharo. I build the image I want from Core. If > there were a suitable special purpose image built as outlined above, Same, I don't use anylonger full phaor for dev image nor to distribute drgeo Hilaire

June 19, 2011

[Pharo-project] ZnServer - Swazoo - Comanche

by GermÃ¡n Arduino

Hi Sven, People: I want to ask about ZnServer, is focused in have at some point all the features of Swazoo or Comanche and being itself a complete web server? Or the goal is only to be a default implementation, as the comment says? Thanks. GermÃ¡n.

June 19, 2011

Re: [Pharo-project] roadmap for 1.4

by Guillermo Polito

What if we try integrating MetacelloBrowser in that PharoCoreWithVitamins? That can solve our one-click-download problem! Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 1.3 and it works. I got ashamed by the amount of options in the menu, but I managed to find how to load a configuration and a version, jeje. Cheers, Guille On Sun, Jun 19, 2011 at 7:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: > > > Hi, > > > > I think that the best idea is to have one image for the system > developers and end-users (for example, I almost never used full Pharo so it > lost one tester). On the other hand we should continue with the > modularization to allow to generate headless kernel image, gopher image, > basic morphic image etc. on the request with bootstrapping. To have smallest > possible image is not the main goal of the effort around PharoKernel. The > main goal is to have beauty modular system where all dependencies all > described well and packages can be easily loaded and unloaded. The > buildserver can generate all the set of images for special purposes so it > will be more natural then now when we have two main images. > > Yes yes yes but :) we should have a set of tools that are working together > and we should not be responsible of making sure that all the possible > combination work. > I would like to get a process (as I mentioned in the other mail) > seed + MetacelloSpec + modification => seed' + MetacelloSpec' > > and that we are able to build hudson that takes > aSeed + a spec > => run all the tests + run all the quality check > > Right now we have > seed + list of package + modification => seed' + list of package' > > and we get in trouble when we modify seed parts that influence > external package > > so what we want is to have > seed + metacello = the minimal tools that we need to be efficient > modifying seed > for me > OB Engine > Shout > O/Ecompletion > > Stef > > > > > > -- Pavel > > > > > > > > 18.6.2011 v 22:29, Guillermo Polito <guillermopolito(a)gmail.com>: > > > >> Hi Stef! > >> > >> do you mean integrating all them in the Core? Or maybe follow Markus' > idea of having just one image? Maybe that's an important discussion to have > too :). > >> I can give a hand for the repository stuff. Should we replicate > repositories + metacello configs in order to be able to freeze them, isn't > it? > >> > >> Guille > >> > >> On Sat, Jun 18, 2011 at 9:59 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys > >> > >> here is a kind of dump of roadmap for 1.4 first level is to make sure > that we have only one single image. > >> > >> - load FileSystem > >> -> so that we can start to integrate and improve the fileSystem > API > >> > >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what > should be changed for RPackage to work > >> > >> - Ring > >> -> so that we can start to integrate it > >> > >> - Fuel > >> -> so that we can deprecate SmartRefStream (there may be a > problem with mcz (not sure)). > >> > >> - I want Opal in 1.4 too. > >> > >> - continue to remove StringHolder hierarchy > >> > >> - Morphic improvements > >> > >> Comments are welcomed. > >> > >> Stef > >> > >> > >> > > >

June 19, 2011