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
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.
On Thu, Apr 28, 2016 at 3:13 PM, Juan Vuletich JuanVuletich@zoho.com wrote:
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 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.
On Thu, Apr 28, 2016 at 3:13 PM, Juan Vuletich <JuanVuletich@zoho.com
wrote:
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://g ithub.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 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.
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 JuanVuletich@zoho.com:
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
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.
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 < nicolas.cellier.aka.nice@gmail.com>:
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 JuanVuletich@zoho.com:
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 <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com>:
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 <JuanVuletich@zoho.com <mailto:JuanVuletich@zoho.com>>: 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 Cuis-dev@cuis-smalltalk.org http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org
I can reproduce the problem with same snippet on a Squeak 4.6 image with squeak.cog.v3. The snippet works well with squeak.stack.v3.
2016-04-28 21:46 GMT+02:00 Juan Vuletich JuanVuletich@zoho.com:
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 < nicolas.cellier.aka.nice@gmail.com>:
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 JuanVuletich@zoho.com:
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 listCuis-dev@cuis-smalltalk.orghttp://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 JuanVuletich@zoho.com 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 < nicolas.cellier.aka.nice@gmail.com>:
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 JuanVuletich@zoho.com:
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 listCuis-dev@cuis-smalltalk.orghttp://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org
Um, ignore that last message. I see the problem staring me in the face. Thanks for the fix, Nicolas.
On Sat, Apr 30, 2016 at 9:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Juan, Nicolas,
which versions are broken? I want to see the source for the brokenversion, 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 JuanVuletich@zoho.com 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 < nicolas.cellier.aka.nice@gmail.com>:
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 JuanVuletich@zoho.com:
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 listCuis-dev@cuis-smalltalk.orghttp://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org
-- _,,,^..^,,,_ best, Eliot
Thanks you all Folks.
Cheers, Juan Vuletich
On 4/30/2016 1:51 PM, Eliot Miranda wrote:
Um, ignore that last message. I see the problem staring me in the face. Thanks for the fix, Nicolas.
On Sat, Apr 30, 2016 at 9:49 AM, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> wrote:
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 <JuanVuletich@zoho.com <mailto:JuanVuletich@zoho.com>> 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 VuletichgenPrimitiveIdentical 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 <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: 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 <JuanVuletich@zoho.com <mailto:JuanVuletich@zoho.com>>: 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 Cuis-dev@cuis-smalltalk.org <mailto:Cuis-dev@cuis-smalltalk.org> http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org-- _,,,^..^,,,_ best, Eliot-- _,,,^..^,,,_ best, Eliot
Hi Nicolas,
on a point of terminology...
On Apr 28, 2016, at 12:39 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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.
Yes, one /does/ invoke primitive 110; that's what the primitive pragma specifies. But the VM doesn't necessarily invoke the primitiveIdentical implementation of primitive 110 in the interpreter and will very likely invoke code generated by genPrimitiveIdentical.
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 nicolas.cellier.aka.nice@gmail.com:
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 JuanVuletich@zoho.com:
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 Nicolas,
On 4/28/2016 4:21 PM, Nicolas Cellier wrote:
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."
More precisely, we never experienced such problems with InterpreterVMs built from VMMaker (for example http://www.squeakvm.org/win32/release/Squeak4.10.2-2612.win32-i386.zip ), and we experienced them with Cog newer than #3370, built from VMMaker-oscog, from Eliot's site. I guess code for prim 110 has diverged between both branches.
Thanks, Juan Vuletich
2016-04-28 21:10 GMT+02:00 Juan Vuletich <JuanVuletich@zoho.com mailto:JuanVuletich@zoho.com>:
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
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Eliot Miranda -
Juan Vuletich -
Nicolas Cellier -
Phil (list)