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

Re: [Pharo-project] [Pharo-users] Pharo Talk ESUG 2010

by GermÃ¡n Arduino

hehe, thanks! You will come to Smalltalks 2010 ? 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Oct 7, 2010 at 1:04 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> >> I think that is a good idea. >> >> I was thinking exactly in ask permit to use this one (and other >> similars) to present Pharo in other contexts, for example in local >> groups, etc. > > That's perfectly allowed and even more, a ppt/keypoint template should be > available. 2 days ago Marcus borrowed this one for my PhD first year > evaliuation ;) > >> >> Cheers. >> GermÃ¡n. >> >> >> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > What do you think about having these presentations and videos available >> > from >> > the website?? maybe under Community or under a new section "Media" or >> > even >> > inside documentation. >> > >> > Adrian? >> > >> > On Wed, Oct 6, 2010 at 12:13 PM, Marcus Denker <marcus.denker(a)inria.fr> >> > wrote: >> >> >> >> Hi, >> >> >> >> Now online: >> >> >> >> Slides Slideshare: Â http://www.slideshare.net/esug/pharo >> >> Slides Download: >> >> http://www.marcusdenker.de/talks/10ESUG/2010PharoESUG.pdf >> >> Video Web: Â http://esug2010.objectfusion.fr/tuesday.html >> >> Â Â Â Â (part of all the Tuesday Videos) >> >> Video for Download: >> >> Â Â Â Â flv: >> >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.flv >> >> Â Â Â Â mp4: >> >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.mp4 >> >> >> >> Â Â Â Â Marcus >> >> >> >> >> >> -- >> >> Marcus Denker Â -- http://www.marcusdenker.de >> >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >> >> >> _______________________________________________ >> >> Pharo-users mailing list >> >> Pharo-users(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> > >> > _______________________________________________ >> > 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] [Pharo-users] Pharo Talk ESUG 2010

by Mariano Martinez Peck

On Thu, Oct 7, 2010 at 1:04 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > I think that is a good idea. > > I was thinking exactly in ask permit to use this one (and other > similars) to present Pharo in other contexts, for example in local > groups, etc. > That's perfectly allowed and even more, a ppt/keypoint template should be available. 2 days ago Marcus borrowed this one for my PhD first year evaliuation ;) > > Cheers. > GermÃ¡n. > > > 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > What do you think about having these presentations and videos available > from > > the website?? maybe under Community or under a new section "Media" or > even > > inside documentation. > > > > Adrian? > > > > On Wed, Oct 6, 2010 at 12:13 PM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> Hi, > >> > >> Now online: > >> > >> Slides Slideshare: http://www.slideshare.net/esug/pharo > >> Slides Download: > http://www.marcusdenker.de/talks/10ESUG/2010PharoESUG.pdf > >> Video Web: http://esug2010.objectfusion.fr/tuesday.html > >> (part of all the Tuesday Videos) > >> Video for Download: > >> flv: > >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.flv > >> mp4: > >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.mp4 > >> > >> Marcus > >> > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > _______________________________________________ > > 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] [Pharo-users] Pharo Talk ESUG 2010

by GermÃ¡n Arduino

I think that is a good idea. I was thinking exactly in ask permit to use this one (and other similars) to present Pharo in other contexts, for example in local groups, etc. Cheers. GermÃ¡n. 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > What do you think about having these presentations and videos available from > the website?? maybe under Community or under a new section "Media" or even > inside documentation. > > Adrian? > > On Wed, Oct 6, 2010 at 12:13 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> Hi, >> >> Now online: >> >> Slides Slideshare: Â http://www.slideshare.net/esug/pharo >> Slides Download: http://www.marcusdenker.de/talks/10ESUG/2010PharoESUG.pdf >> Video Web: Â http://esug2010.objectfusion.fr/tuesday.html >> Â Â Â Â (part of all the Tuesday Videos) >> Video for Download: >> Â Â Â Â flv: >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.flv >> Â Â Â Â mp4: >> http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.mp4 >> >> Â Â Â Â Marcus >> >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > 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

[Pharo-project] FFI with 15+ args and Smallapack in Pharo

by Nicolas Cellier

So, even if Bill did not help me a lot, and even if it does not help him neither, I finally did it. you can now test FFI calls with many arguments in latest Pharo 1.2 12172 The package is at http://www.squeaksource.com/Smallapack/Compiler-nicePharo12.245.mcz This also give anybody a chance to load Smallapack packages - if interested in debugging at machine code level ;) Nicolas ---------------------------------------------- Name: Compiler-nicePharo12.245 Author: nice Time: 7 October 2010, 12:39:29 am UUID: 9f3a6b0f-f25f-4510-b373-4dc99f39f3f6 Ancestors: Compiler-MarcusDenker.244 A version of Compiler with support for methods with many arguments including external FFI calls - For inclusion in Pharo 1.2

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Schwab,Wilhelm K

Stef, Yup - that's how Migrate loads it. Just some thanks and encouragement to allow it to continue that way. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, October 06, 2010 6:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Tests broken with Citezen have a look at the configuration you can pick noWeb. Stef On Oct 6, 2010, at 7:17 PM, Schwab,Wilhelm K wrote: > 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 > > _______________________________________________ > 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] [Pharo-users] Pharo Talk ESUG 2010

by Mariano Martinez Peck

What do you think about having these presentations and videos available from the website?? maybe under Community or under a new section "Media" or even inside documentation. Adrian? On Wed, Oct 6, 2010 at 12:13 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > Now online: > > Slides Slideshare: http://www.slideshare.net/esug/pharo > Slides Download: http://www.marcusdenker.de/talks/10ESUG/2010PharoESUG.pdf > Video Web: http://esug2010.objectfusion.fr/tuesday.html > (part of all the Tuesday Videos) > Video for Download: > flv: > http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.flv > mp4: > http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.mp4 > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Oct. 6, 2010

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

by Schwab,Wilhelm K

Stef, Good enough, but it sounded like a higher level of cleaning was on the way?? Some of the code that I have using "Smalltalk at:" originally expected a SystemDictionary. I have no problem with implementation changes, and I like the #environment idea. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, October 06, 2010 6:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification This is why the image does not use Smalltalk at: but the at: method is still defined in SmalltalkImage. > 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. I started in 2002 to remove hardcoded Smalltalk at: and replace them by self class environment for the reason that having the possibility to have different systemDictionary instance can help us for: bootstrapping the compiler, building atomic laoding like VW for example. > > 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 > > _______________________________________________ > 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] Newbie question: Connection to SQLite DB

by Schwab,Wilhelm K

I'm not sure I follow your concern. The Win32 examples will certainly fail on other than Win32. I am not even certain if they are currently expected to work on Windows (not simply a dig at its flakiness - it might have changed enough to break something). It looks like one is expected to click a mouse button to terminate the example. Are you matching 32 and 64 bit OS and image/vm? What error do you get? Posting a debug log of it might help. Especially early in Metacello's life, I had big problems with: (1) discovering how to use a given configuration; (2) some configurations were loading things that one might not necessarily want. An example of the latter was ConfiurationOfCitezen, which at one point loaded Seaside; it now does what one would want, leaving it to the user to load the desired version of Seaside. You just prompted me to look at Migrate's various #load* methods, which reveals a few decisions that are no doubt incorrect or at least overly presumptuous. I would pass along the once common advice of "just search the web" but that turns up a very dangerous mix of current and dated links. Make sure you are using the configuration correctly. Sorry if I am missing your point. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of nullPointer [epicfan(a)gmail.com] Sent: Monday, October 04, 2010 8:27 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Newbie question: Connection to SQLite DB Well, I first install Sqlite project; I add ConfigurationOfSQLite3 to image. Later: (ConfigurationOfSQLite3 project version: '1.1') load. That seems load Sqlite3 classes and dependences too, FFI included. But if I try execute one example of FFI I get an error. For example: Win32Window win32Draw Now IÂ´m using Windows7 but fails me too Mac Snow Leopard OS... IÂ´m very lost on that subject... Regards -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ 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] bad bracket autocompletion in Pharo Core 1.2

by Mariano Martinez Peck

I detected a similar problem: once you type an opening parenthesis, and then something else, it adds a new one at the END of the code check http://code.google.com/p/pharo/issues/detail?id=2939 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com> > http://code.google.com/p/pharo/issues/detail?id=3069 > > if you type: > > [] -> []] > > () -> ()) > > {} -> {}} > > > > Bye! > > _______________________________________________ > 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] Pointer types

