New search for Raku documentation page

[Richard Hainsworth]

Hi everyone,

A new search facility has been developed for the Raku documentation 
site. It would be useful to get some feedback.


The new search can be tested at 'https://new-raku.finanalyst.org'. Try 
clicking on the 'i' button next to the search panel for information.


The search interface is as close as possible to the previous interface 
(which is still in use on docs.raku.org and docs-dev.raku.org).


Please comment in the issue opened on github.com/Raku/doc-website

Several shortcuts  have been added, and feedback on which shortcuts to 
have  as defaults would be helpful. Ditto for the default values of some 
options.


Regards,

Richard Hainsworth, aka finanalyst

Re: New doc site

[ToddAndMargo via perl6-users]

On Tue, Feb 28, 2023 at 1:12 AM ToddAndMargo via perl6-users
 wrote:




http://raku.docs.org

At first glance, this looks like a treasure trove.

I did not see anything about GUI programming,
but I did not look that close.



On 2/28/23 16:32, Will Coleda wrote:
> Sorry, there is no GUI programming that's part of the core; the docs
> site is for the language spec and any core modules.
>

Hi Will,

It would be nice at some point to have the ability
to have a window pop up and fill in values, etc..

-T

Re: New doc site

[Will Coleda]

Sorry, there is no GUI programming that's part of the core; the docs
site is for the language spec and any core modules.

On Tue, Feb 28, 2023 at 1:12 AM ToddAndMargo via perl6-users
 wrote:
>
>
> > http://raku.docs.org
> At first glance, this looks like a treasure trove.
>
> I did not see anything about GUI programming,
> but I did not look that close.

Re: New doc site

[ToddAndMargo via perl6-users]

http://raku.docs.org

At first glance, this looks like a treasure trove.

I did not see anything about GUI programming,
but I did not look that close.

Re: New doc site

[yary]

Really liking the look of the site and responsiveness of the search bar-
first impression 
-y


On Mon, Feb 27, 2023 at 10:54 AM Will Coleda  wrote:

> Embarrassing!
>
> Thanks for catching that, thankful she got it right in the weekly!
>
>
> On Mon, Feb 27, 2023 at 8:51 AM Marcel Timmerman  wrote:
> >
> > On 27-02-2023 01:08, Will Coleda wrote:
> > > Since I know not everyone is on IRC:
> > >
> > > The updated raku.docs.org site is now live! Big thanks to everyone who
> > > helped make this happen!
> > >
> > > If you find any issues please let me know at
> > >
> > > https://github.com/raku/doc/issues - content
> > >
> > > https://github.com/raku/doc-website/issues - site, search, styling,
> etc.
> > Hi Will,
> >
> > Thanks for all the effort you and all writers/debuggers have put into it.
> > A small typo above though; 'raku.docs.org' should be
> > 'https://docs.raku.org/'.  However, I could find it via the weekly post
> > of Elizabeth.
> >
> > Thanks again,
> > Marcel
>

Re: New doc site

[Will Coleda]

Embarrassing!

Thanks for catching that, thankful she got it right in the weekly!


On Mon, Feb 27, 2023 at 8:51 AM Marcel Timmerman  wrote:
>
> On 27-02-2023 01:08, Will Coleda wrote:
> > Since I know not everyone is on IRC:
> >
> > The updated raku.docs.org site is now live! Big thanks to everyone who
> > helped make this happen!
> >
> > If you find any issues please let me know at
> >
> > https://github.com/raku/doc/issues - content
> >
> > https://github.com/raku/doc-website/issues - site, search, styling, etc.
> Hi Will,
>
> Thanks for all the effort you and all writers/debuggers have put into it.
> A small typo above though; 'raku.docs.org' should be
> 'https://docs.raku.org/'.  However, I could find it via the weekly post
> of Elizabeth.
>
> Thanks again,
> Marcel

Re: New doc site

[Marcel Timmerman]

On 27-02-2023 01:08, Will Coleda wrote:

Since I know not everyone is on IRC:

The updated raku.docs.org site is now live! Big thanks to everyone who
helped make this happen!

If you find any issues please let me know at

https://github.com/raku/doc/issues - content

https://github.com/raku/doc-website/issues - site, search, styling, etc.

Hi Will,

Thanks for all the effort you and all writers/debuggers have put into it.
A small typo above though; 'raku.docs.org' should be 
'https://docs.raku.org/'.  However, I could find it via the weekly post 
of Elizabeth.


Thanks again,
Marcel

New doc site

[Will Coleda]

Since I know not everyone is on IRC:

The updated raku.docs.org site is now live! Big thanks to everyone who
helped make this happen!

If you find any issues please let me know at

https://github.com/raku/doc/issues - content

https://github.com/raku/doc-website/issues - site, search, styling, etc.

Re: When to use .new?

[ToddAndMargo via perl6-users]

On 12/5/22 11:19, Ralph Mellor wrote:

I forgot to mention one other shortcut that is always available
if you do have to use `.new` (which is the case for most types).

You can write:
```
my $foo = 42;
```
The `42` on the RHS of the `=` is the shortest way to create
an integer value corresponding to `42`.

But you could also write:
```
my $foo = Int.new: 42;
```
It's odd, but you could that. You could also write:

```
my Int $foo .= new: 42;
```
Note the `.=` instead of `=` and the `new` instead of `Int.new`.

That is, if you constrain a variable's type, and want to initialize
that variable to a value of exactly that type, you don't have to
repeat the type name on the RHS of the `=` if you write it as above.

For types that have literal forms it's not helpful. And for short type
names it's helpful, but only a little. But let's say you really wanted
to write out the full `NativeCall::Types::Pointer` and you wanted a
variable constrained to that type and initialized to have a value of
that type. Now it's a big deal:

```
my NativeCall::Types::Pointer $foo .= new: 42;
```

--
raiph


Hi Ralph,

Thank you for the excellent explanation!

Is there a list of what variables/object
I have to use .new with and which ones I
don't?

-T

Re: When to use .new?

[Ralph Mellor]

I forgot to mention one other shortcut that is always available
if you do have to use `.new` (which is the case for most types).

You can write:
```
my $foo = 42;
```
The `42` on the RHS of the `=` is the shortest way to create
an integer value corresponding to `42`.

But you could also write:
```
my $foo = Int.new: 42;
```
It's odd, but you could that. You could also write:

```
my Int $foo .= new: 42;
```
Note the `.=` instead of `=` and the `new` instead of `Int.new`.

That is, if you constrain a variable's type, and want to initialize
that variable to a value of exactly that type, you don't have to
repeat the type name on the RHS of the `=` if you write it as above.

For types that have literal forms it's not helpful. And for short type
names it's helpful, but only a little. But let's say you really wanted
to write out the full `NativeCall::Types::Pointer` and you wanted a
variable constrained to that type and initialized to have a value of
that type. Now it's a big deal:

```
my NativeCall::Types::Pointer $foo .= new: 42;
```

--
raiph

Re: When to use .new?

[Ralph Mellor]

On Thu, Dec 1, 2022 at 4:28 AM ToddAndMargo via perl6-users
 wrote:
>
> Why can I get away with `my Str $x = "";`
>
> But I have to use .new here (an other places too) `my $ppSession = 
> NativeCall::Types::Pointer.new();`

There are ways to write the value of some data types with minimum fuss.

This is typically the case for oft used types like strings and numbers.

Many programming languages have "literals" as the ultimate no fuss way.

Raku has them for strings and numbers:

```
"this is a string"
42 # <-- `42` is a number, an integer
```

You create a string by just writing its value inside quote marks.

You create a number by just writing its value.

The `.new` is implicit, happening behind the scenes.



It's not practical to have "literal" short cuts for *all* data types.

While code corresponding to pointers (and dereferences of them)
is *explicitly* written a LOT in C, explicit pointer coding is almost
completely eliminated in Raku.

The only exception is in some NativeCall code that makes a lot of
use of its `Pointer` type for representing a Raku wrapped C Pointer.

Is that enough to justify introducing a "literal" form for `Pointer`s?

I doubt it. But if you wanted to explore that, Raku makes it possible.

> Is there some rule I can follow that let me know when I have to
> use `.new and when I do not?

About the only rule there can be for arbitrary Raku code is whether
you already know a way to create a value without using `.new`, or
have time available to investigate the two approaches. For builtin
types that means reading the official Raku doc. For user defined
types defined in modules you use that means reading the doc of
those modules.

But in general the vast majority of types require use of `.new`.

The main exceptions I can think of are strings, numbers, pairs,
and basic collections. (Untyped lists, captures, positional arrays,
and associative arrays -- hashes etc.)

> (I am getting tired of figuring it out the hard way.)

I found it easy because I didn't *try* to find out but was just
delighted each time I realized there was yet another nice and
even shorter way to create values.

One thing I note in this context here is that one doesn't have to
write out the fully qualified type name `NativeCall::Types::Pointer`.

One can just write `Pointer`.

(NativeCall introduces this short form by default if you write `use
NativeCall;`)

--
raiph

When to use .new?

[ToddAndMargo via perl6-users]

Hi All,

Why can I get away with

   my Str $x = "";

But I have to use .new here (an other places too)

   my $ppSession = NativeCall::Types::Pointer.new();


Is there some rule I can follow that let me know
when I have to use .new and when I do not?
(I am getting tired of figuring it out the
hard way.)

Many thanks,
-T

Re: How in Raku can a symlink be edited to a new target, if the target is a directory.

[Richard Hainsworth]

Ignore this message.

It turns out I had set up my file structure incorrectly, so the 
description below is wrong and the problem is elsewhere. Raku handles a 
symlink to a directory correctly.


On 07/11/2022 9:55 am, Richard Hainsworth wrote:
I want - in a Raku program - update a symlink from 'plug-v1' to 
'plug-v2', where both plug-v1 and plug-v2 are sub-directories of 
'src'. The symlink is 'plug'.


I am using Ubuntu.

First time I create symlink with

'src/plug-v1'.IO.symlink( 'plug' );

If now I want to change the link, then the following

'src/plug-v2'.IO.symlink( 'plug' );

causes the error:

Failed to symlink file: file already exists

This is understandable.

So then I tried

'plug'.IO.unlink if 'plug'.IO ~~ :e;

'src/plug-v2'.IO.symlink( 'plug' );

This seems to work in a test file in which I create the directories 
then symlink and unlink.


However, when I try this sequence in a Raku script on a symlink that 
exists before the program runs, I get the error


Failed to delete file: illegal operation on a directory in block 
 at test.raku line 18


where line 18 corresponds to the " 'plug'.IO.unlink " statement.

Looking at the documentation for "*nix", I see that in some flavours 
of Unix, 'unlink' deletes a directory, rather than removing a symlink. 
I can see therefore that since 'plug' is a symlink to a directory, 
Raku is forbidding the operation.


There are some options to unlink that seem to get round this problem, 
but those options do not seem to exist (or are not documented) in Raku.


How do I achieve programatically in Raku an edit of a symlink to a new 
target, if the target is a directory.

How in Raku can a symlink be edited to a new target, if the target is a directory.

[Richard Hainsworth]

I want - in a Raku program - update a symlink from 'plug-v1' to 
'plug-v2', where both plug-v1 and plug-v2 are sub-directories of 'src'. 
The symlink is 'plug'.


I am using Ubuntu.

First time I create symlink with

'src/plug-v1'.IO.symlink( 'plug' );

If now I want to change the link, then the following

'src/plug-v2'.IO.symlink( 'plug' );

causes the error:

Failed to symlink file: file already exists

This is understandable.

So then I tried

'plug'.IO.unlink if 'plug'.IO ~~ :e;

'src/plug-v2'.IO.symlink( 'plug' );

This seems to work in a test file in which I create the directories then 
symlink and unlink.


However, when I try this sequence in a Raku script on a symlink that 
exists before the program runs, I get the error


Failed to delete file: illegal operation on a directory in block  
at test.raku line 18


where line 18 corresponds to the " 'plug'.IO.unlink " statement.

Looking at the documentation for "*nix", I see that in some flavours of 
Unix, 'unlink' deletes a directory, rather than removing a symlink. I 
can see therefore that since 'plug' is a symlink to a directory, Raku is 
forbidding the operation.


There are some options to unlink that seem to get round this problem, 
but those options do not seem to exist (or are not documented) in Raku.


How do I achieve programatically in Raku an edit of a symlink to a new 
target, if the target is a directory.

Re: Greeting Larry Wall: I will learn to love you new language.

[Ralph Mellor]

On Sat, Dec 25, 2021 at 4:31 PM Maneesh Sud via perl6-users
 wrote:
>
> Merry Christmas and a Happy New Year.

Hi. Happy holidays to you too.

> Does perl6 or moarvm run on risc-v 32-bit processors.

I think a key piece is dyncall/libffi support. Googling suggests
dyncall doesn't support risc-v but libffi does. But I really don't
know much about such things.

I recommend you focus on the IRC channel #moarvm rather
than this mailing list for more info/discussion of such matters.
The channel is publicly logged and searchable. My search for
`risc` draws a blank:
https://logs.liz.nl/search.html?query=risc=words==moarvm;
message-type==2013-11-04=2021-12-26

I suggest you log on there and ask. Here's a web client link:
https://kiwiirc.com/nextclient/irc.libera.chat/#moarvm

Good luck and happy holidays!

--
love, raiph

Greeting Larry Wall: I will learn to love you new language.

[Maneesh Sud via perl6-users]

Merry Christmas and a Happy New Year.
Does perl6 or moarvm run on risc-v 32-bit processors. how much RAM do I need.
Do I need RTOS and Java or is there another way to boot strap.
uClinux is now part of the main kernel any ports to risc5 microcontrollers.
Reference designs including PCB for a micro that can run perl and supports Wifi 
and BLE.

I bought two ESP32-C3. I supports BLE Long Range.

Sent with ProtonMail Secure Email.

Re: Why does .new initialize?

[William Michels via perl6-users]

Possibly relevant StackOverflow question:

"Why does constraining a Perl 6 named parameter to a definite value make it
a required value?"
https://stackoverflow.com/questions/48166325/why-does-constraining-a-perl-6-named-parameter-to-a-definite-value-make-it-a-req

On Mon, Jul 19, 2021 at 10:00 AM Peter Scott  wrote:

> On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
> > If .new wouldn't initialize a type to its basic instantiation, what
> would be the point of .new then?
> >
> > FWIW, the same goes for:
> >
> >  dd Int.new;  # 0
> >  dd Num.new;  # 0e0
> >  dd Complex.new;  # <0+0i>
> >  dd Str.new;  # ""
> >
> > If you want to leave it undefined, don't call .new on it?
> >
> > *confused*
>
> Only that there's a vocal school of thought in O-O that says new()
> should only allocate memory and never put anything in there.  Now I know
> that Raku doesn't subscribe to that I have no problem.
>
> Cheers,
> Peter
>

Re: Why does .new initialize?

[Vadim Belman]

Matthew has provided some concrete examples of default initializations. I'd 
like to scratch the surface of more general problem: encapsulation. In many 
cases only a class knows it's real internal structure and can use this 
information to protect the data from misuse by 3rd party code which may not 
have the sufficient level of knowledge. If we deprive a class the right of 
self-initializing according what it knows will be a correct state then what 
remains of the encapsulation principle?

Let me make a guess. Perhaps the meaning of "new() should only allocate memory 
and never put anything in there" statement is a bit different. Perhaps the 
initial discussion was about the method new() in particular. It probably stems 
from the early days of Perl OO when more or less typical code was something like

sub new {
my $self = bless {}, shift;
$self->{foo} = 13;
$self->{bar} = 42;
return $self;
}

Then moving the initialization lines for attributes foo and bar out of new() 
makes full sense. One of the approaches taken before the Moose epoch was:

sub new {
my $self = bless {}, shift;
$self->init(@_);
return $self;
}

This was solving some pretty much common errors in class design and allowed the 
child classes to implement their own init() methods without actually worrying 
about object's origins.

Getting back to Raku, the principle is carefully followed because it's new() 
doesn't do any actual object initialization. Instead it re-delegates it down to 
submethods BUILDALL, BUILD, TWEAK. Apparently, it is possible to literally 
follow the principle and split pure new and initialization code. But how much 
happy would you be writing something like Class.new.INITIALIZE(:foo(13), 
:bar(42)) every time? And how much sense would it make?

Best regards,
Vadim Belman

> On Jul 19, 2021, at 1:09 PM, Peter Scott  wrote:
> 
> Yes.  I'm agnostic on this point, but there was a time when some prominent 
> Perl contributors were dogmatic about it and I didn't know how widespread it 
> was.
> 
> Peter
> 
> On 7/19/2021 10:06 AM, Vadim Belman wrote:
>> 
>> Let me guess. The school prohibits object self-initialization? It has to be 
>> done by external code?
>> 
>> Best regards,
>> Vadim Belman
>> 
>>> On Jul 19, 2021, at 1:00 PM, Peter Scott >> <mailto:pe...@psdt.com>> wrote:
>>> 
>>> On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
>>>> If .new wouldn't initialize a type to its basic instantiation, what would 
>>>> be the point of .new then?
>>>> 
>>>> FWIW, the same goes for:
>>>> 
>>>> dd Int.new;  # 0
>>>> dd Num.new;  # 0e0
>>>> dd Complex.new;  # <0+0i>
>>>> dd Str.new;  # ""
>>>> 
>>>> If you want to leave it undefined, don't call .new on it?
>>>> 
>>>> *confused*
>>> 
>>> Only that there's a vocal school of thought in O-O that says new() should 
>>> only allocate memory and never put anything in there.  Now I know that Raku 
>>> doesn't subscribe to that I have no problem.
>>> 
>>> Cheers,
>>> Peter
>> 
> 

Re: Why does .new initialize?

[Matthew Stuckwisch]

In general, the idea of initialized doesn't mean a lot in Raku, at least
not at the language level.

At any given time, any variable has a value. By default, if you've typed a
variable, it's initially set to the type itself (Any is the default type,
so the default default value). The only exceptions are native types which
are either 0 or the empty string, depending, or if you've added a trait to
override the default value. Note the following, which may be a bit
surprising to you:

my Int $a;
my $b = Int;
my $c;
say $a === $b === Int; # True
say $c === $a; # False

$c's value here is (Any), but both $a and $b are (Int).

.new calls self.bless, which handles all of the allocation stuff behind the
scenes, but —importantly— each attribute, like any variable, will always
have a value (it just might not be defined), such that

class Foo {
has Rat $.bar;
}
say Foo.new.bar === Rat; # True
say Foo.new.bar.defined; # False

In some classes, undefined values for those attributes may not make sense,
and each can make its own decisions how to handle when lacking defined
values.

Hope that makes sense,

Matéu

On Mon, Jul 19, 2021, 19:10 Peter Scott  wrote:

> Yes.  I'm agnostic on this point, but there was a time when some prominent
> Perl contributors were dogmatic about it and I didn't know how widespread
> it was.
>
> Peter
>
> On 7/19/2021 10:06 AM, Vadim Belman wrote:
>
>
> Let me guess. The school prohibits object self-initialization? It has to
> be done by external code?
>
> Best regards,
> Vadim Belman
>
> On Jul 19, 2021, at 1:00 PM, Peter Scott  wrote:
>
> On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
>
> If .new wouldn't initialize a type to its basic instantiation, what would
> be the point of .new then?
>
> FWIW, the same goes for:
>
> dd Int.new;  # 0
> dd Num.new;  # 0e0
> dd Complex.new;  # <0+0i>
> dd Str.new;  # ""
>
> If you want to leave it undefined, don't call .new on it?
>
> *confused*
>
>
> Only that there's a vocal school of thought in O-O that says new() should
> only allocate memory and never put anything in there.  Now I know that Raku
> doesn't subscribe to that I have no problem.
>
> Cheers,
> Peter
>
>
>
>

Re: Why does .new initialize?

[Peter Scott]

Yes.  I'm agnostic on this point, but there was a time when some 
prominent Perl contributors were dogmatic about it and I didn't know how 
widespread it was.


Peter

On 7/19/2021 10:06 AM, Vadim Belman wrote:


Let me guess. The school prohibits object self-initialization? It has 
to be done by external code?


Best regards,
Vadim Belman

On Jul 19, 2021, at 1:00 PM, Peter Scott <mailto:pe...@psdt.com>> wrote:


On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
If .new wouldn't initialize a type to its basic instantiation, what 
would be the point of .new then?


FWIW, the same goes for:

dd Int.new;  # 0
dd Num.new;  # 0e0
dd Complex.new;  # <0+0i>
dd Str.new;  # ""

If you want to leave it undefined, don't call .new on it?

*confused*


Only that there's a vocal school of thought in O-O that says new() 
should only allocate memory and never put anything in there.  Now I 
know that Raku doesn't subscribe to that I have no problem.


Cheers,
Peter

Re: Why does .new initialize?

[Vadim Belman]

Let me guess. The school prohibits object self-initialization? It has to be 
done by external code?

Best regards,
Vadim Belman

> On Jul 19, 2021, at 1:00 PM, Peter Scott  wrote:
> 
> On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
>> If .new wouldn't initialize a type to its basic instantiation, what would be 
>> the point of .new then?
>> 
>> FWIW, the same goes for:
>> 
>> dd Int.new;  # 0
>> dd Num.new;  # 0e0
>> dd Complex.new;  # <0+0i>
>> dd Str.new;  # ""
>> 
>> If you want to leave it undefined, don't call .new on it?
>> 
>> *confused*
> 
> Only that there's a vocal school of thought in O-O that says new() should 
> only allocate memory and never put anything in there.  Now I know that Raku 
> doesn't subscribe to that I have no problem.
> 
> Cheers,
> Peter

Re: Why does .new initialize?

[Peter Scott]

On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:

If .new wouldn't initialize a type to its basic instantiation, what would be 
the point of .new then?

FWIW, the same goes for:

 dd Int.new;  # 0
 dd Num.new;  # 0e0
 dd Complex.new;  # <0+0i>
 dd Str.new;  # ""

If you want to leave it undefined, don't call .new on it?

*confused*


Only that there's a vocal school of thought in O-O that says new() 
should only allocate memory and never put anything in there.  Now I know 
that Raku doesn't subscribe to that I have no problem.


Cheers,
Peter

Re: Why does .new initialize?

[Elizabeth Mattijsen]

> On 19 Jul 2021, at 05:49, Peter Scott  wrote:
> 
> I'm curious as to why Rat.new initializes instead of leaving as undefined:
> 
> > $*RAKU
> Raku (6.d)
> > my Rat $p
> (Rat)
> > put $p
> Use of uninitialized value $p of type Rat in string context.
> Methods .^name, .raku, .gist, or .say can be used to stringify it to 
> something meaningful.
>   in block  at  line 1
> > my $q = Rat.new
> 0
> > put $q
> 0

If .new wouldn't initialize a type to its basic instantiation, what would be 
the point of .new then?

FWIW, the same goes for:

dd Int.new;  # 0
dd Num.new;  # 0e0
dd Complex.new;  # <0+0i>
    dd Str.new;  # ""

If you want to leave it undefined, don't call .new on it?

*confused*

Why does .new initialize?

[Peter Scott]

I'm curious as to why Rat.new initializes instead of leaving as undefined:

> $*RAKU
Raku (6.d)
> my Rat $p
(Rat)
> put $p
Use of uninitialized value $p of type Rat in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to 
something meaningful.

  in block  at  line 1
> my $q = Rat.new
0
> put $q
0


Peter Scott

new raku just hit: 2021.05

[ToddAndMargo via perl6-users]

GetRaku  new update downloaded  2021.04.02 --> 2021.05

https://github.com/nxadm/rakudo-pkg/releases

No idea what changed

new raku just hit: 2021.04.02

[ToddAndMargo via perl6-users]

Hi All,

https://github.com/nxadm/rakudo-pkg/releases

RakudoPkgFedora33-2021.04.02.x86_64.rpm

Installed without incident

:-)

-T

new rakudo

[ToddAndMargo via perl6-users]

Hi All,

I just saw an update come through for

https://github.com/nxadm/rakudo-pkg/releases

RakudoPkgFedora33-2020.12.x86_64.rpm
   -->
RakudoPkgFedora33-2020.12.04.x86_64.rpm

I have no idea what the changes are.

-T

IO::Socket::Async::SSL on new Linux

[Mark Devine]

Appreciation to https://github.com/jnthn for his recent update to 
https://github.com/jnthn/p6-io-socket-async-ssl.

My lab consists of the below Linux platforms, where the starred four 
distributions were snagged on IO::Socket::Async::SSL, thereby holding back cro. 
 Not tonight!

CentOS Linux release 7.9.2009 (Core)
*   CentOS Linux release 8.2.2004 (Core)
Debian GNU/Linux 10 (buster)
Fedora 32 (Thirty Two)
*   Fedora 33 (Thirty Three)
Oracle Linux Server 7.9
*   Oracle Linux Server 8.3
openSUSE Leap 15.2
Ubuntu 18.04.5 LTS
*   Ubuntu 20.04.1 LTS

Gratitude for getting cro via IO::Socket::Async::SSL enabled on these more 
recent distros.

- Mark

Re: New Raku 2020.10.02

[Todd Chester via perl6-users]

On 10/29/20 2:58 PM, Bruce Gray wrote:

I don't know if you are*supposed*  to have to do all this to "know what 
changed" (since I do not use those packages myself); I am just trying to answer the 
implied question.


I wrote a program that checks about 70 programs I support and
downloads new revisions.   It does not download release notes,
so I say I don't know what changed.

I was not asking for help.  Just informing.

Re: New Raku 2020.10.02

[Bruce Gray]

> On Oct 29, 2020, at 12:46 PM, ToddAndMargo via perl6-users 
>  wrote:
> 
> GetRaku  new update downloaded  2020.10 --> 2020.10.02
> 
> https://github.com/nxadm/rakudo-pkg/releases
> 
> I do not know what changed

The URL that you provided:
https://github.com/nxadm/rakudo-pkg/releases
says this (at the top) as the summary for the minor-version (Rakudo 
v2020.10-02) release:
Support for Fedora 33.
, and further down is the summary of the main (Rakudo v2020.10) release:
New upstream release.
, so the 2020.10 package was published to provide the new 2020.10 version of 
Rakudo, 
and then the 2020.10-02 package added support for the platform "Fedora 33".

If you would like to see the details, click the "Compare" drop-down to the left 
of Rakudo v2020.10-02 , and select tag "v2020.10".
This will show all the commits between the two releases (which you could 
explore in detail by clicking on each title or the hash),
followed by a (much more convenient!) summary of all the commits as one 
combined commit.

I don't know if you are *supposed* to have to do all this to "know what 
changed" (since I do not use those packages myself); I am just trying to answer 
the implied question.

-- 
Hope this helps,
Bruce Gray (Util of PerlMonks)

New Raku 2020.10.02

[ToddAndMargo via perl6-users]

GetRaku  new update downloaded  2020.10 --> 2020.10.02

https://github.com/nxadm/rakudo-pkg/releases

I do not know what changed

Re: Brace interpolation in strings creates a new scope?

[Sean McAfee]

On Mon, Oct 26, 2020 at 12:04 PM Elizabeth Mattijsen  wrote:

> Personally, I would avoid the use of the anonymous state variable.  I
> think it is an example where Larry would nowadays apply rule #2.
>

Well, I wouldn't use a construction like that in real code.  It just seems
like one of the simpler ways to introduce anonymous state variables.

For the end of my talk, I plan to explore a golfing challenge I worked on a
while ago that calls for zipping two infinite sequences together with the
replication operator xx, where the second sequence is:

1, 1, 2, 2, 3, 3, 4, 4, ...

I wasn't really happy with any of the ways I came up with to generate that
second sequence, like:

{ 1 + $++ div 2 } ... *
map * div 2, 2 .. *

Then I had the sudden inspiration that xx coerces its second argument to
Int, meaning all I really needed was:

1, 1.5 ... *

Re: Brace interpolation in strings creates a new scope?

[Patrick R. Michaud]

On Mon, Oct 26, 2020 at 08:04:21PM +0100, Elizabeth Mattijsen wrote:
> > On 26 Oct 2020, at 18:40, Sean McAfee  wrote:
> > Is this the intended behavior?  The doc page on quoting constructs 
> > just says that values can be interpolated with braces, but (at least 
> > to my eyes) doesn't suggest that this involves creating a new scope, 
> > or a new function, or however it is that this happens.
> 
> I guess we need to update the documentation.  But the braces inside a 
> double quoted string *do* create a new scope, causing the behaviour of 
> ++$ that you have seen.

In general Raku tries to avoid special cases... so I think that braces pretty 
much _always_ introduce a new scope.  I can't think of any exceptions at the 
moment, except for *maybe* when they are used as a hash constructor.  (And 
perhaps not even there.)

Of course I could be mistaken in this... but as a general rule, in language 
design there's been an effort to keep things consistent so that we don't have 
to say things like "braces create a new scope except when used in string 
interpolation" etc.

Pm

Re: Brace interpolation in strings creates a new scope?

[Elizabeth Mattijsen]

> On 26 Oct 2020, at 18:40, Sean McAfee  wrote:
> Is this the intended behavior?  The doc page on quoting constructs just says 
> that values can be interpolated with braces, but (at least to my eyes) 
> doesn't suggest that this involves creating a new scope, or a new function, 
> or however it is that this happens.

I guess we need to update the documentation.  But the braces inside a double 
quoted string *do* create a new scope, causing the behaviour of ++$ that you 
have seen.

> For my presentation I can just alter some lines to:
> 
> say "You called me ", ++$times, " times";
> 
> and
> 
> say "You called me ", ++$, " times";
> 
> ...but that seems a bit less elegant than what I had originally.

Alternately you could do:

   say "You called me " ~ ++$ ~ " times";

Personally, I would avoid the use of the anonymous state variable.  I think it 
is an example where Larry would nowadays apply rule #2.



Liz

Brace interpolation in strings creates a new scope?

[Sean McAfee]

I'm putting together a Raku presentation for my co-workers and have a
section on state variables.  This is my example:

sub how-many {
state $times;
say "You called me {++$times} times";
}

> how-many
You called me 1 times
> how-many
You called me 2 times
> how-many
You called me 3 times

Then I thought I'd mention anonymous state variables by modifying my
example thusly:

sub how-many {
say "You called me {++$} times";
}

But this gives:

> how-many
You called me 1 times
> how-many
You called me 1 times
> how-many
You called me 1 times

Is this the intended behavior?  The doc page on quoting constructs just
says that values can be interpolated with braces, but (at least to my eyes)
doesn't suggest that this involves creating a new scope, or a new function,
or however it is that this happens.

For my presentation I can just alter some lines to:

say "You called me ", ++$times, " times";

and

say "You called me ", ++$, " times";

...but that seems a bit less elegant than what I had originally.

Re: New type Stash for Block is not a mixin type

[Fernando Santagata]

It seems that Rakudo 2020.09 solved the regression problem!

On Sat, Sep 26, 2020 at 10:01 AM Fernando Santagata <
nando.santag...@gmail.com> wrote:

> Thank you, I'll see if I can concoct a self-contained example in order to
> open an issue.
>
> On Thu, Sep 24, 2020, 20:13 Elizabeth Mattijsen  wrote:
>
>> Feels like a regression worthy of a Rakudo issue
>>
>> > On 24 Sep 2020, at 20:26, Fernando Santagata 
>> wrote:
>> >
>> > Hello,
>> >
>> > Since I upgraded to the last Rakudo I'am having a weird problem. I have
>> a module like this:
>> >
>> > unit class Class1;
>> > etc.
>> >
>> > Then a second module:
>> >
>> > unit class Class2;
>> > use Class1;
>> > etc.
>> >
>> > In a program I need both modules, so it begins with two lines:
>> >
>> > use Class1;
>> > use Class2;
>> > etc.
>> >
>> > At this point if I run the program I get this error:
>> >
>> > New type Stash for Block is not a mixin type
>> >
>> > pointing to the line of code that uses Class2. If I remove the "use
>> Class1" line, that program works fine.
>> > But it bugs me, because I don't understand that behavior.
>> >
>> > Any hint?
>> > The whole thing worked fine using version 2020.07.
>> >
>> > --
>> > Fernando Santagata
>>
>

-- 
Fernando Santagata

New Raku

[ToddAndMargo via perl6-users]

GetRaku  new update downloaded  2020.08.2 --> 2020.09

I don't know what has changed though

https://github.com/nxadm/rakudo-pkg/releases

Re: New type Stash for Block is not a mixin type

[Fernando Santagata]

Thank you, I'll see if I can concoct a self-contained example in order to
open an issue.

On Thu, Sep 24, 2020, 20:13 Elizabeth Mattijsen  wrote:

> Feels like a regression worthy of a Rakudo issue
>
> > On 24 Sep 2020, at 20:26, Fernando Santagata 
> wrote:
> >
> > Hello,
> >
> > Since I upgraded to the last Rakudo I'am having a weird problem. I have
> a module like this:
> >
> > unit class Class1;
> > etc.
> >
> > Then a second module:
> >
> > unit class Class2;
> > use Class1;
> > etc.
> >
> > In a program I need both modules, so it begins with two lines:
> >
> > use Class1;
> > use Class2;
> > etc.
> >
> > At this point if I run the program I get this error:
> >
> > New type Stash for Block is not a mixin type
> >
> > pointing to the line of code that uses Class2. If I remove the "use
> Class1" line, that program works fine.
> > But it bugs me, because I don't understand that behavior.
> >
> > Any hint?
> > The whole thing worked fine using version 2020.07.
> >
> > --
> > Fernando Santagata
>

Re: New type Stash for Block is not a mixin type

[Elizabeth Mattijsen]

Feels like a regression worthy of a Rakudo issue

> On 24 Sep 2020, at 20:26, Fernando Santagata  
> wrote:
> 
> Hello,
> 
> Since I upgraded to the last Rakudo I'am having a weird problem. I have a 
> module like this:
> 
> unit class Class1;
> etc.
> 
> Then a second module:
> 
> unit class Class2;
> use Class1;
> etc.
> 
> In a program I need both modules, so it begins with two lines:
> 
> use Class1;
> use Class2;
> etc.
> 
> At this point if I run the program I get this error:
> 
> New type Stash for Block is not a mixin type
> 
> pointing to the line of code that uses Class2. If I remove the "use Class1" 
> line, that program works fine.
> But it bugs me, because I don't understand that behavior.
> 
> Any hint?
> The whole thing worked fine using version 2020.07.
> 
> -- 
> Fernando Santagata

New type Stash for Block is not a mixin type

[Fernando Santagata]

Hello,

Since I upgraded to the last Rakudo I'am having a weird problem. I have a
module like this:

unit class Class1;
etc.

Then a second module:

unit class Class2;
use Class1;
etc.

In a program I need both modules, so it begins with two lines:

use Class1;
use Class2;
etc.

At this point if I run the program I get this error:

New type Stash for Block is not a mixin type

pointing to the line of code that uses Class2. If I remove the "use Class1"
line, that program works fine.
But it bugs me, because I don't understand that behavior.

Any hint?
The whole thing worked fine using version 2020.07.

-- 
Fernando Santagata

Re: How to I modify what is a new line in lines?

[ToddAndMargo via perl6-users]

On 2020-08-31 18:54, William Michels via perl6-users wrote:

On Mon, Aug 31, 2020 at 6:07 PM ToddAndMargo via perl6-users
 wrote:


On 2020-08-31 17:21, yary wrote:

First part of my previous email on this thread! Re-read this bit


First, you were looking at the docs for Path's "lines", but you are
using a string "lines" and those docs say

multi method lines(Str:D: $limit, :$chomp = True)
multi method lines(Str:D: :$chomp = True)

Files get "nl-in" due to the special case of text files having various
line endings to tweak.

Strings already have "split" and "comb" for all the flexibility one may
need there, and what you're playing with is more naturally
dd $_ for $x.split("\t"); # "a","b", ... removes \t
dd $_ for $x.split(//); "a\t","b\t", 


and restating the above: "string".lines is different a different method
from "File.txt".IO.lines, which is also different from
"File.txt".IO.open.lines .  Yes that's confusing but there are reasons
for all that which make sense when one thinks about them a while.

So if you want to split a string, use split!

If you want to experiment a text file's line endings with "lines", do
that experiment with a file! Which was the 2nd part of my previous email


dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
"Li"
"ne 0\n"
"Li"
"ne 1\n"


-y


Hi Yary,

I think I am getting it.  I am confusing str with file.

In the following, LineTabs.txt is
"Line 1\tLine 2\tLine 3\tLine 4\t"

$ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :!chomp,
:nl-in["\t"])[1,2,0];'
"Line 1\t"
"Line 2\t"
"Line 0\t"

$ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :chomp,
:nl-in["\t"])[1,2,0];'
"Line 1"
"Line 2"
"Line 0"

I am having trouble wrapping my mind around `dd $_ for`.  What
exactly is going on?

-T


dd is the data-dumper function. Used for debugging. See:

https://docs.raku.org/programs/01-debugging#index-entry-dd

Below, you're calling dd on $_ , which is why you don't have/need a
call to print/put/say in that line of code. It's dd() that's giving
you output:

$ raku -e 'dd($_) for "LinesTabs.txt".IO.lines( :chomp, :nl-in["\t"])[1,2,0];'

HTH, Bill.



Hi Bill,

I get it now.  The "$_" is coming from "for" not the "dd".

raku -e 'dd($_) for "LinesTabs.txt".IO.lines( :chomp, :nl-in["\t"])[1,2,0];'

Is a reverse way of saying:

$ raku -e 'for "LinesTabs.txt".IO.lines( :chomp, :nl-in["\t"])[1,2,0] 
{dd $_;}'


"Line 1"
"Line 2"
"Line 0"


$ raku -e 'for "LinesTabs.txt".IO.lines(:!chomp, :nl-in["\t"])[1,2,0] 
{dd $_;}'


"Line 1\t"
"Line 2\t"
"Line 0\t"

Thank you!

:-)

-T

p.s. I almost never use the reverse method because my
eyes have to go back and forth to figure it out,
not left to right.  I do see the utility it it though.
Maybe when I get better at it.

Re: How to I modify what is a new line in lines?

[William Michels via perl6-users]

On Mon, Aug 31, 2020 at 6:07 PM ToddAndMargo via perl6-users
 wrote:
>
> On 2020-08-31 17:21, yary wrote:
> > First part of my previous email on this thread! Re-read this bit
> >
> >> First, you were looking at the docs for Path's "lines", but you are
> >> using a string "lines" and those docs say
> >>
> >> multi method lines(Str:D: $limit, :$chomp = True)
> >> multi method lines(Str:D: :$chomp = True)
> >>
> >> Files get "nl-in" due to the special case of text files having various
> >> line endings to tweak.
> >>
> >> Strings already have "split" and "comb" for all the flexibility one may
> >> need there, and what you're playing with is more naturally
> >> dd $_ for $x.split("\t"); # "a","b", ... removes \t
> >> dd $_ for $x.split(//); "a\t","b\t", 
> >
> > and restating the above: "string".lines is different a different method
> > from "File.txt".IO.lines, which is also different from
> > "File.txt".IO.open.lines .  Yes that's confusing but there are reasons
> > for all that which make sense when one thinks about them a while.
> >
> > So if you want to split a string, use split!
> >
> > If you want to experiment a text file's line endings with "lines", do
> > that experiment with a file! Which was the 2nd part of my previous email
> >
> >> dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
> >> "Li"
> >> "ne 0\n"
> >> "Li"
> >> "ne 1\n"
> >
> > -y
>
> Hi Yary,
>
> I think I am getting it.  I am confusing str with file.
>
> In the following, LineTabs.txt is
> "Line 1\tLine 2\tLine 3\tLine 4\t"
>
> $ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :!chomp,
> :nl-in["\t"])[1,2,0];'
> "Line 1\t"
> "Line 2\t"
> "Line 0\t"
>
> $ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :chomp,
> :nl-in["\t"])[1,2,0];'
> "Line 1"
> "Line 2"
> "Line 0"
>
> I am having trouble wrapping my mind around `dd $_ for`.  What
> exactly is going on?
>
> -T

dd is the data-dumper function. Used for debugging. See:

https://docs.raku.org/programs/01-debugging#index-entry-dd

Below, you're calling dd on $_ , which is why you don't have/need a
call to print/put/say in that line of code. It's dd() that's giving
you output:

$ raku -e 'dd($_) for "LinesTabs.txt".IO.lines( :chomp, :nl-in["\t"])[1,2,0];'

HTH, Bill.

Re: How to I modify what is a new line in lines?

[ToddAndMargo via perl6-users]

On 2020-08-31 17:21, yary wrote:

First part of my previous email on this thread! Re-read this bit

First, you were looking at the docs for Path's "lines", but you are 
using a string "lines" and those docs say


multi method lines(Str:D: $limit, :$chomp = True)
multi method lines(Str:D: :$chomp = True)

Files get "nl-in" due to the special case of text files having various 
line endings to tweak.


Strings already have "split" and "comb" for all the flexibility one may 
need there, and what you're playing with is more naturally

dd $_ for $x.split("\t"); # "a","b", ... removes \t
dd $_ for $x.split(//); "a\t","b\t", 


and restating the above: "string".lines is different a different method 
from "File.txt".IO.lines, which is also different from 
"File.txt".IO.open.lines .  Yes that's confusing but there are reasons 
for all that which make sense when one thinks about them a while.


So if you want to split a string, use split!

If you want to experiment a text file's line endings with "lines", do 
that experiment with a file! Which was the 2nd part of my previous email



dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
"Li"
"ne 0\n"
"Li"
"ne 1\n"


-y


Hi Yary,

I think I am getting it.  I am confusing str with file.

In the following, LineTabs.txt is
"Line 1\tLine 2\tLine 3\tLine 4\t"

$ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :!chomp, 
:nl-in["\t"])[1,2,0];'

"Line 1\t"
"Line 2\t"
"Line 0\t"

$ raku -e 'dd $_ for "LinesTabs.txt".IO.lines( :chomp, 
:nl-in["\t"])[1,2,0];'

"Line 1"
"Line 2"
"Line 0"

I am having trouble wrapping my mind around `dd $_ for`.  What
exactly is going on?

-T

Re: How to I modify what is a new line in lines?

[yary]

First part of my previous email on this thread! Re-read this bit

> First, you were looking at the docs for Path's "lines", but you are
> using a string "lines" and those docs say
>
> multi method lines(Str:D: $limit, :$chomp = True)
> multi method lines(Str:D: :$chomp = True)
>
> Files get "nl-in" due to the special case of text files having various
> line endings to tweak.
>
> Strings already have "split" and "comb" for all the flexibility one may
> need there, and what you're playing with is more naturally
> dd $_ for $x.split("\t"); # "a","b", ... removes \t
> dd $_ for $x.split(//); "a\t","b\t", 

and restating the above: "string".lines is different a different method
from "File.txt".IO.lines, which is also different from
"File.txt".IO.open.lines .  Yes that's confusing but there are reasons for
all that which make sense when one thinks about them a while.

So if you want to split a string, use split!

If you want to experiment a text file's line endings with "lines", do that
experiment with a file! Which was the 2nd part of my previous email

> dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
> "Li"
> "ne 0\n"
> "Li"
> "ne 1\n"

-y


On Mon, Aug 31, 2020 at 5:12 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-08-30 08:42, yary wrote:
> > You were close!
> >
> > First, you were looking at the docs for Path's "lines", but you are
> > using a string "lines" and those docs say
> >
> > multi method lines(Str:D: $limit, :$chomp = True)
> > multi method lines(Str:D: :$chomp = True)
> >
> > Files get "nl-in" due to the special case of text files having various
> > line endings to tweak.
> >
> > Strings already have "split" and "comb" for all the flexibility one may
> > need there, and what you're playing with is more naturally
> > dd $_ for $x.split("\t"); # "a","b", ... removes \t
> > dd $_ for $x.split(//); "a\t","b\t", 
> >
> > Now back to the Path lines, which DOES let you specify line endings
> >
> > methodlines(IO::Path:D::$chomp=True, :$enc='utf8', :$nl-in= ["\x0A",
> > "\r\n"], |c-->Seq:D)
> >
> > $ cat line0-10.txt
> > Line 0
> > Line 1
> > Line 2
> > ...
> >
> > let's pretend that the letter "i" is a line ending.
> > named arguments can be conveniently written colon pairs :-)
> >
> > my $nl-in="i"; dd $_ for 'line0-10.txt'.IO.lines(:$nl-in)[0..3];
> > "L"
> > "ne 0\nL"
> > "ne 1\nL"
> > "ne 2\nL"
> >
> > How about splitting on either "i" or "\n", and not chomping
> >
> > my $nl-in=("i","\n"); dd $_ for 'line0-10.txt'.IO.lines(:$nl-in,
> > :!chomp)[0..3];
> > "Li"
> > "ne 0\n"
> > "Li"
> > "ne 1\n"
> >
> > To put in line endings without having a variable of the same name as the
> > naed arg, use the full form of the colon pair
> > dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
> > "Li"
> > "ne 0\n"
> > "Li"
> > "ne 1\n"
> >
> >
> >
> > -y
>
> Hi Yary,
>
> Now what am I doing wrong?
>
> p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:nl-in["\t", 0x09],
> :!chomp) {dd $_};'
>
> Str $x = "a\tb\tc\td\t"
>
> "a\tb\tc\td\t"
>
> :'(
> -T
>

Re: How to I modify what is a new line in lines?

[ToddAndMargo via perl6-users]

On 2020-08-30 08:42, yary wrote:

You were close!

First, you were looking at the docs for Path's "lines", but you are 
using a string "lines" and those docs say


multi method lines(Str:D: $limit, :$chomp = True)
multi method lines(Str:D: :$chomp = True)

Files get "nl-in" due to the special case of text files having various 
line endings to tweak.


Strings already have "split" and "comb" for all the flexibility one may 
need there, and what you're playing with is more naturally

dd $_ for $x.split("\t"); # "a","b", ... removes \t
dd $_ for $x.split(//); "a\t","b\t", 

Now back to the Path lines, which DOES let you specify line endings

methodlines(IO::Path:D::$chomp=True, :$enc='utf8', :$nl-in= ["\x0A", 
"\r\n"], |c-->Seq:D)


$ cat line0-10.txt
Line 0
Line 1
Line 2
...

let's pretend that the letter "i" is a line ending.
named arguments can be conveniently written colon pairs :-)

my $nl-in="i"; dd $_ for 'line0-10.txt'.IO.lines(:$nl-in)[0..3];
"L"
"ne 0\nL"
"ne 1\nL"
"ne 2\nL"

How about splitting on either "i" or "\n", and not chomping

my $nl-in=("i","\n"); dd $_ for 'line0-10.txt'.IO.lines(:$nl-in, 
:!chomp)[0..3];

"Li"
"ne 0\n"
"Li"
"ne 1\n"

To put in line endings without having a variable of the same name as the 
naed arg, use the full form of the colon pair

dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
"Li"
"ne 0\n"
"Li"
"ne 1\n"



-y


Hi Yary,

Now what am I doing wrong?

p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:nl-in["\t", 0x09], 
:!chomp) {dd $_};'


Str $x = "a\tb\tc\td\t"

"a\tb\tc\td\t"

:'(
-T

Re: How to I modify what is a new line in lines?

[Brad Gilbert]

$file.IO.lines( :nl-in(…), :chomp, … )

is actually short for

$file.IO.open( :nl-in(…), :chomp ).lines( … )

On Sun, Aug 30, 2020 at 10:43 AM yary  wrote:

> You were close!
>
> First, you were looking at the docs for Path's "lines", but you are using
> a string "lines" and those docs say
>
> multi method lines(Str:D: $limit, :$chomp = True)
> multi method lines(Str:D: :$chomp = True)
>
> Files get "nl-in" due to the special case of text files having various
> line endings to tweak.
>
> Strings already have "split" and "comb" for all the flexibility one may
> need there, and what you're playing with is more naturally
> dd $_ for $x.split("\t"); # "a","b", ... removes \t
> dd $_ for $x.split(//); "a\t","b\t", 
>
> Now back to the Path lines, which DOES let you specify line endings
>
> method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in = ["\x0A"
> , "\r\n"], |c --> Seq:D)
>
> $ cat line0-10.txt
> Line 0
> Line 1
> Line 2
> ...
>
> let's pretend that the letter "i" is a line ending.
> named arguments can be conveniently written colon pairs :-)
>
> my $nl-in="i"; dd $_ for 'line0-10.txt'.IO.lines(:$nl-in)[0..3];
> "L"
> "ne 0\nL"
> "ne 1\nL"
> "ne 2\nL"
>
> How about splitting on either "i" or "\n", and not chomping
>
> my $nl-in=("i","\n"); dd $_ for 'line0-10.txt'.IO.lines(:$nl-in,
> :!chomp)[0..3];
> "Li"
> "ne 0\n"
> "Li"
> "ne 1\n"
>
> To put in line endings without having a variable of the same name as the
> naed arg, use the full form of the colon pair
> dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
> "Li"
> "ne 0\n"
> "Li"
> "ne 1\n"
>
>
>
> -y
>
>
> On Sun, Aug 30, 2020 at 2:58 AM ToddAndMargo via perl6-users <
> perl6-users@perl.org> wrote:
>
>> Hi All,
>>
>> https://docs.raku.org/type/IO::Path#method_lines
>>
>> method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in =
>> ["\x0A", "\r\n"], |c --> Seq:D)
>>
>> How do I change what lines sees as a new line.  Is it
>> :$nl-in?  A tab in this case.
>>
>> Some of my missteps:
>>
>> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, "\t") {dd $_};'
>> Str $x = "a\tb\tc\td\t"
>>
>>
>> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :$nl-in =
>> ["\x0A", "\r\n"]) {dd $_};'
>> ===SORRY!=== Error while compiling -e
>> Variable '$nl-in' is not declared
>> at -e:1
>> --> tc\td\t"; dd $x; for $x.lines(:!chomp, :⏏$nl-in = ["\x0A",
>> "\r\n"]) {dd $_};
>>
>> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :nl-in =
>> ["\x0A", "\r\n"]) {dd $_};'
>> Str $x = "a\tb\tc\td\t"
>> Cannot modify an immutable Pair (nl-in => True)
>>in block  at -e line 1
>>
>>
>> Many thanks,
>> -T
>>
>

Re: How to I modify what is a new line in lines?

[yary]

You were close!

First, you were looking at the docs for Path's "lines", but you are using a
string "lines" and those docs say

multi method lines(Str:D: $limit, :$chomp = True)
multi method lines(Str:D: :$chomp = True)

Files get "nl-in" due to the special case of text files having various line
endings to tweak.

Strings already have "split" and "comb" for all the flexibility one may
need there, and what you're playing with is more naturally
dd $_ for $x.split("\t"); # "a","b", ... removes \t
dd $_ for $x.split(//); "a\t","b\t", 

Now back to the Path lines, which DOES let you specify line endings

method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in = ["\x0A",
"\r\n"], |c --> Seq:D)

$ cat line0-10.txt
Line 0
Line 1
Line 2
...

let's pretend that the letter "i" is a line ending.
named arguments can be conveniently written colon pairs :-)

my $nl-in="i"; dd $_ for 'line0-10.txt'.IO.lines(:$nl-in)[0..3];
"L"
"ne 0\nL"
"ne 1\nL"
"ne 2\nL"

How about splitting on either "i" or "\n", and not chomping

my $nl-in=("i","\n"); dd $_ for 'line0-10.txt'.IO.lines(:$nl-in,
:!chomp)[0..3];
"Li"
"ne 0\n"
"Li"
"ne 1\n"

To put in line endings without having a variable of the same name as the
naed arg, use the full form of the colon pair
dd $_ for 'line0-10.txt'.IO.lines(:nl-in["i","\n"], :!chomp)[0..3];
"Li"
"ne 0\n"
"Li"
"ne 1\n"



-y


On Sun, Aug 30, 2020 at 2:58 AM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi All,
>
> https://docs.raku.org/type/IO::Path#method_lines
>
> method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in =
> ["\x0A", "\r\n"], |c --> Seq:D)
>
> How do I change what lines sees as a new line.  Is it
> :$nl-in?  A tab in this case.
>
> Some of my missteps:
>
> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, "\t") {dd $_};'
> Str $x = "a\tb\tc\td\t"
>
>
> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :$nl-in =
> ["\x0A", "\r\n"]) {dd $_};'
> ===SORRY!=== Error while compiling -e
> Variable '$nl-in' is not declared
> at -e:1
> --> tc\td\t"; dd $x; for $x.lines(:!chomp, :⏏$nl-in = ["\x0A",
> "\r\n"]) {dd $_};
>
> $ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :nl-in =
> ["\x0A", "\r\n"]) {dd $_};'
> Str $x = "a\tb\tc\td\t"
> Cannot modify an immutable Pair (nl-in => True)
>in block  at -e line 1
>
>
> Many thanks,
> -T
>

How to I modify what is a new line in lines?

[ToddAndMargo via perl6-users]

Hi All,

https://docs.raku.org/type/IO::Path#method_lines

method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in = 
["\x0A", "\r\n"], |c --> Seq:D)


How do I change what lines sees as a new line.  Is it
:$nl-in?  A tab in this case.

Some of my missteps:

$ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, "\t") {dd $_};'
Str $x = "a\tb\tc\td\t"


$ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :$nl-in = 
["\x0A", "\r\n"]) {dd $_};'

===SORRY!=== Error while compiling -e
Variable '$nl-in' is not declared
at -e:1
--> tc\td\t"; dd $x; for $x.lines(:!chomp, :⏏$nl-in = ["\x0A", 
"\r\n"]) {dd $_};


$ p6 'my $x="a\tb\tc\td\t"; dd $x; for $x.lines(:!chomp, :nl-in = 
["\x0A", "\r\n"]) {dd $_};'

Str $x = "a\tb\tc\td\t"
Cannot modify an immutable Pair (nl-in => True)
  in block  at -e line 1


Many thanks,
-T

No such method 'prefix' for invocant of type 'Capture' when trying to patch a new library include path

[Konrad Bucheli via perl6-users]

Dear Raku experts


I have a little patch which adds another library include path and installation 
site named "foo" which points to "/opt/foo/lib", see attached patch.

That worked (in a similar fashion) well with 2020.02, but with 2020.05 it fails 
on the following test:


$ cat foo.rakumod
unit module foo;
use Test;
$ raku -I . -e "use foo"
===SORRY!=== Error while compiling -e
===SORRY!=== Error while compiling /home/kb/foo.rakumod (foo)
No such method 'prefix' for invocant of type 'Capture'
at /home/kb/foo.rakumod (foo):2

at -e:1
$


Interestingly it works fine after the second or third time, and then always, 
until I remove the ~/.raku and .precomp directories...

Maybe it is fine when it somehow managed to get precompiled. And without this 
little innocent patch it is also working.

Can someone enlighten me?

Cheers

Konrad
diff --git a/src/core.c/CompUnit/RepositoryRegistry.pm6 b/src/core.c/CompUnit/RepositoryRegistry.pm6
index 84250e72e..26274464e 100644
--- a/src/core.c/CompUnit/RepositoryRegistry.pm6
+++ b/src/core.c/CompUnit/RepositoryRegistry.pm6
@@ -136,6 +136,7 @@ class CompUnit::RepositoryRegistry {
 my str $core   = 'inst#' ~ $prefix ~ $sep ~ 'core';
 my str $vendor = 'inst#' ~ $prefix ~ $sep ~ 'vendor';
 my str $site   = 'inst#' ~ $prefix ~ $sep ~ 'site';
+my str $foo= 'inst#' ~ '/opt/foo/lib';
 
 my str $home;
 my str $home-spec;
@@ -182,6 +183,17 @@ class CompUnit::RepositoryRegistry {
   )
 ) unless nqp::existskey($unique, $site);
 
+# FOO specific: /opt/foo/lib
+nqp::bindkey($custom-lib, 'foo',
+  $next-repo := self!register-repository(
+$foo,
+CompUnit::Repository::Installation.new(
+  :prefix('/opt/foo/lib'),
+  :$next-repo
+)
+  )
+) unless nqp::existskey($unique, $foo);
+
 nqp::bindkey($custom-lib,'home',
   $next-repo := self!register-repository(
 $home-spec,
@@ -215,6 +227,11 @@ class CompUnit::RepositoryRegistry {
 my \repo := nqp::atkey($repos,$site);
 nqp::bindkey($custom-lib,'site',repo) if repo;
 }
+# FOO specific: /opt/foo/lib
+unless nqp::existskey($custom-lib, 'foo') {
+my \repo := nqp::atkey($repos, $foo);
+nqp::bindkey($custom-lib, 'foo', \repo) if repo;
+}
 unless nqp::existskey($custom-lib,'home') {
 if $home-spec {
 my \repo := nqp::atkey($repos,$home-spec);

Re: comment on the new name change

[ToddAndMargo via perl6-users]

On 2019-12-06 09:55, Parrot Raiser wrote:

Should users of Raku be termed "Rakuuns"? :-)*



Hysterical!

Re: comment on the new name change

[Parrot Raiser]

Should users of Raku be termed "Rakuuns"? :-)*

Re: comment on the new name change

[Brad Gilbert]

History lesson:

Rakudo is short for Rakuda Do

Rakuda Do is supposed to have meant "the way of the camel"

The first book about Perl was Learning Perl. It had a Camel on the front
cover.
(Note also that the name of the butterfly logo is named Camelia, and that
the first 5 characters spell Camel.)

Rakudo means Paradise.

So there are two reasons Rakudo was chosen for the name of the compiler.

Raku is of course the first 4 letters of Rakudo.

Raku means comfort, ease, or relief.

Raku is also a form of pottery.
(This seems like it might be a coincidence, but knowing Larry it may be
intentional.)

The design of the Raku language is so cohesive that even the new name has
more than one reason it was chosen.

On Fri, Dec 6, 2019 at 2:12 AM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi All,
>
> I personally do not care if we call Perl 6 "The Flying
> Zucchini".
>
> But what I really like is that I can now to a web search
> on "raku" and not get 3,264,682,533 hits on Perl 5
> that I have to frustratingly sort through to find what
> I want.
>
> So I am a happy camper with the new name.
>
> Just out of curiosity, was this the intention
> of the new name?
>
> https://www.thoughtco.com/raku-meaning-and-characters-2028515
>
>  The Japanese word raku, pronounced "rah-koo", is a
>  commonly-used word that means comfort, ease, or
>  relief.
>
> Having used several other programming languages in
> my lifetime, if this was the intention, I do have to
> say the name fits
>
> :-)
>
> -T
>

comment on the new name change

[ToddAndMargo via perl6-users]

Hi All,

I personally do not care if we call Perl 6 "The Flying
Zucchini".

But what I really like is that I can now to a web search
on "raku" and not get 3,264,682,533 hits on Perl 5
that I have to frustratingly sort through to find what
I want.

So I am a happy camper with the new name.

Just out of curiosity, was this the intention
of the new name?

https://www.thoughtco.com/raku-meaning-and-characters-2028515

The Japanese word raku, pronounced "rah-koo", is a
commonly-used word that means comfort, ease, or
relief.

Having used several other programming languages in
my lifetime, if this was the intention, I do have to
say the name fits

:-)

-T

Re: perl6's new name?

[Laurent Rosenfeld via perl6-users]

Maybe I wasn't clear enough.  What I meant to say it that I wasn't
enthusiastic about a name change, but, if the name really has to change,
then Camelia is my favorite name.



Le mer. 14 août 2019 à 05:49, Eliza  a écrit :

> Hi,
>
> on 2019/8/14 5:19, Laurent Rosenfeld via perl6-users wrote:
> > Having said that, I should add that if the name should really change, I
> > think Camelia is probably the least bad idea that I can think of.
> >
>
> Following the link:
>
> https://medium.com/@ThePearlSource/pearls-and-birthstones-the-pearl-month-giveaway-f8c0da46fdc0
>
> June - Pearl
> July - Ruby
> August - Peridot
>
> So how about perl6 renames to Peridot or Peri?
>
> regards,
> Eliza
>

Re: perl6's new name?

[Marcel Timmerman]

Hi David,

I think you're right in this. While I like the name chosen by Eliza I 
also thought about the changes which will follow after the renaming. 
Like in documentation with mentions of perl6, websites, books, 
extensions of modules, programs and pod docs etc.


If it comes to renaming, Camelia is the name for me. I strongly oppose 
to Raku or other names referring to Rakudo, Moarvm or other 
implementation of perl6 because we should keep the freedom to change 
that name of the implementation without having to change the name of the 
language it implements. In the past it has been Parrot for example.


Marcel


On 8/11/19 11:14 PM, Eliza wrote:

Hello perl6 world,

I saw the perl6 github issue, just was confused will perl6 change its 
name?





https://github.com/perl6/problem-solving/issues/81


I don't know whether to take this is troll bait or a real issue. Lots 
of people seem to be responding; so in case the issue is real, I will 
make two points against changing the name of Perl 6



From an X.Y major-minor version numbering system standpoint, X is 
incremented whenever the product changes significantly.  In the 
context of computer programming languages, source code incompatibility 
is an obvious criteria for changing X.  If source code is compatible 
after a change, then Y should be changed.  Perl 6 is significantly 
different from Perl 5, and, in general, Perl 6 programs are 
incompatible with the Perl 5 compiler/ interpreter and vice-versa.  
Therefore, the "6" was properly applied and "Perl 6" is correct.



From a practical standpoint, there is too much water under the bridge. 
Name changes need to be done up front (Ruby was done properly in this 
regard).



David

Re: perl6's new name?

[Eliza]

Hi,

on 2019/8/13 11:52, Veesh Goldman wrote:
All ML really happens in C++. The only advantage that python has is that 
people use it. P6 is flexible enough that I'm sure you can port 
TensorFlow using nativeCall within a month.
Perl as a whole has a terrible image problem. People think it's just awk 
with more punctuation variables. Literally, to most people Perl is regexes.
In my opinion, what we need is a tutorial website that ranks high on 
search engines for searches not about Perl, so that people will realize 
that Perl is very readable and very useful. But I digress.


Though I do use perl every day but just found this interesting article 
from Hacknews about python you may just give a try reading.


http://cloudcache.net/PythonCoverStoryNJH_FINAL.pdf

regards,
Eliza

Re: perl6's new name?

[Eliza]

Hi,

on 2019/8/14 5:19, Laurent Rosenfeld via perl6-users wrote:
Having said that, I should add that if the name should really change, I 
think Camelia is probably the least bad idea that I can think of.




Following the link: 
https://medium.com/@ThePearlSource/pearls-and-birthstones-the-pearl-month-giveaway-f8c0da46fdc0


June - Pearl
July - Ruby
August - Peridot

So how about perl6 renames to Peridot or Peri?

regards,
Eliza

Re: perl6's new name?

[Laurent Rosenfeld via perl6-users]

I don't think the decision has been made so far. At this point, it is a
proposal  by one (or possibly several) individual(s) whom I very much
respect.

And it is definitely not going to hapopen this week (and quite probably not
this month).

Even though my opinion on the subject is probably irrelevant to most
people, I want to say for the record that I'm personally not in favor of a
name change, as I'm afraid that this will make things even more complicated
than they currently are. Perl 6 has been known under this name for almost
20 years by now, giving it a new name now might just blur everything in the
mind of most people. "The ship has sailed," as they say. I'm afraid that
changing the name today might actually become a marketing disaster. And I
am not saying that as an author of one of the Perl 6 books, my concern is
really not to lose sales on my book (if it were, my book wouldn't be freely
available on-line and open source).

At the same time, I can certainly understand some of the arguments for a
name change.

Having said that, I should add that if the name should really change, I
think Camelia is probably the least bad idea that I can think of.

Cheers,
Laurent.


Le mar. 13 août 2019 à 21:46, William Michels via perl6-users <
perl6-users@perl.org> a écrit :

> I've put up two name suggestions for Perl 6:
>
> NUPERL:
> www.nuperl.orgwww.nuperl.comwww.nuperl.net
>
> NEUPERL:
> www.neuperl.orgwww.neuperl.comwww.neuperl.net
>
> Specifics:
> https://github.com/perl6/problem-solving/issues/81#issuecomment-520960546
>
> I'm not sure why this decision has to be made now. A number of good
> books just released under the "Perl 6" name, so those authors will
> lose sales traction. But if a name-change is inevitable, it seems that
> the 5 year anniversary of the release of Perl 6 is coming up on
> Christmas Day, 2020. Why not then?
>
> I's primary season and election season in the US, so if someone wants
> to put up a Doodle-Poll, this might be fun. We can get a better idea
> of how popular the names Camelia, Raku, ofun, Nuperl, Neuperl,
> larrylang, Albus, Perlsix, Zeta, etc. are .
>
> https://beta.doodle.com/free-poll
>
> Otherwise, why this month? Why this week?
>

Re: perl6's new name?

[William Michels via perl6-users]

I've put up two name suggestions for Perl 6:

NUPERL:
www.nuperl.orgwww.nuperl.comwww.nuperl.net

NEUPERL:
www.neuperl.orgwww.neuperl.comwww.neuperl.net

Specifics: 
https://github.com/perl6/problem-solving/issues/81#issuecomment-520960546

I'm not sure why this decision has to be made now. A number of good
books just released under the "Perl 6" name, so those authors will
lose sales traction. But if a name-change is inevitable, it seems that
the 5 year anniversary of the release of Perl 6 is coming up on
Christmas Day, 2020. Why not then?

I's primary season and election season in the US, so if someone wants
to put up a Doodle-Poll, this might be fun. We can get a better idea
of how popular the names Camelia, Raku, ofun, Nuperl, Neuperl,
larrylang, Albus, Perlsix, Zeta, etc. are .

https://beta.doodle.com/free-poll

Otherwise, why this month? Why this week?

Re: perl6's new name?

[David Christensen]

On 8/11/19 11:14 PM, Eliza wrote:

Hello perl6 world,

I saw the perl6 github issue, just was confused will perl6 change its name?





https://github.com/perl6/problem-solving/issues/81


I don't know whether to take this is troll bait or a real issue.  Lots 
of people seem to be responding; so in case the issue is real, I will 
make two points against changing the name of Perl 6



From an X.Y major-minor version numbering system standpoint, X is 
incremented whenever the product changes significantly.  In the context 
of computer programming languages, source code incompatibility is an 
obvious criteria for changing X.  If source code is compatible after a 
change, then Y should be changed.  Perl 6 is significantly different 
from Perl 5, and, in general, Perl 6 programs are incompatible with the 
Perl 5 compiler/ interpreter and vice-versa.  Therefore, the "6" was 
properly applied and "Perl 6" is correct.



From a practical standpoint, there is too much water under the bridge. 
Name changes need to be done up front (Ruby was done properly in this 
regard).



David

Re: perl6's new name?

[David E.]

It's been said before, but I do think that the "Perl6" name is holding back
adoption.  Too many people think of the old Perl, and have no interest in
looking at what's changed in a new version of the "same" language.
Whatever the new name ultimately becomes, changing it (perhaps timed with a
new major release of the Rakudo implementation), would do much to improve
adoption.


Camelia could work, but I'll throw in another suggestion that's been in my
head for a while:  *PANL* - short for "Perl 6 is A New Language".
Alternatively, its components can be referred to as the "PAN Language",
"PAN Interpreter", "PAN Specification", etc with a possible logo being a
frying pan (held by a camel?) mixing up all of the best language concepts &
tools ;-)

It's short and makes clear that this is a part of the Perl family (for
those that care), while still conveying that it is, for all intents and
purposes, a new language.

-David

On Tue, Aug 13, 2019 at 1:21 AM BELOSCAR Christian <
christian.belos...@gmail.com> wrote:

> Camelia : Excellent idea Eliza, I totally agree with yours arguments and
> what a sympathetic non technical name
> accorded with its logo and attracting young programmers too. I vote for
> this choice with enthusiasm !
>
> Chris
>
> Le lun. 12 août 2019 à 08:15, Eliza  a écrit :
>
>> Hello perl6 world,
>>
>> I saw the perl6 github issue, just was confused will perl6 change its
>> name?
>>
>> Perl 6 was initially conceived to be the next version of Perl 5. It took
>> way too long to mature to an initial release. Meanwhile, people
>> interested in taking Perl 5 along, took back the reigns and continued
>> developing Perl 5.
>>
>> Having two programming languages that are sufficiently different to not
>> be source compatible, but only differ in what many perceive to be a
>> version number, is hurting the image of both Perl 5 and Perl 6 in the
>> world. Since the word "Perl" is still perceived as "Perl 5" in the
>> world, it only seems fair that "Perl 6" changes its name.
>>
>> Since Larry has indicated, in his video message to the participants of
>> PerlCon 2019 in Riga, that the two sister languages are now old and wise
>> enough to take care of themselves, such a name change would no longer
>> require the approval of the BDFL.
>>
>> I would therefore propose to change the name to "the Camelia Programming
>> Language" or "Camelia" for short, for several reasons:
>>
>> the search term "camelia programming language" already brings you to the
>> right place. This means that changing the name to "Camelia" will have
>> minimal impact on findability on search engines such as Google and
>> DuckDuckGo.
>>
>> the logo / mascot would not need changing: it's just that it now also
>> becomes the actual name of the programming language.
>>
>> "Camelia" in its name, still carries something Perlish inside of it.
>>
>> The concept of "Camelia" being an implementation of a specification in
>> "roast", still stands. The alternative, to use "Rakudo" as the name of
>> the language, would cause confusion with the name being used to indicate
>> an implementation, and would endanger the separation between
>> specification and implementation.
>>
>> Choosing yet another name, such as Albus, would mean having to start
>> from scratch with marketing and getting the name out there. Hence my
>> preference for a known name such as "Camelia".
>>
>> The "Camelia" logo is still copyright Larry Wall, so it would allow
>> Larry to still be connected to one of the programming languages that he
>> helped get into the world.
>>
>> https://github.com/perl6/problem-solving/issues/81
>>
>> regards,
>> Eliza
>>
>

Re: perl6's new name?

[BELOSCAR Christian]

Camelia : Excellent idea Eliza, I totally agree with yours arguments and
what a sympathetic non technical name
accorded with its logo and attracting young programmers too. I vote for
this choice with enthusiasm !

Chris

Le lun. 12 août 2019 à 08:15, Eliza  a écrit :

> Hello perl6 world,
>
> I saw the perl6 github issue, just was confused will perl6 change its name?
>
> Perl 6 was initially conceived to be the next version of Perl 5. It took
> way too long to mature to an initial release. Meanwhile, people
> interested in taking Perl 5 along, took back the reigns and continued
> developing Perl 5.
>
> Having two programming languages that are sufficiently different to not
> be source compatible, but only differ in what many perceive to be a
> version number, is hurting the image of both Perl 5 and Perl 6 in the
> world. Since the word "Perl" is still perceived as "Perl 5" in the
> world, it only seems fair that "Perl 6" changes its name.
>
> Since Larry has indicated, in his video message to the participants of
> PerlCon 2019 in Riga, that the two sister languages are now old and wise
> enough to take care of themselves, such a name change would no longer
> require the approval of the BDFL.
>
> I would therefore propose to change the name to "the Camelia Programming
> Language" or "Camelia" for short, for several reasons:
>
> the search term "camelia programming language" already brings you to the
> right place. This means that changing the name to "Camelia" will have
> minimal impact on findability on search engines such as Google and
> DuckDuckGo.
>
> the logo / mascot would not need changing: it's just that it now also
> becomes the actual name of the programming language.
>
> "Camelia" in its name, still carries something Perlish inside of it.
>
> The concept of "Camelia" being an implementation of a specification in
> "roast", still stands. The alternative, to use "Rakudo" as the name of
> the language, would cause confusion with the name being used to indicate
> an implementation, and would endanger the separation between
> specification and implementation.
>
> Choosing yet another name, such as Albus, would mean having to start
> from scratch with marketing and getting the name out there. Hence my
> preference for a known name such as "Camelia".
>
> The "Camelia" logo is still copyright Larry Wall, so it would allow
> Larry to still be connected to one of the programming languages that he
> helped get into the world.
>
> https://github.com/perl6/problem-solving/issues/81
>
> regards,
> Eliza
>

Re: perl6's new name?

[Veesh Goldman]

All ML really happens in C++. The only advantage that python has is that
people use it. P6 is flexible enough that I'm sure you can port TensorFlow
using nativeCall within a month.
Perl as a whole has a terrible image problem. People think it's just awk
with more punctuation variables. Literally, to most people Perl is regexes.
In my opinion, what we need is a tutorial website that ranks high on search
engines for searches not about Perl, so that people will realize that Perl
is very readable and very useful. But I digress.

On Tue, Aug 13, 2019, 05:18 Francis Grizzly Smit  wrote:

>
> On 13/08/2019 12:03, Eliza wrote:
>
> Hi,
>
> on 2019/8/13 3:17, Stephen Wilcoxon wrote:
>
> Perl, on the other hand, can do anything Python can (except stackless)
> and,
> generally, just as easily.
>
>
> I don't think so specially in AI/ML field.
>
> Python can handle primitive types much better than ruby/perl can at the
> moment. And has much less of an overhead, compared to ruby where almost
> everything is a FixNum etc (perl is even worse on types), where Python can
> see the actual integer or float and calculations can run at close to C++
> speeds.
>
>
> Python handles types differently than perl6 but certainly not better, even
> perl 5 only has a few deficits compared to python mostly it's just
> different
>
>
> --
>
>.~. In my life God comes first
>/V\ but Linux is pretty high after that :-D
>   /( )\Francis (Grizzly) Smit
>   ^^-^^http://www.smit.id.au/
>
>

Re: perl6's new name?

[Eliza]

Hi,

on 2019/8/13 3:17, Stephen Wilcoxon wrote:

Perl, on the other hand, can do anything Python can (except stackless) and,
generally, just as easily.


I don't think so specially in AI/ML field.

Python can handle primitive types much better than ruby/perl can at the 
moment. And has much less of an overhead, compared to ruby where almost 
everything is a FixNum etc (perl is even worse on types), where Python 
can see the actual integer or float and calculations can run at close to 
C++ speeds.

Re: perl6's new name?

[Eliza]

Hi,

on 2019/8/13 2:17, Stephen Wilcoxon wrote:
I love Perl but it has an image problem.  If Perl didn't have an image 
problem,

Python never would have become so popular.


can you give more detailed description what image problem perl has? thanks.

Re: perl6's new name?

[David Green]

It’s far from obvious that playing with the name is likely to make things 
significantly better. Perl 6 has been P6 longer than Perl 5 had been P5 — or 
Perl Anything — at the time it was conceived. That’s not to say nothing should 
be done about it, but as some people have pointed out in the Github thread, 
there are important issues to be dealt with first. In the meantime, that would 
give an opportunity for anyone who is serious about the marketing side of 
things to do some actual research instead of guessing what we think might 
possibly help sort of.


> On 2019-Aug-12, at 11:57 am, Richard Hainsworth  
> wrote:
> There are is one statement in Eliza's original text that is not correct, and 
> several that are debatable.
Here’s the original text quoted from LizMat's Github issue: 
https://github.com/perl6/problem-solving/issues/81 


Perl 6 certainly started out as the next version of Perl 5 (hence the “6” in 
the name), and had Larry been able to see into the future, no doubt the 
marketing would have been different. And we should care about marketing, 
because Perl(s) exist in a market of programming languages, and if the product 
isn’t profitable (in a programming-language sense) then eventually there will 
by nobody left to develop and maintain it and write modules for it. Which would 
be a real shame.
But of course you’re right that there needs to be a good reason for whatever 
course of action is chosen, and I don’t see what that reason is.


-David

Re: perl6's new name?

[Joseph Brenner]

> If Perl had worked harder to stay in the public eye in a good way (rather
than being viewed as dieing), there wouldn't have been a perceived
need for Python.

As I remember it, there was a concerted attack on perl with Python
being held up as the-anti-perl.  There wasn't (yet) any question of
perl dieing.

My take-- which I owe a lot to Steve Yegge's peculiar writings on the
subject-- is that the computer science intelligensia were actively
offended by that upstart outsider Larry Wall was showing you could do
things differently and still come up with something useful.

Re: perl6's new name?

[Joseph Brenner]

I think:

(1) For a rename to happen, Larry Wall really has to sign off on it:
this is just a social reality of the perl world.

(2) The rename really has to be an announced, offical rename.   It
can't be just an alias or a knickname or anything like that.

I find I like the name Camelia in part because Larry might actually
sign-off on it, in part because most of the alternatives I've heard
proposed ("raku", "six", etc) seem very awkward.

It does not seem that this issue is going to go away without a rename.

Names are important to perception, and they can matter critically to
the outside world.


On 8/12/19, Richard Hainsworth  wrote:
> 
>>
>> The decision on perl 5 vs perl 6 naming is more revolutionary but it
>> IS hurting
>> Perl.  I love Perl but it has an image problem.
> True. Would a name change now have much effect?
>> If Perl didn't have an image problem,
>> Python never would have become so popular.
> Mmmm.  That is a very strong assertion and diminishes Python and its
> developers. It's the sort of statement that can't easily be tested. More
> a belief.
>>   Perl used to be THE scripting
>> language.
> True. And C was THE programming language. Life moves on. And in circles.
> Fashions come and go, and what was fashionable can again be so.
>>   It doesn't matter that it is still around and still continuing to be
>> developed.
>> What matters is people's PERCEPTIONS of Perl (dead, dieing,
>> irrelevant, etc).
>>
>> Too little was done for too long about Perl's image.  It may be too
>> late to bring it
>> back into the forefront as it used to be.
>
> Being excited about a language and using it for cool things - and
> broadcasting to the world that its cool will do more to change
> perceptions that Perl is cool, than a name change to Camilea.
>
> As you said: Perceptions are the most important thing.
>

Re: perl6's new name?

[Stephen Wilcoxon]

On Mon, Aug 12, 2019 at 1:42 PM Richard Hainsworth 
wrote:
>
> > The decision on perl 5 vs perl 6 naming is more revolutionary but it
> > IS hurting
> > Perl.  I love Perl but it has an image problem.
> True. Would a name change now have much effect?
> > If Perl didn't have an image problem,
> > Python never would have become so popular.
> Mmmm.  That is a very strong assertion and diminishes Python and its
> developers. It's the sort of statement that can't easily be tested. More
> a belief.


Not really.  If Perl had worked harder to stay in the public eye in a good
way (rather
than being viewed as dieing), there wouldn't have been a perceived need for
Python.

Python is fundamentally flawed (significant whitespace was stressed in
multiple classes
in grad school as something to NEVER do when designing a language (and an
older one
that I can no longer remember was used as the example)).

> >   Perl used to be THE scripting
> > language.
> True. And C was THE programming language. Life moves on. And in circles.
> Fashions come and go, and what was fashionable can again be so.

The big difference being that C is a primitive (as in very low-level)
language that is
great for some things but requires far more work than "modern" languages
for a
lot of things.  If you don't need the speed, there's little reason to use C
these days.

Perl, on the other hand, can do anything Python can (except stackless) and,
generally, just as easily.

Re: perl6's new name?

[Parrot Raiser]

"5" is a version number of Perl. To run it, $/usr/bin/perl "6" is part
of the name of Perl6.
To run it, $/usr/bin/perl6.

With the production version of Perl incremented by 2 every year, it's
still about 35 years before the version gets to an inconvenient 3
digits. (Will there really be enough worth changing that many times,
and how many of us will still be around to care?)

Energy expended in nominal disputes would be better spent producing
killer apps in some fashionable area (AI, ML, even a web framework),
so that people  don't care what the language is called, they just want
to use it. Ruby applications might be a good place to start, since
that community seems to have fractured, and Perl6 has a lot in common
with Ruby.

On 8/12/19, Richard Hainsworth  wrote:
> 
>>
>> The decision on perl 5 vs perl 6 naming is more revolutionary but it
>> IS hurting
>> Perl.  I love Perl but it has an image problem.
> True. Would a name change now have much effect?
>> If Perl didn't have an image problem,
>> Python never would have become so popular.
> Mmmm.  That is a very strong assertion and diminishes Python and its
> developers. It's the sort of statement that can't easily be tested. More
> a belief.
>>   Perl used to be THE scripting
>> language.
> True. And C was THE programming language. Life moves on. And in circles.
> Fashions come and go, and what was fashionable can again be so.
>>   It doesn't matter that it is still around and still continuing to be
>> developed.
>> What matters is people's PERCEPTIONS of Perl (dead, dieing,
>> irrelevant, etc).
>>
>> Too little was done for too long about Perl's image.  It may be too
>> late to bring it
>> back into the forefront as it used to be.
>
> Being excited about a language and using it for cool things - and
> broadcasting to the world that its cool will do more to change
> perceptions that Perl is cool, than a name change to Camilea.
>
> As you said: Perceptions are the most important thing.
>

Re: perl6's new name?

[Richard Hainsworth]

The decision on perl 5 vs perl 6 naming is more revolutionary but it 
IS hurting

Perl.  I love Perl but it has an image problem.

True. Would a name change now have much effect?

If Perl didn't have an image problem,
Python never would have become so popular.
Mmmm.  That is a very strong assertion and diminishes Python and its 
developers. It's the sort of statement that can't easily be tested. More 
a belief.

  Perl used to be THE scripting
language.
True. And C was THE programming language. Life moves on. And in circles. 
Fashions come and go, and what was fashionable can again be so.
  It doesn't matter that it is still around and still continuing to be 
developed.
What matters is people's PERCEPTIONS of Perl (dead, dieing, 
irrelevant, etc).


Too little was done for too long about Perl's image.  It may be too 
late to bring it

back into the forefront as it used to be.


Being excited about a language and using it for cool things - and 
broadcasting to the world that its cool will do more to change 
perceptions that Perl is cool, than a name change to Camilea.


As you said: Perceptions are the most important thing.

Re: perl6's new name?

[Stephen Wilcoxon]

I agree that the "incorrect statement" was factually incorrect.  However, it
was widely perceived to be correct.  That perception did hurt perl (both 5
and 6).
It made many people see perl as "dead" while perl 6 was under development.

>>> "It took way too long to mature to an initial release"
>
> 1. Yeah, it too a long time. Yeah that really really depressed me. But
> to be fair, the task was not trivial. And the timescale is shorter than
> it has taken humanity to return to the Moon! But now, things are
> different. I only use Perl 6 when I have the choice. When I need speed,
> I go to Perl 5, or to C. When I have in-browser stuff, I use javascript.
> When I do Android apps, I bang my head to get Java to work. Etc etc etc.
> Given the diversity of hardware and operating systems today, I doubt
> there will ever be a single universal language for all things.

Because many people believed the incorrect statement, the length of time
it took to implement perl 6 was too long.  A lot of people viewed perl as
dead
or in limbo.

>>> "Having two programming languages that are sufficiently different to
>>> not be source compatible, but only differ in what many perceive to be a
>>> version number, is hurting the image of both Perl 5 and Perl 6 in the
world"
>
> 2. "Hurt the image"? That is marketing speak. Marketing speak has its
> uses. But if the Perl community wants to be different, why do we need to
> kowtow to marketing gurus? Just because others do it, doesn't mean we
> have to. Especially not if there is a really good reason not to. I
> happen to agree with Larry that the continuing unity of the Perl
> community, with two sister languages that interact with each other, is
> very very valuable, and not to be easily sacrificed on the altar of
> fashionable phrases. Unity is much more valuable than the 'benefits' of
> 'brand image'.

I agree the unity of the Perl community is important.  However, I'm not sure
that outweighs the external perceptions.  People are used to higher versions
being mostly backwards-compatible but perl 6 is not.  This has managed to
put perl in a worse situation than Python (2 vs 3) in a lot of people's
perceptions.

>>> "such a name change would no longer require the approval of the BDFL"
>
> 3. The Benevolent Dictator still lives, and there are revolutionaries
> and revisionists who want to change things? Well I'm sympathetic to
> revolutionaries. Two things though: Whose exactly approval is to be
> required for a name change? And actually I think that Larry Wall is
> still more revolutionary in his decision to have the sister languages of
> Perl 5 and Perl 6 than all those parroting the market speak about name
> change and brand value.

The decision on perl 5 vs perl 6 naming is more revolutionary but it IS
hurting
Perl.  I love Perl but it has an image problem.  If Perl didn't have an
image problem,
Python never would have become so popular.  Perl used to be THE scripting
language.  It doesn't matter that it is still around and still continuing
to be developed.
What matters is people's PERCEPTIONS of Perl (dead, dieing, irrelevant,
etc).

Too little was done for too long about Perl's image.  It may be too late to
bring it
back into the forefront as it used to be.

On Mon, Aug 12, 2019 at 12:58 PM Richard Hainsworth 
wrote:
>
> On the topic raised by Eliza, a counter rant. Hopefully, everyone will
> detect the humour (English spelling) and not take offence.
>
> There are is one statement in Eliza's original text that is not correct,
> and several that are debatable. The debatable statements are
> understandable, and entirely reasonable per se, given the way software
> and other languages are developed. The statements are not however
> consistent with the distinct and unique way that Larry Wall has guided
> the development of Perl since he first wrote Perl 1.
>
> The 'name' issue has been hotly debated for years. Larry has made a
> decision.
>
> Whatever way one might feel about his decision, an over-riding
> consideration (looking at Larry's words) is one of unity: keeping the
> whole Perl world together, and not letting it shatter into pieces over
> shibboleths. I think that this unity is really important and well worth
> fighting for. More power to Larry!
>
> Incorrect statement: "Perl 6 was initially conceived to be the next
> version of Perl 5."
>
> No. It might be correct to say that Perl 6 was conceived to be the next
> evolution of **Perl**. It was never ever conceived to be backwards
> compatible, in fact it was explicitly designed _not_ to be backwards
> compatible, and so was never the 'next Perl 5'. There was / is a goal to
> allow for most Perl 5 programs / modules to be automatically re-written
> into Perl 6, and there is already the possibility of writing Perl 5 code
> inline in a Perl 6 program. But inlined Perl 5 remains Perl 5.
>
> Perl 5 has developed significantly since the Perl 6 evolution process
> began. That just shows the power and resiliance of the original 

Re: perl6's new name?

[Richard Hainsworth]

On the topic raised by Eliza, a counter rant. Hopefully, everyone will 
detect the humour (English spelling) and not take offence.


There are is one statement in Eliza's original text that is not correct, 
and several that are debatable. The debatable statements are 
understandable, and entirely reasonable per se, given the way software 
and other languages are developed. The statements are not however 
consistent with the distinct and unique way that Larry Wall has guided 
the development of Perl since he first wrote Perl 1.


The 'name' issue has been hotly debated for years. Larry has made a 
decision.


Whatever way one might feel about his decision, an over-riding 
consideration (looking at Larry's words) is one of unity: keeping the 
whole Perl world together, and not letting it shatter into pieces over 
shibboleths. I think that this unity is really important and well worth 
fighting for. More power to Larry!


Incorrect statement: "Perl 6 was initially conceived to be the next 
version of Perl 5."


No. It might be correct to say that Perl 6 was conceived to be the next 
evolution of **Perl**. It was never ever conceived to be backwards 
compatible, in fact it was explicitly designed _not_ to be backwards 
compatible, and so was never the 'next Perl 5'. There was / is a goal to 
allow for most Perl 5 programs / modules to be automatically re-written 
into Perl 6, and there is already the possibility of writing Perl 5 code 
inline in a Perl 6 program. But inlined Perl 5 remains Perl 5.


Perl 5 has developed significantly since the Perl 6 evolution process 
began. That just shows the power and resiliance of the original Perl 
concept, and the creativity of Perl 5 developers. The 'next versions' of 
Perl 5 compared to the Perl 5 that existed when the first Perl 6 
Apocalypses were written, have already landed. Perl 5 remains a great 
modern language. That in itself is a different gloss to 'took back the 
reigns', by which I mean that the same facts of history can be treated 
in very different ways if you change your perspective. Not everything in 
life has to correspond to simple explanations, or sound bites 
convertible into limited character messages.


The debatable statements include:

- "It took way too long to mature to an initial release"

- "Having two programming languages that are sufficiently different to 
not be source compatible, but only differ in what many perceive to be a 
version number, is hurting the image of both Perl 5 and Perl 6 in the world"


- "such a name change would no longer require the approval of the BDFL"

1. Yeah, it too a long time. Yeah that really really depressed me. But 
to be fair, the task was not trivial. And the timescale is shorter than 
it has taken humanity to return to the Moon! But now, things are 
different. I only use Perl 6 when I have the choice. When I need speed, 
I go to Perl 5, or to C. When I have in-browser stuff, I use javascript. 
When I do Android apps, I bang my head to get Java to work. Etc etc etc. 
Given the diversity of hardware and operating systems today, I doubt 
there will ever be a single universal language for all things.


2. "Hurt the image"? That is marketing speak. Marketing speak has its 
uses. But if the Perl community wants to be different, why do we need to 
kowtow to marketing gurus? Just because others do it, doesn't mean we 
have to. Especially not if there is a really good reason not to. I 
happen to agree with Larry that the continuing unity of the Perl 
community, with two sister languages that interact with each other, is 
very very valuable, and not to be easily sacrificed on the altar of 
fashionable phrases. Unity is much more valuable than the 'benefits' of 
'brand image'.


3. The Benevolent Dictator still lives, and there are revolutionaries 
and revisionists who want to change things? Well I'm sympathetic to 
revolutionaries. Two things though: Whose exactly approval is to be 
required for a name change? And actually I think that Larry Wall is 
still more revolutionary in his decision to have the sister languages of 
Perl 5 and Perl 6 than all those parroting the market speak about name 
change and brand value.


Richard

aka finanalyst

On 12/08/2019 07:14, Eliza wrote:

Hello perl6 world,

I saw the perl6 github issue, just was confused will perl6 change its 
name?


Perl 6 was initially conceived to be the next version of Perl 5. It 
took way too long to mature to an initial release. Meanwhile, people 
interested in taking Perl 5 along, took back the reigns and continued 
developing Perl 5.


Having two programming languages that are sufficiently different to 
not be source compatible, but only differ in what many perceive to be 
a version number, is hurting the image of both Perl 5 and Perl 6 in 
the world. Since the word "Perl" is still perceived as "Perl 5" in the 
world, it only seems fair that "Perl 6" changes its name.


Since Larry has indicated, in his video message to the participants of 

Re: perl6's new name?

[Erez Schatz]

It's all bike-shedding.

On 8/12/19 9:14 AM, Eliza wrote:

Hello perl6 world,

I saw the perl6 github issue, just was confused will perl6 change its 
name?


Perl 6 was initially conceived to be the next version of Perl 5. It 
took way too long to mature to an initial release. Meanwhile, people 
interested in taking Perl 5 along, took back the reigns and continued 
developing Perl 5.


Having two programming languages that are sufficiently different to 
not be source compatible, but only differ in what many perceive to be 
a version number, is hurting the image of both Perl 5 and Perl 6 in 
the world. Since the word "Perl" is still perceived as "Perl 5" in the 
world, it only seems fair that "Perl 6" changes its name.


Since Larry has indicated, in his video message to the participants of 
PerlCon 2019 in Riga, that the two sister languages are now old and 
wise enough to take care of themselves, such a name change would no 
longer require the approval of the BDFL.


I would therefore propose to change the name to "the Camelia 
Programming Language" or "Camelia" for short, for several reasons:


the search term "camelia programming language" already brings you to 
the right place. This means that changing the name to "Camelia" will 
have minimal impact on findability on search engines such as Google 
and DuckDuckGo.


the logo / mascot would not need changing: it's just that it now also 
becomes the actual name of the programming language.


"Camelia" in its name, still carries something Perlish inside of it.

The concept of "Camelia" being an implementation of a specification in 
"roast", still stands. The alternative, to use "Rakudo" as the name of 
the language, would cause confusion with the name being used to 
indicate an implementation, and would endanger the separation between 
specification and implementation.


Choosing yet another name, such as Albus, would mean having to start 
from scratch with marketing and getting the name out there. Hence my 
preference for a known name such as "Camelia".


The "Camelia" logo is still copyright Larry Wall, so it would allow 
Larry to still be connected to one of the programming languages that 
he helped get into the world.


https://github.com/perl6/problem-solving/issues/81

regards,
Eliza

Re: perl6's new name?

[JJ Merelo]

Hi,

El lun., 12 ago. 2019 a las 8:15, Eliza () escribió:

> Hello perl6 world,
>
> I saw the perl6 github issue, just was confused will perl6 change its name?
>

Yes, it might. Perl 6 will still be the language, but the implementation
(the stack including MoarVM, NQP and Rakudo) will be called Camelia. That's
the proposal, needs to be approved (or rejected).

Cheers

JJ

perl6's new name?

[Eliza]

Hello perl6 world,

I saw the perl6 github issue, just was confused will perl6 change its name?

Perl 6 was initially conceived to be the next version of Perl 5. It took 
way too long to mature to an initial release. Meanwhile, people 
interested in taking Perl 5 along, took back the reigns and continued 
developing Perl 5.


Having two programming languages that are sufficiently different to not 
be source compatible, but only differ in what many perceive to be a 
version number, is hurting the image of both Perl 5 and Perl 6 in the 
world. Since the word "Perl" is still perceived as "Perl 5" in the 
world, it only seems fair that "Perl 6" changes its name.


Since Larry has indicated, in his video message to the participants of 
PerlCon 2019 in Riga, that the two sister languages are now old and wise 
enough to take care of themselves, such a name change would no longer 
require the approval of the BDFL.


I would therefore propose to change the name to "the Camelia Programming 
Language" or "Camelia" for short, for several reasons:


the search term "camelia programming language" already brings you to the 
right place. This means that changing the name to "Camelia" will have 
minimal impact on findability on search engines such as Google and 
DuckDuckGo.


the logo / mascot would not need changing: it's just that it now also 
becomes the actual name of the programming language.


"Camelia" in its name, still carries something Perlish inside of it.

The concept of "Camelia" being an implementation of a specification in 
"roast", still stands. The alternative, to use "Rakudo" as the name of 
the language, would cause confusion with the name being used to indicate 
an implementation, and would endanger the separation between 
specification and implementation.


Choosing yet another name, such as Albus, would mean having to start 
from scratch with marketing and getting the name out there. Hence my 
preference for a known name such as "Camelia".


The "Camelia" logo is still copyright Larry Wall, so it would allow 
Larry to still be connected to one of the programming languages that he 
helped get into the world.


https://github.com/perl6/problem-solving/issues/81

regards,
Eliza

Re: .new?

[ToddAndMargo]

On 09/14/2018 03:39 AM, Timo Paulssen wrote:

Telemetry::Sampler isn't a routine, it's a class. You can follow the
link labelled "from Telemetry::Sampler" to get to the documentation of
the class by that name, which explains what it is, how you get it, and
how you use it.

I'll file a bug for the "new" routine page.

Hope that helps!
   - Timo


Thank you!

Re: .new?

[Brad Gilbert]

On Fri, Sep 14, 2018 at 6:19 AM Todd Chester  wrote:
>
>
>
> On 09/14/2018 03:34 AM, Simon Proctor wrote:
> > I think the docs of objects (sorry on my phone no link) describe object
> > creation and the default new quite well.
>
> They most probably are and most developers would have no issues
> figuring them out.
>
> If a common user can't make heads or tails out of them, then
> they need some work.  Perl 5's perldocs are wonderfully easy
> to understand.  The developers have their own specifications.
> The Docs need to be understandable by the riff raff.
>
>  > Do a search for objects.
>
> What do you mean?
>
> Can you throw an example at me?

In the Perl 6 docs you often are looking for a subroutine or a method
indiscriminately. So the routine pages pull from both lists dynamically.

That is what happened here.

In the case of `.new()` this is a really bad idea.
That is because every object has a new.

Since the pages for routines pull the method documentation out of its
broader context, it can sometimes be confusing.
The broader context being the pages for the types themselves.

This works decently for things like `.substr()` because there is really
only one type which that works on, and is fairly easy to guess about
the wider context.

In the case of `.new()` there is no way to guess about the wider
context.
It is also one of the methods that most people would just get,
so the documentation for each instance of this method
only describes the differences from the norm.

Basically the documentation for `.new()` needs to be hand-crafted.

Re: .new?

[Parrot Raiser]

> Do a search for objects.

What do you mean?

Into you favourite search engine, e.g. duckduckgo, type perl6 objects

Re: .new?

[Todd Chester]

On 09/14/2018 03:34 AM, Simon Proctor wrote:
I think the docs of objects (sorry on my phone no link) describe object 
creation and the default new quite well.


They most probably are and most developers would have no issues
figuring them out.

If a common user can't make heads or tails out of them, then
they need some work.  Perl 5's perldocs are wonderfully easy
to understand.  The developers have their own specifications.
The Docs need to be understandable by the riff raff.

> Do a search for objects.

What do you mean?

Can you throw an example at me?

Re: .new?

[Todd Chester]

On 09/14/2018 03:37 AM, Elizabeth Mattijsen wrote:

Good catch!


I am not sure exactly what I tripped across, but as
I tell my wife "sometimes it pays to be an idiot."

:-)

-T

Re: .new?

[Timo Paulssen]

The doc website creates the pages under "routine/" by collecting every
type's methods and relevant subs of that name and putting them all on a
page.

It's a very unfortunate accident that the one for Telemetry::Sampler
ends up at the top, because right below that is the one for Mu, which is
the most general one that also links to the "documentation on object
construction" where things are explained clearly in a tutorial style.

Telemetry::Sampler isn't a routine, it's a class. You can follow the
link labelled "from Telemetry::Sampler" to get to the documentation of
the class by that name, which explains what it is, how you get it, and
how you use it.

I'll file a bug for the "new" routine page.

Hope that helps!
  - Timo

On 14/09/2018 12:30, Todd Chester wrote:
> Hi All,
>
> What exactly is going on with .new?
>
>   https://docs.perl6.org/routine/new
>   method new(Telemetry::Sampler: @instruments --> Telemetry::Sampler:D)
>
> The whole thing went over my head.  It looks like
> specifications for the developers, but I really can't
> tell.  And it looks like it might be really handy.
>
> What can I use it for?
>
>
> Also, does "Telemetry::Sampler" mean what it does in Perl 5,
> which is a routine called "Sampler" found in the module
> called "Telemetry"?
>
> Many thanks,
> -T

Re: .new?

[Elizabeth Mattijsen]

Good catch!

I think that one is worth a documentation issue.  The perl6doc builder gathered 
information about all “new” methods it could find *without any context*, and 
put them into one file.  For a method such as “new” not the best thing to do.  
I would argue that this page should be replaced by an ad-hoc page explaining 
the default way how the “new” method works.

In any case, Telemetry::Sampler should *not* be the entry on this page.

> On 14 Sep 2018, at 12:30, Todd Chester  wrote:
> 
> Hi All,
> 
> What exactly is going on with .new?
> 
>  https://docs.perl6.org/routine/new
>  method new(Telemetry::Sampler: @instruments --> Telemetry::Sampler:D)
> 
> The whole thing went over my head.  It looks like
> specifications for the developers, but I really can't
> tell.  And it looks like it might be really handy.
> 
> What can I use it for?
> 
> 
> Also, does "Telemetry::Sampler" mean what it does in Perl 5,
> which is a routine called "Sampler" found in the module
> called "Telemetry"?
> 
> Many thanks,
> -T

Re: .new?

[Simon Proctor]

I think the docs of objects (sorry on my phone no link) describe object
creation and the default new quite well.

Do a search for objects.

On Fri, 14 Sep 2018, 11:30 Todd Chester,  wrote:

> Hi All,
>
> What exactly is going on with .new?
>
>https://docs.perl6.org/routine/new
>method new(Telemetry::Sampler: @instruments --> Telemetry::Sampler:D)
>
> The whole thing went over my head.  It looks like
> specifications for the developers, but I really can't
> tell.  And it looks like it might be really handy.
>
> What can I use it for?
>
>
> Also, does "Telemetry::Sampler" mean what it does in Perl 5,
> which is a routine called "Sampler" found in the module
> called "Telemetry"?
>
> Many thanks,
> -T
>

.new?

[Todd Chester]

Hi All,

What exactly is going on with .new?

  https://docs.perl6.org/routine/new
  method new(Telemetry::Sampler: @instruments --> Telemetry::Sampler:D)

The whole thing went over my head.  It looks like
specifications for the developers, but I really can't
tell.  And it looks like it might be really handy.

What can I use it for?


Also, does "Telemetry::Sampler" mean what it does in Perl 5,
which is a routine called "Sampler" found in the module
called "Telemetry"?

Many thanks,
-T

Re: Why is my class rejecting new()?

[Richard Hainsworth]

Futher to Timo's explanation, below is a rewrite of your code to consider.

The documentation reference is 
https://docs.perl6.org/language/classtut#Constructors


class Etran {
has $.dstamp is rw;
has $.folio is rw;
has $.ticker is rw;
has $.way; # only used at initialisation
has $.qty is rw;
has $.amount is rw;
has $.desc is rw;

submethod BUILD ( :$!dstamp, :$!folio, :$!ticker, :$!qty, :$!amount, 
:$!way = 'B', :$!desc ) {
$!qty = -$!qty if $!way ne 'B'; # set $way default to 'B' in 
signature
}
} # end of class declaration
# your new does not use $cmd, so I omitted it

# in program

my Etran $transaction .= new( :dstamp('some value'), :folio('another val'),
:qty( 15 ), :ticker( 'AXB' ), :amount( 4000 ), :desc('not alot') );
say $transaction;
my Etran $dummy .= new(:dstamp('some value'), :folio('another val'),
:qty( 15 ), :ticker( 'AXB' ), :amount( 4000 ), :desc('not alot') , 
:way('C'));
say $dummy;
# no information given about shlex-fields, but it need to return a list of 
named pairs,

# running the code above results in
# Etran.new(dstamp => "some value", folio => "another val", ticker => "AXB", way => "B", qty => 
15, amount => 4000, desc => "not alot")
# Etran.new(dstamp => "some value", folio => "another val", ticker => "AXB", way => "C", qty => 
-15, amount => 4000, desc => "not alot")

...

The only reason BUILD is needed is because $!qty is initialised from 
:qty and :way.


If there was no special intialisation, then no BUILD would be needed.


Timo explained the underlying reason, but the way I think of the 
difference between ! and . twiggles is that if you specify eg "has 
$.folio" in the class then perl6 creates a getter and setter 
automatically, so that when you have an instance of the class (eg. 
$transaction in my snippet), then you can write code as:

$transaction.folio = "arbitrary thing";

# if you don't use the attribute on left, then there is no need for the 
"is rw" trait in the declaration.


my $val = $transaction.folio; # these are automatically created methods 
in the class.


...

If you had specified "has $!folio" in the class, then later in the 
program $transaction.folio is undefined.


However, the getter/setter methods are created towards the end of the 
class creation process, and so they are not available to new or BUILD.


But within the class definition code (for example the BUILD submethod or 
a method called new), $!folio is always available, even if it is 
specified by "has $.folio".


Timo mentioned that your method new needs an explicit 'self.bless'.

There should be no need to create a 'new' method for a class because one 
is created automatically using the BUILD submethod (if it exists), and 
if you haven't provided one, perl6 creates one for you.


Hope this helps.



On Thursday, July 20, 2017 05:51 PM, Mark Carter wrote:


I have a class definition:

class Etran {
 has $.dstamp is rw;
 has $.folio is rw;
 has $.ticker is rw;
 has $.qty is rw;
 has $.amount is rw;
 has $.desc is rw;

 method new($line) {
 my ($cmd, $dstamp, $folio, $ticker, $qty, $amount, $way, 
$desc) = shlex-fields $line;
 $!dstamp = $dstamp;
 $!folio = $folio;
 $!ticker = $ticker;
 $!qty = $way == "B" ?? $qty !! - $qty;
 $!amount = $amount;
 $!desc = $desc;
 }

}**
which I instantiate with
my $e = Etran.new($line);

However, it gives an error message:
Cannot look up attributes in a Etran type object
at the line
$!dstamp = $dstamp;

Why that, and how do I fix it?

Also, I don't really understand the difference between using the twigils "." and using 
"!",
and have yet to see an explanation that I understand.

Re: Why is my class rejecting new()?

[Timo Paulssen]

On 20/07/17 11:51, Mark Carter wrote:
>
> I have a class definition:
>
> class Etran {
> has $.dstamp is rw;
> has $.folio is rw;
> has $.ticker is rw;
> has $.qty is rw;
> has $.amount is rw;
> has $.desc is rw;
>
> method new($line) {
> my ($cmd, $dstamp, $folio, $ticker, $qty, $amount, $way, 
> $desc) = shlex-fields $line;
> $!dstamp = $dstamp;
> $!folio = $folio;
> $!ticker = $ticker;
> $!qty = $way == "B" ?? $qty !! - $qty;
> $!amount = $amount;
> $!desc = $desc;
> }
>
> }**
> which I instantiate with
>   my $e = Etran.new($line);
>
> However, it gives an error message:
>   Cannot look up attributes in a Etran type object
> at the line 
>   $!dstamp = $dstamp;
>
> Why that, and how do I fix it?
>
> Also, I don't really understand the difference between using the twigils "." 
> and using "!",
> and have yet to see an explanation that I understand.
The method new is invoked on the type Etran itself, not an instance of
it. As such, no storage space exists to put the data into.

What you really want is to create a new Etran object using "self.bless"
and passing all of your variables as named arguments.

Another thing is that you're trying to compare strings with == ($way vs
"B"), but == is numerical comparison and as such will try to numify "B"
and whatever is in $way. You'll want the "eq" operator instead.


There are multiple differences between $. and $! - "$.foo" is just
short-hand for "self.foo.item", and since you'd usually use the "$.foo"
syntax with attributes only, you'll be using the accessor method that
gets created for you.

$! on the other hand directly accesses the underlying storage for the
attribute. These are private to the class that defines them.

Hope that helps a bit?
  - Timo

Why is my class rejecting new()?

[Mark Carter]

I have a class definition:

class Etran {
has $.dstamp is rw;
has $.folio is rw;
has $.ticker is rw;
has $.qty is rw;
has $.amount is rw;
has $.desc is rw;

method new($line) {
my ($cmd, $dstamp, $folio, $ticker, $qty, $amount, $way, $desc) 
= shlex-fields $line;
$!dstamp = $dstamp;
$!folio = $folio;
$!ticker = $ticker;
$!qty = $way == "B" ?? $qty !! - $qty;
$!amount = $amount;
$!desc = $desc;
}

}**
which I instantiate with
my $e = Etran.new($line);

However, it gives an error message:
Cannot look up attributes in a Etran type object
at the line
$!dstamp = $dstamp;

Why that, and how do I fix it?

Also, I don't really understand the difference between using the twigils "." and using 
"!",
and have yet to see an explanation that I understand.

Re: What's involved in the creation of a new Rakudo * version?

[Aaron Sherman]

Yep, I'm pleased that Star is behind a bit. It needs to be the stable face
of Perl 6, but updated frequently enough that it's not irrelevant.

On Sun, Oct 16, 2016, 12:51 PM Steve Mynott  wrote:

> There are star releases every 3 months.
>
> There was a RC0 of 2016.10 released today.
>
> There is a link on perl6.org to the Tarball.
>
> You can help by installing on as many systems as possible -- particularly
> on recent Linux systems with HLE in /proc/cpuinfo
>
> Cheers Steve
>
>
> On Sunday, 16 October 2016, Parrot Raiser <1parr...@gmail.com> wrote:
>
> We "Star" users are falling rather behind the compiler versions.
> I'd like to help catch up, if the processes involved are sufficiently
> mundane.
> Is there a checklist of the required tasks from which to work?
>
>
>
> --
> 4096R/EA75174B Steve Mynott 
>
>

Re: What's involved in the creation of a new Rakudo * version?

[Steve Mynott]

There are star releases every 3 months.

There was a RC0 of 2016.10 released today.

There is a link on perl6.org to the Tarball.

You can help by installing on as many systems as possible -- particularly
on recent Linux systems with HLE in /proc/cpuinfo

Cheers Steve

On Sunday, 16 October 2016, Parrot Raiser <1parr...@gmail.com> wrote:

> We "Star" users are falling rather behind the compiler versions.
> I'd like to help catch up, if the processes involved are sufficiently
> mundane.
> Is there a checklist of the required tasks from which to work?
>


-- 
4096R/EA75174B Steve Mynott 

Re: What's involved in the creation of a new Rakudo * version?

[Moritz Lenz]

Hi

On 16.10.2016 17:24, Parrot Raiser wrote:
> We "Star" users are falling rather behind the compiler versions.
> I'd like to help catch up, if the processes involved are sufficiently mundane.
> Is there a checklist of the required tasks from which to work?

Yes, there is:
https://github.com/rakudo/star/blob/master/tools/star/release-guide.pod

Cheers,
Moritz


-- 
Moritz Lenz
https://deploybook.com/ -- https://perlgeek.de/ -- https://perl6.org/

Re: Proposed new string methods: trim-rw, trim-leading-rw, trim-trailing-rw

[Philip Hazelden]

Correct me if I'm wrong, can't you do

$s .= trim

?

On 12:45pm, Fri, 14 Aug 2015 Tom Browder tom.brow...@gmail.com wrote:

 In an earlier thread of mine on this list seeking help, Liz mentioned
 one string method that has now been dcoumented, 'substr-rw', which
 allows in-place modification of a string variable.

 In my journey with Perl 6 I have enjoyed the string 'trim' method so I
 can do this:

   my $s = '   blah ';
   $s = $s.trim;
   say $s; # 'blah'

 Using 'substr-rw' as precedent, I am proposing a similar set of
 methods for 'trim' so that I can do this:

   my $s = '  blah ';
   $s.trim-rw;
   say $s; # 'blah';

 (and similarly for 'trim-leading-rw' and 'trim-trailing-rw').

 If there is no objection, I would like to add a feature request but
 where to do it?  The immediate place I thought of is the Rakudo git
 site but isn't this more of a language feature?

 Best regards,

 -Tom

Re: Proposed new string methods: trim-rw, trim-leading-rw, trim-trailing-rw

[Brandon Allbery]

On Fri, Aug 14, 2015 at 8:07 AM, Tom Browder tom.brow...@gmail.com wrote:

 But I've tried it and it works (but the syntax still bothers me for
 now).  Note that the same behavior applies to the 'substr' string
 method so that begs the question of why is the 'substr-rw' method
 justified and 'trim-rw' not?  It seems at first glance that the
 'substr-rw' method should be removed.


IIRC substr-rw is a performance hack because substr was being slowed in all
cases in order to accommodate the rw use case. trim doesn't have the same
issue.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Proposed new string methods: trim-rw, trim-leading-rw, trim-trailing-rw

[Tom Browder]

On Aug 14, 2015 8:46 AM, Brandon Allbery allber...@gmail.com wrote:
 On Fri, Aug 14, 2015 at 8:07 AM, Tom Browder tom.brow...@gmail.com wrote:
...
 now).  Note that the same behavior applies to the 'substr' string
 method so that begs the question of why is the 'substr-rw' method
 justified and 'trim-rw' not?  It seems at first glance that the
 'substr-rw' method should be removed.
...
 IIRC substr-rw is a performance hack because substr was being slowed
 in all cases in order to accommodate the rw use case. trim doesn't
 have the same issue.

Thanks for the enlightenment, Brandon.

-Tom

Re: Writing New Modules for Submission

[Tobias Leich]

Hi, a Makefile, Changelog and MANIFEST or LICENSE files belong into the
root directory, and should not be removed.
Module that you write for tests might go under t/lib. Other files like
media files that shall be installed should be in resource or share.

Am 21.03.2015 um 16:51 schrieb Tom Browder:

 The guidance for the directory layout for a proposed module is very
 clear for mandatory items, and two other directories are also
 mentioned: bin and doc.

 What about other items such as a Makefile for developer use,
 development test scripts and modules, and miscellaneous files found in
 CPAN Perl 5 modules such as TODO, Changes, and MANIFEST?  Should they
 be removed, or maybe moved to a directory hidden from the module
 ecosystem?

 Thanks.

 -Tom

Writing New Modules for Submission

[Tom Browder]

The guidance for the directory layout for a proposed module is very clear
for mandatory items, and two other directories are also mentioned: bin and
doc.

What about other items such as a Makefile for developer use, development
test scripts and modules, and miscellaneous files found in CPAN Perl 5
modules such as TODO, Changes, and MANIFEST?  Should they be removed, or
maybe moved to a directory hidden from the module ecosystem?

Thanks.

-Tom

Re: New Perl 6 Advent Calendar: call for ideas

[Leon Timmermans]

2010/11/6 Tadeusz Sośnierz tadzi...@gmail.com:
 As I accidentally volunteered for managing a list of topics and writers
 for this year's Advent Calendar [1], I started to collect some ideas of
 things it'd be nice to write about. There's a gist [2] with the list of
 things from the top of my head. If you have any ideas, please post them,
 bonus points if you could write about it.

I found the Fibers implementation[1] recently posted on perl6-language
really interesting, and it may be a good way to show off the power of
lazy lists and gather/take.

Leon

[1] http://www.mail-archive.com/perl6-...@perl.org/msg90270.html

New Perl 6 Advent Calendar: call for ideas

[Tadeusz Sośnierz]

Hello,
As I accidentally volunteered for managing a list of topics and writers
for this year's Advent Calendar [1], I started to collect some ideas of
things it'd be nice to write about. There's a gist [2] with the list of
things from the top of my head. If you have any ideas, please post them,
bonus points if you could write about it.

Regards,
Ted

[1] http://perl6advent.wordpress.com/
[2] https://gist.github.com/664348

Re: New Perl 6 Advent Calendar: call for ideas

[Moritz Lenz]

Hi,

On 11/06/2010 01:51 PM, Tadeusz Sośnierz wrote:
 As I accidentally volunteered for managing a list of topics and writers
 for this year's Advent Calendar [1],

Thanks for volunteering!

 I started to collect some ideas of
 things it'd be nice to write about. There's a gist [2] with the list of
 things from the top of my head. If you have any ideas, please post them,
 bonus points if you could write about it.

I'd suggest to use a file in a repo that we can easily edit, like last
year's https://github.com/perl6/mu/tree/master/misc/perl6advent-2009/

Possible topics of interest (two stars mark those topics that I'd write
about myself, though certainly not all of them, and I'm happy to
delegate to others):


** MAIN and USAGE subs
* laziness (+ perhaps list iteration model)
* series operator
* explaining one or more Perl 6 solutions on rosettacode
** lexical subs and importing/exporting
* is everything a reference?
** Z and X meta operators (not covered in
http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperator/ )
** basic parsing: what is a term, what is an operator? why is the
distinction import?
** meta object protocol
* the Perl 6 community
* infrastructure (what editors/IDEs are good for Perl 6 hacking/have
syntax hilighting, tools used for hacking and presentations etc.)

Cheers,
Moritz

New Perl 6 wiki page on Perl 6 fundraising and related topics.

[Conrad Schneiker]

I've started a new Perl 6 wiki page for Perl 6 fundraising and
related topics:

http://www.perlfoundation.org/perl6/index.cgi?perl_6_donations_and_fundraisi
ng

It's still very preliminary, and it may take another day or two
before I finish collecting stuff from previous discussion threads
that I also plan to include.

Best regards,
Conrad Schneiker

www.AthenaLab.com

http://www.perlfoundation.org/perl6  - Official Perl 6 Wiki
http://www.perlfoundation.org/parrot - Official Parrot Wiki

Best regards,
Conrad Schneiker