On Sun, Jan 19, 2020 at 12:20:18AM -0500, Paul Procacci wrote:
> On Sun, Jan 19, 2020 at 12:12 AM yary wrote:
>
> > In UTF-16 every character is 16 bits, so all 8 bits of zeros tells you is
> > that it's possibly a big-endian ascii character or a little-endian
> > non-ascii character at a
Follow up:
Hi All,
Once JJ agreed this was a bug and it got posted,
the developers ran with it and even created a new
class to handle the problem.
https://github.com/Raku/doc/pull/3171#issuecomment-575991403
# class CArray
multi new (Str $data , :$encoding = 'utf8') {
On 2020-01-19 00:08, Tobias Boege wrote:
On Sat, 18 Jan 2020, ToddAndMargo via perl6-users wrote:
Would you be so kind to post this as an issue in the documentation, so
we can pick up on it?
Thanks!
JJ
Would you mind posting back the link to it, so I can
get on the following list?
On Sat, 18 Jan 2020, ToddAndMargo via perl6-users wrote:
>
> > Would you be so kind to post this as an issue in the documentation, so
> > we can pick up on it?
> >
> > Thanks!
> >
> > JJ
>
> Would you mind posting back the link to it, so I can
> get on the following list?
On 2020-01-18 21:42, Paul Procacci wrote:
Sorry. Not a WINAPI expert, nor do I want to be. ;)
The $nSize variable looks fishy. Can it ever contain a value that's <= 2?
If so, you're in for a surprise one day. ;)
Bedtime.
~Paul
Hi Paul,
Great catch. Thank you for the peer preview!
-T
On 2020-01-18 21:49, ToddAndMargo via perl6-users wrote:
On 2020-01-18 21:42, Paul Procacci wrote:
Sorry. Not a WINAPI expert, nor do I want to be. ;)
No Welcome to the Dar Side for you!!!
:-)
The $nSize variable looks fishy. Can it ever contain a value that's
<= 2?
The buffer always
On 2020-01-18 21:42, Paul Procacci wrote:
Sorry. Not a WINAPI expert, nor do I want to be. ;)
No Welcome to the Dar Side for you!!!
:-)
The $nSize variable looks fishy. Can it ever contain a value that's <= 2?
The buffer always has some size to it. Maybe not.
This is is what it
Sorry. Not a WINAPI expert, nor do I want to be. ;)
The $nSize variable looks fishy. Can it ever contain a value that's <= 2?
If so, you're in for a surprise one day. ;)
Bedtime.
~Paul
On Sun, Jan 19, 2020 at 12:28 AM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> On
On 2020-01-18 21:20, Paul Procacci wrote:
Perfect. Obviously didn't know that. My assumption that only the first
byte gets checked was obviously wrong.
Thanks gents.
This is the way I dig out the ascii characters
from the word array. $nSize comes back from
function call.
loop (my
On 2020-01-18 21:04, ToddAndMargo via perl6-users wrote:
I changed the initialization of the buffer from
0x00 to 0xFF to make the double nul at the end a
bit more obvious:
# my BYTES $lpBuffer = CArray[BYTE].new( 0 xx $nSize );
my BYTES $lpBuffer = CArray[BYTE].new( 0xFF xx $nSize
Perfect. Obviously didn't know that. My assumption that only the first
byte gets checked was obviously wrong.
Thanks gents.
On Sun, Jan 19, 2020 at 12:12 AM yary wrote:
> In UTF-16 every character is 16 bits, so all 8 bits of zeros tells you is
> that it's possibly a big-endian ascii
In UTF-16 every character is 16 bits, so all 8 bits of zeros tells you is
that it's possibly a big-endian ascii character or a little-endian
non-ascii character at a position divisible by 256. All zeros U+ is
unicode NULL, which the windows UTF-16 C convention uses to terminate the
string.
-y
On 2020-01-18 20:05, Paul Procacci wrote:
>> I also found out the
>> hard wasy the UTF16 strings need to be terminated with
>> a double nul (0x).
Not to doubt you (I don't do anything in UTF-16), but can you show an
example of this?
I would have thought a single NULL character is
>> I also found out the
>> hard wasy the UTF16 strings need to be terminated with
>> a double nul (0x).
Not to doubt you (I don't do anything in UTF-16), but can you show an
example of this?
I would have thought a single NULL character is enough.
The 1st byte of a Unicode character
On 2020-01-18 04:55, Tobias Boege wrote:
BUT the terminating NUL character is not inserted by NativeCall and it
isn't inserted by
Hi Tobias,
I found this out the hard way. I also found out the
hard wasy the UTF16 strings need to be terminated with
a double nul (0x).
-T
Would you be so kind to post this as an issue in the documentation, so
we can pick up on it?
Thanks!
JJ
Would you mind posting back the link to it, so I can
get on the following list?
Thank you Tobias.
This is what I was trying to get at, but wasn't sure _how_ to reach that
conclusion.
You've done so elegantly.
~Paul
On Sat, Jan 18, 2020 at 7:55 AM Tobias Boege wrote:
> On Sat, 18 Jan 2020, JJ Merelo wrote:
> > The example works perfectly, and it does because it's a string
El sáb., 18 ene. 2020 a las 13:55, Tobias Boege ()
escribió:
> On Sat, 18 Jan 2020, JJ Merelo wrote:
> > The example works perfectly, and it does because it's a string literal
> > which is already 0 terminated. Let's use this code instead of the one
> that
> > I used in my other mail about this
On Sat, 18 Jan 2020, JJ Merelo wrote:
> The example works perfectly, and it does because it's a string literal
> which is already 0 terminated. Let's use this code instead of the one that
> I used in my other mail about this (which you probably didn't read anyway):
>
> 8< 8< 8<
>
> What does
I know this is utterly and absolutely absurd, but so it goes.
El vie., 17 ene. 2020 a las 23:28, ToddAndMargo ()
escribió:
> Hi JJ,
>
> Please be my hero.
>
> I won't call you any goofy names out of
> affection and friendship, as others will get
> their nickers in a twist.
>
> This is from a
>> For anyone following along that is not familiar with
>> C, a BYTE in C is called a Char in C. (Causes
>> some interesting conversations when UTF16 gets involved.)
I don't want to make this about C, but to clarify there's no type called
"BYTE" in the C language.
If BYTE is defined it's system
For anyone following along that is not familiar with
C, a BYTE in C is called a Char in C. (Causes
some interesting conversations when UTF16 gets involved.)
On 2020-01-17 17:03, Paul Procacci wrote:
>> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14.
>> leaving off the nul is not a valid
>> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14.
>> leaving off the nul is not a valid way of presenting a
>> string to a C function.
Here's the rub though Todd. Who is saying it's a string that is being
passed? (Hint: You are)
If the intention is to pass 3 bytes "FOO" starting at a given
On 2020-01-17 15:34, Paul Procacci wrote:
Todd (and others),
So a few things.
1)
JJ's example worked by chance. (sorry JJ).
It worked because it just so happens that either his OS zero filled the
block he was allocated by the allocator
or because he didn't reuse the block that was given to
Todd (and others),
So a few things.
1)
JJ's example worked by chance. (sorry JJ).
It worked because it just so happens that either his OS zero filled the
block he was allocated by the allocator
or because he didn't reuse the block that was given to him initially by the
allocator.
2)
If you
Hi JJ,
Please be my hero.
I won't call you any goofy names out of
affection and friendship, as others will get
their nickers in a twist.
This is from a previous conversation we had concerning
the mistake in
https://docs.raku.org/language/nativecall#index-entry-nativecall
my $string =
26 matches
Mail list logo
