Re: Marketing / PR / Branding

[Polgár Márton]

There is a thematic page on Github for a while called Discussions. In 
the case of the Raku/problem-solving repository, it's second next to 
Issues, and next to Pull requests. The direct link to this particular 
discussion is https://github.com/Raku/problem-solving/discussions/395.


On 2023. 10. 31. 14:46, Tom Browder wrote:
On Tue, Oct 31, 2023 at 08:41 Fernando Santagata 
 wrote:


Hi Richard,

Where is the Raku/Problem-solvers discussion about PR?


Ditto

Re: What does `:_` and/or `:_:` signify?

[Polgár Márton]

The code tried to do the same with `dd` as with `say`. There are two 
differences:


 * `dd`, as a kind of debug tool, doesn't assign any special meaning to
   named arguments so it's more than willing to give a Pair back with a
   colon syntax representation even if was understood as a named argument.
 * there is no `dd` method. I think nowhere in the core but at least
   not in the interface of a Pair.

By the way, I don't think the underscore has any special significance in 
these examples. It would be all the same with `:foobar`, `dd :foobar`, 
`dd foobar`, `dd :foobar:`


Hope this helps ^^

On 2023. 09. 26. 23:02, William Michels wrote:

Hi Marton, Thanks for the reply.

Below last example (in the REPL), does `dd` not work on Pairs?
Or is this Indirect Object Notation at work?


[3] > :_
_ => True
[4] > dd :_
:_
Nil
[5] > dd _
===SORRY!=== Error while compiling:
Undeclared name:
    _ used at line 1

[5] > dd :_:
No such method 'dd' for invocant of type 'Pair'
  in block  at  line 1




On Sep 24, 2023, at 23:40, Polgár Márton 
 wrote:


Hi Bill,

:_ is a Pair with the colon syntax that stands for "_" => True. In 
the first case, it got passed as a named argument and say ignored it. 
The second case was a method call using the colon syntax - the syntax 
lizmat challenged not so long ago. 
https://github.com/Raku/problem-solving/issues/384 so, ultimately, it 
was (:_).say, a normal say method call on a Pair.


Cheers



A(z) Galaxy eszközömről küldve



 Eredeti üzenet 
Feladó: William Michels 
Dátum: 2023. 09. 25. 7:15 (GMT+01:00)
Címzett: perl6-users 
Tárgy: What does `:_` and/or `:_:` signify?

Hello,

While playing around in an attempt to define new operators, I 
stumbled upon some curious results.


In the REPL, trying `say :_` returns a blank line.

In the REPL, trying `say :_:` returns `_ => True`.

What is the meaning of this?

admin@mbp ~ % raku
Welcome to Rakudo™ v2023.05.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2023.05.

To exit type 'exit' or '^D'
[0] > say _
===SORRY!=== Error while compiling:
Undeclared name:
    _ used at line 1

[0] > say :_

[0] > say :_:
_ => True
[0] >

RE: What does `:_` and/or `:_:` signify?

[Polgár Márton]

Hi Bill,

:_ is a Pair with the colon syntax that stands for "_" => True. In the first 
case, it got passed as a named argument and say ignored it. The second case was 
a method call using the colon syntax - the syntax lizmat challenged not so long 
ago.  https://github.com/Raku/problem-solving/issues/384 so, ultimately, it was 
(:_).say, a normal say method call on a Pair.

Cheers



A(z) Galaxy eszközömről küldve



 Eredeti üzenet 
Feladó: William Michels 
Dátum: 2023. 09. 25. 7:15 (GMT+01:00)
Címzett: perl6-users 
Tárgy: What does `:_` and/or `:_:` signify?

Hello,

While playing around in an attempt to define new operators, I stumbled upon 
some curious results.

In the REPL, trying `say :_` returns a blank line.

In the REPL, trying `say :_:` returns `_ => True`.

What is the meaning of this?

admin@mbp ~ % raku
Welcome to Rakudo™ v2023.05.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2023.05.

To exit type 'exit' or '^D'
[0] > say _
===SORRY!=== Error while compiling:
Undeclared name:
_ used at line 1

[0] > say :_

[0] > say :_:
_ => True
[0] >

Raku Conference date about to be announced

[Polgár Márton]

Hi,

