Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-30 17:20, Veesh Goldman wrote:

Hi Todd,
A couple of things.
One is that Int and int are totally unrelated concepts. Captial Int is a 
high level concept, which has a type constraint related to it, and 
belongs to raku's object system. Lowercase int is a special case, it's 
only for the interface with C, and it represents a low level piece of 
memory. It's not that one is bounded and the other has Larry magic 
sprinkled on it (even though it happens to have that), they're totally 
conceptually different.


Raku doesn't actually know what resides in the C space, because int 
doesn't really talk to raku, so in order to do something meaningful with 
that memory, you need to make sure it's dealt with in the right context. 
What I mean to say is that raku won't stop you from assigning negative 
numbers to an unsigned int, b/c it doesn't belong in the Object system. 
It just defines a way to send raku values down into C-world (which, 
despite the name, is not a pleasant place).


When you try to use a native variable like a raku variable, you have 2 
choices. Either raku would blow up in your face and die (probably not 
what you want), or raku would wrap the variable in something it 
understands (autoboxing, as explained above). If you want to get a more 
specific wrapper, nothing is stopping you from implementing that 
yourself. In fact, someone posted earlier in this thread an 
implementation where you wrap your native uints in an object which would 
point to the specific type you want.


I believe the issue that you're having with the array is also because of 
autoboxing. Observe the following code:

use NativeCall
my $ary = CArray.new( 0xff );
say $ary[0];
#  -1
multi sub check-it (uint8 $i) { say 'uint8' }
multi sub check-it(Int $i) { say 'Int' }
check-it $ary[0]
# uint8
That proves that raku KNOWs that it's a uint8, just many operations will 
autobox it. Perhaps we need some more clarity about autoboxing rules.


What is further interesting, which was a point I think you were making, 
is if we add another multi:

multi sub check-it (int8 $i) { say 'int8' }
check-it $ary[0];
# Ambiguous call to 'check-it(Int)'; these signatures all match:
# :(uint8 $i)
# :(int8 $i)

So this may actually indicate that raku does not actually know it's a 
uint8, it just knows that it's supposed to be 8 bits long. This is what 
I've got, but I think the point here is that int represents memory, and 
Int is an object, and they're two totally distinct concepts so what 
applies to one is irrelevant to the other.


Hope this helps,
Veesh


Hi Veesh,

I adored the letter.  It was extremely well written and very
easy to follow.

Your explanation of bounding was the first time I actually
understood what was actually happening with bounding:
"liberate from C ..." and manipulate it in Raku-World.

I had previously been told I did not understand C Pointers,
which I though was rather odd as that is one of the few
things about C that I actually understand.  I had no idea
where they were coming from.

I wrote myself a little program to demonstrate
what I learned:


#!/usr/bin/env perl6
use NativeCall;
constant BYTE := uint8;
constant BYTES:= CArray[BYTE];
my BYTES  $u = CArray[BYTE].new( 0xFF, 0x7f );

say"u[0] base 10 boxed to Int <", $u[0], ">";
say"u[0] ^name after boxing   <", $u[0].^name, ">";
printf "u[0] OR  0x00 base 2  <%08s>\n", ($u[0] +& 0xFF).base(2);
say"u[0] OR 0x00 base 10  <", ($u[0] +| 0x00).base(10), ">";
say"u[0] OR 0x00 base 16  <", ($u[0] +| 0x00).base(16);
printf "(u[0] +3) +| 0x00)<%08s>\n", (($u[0] +3) +| 0x00).base(2);


$ intTest.pl6
u[0] base 10 boxed to Int <-1>
u[0] ^name after boxing   
u[0] OR 0x00 base 2   <>
u[0] OR 0x00 base 10  <255>
u[0] OR 0x00 base 16  
u[0] OR  0x00 base 2 +3   <0010>

Going over it

$u[0] base 10 boxed to Int <-1>

shows that $u[0] got unbounded into Raku-World
for operation on it as an Int.  The "-1" is
because in the unbounding processed the cardinal
number inside $u[0]'s high bit as a sign bit, even
though $u[0] is an unsigned integer.

It would be nice if it unbounded to a UInt as
both are unsigned integers.  But Int also
works, you just have to be wary of the upper
bit in the uint being interpreted as a sign bit:
use "-1" in place of 0xFF, etc..

   $u[0] ^name after boxing   

Show that $u[0] was being operating on AFTER
it was unbounded and that the reason why ^name
gets a participation trophy is because it is
returning the name of the C-World liberated
variable, not the raw variable.

There is a trail back to the raw variable or
the variable could not be unbonded, but ^name is
not cleaver enough to follow the trail.  You
just have to be aware of ^name's limitation and
be glad it return a variable that is similar.
I can live with it.

   $u[0] OR 0x00 base 2   <>
   $u[0] OR 0x00 base 10  <255>
   $u[0] OR 0x00 base 16  

Show the actual bit value of $u[0].  AND
that the actu

Re: stolen uint's

[Veesh Goldman]

Hi Todd,
A couple of things.
One is that Int and int are totally unrelated concepts. Captial Int is a
high level concept, which has a type constraint related to it, and belongs
to raku's object system. Lowercase int is a special case, it's only for the
interface with C, and it represents a low level piece of memory. It's not
that one is bounded and the other has Larry magic sprinkled on it (even
though it happens to have that), they're totally conceptually different.

Raku doesn't actually know what resides in the C space, because int doesn't
really talk to raku, so in order to do something meaningful with that
memory, you need to make sure it's dealt with in the right context. What I
mean to say is that raku won't stop you from assigning negative numbers to
an unsigned int, b/c it doesn't belong in the Object system. It just
defines a way to send raku values down into C-world (which, despite the
name, is not a pleasant place).

When you try to use a native variable like a raku variable, you have 2
choices. Either raku would blow up in your face and die (probably not what
you want), or raku would wrap the variable in something it understands
(autoboxing, as explained above). If you want to get a more specific
wrapper, nothing is stopping you from implementing that yourself. In fact,
someone posted earlier in this thread an implementation where you wrap your
native uints in an object which would point to the specific type you want.

I believe the issue that you're having with the array is also because of
autoboxing. Observe the following code:
use NativeCall
my $ary = CArray.new( 0xff );
say $ary[0];
#  -1
multi sub check-it (uint8 $i) { say 'uint8' }
multi sub check-it(Int $i) { say 'Int' }
check-it $ary[0]
# uint8
That proves that raku KNOWs that it's a uint8, just many operations will
autobox it. Perhaps we need some more clarity about autoboxing rules.

What is further interesting, which was a point I think you were making, is
if we add another multi:
multi sub check-it (int8 $i) { say 'int8' }
check-it $ary[0];
# Ambiguous call to 'check-it(Int)'; these signatures all match:
# :(uint8 $i)
# :(int8 $i)

So this may actually indicate that raku does not actually know it's a
uint8, it just knows that it's supposed to be 8 bits long. This is what
I've got, but I think the point here is that int represents memory, and Int
is an object, and they're two totally distinct concepts so what applies to
one is irrelevant to the other.

Hope this helps,
Veesh

On Thu, Jan 30, 2020 at 9:56 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-30 08:11, Andy Bach wrote:
> >>> I’m STILL waiting  for you to show me ONE example of a `uint` turning
> >>> into `int`.  Not `Int`, via auto-boxing, `int`, via who-knows-what.
> >
> > $ p6 'my uint8 $u; say $u.^name;'
> > Int
> >
> > Did you not notice the capital "I" in both his request and your code
> output?
>
> Hi Andy,
>
>
> Oh I did.  It was just a bad example.
>
> And as far as the Int thing goes, to figure that out,
> the structure of the variable had to be queried,
> so there is a trail back to the actual type of
> of variable.  In other words, it should have
> given the correct answer as to what the variable
> was declared as.  So no excuses.
>
> Raku variables all come with structures, so
> no excuses for ^name saying a banana is a rabbit.
> The structure is were ^name queried to get
> the Int.
>
> My opinion, ^name should be dropped if it is
> not going to give back the actually type of the
> variable.
>
> I posted a better example showing where a
> declared uint8 was being treated as a int8:
> suddenly, 0xFF became -1.
>
> -T
>

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-30 08:11, Andy Bach wrote:

I’m STILL waiting  for you to show me ONE example of a `uint` turning
into `int`.  Not `Int`, via auto-boxing, `int`, via who-knows-what.


$ p6 'my uint8 $u; say $u.^name;'
Int

Did you not notice the capital "I" in both his request and your code output?


Hi Andy,


Oh I did.  It was just a bad example.

And as far as the Int thing goes, to figure that out,
the structure of the variable had to be queried,
so there is a trail back to the actual type of
of variable.  In other words, it should have
given the correct answer as to what the variable
was declared as.  So no excuses.

Raku variables all come with structures, so
no excuses for ^name saying a banana is a rabbit.
The structure is were ^name queried to get
the Int.

My opinion, ^name should be dropped if it is
not going to give back the actually type of the
variable.

I posted a better example showing where a
declared uint8 was being treated as a int8:
suddenly, 0xFF became -1.

-T

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 17:45, Trey Harris wrote:



On Wed, Jan 29, 2020 at 20:20 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-29 10:28, Trey Harris wrote:
 > B is not a subset of A. That is the relationship of uint and int—two
 > distinct types whose values happen to overlap in a way that
describes a
 > subset. Perl isn’t Prolog; a logical relationship between two
types is
 > not a first-class entity of the language.
 >
 >
 >
 >     I know, I am slicing the baloney thin here, but uint is
 >     not a static C variable. It can change into an int with
 >     the position of the moon.
 >
 >
 > I’m STILL waiting for you to show me ONE example of a `uint` turning
 > into `int`. Not `Int`, via auto-boxing, `int`, via who-knows-what.
 > Either do that, or stop making the assertion it does that; if you
don’t
 > show a reproducible example, I am going to conclude you are lying
if you
 > persist.

$ p6 'my uint8 $u; say $u.^name;'
Int

I’m done. I haven’t killfiled anyone in over twenty years. 
Congratulations, you’re the first this century.




#!/usr/bin/env perl6

use NativeCall;

constant BYTE := uint8;
constant BYTES:= CArray[BYTE];

my BYTES  $lpBuffer = CArray[BYTE].new( 0xFF xx 4 );

