Re: Nativecall - Help with converting wchar_t CArray to something printable

Hi Paul, I can't help, since I haven't a Windows PC, but I noticed that you initialize your $entry variable like this: my PROCESSENTRY32 $entry .= new(:dwSize(nativesizeof(PROCESSENTRY32))); I don't think the argument to the "new" call is necessary. Try this: my PROCESSENTRY32 $entry .= new; say

Re: Nativecall - Help with converting wchar_t CArray to something printable

Hi Fernando, I appreciate your response. The windows api requires that the dwSize member of the structure gets set to the size of the structure. This is the reason why the object is being constructed as I've provided. ~Paul On Sun, Jan 3, 2021 at 4:58 AM Fernando Santagata wrote: > Hi Paul, >

Re: Nativecall - Help with converting wchar_t CArray to something printable

On 1/2/21 11:38 PM, Paul Procacci wrote: I don't have a C string that's terminated by null. I have a CArray[int16] of length 260 that's passed to and filled in by the windows api. https://docs.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot

Extra . needed

I was playing with classes and adding a closure to an attribute. I discovered that to call a closure on object I need `.()` rather than just `()`. See REPL below. raku Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2020.12. Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d. Built on MoarVM version 2020.12. To exit type

Re: Nativecall - Help with converting wchar_t CArray to something printable

Todd, Nothing you stated addresses my initial question nor subsequent findings. My question is simply how to retrieve the value that gets stored in the CArray; nothing more. My subsequent findings included the following as I believe I'm running into it: https://github.com/rakudo/rakudo/issues/3633

Re: Extra . needed

You've already asked a similar question. https://stackoverflow.com/questions/54033524/perl6-correctly-passing-a-routine-into-an-object-variable When you call $a.f() you are getting the value in &!f which is a function. When you call $a.f().() you are getting the value in &!f, and then also calli

Re: Nativecall - Help with converting wchar_t CArray to something printable

To expand further on the problem I'm running into, take the following C function: #include typedef struct T { char a[260]; int32_t b; } T; void setTest(T *t) { (void)memset(t->a, 'T', 260); t->b = 1; } - gcc -c -O3 -Wext

Re: Nativecall - Help with converting wchar_t CArray to something printable

Todd, I've made a mistake. Raku does ensure a pointer gets passed to the function transparently when referencing a structure and doesn't require one to be explicit. I stand corrected. ~Paul On Sun, Jan 3, 2021 at 1:40 PM Paul Procacci wrote: > Todd, > > Nothing you stated addresses my initial

Re: Extra . needed

Hi Richard, it doesn't appear to be a REPL-only result: user@mbook:~$ cat richard_closure.p6 class A { has &.f = -> { 'xyz' }}; my A $a .=new; say $a.f(); say $a.f.(); user@mbook:~$ raku richard_closure.p6 -> { #`(Block|140238954644472) ... } xyz user@mbook:~$ raku --version Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v

Nativecall - Callee filled static character array - CArray [repost]

This is a repost from an improperly worded email. That previous email thread divulged into things it shouldn't have to which I'm partially to blame. This isn't Windows specific - the problem occurs across platforms. This is simply about the proper way to define an *inline* array of items in a Raku

Re: Nativecall - Help with converting wchar_t CArray to something printable

On 1/3/21 12:00 PM, Paul Procacci wrote: Todd, I've made a mistake. Raku does ensure a pointer gets passed to the function transparently when referencing a structure and doesn't require one to be explicit. I stand corrected. ~Paul Did you get it working?

Re: Nativecall - Help with converting wchar_t CArray to something printable

No, it doesn't work. The inline statically defined array in Raku never gets filled with any data from the win32 function call. On Sun, Jan 3, 2021 at 9:37 PM ToddAndMargo via perl6-users < perl6-us...@perl.org> wrote: > On 1/3/21 12:00 PM, Paul Procacci wrote: > > Todd, > > > > I've made a mistak

Re: Nativecall - Help with converting wchar_t CArray to something printable

On 1/3/21 10:40 AM, Paul Procacci wrote: Furthermore you can't pass a naked $entry to like so: Process32First($handle, $entry) It has to be a pointer;  had you tried what you suggested, raku would have thrown errors and for good reason. Do you understand about "is rw" now? Process32Firs

Re: Nativecall - Help with converting wchar_t CArray to something printable

Todd, I know what 'is rw' is for. This isn't at all related to the problem I'm having. On Sun, Jan 3, 2021 at 9:43 PM ToddAndMargo via perl6-users < perl6-us...@perl.org> wrote: > On 1/3/21 10:40 AM, Paul Procacci wrote: > > Furthermore you can't pass a naked $entry to like so: > > Process32Fir

Re: Nativecall - Help with converting wchar_t CArray to something printable

On 1/3/21 6:46 PM, Paul Procacci wrote: Todd, I know what 'is rw' is for.  This isn't at all related to the problem I'm having. Hi Paul, I seems to be only annoying you, so I will stop here. Good luck with your project. Is sounds fun. -T

Re: Nativecall - Help with converting wchar_t CArray to something printable

On 1/3/21 10:40 AM, Paul Procacci wrote: Irrelevant musings: -- A windows handle is a pointer. A handle is an abstraction to a memory location that can be used in subsequent api calls. Declaring it as any incarnation of an int is a mistake and will not function properly across all machines. H

Re: Nativecall - Callee filled static character array - CArray [repost]

Hello, Maybe the behavior you're seeing is related to this bug: https://github.com/rakudo/rakudo/issues/3633 For what I was concerned, Raku 2020.10 solved the problem, but since the issue was reopened right after I closed it, I imagine the problem is still lingering. Perhaps you can add some rem

Re: Nativecall - Callee filled static character array - CArray [repost]

Thanks for that. I did see that but neglected to add my 2 cents. I just have though. ~Paul On Sun, Jan 3, 2021 at 8:40 PM Paul Procacci wrote: > This is a repost from an improperly worded email. > That previous email thread divulged into things it shouldn't have to which > I'm partially to blam