- Pharo-dev - lists.pharo.org

[Pharo-project] Policy for storing metacello configurations
by Max Leske Aug. 24, 2011

Aug. 24, 2011

I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent. Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦). Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us. Cheers, Max

7 13

[Pharo-project] Little fix for #4697
by Michael Roberts Aug. 23, 2011

Aug. 23, 2011

In inbox: Name: Tools-MikeRoberts.658 Issue: 4697 -Fix to OrderedCollectionInspector that fails #fieldList on OrderedCollections that are not fully formed. ---- I did a little fix for this bug, that prevents the debugger stepping into OrderedCollection new. I mention this to folks working on tools because it is an interesting edge case. If you specialise an inspector for a particular class, for example, you have to handle the case where the object is not fully formed. e.g right after basicNew, or in the middle of some initialisation. It failed for the debugger, because it relies on embedding an inspector for the receiver (bottom left) panel. So i guess this edge case is subtle... cheers, Mike

2 1

Re: [Pharo-project] Some bugs
by Marcus Denker Aug. 23, 2011

Aug. 23, 2011

On Aug 23, 2011, at 9:23 AM, Lukas Renggli wrote: > > > Now I think the subliminal message of this thread is that the Pharo > community should focus on making the existing images really stable > before hacking away on Pharo 1.4 and beyond ... :-) > And we need more people actually looking at the bug tracker... I sometimes feel a bit lonely... Marcus -- Marcus Denker -- http://marcusdenker.de

5 4

Re: [Pharo-project] Some bugs
by Marcus Denker Aug. 23, 2011

Aug. 23, 2011

On Aug 23, 2011, at 9:54 AM, Alexandre Bergel wrote: > These issues are for 1.2.2. Who is maintaining it by the way? We maintain the current released image. But when people provide easy to integrate, clear and useful bug fixes for older versions, we integrate them. (this was done for 1.1.2, it has all fixes that where added for 1.2.2) Of course it would be possible (and I would prefer it), if a group of 1.2 users could take that over (e.g. commercial users that are actually using 1.2) The idea would not to actively develope it, but just make sure that all the fixes are added that make sense (bug fixes, mostly). *And* make that driven and coordingated by actual users of that version. This way we make sure that a release gets important fixes as long as it is used. We could have such a group for just every version released: It gets "handed off" to the people using the release. This group than of course, with time, gets smaller, and in the end fades away. The most important effect of this would be to not burn people maintaining old versions they don't use themselves... Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] RBNodes accept vs. visit
by Camillo Bruni Aug. 23, 2011

Aug. 23, 2011

Hi everyone, I just had a quick look at the RBNodes. Is there a particular reason why the visitor pattern methods are prefixed on both sides with 'accept'? eg. RBArrayNode >> acceptVisitor: aProgramNodeVisitor ^ aProgramNodeVisitor acceptArrayNode: self camillo

4 4

[Pharo-project] Research Engineer Position at INRIA
by StÃ©phane Ducasse Aug. 23, 2011

Aug. 23, 2011

Hi guys We have a position for an engineer position around dynamic language (javascript, smalltalk) and security. Engineer position â¢ Duration: 1-2 years â¢ Starting date: end 2011/beginning 2012 â¢ Where: RMOD team at INRIA Lille Nord Europe http://rmod.lille.inria.fr/ â¢ Salary: 55 Keuros net (before taxes) Keywords: dynamic languages, security, information flow, Smalltalk, Javascript The position will take place in the context of the Systematic Resilience project. Three main tasks will be our focus: â¢ Develop a component model named JIO to manage I/O user interface in Javascript for cloud applications â¢ Identification of security problems in Javascript â¢ Study and analyze approaches towards securing Javascript and dynamic languages (Caja, isolate...) â¢ Prototype of a safe architecture for Resilience Please contact Stephane Ducasse (Stephane.Ducasse(a)inria.fr) for more information. ------------------------ Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.ducasse(a)inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.

1 0

[Pharo-project] Hudson build became unstable: Pharo Core 1.3 #400
by marcus.denker＠inria.fr Aug. 23, 2011

Aug. 23, 2011

See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/400/>

2 1

[Pharo-project] [update 1.4] #14110
by Marcus Denker Aug. 23, 2011

Aug. 23, 2011

14110 ----- Issue 4642: FinderUI>>compileSource: aString notifying: aController http://code.google.com/p/pharo/issues/detail?id=4642 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.3] #13300
by Marcus Denker Aug. 23, 2011

Aug. 23, 2011

13300 ----- Issue 4430: When copying a class, do not copy the methods it obtains from Traits http://code.google.com/p/pharo/issues/detail?id=4430 Issue 4642: FinderUI>>compileSource: aString notifying: aController http://code.google.com/p/pharo/issues/detail?id=4642 -- Marcus Denker -- http://marcusdenker.de

1 0

Aug. 23, 2011

We have a 3 year postdoc position on dynamic languages and security: http://rmod.lille.inria.fr/web/pier/blog/2011-08-19-2 Do not hesitate to apply Postdoc Position â¢ Duration: 3 years â¢ Starting date: end 2011 â¢ Where: RMOD team at INRIA Lille Nord Europe http://rmod.lille.inria.fr â¢ Salary: 55 Keuros net (before taxes) Keywords: dynamic languages, security, information flow, Smalltalk, Javascript The position will take place in the context of the Systematic Resilience project. We will focus on the following main tasks: â¢ Identification and understanding of security problems in Javascript and other dynamic languages â¢ Study and analyze existing approaches towards securing Javascript (Caja, isolates...) â¢ Comparison of different approaches to secure dynamic applications (Zope model, ZTK), Ruby â¢ Study of Mirrors/Capabilities as a basis for security in Javascript â¢ Proposition of an safe architecture for Resilience Please contact Stephane Ducasse (Stephane.Ducasse(a)inria.fr) for more information. Stef ------------------------ Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.ducasse(a)inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.

1 0