if$lpBuffer[0] == -1   { say "$lpBuffer[0] acts like an integer"; }
elsif $lpBuffer[0] == 0xFF { say "$lpBuffer[0] acts like an unsigned 
integer"; }

else   { say $lpBuffer[0], " unknown"; }


-1 acts like an integer

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 20:20 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 10:28, Trey Harris wrote:
> > B is not a subset of A. That is the relationship of uint and int—two
> > distinct types whose values happen to overlap in a way that describes a
> > subset. Perl isn’t Prolog; a logical relationship between two types is
> > not a first-class entity of the language.
> >
> >
> >
> > I know, I am slicing the baloney thin here, but uint is
> > not a static C variable. It can change into an int with
> > the position of the moon.
> >
> >
> > I’m STILL waiting for you to show me ONE example of a `uint` turning
> > into `int`. Not `Int`, via auto-boxing, `int`, via who-knows-what.
> > Either do that, or stop making the assertion it does that; if you don’t
> > show a reproducible example, I am going to conclude you are lying if you
> > persist.
>
> $ p6 'my uint8 $u; say $u.^name;'
> Int
>
I’m done. I haven’t killfiled anyone in over twenty years. Congratulations,
you’re the first this century.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 10:28, Trey Harris wrote:
B is not a subset of A. That is the relationship of uint and int—two 
distinct types whose values happen to overlap in a way that describes a 
subset. Perl isn’t Prolog; a logical relationship between two types is 
not a first-class entity of the language.




I know, I am slicing the baloney thin here, but uint is
not a static C variable. It can change into an int with
the position of the moon.


I’m STILL waiting for you to show me ONE example of a `uint` turning 
into `int`. Not `Int`, via auto-boxing, `int`, via who-knows-what. 
Either do that, or stop making the assertion it does that; if you don’t 
show a reproducible example, I am going to conclude you are lying if you 
persist.


$ p6 'my uint8 $u; say $u.^name;'
Int

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:50, ToddAndMargo via perl6-users wrote:

This all came up when I tried to match

   RegSetValueExW(
_In_ HKEY hKey,
_In_opt_ LPCWSTR lpValueName,
_Reserved_ DWORD Reserved,
_In_ DWORD dwType,
_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
_In_ DWORD cbData

where CbData can either be a UTF little endian C string,


typo.  That should have been lpData, not cbData


terminated by a nul or a four byte little endian
unsigned integer (no two's complement allowed) depending
on the value of lpValueName (REG_SZ, REG_DWORD, etc.)



--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 16:00, Trey Harris wrote:

where CbData can either be a UTF little endian C string,



I understand now.

I typo'ed cbData.  That should have been lpData.

:'(

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 18:39 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 15:32, ToddAndMargo via perl6-users wrote:
> > `DWORD cbData`
>
> cbData is a 32 bit unsigned integer.  It follows
> all the rules for unsigned integers.  You do not
> terminate it.  WinAPI knows it is 32 bits long.
>
> lpData (Long Pointer Data) is where you put the
> 0x at the end, if you are using it as a string.
> lpData is an array of bytes of your chosen length.
>

 You keep telling me about fields I’m not asking about.

Let me quote you to you, from
:

> This all came up when I tried to match
>
>RegSetValueExW(
>_In_ HKEY hKey,
>_In_opt_ LPCWSTR lpValueName,
>_Reserved_ DWORD Reserved,
>_In_ DWORD dwType,
>_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
>_In_ DWORD cbData
>
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

I would like to know about “where CbData can either be a UTF little endian
C string, terminated by a nul or a four byte little endian unsigned integer
(no two's complement allowed) depending on the value of lpValueName
(REG_SZ, REG_DWORD, etc.)”. That is what I and others find so bizarre. That
doesn’t seem to need reference to anything except cbData and lpValueName.

I’m just curious about this thing that can (again, quoting you) be “EITHER”
a UTF string ”OR a four byte little endian unsigned integer (no two’s
complement allowed)”. Tell me about that please. Just that.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 15:32, ToddAndMargo via perl6-users wrote:

`DWORD cbData`


cbData is a 32 bit unsigned integer.  It follows
all the rules for unsigned integers.  You do not
terminate it.  WinAPI knows it is 32 bits long.

lpData (Long Pointer Data) is where you put the
0x at the end, if you are using it as a string.
lpData is an array of bytes of your chosen length.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 15:22, Trey Harris wrote:



On Wed, Jan 29, 2020 at 17:52 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-29 14:20, Trey Harris wrote:
 > I don’t care about IpData or ValueData—those are completely
unremarkable
 > fields. Showing me more code relating to them—or any other fields
 > besides cData—isn’t helpful to understanding how the 3-bytes UTF
+ null
 > cData field works.

hi Trey,

I think what I am missing is your "3-bytes UTF + null" question.

It is only four bytes long when addressed as a REG_DWORD
(32 bit unsigned integer).  There is no nul at the end.

The bounds are 0x0..0x_.  No boxing allowed

$cbData = 4;


If your are addressing is as a REG_SZ (registry string),
it can be as many bytes as you want when.  You just have
to terminate it with a 0x

$cbData = $lpData.elems * 2;  # words are two bytes long

Does that help?


Could you show the API definition again, please? The copy I see says 
that field is a `DWORD cbData`. I don’t see the “as many bytes as you 
want when. You just have to terminate it with a 0x” part of the 
definition. Could you highlight it?



https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

   lpData

   The data to be stored.

   For string-based types, such as REG_SZ, the string must
   be null-terminated.

   cbData

   The size of the information pointed to by the lpData
   parameter, in bytes. If the data is of type REG_SZ,
   REG_EXPAND_SZ, or REG_MULTI_SZ, cbData must include
   the size of the terminating null character or
   characters.

Any better?

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 17:52 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 14:20, Trey Harris wrote:
> > I don’t care about IpData or ValueData—those are completely unremarkable
> > fields. Showing me more code relating to them—or any other fields
> > besides cData—isn’t helpful to understanding how the 3-bytes UTF + null
> > cData field works.
>
> hi Trey,
>
> I think what I am missing is your "3-bytes UTF + null" question.
>
> It is only four bytes long when addressed as a REG_DWORD
> (32 bit unsigned integer).  There is no nul at the end.
>
> The bounds are 0x0..0x_.  No boxing allowed
>
> $cbData = 4;
>
>
> If your are addressing is as a REG_SZ (registry string),
> it can be as many bytes as you want when.  You just have
> to terminate it with a 0x
>
> $cbData = $lpData.elems * 2;  # words are two bytes long
>
> Does that help?


Could you show the API definition again, please? The copy I see says that
field is a `DWORD cbData`. I don’t see the “as many bytes as you want when.
You just have to terminate it with a 0x” part of the definition. Could
you highlight it?

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 14:20, Trey Harris wrote:
I don’t care about IpData or ValueData—those are completely unremarkable 
fields. Showing me more code relating to them—or any other fields 
besides cData—isn’t helpful to understanding how the 3-bytes UTF + null 
cData field works.


hi Trey,

I think what I am missing is your "3-bytes UTF + null" question.

It is only four bytes long when addressed as a REG_DWORD
(32 bit unsigned integer).  There is no nul at the end.

The bounds are 0x0..0x_.  No boxing allowed

$cbData = 4;


If your are addressing is as a REG_SZ (registry string),
it can be as many bytes as you want when.  You just have
to terminate it with a 0x

$cbData = $lpData.elems * 2;  # words are two bytes long

Does that help?

-T

Re: stolen uint's

[Trey Harris]

I’m still asking you the same question I asked in
https://www.nntp.perl.org/group/perl.perl6.users/2020/01/msg8029.html

I don’t care about IpData or ValueData—those are completely unremarkable
fields. Showing me more code relating to them—or any other fields besides
cData—isn’t helpful to understanding how the 3-bytes UTF + null cData field
works.

Could you please confine your answer to cData, and only in the case where
it’s UTF + Null and not a numeric value? It creates such bizarre
restrictions on what it can hold that I’m trying to wrap my head around how
it works in practice. That’s all I want to know.

Also, you could show code where a ‘uint’ becomes an ‘int’ unbidden, or say
you were mistaken and confused the uppercased auto-boxed ‘Int’ for the
lowercased native ‘int’.

Finally, you could also explain if the multis suggested for solving your
type-checking issue are what you wanted or not.

Thank you.

On Wed, Jan 29, 2020 at 16:40 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 13:01, Trey Harris wrote:
> >
> > On Wed, Jan 29, 2020 at 15:28 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > "Todd" would convert to
> >   84 00 111 00 100 00 100 00 00 00
> >
> >
> > I’m sorry, you misunderstood me. I wasn’t asking how to convert text
> > into UTF. I was asking for an example of the 3-byte UTF plus 32-bit null
> > cbData field. “Todd\0” is not 3-bytes + null, it’s 4 bytes + null. (You
> > can see that from your groupings above—every two pairs make an octet,
> > and there are 5 pairs. That’s 40 bits, not 32.)
> >
> > Also, I assume you used that because it’s your name—could you use an
> > example from the actual registry dataset like what you’re processing,
> > please, and not one that you’ve invented yourself? I’m trying to see how
> > it’s _used_ in real life, not how you’re imagining it could be used.
>
>
> Hi Trey,
>
> In the following example, I am not messing
> with a key that Widows actually uses, but should,
> don't you think?
>
>  The registry hive is: HKEY_LOCAL_MACHINE
>  The key location is:  SOFTWARE\Microsoft\Windows NT\CurrentVersion
>  The key is:   BestLookingEngineer
>  The key type is:  REG_SZ  (means a string)
>  and the "True" turns on debugging
>
> perl6 -I. -e "use NativeConstants; use WinReg :WinRegSetValue; say
> WinRegSetValue( HKEY_LOCAL_MACHINE, Q[SOFTWARE\Microsoft\Windows
> NT\CurrentVersion], Q[BestLookingEngineer], REG_SZ, 'Todd', True );"
>
>
> WinRegSetValue Debug
>   ValueType  REG_SZ  (1)
> KeyName  BestLookingEngineer
> lpValueName  66 101 115 116 76 111 111 107 105 110 103 69 110 103
> 105 110 101 101 114 0
>  dsType  1
>   ValueData  Todd
>  lpData  84 111 100 100 0
>lpData.elems  5
>  cdData  10
>
>
> lpValueName is comes from
>
>  sub to-UTF16-c-str( Str $RakuStr ) returns CArray[uint16] is
> export( :to-UTF16-c-str )  {
> # Converts a UTF8 Raku string into a UTF16 little endian C string
> # Note: C Strings are always terminated with a nul.  WinAPI will
> malfunction without it
>
> my $CStr = CArray[uint16].new();
> $CStr = CArray[uint16].new( $RakuStr.encode.list, 0 );  # add a
> nul to the end
>
> return $CStr;
>   }
>
>
> I have yet to figure out a way to break
>
> my $CStr = CArray[uint16].new();
>
> into bytes for analysis, but it is UTF16 little endian.
> The "W" at the end of "RegSetValueExW" requires it.
>
> In the real world, I check the LUA key
>
>
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
>
>   "EnableLUA"=dword:
>
> to make sure it is zero, so I can mount and dismount
> hidden drive partitions.  The same module will
> unset the LUA for you on a prompt.
>
> -T
>

Re: stolen uint's

[ToddAndMargo via perl6-users]

Widows 


Chuckle.  You should see how I typo `shutdown`.
The "i" and the "u" are a little too close to
each other.


--
~~
When you say, "I wrote a program that
crashed Windows," people just stare at
you blankly and say, "Hey, I got those
with the system, for free."
 -- Linus Torvalds
~~

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 13:01, Trey Harris wrote:


On Wed, Jan 29, 2020 at 15:28 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


"Todd" would convert to
      84 00 111 00 100 00 100 00 00 00


I’m sorry, you misunderstood me. I wasn’t asking how to convert text 
into UTF. I was asking for an example of the 3-byte UTF plus 32-bit null 
cbData field. “Todd\0” is not 3-bytes + null, it’s 4 bytes + null. (You 
can see that from your groupings above—every two pairs make an octet, 
and there are 5 pairs. That’s 40 bits, not 32.)


Also, I assume you used that because it’s your name—could you use an 
example from the actual registry dataset like what you’re processing, 
please, and not one that you’ve invented yourself? I’m trying to see how 
it’s _used_ in real life, not how you’re imagining it could be used.



Hi Trey,

In the following example, I am not messing
with a key that Widows actually uses, but should,
don't you think?

The registry hive is: HKEY_LOCAL_MACHINE
The key location is:  SOFTWARE\Microsoft\Windows NT\CurrentVersion
The key is:   BestLookingEngineer
The key type is:  REG_SZ  (means a string)
and the "True" turns on debugging

perl6 -I. -e "use NativeConstants; use WinReg :WinRegSetValue; say 
WinRegSetValue( HKEY_LOCAL_MACHINE, Q[SOFTWARE\Microsoft\Windows 
NT\CurrentVersion], Q[BestLookingEngineer], REG_SZ, 'Todd', True );"



WinRegSetValue Debug
 ValueType  REG_SZ  (1)
   KeyName  BestLookingEngineer
   lpValueName  66 101 115 116 76 111 111 107 105 110 103 69 110 103 
105 110 101 101 114 0

dsType  1
 ValueData  Todd
lpData  84 111 100 100 0
  lpData.elems  5
cdData  10


lpValueName is comes from

sub to-UTF16-c-str( Str $RakuStr ) returns CArray[uint16] is 
export( :to-UTF16-c-str )  {

   # Converts a UTF8 Raku string into a UTF16 little endian C string
   # Note: C Strings are always terminated with a nul.  WinAPI will 
malfunction without it


   my $CStr = CArray[uint16].new();
   $CStr = CArray[uint16].new( $RakuStr.encode.list, 0 );  # add a 
nul to the end


   return $CStr;
 }


I have yet to figure out a way to break

   my $CStr = CArray[uint16].new();

into bytes for analysis, but it is UTF16 little endian.
The "W" at the end of "RegSetValueExW" requires it.

In the real world, I check the LUA key


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

 "EnableLUA"=dword:

to make sure it is zero, so I can mount and dismount
hidden drive partitions.  The same module will
unset the LUA for you on a prompt.

-T

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 15:28 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> "Todd" would convert to
>  84 00 111 00 100 00 100 00 00 00


I’m sorry, you misunderstood me. I wasn’t asking how to convert text into
UTF. I was asking for an example of the 3-byte UTF plus 32-bit null cbData
field. “Todd\0” is not 3-bytes + null, it’s 4 bytes + null. (You can see
that from your groupings above—every two pairs make an octet, and there are
5 pairs. That’s 40 bits, not 32.)

Also, I assume you used that because it’s your name—could you use an
example from the actual registry dataset like what you’re processing,
please, and not one that you’ve invented yourself? I’m trying to see how
it’s _used_ in real life, not how you’re imagining it could be used.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 11:36, Trey Harris wrote:
On Wed, Jan 29, 2020 at 14:01 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-29 06:34, Trey Harris wrote:
 > I was going to ask about that (but it seemed out of Raku-world,
and I
 > don’t even play someone who knows about Windows on TV), but,
okay, I’ll
 > bite... what are some examples of the precisely 3-byte + 32-bit
null UTF
 > strings you imagine being encoded by this interface? I have never
heard
 > of such a small fixed-width UTF data structure before because
it’s just
 > so bizarre, and then mandating a null termination so you lose the
4th
 > byte that would make this structure at least somewhat coherent as a
 > UCS-4 codepoint... since there’s no such thing as UTF-24, I
assume this
 > is three UTF-8 bytes packed (which I guess is what you mean by
“little
 > endian C string”, but that becomes at best ill-defined abutted
next to
 > “UTF”)... But, what on earth is it being used for?
 >
 > I’m fascinated, in the way a cat is fascinated by a snake

Trey,

You are basically setting up a buffer of bytes
and then telling the WinAPI how long the
data in the buffer is as well as what type of
data the buffer contains.


That is clear from the document linked at
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

But what I was asking about and what I don’t understand is what you 
meant when you wrote:

where CbData can either be a UTF little endian C string,
terminated by a nul or a four byte little endian
unsigned integer (no two's complement allowed) depending
on the value of lpValueName (REG_SZ, REG_DWORD, etc.)


Can you explain just this part:

where CbData can… be a UTF little endian C string,
terminated by a null


That’s the part I’m fascinated by because it’s just so strange. What’s 
an example of a valid value of this type and not the “unsigned integer 
(no two’s complement allowed)”?



"Todd" would convert to
84 00 111 00 100 00 100 00 00 00

Here is a more elaborate UTF16 little endian example.  It
return the WinAPI error string that goes with the error code

perl6 -I. -e "use lib '.'; use WinErr :WinFormatMessage; say 
WinFormatMessage( 0x20, True );"


WinFormatMessage: Debug:
   WinGetLastError  0
   Error Number 32
   nSize1024
   RtnCode  81
   Error String Characters  79
   ErrorString  it is being used by another process.>

   lpBuffer

84 0 104 0 101 0 32 0 112 0 114 0 111 0 99 0 101 0 115 0 115 0 32 0 99 0 
97 0 110 0 110 0 111 0 116 0 32 0 97 0 99 0 99 0 101 0 115 0 115 0 32 0 
116 0 104 0 101 0 32 0 102 0 105 0 108 0 101 0 32 0 98 0 101 0 99 0 97 0 
117 0 115 0 101 0 32 0 105 0 116 0 32 0 105 0 115 0 32 0 98 0 101 0 105 
0 110 0 103 0 32 0 117 0 115 0 101 0 100 0 32 0 98 0 121 0 32 0 97 0 110 
0 111 0 116 0 104 0 101 0 114 0 32 0 112 0 114 0 111 0 99 0 101 0 115 0 
115 0 46 0 13 0 10 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
-1 -1 -1 -1 -1



The buffer was prefilled with 0xFF (-1) to clearly show
the 0x terminator at the end of the buffer.


I will eMail you off line a test example I am including in
my WinAPI paper.

-T

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 14:39 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 11:32, Trey Harris wrote:
> > On Wed, Jan 29, 2020 at 13:50 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > Why don't use use
> >
> > typeMappings[type_index( typeid(char) )] = "char";
> >
> > Finally, a definition I can work with...
> >
> > We can treat this as a request for typeid(); the mapping creation and
> > lookup is an implementation detail.
> >
> > So: the C++ typeid operator works in two modes, static (which happens at
> > compile-time and is inlined) and dynamic (which happens at runtime and
> > is subject to polymorphism). Do you want the static or the dynamic
> behavior?
>
>
> I thought that was C not C++, but ...


The `typeid` operator is C++. Some stdlib extensions have a `typeid` in C,
but it’s non-standard.

Also, your example given below is C++, not C.

As variables in Raku get boxed and coerced
> all the time, I guess I am asking for dynamic.


In that case, you have it already as was mentioned much earlier. See
https://gist.github.com/treyharris/0ce541c07a1f94b41af61207563e7807

with
```perl6
proto check_type($ --> Str) { * }
multi check_type(uint $var) { return "uint" }
multi check_type(Int $var) { return "Int" }

my uint $ui = 42;
say "Value is $ui"; # Value is 42
say check_type($ui); # uint
say ".^name is {$ui.^name}"; # .^name is Int
say check_type($ui); # uint

# .abs autoboxes
say check_type($ui.abs); # Int

# abs() does not
say check_type(abs $ui); # uint
```

Is that what you’re going for?



>
> I am after what the variable is at the moment I
> ask.
>
> Is Raku written in C or C++?


You can go to https://github.com/rakudo/rakudo and determine this for
yourself—click the colored bar to see the language breakdown. (92.6% at the
moment is written in Raku itself; it’s mostly a self-hosted language.)

One of the guys on the C group wrote me this:


That was C++, for the record.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 11:32, Trey Harris wrote:
On Wed, Jan 29, 2020 at 13:50 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


Why don't use use

typeMappings[type_index( typeid(char) )] = "char";

Finally, a definition I can work with...

We can treat this as a request for typeid(); the mapping creation and 
lookup is an implementation detail.


So: the C++ typeid operator works in two modes, static (which happens at 
compile-time and is inlined) and dynamic (which happens at runtime and 
is subject to polymorphism). Do you want the static or the dynamic behavior?



I thought that was C not C++, but ...

As variables in Raku get boxed and coerced
all the time, I guess I am asking for dynamic.

I am after what the variable is at the moment I
ask.

Is Raku written in C or C++?

One of the guys on the C group wrote me this:


#include 
#include 
#include 
#include 
#include 

using namespace std;

int main()
{
unordered_map typeMappings;
typeMappings[type_index( typeid(char) )]   = "char";
typeMappings[type_index( typeid(unsigned char) )]  = "unsigned 
char";

typeMappings[type_index( typeid(signed char) )]= "signed char";
typeMappings[type_index( typeid(short) )]  = "short";
typeMappings[type_index( typeid(unsigned short) )] = "unsigned 
short";

typeMappings[type_index( typeid(int) )]= "int";
typeMappings[type_index( typeid(unsigned int) )]   = "unsigned 
int";

typeMappings[type_index( typeid(long) )]   = "long";
typeMappings[type_index( typeid(unsigned long) )]  = "unsigned 
long";

typeMappings[type_index( typeid(long long) )]  = "long long";
typeMappings[type_index( typeid(unsigned long long) )] = "unsigned 
long long";

typeMappings[type_index( typeid(float) )]  = "float";
typeMappings[type_index( typeid(double) )] = "double";
typeMappings[type_index( typeid(long double) )]= "long double";

int a, c;
float b;
long long d;
cout << typeMappings[type_index( typeid(a + b) )] << endl;
cout << typeMappings[type_index( typeid(a + c) )] << endl;
cout << typeMappings[type_index( typeid(a + d) )] << endl;
}

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 14:01 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 06:34, Trey Harris wrote:
> > I was going to ask about that (but it seemed out of Raku-world, and I
> > don’t even play someone who knows about Windows on TV), but, okay, I’ll
> > bite... what are some examples of the precisely 3-byte + 32-bit null UTF
> > strings you imagine being encoded by this interface? I have never heard
> > of such a small fixed-width UTF data structure before because it’s just
> > so bizarre, and then mandating a null termination so you lose the 4th
> > byte that would make this structure at least somewhat coherent as a
> > UCS-4 codepoint... since there’s no such thing as UTF-24, I assume this
> > is three UTF-8 bytes packed (which I guess is what you mean by “little
> > endian C string”, but that becomes at best ill-defined abutted next to
> > “UTF”)... But, what on earth is it being used for?
> >
> > I’m fascinated, in the way a cat is fascinated by a snake
>
> Trey,
>
> You are basically setting up a buffer of bytes
> and then telling the WinAPI how long the
> data in the buffer is as well as what type of
> data the buffer contains.


That is clear from the document linked at
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

But what I was asking about and what I don’t understand is what you meant
when you wrote:
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

Can you explain just this part:
> where CbData can… be a UTF little endian C string,
> terminated by a null

That’s the part I’m fascinated by because it’s just so strange. What’s an
example of a valid value of this type and not the “unsigned integer (no
two’s complement allowed)”?

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 11:17, William Michels via perl6-users wrote:

"I am not posting it here as it is several hundred lines long and then I'd get the 
finger wagged at me.  Everything is spread across several modules."


On the contrary, this email list is the perfect place to put up
nascent Raku/Perl6 that you're having problems with. The issue is you
making the effort to post a small plain-text **reproducible example**
of problems you're having with Raku/Perl6 code. (Otherwise, it matters
not to me whether your code is 20 lines or 200 lines long).

  But frankly you'll get more answers to your questions if 1) your code
example is short, and 2) other people can copy your code into their
REPLs and can reproduce your issue.

HTH,  Bill.


I was not asking for advice when I asked if he wanted
to see the code. I was giving advice.  I did try
to explain with out the entire code and I also give
snippets.

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:50 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Why don't use use
>
> typeMappings[type_index( typeid(char) )] = "char";
>
Finally, a definition I can work with...

We can treat this as a request for typeid(); the mapping creation and
lookup is an implementation detail.

So: the C++ typeid operator works in two modes, static (which happens at
compile-time and is inlined) and dynamic (which happens at runtime and is
subject to polymorphism). Do you want the static or the dynamic behavior?

Re: stolen uint's

[William Michels via perl6-users]

> "I am not posting it here as it is several hundred lines long and then I'd 
> get the finger wagged at me.  Everything is spread across several modules."

On the contrary, this email list is the perfect place to put up
nascent Raku/Perl6 that you're having problems with. The issue is you
making the effort to post a small plain-text **reproducible example**
of problems you're having with Raku/Perl6 code. (Otherwise, it matters
not to me whether your code is 20 lines or 200 lines long).

 But frankly you'll get more answers to your questions if 1) your code
example is short, and 2) other people can copy your code into their
REPLs and can reproduce your issue.

HTH,  Bill.





On Wed, Jan 29, 2020 at 10:34 AM ToddAndMargo via perl6-users
 wrote:
>
> On 2020-01-29 00:43, Tobias Boege wrote:
> > On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:
> >> This all came up when I tried to match
> >>
> >>RegSetValueExW(
> >>_In_ HKEY hKey,
> >>_In_opt_ LPCWSTR lpValueName,
> >>_Reserved_ DWORD Reserved,
> >>_In_ DWORD dwType,
> >>_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
> >>_In_ DWORD cbData
> >>
> >> where CbData can either be a UTF little endian C string,
> >> terminated by a nul or a four byte little endian
> >> unsigned integer (no two's complement allowed) depending
> >> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
> >>
> >> I wound up doing this:
> >>
> >> subset StrOrDword where Str | UInt;
> >> sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName, 
> >> ValueNames
> >> $ValueType, StrOrDword $ValueData, Bool $Debug = False )
> >>  returns DWORD is export( :WinRegSetValue ) {
> >
> > Are you really 100% sure that you interpreted this API correctly? I see how
> > a DWORD cbData can be a four-byte unsigned integer: it gives the length of
> > lpData in bytes, as documented [1].
> >
> > But then a DWORD is 4 bytes long. Reusing these 4 bytes for an alternative
> > interface where you may pass a UTF-whatever string that is at most 4 bytes
> > encoded, including the NUL terminator... seems too insane. And there is no
> > mention of that in the documentation page [1]. I do not think that cbData
> > is ever used for anything but to indicate the length of the buffer lpData.
> > It is lpData which can have a multitude of types (and serialization 
> > formats),
> > the intended one to be taken from the dwType argument (not lpValueName).
> >
> > My advice is still the same I gave in my very first reply to this thread:
> > make your function a multi and write a candidate for each dwType. You have
> > to write different code for serializing an integer vs. a string to pass as
> > lpData anyway and the compiler can detect native types in multi dispatch
> > for you:
> >
> ># REG_DWORD
> >multi WinRegSetValue(…, uint32 $data) {
> >use experimental :pack;
> >RegSetValueExW(…, REG_DWORD, pack("L", $data), 4)
> >}
> >
> ># REG_SZ
> >multi WinRegSetValue(…, Str $data) {
> >my $blob = "$data\0".encode
> >RegSetValueExW(…, REG_SZ, $blob, $blob.bytes)
> >}
> >
> ># REG_BINARY
> >multi WinRegSetValue(…, blob8 $data) {
> >RegSetValueExW(…, REG_BINARY, $data, $data.bytes)
> >}
> >
> > Regards,
> > Tobias
> >
> > [1] 
> > https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
> >
>
>
>
> Hi Tobias,
>
> I don't have to get so complicated.  Code looks sweet
> though.  I will probably write it down for use
> on other things. Thank you!
>
> Oh yes.  I can pass it strings and DWORD with ease.
>
> I check the value of lpValueName and then proceed.
>
> lpData is basically an array of bytes.  I set the
> bytes up based on lpValueName.  And you have to
> tell cbData how many bytes are legitimate
> in lpData.
>
> It they pass me a string for REG_DWORD or a UInt for
> a REG_SZ, I wag the finger wagged at them big time.
> For example:
>
> if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets
> "boxed" to an Int
>$ErrStr = "ERROR: $SubName\n\n" ~
>  "   ValueData must be an Unsigned Integer when used
> with $ValueType\n\n" ~
>  "   Cowardly exiting\n\n";
>say $ErrStr;
>WinMsg( "ValueData Error", $ErrStr );
>exit;
> }
>
> Hm... I forgot the "Bummer Dude!"
>
> Would you like to see the actual code?  I am not
> posting it here as it is several hundred lines long
> and then I'd get the finger wagged at me.  Every
> thing is spread across several modules.
>
> -T

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 10:58, Tom Browder wrote:

On Wed, Jan 29, 2020 at 12:34 PM ToddAndMargo via perl6-users
 wrote:

On 2020-01-29 00:43, Tobias Boege wrote:

On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:

This all came up when I tried to match

...

 if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets
"boxed" to an Int
$ErrStr = "ERROR: $SubName\n\n" ~
  "   ValueData must be an Unsigned Integer when used
with $ValueType\n\n" ~
  "   Cowardly exiting\n\n";
say $ErrStr;
WinMsg( "ValueData Error", $ErrStr );
exit;
 }

Hm... I forgot the "Bummer Dude!"

Would you like to see the actual code?  I am not
posting it here as it is several hundred lines long


Todd, use your Github account to post real code. You can access your
account via a browser easily.

-Tom



hi Tom,

I know.

I am in eMail hell at the moment.  I am transitioning
over a customer from one server to another and running
afoul of

[Bug 538375] When attempting to copy or move large numbers of local 
messages to an IMAP server, it fails without any error or status message

https://bugzilla.mozilla.org/show_bug.cgi?id=538375

So I should stop goofing off and get to migrating

-T

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 06:34, Trey Harris wrote:
I was going to ask about that (but it seemed out of Raku-world, and I 
don’t even play someone who knows about Windows on TV), but, okay, I’ll 
bite... what are some examples of the precisely 3-byte + 32-bit null UTF 
strings you imagine being encoded by this interface? I have never heard 
of such a small fixed-width UTF data structure before because it’s just 
so bizarre, and then mandating a null termination so you lose the 4th 
byte that would make this structure at least somewhat coherent as a 
UCS-4 codepoint... since there’s no such thing as UTF-24, I assume this 
is three UTF-8 bytes packed (which I guess is what you mean by “little 
endian C string”, but that becomes at best ill-defined abutted next to 
“UTF”)... But, what on earth is it being used for?


I’m fascinated, in the way a cat is fascinated by a snake


Trey,

You are basically setting up a buffer of bytes
and then telling the WinAPI how long the
data in the buffer is as well as what type of
data the buffer contains.

-T

Re: stolen uint's

[Tom Browder]

On Wed, Jan 29, 2020 at 12:34 PM ToddAndMargo via perl6-users
 wrote:
> On 2020-01-29 00:43, Tobias Boege wrote:
> > On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:
> >> This all came up when I tried to match
...
> if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets
> "boxed" to an Int
>$ErrStr = "ERROR: $SubName\n\n" ~
>  "   ValueData must be an Unsigned Integer when used
> with $ValueType\n\n" ~
>  "   Cowardly exiting\n\n";
>say $ErrStr;
>WinMsg( "ValueData Error", $ErrStr );
>exit;
> }
>
> Hm... I forgot the "Bummer Dude!"
>
> Would you like to see the actual code?  I am not
> posting it here as it is several hundred lines long

Todd, use your Github account to post real code. You can access your
account via a browser easily.

-Tom

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 17:00, Trey Harris wrote:
On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-28 16:56, Trey Harris wrote:
 > In other words—yes, you want Raku to attempt to provoke a
segmentation
 > fault, then recover and tell you whether it faulted or not.

Huh?  I just want to know what the variable actually is.  I
do not wnat to crash anything.

Write me a C program to do the equivalent, then, please. You will 
segfault. If you don’t, then you’re asking a question we might be able 
to answer.


Why don't use use

typeMappings[type_index( typeid(char) )] = "char";

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 00:43, Tobias Boege wrote:

On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:

This all came up when I tried to match

   RegSetValueExW(
   _In_ HKEY hKey,
   _In_opt_ LPCWSTR lpValueName,
   _Reserved_ DWORD Reserved,
   _In_ DWORD dwType,
   _In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
   _In_ DWORD cbData

where CbData can either be a UTF little endian C string,
terminated by a nul or a four byte little endian
unsigned integer (no two's complement allowed) depending
on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

I wound up doing this:

subset StrOrDword where Str | UInt;
sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName, ValueNames
$ValueType, StrOrDword $ValueData, Bool $Debug = False )
 returns DWORD is export( :WinRegSetValue ) {


Are you really 100% sure that you interpreted this API correctly? I see how
a DWORD cbData can be a four-byte unsigned integer: it gives the length of
lpData in bytes, as documented [1].

But then a DWORD is 4 bytes long. Reusing these 4 bytes for an alternative
interface where you may pass a UTF-whatever string that is at most 4 bytes
encoded, including the NUL terminator... seems too insane. And there is no
mention of that in the documentation page [1]. I do not think that cbData
is ever used for anything but to indicate the length of the buffer lpData.
It is lpData which can have a multitude of types (and serialization formats),
the intended one to be taken from the dwType argument (not lpValueName).

My advice is still the same I gave in my very first reply to this thread:
make your function a multi and write a candidate for each dwType. You have
to write different code for serializing an integer vs. a string to pass as
lpData anyway and the compiler can detect native types in multi dispatch
for you:

   # REG_DWORD
   multi WinRegSetValue(…, uint32 $data) {
   use experimental :pack;
   RegSetValueExW(…, REG_DWORD, pack("L", $data), 4)
   }

   # REG_SZ
   multi WinRegSetValue(…, Str $data) {
   my $blob = "$data\0".encode
   RegSetValueExW(…, REG_SZ, $blob, $blob.bytes)
   }

   # REG_BINARY
   multi WinRegSetValue(…, blob8 $data) {
   RegSetValueExW(…, REG_BINARY, $data, $data.bytes)
   }

Regards,
Tobias

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw





Hi Tobias,

I don't have to get so complicated.  Code looks sweet
though.  I will probably write it down for use
on other things. Thank you!

Oh yes.  I can pass it strings and DWORD with ease.

I check the value of lpValueName and then proceed.

lpData is basically an array of bytes.  I set the
bytes up based on lpValueName.  And you have to
tell cbData how many bytes are legitimate
in lpData.

It they pass me a string for REG_DWORD or a UInt for
a REG_SZ, I wag the finger wagged at them big time.
For example:

   if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets 
"boxed" to an Int

  $ErrStr = "ERROR: $SubName\n\n" ~
"   ValueData must be an Unsigned Integer when used 
with $ValueType\n\n" ~

"   Cowardly exiting\n\n";
  say $ErrStr;
  WinMsg( "ValueData Error", $ErrStr );
  exit;
   }

Hm... I forgot the "Bummer Dude!"

Would you like to see the actual code?  I am not
posting it here as it is several hundred lines long
and then I'd get the finger wagged at me.  Every
thing is spread across several modules.

-T

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:28 Trey Harris  wrote:

> whose values happen to overlap in a way that describes a subset. Perl
> isn’t Prolog;
>

It isn’t either, but that’s irrelevant; I meant Raku obviously. Thinko.

>

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:04 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 09:19, Trey Harris wrote:
> >
> > The first line of https://docs.raku.org/type/UInt is:
> >  > The `|Int`| is defined as a subset of `|Int|:`
> >
> > How does that not “reflect that UInt is not a unique [type, I assume you
> > meant], but a subset of Int”?
>
> You are correct.  Mumble, mumble.
>
>
>
>
> > 2) that uint is not a native type, but a subset of int.
> >
> >
> > But `uint` is not a subset of `int`; they’re both native types so can’t
> > be subtypes as the constraints would have to hook to the metamodel,
> > which uint and int lack because they’re unboxed. (A “sticker on the
> > “box” is where you write the constraints, if you want to think of it
> > that way.)
>
> So long as it is treated as a subset of int, it is a subset.


“treated as a subset”?

I don’t know what you mean:

```console
> int.does(uint)
False
> uint.does(int)
False
> int.isa(uint)
False
> uint.isa(int)
False
> UInt.does(Int)
True
> Int.does(UInt)
True
> UInt.isa(Int)
True
> Int.isa(UInt)
False
```

If I write:

```
class A { has Int $.value }
class B { has Int $.value where * ≥ 0; }
```

B is not a subset of A. That is the relationship of uint and int—two
distinct types whose values happen to overlap in a way that describes a
subset. Perl isn’t Prolog; a logical relationship between two types is not
a first-class entity of the language.

>

> I know, I am slicing the baloney thin here, but uint is
> not a static C variable. It can change into an int with
> the position of the moon.


I’m STILL waiting for you to show me ONE example of a `uint` turning into
`int`. Not `Int`, via auto-boxing, `int`, via who-knows-what. Either do
that, or stop making the assertion it does that; if you don’t show a
reproducible example, I am going to conclude you are lying if you persist.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 09:19, Trey Harris wrote:


The first line of https://docs.raku.org/type/UInt is:
 > The `|Int`| is defined as a subset of `|Int|:`

How does that not “reflect that UInt is not a unique [type, I assume you 
meant], but a subset of Int”?


You are correct.  Mumble, mumble.





2) that uint is not a native type, but a subset of int.


