- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] AppeX

by Tudor Girba

Hi, On Mon, Sep 15, 2014 at 11:27 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi, > > > I'm accustomed to the smart suggestion stuff as I implemented it, makes it > very easy to drill down in code... > > What I use a lot: > > Right mouse button on a global, select 'Browse' : inspect the class > variable or open a browser on the class (depending on what it is). Also > valid in a class #subclass: display in the browser, to browse the super > class. > > Implementors / sendors of / accesses to instance var under right mouse > button: open a full browser showing all the resulting methods (and not a > message list :( ). Also works in the string containing instance variable > names in a class definition pane. > > Double click on a package / class -> open a browser scoped to that package > / class (where all search operations are limited to that scope). > > Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui > (no package choice) : result of the finder will appear in a new browser, > and finder is scoped by the initial browser scope. > > So, when I end up in Nautilus, I just find myself very clumsy looking > around (which is not good for my self-esteem ;) ) Not forgetting the fact > that opening a Nautilus browser takes a lot longer. > Are you comparing with the AltBrowser? > In Moose also, GTInspector is slow. > What is slow? > > Take it as a different experience on the GUI side; I know I invest a lot > in the motor skill part of the GUI, and this has an effect when I switch > platform. > It seems to me that you are not comparing the Moose image with the Pharo image, right? What are you comparing with? Can I look at these changes? Cheers, Doru > Thierry > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

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

by Hilaire

Nice for project with a delimited scope. Problem: you cut yourself from translators aggregated in oneline free software community. For example https://translations.launchpad.net/drgeo For DrGeo this is a show stopper. Hilaire Le 15/09/2014 10:23, Torsten Bergmann a Ã©crit : > 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. > -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Thierry Goubier

Hi Kilon, you don't need any parser to do that, you need something to generate C / C++ code :) There are Smalltalk to C translators floating around, and I believe one of them is in the Squeak / Pharo code base to generate the VM (or part of it). If you want to do it yourself, you probably should: explore the Ring model as a way to export the package / class structure in C++ (just generate text as you go) and also make a pass method by method, asking for the RBAST of the method, and a visitor to generate the C / C++ equivalent to each node of the AST (and you'll find the Smalltalk AST very simple and nice :) ). Thierry 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > 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] Parsing Pharo syntax to C/C++

by Serge Stinckwich

On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > I may be wrong, but I think the closest thing out there is Slang. Is the > pseudo smalltalk used to develop the VM. > > Also there is a project for generating C for arduino, (a project related > with EToys), but i am not sure about how complete is. Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 15, 2014

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

by Hilaire

May be I wrongly expressed: imagine a 3D game whose model world is in Pharo then rendered in Blender (I guess model data need to be share between Pahro and Blender, but graphic only reside on Blender). Now you could use the Pharo dev tools like inspector & al. to play with your games. With DrGeo analogy: it will be more like a shared 3D model between Pharo and Blender, and controlled from Pharo. Le 15/09/2014 11:02, kilon alios a Ã©crit : > 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. > -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Santiago Bragagnolo

I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM. Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is. 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > 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] AppeX

by Thierry Goubier

Hi, 2014-09-15 10:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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. > I was thinking of having a look at TxText ;) I noticed that I have already started to reimplement part of the StringHolder / PluggableTextMorph logic outside it (via menu command objects / keymapping shortcuts instead of using the hardcoded versions inside the Morph or Model object) and I wanted to see if this was already done (or prepared for) in TxText. I think that, even in the context of the current TextEditor, I could customize based on islands based on what I already have. But I have to spend some time on it. > > >> >>> 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? > I'm accustomed to the smart suggestion stuff as I implemented it, makes it very easy to drill down in code... What I use a lot: Right mouse button on a global, select 'Browse' : inspect the class variable or open a browser on the class (depending on what it is). Also valid in a class #subclass: display in the browser, to browse the super class. Implementors / sendors of / accesses to instance var under right mouse button: open a full browser showing all the resulting methods (and not a message list :( ). Also works in the string containing instance variable names in a class definition pane. Double click on a package / class -> open a browser scoped to that package / class (where all search operations are limited to that scope). Ctrl+F -> open the finder toolbar on top of the browser, with reduced gui (no package choice) : result of the finder will appear in a new browser, and finder is scoped by the initial browser scope. So, when I end up in Nautilus, I just find myself very clumsy looking around (which is not good for my self-esteem ;) ) Not forgetting the fact that opening a Nautilus browser takes a lot longer. In Moose also, GTInspector is slow. Take it as a different experience on the GUI side; I know I invest a lot in the motor skill part of the GUI, and this has an effect when I switch platform. Thierry

Sept. 15, 2014

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