for those of you not paying close attention to Reddit or the Telegram 
group of the Raku Conference - Andrew Shitov has already proposed a date 
for the conference this year: 
https://www.reddit.com/r/rakulang/comments/15y82fq/the_raku_conference_2023_date/


Feel free to share your thoughts about it, especially with him. :) It 
seems the announcement is really close, please be patient.


Martin Burger as your local postman

Re: Help with %?RESOURCES variable

[Polgár Márton]

I mean, yes... the program runs at runtime. Anything available to the 
program is "available during runtime". Yes, you can look up the content 
at runtime - e.g from the place where it's installed. It is NOT advised 
to try and change the content that you can look up with %?RESOURCES - 
you aren't even supposed to know where it is; but as static data, you 
can always access it during runtime.


Regardless, what Brad Gilbert says seems to be consistent with what I 
can recall from a couple of months ago: it is only set in *modules* of a 
distribution. It can be set even if the module isn't precompiled but 
either way - it's not set in a mere raku script, even if it is located 
under the root folder of a distribution.


On 2023. 04. 19. 21:54, yary wrote:

https://docs.raku.org/language/variables says

|%?RESOURCES|is a compile-time variable available to the code of
aDistribution <https://docs.raku.org/type/Distribution.html>.

It contains a hash that provides compile and runtime access to
files associated with the Distribution of the current compilation
unit.


 The intent of that reads as - the value is set during compilation, 
and is available during runtime. Seems like either the doc is wrong, 
or the implementation is incomplete. I'm hoping that the doc is right, 
because it's useful to be able to read %?RESOURCES during runtime, and 
in general useful to set a variable once during compile, then read it 
forever at runtime.


-y


On Wed, Apr 19, 2023 at 3:00 PM Brad Gilbert  wrote:

Unless things have changed since I was last active, only modules
are precompiled. `?` Twigilled variables are set at compile time.
So if it had any values, they wouldn't be useful, because they
would be created anew every time.

On Mon, Apr 17, 2023, 11:48 AM David Santiago 
wrote:


Hi Polgár

A seg, 17-04-2023 às 18:08 +0200, Polgár Márton escreveu:
> I think this is the classic case of ?-twigilled, "compile-time"
> variables only being available in modules. It kind of forces
you to
> always have the pattern of: heavy-lifting in a module inside
lib, and
> the script just uses the module.
>



yes, that was the case. It works inside a module. I guess i
have to
think differently on how to organize the code.

Thanks and best regards,
David Santiago

Re: Help with %?RESOURCES variable

[Polgár Márton]

I think this is the classic case of ?-twigilled, "compile-time" 
variables only being available in modules. It kind of forces you to 
always have the pattern of: heavy-lifting in a module inside lib, and 
the script just uses the module.


On 2023. 04. 17. 18:01, David Santiago wrote:

I'm trying to use the variable %?RESOURCES without success. It doesn't
work even when i install it locally with zef

I have the following:

demanuel@archlinux test> cat resources/text.txt
This is my test file
demanuel@archlinux test> cat bin/run-me
sub MAIN(){
 say %?RESOURCES{"text.txt"}.slurp(:close);
}
demanuel@archlinux test> cat META6.json
{
   "raku" : "6.d",
   "name" : "Test",
   "api"  : "1",
   "auth" : "demanuel",
   "version" : "0.0.1",
   "description" : "my resources test",
   "authors" : [ "demanuel" ],
   "license" : "GPLv3",
   "resources": [
 "text.txt"
   ]
}
demanuel@archlinux test> tree
.
├── bin
│   └── run-me
├── lib
├── META6.json
└── resources
 └── text.txt

4 directories, 3 files
demanuel@archlinux test> raku -I ./lib bin/run-me
Nil
demanuel@archlinux test> zef install .
===> Testing: Test:ver<0.0.1>:auth:api<1>
===> Testing [OK] for Test:ver<0.0.1>:auth:api<1>
===> Installing: Test:ver<0.0.1>:auth:api<1>

1 bin/ script [run-me] installed to:
/home/demanuel/.raku/bin
demanuel@archlinux test> run-me
Nil
demanuel@archlinux test>




Can someone point me what i'm doing wrong?

Best regards,
David Santiago

Re: Undefine mixed data

[Polgár Márton]

If you made actual evidential arguments why it's good that Nil gets fed 
into @variables on assignment, or why is it good that @variables are, 
yes, both defined and DEFINITE when only declared, why this 
inconsistency, or counterpointing design,with $variables, is a good 
thing, we could discuss that.


