<div dir="ltr">Seeing this, I believe that bit was used for something else in sista and we agreed with Eliot 32k literals was enough? I cannot remember. <div>I think the bit meant Cogit should not generate profiling counter for the method or something like that.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 9, 2022 at 3:41 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div>Or just restrict EncoderForSistaV1>>#genPushCharacter:</div><div><br></div><div>...snip...</div><div>     (code < 0 or: [code > 16r7FFF]) ifTrue:<br>         [^self outOfRangeError: 'character' index: code range: 0 to: 16r7FFF].</div><div>...snip...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 14:16, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div id="gmail-m_-3109944182360237572gmail-m_5520665650860246595__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">

                                        Hi Nicolas --<div><br></div><div>Thanks! Also for the proposed workaround in VMMaker.oscog-nice.3174.</div><div><br></div><div>For what it's worth, one can always replace the character-literal syntax with string access:</div><div><br></div><div>$x.</div><div>'x' first.</div><div><br></div><div>Or store the code point if the optical appearance is not relevant:</div><div><br></div><div>Character value: 16r78. </div><div><br></div><div>Best,</div><div>Marcel</div><div></div>

                                        <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

                        <p style="color:rgb(170,170,170);margin-top:10px">Am 09.03.2022 10:02:46 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,

<br>yes, I agree, the bug is in bytecode encoding/decoding of immediate

<br>Character value,

<br>I stepped into (Compiler evaluate: (String with: $$ with: (Character value:

<br>16r8000))), and if we step into executeMethod, we can inspect what is going

on.

<br>

<br>

<br>Le mer. 9 mars 2022 à 08:39, Marcel Taeumel <u></u> a

<br>écrit :

<br>

<br>>

<br>> Hi Nicolas --

<br>>

<br>> There is a bug in the EncoderForSistaV1. The behavior is okay for

> EncoderForV3PlusClosures. We can discuss this on squeak-dev now, I suppose.

<br>>

> CompiledCode preferredBytecodeSetEncoderClass: EncoderForSistaV1.

> CompiledCode preferredBytecodeSetEncoderClass: EncoderForV3PlusClosures.

<br>>

<br>> If you do send #halt instead of #asInteger, you get another interesting

<br>> debugger when trying to start debugging:

<br>>

<br>>

<br>>

<br>> Best,

<br>> Marcel

<br>>

<br>> Am 09.03.2022 08:34:11 schrieb Nicolas Cellier <

<br>> <a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:

<br>> Ah OK, I see it on macos too

> It remains to determine which operation exactly is involved...

<br>> The TextMorph holding the printed result is correct - a WideString, whose

> last Character is (Character value: 32768).

<br>>

<br>> Le mer. 9 mars 2022 à 08:08, Marcel Taeumel a

<br>> écrit :

<br>>

<br>> >

<br>> > Hi Dave, hi Nicolas --

<br>> >

<br>> > I am working in Windows 10.

<br>> >

<br>> > > I cannot reproduce on Linux 64 bit either:

<br>> > > (Character value: 16r8000) asInteger hex ==> '16r8000'

<br>> >

<br>> > That's not how you would reproduce it. The bug affects character

<br>> literals,

<br>> > not character objects/instances. You have to evaluate code on that

<br>> > character literal.

<br>> >

<br>> > Maybe this picture helps:

<br>> >

<br>> >

<br>> >

<br>> > Best,

<br>> > Marcel

<br>> >

<br>> > Am 08.03.2022 18:56:09 schrieb David T. Lewis :

<br>> >

<br>> > I cannot reproduce on Linux 64 bit either:

<br>> >

<br>> > (Character value: 16r8000) asInteger hex ==> '16r8000'

<br>> >

<br>> > Dave

<br>> >

<br>> >

<br>> > On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:

<br>> > >

<br>> > > Hi Marcel,

<br>> > > which OS ?

<br>> > > I cannot reproduce on macos 64,

<br>> > >

<br>> > > Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]

<br>> > > 5.20211023.2003

<br>> > > Mac OS X built on Mar 6 2022 15:31:16 CET Compiler: 4.2.1 Compatible

<br>> > Apple

<br>> > > LLVM 10.0.1 (clang-1001.0.46.4)

<br>> > > platform sources revision VM: 202110232003

<br>> > >

<br>> > > Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel a

<br>> > > ??crit :

<br>> > >

<br>> > > >

