Re: why not raku ?

[Aureliano Guedes]

Some time ago I found an example of how to integrate C++ through
NativeCall, but it is not straightforward.
If we have the advantage of using C and *C++* libs, we will just need one
more step: "convert legions of dev to our sect".

As more devs became a rakoon, more the language became popular and
populated of tools and libs.

Imo, the first thing we need to think about is writing really good
documentation.
Easy to navigate. Easy to understand. Easy to find practical examples.

Few months ago I was trying to adapt the C++ lib xframe<
https://github.com/xtensor-stack/xframe>.
But I missed everything because I didn't put it on github and my HDD died,
sorry about that.
Anyway, I'm quite limited in knowledge about Raku.


On Mon, Nov 22, 2021 at 12:33 AM Clifton Wood 
wrote:

> Ralph:
>
> It has *two* compelling use cases, and it's the ones that brought me to
> Raku in the first place:
>
> - First class C integration without the need for C (NativeCall)
>
> - Grammars
>
> I have gone through over 20 C libraries with at least a modicum of
> success. All in Raku. All easily done to get the basic support (C stubs).
> I've written utilities that make much of the work of porting an .h file as
> simple as running a single script.
>
> Hopefully I will be able to get these projects out the door, but I have to
> overcome the CURI output limitations first. I'd really like to have a
> custom installer built to handle output to the user while pre-compiling,
> but I've decided that's something that can wait for the future.
>
> I guess I'll be releasing the first lib sometime soon.
>
> - Xliff
>
> On Sun, Nov 21, 2021 at 10:28 PM Clifton Wood 
> wrote:
>
>> Piper: That would be zef
>>
>> https://github.com/ugexe/zef
>>
>> On Sun, Nov 21, 2021 at 8:51 PM Piper H  wrote:
>>
>>> What's the package management tool for raku?
>>> The stuff like gem/bundle for ruby and cpanm for perl5.
>>>
>>> Thanks.
>>>
>>> On Mon, Nov 22, 2021 at 9:43 AM Ralph Mellor 
>>> wrote:
>>>
 My 2c:

 On Fri, Nov 19, 2021 at 9:45 AM Marc Chantreux  wrote:
 >
 > > I like ruby and perl
 >
 > so do I but raku is by far my prefered interpreted langage now.

 Nit. It's compiled, in the same way Java or C# is compiled.

 Consider:
 ```
 say 42;
 constant foo = die;
 ```
 If it were interpreted, the `42` would appear, and then the
 program would die. But instead it dies at compile-time
 (`constant`s are initialized at compile-time).

 That said, the usual way of using it is to run a program,
 which compiles it, and then, if it successfully compiles,
 immediately runs the compiled program.

 > I don't raku that much and most of the time, i read the
 > doc more than i actually write code but when it's writen,
 > it's always elegant and concise the way i never seen before.

 Many folk who like Ruby or Python or Lang X say much the
 same thing about those PLs.

 > > Maybe perl6 is still not production-ready?

 Imo it's as production ready as Python.

 > > but why so few open source projects which were developed by perl6?

 It's all relative. Compared to most of the thousands of PLs
 with less projects, there are lots of projects developed in Raku.

 But you presumably mean in comparison to the likes of Python and Ruby.

 There are many factors. Some I'd focus on are:

 * It's unusual. Few folk like that.

 * It has a large language surface area. Few folk like that.

 * It's very slow. Very few folk like that.

 * It has no widely recognized distinctive compelling use case.

 As a consequence of these and other factors there is minimal
 interest in it so far, let alone adoption.

 So now, one can add another factor:

 * It isn't interesting to most, and has had minimal adoption so far.
 Almost NO folk are OK with that.

 So now, one can add another factor:

 * Almost NO folk want to help develop it. And you can't attract
 them either. Unless they get it. Because then they fall in love
 with it. And so it rolls. For now.

 So, for now, it needs more work, as it has always done.

 > * raku shines on interpreted langages when people are
 > moving to compiled langages

 It's a compiled language, so that's not quite right. Perhaps
 you meant it's dynamically typed rather than statically typed,
 but that's not quite right either.

 If one squints, it's an open source alternative to Oracle's
 Truffle/Graal/JVM, but it's wy slower.

 > * raku is that rich it's hard to get it in a first view

 I'd say it's hard to *ever* get most of it. It's as ambitious
 as Truffle/Graal/JVM, perhaps even more so.

 But it should and *will* be easy to get it a little at a time.

 But we're not there yet.

 There's a fairly obvious way to make it

