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

[Pharo-project] is this a bug or just a limitation ?

by Mariano Martinez Peck

I am inside a method and I do ctrl + s where I have a undeclared variable. In that moment, a popup appears and I want to do "declare temp" for example. But, as I did ctrl + s I would like to go to "declare temp" with the beyboard, and then, press enter. But this, doesn't work and the popup is closed. To make this work, I have to click on "declare temp" with the mouse :( I think the most important thing I miss for others IDE is the mouse dependence we have in squeak. Just as an example, when I use Eclipse, I almost don't need the mouse and it is very fast this. Thanks, Mariano

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: > >>> 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 :) > > I think you are missing the point. > An example: > in order to get the MIME type of a file on a Mac you can use a certain > system call to do that. There two choices: you write or extend a plugin > (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox > safe, but quick to do and maintain). > I think you miss the point. :) If VM in control whether allow or disallow FFI calls then you get much more security than leaving it to be handled by OS and hoping that there is no squeakFFI library in same directory where VM located or in one of the search dirs. > If FFI is not default, then people tend to do the extra work to work > with a plugin. > If it is available, people will avoid that extra work and I think that > is absolutely legitimate and has nothing to do with good or bad code. > can't take it as a strong argument. Maybe Croquet doing it in wrong way by using FFI to make GL calls. But it was ultimately their own choice. To encourage people to write a plugins instead of use of FFI, a better way would be to improve VMMaker tool and simplify VM building procedure. But limiting people from use of FFI in hope that they eventually start writing plugins i think is spoiled idea. > 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] Some issues with Pharo-dev build #10243

by Dale Henrichs

----- "Igor Stasenko" <siguctua(a)gmail.com> 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. Igor, I can see the 'extra contexts' that you reported in your other message, but I don't seem to be able to reproduce the above problem. Pressing 'restart' trims the stack and doesn't throw an error when I try it (using OB-Tools-dkh.62)... Could you reproduce the bug and supply an 'error report' for the stack error that you get, so I can get a better idea of what the problem may be. Dale

Feb. 24, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Michael Rueger

Lukas Renggli wrote: >> 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. If everybody is ok with that we could start a forked version and make it work on Pharo. I would volunteer to at least try to fix the problems. Michael

Feb. 24, 2009

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

by Igor Stasenko

2009/2/25 Dale Henrichs <dale.henrichs(a)gemstone.com>: > I'll take a look at your two (or three:) issues. Just for my info, what version of OB-Tools were you using? > OB-Tools-dkh.62 OmniBrowser-dr.441 OB-Standard-dr.339 OB-Enhancements-dr.310 > Dale > > ----- "Igor Stasenko" <siguctua(a)gmail.com> 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] Towards Pharo 1.0

by Michael Rueger

Igor Stasenko wrote: >> 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 :) I think you are missing the point. An example: in order to get the MIME type of a file on a Mac you can use a certain system call to do that. There two choices: you write or extend a plugin (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox safe, but quick to do and maintain). If FFI is not default, then people tend to do the extra work to work with a plugin. If it is available, people will avoid that extra work and I think that is absolutely legitimate and has nothing to do with good or bad code. Michael

Feb. 24, 2009

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