- Pharo-dev - lists.pharo.org

[Pharo-project] facetious Splitter
by nicolas cellier Oct. 26, 2008

Oct. 26, 2008

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

3 6

[Pharo-project] [ANN] 10112 and 10113
by StÃ©phane Ducasse Oct. 26, 2008

Oct. 26, 2008

10112 - deprecated hasLiteralThrou.... 10114 - FileDirectory etoy clean ups - Project/ThreadNavigation removed some methods.

1 0

[Pharo-project] [ANN] 10111 etoyFriendly preference out....
by StÃ©phane Ducasse Oct. 26, 2008

Oct. 26, 2008

- Debugger etoy removal - remove etoyFriendly preference - red/green for conflicts in MC (damien Pollet)

1 0

[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

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

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