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. |
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. |
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 >> 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. |
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. |
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. |
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. |
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. |
Free forum by Nabble | Edit this page |