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-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K
[bsch...@anest.ufl.edu]
Sent: Saturday, August 21, 2010 8:19 PM
To: Pharo-project@lists.gforge.inria.fr; vm-...@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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899
So, is it safe to integrate? Guille On Sat, Aug 21, 2010 at 9:06 PM, Levente Uzonyi 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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12104
12104 - - Cleaning left over of at: 4 and first in HTTPServerDirectory and ServerDirectory. - Introduction of SocketPrimitiveFailed from CUIS. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] some important fixes we should focus on for 1.2
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 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12103
12103 - - Issue 2839: ContextInspector. Thanks Andreas Raab - Issue 2840: UUID class>>fromString36:. Thanks Nicolas Cellier. http://bugs.squeak.org/view.php?id=7262 Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] some important fixes we should focus on for 1.2
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 : >> 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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > = > Germán S. Arduino Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > = > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] FFI and underscores in 1.1 (RC2)
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] some important fixes we should focus on for 1.2
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 : > 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- = Germán S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trying to install Rio file handling package
Thanks. Lawson On 8/20/10 2:46 PM, Schwab,Wilhelm K wrote: Rio was a thorn in my side for several (sub)releases, but it was apparently because something was loading an old version of it?? You might try loading it in Linux, as there was a bug that would prevent it loading on Windows at one point, but it could load on Linux (and probably a mac too), after which it would have to fixed for the image to load on Windows. Good luck. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] some important fixes we should focus on for 1.2
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
