August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Esug-list] Preparing my presentation of NativeBoost

by Sean Allen

On Fri, Aug 5, 2011 at 2:38 PM, Martin McClure <martin.mcclure(a)vmware.com>wrote: > On 08/05/2011 04:00 AM, Igor Stasenko wrote: > >> Hi, >> >> i'd like to know what you would like to know about things you don't >> know about NativeBoost :) >> because i don't know what would you like to know more: >> >> - more in-depth about an implementation details >> - more about examples and how to use it >> >> just thinking, what i should focus on. >> > > I know very little about NativeBoost. I'm very interested in its > implementation, but would like *some* examples of usage. > > Martin said what I was thinking. I'm more of a how was it done first sort.

Aug. 6, 2011

[Pharo-project] Coral status & directions (was: Re: about coral)

by Damien Pollet

On 6 August 2011 14:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > What is the status of Coral? Is it usable? Thanks. The syntax / compiler extension works fine and should not require much changes. All examples work for me, but it still depends too much on what flavor of the VM you have and is only tested on Mac. So, I'd say, it's useable for early adopters :) What's currently problematic is properly starting the VM in headless mode and passing it command-line arguments. This currently works with the Cog Carbon VM, and it should work with the linux VMs as well. I don't know about windows. I'd like to eliminate the generate-and-install-coral.sh step, or generate a script that doesn't hardcode paths to the VM and to the Coral image, or devise some way to install everything that makes it more practicalâ¦ The problem is, different flavors of the VM don't report the same think for the VM/image/current pathâ¦ There is a problem with OSProcess on the Cog Cocoa VM. I also need to check that the proper Filesystem package is installed, because the current ConfigurationOfCoral predates Colin's big refactoring. Now, for directions of improvement: I'm currently writing a (petit)parser for command-line arguments inspired by http://rubydoc.info/gems/cri/2.0.2/frames (yup, Smalltalk learns from Ruby, for once :) This will make it easy to write Coral scripts with options, flags, subcommands that respect well-known conventions for unix shell commands, properly check argument formats, etc. Eventually this will provide enough information to generate man pages, -h --help text, and even completion functions for bash and zsh. We're going to need some way to structure script code. I don't think we want an include/require statement to write scripts in several files, but there should be a way for a script to depend on code that is not in the base Coral image. Maybe loading parcels? The Console class provides basic access to ANSI escape sequences but this could be refactored. This will be needed for the next stepsâ¦ â¦I want a text-mode inspector and debugger integrated in the REPL. I'm jealous of Ruby having https://github.com/pry/pry#readme :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 6, 2011

Re: [Pharo-project] How to deprecate a Class?

by Noury Bouraqadi

I'd rather use trait. Note that in both cases, subclasses will be made deprecated too. Noury On 4 aoÃ»t 2011, at 10:17, Nicolas Cellier wrote: > Why not make this class a factory in the interim ? > > DeprecatedClass class>>new > self deprecated: 'DeprecatedClass use BrandNewClass instead'. > ^BrandNewClass new > > 2011/8/4 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Thu, Aug 4, 2011 at 1:42 AM, Chris Cunningham <cunningham.cb(a)gmail.com> >> wrote: >>> >>> On Mon, Aug 1, 2011 at 12:21 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> The most important aspects is that there is not reference to it. >>>> and that if we replace it by something else, it works. >>>> After we can write in the comments in big that the class is deprecated. >>>> >>> >>> Could you (we) also deprecate all the methods in the class? Ideally >>> in some automated way, of course. >>> >> >> Or remove all methods and implement >> >> doesNotUnderstand: >> >> ^Error new signal: 'All mehtods of this class are deprecated, please use >> ....' >> >> >> hehheheh :) >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > Noury Bouraqadi http://car.mines-douai.fr/noury -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

Aug. 6, 2011

Re: [Pharo-project] Web app security

by Igor Stasenko

On 6 August 2011 12:06, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > with a public SmallHarbour (public fork of SeasideHosting - > smallharbour.org) people can upload images that do bad things: change > filesystem, run commands, .... > Actually, what are the ways of securing a server so people can't do bad > things ? > I'm thinking of: > - run the vm/image within a low right unix account > - remove dangerous plugins (OSProcess, ?) you don't need to remove dangerous plugins. What you can do (with latest VMs) is to use 'disable module loading' mechanism. http://code.google.com/p/cog/issues/detail?id=13 > Can we easily chroot ? > what are known solutions ? > Laurent. -- Best regards, Igor Stasenko AKA sig.

Aug. 6, 2011

Re: [Pharo-project] [Pharo-coral] about coral

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > We want Coral to be loadable in Pharo core but not included by default at > least for now. > What is the status of Coral? Is it usable? Thanks. Sean -- View this message in context: http://forum.world.st/about-coral-tp3723018p3723265.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 6, 2011

Re: [Pharo-project] Web app security

by Dale Henrichs

