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

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

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

by Camillo Bruni

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. >

Nov. 28, 2012

[Pharo-project] Athens + Amber + HTML5 canvas

by Igor Stasenko

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.

Nov. 28, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Igor Stasenko

Apart from this, there is new primitive: 220. If Camillo will make changes, then it will be either plugin primitive or 220. I am in favor of migrating stuff to 220 (because it is much faster) but before we will have fully functional prim220 code generator support, i think we should keep both. because then i can tell which prim i wanna use by putting either: <primitive:220 error: errorCode> or <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> and code may vary because convention is different. So, i do not see how you can safely assume that "everything which does not have primitive pragma, should use one of these" On 26 November 2012 21:42, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > I don't know exactly why... but I tend to agree with Igor with this one... > It's not that I like copy/paste, or that the <..> pragma is sexy but it > seems to me that there will be too much going on under the hood > :) yeah.. what can i say.. jumping from high level to very low level penetrating multiple layers of abstraction.. what you expected? :) But the fun part is that it demonstrates quite clearly: you can use high-level language for low-level stuff quite easy and efficient. > but ... well I hope at least that the user will see the pragma to understand > that something funky is going on > > -- > Ciprian > > > On Mon, Nov 26, 2012 at 5:57 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: >> -- Best regards, Igor Stasenko.

Nov. 28, 2012

Re: [Pharo-project] NativeBoost extending Object

by Igor Stasenko

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? Imo extension to Object is fine. All methods use namespace prefix, so there is a little chance to clash with some other project/package. 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.. > 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. > 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. > (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.

Nov. 28, 2012

Re: [Pharo-project] Getting started with Athens

by Casimiro de Almeida Barreto

On 28-11-2012 19:15, Igor Stasenko wrote: > On 28 November 2012 21:11, Casimiro de Almeida Barreto > <casimiro.barreto(a)gmail.com> wrote: >> In Fedora 17 it seems to be a CogVM problem. >> For instance, if I compile the B3DAccelerationPlugin as internal plugin, >> then OpenGL works OK. Otherwise it fails because libGL is not found. >> > hmm.. how is this related to NB/Athens? Same sort of thing happens on NativeBoost (unresolved links) > >> I had this problem before, just forgot about it (using stackVM). >> >> If someone know how to fix the problem I'm all ears. >> >> PS: I've tried all tricks concerning ld.conf.so, LD_LIBRARY_PATH, etc. >> >> > I don't know why things don't work on fedora.. > is its kernel supports dlopen()/dlsym() functions? > because if yes, you can use them to load libs.. and getting functions. >

Nov. 28, 2012

[Pharo-project] NativeBoost extending Object

by Ciprian Teodorov

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? 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. This way we won't need to extend Object anymore... Igor, what do you think? (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

Nov. 28, 2012

Re: [Pharo-project] Getting started with Athens

by Igor Stasenko

On 28 November 2012 21:11, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > In Fedora 17 it seems to be a CogVM problem. > For instance, if I compile the B3DAccelerationPlugin as internal plugin, > then OpenGL works OK. Otherwise it fails because libGL is not found. > hmm.. how is this related to NB/Athens? > I had this problem before, just forgot about it (using stackVM). > > If someone know how to fix the problem I'm all ears. > > PS: I've tried all tricks concerning ld.conf.so, LD_LIBRARY_PATH, etc. > > I don't know why things don't work on fedora.. is its kernel supports dlopen()/dlsym() functions? because if yes, you can use them to load libs.. and getting functions. -- Best regards, Igor Stasenko.

Nov. 28, 2012