by Schwab,Wilhelm K

Sig, Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? That's ok, just want to know if there is an applicable lesson on FFI to be extracted. You say the NB callout generator knows nothing about types. Is that how it should be? The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Maybe all it takes is a scan for a suitable handler before or after the method is compiled. I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. IIRC, Andreas patched the compiler to report the bogus types. "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: MyClass>>externalTypeAlias: aTypeName aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. ^ nil Then, any method which contains an FFI callout in MyClass, will use that alias." What is MyClass in the above? Is it the class holding the callout method, or it elsewhere in the chain? I ask because it could be a sore spot for maintenance/pluggability. I'm wondering how you and I would independently add such instructions. If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Make sense? My hunch is that you have it handled. 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: Monday, October 04, 2010 7:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pointer types On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. > > Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? > In NB, there is a type system, which implements C<->Smalltalk coercions. The responsibility of type coercions taken by a subclasses of NBExternalType, so NB callout code generator actually knows nothing about types and how to coerce them. To create own custom type, you need to subclass from NBExternalType and override methods which responsible for coercions. There you can define any kind of operations , what needs to be done in order to push value on stack, or convert it to some smalltalk object. Then, in your DoubleArray class, simply implement a message on a class side: asNBExternalType: gen ^ MyDoubleArrayExternalType new And then, in FFI callouts you can use a class name directly: DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) etc. Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: MyClass>>externalTypeAlias: aTypeName aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. ^ nil Then, any method which contains an FFI callout in MyClass, will use that alias. So, you can write callout as: double* foo (double *arr, double ** arrPtrPtr) but it will be understood as: DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) About handling pointers.. well for smalltalk there is no pointers, just objects. So, in NB NBExternalType keeps two things: - a value type - a pointer arity So, for example, when you specifying type, like: char *** a value type will be char and pointer arity will be 3. It is up to NBExternalType subclass how to push values whose pointer arity > 0. By default, if pointerArity > 0, then it is treated as a pointer, which can be either: - nil, ByteArray, or NBExternalAddress > Bill > > > > _______________________________________________ > 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. _______________________________________________ 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

On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > 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. Yes I know gnerates = clone in my mail. > 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). Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

have a look at the configuration you can pick noWeb. Stef On Oct 6, 2010, at 7:17 PM, Schwab,Wilhelm K wrote: > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

This is why the image does not use Smalltalk at: but the at: method is still defined in SmalltalkImage. > 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. I started in 2002 to remove hardcoded Smalltalk at: and replace them by self class environment for the reason that having the possibility to have different systemDictionary instance can help us for: bootstrapping the compiler, building atomic laoding like VW for example. > > 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 > > _______________________________________________ > 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

[Pharo-project] Strange code replacement when prompting unknown selector

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=3070 Cheers! Guille

Oct. 6, 2010

[Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=3069 if you type: [] -> []] () -> ()) {} -> {}} Bye!

Oct. 6, 2010

Re: [Pharo-project] Bug in Pharo compiler?

by Henrik Sperre Johansen

