November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Seaside and SUnit

by StÃ©phane Ducasse

you have two testing frameworks albratross and david shaffer testing framework You also have selenium that people use to test seaside app. Stef On Nov 7, 2009, at 1:04 AM, Schwab,Wilhelm K wrote: > Stef, > > Is albatross the right place to look for help? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 7, 2009

Re: [Pharo-project] Merging Algorithm Question

by Lukas Renggli

When I merge Morphic-jannik_laval.400 into the latest Pharo 1.1 I do not get a class called Presenter. Or what ***exactly*** did you try to do? Lukas 2009/11/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Nov 4, 2009, at 9:38 PM, Lukas Renggli wrote: > >>> Lukas in my example in fact Presenter was removed as well as other >>> methods. >>> Then since they were present at the time jannik commited they >>> reappear >>> when I merge >>> and I do not see why they are not at least tagged with conflicts. >> >> If you remove Presenter and Jannik does not touch it, then it should >> remain removed after the merge. > > > yes this is what I thought (or at least a conflict) > >> If you remove Presenter and Jannik does touch it, then you should get >> a conflict. > > Yes this is what I thought too :) > >> Presenter can only reappear, if in your delta or in the delta of >> Jannik the Presenter is added (which doesn't seem to make sense, so I >> don't understand). > > me neither :) > because Jannik did not touch it. > Can you give a try to do a merge of heading removal in the latest 1,1 > image to see > if you get the same behavior. > >> >> Lukas >> >> -- >> Lukas Renggli >> http://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 http://www.lukas-renggli.ch

Nov. 7, 2009

[Pharo-project] Linux VM download has split personality

by Martin McClure

The current Linux VM download, http://gforge.inria.fr/frs/download.php/24653/pharo-vm-0.15.2e-linux.zip, linked to from the pharo-download page, seems rather confused. It contains two top-level directories: pharo-vm-0.15.2d-linux pharo-vm-0.15.2e-linux The 0.15.2d one contains over 200 symlinks in 90 directories, but no actual files. The 0.15.2e one contains over 400 files, but no symlinks. The previous zip file contains the same number of symlinks and files, but all under the same directory. Regards, -Martin

Nov. 7, 2009

Re: [Pharo-project] feedback on HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading

by Schwab,Wilhelm K

Stef, Let's see, we have a method that includes writes to the transcript along side of obfuscated (in the name of speed) access to instance variables of a stream that is used as little more than a glorified value holder for an integer position. FWIW, I don't think that an HTTP client should inherit from socket; there is a lot of errant use of inheritance in Squeak. We have bigger battles to fight, but over time, these things should be refactored. Today I discovered that SocketStream defaults to using timeouts and suppressing errors. Hopefully I have corrected those two problems for my code. I trust your judgement. Is any of the above helpful? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, November 05, 2009 3:40 PM To: Pharo Development Subject: [Pharo-project] feedback on HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading I would really like to get some feddback on that issue http://code.google.com/p/pharo/issues/detail?id=1152 Issue 1152: HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 7, 2009

[Pharo-project] Seaside and SUnit

by Schwab,Wilhelm K

Stef, Is albatross the right place to look for help? Bill

Nov. 7, 2009

Re: [Pharo-project] invalid sources for unregistered CompiledMethod

by Igor Stasenko

