Smalltalk › Pharo › Pharo Smalltalk Users

Storing block closure code

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

NorbertHartl

Storing block closure code

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

Esteban A. Maringolo

Re: Storing block closure code

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 <[hidden email]>:

> 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
>
>

NorbertHartl

Re: Storing block closure code

Am 14.07.2014 um 17:44 schrieb Esteban A. Maringolo <[hidden email]>:

> 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 <[hidden email]>:
>> 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
>>
>>
>

Dale Henrichs-3

Re: Storing block closure code

In reply to this post by NorbertHartl

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 <[hidden email]> 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

Dale Henrichs-3

Re: Storing block closure code

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 <[hidden email]> 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 <[hidden email]> 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

Esteban A. Maringolo

Re: Storing block closure code

2014-07-14 13:11 GMT-03:00 Dale Henrichs <[hidden email]>:
> If *you* are the wiseguy, then Smalltalk is a pretty powerful internal DSL:)

+1

--
Esteban

Ben Coman

Re: Storing block closure code

In reply to this post by Esteban A. Maringolo

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 [hidden email]:

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

Dale Henrichs-3

Re: Storing block closure code

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 <[hidden email]> 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.

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 [hidden email]:

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

NorbertHartl

Re: Storing block closure code

Ok,

I think that's what you get if you forget a tiny little detail and that is enough so everything is discussed just not what you wanted to know :)

My concern is not security. I know pretty well it would be a stupid to let anyone inject smalltalk code via http interface. If I were about security I would do the same as Esteban: Defining a allowed set of operations and make classes for them.

My point is that it is purely internal what I like to use. And I think I would like it not to be restricted in the kind of queries I do. Hence the idea of using smalltalk. I'm only interested in the drawbacks that blocks might have. As they are created from string to only thing they might depend on context-wise would be self (if I decide to use a helper). My question was if there is anything besides that could make the use of blocks and serializing/materializing troublesome.

thanks,

norbert

Am 14.07.2014 um 21:05 schrieb Dale Henrichs <[hidden email]>:

Ben,

Dale

On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman <[hidden email]> 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.

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 [hidden email]:

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

MaxBareis

Number is not accepted by UI

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save
the method. Am I on a wrong path or should that work and if how can I
avoid the UI error message?

Regards

Max

Esteban A. Maringolo

Re: Number is not accepted by UI

You can only put the minus sign ("-") before a literal number.

Ej -12, - 4.4, -2/3, etc.

But not in front of any other "non number" object (from the parser
point of view):

Ej:

- #() size "only numbers may be negated"

What you want to do can be performed sending the message #negated to
the object returned by #width.

So #negatedWidth would be:

negatedWidth:
^self width negated

Regards!

Esteban A. Maringolo

2014-07-15 19:16 GMT-03:00 Verkoster Info <[hidden email]>:

> Hi,
>
> I am using latest Pharo 3.0 + vm.
>
> I have a method width with
> width
>
> ^ 115 * self ratio.
> in my understanding it returns a Number.
>
> When I try to create a method
> negatedWidth
>
> ^ - (self width).
>
> the UI tells me that only Numbers may be negated. I am not able to save the
> method. Am I on a wrong path or should that work and if how can I avoid the
> UI error message?
>
> Regards
>
> Max
>

NorbertHartl

Re: Number is not accepted by UI

In reply to this post by MaxBareis

Max,

Am 16.07.2014 um 00:16 schrieb Verkoster Info <[hidden email]>:

> Hi,
>
> I am using latest Pharo 3.0 + vm.
>
> I have a method width with
> width
>
> ^ 115 * self ratio.
> in my understanding it returns a Number.
>
> When I try to create a method
> negatedWidth
>
> ^ - (self width).
>
> the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
>

It is all objects and you need to send a message to them in order to have a result. So a prefixed - (minus sign) won't work. But this is a very good demonstration what I have often encountered while learning smalltalk. The most obvious choice is the right one. The solution is already in the method name. You can write it

negatedWidth

^ self width negated

:) You see. It is easy and it makes completely sense now, no?

Norbert

camille teruel

Re: Number is not accepted by UI

In reply to this post by MaxBareis

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".

The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

camille teruel

Re: Number is not accepted by UI

I've been overtaken :)

Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.
However you have the message #negated .

negatedWidth
^ self width negated

Cheers,
Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

MaxBareis

Re: Number is not accepted by UI

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

