- Pharo-dev - lists.pharo.org

Re: [Pharo-project] MIMEdatabase fix?

by Lukas Renggli

> Then I think that we should first make sure that seaside can run and > after we should > really put pression on the KOM maintainer or declare that it is > incompatible with pharo > and hope that Philippe reported to Giovanni that Kom does not work in Pharo. He replied that he has no time to work on it at the moment. I hope that somebody will jump in, because Kom is a central part of Seaside and widely adapted for many productive applications. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 24, 2009

Re: [Pharo-project] Towards Pharo 1.0

by Igor Stasenko

2009/2/25 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> Concerning FFI sandboxing.. >> why not just add -noffi option at startup time (and similar flag to Interpreter) >> then simply fail all prims which trying to use FFI callouts. >> Then regardless of what you doing (loaded ffi code or not) you can't >> escape sandbox. > > The core issue about having FFI or Alien available in the standard > system is that then people start coding against it. One you go down that > road, it is hard to reverse that and make a system "sandboxable". > sound like: a) isolationists tactics b) teaching others how to write good code i really don't like when people deciding upfront what is good or bad and don't providing any choice how to change this. This is against the spirit of smalltalk. Use java then, with its sealed classes :) > Michael > > _______________________________________________ > 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.

Feb. 24, 2009

Re: [Pharo-project] Towards Pharo 1.0

by Michael Rueger

Igor Stasenko wrote: > Concerning FFI sandboxing.. > why not just add -noffi option at startup time (and similar flag to Interpreter) > then simply fail all prims which trying to use FFI callouts. > Then regardless of what you doing (loaded ffi code or not) you can't > escape sandbox. The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable". Michael

Feb. 24, 2009

Re: [Pharo-project] Towards Pharo 1.0

by Igor Stasenko

Concerning FFI sandboxing.. why not just add -noffi option at startup time (and similar flag to Interpreter) then simply fail all prims which trying to use FFI callouts. Then regardless of what you doing (loaded ffi code or not) you can't escape sandbox. 2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote: > >> Schwab,Wilhelm K wrote: >>> FFI has (it seems to me) long been viewed as an evil in the Squeak >>> community. Â I have no idea whether that is justified, but I have to >>> say that the analogous features in Dolphin have been essential. >> >> The motiviation behind not including FFI in the "standard" image was >> security. FFI allows you to circumvent the Squeak sandbox. > > by sandboxing you mean protected from squeak. > You cannot access the file system if you do not have FFI > Because one day we will have also to think about sandboxing pharo from > its own > downloaded code. > >> Which is only >> really interesting for Squeak applications that download untrusted >> code >> from somewhere (e.g. etoys projects). >> >>> >>> Unless there is a very good reason to exclude it, I would ask for FFI >>> in 1.0. Â For myself, the next big hurdle is underscores, largely >>> because so many of the external entities to which I would be mapping >>> contain them. >> >> I would support that, if it wasn't for Alien, which should be >> replacing >> FFI any time now :-) >> >> Michael >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2009

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by Dale Henrichs

Feb. 24, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by Igor Stasenko

2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> >> >> Can i put my 5 cents in it? >> >> - collect all such overrides into a separate package, named Morphic :) > > lol > > probably part of the solution is there :) and its a good chance to take an overview of them, check duplicates/unnecessary code & overall design. Mostly the same things Pharo is currently concerned with :) > Stef -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2009

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by Igor Stasenko

2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > This is the OB based debugger? > Yeah, OTDebugger btw, how i can switch to old one? > Stef > On Feb 24, 2009, at 10:00 PM, Igor Stasenko wrote: > >> one more thing: >> pressing 'restart' does not restarts evaluation from choosen context, >> and also throws me an error, when i previously created a new method by >> 'create method' button. >> >> (*sarcasm*) I think this build should be renamed to pharo-dev-dev , to >> indicate that this image is suitable for developing a development >> tools, like Debugger >> (*sarcasm end*) >> >> Nevertheless, you doing a great job guys! :) >> >> >> -- >> 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 >> > > > _______________________________________________ > 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.

Feb. 24, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by StÃ©phane Ducasse

> >> > > Can i put my 5 cents in it? > > - collect all such overrides into a separate package, named Morphic :) lol probably part of the solution is there :) Stef > > > >> Stef >> >> >> _______________________________________________ >> 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 >

Feb. 24, 2009

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by StÃ©phane Ducasse

This is the OB based debugger? Stef On Feb 24, 2009, at 10:00 PM, Igor Stasenko wrote: > one more thing: > pressing 'restart' does not restarts evaluation from choosen context, > and also throws me an error, when i previously created a new method by > 'create method' button. > > (*sarcasm*) I think this build should be renamed to pharo-dev-dev , to > indicate that this image is suitable for developing a development > tools, like Debugger > (*sarcasm end*) > > Nevertheless, you doing a great job guys! :) > > > -- > 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 >

Feb. 24, 2009

Re: [Pharo-project] Towards Pharo 1.0

by StÃ©phane Ducasse

On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote: > Schwab,Wilhelm K wrote: >> FFI has (it seems to me) long been viewed as an evil in the Squeak >> community. I have no idea whether that is justified, but I have to >> say that the analogous features in Dolphin have been essential. > > The motiviation behind not including FFI in the "standard" image was > security. FFI allows you to circumvent the Squeak sandbox. by sandboxing you mean protected from squeak. You cannot access the file system if you do not have FFI Because one day we will have also to think about sandboxing pharo from its own downloaded code. > Which is only > really interesting for Squeak applications that download untrusted > code > from somewhere (e.g. etoys projects). > >> >> Unless there is a very good reason to exclude it, I would ask for FFI >> in 1.0. For myself, the next big hurdle is underscores, largely >> because so many of the external entities to which I would be mapping >> contain them. > > I would support that, if it wasn't for Alien, which should be > replacing > FFI any time now :-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2009