January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 11:34 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Jan 9, 2010, at 22:32 , Mariano Martinez Peck wrote: > > > Thanks Benoit for the report and taking the time to run all the > > tests. I > > already knew that there are a lot failing tests. Unfortunately, > > there is not > > too much I can do: > > > > 1) Maintainers of packages with failures can tell me if they are > > failing for > > "my fault". I mean, because I don't load a dependency or something > > like > > that. And if this is the case, I can fix that. > > > > 2) I can remove all the packages that have failing tests -> I think > > we will > > load very few packages. > > > > 3) We should ask maintainers to fix them. Of course, there are > > packages that > > even don't have maintainers. > > > > thoughts about this ? > > Some time ago I individually talked with each maintainer and > eventually we managed to get all tests pass. That was with the > previous build of the Pharo image that Damien did. Now, I don't know > which additional tests you have loaded (?) but either these need to be > fixed or we should not load them. We want all tests to be green for > the release. > > Adrian: Most of the failing tests are from OB. Someone said Lukas made all those tests green, but they are commited in his repo. Someone should merge that with the wiresong repo. If no one merge that, I don't know what to do: or remove them or keep them. The only 3 tests no related with OB that are failing are: ObjectFinalizerTests >> testFinalizationOfEquals This one is failure, but running it again, it is green. Any idea? ReleaseTest >> testUndeclared failes. WeakSetInspectorTest >> testSymbolTableM6812 Related to NewInspector. I cc Frederic. Cheers Mariano > Cheers, > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] TestRunner author while running tests

by StÃ©phane Ducasse

Yes apparently adrian K mentioned that he fixes the problem I should have a look at his code. Now I could not find the mcz file. Stef On Jan 10, 2010, at 11:51 AM, Adrian Lienhard wrote: > The reason for this change (which I did with Oscar at Lille) was to > avoid the author dialog when running tests. It is very annoying > because when you run all the tests, get a coffee, and later come back, > the test runner would wait for your input halfway through. > > Now the first solution below had the annoying problem that > 'TestRunner' ends up as your initials when you compiled a method and > the testrunner has not returned, e.g., because you have a halt in the > code. To improve this, I slightly changed the behavior as follows: > (comment from issue #1379): > > A preliminary fix is in #10494. Now the name 'TestRunner' is only used > if no author was set before starting the tests. The implementation of > temporarily setting another author name is too simple to cope with the > suspending of a process and opening > a debugger from a failed assertion. In this case, one would ideally > want to use the real author. The desired behavior could be implemented > using a dynamic variable to request the author. The test runner could > then catch the notification and return the temporary author. This > would then not interfere with compiling methods in the debugger > because it runs in a different call stack. > > As Lukas suggests, instead fixing the offending tests is also a > possible solution. If possible, though, I would prefer a generic > solution. > > Adrian > > On Jan 10, 2010, at 09:40 , Lukas Renggli wrote: > >> Looks like the code of Adrian Lienhard ;-) >> >> I guess that it tries to fix tests so that they do not pup-up a dialog >> when they compile code. >> >> Initially the code in SUnit was like this: >> >> TestCase>>runCase >> [self setUp. >> self performTest] >> ensure: [ >> self tearDown. >> self cleanUpInstanceVariables ] ] >> >> Then it was change to this (this is where I discovered the issue): >> >> TestCase>>runCase >> Author >> useAuthor: 'TestRunner' >> during: [ >> [self setUp. >> self performTest] >> ensure: [ >> self tearDown. >> self cleanUpInstanceVariables ] ] >> >> In the latest version it was changed again: >> >> TestCase>>runCase >> Author >> ifUnknownAuthorUse: 'TestRunner' >> during: [ >> [self setUp. >> self performTest] >> ensure: [ >> self tearDown. >> self cleanUpInstanceVariables ] ] >> >> In any case the author name is 'TestRunner' if you edit source code >> anywhere in the system when a debugger on a test is open. Also I am >> not sure what happens if you have multiple debuggers on tests open, >> that might give very strange situations. >> >> I suggest that we revert to the earliest presented version of the >> method in question, and fix the particular tests that compile code. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] Running untrusted code & sandboxing

by StÃ©phane Ducasse

indeed We do not say that we have the solution but this a good problem to work on. >>>> This seems related: >> >> http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf >> > > Highly related! > But the devil in details. :) > >> >>>> >>> Yes :-) And a PhD Student working on it. And a ANR (french NSF) proposal >> ^two, attacking from two sides. >> >> >> Marcus >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

[Pharo-project] [update 1.1] #11150

by Marcus Denker

11150 ----- Issue 1593 : Packages: strange MC packages in need of cleanup

Jan. 10, 2010

Re: [Pharo-project] Running untrusted code & sandboxing

by Igor Stasenko

