- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13215

by Marcus Denker

13215 ----- Issue 4269: MultiCanvasCharacterScanner is unused http://code.google.com/p/pharo/issues/detail?id=4269 Issue 4271: remove update uploading support from FileList http://code.google.com/p/pharo/issues/detail?id=4271 Issue 4270: SegmentScanner is unused http://code.google.com/p/pharo/issues/detail?id=4270 Issue 4266: TasklistMorph>>selectTask DNU http://code.google.com/p/pharo/issues/detail?id=4266 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 25, 2011

Re: [Pharo-project] Tiling windows

by laurent laffont

Now there's a button to open the world menu. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st On Wed, May 25, 2011 at 11:20 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > On Wed, May 25, 2011 at 11:06 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I do not understand. >> >> how can I get a browser? >> > > Hey, this is just a start :) I will add a button to open the world menu. > > > once this is one is created I get the browser full screen >> but then how do I get a chance to create a new one if I want. >> >> dividing the browsers based on the screen size results in rather small >> browsers :) >> > > yes, but because browsers waste space IMHO. Maybe we could get rid of > windows borders when tiled. > > Laurent. > > > >> >> Stef >> >> >> > TWMBar new open. >> > >> > The real manager is TilingWM. Try: >> > >> > (TilingWM forWorld: World) tileVisibleWindows. >> > (TilingWM forWorld: World) tileBrowsers. >> > (TilingWM forWorld: World) tileWorkspaces. >> > >> >> >> >

May 25, 2011

Re: [Pharo-project] Gettext package?

by StÃ©phane Ducasse

>> > > If you want to keep and improve the existing "localisation & translation" support, I think it's a good idea to integrate Gettext. It uses a format that is used beyond the Smalltalk community. yes > > But I guess the above depends wether the 'core' Pharo tools require some "translation" support. And I don't think they do, i.e: I don't think we want a french version of the system browser ;-) :) > They might require "localisation" without the translation (i.e. date format etc.) but Gettext is not about that. Any internationalization support is more a package to be used by applications developed in Pharo. > My use of Gettext, for example, is for translation support in Seaside apps. Hilaire uses it for Dr. Geo. > > Of course, GemStone and Visualworks also come with an internationalization library integrated in the basic image (not entirely sure about VW). > > If I do more work using Gettext, I can certainly do something for its integration in Pharo. excellent so let us know. > > Johan

May 25, 2011

Re: [Pharo-project] Gettext package?

by Johan Brichau