However, you didn't, so now I'm left with personal impressions. You seem 
like the kind of user that Perl 6 should have never created: a user who 
is desperately willing to fix themselves when the language is shaking. I 
think replicating this mentality, i.e teaching people that they just 
have to learn harder, every single time they have a sensible and 
consistent complaint about the language, is much more dangerous than 
planting the thought that, as promised, Perl 6 made new mistakes, as 
opposed to the old Perl 5 mistakes. I think it's only fair that if I 
demonstrate a problem, building upon the experience of others, and point 
out a direction in which it could be improved, then that's legitimate 
impact. Really, let people think that there is a big broad problem in 
Raku's design - which is not a unique thing among programming languages 
really; part of the reason there is so many of them! - , and give them 
ways to cope, and hope for improvements. For the people, that's 
healthier than recognizing the problem nevertheless, but finding out 
that it's denied.


You probably know that Nil is far from being two decades old, or the 
Great List Refactor. These are things that took place before the first 
official release but they were also much bigger changes than the one we 
are talking about. It *is *possible to change the language, and it is 
sometimes desirable as well.


For defined and DEFINITE - I think you are correct and I don't know 
myself how to properly explain it. Horribile dictu: I think this part of 
the language is overwhelmingly complicated, way beyond usefulness. But I 
don't think it's downright contradictory. Another example would be Empty 
which is clearly DEFINITE, yet not defined.


Anyway, it doesn't help us with the @variables that start from being 
both DEFINITE and defined while $variables start from being not DEFINITE 
and clearly not defined.

Re: Undefine mixed data

[Polgár Márton]

Grr, sorry for the spam. After all this trying, the last part still 
couldn't be delivered. So here is the whole message instead: 
https://gist.github.com/2colours/53b3c3108b0a44fa559eeed0370c26bf.

Re: Undefine mixed data

[Polgár Márton]

it does no good, ever, that you get to store a Nil value ... in an array

Why do you think the `is default(Nil)` idiom for storing `Nil`s in `Scalar`s
is OK except when the `Scalar`s are inside an array?

I grant that, as jnthn put it in an SO discussing this:


While there is the `is default(Nil)` trick, I'd strongly suggest using some
other value as your sentinel. Trying to use a language feature in a
situation where you don't want the primary behavior it exists to provide
will generally not go smoothly.

So, it is not something most Rakoons are likely to ever want. But that's
the rule that proves the exception -- on rare occasions *some* Rakoons
*do* want to store a `Nil` in an array because it's not a sentinel but a
`Nil` representing a `Nil`.


I still remember very well the discussion where among several people, 
Larry Wall pointed out 
 
that Nil is designed to /not /act like a usual value. Yes, you can bind 
to it - I suppose if you want it to show up in an array so much, you 
/could /bind it there, /even though it's a bad idea among the people who 
know the most about the intents and design of Raku/ -, furthermore, you 
can set it as a default for a container - but the latter could be as 
much taken as a skeleton falling out of the cupboard, or, if you don't 
like this visuals, enough rope to shoot yourself in the foot.


Also, since Arrays don't actually contain all the containers of the 
universe when they are created - rather just know a way to "animate" new 
containers - I can imagine that setting `is default(Nil)` may even cause 
discrepancy somewhere else.



For obvious reasons I'm not going to look for examples of this use in
`Array`s to share them in this thread.


On the other hand, let me show you examples where the lackiness of 
@variables causes inconvenience, that, in my opinion, would test the 
patience (and sense of reality) of any newcomer to the language. (To be 
continued.)

Re: Undefine mixed data

[Polgár Márton]

(Since this mail couldn't be delivered at first, I'll try to 
aggressively split it this time...)


Dear Ralph,

I'm sorry that you get frustrated but this is still for all intents and 
purposes a technical discussion so I don't think it does any good to be 
vocal about it. There are good points and bad points, arguments and 
counter-arguments. I can also get upset when I feel indifference or 
dishonesty in a response that's meant to be an argument but I think a 
thread like this should read like valuable technical content to an 
"outsider".



you cannot reasonably indicate for an array that it doesn't have
valid content, as opposed to being empty by chance

