February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trusting Trust

by Igor Stasenko

On 7 February 2012 15:47, Ben Coman <btc(a)openinworld.com> wrote: > > This is slightly paranoid thinking, but considering the long evolution of > Smalltalk live images (apparently all the way from the original Xerox PARC > ST80 [1] ) in relation to Ken Thompson's "Reflections on Trusting Trust" [2] > - are there any mechanisms to prevent trojan code living undetected inside a > Smalltalk Â compiler/decompiler ? Â Bruce Schneier [3] provides a shorter > overview of [2] if that is not to your taste. > yes. Such mechanism is you :) Actually, you can ask same question to Lunix kernel, or any other open project with all source code available. And get same response. Trojans don't like the light, they usually lurking in closed-source environments. You can attempt to add a trojan, but since there is too many eyes, which will be looking what you done, even if you somehow succeed with integrating it into the system, it won't stay there for long for sure. > To what degree might this ever be an issue with Pharo and how might it be > mitigated ? > > cheers, -ben > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-January/011116.… > [2] http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf > [3] http://www.schneier.com/blog/archives/2006/01/countering_trus.html > > > -- Best regards, Igor Stasenko.

Feb. 7, 2012

[Pharo-project] It would be me first

by Igor Stasenko

saying that SqueakSource down. or it is down only for me , such an unlucky guy? :) -- Best regards, Igor Stasenko.

Feb. 7, 2012

[Pharo-project] Trusting Trust

by Ben Coman

This is slightly paranoid thinking, but considering the long evolution of Smalltalk live images (apparently all the way from the original Xerox PARC ST80 [1] ) in relation to Ken Thompson's "Reflections on Trusting Trust" [2] - are there any mechanisms to prevent trojan code living undetected inside a Smalltalk compiler/decompiler ? Bruce Schneier [3] provides a shorter overview of [2] if that is not to your taste. To what degree might this ever be an issue with Pharo and how might it be mitigated ? cheers, -ben [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-January/011116.… [2] http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf [3] http://www.schneier.com/blog/archives/2006/01/countering_trus.html

Feb. 7, 2012

Re: [Pharo-project] Slides Pharo talk Fosdem

by Philippe Marschall

On 02/07/2012 02:15 PM, Marcus Denker wrote: > Hi, > > I have put the slides online: > > -Slides SlideShare > http://www.slideshare.net/MarcusDenker/pharo-next-steps > -Slides PDF > http://rmod.lille.inria.fr/archives/talks/2012-Fosdem-Denker-Pharo.pdf Thanks for the PDF slides! Cheers Philippe

Feb. 7, 2012

[Pharo-project] Slides Pharo talk Fosdem

by Marcus Denker

Hi, I have put the slides online: -Slides SlideShare http://www.slideshare.net/MarcusDenker/pharo-next-steps -Slides PDF http://rmod.lille.inria.fr/archives/talks/2012-Fosdem-Denker-Pharo.pdf The slides are more or less the same as at Smalltalks. Adriaan van Os has some photos here: http://a3aan.st/fosdem2012/index.php/list/0/01+DevRoom -- Marcus Denker -- http://marcusdenker.de

Feb. 7, 2012

[Pharo-project] [update 1.4] #14318

by Marcus Denker

14318 ----- Issue 5260: Add a method on Browser class http://code.google.com/p/pharo/issues/detail?id=5260 Issue 5259: Minor Fix in PLuggableListMorph http://code.google.com/p/pharo/issues/detail?id=5259 -- Marcus Denker -- http://marcusdenker.de

Feb. 7, 2012

Re: [Pharo-project] NBOpenGL error every third execution of example

by Igor Stasenko

Actually, being able to create and control multiple GL windows was unexpected side effect of my design. My primary goal was to make it work for at least one context. For making things work with multiple contexts, more work to be done by adding things/checks like glMakeCurrent() all over the places, where context switching is likely. On 7 February 2012 05:10, Lawson English <lenglish5(a)cox.net> wrote: > That takes care of it, even for the case when several windows are open at > once: > > > GLTTRenderingDemo new openInWorld. > Smalltalk garbageCollect. Smalltalk garbageCollect. > > GLTTRenderingDemo new openInWorld. > Smalltalk garbageCollect. Smalltalk garbageCollect. > > GLTTRenderingDemo new openInWorld. > Smalltalk garbageCollect. Smalltalk garbageCollect. > > GLTTRenderingDemo new openInWorld. > Smalltalk garbageCollect. Smalltalk garbageCollect. > > L > > > On 2/6/12 6:35 PM, Igor Stasenko wrote: >> >> could be related to freeing resources/switching to right context. >> >> try doing >> Smalltalk garbageCollect >> 2 times, after closing the window, before opening it again. >> >> On 6 February 2012 22:50, Lawson English<lenglish5(a)cox.net> Â wrote: >>> >>> When I do the following with the latest version of NBOpenGL, I get an >>> error: >>> FrameBuffer status: unk error on the third (4th?) evaluation of >>> >>> GLTTRenderingDemo new openInWorld. >>> >>> This happens whether or not another OpenGL example is open. >>> >>> The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an >>> error. >>> >>> >>> I have seen this error before but didn't realize how easy it was to >>> replicate. >>> >>> >>> >>> Lawson >>> >>> >>> >> >> > > -- Best regards, Igor Stasenko.

