July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Sockets don't close, 100% CPU

by Sven Van Caekenberghe

On 06 Jul 2011, at 15:48, Henrik Johansen wrote: > Alternatively, to see what I mean fast, evaluate in a workspace using a Cog VM: > overflowingSockets := (1 to: Smalltalk vm maxExternalSemaphores / 2) collect: [:e | Socket newTCP] I didn't know about #maxExternalSemaphores and maxExternalSemaphores: Nice to see DomainError being used ;-) Sven

July 6, 2011

Re: [Pharo-project] Latest and greatest OSProcessPlugin for CogVM

by Igor Stasenko

On 6 July 2011 14:49, Danie Roux <lists+pharo(a)danieroux.com> wrote: > Hi all, > > Can someone point me to the latest and greatest Linux32 binary of > OSProcessPlugin? > > I have strange lockups with my current version of the plugin > (UnixOSProcessPlugin 10 April 2010) and the latest from > squeaksource.com/OSProcess.html > > Before I bug (pun intended) David, I would like to try the latest version. > > With my current configuration, this locks up my image quickly (and the > timestamp on /tmp/weird stops changing): > > 10000 timesRepeat: [ OSProcess waitForCommand: 'touch /tmp/weird'. ] > Just a note: This is on my list of todos for building this plugin for cog vms out of the box. But i haven't done anything for it yet. > -- > Danie Roux *shuffle* Adore Unix - http://danieroux.com > > -- Best regards, Igor Stasenko AKA sig.

July 6, 2011

Re: [Pharo-project] Sockets don't close, 100% CPU

by Henrik Johansen

On Jul 6, 2011, at 3:16 39PM, StÃ©phane Ducasse wrote: > I do not understand. We fixed the problem reported by chris. > So is there something else? > > Stef Read the last 2 posts in the thread, the issue is not related to what turned out to be solution for Chris' problem, but my wrong speculation of what it might be. ;) Alternatively, to see what I mean fast, evaluate in a workspace using a Cog VM: overflowingSockets := (1 to: Smalltalk vm maxExternalSemaphores / 2) collect: [:e | Socket newTCP] And then try to connect to a Monticello repository :) Cheers, Henry

July 6, 2011

Re: [Pharo-project] Preparing the pharo sprint friday 8th of July

by StÃ©phane Ducasse

On Jul 6, 2011, at 11:05 AM, Sven Van Caekenberghe wrote: > > On 02 Jul 2011, at 19:44, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I'm preparing the sprint and I would like to know who is attending. >> http://rmod.lille.inria.fr/ for the location. >> >> Stef > > I'll be coming as well. > > So I just drive to the Av. Carl Gauss, building M3/M5 I guess. yes we are in the M3 > Is this an open access campus/building ? yes > Is the parking space open for visitors ? plenty > What is the room ? 116 Now I'm checking for the space. > Will there be food ? yes :) > Timeframe ? we wil there around 9h > > Sven > > >

July 6, 2011

Re: [Pharo-project] [Pharo-fuel] [ANN] Fuel version 1.5 released

by StÃ©phane Ducasse

thanks a lot. Stef > Changes on 1.5: > > - Initialize instances after materialization implementing > #fuelAfterMaterialization. > - Ignore transient instance variables overriding > #fuelIgnoredInstanceVariableNames. > - Limit serialization progress bar to update at most once every 250 > milliseconds. > - Traits are serialized and materialized as a regular objects > (http://code.google.com/p/fuel/issues/detail?id=59) > - Removed mappers system cache (Eliot). > - Many new tests. > - Benchmarks: compare Fuel against StOMP, SRP, SIXX, Magma, EsAndEm > and Fuel with progress bar. > - Benchmarks: new samples, scripts, and CSV exporter. > - Benchmarks: measure serialization stream size. > - Removed some redundant #fuelAccept:. > - Several aesthetic changes in protocols, categories and comments. > - Now #materialize answers the materialized root. > - Removed special cluster for HashedCollection.Now #rehash is sended > via #fuelAfterMaterialization. > - MethodContext serialization does not serialize temps > (http://code.google.com/p/fuel/issues/detail?id=61) > - Classes and Traits now serialize its environment > (testCreateWithSmalltalkGlobalsEnvironment). > - Fixed serialization of non-octet characters (testCharacter). > - Fixed a bug serializing the system dictionary. > FLWellKnownObjectsCluster handles it. (testSmalltalkGlobals). > - Fixed a bug serializing class variables (testClassVariable). > - Fixed a bug when serializing a collection with size greater than > 1^16 with repeated elements inside. > - Fixed testTwoCompiledMethodsReferencingSameClassVariable. > - Optimization: instanceIndexes are directly created with the exact > size (Henrik). > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

July 6, 2011

Re: [Pharo-project] Sockets don't close, 100% CPU

by StÃ©phane Ducasse