Hit the button a bit fast there... On 06.10.2010 23:13, Henrik Sperre Johansen wrote: > On 06.10.2010 22:56, James Ladd wrote: >> Hi All, >> >> Currently im running the Redline Smalltalk compiler >> (http://redline.st) over the Pharo source >> to make sure that it is compatible with Pharo. >> >> What I noticed while compiling the class BitBlt is that an instance >> variable is also used as >> a method argument name! >> >> If you try and do this with the environment you get a "name already >> defined" error, yet >> it is in the source. >> >> Not sure what to do about it? >> >> Rgs, James. > The compiler has been changed to be more strict about shadowing inst > vars, but code which has not been since the change was made may still > exist. > ... which has not been altered since the change... > Submit a bug to the tracker mentioning the affected method, and it > will be fixed. Which would be to rename the method argument name, by the way. Cheers, Henry

Oct. 6, 2010

Re: [Pharo-project] Bug in Pharo compiler?

by Henrik Sperre Johansen

On 06.10.2010 22:56, James Ladd wrote: > Hi All, > > Currently im running the Redline Smalltalk compiler > (http://redline.st) over the Pharo source > to make sure that it is compatible with Pharo. > > What I noticed while compiling the class BitBlt is that an instance > variable is also used as > a method argument name! > > If you try and do this with the environment you get a "name already > defined" error, yet > it is in the source. > > Not sure what to do about it? > > Rgs, James. The compiler has been changed to be more strict about shadowing inst vars, but code which has not been since the change was made may still exist. Submit a bug to the tracker mentioning the affected method, and it will be fixed. Cheers, Henry

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Nicolas Cellier

Bill, that was not obvious... and is probably not helpful to me. At least, Miguel's response was funny. Thank you for provoking that, I owe you a smile :) Nicolas 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > What I am saying to him is that the decision of whether or not to wrap pllegend() is complicated, so whether or not I adopt his proposed solution will probably be more about the relevance of pllegend() to those funding my efforts than the technical merits of what he suggests. > > > > ________________________________________ > 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 4:21 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > El miÃ©, 06-10-2010 a las 16:08 -0400, Schwab,Wilhelm K escribiÃ³: >> It might still work at first try, though your initial presentation of it left me expecting something else. Â Don't give up as quickly as you seem to think I do. Â I will admit that the legend support in PLplot is not all that great to start, and it might not be worthy of heroic measures. Â It is not even clear that it is finalized, though they seem resistant to changing what they have. Â A clean way to go from a fraction of 0@0 extent:1@1 (aka a viewport) to a legend might be even more valuable. Â I have already used viewports to good effect, so adding a legend based on them might be reasonable and not all that different from what I will be doing with R not too long from now. Â Controlling text size can be problematic, which with a couple of other quirks is why I initially had high hopes for pllegend(). >> >> What PLplot does very nicely is plot "large" numbers of points from arrays of doubles. Â For now, we are lacking in the infrastructure required to take advantage of that. Â My solution so far is not ideal. >> > > Sorry but when reading those types of emails sometimes I ask myself if I > am not victim of a prank and lose to the Turing machine test and the > mails were really generated automatically from a computer or some kind > of Eliza software. > > What are you talking about Bill? And what has that to do with the words > and the very reasonable points that Nicolas expresed in the mail you are > responding to? > > >> >> >> ________________________________________ >> 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 3:30 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI number of arguments >> >> 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> > 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). >> > >> >> Well, it might have worked at first try, or not... At least that would >> be a valuable information. >> You could even have enrolled me in helping a port to Pharo, my time is >> scarse, but it's free. >> If you have a simple solution, that's OK, but I just wonder why you >> asked this list. >> If you don't take our answers into account, then we're in a dead-end. >> No feedback, no win-win cycle. >> If it's just to diiscuss technical merit of whatever solution, without >> a line of code to share, then it's gonna get too abstract to interest >> many of us. >> Beware to not dry the sources. >> >> Cheers >> >> Nicolas >> >> > 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 >> > >> > _______________________________________________ >> > 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 >

Oct. 6, 2010

[Pharo-project] Bug in Pharo compiler?

by James Ladd

Hi All, Currently im running the Redline Smalltalk compiler (http://redline.st) over the Pharo source to make sure that it is compatible with Pharo. What I noticed while compiling the class BitBlt is that an instance variable is also used as a method argument name! If you try and do this with the environment you get a "name already defined" error, yet it is in the source. Not sure what to do about it? Rgs, James.

Oct. 6, 2010

Re: [Pharo-project] FFI number of arguments

by Schwab,Wilhelm K

What I am saying to him is that the decision of whether or not to wrap pllegend() is complicated, so whether or not I adopt his proposed solution will probably be more about the relevance of pllegend() to those funding my efforts than the technical merits of what he suggests. ________________________________________ 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 4:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments El miÃ©, 06-10-2010 a las 16:08 -0400, Schwab,Wilhelm K escribiÃ³: > It might still work at first try, though your initial presentation of it left me expecting something else. Don't give up as quickly as you seem to think I do. I will admit that the legend support in PLplot is not all that great to start, and it might not be worthy of heroic measures. It is not even clear that it is finalized, though they seem resistant to changing what they have. A clean way to go from a fraction of 0@0 extent:1@1 (aka a viewport) to a legend might be even more valuable. I have already used viewports to good effect, so adding a legend based on them might be reasonable and not all that different from what I will be doing with R not too long from now. Controlling text size can be problematic, which with a couple of other quirks is why I initially had high hopes for pllegend(). > > What PLplot does very nicely is plot "large" numbers of points from arrays of doubles. For now, we are lacking in the infrastructure required to take advantage of that. My solution so far is not ideal. > Sorry but when reading those types of emails sometimes I ask myself if I am not victim of a prank and lose to the Turing machine test and the mails were really generated automatically from a computer or some kind of Eliza software. What are you talking about Bill? And what has that to do with the words and the very reasonable points that Nicolas expresed in the mail you are responding to? > > > ________________________________________ > 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 3:30 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > 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). > > > > Well, it might have worked at first try, or not... At least that would > be a valuable information. > You could even have enrolled me in helping a port to Pharo, my time is > scarse, but it's free. > If you have a simple solution, that's OK, but I just wonder why you > asked this list. > If you don't take our answers into account, then we're in a dead-end. > No feedback, no win-win cycle. > If it's just to diiscuss technical merit of whatever solution, without > a line of code to share, then it's gonna get too abstract to interest > many of us. > Beware to not dry the sources. > > Cheers > > Nicolas > > > 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 > > > > _______________________________________________ > > 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] KomHttpServer in pharo 1.2

by Guillermo Polito

SmalltalkImage>>platformName: Ticket and fix in http://code.google.com/p/pharo/issues/detail?id=3068 KomHttpServer, I submitted the fix to the repo. Thank you everyone :D!!! On Wed, Oct 6, 2010 at 5:10 PM, Giovanni Corriga <giovanni(a)corriga.net>wrote: > Hola Guillermo, > > the KomHttpServer repository on SqueakSource has no write restrictions > - feel free to upload a new .mcz file :) > > Giovanni > > 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > I've cc the authors that are in the squeaksource project. > > > > 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com> > >> > >> Jaja, you're right :). > >> > >> What is better? Having SmalltalkImage or OSPlatform hardcoded there? > If > >> we decide the right answer is SmalltalkImage, then we should change the > >> deprecation in SmalltalkImage which currently is: > >> > >> platformName > >> "Return the name of the platform we're running on" > >> > >> self deprecated: 'Use OSPlatform'. > >> ^ OSPlatform platformName > >> > >> And maybe it's better as > >> > >> platformName > >> "Return the name of the platform we're running on" > >> > >> self deprecated: 'Use OSPlatform'. > >> ^ self os platformName > >> > >> Cheers! > >> > >> On Tue, Oct 5, 2010 at 6:36 PM, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >>> > >>> On 05.10.2010 23:29, Guillermo Polito wrote: > >>>> > >>>> Why not > >>>> > >>>> self class environment platformName > >>>> > >>>> ? > >>> > >>> Because it doesn't work? ;) > >>> > >>> The class environment is the SystemDictionary instance containing > classes > >>> and globals, not the SmalltalkImage instance, > >>> (Smalltalk is now a shortcut for the sole SmalltalkImage instance), > where > >>> you find access to OSPlatform through the #os delegation method. > >>> SmalltalkImage platformName is deprecated in 1.2, the cross-dialect way > >>> to do it is through using Smalltalk os platformName. > >>> > >>> Cheers, > >>> Henry > >>> > >>> _______________________________________________ > >>> 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 Miguel CobÃ¡

El miÃ©, 06-10-2010 a las 16:08 -0400, Schwab,Wilhelm K escribiÃ³: > It might still work at first try, though your initial presentation of it left me expecting something else. Don't give up as quickly as you seem to think I do. I will admit that the legend support in PLplot is not all that great to start, and it might not be worthy of heroic measures. It is not even clear that it is finalized, though they seem resistant to changing what they have. A clean way to go from a fraction of 0@0 extent:1@1 (aka a viewport) to a legend might be even more valuable. I have already used viewports to good effect, so adding a legend based on them might be reasonable and not all that different from what I will be doing with R not too long from now. Controlling text size can be problematic, which with a couple of other quirks is why I initially had high hopes for pllegend(). > > What PLplot does very nicely is plot "large" numbers of points from arrays of doubles. For now, we are lacking in the infrastructure required to take advantage of that. My solution so far is not ideal. > Sorry but when reading those types of emails sometimes I ask myself if I am not victim of a prank and lose to the Turing machine test and the mails were really generated automatically from a computer or some kind of Eliza software. What are you talking about Bill? And what has that to do with the words and the very reasonable points that Nicolas expresed in the mail you are responding to? > > > ________________________________________ > 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 3:30 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI number of arguments > > 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > 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). > > > > Well, it might have worked at first try, or not... At least that would > be a valuable information. > You could even have enrolled me in helping a port to Pharo, my time is > scarse, but it's free. > If you have a simple solution, that's OK, but I just wonder why you > asked this list. > If you don't take our answers into account, then we're in a dead-end. > No feedback, no win-win cycle. > If it's just to diiscuss technical merit of whatever solution, without > a line of code to share, then it's gonna get too abstract to interest > many of us. > Beware to not dry the sources. > > Cheers > > Nicolas > > > 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 > > > > _______________________________________________ > > 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] KomHttpServer in pharo 1.2

by Giovanni Corriga

Hola Guillermo, the KomHttpServer repository on SqueakSource has no write restrictions - feel free to upload a new .mcz file :) Giovanni 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I've cc the authors that are in the squeaksource project. > > 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com> >> >> Jaja, you're right :). >> >> What is better?Â Having SmalltalkImage or OSPlatform hardcoded there?Â If >> we decide the right answer is SmalltalkImage, then we should change the >> deprecation in SmalltalkImage which currently is: >> >> platformName >> Â Â Â "Return the name of the platform we're running on" >> >> Â Â Â self deprecated: 'Use OSPlatform'. >> Â Â Â ^ OSPlatform platformName >> >> And maybe it's better as >> >> platformName >> Â Â Â "Return the name of the platform we're running on" >> >> Â Â Â self deprecated: 'Use OSPlatform'. >> Â Â Â ^ self os platformName >> >> Cheers! >> >> On Tue, Oct 5, 2010 at 6:36 PM, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> Â On 05.10.2010 23:29, Guillermo Polito wrote: >>>> >>>> Why not >>>> >>>> self class environment platformName >>>> >>>> ? >>> >>> Because it doesn't work? ;) >>> >>> The class environment is the SystemDictionary instance containing classes >>> and globals, not the SmalltalkImage instance, >>> (Smalltalk is now a shortcut for the sole SmalltalkImage instance), where >>> you find access to OSPlatform through the #os delegation method. >>> SmalltalkImage platformName is deprecated in 1.2, the cross-dialect way >>> to do it is through using Smalltalk os platformName. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> 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

