July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Storing block closure code

by Esteban A. Maringolo

2014-07-14 13:11 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > If *you* are the wiseguy, then Smalltalk is a pretty powerful internal DSL:) +1 -- Esteban

July 14, 2014

Re: [Pharo-users] Storing block closure code

by Dale Henrichs

If *you* are the wiseguy, then Smalltalk is a pretty powerful internal DSL:) Dale On Mon, Jul 14, 2014 at 9:09 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I > would worry about some wiseguy writing malicious code in the block ... > > Dale > > > On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I was looking for a solution where I can have a textual grammar for a DSL >> in order to specify filters on objects. I didn't really search the net >> because I know a cute little DSL for that already. It is called smalltalk, >> you might have heard of it. >> >> So what I do is putting the filter spec into the image via an http >> interface, materialize the filter in image and store it in a database to >> have them survive image restart. A filter spec could look like this >> >> [ :value | ( self sectionLabelOf: value ) = 'device' ] >> >> I want to know if there is any trouble to expect if I'm using plain block >> syntax for that task. As the blocks are injected using an http interface >> there is no environment/context problem. I would have some helper class as >> a facade to ease the filtering let's call it >> >> FilterHelper (would have a class side method #sectionLabelOf:) >> >> So getting the block code via HTTP I could do >> >> block := Smalltalk compiler >> evaluate: request contents >> for: FilterHelper >> logged: false >> >> And I would serialize it into a database as a string again doing >> >> self store: block sourceNode formattedCode >> >> Are there any possible drawbacks using it this way? >> >> thanks, >> >> Norbert >> >> >> >

July 14, 2014

Re: [Pharo-users] Storing block closure code

by Dale Henrichs

If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I would worry about some wiseguy writing malicious code in the block ... Dale On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I was looking for a solution where I can have a textual grammar for a DSL > in order to specify filters on objects. I didn't really search the net > because I know a cute little DSL for that already. It is called smalltalk, > you might have heard of it. > > So what I do is putting the filter spec into the image via an http > interface, materialize the filter in image and store it in a database to > have them survive image restart. A filter spec could look like this > > [ :value | ( self sectionLabelOf: value ) = 'device' ] > > I want to know if there is any trouble to expect if I'm using plain block > syntax for that task. As the blocks are injected using an http interface > there is no environment/context problem. I would have some helper class as > a facade to ease the filtering let's call it > > FilterHelper (would have a class side method #sectionLabelOf:) > > So getting the block code via HTTP I could do > > block := Smalltalk compiler > evaluate: request contents > for: FilterHelper > logged: false > > And I would serialize it into a database as a string again doing > > self store: block sourceNode formattedCode > > Are there any possible drawbacks using it this way? > > thanks, > > Norbert > > >

July 14, 2014

Re: [Pharo-users] Storing block closure code

by Norbert Hartl

Am 14.07.2014 um 17:44 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > Are you going to be the end user of this? > Yes, it is pure internal functionality. > I wouldn't let users compile whatever Smalltalk expressions they want. > You can't scope the globals that can be accessed by the compiler. > Of course not. Sorry, I wasn't specific enough. > What I would do is model a hierarchy of "Condition" objects used by > "Filter" objects, which are composable, and know how to translate > themselves to SQL, Mongo condition, or even Smalltalk expressions to > apply the conditions to a collection of objects. > > The other way is to have a DSL, but that's a longer road if what you > plan is simply to apply filters. > I want a simple solution with powerful capabilities and therefor smalltalk is the perfect match IMHO. Norbert > We've done both in my previous job and worked perfectly. > > > Regards! > > > > Esteban A. Maringolo > > > 2014-07-14 12:19 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> I was looking for a solution where I can have a textual grammar for a DSL in order to specify filters on objects. I didn't really search the net because I know a cute little DSL for that already. It is called smalltalk, you might have heard of it. >> >> So what I do is putting the filter spec into the image via an http interface, materialize the filter in image and store it in a database to have them survive image restart. A filter spec could look like this >> >> [ :value | ( self sectionLabelOf: value ) = 'device' ] >> >> I want to know if there is any trouble to expect if I'm using plain block syntax for that task. As the blocks are injected using an http interface there is no environment/context problem. I would have some helper class as a facade to ease the filtering let's call it >> >> FilterHelper (would have a class side method #sectionLabelOf:) >> >> So getting the block code via HTTP I could do >> >> block := Smalltalk compiler >> evaluate: request contents >> for: FilterHelper >> logged: false >> >> And I would serialize it into a database as a string again doing >> >> self store: block sourceNode formattedCode >> >> Are there any possible drawbacks using it this way? >> >> thanks, >> >> Norbert >> >> >

July 14, 2014

Re: [Pharo-users] Storing block closure code

by Esteban A. Maringolo

Are you going to be the end user of this? I wouldn't let users compile whatever Smalltalk expressions they want. You can't scope the globals that can be accessed by the compiler. What I would do is model a hierarchy of "Condition" objects used by "Filter" objects, which are composable, and know how to translate themselves to SQL, Mongo condition, or even Smalltalk expressions to apply the conditions to a collection of objects. The other way is to have a DSL, but that's a longer road if what you plan is simply to apply filters. We've done both in my previous job and worked perfectly. Regards! Esteban A. Maringolo 2014-07-14 12:19 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > I was looking for a solution where I can have a textual grammar for a DSL in order to specify filters on objects. I didn't really search the net because I know a cute little DSL for that already. It is called smalltalk, you might have heard of it. > > So what I do is putting the filter spec into the image via an http interface, materialize the filter in image and store it in a database to have them survive image restart. A filter spec could look like this > > [ :value | ( self sectionLabelOf: value ) = 'device' ] > > I want to know if there is any trouble to expect if I'm using plain block syntax for that task. As the blocks are injected using an http interface there is no environment/context problem. I would have some helper class as a facade to ease the filtering let's call it > > FilterHelper (would have a class side method #sectionLabelOf:) > > So getting the block code via HTTP I could do > > block := Smalltalk compiler > evaluate: request contents > for: FilterHelper > logged: false > > And I would serialize it into a database as a string again doing > > self store: block sourceNode formattedCode > > Are there any possible drawbacks using it this way? > > thanks, > > Norbert > >

July 14, 2014

Storing block closure code

by Norbert Hartl

I was looking for a solution where I can have a textual grammar for a DSL in order to specify filters on objects. I didn't really search the net because I know a cute little DSL for that already. It is called smalltalk, you might have heard of it. So what I do is putting the filter spec into the image via an http interface, materialize the filter in image and store it in a database to have them survive image restart. A filter spec could look like this [ :value | ( self sectionLabelOf: value ) = 'device' ] I want to know if there is any trouble to expect if I'm using plain block syntax for that task. As the blocks are injected using an http interface there is no environment/context problem. I would have some helper class as a facade to ease the filtering let's call it FilterHelper (would have a class side method #sectionLabelOf:) So getting the block code via HTTP I could do block := Smalltalk compiler evaluate: request contents for: FilterHelper logged: false And I would serialize it into a database as a string again doing self store: block sourceNode formattedCode Are there any possible drawbacks using it this way? thanks, Norbert

July 14, 2014

Re: [Pharo-users] Package Dependencies Analyzer

by stepharo

thanks baptiste I will try it on polymorph :) Stef On 12/7/14 12:34, Baptiste QuidÃ© wrote: > > Hi Stef, > > I think it's not normal. I will fix it when I will be at home or work. > Try the gofer script and everything should be ok > > Le 12 juil. 2014 12:26, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > Hi baptiste > > I loaded your tools via the metacello browser in Pharo40 but I do > not get a menu to invoke it. > Is it normal? > > Stef > > On 11/7/14 18:42, Baptiste QuidÃ© wrote: > > Hello Pharo users, > > let me introduce a new tool that I developed in the RMOD team: > package dependencies analyzer. > > This project provides a tool able to analyze Smalltalk project > packages and detect dependencies to other packages. It enables > automatic dependency analysis to detect wrong project > description (declared dependencies). It's very easy to use and > i hope it will be helpful during your development time. > > As soon as possible, a next version will enable to detect > cycle dependencies among packages. > > The description of the project is on this web-page : > http://www.baptistequide.fr/packagedependencies.php > It's already available on the Configuration Browser on Pharo. > > Your feedback and suggestions are mostly welcome to improve > this project. I invite you to test the tool. > > Cheers, > > Baptiste > > > >

