nil does not understand #shouldBeAliased:

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

nil does not understand #shouldBeAliased:

onierstrasz

Hi Folks,

I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.

I compile Graph-ET-Util.st as follows:

+ cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
+ /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st

and I get the following error:

Compiler loaded
Compiling collected .st files
Importing: Graph-ET-Util.st
Importer >> import:
BlockClosure >> whileFalse:
...
SemanticAnalyzer >> visit:
SendNode >> accept:
SemanticAnalyzer >> visitSendNode:
UndefinedObject >> doesNotUnderstand:
nil does not understand #shouldBeAliased:

#shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:

I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.

https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st

Hints anyone?

Thanks in advance,
Oscar

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

Nicolas Petton
Hi Oscar,

I will have a look at it tonight. It might be a bug in the compiler, but
it's IMO quite unlikely, looking at the issue.

Cheers,
Nico


Oscar Nierstrasz writes:

> Hi Folks,
>
> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>
> I compile Graph-ET-Util.st as follows:
>
> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>
> and I get the following error:
>
> Compiler loaded
> Compiling collected .st files
> Importing: Graph-ET-Util.st
> Importer >> import:
> BlockClosure >> whileFalse:
> ...
> SemanticAnalyzer >> visit:
> SendNode >> accept:
> SemanticAnalyzer >> visitSendNode:
> UndefinedObject >> doesNotUnderstand:
> nil does not understand #shouldBeAliased:
>
> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>
> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>
> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>
> Hints anyone?
>
> Thanks in advance,
> Oscar


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

Herby Vojčík
It is a bug in a compiler (or parser, I don't know who copies receiver to SendNodes in the CascadeNode), the failing method is

```smalltalk
strongHighlightWhenClick

        (self diagram) on: ROMouseClick do: [:event |
                | attributes |
                attributes := event element attributes.
               
                (attributes includesKey: #isPressed)
                        ifTrue: [ROBlink unhighlight:  event element.
                                attributes removeKey: #isPressed ];
                        ifFalse: [ROBlink highlight: event element.
                                attributes at: #isPressed put: true ].
                ].
```

If you inspect `Smalltalk current parse: '<the code of method>' and dive into the
cascade in the do: block, you see that second send in cascade has nil receiver (it should be SendNode); the whole CascadeNode as well as first SendNode have it fine.

Oscar: why ifTrue:; ifFalse: in cascade? It can be one messag
e ifTrue:ifFalse: (and it should work around this issue).

Nicolas Petton wrote:

> Hi Oscar,
>
> I will have a look at it tonight. It might be a bug in the compiler, but
> it's IMO quite unlikely, looking at the issue.
>
> Cheers,
> Nico
>
>
> Oscar Nierstrasz writes:
>
>> Hi Folks,
>>
>> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>>
>> I compile Graph-ET-Util.st as follows:
>>
>> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
>> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>>
>> and I get the following error:
>>
>> Compiler loaded
>> Compiling collected .st files
>> Importing: Graph-ET-Util.st
>> Importer>>  import:
>> BlockClosure>>  whileFalse:
>> ...
>> SemanticAnalyzer>>  visit:
>> SendNode>>  accept:
>> SemanticAnalyzer>>  visitS
endNode:

>> UndefinedObject>>  doesNotUnderstand:
>> nil does not understand #shouldBeAliased:
>>
>> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>>
>> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>>
>> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>>
>> Hints anyone?
>>
>> Thanks in advance,
>> Oscar
>
>

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

onierstrasz

Cool!

Indeed, the cascade is unnecessary.  Removing it allows the file to compile.

What I don't understand is why it should make a difference.

BTW, Herby, how exactly did you home in on the failing method?

Cheers,
Oscar

On Dec 17, 2013, at 1:27 PM, Herby Vojčík <[hidden email]> wrote:

> It is a bug in a compiler (or parser, I don't know who copies receiver to SendNodes in the CascadeNode), the failing method is
>
> ```smalltalk
> strongHighlightWhenClick
>
>       (self diagram) on: ROMouseClick do: [:event |
>               | attributes |
>               attributes := event element attributes.
>                              (attributes includesKey: #isPressed)
>                       ifTrue: [ROBlink unhighlight:  event element.                                attributes removeKey: #isPressed ];
>                       ifFalse: [ROBlink highlight: event element.
>                               attributes at: #isPressed put: true ].
>               ].
> ```
>
> If you inspect `Smalltalk current parse: '<the code of method>' and dive into the
> cascade in the do: block, you see that second send in cascade has nil receiver (it should be SendNode); the whole CascadeNode as well as first SendNode have it fine.
>
> Oscar: why ifTrue:; ifFalse: in cascade? It can be one messag
> e ifTrue:ifFalse: (and it should work around this issue).
>
> Nicolas Petton wrote:
>> Hi Oscar,
>>
>> I will have a look at it tonight. It might be a bug in the compiler, but
>> it's IMO quite unlikely, looking at the issue.
>>
>> Cheers,
>> Nico
>>
>>
>> Oscar Nierstrasz writes:
>>
>>> Hi Folks,
>>>
>>> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>>>
>>> I compile Graph-ET-Util.st as follows:
>>>
>>> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
>>> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>>>
>>> and I get the following error:
>>>
>>> Compiler loaded
>>> Compiling collected .st files
>>> Importing: Graph-ET-Util.st
>>> Importer>>  import:
>>> BlockClosure>>  whileFalse:
>>> ...
>>> SemanticAnalyzer>>  visit:
>>> SendNode>>  accept:
>>> SemanticAnalyzer>>  visitS
> endNode:
>>> UndefinedObject>>  doesNotUnderstand:
>>> nil does not understand #shouldBeAliased:
>>>
>>> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>>>
>>> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>>>
>>> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>>>
>>> Hints anyone?
>>>
>>> Thanks in advance,
>>> Oscar
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

Nicolas Petton
Hi Oscar,

It is indeed a bug. I'll fix it shortly. I think I'll do a release, as
master also includes important fixes for ie8.

Cheers,
Nico


Oscar Nierstrasz writes:

> Cool!
>
> Indeed, the cascade is unnecessary.  Removing it allows the file to compile.
>
> What I don't understand is why it should make a difference.
>
> BTW, Herby, how exactly did you home in on the failing method?
>
> Cheers,
> Oscar
>
> On Dec 17, 2013, at 1:27 PM, Herby Vojčík <[hidden email]> wrote:
>
>> It is a bug in a compiler (or parser, I don't know who copies receiver to SendNodes in the CascadeNode), the failing method is
>>
>> ```smalltalk
>> strongHighlightWhenClick
>>
>>       (self diagram) on: ROMouseClick do: [:event |
>>               | attributes |
>>               attributes := event element attributes.
>>                              (attributes includesKey: #isPressed)
>>                       ifTrue: [ROBlink unhighlight:  event element.                                attributes removeKey: #isPressed ];
>>                       ifFalse: [ROBlink highlight: event element.
>>                               attributes at: #isPressed put: true ].
>>               ].
>> ```
>>
>> If you inspect `Smalltalk current parse: '<the code of method>' and dive into the
>> cascade in the do: block, you see that second send in cascade has nil receiver (it should be SendNode); the whole CascadeNode as well as first SendNode have it fine.
>>
>> Oscar: why ifTrue:; ifFalse: in cascade? It can be one messag
>> e ifTrue:ifFalse: (and it should work around this issue).
>>
>> Nicolas Petton wrote:
>>> Hi Oscar,
>>>
>>> I will have a look at it tonight. It might be a bug in the compiler, but
>>> it's IMO quite unlikely, looking at the issue.
>>>
>>> Cheers,
>>> Nico
>>>
>>>
>>> Oscar Nierstrasz writes:
>>>
>>>> Hi Folks,
>>>>
>>>> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>>>>
>>>> I compile Graph-ET-Util.st as follows:
>>>>
>>>> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
>>>> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>>>>
>>>> and I get the following error:
>>>>
>>>> Compiler loaded
>>>> Compiling collected .st files
>>>> Importing: Graph-ET-Util.st
>>>> Importer>>  import:
>>>> BlockClosure>>  whileFalse:
>>>> ...
>>>> SemanticAnalyzer>>  visit:
>>>> SendNode>>  accept:
>>>> SemanticAnalyzer>>  visitS
>> endNode:
>>>> UndefinedObject>>  doesNotUnderstand:
>>>> nil does not understand #shouldBeAliased:
>>>>
>>>> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>>>>
>>>> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>>>>
>>>> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>>>>
>>>> Hints anyone?
>>>>
>>>> Thanks in advance,
>>>> Oscar
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>> For more options, visit https://groups.google.com/groups/opt_out.


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

Herby Vojčík
In reply to this post by onierstrasz


Oscar Nierstrasz wrote:
> Cool!
>
> Indeed, the cascade is unnecessary.  Removing it allows the file to compile.
>
> What I don't understand is why it should make a difference.
>
> BTW, Herby, how exactly did you home in on the failing method?You

Your stack showed SemanticAnalyzer >> visitSendNode fail by not
understanding #shouldBeAliased. There is only one send of this selector
there, and it only fires when selector that is to be inlined is
processed and it is sent to its receiver (which should contain a Node).
After a pretty little search I found the list of selector that IRInliner
inlines - and those were only ifTrue:ifFalse: family and ifNil:ifNotNil:
family. I looked over your file and found there was very little send of
these (maybe only that one, may a few more). I knew CascadeNode has
SendNodes as its subnodes, and it looked suspicous for me immediately
that there can be the bug (it is scenario that may have slipped - using
inlineable selector in cascade's not first send). After I parsed it, I
found out it was really there.

Herby

>
> Cheers,
> Oscar
>
> On Dec 17, 2013, at 1:27 PM, Herby Vojčík<[hidden email]>  wrote:
>
>> It is a bug in a compiler (or parser, I don't know who copies receiver to SendNodes in the CascadeNode), the failing method is
>>
>> ```smalltalk
>> strongHighlightWhenClick
>>
>>        (self diagram) on: ROMouseClick do: [:event |
>>                | attributes |
>>                attributes := event element attributes.
>>                               (attributes includesKey: #isPressed)
>>                        ifTrue: [ROBlink unhighlight:  event element.                                attributes removeKey: #isPressed ];
>>                        ifFalse: [ROBlink highlight: event element.
>>                                attributes at: #isPressed put: true ].
>>                ].
>> ```
>>
>> If you inspect `Smalltalk current parse: '<the code of method>' and dive into the
>> cascade in the do: block, you see that second send in cascade has nil receiver (it should be SendNode); the whole CascadeNode as well as first SendNode have it fine.
>>
>> Oscar: why ifTrue:; ifFalse: in cascade? It can be one messag
>> e ifTrue:ifFalse: (and it should work around this issue).
>>
>> Nicolas Petton wrote:
>>> Hi Oscar,
>>>
>>> I will have a look at it tonight. It might be a bug in the compiler, but
>>> it's IMO quite unlikely, looking at the issue.
>>>
>>> Cheers,
>>> Nico
>>>
>>>
>>> Oscar Nierstrasz writes:
>>>
>>>> Hi Folks,
>>>>
>>>> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>>>>
>>>> I compile Graph-ET-Util.st as follows:
>>>>
>>>> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
>>>> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>>>>
>>>> and I get the following error:
>>>>
>>>> Compiler loaded
>>>> Compiling collected .st files
>>>> Importing: Graph-ET-Util.st
>>>> Importer>>   import:
>>>> BlockClosure>>   whileFalse:
>>>> ...
>>>> SemanticAnalyzer>>   visit:
>>>> SendNode>>   accept:
>>>> SemanticAnalyzer>>   visitS
>> endNode:
>>>> UndefinedObject>>   doesNotUnderstand:
>>>> nil does not understand #shouldBeAliased:
>>>>
>>>> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>>>>
>>>> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>>>>
>>>> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>>>>
>>>> Hints anyone?
>>>>
>>>> Thanks in advance,
>>>> Oscar
>>>
>> --
>> You received this message because you are subscribed to the Google Groups "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>> For more options, visit https://groups.google.com/groups/opt_out.
>

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: nil does not understand #shouldBeAliased:

Nicolas Petton
In reply to this post by Nicolas Petton
Hi guys,

Here's the issue https://github.com/amber-smalltalk/amber/issues/774.
The fix has been merged
https://github.com/amber-smalltalk/amber/commit/f0b70f605428114f851ceb1c11eb074ba3c55ebd#diff-4aa1eaef4db8e855700a42398837b7e0R577


Cheers,
Nico

Nicolas Petton writes:

> Hi Oscar,
>
> It is indeed a bug. I'll fix it shortly. I think I'll do a release, as
> master also includes important fixes for ie8.
>
> Cheers,
> Nico
>
>
> Oscar Nierstrasz writes:
>
>> Cool!
>>
>> Indeed, the cascade is unnecessary.  Removing it allows the file to compile.
>>
>> What I don't understand is why it should make a difference.
>>
>> BTW, Herby, how exactly did you home in on the failing method?
>>
>> Cheers,
>> Oscar
>>
>> On Dec 17, 2013, at 1:27 PM, Herby Vojčík <[hidden email]> wrote:
>>
>>> It is a bug in a compiler (or parser, I don't know who copies receiver to SendNodes in the CascadeNode), the failing method is
>>>
>>> ```smalltalk
>>> strongHighlightWhenClick
>>>
>>>       (self diagram) on: ROMouseClick do: [:event |
>>>               | attributes |
>>>               attributes := event element attributes.
>>>                              (attributes includesKey: #isPressed)
>>>                       ifTrue: [ROBlink unhighlight:  event element.                                attributes removeKey: #isPressed ];
>>>                       ifFalse: [ROBlink highlight: event element.
>>>                               attributes at: #isPressed put: true ].
>>>               ].
>>> ```
>>>
>>> If you inspect `Smalltalk current parse: '<the code of method>' and dive into the
>>> cascade in the do: block, you see that second send in cascade has nil receiver (it should be SendNode); the whole CascadeNode as well as first SendNode have it fine.
>>>
>>> Oscar: why ifTrue:; ifFalse: in cascade? It can be one messag
>>> e ifTrue:ifFalse: (and it should work around this issue).
>>>
>>> Nicolas Petton wrote:
>>>> Hi Oscar,
>>>>
>>>> I will have a look at it tonight. It might be a bug in the compiler, but
>>>> it's IMO quite unlikely, looking at the issue.
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>>
>>>> Oscar Nierstrasz writes:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I am able to recompile most of RoAmber now, but still have a couple of strange compiler errors.  This one appears to be a bug in the compiler itself.
>>>>>
>>>>> I compile Graph-ET-Util.st as follows:
>>>>>
>>>>> + cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
>>>>> + /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Graph-ET-Util.st
>>>>>
>>>>> and I get the following error:
>>>>>
>>>>> Compiler loaded
>>>>> Compiling collected .st files
>>>>> Importing: Graph-ET-Util.st
>>>>> Importer>>  import:
>>>>> BlockClosure>>  whileFalse:
>>>>> ...
>>>>> SemanticAnalyzer>>  visit:
>>>>> SendNode>>  accept:
>>>>> SemanticAnalyzer>>  visitS
>>> endNode:
>>>>> UndefinedObject>>  doesNotUnderstand:
>>>>> nil does not understand #shouldBeAliased:
>>>>>
>>>>> #shouldBeAliased is implemented in SendNode. It looks like the Semantic Analyzer is getting a nil Node somehow and trying to send it #shouldBeAliased:
>>>>>
>>>>> I guess there is an aliasing problem somewhere in Graph-ET-Util.st, but I don't have enough information to move forward.
>>>>>
>>>>> https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Graph-ET-Util.st
>>>>>
>>>>> Hints anyone?
>>>>>
>>>>> Thanks in advance,
>>>>> Oscar
>>>>
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "amber-lang" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>>> For more options, visit https://groups.google.com/groups/opt_out.


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.