July 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Object-oriented reengineering patterns :)

by StÃ©phane Ducasse

In changeList browseCurrentVersionsOfSelections "Opens a message-list browser on the current in-memory versions of all methods that are currently seleted" | aList | aList := OrderedCollection new. Cursor read showWhile: [ 1 to: changeList size do: [:i | (listSelections at: i) ifTrue: [ | aClass aChange | aChange := changeList at: i. (aChange type = #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) contentsDiffedFromCurrent "Answer the contents diffed forward from current (in-memory) method version" | aChange aClass | listIndex = 0 ifTrue: [^ '']. aChange := changeList at: listIndex. (aChange type == #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) ifTrue: destroyCurrentCodeOfSelections "Actually remove from the system any in-memory methods with class and selector identical to items current selected. This may seem rather arcane but believe me it has its great uses, when trying to split out code. To use effectively, first file out a change set that you wish to split off. Then open a ChangeList browser on that fileout. Now look through the methods, and select any of them which you want to remove completely from the system, then issue this command. For those methods where you have made changes to pre-existing versions, of course, you won't want to remove them from the system, so use this mechanism with care!" | aClass aChange aList | aList := OrderedCollection new. 1 to: changeList size do: [:index | (listSelections at: index) ifTrue: [aChange := changeList at: index. (aChange type = #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) ifTrue: and a couple more.... I like old design. It is sweet and you feel cool when you fix it. Stef

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by StÃ©phane Ducasse

Ok ;) > My point was that while good work on non-interactive errors in the standard compiler has been done there's no guarantee its finished and we should check and make whatever modifications are required so that it all errors can be caught. > > best > Eliot > > Fernando if you can check and let us know.

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Lukas Renggli

Yeah, these notifications are integrated in Pharo 1.0. OmniBrowser uses them. Lukas On 23 July 2010 19:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I thought I integrated those. > Fernando if you can check and let us know. > > Stef > > On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > >> Hi Fernando, >> >> On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. >> >> I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, >> it always gives me visual feedback ( pop menus and related dialogs). >> >> Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. Â These are in Squeak 4.1. Â Have you taken a look at the trunk 4.1 compiler? Â Clearly the standard compiler should be able to do what you want. Â We should fix it :) >> >> best >> Eliot >> >> Maybe the newCompiler is more customizable? >> >> Fernando >> >> >> On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: >> >> > You can use #parseMethod:onError: to check for syntactical errors. >> > >> > Semantical errors are harder to detect, some of them (e.g. undeclared >> > variables) you can find using AST-Semantics. >> > >> > Lukas >> > >> > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> >> I have a question about validating a methodNode, suppose we have the following: >> >> >> >> parsedNode := Â RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. >> >> >> >> Is there a way of checking the health/validity of the parsedNode? >> >> >> >> I couldn't find any behavior in RBMethodNode or related classes. >> >> >> >> Lukas, do you have an idea is i could run any Lint rule? >> >> >> >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. >> >> >> >> Thanks, >> >> Fernando >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Eliot Miranda

Hi StÃ©phane, On Fri, Jul 23, 2010 at 10:12 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I thought I integrated those. > My point was that while good work on non-interactive errors in the standard compiler has been done there's no guarantee its finished and we should check and make whatever modifications are required so that it all errors can be caught. best Eliot > Fernando if you can check and let us know. > > Stef > > On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > > > Hi Fernando, > > > > On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> > wrote: > > Lukas, thanks for the answer. I will see if AST-Semantics solves my > problem. > > > > I also tried using the Compiler and the parser, and faking a notifier. > But the Compiler>>interactive behavior is hard to override, > > it always gives me visual feedback ( pop menus and related dialogs). > > > > Colin Putney has done good work replacing a number of interactive errors > with exceptions whose defaultAction is to produce the notifier. These are > in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly > the standard compiler should be able to do what you want. We should fix it > :) > > > > best > > Eliot > > > > Maybe the newCompiler is more customizable? > > > > Fernando > > > > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > > variables) you can find using AST-Semantics. > > > > > > Lukas > > > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > >> I have a question about validating a methodNode, suppose we have the > following: > > >> > > >> parsedNode := RBParser parseMethod: 'test ^ self add: > anUnbindedVariable'. > > >> > > >> Is there a way of checking the health/validity of the parsedNode? > > >> > > >> I couldn't find any behavior in RBMethodNode or related classes. > > >> > > >> Lukas, do you have an idea is i could run any Lint rule? > > >> > > >> My idea is to provide a method editor morph, that prevents from > accepting invalid sources, and informs the user any problems detected with > the edited code. > > >> > > >> Thanks, > > >> Fernando > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > > > > > > > > > > -- > > > Lukas Renggli > > > www.lukas-renggli.ch > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by StÃ©phane Ducasse

I thought I integrated those. Fernando if you can check and let us know. Stef On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > Hi Fernando, > > On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. > > I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). > > Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. These are in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly the standard compiler should be able to do what you want. We should fix it :) > > best > Eliot > > Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > variables) you can find using AST-Semantics. > > > > Lukas > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > >> I have a question about validating a methodNode, suppose we have the following: > >> > >> parsedNode := RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. > >> > >> Is there a way of checking the health/validity of the parsedNode? > >> > >> I couldn't find any behavior in RBMethodNode or related classes. > >> > >> Lukas, do you have an idea is i could run any Lint rule? > >> > >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. > >> > >> Thanks, > >> Fernando > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Eliot Miranda

