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

Re: [Pharo-project] #traits

by Adrian Lienhard

Thanks, Damien, looks good. Adrian On Jan 6, 2009, at 11:28 , Damien Cassou wrote: > On Mon, Jan 5, 2009 at 9:50 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Damien, thanks for implementing this. I checked your submission, >> however, the last version, Traits-damiencassou.254, deletes classes >> like Trait from the system. Something went wrong there. Could you >> check again? > > Done. See the issue tracker. > > > Bye > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2009

Re: [Pharo-project] Next Issue ;-)

by Gary Chambers

That is normally a symptom of something updating the World morphs in a non-UI process. Morphs should only be changed from the UI process otherwise all kind of inconsistencies can happen. WorldState addDeferredUIMessage: can be used top safely perform actions but, for some applications, finer control is needed. We have developed Squeak applications that are of necessity multi-process driven and were forced to modify WorldState to allow (mutex based) synchronisation with the event loop, thus avoiding the issues. Regards, Gary. ----- Original Message ----- From: "Brian Brown" <brian(a)ablelinktech.com> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 05, 2009 10:26 PM Subject: [Pharo-project] Next Issue ;-) > I'm trying to load cryptography 1.1 from the Universe browser. > Everything seems to go well, and the dialog completes and exits. > Immediately following that, whenever the mouse moves over any morphs, > you get the below traceback. the ivars leftMorphs, enteredMorphs, and > overMorphs are all nil, but are being treated as collections... > > > UndefinedObject(Object)>>doesNotUnderstand: #includes: > MouseOverHandler>>noticeMouseOver:event: > HandMorph>>noticeMouseOver:event: > OBTextMorphWithShout(Morph)>>handleMouseOver: > MouseEvent>>sentTo: > OBTextMorphWithShout(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBTextMorphWithShout(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > TransformMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBPluggableTextMorphWithShout(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBGroupingMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > SystemWindow(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > PasteUpMorph(Morph)>>processEvent:using: > PasteUpMorph>>processEvent:using: > PasteUpMorph(Morph)>>processEvent: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > MouseOverHandler>>processMouseOver: > HandMorph>>handleEvent: > HandMorph>>processEvents > [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h > processEvents. ActiveHand := nil]} > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > PasteUpMorph>>doOneCycle > [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor > yield. false] whileFalse. nil]} > [] in BlockContext>>newProcess {[self value. Processor > terminateActive]} > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2009

Re: [Pharo-project] #traits

by Damien Cassou

On Mon, Jan 5, 2009 at 9:50 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Damien, thanks for implementing this. I checked your submission, > however, the last version, Traits-damiencassou.254, deletes classes > like Trait from the system. Something went wrong there. Could you > check again? Done. See the issue tracker. Bye -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 6, 2009

Re: [Pharo-project] Underscores question

by Gwenael Casaccio

On Tuesday 06 January 2009 09:54:56 Lukas Renggli wrote: > > This is not yet integrated > > I assume a change like that will affect many different places. Is > there a list of things that remain to be fixed (Debugger, > RefactoringBrowser, Method Finder, ...). > > Lukas Yes, I don't have the list but I will publish the list on the mailing list before any public release and off course I'll publish the fix. Gwenael

Jan. 6, 2009

Re: [Pharo-project] Collection extensions

by Lukas Renggli

> Yes can you make a list of the ones that are conflicting with other > implementations? Well, unfortunately these are all methods that are not specified in the ANSI standard. >>> Why can't we tag the methods with <notAnsi> and build a tool that >>> check when you do a fill out. >> >> The problem is that such message sends can't be reliably detected >> statically. > > I lost me here. I was commenting on the suggestion to check possible incompatibilities when saving a package. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 6, 2009

Re: [Pharo-project] Collection extensions

by StÃ©phane Ducasse

