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

[Pharo-project] 'foo' asTime

by Philippe Marschall

Guess what it does. Not what I expect it to do. Cheers Philippe

Aug. 22, 2010

Re: [Pharo-project] Beyond animated gif?

by Chris Muller

Hi Bill, I have this exact same requirement in one of my applications. I've started out using mencoder as well, but the "avi" videos files produced cannot be played in Windows. Are you able to play yours in Windows? 2010/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > mencoder can do the job. Â See > > Â Â http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-images.html > > Don't work too hard on getting the list of files to work, at least be warned if you do. Â I put the resulting error message into Google and the first link was a patch with a question about where to send it. Â Helpful, if not encouraging. Â Listing the frame files on the command line does work; I am not sure when any limits on the length of the command line would strike. > > Note that I pass a collection of closures rather than forms; the hope is that it will be less resource hungry than creating all of the frames at one time. > > Bill > > > > ________________________________________ > 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 14, 2010 6:04 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Beyond animated gif? > > Hello all, > > I have a growing number of annotated images and thought it would be nice to make a movie out of them. Â Following the example of an animated gif, I had a result a LOT faster than I expected, but the quality is really poor. Â Maybe setting a palette would help, but I'm wondering if there are other/better ways? Â Extra credit goes to any solution that can be driven from within Pharo or at least w/o littering my drive with lots of images, but I'll take what I can get if the quality is right. > > images2mpg has been mentioned in a few places, but it is playing hard to get. > > 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] FFI and underscores in 1.1 (RC2)

by Lukas Renggli

FYI: I fixed the #numArgs bug in http://code.google.com/p/pharo/issues/detail?id=2844. Lukas On 22 August 2010 16:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Repeat after me: the Debugger is your friend. > You just have to write something like > > Object compile: '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*) module: ''opendbx''> > Â Â ^self externalCallFailed' > > in a workspace and select 'debug it' menu item. > > Since I'm in a good mood, I tell you the result: > > In Parser>>externalFunctionDeclaration you can see this sentence: > > Â Â Â Â (args position = self properties selector numArgs) ifFalse: [ > Â Â Â Â Â Â Â Â ^self expected: 'Matching number of arguments']. > > What if you put an underscore in the selector ? > > Â Â Â #a_piInitialize:backend:host:port: numArgs -> -1 > > This means this selector is not recognized as a valid selector... > So you have to fix String>>numArgs, then you'll be able to compile a > selector with underscores. > > Repeat after me: the Debugger is your friend. > > Nicolas > > 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> See 2842. >> >> Thanks for confirming it! >> >> Bill >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] >> Sent: Sunday, August 22, 2010 5:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) >> >> 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<mailto:bschwab@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<mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Aug. 22, 2010

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

by Nicolas Cellier

Repeat after me: the Debugger is your friend. You just have to write something like Object compile: '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*) module: ''opendbx''> ^self externalCallFailed' in a workspace and select 'debug it' menu item. Since I'm in a good mood, I tell you the result: In Parser>>externalFunctionDeclaration you can see this sentence: (args position = self properties selector numArgs) ifFalse: [ ^self expected: 'Matching number of arguments']. What if you put an underscore in the selector ? #a_piInitialize:backend:host:port: numArgs -> -1 This means this selector is not recognized as a valid selector... So you have to fix String>>numArgs, then you'll be able to compile a selector with underscores. Repeat after me: the Debugger is your friend. Nicolas 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > See 2842. > > Thanks for confirming it! > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] > Sent: Sunday, August 22, 2010 5:41 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) > > 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<mailto:bschwab@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<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 22, 2010

Re: [Pharo-project] Linux vm

by Schwab,Wilhelm K