But `uint` is not a subset of `int`; they’re both native types so can’t 
be subtypes as the constraints would have to hook to the metamodel, 
which uint and int lack because they’re unboxed. (A “sticker on the 
“box” is where you write the constraints, if you want to think of it 
that way.)


So long as it is treated as a subset of int, it is a subset.
I know, I am slicing the baloney thin here, but uint is
not a static C variable. It can change into an int with
the position of the moon.

If you have access to the C code, what is its definition?




3) that uint and int are not "static" (in the C sense)
     variables and can be changed to other things with
     coercion and boxing.  A discussion on when and how
     that is done would be appreciated.



The indexing of Auto-boxing and linking to it where appropriate should 
solve this. Please open a doc issue stating exactly this (and not a 
request for 1 and 2, which are not valid).


Would you mind doing it?  My prose does not get past
the first level.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-29 09:20, Trey Harris wrote:

Argh! Editing error...

On Wed, Jan 29, 2020 at 12:19 Trey Harris > wrote:


The first line of https://docs.raku.org/type/UInt is:

 > The `|Int`| is defined as a subset of `|Int|:`


Should have been (and is in that URL) “The `UInt` is defined as…”


Is alright.  It is not as if I don't make an booboo's
myself.

Re: stolen uint's

[Trey Harris]

Argh! Editing error...

On Wed, Jan 29, 2020 at 12:19 Trey Harris  wrote:

> The first line of https://docs.raku.org/type/UInt is:
>>
> > The `Int` is defined as a subset of `Int:`
>

Should have been (and is in that URL) “The `UInt` is defined as…”

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 11:58 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 22:16, Veesh Goldman wrote:
> > Hi Todd,
> > I'd just like to point out one thing. Your confusion here (and in a few
> > related posts) is that you aren't grokking the difference between uint
> > and UInt.
>
> Hi Veesh,
>
> I am well aware of the difference between UInt and uint.  Two
> weeks ago I was not.
>
> And because they are different, when I ^name on a variable,
> I don't want to see some different come back than what I
> declared it as.
>
> Now Perl variables are not "Static" variables as in C.  They
> have structures assigned to them that allow for all kinds on
> interesting things not allowed in C.  Inside these structures
> is the definition of what the thing is, otherwise you
> could not unbox them, etc..  I want both ^name and .range
> to accurately reflect what is in the structure's definition.
>
> And especially since this is even possible with C, It should
> be possible with Raku being that Raku is written in C.
>
> typeMappings[type_index( typeid(unsigned int) )] = "unsigned int";
>
> And C has no structures to inquire from.
>
> Basically, if I ask a banana what it is, I don't want
> to be told it is an apple.
>
>
> >
> > Please correct me if I'm wrong. But if there needs to be an update to
> > docs, it probably should be to a document that clarifies the difference.
>
> I would like to see the docs updates to
>
> 1) reflect that UInt is not a unique variable, but a subset
> of Int


