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

Re: [Pharo-project] SSL Failing on Mac

by Igor Stasenko

On 25 October 2012 01:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > On Mac Lion, when I use a VM from the Zodiac one-click, everything works, but > when I use the latest from Jenkins (from the latest "failed" build, which > built for Mac, but just failed for Windows), I get: > "PrimitiveFailed: primitive #primitiveSSLCreate in a ZdcPluginSSLSession > failed" > > Any ideas? > I have some: - add tests to check if it works. So we will know if it functional or not before people will start using it and find by themselves :) > Thanks, > Sean > > > > -- > View this message in context: http://forum.world.st/SSL-Failing-on-Mac-tp4652872.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Oct. 25, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

On 24 October 2012 21:55, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > I finally managed to commit the stuff. > Now I looked a little bit into the idea of generalizing it to work with any > loader, which seems to work pretty much. Now I have two questions: > First of all, what about #argName:type:arity? Should we remove it and > replace it everywhere with #argName:indirectIndex:type:arity ? Or we should > keep it? I don't quite grasp the impact such a change will have on the whole > machinery (Ex. NBNativeFunctionGen, and NativeArgument). > This is a contract between parser and its requestor. Since we changing contract, all requestors should use new protocol. NBNativeFunctionGen can simply ignore that, because they don't handle smalltalk objects. NativeArgument is encapsulation of parsed argument. But since index transformed into different loader, there no need to change anything for it. > Secondly, i was thinking about ways to check the indirect bounds... and I'm > quite dry of ideas... Is there any generic way to check the bounds of an > object, or we should do that on a case by case basis? Typically I would > think that we need something that gives us the size of an object in bytes, > however I'm not sure that all our objects are contiguous in memory (or if > they are that they will be like that forever), moreover what about > smallintegers? Should we restrict the approach to Arrays only? > Look at InterpreterProxy, it has such functionality. And sure thing smallints should no be allowed. But if you find it hard to implement, just leave 'self halt' there, and meanwhile use callouts with option to check bounds turned off. I will implement that later. > well that's it for now > Cheers, > Ciprian > > > On Wed, Oct 24, 2012 at 8:47 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> May be we should ask dave mason because he wrote a C header parser or >> something like that. >> >> 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(a)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(a)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(a)gmail.com> >> > > wrote: >> > >> >> > >> On 22 October 2012 12:00, Henrik Sperre Johansen >> > >> <henrik.s.johansen(a)veloxit.no> wrote: >> > >> > On 22.10.2012 02:37, Igor Stasenko wrote: >> > >> >> >> > >> >> On 22 October 2012 01:59, Nicolas Cellier >> > >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > >> >>> >> > >> >>> 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: >> > >> >>>> >> > >> >>>> On 22 October 2012 01:20, Nicolas Cellier >> > >> >>>> <nicolas.cellier.aka.nice(a)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(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 >> >> > > > > -- > 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.

Oct. 25, 2012

[Pharo-project] SSL Failing on Mac

by Sean P. DeNigris

On Mac Lion, when I use a VM from the Zodiac one-click, everything works, but when I use the latest from Jenkins (from the latest "failed" build, which built for Mac, but just failed for Windows), I get: "PrimitiveFailed: primitive #primitiveSSLCreate in a ZdcPluginSSLSession failed" Any ideas? Thanks, Sean -- View this message in context: http://forum.world.st/SSL-Failing-on-Mac-tp4652872.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 24, 2012

[Pharo-project] Confused about SSL Plugin dependencies

by Sven Van Caekenberghe