Alain Busser

Re: Number is not accepted by UI

That's where the Inspector comes in:

To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...

Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...

Alain

On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <[hidden email]> wrote:

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

MaxBareis

Re: Number is not accepted by UI

The misunderstanding her is based in the error message of the ui.

when you write

^ - self width.

and save, the UI writes this text into the code:

^ only numbers may be negated ->- self width.

More helpful would have been something like: „only literals may be negated with - use <object> negated instead“.

I was irritated and on the wrong track because I was absolutely sure that self width is a number.

Regards

Max

Am 16.07.2014 um 10:44 schrieb Alain Busser <[hidden email]>:

That's where the Inspector comes in:

To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...

Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...

Alain

On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <[hidden email]> wrote:

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

NorbertHartl

Re: Number is not accepted by UI

Am 16.07.2014 um 11:12 schrieb Max Bareis <[hidden email]>:

The misunderstanding her is based in the error message of the ui.
when you write
^ - self width.
and save, the UI writes this text into the code:
^ only numbers may be negated ->- self width.

More helpful would have been something like: „only literals may be negated with - use <object> negated instead“.

Then it needs to be "only number literals…"

I was irritated and on the wrong track because I was absolutely sure that self width is a number.

There is a difference between an object and the way you can instantiate it. The minus sign relates to the fact that smalltalk has syntax for numbers and the minus sign is part of that syntax enabling you to instantiate negated numbers. As soon as the object is created you can only send messages.

Norbert

Am 16.07.2014 um 10:44 schrieb Alain Busser <[hidden email]>:

That's where the Inspector comes in:

To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...

Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...

Alain

On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <[hidden email]> wrote:

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

Alain Busser

Re: Number is not accepted by UI

In reply to this post by MaxBareis

Then the browser had helped you, as you would have found that the "-" is a method for subtraction only. But it takes more time to look inside this browser... The reward is that you find gold nuggets here and there; for example, when I saw that there were a "asRomanLitteral" for the integers, I was astonished and pleased at the same time.

On Wed, Jul 16, 2014 at 1:12 PM, Max Bareis <[hidden email]> wrote:

The misunderstanding her is based in the error message of the ui.
when you write

^ - self width.
and save, the UI writes this text into the code:
^ only numbers may be negated ->- self width.

More helpful would have been something like: „only literals may be negated with - use <object> negated instead“.

I was irritated and on the wrong track because I was absolutely sure that self width is a number.

Regards

Max

Am 16.07.2014 um 10:44 schrieb Alain Busser <[hidden email]>:

That's where the Inspector comes in:

To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...

Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...

Alain

On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <[hidden email]> wrote:

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max

camille teruel

Re: Number is not accepted by UI

In reply to this post by MaxBareis

On 16 juil. 2014, at 11:12, Max Bareis <[hidden email]> wrote:

The misunderstanding her is based in the error message of the ui.
when you write
^ - self width.
and save, the UI writes this text into the code:
^ only numbers may be negated ->- self width.

More helpful would have been something like: „only literals may be negated with - use <object> negated instead“.

I was irritated and on the wrong track because I was absolutely sure that self width is a number.

You are right, the error message should be better.

I opened a bug entry and submitted a slice with the new error message: "The '-' prefix works only for literal numbers (use #negated instead)".

https://pharo.fogbugz.com/f/cases/13568/Better-error-message-when-using-prefix

Regards

Max

Am 16.07.2014 um 10:44 schrieb Alain Busser <[hidden email]>:

That's where the Inspector comes in:

To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...

Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...

Alain

On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <[hidden email]> wrote:

It definitely is,

thanks for all your answers…

Regards

Max

Am 16.07.2014 um 00:56 schrieb Camille Teruel <[hidden email]>:

I've been overtaken :)
Isn't that an active mailing list ?

On 16 juil. 2014, at 00:53, Camille Teruel <[hidden email]> wrote:

Hi Max,

Pharo doesn't have syntax for prefix operator like "-".
The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.

However you have the message #negated .

negatedWidth
^ self width negated

Cheers,

Camille

On 16 juil. 2014, at 00:16, Verkoster Info <[hidden email]> wrote:

Hi,

I am using latest Pharo 3.0 + vm.

I have a method width with
width

^ 115 * self ratio.
in my understanding it returns a Number.

When I try to create a method
negatedWidth

^ - (self width).

the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?

Regards

Max