Feb. 7, 2012

Re: [Pharo-project] NBOpenGL error every third execution of example

by Lawson English

That takes care of it, even for the case when several windows are open at once: GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. L On 2/6/12 6:35 PM, Igor Stasenko wrote: > could be related to freeing resources/switching to right context. > > try doing > Smalltalk garbageCollect > 2 times, after closing the window, before opening it again. > > On 6 February 2012 22:50, Lawson English<lenglish5(a)cox.net> wrote: >> When I do the following with the latest version of NBOpenGL, I get an error: >> FrameBuffer status: unk error on the third (4th?) evaluation of >> >> GLTTRenderingDemo new openInWorld. >> >> This happens whether or not another OpenGL example is open. >> >> The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an >> error. >> >> >> I have seen this error before but didn't realize how easy it was to >> replicate. >> >> >> >> Lawson >> >> >> > >

Feb. 7, 2012

Re: [Pharo-project] NBOpenGL error every third execution of example

by Igor Stasenko

could be related to freeing resources/switching to right context. try doing Smalltalk garbageCollect 2 times, after closing the window, before opening it again. On 6 February 2012 22:50, Lawson English <lenglish5(a)cox.net> wrote: > When I do the following with the latest version of NBOpenGL, I get an error: > FrameBuffer status: unk error on the third (4th?) evaluation of > > GLTTRenderingDemo new openInWorld. > > This happens whether or not another OpenGL example is open. > > The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an > error. > > > I have seen this error before but didn't realize how easy it was to > replicate. > > > > Lawson > > > -- Best regards, Igor Stasenko.

Feb. 7, 2012

Re: [Pharo-project] better Behavior>>methodDict

by Nicolas Cellier

How many senders of #methodDict would miss-behave? No risk to throw away a freshly basicAddedSelector:withMethod: ? Or should the IDE be aware of the cannotInterpret: experiments ? Maybe the comment should be (seriously): "When methodDict instance variable of a class is nil, the VM will redirect any message send to an instance by sending the message cannotInterpret: to the receiver but starting the look up in the superclass. NDLR: Or is it to the next superclass having a non nil methodDict? Since most senders of #methodDict message are unaware of this feature, we try to fool them by providing a new empty MethodDictionary in this case, which shall hopefully make them apparently work. Whether undesirable side effect might occur or not, silently or not, is unspecified. Cross your fingers..." Nicolas 2012/2/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Feb 6, 2012 at 10:17 PM, StÃ©phane Ducasse > <Stephane.Ducasse(a)inria.fr> wrote: >> >> Hi mariano >> >> I have the impression that methodDict should be redefined as you propose >> it because else it does not work well with the cannotInterpret hook. I >> suggest to redefine methodDict as follow. notice the cool comment!!! >> If this is ok -> open a bug entry. >> >> >> Behavior >> methodDict >> Â Â Â Â "The method dictionary of a class can be nil when we want to use >> the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM >> sends the message cannotInterpret: to the receiver but starting the look up >> in the superclass. Now the system relies that when the message methodDict is >> sent to a class a method dictionary is returned. The implementation below >> makes sure that a method dictionary can be nilled but does not confuse the >> system." >> >> Â Â Â Â methodDict == nil ifTrue: [^ MethodDictionary new ]. >> Â Â Â Â ^ methodDict >> > > For me that's perfect and avoids an override in my code :) > > Maybe we can do: > > > Behavior >> methodDict > Â Â Â Â "The method dictionary of a class can be nil when we want to use the > cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends > the message cannotInterpret: to the receiver but starting the look up in the > superclass. Now the system relies that when the message methodDict is sent > to a class a method dictionary is returned. The implementation below makes > sure that a method dictionary can be nilled but does not confuse the > system." > > Â Â Â Â methodDict == nil ifTrue: [^ self manageMDFault ]. > Â Â Â Â ^ methodDict > > > Behavior >> manageMDFault > > ^ MethodDictionary new > > > That way subclasses can change it without needing an override. > > but both solutions are fine with me. Other opinions? > > > -- > Mariano > http://marianopeck.wordpress.com >

Feb. 7, 2012