On Jan 6, 2009, at 9:45 AM, Oscar Nierstrasz wrote: > > Hi Folks, > > I recall some time ago discussing extensions like split: and join: for > OrderedCollections to better support string operations typically > supported in scripting languages. Maybe we need to take a deeper look > at how best to refresh the Collections framework in Pharo to modernize > it, yet without breaking the ANSI standard ... Yes. I would like that we move on this one too. > There are a lot of good suggestions here, but since Collections are > central to everything in Smalltalk, I think it would be wise if we > step back and consider how best to proceed. We started by writing tests tests and tests. The idea is to have a good coverage of the collections and identify also the problems. This is what we are currently doing. We are writing traits and composing them to reuse tests across multiple test case. If you want to join you can publish in the pharoInbox. I think that in the process we will then identify misplaced/to remove method > The issues appear to be: > > - stripping out obsolete junk > - conformance to ANSI standard > - traits refactoring > - useful String extensions (based on similar interfaces in perl, Ruby > etc.) > - other useful collection extension (ditto) > > Did I miss something? > > We can't do all of these at once, but we do need to make progress ... > What is the best way to go ahead? Right now looking at the trait tests we implemented and improve them (add more tests add new trait tests and use the trait tests to better cover the system). > > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 6, 2009

Re: [Pharo-project] Collection extensions

by StÃ©phane Ducasse

On Jan 6, 2009, at 8:04 AM, Lukas Renggli wrote: >> So why do we do pharo. Really. If everything as to be compatible with >> other smalltalk. Terrible. >> Can't we get smarter? > > You are right, this change does not harm anyone not using the method. > > We'll have to update our tests of methods not to be sent. > > Still, I would rather like to see methods removed from Collection > than added. Yes can you make a list of the ones that are conflicting with other implementations? >> Why can't we tag the methods with <notAnsi> and build a tool that >> check when you do a fill out. > > The problem is that such message sends can't be reliably detected > statically. I lost me here. Stef

Jan. 6, 2009

Re: [Pharo-project] Pharo Issues

by StÃ©phane Ducasse