Laurent, I think that the best defense is the limited access/rights unix account, perhaps even a separate unix user per account (to provide isolation between accounts) ... I think this is what VMware does in in its Cloud Foundry ... to be completely safe you'd have to turn off the ability to read and write files and turn off socket access (this is what javascript in the browser does), but going this far severely limits what you can do in the image ... I would think that you could screw things down pretty tight just using unix permissions .... Dale ----- Original Message ----- | From: "laurent laffont" <laurent.laffont(a)gmail.com> | To: "Seaside - developer list" <seaside-dev(a)lists.squeakfoundation.org>, "An open mailing list to discuss any topics | related to an open-source Smalltalk" <pharo-project(a)lists.gforge.inria.fr> | Sent: Saturday, August 6, 2011 3:06:38 AM | Subject: [Pharo-project] Web app security | | Hi, | | | with a public SmallHarbour (public fork of SeasideHosting - | smallharbour.org ) people can upload images that do bad things: | change filesystem, run commands, .... | | | Actually, what are the ways of securing a server so people can't do | bad things ? | | | I'm thinking of: | - run the vm/image within a low right unix account | - remove dangerous plugins (OSProcess, ?) | | | Can we easily chroot ? | | | what are known solutions ? | | | Laurent.

Aug. 6, 2011

Re: [Pharo-project] Managing logos and backgrounds IN the image

by Lukas Renggli

Have a look at the Smalltalk scripts of the Jenkins builder. There are various examples that do exactly that (Seaside, Pier, Pharo, PetitParser, ...). Some use the #storeString of Form instances, others use ByteArrays, but the simplest is if you just load the image from a webserver. Lukas On Saturday, 6 August 2011, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I want to do two things: > > 1) set a custom logo and background for my images. > 2) I want to do 1) from my ConfigurationOfMariano > 3) I want to have the logo and background picture as a ByteArray/Bitmap or whatever but inside the image (not needing an external file). > > For 1) I know I can do for the background image: > > World backgroundImage: (ImageReadWriter formFromFileNamed: 'whatever.png') layout: #scaled. > > And for the logo: > > LogoImageMorph default: (ImageMorph withForm: (ImageReadWriter formFromFileNamed: 'whatever')) > > > Now....I need the second part, how to read it from file and store it as an image directly in the image. Something similar as icons are stored. > And of course, then how to read them and set it to the background and logo. > > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 6, 2011

[Pharo-project] Managing logos and backgrounds IN the image

by Mariano Martinez Peck

Hi guys. I want to do two things: 1) set a custom logo and background for my images. 2) I want to do 1) from my ConfigurationOfMariano 3) I want to have the logo and background picture as a ByteArray/Bitmap or whatever but inside the image (not needing an external file). For 1) I know I can do for the background image: World backgroundImage: (ImageReadWriter formFromFileNamed: 'whatever.png') layout: #scaled. And for the logo: LogoImageMorph default: (ImageMorph withForm: (ImageReadWriter formFromFileNamed: 'whatever')) Now....I need the second part, how to read it from file and store it as an image directly in the image. Something similar as icons are stored. And of course, then how to read them and set it to the background and logo. Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Aug. 6, 2011

[Pharo-project] Web app security

by laurent laffont

Hi, with a public SmallHarbour (public fork of SeasideHosting - smallharbour.org) people can upload images that do bad things: change filesystem, run commands, .... Actually, what are the ways of securing a server so people can't do bad things ? I'm thinking of: - run the vm/image within a low right unix account - remove dangerous plugins (OSProcess, ?) Can we easily chroot ? what are known solutions ? Laurent.

Aug. 6, 2011

Re: [Pharo-project] [Pharo-coral] about coral

by StÃ©phane Ducasse

Something I forgot to say is that we can have a squeak package in the ConfigurationOfCoral. We want Coral to be loadable in Pharo core but not included by default at least for now. We should first close the doors that we opened. Stef > Hi frank > > Oscar is not in charge since a long time about coral. In fact it had always been my iea, and since oscar like scripting language > he was participating. Now Damien is helping a lot. > If you have changes that you think can go in our version please send them. > I do not know why the REPL is not working anymore and probably that we should use the stdout that were introduced in 1.3 > > This has been years that I want a smalltalk with a scripting layer and if you want to join you are welcome. > > Stef > > > > ---------- Forwarded message ---------- > From: Frank Shearar <frank.shearar(a)gmail.com> > Date: Fri, Aug 5, 2011 at 6:33 PM > Subject: [squeak-dev] "Pharoism" package? > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > Hi, > > I did some work yesterday [1] getting Coral (a scripting framework for > Pharo: http://www.squeaksource.com/Coral.html) working in Trunk. I > made a few adjustments to Coral itself, mailing Oscar Nierstrasz the > changes (what look to be getting Coral to work with the latest > Filesystem code, post-large-refactor), and had to add a few methods to > Squeak that Coral was expecting. Presumably these were methods renamed > by Pharo: > > Character >> join: > String >> join: > Class >> addInstVarNamed: > MetaClass >> addInstVarNamed: > Class >> subclass: > SmalltalkImage >> vmFullPath > Symbol >> isBinary > > My question's a bit broader: there are many more Pharo developers than > Squeak developers, it seems. They're doing lots of cool stuff. We can > easily port these cool things to Squeak (at least, at the moment). If > anyone else is doing this kind've thing, perhaps it's worthwhile > either adding these kinds of methods to Grease, or having a general > "Pharoisms" package. > > It's not all one-way, of course: having things easily loadable into > Squeak means that Squeak hackers (like me) can more easily contribute > to interesting packages (like Coral) without having to keep track of > two communities. (Coral could, with some love, become a full REPL, > which is something I really want.) > > frank > > [1] http://stackoverflow.com/questions/6938114/a-smalltalk-implementation-with-… > > > > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Pharo-coral mailing list > Pharo-coral(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral

Aug. 6, 2011