2010/1/10 Marcus Denker <marcus.denker(a)inria.fr>: > > On Jan 10, 2010, at 11:48 AM, Marcus Denker wrote: > >> >> On Jan 10, 2010, at 11:42 AM, Igor Stasenko wrote: >> >>> Hello all, >>> I am thinking, what could be done to make Squeak 100% safe when >>> running untrusted code. >> ... >> >>> >>> Any other ideas in this regard? > > This seems related: > > Â Â Â Â http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf > Highly related! But the devil in details. :) > >>> >> Yes :-) And a PhD Student working on it. And a ANR (french NSF) proposal > Â Â Â Â Â Â Â Â Â Â Â ^two, attacking from two sides. > > > Â Â Â Â Marcus > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 10, 2010

Re: [Pharo-project] TestRunner author while running tests

by Adrian Lienhard

The reason for this change (which I did with Oscar at Lille) was to avoid the author dialog when running tests. It is very annoying because when you run all the tests, get a coffee, and later come back, the test runner would wait for your input halfway through. Now the first solution below had the annoying problem that 'TestRunner' ends up as your initials when you compiled a method and the testrunner has not returned, e.g., because you have a halt in the code. To improve this, I slightly changed the behavior as follows: (comment from issue #1379): A preliminary fix is in #10494. Now the name 'TestRunner' is only used if no author was set before starting the tests. The implementation of temporarily setting another author name is too simple to cope with the suspending of a process and opening a debugger from a failed assertion. In this case, one would ideally want to use the real author. The desired behavior could be implemented using a dynamic variable to request the author. The test runner could then catch the notification and return the temporary author. This would then not interfere with compiling methods in the debugger because it runs in a different call stack. As Lukas suggests, instead fixing the offending tests is also a possible solution. If possible, though, I would prefer a generic solution. Adrian On Jan 10, 2010, at 09:40 , Lukas Renggli wrote: > Looks like the code of Adrian Lienhard ;-) > > I guess that it tries to fix tests so that they do not pup-up a dialog > when they compile code. > > Initially the code in SUnit was like this: > > TestCase>>runCase > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > Then it was change to this (this is where I discovered the issue): > > TestCase>>runCase > Author > useAuthor: 'TestRunner' > during: [ > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > In the latest version it was changed again: > > TestCase>>runCase > Author > ifUnknownAuthorUse: 'TestRunner' > during: [ > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > In any case the author name is 'TestRunner' if you edit source code > anywhere in the system when a debugger on a test is open. Also I am > not sure what happens if you have multiple debuggers on tests open, > that might give very strange situations. > > I suggest that we revert to the earliest presented version of the > method in question, and fix the particular tests that compile code. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] Running untrusted code & sandboxing

by Marcus Denker

On Jan 10, 2010, at 11:48 AM, Marcus Denker wrote: > > On Jan 10, 2010, at 11:42 AM, Igor Stasenko wrote: > >> Hello all, >> I am thinking, what could be done to make Squeak 100% safe when >> running untrusted code. > ... > >> >> Any other ideas in this regard? This seems related: http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf >> > Yes :-) And a PhD Student working on it. And a ANR (french NSF) proposal ^two, attacking from two sides. Marcus

Jan. 10, 2010

Re: [Pharo-project] Running untrusted code & sandboxing

by Marcus Denker

On Jan 10, 2010, at 11:42 AM, Igor Stasenko wrote: > Hello all, > I am thinking, what could be done to make Squeak 100% safe when > running untrusted code. ... > > Any other ideas in this regard? > Yes :-) And a PhD Student working on it. And a ANR (french NSF) proposal in the works for more... :-) Marcus

Jan. 10, 2010

Re: [Pharo-project] Finalization quirk

by Philippe Marschall

On 06.01.2010 21:27, John M McIntosh wrote: > Bill, I always tell people > > (a) finalization will occur later, not when you think it should > (b) finalization will occur slower/faster than you think. > (c) both (a) & (b) will vary (d) finalization will occur in a different process, right? Cheers Philippe

Jan. 10, 2010

[Pharo-project] Running untrusted code & sandboxing

by Igor Stasenko

Hello all, I am thinking, what could be done to make Squeak 100% safe when running untrusted code. >From one side, stands a compiler, but from another is run time environment. What i thinking that untrusted code should use own, sepatate class/object hierarchy and do not use any of existing objects from 'unsafe' part of image. If we could use a separation in image, like: [ core [ unsafe ] ] where 'core' is our regular image, or dev image. It is safe to have a references from objects in regular space to ones in unsafe one. But we should prevent leaking a reference to objects in 'core' area being captured by any objects in 'unsafe' area, where untrusted code runs. Ultimately, before running an untrusted code, we should swap the specialObjectsArray, so all things, which VM primitives could see, will be pointing inside unsafe space, and therefore we making impossible to obtain a pointer to any object from 'core' area even when using primitives. But then, once we switch a specialObjectsArray, and if there is no objects pointing back to core, VM will GC it mercilessly. And of course, once untrusted code finished its job, or interrupt occurs, we should be able to switch whole VM context back to core. So, there should be a pointer back to core area. But once we have it, we have a chance that malicious code could find it and break from the jail. Well, maybe with help of specialized compiler, which knows what primitives are unsafe, we could hide this reference? Any other ideas in this regard? -- Best regards, Igor Stasenko AKA sig.

Jan. 10, 2010