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

Re: [Pharo-project] zero conf build

by Camillo Bruni

the scripts starts with #!/bin/bash so IMO you're fine, no? well definitely won't harm to pass it on directly to bash ;) thanks On 2012-10-23, at 00:47, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Camillo Bruni-3 wrote >> curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh > > > If on a system where bash is not the default shell (e.g. Ubuntu 12.04) that > line should be: > > curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | bash > > > > > -- > View this message in context: http://forum.world.st/zero-conf-build-tp4652566p4652567.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 22, 2012

Re: [Pharo-project] zero conf build

by Paul DeBruicker

Camillo Bruni-3 wrote > curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh If on a system where bash is not the default shell (e.g. Ubuntu 12.04) that line should be: curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | bash -- View this message in context: http://forum.world.st/zero-conf-build-tp4652566p4652567.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 22, 2012

[Pharo-project] zero conf build

by Camillo Bruni

I finally managed to create a zero conf pharo image build setup: # =========================================================================== curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh ./vm.sh Pharo.image save $JOB_NAME REPO=http://smalltalkhub.com/mc/dh83/nabujito/main ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfNabujito --install=development ./vm.sh $JOB_NAME.image test --junit-xml-output Nabujito zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes # =========================================================================== ./ciPharo20Cog.sh --help This is an entry point script for any Pharo image CI This script will download the latest Pharo 2.0 image and the latest VM Result in the current directory: vm directory containing the VM vm.sh script forwarding to the VM inside vm/ Pharo.image The latest pharo image Pharo.changes The corresponding pharo changes" # =========================================================================== have fun!

Oct. 22, 2012

Re: [Pharo-project] Hello + postgresql

by roberto.minelli＠usi.ch

Thank you for the answer. Actually I put Pharo in standby for a while (deadlines are coming!) The last thing I tried to do, was a query on a relatively big database (~10m entries) and every time I issued the query, Pharo quitted unexpectedly. As soon as I resume my tests with Pharo, Postgres, OpenDBX, and Glorp I'll for sure get back to you! By now thanks for your answer. Anyway, did someone manage to install OpenDBX on a Mac running Mountain Lion (and Pharo 2.0)? As far as I rememer I had problems in compiling and installing OpenDBX native driver. However, I'll post more detailed question as soon as I resume my tests :) Cheers, Roberto Il giorno 22-ott-2012, alle ore 22:42, "Mariano Martinez Peck" <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> ha scritto: On Fri, Oct 19, 2012 at 6:38 PM, roberto.minelli(a)usi.ch<mailto:roberto.minelli@usi.ch> <roberto.minelli(a)usi.ch<mailto:roberto.minelli@usi.ch>> wrote: I managed to have Pharo 1.4 with a working version of PostgresV2 native driver. I'll try with a fresh image and dbxtalk and let you guys know. You can see our set of tools here: http://dbxtalk.smallworks.com.ar/tools Il giorno 19-ott-2012, alle ore 18:05, "Yanni Chiu" <yanni(a)rogers.com<mailto:yanni@rogers.com>> ha scritto: > On 19/10/12 4:05 AM, roberto.minelli(a)usi.ch<mailto:roberto.minelli@usi.ch> wrote: >> >> I already received some answers, but further hints are appreciated. > > Just download a Pharo-1.4 one-click, and proceed to install and setup up dbxtalk (see: http://dbxtalk.smallworks.com.ar/) The dbxtalk stuff has the option to use the native PostgreSQL driver. > > IMHO, further up front investigation is going to be of limited value. I already tried, tried and tried. I just wrote in the mailing list after severa trials. However next time I'll write when I encounter specific problems ;) > Just dive in, and ask specific questions as you work through it (e.g. where do I find ...? Is ... supposed to be working, because I did ..., and it didn't work). Thank you, > Roberto -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2012

Re: [Pharo-project] Hello + postgresql

by Mariano Martinez Peck

On Fri, Oct 19, 2012 at 6:38 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > I managed to have Pharo 1.4 with a working version of PostgresV2 native > driver. I'll try with a fresh image and dbxtalk and let you guys know. > You can see our set of tools here: http://dbxtalk.smallworks.com.ar/tools > > Il giorno 19-ott-2012, alle ore 18:05, "Yanni Chiu" <yanni(a)rogers.com> ha > scritto: > > > On 19/10/12 4:05 AM, roberto.minelli(a)usi.ch wrote: > >> > >> I already received some answers, but further hints are appreciated. > > > > Just download a Pharo-1.4 one-click, and proceed to install and setup up > dbxtalk (see: http://dbxtalk.smallworks.com.ar/) The dbxtalk stuff has > the option to use the native PostgreSQL driver. > > > > IMHO, further up front investigation is going to be of limited value. > > I already tried, tried and tried. I just wrote in the mailing list after > severa trials. However next time I'll write when I encounter specific > problems ;) > > > Just dive in, and ask specific questions as you work through it (e.g. > where do I find ...? Is ... supposed to be working, because I did ..., and > it didn't work). > > Thank you, > > > Roberto > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2012

Re: [Pharo-project] Hello + postgresql

by Mariano Martinez Peck

On Fri, Oct 19, 2012 at 7:47 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > > > On 19/10/12 12:38 PM, roberto.minelli-BHDiRLqP7qo(a)**public.gmane.org<roberto.minelli-BHDiRLqP7qo(a)public.gmane.org>wrote: > >> I managed to have Pharo 1.4 with a working version of PostgresV2 >> native driver. I'll try with a fresh image and dbxtalk and let you >> guys know. >> > > If the native Postgres driver is good enough for now, there's no need to > bother getting hardware specific opendbx libraries to work. However, the > dbxtalk configuration includes Glorp, which you might want to try out. > > Yes, but still, you can also use Glorp with the native postgres driver if you want. (((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version: with: #stable) load: 'GlorpPostgresV2Native' If you have more questions/problems, please ask :) -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2012

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

by Noury Bouraqadi

Yes. We'll be 6 from Ecole des Mines : Santiago, Nick, Mariano, Jannik (yes he's back :-), Luc, and me. 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. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Ciprian Teodorov

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 <http://www.graphviz.org/>, metis<http://www.cs.umn.edu/~metis>, abc <http://www.eecs.berkeley.edu/~alanmi/abc/>, vpr<http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html>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<http://www.sdml.info/projects/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

Oct. 22, 2012

[Pharo-project] [update 2.0] #20360

by Marcus Denker

20360 ----- Issue 6862: Configation CLI should not distinguish between symbol and strings as version names http://code.google.com/p/pharo/issues/detail?id=6862 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.45.diff -- Marcus Denker -- http://marcusdenker.de

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

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.

Oct. 22, 2012