Assuming http://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=linux… as linked from http://www.pharo-project.org/pharo-download is the official Linux VM used by the whole build process, I am confused about the dependencies of the shipped SSL plugin. On my Ubuntu machine, the following output is of the working plugin: ubuntu@ip-10-48-234-254:~/experimental$ ldd bin/libSqueakSSL.so linux-gate.so.1 => (0xb7702000) libm.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libm.so.6 (0xb76c6000) libdl.so.2 => /lib/i386-linux-gnu/tls/i686/nosegneg/libdl.so.2 (0xb76c1000) libpthread.so.0 => /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0 (0xb76a6000) libssl.so.0.9.8 => /lib/i386-linux-gnu/libssl.so.0.9.8 (0xb7657000) libc.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6 (0xb74ad000) /lib/ld-linux.so.2 (0xb7703000) libcrypto.so.0.9.8 => /lib/i386-linux-gnu/libcrypto.so.0.9.8 (0xb7334000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb731e000) While the following output is of the non-working version downloaded from the links above ubuntu@ip-10-48-234-254:~/experimental$ ldd pharocog/libSqueakSSL.so linux-gate.so.1 => (0xb77a7000) libssl.so.6 => not found libc.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6 (0xb75ee000) /lib/ld-linux.so.2 (0xb77a8000) What package has to be installed to resolve this dependency ? Against which library was this variant of the SSL plugin built ? I alread have both the following ubuntu@ip-10-48-234-254:~/experimental$ aptitude search "~i" | grep ssl i A libio-socket-ssl-perl - Perl module implementing object oriented i i A libnet-ssleay-perl - Perl module for Secure Sockets Layer (SSL) i libssl0.9.8 - SSL shared libraries i A libssl1.0.0 - SSL shared libraries i openssl - Secure Socket Layer (SSL) binary and relat i python-openssl - Python wrapper around the OpenSSL library i A ssl-cert - simple debconf wrapper for OpenSSL Thx, Sven

Oct. 24, 2012

Re: [Pharo-project] NativeBoost FFI

by Ciprian Teodorov

Hi Igor, I finally managed to commit the stuff. Now I looked a little bit into the idea of generalizing it to work with any loader, which seems to work pretty much. Now I have two questions: First of all, what about #argName:type:arity? Should we remove it and replace it everywhere with #argName:indirectIndex:type:arity ? Or we should keep it? I don't quite grasp the impact such a change will have on the whole machinery (Ex. NBNativeFunctionGen, and NativeArgument). Secondly, i was thinking about ways to check the indirect bounds... and I'm quite dry of ideas... Is there any generic way to check the bounds of an object, or we should do that on a case by case basis? Typically I would think that we need something that gives us the size of an object in bytes, however I'm not sure that all our objects are contiguous in memory (or if they are that they will be like that forever), moreover what about smallintegers? Should we restrict the approach to Arrays only? well that's it for now Cheers, Ciprian On Wed, Oct 24, 2012 at 8:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > May be we should ask dave mason because he wrote a C header parser or > something like that. > > 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(a)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(a)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(a)gmail.com> > wrote: > > >> > > >> On 22 October 2012 12:00, Henrik Sperre Johansen > > >> <henrik.s.johansen(a)veloxit.no> wrote: > > >> > On 22.10.2012 02:37, Igor Stasenko wrote: > > >> >> > > >> >> On 22 October 2012 01:59, Nicolas Cellier > > >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > >> >>> > > >> >>> 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: > > >> >>>> > > >> >>>> On 22 October 2012 01:20, Nicolas Cellier > > >> >>>> <nicolas.cellier.aka.nice(a)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(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 > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Oct. 24, 2012

[Pharo-project] We are looking for two logos for the Pharo Consortium

by StÃ©phane Ducasse

Hi Pharo is looking for a logo for the Consortium Member - As a member of the consortium we would like companies to be able to put a logo on their web site. - we would like to have the same for the association member. Does anybody want to propose some logos? Pharo Consortium Member is a real challenge :) Stef

Oct. 24, 2012

Re: [Pharo-project] NativeBoost FFI

by StÃ©phane Ducasse

