February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Alexandre Bergel

> > I am highly skeptical about LPF. Sorry if I missed some emails. What is LPF? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Marcus Denker

On 22.02.2009, at 19:04, Keith Hodges wrote: > Marcus Denker wrote: >> On 21.02.2009, at 18:31, Damien Cassou wrote: >> >> >>> Hi, >>> >>> is there a way to get the #ifNotNilDo: behavior to write compatible >>> Squeak and Pharo code? >>> >>> >> >> -> do not use ifNotNilDo: >> -> use ifNotNil: without the argument. >> >> The real fix of course would be for Squeak adopting the optinal args >> changeset >> (this is from 2007...) >> >> Marcus >> > ok, we shall add that to LPF, where is it? > http://bugs.squeak.org/view.php?id=6426 The solution is to adopt vasilie's fix: http://blog.3plus4.org/2007/04/22/notnil-then-what/ > > What would help though is if you told us what you are changing/ > breaking > so that we can do something about it. The Author class is another > incompatibility issue that I expect to have to address via LPF. Are > there any more? Thousands. Literally. I am highly skeptical about LPF. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 22, 2009

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Keith Hodges

Marcus Denker wrote: > On 21.02.2009, at 18:31, Damien Cassou wrote: > > >> Hi, >> >> is there a way to get the #ifNotNilDo: behavior to write compatible >> Squeak and Pharo code? >> >> > > -> do not use ifNotNilDo: > -> use ifNotNil: without the argument. > > The real fix of course would be for Squeak adopting the optinal args > changeset > (this is from 2007...) > > Marcus > ok, we shall add that to LPF, where is it? You see the purpose of LPF is to be able to make these changes in such a way as to liberate pioneers such as yourselves to move forward. We can offer this fix to the majority of squeak users, and this preserves the backward compatability, in a forward thinking way. What would help though is if you told us what you are changing/breaking so that we can do something about it. The Author class is another incompatibility issue that I expect to have to address via LPF. Are there any more? cheers Keith

Feb. 22, 2009

Re: [Pharo-project] Deleting Mantis Pharo project

by Keith Hodges

Adrian Lienhard wrote: > I just noticed, that in the Squeak Mantis bug tacker there is a > project called Pharo. This should be deleted to avoid confusion. Does > anybody know who to contact? > > Adrian > > I will ask to get that sorted Keith

Feb. 22, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Bruce O'Neel

Hi, Ah, very nice. Thanks! cheers bruce On Sun, Feb 22, 2009 at 09:16:41AM -0500, David T. Lewis wrote: > On Sun, Feb 22, 2009 at 01:47:40PM +0100, Bruce O'Neel wrote: > > > > I downloaded Ian's image/changes bundle named unix-3.10-4.vmm.tar.gz from http://www.squeakvm.org/unix/ > > and looked into it a bit. > > > > In ObjectMemory biasToGrow it looks like the problem is > > > > biasToGrow > > | growSize | > > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) > > self growObjectMemory: growSize > > > > there are no '.'s after the lines. Shouldn't it look like: > > > > biasToGrow > > | growSize | > > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock). > > self growObjectMemory: growSize. > > > > that? > > > > It looks like the slang interpreter/translater must be coughing a bit on what is basically > > slight invalid syntax, right? > > This is http://bugs.squeak.org/view.php?id=6667. The fix was applied to VMMaker-tpr.63. > You are probably using sources generated from VMMaker 3.8b6, which is the same as > VMMaker-tpr.58, so the sources you are using would not have this fix. > > If someone can build a VM using more up to date VMMaker and verify that the problem > goes away, that would be good. I suggest using VMMaker-dtl.113 from the VMMaker > project on SqueakSource for this. (Note, there is a more recent VMMaker-eem.114 that > contains Eliot's updates for block closures, but you may have trouble loading it > into some Squeak/Pharo images. The glitch may be sorted out by the time you read > this, if not just stick with VMMaker-dtl.113 or earlier for now.) > > > > > I guess that next up I have to figure out how to actually run vm maker :-) > > > > Yes :) > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Gary Chambers

Thanks Markus... glad people like it. As Igor suggests, dropShadow handling in Canvas and HandMorph would be better located elsewhere to make things cleaner. Now, if only I had the time to redo Morphic layout behaviour to work accurately... Regards, Gary ----- Original Message ----- From: "Marcus Denker" <denker(a)iam.unibe.ch> To: "Pharo Mailing List" <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:15 PM Subject: [Pharo-project] Shadow in Watery2 > Gary, > > Watery2 looks better and better :-) Great! > > One question regarding the shadow: Now the active window has > a translucent shadow (like macos), very nice. > > But it's turned off and replaced with the hard non-translucend > Morphic shadow while moving the window. > Would it be possible to render the same shadow, even wen picking > up windows? This would result in a much smoother apperance, and I > think it even would feel faster. > > Marcus > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by Rob Rothwell