<br>> > > > Hi Eliot, hi all --

<br>> > > >

<br>> > > > I think we have an sign-bit bug for character literals with code

<br>> > points >

<br>> > > > 16r7FFF.

<br>> > > >

<br>> > > > Steps to reproduce:

<br>> > > >

<br>> > > > 1. Print it: "Character value: 16r8000"

<br>> > > > 2. Inspect the result by evaluating the character literal or send

<br>> > > > #asInteger to it. It will most likely not render in a standard

<br>> Squeak

<br>> > and

<br>> > > > show up like "$? asInteger".

<br>> > > >

<br>> > > > In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.

<br>> > > > In a 64-bit VM, I will get the (negative) integer value '-16r8000'.

<br>> > > >

<br>> > > > Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In

<br>> > 64-bit,

<br>> > > > this means a negative number. Not sure about bits 30 and 31 here.

<br>> > > >

> > > > Is there a bug in the upper tag bits of immediate characters?

> > > > Is this related to the 2-byte or 3-byte byte codes in SistaV1?

<br>> > > >

<br>> > > > Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine

<br>> was

<br>> > 0

<br>> > > > in this experiment.)

<br>> > > >

<br>> > > > VM: 202112201228 (VMMaker.oscog-eem.3116)

<br>> > > >

<br>> > > > Best,

<br>> > > > Marcel

<br>> > > >

<br>> >

<br>> >

<br>> Ah OK, I see it on macos too

> It remains to determine which operation exactly is involved...

<br>> The TextMorph holding the printed result is correct - a WideString, whose

> last Character is (Character value: 32768).

<br>>

<br>> Le mer. 9 mars 2022 à 08:08, Marcel Taeumel <u></u> a

<br>> écrit :

<br>>

<br>>>

<br>>>

<br>>> Hi Dave, hi Nicolas --

<br>>>

>> I am working in Windows 10.

<br>>>

<br>>> > I cannot reproduce on Linux 64 bit either:

<br>>> > (Character value: 16r8000) asInteger hex ==> '16r8000'

<br>>>

<br>>> That's not how you would reproduce it. The bug affects character

<br>>> literals, not character objects/instances. You have to evaluate code on

>> that character literal.

<br>>>

<br>>> Maybe this picture helps:

<br>>>

<br>>>

<br>>>

<br>>> Best,

<br>>> Marcel

<br>>>

<br>>>

<br>>> Am 08.03.2022 18:56:09 schrieb David T. Lewis <u></u>:

<br>>>

<br>>> I cannot reproduce on Linux 64 bit either:

<br>>>

<br>>> (Character value: 16r8000) asInteger hex ==> '16r8000'

<br>>>

<br>>> Dave

<br>>>

<br>>>

<br>>> On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:

<br>>> >

<br>>> > Hi Marcel,

<br>>> > which OS ?

<br>>> > I cannot reproduce on macos 64,

<br>>> >

<br>>> > Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]

<br>>> > 5.20211023.2003

<br>>> > Mac OS X built on Mar 6 2022 15:31:16 CET Compiler: 4.2.1 Compatible

<br>>> Apple

<br>>> > LLVM 10.0.1 (clang-1001.0.46.4)

<br>>> > platform sources revision VM: 202110232003

<br>>> >

<br>>> > Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel a

<br>>> > ??crit :

<br>>> >

<br>>> > >

<br>>> > > Hi Eliot, hi all --

<br>>> > >

<br>>> > > I think we have an sign-bit bug for character literals with code

<br>>> points >

<br>>> > > 16r7FFF.

<br>>> > >

<br>>> > > Steps to reproduce:

<br>>> > >

<br>>> > > 1. Print it: "Character value: 16r8000"

<br>>> > > 2. Inspect the result by evaluating the character literal or send

<br>>> > > #asInteger to it. It will most likely not render in a standard Squeak

<br>>> and

<br>>> > > show up like "$? asInteger".

<br>>> > >

<br>>> > > In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.

<br>>> > > In a 64-bit VM, I will get the (negative) integer value '-16r8000'.

<br>>> > >

<br>>> > > Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In

<br>>> 64-bit,

<br>>> > > this means a negative number. Not sure about bits 30 and 31 here.

<br>>> > >

>> > > Is there a bug in the upper tag bits of immediate characters?

>> > > Is this related to the 2-byte or 3-byte byte codes in SistaV1?

<br>>> > >