The first line of https://docs.raku.org/type/UInt is:
> The `Int` is defined as a subset of `Int:`

How does that not “reflect that UInt is not a unique [type, I assume you
meant], but a subset of Int”?


>
> 2) that uint is not a native type, but a subset of int.


But `uint` is not a subset of `int`; they’re both native types so can’t be
subtypes as the constraints would have to hook to the metamodel, which uint
and int lack because they’re unboxed. (A “sticker on the “box” is where you
write the constraints, if you want to think of it that way.)


>
> 3) that uint and int are not "static" (in the C sense)
> variables and can be changed to other things with
> coercion and boxing.  A discussion on when and how
> that is done would be appreciated.


The indexing of Auto-boxing and linking to it where appropriate should
solve this. Please open a doc issue stating exactly this (and not a request
for 1 and 2, which are not valid).

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 22:16, Veesh Goldman wrote:

Hi Todd,
I'd just like to point out one thing. Your confusion here (and in a few 
related posts) is that you aren't grokking the difference between uint 
and UInt.


Hi Veesh,

I am well aware of the difference between UInt and uint.  Two
weeks ago I was not.

And because they are different, when I ^name on a variable,
I don't want to see some different come back than what I
declared it as.

Now Perl variables are not "Static" variables as in C.  They
have structures assigned to them that allow for all kinds on
interesting things not allowed in C.  Inside these structures
is the definition of what the thing is, otherwise you
could not unbox them, etc..  I want both ^name and .range
to accurately reflect what is in the structure's definition.

And especially since this is even possible with C, It should
be possible with Raku being that Raku is written in C.

typeMappings[type_index( typeid(unsigned int) )] = "unsigned int";

And C has no structures to inquire from.

Basically, if I ask a banana what it is, I don't want
to be told it is an apple.




Please correct me if I'm wrong. But if there needs to be an update to 
docs, it probably should be to a document that clarifies the difference.


I would like to see the docs updates to

1) reflect that UInt is not a unique variable, but a subset
   of Int

2) that uint is not a native type, but a subset of int.

3) that uint and int are not "static" (in the C sense)
   variables and can be changed to other things with
   coercion and boxing.  A discussion on when and how
   that is done would be appreciated.

-T

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 03:44 Tobias Boege  wrote:

> On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:
> > This all came up when I tried to match
> >
> >   RegSetValueExW(
> >   _In_ HKEY hKey,
> >   _In_opt_ LPCWSTR lpValueName,
> >   _Reserved_ DWORD Reserved,
> >   _In_ DWORD dwType,
> >   _In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
> >   _In_ DWORD cbData
> >
> > where CbData can either be a UTF little endian C string,
> > terminated by a nul or a four byte little endian
> > unsigned integer (no two's complement allowed) depending
> > on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
> >
> > I wound up doing this:
> >
> > subset StrOrDword where Str | UInt;
> > sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName,
> ValueNames
> > $ValueType, StrOrDword $ValueData, Bool $Debug = False )
> > returns DWORD is export( :WinRegSetValue ) {
>
> Are you really 100% sure that you interpreted this API correctly? I see how
> a DWORD cbData can be a four-byte unsigned integer: it gives the length of
> lpData in bytes, as documented [1].


>
> But then a DWORD is 4 bytes long. Reusing these 4 bytes for an alternative
> interface where you may pass a UTF-whatever string that is at most 4 bytes
> encoded, including the NUL terminator... seems too insane.


I was going to ask about that (but it seemed out of Raku-world, and I don’t
even play someone who knows about Windows on TV), but, okay, I’ll bite...
what are some examples of the precisely 3-byte + 32-bit null UTF strings
you imagine being encoded by this interface? I have never heard of such a
small fixed-width UTF data structure before because it’s just so bizarre,
and then mandating a null termination so you lose the 4th byte that would
make this structure at least somewhat coherent as a UCS-4 codepoint...
since there’s no such thing as UTF-24, I assume this is three UTF-8 bytes
packed (which I guess is what you mean by “little endian C string”, but
that becomes at best ill-defined abutted next to “UTF”)... But, what on
earth is it being used for?

I’m fascinated, in the way a cat is fascinated by a snake

Re: stolen uint's

[Tobias Boege]

On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:
> This all came up when I tried to match
> 
>   RegSetValueExW(
>   _In_ HKEY hKey,
>   _In_opt_ LPCWSTR lpValueName,
>   _Reserved_ DWORD Reserved,
>   _In_ DWORD dwType,
>   _In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
>   _In_ DWORD cbData
> 
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
> 
> I wound up doing this:
> 
> subset StrOrDword where Str | UInt;
> sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName, ValueNames
> $ValueType, StrOrDword $ValueData, Bool $Debug = False )
> returns DWORD is export( :WinRegSetValue ) {

Are you really 100% sure that you interpreted this API correctly? I see how
a DWORD cbData can be a four-byte unsigned integer: it gives the length of
lpData in bytes, as documented [1].

But then a DWORD is 4 bytes long. Reusing these 4 bytes for an alternative
interface where you may pass a UTF-whatever string that is at most 4 bytes
encoded, including the NUL terminator... seems too insane. And there is no
mention of that in the documentation page [1]. I do not think that cbData
is ever used for anything but to indicate the length of the buffer lpData.
It is lpData which can have a multitude of types (and serialization formats),
the intended one to be taken from the dwType argument (not lpValueName).

My advice is still the same I gave in my very first reply to this thread:
make your function a multi and write a candidate for each dwType. You have
to write different code for serializing an integer vs. a string to pass as
lpData anyway and the compiler can detect native types in multi dispatch
for you:

  # REG_DWORD
  multi WinRegSetValue(…, uint32 $data) {
  use experimental :pack;
  RegSetValueExW(…, REG_DWORD, pack("L", $data), 4)
  }

  # REG_SZ
  multi WinRegSetValue(…, Str $data) {
  my $blob = "$data\0".encode
  RegSetValueExW(…, REG_SZ, $blob, $blob.bytes)
  }

  # REG_BINARY
  multi WinRegSetValue(…, blob8 $data) {
  RegSetValueExW(…, REG_BINARY, $data, $data.bytes)
  }

Regards,
Tobias

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: stolen uint's

[Veesh Goldman]

Hi Todd,
I'd just like to point out one thing. Your confusion here (and in a few
related posts) is that you aren't grokking the difference between uint and
UInt.


Please correct me if I'm wrong. But if there needs to be an update to docs,
it probably should be to a document that clarifies the difference.

On Wed, Jan 29, 2020, 06:57 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 18:57, Trey Harris wrote:
> > For doing that sort of thing, learning a little glue C would probably be
> > very useful (IMO, every systems-oriented programmer is helped immensely
> > by knowing enough C to be able to munge low-level data structures). This
> > is a lovely little example of a numeric library using native arithmetic
> > where most of the work is shunted into C but the interface is native
> Raku:
> >
> > https://github.com/p6-pdf/Base64-Native-p6
>
>
> Trivia:
>
> "Reflection" may be being considered for C++20
>

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:57, Trey Harris wrote:
For doing that sort of thing, learning a little glue C would probably be 
very useful (IMO, every systems-oriented programmer is helped immensely 
by knowing enough C to be able to munge low-level data structures). This 
is a lovely little example of a numeric library using native arithmetic 
where most of the work is shunted into C but the interface is native Raku:


https://github.com/p6-pdf/Base64-Native-p6



Trivia:

"Reflection" may be being considered for C++20

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 22:03 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi Trey,
>
> Any chance of you sneaking in on the doc pages
> for ^name and range to explain the things you
> explained to me?



For `.^name`—I suppose, though I’m not sure what would be appropriate
there—anything beyond that native-typed variables will show the autoboxed
type? I don’t think a description of autoboxing itself is relevant there. I
just noticed the “Auto-boxing” section of
https://docs.raku.org/language/numerics is unindexed, though, so that
should probably be fixed (and it should be aliased so typing either
autoboxing or auto-boxing into the search box both turn it up).

For range (lower-cased), absolutely not. If my proposal for adding
front-matter to routine pages is eventually adopted, that would be
reasonable. But right now, when routine pages are entirely auto-generated
from snippets elsewhere, that would mean adding information to
https://docs.raku.org/type/X::OutOfRange#method_range — and the behavior
that tripped you up has nothing even tangentially to do with the
`X::OutOfRange` exception.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:57, Trey Harris wrote:
For doing that sort of thing, learning a little glue C would probably be 
very useful (IMO, every systems-oriented programmer is helped immensely 
by knowing enough C to be able to munge low-level data structures). This 
is a lovely little example of a numeric library using native arithmetic 
where most of the work is shunted into C but the interface is native Raku:


https://github.com/p6-pdf/Base64-Native-p6


Interesting.  I am doing something like that in NativeCall.

Re: stolen uint's

[ToddAndMargo via perl6-users]

Hi Trey,

Any chance of you sneaking in on the doc pages
for ^name and range to explain the things you
explained to me?

I am a little odd in that I actually try to use
the manual pages.  But there may be other out
there too. (Because I do not like the way the
manual pages are written, does not mean I don't
try to use them.)

-T

Re: stolen uint's

[Trey Harris]

For doing that sort of thing, learning a little glue C would probably be
very useful (IMO, every systems-oriented programmer is helped immensely by
knowing enough C to be able to munge low-level data structures). This is a
lovely little example of a numeric library using native arithmetic where
most of the work is shunted into C but the interface is native Raku:

https://github.com/p6-pdf/Base64-Native-p6


On Tue, Jan 28, 2020 at 21:50 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 18:18, Trey Harris wrote:
> > my uint $z = -32;
> > 224
>
> Another misunderstanding on my part.  I thought it
> would barf.
>
> All I really need to know is what is expected.
> To me I am getting wrong answers back, but as
> long as they are consistent answers I can deal
> with it:
>
> if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets "boxed
> to an Int
>
> Thank you for all the time you have spent with me on this!
>
> -T
>
> This all came up when I tried to match
>
>RegSetValueExW(
>_In_ HKEY hKey,
>_In_opt_ LPCWSTR lpValueName,
>_Reserved_ DWORD Reserved,
>_In_ DWORD dwType,
>_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
>_In_ DWORD cbData
>
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
>
> I wound up doing this:
>
> subset StrOrDword where Str | UInt;
> sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName,
> ValueNames $ValueType, StrOrDword $ValueData, Bool $Debug = False )
>  returns DWORD is export( :WinRegSetValue ) {
>

Re: stolen uint's

[ToddAndMargo via perl6-users]

Question: in those instance where I ONLY want
to play with 8,16, or 32 BITS and have Raku
leave whatever pattern I put in them along,
what is the best thing to declare them as?

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:41, Trey Harris wrote:



On Tue, Jan 28, 2020 at 21:18 Trey Harris > wrote:


Nope. If I give you:

0x41

and tell you that’s a single octet, and that’s all you have, and I
and ask you whether that’s an “A” or a decimal 97 or something else
described by 0101, how do you answer? You can’t.


Sorry, editing mistake; I started out with a different example. Of 
course I meant decimal 65.



No problem.  I appreciate all the help

:-)

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:18, Trey Harris wrote:

my uint $z = -32;
224


Another misunderstanding on my part.  I thought it
would barf.

All I really need to know is what is expected.
To me I am getting wrong answers back, but as
long as they are consistent answers I can deal
with it:

if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets "boxed 
to an Int


Thank you for all the time you have spent with me on this!

-T

This all came up when I tried to match

  RegSetValueExW(
  _In_ HKEY hKey,
  _In_opt_ LPCWSTR lpValueName,
  _Reserved_ DWORD Reserved,
  _In_ DWORD dwType,
  _In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
  _In_ DWORD cbData

where CbData can either be a UTF little endian C string,
terminated by a nul or a four byte little endian
unsigned integer (no two's complement allowed) depending
on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

I wound up doing this:

subset StrOrDword where Str | UInt;
sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName, 
ValueNames $ValueType, StrOrDword $ValueData, Bool $Debug = False )

returns DWORD is export( :WinRegSetValue ) {

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 18:34, Trey Harris wrote:
And that’s another thing: you’ll notice if you define a `my uint8 $x;` 
it will be set to 0. No undefined, no Nil. That doesn’t happen with 
non-native numeric values.




Huh.  I thought is as nil.

> my uint $x; say $x.base(2)
0

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 21:18 Trey Harris  wrote:

> Nope. If I give you:
>
> 0x41
>
> and tell you that’s a single octet, and that’s all you have, and I and ask
> you whether that’s an “A” or a decimal 97 or something else described by
> 0101, how do you answer? You can’t.
>

Sorry, editing mistake; I started out with a different example. Of course I
meant decimal 65.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 21:18 Trey Harris  wrote:

> values, such as 'undefined' and 'Nil' as well as its type.
>
>
And that’s another thing: you’ll notice if you define a `my uint8 $x;` it
will be set to 0. No undefined, no Nil. That doesn’t happen with non-native
numeric values.


> Nope. If I give you:
>
> 0x41
>
> and tell you that’s a single octet, and that’s all you have, and I and ask
> you whether that’s an “A” or a decimal 97 or something else described by
> 0101, how do you answer? You can’t.
>
> Raku knows at compile time—otherwise, it couldn’t autobox into an ‘Int’
> vs. a ‘Real’ for an int32 vs. a num32, for example—but that’s not currently
> exposed to the runtime; you can pitch a new feature, but it would be
> necessary to know what one would use it for to design an interface for it.
>
> An ability to cause a failure or exception to be thrown if a given value
> is autoboxed would be much more defensible, I think—“I need to ensure this
> thing doesn’t get munged by something unexpected into a form that my native
> call will barf at” seems more reasonable (though unboxing should prevent
> that in cases where you’re not round-tripping outside of Raku before your
> native call).
>

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:59 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

>
> > Ah You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see
> > that example and I can’t find it scrolling back. Would you repost it,
> > please? That would change things (and possibly indicate a bug).
>
>  > my uint $u= 0xFF44; say $u.^name
> Int
>
> It was upper case Int.  Again, wrong answer.  It should
> have been "UInt"


No—it’s the right answer, because it’s a type constraint, and you can
assign a negative integer to a uint and you’ll get the complement. See the
difference:

```console
> my UInt $x = 32;
32
> $x = -32;
Type check failed in assignment to $x; expected UInt but got Int (-32)
 in block  at  line 1
> my uint $z = -32;
224
```

You can argue that it _should_ barf on negative integers instead, but that
would make working with a number of Unix C std lib native calls that use
unsigned values in... historical interesting ways difficult. That’s perhaps
a niche-enough case that I think you could reasonably argue for autoboxing
into UInt instead. But that would be a behavioral change; *answering*
`UInt`, when it’s absolutely autoboxing into an `Int`, would be wrong; Raku
would be lying to you.
To answer your other questions in your prior mail:

On Tue, Jan 28, 2020 at 20:32 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:17, Trey Harris wrote:
> >  > Write me a C program to do the equivalent, then, please. You will
> >  > segfault. If you don’t, then you’re asking a question we might
> > be able
> >  > to answer.
> >
> > I can't write in C
> >
> >
> > Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
> > language with pointer arithmetic?
>
> I used points all the time in Modula2.  And reference pointers in Perl5


Pascal and its descendants used type-safe pointers. You’d have to have
experience with a language with unsafe pointers to get my point there.

>
> You’ve
> > shown multiple examples of autoboxing. So... you could request Raku add
> > a pragma or trait that would result in a fatal exception being thrown if
> > autoboxing occurs.
>
> What?  I am not wanting to crash anything.  he phrase "the unbox type
> is" will do fine.  Gives perfect warning.


Finding an example of where that’s generally useful is the question. It’s a
type constraint in addition to being a storage type, so if you don’t
violate the constraint, and you don’t coerce it into something else, it
will be what you constrained it to be.

To want to interrogate that doesn’t seem to have a point beyond just being
mistrustful of the language. If you can articulate the usefulness, then you
could look at it—an `nqp::typeof` existed until a few years ago, and I
imagine it could be re-exposed (which would be the first step, since the
native API offers no way to get at that information from Raku code AFAICT).
But you’d have to show a need for a new low-level call like that.

> You can already wrap the variable in a class that
> > keeps the native value immutable so that it can’t be autoboxed.
> >
> > You can compare a native value to another in a way that will tell you if
> > the are or aren’t the same. From that last, you could build something
> > rather crude that created a value of every type you’re interested in,
> > compared your value to each, and then told you if any matched
> > bit-for-bit, which might be sufficient for your purposes (which I still
> > don’t understand)?
> >
> > But what you *can’t* do is ask what it is without autoboxing it. An
> > unsigned 32-bit int is just 32 bits that are entirely used to express an
> > integer—there’s no room to mark what it is, so asking it what it is is
> > meaningless—and once it’s autoboxed, it’s different than it was before
> > the autoboxing.
>
> My misunderstandings
>
> 1) I though 'uint' and 'int' were both separate native types.
> The manual does state such.


They are; show me an example of getting ‘int’ (unboxed) rather than ‘Int’
(autoboxed) from a ‘uint’, though. Do the above test of assign `-32` to a
`uint` vs. an `int` and you’ll see, they’re different, even though they
both autobox into `Int`—the `int` will be -32 rather than the complement.

2) I thought 'unit' had a structure that went along with it,
> as does a string.  And inside that structure were unicorn
> values, such as 'undefined' and 'Nil' as well as its type.


Nope. If I give you:

0x41

and tell you that’s a single octet, and that’s all you have, and I and ask
you whether that’s an “A” or a decimal 97 or something else described by
0101, how do you answer? You can’t.

Raku knows at compile time—otherwise, it couldn’t autobox into an ‘Int’ vs.
a ‘Real’ for an int32 vs. a num32, for example—but that’s not currently
exposed to the runtime; you can pitch a new feature, but it would be
necessary to know what one would use it for to design an interface for it.

An ability to cause a failure or exception to be thrown if a given valu

Re: stolen uint's

[ToddAndMargo via perl6-users]

Ah You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see 
that example and I can’t find it scrolling back. Would you repost it, 
please? That would change things (and possibly indicate a bug).


> my uint $u= 0xFF44; say $u.^name
Int

It was upper case Int.  Again, wrong answer.  It should
have been "UInt"

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:32 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:17, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 20:04 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > On 2020-01-28 17:00, Trey Harris wrote:
> >  > On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users
> >  > mailto:perl6-users@perl.org>
> > >> wrote:
> >  >
> >  > On 2020-01-28 16:56, Trey Harris wrote:
> >  >  > In other words—yes, you want Raku to attempt to provoke a
> >  > segmentation
> >  >  > fault, then recover and tell you whether it faulted or not.
> >  >
> >  > Huh?  I just want to know what the variable actually is.  I
> >  > do not wnat to crash anything.
> >  >
> >  > Write me a C program to do the equivalent, then, please. You will
> >  > segfault. If you don’t, then you’re asking a question we might
> > be able
> >  > to answer.
> >
> > I can't write in C
> >
> >
> > Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
> > language with pointer arithmetic?
>
> I used points all the time in Modula2.  And reference pointers in Perl5
>
> >
> > I just want the correct answer back.  If the wrong answer is coming
> > back, why even have the function available.
> >
> >
> > You haven’t shown one example of the “wrong answer… coming back”.
>
> I got back 'int' for 'unit'.


Ah You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see
that example and I can’t find it scrolling back. Would you repost it,
please? That would change things (and possibly indicate a bug).

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 17:17, Trey Harris wrote:
On Tue, Jan 28, 2020 at 20:04 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-28 17:00, Trey Harris wrote:
 > On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users
 > mailto:perl6-users@perl.org>
>> wrote:
 >
 >     On 2020-01-28 16:56, Trey Harris wrote:
 >      > In other words—yes, you want Raku to attempt to provoke a
 >     segmentation
 >      > fault, then recover and tell you whether it faulted or not.
 >
 >     Huh?  I just want to know what the variable actually is.  I
 >     do not wnat to crash anything.
 >
 > Write me a C program to do the equivalent, then, please. You will
 > segfault. If you don’t, then you’re asking a question we might
be able
 > to answer.

I can't write in C


Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any 
language with pointer arithmetic?


I used points all the time in Modula2.  And reference pointers in Perl5



I just want the correct answer back.  If the wrong answer is coming
back, why even have the function available.


You haven’t shown one example of the “wrong answer… coming back”.


I got back 'int' for 'unit'.

You’ve 
shown multiple examples of autoboxing. So... you could request Raku add 
a pragma or trait that would result in a fatal exception being thrown if 
autoboxing occurs.


What?  I am not wanting to crash anything.  he phrase "the unbox type 
is" will do fine.  Gives perfect warning.


You can already wrap the variable in a class that 
keeps the native value immutable so that it can’t be autoboxed.


You can compare a native value to another in a way that will tell you if 
the are or aren’t the same. From that last, you could build something 
rather crude that created a value of every type you’re interested in, 
compared your value to each, and then told you if any matched 
bit-for-bit, which might be sufficient for your purposes (which I still 
don’t understand)?


But what you *can’t* do is ask what it is without autoboxing it. An 
unsigned 32-bit int is just 32 bits that are entirely used to express an 
integer—there’s no room to mark what it is, so asking it what it is is 
meaningless—and once it’s autoboxed, it’s different than it was before 
the autoboxing.


My misunderstandings

1) I though 'uint' and 'int' were both separate native types.
The manual does state such.

2) I thought 'unit' had a structure that went along with it,
as does a string.  And inside that structure were unicorn
values, such as 'undefined' and 'Nil' as well as its type.