It might still work at first try, though your initial presentation of it left me expecting something else. Don't give up as quickly as you seem to think I do. I will admit that the legend support in PLplot is not all that great to start, and it might not be worthy of heroic measures. It is not even clear that it is finalized, though they seem resistant to changing what they have. A clean way to go from a fraction of 0@0 extent:1@1 (aka a viewport) to a legend might be even more valuable. I have already used viewports to good effect, so adding a legend based on them might be reasonable and not all that different from what I will be doing with R not too long from now. Controlling text size can be problematic, which with a couple of other quirks is why I initially had high hopes for pllegend(). What PLplot does very nicely is plot "large" numbers of points from arrays of doubles. For now, we are lacking in the infrastructure required to take advantage of that. My solution so far is not ideal. ________________________________________ 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 3:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI number of arguments 2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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). > Well, it might have worked at first try, or not... At least that would be a valuable information. You could even have enrolled me in helping a port to Pharo, my time is scarse, but it's free. If you have a simple solution, that's OK, but I just wonder why you asked this list. If you don't take our answers into account, then we're in a dead-end. No feedback, no win-win cycle. If it's just to diiscuss technical merit of whatever solution, without a line of code to share, then it's gonna get too abstract to interest many of us. Beware to not dry the sources. Cheers Nicolas > 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 > > _______________________________________________ > 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

2010/10/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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). > Well, it might have worked at first try, or not... At least that would be a valuable information. You could even have enrolled me in helping a port to Pharo, my time is scarse, but it's free. If you have a simple solution, that's OK, but I just wonder why you asked this list. If you don't take our answers into account, then we're in a dead-end. No feedback, no win-win cycle. If it's just to diiscuss technical merit of whatever solution, without a line of code to share, then it's gonna get too abstract to interest many of us. Beware to not dry the sources. Cheers Nicolas > 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 > > _______________________________________________ > 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