- Pharo-dev - lists.pharo.org

[Pharo-project] [Jenkins] State of transition Hudson -> Jenkins
by Marcus Denker July 6, 2011

July 6, 2011

State of transition Hudson -> Jenkins ============================= We are slowly (step by step) moving builds from Hudson to Jenkins. the last days e.g. Coral (the scripting engine), RPackage, Nautilus... https://ci.lille.inria.fr/pharo/ The largest thing to move will be the VM autobuilt... that will be done later. Jean Baptiste Arnaud started with a setup for regression testing. https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20Regression%20Tests/ This means "doing something slow" "run all tests" get new image "doing something other" "run all tests" The idea here is that this will be used for the following -> recompile the image -> decompile and recompile the decompiled code -> pretty print -> condense sources -> condense changes .... On the TODO list we have -> test the compiled VMs by running all tests on all plattforms -> update the One-click build script with the last good VM -> update the VM used to do everything with the self-build vm The goal is of course to have that what we release be build completely without human intervention, after every commit (either VM source or Image level change). In addtion, this setup will be available for others to use. This way students can easily clone the VM source and set up Continuous Integration for their research Fork. This will than make it far far easier for people to invent cool stuff that needs VM changes, like e.g. this: http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf or http://rmod.lille.inria.fr/archives/papers/Arna10a-Tools2010-ReadOnlyExecut… The problem right now is that all the code is "somewhere" and just picking up where the student left is a huge amount of work... with Git and autbuild, this will get much much better. (and it simplifies the life of the student a lot... autobuild, easy to track changes in the upstream...) JB already successfully builds his Handle VM: https://pharo-ic.lille.inria.fr/hudson/job/Handles/ So we are getting there. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] reloaded Core failing tests
by Pavel Krivanek July 6, 2011

July 6, 2011

Hi Marcus, add this line to the initCore.st script on CI server: ActiveHand instVarNamed: #targetOffset put: 0@0. this will fix the testTargetPoint. The second and last failing tests is related to compressed unicode tables in the kernel image. I will prepare the code that will regenerate this tables. The second option is to disable call of privShrinkUnicodeTables method in privShrinkingProcess. The resultant kernel and gofer images will be bigger. The question is if we will shrink this tables by default. -- Pavel

1 0

[Pharo-project] [ANN] Fuel version 1.5 released (bis)
by Martin Dias July 6, 2011

July 6, 2011

Hi. I am happy to announce the new release version 1.5. At the end of this message is the list of changes. Fuel is a binary serialization system for Smalltalk that provides extremely fast deserialization. More information on our home page<http://rmod.lille.inria.fr/web/pier/software/Fuel> . In next days we will update it. We have much more to show especially in benchmarks section. We have many ideas and new issues<http://code.google.com/p/fuel/issues/list>to keep working on Fuel. You can download this version in Pharo with: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.5') load. Again, I have to thank ESUG for sponsoring me for Fuel development through the SummerTalk program. Changes: - 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).

1 1

[Pharo-project] [ANN] Fuel version 1.5 released
by Martin Dias July 6, 2011

July 6, 2011

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

4 4

[Pharo-project] Latest and greatest OSProcessPlugin for CogVM
by Danie Roux July 6, 2011

July 6, 2011

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

3 2

[Pharo-project] Sockets don't close, 100% CPU
by Janko MivÅ¡ek July 6, 2011

July 6, 2011

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

4 15

[Pharo-project] Preparing the pharo sprint friday 8th of July
by StÃ©phane Ducasse July 6, 2011

July 6, 2011

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

2 4

Re: [Pharo-project] About locating home
by Marcus Denker July 6, 2011

July 6, 2011

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(a)inria.fr> 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(a)gmail.com> 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. So: Do not hold your breath. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 3

Re: [Pharo-project] Preparing the pharo sprint friday 8th of July
by Marcus Denker July 6, 2011

July 6, 2011

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.

1 0

Re: [Pharo-project] Preparing the pharo sprint friday 8th of July
by Marcus Denker July 6, 2011

July 6, 2011

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.

3 2