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

Re: [Pharo-project] FFI and underscores in 1.1 (RC2)

by Mariano Martinez Peck

I can reproduce the problem. I have this method that works: apiInitialize: handle backend: backend host: host port: port "long odbx_init(odbx_t**, char*, char*, char*)" <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> ^self externalCallFailed But not this one: apiInitialize: handle backend: backend host: host port: port "long odbx_init(odbx_t**, char*, char*, char*)" <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> ^self externalCallFailed a_piInitialize: handle backend: backend host: host port: port "long odbx_init(odbx_t**, char*, char*, char*)" <cdecl: long 'odbx_init' (ulong* char* char* char* Matching number of arguments expected ->) module: 'opendbx'> ^self externalCallFailed Please, open a ticket. Maybe Lukas can help us. Cheers Mariano On Sat, Aug 21, 2010 at 9:47 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I just had an underwhelming response to my latest adventure into FFI, > specifically wrapping the Acces IO USB API. Specifically, very few > functions survived from description to actually being compiled. AFAICT, the > compiler does not like underscores in method names for external functions. > > I'm not even sure how to describe it other than to give an example. This > works: > > dIOWrite8:deviceIndex byteIndex:byteIndex data:data > "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long > ByteIndex, unsigned char Data)" > > < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > > ^self invalidCall. > > > This should compile, but it complains about a mismatch in the number of > arguments: > > DIO_Write8:deviceIndex byteIndex:byteIndex data:data > "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long > ByteIndex, unsigned char Data)" > > < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > > ^self invalidCall. > > The less Pharo forces us to change names as given from the outside, the > better off we will be. I am using a 1.1 RC2 image, just in case this has > been fixed since then?? I really need to build a new image soon. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 22, 2010

Re: [Pharo-project] Linux vm

by Schwab,Wilhelm K

It has been a long day, and it might not have needed to be so. Within 15 minutes of seeing "undefined symbol: libusb_close" from dlerror(), I had the problem not only diagnosed but fixed; seeing the error in something related to USB support was enough to suggest I needed to link that library into the .so I was trying to load. I was still guessing, but it was an educated guess based on a concrete lead. Is there a way to get such diagnostic information without hacking the vm source? If not, please consider the following as a proposed patch. I have tried to strike a balance between seeing enough to make sense of errant plugin paths and giving detailed information about failures when given an absolute path. Behavior changes (I intend/think) only if something won't load (it says what it was trying to do) and if the library is specified by absolute path, in which case it gives diagnostic output on any failure to load. Bill ( Squeak-...-src/unix/vm/sqUnixExternalPrims.c ) static void *tryLoadModule(char *in, char *name) { char path[PATH_MAX], *out= path; void *handle= 0; int c; while ((c= *in++) && ':' != c) { /* copy next plugin path to path[] */ switch (c) { case '%': if ('n' == *in || 'N' == *in) { /* replace %n with name of plugin */ ++in; strcpy(out, name); out += strlen(name); continue; } if ('%' == *in) { ++in; *out++= '%'; continue; } /* fall through... */ default: *out++= c; continue; } } sprintf(out, "/" MODULE_PREFIX "%s" MODULE_SUFFIX, name); handle= dlopen(path, RTLD_NOW | RTLD_GLOBAL); fdebugf((stderr, "tryLoading(%s) = %p\n", path, handle)); // 8-10 wks - no silent failures if( !handle ){ // 8-10 - if a load fails, tell the user what we tried to load: fprintf(stdout, "Load failed for: %s\n", path); // 8-10 - is the given path absolute? If so, try again with it // as given and report diagnostic information if it fails. if( (int)(name[0])==47 ) { handle=dlopen(name, RTLD_NOW | RTLD_GLOBAL); fprintf(stdout, "Load-by-name(%s) = %p\n", name, handle); if(!handle){ fprintf(stdout,"Error loading library: %s\n",dlerror()); } } } if (!handle) { struct stat buf; if ((0 == stat(path, &buf)) && ! S_ISDIR(buf.st_mode)) fprintf(stderr, "%s\n", dlerror()); } return handle; } ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Saturday, August 21, 2010 8:19 PM To: Pharo-project(a)lists.gforge.inria.fr; vm-dev(a)lists.squeakfoundation.org Subject: [Pharo-project] Linux vm Hello all, Is there a way to get the pre-compiled linux vm to describe what the full path is to a library it is trying to load? I can hack the source to do so, but then I start wondering what I might have disturbed in the process. Out of the box, all I get is an external library with a nil handle and no clue what did or did not happen. At various points in my struggle today, I saw what looked like a tendency to load plugins from the vmpath//so.pluginName (two slashes rather than one). It raises the question of whether the code is adding an extra slash when it is not given an explicit plugins path?? The separate concern is that I need information about what is happening when one of my libraries fails to load. One possibility is that a particular .so can't load. How would I find out whether that this is case? Is there a way to test load it or to get the vm to tell me the cause of a failure to load it? Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899

