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

Re: [Pharo-project] What happened to COTDC?

by StÃ©phane Ducasse

laurent got busy but somebody else can just do the same and it would be great. Stef On Nov 26, 2011, at 3:37 PM, Sean P. DeNigris wrote: > We seemed to be doing so well... > > -- > View this message in context: http://forum.world.st/What-happened-to-COTDC-tp4110480p4110480.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 26, 2011

Re: [Pharo-project] RB API

by StÃ©phane Ducasse

Great! We were starting to write a chapter on that but the person changed job. Stef On Nov 26, 2011, at 3:36 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> In case anyone else can benefit, I eventually ended up with: >> RBParseTreeRewriter new >> replace: '``@object deprecated: ``@arg1 ' >> with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') >> in:(''Pharo', versionNumber asString, ''')'. >> > > I added this example to the online book until we have some better ones > http://book.pharo-project.org/book/PharoTools/Refactoring-Browser/Programma… > > -- > View this message in context: http://forum.world.st/RB-API-tp3781019p4110478.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 26, 2011

[Pharo-project] What happened to COTDC?

by Sean P. DeNigris

We seemed to be doing so well... -- View this message in context: http://forum.world.st/What-happened-to-COTDC-tp4110480p4110480.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 26, 2011

Re: [Pharo-project] RB API

by Sean P. DeNigris

Sean P. DeNigris wrote > > In case anyone else can benefit, I eventually ended up with: > RBParseTreeRewriter new > replace: '``@object deprecated: ``@arg1 ' > with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') > in:(''Pharo', versionNumber asString, ''')'. > I added this example to the online book until we have some better ones http://book.pharo-project.org/book/PharoTools/Refactoring-Browser/Programma… -- View this message in context: http://forum.world.st/RB-API-tp3781019p4110478.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 26, 2011

[Pharo-project] INRIA Postdoc position: security in dynamic languages

by stephane ducasse

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. http://rmod.lille.inria.fr/ http://stephane.ducasse.free.fr

Nov. 26, 2011

[Pharo-project] Postdoc position: security in dynamic languages

by StÃ©phane Ducasse

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. http://rmod.lille.inria.fr/ http://stephane.ducasse.free.fr

Nov. 26, 2011

Re: [Pharo-project] Issue Template Pharo 1.3 Enhancement? (was: Font lookup using styleName?)

by StÃ©phane Ducasse

Hi Bernhard the idea is enh only go for the current alpha except if they are more than enh but really urgent freaky fixing a terribly broken aspect of a stable :). so go ahead and add a bug entry Stef On Nov 25, 2011, at 11:01 PM, Bernhard Pieber wrote: > Hi everyone, > > I have implemented a test for the missing method and the method itself. Before I can upload it I need to create an issue for the enhancement. In the tracker I am missing a template for a Pharo 1.3 Enhancement. Would you mind creating one? Or is it a policy that if someone who wants to contribute an enhancement has to use the unstable version, Pharo 1.4 in this case? > > Cheers, > Bernhard > > Am 22.11.2011 um 08:19 schrieb StÃ©phane Ducasse: >> On Nov 21, 2011, at 9:15 PM, Bernhard Pieber wrote: >> >>> Hi everyone, >>> >>> I am using Pharo 1.3 and I am quite a newbie when it comes to Pharo so please be kindâ¦ >> >> we always are :) >> Seriously in fact :) >> >>> I saw in the font chooser that Pharo supports font families with multiple styles. On my Mac for instance the font family Helvetica has the styles Light, Light Oblique, Regular, Oblique, Bold, and Bold Oblique. In the code font families are subinstances of FontFamilyAbstract and styles are subinstances of FontFamilyMemberAbstract. >>> >>> However, for creating fonts programmatically there seems to be no message which takes the style into account. There is LogicalFont class>>#familyName:pointSize:. How do I know which of the styles this uses? >>> >>> Then there is LogicalFont class>>#familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue:. How should I know which parameters I have to pass in to get a certain style? >>> >>> I would have expected a method like #familyName:styleName:pointSize: but I did not find one. Any idea why? Is this an omission or a feature? >> >> probably an omission but I will wait to learn if somebody has the answer >> >>> Cheers, >>> Bernhard >

Nov. 26, 2011

Re: [Pharo-project] class rename and Fuel

by Yanni Chiu

On 25/11/11 5:46 PM, Martin Dias wrote: > > This can be the problem. Can you update these references to point NewClass? Now that I know what's holding on to the class, I can figure out what to do. Ideally, I'd like to remove the reference to the class, and have the command list re-generated. This strategy is available for a Pier kernel, but not for the general migration problem for Fuel. > I want to support in fuel 1.8 some way of specifying that a class has > been renamed. Something like: > > FLMaterializer newDefault > classRenames: { #OldClass -> #NewClass } > materializeFrom: aFile. > > Would this solve your problem? Yes it would, but the real issue for me is whether or not the migration code stays forever in the code base, or should a one time migration step be run (and keep no migration trail in the Fuel code).

Nov. 25, 2011

Re: [Pharo-project] Fuel bug: infinite recursion in "analyzer when:substituteBy:"

by Yanni Chiu

On 25/11/11 5:26 PM, Martin Dias wrote: > Hi Yanni > > This is a feature or a known issue, I am not sure yet! It makes sense why it is the way it is (as you've noted below). Once you know this is what's happening. But, when first encountered, it's a bit scary to see your image not respond. I'm not sure whether it's a bug or feature, either. However, I suspect any infinite recursion should be classified as a bug. > In serialization, when you substitute an object by another, such > substitution(*) is then serialized using the same rules, so you might > need the guard condition to avoid the infinite loop. > > This was the simpler implementation, but maybe it's undesirable or it's > too error prone. Do you think we should change this? Probably, the right answer is to allow a choice of whether or not the substituted object(s) are subject to further substitution. And, no matter which choice is made, no infinite loop should occur -- a tall order. > *: note the substitution can be not just an object but a graph of > objects, some of them able to be substituted too. Good to know this.

Nov. 25, 2011

Re: [Pharo-project] class rename and Fuel

by Martin Dias

Hi Yanni, On Fri, Nov 25, 2011 at 7:22 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/11/11 3:56 PM, Yanni Chiu wrote: > >> >> Any ideas why Fuel is looking for OldClass, yet there are no instances >> of OldClass in the de-serialized object graph. >> > > There are no instances, but the class object itself is being held in > various places in the Pier kernel. > This can be the problem. Can you update these references to point NewClass? I want to support in fuel 1.8 some way of specifying that a class has been renamed. Something like: FLMaterializer newDefault classRenames: { #OldClass -> #NewClass } materializeFrom: aFile. Would this solve your problem? cheers, MartÃn

Nov. 25, 2011