- Pharo-dev - lists.pharo.org

[Pharo-project] stephane.ducasse@inria.fr

by Henrik Johansen

Here's a fix for the BlockContext test. Basically, the error message had changed format, so the test that the correct error message was reported failed. I changed the test to check for the (new) error format (which adds argument(s) at the end of the sentence), and changed the error message to not call printstring, since this resulted in the string containing '1' instead of 1. For some reason (which I'm not aware of) the printstring of numbers seem to include quotes. On a totally unrelated note, (didn't include it in the cs since it's not remotely related) Debugger contents:notifying contains a call to Smalltalk>> isMorphic which should probably be removed, comes up everytime you try to save a method edit in the debugger. Cheers, Henry StÃ©phane Ducasse wrote: > I released an archive with two images > 10259 with tests run > 10259-withClosure + john + lukas + my fixes so far > > so that we can go faster to fix the problems > > https://gforge.inria.fr/frs/?group_id=1299 and files > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > 'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March 2009 at 1:47:53 pm'! !BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! numArgsError: numArgsForInvocation | printNArgs | printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] ifFalse:['s'])]. self error: 'This block accepts ', (printNArgs value: numArgs), ', but was called with ', (printNArgs value: numArgsForInvocation), '.'! ! !BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik Sperre Johansen 3/23/2009 13:45'! testValueWithArguments self should: [aBlockContext valueWithArguments: #(1 )] raise: Error. self shouldnt: [aBlockContext valueWithArguments: #()] raise: Error. [aBlockContext valueWithArguments: #(1 )] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 0 arguments, but was called with 1 argument.']. [[:i | 3 + 4] valueWithArguments: #(1 2)] ifError: [:err :rcvr | self assert: err = 'Error: This block accepts 1 argument, but was called with 2 arguments.']! !

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by StÃ©phane Ducasse

I released an archive with two images 10259 with tests run 10259-withClosure + john + lukas + my fixes so far so that we can go faster to fix the problems https://gforge.inria.fr/frs/?group_id=1299 and files Stef

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by StÃ©phane Ducasse

ok for now I patched that :) On Mar 23, 2009, at 11:56 AM, Henrik Johansen wrote: > My bad, meant Polymorph-EventEnhancements. > Some more details for those interested (hope I remember correctly this > time): > The two methods are needed if one wants to be able to use something as > argument for the evaluate part of Object when: #XYZ evaluate: myBlock, > due to ActionSequence implementation details... > For Polymorph, in the createXYZBoxFor: methods in the Vistary themes, > addUpAction: does just that with blocks, thus the methods are needed > for it. > > Cheers, > Henry > > Henrik Johansen wrote: >> http://code.google.com/p/pharo/issues/detail?id=337 >> >> I believe the resolution then was Gary moving the two methods to >> Polymorph-Overrides. >> Probably some house-cleaning which caused them to be lost this time. >> I still stand by my OR: suggestion from back then, isValid is a >> terrible >> method name, imo ;) >> >> Cheers, >> Henry >> >> Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> Adding #isValid got me a little further along. I was able to >>> select the new theme and can at least open a debugger, though >>> _using_ it stirs up trouble over #asMinimalRepresentation (or >>> similar method). In trying to evaluate 'hello' at:200, I was >>> faced with some message boxes claiming there was no such method; >>> that seemed to happen w/ vistary and not watery2??? I too had >>> problems closing windows. >>> >>> Bill >>> >>> --- >>> Wilhelm K. Schwab, Ph.D. >>> bschwab AT anest DOT ufl DOT edu >>> >>> -----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: Sunday, March 22, 2009 1:35 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Cc: Eliot Miranda >>> Subject: Re: [Pharo-project] [ANN] Closures for beta testers >>> >>> >>> >>>> UIThemeVistary beCurrent. >>>> >>>> >>> what is nice is that the VM does not crash. >>> I cannot open any browser. >>> So in another image I checked a bit. >>> >>> BlockContext defined isValid (a polymoprph-EventEnhancements) >>> >>> sent by >>> >>> BlockContext>>isValid >>> "Answer true so we can be used in event dispatching." >>> >>> ^true >>> >>> WeakActionSequence>>asMinimalRepresentation >>> >>> | valid | >>> valid := self select: [:e | e isValid ]. >>> valid size = 0 >>> ifTrue: [^nil]. >>> valid size = 1 >>> ifTrue: [^valid first]. >>> ^valid >>> >>> I do not really know the code of gary. >>> As a pure hack I added isValid to blockClosure to return true and >>> I did not get the problem >>> >>> of course this is a shitty way to answer the problem. >>> >>> >>> Now when I close using the cross on the right (and not the button >>> on the left) the vistaryStyle I get similar problems >>> >>> [closure] in UIThemeVistary>>createCloseBoxFor: DNU >>> asMinimalRepresentation >>> >>> >>> BlockContext>>asMinimalRepresentation >>> "Answer the receiver." >>> >>> ^self >>> >>> I defined the same in BlockClosure and it worked but I would >>> prefer to understand what I was doing. >>> >>> >>> >>> >>> stef >>> >>> >>> _______________________________________________ >>> 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 >

