- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update] 10114

by StÃ©phane Ducasse

no something that noury wrote to create class on the fly and remove them may be a duplicate :( Stef On Oct 26, 2008, at 6:52 PM, Keith Hodges wrote: > Marcus Denker wrote: >> - Issue 274: TwoWayScrollPane shoud be removed >> - Issue 291: SystemNavigation tests + reimplementation for queries >> on sent and unsent messages >> - Issue 290: SUnit Enhancement to ease writing tests involving the >> creation of classes >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker > Is 290 my ClassClonerTestResource? > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2008

[Pharo-project] Re: facetious Splitter

by nicolas cellier

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > 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 > OK far better behavior in 10114! However, in FileList, the directory list/file list splitter can go too far left: It is obscuring the splitter It can also go too far right, pushing file list outside window bounds. I also detected a ( collect: []) max which could be written ( detectMax: []). (browse leftBoundary and consor) Nicolas

Oct. 26, 2008

Re: [Pharo-project] [update] 10114

by Keith Hodges

Marcus Denker wrote: > - Issue 274: TwoWayScrollPane shoud be removed > - Issue 291: SystemNavigation tests + reimplementation for queries > on sent and unsent messages > - Issue 290: SUnit Enhancement to ease writing tests involving the > creation of classes > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker Is 290 my ClassClonerTestResource? Keith

Oct. 26, 2008

[Pharo-project] [update] 10114

by Marcus Denker

- Issue 274: TwoWayScrollPane shoud be removed - Issue 291: SystemNavigation tests + reimplementation for queries on sent and unsent messages - Issue 290: SUnit Enhancement to ease writing tests involving the creation of classes -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 26, 2008

[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