Great! Thanks for the feedback. Stef On Jan 5, 2009, at 11:10 PM, Brian Brown wrote: > That worked as expected - I updated from a fresh 10196 image with no > problems. > > Thanks Stef! > > - Brian > > On Jan 5, 2009, at 2:16 PM, StÃ©phane Ducasse wrote: > >> I rolledback to the old version since it loaded for me when updating >> from 10191 (too long we should publish an image soon) >> Brian could you retry and let us know. I would be sure that the >> update >> works also with a dev image. >> Thanks >> >> >> On Jan 5, 2009, at 10:11 PM, StÃ©phane Ducasse wrote: >> >>> Adrian >>> >>> I just commited a new script280 (which remove the Sixx- >>> stephane_ducasse.2.mcz) >>> I'm wondering why we have a sixx package in pharo-core. To me this >>> is >>> at the minimum a dev dependency >>> I will retry to load scriptloader711 and rollback if necessary >>> >>> >>> >>> >>> On Jan 5, 2009, at 9:56 PM, Adrian Lienhard wrote: >>> >>>> Hi Brian, >>>> >>>> I checked and it worked for me. It looks like a network issue or >>>> SqueakSource not replying for a second. Could you try again and >>>> report >>>> back if the problem persists for you? I also suggest to delete the >>>> package-cache folder. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Jan 5, 2009, at 21:45 , Brian Brown wrote: >>>> >>>>> Greetings all, >>>>> >>>>> I download the latest image from the site (10196 dev), and >>>>> selected >>>>> "Software update" from the System Menu. There is an error with >>>>> update: >>>>> >>>>> 10201-Pha-FlapTabViewerObjectPassOneOverScriptSyst >>>>> >>>>> While it is in the "Adding Versions" step, we get an exception >>>>> trying >>>>> to read a stream on this file: Sixx-stephane_ducasse.2.mcz >>>>> >>>>> >>>>> Here is the traceback: >>>>> >>>>> UndefinedObject(Object)>>doesNotUnderstand: #readStream >>>>> MCScanner class>>scanTokens: >>>>> MCMczReader>>parseMember: >>>>> MCMczReader>>loadPackage >>>>> MCMczReader(MCVersionReader)>>package >>>>> MCMczReader(MCVersionReader)>>basicVersion >>>>> MCMczReader(MCVersionReader)>>version >>>>> [] in >>>>> MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >>>>> {[:r | r version]} >>>>> BlockContext>>valueWithPossibleArgs: >>>>> MCMczReader(ProtoObject)>>ifNotNil: >>>>> MCHttpRepository>>versionReaderForFileNamed:do: >>>>> MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >>>>> [] in ScriptLoader>>loadTogether:merge: {[:fn | loader >>>>> addVersion: >>>>> (self repository loadVersionFromFileNamed: fn)]} >>>>> [] in >>>>> OrderedCollection(SequenceableCollection)>>do:displayingProgress: >>>>> {[:each :i | bar value: i. aBlock value: each]} >>>>> OrderedCollection(SequenceableCollection)>>withIndexDo: >>>>> [] in >>>>> OrderedCollection(SequenceableCollection)>>do:displayingProgress: >>>>> {[:bar | self withIndexDo: [:each :i | bar value: i. >>>>> aBlock >>>>> value: e...]} >>>>> [] in ProgressInitiationException>>defaultAction {[result := >>>>> workBlock >>>>> value: progress]} >>>>> BlockContext>>ensure: >>>>> ProgressInitiationException>>defaultAction >>>>> UndefinedObject>>handleSignal: >>>>> MethodContext(ContextPart)>>handleSignal: >>>>> MethodContext(ContextPart)>>handleSignal: >>>>> ProgressInitiationException(Exception)>>signal >>>>> ProgressInitiationException>>display:at:from:to:during: >>>>> ProgressInitiationException class>>display:at:from:to:during: >>>>> ByteString(String)>>displayProgressAt:from:to:during: >>>>> OrderedCollection(SequenceableCollection)>>do:displayingProgress: >>>>> ScriptLoader>>loadTogether:merge: >>>>> ScriptLoader>>script280 >>>>> ScriptLoader>>update10201 >>>>> UndefinedObject>>DoIt >>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>>> Compiler class>>evaluate:for:notifying:logged: >>>>> Compiler class>>evaluate:for:logged: >>>>> Compiler class>>evaluate:logged: >>>>> [] in >>>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: >>>>> {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self >>>>> nextChunk l...]} >>>>> BlockContext>>on:do: >>>>> [] in >>>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: >>>>> {[:bar | [self atEnd] whileFalse: [bar value: self position. >>>>> self skipS...]} >>>>> [] in ProgressInitiationException>>defaultAction {[result := >>>>> workBlock >>>>> value: progress]} >>>>> BlockContext>>ensure: >>>>> ProgressInitiationException>>defaultAction >>>>> UndefinedObject>>handleSignal: >>>>> MethodContext(ContextPart)>>handleSignal: >>>>> ProgressInitiationException(Exception)>>signal >>>>> ProgressInitiationException>>display:at:from:to:during: >>>>> ProgressInitiationException class>>display:at:from:to:during: >>>>> ByteString(String)>>displayProgressAt:from:to:during: >>>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: >>>>> [] in ChangeSet class>>newChangesFromStream:named: {[newSet >>>>> ifNotNil: [(aStream respondsTo: #converter:) ifTrue: >>>>> [newStrea...]} >>>>> BlockContext>>ensure: >>>>> ChangeSet class>>newChangesFromStream:named: >>>>> [] in Utilities >>>>> class>>readServer:special:updatesThrough:saveLocally:updateImage: >>>>> {[:bar | [this := docQueue next. nextDoc := docQueue next. >>>>> nextDoc >>>>> = #fail...]} >>>>> [] in ProgressInitiationException>>defaultAction {[result := >>>>> workBlock >>>>> value: progress]} >>>>> BlockContext>>ensure: >>>>> ProgressInitiationException>>defaultAction >>>>> UndefinedObject>>handleSignal: >>>>> MethodContext(ContextPart)>>handleSignal: >>>>> ProgressInitiationException(Exception)>>signal >>>>> ProgressInitiationException>>display:at:from:to:during: >>>>> ProgressInitiationException class>>display:at:from:to:during: >>>>> ByteString(String)>>displayProgressAt:from:to:during: >>>>> [] in Utilities >>>>> class>>readServer:special:updatesThrough:saveLocally:updateImage: >>>>> {[urls := self newUpdatesOn: (serverList collect: >>>>> [:url | >>>>> url , 'up...]} >>>>> BlockContext>>ensure: >>>>> CursorWithMask(Cursor)>>showWhile: >>>>> Utilities >>>>> class>>readServer:special:updatesThrough:saveLocally:updateImage: >>>>> Utilities class>>readServerUpdatesThrough:saveLocally:updateImage: >>>>> Utilities class>>readServerUpdatesSaveLocally:updateImage: >>>>> Utilities class>>updateFromServer >>>>> TheWorldMenu>>doMenuItem:with: >>>>> [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >>>>> {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: >>>>> selector] ...]} >>>>> BlockContext>>ensure: >>>>> CursorWithMask(Cursor)>>showWhile: >>>>> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >>>>> ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: >>>>> ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: >>>>> MouseButtonEvent>>sentTo: >>>>> ToggleMenuItemMorph(Morph)>>handleEvent: >>>>> MorphicEventDispatcher>>dispatchDefault:with: >>>>> MorphicEventDispatcher>>dispatchEvent:with: >>>>> ToggleMenuItemMorph(Morph)>>processEvent:using: >>>>> MorphicEventDispatcher>>dispatchDefault:with: >>>>> MorphicEventDispatcher>>dispatchEvent:with: >>>>> MenuMorph(Morph)>>processEvent:using: >>>>> MenuMorph(Morph)>>processEvent: >>>>> MenuMorph>>handleFocusEvent: >>>>> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. >>>>> ActiveEvent := anEvent. result := focusHolder han...]} >>>>> [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} >>>>> BlockContext>>on:do: >>>>> PasteUpMorph>>becomeActiveDuring: >>>>> HandMorph>>sendFocusEvent:to:clear: >>>>> HandMorph>>sendEvent:focus:clear: >>>>> HandMorph>>sendMouseEvent: >>>>> HandMorph>>handleEvent: >>>>> HandMorph>>processEvents >>>>> [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h >>>>> processEvents. ActiveHand := nil]} >>>>> Array(SequenceableCollection)>>do: >>>>> WorldState>>handsDo: >>>>> WorldState>>doOneCycleNowFor: >>>>> WorldState>>doOneCycleFor: >>>>> PasteUpMorph>>doOneCycle >>>>> [] in Project class>>spawnNewProcess {[[World doOneCycle. >>>>> Processor >>>>> yield. false] whileFalse. nil]} >>>>> [] in BlockContext>>newProcess {[self value. Processor >>>>> terminateActive]} >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >

Jan. 6, 2009

Re: [Pharo-project] Underscores question

by Lukas Renggli

> This is not yet integrated I assume a change like that will affect many different places. Is there a list of things that remain to be fixed (Debugger, RefactoringBrowser, Method Finder, ...). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 6, 2009

Re: [Pharo-project] Underscores question

by Gwenael Casaccio

On Tuesday 06 January 2009 01:46:39 Bill Schwab wrote: > Gwenael, > > That is great, but I keep getting "Nothing more expected ->" in place > of the uderscore any time I try it. Am I doing something wrong, or is > it simply not yet integrated? > This is not yet integrated > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> mrgwen(a)gmail.com 1/5/2009 7:25:25 AM >>> > > On Sunday 04 January 2009 17:41:21 Bill Schwab wrote: > > Gwenael, > > > > Stef mentioned that you are working on a parser, in part to address > > problems with $_. At the risk of appearing impatient, do your goals > > include allowing the use of $_ in selector and class names? If so, > > is > > > it something simple that could appear soon, or is it involved and > > likely > > > to take a while? I have some external interfacing requirements that > > would be simplified if $_ were unconstrained. > > Hi Bill, > > You can put _ in selector and class names. There is only a problem > with _ when it is used instead of :=. > > Cheers, > Gwenael > > > Bill > > > > > > > > > > Wilhelm K. Schwab, Ph.D. > > University of Florida > > Department of Anesthesiology > > PO Box 100254 > > Gainesville, FL 32610-0254 > > > > Email: bschwab(a)anest.ufl.edu > > Tel: (352) 273-6785 > > FAX: (352) 392-7029 > > > > > > _______________________________________________ > > 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

Jan. 6, 2009