On Oct 23, 2012, at 7:35 PM, Ciprian Teodorov wrote:
> Hi Igor,
>
> There seems to be an issue with the squeaksource repo... I don't see myself listed amongst the developers nor can I commit
>
> I'm using this connection string:
> MCHttpRepository
> � � location: '
http://www.squeaksource.com/NativeBoost'
>
>
> � � user: 'cip.t'
>
> � � password: '*******'
>
> Cheers
> Ciprian
>
> On Tue, Oct 23, 2012 at 10:20 AM, Igor Stasenko <
siguctua@gmail.com> wrote:
> HI, Ciprian.
> I added you to developers.
>
> Just single comment about auto-generated wrapper(s)/bindings:
> You need to do it only once. Then it will not be needed.
>
> Yes, you can do it automated or manually (automated is preferred), but
> since you do it only once, even if manually, this is not going to be
> too big bottleneck.
> Sure things, having a tool(s) which can automate that would be nice.
> But according to my experience, you can automate it only partially,
> but not fully.
> There , of course, exceptions like OpenGL library which API design
> allows to automate wrapping.
>
> And sure thing it would be nice to have some code generators to import
> from C header(s).
>
>
> On 22 October 2012 19:52, Ciprian Teodorov <
ciprian.teodorov@gmail.com> wrote:
> > Hi guys,
> >
> > First of all sorry for not saying anything the whole day ... but I don't
> > have internet connection at work. I hope I'll be excused though ;)
> >
> > Now it will be a difficult for me to address all the issues raised ...
> > however I will try
> >
> > First of all, IMHO any FFI should facilitate the task of the person writing
> > the library wrapper.
> > This comes the issue of (hopefully automatically) parsing C headers and
> > generating the calls.
> > Why?... well because if I take for instance the BLAS/LAPACK case (which was
> > cited today) have over 1000 functions exported.
> > Even if it is not 1000 lets say that you have a smaller library from which
> > you want to use only one function X but in order to use that precise
> > function you will maybe have to initialize some C context data, or a
> > specific data structure.
> > Of course you can do that by hand, but what if you really want to benefit
> > from the library without diving into the details... well in that case you
> > are a little bit stuck, either you write by hand a bunch of wrappers or you
> > quit.
> >
> > The problem is that nice libraries that you want to use they usually have
> > horrible data structures behind that you cannot set up easily. This happened
> > to me several times in the future while trying to use different external
> > library calls (graphviz, metis, abc, vpr to name a few) in Pharo (with FFI,
> > with Alien, etc). In almost all cases I ended up generating text files and
> > calling some bloody c program using these files as input. The problem is
> > that has a huge impact on performances...
> >
> > Now with nativeboost I found it pretty easy to automatically generate some
> > usable binding... I parsed the C headers with srcml, the I have parsed the
> > XML looking for function definitions... For these definitions I've generated
> > the wrappers. Only that for over 15 argument functions that did not work.
> >
> > Now, I do not like the idea of hacking the compiler, or even subclassing it
> > like Nicolas did for Smallapack. And luckily we do not need to do that with
> > the arguments in an array trick... Moreover, I completely agree with Igor on
> > the fact that 15 arguments are to many, however Pharo really needs to have
> > an automatable FFI generation.
> >
> > Igor, I have seen that you have mentioned some work-arounds using instance
> > variables, and/or NBExternalStructures. Both these ideas are great,
> > especially the use of the NBExternalStructure, however in my opinion if you
> > want to generate them automatically you've got yourself an even bigger
> > problem.
> > Will you generate a new class for each function call that you have?
> > What about the FFI being a wormhole to an ugly and mean world?
> > I think we should try to reduce the size of that hole ;)
> > Though, you have a point with using named arguments, and I think that is a
> > cool solution too. That is why I was speaking about directly accessing the
> > instance variables by name.
> > I simply didn't know enough about the hidden powers of NBExternalStructure.
> > ;)
> >
> > As for extending the nativeboost signatures and accessing object fields by
> > name, I completely agree with you that it is not a good idea.
> >
> > However, using the indices of arrays I think is only a small addition that
> > can have a huge impact on the way people use NativeBoost FFI without adding
> > to much extra-overhead.
> > By the way, I think we definitely have to do the bound-checking trick by
> > default.
> > Moreover, having the NBSTInObjectArgument as a wrapper over another loader
> > is a great idea, giving us another degree of "controlled" freedom. ;)
> >
> > Thanks Henrik for the good joke (I didn't see it coming :)), It makes me
> > hate this idea now. :P
> >
> > self callFn: {x . y}
> > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , )
> > I for one welcome our new syntactic overlords!
> >
> > As for supporting or not more than 15 arguments for typical method calls...
> > I don't know... maybe is good maybe is bad, but I think there are other
> > things that need to be done before making a fuss about it. By the way is it
> > an arbitrary limit, or it is imposed by the use of 4 bytes for storing the
> > number of arguments?
> >
> > Now let me come back to practical issues. My squeaksource id is cip.t (you
> > can find me searching "ciprian" in the members list).
> >
> > Cheers,
> > Ciprian Teodorov
> >
> >
> >
> >
> >
> > On Mon, Oct 22, 2012 at 1:09 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
> >>
> >> On 22 October 2012 12:00, Henrik Sperre Johansen
> >> <
henrik.s.johansen@veloxit.no> wrote:
> >> > On 22.10.2012 02:37, Igor Stasenko wrote:
> >> >>
> >> >> On 22 October 2012 01:59, Nicolas Cellier
> >> >> <
nicolas.cellier.aka.nice@gmail.com> wrote:
> >> >>>
> >> >>> 2012/10/22 Igor Stasenko <
siguctua@gmail.com>:
> >> >>>>
> >> >>>> On 22 October 2012 01:20, Nicolas Cellier
> >> >>>> <
nicolas.cellier.aka.nice@gmail.com> wrote:
> >> >>>>>
> >> >>>>> 5 parameters???? Igor, you're a dictator ;)
> >> >>>>> Those theories are nice, but unhelpfull when applied to FFI
> >> >>>>> Pragmatically there's not any chance I rewrite LAPACK+BLAS for the
> >> >>>>> sake of purity.
> >> >>>>>
> >> >>>>> And your workaround (creating a class) is very poor, because maybe
> >> >>>>> classes themselves should not have more than 5 instance variables ;)
> >> >>>>>
> >> >>>> Hehe.
> >> >>>> This is same thing like increasing number of literals for methods
> >> >>>> (and
> >> >>>> max distances between jumps).
> >> >>>> It just makes sense where you deal with external chaotic world.
> >> >>>> My ideology is simple: prevent that chaos from entering our little
> >> >>>> peaceful bay.
> >> >>>>
> >> >>> That's not exactly the philosophy behind FFI.
> >> >>> FFI is here to let the user manage the external chaotic world.
> >> >>> OK, external peels of the onion should have 5 parameters or less.
> >> >>> Near the sprout, you can't raise such barriers, or there is no onion
> >> >>> at
> >> >>> all.
> >> >>>
> >> >> Well, that's part of developer's responsibility, how to prevent chaos.
> >> >> Needless to say, nobody wants to deal with so many arguments at once
> >> >> (too much space for mistakes).
> >> >> As for my workaround: this mainly, how you tame the complexity in case
> >> >> it is inevitable?
> >> >> Look how code to call that function will look like:
> >> >>
> >> >> 1. passing as array
> >> >>
> >> >> args := Array new: 100.
> >> >> args at:1 put: x;
> >> >> at:2 put: y;
> >> >> � ...
> >> >> at: 100 put: zork
> >> >>
> >> >> self callFn: args.
> >> >
> >> > self callFn: {x . y}
> >> > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , )
> >> > I for one welcome our new syntactic overlords!
> >> >
> >>
> >> Yes, it looks familiar, but cannot tell where i seen it.
> >> Gah.. how i could forget about it?
> >>
> >>
> >> >>
> >> >> 2. passing as instance of class, or external structure:
> >> >>
> >> >> args := MyFunctionArgs new.
> >> >> args
> >> >> � firstArgumentName: x;
> >> >> � secondArgumentName: y;
> >> >> � ...
> >> >> � hundrethArgumentName: zork.
> >> >> self callFn: args.
> >> >>
> >> >> admit that dealing with names instead of numbers leaves much less
> >> >> space for mistakes
> >> >> and serves for better clarity at same time.
> >> >> So, even if it is more cumbersome because requires defining extra
> >> >> class, at the end you win much more.
> >> >>
> >> >> Anyways, if people think it is worth adding indirect argument loader (
> >> >> in form of param@<index>, but not param@ivar), we can introduce that.
> >> >>
> >> > While I often find this a good idea for maintainability, it sorta flies
> >> > in
> >> > the face of another of ST's strengths, iterative/exporatory programming.
> >> > If you are forced to think up front about which parameter classes you
> >> > need
> >> > due to a small limit, rather than introduce them ad-hoc when the code
> >> > really
> >> > needs the refactoring to remain legible, it slows you down.
> >> >
> >> > Not thinking of FFI specifically, but I have seen lots of evolved
> >> > mathematical models where a 5-parameter limit upfront would probably
> >> > lead to
> >> > either:
> >> > a) *Really* bad code, ie. making the calculation object stateful by
> >> > storing
> >> > in instvars instead. (and in the process, make it really hard to know
> >> > which
> >> > instvars are actually part of object state and not temp vars of some
> >> > calculation)
> >> > b) Switching to another programming language out of frustration.
> >> >
> >>
> >> keyword message syntax is bad for many arguments..
> >> for such cases i find a positional argument notation more appeal
> >> because it is more compact.
> >> In any case, a complex math formulas smell equally bad in any
> >> programming language
> >> (sometime even if written by hand on paper using math notation(s) ;)
> >>
> >> > Cheers,
> >> > Henry
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko.
> >>
> >
> >
> >
> > --
> > Dr. Ciprian TEODOROV
> > Ing�nieur D�veloppement CAO
> >
> > t�l : 06 08 54 73 48
> > mail :
ciprian.teodorov@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@gmail.com
>
www.teodorov.ro