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

[Pharo-project] [ANN] 10112 and 10113

by StÃ©phane Ducasse

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

Oct. 26, 2008

[Pharo-project] [ANN] 10111 etoyFriendly preference out....

by StÃ©phane Ducasse

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

Oct. 26, 2008

Re: [Pharo-project] changes file

by Lukas Renggli

> mcz seems to be a bit too cumbersom... they get very large very fast, and > then it's very slow > to unpack all of them. Monticello 2 is based on a file-format designed to handle this kind of functionality in a very time and space efficent manner. Monticello 2 is not integrated as a change-set replacement yet, but I guess this would be easy and give several other advantages such as simple merging. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 26, 2008

[Pharo-project] [update] 10110

by Marcus Denker

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

Oct. 26, 2008

[Pharo-project] About managing pharo submissions

by StÃ©phane Ducasse

hi guys We are analysing where we are loosing time. - we cannot script squeaksource to move package around - we cannot work on slice (ie taking into account dependencies to move packages). So we are thinking that may be we should not us pharoInbox but only get cs. What do you think? Stef

Oct. 26, 2008

[Pharo-project] Re: Bug with valueWithReceiver:arguments:

by Klaus D. Witzel

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

Oct. 26, 2008

[Pharo-project] Bug with valueWithReceiver:arguments:

by Frederic Pluquet

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

Oct. 26, 2008

Re: [Pharo-project] about MC browser changes

by Damien Pollet

This update breaks if you have MC windows open, because MCWorkingCopyBrowser doesn't initialize its order instvar lazily. On Sat, Oct 25, 2008 at 8:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > so I get it when I do updates -> 10106 > I retried from a 10104 I got your fixes. > > Stef > > On Oct 25, 2008, at 9:24 PM, Lukas Renggli wrote: > >> I am also talking about the sorting fixes. >> >> Lukas >> >> On 10/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> wait I was talking about your sorting menu. >>> Were you talking about the jf fixes? >>> >>> Stef >>> >>> On Oct 25, 2008, at 8:59 PM, Lukas Renggli wrote: >>> >>>> On Sat, Oct 25, 2008 at 8:41 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> 10106 contained your fix. >>>>> Ok excellent! This was a really cool addition. >>>> >>>> Wired. I loaded all updates but it was not there? So I loaded it >>>> manually. >>>> >>>> Anyway, if it is in now this is good. People should just make sure to >>>> close their Monticello Browser before pdating, otherwise there is a >>>> debugger coming up. >>>> >>>> Cheers, >>>> 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 >> >> _______________________________________________ >> 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 > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 26, 2008

[Pharo-project] [ann] new core image for #10107 online

by Marcus Denker

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

Oct. 26, 2008

Re: [Pharo-project] changes file

by Marcus Denker

On 22.10.2008, at 22:01, John M McIntosh wrote: > 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 > Yes, the changes file starts to bug me, too. Especially as we will hit the 32MB wall at some point. > 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? mcz seems to be a bit too cumbersom... they get very large very fast, and then it's very slow to unpack all of them. I think we should make a file-system based solution: the history browser should just look into a directort ClassName/methodName/ and then show all the files there (named by timestamp). Later one can even simply make a web-server based solution: http-get to a server for all the history. I love .changes as a changelog, this we should keep. But any release done (even the intermediate ones) should come with an empty log. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 26, 2008