<br>>> > > Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine

<br>>> was 0

<br>>> > > in this experiment.)

<br>>> > >

<br>>> > > VM: 202112201228 (VMMaker.oscog-eem.3116)

<br>>> > >

<br>>> > > Best,

<br>>> > > Marcel

<br>>> > >

<br>>>

<br>>>

<br>>

<br><div dir="ltr"><div>Hi Marcel,</div><div>yes, I agree, the bug is in bytecode encoding/decoding of immediate Character value,</div><div>I stepped into (Compiler evaluate: (String with: $$ with: (Character value: 16r8000))), and if we step into executeMethod, we can inspect what is going on.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 08:39, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;min-width:500px"> <div id="gmail-m_-3109944182360237572gmail-m_5520665650860246595gmail-m_398136198968824617__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">

<br>                                        Hi Nicolas --<div></div>

<br>                                        <div><br></div><div>There is a bug in the EncoderForSistaV1. The behavior is okay for EncoderForV3PlusClosures. We can discuss this on squeak-dev now, I suppose.</div><div><br></div><div><span style="font-size:13.3333px">CompiledCode preferredBytecodeSetEncoderClass: EncoderForSistaV1.</span><br></div><div><span style="font-size:10pt">CompiledCode preferredBytecodeSetEncoderClass: EncoderForV3PlusClosures.</span><br></div><div><span style="font-size:10pt"><br></span></div><div><span style="font-size:10pt">If you do send #halt instead of #asInteger, you get another interesting debugger when trying to start debugging:</span></div><div><span style="font-size:10pt"><br></span></div><div><img id="gmail-m_-3109944182360237572gmail-m_5520665650860246595gmail-m_3981361989688246173c61bc55-a92f-4109-bcc8-131cff5f8428" src="cid:17f6f1ed7dbcb971f162" width="318" height="215"><br></div><div><span style="font-size:10pt"><br></span></div><div><span style="font-size:10pt">Best,</span></div><div><span style="font-size:10pt">Marcel</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

<br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 09.03.2022 08:34:11 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Ah OK, I see it on macos too

It remains to determine which operation exactly is involved...

<br><br>The TextMorph holding the printed result is correct - a WideString, whose

last Character is (Character value: 32768).

<br><br>

<br><br>Le mer. 9 mars 2022 à 08:08, Marcel Taeumel <u></u> a

<br><br>écrit :

<br><br>

<br><br>>

<br><br>> Hi Dave, hi Nicolas --

<br><br>>

> I am working in Windows 10.

<br><br>>

<br><br>> > I cannot reproduce on Linux 64 bit either:

<br><br>> > (Character value: 16r8000) asInteger hex ==> '16r8000'

<br><br>>

<br><br>> That's not how you would reproduce it. The bug affects character literals,

<br><br>> not character objects/instances. You have to evaluate code on that

<br><br>> character literal.

<br><br>>

<br><br>> Maybe this picture helps:

<br><br>>

<br><br>>

<br><br>>

<br><br>> Best,

<br><br>> Marcel

<br><br>>

<br><br>> Am 08.03.2022 18:56:09 schrieb David T. Lewis <u></u>:

<br><br>>

<br><br>> I cannot reproduce on Linux 64 bit either:

<br><br>>

<br><br>> (Character value: 16r8000) asInteger hex ==> '16r8000'

<br><br>>

<br><br>> Dave

<br><br>>

<br><br>>

<br><br>> On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:

<br><br>> >

<br><br>> > Hi Marcel,

<br><br>> > which OS ?

<br><br>> > I cannot reproduce on macos 64,

<br><br>> >

<br><br>> > Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]

<br><br>> > 5.20211023.2003

<br><br>> > Mac OS X built on Mar 6 2022 15:31:16 CET Compiler: 4.2.1 Compatible

<br><br>> Apple

<br><br>> > LLVM 10.0.1 (clang-1001.0.46.4)

<br><br>> > platform sources revision VM: 202110232003

<br><br>> >

<br><br>> > Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel a

<br><br>> > ??crit :

<br><br>> >

<br><br>> > >

<br><br>> > > Hi Eliot, hi all --

<br><br>> > >

<br><br>> > > I think we have an sign-bit bug for character literals with code

<br><br>> points >

<br><br>> > > 16r7FFF.

<br><br>> > >

<br><br>> > > Steps to reproduce:

<br><br>> > >

