October 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] changes file
by John M McIntosh Oct. 26, 2008

Oct. 26, 2008

I note I downloaded the current pharo image/changes for pushing out on the iPhone and noticed the changes was 10.5MB, but if I condense it becomes 4.2MB which is much easier to deal with if I include it in an iPhone.app I'm wondering here if you need to push out the changes with all the method versions in it, or should it be condenced first and rely on changes from MC to show the history of how the methods evolved? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

3 2

[Pharo-project] [update] 10110
by Marcus Denker Oct. 26, 2008

Oct. 26, 2008

Issue 284: add literalsDo: as deprecated method Issue 253: Mantis 6933 MultiByteFileStream upTo: does not work in binary mode Issue 252: Mantis 6812 cannot inspect a WeakSet -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

[Pharo-project] Re: Bug with valueWithReceiver:arguments:
by Klaus D. Witzel Oct. 26, 2008

Oct. 26, 2008

On Sun, 26 Oct 2008 13:39:04 +0100, Andreas Raab wrote: > Hi Frederic - > > Congrats! You found the first real VM bug in five years or so ;-) I'm > not completely sure what the problem is but there is obviously something > wrong here. It's easiest to recreate the problem by copying the #/ > method and simply do something like: > > SmallInteger>>foo: aNumber > "(SmallInteger>>#foo:) valueWithReceiver: 11 arguments: {2}" > <primitive: 10> > self halt. > aNumber isZero ifTrue: [^(ZeroDivide dividend: self) signal]. > (aNumber isMemberOf: SmallInteger) > ifTrue: [^(Fraction numerator: self denominator: aNumber) reduced] > ifFalse: [^super / aNumber] > > When you run this, you'll see that the debugger shows *two* frames with > SmallInteger>>foo: on them. Inspecting the "parent" frame will > eventually crash the system since it has a completely bogus stack > pointer (-1). > > It seems that in a failing primitive method we end up with a bogus > activation record in primitiveExecMethodWithArgs (removing the primitive > from the above makes it work fine). I'm somewhat at a loss here as to > what the problem might be given that the implementations of > primPerformWithArgs and primExecWithArgs are so similar but > interestingly, the equivalent: > > 11 perform: #foo: withArguments:{2}. > > works fine with or without the primitive. Somewhere there must be a > difference ... The difference can be this: #primitiveExecuteMethod is called as part of #primitiveResponse, and in turn calls #executeNewMethod which again does #primitiveResponse. If the latter does #primitiveFail, the now *two* activations of #primitiveResponse want to handle the situation - without knowing from each other. Perhaps #primitiveExecuteMethod should end with an explicit [ ... ^ self success: true] in its true-branch (this is just a thought, I have as yet not looked deeper). Besides: if #primitiveExecuteMethod would do its own #primitiveFail, it looks like its arguments are no longer on the stack. /Klaus > Cheers, > - Andreas > > Frederic Pluquet wrote: >> Hello, >> I found a fondamental bug in Squeak and Pharo. The next code >> 11 / 2 gives the fraction (11/2). It's correct. But the next code >> (SmallInteger>>#/) valueWithReceiver: 11 arguments: {2} >> gives 1 ! >> The problem is the method valueWithReceiver:arguements: is used hugely >> with method wrappers... >> After long time of debugging, I found a point to debug: this method >> don't have the good behavior with compiled methods having a primitive >> that fails and executes some code after (as in SmallInteger>>#/ method >> when the division don't give a whole integer). In fact, when I send >> this message, the vm executes normally the compiled method but, in >> place of returns simply the good result, seems to rerun the the >> compiled method with other arguments (completly wrong) and returns so a >> wrong result. >> For example, (SmallInteger>>#/) valueWithReceiver: 11 arguments: {2} >> has the following execution trace : >> 2 isZero >> | 2 = 0 >> | returns: false >> returns: false >> 2 isMemberOf: SmallInteger >> | 2 class >> | returns: SmallInteger >> | SmallInteger == SmallInteger >> | returns: true >> returns: true >> Fraction numerator: 101 denominator: 2 >> | Fraction new >> | | Fraction basicNew >> | | returns: a Fraction instance >> | | (a Fraction instance) initialize >> | | returns: a Fraction instance >> | returns: a Fraction instance >> | a Fraction instance setNumerator: 101 denominator: 2 >> | | 2 = 0 >> | | returns: false >> | | 101 asInteger >> | | returns: 101 >> | | 2 asInteger >> | | returns: 2 >> | | 2 abs >> | | | 2 < 0 >> | | | returns: false >> | | returns: 2 >> | | 2 < 0 >> | | returns: false >> | returns: (101/2) >> returns: (101/2) >> (101/2) reduced >> | 101 = 0 >> | returns: false >> | 101 gcd: 2 >> | | 101 = 0 >> | | returns: false >> | | 2 \\ 101 >> | | returns: 2 >> | | 2 = 0 >> | | returns: false >> | | 101 \\ 2 >> | | returns: 1 >> | | 1 = 0 >> | | returns: false >> | | 2 \\ 1 >> | | returns: 0 >> | | 0 = 0 >> | | returns: true >> | | 1 abs >> | | | 1 < 0 >> | | | returns: false >> | | returns: 1 >> | returns: 1 >> | 101 // 1 >> | returns: 101 >> | 2 // 1 >> | returns: 2 >> | 2 = 1 >> | returns: false >> | Fraction numerator: 101 denominator: 2 >> | | Fraction new >> | | | Fraction basicNew >> | | | returns: a Fraction instance >> | | | (a Fraction instance) initialize >> | | | returns: a Fraction instance >> | | returns: a Fraction instance >> | | (a Fraction instance) setNumerator: 101 denominator: 2 >> | | | 2 = 0 >> | | | returns: false >> | | | 101 asInteger >> | | | returns: 101 >> | | | 2 asInteger >> | | | returns: 2 >> | | | 2 abs >> | | | | 2 < 0 >> | | | | returns: false >> | | | returns: 2 >> | | | 2 < 0 >> | | | returns: false >> | | returns: (101/2) >> | returns: (101/2) >> returns: (101/2) >> 2 isZero >> | 2 = 0 >> | returns: false >> returns: false >> false isMemberOf: SmallInteger >> | false class >> | returns: False >> | False == SmallInteger >> | returns: false >> returns: false >> Please help me to fix this bug. I really need it works fine ! >> FrÃ©d >> -- FrÃ©dÃ©ric Pluquet >> UniversitÃ© Libre de Bruxelles (ULB) >> Assistant >> http://www.ulb.ac.be/di/fpluquet >> >> ------------------------------------------------------------------------ >> > > > -- âIf at first, the idea is not absurd, then there is no hope for itâ. Albert Einstein