Ok thanks Hilaire. I will take a look at the current state of the package in etoys and split up the code as I mentioned. I'm new to this kind of internationalization stuff, so I will do some work as part of internationalizing our web apps. On 24 May 2011, at 23:13, Hilaire Fernandes wrote: > I ported the gettext package from Etoys to Pharo with help of other > (Henrik). > I have to admit I mostly forgot about its internal, even if I amn using > it for DrGeo. > In between, some part of the gettext package in Etoys was improved, I > forgot which part exactly. Bert may remember a bit more. > > Do whatever you think is appropriate with the package. As you hacked the > package recently you are definitely in a better position to split it in > different component. > > Hilaire > > Le 24/05/2011 11:11, Johan Brichau a Ã©crit : >> Hi guys, >> >> What is the future of the Gettext package in the PharoNonCorePackages repository? >> Is the intention to include it in Pharo core? Should that package become a separate project? Something else? >> >> I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). >> Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy. >> >> Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. >> But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package). >> >> So, I would like to get in touch with the stakeholders of the package and discuss where it's going. >> >> cheers >> Johan >> >> (see more info below -- mails >> >> >> Begin forwarded message: >> >>> From: Johan Brichau <johan(a)inceptive.be> >>> Date: 24 May 2011 08:26:33 GMT+02:00 >>> To: Philippe Marschall <philippe.marschall(a)gmail.com> >>> Cc: GemStone Seaside beta discussion <beta(a)seaside.gemstone.com> >>> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone >>> Reply-To: GemStone Seaside beta discussion <beta(a)seaside.gemstone.com> >>> >>> Hi Philippe, >>> >>> Yes, those are classes I left out (but they don't have the WA prefix). >>> >>> I also prefer that there is a shared common package for both platforms but there are more differences spread over several methods. >>> Off the top of my head, most differences are located in the MOFile class. Also, the 'startup' methods that are used to trigger a locale refresh when starting the Pharo image are not applicable in Gemstone. >>> >>> I'm willing to work towards a common package + platform-specific packages. Probably, we have to hear what the Pharo people (and specifically Hilaire Fernandes) think about it. >>> >>> cheers >>> Johan >>> >>> On 23 May 2011, at 20:08, Philippe Marschall wrote: >>> >>>> 2011/5/23 Johan Brichau <johan(a)inceptive.be>: >>>>> Hi all, >>>>> >>>>> The Gettext [1] implementation of Pharo has now been ported to Gemstone, such that we can use it for internationalization in web applications together with Gettext-Seaside. >>>>> More precisely, the Gettext package is a prerequisite for Gettext-Seaside. >>>>> >>>>> With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only those parts that are required to deploy the translation files in the Seaside web apps. >>>>> The implementation that generates translation files from the codebase is a bit more entrenched into platform-specific libraries. So, one has to generate the translation catalogs to disk in Pharo, edit them with a tool like poedit, and deploy the locale with the Gemstone deployment. >>>> >>>> Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are >>>> the classes that don't work in Gemstone. If so I could split the >>>> package into a portable part and a Pharo part so you don't need to >>>> load them im GemSonte. >>>> >>>> Cheers >>>> Philippe >>> >> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

May 25, 2011

Re: [Pharo-project] Gettext package?

by Johan Brichau

On 25 May 2011, at 11:34, StÃ©phane Ducasse wrote: >> But does it belong into that what we call Pharo? > > yes probably. If you want to keep and improve the existing "localisation & translation" support, I think it's a good idea to integrate Gettext. It uses a format that is used beyond the Smalltalk community. But I guess the above depends wether the 'core' Pharo tools require some "translation" support. And I don't think they do, i.e: I don't think we want a french version of the system browser ;-) They might require "localisation" without the translation (i.e. date format etc.) but Gettext is not about that. Any internationalization support is more a package to be used by applications developed in Pharo. My use of Gettext, for example, is for translation support in Seaside apps. Hilaire uses it for Dr. Geo. Of course, GemStone and Visualworks also come with an internationalization library integrated in the basic image (not entirely sure about VW). If I do more work using Gettext, I can certainly do something for its integration in Pharo. Johan

May 25, 2011

Re: [Pharo-project] [update 1.3] #13215

by Marcus Denker

On May 25, 2011, at 9:24 AM, Marcus Denker wrote: > 13215 > ----- > > Issue 4266: TasklistMorph>>selectTask DNU > http://code.google.com/p/pharo/issues/detail?id=4266 > Issue 1817: [etoy] Should remove project > http://code.google.com/p/pharo/issues/detail?id=1817 I will revert this update. The Project Removal seems to be not loadable by Monticello. (We should relaly use changesets when changing deeply the state of the image... it's hard to controll with Monticello what is happening). -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 25, 2011

Re: [Pharo-project] Do we freeze 1.3?

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=4273 :) On May 25, 2011, at 1:08 PM, Gary Chambers wrote: > Also, a problem with finalisation of FT2Handles... > > Fix: > > FT2Handle class>>deregister: aHandle > Registry ifNotNil: [ :reg | | finalizer | > finalizer := reg remove: aHandle ifAbsent: []. > finalizer ifNotNil: [ finalizer executor beNull. > self knownHandles remove: aHandle ifAbsent: [ ] ] ]

May 25, 2011

Re: [Pharo-project] Do we freeze 1.3?

by Gary Chambers

Also, a problem with finalisation of FT2Handles... Fix: FT2Handle class>>deregister: aHandle Registry ifNotNil: [ :reg | | finalizer | finalizer := reg remove: aHandle ifAbsent: []. finalizer ifNotNil: [ finalizer executor beNull. self knownHandles remove: aHandle ifAbsent: [ ] ] ] Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, May 25, 2011 11:49 AM Subject: Re: [Pharo-project] Do we freeze 1.3? thanks! On May 25, 2011, at 11:50 AM, Gary Chambers wrote: > Aside from an issue I've encountered with Windows VM answering an empty > string for the first command line parameter, rather than nil. > > Workaround : > > CommandLine class>>commandLineInput > "self commandLineInput" > > | str index args | > args := OrderedCollection new. > str := Smalltalk getSystemAttribute: (index := 2). > [ str isNil or: [ str isEmpty ] ] whileFalse: > [ args add: str. > str := Smalltalk getSystemAttribute: (index := index + 1) ]. > ^ args. > > (Sorry, can't login to create an issue at present...) > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, May 25, 2011 10:33 AM > Subject: Re: [Pharo-project] Do we freeze 1.3? > > +1 > > On Wed, May 25, 2011 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > Hello, > > 1.3 seems to stabilize... > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > > just 12 issues left. > > We could freeze soon. > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 25, 2011

Re: [Pharo-project] Do we freeze 1.3?

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=4272 Stef On May 25, 2011, at 11:50 AM, Gary Chambers wrote: > Aside from an issue I've encountered with Windows VM answering an empty string for the first command line parameter, rather than nil. > > Workaround : > > CommandLine class>>commandLineInput > "self commandLineInput" > > | str index args | > args := OrderedCollection new. > str := Smalltalk getSystemAttribute: (index := 2). > [ str isNil or: [ str isEmpty ] ] whileFalse: > [ args add: str. > str := Smalltalk getSystemAttribute: (index := index + 1) ]. > ^ args. > > (Sorry, can't login to create an issue at present...) > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, May 25, 2011 10:33 AM > Subject: Re: [Pharo-project] Do we freeze 1.3? > > +1 > > On Wed, May 25, 2011 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > 1.3 seems to stabilize... > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > > just 12 issues left. > > We could freeze soon. > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 25, 2011

Re: [Pharo-project] Do we freeze 1.3?

by StÃ©phane Ducasse

thanks! On May 25, 2011, at 11:50 AM, Gary Chambers wrote: > Aside from an issue I've encountered with Windows VM answering an empty string for the first command line parameter, rather than nil. > > Workaround : > > CommandLine class>>commandLineInput > "self commandLineInput" > > | str index args | > args := OrderedCollection new. > str := Smalltalk getSystemAttribute: (index := 2). > [ str isNil or: [ str isEmpty ] ] whileFalse: > [ args add: str. > str := Smalltalk getSystemAttribute: (index := index + 1) ]. > ^ args. > > (Sorry, can't login to create an issue at present...) > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, May 25, 2011 10:33 AM > Subject: Re: [Pharo-project] Do we freeze 1.3? > > +1 > > On Wed, May 25, 2011 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > 1.3 seems to stabilize... > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > > just 12 issues left. > > We could freeze soon. > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 25, 2011