problem in porting from smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

problem in porting from smalltalk

nelson -
hi,
  i'm porting some code from smalltalk and i receive a runtime error of this type

argument of or: must be a block or variable


(or: is the method i'm implementing)

I pass to it a variable i suppose ( the number 0.2)

this is the code:

a _ FuzzyMagnitude new degree:0.7.
b _ FuzzyMagnitude new degree:0.20.
a and: b. 
a and:  <- argument of and: must be a block or variable ->0.2.

(FuzzyMagnitude is an object that i have defined)
 advice,
  nelson
thanks for any


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

stéphane ducasse-2
In smalltalk there are two forms for conjunction (and) : the lazy and  
"normal" one

and: evaluates only the second argument is the first one is true
so you have to pass a block

(1 > 2) and: [3 error]
(1 <2) and: [3 error]

compare
with
(1>2) & (3 error)

Stef

On 19 févr. 06, at 12:20, nelson - wrote:

> hi,
>   i'm porting some code from smalltalk and i receive a runtime  
> error of this type
>
> argument of or: must be a block or variable
>
>
> (or: is the method i'm implementing)
>
> I pass to it a variable i suppose ( the number 0.2)
>
> this is the code:
>
> a _ FuzzyMagnitude new degree:0.7.
> b _ FuzzyMagnitude new degree:0.20.
> a and: b.
> a and:  <- argument of and: must be a block or variable ->0.2.
>
> (FuzzyMagnitude is an object that i have defined)
>  advice,
>   nelson
> thanks for any
>


Reply | Threaded
Open this post in threaded view
|

RE: problem in porting from smalltalk

Peter Crowther-2
In reply to this post by nelson -
> From: [...] nelson
> argument of or: must be a block or variable
> (or: is the method i'm implementing)

You've just been hit by the Compiler trying to compile inline code for
'and:' and 'or:', I suspect.  If you reimplement them as fuzzyAnd: and
fuzzyOr:, the problem will probably go away.

                - Peter

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Nicolas Cellier-3
Le Dimanche 19 Février 2006 14:08, Peter Crowther a écrit :
> > From: [...] nelson
> > argument of or: must be a block or variable
> > (or: is the method i'm implementing)
>
> You've just been hit by the Compiler trying to compile inline code for
> 'and:' and 'or:', I suspect.  If you reimplement them as fuzzyAnd: and
> fuzzyOr:, the problem will probably go away.
>
>   - Peter

browse class MessageNode and classVar MacroTransformers to see a list of
messages that are compiled inline and cannot be redefined in Squeak.

(I think they can be in VW).

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

nelson -
In reply to this post by Peter Crowther-2


2006/2/19, Peter Crowther <[hidden email]>:
> From: [...] nelson
> argument of or: must be a block or variable
> (or: is the method i'm implementing)

You've just been hit by the Compiler trying to compile inline code for
'and:' and 'or:', I suspect.  If you reimplement them as fuzzyAnd: and
fuzzyOr:, the problem will probably go away.

                - Peter


Dear Peter,
   the problem is that i HAVE to impelement and: .... I have a fuzzyAnd: method, but i want to be able to mix crisp and fuzzy value, so redefining and: definition would be the best choice... can I disable this code inlining?

thanks,
  nelson


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Bryce Kampjes
nelson - writes:

 > Dear Peter,
 >    the problem is that i HAVE to impelement and: .... I have a fuzzyAnd:
 > method, but i want to be able to mix crisp and fuzzy value, so redefining
 > and: definition would be the best choice... can I disable this code
 > inlining?

You should definately be able to disable the and: inlining. I doubt
that everyone would be happy with such a change in the mainstream
image but it's definately reasonable for your personal images or for a
project that needs and: to behave like a proper method.

Poke around in the Compiler class, and save your image frequently.
Try exploring how the "special" instance variable on MessageNode is
used.

Hmm, yet another argument for full message inlining. But for now,
you'll loose performance, however the loss may not be noticable.

Bryce

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Nicolas Cellier-3
Le Mercredi 22 Février 2006 23:36, Bryce Kampjes a écrit :

> nelson - writes:
>  > Dear Peter,
>  >    the problem is that i HAVE to impelement and: .... I have a fuzzyAnd:
>  > method, but i want to be able to mix crisp and fuzzy value, so
>  > redefining and: definition would be the best choice... can I disable
>  > this code inlining?
>
> You should definately be able to disable the and: inlining. I doubt
> that everyone would be happy with such a change in the mainstream
> image but it's definately reasonable for your personal images or for a
> project that needs and: to behave like a proper method.
>
> Poke around in the Compiler class, and save your image frequently.
> Try exploring how the "special" instance variable on MessageNode is
> used.
>
> Hmm, yet another argument for full message inlining. But for now,
> you'll loose performance, however the loss may not be noticable.
>
> Bryce

What about a little change in the #and: form ?

using blocks both sides of the #and: message would enable the compiler to
choose its way of generating bytecodes:

When both receiver and argument are blocks, use bytecode optimization.
 [a < 0] and: [b > a]
When one of the two isn't a block, then use regular message send.
 a and: b

This is in the spirit of whileTrue: optimization in VW.
Of course, most senders of #and: would have to be rewritten with block
receiver to profit by compiler optimization.

What do you think of this proposition ?

Another more radical solution is a kind of <pragma: #dontOptimizedCode>,
or maybe more selective <dontOptimize: #and:>...

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Lukas Renggli
> This is in the spirit of whileTrue: optimization in VW.
> Of course, most senders of #and: would have to be rewritten with block
> receiver to profit by compiler optimization.

That doesn't make sense, #and: and #whileTrue: are completely
different constructs. See the difference when writing down the
execution path of a and b as regular expressions:

      a and: [ b ] -> ab?

      [ a ] whileTrue: [ b ] -> a(ba)*

There is no point in putting expressions into a block that are
executed exactly once. This also violates the SmallLint rule "Block
immediately evaluated".

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

RE: Re: problem in porting from smalltalk

Peter Crowther-2
In reply to this post by nelson -
> From: nicolas cellier
> Have to revert to a <pragma> thing...

I'm not convinced.  Pragmas are at best a kludge.

I liked the early gcc response to #pragma.  The spec stated that a
compiler could do whatever it wanted when it saw a #pragma, so gcc tried
to run a variety of games and threw a segmentation fault if it failed to
find any of them.

                - Peter

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

stéphane ducasse-2
I think that nicolas is talking about
method pragmas as in VW and now in squeak 3.9.

Retrospectively I think that pragmas are really an excellent addition  
to VW
with is bloated with the lot of less desirable features (class import  
level...)

Stef

On 23 févr. 06, at 22:17, Peter Crowther wrote:

>> From: nicolas cellier
>> Have to revert to a <pragma> thing...
>
> I'm not convinced.  Pragmas are at best a kludge.
>
> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc  
> tried
> to run a variety of games and threw a segmentation fault if it  
> failed to
> find any of them.
>
> - Peter
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Re: problem in porting from smalltalk

Lukas Renggli
In reply to this post by Peter Crowther-2
> I'm not convinced.  Pragmas are at best a kludge.
>
> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc tried
> to run a variety of games and threw a segmentation fault if it failed to
> find any of them.

The pragmas in 3.9 are not there to tweak the code generator. After
parsing they are put into the compiled method, so that the system can
query tagged methods. It has absolutely nothing to do with the
#pragma, except that is shared its name.

The Smalltalk pragmas are a key element to write extensible software.
Right now a lot of extension problems can only be solved trough the
use of strange naming conventions, such as that test-methods in SUnit
have to start with #test, or that meta-descriptions in Magritte have
to start with #description, etc. Moreover there is no clean way to
tell the system that a specific method is used as an event-handler, or
that a method explicitly fails an SLint rule, or that it returns a
string of a specific mime-type, etc. Pragmas are a slick solution to a
permanent problem that cannot be easily solved otherwise.

Lukas


--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Andreas.Raab
Lukas Renggli wrote:
> The pragmas in 3.9 are not there to tweak the code generator. After
> parsing they are put into the compiled method, so that the system can
> query tagged methods. It has absolutely nothing to do with the
> #pragma, except that is shared its name.

Which is precisely the reason why I originally called them "annotations"
instead of pragmas.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Nicolas Cellier-3
> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc tried
> to run a variety of games and threw a segmentation fault if it failed to
> find any of them.
>
>                 - Peter

Yes, early, but then they added their own __attribute__...

> Which is precisely the reason why I originally called them "annotations"
> instead of pragmas.
>
> Cheers,
>    - Andreas

As everybody, I dislike pragmas for they are compiler dependent, not part of
the language definition itself, and lead to portability problems
(already upset by structure alignment in {} and its damn pragmas).

Inside squeak, portability is not a problem, you can change the compiler, and
you can make this change a prereq when loading into another image.

Problems will raise when you want to move outside Squeak.
But in this case, Squeakers will also get problems with the {a. b. c.}
extension, Dolphiners with the ##() extension etc...

So, at inter-dialect level, pragmas, annotations or whatever syntax extension
will lead to portability problem, because they are not standard.
The difference between #annotations and #pragmas might not be so thick from a
pragmatic point of view...

------------------------------------------------------------------------
The facts:
Without byte code optimization, Smalltalk would not be efficient at all.
Byte code optimization makes Smalltalk not as extensible as it should be.
This problem exists in other Smalltalks.

The solutions:
- Nobody likes the pragma. OK.
- Lukas does not like blocks evaluated once and only once. OK.
- Bryce and Peter suggested unoptimizing only #and/#or:, and that is the
simpler solution by now. In a 3.8 image just :

MessageNode>>transformAnd: encoder
    ^false
MessageNode>>transformOr: encoder
    ^false

Maybe the not optimized and: won't break performance noticeably... worth
trying...

A work around to get both optimized and notoptimized code on a class basis is
this one (mostly 3 classes and 4 messages):
- declare  compilerClass ^NotOptimizedAndOrCompiler as class method where you
intend to use your fuzzy logic and: extension...
- NotOptimizedAndOrCompiler will arrange to use NotOptimizedAndOrParser
- NotOptimizedAndOrParser will use NotOptimizedAndOrMessageNode
- NotOptimizedAndOrMessageNode will only redefine above transformAnd:
transformOr: methods
- maybe have to change a few more refs of MessageNode... (turning isMemberOf:
into isKindOf: and other things like that)

> The clean solution is to dynamically inline message sends so the
> simple unoptimised version of and: is as fast as the optimised
> version. A system with dynamicly inlined messages would be much
> faster for other things as well.
>
> Bryce

Waouh. At the VM level ? That one is far above my skills...
Isn't it the kind of optimization in VW VM ?
My understanding of efficiency problem when not open-bytecoding #and: is the
creation of BlockContext.
Inlining send you gain creation of a MethodContext but not of a  BlockContext.
But if you also gain speed elsewhere, that's surely better...

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

stéphane ducasse-2
In reply to this post by Andreas.Raab
andreas may be VW people got first the wrong name, but using a  
consistent one is better I think.

Stef

On 23 févr. 06, at 22:58, Andreas Raab wrote:

> Lukas Renggli wrote:
>> The pragmas in 3.9 are not there to tweak the code generator. After
>> parsing they are put into the compiled method, so that the system can
>> query tagged methods. It has absolutely nothing to do with the
>> #pragma, except that is shared its name.
>
> Which is precisely the reason why I originally called them  
> "annotations" instead of pragmas.
>
> Cheers,
>   - Andreas
>


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Andreas.Raab
<meta>
Not that I personally care that much about this particular name but you
are touching a sore point here. That point is that in too many
situations I have seen people copying really screwed up stuff from VW[*]
and other systems just because they can't change it there and don't want
to work around the differences. What happens then is that you are
actively making Squeak worse by repeating a bad decision (even worse:
you are repeating it although you have the benefit of hindsight) where
instead you should be fixing the mistake and help make Squeak a better
system.

And yes, I understand that this is inconvenient if you care about
compatibility but slavishly repeating everything VW does will only get
you a VW clone, not a better system.
</meta>

[*] My pet peeve these days: Proliferation of standard protocols for the
"sake" of compatibility with X, Y, or Z. Just look at the evolution of
the Collection protocols over the last 4-5 Squeak versions to see what I
mean. I mean, if people need compatibility, why not make a compatibility
*package*? Like, in this, a subclass of the real thing that's named
Pragma and can be used if you need "compatible" pragmas.

Cheers,
   - Andreas

stéphane ducasse wrote:

> andreas may be VW people got first the wrong name, but using a
> consistent one is better I think.
>
> Stef
>
> On 23 févr. 06, at 22:58, Andreas Raab wrote:
>
>> Lukas Renggli wrote:
>>> The pragmas in 3.9 are not there to tweak the code generator. After
>>> parsing they are put into the compiled method, so that the system can
>>> query tagged methods. It has absolutely nothing to do with the
>>> #pragma, except that is shared its name.
>>
>> Which is precisely the reason why I originally called them
>> "annotations" instead of pragmas.
>>
>> Cheers,
>>   - Andreas
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Markus Gälli-3
In reply to this post by stéphane ducasse-2

On Feb 24, 2006, at 9:10 AM, stéphane ducasse wrote:

> andreas may be VW people got first the wrong name, but using a  
> consistent one is better I think.

Being consistent with the thinking and naming conventions of some  
Java folks, who might want to drop in, wouldn't hurt either.
Especially as they might have a bigger problem to change their  
"bindings" than the VW-folks... ;-)

And to me "annotations" seems to be a much more telling word than  
"pragma" (though "attribute" from C# seems to be the more polymorph...)

See also
http://en.wikipedia.org/wiki/Annotation
"Differences in computer languages have given rise to a variety of  
words for programmer-added metadata, including annotation (Java),  
attribute (C#), pragma (C), and metadata (HTML)."

Cheers,

Markus

>
> Stef
>
> On 23 févr. 06, at 22:58, Andreas Raab wrote:
>
>> Lukas Renggli wrote:
>>> The pragmas in 3.9 are not there to tweak the code generator. After
>>> parsing they are put into the compiled method, so that the system  
>>> can
>>> query tagged methods. It has absolutely nothing to do with the
>>> #pragma, except that is shared its name.
>>
>> Which is precisely the reason why I originally called them  
>> "annotations" instead of pragmas.
>>
>> Cheers,
>>   - Andreas
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

stéphane ducasse-2
In reply to this post by Andreas.Raab
<pragmatic and not ranting> I guess that we are not slavishly  
reproducing VW. And lukas and marcus did a really good
to get annotation or pragmas in Squeak.  Just helping Squeak and VW  
to communicate more.
Because when you will be happily be able to use their crypto package  
then we would all have win something.
And easing the port of good abstractions (Pier, Seaside) between the  
dialect is important for everybody.
<\pragmatic and not ranting>

> <meta>
> Not that I personally care that much about this particular name but  
> you are touching a sore point here. That point is that in too many  
> situations I have seen people copying really screwed up stuff from  
> VW[*] and other systems just because they can't change it there and  
> don't want to work around the differences. What happens then is  
> that you are actively making Squeak worse by repeating a bad  
> decision (even worse: you are repeating it although you have the  
> benefit of hindsight) where instead you should be fixing the  
> mistake and help make Squeak a better system.
>
> And yes, I understand that this is inconvenient if you care about  
> compatibility but slavishly repeating everything VW does will only  
> get you a VW clone, not a better system.
> </meta>
>
> [*] My pet peeve these days: Proliferation of standard protocols  
> for the "sake" of compatibility with X, Y, or Z. Just look at the  
> evolution of the Collection protocols over the last 4-5 Squeak  
> versions to see what I mean. I mean, if people need compatibility,  
> why not make a compatibility *package*? Like, in this, a subclass  
> of the real thing that's named Pragma and can be used if you need  
> "compatible" pragmas.
>
> Cheers,
>   - Andreas
>
> stéphane ducasse wrote:
>> andreas may be VW people got first the wrong name, but using a  
>> consistent one is better I think.
>> Stef
>> On 23 févr. 06, at 22:58, Andreas Raab wrote:
>>> Lukas Renggli wrote:
>>>> The pragmas in 3.9 are not there to tweak the code generator. After
>>>> parsing they are put into the compiled method, so that the  
>>>> system can
>>>> query tagged methods. It has absolutely nothing to do with the
>>>> #pragma, except that is shared its name.
>>>
>>> Which is precisely the reason why I originally called them  
>>> "annotations" instead of pragmas.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Lukas Renggli
In reply to this post by Andreas.Raab
Andreas, did you have a look at the implementation? It is not an 1:1,
it just supports the same protocol.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Louis LaBrunda
In reply to this post by Nicolas Cellier-3

Hi All,

I am not new to Smalltalk but I am very, very new to Squeak and know
nothing about the compiler and its optimizations, so this suggestion may be
way off base, but here goes, couldn't the optimized code for and: and or:
be enhanced to test to see if the receiver is a boolean and if not pass the
message on the receiver in the non optimized way?  Hopefully this extra
test would not reduced the optimization much.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com


Reply | Threaded
Open this post in threaded view
|

Re: problem in porting from smalltalk

Andreas.Raab
In reply to this post by Lukas Renggli
Yup, I sure did. Mostly because I was concerned about the IP aspects.
But keep in mind that my rant was a meta rant and (in this case) pointed
at using the name Pragma where one only has to look at
http://www.google.com/search?q=define:+pragma to see that pragma
describes not what these annotations are being used for and that
therefore the "consistency" argument is really a "compatibility"
argument, e.g., VW uses that bad name so we have to use the same bad
name. And there is really no point in that unless you want to write a VW
clone.

Cheers,
   - Andreas

Lukas Renggli wrote:

> Andreas, did you have a look at the implementation? It is not an 1:1,
> it just supports the same protocol.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>


12