- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] NativeBoost extending Object

by Camillo Bruni

>> 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 ;)

Nov. 28, 2012

Re: [Pharo-project] NativeBoost extending Object

by Camillo Bruni

> > What i dislike about traits that if it used multiple times, > browsing implementors of trait method will give you list of all very > same methods > where that trait is used. > So, if you not careful enough, you can mistakenly change method for a > single class, > instead of modifying trait method.. nope this does no longer happen in 2.0, I change implementors/senders to only show the method definitions. So trait methods are only shown on traits. aka, random changes don't happen that easily anymore

Nov. 28, 2012

Re: [Pharo-project] NativeBoost extending Object

by Ciprian Teodorov

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... > Imo extension to Object is fine. All methods use namespace prefix, so > there is a little chance to clash with some other project/package. yes I agree namespace prefix protects us somehow (at the same time I'm looking the whole day at C code with company_library_MyFoo(x, y, z) calls and I don't like it) > What i dislike about traits that if it used multiple times, > browsing implementors of trait method will give you list of all very > same methods > where that trait is used. > So, if you not careful enough, you can mistakenly change method for a > single class, > instead of modifying trait method.. > > This sucks, but I think that it is not an issue, maybe someday the traits will get the attention they deserve, and somebody will fix this problem. I'm a dreamer maybe... but well > > As for ByteArray maybe instead of using the methods inherited from Object > > maybe we can use a double-dispatch scheme to delegate NB calls to another > > class. > > > > i see that you want to avoid duplicated code. > but delegation will cost 1 more message send. > while i actually wondering if we need those extensions at all. > except from some important ones (internally by NB), i don't think that > using nbXAtOffset: > is good practice. > I think that people should use more higher level abstractions for > working with data. > those methods providing direct access to memory (with all possible > consequences).. > so one should use them only if there's no better/more elegant way. > > > So, even if you put implementation into single class, it won't make > things less bloated: > you will still have to provide a 'delegation methods' , i.e.: > > nbXXXAtOffset: offset > ^ SomeGuyInCharge doXXXAtOffset: offset for: self > > which won't make number of methods any bit smaller. > that's why i asking , what if better would be to look for a ways how > we can get rid of all of them instead.. > and provide something better in exchange. > > I completely agree with you on this... > > This way we won't need to extend Object anymore... > > > > Igor, what do you think? > > > well, extensions were put for reason: to avoid using globals and to > make things more convenient to use. > > don't let me wrong: i don't like extending Object.. especially > over-extending: right now it is 9 extension methods. > I'd rather consider if we can shrink that protocol to remove: > nbCall: fnSpec module: aModuleNameOrHandle options: callOptions > nbCall: fnSpec options: callOptions > nbCall: fnSpec module: aModuleNameOrHandle > nbCall: fnSpec > > since new api, which i introduced recently, provides similar abilities > without need of polluting > any class(es) protocols more than necessary. > > Yep your new API is cool I like it... I hope I'm not bothering you too much with these small things... By the way did you see my last mail about structs, and enums...? good night > > > (if you agree I will do it for NB)... I don't know if that will play well > > with existing NB-based projects though (Athens, NBOpenGL, etc...) > > But I think it is worth it on the long run... > > > > Cheers, > > -- > > 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. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 28, 2012