- Pharo-dev - lists.pharo.org

[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

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

by Martin Dias

Hi Yanni This is a feature or a known issue, I am not sure yet! 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? *: note the substitution can be not just an object but a graph of objects, some of them able to be substituted too. MartÃn On Fri, Nov 25, 2011 at 6:20 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > The attached test case, reproduced below: > > | result | > self analyzer > when: [:x | FLPair = x class and: [x left isNil not] ] > substituteBy: [:x | x copy left: $A ]. > result := self resultOfSerializeAndMaterializ**e: > (FLPair new left: $a; right: $b; yourself). > self assert: result left = $A. > > causes an infinite loop with IdentityDictionary (see stack trace at end). > > The similar test case #testTransientPairLeft, works because the guard > condition is negated by the replacement (i.e. "x left isNil not" is made > false by the replacement). > > The attached test case does not make "x left isNil not" false. It causes > an infinite recursion, so use "ctrl-." to stop it before too long. > > Is this a bug, or the intention of the #when:substituteBy: feature? I've > worked around it, by making sure to always have the substituted value fail > the guard clause. > > -- > Yanni > > > ==== stack trace ==== > IdentityDictionary>>scanFor: > IdentityDictionary(**HashedCollection)>>**findElementOrNil: > IdentityDictionary(Dictionary)**>>at:ifAbsent: > FLPluggableSubstitutionCluster**(FLSubstitutionCluster)>>add:**traceWith: > FLAnalysis>>mapAndTrace: > FLAnalysis>>run > [:anObject | (FLAnalysis newWith: self firstInMapperChain root: anObject) > run; yourself] in FLAnalyzer>>setDefaultAnalysis > FLAnalyzer>>analysisFor: > FLSerialization>>analysisStep > FLSerialization>>run > [:anObject :aStream | (FLSerialization > root: anObject > on: aStream > analyzer: self analyzer) run; yourself] in FLSerializer>>** > defaultSerialization > [self nextPutSignatureOn: aStream. > self nextPutVersionOn: aStream. > ^ self serializationFactory value: anObject value: aStream] in > FLSerializer>>serialize:on: > BlockClosure>>ensure: > FLSerializer>>serialize:on: > [:aStream | self serializer serialize: anObject on: aStream] in > FLPluggableSubstitutionTest(**FLSerializationTest)>>**serialize: > [:aStream | aValuable value: aStream binary] in FLFileStreamStrategy>>** > writeStreamDo: > [anotherBlock value: file] in MultiByteFileStream class(FileStream > class)>>detectFile:do: > BlockClosure>>ensure: > MultiByteFileStream class(FileStream class)>>detectFile:do: > MultiByteFileStream class(FileStream class)>>forceNewFileNamed:do: >

Nov. 25, 2011

Re: [Pharo-project] class rename and Fuel

by Yanni Chiu

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.

Nov. 25, 2011

Re: [Pharo-project] How turn on Halo's?

by Henrik Sperre Johansen

On 25.11.2011 22:18, Helene Bilbo wrote: > Denis Kudriashov wrote >> Can I turn on halos. And is rotating morphs supported in pharo? >> > I love the rotating Morphs in Squeak! I found the functionality still in > Pharo, but only in RectangleMorph. But it seems to work fine to just copy > the methods from the t-rotating category of RectangleMorph back into Morph. > > So Browsers can be rotated again, while you type text into them :) > > I think itâs a very important feature, even if it is of no professional use. > really. > > Best regards, > Helene. > Yes, it's possible, see Transform/Transformation morphs which are still there. Be aware though, if invalidating the morph often enough (say, resizing without fastDrag), it will generate enough garbage through temporary bitmaps that the garbage collector gets stressed out and the image can "hangs". http://forum.world.st/Canvas-transform-bug-when-rendering-text-td1754208.ht… I imagine this will be much simpler and easier to do in a path-based Canvas like Athens. Cheers, Henry

Nov. 25, 2011

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

by Bernhard Pieber

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. 25, 2011

Re: [Pharo-project] Morphic Cleanup Status

by StÃ©phane Ducasse

On Nov 25, 2011, at 11:08 AM, Fernando Olivero wrote: > Hi Sean, i got overwhelmed last year with the task of porting CUIS > Morphic, to Pharo. There's just to much differences on several common > classes, it's hard to fully understand how to merge both ui > frameworks. > > Even though i believe Juan has a did an excellent work in simplifying > Morphic, and adding simpler code, like for example his new layouts > (download CUIS and try them out). > > But my overall impression , was that we need to stop being backward > compatible in order to create a simple Morphic-like framework for > Pharo, and start from scratch. Fixing current Morphic is also a > humongous task, for example see Stef's nice work on cleaning the > event handling mechanism. BTW you should be able to use the new event hierarchy: it is clean (no first secondâ¦..) and a nice support for double dispatch. I hope that next week I can sit with igor and we finish our journey. How do you deal with event in Gaucho. Stef > > Fernando > > On Fri, Nov 25, 2011 at 9:38 AM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: >> Le 25/11/2011 07:39, Sean P. DeNigris a Ã©crit : >>> What's currently in progress? SimpleMorphic? CUIS related? Other? >>> >>> I was pulling my hair out with Morphic layouts yesterday and started to >>> clean, but I don't want to duplicate efforts on things already being worked >>> on. There are a bunch of open issues and discussions on the list. What's >>> actively being done right now? >> Hi Sean, >> AFAIK, no deep cleaning action. nothing from my side for now. >> I think they have done some refactoring around layout managing in CUIS >> (SimpleMorphic). >> btw, **thanks a lot** for all you are doing. >> Cheers >> Alain >> >>> >>> Thanks. >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/Morphic-Cleanup-Status-tp4106566p4106566.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

Nov. 25, 2011