Wow. I bow to the depths of the Squeak neural connections that must be going on in your brain... I can only seem to find stuff like that in procedural languages when I don't know the system at all. Anyway, you are right! All I did was recompile PluggableTextMorph>>drawOn: and Smallalk condenseChanges ran to completion. I'm not quite sure how to test the Trait problems mentioned at the beginning of the thread to see if they are fixed by this, though... Rob On Sun, Feb 22, 2009 at 9:25 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Found it... > > PositionableStream>>#backChunk chokes on parsing the preamble of > PluggableTextMorph>>#drawOn:. String>>#asCharacter is the method that > comes just before #drawOn: in the changes file: > > ---------- > !String methodsFor: 'converting' stamp: 'marcus.denker 2/20/2009 > 20:16' prior: 31206904! > asCharacter > "Answer the receiver's first character, or a strange round non-ascii > character if none. Idiosyncratic, provisional." > > ^ self size > 0 ifTrue: [self first] ifFalse:[$Â·]! ! > !PluggableTextMorph methodsFor: 'drawing' stamp: 'marcus.denker > 2/20/2009 16:30' prior: 27409324! > drawOn: aCanvas > ---------- > > When parsing #asCharacter, the UTF8 encoder fails with an > errorMalformedInput because it seems to read back to the strange dot > character. > > The question is whether this character should not be used, or whether > parsing is bogus. Looking at #backChunk and related methods, latter > seems possible. Looks a bit fishy with sends to #oldBack, > #oldPeekBack, but also to #back. Damien, can you verify your changes > in these methods? > > As a workaround recompiling PluggableTextMorph>>#drawOn: solves the > problem (because then the source position of this method is moved away > from the asCharacter method). > > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > On Feb 22, 2009, at 14:18 , Adrian Lienhard wrote: > > > I'm debugging it right now. > > > > What you see are only secondary symptoms because the debugger cannot > > read the sources anymore because the source pointers have already > > been modified but the sources file is still the old one... > > > > To avoid this and still see the problem, modify #moveChangesTo: to > > not move the source (moveSource: false). > > > > The actual problem seems to be related to UTF8 conversion or stream > > positioning (UTF8TextConverter>>errorMalformedInput). Backlog > > attached. > > > > Adrian > > > > <SqueakDebug.log> > > > > On Feb 22, 2009, at 14:00 , StÃ©phane Ducasse wrote: > > > >> I added a trace in condenseChanges > >> > >> > >> PluggableTabBarMorph > >> PluggableTabButtonMorph > >> PluggableTextAttribute > >> PluggableTextEditorMorph > >> PluggableTextFieldMorph > >> PluggableTextMorph > >> (and is Undeclared) (See is Undeclared) (Unless is Undeclared) > >> (works is Undeclared) (Portions is Undeclared) (Copyright is > >> Undeclared) > >> > >> > >> > >> Stef > >> > >> On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > >> > >>> I tried > >>> - to recompile the method licenseString on Smalltalk > >>> - remove it completely from the system > >>> > >>> I still get the same problem > >>> > >>> Stef > >>> > >>> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > >>> > >>>> Adrian in 10241 when i did Smalltalk condenseChanges > >>>> > >>>> I got a ClassDescription > >>>> > >>>> syntax error on the license > >>>> > >>>> > >>>> " > >>>> use and modification subject to a liberal open source license. See > >>>> the main Squeak website for details. Unless stated to the > >>>> contrary, > >>>> works submitted for incorporation into or for distribution with > >>>> Squeak > >>>> shall be presumed subject to the same license. > >>>> > >>>> Portions of Squeak are: > >>>> > >>>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. > >>>> Copyright (c) 1997-2001 Walt Disney Company, and/or > >>>> Copyrighted works of many other contributors. > >>>> All rights reserved. > >>>> ' > >>>> > >>>> " > >>>> > >>>> I think that fixing the condensing is the next key items since > >>>> now we > >>>> cannot work with Moose anymore. The changeset is getting too > >>>> close to > >>>> the limit. > >>>> > >>>> Stef > >>>> > >>>> > >>>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: > >>>> > >>>>> #10241 > >>>>> > >>>>> Issue 167: > >>>>> - Traits implementation refactoring (no sharing of compiled > >>>>> methods > >>>>> and source) > >>>>> - New tests for Traits MOP > >>>>> > >>>>> > >>>>> Since this changes the handling of sources, the following issues > >>>>> with > >>>>> condensing changes may be resolved: > >>>>> http://code.google.com/p/pharo/issues/detail?id=466 > >>>>> http://code.google.com/p/pharo/issues/detail?id=470 > >>>>> > >>>>> Can somebody check these issues? > >>>>> > >>>>> Adrian > >>>>> ___________________ > >>>>> http://www.adrian-lienhard.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 > >>>> > >>> > >>> > >>> _______________________________________________ > >>> 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 >

Feb. 22, 2009

[Pharo-project] suggestion for the category chooser

by StÃ©phane Ducasse