March 23, 2009

Re: [Pharo-project] Site slow?

by StÃ©phane Ducasse

not now at least. On Mar 23, 2009, at 11:55 AM, Michael Rueger wrote: > Hi all, > > the pharo site seems to be really slooow. > Anyone else seeing this? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by Henrik Johansen

My bad, meant Polymorph-EventEnhancements. Some more details for those interested (hope I remember correctly this time): The two methods are needed if one wants to be able to use something as argument for the evaluate part of Object when: #XYZ evaluate: myBlock, due to ActionSequence implementation details... For Polymorph, in the createXYZBoxFor: methods in the Vistary themes, addUpAction: does just that with blocks, thus the methods are needed for it. Cheers, Henry Henrik Johansen wrote: > http://code.google.com/p/pharo/issues/detail?id=337 > > I believe the resolution then was Gary moving the two methods to > Polymorph-Overrides. > Probably some house-cleaning which caused them to be lost this time. > I still stand by my OR: suggestion from back then, isValid is a terrible > method name, imo ;) > > Cheers, > Henry > > Schwab,Wilhelm K wrote: > >> Stef, >> >> Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows. >> >> Bill >> >> --- >> Wilhelm K. Schwab, Ph.D. >> bschwab AT anest DOT ufl DOT edu >> >> -----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: Sunday, March 22, 2009 1:35 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Cc: Eliot Miranda >> Subject: Re: [Pharo-project] [ANN] Closures for beta testers >> >> >> >>> UIThemeVistary beCurrent. >>> >>> >> what is nice is that the VM does not crash. >> I cannot open any browser. >> So in another image I checked a bit. >> >> BlockContext defined isValid (a polymoprph-EventEnhancements) >> >> sent by >> >> BlockContext>>isValid >> "Answer true so we can be used in event dispatching." >> >> ^true >> >> WeakActionSequence>>asMinimalRepresentation >> >> | valid | >> valid := self select: [:e | e isValid ]. >> valid size = 0 >> ifTrue: [^nil]. >> valid size = 1 >> ifTrue: [^valid first]. >> ^valid >> >> I do not really know the code of gary. >> As a pure hack I added isValid to blockClosure to return true and I did not get the problem >> >> of course this is a shitty way to answer the problem. >> >> >> Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems >> >> [closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation >> >> >> BlockContext>>asMinimalRepresentation >> "Answer the receiver." >> >> ^self >> >> I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing. >> >> >> >> >> stef >> >> >> _______________________________________________ >> 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 > > >

March 23, 2009

[Pharo-project] Site slow?

by Michael Rueger

Hi all, the pharo site seems to be really slooow. Anyone else seeing this? Michael

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by Henrik Johansen

