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

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