- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)

by Mariano Martinez Peck

On Tue, May 11, 2010 at 1:55 PM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Hi Mariano, all > Le 11/05/2010 11:43, Mariano Martinez Peck a Ã©crit : > > Hi Alain. DEVImageCreator has to be updated to use the new preferences. I >> can do it but it will require much more than for me than for you ;) >> >> For preferences it is DEVImageCreator >> setDefaultPreferences >> it is using Preferences class for the moment. It should be updated to use >> Settings, isn't it ? >> > I don't think so. There is no need for such a initialization anymore since > package are defining their own preferences. > If a default value is desired then it should be set by an initialization > method or lazily by the getter. > I find the lazy initialization better because then, the SettingBrowser can > reset the preference to the default by setting it to nil. > > But maybe the default value in the "PharoCore" is not the same as PharoDev? I mean, suppose these are the default prefrences we used in the pharo dev images: setDefaultPreferences. Preferences disable: #annotationPanes; disable: #allwaysShowVScrollBar; enable: #alternativeButtonsInScrollBars; disable: #fadedBackgroundWindows; enable: #fastDragWindowForMorphic; disable: #fullScreenLeavesDeskMargins; enable: #generalizedYellowButtonMenu; enable: #mouseClickForKeyboardFocus; enable: #noWindowAnimationForClosing; disable: #scrollBarsNarrow; disable: #scrollBarsWithoutMenuButton; disable: #showSplitterHandles; disable: #syntaxHighlightingAsYouTypeAnsiAssignment; enable: #showTextEditingState; disable: #windowAnimation; setPreference: #GlyphContrast toValue: 55; disable: #roundedWindowCorners; disable: #roundedMenuCorners; enable: #infiniteUndo; enable: #useUndo; enable: #mercuryPanel; disable: #showUpdateOptionInWorldMenu. If we used to do this, I guess it was becuase most of the default preferences of the core image was different. Otherwise, this method doesn't have sense. If I now do what you say, I am changing the default value of the pharo core image also. Is this correct ? or this should be only one flavor (PharoDev) ? Anyway, suppose I want to do the same as above, I should do something like: Preferences infiniteUndoSetting: true; etc.... Similar happens with external packages. Suppose OB developers (Lukas?) doesn't want to have mercury bar enable by default, but us (in PharoDev) we DO want it. Then I need to set such preference. Maybe the name default looks bad for you. It should be "preferences for PharoDev image" > BTW, Preferences is still present in Pharo 1.1 and thus, >> setDefaultPreferences is still working but I guess it should be updated. >> > why ? there is no need for setDefaultPreferences anymore. > > >> Do you know when Preferences class will be completely removed? Pharo 1.2? >> > I don't know. Maybe we can let it in the 1.1 in order > to let maintainers the possibility to port their packages and > definitively remove it in 1.2. > I agree, 1.2. > The same for TheWorldMenu I guess. > ok Cheers Mariano > Cheers > Alain > > >> Thanks! >> >> Mariano >> > >

May 11, 2010

Re: [Pharo-project] [Vm-dev] Re: Freetype plugin archive

by Mariano Martinez Peck

