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

Re: [Pharo-project] FileList fix

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > I will intergate that as soon as there is negative feedback. FileBrowser can't be opened with last prebuild #10218 Cheers Alain > > > Stef > > On Feb 2, 2009, at 10:06 PM, Alain Plantec wrote: > >> Hi all, >> File list seems to be broken by last updates (was not in 10204). >> (FileList>>morphicPatternPane is lost) >> Polymorph-Widgets-alain_plantec.41 is in PharoInbox >> Alain >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >

Feb. 5, 2009

[Pharo-project] [ANN] prebuild #10218

by Marcus Denker

https://gforge.inria.fr/frs/download.php/16779/Pharo0.1Core-10218.zip ChangeLOG: ---------- update10205 - New Diff Tools - More collection tests - Collections Packages ------------------------------------------------------ update10206 Deleting Collection Package ------------------------------------------------------ update10207 -New collection Tests ------------------------------------------------------ update10208 - Enh Tool diff. - Issue 444: Simple Morphic cleanup: Clean up Morph Remove ownerThatIsA:orA: from Morph. - more collection tests. - Issue 445: AligmentMorphBob1 should be merged into AligmentMorph - Minor cleaning of Bergel on StringHolder ------------------------------------------------------ update10209 WatchIt integration Issue 440: Watch-it extension ------------------------------------------------------ update10210 - Damien Cassou more tests - Lukas Renggli Browse class in Sunit Browser ------------------------------------------------------ update10211 Polymoprh fixes ------------------------------------------------------ update10212 - Watchit window - DropListMorph button tweaks. Fix for repeated confirmation with DualChangeSorter. Adapt text labels for PluggableButtonMorphs on theme change. + Watery2 now supports mixed corner styles for buttons. Fixes for drop lists and expanders to honour corner rounding. Fix for RowLayout when cellInset is a Point as opposed to Integer. - Added history to Workspace. When you close a workspace now you will not be bothered with a popup window asking you whether you sure you want to close the window. In the workspace you have access to the historic of the last 5 previous contents.. - Collectiontests ------------------------------------------------------ update10213 - 002 classFromPattern move from Utilities to SystemNavigation - Issue 56: 7106 CollectionEnh (M6350 M6351) Mantis http://bugs.squeak.org/view.php?id=6350 WriteStream>>ensureEndsWith:, ensureASpace by Damien Cassou http://bugs.squeak.org/view.php?id=6351 String space + tests space - SmallDictionary capacity This is a patch for http://bugs.squeak.org/view.php?id=7256 ------------------------------------------------------ update10214 - More collection tests - SUnit coverage improved - allSelectorsAbove, allSelectorUntil:, allSuperclassesIncluding: - polymorphWidgets ------------------------------------------------------ update10215 - Object Class uniclass support - Less Player references - UnscriptedPlayer removed - RemoveDemandsThumbnail protocol - Remove ScriptableButton - Remove StackMorph ------------------------------------------------------ update10216 - ClassBuilder fix for http://code.google.com/p/pharo/issues/detail?id=443 - Fix ClassBuilder bug introduced by http://code.google.com/p/pharo/issues/detail?id=246 - Adds TPureBehavior>>withAllSubclassesDo: to provide polymorphism between classes and traits ------------------------------------------------------ update10217 Polymorph Small tweak to drop-list/expander up/down arrow. #taskbarLabel available to SystemWindow subclasses and models to provide potentially abbreviated label. PreferenceBrowser integration classes moved to Theme sub-package. Tweaks to Preference Browser. Cmd+W (in addition to Cmd+Delete) now closes system window with focus. #ByteArray support - literal byte arrays are now also parsed as part of a literal array without the hash #( [ 1 2 ] #[ 1 2 ] ) - hardened the tests - added support for literal byte arrays to the compiler - the implementation is compatible with GST and VW - added 6 tests for the new functionality - storeOn: + printOn: fixed #[1 2 3 ] -> #[1 2 3] but for now we have a bug #(1 #[2] 3) an Array(1 #[2] 3) ------------------------------------------------------ update10218 bytearray isLiteral -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 5, 2009

Re: [Pharo-project] About Preference Flow: was Re:MonticelloChangesDialog

by Gary Chambers