July 14, 2014

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Ben Coman

July 14, 2014

Pharo 40 June meeting

by stepharo

Hi guys We run the first checkpoint meeting around meeting with the team at rmod and we analysed why we did not get public sprints and regular hangouts. We were tired I guessed. Now we will have a public calendar with the next 6 months of planified events. The calendar will be (may be it is already) added to the web site. Since the team is reorganizing itself and its priority here is a report of our analysis for the first iteration. If you have resources and you want to get an impact please join and let us know. Pharo 40 features list ====================== - Modularisation is under way - Tools - Morphic - Polymorph package structure is slowly getting cleaner - Infrastructure - Android (Missing management events and graphics) - Raspberry (FFI works, vm works, OS process) - Spur should be finished this week - found a bug in Spur related to weak structure (already fixed by Eliot) - release each image we produce to Spur format - nativeBoost is not working - large integer plugin is not working - Host window integration - OSWindow common interface - Multiple back-ends (VM, SDL2, plugin) - Ready to be integrated. - Need some class comments! - New bytecode set - integrated this morning - needs a new vm for the bytecodeset - Spur 64 bits - starting to work on it in September - Removing old compiler - reloadable - needed for VM - Spur - System Localization - usman should open a bug issue - Leading Char Removal - probably we will not do it. - Guille Core - bootstrap - next fridayâ¦ - Unloading Reloading tools - JB will help - Athens - roadmap - missing txText - TxText - Widget is there and working - Morph is working - Spec integration - Not all tool use Spec - Clean version - Igor MUST release a version and not try to make the complete system working with it. - Remove the old browser - kill the filePackage browser - We should get Nautilus or OndoBrowser browsing Ring - Spec - Should do a pass - Check the design (in particular link between adapter and morph) - Examples-driven are needed - GitSupport - filetree integration is working but not good enough - small progress. - Martin should check with Max the status of libgit2 - Need to build on top of that. - Morph and theme - we will see if we have the time - brainstorming on a solution - Make sure that we do not overuse Ring - Font with FreeType - Glamour - esteban roadmap - first bootstrap - second only a stripped down version - development outside the image - Ombu/Epicea - call for more users - ZnUrl should be used in place of URI URL - Keychain Removal - Morph class side announcer - we should look at the announcer plague - Intersect: - should be finished - Image-level resources - brainstorming prototyping - Opal there is progress! - slots <-> OPAL - subclassing and adding instance compiled - specific slots are on the way - ClassBuilder - should be revisited. Previous wish list ================== - Web site animation - catalog (meta data and ressources) - videos - Infrastructure ppa linux linux [glibc] win32 OSX iOS android (Missing management events and graphics) raspberry (works) solaris CentOS + OSX - Investigate obs openbuild service - extracting VM as dylib + GUI + console

July 14, 2014

Consortium report

by stepharo

Hi pharoers Here is the report of the consortium meeting held in late June. Sorry for the time it took to send it around. It is the same as the one we sent in the consortium mailing-list and is public. There is a draft of a roadmap for Pharo 40. Stef

July 14, 2014