<br><br>> > > 1. Print it: "Character value: 16r8000"

<br><br>> > > 2. Inspect the result by evaluating the character literal or send

<br><br>> > > #asInteger to it. It will most likely not render in a standard Squeak

<br><br>> and

<br><br>> > > show up like "$? asInteger".

<br><br>> > >

<br><br>> > > In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.

<br><br>> > > In a 64-bit VM, I will get the (negative) integer value '-16r8000'.

<br><br>> > >

<br><br>> > > Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In

<br><br>> 64-bit,

<br><br>> > > this means a negative number. Not sure about bits 30 and 31 here.

<br><br>> > >

> > > Is there a bug in the upper tag bits of immediate characters?

> > > Is this related to the 2-byte or 3-byte byte codes in SistaV1?

<br><br>> > >

<br><br>> > > Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was

<br><br>> 0

<br><br>> > > in this experiment.)

<br><br>> > >

<br><br>> > > VM: 202112201228 (VMMaker.oscog-eem.3116)

<br><br>> > >

<br><br>> > > Best,

<br><br>> > > Marcel

<br><br>> > >

<br><br>>

<br><br>>

<br><br><div dir="ltr"><div>Ah OK, I see it on macos too<br></div><div>It remains to determine which operation exactly is involved...</div><div>The TextMorph holding the printed result is correct - a WideString, whose last Character is (Character value: 32768).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 08:08, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;min-width:500px"> <div id="gmail-m_-3109944182360237572gmail-m_5520665650860246595gmail-m_398136198968824617gmail-m_-7160874889616242553__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">

<br><br>                                        Hi Dave, hi Nicolas --<div><br></div><div>I am working in Windows 10.</div><div><br></div><div>> <span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">I cannot reproduce on Linux 64 bit either:</span></div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> (Character value: 16r8000) asInteger hex ==> '16r8000'</span><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">That's not how you would reproduce it. The bug affects character literals, not character objects/instances. You have to evaluate code on that character literal.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Maybe this picture helps:</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><img id="gmail-m_-3109944182360237572gmail-m_5520665650860246595gmail-m_398136198968824617gmail-m_-7160874889616242553377a17ac-9eaa-478e-b331-79d809eb830e" src="cid:17f6f1ed7dacb971f161" width="343" height="114"><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><br></div><div>Best,</div><div>Marcel</div><div></div>

<br><br>                                        <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

<br><br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 08.03.2022 18:56:09 schrieb David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br>I cannot reproduce on Linux 64 bit either:<br><br>  (Character value: 16r8000) asInteger hex ==> '16r8000' <br><br>Dave<br><br><br>On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:<br>>  <br>> Hi Marcel,<br>> which OS ?<br>> I cannot reproduce on macos 64,<br>> <br>> Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]<br>> 5.20211023.2003<br>> Mac OS X built on Mar  6 2022 15:31:16 CET Compiler: 4.2.1 Compatible Apple<br>> LLVM 10.0.1 (clang-1001.0.46.4)<br>> platform sources revision VM: 202110232003<br>> <br>> Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel <u></u> a<br>> ??crit :<br>> <br>> ><br>> > Hi Eliot, hi all --<br>> ><br>> > I think we have an sign-bit bug for character literals with code points ><br>> > 16r7FFF.<br>> ><br>> > Steps to reproduce:<br>> ><br>> > 1. Print it: "Character value: 16r8000"<br>> > 2. Inspect the result by evaluating the character literal or send<br>> > #asInteger to it. It will most likely not render in a standard Squeak and<br>> > show up like "$? asInteger".<br>> ><br>> > In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.<br>> > In a 64-bit VM, I will get the (negative) integer value '-16r8000'.<br>> ><br>> > Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In 64-bit,<br>> > this means a negative number. Not sure about bits 30 and 31 here.<br>> ><br>> > Is there a bug in the upper tag bits of immediate characters?<br>> > Is this related to the 2-byte or 3-byte byte codes in SistaV1?<br>> ><br>> > Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was 0<br>> > in this experiment.)<br>> ><br>> > VM: 202112201228 (VMMaker.oscog-eem.3116)<br>> ><br>> > Best,<br>> > Marcel<br>> ><br><br><u></u></div></blockquote></div></blockquote></div>

<br><br><u></u><u></u></div></blockquote></div></blockquote></div>

<br><u></u><u></u><u></u></div></blockquote></div></blockquote></div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div>