- Pharo-dev - lists.pharo.org

[Pharo-project] Alt-. does not work anymore on Linux or?

by GÃ¶ran Krampe

Hey! I just realized that alt-. doesn't seem to fly on my Ubuntu 12.10 in Pharo 1.4 nor 2.0 one-clicks. It *does* however work fine in Squeak 4.3 one-click. In Squeak I can: Run "(Delay forSeconds: 5) wait" and interrupt it with alt-. Or just press Alt-. and get a debugger. Also it seems that Process browser in Squeak is opened up *without* having any process be suspended. Not sure why Pharo is different there and shows the UI process as suspended? regards, GÃ¶ran

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Ciprian Teodorov

I remember reading about some issues with sharing traits code, however I don't remember exactly the problem. But it seemed that it can be fixed... Can somebody refresh my memory on that? If it is only an implementation problem maybe we can fix it... In that case the n*m issue is gone. About using 'self' in nb calls I don't see any problem, it just means that your class uses the trait, and it is doing ffi... On Nov 29, 2012 7:00 AM, "Yanni Chiu" <yanni(a)rogers.com> wrote: > On 28/11/12 9:32 PM, Camillo Bruni wrote: > >> >> where? memory is the only thing you may waste, and we still have plenty >> of it >> to waste. >> > > That's the kind of thinking that can lead to things like needing 100's of > MB of RAM just to run the Java-based install programs. IMHO, conserving > resources is always important, and some times has to be traded-off. > > just to make sure guys, you know about this, maybe it will lower your >>> obsession with traits :) >>> >> >> I think all your doubts are based on wrong ideas. Maybe if you come from >> C++ or C yes, but we're in Smalltalk? Modularity and maintainability is >> what you want to go for! size of objects in memory, specially static >> objects >> like methods, is a thing you hardly ever care about... >> > > You said "hardly ever care", but when you care - it matters. I'd like to > be able to run many images on a single server. If you make each base image > big, then I can run fewer such images. If it's in the base image, and it's > not striped out by #prepareForProduction, then it's a problem. > > > >

Nov. 29, 2012

Re: [Pharo-project] Getting started with Athens

by Igor Stasenko

On 29 November 2012 09:06, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Hi Igor, > > I've played with chipmunk lib & Esteban examples yesterday. But there's > always this step to pass where NB throws some generic error when the lib is > not found or not compiled with right options, .... > who said that it will be easy? nothing is perfect :) > Would be nice to have some clearer error messages if possible like: > > - NBLibraryNotFoundException: "libchipmunk.dylib not found in path > (/usr/local/lib, ./usr/lib...)"..... > - NBFunctionAdressNotFoundException: "libchipmunk.dylib loaded, but could > not find adress for function xxxxx, check compilation options ..." > - NBCPlusPlusException: "libXXXX is C++ library, won't work" > > yes, i agree: clear error messages mean less confusion to users and less time to waste answering same questions over and over again on mailing list. :) > > Laurent > -- Best regards, Igor Stasenko.

Nov. 29, 2012

[Pharo-project] NativeBoost extending Object

by Igor Stasenko

On 29 November 2012 08:29, Torsten Bergmann <astares(a)gmx.de> wrote: >>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. > > What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the > callout protocol. > > self externalCaller call: 'whatever' > > This wont overload Object but may require some fiddling since > "thisContext sender" is used. > > ... and this is what new api 'self nbCallout' provides. > > I also dislike the "namespacing" using "nb" in the selectors. > What if you rename or replace the project in the future? > > I would have to rename my methods from ffiCall: to alienCall: > to nbCall: ... ;) > a solution to this problem: use own convenience method(s).. then if you will ever need to get rid of namespace, all you need to do is change few methods. > Yes I know it is a different interface protocol from FFI to > NativeBoost - but still nobody is interested that the > subproject is called FFI/Alien/NativeBoost once it is > integrated in standard Pharo. > > You just want to do an external call like in any other > language and you are just interested that it works > reliable and easy. > > > And I would vote for a simple pragma <externalCall> > instead of > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > Sorry for all the wished ... but Christmas is near ... > did you behave well this year? you know Santa do not likes bad boys :) If serious.. we're evolving.. and it takes time and effort to change skins. Once we will be ready to get rid of namespace prefix, then we can abandon it, but not right now. > BTW: I marked 1.6 as release > 1.7 as stable > 1.8 as new development in the config > > We can also mark 1.7 as release since there was an official > announcement from Igor. Version 1.8 should get new developments. > > Thanks > Torsten -- Best regards, Igor Stasenko.

Nov. 29, 2012

Re: [Pharo-project] Getting started with Athens

by laurent laffont

Hi Igor, I've played with chipmunk lib & Esteban examples yesterday. But there's always this step to pass where NB throws some generic error when the lib is not found or not compiled with right options, .... Would be nice to have some clearer error messages if possible like: - NBLibraryNotFoundException: "libchipmunk.dylib not found in path (/usr/local/lib, ./usr/lib...)"..... - NBFunctionAdressNotFoundException: "libchipmunk.dylib loaded, but could not find adress for function xxxxx, check compilation options ..." - NBCPlusPlusException: "libXXXX is C++ library, won't work" Laurent On Wed, Nov 28, 2012 at 5:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Try: > > CairoLibraryLoader getLibraryHandle > > also check what > > CairoLibraryLoader getLibraryPath > > answers and if the cairo library exists under that path. > > If not, change the implementation to point to right location of library. > > > -- > Best regards, > Igor Stasenko. >

Nov. 29, 2012

Re: [Pharo-project] Getting started with Athens

by StÃ©phane Ducasse

Vanessa can you log all the questions that you ask yourself? Because I will take the slides of igor and turn them into a first draft of a chapter. And I would like to see if it answers or not your question. Can you also log what you learn because we could pair write the chapter after and this would be also good for your cv :) Imagine a chapter in a book with Ze great Stef. Incredible isn't :) Stef On Nov 28, 2012, at 9:46 PM, Vanessa PeÃ±a Araya wrote: > On 11/28/2012 05:11 PM, Igor Stasenko wrote: >> On 28 November 2012 20:01, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com> wrote: >>> Stef >>> >>> I was trying Athens on Pharo 2.0 today (I really like Pharo 2.0!! <3), but I >>> had a couple of problems with the examples. I was going to post it later but >>> I'll add them here: >>> >>> - exampleDrawText >>> With AthensCairoSurface StrikeFont does not understand glyphRendererOn: >>> >> and it shoudn't. >> Make sure you enabled freetype library in settings. >> >> (LogicalFont familyName: 'Arial' pointSize: 20) realFont. >> >> should answer a freetype font, not strike font instance. > > I didn't know that, thanks. Works perfect now :) >> >>> With AthensBallonSurface does not understand Clear: >>> >>> If it helps, others examples like example8, exampleDrawForm and >>> exampleDrawForm2 don't work for me with AthensBallonSurface. And >>> exampleStrokeRect with AthensCairoSurface only shows a black rectangle. >>> >> Sorry, i did not tested balloon surface for a while. That's trivial to >> fix though. >> >> The problem with balloon that many features may not work there properly, >> because balloon capabilities is very limiting. >> Balloon backend will stay there as a 'last resort', when nothing else works. >> >> .. but perhaps i should do a pass on it, to prevent to much bitrotting. > Maybe a comment? I think that's hard to know when I was starting with Athens, a comment might help choosing the right surface. > > Thanks for the help. >> >>> I'm particularly interesting in the one with rendering text. >>> >> just make sure you don't use strike fonts. freetype should work fine with >> balloon backend. >> >>> Thanks, >>> Vanessa. >>> > >

Nov. 29, 2012

Re: [Pharo-project] Getting started with Athens

by StÃ©phane Ducasse

On Nov 28, 2012, at 9:11 PM, Igor Stasenko wrote: > On 28 November 2012 20:01, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com> wrote: >> Stef >> >> I was trying Athens on Pharo 2.0 today (I really like Pharo 2.0!! <3), but I >> had a couple of problems with the examples. I was going to post it later but >> I'll add them here: >> >> - exampleDrawText >> With AthensCairoSurface StrikeFont does not understand glyphRendererOn: >> > and it shouldn't. may be we should have a check for that. > Make sure you enabled freetype library in settings. > > (LogicalFont familyName: 'Arial' pointSize: 20) realFont. > > should answer a freetype font, not strike font instance. > >> With AthensBallonSurface does not understand Clear: >> >> If it helps, others examples like example8, exampleDrawForm and >> exampleDrawForm2 don't work for me with AthensBallonSurface. And >> exampleStrokeRect with AthensCairoSurface only shows a black rectangle. >> > > Sorry, i did not tested balloon surface for a while. That's trivial to > fix though. > > The problem with balloon that many features may not work there properly, > because balloon capabilities is very limiting. > Balloon backend will stay there as a 'last resort', when nothing else works. > > .. but perhaps i should do a pass on it, to prevent to much bit rotting. can you add that to your todo? :) > >> I'm particularly interesting in the one with rendering text. >> > just make sure you don't use strike fonts. freetype should work fine with > balloon backend. > >> Thanks, >> Vanessa. >> > > -- > Best regards, > Igor Stasenko. >

Nov. 29, 2012

[Pharo-project] NativeBoost extending Object

by Torsten Bergmann

>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the callout protocol. self externalCaller call: 'whatever' This wont overload Object but may require some fiddling since "thisContext sender" is used. I also dislike the "namespacing" using "nb" in the selectors. What if you rename or replace the project in the future? I would have to rename my methods from ffiCall: to alienCall: to nbCall: ... ;) Yes I know it is a different interface protocol from FFI to NativeBoost - but still nobody is interested that the subproject is called FFI/Alien/NativeBoost once it is integrated in standard Pharo. You just want to do an external call like in any other language and you are just interested that it works reliable and easy. And I would vote for a simple pragma <externalCall> instead of <primitive: #primitiveNativeCall module: #NativeBoostPlugin> Sorry for all the wished ... but Christmas is near ... BTW: I marked 1.6 as release 1.7 as stable 1.8 as new development in the config We can also mark 1.7 as release since there was an official announcement from Igor. Version 1.8 should get new developments. Thanks Torsten

Nov. 29, 2012

Re: [Pharo-project] Athens + Amber + HTML5 canvas

by Tudor Girba

+1 Doru On 29 Nov 2012, at 00:59, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: > > Good idea :) > > Nico > > Camillo Bruni <camillobruni(a)gmail.com> writes: > >> indeed that would be nice! >> >> => maybe put it on the rmod wiki page as a students project? >> >> On 2012-11-28, at 19:30, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hi, >>> i just looked at js.html5 canvas.. >>> you know that it will be very easy to port Athens on Amber and provide >>> Athens API for html5 canvas. >>> >>> the functionality is quite similar to cairo. (a bit obfuscated >>> though.. but still) >>> >>> Now the point it that one can use Athens API for drawing things in >>> pharo as well as in browser.. >>> without much changes.. >>> So, you can develop & test graphics in pharo, and deploy in browser app.. >>> >>> Any takers? :) >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > -- > Nicolas Petton > http://nicolas-petton.fr > -- www.tudorgirba.com "Presenting is storytelling."

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Yanni Chiu

On 28/11/12 9:32 PM, Camillo Bruni wrote: > > where? memory is the only thing you may waste, and we still have plenty of it > to waste. That's the kind of thinking that can lead to things like needing 100's of MB of RAM just to run the Java-based install programs. IMHO, conserving resources is always important, and some times has to be traded-off. >> just to make sure guys, you know about this, maybe it will lower your >> obsession with traits :) > > I think all your doubts are based on wrong ideas. Maybe if you come from > C++ or C yes, but we're in Smalltalk? Modularity and maintainability is > what you want to go for! size of objects in memory, specially static objects > like methods, is a thing you hardly ever care about... You said "hardly ever care", but when you care - it matters. I'd like to be able to run many images on a single server. If you make each base image big, then I can run fewer such images. If it's in the base image, and it's not striped out by #prepareForProduction, then it's a problem.

Nov. 29, 2012