- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ANN] Easy I18N for Pharo

by Sven Van Caekenberghe

Perfect! Well done & presented (as usual ;-) The way I see it, that is all there is to it. I like it that a single image can translate into multiple languages. I guess some people would also like String>>#translated ^ I18NTranslator defaultTranslator at: self I assume that the actual storage is open ended to also allow databases and so on ? On 15 Sep 2014, at 10:23, Torsten Bergmann <astares(a)gmx.de> wrote: > Need an easy translation framework for your Pharo application > with no external dependency? > > Then check out the I18N project: > > http://smalltalkhub.com/#!/~TorstenBergmann/I18N > > Docu and examples can be found on the same page, screenshot > is attached. > > Bye > T.<i18n.png>

Sept. 15, 2014

Re: [Pharo-dev] AppeX

by Tudor Girba

Hi, On Mon, Sep 15, 2014 at 9:57 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-15 6:44 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> As you could see in the Pillar highlighting support, Rubric can now >> handle any syntax highlighting in a rather straightforward way. You can >> also easily embed this in a Glamour browser. >> > > I'll have a look. I find that PluggableTextMorph automatic behavior (smart > characters, styling) is very nice when doing Smalltalk code, but a pain in > anything else. I'd like to see that Smalltalk-customized code be refactored > elsewhere than in the editor. > > What I'd like to see is the ability to customize the behavior for islands > of text inside a text (recursively of course :)). > This is not yet possible. I would hope we get this to work within the context of TxText. > >> You can see the example in the GT-InspectorExtensions-Pillar. You can >> load the code in a Moose image like this: >> Gofer new >> smalltalkhubUser: 'Pier' project: 'Pillar'; >> configuration; >> loadStable. >> Gofer new >> smalltalkhubUser: 'JanKurs' project: 'PetitParser'; >> configurationOf: #PetitParserIslands; >> load. >> #ConfigurationOfPetitParserIslands asClass loadDevelopment. >> Gofer new >> smalltalkhubUser: 'Moose' project: 'GToolkit'; >> package: 'GT-InspectorExtensions-Pillar'; >> load. >> > > Ok. The Moose image is a bit of a down to me when trying to understand > code because code exploration capabilities are limited / non obvious > compared to what I use in Pharo. > What do you mean? What is different for you in this area? Doru > > Thierry > > >> >> Cheers, >> Doru >> >> >> >> On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> >>> 2014-09-05 16:03 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> >>>> Maybe we can start small. >>>> >>>> I've current needs that could well be handled in the environment. >>>> >>>> The FileBrowser is in my view quite not used enough. >>>> >>>> When doing web applications, I deal with Javascript, CSS, content files >>>> etc all the time. >>>> >>>> The FileBrowser allows to edit files in its content pane. >>>> Doing an Accept (Alt-S) on the pane saves the file. >>>> >>>> So, instead of starting an external edit session in Vim, I mostly work >>>> there for some smaller changes (like tweaking CSS). >>>> >>>> Now, if we could have a syntax highlighter in there it would be nice. >>>> >>> >>> Yes. Anybody knows what is the API for adding / changing the styler on a >>> text morph? I'll have a use for a SmaCC grammar styler as well. >>> >>> Anybody has a CSS parser around? >>> >>> Thierry >>> >>> >>>> >>>> For CSS it wouldn't be too damn hard I think. >>>> >>>> >>>> Phil >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >>>> wrote: >>>> >>>>> Hi Torsten, Phil, >>>>> >>>>> On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote: >>>>> > Hi Phil, >>>>> > >>>>> > if there is something I would like to see our Pharo ecosystem and ST >>>>> in general moving >>>>> > towards is to such a "multilanguage"/"multisourcecode"/"flexible >>>>> ressources" kind of >>>>> > thing. Even when this could not be a short term goal I would like to >>>>> see this >>>>> > in the long term. >>>>> >>>>> I've been working in this area for many years now. And have learned a >>>>> good deal while doing that :-) >>>>> Making one language to execute within other's environment is the easy >>>>> part, though it could be a lot of work (especially, if you care about >>>>> performance). Making tools to be aware of different languages is not >>>>> hard too, thought it is "just" a huge amount of work that has to be >>>>> done. The tricky part is to allow one to talk to each other, preserving >>>>> each other's semantics and still stay intuitive, clear and free of >>>>> unnecessary boilerplate code. Another tricky bit is to make other >>>>> workflows and ways of coding things in other languages work nicely with >>>>> the way Smalltalk way we do it in Smalltalk. These are tough bits. >>>>> That's where a real research has yet to be done... >>>>> >>>>> > - running Java inside of Smalltalk/X >>>>> >>>>> Well, Smalltalk/X can do much more with Java than "just" run it. >>>>> Java has been fully integrated into development tools supporting full >>>>> development cycle :-) >>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

