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

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

by stepharo

I ***LOVE*** the doc :) Stef On 15/9/14 10:23, Torsten Bergmann 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.

Sept. 15, 2014

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

by stepharo

> I understand your frustration because I felt it a few months ago. > > Now, you should bet on Athens, that the less risky way and it is part > of Pharo itself, and it is backed by a C library. For DrGeo, I found > bitmap rendering to be much faster after Athens use. > Whenever you meet issue, Igor will be helpful and this will help > improving Athens. > > Now, I have to admit I don't understand why Igor was distracted with > other task before finishing and polishing the Athens support on the image. - War in Ukraina. - And igor is working on TxText: writing a texteditor is something that takes time. We need it because we want to display text with athens. - worked on OSWindow We will push it in the image as soon as we release the new integration tool that will manage configurations (like that we can update Zinc, TxText, OSWindow, Athens,.... using configuration) > It brings to destabilizing state for newcomer or even expert willing > to invest on Athens use. I got lost many time and I was close to throw > all the code through the window as well. > > Hilaire >

Sept. 15, 2014

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

by stepharo

Guys the animation of roassal2 are done really simply using viva. Stef On 14/9/14 19:07, Nicolai Hess wrote: > 2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>>: > > Plenty ? no > > A few ? yes > > Woden is certainly a project that I want it to be successful and > keep going forward but at the moment I can't say its usable when > each time I resize the window it corrupts the viewport. > > No offense intended but lately the more I dive inside Pharo the > more I feel I waste my time, I love the IDE and the environment > and live coding but using the libraries is a never ending struggle > for me. I agree with Nicolai the landscape is not good, Pharo > really lacks mature libraries . Sure we like to bash Java but Java > libs are rock solid and very well documented. I bring Java as > example. Again I am not complaining at all, I knew when I came to > Pharo that I will have to face these limitations. I also don't > feel comfortable asking questions all the time as if I want others > to do my code but I did not have much of a choice. I just cant > deal with the lack of documentation any more. > > I think Pharo as a general idea is great , you definitely have > taken the Squeak fork one big step further but you have a very > long road ahead of you to make Pharo a modern environment. Asking > for animating a window with good performance is one of the very > basics of a good GUI API. I know you have limited resources and > once again I am not complaining at all I just present my opinion. > Its clear that Pharo needs a lot more people to contribute and > bring the system forward at least to solve the basic problems. > > > This is definitly wrong :) > Especially the older squeak versions were ahead of its time with > (animated) interactive UI elements. > Java (Swing) does not come with an animation framework for the UI > (JavaFX, yes but that took its time). > There was a timing/animation framework used by Roman Guy for its > FilthyRich clients, that did really look great. > He created UIs that never looked like ordinary Java UIs. But I think > that was done by few people only. > So, doing this for pharo should be doable. (I do remember something > like that was done for > Morphic (maybe this one: > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki…)) > > yoiu can do great thinks with Qt for C++ simple animation with the > good old qwidget and > the newer qml-framework. That's what I would call feature UIs (mostly > what is done nowadays on mobile devices and other > "platforms" have their own frameworks (java)android and Object-C (IPhone). > > And I think we will see more "feature"-UI on the web with > HTML5/Canvas/Web-GL. > > Do we need a good new UI framework for pharo? Yes. > Do we need many developers for working on this ? No, I think a > handfull (2-4) people would be enough. > What pharo really needs are: > Many more developers *using* pharo as a platform. > > nicolai > > > > Thank you all people who helped me. But I don't think it worths to > make my project in Pharo, too many problems. I feel privileged to > have helped you with my contributions , I wish the Pharo the best. > > I could return back to Python but I think its time for me to bite > the bullet and learn C/C++, since graphics is an area that deeply > interest me (more as an artist less as a coder), so I don't have > much of choice. Maybe I can brings some of my code back to Pharo > with NB wrappers , I definitely will keep a close eye on Pharo. > > In a few months I will also present to the Pharo community a > secret last contribution ;) > > On Sun, Sep 14, 2014 at 6:26 PM, phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>> wrote: > > Do you know anything better for futuristic UIs at the moment? > > I guess that we aren't talking about commercial dev here. And > if we would rely on everything being documented in Pharo, > errr, we wouldn't go too far. > > That being said, there are plenty of examples in the Woden code. > > Phil > > Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> a Ã©crit : > > Why should he use it, now? > I mean, is there a stable API? Or a roadmap ? > > Sometimes it is a bit dangerous to trust on "bleeding > edge" pharo frameworks. > I did some work based on Roassal3D just to found out there > won't be any further development. > The same happens with Roassal and GraphET. > The same can happen with Woden too :) > > > > > > 2014-09-14 14:13 GMT+02:00 phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>>: > > Why not use Woden? > > Phil > > Le 14 sept. 2014 12:51, "kilon alios" > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> > a Ã©crit : > > yeah I am afraid transparency is very important to me > > On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess > <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> > wrote: > > 2014-09-14 11:32 GMT+02:00 stepharo > <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > I remember that there was an animated gif > support. > Now I do not remember exactly. > > > At least in squeak there is an > AnimatedImageMorph, that can load and display > animated gifs. > That works and is quite fast even for multiple > instances. But of course no (alpha-)transparency > > > for roassal2 have a look at the viva > classes: this is the animation frameworks > that igor designed. > > Stef > > > > On 14/9/14 10:22, kilon alios wrote: >> so I tried to animate in Roassal having >> two different images display with a delay >> for few millisecond but it only displays >> the second image with this code >> >> form1 :=Form >> fromFileNamed:'/Users/kilon/Pictures/pharo.png'. >> form2 :=Form >> fromFileNamed:'/Users/kilon/Pictures/box.png'. >> v := RTView new. >> c := v canvas. >> s := TRBitmapShape new. >> s form: form1. >> c addShape: s. >> v open. >> >> (1 to: 100) do: [ :index| >> s form: form1. >> s signalUpdate . >> "(Delay forMilliseconds: 1000 ) wait." >> s form: form2. >> s signalUpdate . >> (Delay forMilliseconds: 1000) wait.]. >> >> I looked into RTAnimation but dont know >> how to use it for this example. Any help >> ? Does Roassal 2 support such animations ? >> >> if I do s form: and then s signalUpdate >> for each form separately it works fine >> but inside the loops does not seem to >> work , I tried bigger delays with no effect. >> >> On Sun, Sep 14, 2014 at 10:57 AM, >> stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Ronie when you ready I can help >> writting a chapter for the nex book. >> >> Stef >> >> >> On 13/9/14 21:42, Ronie Salgado wrote: >>> Hello, >>> >>> On 13/9/14 20:11, Enrico Schwass >>> wrote: >>>> Hi >>>> >>>> another option could be the >>>> verse protocol. There was a >>>> plugin for Maya and Blender to >>>> do realtime rendering. Dont >>>> know if there is some automatic >>>> Swig-like wrapper for smalltalk >>>> but FFI might work. >>> >>> There is Wig like wrapper for >>> Pharo done by ronie salgado. >>> >>> >>> I have an adapted version of Swig >>> for Pharo NativeBoost here: >>> https://github.com/ronsaldo/swig >>> >>> Currently I am using it to generate >>> my Bullet bindings (available here: >>> https://github.com/ronsaldo/bullet-pharo) >>> that can be used as an example of >>> using Swig. >>> I still have to improve more my Swig >>> generator, by writing documentation >>> and fixing some bugs. >>> >>> Greetings, >>> Ronie >>> >>> 2014-09-13 16:11 GMT-03:00 stepharo >>> <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>>: >>> >>> >>> On 13/9/14 20:11, Enrico Schwass >>> wrote: >>>> Hi >>>> >>>> another option could be the >>>> verse protocol. There was a >>>> plugin for Maya and Blender to >>>> do realtime rendering. Dont >>>> know if there is some automatic >>>> Swig-like wrapper for smalltalk >>>> but FFI might work. >>> >>> There is Wig like wrapper for >>> Pharo done by ronie salgado. >>> >>> Stef >>> >>> >>>> >>>> http://youtu.be/c_D2YJSNj8I >>>> >>>> Almost a decade ago I did some >>>> ruby bindings by hand. It was >>>> working out of the box >>>> >>>> Bye >>>> Enno >>>> >>>> Am 13.09.2014 um 16:11 schrieb >>>> kilon alios >>>> <kilon.alios(a)gmail.com >>>> <mailto:kilon.alios@gmail.com>>: >>>> >>>>> >>>>> " I am curious. You mean >>>>> rendering Bitmap from blender, >>>>> for later use in Pharo UI? " >>>>> >>>>> yes exactly. Blender can >>>>> render in all popular graphics >>>>> files, most used are png. >>>>> Animation frames can be >>>>> rendered each frame in its own >>>>> file. >>>>> >>>>> So basically its a lot like >>>>> the average games out there. >>>>> >>>>> "I will suggest bare bone >>>>> Morphic mainly, then Athens >>>>> when you need vectorial drawing." >>>>> >>>>> ok >>>>> >>>>> "For iStoa I decided to go >>>>> purely Morphic, I have a lot >>>>> of bitmap. Bitmap source is >>>>> SVG, then converted to PNG, >>>>> overscaled for production use. >>>>> Then from iStoa, depending on >>>>> the application window extent, >>>>> the bitmap are downscaled >>>>> accordingly, I am pretty >>>>> satisfied by the result." >>>>> >>>>> I fail to understand how your >>>>> bitmap source is SVG for me >>>>> bitmap is a raster graphic >>>>> format svg is procedural >>>>> graphic format. Two opposite >>>>> things. >>>>> >>>>> "Sure. The downpoint, you will >>>>> depend on one additional layer." >>>>> >>>>> dependency is not an issue. >>>>> Afterall the graphic files >>>>> themselves will be far bigger >>>>> download even more so if the >>>>> GUI becomes very large. >>>>> >>>>> "Nice. What will be the >>>>> expected outcomes of such API, >>>>> I am not sure to understand >>>>> and I am curious." >>>>> >>>>> Well Blender besides creating >>>>> 3d objects (which can be used >>>>> as 2d objects too) it can also >>>>> create 3d unrendable objects. >>>>> That means that objects >>>>> produce no graphics and have >>>>> the role of placeholders or >>>>> helpers, for example when you >>>>> want an emitter of light or >>>>> emitter of a physical power >>>>> like gravity or wind. Those >>>>> are called dummy objects and I >>>>> could use them to give >>>>> characteristics to the >>>>> graphics , for example I could >>>>> use a dummy to define the are >>>>> of influence of a mouse click >>>>> , or what type of event the >>>>> bitmap will respond to. That >>>>> means you wont have to import >>>>> the graphics manually to pharo >>>>> and create a separate morph >>>>> for each bitmap and then set >>>>> the events but rather press a >>>>> button in blender and then >>>>> Ephestos will import then >>>>> bitmaps to pharo , set the >>>>> events and create the morphs >>>>> automagically. >>>>> >>>>> So basically you will be using >>>>> Blender as a GUI designer. >>>>> >>>>> "Use fuel to store the state >>>>> of your application objects." >>>>> >>>>> ah nice so fuel is a good >>>>> candidate. >>>>> >>>>> I will also take a look at Dr >>>>> Geo and Phratch , both apps >>>>> have custom GUIs and use only >>>>> Morphic (Dr Geo using Athens >>>>> for the geometry primitives) . >>> >>> >> >> > > > > > >

Sept. 15, 2014

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

by stepharo

> I remember that there was an animated gif support. > Now I do not remember exactly. > > > At least in squeak there is an AnimatedImageMorph, that can load and > display animated gifs. > That works and is quite fast even for multiple instances. But of > course no (alpha-)transparency Yes this is that one. Stef

Sept. 15, 2014

Command shell font is too tiny :(

by kilon alios

So I got Command Shell from the configuration browser in Pharo 3 and it looks like it ignores the font size I have set in preferences , why ? The font it uses is too tiny I can barely make the letters, anyone else with same issue ?

Sept. 15, 2014

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

by Ben Coman

Sept. 15, 2014

How often should a uninitializedvariable warning be shown?

by Stephan Eggermont

Does it make sense to warn more than once for each variable? Stephan distibutionMapOn: a a roassal2 title: 'Distribution map'; painting: [:view2 | "Simple example of a distribution map. Green methods are short. Orange are long. Red are very long" | view classes d packages | self halt. packages := self forumPackages. classes := OrderedCollection new. packages do: [ :p | classes addAll: p classes ]. d := IdentityDictionary new. classes do: [:aClass | aClass methods do: [:m | d at: m put: m getSource lineCount ] ]. view shape rectangle withoutBorder. view nodes: classes forEach: [ :each | view shape label. view node: each. view node: each forIt: [ view interaction action: #browse. view shape rectangle size: 8; if: [:m | (d at: m) < 5 ] fillColor: Color green; if: [:m | (d at: m) >= 5 and: [ (d at: m) < 25 ] ] fillColor: Color orange; if: [:m | (d at: m) >= 25 ] fillColor: Color red. view nodes: (each methods sortedAs: [:m | (d at: m) ]). view gridLayout gapSize: 1 ]. view verticalLineLayout ]. view gridLayout]

Sept. 15, 2014

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

by Thierry Goubier

2014-09-15 15:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> Hum, I would more like SSE and AVX code done this way: matrix >> multiplications, bitmap processing, heavily used code, SciSmalltalk stuff >> on very large datasets. >> > > Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain > goes C code which gets compiled through some "black-hole toolchain" in the > NVidia SDK with host and GPU blocks. > You may be interested to contact Bernard Pottier. His NetGen toolkit does CUDA code generation. NetGen is VisualWorks only for the moment, even if I know someone who would like to have it in Pharo (well, two guys at least). > > That's too much to handle for my tastes, so the best is for me to have an > engine (or for a better metaphor) and using Pharo to drive/steer/harness it. > Yes. I intended to do things around that, but didn't found the time. > > > Indeed! CUDA =-) > > OpenCL, SPIR code generation and link to Cog. > >> >> The ability to generate better code than when targetting C. >> > > True too. But aren't those compilers smart enough already? With current > CPUs, well, it takes a strong man to do better things than the compiler it > seems. Or am I mistaken? > You are. A lot may be done if your input language is not C, but this is not allways relevant to the Pharo situation. I should know a lot more about LLVM-IR generation in a few months time. I'll say if I see easy gains when doing Smalltalk code. > >> >>> >>> Ah, I should have taken the research career :-) >>> >> >> Hum, you know that researchers are allways on the lookout for SMEs to >> collaborate on projects :-) >> > > Duly noted :-) Feel free to tickle me :-) > Noted :) Thierry

Sept. 15, 2014

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

by Ben Coman

Sept. 15, 2014

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

by Jan Vrany

> Wasn't Smalltalk/X the one which had a more complete version of > that C translation? Yes. Smalltalk/X **still** compiles Smalltalk to C (bytecode interpreting and JITing modes are also supported, of course). Best, Jan

Sept. 15, 2014