Cuis now runs with latest Cog, but I don't understand the problem we had

Hi Eliot, Folks,

Until today, Cuis wouldn't run with any Cog VM newer than #3370. Phil Bellalouna just found the problem. I short, the problem is Character>>#= calling primitive 110 directly. For some reason, primitive 110 works ok if called from #== but not if called from #=, at least in Character.

If you want to see the problem, just get latest Cuis from https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev and run it with latest Cog. It will start ok. Then browse Character>>#= and uncomment the <primitive: 110> line, and debuggers immediately arise.

I'm posting this because I can't understand why does this happen, and maybe this leads to some fix/enh in Cog. Besides, I'm curious and I'd like to know. So, please take a look and enlighten me.

Thanks,
Juan Vuletich

On 4/28/2016 2:13 PM, Phil (list) wrote:

On Thu, 2016-04-28 at 12:58 -0400, Phil (list) wrote:

On Thu, 2016-04-28 at 16:43 +0200, Clément Bera wrote:

  Have you tried on latest VM ? I remembered fixing a bug on #==
primitive like a month ago. The problem was when performing #==
primitive with the argument being a forwarder to an immediate.

The problem still existed as of Cog #3686 (Juan found the fix
yesterday.)  On my system, Cuis last worked perfectly with 3370,
mostly
worked with 3390, somewhat worked with 3427 and did not work after
that
until we found the Character>>#= bug/fix.

Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected.

Fortunately I work with Gera Richarte @ Satellogic, and it didn't take long for him to suggest an explanation: Maybe prim 110 is broken in recent Cog VMs, but nobody notices it because the only sender is #== that is already optimized by the jitter, so prim 110 is never really called. And I realized we can test that theory. First, we add this method to Character:

=== aCharacter
<primitive: 110>
    self halt

Then the following snippet (in latest Cuis, #2744):

    0 to: 255 do: [ :i1 | 0 to: 255 do: [ :i2 | i1 = i2 ifFalse: [(Character value: i1) === (Character value: i2) ifTrue: [{i1.i2} print ]]]]

prints nothing if run with Cog 3370, but prints a lot of pairs in more recent Cog. So I think Gera is right.

Thanks,
Juan Vuletich

Hi Juan, then how do you explain:

"Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected."

2016-04-28 21:10 GMT+02:00 Juan Vuletich <[hidden email]>:

On 4/28/2016 2:13 PM, Phil (list) wrote:

On Thu, 2016-04-28 at 12:58 -0400, Phil (list) wrote:

On Thu, 2016-04-28 at 16:43 +0200, Clément Bera wrote:

  Have you tried on latest VM ? I remembered fixing a bug on #==
primitive like a month ago. The problem was when performing #==
primitive with the argument being a forwarder to an immediate.

The problem still existed as of Cog #3686 (Juan found the fix
yesterday.)  On my system, Cuis last worked perfectly with 3370,
mostly
worked with 3390, somewhat worked with 3427 and did not work after
that
until we found the Character>>#= bug/fix.

Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected.

Fortunately I work with Gera Richarte @ Satellogic, and it didn't take long for him to suggest an explanation: Maybe prim 110 is broken in recent Cog VMs, but nobody notices it because the only sender is #== that is already optimized by the jitter, so prim 110 is never really called. And I realized we can test that theory. First, we add this method to Character:

=== aCharacter
<primitive: 110>
    self halt

