May 2010 - Pharo-dev - lists.pharo.org

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

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

by Marcus Denker

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: nameForServer: aServer ^self servers keyAtValue: aServer which is only called by methods that have no senders. Maybe we should clean this a bit? Marcus > > On May 11, 2010, at 9:41 AM, Marcus Denker wrote: > >> Hi, >> >> I think one question one should always ask: Do I have a real need for the new method? >> >> Sometimes it makes sense to add new API methods even outside of direct need. >> Consistency is the most important reason to add something. >> >> So is there a direct need for your method? >> >> Marcus >> >> >> >> On May 10, 2010, at 4:36 PM, Tristan Bourgois wrote: >> >>> >>> keyAtValue: returns one key of the value specified but if you have more time >>> the same value the method return one key. >>> An example: >>> t:=Dictionary new. >>> t at: 'toto' put: 4. >>> t at: 'foo' put: 4. >>> t keyAtValue:4. -> 'foo' >>> >>> So we can't recuperate all of the keys. I propose to create the methods >>> keysAtValue: who return an Array with all the keys for this value. >>> >>> I'm not in Pharo very long time so I can not say if it can be useful so I am >>> asking to you the question. >>> >>> Tristan Bourgois. >>> -- >>> View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 11, 2010

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

by laurent laffont

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. > > 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 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

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Henrik Johansen

On May 11, 2010, at 10:37 16AM, StÃ©phane Ducasse wrote: > may be we should write that on the book henrik would like to write some paragraph on fonts for dummies like us. > > Stef I would need an account first then :) Cheers, Henry

May 11, 2010