http://code.google.com/p/pharo/issues/detail?id=337 I believe the resolution then was Gary moving the two methods to Polymorph-Overrides. Probably some house-cleaning which caused them to be lost this time. I still stand by my OR: suggestion from back then, isValid is a terrible method name, imo ;) Cheers, Henry Schwab,Wilhelm K wrote: > Stef, > > Adding #isValid got me a little further along. I was able to select the new theme and can at least open a debugger, though _using_ it stirs up trouble over #asMinimalRepresentation (or similar method). In trying to evaluate 'hello' at:200, I was faced with some message boxes claiming there was no such method; that seemed to happen w/ vistary and not watery2??? I too had problems closing windows. > > Bill > > --- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > -----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: Sunday, March 22, 2009 1:35 PM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Eliot Miranda > Subject: Re: [Pharo-project] [ANN] Closures for beta testers > > >> UIThemeVistary beCurrent. >> > > what is nice is that the VM does not crash. > I cannot open any browser. > So in another image I checked a bit. > > BlockContext defined isValid (a polymoprph-EventEnhancements) > > sent by > > BlockContext>>isValid > "Answer true so we can be used in event dispatching." > > ^true > > WeakActionSequence>>asMinimalRepresentation > > | valid | > valid := self select: [:e | e isValid ]. > valid size = 0 > ifTrue: [^nil]. > valid size = 1 > ifTrue: [^valid first]. > ^valid > > I do not really know the code of gary. > As a pure hack I added isValid to blockClosure to return true and I did not get the problem > > of course this is a shitty way to answer the problem. > > > Now when I close using the cross on the right (and not the button on the left) the vistaryStyle I get similar problems > > [closure] in UIThemeVistary>>createCloseBoxFor: DNU asMinimalRepresentation > > > BlockContext>>asMinimalRepresentation > "Answer the receiver." > > ^self > > I defined the same in BlockClosure and it worked but I would prefer to understand what I was doing. > > > > > stef > > > _______________________________________________ > 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 > > >

March 23, 2009

Re: [Pharo-project] Mickael system submission Slice merging problem

by StÃ©phane Ducasse

I do not know since we will have to created the packages and delete the working copy but probably. Stef On Mar 23, 2009, at 11:02 AM, Adrian Lienhard wrote: > > On Mar 21, 2009, at 14:11 , Michael Rueger wrote: > >> StÃ©phane Ducasse wrote: >>> Hi mike >>> >>> could you redo you system organization changes? >> >> I will take a look. >> All the slice should do is to exchange packaging, it is not supposed >> to >> change any code at all. If there have been changes in the meantime, I >> simply need to do re-packaging again. > > It seems, such changes (like moving a class between packages) are > simpler to handle with changesets. When we create a new update we > apply the cs without the need for merging with MC. > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Mickael system submission Slice merging problem

by Michael Rueger

Adrian Lienhard wrote: > It seems, such changes (like moving a class between packages) are > simpler to handle with changesets. When we create a new update we > apply the cs without the need for merging with MC. Even simpler with config maps. A config map could be used as a slice as well. Michael

March 23, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by StÃ©phane Ducasse

thanks for the clarification On Mar 23, 2009, at 10:31 AM, Henrik Johansen wrote: > Short answer: Yes. > Long answer: > The implementation in BorderedMorph was fixed in Polymorph-Overrides, > then that version was promoted to Morph, then BorderedMorph reverted > to > pre-Polymorph-Overrides functionality from the removeSelector: in my > cs. > So the "correct" thing to do would be to remove all versions of the > method from BorderedMorph, as it's former (correct) version is now > used > by Morph. > > Cheers, > Henry > > StÃ©phane Ducasse wrote: >> so henrik >> is is ok if I remove areasRemainingToFill: from BorderedMorph? >> >> Stef >> >> On Mar 19, 2009, at 1:46 PM, Henrik Johansen wrote: >> >> >>> I know, which is why I thought it was strange, the .cs contained: >>> !BorderedMorph removeSelector: #areasRemainingToFill:! >>> which when I file it in, results in no areasRemainingToFill: method >>> for >>> BorderedMorph in the image. >>> >>> I really have no idea how the update process makes it revert to an >>> older >>> version instead, nor how one would go about fixing it... :/ >>> >>> Cheers, >>> Henrik >>> >>> StÃ©phane Ducasse wrote: >>> >>>> henrik I just integrated the file you gave me. >>>> If you have a new version that fixes the problem I will do a new >>>> version. >>>> >>>> Stef >>>> >>>> On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: >>>> >>>> >>>>> It seems BorderedMorph's areasRemainingToFill: method got reverted >>>>> to >>>>> the version in use prior to the override by PolyMorph (which has >>>>> now >>>>> been promoted to Morph), instead of removed completely. >>>>> (This is the state my image is in after updating a released 248, >>>>> at >>>>> least) >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> StÃ©phane Ducasse wrote: >>>>> >>>>>> Issue 655: Overlapping Graphics on World do not Properly >>>>>> Repaint >>>>>> Issue 658: Preferences resetHaloSpecifications >>>>>> Issue 664: unimplemented errorCantGoBack >>>>>> Closed 665 >>>>>> >>>>>> now we will focus on the closures. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >> >> >> _______________________________________________ >> 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 >

March 23, 2009