Eliot, Thanks for you prompt and helpful reply. I will admit I have not tried this yet, but I see where you are going and think it is better to cross-post this into Pharo-dev so it will be searchable via the Gmane archive than to actually see the messages that result; I will sooner or later get to the latter. There is still the possible problem of an errant / in the default plugins path, and that the vm does not provide feedback on failures, at least not that I can find. Problems like I had yesterday go from a frustrating mystery to readily solved with a tiny hint that (in this case) is available from dlerror(); we should pass it along to the programmer. Bill ==================================== Eliot Miranda eliot.miranda at gmail.com Sun Aug 22 02:53:30 UTC 2010 What I do is manually repeat the link command using options that will cause the linker to complain about unresolved symbols. You'll get some false positives (dynamically-linked runtime routines) but you'll also get any actually undefined symbols. Use -Wl,--warn-unresolved-symbols -Wl,--no-allow-shlib-undefined when manually repeating the link command. So while this is after the fact you should try remaking your plugin with the libusb support missing, copy the link command and repeat it adding -Wl,--warn-unresolved-symbols -Wl,--no-allow-shlib-undefined and this tie you should see the link fail while listing libusb_close et al. HTH Eliot ________________________________________ 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 10:39 PM To: Pharo-project(a)lists.gforge.inria.fr; vm-dev(a)lists.squeakfoundation.org Subject: Re: [Pharo-project] Linux vm 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 _______________________________________________ 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] FFI and underscores in 1.1 (RC2)

by Schwab,Wilhelm K

See 2842. Thanks for confirming it! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Sunday, August 22, 2010 5:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) 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<mailto:bschwab@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

[Pharo-project] VMIL 2010: extended deadline

by Michael Haupt

Apologies for multiple copies. ** EXTENDED DEADLINE: September 1st, 2010 ** Dear Colleagues: It gives us great pleasure to invite you to submit your contributions to **the fourth international workshop on Virtual Machines and Intermediate Languages (VMIL 2010)**, which will be co-located with SPLASH 2010 (former OOPSLA). This workshop is a forum for research in virtual machines (VM) and intermediate languages (IL). It is dedicated to identifying programming mechanisms and constructs that are currently realized as code transformations or implemented in libraries but should rather be supported at VM and IL level. ------------------------------------------------------------ **Invited Talks** In the tradition of past VMIL workshops, the 2010 edition will feature high-quality, on-topic invited talks. At this moment, talks by Cliff Click and Kathryn McKinley are confirmed. ------------------------------------------------------------ **Due Dates** Papers for VMIL are due September 1, 2010. Notification of acceptance will be on September 12, 2010. ------------------------------------------------------------ **Program Committee** We have once again assembled an excellent program committee which consists of Walter Binder, Steve Blackburn, Erik Ernst, Naveen Kumar, Doug Simon, Roel Wuyts, and all workshop organizers. ------------------------------------------------------------ For more details please see: http://www.cs.iastate.edu/~design/vmil/ We look forward to your submissions to VMIL 2010. Best regards, Hridesh Rajan, Christoph Bockisch, Michael Haupt and Robert Dyer VMIL 2010 Organizers

Aug. 22, 2010

Re: [Pharo-project] SocketStream enh

by Lukas Renggli

On 22 August 2010 13:53, Philippe Marschall <kustos(a)gmx.net> wrote: > On 18.08.2010 12:56, StÃ©phane Ducasse wrote: >> >>>>>> I will integrate the following SocketStream tests and before I would love to see if this >>>>>> does not impact seaside >>>>>> >>>>>> http://code.google.com/p/pharo/issues/detail?id=2767 >> >> Does anybody have the time to give feedback on this important network changes? > > I did a short test with Seaside and everything still seems to work. And > if it fixes bugs, I'm all tits forward about it. > > The deprecation of SmalltalkImage >> #platformName is a PITA though. It > requires us to have different versions of Comanche and WebClient for > different versions of Pharo. Pharo 1.0 is long outdated, Pharo 1.2 is not stable yet. We should only target Pharo 1.1. Also the latest development tools only work in Pharo 1.1. There is no point in making Seaside work in all versions. Lukas -- Lukas Renggli www.lukas-renggli.ch

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: > So, is it safe to integrate? If you're asking me, I don't know for sure, because I don't use Pharo. But it's probably safe. Levente > > 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 >> > > _______________________________________________ > 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] SocketStream enh

by Philippe Marschall

On 18.08.2010 12:56, StÃ©phane Ducasse wrote: > >>>>> I will integrate the following SocketStream tests and before I would love to see if this >>>>> does not impact seaside >>>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=2767 > > Does anybody have the time to give feedback on this important network changes? I did a short test with Seaside and everything still seems to work. And if it fixes bugs, I'm all tits forward about it. The deprecation of SmalltalkImage >> #platformName is a PITA though. It requires us to have different versions of Comanche and WebClient for different versions of Pharo. Cheers Philippe

Aug. 22, 2010