- Pharo-users - lists.pharo.org

Re: [Pharo-users] Roassal2 Composite Shape

by Peter UhnÃ¡k

Well in the long run I will probably need much more shapes that are currently present so I will probably end up making both TRShape and RTShape anyway. As far as contribution goes, I'd be happy to contribute but I'm still quite new to both Pharo and Smalltalk so I'm quite skeptical about the code quality. I've actually already made both shapes for rounded box but it will need some testing first; so I'll keep you posted. Peter On Mon, Jul 14, 2014 at 10:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Indeed, Roassal does not have a rectangle with rounded corner. Having it > in Roassal means you need a new TRShape and a new RTShape. > > I could easily do the RTShape. But we need the TRShape first. Do you feel > like doing it? This will be a valuable addition to Roassal. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jul 13, 2014, at 9:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Thank you, the example now works. However as I've mentioned in > previous post I'm not sure about the rest of the shapes posted in the > attachment. E.g. I haven't seen any notion of "box with rounded > corners". I could compose it from four RTArc nad four RTLine but it > seems to me overly complex compared to creating new Trachert/Roassal > classes. The same would go for the other shapes. What are your > thoughts/recommendations on that? > > Peter > > On Sun, Jul 13, 2014 at 3:25 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: > > Sorry, the version was not properly saved in SmalltalkHub. If you update > Roassal2 and Trachel, you should be able to execute the code snippet Iâve > sent you. Maybe you want to add âv openâ at the end. If you are using > GTInspector, this is not necessary. > > As far as I understand your description of the problem, you do not need to > create your own shape. > > Let me know how it goes. > > Cheers, > Alexandre > > > On Jul 13, 2014, at 10:38 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Thank you both for suggestions. > > According to Monticello I have latest Roassal2 and yet I don't see > RTMultiCompositeShape, but I would assume it should be what I was looking > for originally. > > In the meantime I chose to do it manually - creating a custom shape in > both Roassal and Trachert: > I've done it in a single path because it seems that having multiple > separate paths just creates more trouble. > ======== > computePath > canvas ifNil: [ ^ self ]. > path := self athensCanvas > createPath: [ :builder | > builder absolute. > self ccwCirclePath: builder radius: 0.5. "building > circular path with specified radius" > self cwCirclePath: builder radius: 0.48. > self ccwCirclePath: builder radius: 0.4 ] > ======== > > But even if I could manage to do this with MultiCompositeShape I'm not > sure about the rest of the shapes (see attachment). > > Peter > > > > > On Sun, Jul 13, 2014 at 1:18 AM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > Hi Peter, > > I am not sure what you try to do. Having two ellipses with the same > center? But different radius? > > Something like that maybe: > -=-=-=-=-=-=-=-=-= > | v | > v := RTView new. > v @ RTDraggableView. > > shape := RTMultiCompositeShape new. > shape add: (RTEllipse new color: (Color yellow alpha: 0.3); size: [:c | c > numberOfMethods sqrt * 10 ]). > shape add: (RTEllipse new color: (Color green alpha: 0.3); size: [:c | c > numberOfLinesOfCode sqrt * 10 ]). > > v addAll: (shape elementsOn: RTShape withAllSubclasses). > RTFlowLayout on: v elements. > > v > -=-=-=-=-=-=-=-=-= > > <Screen Shot 2014-07-13 at 1.18.36 AM.png> > > Alexandre > > > On Jul 11, 2014, at 11:05 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi > > I'm trying to draw an ellipse inside another ellipse but to no avail. I've > tried using RTCompositeShape but that just expands the size of the smaller > shape. Is there something else I'm missing (like fixing dimensions so they > won't get updated) or should I subclass RTAbstractCompositeShape and try to > make something on my own? > > Thanks, > Peter > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > <shapes.png> > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

July 15, 2014

Re: [Pharo-users] Roassal2 Composite Shape

by Alexandre Bergel

Indeed, Roassal does not have a rectangle with rounded corner. Having it in Roassal means you need a new TRShape and a new RTShape. I could easily do the RTShape. But we need the TRShape first. Do you feel like doing it? This will be a valuable addition to Roassal. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Jul 13, 2014, at 9:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Thank you, the example now works. However as I've mentioned in > previous post I'm not sure about the rest of the shapes posted in the > attachment. E.g. I haven't seen any notion of "box with rounded > corners". I could compose it from four RTArc nad four RTLine but it > seems to me overly complex compared to creating new Trachert/Roassal > classes. The same would go for the other shapes. What are your > thoughts/recommendations on that? > > Peter > > On Sun, Jul 13, 2014 at 3:25 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Sorry, the version was not properly saved in SmalltalkHub. If you update Roassal2 and Trachel, you should be able to execute the code snippet Iâve sent you. Maybe you want to add âv openâ at the end. If you are using GTInspector, this is not necessary. >> >> As far as I understand your description of the problem, you do not need to create your own shape. >> >> Let me know how it goes. >> >> Cheers, >> Alexandre >> >> >> On Jul 13, 2014, at 10:38 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Thank you both for suggestions. >>> >>> According to Monticello I have latest Roassal2 and yet I don't see RTMultiCompositeShape, but I would assume it should be what I was looking for originally. >>> >>> In the meantime I chose to do it manually - creating a custom shape in both Roassal and Trachert: >>> I've done it in a single path because it seems that having multiple separate paths just creates more trouble. >>> ======== >>> computePath >>> canvas ifNil: [ ^ self ]. >>> path := self athensCanvas >>> createPath: [ :builder | >>> builder absolute. >>> self ccwCirclePath: builder radius: 0.5. "building circular path with specified radius" >>> self cwCirclePath: builder radius: 0.48. >>> self ccwCirclePath: builder radius: 0.4 ] >>> ======== >>> >>> But even if I could manage to do this with MultiCompositeShape I'm not sure about the rest of the shapes (see attachment). >>> >>> Peter >>> >>> >>> >>> >>> On Sun, Jul 13, 2014 at 1:18 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Hi Peter, >>> >>> I am not sure what you try to do. Having two ellipses with the same center? But different radius? >>> >>> Something like that maybe: >>> -=-=-=-=-=-=-=-=-= >>> | v | >>> v := RTView new. >>> v @ RTDraggableView. >>> >>> shape := RTMultiCompositeShape new. >>> shape add: (RTEllipse new color: (Color yellow alpha: 0.3); size: [:c | c numberOfMethods sqrt * 10 ]). >>> shape add: (RTEllipse new color: (Color green alpha: 0.3); size: [:c | c numberOfLinesOfCode sqrt * 10 ]). >>> >>> v addAll: (shape elementsOn: RTShape withAllSubclasses). >>> RTFlowLayout on: v elements. >>> >>> v >>> -=-=-=-=-=-=-=-=-= >>> >>> <Screen Shot 2014-07-13 at 1.18.36 AM.png> >>> >>> Alexandre >>> >>> >>> On Jul 11, 2014, at 11:05 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi >>>> >>>> I'm trying to draw an ellipse inside another ellipse but to no avail. I've tried using RTCompositeShape but that just expands the size of the smaller shape. Is there something else I'm missing (like fixing dimensions so they won't get updated) or should I subclass RTAbstractCompositeShape and try to make something on my own? >>>> >>>> Thanks, >>>> Peter >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> <shapes.png> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

July 14, 2014

Re: [Pharo-users] Storing block closure code

by Dale Henrichs

Ben, It's not just Global references that you have to worry about ... `self environment` is an easy way to get direct access to `Smalltalk` ... you can use `self superclass superclass subclasses...` to navigate to just about any class in the system ...and this is only with a couple minutes of thought:) .... to be truly safe you have to work a bit harder and construct a sandbox that is a subset of the standard environment ... Dale On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman <btc(a)openinworld.com> wrote: > Esteban A. Maringolo wrote: > > 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. > > > > CompilationContext had instance variable /environment/ that contains a > SystemDictionary(lots of globals). I wonder how effective it would be, or > how horribly it would break things, to change that for a limited list. > cheers -ben > > > 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> <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 Ben Coman

July 14, 2014

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