- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by Eliot Miranda

Oops, I'm soooo stupid :) Instead, put the count in the finalization loop, and compare against it. e.g. finalizationProcess [true] whileTrue: [ WeakFinalizationList initTestPair. FinalizationSemaphore wait. >>> FinalizationCount := FinalizationCount + 1. FinalizationLock critical: [ WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [ [ weakDependent finalizeValues ] on: Exception fork: [:ex | ex pass ] ]]]]. finalizationCount ^FinalizationCount Set subclass: #WeakSet instanceVariableNames: 'flag finalizationCount' classVariableNames: '' poolDictionaries: '' category: 'Collections-Weak' size | newFinalizationCount | newFinalizationCount := WeakArray getFinalizationCount. newFinalizationCount == finalizationCount ifTrue: [^tally]. tally := self computeActualSIze. finalizationCount := newFinalizationCount On Fri, Jun 7, 2013 at 11:30 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Fri, Jun 7, 2013 at 2:34 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > >> On 7 juin 2013, at 11:19, Pharo Issue Tracker wrote: >> >> A FogBugz case was edited by Stephane Ducasse. >> >> Case ID: 10840 >> Title: WeakSet>>#size utterly broken >> Status: Resolved (Fix Review Needed) >> Category: Bug >> Project: Collection >> Area: Misc >> Priority: 3 - Must Fix >> Milestone: Pharo3.0: 30/03/2014 >> Assigned To: Camille Teruel >> >> URL: https://pharo.fogbugz.com/f/cases/10840 >> >> Last message: >> Please can you send a mail to the mailing-list so that we all discuss >> this problems. >> >> >> Hello everyone, >> >> WeakSet>>#size is broken as demonstrated by the following snippet: >> >> set := WeakSet new. >> set add: Object new. >> Smalltalk garbageCollect. >> set size. "answers 1 instead of 0" >> >> That is because a WeakSet has no mean to know when its items get garbage >> collected, and thus the tally cannot be updated. >> So we need to override #size in Weak, I propose: >> size >> | counter | >> counter := 0. >> self do: [ :e | counter := counter + 1 ]. >> ^ counter >> But that it rather inefficient for such a simple query. >> Any proposition? >> > > One way is to add WeakSets to FInalizationDependents and implement > finalizeValues to update the size. But that's making work. A lazy > solution might be better. > > You *could*, I suppose, use the VM's count of the number of incremental > and full GCs (alas there's no single count). I think this is too ugly and > one would need something neater, but it would work like this: > > size > | newGCCount | > newGCCount := self getGCCount. > newGCCount == existingGCCount ifTrue: > [^tally]. > tally := self computeActualSIze. > existingGCCount := newGCCount > > where > getGCCount > ^(Smalltalk vmParameterAt: 7) + (Smalltalk vmParameterAt: 9) > > There are obviously thread-safety issues here, but there are issues with > the existing code and your suggestion too ;) > > The most useful single count here would be a count that was incremented > once in each GC that finalized one or more references. > > Note also that for this to be reliable instances' record of the count > would have to be invalidated on snapshot or start-up, which could entail an > expensive allInstancesDo:. > > Perhaps the class WeakSet should maintain its instances in (of course) a > WeakSet and then add only itself to FinalizationDependents and enumerate > the set on finalization? > > > > I note that in the VisualWorks VM, objects that have references finalized > are added to a queue so every instance that loses a reference gets sent > finalize, instead of only dependents as in Squeak. This has its won > problems (the VM must cope with a potentially large list) but I think it > provides more convenient control. > > >> >> The bug entry is: https://pharo.fogbugz.com/f/cases/10840 >> >> >> >> If you do not want to receive automatic notifications anymore, change >> your preferences in the Options screen. ( >> https://pharo.fogbugz.com/default.asp?pg=pgPrefs) >> >> >> > > > -- > best, > Eliot > -- best, Eliot

June 7, 2013