Any chance of an unboxing warning?

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:04 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:00, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > On 2020-01-28 16:56, Trey Harris wrote:
> >  > In other words—yes, you want Raku to attempt to provoke a
> > segmentation
> >  > fault, then recover and tell you whether it faulted or not.
> >
> > Huh?  I just want to know what the variable actually is.  I
> > do not wnat to crash anything.
> >
> > Write me a C program to do the equivalent, then, please. You will
> > segfault. If you don’t, then you’re asking a question we might be able
> > to answer.
>
> I can't write in C


Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
language with pointer arithmetic?

I just want the correct answer back.  If the wrong answer is coming
> back, why even have the function available.


You haven’t shown one example of the “wrong answer… coming back”. You’ve
shown multiple examples of autoboxing. So... you could request Raku add a
pragma or trait that would result in a fatal exception being thrown if
autoboxing occurs. You can already wrap the variable in a class that keeps
the native value immutable so that it can’t be autoboxed.

You can compare a native value to another in a way that will tell you if
the are or aren’t the same. From that last, you could build something
rather crude that created a value of every type you’re interested in,
compared your value to each, and then told you if any matched bit-for-bit,
which might be sufficient for your purposes (which I still don’t
understand)?

But what you *can’t* do is ask what it is without autoboxing it. An
unsigned 32-bit int is just 32 bits that are entirely used to express an
integer—there’s no room to mark what it is, so asking it what it is is
meaningless—and once it’s autoboxed, it’s different than it was before the
autoboxing.

>

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 17:00, Trey Harris wrote:
On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-28 16:56, Trey Harris wrote:
 > In other words—yes, you want Raku to attempt to provoke a
segmentation
 > fault, then recover and tell you whether it faulted or not.

Huh?  I just want to know what the variable actually is.  I
do not wnat to crash anything.

Write me a C program to do the equivalent, then, please. You will 
segfault. If you don’t, then you’re asking a question we might be able 
to answer.


I can't write in C

I just want the correct answer back.  If the wrong answer is coming 
back, why even have the function available.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 16:56, Trey Harris wrote:
> > In other words—yes, you want Raku to attempt to provoke a segmentation
> > fault, then recover and tell you whether it faulted or not.
>
> Huh?  I just want to know what the variable actually is.  I
> do not wnat to crash anything.
>
Write me a C program to do the equivalent, then, please. You will segfault.
If you don’t, then you’re asking a question we might be able to answer.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 16:56, Trey Harris wrote:
In other words—yes, you want Raku to attempt to provoke a segmentation 
fault, then recover and tell you whether it faulted or not.


Huh?  I just want to know what the variable actually is.  I
do not wnat to crash anything.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:55 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 16:52, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 19:46 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> >  > my uint $u= 0xFF44; say $u.^name
> > Int
> >
> > Wrong answer
> >
> > It’s absolutely the right answer. You autoboxed it by running a
> > method—`.^name`—on it. A uint can’t respond to `.^name`, so you can
> > never get that as the right answer. If you try assigning a negative
> > value to it after doing `.^name`, you’ll be able to, but if you read it
> > back, it will be the complement.
> >
> > You seem to be asking for Raku to intentionally provoke, then recover
> > from, a segmentation fault, and then tell you whether or not it faulted.
> > Is that what you’re asking for?
>
> How am I suppose to know when something gets altered by my
> observation of it?  Seriously.
>
> If it is a uint, I want to see uint.  If it
> is being altered, I want to see that too.
>
In other words—yes, you want Raku to attempt to provoke a segmentation
fault, then recover and tell you whether it faulted or not.

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 16:52, Trey Harris wrote:
On Tue, Jan 28, 2020 at 19:46 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


 > my uint $u= 0xFF44; say $u.^name
Int

Wrong answer

It’s absolutely the right answer. You autoboxed it by running a 
method—`.^name`—on it. A uint can’t respond to `.^name`, so you can 
never get that as the right answer. If you try assigning a negative 
value to it after doing `.^name`, you’ll be able to, but if you read it 
back, it will be the complement.


You seem to be asking for Raku to intentionally provoke, then recover 
from, a segmentation fault, and then tell you whether or not it faulted. 
Is that what you’re asking for?


How am I suppose to know when something gets altered by my
observation of it?  Seriously.

If it is a uint, I want to see uint.  If it
is being altered, I want to see that too.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:46 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> > my uint $u= 0xFF44; say $u.^name
> Int
>
> Wrong answer
>
It’s absolutely the right answer. You autoboxed it by running a
method—`.^name`—on it. A uint can’t respond to `.^name`, so you can never
get that as the right answer. If you try assigning a negative value to it
after doing `.^name`, you’ll be able to, but if you read it back, it will
be the complement.

You seem to be asking for Raku to intentionally provoke, then recover from,
a segmentation fault, and then tell you whether or not it faulted. Is that
what you’re asking for?

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 16:30, Trey Harris wrote:
On Tue, Jan 28, 2020 at 19:06 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


On 2020-01-28 15:37, Trey Harris wrote:
 >
 >
 > On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users
 > mailto:perl6-users@perl.org>
>> wrote:
 >
 >     Observer effect (physics)
 > https://en.wikipedia.org/wiki/Observer_effect_(physics)
 >
 >           In physics, the observer effect is the theory that
 >           the mere observation of a phenomenon inevitably
 >           changes that phenomenon ... An especially unusual
 >           version of the observer effect occurs in quantum
 >           mechanics, as best demonstrated by the double-slit
 >           experiment
 >
 >     Seems Quantum theory has come to Raku, only we call it