May be we should ask dave mason because he wrote a C header parser or something like that. 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(a)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(a)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(a)gmail.com> wrote: > >> > >> On 22 October 2012 12:00, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >> > On 22.10.2012 02:37, Igor Stasenko wrote: > >> >> > >> >> On 22 October 2012 01:59, Nicolas Cellier > >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >>> > >> >>> 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: > >> >>>> > >> >>>> On 22 October 2012 01:20, Nicolas Cellier > >> >>>> <nicolas.cellier.aka.nice(a)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(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

Oct. 24, 2012

Re: [Pharo-project] NativeBoost VM on Windows

by StÃ©phane Ducasse

> >> you mean you will release them outside jenkins ? >> > no. I mean release on jenkins ;) > Anything outside jenkins is not exists. Yes I love that statement Automated tasks to team complexity. Free our energy for non stupid tasks robots can do!!!

Oct. 24, 2012

Re: [Pharo-project] [Pharo-users] [Call for Participation] Pharo Sprint Nov 2

by StÃ©phane Ducasse

massive :) > Yes. We'll be 6 from Ecole des Mines : Santiago, Nick, Mariano, Jannik (yes he's back :-), Luc, and me. So we should go an buy cookies and drinks Stef > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://car.mines-douai.fr/noury > > On 22 oct. 2012, at 12:08, Santiago Bragagnolo wrote: > >> i'm going >> >> 2012/10/22 Marcus Denker <marcus.denker(a)inria.fr> >> RMoD is organizing a Pharo Sprint >> >> â¢ When? Fr, Nov 2nd. Starting at 9am >> â¢ Where? INRIA Lille, Building B. http://www.inria.fr/centre/lille >> >> The plan is to push together to evaluate which bugs need to be fixed before a release (and of course fix as many as possible). >> Please contact us if you plan to attend until 30/10! >> >> http://rmod.lille.inria.fr/web/pier/Events/PharoSprintNov12 >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > > Noury Bouraqadi > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > >

Oct. 24, 2012

Re: [Pharo-project] 1/2 hour

by StÃ©phane Ducasse

Hi joe did you sign the license agreement? Stef On Oct 24, 2012, at 4:14 PM, Joe Rickerby wrote: > I'd be very happy if hour just returned the same as hours. I can also make the change, but I've never done one before, do I submit it to Pharo inbox? > > On 24 Oct 2012, at 2:28pm, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> the current implementation does not make any sense. >> despite the grammatical correctness of (1 hour) and the implied >> mistake of (2 hour). I think we should change or remove it! >> >> https://code.google.com/p/pharo/issues/detail?id=6876 >> >> >> >> On 2012-10-24, at 14:52, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: >>> If it not use I don't know but the message >>> 1 hour >> >> yes, but technically 0.5 hour is correct (though silly it does not work >> properly..) >> >>> makes sense to me. >>> >>> cheers, >>> Fabrizio >>> >>> 2012/10/24 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> >>> >>>> I found almost no senders of #Number>>hour, and also have not sense at >>>> all. Probably we want to remove it. >>>> >>>> >>>> 2012/10/24 Joe Rickerby <joe.rickerby(a)square-i.net> >>>> >>>>> I can't believe I'd be the first person to find this, so sorry if this >>>>> has been discussed before. >>>>> >>>>> I was writing some code today, using Durations. I've come across the >>>>> hour/hours methods before, and so I know that '2 hour' is really one hour, >>>>> and that you have to write '2 hours' to have the thing work as expected. >>>>> >>>>> It's a little strict for the language to do this, but I can see the logic. >>>>> >>>>> What doesn't work for me is when I write '0.5 hour' or '(1/2) hour'. Both >>>>> will return a duration of 1 hour. In my head I pronounce this 'half an >>>>> hour', so it's an entirely reasonable thing to write. >>>>> >>>>> Can something be done about this? >>>>> >>>>> Joe >> >> > > > Joe Rickerby > Software Developer > > Square [i] International > 41 Maltby Street > London > > http://www.square-i.net > > P Please consider the environment before printing this email > > This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. Square Group does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not represent those of Square Group Ltd unless otherwise specifically stated. While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient. >

Oct. 24, 2012