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

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

Stick around. Have you noticed that some of what I am "taking" is going into an interface to GSL? When I am finally able to "take" something that provides callbacks, you will be in for a shock. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Wednesday, October 06, 2010 2:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments Bill, On Wed, Oct 6, 2010 at 10:24 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Miguel, I do not "need" to make the call. I am wondering whether I can do so in a way that will benefit others, or I should just say the hell with it and either provide similar functionality a different way or provide the same functionality via a .so of my own creation. The latter is fine for me but does not do much for anyone else. And let's say I make it and the thing seg faults. How can I tell the difference between a limitation of the plugin or a mistake on my part calling a fairly cumbersome function? The answer: I can't, not without work that I cannot justify doing when a ready solution exists. You can. You're just too lazy to try. You need to read (at least) http://en.wikipedia.org/wiki/Reciprocal_altruism. I share Miguel's and Nicolas' impressions of you. I see you taking much more than you give and it's straining my patience. Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>] Sent: Wednesday, October 06, 2010 12:52 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] FFI number of arguments El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: > Miguel, > > I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. The Pharo archives are then a more rich resource they than had been. I happen to know it works, because many of the helpful messages I find are in fact mine. > > As for whether I could "easily" make the call in question: give me a break. It has roughly 20 arguments, and would be a fair amount of work to set up. If someone else knows one way or the other, it might trigger either a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? You might read what I asked: "have you tried this?" Not "please do this for me." It would be wasteful to attempt the call without asking for scouting reports. > But in the end if you really need to use that call, either it works or don't, you'll need to write it, even if someone says that it doesn't work. Why, because you need it, and if you don't need it then your question is rhetoric, because you don't even mind the answer. You can't ask for advise for every and each step you take, most times you should walk away, _fix_ what you find wrong and then report back the fix. That would really make the archives more rich because you are contributing back real knowledge and maybe code and not just polluting the archives with threads that ask things but solve nothing for anyone but you. Cheers > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>] > Sent: Wednesday, October 06, 2010 12:13 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > > Levente, > > > > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? > > > > But Bill, almost all your questions are long and without apparent focus > on the real point. Some other times are like this, things that you could > easily test by yourself maybe in less time that takes you to write so > many words, send the email and wait for a response from someone willing > to decipher what the real problem is. Other times you point at problems > that you find in your environment without giving better hints than "in a > hopefully updated image", "in a, I think, not modified image", "in my > machine", that doesn't help in helping you. > Then you point some problems that it appears that are very evident to > you and whose solution is also very obvious to you but you don't provide > a fix for them neither, like the always topic of yours about sockets. > > Then when someone points and the obvious things you should do (your > homework, in verifying yourself what you are asking to the list) or to > precise the information needed to better answer you, you respond upset > as if anyone should be obliged to answer you or even read your mails. > > So, please, read > > http://www.catb.org/esr/faqs/smart-questions.html > > do your homework and then ask the list. > > > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] > > Sent: Tuesday, October 05, 2010 11:09 PM > > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > Subject: Re: [Pharo-project] FFI number of arguments > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? > > > > It works up to 128 arguments. But why don't you try it yourself? > > > > > > Levente > > > > > > > > > > > > > > ________________________________________ > > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] > > > Sent: Tuesday, October 05, 2010 10:26 PM > > > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > > Subject: Re: [Pharo-project] FFI number of arguments > > > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > >> Hello all, > > >> > > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: > > >> > > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > > >> > > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > > > > > You can create your own function object and invoke it with an array. > > > Here's an fprintf example on windows: > > > > > > fprintf := ExternalLibraryFunction > > > name: 'fprintf' > > > module: 'msvcrt.dll' > > > callType: ExternalFunction callTypeCDecl > > > returnType: ExternalType signedLong > > > argumentTypes: { > > > (ExternalType structTypeNamed: #FILE) asPointerType. > > > ExternalType string. > > > ExternalType signedLong }. > > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > > Stdio default fcloseWith: file. > > > > > > > > > Levente > > > > > > P.S.: Note that you need the FILE and Stdio classes to run this example. > > > > > >> > > >> Bill > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