[update 3.0] #30188

by StÃ©phane Ducasse

30188 ----- 10745 [ENH]: MethodContext>>#callChainAnySatisfy: https://pharo.fogbugz.com/default.asp?10745 10838 an MCOrganizationDefinition should only remove empty categories during unload https://pharo.fogbugz.com/default.asp?10838 10853 AlainTreeModel: Want menu on tree items only https://pharo.fogbugz.com/default.asp?10853 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-StephaneDucasse.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-StephaneDucasse.81… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1472.d…

June 7, 2013

OpenGL: NBMacGlAPI missing?

by Alexandre Bergel

Hi! I have installed NBOpenGL from http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL I have loaded Version 2.0 using the configuration The method NBMacGlAPI>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry refers to the class NBCallFailureHandler, which is not existing Apparently NBSTIvarLoader is also missing... I guess ConfigurationOfNBOpenGL is not loading everything... It would be nice to fix this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 7, 2013

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by Eliot Miranda

On Fri, Jun 7, 2013 at 2:34 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > On 7 juin 2013, at 11:19, Pharo Issue Tracker wrote: > > A FogBugz case was edited by Stephane Ducasse. > > Case ID: 10840 > Title: WeakSet>>#size utterly broken > Status: Resolved (Fix Review Needed) > Category: Bug > Project: Collection > Area: Misc > Priority: 3 - Must Fix > Milestone: Pharo3.0: 30/03/2014 > Assigned To: Camille Teruel > > URL: https://pharo.fogbugz.com/f/cases/10840 > > Last message: > Please can you send a mail to the mailing-list so that we all discuss this > problems. > > > Hello everyone, > > WeakSet>>#size is broken as demonstrated by the following snippet: > > set := WeakSet new. > set add: Object new. > Smalltalk garbageCollect. > set size. "answers 1 instead of 0" > > That is because a WeakSet has no mean to know when its items get garbage > collected, and thus the tally cannot be updated. > So we need to override #size in Weak, I propose: > size > | counter | > counter := 0. > self do: [ :e | counter := counter + 1 ]. > ^ counter > But that it rather inefficient for such a simple query. > Any proposition? > One way is to add WeakSets to FInalizationDependents and implement finalizeValues to update the size. But that's making work. A lazy solution might be better. You *could*, I suppose, use the VM's count of the number of incremental and full GCs (alas there's no single count). I think this is too ugly and one would need something neater, but it would work like this: size | newGCCount | newGCCount := self getGCCount. newGCCount == existingGCCount ifTrue: [^tally]. tally := self computeActualSIze. existingGCCount := newGCCount where getGCCount ^(Smalltalk vmParameterAt: 7) + (Smalltalk vmParameterAt: 9) There are obviously thread-safety issues here, but there are issues with the existing code and your suggestion too ;) The most useful single count here would be a count that was incremented once in each GC that finalized one or more references. Note also that for this to be reliable instances' record of the count would have to be invalidated on snapshot or start-up, which could entail an expensive allInstancesDo:. Perhaps the class WeakSet should maintain its instances in (of course) a WeakSet and then add only itself to FinalizationDependents and enumerate the set on finalization? I note that in the VisualWorks VM, objects that have references finalized are added to a queue so every instance that loses a reference gets sent finalize, instead of only dependents as in Squeak. This has its won problems (the VM must cope with a potentially large list) but I think it provides more convenient control. > > The bug entry is: https://pharo.fogbugz.com/f/cases/10840 > > > > If you do not want to receive automatic notifications anymore, change your > preferences in the Options screen. ( > https://pharo.fogbugz.com/default.asp?pg=pgPrefs) > > > -- best, Eliot

June 7, 2013

Re: [Pharo-dev] new Cog VMs available

by StÃ©phane Ducasse