Hi I think that the category chooser could be improved to avoid to have to type twice the category. Right now if I want to create a category I have to know up front whether it exist or not then I have to select new if it does not else if naively I type the new cat the ui tells me well that it is not defined but in such a case I have to retype it. The solution could be remove the fact that for new category we have to press new... when the user enter the category whether it matches or not return the string that the user entered modulo with its matched string in the list. This way as a user I do not have to choose upfront. I want to create a cat I either select on the list or I type and there is one which I can select or I type and there is none in the list so we get a new one the I typed. Stef

Feb. 22, 2009

[Pharo-project] Deleting Mantis Pharo project

by Adrian Lienhard

I just noticed, that in the Squeak Mantis bug tacker there is a project called Pharo. This should be deleted to avoid confusion. Does anybody know who to contact? Adrian ___________________ http://www.adrian-lienhard.ch/

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by Adrian Lienhard

Found it... PositionableStream>>#backChunk chokes on parsing the preamble of PluggableTextMorph>>#drawOn:. String>>#asCharacter is the method that comes just before #drawOn: in the changes file: ---------- !String methodsFor: 'converting' stamp: 'marcus.denker 2/20/2009 20:16' prior: 31206904! asCharacter "Answer the receiver's first character, or a strange round non-ascii character if none. Idiosyncratic, provisional." ^ self size > 0 ifTrue: [self first] ifFalse:[$Â·]! ! !PluggableTextMorph methodsFor: 'drawing' stamp: 'marcus.denker 2/20/2009 16:30' prior: 27409324! drawOn: aCanvas ---------- When parsing #asCharacter, the UTF8 encoder fails with an errorMalformedInput because it seems to read back to the strange dot character. The question is whether this character should not be used, or whether parsing is bogus. Looking at #backChunk and related methods, latter seems possible. Looks a bit fishy with sends to #oldBack, #oldPeekBack, but also to #back. Damien, can you verify your changes in these methods? As a workaround recompiling PluggableTextMorph>>#drawOn: solves the problem (because then the source position of this method is moved away from the asCharacter method). Adrian ___________________ http://www.adrian-lienhard.ch/ On Feb 22, 2009, at 14:18 , Adrian Lienhard wrote: > I'm debugging it right now. > > What you see are only secondary symptoms because the debugger cannot > read the sources anymore because the source pointers have already > been modified but the sources file is still the old one... > > To avoid this and still see the problem, modify #moveChangesTo: to > not move the source (moveSource: false). > > The actual problem seems to be related to UTF8 conversion or stream > positioning (UTF8TextConverter>>errorMalformedInput). Backlog > attached. > > Adrian > > <SqueakDebug.log> > > On Feb 22, 2009, at 14:00 , StÃ©phane Ducasse wrote: > >> I added a trace in condenseChanges >> >> >> PluggableTabBarMorph >> PluggableTabButtonMorph >> PluggableTextAttribute >> PluggableTextEditorMorph >> PluggableTextFieldMorph >> PluggableTextMorph >> (and is Undeclared) (See is Undeclared) (Unless is Undeclared) >> (works is Undeclared) (Portions is Undeclared) (Copyright is >> Undeclared) >> >> >> >> Stef >> >> On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: >> >>> I tried >>> - to recompile the method licenseString on Smalltalk >>> - remove it completely from the system >>> >>> I still get the same problem >>> >>> Stef >>> >>> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: >>> >>>> Adrian in 10241 when i did Smalltalk condenseChanges >>>> >>>> I got a ClassDescription >>>> >>>> syntax error on the license >>>> >>>> >>>> " >>>> use and modification subject to a liberal open source license. See >>>> the main Squeak website for details. Unless stated to the >>>> contrary, >>>> works submitted for incorporation into or for distribution with >>>> Squeak >>>> shall be presumed subject to the same license. >>>> >>>> Portions of Squeak are: >>>> >>>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >>>> Copyright (c) 1997-2001 Walt Disney Company, and/or >>>> Copyrighted works of many other contributors. >>>> All rights reserved. >>>> ' >>>> >>>> " >>>> >>>> I think that fixing the condensing is the next key items since >>>> now we >>>> cannot work with Moose anymore. The changeset is getting too >>>> close to >>>> the limit. >>>> >>>> Stef >>>> >>>> >>>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >>>> >>>>> #10241 >>>>> >>>>> Issue 167: >>>>> - Traits implementation refactoring (no sharing of compiled >>>>> methods >>>>> and source) >>>>> - New tests for Traits MOP >>>>> >>>>> >>>>> Since this changes the handling of sources, the following issues >>>>> with >>>>> condensing changes may be resolved: >>>>> http://code.google.com/p/pharo/issues/detail?id=466 >>>>> http://code.google.com/p/pharo/issues/detail?id=470 >>>>> >>>>> Can somebody check these issues? >>>>> >>>>> Adrian >>>>> ___________________ >>>>> http://www.adrian-lienhard.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 >>>> >>> >>> >>> _______________________________________________ >>> 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

Feb. 22, 2009