[ANN] Easy I18N for Pharo

by Torsten Bergmann

Need an easy translation framework for your Pharo application with no external dependency? Then check out the I18N project: http://smalltalkhub.com/#!/~TorstenBergmann/I18N Docu and examples can be found on the same page, screenshot is attached. Bye T.

Sept. 15, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] c8ff39: 40225

by Thierry Goubier

2014-09-15 9:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > 13833 rename String>>#withFirstCharacterDownshifted to >> String>>#uncapitalized >> https://pharo.fogbugz.com/f/cases/13833 >> >> I added two more issue to make that transition easier... > (for the critic, we should have a "Pharo3 to Pharo4 porting" section) > > 14019 add critics rule for #withCaracterDownShifted -> #uncapitalized > > https://pharo.fogbugz.com/f/cases/14019/add-critics-rule-for-withCaracterDo… > > 14018 backport #uncapitalized to Pharo3 > https://pharo.fogbugz.com/f/cases/14018/backport-uncapitalized-to-Pharo3 > > > Thanks Marcus, this is really nice to do it like that :) Thierry

Sept. 15, 2014

Re: [Pharo-dev] AppeX

by Thierry Goubier

2014-09-15 6:44 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > As you could see in the Pillar highlighting support, Rubric can now handle > any syntax highlighting in a rather straightforward way. You can also > easily embed this in a Glamour browser. > I'll have a look. I find that PluggableTextMorph automatic behavior (smart characters, styling) is very nice when doing Smalltalk code, but a pain in anything else. I'd like to see that Smalltalk-customized code be refactored elsewhere than in the editor. What I'd like to see is the ability to customize the behavior for islands of text inside a text (recursively of course :)). > > You can see the example in the GT-InspectorExtensions-Pillar. You can load > the code in a Moose image like this: > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > loadStable. > Gofer new > smalltalkhubUser: 'JanKurs' project: 'PetitParser'; > configurationOf: #PetitParserIslands; > load. > #ConfigurationOfPetitParserIslands asClass loadDevelopment. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load. > Ok. The Moose image is a bit of a down to me when trying to understand code because code exploration capabilities are limited / non obvious compared to what I use in Pharo. Thierry > > Cheers, > Doru > > > > On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> >> 2014-09-05 16:03 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> Maybe we can start small. >>> >>> I've current needs that could well be handled in the environment. >>> >>> The FileBrowser is in my view quite not used enough. >>> >>> When doing web applications, I deal with Javascript, CSS, content files >>> etc all the time. >>> >>> The FileBrowser allows to edit files in its content pane. >>> Doing an Accept (Alt-S) on the pane saves the file. >>> >>> So, instead of starting an external edit session in Vim, I mostly work >>> there for some smaller changes (like tweaking CSS). >>> >>> Now, if we could have a syntax highlighter in there it would be nice. >>> >> >> Yes. Anybody knows what is the API for adding / changing the styler on a >> text morph? I'll have a use for a SmaCC grammar styler as well. >> >> Anybody has a CSS parser around? >> >> Thierry >> >> >>> >>> For CSS it wouldn't be too damn hard I think. >>> >>> >>> Phil >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>> >>>> Hi Torsten, Phil, >>>> >>>> On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote: >>>> > Hi Phil, >>>> > >>>> > if there is something I would like to see our Pharo ecosystem and ST >>>> in general moving >>>> > towards is to such a "multilanguage"/"multisourcecode"/"flexible >>>> ressources" kind of >>>> > thing. Even when this could not be a short term goal I would like to >>>> see this >>>> > in the long term. >>>> >>>> I've been working in this area for many years now. And have learned a >>>> good deal while doing that :-) >>>> Making one language to execute within other's environment is the easy >>>> part, though it could be a lot of work (especially, if you care about >>>> performance). Making tools to be aware of different languages is not >>>> hard too, thought it is "just" a huge amount of work that has to be >>>> done. The tricky part is to allow one to talk to each other, preserving >>>> each other's semantics and still stay intuitive, clear and free of >>>> unnecessary boilerplate code. Another tricky bit is to make other >>>> workflows and ways of coding things in other languages work nicely with >>>> the way Smalltalk way we do it in Smalltalk. These are tough bits. >>>> That's where a real research has yet to be done... >>>> >>>> > - running Java inside of Smalltalk/X >>>> >>>> Well, Smalltalk/X can do much more with Java than "just" run it. >>>> Java has been fully integrated into development tools supporting full >>>> development cycle :-) >>>> >>>> >>>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Sept. 15, 2014

Re: [Pharo-dev] About renaming API methods

by Johan Brichau