by Guillermo Polito

So, is it safe to integrate? Guille On Sat, Aug 21, 2010 at 9:06 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 21 Aug 2010, Guillermo Polito wrote: > >> Hi! I wass looking at tha issue, specially at the item that says: >> >> "- ensure that #rehashWithoutBecome doesn't send #become:, making >> #rehashAllInstances a lot faster" >> >> And the change made in squeak was: >> >> Item was changed: >> ----- Method: MethodDictionary>>rehashWithoutBecome (in category >> 'private') ----- >> rehashWithoutBecome >> >> + Â Â Â | newInstance | >> + Â Â Â newInstance := self species new: self basicSize - 1. "Make >> sure it has the same capacity" >> + Â Â Â 1 to: self basicSize do: [ :index | >> + Â Â Â Â Â Â Â (self basicAt: index) ifNotNil: [ :key | >> + Â Â Â Â Â Â Â Â Â Â Â newInstance at: key put: (array at: index) ] ]. >> + Â Â Â ^newInstance! >> - Â Â Â | newSelf | >> - Â Â Â newSelf := self species new: self size. >> - Â Â Â 1 to: self basicSize do: [ :i | >> - Â Â Â Â Â Â Â | key | >> - Â Â Â Â Â Â Â (key := self basicAt: i) ifNotNil: [ >> - Â Â Â Â Â Â Â Â Â Â Â newSelf at: key put: (array at: i) ] ]. >> - Â Â Â ^newSelf! >> >> And I figured out that this change does nothing with its comment >> "ensure that #rehashWithoutBecome doesn't send #become:" >> >> Also, the only senders in the Core image are ScriptLoader >> SmalltalkImage (and there is no ?#rehashAllInstances ). >> >> ------------------------------------------ >> >> I tried this code before and after the change >> >> oldDicts := MethodDictionary allInstances. >> [ | newDicts | Â newDicts := Array new: oldDicts size. >> Â Â Â Â oldDicts withIndexDo: [ :d :index | newDicts at: index put: d >> rehashWithoutBecome ].] timeToRun >> >> And I saw a little improvement in performance (but it fluctuated a >> lot...). >> >> Does anyone know a performance difference between size and basicSize >> in Dictionary, HashedCollection or MethodDictionary? > > 1. #basicSize is only meaningful for MethodDictionary, for other > HashedCollections it's not related to the elements of the collection (at > least in Squeak). > 2. The performance difference (in Squeak) comes from the fact that if #size > returns a power of two, then (with the old code) the MethodDictionary will > grow when the last element is inserted by the loop. During the growth all > elements will be hashed again and #become: will be used to swap the old and > the new MethodDictionary, which is "very slow" in Squeak (and in Pharo). > > So if you apply the change and you have a few MethodDictionaries with power > of two size in your image and all relevant changes from Squeak are applied, > then you should see the speedup. > > All in all: in Squeak without this patch #rehashWithoutBecome could send > #become: in the "background". > > > Levente > >> >> Thanks >> >> _______________________________________________ >> 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 >

Aug. 22, 2010

[Pharo-project] Linux vm

by Schwab,Wilhelm K

Hello all, Is there a way to get the pre-compiled linux vm to describe what the full path is to a library it is trying to load? I can hack the source to do so, but then I start wondering what I might have disturbed in the process. Out of the box, all I get is an external library with a nil handle and no clue what did or did not happen. At various points in my struggle today, I saw what looked like a tendency to load plugins from the vmpath//so.pluginName (two slashes rather than one). It raises the question of whether the code is adding an extra slash when it is not given an explicit plugins path?? The separate concern is that I need information about what is happening when one of my libraries fails to load. One possibility is that a particular .so can't load. How would I find out whether that this is case? Is there a way to test load it or to get the vm to tell me the cause of a failure to load it? Bill

Aug. 22, 2010

Re: [Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899

by Levente Uzonyi

On Sat, 21 Aug 2010, Guillermo Polito wrote: > Hi! I wass looking at tha issue, specially at the item that says: > > "- ensure that #rehashWithoutBecome doesn't send #become:, making > #rehashAllInstances a lot faster" > > And the change made in squeak was: > > Item was changed: > ----- Method: MethodDictionary>>rehashWithoutBecome (in category > 'private') ----- > rehashWithoutBecome > > + | newInstance | > + newInstance := self species new: self basicSize - 1. "Make > sure it has the same capacity" > + 1 to: self basicSize do: [ :index | > + (self basicAt: index) ifNotNil: [ :key | > + newInstance at: key put: (array at: index) ] ]. > + ^newInstance! > - | newSelf | > - newSelf := self species new: self size. > - 1 to: self basicSize do: [ :i | > - | key | > - (key := self basicAt: i) ifNotNil: [ > - newSelf at: key put: (array at: i) ] ]. > - ^newSelf! > > And I figured out that this change does nothing with its comment > "ensure that #rehashWithoutBecome doesn't send #become:" > > Also, the only senders in the Core image are ScriptLoader > SmalltalkImage (and there is no ?#rehashAllInstances ). > > ------------------------------------------ > > I tried this code before and after the change > > oldDicts := MethodDictionary allInstances. > [ | newDicts | newDicts := Array new: oldDicts size. > oldDicts withIndexDo: [ :d :index | newDicts at: index put: d > rehashWithoutBecome ].] timeToRun > > And I saw a little improvement in performance (but it fluctuated a lot...). > > Does anyone know a performance difference between size and basicSize > in Dictionary, HashedCollection or MethodDictionary? 1. #basicSize is only meaningful for MethodDictionary, for other HashedCollections it's not related to the elements of the collection (at least in Squeak). 2. The performance difference (in Squeak) comes from the fact that if #size returns a power of two, then (with the old code) the MethodDictionary will grow when the last element is inserted by the loop. During the growth all elements will be hashed again and #become: will be used to swap the old and the new MethodDictionary, which is "very slow" in Squeak (and in Pharo). So if you apply the change and you have a few MethodDictionaries with power of two size in your image and all relevant changes from Squeak are applied, then you should see the speedup. All in all: in Squeak without this patch #rehashWithoutBecome could send #become: in the "background". Levente > > Thanks > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 22, 2010

[Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899

by Guillermo Polito

Hi! I wass looking at tha issue, specially at the item that says: "- ensure that #rehashWithoutBecome doesn't send #become:, making #rehashAllInstances a lot faster" And the change made in squeak was: Item was changed: ----- Method: MethodDictionary>>rehashWithoutBecome (in category 'private') ----- rehashWithoutBecome + | newInstance | + newInstance := self species new: self basicSize - 1. "Make sure it has the same capacity" + 1 to: self basicSize do: [ :index | + (self basicAt: index) ifNotNil: [ :key | + newInstance at: key put: (array at: index) ] ]. + ^newInstance! - | newSelf | - newSelf := self species new: self size. - 1 to: self basicSize do: [ :i | - | key | - (key := self basicAt: i) ifNotNil: [ - newSelf at: key put: (array at: i) ] ]. - ^newSelf! And I figured out that this change does nothing with its comment "ensure that #rehashWithoutBecome doesn't send #become:" Also, the only senders in the Core image are ScriptLoader SmalltalkImage (and there is no Â·#rehashAllInstances ). ------------------------------------------ I tried this code before and after the change oldDicts := MethodDictionary allInstances. [ | newDicts | newDicts := Array new: oldDicts size. oldDicts withIndexDo: [ :d :index | newDicts at: index put: d rehashWithoutBecome ].] timeToRun And I saw a little improvement in performance (but it fluctuated a lot...). Does anyone know a performance difference between size and basicSize in Dictionary, HashedCollection or MethodDictionary? Thanks

Aug. 21, 2010

[Pharo-project] [update 1.2] #12104

by StÃ©phane Ducasse

12104 ----- - Cleaning left over of at: 4 and first in HTTPServerDirectory and ServerDirectory. - Introduction of SocketPrimitiveFailed from CUIS. Stef

Aug. 21, 2010

Re: [Pharo-project] some important fixes we should focus on for 1.2

by Guillermo Polito

I'll have a look at http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: MethodDictionary improvement On Sat, Aug 21, 2010 at 1:41 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > here is a list of issue I would like to work and get some help. > > Stef > > http://code.google.com/p/pharo/issues/detail?id=2570 Issue 2570: > Removed implicit conversion of DateAndTime equality-testing argument. > > http://code.google.com/p/pharo/issues/detail?id=2579 > http://code.google.com/p/pharo/issues/detail?id=2698 > Â Â Issue 2698: Â Â Â Â Smalltalk registration to SystemChangeNotifier should be handle in startup > http://code.google.com/p/pharo/issues/detail?id=2177 Issue 2177: Â Â Â Â Generalize stream protocol #readInto:startingAt:count: > Issue 1981: Â Â Raising DuplicateError Exception in class builder > http://code.google.com/p/pharo/issues/detail?id=1981 > http://code.google.com/p/pharo/issues/detail?id=2146 Issue 2146: Â Â Â Â Fix SystemChangeNotification for traits. > > http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: Â Â Â Â MethodDictionary improvement > http://code.google.com/p/pharo/issues/detail?id=2315 Method Dictionary Compact protocol to investigate > > http://code.google.com/p/pharo/issues/list?cursor=2313 Â Issue 2313: Â Â HashedCollectionIntegrityTest > > http://code.google.com/p/pharo/issues/detail?id=2583 Issue 2583: Â Â Â Â COG - MessageTally > Â Issue 2619: Â Â ignore vm parameters with nil value in MessageTally, so it can be used in Cog > > http://code.google.com/p/pharo/issues/detail?id=2584 COG- COG- LargeNegativeInteger to be compact at 5 > > http://code.google.com/p/pharo/issues/detail?id=2567 > Â Issue 2567: Â Â evaluate the finalizers outside the protected block in WeakRegistry > > http://code.google.com/p/pharo/issues/detail?id=2564 > Â Issue 2564: Â Â WeakKeyDictionary finalizeValue tests > > http://code.google.com/p/pharo/issues/detail?id=2769 > Issue 2769: Â Â Fixes for broken SocketStream behavior. > > http://code.google.com/p/pharo/issues/list?cursor=2551 weakstructure > > http://code.google.com/p/pharo/issues/detail?can=2&q=2244 > Issue 2244: Â Â Socket support for #next:putAll:startingAt: and #readInto:startingAt:count: > > http://code.google.com/p/pharo/issues/detail?id=2825 > Issue 2825: Â Â [[true] whileTrue] fork cannot be interrupted > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 21, 2010

[Pharo-project] [update 1.2] #12103

by StÃ©phane Ducasse

12103 ----- - Issue 2839: ContextInspector. Thanks Andreas Raab - Issue 2840: UUID class>>fromString36:. Thanks Nicolas Cellier. http://bugs.squeak.org/view.php?id=7262 Stef

Aug. 21, 2010

Re: [Pharo-project] some important fixes we should focus on for 1.2

by StÃ©phane Ducasse

Thanks! Stef On Aug 21, 2010, at 9:09 PM, GermÃ¡n Arduino wrote: > Hi Stef: > > I am with very little free time, but I'm still dealing with the Issue 2770. > > As fas as I can understand and fix it, can try with some of the issues > you commented. > > Cheers. > > 2010/8/21 stephane ducasse <stephane.ducasse(a)free.fr>: >> Hi guys >> >> here is a list of issue I would like to work and get some help. >> >> Stef >> >> http://code.google.com/p/pharo/issues/detail?id=2570 Issue 2570: >> Removed implicit conversion of DateAndTime equality-testing argument. >> >> http://code.google.com/p/pharo/issues/detail?id=2579 >> http://code.google.com/p/pharo/issues/detail?id=2698 >> Issue 2698: Smalltalk registration to SystemChangeNotifier should be handle in startup >> http://code.google.com/p/pharo/issues/detail?id=2177 Issue 2177: Generalize stream protocol #readInto:startingAt:count: >> Issue 1981: Raising DuplicateError Exception in class builder >> http://code.google.com/p/pharo/issues/detail?id=1981 >> http://code.google.com/p/pharo/issues/detail?id=2146 Issue 2146: Fix SystemChangeNotification for traits. >> >> http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: MethodDictionary improvement >> http://code.google.com/p/pharo/issues/detail?id=2315 Method Dictionary Compact protocol to investigate >> >> http://code.google.com/p/pharo/issues/list?cursor=2313 Issue 2313: HashedCollectionIntegrityTest >> >> http://code.google.com/p/pharo/issues/detail?id=2583 Issue 2583: COG - MessageTally >> Issue 2619: ignore vm parameters with nil value in MessageTally, so it can be used in Cog >> >> http://code.google.com/p/pharo/issues/detail?id=2584 COG- COG- LargeNegativeInteger to be compact at 5 >> >> http://code.google.com/p/pharo/issues/detail?id=2567 >> Issue 2567: evaluate the finalizers outside the protected block in WeakRegistry >> >> http://code.google.com/p/pharo/issues/detail?id=2564 >> Issue 2564: WeakKeyDictionary finalizeValue tests >> >> http://code.google.com/p/pharo/issues/detail?id=2769 >> Issue 2769: Fixes for broken SocketStream behavior. >> >> http://code.google.com/p/pharo/issues/list?cursor=2551 weakstructure >> >> http://code.google.com/p/pharo/issues/detail?can=2&q=2244 >> Issue 2244: Socket support for #next:putAll:startingAt: and #readInto:startingAt:count: >> >> http://code.google.com/p/pharo/issues/detail?id=2825 >> Issue 2825: [[true] whileTrue] fork cannot be interrupted >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 21, 2010