implicit type change

Hello,

I have a nasty problem using native call interface. I get an array of 
bytes from a call representing a pixel buffer. I am storing it in a 
CArray[byte]. Golfing it down it comes to the following (REPL)


 > use NativeCall
 > my CArray[byte] $ba .= new( 255, 254, 3, 4);
NativeCall::Types::CArray[byte].new
 > $ba[0].WHAT
(Int)
 > $ba[0..*-1]
(-1 -2 3 4)


This means (for me) that there is an implicit type conversion from 
unsigned to signed integer and it is not possible to use positive 
numbers only, afterwards.

Regards,
Marcel
0
mt1957
12/8/2019 7:01:50 PM
perl.perl6.users 1278 articles. 0 followers. Follow

5 Replies
15 Views

Similar Articles

[PageSpeed] 17

--000000000000d26f1c0599362839
Content-Type: text/plain; charset="UTF-8"

It looks like a bug: the docs (https://docs.raku.org/language/nativetypes)
specify that 'byte' and 'uint8' are the same and correspond to uint8_t in C.
Substituting 'uint8' to 'byte' in your code returns the same result.

Out of curiosity, if it is something meant for the public, what native call
interface are you working on?

On Sun, Dec 8, 2019 at 8:08 PM Marcel Timmerman <mt1957@gmail.com> wrote:

> Hello,
>
> I have a nasty problem using native call interface. I get an array of
> bytes from a call representing a pixel buffer. I am storing it in a
> CArray[byte]. Golfing it down it comes to the following (REPL)
>
>
>  > use NativeCall
>  > my CArray[byte] $ba .= new( 255, 254, 3, 4);
> NativeCall::Types::CArray[byte].new
>  > $ba[0].WHAT
> (Int)
>  > $ba[0..*-1]
> (-1 -2 3 4)
>
>
> This means (for me) that there is an implicit type conversion from
> unsigned to signed integer and it is not possible to use positive
> numbers only, afterwards.
>
> Regards,
> Marcel
>


-- 
Fernando Santagata

--000000000000d26f1c0599362839
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"color:#000000">It lo=
oks like a bug: the docs (<a href=3D"https://docs.raku.org/language/nativet=
ypes">https://docs.raku.org/language/nativetypes</a>) specify that &#39;byt=
e&#39; and &#39;uint8&#39; are the same and correspond to uint8_t in C.</di=
v><div class=3D"gmail_default" style=3D"color:#000000">Substituting &#39;ui=
nt8&#39; to &#39;byte&#39; in your code returns the same result.</div><div =
class=3D"gmail_default" style=3D"color:#000000"><br></div><div class=3D"gma=
il_default" style=3D"color:#000000">Out of curiosity, if it is something me=
ant for the public, what native call interface are you working on?<br></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sun, Dec 8, 2019 at 8:08 PM Marcel Timmerman &lt;<a href=3D"mailto:mt19=
57@gmail.com">mt1957@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">Hello,<br>
<br>
I have a nasty problem using native call interface. I get an array of <br>
bytes from a call representing a pixel buffer. I am storing it in a <br>
CArray[byte]. Golfing it down it comes to the following (REPL)<br>
<br>
<br>
=C2=A0&gt; use NativeCall<br>
=C2=A0&gt; my CArray[byte] $ba .=3D new( 255, 254, 3, 4);<br>
NativeCall::Types::CArray[byte].new<br>
=C2=A0&gt; $ba[0].WHAT<br>
(Int)<br>
=C2=A0&gt; $ba[0..*-1]<br>
(-1 -2 3 4)<br>
<br>
<br>
This means (for me) that there is an implicit type conversion from <br>
unsigned to signed integer and it is not possible to use positive <br>
numbers only, afterwards.<br>
<br>
Regards,<br>
Marcel<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature">Fernando Santagata</div>

--000000000000d26f1c0599362839--
0
nando
12/8/2019 7:19:24 PM
I hoped that:

  $ 6 'use NativeCall; dd my CArray[uint8] $ba .=3D new( 255, 254, 3, =
4); dd $ba[0..*-1]'
  CArray[uint8] $ba =3D NativeCall::Types::CArray[uint8].new
  (-1, -2, 3, 4).Seq

would be a solution (usint "uint8" rather than "byte"), but alas, no, so =
this feels like a bug

> On 8 Dec 2019, at 20:01, Marcel Timmerman <mt1957@gmail.com> wrote:
>=20
> Hello,
>=20
> I have a nasty problem using native call interface. I get an array of =
bytes from a call representing a pixel buffer. I am storing it in a =
CArray[byte]. Golfing it down it comes to the following (REPL)
>=20
>=20
> > use NativeCall
> > my CArray[byte] $ba .=3D new( 255, 254, 3, 4);
> NativeCall::Types::CArray[byte].new
> > $ba[0].WHAT
> (Int)
> > $ba[0..*-1]
> (-1 -2 3 4)
>=20
>=20
> This means (for me) that there is an implicit type conversion from =
unsigned to signed integer and it is not possible to use positive =
numbers only, afterwards.
>=20
> Regards,
> Marcel
0
liz
12/8/2019 7:25:14 PM
--------------8AB0E777AE398A35D051D12D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/8/19 8:19 PM, Fernando Santagata wrote:
> It looks like a bug: the docs 
> (https://docs.raku.org/language/nativetypes) specify that 'byte' and 
> 'uint8' are the same and correspond to uint8_t in C.
> Substituting 'uint8' to 'byte' in your code returns the same result.
>
> Out of curiosity, if it is something meant for the public, what native 
> call interface are you working on?
Hi Fernando,

I'm working on the Gnome GTK+ interface. I started this as a learning 
task for the native call interface but it is grown into a huge project. 
The packages are Gnome::N, Gnome::Glib, Gnome::GObject, Gnome::Gdk3, 
Gnome::Gtk3, Gnome::Gtk3::Glade and more to come.

>
> On Sun, Dec 8, 2019 at 8:08 PM Marcel Timmerman <mt1957@gmail.com 
> <mailto:mt1957@gmail.com>> wrote:
>
>     Hello,
>
>     I have a nasty problem using native call interface. I get an array of
>     bytes from a call representing a pixel buffer. I am storing it in a
>     CArray[byte]. Golfing it down it comes to the following (REPL)
>
>
>      > use NativeCall
>      > my CArray[byte] $ba .= new( 255, 254, 3, 4);
>     NativeCall::Types::CArray[byte].new
>      > $ba[0].WHAT
>     (Int)
>      > $ba[0..*-1]
>     (-1 -2 3 4)
>
>
>     This means (for me) that there is an implicit type conversion from
>     unsigned to signed integer and it is not possible to use positive
>     numbers only, afterwards.
>
>     Regards,
>     Marcel
>
>
>
> -- 
> Fernando Santagata


--------------8AB0E777AE398A35D051D12D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 12/8/19 8:19 PM, Fernando Santagata
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJ+jyGhUTNS4W-mbg6z2g=MFF_RWRxnpSOTs8Tse65KnwapzOg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_default" style="color:#000000">It looks like a
          bug: the docs (<a
            href="https://docs.raku.org/language/nativetypes"
            moz-do-not-send="true">https://docs.raku.org/language/nativetypes</a>)
          specify that 'byte' and 'uint8' are the same and correspond to
          uint8_t in C.</div>
        <div class="gmail_default" style="color:#000000">Substituting
          'uint8' to 'byte' in your code returns the same result.</div>
        <div class="gmail_default" style="color:#000000"><br>
        </div>
        <div class="gmail_default" style="color:#000000">Out of
          curiosity, if it is something meant for the public, what
          native call interface are you working on?<br>
        </div>
      </div>
    </blockquote>
    Hi Fernando,<br>
    <br>
    I'm working on the Gnome GTK+ interface. I started this as a
    learning task for the native call interface but it is grown into a
    huge project. The packages are Gnome::N, Gnome::Glib,
    Gnome::GObject, Gnome::Gdk3, Gnome::Gtk3, Gnome::Gtk3::Glade and
    more to come.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAJ+jyGhUTNS4W-mbg6z2g=MFF_RWRxnpSOTs8Tse65KnwapzOg@mail.gmail.com"><br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, Dec 8, 2019 at 8:08 PM
          Marcel Timmerman &lt;<a href="mailto:mt1957@gmail.com"
            moz-do-not-send="true">mt1957@gmail.com</a>&gt; 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">Hello,<br>
          <br>
          I have a nasty problem using native call interface. I get an
          array of <br>
          bytes from a call representing a pixel buffer. I am storing it
          in a <br>
          CArray[byte]. Golfing it down it comes to the following (REPL)<br>
          <br>
          <br>
           &gt; use NativeCall<br>
           &gt; my CArray[byte] $ba .= new( 255, 254, 3, 4);<br>
          NativeCall::Types::CArray[byte].new<br>
           &gt; $ba[0].WHAT<br>
          (Int)<br>
           &gt; $ba[0..*-1]<br>
          (-1 -2 3 4)<br>
          <br>
          <br>
          This means (for me) that there is an implicit type conversion
          from <br>
          unsigned to signed integer and it is not possible to use
          positive <br>
          numbers only, afterwards.<br>
          <br>
          Regards,<br>
          Marcel<br>
        </blockquote>
      </div>
      <br clear="all">
      <br>
      -- <br>
      <div dir="ltr" class="gmail_signature">Fernando Santagata</div>
    </blockquote>
    <br>
  </body>
</html>

--------------8AB0E777AE398A35D051D12D--
0
mt1957
12/8/2019 7:47:49 PM
Hi Elizabeth,

Shall I file a bug report then?

> I hoped that:
>
>    $ 6 'use NativeCall; dd my CArray[uint8] $ba .= new( 255, 254, 3, 4); dd $ba[0..*-1]'
>    CArray[uint8] $ba = NativeCall::Types::CArray[uint8].new
>    (-1, -2, 3, 4).Seq
>
> would be a solution (usint "uint8" rather than "byte"), but alas, no, so this feels like a bug
>
>> On 8 Dec 2019, at 20:01, Marcel Timmerman <mt1957@gmail.com> wrote:
>>
>> Hello,
>>
>> I have a nasty problem using native call interface. I get an array of bytes from a call representing a pixel buffer. I am storing it in a CArray[byte]. Golfing it down it comes to the following (REPL)
>>
>>
>>> use NativeCall
>>> my CArray[byte] $ba .= new( 255, 254, 3, 4);
>> NativeCall::Types::CArray[byte].new
>>> $ba[0].WHAT
>> (Int)
>>> $ba[0..*-1]
>> (-1 -2 3 4)
>>
>>
>> This means (for me) that there is an implicit type conversion from unsigned to signed integer and it is not possible to use positive numbers only, afterwards.
>>
>> Regards,
>> Marcel
0
mt1957
12/8/2019 7:48:50 PM
Yes, please.

> On 8 Dec 2019, at 20:48, Marcel Timmerman <mt1957@gmail.com> wrote:
>=20
> Hi Elizabeth,
>=20
> Shall I file a bug report then?
>=20
>> I hoped that:
>>=20
>>   $ 6 'use NativeCall; dd my CArray[uint8] $ba .=3D new( 255, 254, 3, =
4); dd $ba[0..*-1]'
>>   CArray[uint8] $ba =3D NativeCall::Types::CArray[uint8].new
>>   (-1, -2, 3, 4).Seq
>>=20
>> would be a solution (usint "uint8" rather than "byte"), but alas, no, =
so this feels like a bug
>>=20
>>> On 8 Dec 2019, at 20:01, Marcel Timmerman <mt1957@gmail.com> wrote:
>>>=20
>>> Hello,
>>>=20
>>> I have a nasty problem using native call interface. I get an array =
of bytes from a call representing a pixel buffer. I am storing it in a =
CArray[byte]. Golfing it down it comes to the following (REPL)
>>>=20
>>>=20
>>>> use NativeCall
>>>> my CArray[byte] $ba .=3D new( 255, 254, 3, 4);
>>> NativeCall::Types::CArray[byte].new
>>>> $ba[0].WHAT
>>> (Int)
>>>> $ba[0..*-1]
>>> (-1 -2 3 4)
>>>=20
>>>=20
>>> This means (for me) that there is an implicit type conversion from =
unsigned to signed integer and it is not possible to use positive =
numbers only, afterwards.
>>>=20
>>> Regards,
>>> Marcel
0
liz
12/8/2019 10:49:14 PM
Reply: