November 2012 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] NativeBoost extending Object

by Camillo Bruni

> > my main problem with traits that number of compiled methods in system > is going to be n*m, > where n is number of methods in trait and m is number of root-classes > where it used. so? if that is your concern, then you chose the wrong progamming language... > and i am not really happy with that. I prefer having 9 methods in Object than > 9*100 methods in many classes. that's just because traits are a "hack" and copy down methods to make it work, but you as user won't care. > while it is fine from developer's POV (because tools can hide this), > you still paying the price. where? memory is the only thing you may waste, and we still have plenty of it to waste. > 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...

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Igor Stasenko

On 29 November 2012 02:42, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> I think so too, traits would help limiting the scope of FFI. >>> >>> maybe the tools could require some polish, but not using traits won't help ;) >>> >> every time one using double negation, a small kitten dies. >> >> so, please clarify your statement :) > > the double negation stays: > > not using traits won't help <=> using traits will help > > ... improving the infrastructure my main problem with traits that number of compiled methods in system is going to be n*m, where n is number of methods in trait and m is number of root-classes where it used. and i am not really happy with that. I prefer having 9 methods in Object than 9*100 methods in many classes. while it is fine from developer's POV (because tools can hide this), you still paying the price. just to make sure guys, you know about this, maybe it will lower your obsession with traits :) -- Best regards, Igor Stasenko.

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Camillo Bruni

>> I think so too, traits would help limiting the scope of FFI. >> >> maybe the tools could require some polish, but not using traits won't help ;) >> > every time one using double negation, a small kitten dies. > > so, please clarify your statement :) the double negation stays: not using traits won't help <=> using traits will help ... improving the infrastructure

Nov. 29, 2012

Re: [Pharo-project] NativeBoost - new version new ideas ;)

by Igor Stasenko

Sorry for late reply, didn't noticed this mail before. On 26 November 2012 21:32, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > While I'm waiting impatiently for the new NB version I played around some > more and I have noted some ideas: > > First thing is related to structures and callbacks... what if I want to have > a callback as a member of a structure? > It seems to me that the way to go is to declare a MyCallback class and then > use it in the structure, which is fair enough. > But what if I have a function that initializes this structure with a user > provided callback? Then the structure is not printed correctly. > It seems that #coerceReturnValue: is not implemented in the > NBCallbackType... > While this is not a big issue it made me think that I was doing something > wrong... Maybe in this case we can instantiate MyCallback class and put the > fct pointer in in trunk ivar. > A unique instance of callback has unique trunk. This is the only way to identify, which callback was called at runtime. A coerceReturnValue: is not implemented simply because callback has non-trivial initialization procedure and intimately connected with VM internals etc.. you cannot just take random pointer value and then convert it into instance of your callback.. (because this is what coerceReturnValue: should implement). As a compromise, however, coerceReturnValue: could simply answer a NBExternalAddress. so, as input value, it will require a valid callback object instance, and as return value it will give you an address. Does that sounds like a plan? > Secondly, related to structs again... It seems that we can define structures > like: > struct { > void *a[2]; > } > only by transforming them to > struct { > void *a1; > void *a2; > } > Am I wrong... if not maybe we can extend a little bit the syntax for > defining structs to accept the first form... which will be far easier to > write if we have large index values like void *x[20]... > What do you think? yes the "syntax" for struct fields is very simplistic. I put things which was easy to put.. leaving full C coverage for a future. If you want to extend it.. First we need to implement array-type values.. which i wanted to introduce since a while.. but had no time to work on it yet :) > > Lastly, seeing that we are starting to have support for most of c-like > declarations, i am not really satified with the way the enums should be > handled... Maybe we can reify them as some kind of external object so that > we can say something like: > enum { > AAA = 1, > BBB = 2, > }; > MyEnum AAA (to get the item AAA of the enum) > MyEnum BBB value = 2 > and behind the enumeration is defined as a Dictionary of item->value > mappings. This is all good, but doing dict lookup at run time costs a lot more than just using shared pool var. Nothing prevents one from writing a code generator which converts enum {...} syntax into pool initialization method. So you could have best of two worlds (and you can even keep original sources with enum syntax somewhere, to be able to regenerate the code in case of changes)... Which brings is to the question: how often enums need changes? (Hint: almost never). So i agree, it would be cool to have enum -> pool code generator.. which can save little time. (you will use it once per writing binding to some library). As for dictionaries.. bad idea :) i am not ready to pay the price of doing dictionary lookups every time i need constant from enum. > Attached to this mail you will find a fileout of such an approach... not today.. but i will look at it. > I agree that maybe this is not the most optimized way of dealing with enums, > however I like this approach because it is uniform (with structs, external > objects, external addresses, callbacks, etc). > Moreover if a beginner wants to hack his way into NB FFI I think it is > easier to cope with an enum object than with SharedPools defined in classes, > and imported. > > Cheers, > PS: I can't way to get my hand on the new version... > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Igor Stasenko

On 29 November 2012 00:38, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > While I can clearly see your points, I don't quite agree with all of them, > probably because I don't have as much experience as you do. > See bellow some of my thoughts on the matter. At the end I like very much > NativeBoost today, and I think discussing these things helps us move forward > and assume the choices that are made. > > On Wed, Nov 28, 2012 at 11:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 28 November 2012 22:24, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi guys, >> > >> > Looking at NB methods extending Object I am wandering if it won't be >> > better >> > to put them in a Trait to be used by any class needing them? >> > >> i don't see what you will gain from that, except that you will end up >> using that trait >> all over the places? > > What do you understand about all over the places? In my opinion FFI calls > should be very well isolated > in specific modules that are meant for that. I think we might have different > views on this issue... I see using external libraries > as a limited number of classes (maybe just one in most cases) doing the > native calls, and then writing a library that relies on these classes > only for calling the external library. This way the external interfaces are > well defined, and we don't run the risk of having the whole image full of > FFI calls... > In Athens Cairo backend we're using trait TCairoLibrary, which implements single method: #nbLibraryNameOrHandle and still its implementation delegates things to concrete class: nbLibraryNameOrHandle ^ CairoLibraryLoader getLibraryHandle Now there's like 10 or more classes which using this trait. If i put all FFI calls into single class then a) i will not need trait anymore b) i will not need a NB trait as well, because i could just implement own convenience methods in that class and its over but once i will do that, i will produce a god-class which will know everything about cairo and its interfaces. more than that, a certain and convenient uses of FFI callouts will be no longer possible: AthensCairoCanvas>>setSourceR: red g: green b: blue a: alpha <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( void cairo_set_source_rgba ( self , double red, double green, double blue, double alpha) ) instead you will be forced to write it like: AthensCairoCanvas>>setSourceR: red g: green b: blue a: alpha ^ CairoCentral canvas: self setSourceR: red g: green b: blue a: alpha so, instead of single method, which implements given interface (and often it is just enough), you'll have to implement it in central and then in delegate classes. Which basically means doubling number of methods per single FFI call. More code -> more time -> more effort to maintain (and a lot of other 'more's )... second , you cannot use 'self' in function signature, and instead you will be forced to use AthensCairoCanvas * canvas (or similar).. which implies type-check in generated code while for 'self' its not, because if method belongs to certain class it is guaranteed that receiver is always of same type , so you can avoid type check. There's of course many other reasons why i do not like putting everything into single basket: - classes with 100000 methods just stinking badly. Because you can no longer reason & quickly decide whether you need all 100000 or can live with 99999 of them or maybe even 99998. So, i just shown what lies on surface: sure you can isolate all FFI callouts into single module/class.. but separating concerns is much more helpful for development and maintaining code. that's why i love using smalltalk and browser to code instead of C and text editor with single file which holds multi-million lines of source code. -- Best regards, Igor Stasenko.

Nov. 29, 2012

Re: [Pharo-project] NativeBoost extending Object

by Igor Stasenko

On 29 November 2012 00:58, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> On 28 November 2012 22:24, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >>> wrote: >>>> Hi guys, >>>> >>>> Looking at NB methods extending Object I am wandering if it won't be >>> better >>>> to put them in a Trait to be used by any class needing them? >>>> >>> i don't see what you will gain from that, except that you will end up >>> using that trait >>> all over the places? >>> >> What do you understand about all over the places? In my opinion FFI calls >> should be very well isolated >> in specific modules that are meant for that. I think we might have >> different views on this issue... I see using external libraries >> as a limited number of classes (maybe just one in most cases) doing the >> native calls, and then writing a library that relies on these classes >> only for calling the external library. This way the external interfaces are >> well defined, and we don't run the risk of having the whole image full of >> FFI calls... > > I think so too, traits would help limiting the scope of FFI. > > maybe the tools could require some polish, but not using traits won't help ;) > every time one using double negation, a small kitten dies. so, please clarify your statement :) -- Best regards, Igor Stasenko.

Nov. 29, 2012

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

by Nicolas Petton

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

Nov. 28, 2012