"unboxing".
 >
 >
 > As I wrote in your Raku/problem-solving issue (#154), your
question is
 > not well-formed. A native value has no metadata, so how can it
have a
 > type? Any experience at all with a language with pointer arithmetic
 > should make this clear.
 >
 > And you issue doesn’t seem to be with unboxing—as far as I can tell,
 > you’re unboxing (assigning to a native) just fine, it’s the
autoboxing
 > that’s giving you fits.
 >
 > If you can show a language that can do what you want—whether it’s a
 > `typeof` equivalent or a binary data validity checker or a magic
number
 > heuristic or something else, then we may be able to help you, but
right
 > now you seem to be asking for something akin to wanting to know what
 > color the bits in your uint32 are—it’s not a question with meaning.

Trey,

If I ask what something is, I want an accurate answer back.


What does “accurate” mean for a native value? It’s a binary blob. It has 
no type in the memory, only in the runtime. If you successfully assigned 
it and haven’t done any OO operations on it, as far as the runtime’s 
concerned, it’s still the type it was when you assigned it. If you have 
done OO operations on it, then it’s been autoboxed and you can do 
`.^name` against it.


I’ve only asked three times, but I’ll try once more: a problem statement 
would be helpful here.  What are you trying to achieve other than poking 
the spot to see if it still hurts when you poke it? It may be possible 
to do what you want with either anonymous variables or with a class 
serving as a container for a native attribute (which can ensure that the 
attribute can’t be autoboxed).


But just saying “I want to run this method that is undefined on this 
thing and has no well-formed answer for this thing apart from what I can 
see by inspecting the code” isn’t helpful in understanding what you 
want. “And I want it to give me an *accurate* answer” doesn’t help to 
understand what that is, either.






> my uint $u= 0xFF44; say $u.^name
Int

Wrong answer

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:06 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 15:37, Trey Harris wrote:
> >
> >
> > On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > Observer effect (physics)
> > https://en.wikipedia.org/wiki/Observer_effect_(physics)
> >
> >   In physics, the observer effect is the theory that
> >   the mere observation of a phenomenon inevitably
> >   changes that phenomenon ... An especially unusual
> >   version of the observer effect occurs in quantum
> >   mechanics, as best demonstrated by the double-slit
> >   experiment
> >
> > Seems Quantum theory has come to Raku, only we call it "unboxing".
> >
> >
> > As I wrote in your Raku/problem-solving issue (#154), your question is
> > not well-formed. A native value has no metadata, so how can it have a
> > type? Any experience at all with a language with pointer arithmetic
> > should make this clear.
> >
> > And you issue doesn’t seem to be with unboxing—as far as I can tell,
> > you’re unboxing (assigning to a native) just fine, it’s the autoboxing
> > that’s giving you fits.
> >
> > If you can show a language that can do what you want—whether it’s a
> > `typeof` equivalent or a binary data validity checker or a magic number
> > heuristic or something else, then we may be able to help you, but right
> > now you seem to be asking for something akin to wanting to know what
> > color the bits in your uint32 are—it’s not a question with meaning.
>
> Trey,
>
> If I ask what something is, I want an accurate answer back.


What does “accurate” mean for a native value? It’s a binary blob. It has no
type in the memory, only in the runtime. If you successfully assigned it
and haven’t done any OO operations on it, as far as the runtime’s
concerned, it’s still the type it was when you assigned it. If you have
done OO operations on it, then it’s been autoboxed and you can do `.^name`
against it.

I’ve only asked three times, but I’ll try once more: a problem statement
would be helpful here.  What are you trying to achieve other than poking
the spot to see if it still hurts when you poke it? It may be possible to
do what you want with either anonymous variables or with a class serving as
a container for a native attribute (which can ensure that the attribute
can’t be autoboxed).

But just saying “I want to run this method that is undefined on this thing
and has no well-formed answer for this thing apart from what I can see by
inspecting the code” isn’t helpful in understanding what you want. “And I
want it to give me an *accurate* answer” doesn’t help to understand what
that is, either.

>

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-28 15:37, Trey Harris wrote:



On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users 
mailto:perl6-users@perl.org>> wrote:


Observer effect (physics)
https://en.wikipedia.org/wiki/Observer_effect_(physics)

      In physics, the observer effect is the theory that
      the mere observation of a phenomenon inevitably
      changes that phenomenon ... An especially unusual
      version of the observer effect occurs in quantum
      mechanics, as best demonstrated by the double-slit
      experiment

Seems Quantum theory has come to Raku, only we call it "unboxing".


As I wrote in your Raku/problem-solving issue (#154), your question is 
not well-formed. A native value has no metadata, so how can it have a 
type? Any experience at all with a language with pointer arithmetic 
should make this clear.


And you issue doesn’t seem to be with unboxing—as far as I can tell, 
you’re unboxing (assigning to a native) just fine, it’s the autoboxing 
that’s giving you fits.


If you can show a language that can do what you want—whether it’s a 
`typeof` equivalent or a binary data validity checker or a magic number 
heuristic or something else, then we may be able to help you, but right 
now you seem to be asking for something akin to wanting to know what 
color the bits in your uint32 are—it’s not a question with meaning.


Trey,

If I ask what something is, I want an accurate answer back.

-T

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Observer effect (physics)
> https://en.wikipedia.org/wiki/Observer_effect_(physics)
>
>  In physics, the observer effect is the theory that
>  the mere observation of a phenomenon inevitably
>  changes that phenomenon ... An especially unusual
>  version of the observer effect occurs in quantum
>  mechanics, as best demonstrated by the double-slit
>  experiment
>
> Seems Quantum theory has come to Raku, only we call it "unboxing".


As I wrote in your Raku/problem-solving issue (#154), your question is not
well-formed. A native value has no metadata, so how can it have a type? Any
experience at all with a language with pointer arithmetic should make this
clear.

And you issue doesn’t seem to be with unboxing—as far as I can tell, you’re
unboxing (assigning to a native) just fine, it’s the autoboxing that’s
giving you fits.

If you can show a language that can do what you want—whether it’s a
`typeof` equivalent or a binary data validity checker or a magic number
heuristic or something else, then we may be able to help you, but right now
you seem to be asking for something akin to wanting to know what color the
bits in your uint32 are—it’s not a question with meaning.

Re: stolen uint's

[ToddAndMargo via perl6-users]

Observer effect (physics)
https://en.wikipedia.org/wiki/Observer_effect_(physics)

In physics, the observer effect is the theory that
the mere observation of a phenomenon inevitably
changes that phenomenon ... An especially unusual
version of the observer effect occurs in quantum
mechanics, as best demonstrated by the double-slit
experiment

Seems Quantum theory has come to Raku, only we call it "unboxing".

:'(

-T

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-25 18:36, ToddAndMargo via perl6-users wrote:

Question: how do I create a 32 bit variable that is hands off
to the boxing?




> my native D32 is repr('P6int') is Int is nativesize(32) is unsigned { }
(D32)

> my D32 $d = 0xFF44; say D32.^name; say D32.Range;
D32
-Inf^..^Inf

A!!

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-25 18:21, Tobias Boege wrote:

On Sat, 25 Jan 2020, ToddAndMargo via perl6-users wrote:

Hi All,

Anyone have a workaround to my stolen uint's?


constant DWORD := uint32;

(uint32)


subset StrOrDword where Str | DWORD;

(StrOrDword)


sub x( StrOrDword $item ) {

*   say "$item is a " ~ $item.^name;
*   }
&x


x( "abc" );

abc is a Str


x( 3 );

Constraint type check failed in binding to parameter '$item'; expected
StrOrDword but got Int (3)
   in sub x at  line 1
   in block  at  line 1


x( 3.UInt );

Constraint type check failed in binding to parameter '$item'; expected
StrOrDword but got Int (3)
   in sub x at  line 1
   in block  at  line 1



Raku allows you to use native datatypes and to constrain variables to
refuse anything but some kind of native data. But an uint32 is just
32 bits, no class and no methods attached.

If nevertheless you call methods on native values, they will be boxed
into objects that actually support methods to be called on themselves.
Native integers, signed or not, are boxed into Int.

With that in mind, re-read the documentation section about native
dispatch [1]. Your sub x has no candidate that statically accepts
a native integer. Since you use a subset type, the typecheck is
deferred until runtime, but StrOrDword.ACCEPTS has no native integer
candidate either, and at that point you lost already, as

   x(my uint32 $ = 3)

would result in the 3 being auto-boxed to be able to check it against
`Str | uint32` and because of the boxing, its type is now Int and the
check fails. Consider:

   sub x(uint32 $item) { say "$item is a " ~ $item.^name }

   x(3);# works, `only` subs auto-unbox the Int literal
   x(my uint32 $ = 3);  # works, a native integer is provided

In both cases, "3 is a Int" will be printed, because the class name
is obtained by calling a (meta-)method on $x, which triggers boxing
to Int. There is no room for a class name in a 32 bits native integer.

Now, if you change the signature to something subsetty/dynamic like

   sub x($item where uint32)

both calls fail to dispatch, as explained above. On the other hand,
this works because there is an explicit native integer candidate for
the dynamic typecheck, so you don't get boxed:

   sub x($item where -> uint32 { True })

By the way, this has nothing to do with unsigned or signed integers,
your signs are not stolen, your values are boxed. The uint32 type is
simply not suitable to be typechecked against, as this quintessentially
paradoxical line of code tells you:

   say (my uint32 $ = 3) ~~ uint32;  # False

Native data is second-class data in a language where everything
is an object.

If you want a workaround, eschew the subset and provide two candidates
for your sub x: one for Str and one for uint32. How do you expect to
handle something that may either be a Raku string object or a native
integer in a single candidate anyway? Or drop the native integer
altogether and use Int until you really need the native thing.

Regards,
Tobias

[1] https://docs.raku.org/language/numerics#Native_dispatch



Most of the time "Boxing" is a sweet feature.  But are times
when it is a pain in the neck (not my exact word).

I am trying to make my sub declaration match:

https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

  C++
LSTATUS RegSetValueExW(
HKEYhKey,
LPCWSTR lpValueName,
DWORD   Reserved,
DWORD   dwType,
const BYTE  *lpData,
DWORD   cbData
  );
  return a DWORD.  0 = success

Where cdData is either a little endian UTF16 C String or
a little endian 32 bit unsigned integer (DWORD)

And I am trying to catch when folks mix the two up.
based on lpValueName (REG_DWORD, etc.)

Question: how do I create a 32 bit variable that is hands off
to the boxing?

Many thanks,
-T

Re: stolen uint's

[ToddAndMargo via perl6-users]

On 2020-01-25 16:58, ToddAndMargo via perl6-users wrote:

Hi All,

Anyone have a workaround to my stolen uint's?

 > constant DWORD := uint32;
(uint32)

 > subset StrOrDword where Str | DWORD;
(StrOrDword)

 > sub x( StrOrDword $item ) {
*   say "$item is a " ~ $item.^name;
*   }
&x

 > x( "abc" );
abc is a Str

 > x( 3 );
Constraint type check failed in binding to parameter '$item'; expected 
StrOrDword but got Int (3)

   in sub x at  line 1
   in block  at  line 1

 > x( 3.UInt );
Constraint type check failed in binding to parameter '$item'; expected 
StrOrDword but got Int (3)

   in sub x at  line 1
   in block  at  line 1



Many thanks,
-T




> say DWORD.Range
0..4294967295

> my DWORD $c=0xFF44;say $c.DWORD.Range
No such method 'DWORD' for invocant of type 'Int'
  in block  at  line 1

A!

Re: stolen uint's

[Tobias Boege]

On Sat, 25 Jan 2020, ToddAndMargo via perl6-users wrote:
> Hi All,
> 
> Anyone have a workaround to my stolen uint's?
> 
> > constant DWORD := uint32;
> (uint32)
> 
> > subset StrOrDword where Str | DWORD;
> (StrOrDword)
> 
> > sub x( StrOrDword $item ) {
> *   say "$item is a " ~ $item.^name;
> *   }
> &x
> 
> > x( "abc" );
> abc is a Str
> 
> > x( 3 );
> Constraint type check failed in binding to parameter '$item'; expected
> StrOrDword but got Int (3)
>   in sub x at  line 1
>   in block  at  line 1
> 
> > x( 3.UInt );
> Constraint type check failed in binding to parameter '$item'; expected
> StrOrDword but got Int (3)
>   in sub x at  line 1
>   in block  at  line 1
> 

Raku allows you to use native datatypes and to constrain variables to
refuse anything but some kind of native data. But an uint32 is just
32 bits, no class and no methods attached.

If nevertheless you call methods on native values, they will be boxed
into objects that actually support methods to be called on themselves.
Native integers, signed or not, are boxed into Int.

With that in mind, re-read the documentation section about native
dispatch [1]. Your sub x has no candidate that statically accepts
a native integer. Since you use a subset type, the typecheck is
deferred until runtime, but StrOrDword.ACCEPTS has no native integer
candidate either, and at that point you lost already, as

  x(my uint32 $ = 3)

would result in the 3 being auto-boxed to be able to check it against
`Str | uint32` and because of the boxing, its type is now Int and the
check fails. Consider:

  sub x(uint32 $item) { say "$item is a " ~ $item.^name }

  x(3);# works, `only` subs auto-unbox the Int literal
  x(my uint32 $ = 3);  # works, a native integer is provided

In both cases, "3 is a Int" will be printed, because the class name
is obtained by calling a (meta-)method on $x, which triggers boxing
to Int. There is no room for a class name in a 32 bits native integer.

Now, if you change the signature to something subsetty/dynamic like

  sub x($item where uint32)

both calls fail to dispatch, as explained above. On the other hand,
this works because there is an explicit native integer candidate for
the dynamic typecheck, so you don't get boxed:

  sub x($item where -> uint32 { True })

By the way, this has nothing to do with unsigned or signed integers,
your signs are not stolen, your values are boxed. The uint32 type is
simply not suitable to be typechecked against, as this quintessentially
paradoxical line of code tells you:

  say (my uint32 $ = 3) ~~ uint32;  # False

Native data is second-class data in a language where everything
is an object.

If you want a workaround, eschew the subset and provide two candidates
for your sub x: one for Str and one for uint32. How do you expect to
handle something that may either be a Raku string object or a native
integer in a single candidate anyway? Or drop the native integer
altogether and use Int until you really need the native thing.

Regards,
Tobias

[1] https://docs.raku.org/language/numerics#Native_dispatch

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk