September 2014 - Pharo-dev - lists.pharo.org

Parsing Pharo syntax to C/C++

by kilon alios

Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?

Sept. 15, 2014

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

by kilon alios

It depends what you mean by control blender. Blender is 2 things a) C/C++ source code that implements all features that users use b) the Python API that allows to use all features that a user can use. Ephestos already allows full access to (b) . So for example if you wanted Dr Geo to export its data to blender so Dr Geo can convert its geometry to 3D and use all the nice features of blender you can do that already with ephestos. But for modifying existing functionality you need to get your hands dirty with the source. Implementing new fuctionality like importers / exporters etc is also doable via API so its doable via Ephestos. But cpu intense new fuctionality is done by modifying the source. I am not excluding creating a parser for the blender source , at first the thought did not cross my mind. If pettitparser has already a C or C++ parser that will be doable for me. I will have to research it further. If its easy enough I may be sticking with Pharo afterall. 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] [Pharo-users] [ANN] Easy I18N for Pharo

by Torsten Bergmann

Sven Van Caekenberghe wrote: > Perfect! Well done & presented (as usual ;-) I18N is nothing fancy, but thanks. Hope it is usefull for others too. > The way I see it, that is all there is to it. Yes - at least it solved my basic needs so far and maybe it helps us thinking about more internationalized applications for Pharo (or I18N the Pharo image itself) > 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 ? You decide where your translations come from/are loaded from. I use INIFile as it is plain simple to do. Internally I18NTranslator is nothing more than a simple object handling dictionaries. So the strings usually will be stored with the image (or flushed out and reloaded again at startup). If necessary the code can be refactored so that multiple storage backends or a cache can be added. Not on my todo list so far. Bye T.

Sept. 15, 2014

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