Re: lines :$nl-in question

[ToddAndMargo via perl6-users]

On 2020-08-28 18:49, Paul Procacci wrote:
|c slurps the remaining arguments into c and passese those arguments to 
the lines method of IO::Handle.


I do not understand

Re: lines :$nl-in question

[Paul Procacci]

:nl-in is a named parameter that defines what the method lines would
consider as line endings.
It defines  "\x0A", "\r\n" as the default.

Example:
 % echo "Hi, Frank." > test.txt ; echo "What's up?" >> test.txt ; echo
'"test.txt".IO.lines(:nl-in).say' > test.pl6 ; perl6 ./test.pl6
(Hi, Fr nk.
Wh t's up?
)

|c slurps the remaining arguments into c and passese those arguments to the
lines method of IO::Handle.

On Fri, Aug 28, 2020 at 9:18 PM ToddAndMargo via perl6-users <
perl6-us...@perl.org> wrote:

> Hi All,
>
> In the following:
>
> https://docs.raku.org/type/IO::Path#method_lines
>
> (IO::Path) method lines
>
> Defined as:
>
> method lines(IO::Path:D: :$chomp = True, :$enc = 'utf8', :$nl-in =
> ["\x0A", "\r\n"], |c --> Seq:D)
>
> Opens the invocant and returns its lines.
>
> The behavior is equivalent to opening the file specified
> by the invocant, forwarding the :$chomp, :$enc,
> and :$nl-in arguments to IO::Handle.open, then calling
> IO::Handle.lines on that handle, forwarding any of the
> remaining arguments to that method, and returning the
> resultant Seq.
>
> What exactly is and how exactly do you use `:$nl-in`
>
> And if I am not pushing it, what is `|c`?
>
> I am confused,
> -T
>


-- 
__

:(){ :|:& };:

Re: Raku User's Survey 2020 out now....

[ToddAndMargo via perl6-users]

On 2020-08-25 16:46, ToddAndMargo via perl6-users wrote:

On 2020-08-25 16:18, William Michels via perl6-users wrote:

Reposting this from Rakudo Weekly News:

2020.34 Another Survey Time [by liztormato]

"It's that time of the year again! Time for the yearly Raku User
Survey! Please fill in the survey so that the Raku Community can
better tweak the Raku experience. Kudos to JJ Merelo for organizing
this once again!"

Link to Rakudo Weekly News [2020.34]:
https://rakudoweekly.blog/2020/08/24/2020-34-another-survey-time/

Nota bene: The first link on the webpage above "Raku User Survey" will
take you to the GoogleDocs form. If you fill out the form there should
be a link at the top to take you to the current results. If you lose
that link (or want to check back later in the week), simply change the
GoogleDocs URL from the survey Form ending of ".../viewform" to the
survey Analytics ending of .../viewanalytics".

Seventy responses so far! Thanks for doing this JJ!

Best, Bill.




Hi Bill,

I noted it over on the survey, but the things I would
like to see upcoming are

1) documentation that is written for both the beginner
and the advanced user.  Currently, it is only written
for the advanced user, who does not need it.  The
documentation should eventual be on par with Perl 5's
Perl Docs where everyone can use it.

2) a GUI creation tool and support modules to use the
results

3) A gui / no gui switch for Windows.

https://github.com/rakudo/rakudo/issues/3582

Currently, a black box always pops up, disturbing the
user who clicks the "X" in the upper right faster than
a shop-a-holic swipes a credit card.

4) functional support for FTP that works

5) functional support for reading web sites (the text)
and properly follow redirects on par with curl.

6) no separate packages for zef and raku in the
repos, Fedora's for instance.


I think the survey was fishing for complements, which
the got a lot from me.  (Well, except for the
documentation.)  I ADORE Raku.

-T



Missed one:

8)  The developers seriously need to fix the staging
compile times on par with Perl 5:

$ raku -c --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  18.108
Stage syntaxcheck: Syntax OK

lines :$nl-in question

[ToddAndMargo via perl6-users]

Hi All,

In the following:

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

   (IO::Path) method lines

   Defined as:

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


   Opens the invocant and returns its lines.

   The behavior is equivalent to opening the file specified
   by the invocant, forwarding the :$chomp, :$enc,
   and :$nl-in arguments to IO::Handle.open, then calling
   IO::Handle.lines on that handle, forwarding any of the
   remaining arguments to that method, and returning the
   resultant Seq.

What exactly is and how exactly do you use `:$nl-in`

And if I am not pushing it, what is `|c`?

I am confused,
-T

Re: Raku User's Survey 2020 out now....

[ToddAndMargo via perl6-users]

On 2020-08-28 07:49, Brad Gilbert wrote:
Now with all of that said, it is little wonder why Todd has difficulties 
with the function descriptions where others don't.


I also think that if we just replaced what we have for something that 
works for Todd it might make it more difficult for others.

Again because his brain is more unique than most.


Hi Brad,

I am weird, not autistic.  But I do see things that
other people can not see, which is why I am so good
at troubleshooting.

By the way, I adore the way Larry Wall writes.  He
is extremely good at explaining things.  I think
he is damned brilliant.

Also, I can easily tell well written documentation from
poorly written documentation.  Perl 5's Perl Docs
is a great example of well written documentation.

And I am not after a total trash and replacement.  The
framework used currently is good.  It is just not organized
such that it is usable by beginners.

A good point would be to start with the cryptogram, and then
decompose it

this does this
this does this
this does this.

Now looking at
https://docs.raku.org/routine/lines

 sub lines(Str(Cool))
 method lines()

 Coerces the invocant (and in sub form, the argument)
 to Str, decomposes it into lines (with the newline
 characters stripped), and returns the list of lines.

Good so far, but were is $limit and :$chomp stated?
Somewhere in the bowels of the page?  Why is it
missing from the cryptogram?

It should state right away what the parameters are
and what they do.

You have Linux installed on your machine.  Try this
$ nmcli -- help
In your face, tells you what you need.  Defines each
term.


And, not to kick a dead horse, when you use esoteric
terms, meaning those requiring specialized knowledge,
you need to link or define them.  But you don't.
A great example of this shortfall can be found over on

RFE: add some links to Operators #3175
https://github.com/Raku/doc/issues/3175

You will note, I fully described what these esoteric
terms are.  It is a great explanation too.

The response from JJ (Hi JJ) was:

 "I don't really think we should go down to that
 level of detail."

If you don't want the terms to remain "insider knowledge",
yes you should.

So to summarize, the framework is there and mostly
good.  It just need to be refined with the beginner
in mind.  Start small and work up.  And remove the jumble.

Here is an example of a wonderful clean up:
https://docs.raku.org/type/Str#method_contains

When writing documentation, remember "if the reader knew
what he was doing, he would not need the documentation".

And "the solution is intuitively obvious and left up
to the student to figure out on his own" is useless
rubbish.

Also, please keep in mind, that I have tried my hand at
upgrading the documentation, I just cant get past JJ.
"Grant me the wisdom to know the things I can change
and can not change and to know the difference."

-T

Re: Raku User's Survey 2020 out now....

[ToddAndMargo via perl6-users]

On 2020-08-28 03:57, Tom Browder wrote:

On Thu, Aug 27, 2020 at 20:41 ToddAndMargo via perl6-users
 wrote:

On 2020-08-27 16:53, Daniel Long Sockwell wrote:

Very few of the other [methods are documented] this way.


Todd, I have one more suggestion: Why don't you put your "keepers" on Github?

Several advantages:

1. easy to change

2. easy to find

3. more eyes on it

4. PRs from interested parties to fix typos or maybe even errors

5. used Markdown format and can easily convert to pdf

6. maybe inspire you to publish your own Raku book

-Tom



All wonderful suggestions.

And it is in the works, but will probably be a year off.
With the commie flu shutdown, I am so busy I want
to scream.

Re: Extended identifiers in named attributes

[Marcel Timmerman]

Hi Ralph,
Thanks for your answer.

The name 'attributes' was wrong, I meant 'arguments'. Sorry for that. I 
was working on XML files and mixed up some terms.

I don't think you're supposed to be able to have extended identifiers
as named parameter/argument identifiers. They are meant for a few
specific scenarios where there's special value in having adverbs aka
pairs embedded in identifiers:

* Alternations in grammars. Typically of form `foo:sym`.

* Appending :api<>, :auth<>, :ver<> to package identifiers.

They *may* work in a couple of other scenarios but in general,
don't do that.

By the way, "attributes" has a specific meaning in Raku, namely the
fields of object instances.

Regards,
Marcel


--
love, raiph


On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman > wrote:


Hi everyone,

I was experimenting with extended identifiers and found that it is
not possible to use it in named attributes. E.g.

> sub a (:$x:y) { say $x:y; }
===SORRY!=== Error while compiling:
Unsupported use of y///.  In Raku please use: tr///.
--> sub a (:$x:y⏏) { say $x:y; }


> sub a (:$abc:def) { say $abc:def; }
===SORRY!=== Error while compiling:
Invalid typename 'def' in parameter declaration.
--> sub a (:$abc:def⏏) { say $abc:def; }

Is there a trick of some sort to get this done? At the moment I
can only use a slurpy hash and check for its keys. This is good
enough for me but out of curiosity I ask. If not possible, an
extra note in the documentation on named arguments would be necessary.

regards,
Marcel

Re: Raku User's Survey 2020 out now....

[yary]

Right after sending I saw that the semicolon wasn't the issue, sorry! The
second half of my message is correct I think. The command reads a line at a
time, then calls lines()[3,2,5] on that single line which has no lines
after the zeroth.

tee hee, zeroth is a word!

-y


On Fri, Aug 28, 2020 at 10:59 AM William Michels 
wrote:

> I remove the semicolon, and it throws an error:
>
> $ cat test_lines.txt | raku -ne 'my $x=$_; say $x for
> $x.lines()[3,2,5] -> $i {say $i;}'
> ===SORRY!=== Error while compiling -e
> Unexpected block in infix position (missing statement control word
> before the expression?)
> at -e:1
> --> my $x=$_; say $x for $x.lines()[3,2,5] ->
> expecting any of:
> infix
> infix stopper
>
> What's the correct code?
>
> Best, Bill.
>
>
> On Thu, Aug 27, 2020 at 2:12 PM yary  wrote:
> >
> > You have an extra semicolon in there -" say $x; for" -
> >
> > so what happens is for each line
> > 1. it runs "say $x" and thus prints "Line 0" the first time through,
> since it had read "Line 0" only
> > 2. Then it runs "say $i" for each of $x.lines()[3,2,5] - but $x is only
> "Line 0" so it says 3 x "Nil"
> > 3. Repeat for "Line 1", etc
> > -y
> >
> >
> > On Thu, Aug 27, 2020 at 1:40 PM ToddAndMargo via perl6-users <
> perl6-us...@perl.org> wrote:
> >>
> >> On 2020-08-27 13:28, Tobias Boege wrote:
> >> > On Thu, 27 Aug 2020, ToddAndMargo via perl6-users wrote:
> >> >> To pick out particular lines:
> >> >> $ cat Lines.txt | raku -e '.say for lines()[3,2,5]'
> >> >> Line 3
> >> >> Line 2
> >> >> Line 5
> >> >>
> >> >> If it is, it is buried somewhere.
> >> >>
> >> >> And what goes inside the ()?  That may seem like a dumb
> >> >> remark (especially since I live and die in Top Down and
> >> >> know very well what the () does) but it is a common mistake
> >> >> I make with lines is forgetting the () when using the [].
> >> >>
> >> >
> >> > How does that mistake manifest? I cannot see a way in which omitting
> >> > the sub call parentheses in code like that could possibly lead to some
> >> > different behavior.
> >> >
> >>
> >> Here is does not:
> >>
> >> $ cat Lines.txt | raku -e '.say for lines[3,2,5]'
> >> Line 3
> >> Line 2
> >> Line 5
> >>
> >> And I am having trouble reproducing the issue.  Would
> >> help my point, no?  I will write back if I find it.
> >> Usually I forget my mistakes as soon as I figure out
> >> the right way to do things.
> >>
> >> Now this is getting weird!
> >>
> >> $ cat Lines.txt | raku -ne 'my $x=$_; say $x; for $x.lines()[3,2,5] ->
> >> $i {say $i;}'
> >>
> >> Line 0
> >> Nil
> >> Nil
> >> Nil
> >> Line 1
> >> Nil
> >> Nil
> >> Nil
> >> Line 2
> >> ...
>

Re: Raku User's Survey 2020 out now....

[William Michels via perl6-users]

I remove the semicolon, and it throws an error:

$ cat test_lines.txt | raku -ne 'my $x=$_; say $x for
$x.lines()[3,2,5] -> $i {say $i;}'
===SORRY!=== Error while compiling -e
Unexpected block in infix position (missing statement control word
before the expression?)
at -e:1
--> my $x=$_; say $x for $x.lines()[3,2,5] ->
expecting any of:
infix
infix stopper

What's the correct code?

Best, Bill.


On Thu, Aug 27, 2020 at 2:12 PM yary  wrote:
>
> You have an extra semicolon in there -" say $x; for" -
>
> so what happens is for each line
> 1. it runs "say $x" and thus prints "Line 0" the first time through, since it 
> had read "Line 0" only
> 2. Then it runs "say $i" for each of $x.lines()[3,2,5] - but $x is only "Line 
> 0" so it says 3 x "Nil"
> 3. Repeat for "Line 1", etc
> -y
>
>
> On Thu, Aug 27, 2020 at 1:40 PM ToddAndMargo via perl6-users 
>  wrote:
>>
>> On 2020-08-27 13:28, Tobias Boege wrote:
>> > On Thu, 27 Aug 2020, ToddAndMargo via perl6-users wrote:
>> >> To pick out particular lines:
>> >> $ cat Lines.txt | raku -e '.say for lines()[3,2,5]'
>> >> Line 3
>> >> Line 2
>> >> Line 5
>> >>
>> >> If it is, it is buried somewhere.
>> >>
>> >> And what goes inside the ()?  That may seem like a dumb
>> >> remark (especially since I live and die in Top Down and
>> >> know very well what the () does) but it is a common mistake
>> >> I make with lines is forgetting the () when using the [].
>> >>
>> >
>> > How does that mistake manifest? I cannot see a way in which omitting
>> > the sub call parentheses in code like that could possibly lead to some
>> > different behavior.
>> >
>>
>> Here is does not:
>>
>> $ cat Lines.txt | raku -e '.say for lines[3,2,5]'
>> Line 3
>> Line 2
>> Line 5
>>
>> And I am having trouble reproducing the issue.  Would
>> help my point, no?  I will write back if I find it.
>> Usually I forget my mistakes as soon as I figure out
>> the right way to do things.
>>
>> Now this is getting weird!
>>
>> $ cat Lines.txt | raku -ne 'my $x=$_; say $x; for $x.lines()[3,2,5] ->
>> $i {say $i;}'
>>
>> Line 0
>> Nil
>> Nil
>> Nil
>> Line 1
>> Nil
>> Nil
>> Nil
>> Line 2
>> ...

Re: Extended identifiers in named attributes

[yary]

I wonder what was intended with these extended identifiers?
https://github.com/Raku/problem-solving/issues/224* - Extended
identifiers-why and where, exactly?*
-y


On Fri, Aug 28, 2020 at 8:26 AM Ralph Mellor 
wrote:

> I don't think you're supposed to be able to have extended identifiers
> as named parameter/argument identifiers. They are meant for a few
> specific scenarios where there's special value in having adverbs aka
> pairs embedded in identifiers:
>
> * Alternations in grammars. Typically of form `foo:sym`.
>
> * Appending :api<>, :auth<>, :ver<> to package identifiers.
>
> They *may* work in a couple of other scenarios but in general,
> don't do that.
>
> By the way, "attributes" has a specific meaning in Raku, namely the
> fields of object instances.
>
> --
> love, raiph
>
>
> On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman  wrote:
>
>> Hi everyone,
>>
>> I was experimenting with extended identifiers and found that it is not
>> possible to use it in named attributes. E.g.
>>
>> > sub a (:$x:y) { say $x:y; }
>> ===SORRY!=== Error while compiling:
>> Unsupported use of y///.  In Raku please use: tr///.
>> --> sub a (:$x:y⏏) { say $x:y; }
>>
>>
>> > sub a (:$abc:def) { say $abc:def; }
>> ===SORRY!=== Error while compiling:
>> Invalid typename 'def' in parameter declaration.
>> --> sub a (:$abc:def⏏) { say $abc:def; }
>>
>>
>> Is there a trick of some sort to get this done? At the moment I can only
>> use a slurpy hash and check for its keys. This is good enough for me but
>> out of curiosity I ask. If not possible, an extra note in the documentation
>> on named arguments would be necessary.
>>
>> regards,
>> Marcel
>>
>>
>>

Re: Readline package

[Daniel ”Fooist” Lathrop]

10-4

cpan:fooist it is.

Sent from my iPhone

Daniel Lathrop (@lathropd)
Mobile: (206) 718-0349 
PGP key: https://keybase.io/lathropd (raw) 

> On Aug 28, 2020, at 9:51 AM, Ralph Mellor  wrote:
> 
> 
>> 
>> You can alter  to whatever (it just needs to be a string...
> 
> Larry may comment, but in case not, or, if he does, to save him
> some time and give him something to correct, here's my take on
> what he specified^H^H^H^H^Hulated.
> 
> @Larry defined the auth to be a URI.
> 
> Quoting https://en.wikipedia.org/wiki/Uniform_Resource_Identifier:
> 
>> A Uniform Resource Identifier (URI) is a string of characters that
>> unambiguously identifies a particular resource.
> ...
>> The most common form of URI is the Uniform Resource Locator (URL)
> ...
>> More rarely seen in usage is the Uniform Resource Name (URN) ..
>> .for the identification of resources in particular namespaces.
> 
> So, rarely, but sometimes, a URI is an URN.
> 
> Larry didn't specify a URN but rather a URI. So I think he was allowing
> us to go either the URL or URN route. If so, then this perhaps "strangely"
> mirrors his choice of auth as being ambiguously either author or authority.
> 
> But I think, in general, he tilted URN in his examples.
> 
> Continuing with Wikipedia:
> 
>> [G]eneric syntax consists of a hierarchical sequence of five components:
>> URI = scheme:[//authority]path[?query][#fragment]
> 
> So, at its simplest, scheme:path.
> 
> Larry's examples were things like cpan:JRANDOM and github:raiph.
> 
> The Wikipedia page has a section on URI resolution including:
> 
>> Resolving a URI reference against a base URI results in a target URI.
>> The base URI can be obtained, in order of precedence, from:
> ...
>> the context of the application.
> 
> So I think the idea here is that our toolchain determines how the
> string is interpreted.
> 
> So, yes, you can type any string, but that string has a specific
> meaning determined by the toolchain.
> 
> And toolchain tools "should" be sensible, and follow @Larry's
> guidance. Which is to start with, and perhaps stick with, `foo:bar`,
> where:
> 
> * `foo` is one of whatever "schemes" we adopt; which we can for
>  now assume correspond repo domain names -- cpan, github, ...
> 
> * `bar` is a username that's unique within the given scheme.
> 
> --
> love, raiph
> 

Re: Extended identifiers in named attributes

[Ralph Mellor]

I don't think you're supposed to be able to have extended identifiers
as named parameter/argument identifiers. They are meant for a few
specific scenarios where there's special value in having adverbs aka
pairs embedded in identifiers:

* Alternations in grammars. Typically of form `foo:sym`.

* Appending :api<>, :auth<>, :ver<> to package identifiers.

They *may* work in a couple of other scenarios but in general,
don't do that.

By the way, "attributes" has a specific meaning in Raku, namely the
fields of object instances.

--
love, raiph


On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman  wrote:

> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }
>
>
> Is there a trick of some sort to get this done? At the moment I can only
> use a slurpy hash and check for its keys. This is good enough for me but
> out of curiosity I ask. If not possible, an extra note in the documentation
> on named arguments would be necessary.
>
> regards,
> Marcel
>
>
>

Re: Raku User's Survey 2020 out now....

[Andy Bach]

>> Without any arguments, sub lines operates on $*ARGFILES, which
>> defaults to $*IN in the absence of any filenames.

> Be careful with that one, $*IN will lop of the first line if you are not 
> careful.

I think you're talking about mixing $*IN with the "-n" option
# raku -e 'say join(", ", $*IN.lines())' < /tmp/lines.txt
lines 1, lines 2, lines 3, lines 4, lines 5
# raku -ne 'say join(", ", $*IN.lines())' < /tmp/lines.txt
lines 2, lines 3, lines 4, lines 5

It's not lopping, the "-n" takes one line from $*IN before your code executes.

a

p.s.
"cryptogram", at least in my newspaper, is a quote and author's name encoded in 
a substitution cipher (G for A etc) to solve.

Andy Bach, BS, MSCMECFA
Systems Mangler
Internet: andy_b...@wiwb.uscourts.gov
Voice: (608) 261-5738, Cell: (608) 658-1890

"The three great problems of computer science:
compiler complexity and 'off-by-one' errors".
https://martinfowler.com/bliki/TwoHardThings.html


From: ToddAndMargo via perl6-users 
Sent: Thursday, August 27, 2020 8:41 PM
To: perl6-us...@perl.org 
Subject: Re: Raku User's Survey 2020 out now

On 2020-08-27 16:53, Daniel Long Sockwell wrote:

>> Very few of the other [methods are documented] this way.
>> This one also started with an error in the cryptogram
>> as well.  (That is another complaint about the
>> documentation.  The cryptograms are often wrong.)
>> And there should be zero tolerance for "insider knowledge".
>
> This might be a bit ironic, but I can't follow what you're saying here.
> What do you mean by "cryptogram"?  To me, that strikes me as _much_ more
> of an esoteric term than anything in the Raku docs -- but maybe it has a
> common meaning in this context that I just haven't come across (and that
> a basic Internet search didn't turn up).

Here is one.

multi method starts-with(Str:D: Str(Cool) $needle, :i(:$ignorecase),
:m(:$ignoremark) --> Bool:D)

This one is pretty easy to figure out.  Most of the time
though, I get the "what is the world?" thing. When
I do figure them out and they are correct, they can
actually be very helpful.

And I never remember the official name.

>> And "in your face example" would be one of my all time
>> favorite routines which is "lines".  I use "lines"
>> ALL-THE-TIME.
>>
>> https://docs.raku.org/routine/lines
>
> This is so fascinating to me -- you provide that as an example of poor
> documentation, but *I* would look at that as an area where Raku (with
> the help of its docs) just clicks perfectly into place.  Everything that
> the docs explain for this and related topics fits together into a
> cohesive whole, and after reading the docs, I not only see how the language
> works, but am also left with the feeling that the language couldn't
> possibly work any other way.

I picked "lines" on purpose as I KNOW ow it operates.
It is one sweet function, especially when I am careening through raw web
pages.  I as not looking for help with it.


>
>> Without any arguments, sub lines operates on $*ARGFILES, which
>> defaults to $*IN in the absence of any filenames.

Be careful with that one, $*IN will lop of the first line
if you are not careful.


> If you're willing to post your "keepers", I bet others would enjoy
> reading them as well.

Most of them are written specifically for me.  As you can
tell, I am "weird".  It would be anenormous undertaking
for me to clean most of them up.

Usually, when someone asks about a specific thing I have
a keeper on, I will (clean it up and) post it back.
Or if I am just tickled with what I came up with.

When I do, I get all my misspelling pointed out an
any booboo annotated.  It does really help enormously.

Since you are working on the documentation, feel free to
ping me to see if I have something written on the subject.
I am more than happy to have you use from it.  Or maybe
just to see what I find important about he subject.

>
>> Hope that explains it.  I ADORE Raku.  The only thing
>> I dislike is the documentation.
>
> I'm glad you like Raku -- I feel the same way.  Now, I'm going to get
> back to trying to improve the documentation; I've submitted two pull
> requests today, and am making decent progress towards a third.  Maybe
> one day, you'll like the docs as much as you like the language itself.

I have programmed in several languages in my lifetime.  I have to say,
Raku is just damned fun to program in!  And
the community is wonderful.

-T

p.s. my favorite variable is the Associative Array (hash).
(I like put both descriptions together as it nicely describes
what a has is.)

Here is my keeper on a hash:

12/08/2019:

Perl 6 Hashes (associative arrays):


References:
 https://docs.raku.org/language/subscripts#Basics
 https://docs.raku.org/type/Hash#___top
 https://docs.raku.org/type/Hash#:exists
 https://docs.raku.org/type/Hash#method_append



A hash "associates" a Name, called a "key" to a Value, called a "value"

You assign them 

Re: Readline package

[Ralph Mellor]

> You can alter  to whatever (it just needs to be a string...

Larry may comment, but in case not, or, if he does, to save him
some time and give him something to correct, here's my take on
what he specified^H^H^H^H^Hulated.

@Larry defined the auth to be a URI.

Quoting https://en.wikipedia.org/wiki/Uniform_Resource_Identifier:

> A Uniform Resource Identifier (URI) is a string of characters that
> unambiguously identifies a particular resource.
...
> The most common form of URI is the Uniform Resource Locator (URL)
...
> More rarely seen in usage is the Uniform Resource Name (URN) ..
>.for the identification of resources in particular namespaces.

So, rarely, but sometimes, a URI is an URN.

Larry didn't specify a URN but rather a URI. So I think he was allowing
us to go either the URL or URN route. If so, then this perhaps "strangely"
mirrors his choice of auth as being ambiguously either author or authority.

But I think, in general, he tilted URN in his examples.

Continuing with Wikipedia:

> [G]eneric syntax consists of a hierarchical sequence of five components:
> URI = scheme:[//authority]path[?query][#fragment]

So, at its simplest, scheme:path.

Larry's examples were things like cpan:JRANDOM and github:raiph.

The Wikipedia page has a section on URI resolution including:

> Resolving a URI reference against a base URI results in a target URI.
> The base URI can be obtained, in order of precedence, from:
...
> the context of the application.

So I think the idea here is that our toolchain determines how the
string is interpreted.

So, yes, you can type any string, but that string has a specific
meaning determined by the toolchain.

And toolchain tools "should" be sensible, and follow @Larry's
guidance. Which is to start with, and perhaps stick with, `foo:bar`,
where:

* `foo` is one of whatever "schemes" we adopt; which we can for
  now assume correspond repo domain names -- cpan, github, ...

* `bar` is a username that's unique within the given scheme.

--
love, raiph

Re: Raku User's Survey 2020 out now....

[Brad Gilbert]

Daniel, the thing about Todd is that his brain doesn't process the written
word the way most people do.
That is according to him by the way.

He is under the assumption that it is because of how he was taught to read.
I think the issue is different.

I think that he might be on the Autistic Spectrum like me. (And possibly
Larry Wall himself.)

The thing about Autistics is that their brains can be very different to
Allistic people.

I am not saying that is bad, only different.

Parts of their brain can be more developed at the expense of other parts of
the brain.
That can mean that they have to use other parts of their brain to
compensate for the underdeveloped parts.

For example there is a woman on YouTube that processes language by thinking
in pictures.
Which can mean that she has difficulty remembering exactly what was said or
written.

If she heard the sentence “He took his dog for a walk”, she might picture
the Gorton's Fisherman taking a beagle for a walk.
So then if you asked her to repeat the sentence she might say something
almost completely different.

Anyway the problem is that Raku was designed by a linguist. So if you have
difficulties with linguistic content you might be very confused.
Again, according to Todd, he has difficulty with the linguistic content of
the written word.

I think that for me both the language and visual centers are overly
expressed and highly connected so Raku is very easy for me.
I often don't have to read the descriptions of the functions at all. Just
the names and function signature is enough for me to figure it out.

So something like his keepers would be completely pointless for me.
Todd however needs those keepers to compensate for how his brain works
differently.

Again, I am not saying that is bad, only different.

---

Now with all of that said, it is little wonder why Todd has difficulties
with the function descriptions where others don't.

I also think that if we just replaced what we have for something that works
for Todd it might make it more difficult for others.
Again because his brain is more unique than most.

What we could do is try to include things from both groups.

We want to be an inclusive community after all.
There is a reason our mascot was designed to be appealing to youngsters.

On Thu, Aug 27, 2020 at 6:59 PM Daniel Long Sockwell <
dan...@codesections.com> wrote:

>
> Hi Todd,
>
> Thanks for your detailed reply; it really helped me to understand your
> perspective on all this.  I have a few responses to particular points
> you raise
>
> > My perspective on Raku's docs are that they are meant
> > as a refresher for those that already know what they
> > are doing.
>
> My perspective is _very_ different.  I first started programming Raku
> less than two months ago.  In that time, I've learned almost entirely
> from the official docs (supplemented by some of the wonderful Advent
> blog posts, the occasional Stack Overflow question, and some truly kind
> people answering questions on IRC – but I didn't buy any books and, like
> you, have had the official docs open nearly contentiously as I
> programmed Raku).  Throughout that learning process, I found the docs
> helpful and informative. Even when I wasn't all that familiar with Raku,
> I could follow the docs -- I didn't grasp *everything* when I was just
> getting started, of course, but I learned enough to keep going.  And, as
> I did, I was able to dive into some of the more obscure corners of the
> docs and learn a tremendous amount.
>
> >[They seem to have the attitude that]
> >"If you don't understand the Docs, it is because
> >you don't know what you are doing."
>
> I 100% agree with you that "if you don't understand the docs, it's
> because you don't know what you are doing" isn't a good approach to
> take.  All I can say is that I _never_ got the sense that anyone
> involved in Raku's docs had that attitude, and I found the docs
> refreshingly easy to understand -- even when I was brand new to Raku.
> >
> > Lets go to operator classification:
> > https://docs.raku.org/languag/operators#Operator_classification
> >
> > "Operators are just subroutines with funny names. The
> > funny names are composed of the category name (infix,
> > prefix, postfix, circumfix, postcircumfix), followed
> > by a colon, and a list of the operator name or names
> > (two components in the case of circumfix and
> > postcircumfix). A expanded explanation of all these
> > operators and what they mean is included in this table:
> > https://docs.raku.org/language/operators#Operator_classification;
> >
> > Okay, "funny names" means they are "esoteric"
> > https://www.wordnik.com/words/esoteric
> >
> > adjective: Intended for or understood by only a small
> > group, especially one with specialized knowledge
>
> A few thoughts on this example.  First, it appears to be from an older
> version of the documentation: the current
> docs.raku.org/language/operators 

Re: Raku User's Survey 2020 out now....

[Tom Browder]

On Thu, Aug 27, 2020 at 20:41 ToddAndMargo via perl6-users
 wrote:
> On 2020-08-27 16:53, Daniel Long Sockwell wrote:
> >> Very few of the other [methods are documented] this way.

Todd, I have one more suggestion: Why don't you put your "keepers" on Github?

Several advantages:

1. easy to change

2. easy to find

3. more eyes on it

4. PRs from interested parties to fix typos or maybe even errors

5. used Markdown format and can easily convert to pdf

6. maybe inspire you to publish your own Raku book

-Tom

perl6-us...@perl.org, sanfrancisco...@pm.org

[Joseph Brenner]

Deep into that darkness peering, long I stood there, wondering,
fearing, doubting, dreaming dreams of the Raku Study Group.

https://us02web.zoom.us/j/88495193366?pwd=TXpMSlVqaVVGMm52SWlvSmRrZXFBUT09

Password: 4RakuRoll

Note: we're still using that earlier start time: 1pm in California.
This makes things a little easier for people in Europe (that start
time is 10pm in Berlin).

RSVPs are helpful (though not required):

https://www.meetup.com/San-Francisco-Perl/events/272865558/