Nicolas, The "not trivial" did indeed reduce my interest. I can get around it for my own needs far more easily than taking a detour. If a detour is required, then economics will all but force me to take the more sensible path. The question is whether you get a PLplot interface with or without legend support. I get it either way. So much for this mattering only to me (not directed at you). If you look on the PLplot lists, you will find some discussion of the function's design; IMHO, it's not optimal. However, as most things in PLplot, it works; see link below. The options are: (1) call the function as designed (hence my question) (2) use a viewport to make a new coordinate system inside the graph and draw "the hard way" relative to it (3) wrap pllegend() in a .so of my own; five minutes later, I'm calling a restricted functionality version with defaults of value to me. Even I am not thrilled about (3), if only because of linking hassles from my .so to theirs, but it would be quick. (2) is questionable. I have used viewports very successfully to make grids of related graphs and to do limited versions of what gnuplot does with "y2." In this case, it has the potential to turn into a bit of a time sink, and then the question arises "why am I doing it?" If it is just to spread around the benefits of legend support, I probably have to rethink it. If it is better for all of us ("us" is complicated), then it's on the table. Bill http://plplot.sourceforge.net/examples.php?demo=26 ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Wednesday, October 06, 2010 2:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments Hi Bill, I somehow share some of Miguel impressions. Some (most) of your messages are too verbose for me, and - no offense - I often discard them, though I may have a solution to propose. It's hard to understand if our answer was helpful or not, if some details should be changed etc... In one word I've got the feeling to give, but not to share. Maybe my english level is just too low, but you know, these lists are rather international. Sorry for the rant, but please, help us to help you. Back to the technical problem, did the updated version at http://www.squeaksource.com/Smallapack/Compiler-nice.150.mcz help, or did my words "not trivial" stopped you? Nicolas 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Miguel, > > I do not "need" to make the call. I am wondering whether I can do so in a way that will benefit others, or I should just say the hell with it and either provide similar functionality a different way or provide the same functionality via a .so of my own creation. The latter is fine for me but does not do much for anyone else. > > And let's say I make it and the thing seg faults. How can I tell the difference between a limitation of the plugin or a mistake on my part calling a fairly cumbersome function? The answer: I can't, not without work that I cannot justify doing when a ready solution exists. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:52 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: >> Miguel, >> >> I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. The Pharo archives are then a more rich resource they than had been. I happen to know it works, because many of the helpful messages I find are in fact mine. >> >> As for whether I could "easily" make the call in question: give me a break. It has roughly 20 arguments, and would be a fair amount of work to set up. If someone else knows one way or the other, it might trigger either a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? You might read what I asked: "have you tried this?" Not "please do this for me." It would be wasteful to attempt the call without asking for scouting reports. >> > > But in the end if you really need to use that call, either it works or > don't, you'll need to write it, even if someone says that it doesn't > work. Why, because you need it, and if you don't need it then your > question is rhetoric, because you don't even mind the answer. > You can't ask for advise for every and each step you take, most times > you should walk away, _fix_ what you find wrong and then report back the > fix. That would really make the archives more rich because you are > contributing back real knowledge and maybe code and not just polluting > the archives with threads that ask things but solve nothing for anyone > but you. > > Cheers > > >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] >> Sent: Wednesday, October 06, 2010 12:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI number of arguments >> >> El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: >> > Levente, >> > >> > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? >> > >> >> But Bill, almost all your questions are long and without apparent focus >> on the real point. Some other times are like this, things that you could >> easily test by yourself maybe in less time that takes you to write so >> many words, send the email and wait for a response from someone willing >> to decipher what the real problem is. Other times you point at problems >> that you find in your environment without giving better hints than "in a >> hopefully updated image", "in a, I think, not modified image", "in my >> machine", that doesn't help in helping you. >> Then you point some problems that it appears that are very evident to >> you and whose solution is also very obvious to you but you don't provide >> a fix for them neither, like the always topic of yours about sockets. >> >> Then when someone points and the obvious things you should do (your >> homework, in verifying yourself what you are asking to the list) or to >> precise the information needed to better answer you, you respond upset >> as if anyone should be obliged to answer you or even read your mails. >> >> So, please, read >> >> http://www.catb.org/esr/faqs/smart-questions.html >> >> do your homework and then ask the list. >> >> >> >> >> > >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> > Sent: Tuesday, October 05, 2010 11:09 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] FFI number of arguments >> > >> > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: >> > >> > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? >> > >> > It works up to 128 arguments. But why don't you try it yourself? >> > >> > >> > Levente >> > >> > > >> > > >> > > >> > > ________________________________________ >> > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> > > Sent: Tuesday, October 05, 2010 10:26 PM >> > > To: Pharo-project(a)lists.gforge.inria.fr >> > > Subject: Re: [Pharo-project] FFI number of arguments >> > > >> > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: >> > > >> > >> Hello all, >> > >> >> > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: >> > >> >> > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… >> > >> >> > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? >> > > >> > > You can create your own function object and invoke it with an array. >> > > Here's an fprintf example on windows: >> > > >> > > fprintf := ExternalLibraryFunction >> > > name: 'fprintf' >> > > module: 'msvcrt.dll' >> > > callType: ExternalFunction callTypeCDecl >> > > returnType: ExternalType signedLong >> > > argumentTypes: { >> > > (ExternalType structTypeNamed: #FILE) asPointerType. >> > > ExternalType string. >> > > ExternalType signedLong }. >> > > file := Stdio default fopenWith: 'test.txt' with: 'w'. >> > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. >> > > Stdio default fcloseWith: file. >> > > >> > > >> > > Levente >> > > >> > > P.S.: Note that you need the FILE and Stdio classes to run this example. >> > > >> > >> >> > >> Bill >> > >> >> > >> >> > >> _______________________________________________ >> > >> Pharo-project mailing list >> > >> Pharo-project(a)lists.gforge.inria.fr >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > Pharo-project(a)lists.gforge.inria.fr >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > Pharo-project(a)lists.gforge.inria.fr >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Eliot Miranda