Hi Fernando, On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my > problem. > > I also tried using the Compiler and the parser, and faking a notifier. But > the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. These are in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly the standard compiler should be able to do what you want. We should fix it :) best Eliot > Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > variables) you can find using AST-Semantics. > > > > Lukas > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > >> I have a question about validating a methodNode, suppose we have the > following: > >> > >> parsedNode := RBParser parseMethod: 'test ^ self add: > anUnbindedVariable'. > >> > >> Is there a way of checking the health/validity of the parsedNode? > >> > >> I couldn't find any behavior in RBMethodNode or related classes. > >> > >> Lukas, do you have an idea is i could run any Lint rule? > >> > >> My idea is to provide a method editor morph, that prevents from > accepting invalid sources, and informs the user any problems detected with > the edited code. > >> > >> Thanks, > >> Fernando > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 23, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Henrik Johansen

Den 23. juli 2010 kl. 15:15 skrev "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > No dialogs, please :) Actually, it would be fine if there were a different stream class or simply a different method/state (encoding =#userInteraction or something??) that is understood to negotiate such details with "the user." I have no idea what you are suggesting... > In general, exception is the correct way to handle this: the stream "knows" what is wrong; the application will know what to make of it. If the encoding can be detected automatically, that would be great. > Then I fail to see what the problem is. You got an error stating it was not UTF8, which implies a choice of the correct encoding needs to be done by the application. (by setting the streams encoding to something else) As you noticed with gedit/firefox, any "automatic" detection is at best an educated guess, and can not be relied upon to make the correct choice. Cheers, Henry

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Yanni Chiu

Here's my understanding of how it works. Garbage collection is completed before the Unix fork system call is made. At the moment of the fork, the original server VM process and the new image saving VM process share the exact same pages in the Unix OS - due to "Unix copy-on-write memory management". Immediately after the fork, the server VM process continues processing requests. Meanwhile, the image saving VM process proceeds to save the image. As each process continues execution, they will "dirty" their memory pages. Each dirty page means that that page is no longer shared between the two processes - leading to increased OS memory resources being allocated to the two processes. If the server VM process is very active, then a lot of dirty pages will be created, before the image saving VM process can complete. So, running the image saving process at a lower priority may actually be detrimental. One thing that occurs to me now, is whether or not the garbage collection is completed before the fork. If not, and it's done first thing by the image saving process, then it will be as you describe - the whole memory gets copied anyway. -- Yanni Lukas Renggli wrote: > David, is what is said about memory management really true? I thought > that saving the image triggered a garbage collect what forces to copy > the whole memory anyway. > > Lukas > > On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: >> On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >>>> But How I can do that without fork? I track changes in another process and >>>> when I do update I save image in this process. >>>> How I can initiate image saving from ui process? >>> I don't understand what you are saying. >>> >>> The thing is that using #fork to save the image has no effect (other >>> than wrecking the image), because #snapshot:andQuit: is eventually >>> calling a primitive that locks the complete VM anyway. >>> >>> If you want to fork while saving the image you need to use an OS-level >>> fork, not a Smalltalk-level fork. You can do this with OSProcess for >>> example (check the Seaside mailing-list archive). >> "UnixProcess saveImageInBackgroundNicely" >> >> Explained in the method comment: >> >> UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag >> "When Squeak is used as a server it is sometimes desirable to periodically >> save image snapshots. This method forks a headless Squeak to perform a >> snapshot without impacting the server Squeak. Very little additional memory >> is required to do this because Unix copy-on-write memory management allows >> the two Squeak images to share object memory while the save is performed. >> The saved image is given a time stamped name, and the image name of >> the main server Squeak remains unchanged. If niceFlag is true, the >> background OS process runs at lowered scheduling priority." >> >> Dave