If you mean indicate it's undefined, then here's one way:
```
my @array;
say @array.elems;  # 0
say @array.so; # False
say @array.defined;# True

say @array := Array:U; # (Array:U)
say @array.so; # False
say @array.defined;# False
```
If you mean something else, please be specific.
First, it's both inconsistent and inconvenient to have to explicitly 
bind the variable. Second, once you bound it to the undefined (and 
indefinite) value, you cannot store elements into it by assignment 
anymore (there is no auto-vivification either) - so at the end of the 
day, this is a very similar solution to giving up on @variables 
altogether, except here you give up on assignment altogether. However, 
if you want to modify a part of a composite data structure via a 
container (say, a value you retrieved using .values or some sort of 
mapping), binding won't help you; you just spoil your own reference to 
the data you wanted to alter. Again, something that works well for 
Scalars but nothing else.

Re: Undefine mixed data

[Polgár Márton]

For what it's worth, I think most of these behaviors that sometimes even 
contradict each other (like the "freshly undefined" array being both 
.defined and .DEFINITE) are just design mistakes from a different time. 
It was never "the right thing" that you cannot reasonably indicate for 
an array that it doesn't have valid content, as opposed to being empty 
by chance - this is a reason to /avoid /@variables, if anything. 
Similarly, it does no good, ever, that you get to store a Nil value (is 
it even a "value" from high-level perspective? Perhaps not) in an array 
on an assignment, and afterwards the array won't even be empty and lives 
on as something that genuinely holds data.


What differs, though, is the cost of changes. To introduce the concept 
of definedness/definiteness for @variables now, that would both be a 
serious challenge from implementation point of view, and a severely 
breaking change; no matter how we feel about it (I think it /would be 
/the right thing). On the other hand, assignment of Nil is barely 
defensible exactly because of its uselessness. I'm willing to bet my 
life that nobody ever seriously used `@foo = Nil` to mean "yeah, I want 
a one-element array with exactly one Nil value in it". Also, since the 
already highly distinguished nature of Nil, I'm absolutely certain that 
it wouldn't take a lot to make `@foo = Nil` reset the array (or whatever 
Positional container we provide in addition; can't think of anything else).


I realize that 6.e is kind of a packed project so I wouldn't insist on 
quickly messing things up to test this out but since we were talking 
about a "scheduled bug" anyway, I think that could be a "scheduled fix". 
Of course this is all just my opinion and this feels like something 
reasonably simple to achieve; simple enough that I can take up on it 
when the time comes. Objections are welcome, except the kind that refers 
to the breaking nature and legacy reasons.


On 2023. 03. 18. 19:06, Ralph Mellor wrote:

On Fri, Mar 17, 2023 at 11:11 PM rir  wrote:

Deprecating 'undefine' is just making something easy more difficult.

I see a problem with `undefine`:

```
my @bar;
say @bar.defined, @bar.DEFINITE; # TrueTrue
undefine @bar;
say @bar.defined, @bar.DEFINITE; # TrueTrue
```

I think a warning about this is the wrong solution.

I think deprecation is the right solution.



That said, I'm a bit surprised that the deprecation message isn't something like

Please use `foobar` instead

(where `foobar` does exactly the same thing as `undefine`, just using
a different name).



Maybe no one has yet thought of a name that isn't also fraught?

Maybe there is no reasonable name?

Maybe it's only Perl folk who would want `undefine`?

Maybe it's only Perl folk who will see the deprecation message and be unhappy?

Maybe, on balance, it's reasonable to consider it an opportunity to remind Perl
folk that a fresh uninitialized array or hash is NOT undefined?

Dunno. Just keeping an open mind.

Onward...



I searched Rakudo's sources for "undefine".

No useful match?!? Looks like GH search goes from bad to worse. Sigh.



`say &undefine.file` got me `SETTING::src/core.d/operators.pm6`:
https://github.com/rakudo/rakudo/blob/591157170d29f8a45ef316bb0d065e8437059112/src/core.d/operators.pm6#L1-L9:

Git blame led to this commit:
https://github.com/rakudo/rakudo/commit/72bac6708002f992952ca93e617435482824b95f

The commit message mentions "6.d-prep".

A google for that led to:
https://github.com/Raku/6.d-prep

Results of a GH search included
https://github.com/Raku/6.d-prep/search?q=undefine&type=issues

I ask that no one here comments on the discussions therein unless
they are *very* careful to avoid using inflammatory language.



Next I decided to search IRC. That led to this by Larry:


I think we should s/undefine/clear/, because clarity

(https://irclogs.raku.org/perl6/2015-07-02.html#17:19-0001



Liz suggested it was perhaps redundant.

(A similar argument appeared in the 6d prep issues.)

Larry didn't reply. Warnock's dilemma applies though I don't think
Larry ever missed anything. I think he always went with his gut; if
he felt he'd be repeating himself he said nothing.



And so we arrive at 2023 and the same issue arises as ever.

Can we be kind to each other even if we don't agree, even if we
are upset about some decision?



love, ralph

Re: Undefine mixed data

[Polgár Márton]

On 2023. 03. 14. 4:42, rir wrote:

 undefine seen at:
   , line 1
 Will be removed with release v6.e!
 Please use another way: assign a Nil; for Arrays/Hashes, assign Empty or 
() instead.

Will that deprecation require a conditional and two assignments
for mixed data?

[$a, @a, $b, %c, $c, &d].map: { .&undefine};

[$a, @a, $b, %c, $c, &d].map(
 { $_ = $_ ~~ (Associative,Positional).any ?? Empty !! Nil });


And even those ways don't seem too convincing... after all, it's more a 
question of containerization if assigning Nil will cut it or not. I 
didn't know about undefine but it appeared to me as an issue that you 
can just assign Nil to an Array and get something that is not the 
default value - moreover, it doesn't even evaluate to boolean False!


It seemed like something that can wait and that could cause a lot of 
friction as a breaking change but I think it would make overwhelmingly 
more sense to make Nil always set the default. It is a special value of 
a special singularity type on its own; it's questionable whether it 
should ever appear as an assigned element of a composite container but 
to make it STORE in a special, resetting way, seems kind of a 
no-brainer, apart from the "breakage"...

Re: Upcoming documentation meetings

[Polgár Márton]

Hey, you thought right! We were just doing a little testing (or at least 
offered to do) so that functionality concerns can be checked.


By the way, I brought up the example of the Rakudo classes were Jitsi 
kind of failed us and the second occasion was moved to Zoom. It could be 
that something similar happens to us but I suppose we will have to see 
that for ourselves.


On 2023. 02. 06. 10:49, Richard Hainsworth wrote:

I thought it was for 2nd Saturday, which is the 11-th

On 04/02/2023 23:13, Ralph Mellor wrote:

That's super short notice but if you mean EST, so 5pm UK time,
it would work for me.

On Fri, Feb 3, 2023 at 7:07 PM Will Coleda  wrote:

I can do a test tomorrow at noon if there's interest.

On Fri, Feb 3, 2023 at 10:27 AM Parrot Raiser <1parr...@gmail.com> 
wrote:

I think I had problems finding the audio options on Jitsi, and wasted
a couple of meetings doing so. I'd suggest a "test" setup meeting,
where the whole agenda is ensuring that everyone has all the settings
right. Maybe set up a static video shot with background music to give
feedback?

On 2/2/23, Elizabeth Mattijsen  wrote:
On 2 Feb 2023, at 21:11, Ralph Mellor  
wrote:

My internet is flakey when humidity is around 80%+ and the weather
forecast suggests it may be but with luck I'll be "there" 5pm UK 
time

(noon EST, 9am US west coast time) Saturday Feb 11.

If you switch off your camera, you will reduce the needed bandwidth
significantly.  But I guess I don't need to tell you that :-)


Liz

Upcoming documentation meetings

[Polgár Márton]

Hi,

since the broader topic of Raku documentation came up on a SF Raku Study 
Group meeting - and there have been various important news since - it 
seems fitting to announce the planned schedule for the next couple of 
documentation meetups, as it became publicly available at 
https://github.com/Raku/doc/wiki.


Since there is a public Jitsi link, I don't think this would get 
cancelled because of personal problems. This is my "unofficial opinion" 
but I think whether the proposed dates (*noon Eastern time, second 
Saturday of February, March an April respectively*) can be followed is 
only a matter of reaching the "critical mass" of interest now. There is 
plenty of time to plan for it.


Hopefully we can get some insights about the then-condition of 
infrastructure updates in particular - anyway, I'm not worried that we 
won't have anything to talk about if we gather for such a meeting. :)


See you there, and make sure to follow the updates of the wiki and the 
#raku-doc IRC channel on libera (logs available here 
)


Martin Burger