Bill, On Wed, Oct 6, 2010 at 10:24 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Miguel, > > I do not "need" to make the call. I am wondering whether I can do so in a > way that will benefit others, or I should just say the hell with it and > either provide similar functionality a different way or provide the same > functionality via a .so of my own creation. The latter is fine for me but > does not do much for anyone else. > > And let's say I make it and the thing seg faults. How can I tell the > difference between a limitation of the plugin or a mistake on my part > calling a fairly cumbersome function? The answer: I can't, not without work > that I cannot justify doing when a ready solution exists. > You can. You're just too lazy to try. You need to read (at least) http://en.wikipedia.org/wiki/Reciprocal_altruism. I share Miguel's and Nicolas' impressions of you. I see you taking much more than you give and it's straining my patience. Eliot > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [ > miguel.coba(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:52 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: > > Miguel, > > > > I see it very differently: I do extensive searches and summarize the > results, dropping keywords along the way that I wish had been present in > what I finally uncovered somewhere else. The Pharo archives are then a more > rich resource they than had been. I happen to know it works, because many > of the helpful messages I find are in fact mine. > > > > As for whether I could "easily" make the call in question: give me a > break. It has roughly 20 arguments, and would be a fair amount of work to > set up. If someone else knows one way or the other, it might trigger either > a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell > for that, the plugin choked on...." Restating what I linked from another > group is not helpful, nor is telling me how easy it would be to do something > that you have never seen. Did it occur to you that there might be pointer > arguments that would be a potential sources of complexity? You might read > what I asked: "have you tried this?" Not "please do this for me." It would > be wasteful to attempt the call without asking for scouting reports. > > > > But in the end if you really need to use that call, either it works or > don't, you'll need to write it, even if someone says that it doesn't > work. Why, because you need it, and if you don't need it then your > question is rhetoric, because you don't even mind the answer. > You can't ask for advise for every and each step you take, most times > you should walk away, _fix_ what you find wrong and then report back the > fix. That would really make the archives more rich because you are > contributing back real knowledge and maybe code and not just polluting > the archives with threads that ask things but solve nothing for anyone > but you. > > Cheers > > > > Bill > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [ > miguel.coba(a)gmail.com] > > Sent: Wednesday, October 06, 2010 12:13 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI number of arguments > > > > El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > > > Levente, > > > > > > What problem do you have with asking whether someone else has already > tried it? Really, have you not seen examples of working hard on advice from > one source only to discover yet another limit that was not in fine print? > > > > > > > But Bill, almost all your questions are long and without apparent focus > > on the real point. Some other times are like this, things that you could > > easily test by yourself maybe in less time that takes you to write so > > many words, send the email and wait for a response from someone willing > > to decipher what the real problem is. Other times you point at problems > > that you find in your environment without giving better hints than "in a > > hopefully updated image", "in a, I think, not modified image", "in my > > machine", that doesn't help in helping you. > > Then you point some problems that it appears that are very evident to > > you and whose solution is also very obvious to you but you don't provide > > a fix for them neither, like the always topic of yours about sockets. > > > > Then when someone points and the obvious things you should do (your > > homework, in verifying yourself what you are asking to the list) or to > > precise the information needed to better answer you, you respond upset > > as if anyone should be obliged to answer you or even read your mails. > > > > So, please, read > > > > http://www.catb.org/esr/faqs/smart-questions.html > > > > do your homework and then ask the list. > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > > > Sent: Tuesday, October 05, 2010 11:09 PM > > > To: Pharo-project(a)lists.gforge.inria.fr > > > Subject: Re: [Pharo-project] FFI number of arguments > > > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > > > yes, that's what the link describes. The open question is whether > anyone has successfully done that with 15+ arguments? > > > > > > It works up to 128 arguments. But why don't you try it yourself? > > > > > > > > > Levente > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > > > > Sent: Tuesday, October 05, 2010 10:26 PM > > > > To: Pharo-project(a)lists.gforge.inria.fr > > > > Subject: Re: [Pharo-project] FFI number of arguments > > > > > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > > > >> Hello all, > > > >> > > > >> I have been bumping into some functions with large numbers of > arguments. One in particular would be best handled in the image if at all > possible. The following might be the answer: > > > >> > > > >> > http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > > > >> > > > >> Have any of you done this with >15 (or whatever the cutoff is) > arguments? > > > > > > > > You can create your own function object and invoke it with an array. > > > > Here's an fprintf example on windows: > > > > > > > > fprintf := ExternalLibraryFunction > > > > name: 'fprintf' > > > > module: 'msvcrt.dll' > > > > callType: ExternalFunction callTypeCDecl > > > > returnType: ExternalType signedLong > > > > argumentTypes: { > > > > (ExternalType structTypeNamed: #FILE) asPointerType. > > > > ExternalType string. > > > > ExternalType signedLong }. > > > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > > > Stdio default fcloseWith: file. > > > > > > > > > > > > Levente > > > > > > > > P.S.: Note that you need the FILE and Stdio classes to run this > example. > > > > > > > >> > > > >> Bill > > > >> > > > >> > > > >> _______________________________________________ > > > >> Pharo-project mailing list > > > >> Pharo-project(a)lists.gforge.inria.fr > > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > >> > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Nicolas Cellier

Hi Bill, I somehow share some of Miguel impressions. Some (most) of your messages are too verbose for me, and - no offense - I often discard them, though I may have a solution to propose. It's hard to understand if our answer was helpful or not, if some details should be changed etc... In one word I've got the feeling to give, but not to share. Maybe my english level is just too low, but you know, these lists are rather international. Sorry for the rant, but please, help us to help you. Back to the technical problem, did the updated version at http://www.squeaksource.com/Smallapack/Compiler-nice.150.mcz help, or did my words "not trivial" stopped you? Nicolas 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Miguel, > > I do not "need" to make the call. Â I am wondering whether I can do so in a way that will benefit others, or I should just say the hell with it and either provide similar functionality a different way or provide the same functionality via a .so of my own creation. Â The latter is fine for me but does not do much for anyone else. > > And let's say I make it and the thing seg faults. Â How can I tell the difference between a limitation of the plugin or a mistake on my part calling a fairly cumbersome function? Â The answer: I can't, not without work that I cannot justify doing when a ready solution exists. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:52 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: >> Miguel, >> >> I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. Â The Pharo archives are then a more rich resource they than had been. Â I happen to know it works, because many of the helpful messages I find are in fact mine. >> >> As for whether I could "easily" make the call in question: give me a break. Â It has roughly 20 arguments, and would be a fair amount of work to set up. Â If someone else knows one way or the other, it might trigger either a reply along the lines of Â "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Â Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Â Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? Â You might read what I asked: "have you tried this?" Â Not "please do this for me." Â It would be wasteful to attempt the call without asking for scouting reports. >> > > But in the end if you really need to use that call, either it works or > don't, you'll need to write it, even if someone says that it doesn't > work. Why, because you need it, and if you don't need it then your > question is rhetoric, because you don't even mind the answer. > You can't ask for advise for every and each step you take, most times > you should walk away, _fix_ what you find wrong and then report back the > fix. That would really make the archives more rich because you are > contributing back real knowledge and maybe code and not just polluting > the archives with threads that ask things but solve nothing for anyone > but you. > > Cheers > > >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] >> Sent: Wednesday, October 06, 2010 12:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI number of arguments >> >> El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: >> > Levente, >> > >> > What problem do you have with asking whether someone else has already tried it? Â Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? >> > >> >> But Bill, almost all your questions are long and without apparent focus >> on the real point. Some other times are like this, things that you could >> easily test by yourself maybe in less time that takes you to write so >> many words, send the email and wait for a response from someone willing >> to decipher what the real problem is. Other times you point at problems >> that you find in your environment without giving better hints than "in a >> hopefully updated image", "in a, I think, not modified image", "in my >> machine", that doesn't help in helping you. >> Then you point some problems that it appears that are very evident to >> you and whose solution is also very obvious to you but you don't provide >> a fix for them neither, like the always topic of yours about sockets. >> >> Then when someone points and the Â obvious things you should do (your >> homework, in verifying yourself what you are asking to the list) or to >> precise the information needed to better answer you, you respond upset >> as if anyone should be obliged to answer you or even read your mails. >> >> So, please, read >> >> http://www.catb.org/esr/faqs/smart-questions.html >> >> do your homework and then ask the list. >> >> >> >> >> > >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> > Sent: Tuesday, October 05, 2010 11:09 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] FFI number of arguments >> > >> > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: >> > >> > > yes, that's what the link describes. Â The open question is whether anyone has successfully done that with 15+ arguments? >> > >> > It works up to 128 arguments. But why don't you try it yourself? >> > >> > >> > Levente >> > >> > > >> > > >> > > >> > > ________________________________________ >> > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> > > Sent: Tuesday, October 05, 2010 10:26 PM >> > > To: Pharo-project(a)lists.gforge.inria.fr >> > > Subject: Re: [Pharo-project] FFI number of arguments >> > > >> > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: >> > > >> > >> Hello all, >> > >> >> > >> I have been bumping into some functions with large numbers of arguments. Â One in particular would be best handled in the image if at all possible. Â The following might be the answer: >> > >> >> > >> Â http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… >> > >> >> > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? >> > > >> > > You can create your own function object and invoke it with an array. >> > > Here's an fprintf example on windows: >> > > >> > > fprintf := ExternalLibraryFunction >> > > Â Â Â Â name: 'fprintf' >> > > Â Â Â Â module: 'msvcrt.dll' >> > > Â Â Â Â callType: ExternalFunction callTypeCDecl >> > > Â Â Â Â returnType: ExternalType signedLong >> > > Â Â Â Â argumentTypes: { >> > > Â Â Â Â Â Â Â Â (ExternalType structTypeNamed: #FILE) asPointerType. >> > > Â Â Â Â Â Â Â Â ExternalType string. >> > > Â Â Â Â Â Â Â Â ExternalType signedLong }. >> > > file := Stdio default fopenWith: 'test.txt' with: 'w'. >> > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. >> > > Stdio default fcloseWith: file. >> > > >> > > >> > > Levente >> > > >> > > P.S.: Note that you need the FILE and Stdio classes to run this example. >> > > >> > >> >> > >> Bill >> > >> >> > >> >> > >> _______________________________________________ >> > >> Pharo-project mailing list >> > >> Pharo-project(a)lists.gforge.inria.fr >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > Pharo-project(a)lists.gforge.inria.fr >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > Pharo-project(a)lists.gforge.inria.fr >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

Miguel, I do not "need" to make the call. I am wondering whether I can do so in a way that will benefit others, or I should just say the hell with it and either provide similar functionality a different way or provide the same functionality via a .so of my own creation. The latter is fine for me but does not do much for anyone else. And let's say I make it and the thing seg faults. How can I tell the difference between a limitation of the plugin or a mistake on my part calling a fairly cumbersome function? The answer: I can't, not without work that I cannot justify doing when a ready solution exists. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] Sent: Wednesday, October 06, 2010 12:52 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: > Miguel, > > I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. The Pharo archives are then a more rich resource they than had been. I happen to know it works, because many of the helpful messages I find are in fact mine. > > As for whether I could "easily" make the call in question: give me a break. It has roughly 20 arguments, and would be a fair amount of work to set up. If someone else knows one way or the other, it might trigger either a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? You might read what I asked: "have you tried this?" Not "please do this for me." It would be wasteful to attempt the call without asking for scouting reports. > But in the end if you really need to use that call, either it works or don't, you'll need to write it, even if someone says that it doesn't work. Why, because you need it, and if you don't need it then your question is rhetoric, because you don't even mind the answer. You can't ask for advise for every and each step you take, most times you should walk away, _fix_ what you find wrong and then report back the fix. That would really make the archives more rich because you are contributing back real knowledge and maybe code and not just polluting the archives with threads that ask things but solve nothing for anyone but you. Cheers > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > > Levente, > > > > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? > > > > But Bill, almost all your questions are long and without apparent focus > on the real point. Some other times are like this, things that you could > easily test by yourself maybe in less time that takes you to write so > many words, send the email and wait for a response from someone willing > to decipher what the real problem is. Other times you point at problems > that you find in your environment without giving better hints than "in a > hopefully updated image", "in a, I think, not modified image", "in my > machine", that doesn't help in helping you. > Then you point some problems that it appears that are very evident to > you and whose solution is also very obvious to you but you don't provide > a fix for them neither, like the always topic of yours about sockets. > > Then when someone points and the obvious things you should do (your > homework, in verifying yourself what you are asking to the list) or to > precise the information needed to better answer you, you respond upset > as if anyone should be obliged to answer you or even read your mails. > > So, please, read > > http://www.catb.org/esr/faqs/smart-questions.html > > do your homework and then ask the list. > > > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > Sent: Tuesday, October 05, 2010 11:09 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI number of arguments > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? > > > > It works up to 128 arguments. But why don't you try it yourself? > > > > > > Levente > > > > > > > > > > > > > > ________________________________________ > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > > Sent: Tuesday, October 05, 2010 10:26 PM > > > To: Pharo-project(a)lists.gforge.inria.fr > > > Subject: Re: [Pharo-project] FFI number of arguments > > > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > >> Hello all, > > >> > > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: > > >> > > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > > >> > > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > > > > > You can create your own function object and invoke it with an array. > > > Here's an fprintf example on windows: > > > > > > fprintf := ExternalLibraryFunction > > > name: 'fprintf' > > > module: 'msvcrt.dll' > > > callType: ExternalFunction callTypeCDecl > > > returnType: ExternalType signedLong > > > argumentTypes: { > > > (ExternalType structTypeNamed: #FILE) asPointerType. > > > ExternalType string. > > > ExternalType signedLong }. > > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > > Stdio default fcloseWith: file. > > > > > > > > > Levente > > > > > > P.S.: Note that you need the FILE and Stdio classes to run this example. > > > > > >> > > >> Bill > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] System Tracer

by Eliot Miranda

On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > generate a new image. > But that's not what it does. t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > Hi! > > > > What do you want to achieve? > > > > Cheers, > > Alexandre > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > >> Hi > >> > >> Does anyone know where I can find the system tracer that is currently > >> in use in Pharo? > >> > >> Bests > >> Gabriel > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Schwab,Wilhelm K

Damien, FWIW, I use Citezen but not Pier etc. I need a good BibTeX parser (which you provide) to parse incoming entries (typically originating from Google Scholar). I then add fields for my own comments (which get edited as I work) and a URL to full text and save the result to intermediate storage. To limit the scope of damage and because it does no harm otherwise, I store each BibTeX entry in a separate file and, on demand, glue them together into a largely unreadable mess (bibtex does fine with it) that I put adjacent to the offending manuscript as a .bib file. The way most journals of interest to me release full text articles, the workflow is awful. To not go afoul of copyright law, I store the articles out of public view (and not merely by obscurity). Worse than that, I have to make a local copy of the article and then upload it to the Seaside app, after which things start to work as I intended. I would much prefer to give the Seaside app a URL to the article, but things don't work that way. It's clunky, but the result is very useful to me. In short, Citezen is useful by itself, and you have at least one such user. The biggest problem I have had to date was that ConfigurationOfCitezen originally loaded Seaside,which was prematurely forcing 3.0 on me; the current configuration works great. I suspect I won't even notice the change to FileSystem. Thanks for a good tool!! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Damien Pollet [damien.pollet(a)inria.fr] Sent: Wednesday, October 06, 2010 9:02 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Tests broken with Citezen On Wed, Oct 6, 2010 at 14:53, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > There is no implementor of #fieldKeysToRemove yes, probably a missing constant method. I should also remove the dependency to Rio and use Filesystem instead, but my next preoccupation is to get the scripting/validation to work. You're free to hack on the Pier stuff. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Miguel CobÃ¡

El miÃ©, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribiÃ³: > Miguel, > > I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. The Pharo archives are then a more rich resource they than had been. I happen to know it works, because many of the helpful messages I find are in fact mine. > > As for whether I could "easily" make the call in question: give me a break. It has roughly 20 arguments, and would be a fair amount of work to set up. If someone else knows one way or the other, it might trigger either a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? You might read what I asked: "have you tried this?" Not "please do this for me." It would be wasteful to attempt the call without asking for scouting reports. > But in the end if you really need to use that call, either it works or don't, you'll need to write it, even if someone says that it doesn't work. Why, because you need it, and if you don't need it then your question is rhetoric, because you don't even mind the answer. You can't ask for advise for every and each step you take, most times you should walk away, _fix_ what you find wrong and then report back the fix. That would really make the archives more rich because you are contributing back real knowledge and maybe code and not just polluting the archives with threads that ask things but solve nothing for anyone but you. Cheers > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > > Levente, > > > > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? > > > > But Bill, almost all your questions are long and without apparent focus > on the real point. Some other times are like this, things that you could > easily test by yourself maybe in less time that takes you to write so > many words, send the email and wait for a response from someone willing > to decipher what the real problem is. Other times you point at problems > that you find in your environment without giving better hints than "in a > hopefully updated image", "in a, I think, not modified image", "in my > machine", that doesn't help in helping you. > Then you point some problems that it appears that are very evident to > you and whose solution is also very obvious to you but you don't provide > a fix for them neither, like the always topic of yours about sockets. > > Then when someone points and the obvious things you should do (your > homework, in verifying yourself what you are asking to the list) or to > precise the information needed to better answer you, you respond upset > as if anyone should be obliged to answer you or even read your mails. > > So, please, read > > http://www.catb.org/esr/faqs/smart-questions.html > > do your homework and then ask the list. > > > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > Sent: Tuesday, October 05, 2010 11:09 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI number of arguments > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? > > > > It works up to 128 arguments. But why don't you try it yourself? > > > > > > Levente > > > > > > > > > > > > > > ________________________________________ > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > > Sent: Tuesday, October 05, 2010 10:26 PM > > > To: Pharo-project(a)lists.gforge.inria.fr > > > Subject: Re: [Pharo-project] FFI number of arguments > > > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > > > >> Hello all, > > >> > > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: > > >> > > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > > >> > > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > > > > > You can create your own function object and invoke it with an array. > > > Here's an fprintf example on windows: > > > > > > fprintf := ExternalLibraryFunction > > > name: 'fprintf' > > > module: 'msvcrt.dll' > > > callType: ExternalFunction callTypeCDecl > > > returnType: ExternalType signedLong > > > argumentTypes: { > > > (ExternalType structTypeNamed: #FILE) asPointerType. > > > ExternalType string. > > > ExternalType signedLong }. > > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > > Stdio default fcloseWith: file. > > > > > > > > > Levente > > > > > > P.S.: Note that you need the FILE and Stdio classes to run this example. > > > > > >> > > >> Bill > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification

by Schwab,Wilhelm K

Stef, You raise a good point about helping to improve code, and I would MUCH rather see us try "aClass environment" for a while before introducing name spaces. Dolphin started leaning toward environments a long time ago, and suddenly "class names" were messages to the environment, and I was completely blown away by the potential power of it. So, I'm very open to the idea. However, I don't see any harm in ( Smalltalk at:#SomethingNotYetInstalled ), which I have had to use extensively in Migrate's image building code. Is there a better way to do the same thing? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, October 06, 2010 12:31 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification On 6 October 2010 19:08, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 10/6/2010 6:58 AM, Igor Stasenko wrote: >> >> Hello, >> >> just wanna ask, is this part of API will be deprecated in future? >> (in Pharo, it put under 'to clean later' category). >> >> And if yes, then what will be correct (dialect-agnostic) way to access >> globals? >> >> Smalltalk globals at: #Foo ? >> >> I thought that #at: #at:put: (and some others) >> historically is a part of Smalltalk protocol, and should stay there to >> support legacy code and cross-dialect code. >> >> >> What you thoughts about it? > > The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should > remain in Smalltalk for compatibility. Then it's a matter of where that > request is being delegated. > Yes, i am also thinking that for compatibility it should stay. Then i think in modern code, a most future-proof way is self class environment at: #Foo since it completely avoids any kind of early-binding. > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

Miguel, I see it very differently: I do extensive searches and summarize the results, dropping keywords along the way that I wish had been present in what I finally uncovered somewhere else. The Pharo archives are then a more rich resource they than had been. I happen to know it works, because many of the helpful messages I find are in fact mine. As for whether I could "easily" make the call in question: give me a break. It has roughly 20 arguments, and would be a fair amount of work to set up. If someone else knows one way or the other, it might trigger either a reply along the lines of "yeah, I did ti with 30 arguments" or "I fell for that, the plugin choked on...." Restating what I linked from another group is not helpful, nor is telling me how easy it would be to do something that you have never seen. Did it occur to you that there might be pointer arguments that would be a potential sources of complexity? You might read what I asked: "have you tried this?" Not "please do this for me." It would be wasteful to attempt the call without asking for scouting reports. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel CobÃ¡ [miguel.coba(a)gmail.com] Sent: Wednesday, October 06, 2010 12:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > Levente, > > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? > But Bill, almost all your questions are long and without apparent focus on the real point. Some other times are like this, things that you could easily test by yourself maybe in less time that takes you to write so many words, send the email and wait for a response from someone willing to decipher what the real problem is. Other times you point at problems that you find in your environment without giving better hints than "in a hopefully updated image", "in a, I think, not modified image", "in my machine", that doesn't help in helping you. Then you point some problems that it appears that are very evident to you and whose solution is also very obvious to you but you don't provide a fix for them neither, like the always topic of yours about sockets. Then when someone points and the obvious things you should do (your homework, in verifying yourself what you are asking to the list) or to precise the information needed to better answer you, you respond upset as if anyone should be obliged to answer you or even read your mails. So, please, read http://www.catb.org/esr/faqs/smart-questions.html do your homework and then ask the list. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Tuesday, October 05, 2010 11:09 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? > > It works up to 128 arguments. But why don't you try it yourself? > > > Levente > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > Sent: Tuesday, October 05, 2010 10:26 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI number of arguments > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > >> Hello all, > >> > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: > >> > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > >> > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > > > You can create your own function object and invoke it with an array. > > Here's an fprintf example on windows: > > > > fprintf := ExternalLibraryFunction > > name: 'fprintf' > > module: 'msvcrt.dll' > > callType: ExternalFunction callTypeCDecl > > returnType: ExternalType signedLong > > argumentTypes: { > > (ExternalType structTypeNamed: #FILE) asPointerType. > > ExternalType string. > > ExternalType signedLong }. > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > Stdio default fcloseWith: file. > > > > > > Levente > > > > P.S.: Note that you need the FILE and Stdio classes to run this example. > > > >> > >> Bill > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification

by Igor Stasenko

On 6 October 2010 19:08, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 10/6/2010 6:58 AM, Igor Stasenko wrote: >> >> Hello, >> >> just wanna ask, is this part of API will be deprecated in future? >> (in Pharo, it put under 'to clean later' category). >> >> And if yes, then what will be correct (dialect-agnostic) way to access >> globals? >> >> Smalltalk globals at: #Foo ? >> >> I thought that #at: #at:put: Â (and some others) >> historically is a part of Smalltalk protocol, and should stay there to >> support legacy code and cross-dialect code. >> >> >> What you thoughts about it? > > The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should > remain in Smalltalk for compatibility. Then it's a matter of where that > request is being delegated. > Yes, i am also thinking that for compatibility it should stay. Then i think in modern code, a most future-proof way is self class environment at: #Foo since it completely avoids any kind of early-binding. > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

Oct. 6, 2010

Re: [Pharo-project] Tool for: Image2 - Image1 > FileOut?

by Schwab,Wilhelm K

Stefan, I don't fully understand what you have in mind, but the thought that packaging is weak in Pharo is not a new one. In the early days of Dolphin's packaging system, it was not terribly good about loading prerequisites (that improved greatly over time), so I built a tool called Migrate that had presence in both an outgoing image and a new one. The outgoing portion figured out which packages to save and built a script for loading them into the new image. The new image portion did the obvious, along with picking up some loose methods saved along with the packages - don't ask :) In Pharo, I was stunned to find that I was apparently expected to individually save any number of packages, each requiring a multi-step process, using the MC browser, and immediately thought of Migrate. The result is not as slick as what I was able to build in Dolphin, but it works for me. You are welcome to look for the code in the Pharo In Box and try it if you think it will help you (if only to avoid problems in the future, which I fear is what would happen). Something in #suspectMethodsReport might be adaptable to your current situation?? There are no warranties that the code will load and work as-is. See my Wiki and bug tracker entries on streams (e.g. #nextOne, #nextMany:, etc.) for things that you should be using anyway<g> and will likely need to get Migrate to run. If you want to use it, I will be happy to help you get it going. The Migrate class comment appears below. Bill CONFIGURE ========= Configure it using #homeGrownPackageNames and #me to tell it which packages are intended to hold your work, and how to identify you from the (misnomer!!!) #timeStamp aspects of the compiled methods you produce. SAVE YOUR WORK ============== Use #suspectMethodsReport to produce a listing of class>>selector names that might be in danger of being orphaned in your current image. Use #homeGrownPackgesSaveWithMessage: to save all of the identified home grown packages in the next version and with the common text message. BUILD A NEW IMAGE ================= Load Migrate into a new image. If you want a web image, evaluate #web and then save the image. It wants underscore_madness.cs, and loads SIXX and other packages of interest to me; you can edit as needed to remove what you do not want to load. Put your packages in the cache directory for the new image. Yes, it is fussy about these things, but the idea is to find errors early rather than being stopped after a long wait. Likewise, if you do not like what #setPreferences does, edit it. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo(a)stefan-marr.de] Sent: Wednesday, October 06, 2010 4:28 AM To: List Mailing Pharo; pharo-users(a)lists.gforge.inria.fr Subject: [Pharo-project] Tool for: Image2 - Image1 > FileOut? Hello: I got here two images without sufficient development history, source code management, or change sets. One of the images is the basis point and the other contains all the relevant code I need to file out somehow so that it represents a diff which can be filed into the base point image easily. I am only interested in classes, methods, and their meta infos, so general state in the image is not a problem at the moment. If it would be only about methods, that would be easy, since I can find out whether it is a changed/new method by locking at the fileIndex. However, for classes that does not work out. How can I find out whether they changed or were added? That seems to be only possible if they were actually commented... Is there any known tool which could produce me a diff/fileOut/changeSet from two given images? Or might there be any other information in the image I could use to create one myself? Thanks and best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Miguel CobÃ¡

El miÃ©, 06-10-2010 a las 11:50 -0400, Schwab,Wilhelm K escribiÃ³: > Levente, > > What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? > But Bill, almost all your questions are long and without apparent focus on the real point. Some other times are like this, things that you could easily test by yourself maybe in less time that takes you to write so many words, send the email and wait for a response from someone willing to decipher what the real problem is. Other times you point at problems that you find in your environment without giving better hints than "in a hopefully updated image", "in a, I think, not modified image", "in my machine", that doesn't help in helping you. Then you point some problems that it appears that are very evident to you and whose solution is also very obvious to you but you don't provide a fix for them neither, like the always topic of yours about sockets. Then when someone points and the obvious things you should do (your homework, in verifying yourself what you are asking to the list) or to precise the information needed to better answer you, you respond upset as if anyone should be obliged to answer you or even read your mails. So, please, read http://www.catb.org/esr/faqs/smart-questions.html do your homework and then ask the list. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Tuesday, October 05, 2010 11:09 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? > > It works up to 128 arguments. But why don't you try it yourself? > > > Levente > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > > Sent: Tuesday, October 05, 2010 10:26 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI number of arguments > > > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > > > >> Hello all, > >> > >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: > >> > >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… > >> > >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > > > You can create your own function object and invoke it with an array. > > Here's an fprintf example on windows: > > > > fprintf := ExternalLibraryFunction > > name: 'fprintf' > > module: 'msvcrt.dll' > > callType: ExternalFunction callTypeCDecl > > returnType: ExternalType signedLong > > argumentTypes: { > > (ExternalType structTypeNamed: #FILE) asPointerType. > > ExternalType string. > > ExternalType signedLong }. > > file := Stdio default fopenWith: 'test.txt' with: 'w'. > > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > > Stdio default fcloseWith: file. > > > > > > Levente > > > > P.S.: Note that you need the FILE and Stdio classes to run this example. > > > >> > >> Bill > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 6, 2010

Re: [Pharo-project] Smalltalk at: #Foo - needs clarification

by Andreas Raab

On 10/6/2010 6:58 AM, Igor Stasenko wrote: > Hello, > > just wanna ask, is this part of API will be deprecated in future? > (in Pharo, it put under 'to clean later' category). > > And if yes, then what will be correct (dialect-agnostic) way to access globals? > > Smalltalk globals at: #Foo ? > > I thought that #at: #at:put: (and some others) > historically is a part of Smalltalk protocol, and should stay there to > support legacy code and cross-dialect code. > > > What you thoughts about it? The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should remain in Smalltalk for compatibility. Then it's a matter of where that request is being delegated. Cheers, - Andreas

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

Levente, What problem do you have with asking whether someone else has already tried it? Really, have you not seen examples of working hard on advice from one source only to discover yet another limit that was not in fine print? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Tuesday, October 05, 2010 11:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > yes, that's what the link describes. The open question is whether anyone has successfully done that with 15+ arguments? It works up to 128 arguments. But why don't you try it yourself? Levente > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Tuesday, October 05, 2010 10:26 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote: > >> Hello all, >> >> I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: >> >> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… >> >> Have any of you done this with >15 (or whatever the cutoff is) arguments? > > You can create your own function object and invoke it with an array. > Here's an fprintf example on windows: > > fprintf := ExternalLibraryFunction > name: 'fprintf' > module: 'msvcrt.dll' > callType: ExternalFunction callTypeCDecl > returnType: ExternalType signedLong > argumentTypes: { > (ExternalType structTypeNamed: #FILE) asPointerType. > ExternalType string. > ExternalType signedLong }. > file := Stdio default fopenWith: 'test.txt' with: 'w'. > fprintf invokeWithArguments: { file. 'Your number is %d.'. 42 }. > Stdio default fcloseWith: file. > > > Levente > > P.S.: Note that you need the FILE and Stdio classes to run this example. > >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Smalltalk at: #Foo - needs clarification

by Fernando olivero

On Oct 6, 2010, at 5:30 PM, Fernando olivero wrote: > > On Oct 6, 2010, at 4:36 PM, stephane ducasse wrote: > >> >> >>> Hello, >>> >>> just wanna ask, is this part of API will be deprecated in future? >>> (in Pharo, it put under 'to clean later' category). >>> >>> And if yes, then what will be correct (dialect-agnostic) way to access globals? >>> >>> Smalltalk globals at: #Foo ? >>> >>> I thought that #at: #at:put: (and some others) >>> historically is a part of Smalltalk protocol, and should stay there to >>> support legacy code and cross-dialect code. >>> >>> >>> What you thoughts about it? >> >> legacy you said! Let us move on. We keep to help people migrating. >> Now we should avoid it as much as possible even Smalltalk globals at:. It should be more >> self class environment at: >> >> In VisualWorks I'm not sure that Smalltalk at: make sense. > > I've been using: > > Smalltalk globals classNamed: aString. > > IMO It's better from a conceptual view because > 1. it breaks the class-symbol binding, > 2. and a Dictionary-like implementation for lookup. > > > Fernando

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Alexandre Bergel

Yes, it works also for me. Thanks Cheers, Alexandre On 6 Oct 2010, at 11:03, StÃ©phane Ducasse wrote: > I just fixed the code. the test pass now. > Alex I could generate my web page with this version this summer so it should work. > > Stef > > On Oct 6, 2010, at 4:43 PM, Alexandre Bergel wrote: > >>> I'm loading it right now. >>> And the problem is that the default config load everything.... magritte grease seaside.... >>> 20 min at least. >> >> Yes... I was also surprised of this... >> >> Alexandre >> >> >>> >>> >>>> Hi! >>>> >>>> Citezen seems to not run on a 11414. >>>> CZEntry>>clean >>>> >>>> self class fieldKeysToRemove >>>> do: [:each | (self hasFieldWithKey: each) >>>> ifTrue: [self removeFieldWithKey: each]] >>>> >>>> There is no implementor of #fieldKeysToRemove >>>> >>>> I would like to use Citezen to generate the Research webpage on Pharo. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by StÃ©phane Ducasse

I just fixed the code. the test pass now. Alex I could generate my web page with this version this summer so it should work. Stef On Oct 6, 2010, at 4:43 PM, Alexandre Bergel wrote: >> I'm loading it right now. >> And the problem is that the default config load everything.... magritte grease seaside.... >> 20 min at least. > > Yes... I was also surprised of this... > > Alexandre > > >> >> >>> Hi! >>> >>> Citezen seems to not run on a 11414. >>> CZEntry>>clean >>> >>> self class fieldKeysToRemove >>> do: [:each | (self hasFieldWithKey: each) >>> ifTrue: [self removeFieldWithKey: each]] >>> >>> There is no implementor of #fieldKeysToRemove >>> >>> I would like to use Citezen to generate the Research webpage on Pharo. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Alexandre Bergel

> I'm loading it right now. > And the problem is that the default config load everything.... magritte grease seaside.... > 20 min at least. Yes... I was also surprised of this... Alexandre > > >> Hi! >> >> Citezen seems to not run on a 11414. >> CZEntry>>clean >> >> self class fieldKeysToRemove >> do: [:each | (self hasFieldWithKey: each) >> ifTrue: [self removeFieldWithKey: each]] >> >> There is no implementor of #fieldKeysToRemove >> >> I would like to use Citezen to generate the Research webpage on Pharo. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2010

[Pharo-project] TextConstants-related issues (3066 & 3067)

by NicolÃ¡s Paez

Issue 3066: Classes using TextConstants as a common Dictionary Issue 3067: TextConstants used in different ways Saludos! Nico. blog: nicopaez.wordpress.com

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by StÃ©phane Ducasse

I'm loading it right now. And the problem is that the default config load everything.... magritte grease seaside.... 20 min at least. Stef > Hi! > > Citezen seems to not run on a 11414. > CZEntry>>clean > > self class fieldKeysToRemove > do: [:each | (self hasFieldWithKey: each) > ifTrue: [self removeFieldWithKey: each]] > > There is no implementor of #fieldKeysToRemove > > I would like to use Citezen to generate the Research webpage on Pharo. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] System Tracer

by StÃ©phane Ducasse

generate a new image. On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > Hi! > > What do you want to achieve? > > Cheers, > Alexandre > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > >> Hi >> >> Does anyone know where I can find the system tracer that is currently >> in use in Pharo? >> >> Bests >> Gabriel >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Igor Stasenko

On 6 October 2010 16:54, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > > On Oct 6, 2010, at 3:36 PM, Igor Stasenko wrote: > >> On 6 October 2010 16:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 6 October 2010 16:08, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>>> Ok, thanks for the info. >>>> >>>> Â i'm more than interested in the doing the MacOsX port of NBOpenGL. When i have the time ( not in the near future) i will produce a native boost mac vm deployable , plus the NBOpenGL-MacOsX. >>>> >>>> Regarding the window downloable, i followed the instructions in the page, the load order of packages but a certain class seems to be missing when i want to try the example ( the true type font example rendering ) in the NBOpenGL-Morphic package. >>>> >>> >>> Ohh.. i found that last one is saved as >>> NBOpenGL-Morphic-Igor.Stasenko.3fqa >>> >>> instead of >>> NBOpenGL-Morphic-Igor.Stasenko.3 >>> >>> don't ask me how.. looks like some MC bug. >>> >>> it is listed as a separate item in repository packages list .. crap >>> >>> Also, the missing class is NBGLCurveRenderer, which i moved to >>> NBOpenGL-Rome package. >>> I did a snapshot of it. But it depends on RomeCanvas class(es) , which >>> is part of Athens.. >>> But just ignore that for now and load it. For demo, you need only >>> NBGLCurveRenderer which not rely on any Rome-specific stuff. > > Just for curiosity, why this dependance on Rome? To end up providing a Canvas were all the rendering is performed by OpenGL and you text rendering class ? A NBGLCurveRenderer is actually an experiment, which should be a part of something bigger (read Rome). So, that's why i moved it there, breaking demo :) I plan to implement an OpenGL backend for canvas, which implements Rome protocol. And then implement Morphic which using rome-canvas for rendering.. And then implement brand-new zoomable UI in it.. (i have a big plans)... :) > >>> >>> It should be less messy.. But this is still under construction, so , >>> sorry for inconvenience :) >>> >> > No problem! It's a big project, and you are making an excellent job! > >> So, the load order is >> >> Core >> Win >> TrueType >> Display >> Rome >> Morphic.3fqa >> >> then you can run the: >> >> GLTTRenderingDemo new openInWorld >> >> (works for me) :) >> > > > Ok! Great! I wil try it. > > Maybe we could add some OpenGL rendering examples, some of them can be taken from AlienOpenGL examples, or other source. > I found it useful for documenting the usage to have a class called AlienOpenGLExamples, with examples as instance methods Â ( and also to validate that the rendering is ok). > Yes yes. Things needs to be properly organized. I just don't have much time to do that :) > > Fernando > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 6, 2010

[Pharo-project] Smalltalk at: #Foo - needs clarification

by Igor Stasenko

Hello, just wanna ask, is this part of API will be deprecated in future? (in Pharo, it put under 'to clean later' category). And if yes, then what will be correct (dialect-agnostic) way to access globals? Smalltalk globals at: #Foo ? I thought that #at: #at:put: (and some others) historically is a part of Smalltalk protocol, and should stay there to support legacy code and cross-dialect code. What you thoughts about it? -- Best regards, Igor Stasenko AKA sig.

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Fernando olivero

On Oct 6, 2010, at 3:36 PM, Igor Stasenko wrote: > On 6 October 2010 16:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 6 October 2010 16:08, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>> Ok, thanks for the info. >>> >>> i'm more than interested in the doing the MacOsX port of NBOpenGL. When i have the time ( not in the near future) i will produce a native boost mac vm deployable , plus the NBOpenGL-MacOsX. >>> >>> Regarding the window downloable, i followed the instructions in the page, the load order of packages but a certain class seems to be missing when i want to try the example ( the true type font example rendering ) in the NBOpenGL-Morphic package. >>> >> >> Ohh.. i found that last one is saved as >> NBOpenGL-Morphic-Igor.Stasenko.3fqa >> >> instead of >> NBOpenGL-Morphic-Igor.Stasenko.3 >> >> don't ask me how.. looks like some MC bug. >> >> it is listed as a separate item in repository packages list .. crap >> >> Also, the missing class is NBGLCurveRenderer, which i moved to >> NBOpenGL-Rome package. >> I did a snapshot of it. But it depends on RomeCanvas class(es) , which >> is part of Athens.. >> But just ignore that for now and load it. For demo, you need only >> NBGLCurveRenderer which not rely on any Rome-specific stuff. Just for curiosity, why this dependance on Rome? To end up providing a Canvas were all the rendering is performed by OpenGL and you text rendering class ? >> >> It should be less messy.. But this is still under construction, so , >> sorry for inconvenience :) >> > No problem! It's a big project, and you are making an excellent job! > So, the load order is > > Core > Win > TrueType > Display > Rome > Morphic.3fqa > > then you can run the: > > GLTTRenderingDemo new openInWorld > > (works for me) :) > Ok! Great! I wil try it. Maybe we could add some OpenGL rendering examples, some of them can be taken from AlienOpenGL examples, or other source. I found it useful for documenting the usage to have a class called AlienOpenGLExamples, with examples as instance methods ( and also to validate that the rendering is ok). Fernando

Oct. 6, 2010