- Pharo-dev - lists.pharo.org

[Pharo-project] split : bug or feature ?

by laurent laffont

In Pharo: ':' split: 'one:two:three:' => OrderedCollection( 'one' 'two' 'three' '' ) (':' split: 'one:two:three:') size => 4 Last element is an empty String In Ruby: >> 'one:two:three:'.split(':') => ["one", "two", "three"] >> 'one:two:three:'.split(':').size => 3 Laurent Laffont

May 1, 2010

Re: [Pharo-project] gettext package

by StÃ©phane Ducasse

On May 1, 2010, at 9:24 AM, Hilaire Fernandes wrote: > Thanks to the virtual hacking session yesterday on IRC (irc.freenode.org #pharo-project) and the help of hackers Marcus, Henrik and Korakurider we have moved the gettext package in a workable state. Excellent > So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup. > > Still there are thing to do and discuss: > > - I have moved all the modified and added classes in the gettext package. Modified classes were moved out of their original category, for example LocaleID, NaturalLanguageTranslator. > If we want to group translation tool it mean recatgorisation in the core Pharo. I would love to have as much as possible as internationalisation in a identifiable package. > - If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation. but this would be an override. > - regarding translation, we could end with a pharo.po file to group the translated message of the core. It will be located in a folder locale along the image. sounds good. Clearly in the future this should a package metadata. > > > There are still cleaning to do in the internal, and I hope simplifications in the code. Excellent > > Hilaire > > Hilaire Fernandes a Ã©crit : >> I have move in a Gettext package in PharoInbox classes for gettext support. Do not expect it to work. Some of the classes there, are just moved from former categories in pharo System-Localization and Multilingual other are coming from Etoys. >> I have not yet test to load it in a fresh image. >> Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 1, 2010

[Pharo-project] SqueakSource question: how do you make new lines in project description?

by Igor Stasenko

On a project like: http://www.squeaksource.com/Alien.html the project description contains a nicely formatted text. But in my project, no matter what i input in project description field, it squashing to a single paragraph, removing any new lines.. What i am doing wrong? -- Best regards, Igor Stasenko AKA sig.

May 1, 2010

Re: [Pharo-project] gettext package

by Hilaire Fernandes

The gettext package is in the http://www.squeaksource.com/PharoInbox

May 1, 2010

Re: [Pharo-project] gettext package

by Hilaire Fernandes

Thanks to the virtual hacking session yesterday on IRC (irc.freenode.org #pharo-project) and the help of hackers Marcus, Henrik and Korakurider we have moved the gettext package in a workable state. So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup. Still there are thing to do and discuss: - I have moved all the modified and added classes in the gettext package. Modified classes were moved out of their original category, for example LocaleID, NaturalLanguageTranslator. If we want to group translation tool it mean recatgorisation in the core Pharo. - If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation. - regarding translation, we could end with a pharo.po file to group the translated message of the core. It will be located in a folder locale along the image. There are still cleaning to do in the internal, and I hope simplifications in the code. Hilaire Hilaire Fernandes a Ã©crit : > I have move in a Gettext package in PharoInbox classes for gettext > support. Do not expect it to work. Some of the classes there, are just > moved from former categories in pharo System-Localization and > Multilingual other are coming from Etoys. > > I have not yet test to load it in a fresh image. > > Hilaire

May 1, 2010

Re: [Pharo-project] Issue 2372: HelpSystem for 1.1

by StÃ©phane Ducasse

> > Hi, > > The help core package and the according tests package are ready for > integration in the pharo inbox. After talking today with Stephane I also > removed the squeak specific stuff, so it is ready for inclusion in > Pharo 1.1. core image. > > The idea is to have the basic help support (help core) in the Pharo > core image and provide additional docu/help books in the dev-image. for now this is more important to add documentation and since help is easy to unload. I would put helpcore into core + help into dev In the future we may move it outside mini. thanks torsten. Let see what the other think. > > But this should depend on a community decision, so any comments > would be appreciated. > > A second option would be to to keep it out of the core image > and just provide the help support and documentation in the > Pharo-dev image. > > Bye > T. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 1, 2010

Re: [Pharo-project] Xemina Pharo, HÃ ná»i, Viá»t Nam

by Serge Stinckwich

2010/4/29 Torsten Bergmann <astares(a)gmx.de>: > Hi Serge, > > nice demo! Looking through the slides in "Build you own control > structure" you use #ifSeven: as example which is easy, but not a > "real world use case". > > I typically use another example: > > In a few languages you have a "REPEAT (block) UNTIL (cond)" control > structure (in Pascal for instance) which is easy to add to Smalltalk > with a #repeatUntil: method on BlockClosure. Yes your example is nice. Thank you Torsten, for your comment. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 1, 2010

Re: [Pharo-project] [Vm-dev] Question about dragging an image into the vm in Windows

by Andreas Raab

On 4/30/2010 2:58 PM, Mariano Martinez Peck wrote: > On Fri, Apr 30, 2010 at 6:04 PM, Andreas Raab <andreas.raab(a)gmx.de > <mailto:andreas.raab@gmx.de>> wrote: > > On 4/30/2010 5:11 AM, Mariano Martinez Peck wrote: > > The ideal would be: if I have defined a image in the file, to be > allowed > to drag another one. Of course, the one I drag should be used > and set as > systemAttribute 1. > > Do you know how can I do that? is this fixable ? > > > I don't understand what you're asking for. The current handling > makes it so that if you're in a deployment setting with the > ImageFile attribute set, then the VM will pass the argument to the > image where it's been processed. This is so that one can support > file type associations where users can simply double click documents > to open them (drag and drop functions the same way). > > > What I am saying is the following: if you define an image in the .ini > file and then try to drag and drop another image to the .exe (the vm) > then an error is raised in the image (the one that is defined in the ini > file). I wish that instead of loading the image of the ini file and > raise an error, that it loads the image I dragged and dropped. The same > as if there were any image defined in the .ini file. I see what you're saying. It's an interesting idea but currently not supported. Like I was saying the ImageFile feature is provided for deployment scenarios not for development, i.e., the idea is to pretend there's "just" the executable which in every respect behaves like an application. If you wanted to implement your idea I would suggest to create a new entry instead of ImageFile, perhaps named DefaultImage. It's meaning would be to "launch the specified image if no image is specified". This way one can decide whether to use a "strictly sealed" application or a more developer-oriented usage like you're asking for. Cheers, - Andreas

May 1, 2010

Re: [Pharo-project] Issue 2372: HelpSystem for 1.1

by Mariano Martinez Peck

On Fri, Apr 30, 2010 at 11:31 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > The help core package and the according tests package are ready for > integration in the pharo inbox. After talking today with Stephane I also > removed the squeak specific stuff, so it is ready for inclusion in > Pharo 1.1. core image. > > The idea is to have the basic help support (help core) in the Pharo > core image and provide additional docu/help books in the dev-image. > > But this should depend on a community decision, so any comments > would be appreciated. > > A second option would be to to keep it out of the core image > and just provide the help support and documentation in the > Pharo-dev image. > Excellent!! It is possible to easily remove all the code and stuff related to documentation? suppose we put it in core, it would be great to be able to completely and cleanly remove it in ScriptLoader cleanUpForProduction. Cheers Mariano

May 1, 2010

Re: [Pharo-project] [Vm-dev] Question about dragging an image into the vm in Windows

by Mariano Martinez Peck

On Fri, Apr 30, 2010 at 6:04 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/30/2010 5:11 AM, Mariano Martinez Peck wrote: > >> The ideal would be: if I have defined a image in the file, to be allowed >> to drag another one. Of course, the one I drag should be used and set as >> systemAttribute 1. >> >> Do you know how can I do that? is this fixable ? >> > > I don't understand what you're asking for. The current handling makes it so > that if you're in a deployment setting with the ImageFile attribute set, > then the VM will pass the argument to the image where it's been processed. > This is so that one can support file type associations where users can > simply double click documents to open them (drag and drop functions the same > way). > > What I am saying is the following: if you define an image in the .ini file and then try to drag and drop another image to the .exe (the vm) then an error is raised in the image (the one that is defined in the ini file). I wish that instead of loading the image of the ini file and raise an error, that it loads the image I dragged and dropped. The same as if there were any image defined in the .ini file. I am not being clear ? Thanks. Mariano

April 30, 2010