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

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

by Henrik Johansen

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] Preparing the pharo sprint friday 8th of July

by Sven Van Caekenberghe

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.

July 6, 2011

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

by Sven Van Caekenberghe

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. Is this an open access campus/building ? Is the parking space open for visitors ? What is the room ? Will there be food ? Timeframe ? Sven

July 6, 2011

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

by Sven Van Caekenberghe

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

July 6, 2011

Re: [Pharo-project] "I arranged all my public packages with metacello."

by Mariano Martinez Peck

On Tue, Jul 5, 2011 at 2:52 AM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > Hi, > > I arranged all my public packages with metacello. > http://www.squeaksource.com/DaliotsPlayground.html > > What i did was: > step 0. learned metacello with ProStef (ProStef rocks!) > step 1. create a new repository www.squeaksource.com/DaliotsPlayground. > step 2. upload all public packages to it. (Gofer push rocks!) > step 3. With clean image, test each packages installable stand-aone. > This step is a good one, and not everybody does it. It is good to detect if you have specified correctly all the dependencies for each package. Dale, do you think something like this can be added to Metacello toolbox? > step 4. Write small ConfigurationOfXXX package for each package that does > not install alone. > Notice that even if the package is stand alone, it may be worth it to have a conf, because you can still bless versions as released, development, etc. You can descriptions of releases, etc.... > step 5. realize all those small ConfigurationOfXXX have many redundancy. > step 6. create ConfigurationOfDaliotsPlayground and copied baselines and > versions into it. > step 7. removed all ConfigurationOfXXX except > ConfigurationOfDaliotsPlayground. > > Interesting. > ** through this process, tested each packages and ConfigurationOfXXXs by > installing them in clearn image. > > problems: > 1. package testing was uneffiicient consuming a lot of time. > :( it would be good to make it automatic > 2. download counts and activity indicator soared unintentionally. > the same happens with Hudson ;) > 3. testing doubles since Squeak compatibility is not checked. > > yes, but Metacello cannot do magic ;) > Best Regards > > -- > View this message in context: > http://forum.world.st/I-arranged-all-my-public-packages-with-metacello-tp36… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

July 6, 2011

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

by StÃ©phane Ducasse

Hi guys we can also have a skype connection so let us know. Stef On Jul 2, 2011, at 7:44 PM, 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 >

July 6, 2011

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

by Janko MivÅ¡ek

Hi guys, 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: If I put a breakpoint in this method, most processes waiting on socket raise an exception and I can manually terminate them. CPU is then back to normal. But still 48 sockets and their processes are open. Now I debug one such process from Process monitor and immediatelly another batch of self halt exceptions are raised. Now I managed to manually close all sockets and their processes. Has anyone an idea how to avoid those sockets being deadlocked on some waiting? It seems that they timeout but are soon back. They seem to timeout quite fast, is this a reason for 100% CPU? Why I cannot close them but instead a close fail with primitive failure? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 6, 2011

Re: [Pharo-project] About locating home

by Andreas Raab

On 7/4/2011 9:15, Marcus Denker wrote: > > On Jul 4, 2011, at 9:11 AM, Damien Cassou wrote: > >> On Sun, Jul 3, 2011 at 4:25 PM, StÃ©phane Ducasse >> <Stephane.Ducasse-MZpvjPyXg2s(a)public.gmane.org> wrote: >>> FS uses SecurityManager as a fix point to identify home. >>> Now we do not have Security manager so I'm wondering if we should not remove home/document/desktop from FS, >>> else any ideas how we can replace the entry point a securityManager? >> >> Here is some words exchanged with Colin: >> >> On Sun, Apr 17, 2011 at 2:36 AM, Damien Cassou<damien.cassou-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >>> on my computer, the following >>> FSPlatformResolver forCurrentPlatform home >>> evaluates to >>> /home/cassou/Documents/squeak >>> But I would have thought this would return '/home/cassou' instead. >> >> Hi Damien, >> >> Thanks for the report. Using the SecurityManager is a bit of a hack, >> and it doesn't work on all platforms. I'll see what I can do for the >> next release, but I think the only real way to fix this is through >> platform-specific plugin. > > ... 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. Cheers, - Andreas

July 6, 2011

[Pharo-project] [ANN] Fuel version 1.5 released

by Martin Dias

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).

July 6, 2011

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

by Noury Bouraqadi

I'll be there.. But I don't have the rights to add my name. Noury On 2 juil. 2011, at 21:20, Marcus Denker wrote: > > On Jul 2, 2011, at 7:45 PM, 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. >> >> > I added it to > > http://code.google.com/p/pharo/wiki/PharoSprints > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > Noury Bouraqadi http://car.mines-douai.fr/noury -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

July 6, 2011