On 15 Sep 2014, at 09:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Yes, but it is clear that sometimes it is just too much work. e.g we can > (by definition) not put everything new in Pharo4 in Pharo3. > > So this should be seen as a âbest effortâ rule... Putting that best-effort practice into place would already be a big plus. Though I see no reason to not pass method renames through a deprecation status. They can never be *that* urgent, and itâs quite easy to deprecate them and remove them in the next version. Keep up the good work! cheers Johan

Sept. 15, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40226 Home: https://github.com/pharo-project/pharo-core

Sept. 15, 2014

[pharo-project/pharo-core] 110b53: 40226

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 110b53db52e443b94607e4d0c29b66f5d8eb43ab https://github.com/pharo-project/pharo-core/commit/110b53db52e443b94607e4d0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-15 (Mon, 15 Sep 2014) Changed paths: M NautilusRefactoring.package/NautilusRefactoring.class/instance/display/class_andInstVariable_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/inst var/renameInstVarFrom_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/private-inst var/privateRenameInstVarFrom_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script226.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40226.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Announcements.package/MethodAdded.class/instance/accessing/methodAffected.st R System-Announcements.package/MethodAdded.class/instance/accessing/methodClass.st R System-Announcements.package/MethodAdded.class/instance/accessing/protocol.st R System-Announcements.package/MethodAdded.class/instance/accessing/selector.st R System-Announcements.package/MethodModified.class/instance/accessing/methodAffected.st R System-Announcements.package/MethodModified.class/instance/accessing/methodClass.st R System-Announcements.package/MethodModified.class/instance/accessing/newMethod_.st R System-Announcements.package/MethodModified.class/instance/accessing/selector.st R System-Announcements.package/MethodRecategorized.class/instance/accessing/methodAffected.st R System-Announcements.package/MethodRecategorized.class/instance/accessing/methodClass.st R System-Announcements.package/MethodRecategorized.class/instance/accessing/methodRecategorized_.st R System-Announcements.package/MethodRecategorized.class/instance/accessing/selector.st R System-Announcements.package/MethodRemoved.class/instance/accessing/methodAffected.st R System-Announcements.package/MethodRemoved.class/instance/accessing/methodClass.st R System-Announcements.package/MethodRemoved.class/instance/accessing/methodRemoved_.st R System-Announcements.package/MethodRemoved.class/instance/accessing/selector.st R System-Announcements.package/MethodRemoved.class/instance/testing/isProvidedByATrait.st R System-Announcements.package/SystemAnnouncer.class/instance/triggering/methodAdded_selector_inClass_.st R System-Announcements.package/SystemAnnouncer.class/instance/triggering/methodAdded_selector_inProtocol_class_.st R System-Announcements.package/SystemAnnouncer.class/instance/triggering/methodRemoved_protocol_.st R System-Announcements.package/SystemAnnouncer.class/instance/triggering/methodRemoved_selector_class_origin_.st Log Message: ----------- 40226 13214 rename instance variable does not work on class side https://pharo.fogbugz.com/f/cases/13214 14011 Many leftover methods after method announcement refactoring https://pharo.fogbugz.com/f/cases/14011 http://files.pharo.org/image/40/40226.zip

Sept. 15, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Hilaire

Le 14/09/2014 21:41, kilon alios a Ã©crit : > > My problem is not Igor , or Athens or transparency animation with pngs. > The problem is that Blender is way more powerful and tailor made for my > needs, Pharo is not. I knew that before starting with Pharo and I knew > that Pharo would something to have fun thing for some time. Blender is 1 > million lines of code , speciallised to high performance 3d graphics , > build on top of a language that is the most popular for 3d graphics and > on top of very powerful and mature libraries for 3d. > Euh, don't get me wrong, I have nothing to complain against Igor, as I wrote he's very helpful, talented guy with a good load of wisdom. Nevertheless, part of Athens need to be polished and from my pov it looks like it is not the priority, and I am disappointed by that. But again my vision of the situation is from outside, so definitely biased. Regarding Blender and Pharo: don't you want to control Blender engine from a Pharo model. I mean why do you want to bother with graphics and animation rendered by Pharo, it is not what Pharo is good at. What I will do is design the model in Pharo then drive Blender from it. That should be eaiser and benefit from the two worlds. Am I wrong? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Sept. 15, 2014

Re: [Pharo-dev] About renaming API methods

by Marcus Denker

On 15 Sep 2014, at 09:35, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Sep 15, 2014 at 9:16 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 1) add the same API to the current stable version > > this one would be great because I had problems with the FileSystem API > between Pharo 2 and Pharo 3: in Pharo 3 I had deprecated warnings that > I could not fix because Pharo 2 did not have the new API. Yes, but it is clear that sometimes it is just too much work. e.g we can (by definition) not put everything new in Pharo4 in Pharo3. So this should be seen as a âbest effortâ rule... Marcus

Sept. 15, 2014