thanks eliot. Stef On Jun 7, 2013, at 8:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Fri, Jun 7, 2013 at 8:20 AM > Subject: new Cog VMs available > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development <pharo-project(a)lists.gforge.inria.fr> > > > CogVM source as per VMMaker.oscog-eem.296/r2732. > > Make the Production/Debug/Assert distinction static so one can find it with > strings - vm. Add an ident for the ITIMER_HEARTBEAT linux VMs. > > Fix bug in eden filling/object overwrite checking. must use unsigned > vars in the fill loop. > > Add a plugin to support the VMProfiler on linux (now Steve Rees > has told us how to get proper thread priorities on newer linuxes). > > Replace broken primitiveUtcWithOffset with a version that works. > Cast primitiveUtcWithOffset in terms of a new ioLocalSecondsOffset. > > Add stricter checking code to OSProcessPlugins. > > Add SqueakSSL plugin to nsvm plugins. > > Change -version output to print if a Production, Debug or Assert VM. > > Add some error checking to the UnixOSProcessPlugin's forkAndExecInDirectory > prim. Eliminate some compiler warnings in the plugin. > > Eliminate some excessive use of push/popRemappableOop[:] in the SocketPlugin. > > Fix numberic option parsing in sqSocketSetOptions... (quite possibly the longest > C function name I've ever seen). The old code only supported 1-digit length > values, so setsockopt(SO_SNDBUF, 4096 didn't do what was expected at all > (attempted to set the buffer size to 909717556, which is little-endian ascii > for '4096', '4096' asByteArray unsignedLongAt: 1 => 909717556). > > Occasionally bizarre interactions cause the heartbeat's interval timer to > disable. e.g. on CentOS linux when using PAM to authenticate, a failing authen- > tication sequence disables the interval timer, for reasons unknown (setting > a breakpoint in setitimer doesn't show an actual call). So a work around is > to check the timer as a side-effect of ioRelinquishProcessorForMicroseconds. > > Add Callback LIFO ordering support to the new-style Callback return primitives > to the IA32ABI Aline plugins. Fix some compiler warnings there-in. > > Improve the debug message printing in sqUnixExternalPrims.c so it prints line > numbers. > -- > best, > Eliot > > > > -- > best, > Eliot

June 7, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by Bernardo Ezequiel Contreras

Marcus, imho, the filename "latest.zip" is very good because i can have a unique url to that image. i.e. http://files.pharo.org/image/20/latest.zip On Fri, Jun 7, 2013 at 11:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > I changed all links to point to the latest 2.0 build on files.pharo.org > > Reason: > > -> We are fixing bugs, yet people downloading 2.0 do not see the > fix > -> We had multiple times that people wasted quite some effort > re-reporting bugs > that are already fixed. > > Notes > -> the file name "latest.zip" is not good for the image. It should > encode that it is the image only and the version number maybe? > -> I did not change any VM related download links, but I think we > should do the same there. > > > Marcus > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

June 7, 2013

Fwd: new Cog VMs available

by Eliot Miranda

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: Fri, Jun 7, 2013 at 8:20 AM Subject: new Cog VMs available To: Squeak Virtual Machine Development Discussion < vm-dev(a)lists.squeakfoundation.org> Cc: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org>, Pharo Development < pharo-project(a)lists.gforge.inria.fr> CogVM source as per VMMaker.oscog-eem.296/r2732. Make the Production/Debug/Assert distinction static so one can find it with strings - vm. Add an ident for the ITIMER_HEARTBEAT linux VMs. Fix bug in eden filling/object overwrite checking. must use unsigned vars in the fill loop. Add a plugin to support the VMProfiler on linux (now Steve Rees has told us how to get proper thread priorities on newer linuxes). Replace broken primitiveUtcWithOffset with a version that works. Cast primitiveUtcWithOffset in terms of a new ioLocalSecondsOffset. Add stricter checking code to OSProcessPlugins. Add SqueakSSL plugin to nsvm plugins. Change -version output to print if a Production, Debug or Assert VM. Add some error checking to the UnixOSProcessPlugin's forkAndExecInDirectory prim. Eliminate some compiler warnings in the plugin. Eliminate some excessive use of push/popRemappableOop[:] in the SocketPlugin. Fix numberic option parsing in sqSocketSetOptions... (quite possibly the longest C function name I've ever seen). The old code only supported 1-digit length values, so setsockopt(SO_SNDBUF, 4096 didn't do what was expected at all (attempted to set the buffer size to 909717556, which is little-endian ascii for '4096', '4096' asByteArray unsignedLongAt: 1 => 909717556). Occasionally bizarre interactions cause the heartbeat's interval timer to disable. e.g. on CentOS linux when using PAM to authenticate, a failing authen- tication sequence disables the interval timer, for reasons unknown (setting a breakpoint in setitimer doesn't show an actual call). So a work around is to check the timer as a side-effect of ioRelinquishProcessorForMicroseconds. Add Callback LIFO ordering support to the new-style Callback return primitives to the IA32ABI Aline plugins. Fix some compiler warnings there-in. Improve the debug message printing in sqUnixExternalPrims.c so it prints line numbers. -- best, Eliot -- best, Eliot

June 7, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by btc＠openinworld.com

Marcus Denker wrote: > Hi, > > I changed all links to point to the latest 2.0 build on files.pharo.org > > Reason: > > -> We are fixing bugs, yet people downloading 2.0 do not see the fix > -> We had multiple times that people wasted quite some effort re-reporting bugs > that are already fixed. > > Notes > -> the file name "latest.zip" is not good for the image. It should encode that it is the image only and the version number maybe? > -> I did not change any VM related download links, but I think we should do the same there. > > > Marcus > That is great that 2.0 is continuing to improve. +100 for including version numbers on the web page - something like [1]. For the purpose of reproducibility and least surprise, at [2] where it currently says "2.0 (release)" and "Pharo2.0 (win)" I would expect that link to download the _exact_ same file every time, except today that zip file contains files dated today, so obviously is not the same file as last week. You might get away with following "latest" with a link called "Pharo2 (win)" without the minor-version number, but by including a a minor-version number I would expect that it is the constant point-in-time snapshot of the _2.0 release_. [1] http://www.python.org/download/ [2] http://www.pharo-project.org/pharo-download Also, revisiting (major.minor.bugfix) semantic versioning in the context of Pharo, an important part of configuration management for a user is matching versions of VM to Image. For me, I simply this when I update by always taking the fat zip which include both - but it would be nice to have the confidence to just take the image. So it would be good if the VM/Image dependency could be encoded by the version numbers. Something like the following... My shallow understanding of the CI infrastructure is that to "some degree" : 1. the Image CI runs against a constant VM version 2. the VM CI runs against a constant Image version So considering Case 1... a. Image updates would bump only the bugfix number. b. VM updates would bump the minor number. This would make is easy for a user to always determine that Image version 2.2.x was tested against VM Pharo22.exe. To avoid excessively incrementing the minor version number, considering Case 2... c. (for example) you would begin testing VM updates against constant Image 2.0.0 d. when a required VM update breaks a test in Image 2.0.0, then increment the minor version number. Work to get latest VM and latest Image both green. These then become Pharo21.exe and Image 2.1.0, which are used as a the next starting point for Case 1. Further VM updates are now tested against constant Image 2.1.0. Now if you do the same with Pharo 3, then of course you might end up with Pharo25.exe and Pharo31.exe VMs being identical files, but from a user perspective that is a reasonable price to pay for the gain in configuration management. P.S. Its great that the CI infrastructure even allows me to think along these lines. cheers -ben

June 7, 2013

[update 3.0] #30188

by StÃ©phane Ducasse

30188 ----- 10867 enabled: cleans post fix https://pharo.fogbugz.com/default.asp?10867 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDuc…

June 7, 2013

[update 3.0] #30187

by StÃ©phane Ducasse

June 7, 2013