See Preference>>preferenceValue: (that is what happens when a preference is changed). This sends notifyInformeeOfChange which can perform a zero argument selector on the "model" object/class which then eventually has to query Preferences for the value. See senders of, for instance, #addPreference:categories:default:balloonHelp:projectLocal:changeInformee:changeSelector:viewRegistry: and their associated changeSelectors. This is how things are at the moment. Lukas' idea about pragmas is nice, essentially the same as a discovery interface. Either way the PreferenceBrowser would need changing. Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 8:55 PM Subject: Re: [Pharo-project] About Preference Flow: was Re:MonticelloChangesDialog Sorry gary you lost me. I do not get change informee. On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote: > Looking at the changeInformee code in Preferences/Preference, the > informee > still has to query the preference > to pick up any changes as it stands... If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference). Stef > > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, February 04, 2009 2:50 PM > Subject: Re: [Pharo-project] About Preference Flow: was Re: > MonticelloChangesDialog > > > > On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: > >> Ceratainly possible. You'd want a discovery mechanism for a new >> Preference >> Browser also, otherwise who would know what the preferences are. > > no because you still define the preference in the Preference class > it just pushes the right value in MyTool and MyTool does not have to > query Preference > at runtime. > >> The method flow would still be similar, unless you had some >> redirection to >> alternate classes or methods or blocks... > > No. We use the preference when we select it. Then MyTool uses what has > been pushed > to it. and in particular it does not query at runtime preference. > So Preference becomes a removal layer on top of the system and not > something > referenced by every method flow. > >> So, in new scheme (no dependency on Preferences) the doSomething >> might be: >> >> self class shouldUseNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] > > Yes in mytool I deal the way I want about my preference since they are > local to me. > I do not involve preference. Preference is just a handy facade > grouping all the preferences > and an entry point to set the preferences in the tools. > >> >> >> and >> MyTool class>>preferences >> >> would answer something suitable for a preference browser. > > Could be but the package could also install the preferences in the > preferences class > > Stef >> >> >> Regards, Gary. >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, February 04, 2009 7:58 AM >> Subject: [Pharo-project] About Preference Flow: was Re: Monticello >> ChangesDialog >> >> >>> Gary >>> >>> I have a request about the way we use preference. And this is kind >>> of >>> really really important if we want to >>> stop having spaghetti code. >>> >>> Instead of having the current situation ie >>> >>> MyTool>>doSomething >>> >>> .... >>> Preferences useNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >>> >>> >>> and not been able to remove the preferences (or that the preference >>> is >>> just a configuration layer). >>> >>> I would like to have the preference made that way >>> >>> MyTool class>>useNewDiff >>> >>> MyTool class>> useOldDiff >>> >>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>> >>> >>> Preferences useNewDiffTool >>> MyTool useNewDiff >>> >>> I really think that we can do it that way and this way we would >>> have a >>> much more object-oriented system >>> Do you think that this is possible with polymorph? >>> I think so. >>> >>> Stef >>> >>> _______________________________________________ >>> 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. 5, 2009

Re: [Pharo-project] [ANN] Pier 1.1

by StÃ©phane Ducasse

Neat :) Stef On Feb 5, 2009, at 1:11 AM, Tudor Girba wrote: > Hi, > > Release 1.1 of Pier is now available: > www.piercms.com/install > > What's new: > - Several bug fixes > - New syntax constructs > - New and whiter stylesheet > - Pharo inside > > www.piercms.com also received a face lift, and it got some new > documentation. > > Have fun and tell us what you think. > > Doru and Lukas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 5, 2009

[Pharo-project] [ANN] Pier 1.1

by Torsten Bergmann

Time to vote: http://www.dzone.com/links/pier_cms_11_released.html Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Feb. 5, 2009

Re: [Pharo-project] A step by step tutorial about Traits

by Damien Cassou

On Wed, Feb 4, 2009 at 8:10 PM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: > Damien, your document is 35pp, I don't have time to read it > now. Just read section 3. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 5, 2009

Re: [Pharo-project] Seaside?

by Keith Hodges

Lukas Renggli wrote: >>> If you want Seaside 2.9 you should use <http://builder.seaside.st/>. >>> >> Yes - but the builder ONLY allows to create a script for an ALPHA >> release (Seaside 2.9.0-alpha2). >> > > Yes. > > >> The script in ScriptLoader always loaded the NEWEST packages >> so people, who want to help extending and fixing Seaside could >> easily load it. It should also make sure that the latest "hot" >> Seaside stuff is working in Pharo. >> > > This cannot work: > > 1. Installer initializes packages in random order. > What do you mean? Keith

Feb. 5, 2009

[Pharo-project] [ANN] Pier 1.1

by Tudor Girba

Hi, Release 1.1 of Pier is now available: www.piercms.com/install What's new: - Several bug fixes - New syntax constructs - New and whiter stylesheet - Pharo inside www.piercms.com also received a face lift, and it got some new documentation. Have fun and tell us what you think. Doru and Lukas

Feb. 5, 2009

Re: [Pharo-project] Renaming instance variable

by StÃ©phane Ducasse

Thanks! Stef On Feb 4, 2009, at 9:24 PM, David RÃ¶thlisberger wrote: > > >> The problem is that when you code in the core then you should not >> have >> the other packages loaded >> or they should saved in the pharo repository. >> >> Damien could you modify the scriptloader to use the universe to >> load RB? > > I modified it. > > The reason why this method exists is that people can use it to test > latest > experimental features committed to OB (that's why it's named > 'Alpha') that are not > (yet) available in Universe. > I changed the script to load everything from Universe except all OB > packages. > I think that should be fair enough. > > The adapted ScriptLoader is in PharoInbox. > (I also adapted #loadSuperOB ...). > > > David > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 4, 2009

Re: [Pharo-project] A step by step tutorial about Traits

by StÃ©phane Ducasse

Hilaire have a look at CollectionsTest there are really simple example of traits. In 5 minutes you should get that: You have a trait TRemoveTest Trait named: #TRemoveTest uses: {} category: 'CollectionsTests-Abstract' easy TRemoveTest>>testRemoveElementFromEmpty "self debug: #testRemoveElementFromEmpty" self should: [self empty remove: self nonEmpty anyOne] raise: Error Easy self empty is undefined and it will return an empty collection self nonEmpty and nonEmpty one testRemoveElementThatExists "self debug: #testRemoveElementThatExists" | el res | el := self nonEmpty anyOne. self shouldnt: [res := self nonEmpty remove: el ] raise: Error. self assert: res == el testRemoveElementReallyRemovesElement "self debug: #testRemoveElementReallyRemovesElement" | size | size := self nonEmpty size. self nonEmpty remove: self nonEmpty anyOne. self assert: (size -1) = self nonEmpty size OK now you use the trait in a class For example Object subclass: #MySetTest uses: TRemoveTest instanceVariableNames: 'full empty You define setUp full := Set new add: 5 ; add: 6 ;yourself empty := Set new. nonEmpty ^ full empty ^ empty This is it!!!!! You can reuse your traits in another Test. Now if you do not like a trait method you can remove it or redefine it in your class DONE!!! Stef

Feb. 4, 2009