I do not understand. We fixed the problem reported by chris. So is there something else? Stef On Jul 6, 2011, at 11:19 AM, Henrik Johansen wrote: > > On Jul 6, 2011, at 10:54 33AM, Sven Van Caekenberghe wrote: > >> >> On 06 Jul 2011, at 10:40, Janko MivÅ¡ek wrote: >> >>> If I recall others have also problems with sockets in Pharo, so here is >>> the my current image, which: >>> >>> - has 105 Sockets open, mostly waiting >>> - has also >105 processes open >>> - consumes 100% cpu >>> - on aSocket close responds with primitive failure >>> - image is workable, I can browse etc. >>> >>> - Pharo1.2.2a on Linux >>> >>> Sockets are waiting on Socket>>waitForConnectionFor:ifTimeOut: >> >> Is that number of open sockets and processes by design or not ? If they keep coming back, you must be creating them. Your application has to keep these (expensive) resources under control to start with. >> >> Long running Seaside images seem to be fine and they are using sockets and processes a lot. >> >> Socket have #close and #destroy, there might be a difference. >> >> I think that part of the cleanup of sockets is delayed (using finalization) and needs some GC work to complete. GC policies might be involved as well as weak datastructures. >> >> I am also interested in knowning the practical upper bound for open sockets and number of processes. >> >> Sven > > http://forum.world.st/Networking-change-in-Pharo-1-2-tp3456097p3461723.html > should explain it. > > TLDR; Changes in the image are required to work with Cog without silently failing to signal semaphores when too many Sockets are open. > > Cheers, > Henry

July 6, 2011

Re: [Pharo-project] About locating home

by StÃ©phane Ducasse

>> ... which will take 12 month to appear in the VM. Oh, all but the Windows >> VM, of course, because there the Maintainer-who-knows-everything-better-and-needs-to-constantly-show-it >> will have the inspiration in the last minute of realizing that "it can be done better", but of course he has no time >> nor intention of actually doing anything other than blocking everything. > > Yes Markus. Keep treating people like this. It's a great way to make friends. Your style of leadership in this project is truly amazing. Take it easy andreas :) You will even look cooler so winning in PR. Now may be you planted really bad seeds long time ago and they still blossom? Time will be needed to cure some strong hurts. Doru would say that everything has its own flow. After the semaphore fix was not integrated after nearly 2 years so marcus is not that wrong for the delay. Soon with our built system this will be fixed and the semaphore fixed will be integrated. >From my side I'm over that, I know my limits and yours. Now my goal is to build positive energy in this community and make sure that people can build they future (make money, have success based on my days of work). Good holidays. Stef PS: BTW the Pharo mailing-list is not a space for politically correctness. Sorry about that but we will not get that way. We will say crap, bad, and other non politically terms.

July 6, 2011

[Pharo-project] Latest and greatest OSProcessPlugin for CogVM

by Danie Roux

Hi all, Can someone point me to the latest and greatest Linux32 binary of OSProcessPlugin? I have strange lockups with my current version of the plugin (UnixOSProcessPlugin 10 April 2010) and the latest from squeaksource.com/OSProcess.html Before I bug (pun intended) David, I would like to try the latest version. With my current configuration, this locks up my image quickly (and the timestamp on /tmp/weird stops changing): 10000 timesRepeat: [ OSProcess waitForCommand: 'touch /tmp/weird'. ] -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

July 6, 2011

Re: [Pharo-project] Preparing the pharo sprint friday 8th of July

by Marcus Denker

On Jul 6, 2011, at 11:08 AM, Sven Van Caekenberghe wrote: > > On 06 Jul 2011, at 10:22, Noury Bouraqadi wrote: > >> But I don't have the rights to add my name. > > BTW, the last Brussels Sprint is not on that page, might be good for historical reasons. > Added... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 6, 2011

Re: [Pharo-project] [Esug-list] [ANN] Fuel version 1.5 released

by Alexandre Bergel

Impressive Alexandre On 6 Jul 2011, at 10:27, Martin Dias wrote: > I am happy to announce the new release version 1.5. Below is the list > of changes. In next days we will update the home page with current > state. For example, we have much more to show in benchmarks section. > Of course, we have many ideas and new issues to keep working on Fuel. > > Again, I have to thank ESUG for sponsoring me for Fuel development > through the SummerTalk program. > > Changes on 1.5: > > - Initialize instances after materialization implementing > #fuelAfterMaterialization. > - Ignore transient instance variables overriding > #fuelIgnoredInstanceVariableNames. > - Limit serialization progress bar to update at most once every 250 > milliseconds. > - Traits are serialized and materialized as a regular objects > (http://code.google.com/p/fuel/issues/detail?id=59) > - Removed mappers system cache (Eliot). > - Many new tests. > - Benchmarks: compare Fuel against StOMP, SRP, SIXX, Magma, EsAndEm > and Fuel with progress bar. > - Benchmarks: new samples, scripts, and CSV exporter. > - Benchmarks: measure serialization stream size. > - Removed some redundant #fuelAccept:. > - Several aesthetic changes in protocols, categories and comments. > - Now #materialize answers the materialized root. > - Removed special cluster for HashedCollection.Now #rehash is sended > via #fuelAfterMaterialization. > - MethodContext serialization does not serialize temps > (http://code.google.com/p/fuel/issues/detail?id=61) > - Classes and Traits now serialize its environment > (testCreateWithSmalltalkGlobalsEnvironment). > - Fixed serialization of non-octet characters (testCharacter). > - Fixed a bug serializing the system dictionary. > FLWellKnownObjectsCluster handles it. (testSmalltalkGlobals). > - Fixed a bug serializing class variables (testClassVariable). > - Fixed a bug when serializing a collection with size greater than > 1^16 with repeated elements inside. > - Fixed testTwoCompiledMethodsReferencingSameClassVariable. > - Optimization: instanceIndexes are directly created with the exact > size (Henrik). > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 6, 2011