Re: why not raku ?

[Piper H]

Has Larry Wall joined the development team of raku?
I can't think of the case  if Matz was not in the new Ruby development team.

On Mon, Nov 22, 2021 at 7:19 PM Aureliano Guedes 
wrote:

> Some time ago I found an example of how to integrate C++ through
> NativeCall, but it is not straightforward.
> If we have the advantage of using C and *C++* libs, we will just need one
> more step: "convert legions of dev to our sect".
>
> As more devs became a rakoon, more the language became popular and
> populated of tools and libs.
>
> Imo, the first thing we need to think about is writing really good
> documentation.
> Easy to navigate. Easy to understand. Easy to find practical examples.
>
> Few months ago I was trying to adapt the C++ lib xframe<
> https://github.com/xtensor-stack/xframe>.
> But I missed everything because I didn't put it on github and my HDD died,
> sorry about that.
> Anyway, I'm quite limited in knowledge about Raku.
>
>
> On Mon, Nov 22, 2021 at 12:33 AM Clifton Wood 
> wrote:
>
>> Ralph:
>>
>> It has *two* compelling use cases, and it's the ones that brought me to
>> Raku in the first place:
>>
>> - First class C integration without the need for C (NativeCall)
>>
>> - Grammars
>>
>> I have gone through over 20 C libraries with at least a modicum of
>> success. All in Raku. All easily done to get the basic support (C stubs).
>> I've written utilities that make much of the work of porting an .h file as
>> simple as running a single script.
>>
>> Hopefully I will be able to get these projects out the door, but I have
>> to overcome the CURI output limitations first. I'd really like to have a
>> custom installer built to handle output to the user while pre-compiling,
>> but I've decided that's something that can wait for the future.
>>
>> I guess I'll be releasing the first lib sometime soon.
>>
>> - Xliff
>>
>> On Sun, Nov 21, 2021 at 10:28 PM Clifton Wood 
>> wrote:
>>
>>> Piper: That would be zef
>>>
>>> https://github.com/ugexe/zef
>>>
>>> On Sun, Nov 21, 2021 at 8:51 PM Piper H  wrote:
>>>
 What's the package management tool for raku?
 The stuff like gem/bundle for ruby and cpanm for perl5.

 Thanks.

 On Mon, Nov 22, 2021 at 9:43 AM Ralph Mellor 
 wrote:

> My 2c:
>
> On Fri, Nov 19, 2021 at 9:45 AM Marc Chantreux  wrote:
> >
> > > I like ruby and perl
> >
> > so do I but raku is by far my prefered interpreted langage now.
>
> Nit. It's compiled, in the same way Java or C# is compiled.
>
> Consider:
> ```
> say 42;
> constant foo = die;
> ```
> If it were interpreted, the `42` would appear, and then the
> program would die. But instead it dies at compile-time
> (`constant`s are initialized at compile-time).
>
> That said, the usual way of using it is to run a program,
> which compiles it, and then, if it successfully compiles,
> immediately runs the compiled program.
>
> > I don't raku that much and most of the time, i read the
> > doc more than i actually write code but when it's writen,
> > it's always elegant and concise the way i never seen before.
>
> Many folk who like Ruby or Python or Lang X say much the
> same thing about those PLs.
>
> > > Maybe perl6 is still not production-ready?
>
> Imo it's as production ready as Python.
>
> > > but why so few open source projects which were developed by perl6?
>
> It's all relative. Compared to most of the thousands of PLs
> with less projects, there are lots of projects developed in Raku.
>
> But you presumably mean in comparison to the likes of Python and Ruby.
>
> There are many factors. Some I'd focus on are:
>
> * It's unusual. Few folk like that.
>
> * It has a large language surface area. Few folk like that.
>
> * It's very slow. Very few folk like that.
>
> * It has no widely recognized distinctive compelling use case.
>
> As a consequence of these and other factors there is minimal
> interest in it so far, let alone adoption.
>
> So now, one can add another factor:
>
> * It isn't interesting to most, and has had minimal adoption so far.
> Almost NO folk are OK with that.
>
> So now, one can add another factor:
>
> * Almost NO folk want to help develop it. And you can't attract
> them either. Unless they get it. Because then they fall in love
> with it. And so it rolls. For now.
>
> So, for now, it needs more work, as it has always done.
>
> > * raku shines on interpreted langages when people are
> > moving to compiled langages
>
> It's a compiled language, so that's not quite right. Perhaps
> you meant it's dynamically typed rather than statically typed,
> but that's not quite right either.
>
> If one squints, it's an open source alternative to Oracle's
> Truffle/Graal/JVM, but it's wy slower.

Re: why not raku ?

[Salve J Nilsen]

Piper H said:

> Has Larry Wall joined the development team of raku?

He's been part of it since the very beginning. He's also on this list,
chipping in now and then (last time was in June this year).


- Salve

-- 
#!/usr/bin/env perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#
'3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is near! :)

Re: why not raku ?

[Clifton Wood]

Aureliano, where was this example for C++? I'd love to take a look at it!

Raku could really use a dose of Qt.

On Mon, Nov 22, 2021 at 8:52 AM Salve J Nilsen  wrote:

> Piper H said:
>
> > Has Larry Wall joined the development team of raku?
>
> He's been part of it since the very beginning. He's also on this list,
> chipping in now and then (last time was in June this year).
>
>
> - Salve
>
> --
> #!/usr/bin/env perl
> sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua
> Nilsen
> getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#
> '3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is
> near! :)
>

Re: why not raku ?

[rir]

 CURI?

rob

Re: why not raku ?

[Aureliano Guedes]

Hi Clifton Wood,
Here it is.
https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-functions-from-raku-using-the-nativecall-interface/

It was, by far, the best example I founded.
But as simple as it is, I fail to call functions from xframe
 to raku.

You'll also find examples here

which are quite old.
And practical implementation in this repo on github
.




On Mon, Nov 22, 2021 at 11:49 AM Clifton Wood 
wrote:

> Aureliano, where was this example for C++? I'd love to take a look at it!
>
> Raku could really use a dose of Qt.
>
> On Mon, Nov 22, 2021 at 8:52 AM Salve J Nilsen  wrote:
>
>> Piper H said:
>>
>> > Has Larry Wall joined the development team of raku?
>>
>> He's been part of it since the very beginning. He's also on this list,
>> chipping in now and then (last time was in June this year).
>>
>>
>> - Salve
>>
>> --
>> #!/usr/bin/env perl
>> sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua
>> Nilsen
>> getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#> >
>> '3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is
>> near! :)
>>
>

-- 
Aureliano Guedes
skype: aureliano.guedes
contato:  (11) 94292-6110
whatsapp +5511942926110

Re: why not raku ?

[Clifton Wood]

Aureliano:

How are you attempting to call xframe functions?

On Mon, Nov 22, 2021 at 11:24 AM Aureliano Guedes <
guedes.aureli...@gmail.com> wrote:

> Hi Clifton Wood,
> Here it is.
> https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-functions-from-raku-using-the-nativecall-interface/
>
> It was, by far, the best example I founded.
> But as simple as it is, I fail to call functions from xframe
>  to raku.
>
> You'll also find examples here
> 
> which are quite old.
> And practical implementation in this repo on github
> .
>
>
>
>
> On Mon, Nov 22, 2021 at 11:49 AM Clifton Wood 
> wrote:
>
>> Aureliano, where was this example for C++? I'd love to take a look at it!
>>
>> Raku could really use a dose of Qt.
>>
>> On Mon, Nov 22, 2021 at 8:52 AM Salve J Nilsen  wrote:
>>
>>> Piper H said:
>>>
>>> > Has Larry Wall joined the development team of raku?
>>>
>>> He's been part of it since the very beginning. He's also on this list,
>>> chipping in now and then (last time was in June this year).
>>>
>>>
>>> - Salve
>>>
>>> --
>>> #!/usr/bin/env perl
>>> sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua
>>> Nilsen
>>> getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#<
>>> s...@foo.no>
>>> '3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is
>>> near! :)
>>>
>>
>
> --
> Aureliano Guedes
> skype: aureliano.guedes
> contato:  (11) 94292-6110
> whatsapp +5511942926110
>

Re: why not raku ?

[Aureliano Guedes]

Clifton, I think the best solution is wrap with C and then use Raku's
NativeCall.

Like this example


#include 

extern "C"
{
std::vector* intvec_new() { return new std::vector(); }
void intvec_free(std::vector* vec) { delete v; }
// etc. pp.
}


#!/usr/bin/env raku
use NativeCall;

sub holler(Str) is native('cpptest-extern-c') { ... }
holler('Hello World');


But I really don't know if it is the best strategy.
Actually, I really hope to see in some near future the NativeCall working
easy and well with C++ libs.



On Mon, Nov 22, 2021 at 2:50 PM Clifton Wood  wrote:

> Aureliano:
>
> How are you attempting to call xframe functions?
>
> On Mon, Nov 22, 2021 at 11:24 AM Aureliano Guedes <
> guedes.aureli...@gmail.com> wrote:
>
>> Hi Clifton Wood,
>> Here it is.
>> https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-functions-from-raku-using-the-nativecall-interface/
>>
>> It was, by far, the best example I founded.
>> But as simple as it is, I fail to call functions from xframe
>>  to raku.
>>
>> You'll also find examples here
>> 
>> which are quite old.
>> And practical implementation in this repo on github
>> .
>>
>>
>>
>>
>> On Mon, Nov 22, 2021 at 11:49 AM Clifton Wood 
>> wrote:
>>
>>> Aureliano, where was this example for C++? I'd love to take a look at it!
>>>
>>> Raku could really use a dose of Qt.
>>>
>>> On Mon, Nov 22, 2021 at 8:52 AM Salve J Nilsen  wrote:
>>>
 Piper H said:

 > Has Larry Wall joined the development team of raku?

 He's been part of it since the very beginning. He's also on this list,
 chipping in now and then (last time was in June this year).


 - Salve

 --
 #!/usr/bin/env perl
 sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua
 Nilsen
 getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#<
 s...@foo.no>
 '3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is
 near! :)

>>>
>>
>> --
>> Aureliano Guedes
>> skype: aureliano.guedes
>> contato:  (11) 94292-6110
>> whatsapp +5511942926110
>>
>

-- 
Aureliano Guedes
skype: aureliano.guedes
contato:  (11) 94292-6110
whatsapp +5511942926110

Re: why not raku ?

[Clifton Wood]

Aureliano:

You are correct. That is an effective workaround, but it will be a
maintenance nightmare for large C++ libraries if you have to wrap every
method.

There has to be a better way.

- X

On Mon, Nov 22, 2021 at 1:06 PM Aureliano Guedes 
wrote:

> Clifton, I think the best solution is wrap with C and then use Raku's
> NativeCall.
>
> Like this example
> 
>
> #include 
>
> extern "C"
> {
> std::vector* intvec_new() { return new std::vector(); }
> void intvec_free(std::vector* vec) { delete v; }
> // etc. pp.
> }
>
>
> #!/usr/bin/env raku
> use NativeCall;
>
> sub holler(Str) is native('cpptest-extern-c') { ... }
> holler('Hello World');
>
>
> But I really don't know if it is the best strategy.
> Actually, I really hope to see in some near future the NativeCall working
> easy and well with C++ libs.
>
>
>
> On Mon, Nov 22, 2021 at 2:50 PM Clifton Wood 
> wrote:
>
>> Aureliano:
>>
>> How are you attempting to call xframe functions?
>>
>> On Mon, Nov 22, 2021 at 11:24 AM Aureliano Guedes <
>> guedes.aureli...@gmail.com> wrote:
>>
>>> Hi Clifton Wood,
>>> Here it is.
>>> https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-functions-from-raku-using-the-nativecall-interface/
>>>
>>> It was, by far, the best example I founded.
>>> But as simple as it is, I fail to call functions from xframe
>>>  to raku.
>>>
>>> You'll also find examples here
>>> 
>>> which are quite old.
>>> And practical implementation in this repo on github
>>> .
>>>
>>>
>>>
>>>
>>> On Mon, Nov 22, 2021 at 11:49 AM Clifton Wood 
>>> wrote:
>>>
 Aureliano, where was this example for C++? I'd love to take a look at
 it!

 Raku could really use a dose of Qt.

 On Mon, Nov 22, 2021 at 8:52 AM Salve J Nilsen  wrote:

> Piper H said:
>
> > Has Larry Wall joined the development team of raku?
>
> He's been part of it since the very beginning. He's also on this list,
> chipping in now and then (last time was in June this year).
>
>
> - Salve
>
> --
> #!/usr/bin/env perl
> sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve
> Joshua Nilsen
> getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#<
> s...@foo.no>
> '3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is
> near! :)
>

>>>
>>> --
>>> Aureliano Guedes
>>> skype: aureliano.guedes
>>> contato:  (11) 94292-6110
>>> whatsapp +5511942926110
>>>
>>
>
> --
> Aureliano Guedes
> skype: aureliano.guedes
> contato:  (11) 94292-6110
> whatsapp +5511942926110
>

Re: why not raku ?

[Tom Browder]

On Mon, Nov 22, 2021 at 12:13 PM Clifton Wood  wrote:
> Aureliano:
> You are correct. That is an effective workaround, but it will be a 
> maintenance nightmare for large C++ libraries if you have to wrap every 
> method.
> There has to be a better way.

Not so easy to find in the docs, but here is a useful module that
might be the first place to start helping with:

  https://github.com/Skarsnik/gptrixie

It says support for C++ is planned.

-Tom (aka 'tbrowder' on #raku)

why not raku ?

[Clifton Wood]

Tom: Thanks for the mention of gptrixie. I am aware of it. When C++
support is added, I will circle back to it.

> Not so easy to find in the docs, but here is a useful module that might be 
> the first place to start helping with: https://github.com/Skarsnik/gptrixie 
> It says support for C++ is planned. -Tom (aka 'tbrowder' on #raku)

Re: why not raku ?

[Ralph Mellor]

On Mon, Nov 22, 2021 at 3:33 AM Clifton Wood  wrote:
>
> It has two compelling use cases, and it's the ones that
> brought me to Raku in the first place:

It has compelling use cases for me too, and I agree that
grammars and nativecall are both contenders. :)

But, fwiw, I didn't say just "compelling use cases" but:

> no widely recognized distinctive compelling use case

In other words, use cases folk out there know about, and
that what they know about them makes them stand out.

(Btw, I certainly don't think we should be trying to *promote*
them to make them known and stand out. When they're ready,
they'll promote themselves.)

Imo the primary weakness with grammars for now is speed.

Aiui the primary weakness with nativecall is header conversion.

> I've written utilities that make much of the work of
> porting an .h file as simple as running a single script.

That's the ticket! :)

> I have to overcome the CURI output limitations first.

Right. Needs more polish, or even heavy duty work, is
still the case for a lot of what Raku(do) have to offer.

I anticipate things will just keep on improving, and newcomers
will keep on turning up.

> I guess I'll be releasing the first lib sometime soon.

Either way -- sooner or later -- it sounds like just the ticket. :)

--
love, raiph