Then the following snippet (in latest Cuis, #2744):

    0 to: 255 do: [ :i1 | 0 to: 255 do: [ :i2 | i1 = i2 ifFalse: [(Character value: i1) === (Character value: i2) ifTrue: [{i1.i2} print ]]]]

prints nothing if run with Cog 3370, but prints a lot of pairs in more recent Cog. So I think Gera is right.

Thanks,
Juan Vuletich

On 4/28/2016 4:39 PM, Nicolas Cellier via Cuis-dev wrote:

Moreover, as long as you write primitive: 110 in cog, you don't invoke primitive 110.

You rather invoke genPrimitiveIdentical.

Please try the snippet on a StackVM.

Sure. Can you provide a link to such VM? It should be based on VMMaker.oscog-eem.1370/r3386 or later, as the problem doesn't happen with any Cog older than that.

Thanks,
Juan Vuletich

genPrimitiveIdentical has been slightly refactored, but I see no obvious problem by just reading code.

Moreover, when you use Object = you'll also call same methods in the end...

This would deserve experimenting VMSimulator... (I don't have the Bochs plugin working now)

2016-04-28 21:21 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi Juan, then how do you explain:

"Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected."

2016-04-28 21:10 GMT+02:00 Juan Vuletich <[hidden email]>:

On 4/28/2016 2:13 PM, Phil (list) wrote:

On Thu, 2016-04-28 at 12:58 -0400, Phil (list) wrote:

On Thu, 2016-04-28 at 16:43 +0200, Clément Bera wrote:

  Have you tried on latest VM ? I remembered fixing a bug on #==
primitive like a month ago. The problem was when performing #==
primitive with the argument being a forwarder to an immediate.

The problem still existed as of Cog #3686 (Juan found the fix
yesterday.)  On my system, Cuis last worked perfectly with 3370,
mostly
worked with 3390, somewhat worked with 3427 and did not work after
that
until we found the Character>>#= bug/fix.

Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected.

Fortunately I work with Gera Richarte @ Satellogic, and it didn't take long for him to suggest an explanation: Maybe prim 110 is broken in recent Cog VMs, but nobody notices it because the only sender is #== that is already optimized by the jitter, so prim 110 is never really called. And I realized we can test that theory. First, we add this method to Character:

=== aCharacter
<primitive: 110>
    self halt

Then the following snippet (in latest Cuis, #2744):

    0 to: 255 do: [ :i1 | 0 to: 255 do: [ :i2 | i1 = i2 ifFalse: [(Character value: i1) === (Character value: i2) ifTrue: [{i1.i2} print ]]]]

prints nothing if run with Cog 3370, but prints a lot of pairs in more recent Cog. So I think Gera is right.

Thanks,
Juan Vuletich

_______________________________________________
Cuis-dev mailing list
[hidden email]
http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org

 

On 4/28/2016 4:39 PM, Nicolas Cellier via Cuis-dev wrote:

Moreover, as long as you write primitive: 110 in cog, you don't invoke primitive 110.

You rather invoke genPrimitiveIdentical.

Please try the snippet on a StackVM.

Sure. Can you provide a link to such VM? It should be based on VMMaker.oscog-eem.1370/r3386 or later, as the problem doesn't happen with any Cog older than that.

Thanks,
Juan Vuletich

genPrimitiveIdentical has been slightly refactored, but I see no obvious problem by just reading code.

Moreover, when you use Object = you'll also call same methods in the end...

This would deserve experimenting VMSimulator... (I don't have the Bochs plugin working now)

2016-04-28 21:21 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi Juan, then how do you explain:

"Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected."

2016-04-28 21:10 GMT+02:00 Juan Vuletich <[hidden email]>:

On 4/28/2016 2:13 PM, Phil (list) wrote:

On Thu, 2016-04-28 at 12:58 -0400, Phil (list) wrote:

On Thu, 2016-04-28 at 16:43 +0200, Clément Bera wrote:

  Have you tried on latest VM ? I remembered fixing a bug on #==
primitive like a month ago. The problem was when performing #==
primitive with the argument being a forwarder to an immediate.

The problem still existed as of Cog #3686 (Juan found the fix
yesterday.)  On my system, Cuis last worked perfectly with 3370,
mostly
worked with 3390, somewhat worked with 3427 and did not work after
that
until we found the Character>>#= bug/fix.

Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected.

Fortunately I work with Gera Richarte @ Satellogic, and it didn't take long for him to suggest an explanation: Maybe prim 110 is broken in recent Cog VMs, but nobody notices it because the only sender is #== that is already optimized by the jitter, so prim 110 is never really called. And I realized we can test that theory. First, we add this method to Character:

=== aCharacter
<primitive: 110>
    self halt

Then the following snippet (in latest Cuis, #2744):

    0 to: 255 do: [ :i1 | 0 to: 255 do: [ :i2 | i1 = i2 ifFalse: [(Character value: i1) === (Character value: i2) ifTrue: [{i1.i2} print ]]]]

prints nothing if run with Cog 3370, but prints a lot of pairs in more recent Cog. So I think Gera is right.

Thanks,
Juan Vuletich

_______________________________________________
Cuis-dev mailing list
[hidden email]
http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org

Juan, Nicolas,

    which versions are broken?  I want to see the source for the broken version, and so I'd like to know the svn revision number for a broken version.  I'll take them off my site.  I'll build new VMs and upload some time this weekend.

On Thu, Apr 28, 2016 at 12:46 PM, Juan Vuletich <[hidden email]> wrote:

 

On 4/28/2016 4:39 PM, Nicolas Cellier via Cuis-dev wrote:

Moreover, as long as you write primitive: 110 in cog, you don't invoke primitive 110.

You rather invoke genPrimitiveIdentical.

Please try the snippet on a StackVM.

Sure. Can you provide a link to such VM? It should be based on VMMaker.oscog-eem.1370/r3386 or later, as the problem doesn't happen with any Cog older than that.

Thanks,
Juan Vuletich

genPrimitiveIdentical has been slightly refactored, but I see no obvious problem by just reading code.

Moreover, when you use Object = you'll also call same methods in the end...

This would deserve experimenting VMSimulator... (I don't have the Bochs plugin working now)

2016-04-28 21:21 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi Juan, then how do you explain:

"Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected."

2016-04-28 21:10 GMT+02:00 Juan Vuletich <[hidden email]>:

On 4/28/2016 2:13 PM, Phil (list) wrote:

On Thu, 2016-04-28 at 12:58 -0400, Phil (list) wrote:

On Thu, 2016-04-28 at 16:43 +0200, Clément Bera wrote:

  Have you tried on latest VM ? I remembered fixing a bug on #==
primitive like a month ago. The problem was when performing #==
primitive with the argument being a forwarder to an immediate.

The problem still existed as of Cog #3686 (Juan found the fix
yesterday.)  On my system, Cuis last worked perfectly with 3370,
mostly
worked with 3390, somewhat worked with 3427 and did not work after
that
until we found the Character>>#= bug/fix.

Just to clarify: the issue was experienced only when running on Cog...
current versions of the Stack VM performed as expected.

Fortunately I work with Gera Richarte @ Satellogic, and it didn't take long for him to suggest an explanation: Maybe prim 110 is broken in recent Cog VMs, but nobody notices it because the only sender is #== that is already optimized by the jitter, so prim 110 is never really called. And I realized we can test that theory. First, we add this method to Character:

=== aCharacter
<primitive: 110>
    self halt

Then the following snippet (in latest Cuis, #2744):

    0 to: 255 do: [ :i1 | 0 to: 255 do: [ :i2 | i1 = i2 ifFalse: [(Character value: i1) === (Character value: i2) ifTrue: [{i1.i2} print ]]]]

prints nothing if run with Cog 3370, but prints a lot of pairs in more recent Cog. So I think Gera is right.

Thanks,
Juan Vuletich

_______________________________________________
Cuis-dev mailing list
[hidden email]
http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org

--

_,,,^..^,,,_

best, Eliot