On Tue, May 11, 2010 at 10:57 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > > > On Tue, May 11, 2010 at 9:56 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> >> >> >>> >>> I think you're right. I will add this description. >>> >>> Indeed, with easy_squeakvm script you have reproducibility (all is >>> automated, explicit svn rev. and ConfigurationOfVMMaker). >>> >>> >> Yes, it is reproduceable. But it is the same, in the Conf version, I need >> the version of easy_squeakvm script as you will commit after. >> > > > ? 1 version of easy_squeakvm uses automatically the right squeakvm revision > and the right version of ConfigurationOfVMMaker. So the reference is > not ConfigurationOfVMMaker nor squeakvm sources, but easy_squeakvm itself. > There as a misunderstood. I know easy_squeakvm is completly reproducible. What I was saying is that someone that DOES NOT use easy_squeakvm should be reproducible too ;) Putting the SVN revision in the Metacello version helps with this. > > >> >> easy_squeakvm is linux specific...so I would put the svn version, not >> easy_squeakvm script ;) >> > > Yes it's true. But I think it's easily portable to MacOSX as it's a Unix > system. > > As there's some work on the Windows VM build to use CMake if I understand, > with cygwin we can have it too. > > And then we can automatically generate the One-Click archive from scratch > ;p > sounds cool. If I have time I will try easy_squeakvm in my Mac... > > I can tag easy_squeakvm 1.0 for Pharo 1.0, easy_squeakvm 1.1 for Pharo 1.1 > and so on. > > > Laurent Laffont. > > >> >> >>> May be we can "translate" easy_squeakvm to Smalltalk so we can have an >>> EasySqueakVM package (or better name) which is cross platform. >>> >> >> hahahah maybe ;) >> >> >>> >>> Cheers, >>> >>> Laurent Laffont >>> >>> http://pharocasts.blogspot.com/ >>> http://magaloma.blogspot.com/ >>> >>> >>> >>> >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> >>>> >>>>> Laurent Laffont >>>>> >>>>> http://pharocasts.blogspot.com/ >>>>> http://magaloma.blogspot.com/ >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

May 11, 2010

[Pharo-project] Fwd: Re: DEVImageCreator >> setDefaultPreferences (alain?)

by Alain Plantec

-------- Message original -------- Sujet: Re: DEVImageCreator >> setDefaultPreferences (alain?) Date : Tue, 11 May 2010 13:55:41 +0200 De : Alain Plantec <alain.plantec(a)free.fr> RÃ©pondre Ã : alain.plantec(a)free.fr Pour : Mariano Martinez Peck <marianopeck(a)gmail.com> Hi Mariano, all Le 11/05/2010 11:43, Mariano Martinez Peck a Ã©crit : > Hi Alain. DEVImageCreator has to be updated to use the new > preferences. I can do it but it will require much more than for me > than for you ;) > > For preferences it is DEVImageCreator>> setDefaultPreferences > it is using Preferences class for the moment. It should be updated to > use Settings, isn't it ? I don't think so. There is no need for such a initialization anymore since package are defining their own preferences. If a default value is desired then it should be set by an initialization method or lazily by the getter. I find the lazy initialization better because then, the SettingBrowser can reset the preference to the default by setting it to nil. > BTW, Preferences is still present in Pharo 1.1 and thus, > setDefaultPreferences is still working but I guess it should be updated. why ? there is no need for setDefaultPreferences anymore. > > Do you know when Preferences class will be completely removed? Pharo 1.2? I don't know. Maybe we can let it in the 1.1 in order to let maintainers the possibility to port their packages and definitively remove it in 1.2. The same for TheWorldMenu I guess. Cheers Alain > > Thanks! > > Mariano

May 11, 2010

Re: [Pharo-project] Standard input in Pharo?

by StÃ©phane Ducasse

Yes I would really like to have that in Pharo 1.2 if people send us some code. Stef On May 11, 2010, at 1:48 AM, Igor Stasenko wrote: > 2010/5/11 Andrei Stebakov <lispercat(a)gmail.com>: >> I've been just going through "Computer Programming with GNU Smalltalk" book >> using Pharo 1.0 as an actual ST implementation. >> The book mentions "stdin nextLine" as a way to get an input from a user via >> the standard input. >> Is there a similar class/method in Pharo? >> >> > If you are on linux, you can do just: > > stream := FileStream readOnlyFileNamed: '/dev/stdin'. > stream nextLine > > Unfortunately, Squeak VM doesn't provides a default API for working > with stdin/out, > since its more a GUI-centric , not command-line centric thing. > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

Re: [Pharo-project] Migrating among different Pharo releases

by StÃ©phane Ducasse

thanks mariano http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores/ On May 10, 2010, at 10:29 PM, Mariano Martinez Peck wrote: > Hi folks. I think we need to improve the changes/changelog between Pharo versions: 1.0, 1.1 etc. In addition, we need to document somewhere, how external packages maitainers should update their code. Sometimes, with a deprecated it is easy as you can say which other message to use instead. However, removing TheWorldMenu, FillInTheBlank, Preferences, etc it is more complicated as you cannot deprecated. So...if we want maintainers of external packages to update their versions to work with Pharo 1.1 we should document and explain what to do for these situations. For example, I have NO IDEA what to do with code that has references to those classes. Seriously, I don't have idea how to fix them. > > I propose something like Seaside at least: http://www.seaside.st/documentation/migration/28to30 > > Maybe the best start point is: http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne > > Sorry I cannot help by myself with this. I am just speaking in case someone can know and can spent few hours and help with this. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

Re: [Pharo-project] keyAtValue: -> keysAtValue:

by StÃ©phane Ducasse

cool tristan if you have code we will integrate it in 1.2 :) Open a bug entry and put code there. Stef On May 11, 2010, at 11:28 AM, Marcus Denker wrote: > > On May 11, 2010, at 11:20 AM, Tristan Bourgois wrote: > >> >> I understand what you said. >> But I think keyAtValue: is not pertinent. In the case where there are more >> than one same values, you can't know which value is selected. >> >> I should say that replace keyAtValue: by keysAtValue: because, I think, it's >> more pertinent. >> > > And clients that want to use the back-mapping can just do > > (myDict keysAtValue: 'hello') first. > > This would make the problem explicit. > *and* they could even than add an assert to make sure that the mapping does not degenerate. > > I cleaned ServerDirectory a little: > http://code.google.com/p/pharo/issues/detail?id=2408 > > So there is just Encoder left. Which will disappear in 1.2 anyway. > > So yes, we could do that. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

[Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)

by Mariano Martinez Peck

Hi Alain. DEVImageCreator has to be updated to use the new preferences. I can do it but it will require much more than for me than for you ;) For preferences it is DEVImageCreator >> setDefaultPreferences it is using Preferences class for the moment. It should be updated to use Settings, isn't it ? BTW, Preferences is still present in Pharo 1.1 and thus, setDefaultPreferences is still working but I guess it should be updated. Do you know when Preferences class will be completely removed? Pharo 1.2? Thanks! Mariano

May 11, 2010

Re: [Pharo-project] keyAtValue: -> keysAtValue:

by Marcus Denker

On May 11, 2010, at 11:20 AM, Tristan Bourgois wrote: > > I understand what you said. > But I think keyAtValue: is not pertinent. In the case where there are more > than one same values, you can't know which value is selected. > > I should say that replace keyAtValue: by keysAtValue: because, I think, it's > more pertinent. > And clients that want to use the back-mapping can just do (myDict keysAtValue: 'hello') first. This would make the problem explicit. *and* they could even than add an assert to make sure that the mapping does not degenerate. I cleaned ServerDirectory a little: http://code.google.com/p/pharo/issues/detail?id=2408 So there is just Encoder left. Which will disappear in 1.2 anyway. So yes, we could do that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 11, 2010

Re: [Pharo-project] keyAtValue: -> keysAtValue:

by Tristan Bourgois

I understand what you said. But I think keyAtValue: is not pertinent. In the case where there are more than one same values, you can't know which value is selected. I should say that replace keyAtValue: by keysAtValue: because, I think, it's more pertinent. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2173574.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 11, 2010

Re: [Pharo-project] keyAtValue: -> keysAtValue:

by Marcus Denker

On May 11, 2010, at 11:13 AM, Marcus Denker wrote: > > On May 11, 2010, at 10:35 AM, StÃ©phane Ducasse wrote: > >> But marcus the problem is right now keyAtValue: is bogus. Did you see it? >> >> > > It does work when ypu know that there is only one value that is identical. > > Than you can use it to map back and forth. (slowly one of them, of course). > > If there are two values that are the same, the message does not make that much sense. > > I guess this method is used for just the cases when the client needs a table for maping in > both directions. > > The only client in the Core image is ServerDirectory: > Ups. Missed Encoder>>tempNames. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 11, 2010