1 0

[Pharo-project] Bug with valueWithReceiver:arguments:
by Frederic Pluquet Oct. 26, 2008

Oct. 26, 2008

Hello, I found a fondamental bug in Squeak and Pharo. The next code 11 / 2 gives the fraction (11/2). It's correct. But the next code (SmallInteger>>#/) valueWithReceiver: 11 arguments: {2} gives 1 ! The problem is the method valueWithReceiver:arguements: is used hugely with method wrappers... After long time of debugging, I found a point to debug: this method don't have the good behavior with compiled methods having a primitive that fails and executes some code after (as in SmallInteger>>#/ method when the division don't give a whole integer). In fact, when I send this message, the vm executes normally the compiled method but, in place of returns simply the good result, seems to rerun the the compiled method with other arguments (completly wrong) and returns so a wrong result. For example, (SmallInteger>>#/) valueWithReceiver: 11 arguments: {2} has the following execution trace : 2 isZero | 2 = 0 | returns: false returns: false 2 isMemberOf: SmallInteger | 2 class | returns: SmallInteger | SmallInteger == SmallInteger | returns: true returns: true Fraction numerator: 101 denominator: 2 | Fraction new | | Fraction basicNew | | returns: a Fraction instance | | (a Fraction instance) initialize | | returns: a Fraction instance | returns: a Fraction instance | a Fraction instance setNumerator: 101 denominator: 2 | | 2 = 0 | | returns: false | | 101 asInteger | | returns: 101 | | 2 asInteger | | returns: 2 | | 2 abs | | | 2 < 0 | | | returns: false | | returns: 2 | | 2 < 0 | | returns: false | returns: (101/2) returns: (101/2) (101/2) reduced | 101 = 0 | returns: false | 101 gcd: 2 | | 101 = 0 | | returns: false | | 2 \\ 101 | | returns: 2 | | 2 = 0 | | returns: false | | 101 \\ 2 | | returns: 1 | | 1 = 0 | | returns: false | | 2 \\ 1 | | returns: 0 | | 0 = 0 | | returns: true | | 1 abs | | | 1 < 0 | | | returns: false | | returns: 1 | returns: 1 | 101 // 1 | returns: 101 | 2 // 1 | returns: 2 | 2 = 1 | returns: false | Fraction numerator: 101 denominator: 2 | | Fraction new | | | Fraction basicNew | | | returns: a Fraction instance | | | (a Fraction instance) initialize | | | returns: a Fraction instance | | returns: a Fraction instance | | (a Fraction instance) setNumerator: 101 denominator: 2 | | | 2 = 0 | | | returns: false | | | 101 asInteger | | | returns: 101 | | | 2 asInteger | | | returns: 2 | | | 2 abs | | | | 2 < 0 | | | | returns: false | | | returns: 2 | | | 2 < 0 | | | returns: false | | returns: (101/2) | returns: (101/2) returns: (101/2) 2 isZero | 2 = 0 | returns: false returns: false false isMemberOf: SmallInteger | false class | returns: False | False == SmallInteger | returns: false returns: false Please help me to fix this bug. I really need it works fine ! FrÃ©d -- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet

1 0

[Pharo-project] about MC browser changes
by StÃ©phane Ducasse Oct. 26, 2008

Oct. 26, 2008

lukas I merged your changes to get the items sorted (really cool). Now I'm convinced that there was an initialization problems since even if I closed and reopened all the MC browsers I go array indices problems. Could you check 10106 and resubmit a fix if necessary? Stef

3 8

[Pharo-project] [ann] new core image for #10107 online
by Marcus Denker Oct. 26, 2008

Oct. 26, 2008

https://gforge.inria.fr/frs/download.php/10317/Pharo0.1Core-10107.zip -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

[Pharo-project] [ANN] 10107
by StÃ©phane Ducasse Oct. 25, 2008

Oct. 25, 2008

This provides a Fix and Test for String numArgs http://code.google.com/p/pharo/issues/detail?id=237 - Nicolas Cellier: Just a small improvment required to speed up a little number reading: rewrite a condition (a & b) as (a and: [b]). - Issue 275: TODO: remove OldSocket. Change HTTPSocket superclass from OldSimpleClientSocket to Socket. Reimplementing OldSocket protocol into Socket (some methods were missing). Changing CrLf variable access to (String crlf).

1 0

[Pharo-project] Installer in Pharo
by jannick.menanteau.gmail Oct. 25, 2008

Oct. 25, 2008

Hi all, I would like to understand the behavior of Installer, and for this I use http://installer.pbwiki.com/Installer. But when I execute the first exemple : squeakmap := Installer squeakmap. squeakmap install: 'DynamicBindings'. squeakmap open. "opens the squeak map loader gui" I have an error due to a nil value. Installer has no value for 'DynamicBindings'. I think it not find the package. So, I execute Installer squeakmap open. a window is opened but there is nothing in it. For information, it works on Squeak3.10.2. Is there anything to do in Pharo to make it work ? Jannik

3 4

Re: [Pharo-project] facetious Splitter
by Gary Chambers Oct. 25, 2008

Oct. 25, 2008

Ar, no problem. There's still lots of cruft in Morphic. Sometimes feel like starting from scratch again.... Will continue with evolution though. Starting to adapt window controls to the new possibilities garnered with CompositeFillStyles. FreeType could do with some performance optimisation though... Our target platforms (for business applications) have slow processors... Regards, Gary. ----- Original message ----- Hi gary We will integrate polymorph anyway. Now this was just for supportingÂ etoy removal effort. I will work on that once the inbox is empty. Stef > Aye, no problem. Splitters/grips was something in (now) PolymorphÂ > that was a bugger to fix... especially wrt window title area fontÂ > sizes. Was SO broken before :-) > > Regards, Gary. > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, October 25, 2008 4:28 PM > Subject: Re: [Pharo-project] facetious Splitter > > > I'm fixing that in 10104 probably. > > Stef > > On Oct 25, 2008, at 4:57 PM, Gary Chambers wrote: > >> Not to mention the reorganisations in SystemWindow... >> :-) >> >> Regards, Gary. >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr >> > >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, October 25, 2008 8:05 AM >> Subject: Re: [Pharo-project] facetious Splitter >> >> >>> Yes this is bug I introduced when removing etoy and that garyÂ >>> fixedÂ but I harvested part of the solution. >>> The problem was splitter used x and y of morphs and only them soÂ >>> gary replaced that with left right >>> but I should harvest bottomBoundary from UIEnhancements/Â >>> polymorphWidgets.latest >>> Now I got some problems to see what I have to extract exactly. IfÂ >>> you get a list that is working I would be happy. >>> >>> gary said >>> "More to the point... the overrides for bottomBoundary etc. areÂ Â >>> missing in >>> ProportionalSplitterMorph." >>> >>> >>> On Oct 25, 2008, at 12:44 AM, nicolas cellier wrote: >>> >>>> Recipe for a nice scrambling of layouts in Pharo 10102: >>>> >>>> open a FileList; >>>> single click the splitter above text; >>>> you should see an annoying mess in the pane layouts. >>>> >>>> This happens with some other tools (like FileContentsBrowser). >>>> Removing the list of files morph with the halos, I discovered aÂ Â >>>> hidden splitter under top buttons. >>>> You can see the mess in Pharo when acting on these two splitters. >>>> Note that 3.9 ad 3.10.2 images have the hidden splitter too, butÂ >>>> the splitters behaves better. >>>> So it has to be a Pharo change. >>>> Unfortunately morphs are hard to debug! >>>> It would probably be easier to trace recent Morphic changes. AnyÂ >>>> clue? >>>> >>>> Nicolas >>>> >>>> _______________________________________________ >>>> 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

2 1

Oct. 25, 2008

- CompilerTests added - Monticello cool lukas enh added (to be checked). - Random etoy cleans - regex valueOrUnwind fixes. Stef and Marcus sprinting and eating excellent french black chocolate and listening jazz while Damien is painting his futton upstair :)

1 0