July 23, 2010

Re: [Pharo-project] Another RB engine change

by StÃ©phane Ducasse

Smalltalk>>globals ^ self in 1.0 then :) On Jul 23, 2010, at 5:32 PM, Yanni Chiu wrote: > I don't use omnibrowser on Pharo-1.0, but I was still building it. See: > http://hudson.jooshr.org/job/Pharo1.0-Seaside3.0/200/testReport/ > > I checked only a few of the stacktraces on the 404 newly failing tests, and they were all: > SystemDictionary(Object)>>doesNotUnderstand: #globals > > Maybe the simplest thing to do is a maintenance patch to Pharo-1.0 with an implementation for Smalltalk>>globals. > > > > Lukas Renggli wrote: >> I fixed that and about 30 other occurrences of the same problem. >> Name: Refactoring-Core-lr.147 >> Author: lr >> Time: 23 July 2010, 8:14:01 am >> UUID: 8e608df4-579d-4a3d-a589-0eb90109275e >> Ancestors: Refactoring-Core-lr.146 >> - fixed numerous occurrences where the old 'Smalltalk' was used >> Thank you for pointing out. >> Lukas >> On 23 July 2010 00:01, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >>> Hi Lukas, here is another change in the RB engine package. >>> >>> RBClass>>realName: aSymbol >>> self realClass: (Smalltalk at: aSymbol) >>> >>> => >>> self realClass: (Smalltalk globals at: aSymbol) >>> >>> Fernando >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Lukas Renggli

Cool, thanks for the update. On Friday, July 23, 2010, David T. Lewis <lewis(a)mail.msen.com> wrote: > Yes, it really is true. That said, I would expect the practical impact > to vary depending on how busy the main image is. > > If you are running a Squeak/Pharo image that is not busy, such as your > own personal desktop image or a Seaside image that is not currently > receiving requests, then the additional system memory used by the > forked background image is extremely small (it's pretty amazing > actually, try watching it on a system monitor such as xosview). > However, I would expect that if you were to do this with a busy > Seaside image, then that image would be doing a lot of updates to > memory and possibly garbage collection, so that will force the OS > to use more memory. > > Unfortunately this means that the busier your image is, the less > benefit you get from a memory usage point of view. But even at that, > you still get the advantage of doing the image save in a background > OS process running at lower OS scheduling priority. > > I do not actually run any Seaside server images, so someone would > need to try this on a real system to find out how much benefit it > delivers in practice. I would be interested to know the results. > > Dave > > > On Fri, Jul 23, 2010 at 02:12:14PM +0200, Lukas Renggli wrote: >> David, is what is said about memory management really true? I thought >> that saving the image triggered a garbage collect what forces to copy >> the whole memory anyway. >> >> Lukas >> >> On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: >> > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >> >> > But How I can do that without fork? I track changes in another process and >> >> > when I do update I save image in this process. >> >> > How I can initiate image saving from ui process? >> >> >> >> I don't understand what you are saying. >> >> >> >> The thing is that using #fork to save the image has no effect (other >> >> than wrecking the image), because #snapshot:andQuit: is eventually >> >> calling a primitive that locks the complete VM anyway. >> >> >> >> If you want to fork while saving the image you need to use an OS-level >> >> fork, not a Smalltalk-level fork. You can do this with OSProcess for >> >> example (check the Seaside mailing-list archive). >> > >> > "UnixProcess saveImageInBackgroundNicely" >> > >> > Explained in the method comment: >> > >> > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag >> > ? ? ? ?"When Squeak is used as a server it is sometimes desirable to periodically >> > ? ? ? ?save image snapshots. This method forks a headless Squeak to perform a >> > ? ? ? ?snapshot without impacting the server Squeak. Very little additional memory >> > ? ? ? ?is required to do this because Unix copy-on-write memory management allows >> > ? ? ? ?the two Squeak images to share object memory while the save is performed. >> > ? ? ? ?The saved image is given a time stamped name, and the image name of >> > ? ? ? ?the main server Squeak remains unchanged. If niceFlag is true, the >> > ? ? ? ?background OS process runs at lowered scheduling priority." >> > >> > Dave >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010