2009/11/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Ah, I forgot to say that if you recompile the methodClass, it won't > trigger recompilation of those unregistered methods. > Some actions like removing an inst var can then trigger very bad > things when you try to execute those unregistered methods, like > corrupting memory. > > A security in the class builder would be to: > - mutate all unregistered CompiledMethod pointing to this methodClass > Â before the oldClass becomeForward: newClass > > Then, a security in the VM should prevent those CompiledMethod mutant > to be executed. > (or maybe the mutant could simply be modified to send a message like > self mustBeRecompiled). > > What do you think of this one ? > I would just throw an error and prevent (oldClass becomeForward: newClass) before any unregistered methods is removed from system, or .. skip mutating (oldClass becomeForward: newClass) if such methods hanging around, to avoid possible problems, and let user to deal with obsolete classes. The less magic we have, the more predicatable system will be. > > 2009/11/6 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Most CompiledMethod are registered in a methodDictionary. >> But some are not. >> >> (CompiledMethod allInstances reject: [:e | e methodClass ~~ nil and: >> [e selector ~~ nil and: [e == (e methodClass methodDictionary at: e >> selector ifAbsent: [nil])]]]) size >> >> This is often because a BlockClosure has been registered somewhere in >> a registry (a ServiceRegistry for example). >> The objects pointers chain is something like: >> a SeviceRegistry -> a ServiceAction -> a BlockClosure -> a >> MethodContext -> a CompiledMethod... >> >> Another source of MethodContext instances is a concurrent Process >> running in the image. >> >> If ever recompiled, a new instance of the CompiledMethod is installed >> in the methodDictionary. >> But the old CompiledMethod is still there, being pointed to by above chains. >> The old CompiledMethod has a source code pointer pointing to >> sourceCode somewhere in the change Log, and so far it's fine. >> >> But what if you compress the change log ? >> The registered CompiledMethod all get a valid new pointer to the new >> source location. >> But the unregistered ones retain their old pointer now pointing >> randomly in the change file. >> This is bad. >> >> (CompiledMethod allInstances select: [:e | e selector = >> #id:text:button:description:action: and: [(e methodClass >> methodDictionary at: e selector ifAbsent: [nil]) ~~ e]]) anyOne >> getSource >> >> Now if you try to decompile the method, either there is an Error like >> here, or unfortunately the random sourceCode is valid a valid chunk of >> Smalltalk and you open the door to potentially strange things... It >> could be misleading if you try to understand what the hell this >> SeviceAction could be doing. >> >> If you try to decompile the BlockClosure, and getSource does not point >> to valid code, it doesn't work, you get nil... This is another bug, >> because #decompile should revert to homeMethod decompile >> decompileString... >> >> I propose that #condenseChanges and the like, anihilate source code >> pointers of unregistered CompiledMethod. >> This should solve the issue. >> What do you think ? >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 6, 2009

Re: [Pharo-project] invalid sources for unregistered CompiledMethod

by Igor Stasenko

2009/11/6 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Most CompiledMethod are registered in a methodDictionary. > But some are not. > > (CompiledMethod allInstances reject: [:e | e methodClass ~~ nil and: > [e selector ~~ nil and: [e == (e methodClass methodDictionary at: e > selector ifAbsent: [nil])]]]) size > > This is often because a BlockClosure has been registered somewhere in > a registry (a ServiceRegistry for example). > The objects pointers chain is something like: > a SeviceRegistry -> a ServiceAction -> a BlockClosure -> a > MethodContext -> a CompiledMethod... > > Another source of MethodContext instances is a concurrent Process > running in the image. > > If ever recompiled, a new instance of the CompiledMethod is installed > in the methodDictionary. > But the old CompiledMethod is still there, being pointed to by above chains. > The old CompiledMethod has a source code pointer pointing to > sourceCode somewhere in the change Log, and so far it's fine. > > But what if you compress the change log ? > The registered CompiledMethod all get a valid new pointer to the new > source location. > But the unregistered ones retain their old pointer now pointing > randomly in the change file. > This is bad. > > (CompiledMethod allInstances select: [:e | e selector = > #id:text:button:description:action: and: [(e methodClass > methodDictionary at: e selector ifAbsent: [nil]) ~~ e]]) anyOne > getSource > > Now if you try to decompile the method, either there is an Error like > here, or unfortunately the random sourceCode is valid a valid chunk of > Smalltalk and you open the door to potentially strange things... It > could be misleading if you try to understand what the hell this > SeviceAction could be doing. > > If you try to decompile the BlockClosure, and getSource does not point > to valid code, it doesn't work, you get nil... This is another bug, > because #decompile should revert to homeMethod decompile > decompileString... > > I propose that #condenseChanges and the like, anihilate source code > pointers of unregistered CompiledMethod. > This should solve the issue. > What do you think ? > Seems like a right way to go. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 6, 2009

Re: [Pharo-project] invalid sources for unregistered CompiledMethod

by Nicolas Cellier

Ah, I forgot to say that if you recompile the methodClass, it won't trigger recompilation of those unregistered methods. Some actions like removing an inst var can then trigger very bad things when you try to execute those unregistered methods, like corrupting memory. A security in the class builder would be to: - mutate all unregistered CompiledMethod pointing to this methodClass before the oldClass becomeForward: newClass Then, a security in the VM should prevent those CompiledMethod mutant to be executed. (or maybe the mutant could simply be modified to send a message like self mustBeRecompiled). What do you think of this one ? 2009/11/6 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Most CompiledMethod are registered in a methodDictionary. > But some are not. > > (CompiledMethod allInstances reject: [:e | e methodClass ~~ nil and: > [e selector ~~ nil and: [e == (e methodClass methodDictionary at: e > selector ifAbsent: [nil])]]]) size > > This is often because a BlockClosure has been registered somewhere in > a registry (a ServiceRegistry for example). > The objects pointers chain is something like: > a SeviceRegistry -> a ServiceAction -> a BlockClosure -> a > MethodContext -> a CompiledMethod... > > Another source of MethodContext instances is a concurrent Process > running in the image. > > If ever recompiled, a new instance of the CompiledMethod is installed > in the methodDictionary. > But the old CompiledMethod is still there, being pointed to by above chains. > The old CompiledMethod has a source code pointer pointing to > sourceCode somewhere in the change Log, and so far it's fine. > > But what if you compress the change log ? > The registered CompiledMethod all get a valid new pointer to the new > source location. > But the unregistered ones retain their old pointer now pointing > randomly in the change file. > This is bad. > > (CompiledMethod allInstances select: [:e | e selector = > #id:text:button:description:action: and: [(e methodClass > methodDictionary at: e selector ifAbsent: [nil]) ~~ e]]) anyOne > getSource > > Now if you try to decompile the method, either there is an Error like > here, or unfortunately the random sourceCode is valid a valid chunk of > Smalltalk and you open the door to potentially strange things... It > could be misleading if you try to understand what the hell this > SeviceAction could be doing. > > If you try to decompile the BlockClosure, and getSource does not point > to valid code, it doesn't work, you get nil... This is another bug, > because #decompile should revert to homeMethod decompile > decompileString... > > I propose that #condenseChanges and the like, anihilate source code > pointers of unregistered CompiledMethod. > This should solve the issue. > What do you think ? >

Nov. 6, 2009

[Pharo-project] invalid sources for unregistered CompiledMethod

by Nicolas Cellier

Most CompiledMethod are registered in a methodDictionary. But some are not. (CompiledMethod allInstances reject: [:e | e methodClass ~~ nil and: [e selector ~~ nil and: [e == (e methodClass methodDictionary at: e selector ifAbsent: [nil])]]]) size This is often because a BlockClosure has been registered somewhere in a registry (a ServiceRegistry for example). The objects pointers chain is something like: a SeviceRegistry -> a ServiceAction -> a BlockClosure -> a MethodContext -> a CompiledMethod... Another source of MethodContext instances is a concurrent Process running in the image. If ever recompiled, a new instance of the CompiledMethod is installed in the methodDictionary. But the old CompiledMethod is still there, being pointed to by above chains. The old CompiledMethod has a source code pointer pointing to sourceCode somewhere in the change Log, and so far it's fine. But what if you compress the change log ? The registered CompiledMethod all get a valid new pointer to the new source location. But the unregistered ones retain their old pointer now pointing randomly in the change file. This is bad. (CompiledMethod allInstances select: [:e | e selector = #id:text:button:description:action: and: [(e methodClass methodDictionary at: e selector ifAbsent: [nil]) ~~ e]]) anyOne getSource Now if you try to decompile the method, either there is an Error like here, or unfortunately the random sourceCode is valid a valid chunk of Smalltalk and you open the door to potentially strange things... It could be misleading if you try to understand what the hell this SeviceAction could be doing. If you try to decompile the BlockClosure, and getSource does not point to valid code, it doesn't work, you get nil... This is another bug, because #decompile should revert to homeMethod decompile decompileString... I propose that #condenseChanges and the like, anihilate source code pointers of unregistered CompiledMethod. This should solve the issue. What do you think ?

Nov. 6, 2009

Re: [Pharo-project] Author = TestRunner

by Adrian Lienhard

On Nov 5, 2009, at 14:39 , Mariano Martinez Peck wrote: > On Sat, Oct 31, 2009 at 7:20 PM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> It happens for instance if you click one of the failing tests after >> intially running tests, then fix the bug in the debugger that pops >> up. >> (i.e., you're comitting changes while the test is being run). >> >> > Ok....I have just faced this problem too. I looked at the code but I > don't > know how to fix it. > > Anyway, why should tests use a particular Author ? I ask just > because of > ignorance. > Is it because of this http://code.google.com/p/pharo/issues/detail?id=1327 > ? yes. The popup is especially annoying when you run the tests on a test server (but also when you start running all tests, get a coffee and when you come back the test runner asking you for your name). [...] > The opened ticket is http://code.google.com/p/pharo/issues/detail?id=1379 Thanks. I did a quick fix that should handle most common cases. Now the name 'TestRunner' is only used if no author was set before starting the tests. The implementation of temporarily setting another author name is too simple to cope with the suspending of a process and opening a debugger from a failed assertion. In this case, one would ideally want to use the real author. The desired behavior could be implemented using a dynamic variable to request the author. The test runner could then catch the notification and return the temporary author. This would then not interfere with compiling methods in the debugger because it runs in a different call stack. Cheers, Adrian > > Best, > > Mariano > > > >> Cheers, >> Henry >> >> On 31.10.2009 18:31, Adrian Lienhard wrote: >>> If I understand you correctly, the author is permanently set to >>> 'TestRunner' after running tests? >>> >>> Do you know which tests cause the problem? Reverting to the original >>> author is done in an ensure block, so I don't see how that can go >>> wrong right now. >>> >>> Adrian >>> >>> On Oct 29, 2009, at 20:57 , StÃ©phane Ducasse wrote: >>> >>> >>>> apparently there is a bad interaction between the test runner and >>>> the >>>> author >>>> because from time to time I get author = TestRunner >>>> Probably the runner code is not robust enough in case of failure >>>> capture or something like that. >>>> >>>> >>>> runCase >>>> Author >>>> useAuthor: 'TestRunner' >>>> during: [ >>>> [self setUp. >>>> self performTest] >>>> ensure: [ >>>> self tearDown. >>>> self >>>> cleanUpInstanceVariables ] ] >>>> >>>> _______________________________________________ >>>> 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

Nov. 6, 2009