- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Download not working

by Michael Rueger

P.S. it also seems the one-click isn't linked directly from the Pharo site? Michael

Feb. 5, 2009

[Pharo-project] Download not working

by Michael Rueger

Hi all, when I click on any of the download links I get an error (Firefox on Windows and Ubuntu) Secure Connection Failed gforge.inria.fr uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Is it just me? Michael

Feb. 5, 2009

[Pharo-project] [ANN] 20219

by StÃ©phane Ducasse

- File list fix - Preference for Diff - PopUpMenu cleaning Stef

Feb. 5, 2009

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

by StÃ©phane Ducasse

Thanks I will have a look. stef On Feb 5, 2009, at 10:48 AM, Gary Chambers wrote: > 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 > > > _______________________________________________ > 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] 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