Re: A question on AND
And then nobody mentions that `and` has low priority. Try `say 42 & 13` and
`say 42 and 13`.
Best regards,
Vadim Belman
> On Jun 30, 2023, at 9:45 AM, yary wrote:
>
> Most of Richard's parting suggestions I understand & agree with, but not
> this: " why are you using '&&' and not 'and' "
>
> My habit (from Perl 5 days) is to use && || for expressions, and reserve
> "and" "or" for "do this if assignment/function call without parens
> succeeds/fails" – is there a refinement on that distinction in Raku which I
> should pay attention to?
>
> -y
>
>
> On Fri, Jun 30, 2023 at 5:40 AM Richard Hainsworth <mailto:rnhainswo...@gmail.com>> wrote:
>> I tried this and it worked without any problem.
>>
>> Here's the whole program:
>>
>> use v6.d;
>> say @*ARGS.raku;
>> if @*ARGS.elems > 0 && "@*ARGS[0]".lc eq "debug" {
>> say 'got'
>> }
>> and at the terminal:
>>
>> $ raku todd-test.raku debug --debug=50
>> ["debug", "--debug=50"]
>> got
>>
>>
>> FWIW
>> why are you quoting ARGS? The .lc coerces to string anyway.
>> why are you using && and not 'and'
>> why are you not using a sub MAIN with an optional --debug
>> eg. sub MAIN( @args, Bool :$debug=False) {
>> #stuff
>> if $debug { ... }
>>
>>
>>
>> On 30/06/2023 06:06, ToddAndMargo via perl6-users wrote:
>>> if @*ARGS.elems > 0 && "@*ARGS[0]".lc eq "debug" {...}
Re: Rust community in distress
There is a fork, already. At least, this is what he says in the video. There is a catch though, and it is mentioned in the video too. A few catches, actually. First, such conflict-based forks cause harm to project reputation. Second, it confuses potential supporters and this could reduce project funding. Third, developers would get separated between projects. Depending on how many would leave the original product, the pace of development of both could be slowed down by a factor of 2 or even more. Best regards, Vadim Belman > On Jun 9, 2023, at 2:40 AM, İsmail Arılık wrote: > > This is the open source world! So if there is a problem between the > management of Rust and the community, a fork would come and be popular soon. > Leaving Rust shouldn't be an option I think since it is really a good > language. > > On Fri, Jun 9, 2023, 07:04 Darren Duncan <mailto:dar...@darrenduncan.net>> wrote: >> And here Rust seemed to be massively gaining in popularity, and was just >> supported officially for Linux kernel driver support etc. -- Darren Duncan >> >> On 2023-06-08 11:17 a.m., Parrot Raiser wrote: >> > See https://youtu.be/QEnuzwCWpgQ <https://youtu.be/QEnuzwCWpgQ> >> > >> > This is not meant to be an example of schadenfreude. Rust is an >> > interesting >> > language, whose ecological niche has little in common with Perl's or >> > Raku's. Its >> > principal rival is Go, which is definitely more corporate. Alphabet >> > already >> > controls far too much. (Yes, that sentiment may not be compatible with a >> > gmail >> > account.) >> > It is unfortunate when any worthwhile Open Source project suffers from >> > community >> > or personality conflicts. It's worth noting them, to help us avoid similar >> > situations. >>
Re: Undefine mixed data
I'm unable to follow the whole thread in depth, but the point I'd like to make
is directly related to the initial example. My question would be: what exactly
do we undefine? I mean, all the discussion about definedness and truthiness is
undoubtedly great, and I mean no pun here. Special thanks Ralph for clarifying
some stuff which I never spoke out explicitly to myself. Yet, the matter of
containerization seems to be left aside to no purpose.
First of all, what would [1,@a].map(-> \v { v.VAR.^name }) produce? Double
Scalar.
Second, what sense `1.` makes? None. For sure, it fails.
1 and 2 together, what happens when we `[1, @a].map: *.`? We use the
scalar int the 0th array element, then we use... Array? But @a is scalarised
too, according to .VAR result! As a matter of fact, what we have is:
my $a0 = 1; my $a1 = @a; ($a0, $a1).map: *.
In a consistent case one with knowledge of containers would rather expect it to
be `$a0 = Nil; $a1 = Nil;` Therefore, the original array of `[1, @a]` should
end up being `[$(Any), $(Any)]`.
One can say that Scalar container transparency is very much a matter of
convention. In this case what sense does `undefine` makes on an Array? As a
container, it cannot be undefined as such. And how term 'undefine' turns into
'emptify' remains kind of mystery. :)
Another aspect of conventions about transparency is that why are we transparent
depending on the containerized value? For example, `for` doesn't care, it
either sees an item, or it sees an iterable – period. And, suddenly, there is
an exception! Because, otherwise, my initial example should've thrown on `1`
the same way, as in `1.`. But it doesn't and this break the principle
of equality in the face of law.
One way or another, I don't an alternative to the deprecation. I also agree to
the question (I think it was Ralph who expressed it) of what do we expect from
the routine? Falsification, undefining, or ...? Say, we introduce method
`reset`. It would drop all containers to their defaults. But what about
non-containerized values? What about containerization of array elements? Say,
for the non-containers the method may do nothing as this is their default
value. But array elements?
The case would be more clear if we replace array with a list: `(1, @a, $b)` In
this case the containerization is preserved and the behavior is unambiguous. It
also points at the array case and makes the situation more towards element
container having priority over it's value. After all, we always can `@a[1] :=
[1,2]` and end up with array being the item's container.
But at this point let's sit back for a moment and think of this: you see a
problem in my reasoning about how hypothetical `reset` method could act then it
means others may lean either towards my view, or yours and this segregation of
views makes method's existence rather problematic. Unless some kind of voting
would display overwhelming majority of one party. ;)
Just to conclude, I'm not trying to prove something. Just sharing thoughts.
Best regards,
Vadim Belman
> On Mar 13, 2023, at 11:42 PM, 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, ].map: { .};
>
> [$a, @a, $b, %c, $c, ].map(
>{ $_ = $_ ~~ (Associative,Positional).any ?? Empty !! Nil });
>
Re: $/ not always set after a regex match?
There are little known operators `andthen`, `orelse`, `notandthen` (I always
forget about the latter one too). What you are looking for would be:
given $s { m/ $=\w+ / andthen ..say }
Or, if you want a named variable:
given ("aaa") { (my $m = m/$=\w+/) andthen $m..say }
Best regards,
Vadim Belman
> On Jan 2, 2023, at 5:07 PM, yary wrote:
>
> I like statement modifiers, though not so much using side-effect variables
> set by a postfix modifier, I'd like to see the side effect before seeing the
> variable it sets. Something like
>
> / .+ / && put "The root of $_ is $/.";
>
> though the discussion is about not setting $/ in the caller's context and I'm
> not sure how to rewrite it with the matching operation first and passing the
> match result to a named variable and also skipping if no match, all in a
> single statement.
>
> -y
>
>
> On Sat, Dec 31, 2022 at 8:10 PM William Michels via perl6-users
> mailto:perl6-users@perl.org>> wrote:
>> RESENDING: The code examples below should read `` in all cases,
>> not ``, although either works (erroneously?).
>>
>> ---
>>
>> Interested in answering the question:
>>
>> WHICH CODE EXAMPLE IS THE PRETTIEST?
>>
>> Vote for your favorite (or post your own):
>>
>> [#] > #REPL (line numbers altered to differentiate)
>> Nil
>> [0] > $_ = 'gracefully'
>> gracefully
>> [1a] > put "The root of $_ is $/." if / .+ /;
>> The root of gracefully is graceful.
>> [1b] > put "The root of $_ is $<>." if / .+ /;
>> The root of gracefully is graceful.
>> [1c] > print "The root of $_ is " andthen put $/ ~ '.' if / .+
>> /;
>> The root of gracefully is graceful.
>> [1d] > print "The root of $_ is " andthen put $<> ~ '.' if / .+
>> /;
>> The root of gracefully is graceful.
>> [1] >
>> [2a] > put "Or is the root of $_ $/?" if / .+ /;
>> Or is the root of gracefully grace?
>> [2b] > put "Or is the root of $_ $<>?" if / .+ /;
>> Or is the root of gracefully grace?
>> [2c] > print "Or is the root of $_ " andthen put $/ ~ '?' if / .+ > full> /;
>> Or is the root of gracefully grace?
>> [2d] > print "Or is the root of $_ " andthen put $<> ~ '?' if / .+ > full> /;
>> Or is the root of gracefully grace?
>> [#] >
>>
Re: $/ not always set after a regex match?
A side effect is a side effect, it's something we cannot generally predict and must not rely upon. Besides, that effect is caused by a regex which is a separate entity on its own. The primary point is that your sequence objects gets `.sink` method invoked on it because the object itself is, roughly saying, unused. Best regards, Vadim Belman > On Dec 30, 2022, at 4:44 PM, Sean McAfee wrote: > > On Fri, Dec 30, 2022 at 4:12 PM The Sidhekin <mailto:sidhe...@gmail.com>> wrote: >> On Fri, Dec 30, 2022 at 8:51 PM Vadim Belman > <mailto:vr...@lflat.org>> wrote: >>> It is not "untrue". The sequence you produced goes nowhere. Thus the sink >>> context. >> >> "Sink context" is true. >> >> "Useless use" is debatable, at least. > > It's not useless because there's a side effect: setting $/. >
Re: $/ not always set after a regex match?
It is not "untrue". The sequence you produced goes nowhere. Thus the sink
context.
Best regards,
Vadim Belman
> On Dec 30, 2022, at 11:08 AM, Sean McAfee wrote:
>
> Ah, got it, thanks.
>
> It's mildly vexing, but the kind of side-effecty coding I described isn't a
> great idea in general. I only stumbled across the phenomenon while code
> golfing.
>
> As a side note, code like this:
>
> sub f { 1 ... * ~~ /9/; $/ }
>
> ...produces an untrue warning "Useless use of ... in sink context". Not sure
> if it's worth filing a bug report...
>
> On Wed, Dec 28, 2022 at 12:49 PM Elizabeth Mattijsen <mailto:l...@dijkmat.nl>> wrote:
>> That's because it at one time was decided that smart-match would set $/ in
>> the caller's scope. Which is a pain for implementation and optimizations.
>> I would be very much in favour of getting rid of that "feature", fwiw.
>>
>> > On 28 Dec 2022, at 18:45, Sean McAfee > > <mailto:eef...@gmail.com>> wrote:
>> >
>> > But if a sequence has its own $/, why does * ~~ /9/ set $/?
>> >
>> > Actually it's not just sequences, as a little more experimentation showed:
>> >
>> > [0] > first /9/, ^Inf
>> > 9
>> > [1] > $/
>> > Nil
>> > [2] > grep /9/, ^10
>> > (9)
>> > [3] > $/
>> > Nil
>> >
>> > The * ~~ "trick" sets $/ in these cases too.
>> >
>> >
>> > On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen > > <mailto:l...@dijkmat.nl>> wrote:
>> > This isn't specific to the REPL:
>> >
>> > $ raku -e 'say 1 ... /9/; say $/'
>> > (1 2 3 4 5 6 7 8 9)
>> > Nil
>> >
>> > I can only assume that the sequence has its own scope for $/, and thus
>> > isn't visible outside of it.
>> >
>> >
>> > Liz
>> >
>> > > On 28 Dec 2022, at 16:47, Sean McAfee > > > <mailto:eef...@gmail.com>> wrote:
>> > >
>> > > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a
>> > > Regex, the $/ variable seems not to be set:
>> > >
>> > > [0] > 1 ... /9/
>> > > (1 2 3 4 5 6 7 8 9)
>> > > [1] > $/
>> > > Nil
>> > >
>> > > If I match more explicitly using a WhateverCode, it works:
>> > >
>> > > [2] > 1 ... * ~~ /9/
>> > > (1 2 3 4 5 6 7 8 9)
>> > > [3] > $/
>> > > ｢9｣
>> > >
>> > > Is this the intended behavior, or a bug?
>> > >
>> >
>>
Re: $/ not always set after a regex match?
I guessed this answer. :) It makes it extra typing and some linenoise. So, I
wouldn't be really happy about it.
Use of `with` would be less cumbersome, actually. So `with $s ~~ /.../ {
. }`. Or `$s ~~ /.../ andthen .`. The "extra typing issue" is not
gone in this case, but the code clarity doesn't suffer.
Best regards,
Vadim Belman
> On Dec 30, 2022, at 5:22 AM, Elizabeth Mattijsen wrote:
>
> if $s ~~ /$=[\w+]/ -> $/ { say $ }
>
>> On 30 Dec 2022, at 03:54, Vadim Belman wrote:
>>
>> Optimizations, yes... But then, how could we not use code like `if $s ~~
>> /$=[\w+]/ { say $ }`?
>>
>> Speaking of the subject itself, I don't remember how sequences are actually
>> implemented in details, but most likely the regex is processed inside the
>> sequence iterator which owns the $/ used by the regex eventually.
>>
>> Best regards,
>> Vadim Belman
>>
>>> On Dec 28, 2022, at 12:49 PM, Elizabeth Mattijsen wrote:
>>>
>>> That's because it at one time was decided that smart-match would set $/ in
>>> the caller's scope. Which is a pain for implementation and optimizations.
>>> I would be very much in favour of getting rid of that "feature", fwiw.
>>>
>>>> On 28 Dec 2022, at 18:45, Sean McAfee wrote:
>>>>
>>>> But if a sequence has its own $/, why does * ~~ /9/ set $/?
>>>>
>>>> Actually it's not just sequences, as a little more experimentation showed:
>>>>
>>>> [0] > first /9/, ^Inf
>>>> 9
>>>> [1] > $/
>>>> Nil
>>>> [2] > grep /9/, ^10
>>>> (9)
>>>> [3] > $/
>>>> Nil
>>>>
>>>> The * ~~ "trick" sets $/ in these cases too.
>>>>
>>>>
>>>> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen
>>>> wrote:
>>>> This isn't specific to the REPL:
>>>>
>>>> $ raku -e 'say 1 ... /9/; say $/'
>>>> (1 2 3 4 5 6 7 8 9)
>>>> Nil
>>>>
>>>> I can only assume that the sequence has its own scope for $/, and thus
>>>> isn't visible outside of it.
>>>>
>>>>
>>>> Liz
>>>>
>>>>> On 28 Dec 2022, at 16:47, Sean McAfee wrote:
>>>>>
>>>>> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex,
>>>>> the $/ variable seems not to be set:
>>>>>
>>>>> [0] > 1 ... /9/
>>>>> (1 2 3 4 5 6 7 8 9)
>>>>> [1] > $/
>>>>> Nil
>>>>>
>>>>> If I match more explicitly using a WhateverCode, it works:
>>>>>
>>>>> [2] > 1 ... * ~~ /9/
>>>>> (1 2 3 4 5 6 7 8 9)
>>>>> [3] > $/
>>>>> ｢9｣
>>>>>
>>>>> Is this the intended behavior, or a bug?
>>>>>
>>>>
>>>
>>
>
Re: $/ not always set after a regex match?
Optimizations, yes... But then, how could we not use code like `if $s ~~
/$=[\w+]/ { say $ }`?
Speaking of the subject itself, I don't remember how sequences are actually
implemented in details, but most likely the regex is processed inside the
sequence iterator which owns the $/ used by the regex eventually.
Best regards,
Vadim Belman
> On Dec 28, 2022, at 12:49 PM, Elizabeth Mattijsen wrote:
>
> That's because it at one time was decided that smart-match would set $/ in
> the caller's scope. Which is a pain for implementation and optimizations. I
> would be very much in favour of getting rid of that "feature", fwiw.
>
>> On 28 Dec 2022, at 18:45, Sean McAfee wrote:
>>
>> But if a sequence has its own $/, why does * ~~ /9/ set $/?
>>
>> Actually it's not just sequences, as a little more experimentation showed:
>>
>> [0] > first /9/, ^Inf
>> 9
>> [1] > $/
>> Nil
>> [2] > grep /9/, ^10
>> (9)
>> [3] > $/
>> Nil
>>
>> The * ~~ "trick" sets $/ in these cases too.
>>
>>
>> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen wrote:
>> This isn't specific to the REPL:
>>
>> $ raku -e 'say 1 ... /9/; say $/'
>> (1 2 3 4 5 6 7 8 9)
>> Nil
>>
>> I can only assume that the sequence has its own scope for $/, and thus isn't
>> visible outside of it.
>>
>>
>> Liz
>>
>>> On 28 Dec 2022, at 16:47, Sean McAfee wrote:
>>>
>>> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex,
>>> the $/ variable seems not to be set:
>>>
>>> [0] > 1 ... /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [1] > $/
>>> Nil
>>>
>>> If I match more explicitly using a WhateverCode, it works:
>>>
>>> [2] > 1 ... * ~~ /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [3] > $/
>>> ｢9｣
>>>
>>> Is this the intended behavior, or a bug?
>>>
>>
>
Rakudo CoreDev Class, session 2
Dear rakoons, Since I have a Zoom meeting allocated for the class, the previously announced schedule for the second session remains the same: Jan 7, 2022. A bit more details can be found in a reddit post here: https://www.reddit.com/r/rakulang/comments/zxsmvy/rakudo_coredev_class_session_2 Google Calendar entry: https://calendar.google.com/calendar/event?action=TEMPLATE=MGdpYWNpZGNmdHMxZHYzNnA5bGJhdG5qc2IgMGZiMWQ4NTVlOWI2MTA3ZTlmZWM2OWE5ZTg4YjVhYjYxY2IwZmJmNGUxZTI0OTE3MDg2MjE1Yzc5NjkyMWNkYkBn=0fb1d855e9b6107e9fec69a9e88b5ab61cb0fbf4e1e24917086215c796921cdb%40group.calendar.google.com And just the Zoom meeting information follows: Link: https://us02web.zoom.us/j/86809566554?pwd=THFWSzRrMzRRbE5aUm9wcWFuTUhaQT09 <https://www.google.com/url?q=https://us02web.zoom.us/j/86809566554?pwd%3DTHFWSzRrMzRRbE5aUm9wcWFuTUhaQT09=D=calendar=2=AOvVaw2dFRaQG177YP-DaKPfw2a1> Meeting ID: 868 0956 6554 Passcode: 540167 Happy coming New Year! Best regards, Vadim Belman
Rakudo CoreDev Class
Since no other proposals were made I plan to hold the class on Saturday, Dec 3, 20:00UTC. Here is the link to Google Calendar entry with Jitsy Meet reference: https://calendar.google.com/calendar/event?action=TEMPLATE=MGdpYWNpZGNmdHMxZHYzNnA5bGJhdG5qc2IgdnJ1cmcwMUBt=vrurg01%40gmail.com Comments are welcome on: - Reddit: https://www.reddit.com/r/rakulang/comments/z4qsnh/rakudo_coredev_class_announcement/ - Facebook: https://www.facebook.com/groups/raku.perl6/permalink/3371142626485406/ Best regards, Vadim Belman
Re: Problem defining factorial operator in .rakumod file
I like the way you use ~ in `use lib '~/...';`. Though it doesn't work as expected. But it's nice! :D Best regards, Vadim Belman > On Oct 14, 2022, at 4:05 PM, Joseph Polanik wrote: > > On 10/14/22 3:38 PM, Elizabeth Mattijsen wrote: >>> On 14 Oct 2022, at 21:15, Joseph Polanik >>> <mailto:jpola...@charter.net> wrote: >>> Actually, I did create a factorial() sub, but that didn't get me out of my >>> present predicament. It works as expected when invoked from the command >>> line. However, when invoked from a test script (or the REPL) the error >>> message is "Undeclared routine". >> Could you please run that case with: >> >> $ raku --ll-exception -Idir-with-module test-script >> >> and post the output? > $ raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku > Undeclared routine: > factorial used at line 23 > >at SETTING::src/core.c/Exception.pm6:64 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw) > > from gen/moar/Grammar.nqp:4517 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:cry_sorrows) > > from gen/moar/Grammar.nqp:838 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit) > > from gen/moar/Grammar.nqp:553 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:TOP) > > from gen/moar/stage2/QRegex.nqp:2267 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/QRegex.moarvm:parse) > from gen/moar/stage2/NQPHLL.nqp:2301 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:parse) > from gen/moar/stage2/NQPHLL.nqp:2217 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:execute_stage) > > from gen/moar/stage2/NQPHLL.nqp:2252 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:run) > from gen/moar/stage2/NQPHLL.nqp:2248 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:) > from gen/moar/stage2/NQPHLL.nqp:2244 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:compile) > from gen/moar/stage2/NQPHLL.nqp:1919 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:eval) > from gen/moar/stage2/NQPHLL.nqp:2154 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:evalfiles) > > from gen/moar/stage2/NQPHLL.nqp:2114 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval) > > from gen/moar/Compiler.nqp:105 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval) > > from gen/moar/stage2/NQPHLL.nqp:2039 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_line) > > from gen/moar/rakudo.nqp:140 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:MAIN) > > from gen/moar/rakudo.nqp:1 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) > > from :1 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) > > from :1 > (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) > > > The script Run/run_SequenceHelper.raku contains only the following lines > > use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib'; > use SequenceHelper :ALL; > say factorial(5); > > Thanks for looking into this. > > Joe > >
Re: Inconsistencies with "with" chained to "for"
Looks like it worth a bug report. I was probably stumbling upon this too for a couple of times. Best regards, Vadim Belman > On Aug 27, 2022, at 2:24 AM, Fernando Santagata > wrote: > > Hello, > I noticed this behavior: > > [0] > my @a = > [a b c d e] > [1] > .say with $_ for @a > () > [2] > .say if .defined for @a > a > b > c > d > e > [3] > (.say with $_) for @a > a > b > c > d > e > [4] > (.say if .defined) for @a > a > b > c > d > e > > Apparently in this case "with" works only as a statement modifier while "if" > works both ways. > Is this a known behavior with well understood reasons, or should I open an > issue? > > -- > Fernando Santagata
Re: Using fez
Hi, Liz has probably missed the point of your question. Yes, you must do fez upload for each new release. It means each time you'd need to do some pre-release preparations to create an archive, etc... The fastest way is to switch to App::Mi6 for building distributions. My approach is a makefile plus helper scripts I include as a submodule for nearly each project I develop because mi6 doesn't cover my needs. Best regards, Vadim Belman > On Jul 10, 2022, at 11:38 AM, Richard Hainsworth > wrote: > > I have begun uploading modules to fez. > > Suppose a module is in active development. And I have v0.7.1, then v0.7.2 > etc. Do I need to upload each version, or will fez automatically provide the > most updated module? > > When p6c was the main ecosystem, the reference was to github. So, the latest > version on github was used, and zef would use whatever was on github. > >
Re: Is this zef or me: Inconsistent Ecosystem response
How long ago v3.7.5 has been uploaded to p6c? Is p6c enabled in zef
configuration?
And it would be much better and more reliable to migrate to zef/fez ecosystem
already. :)
Best regards,
Vadim Belman
> On Jun 29, 2022, at 8:49 AM, Richard Hainsworth
> wrote:
>
> Hi,
>
> zef appears to be giving inconsistent results.
>
> I have updated several of my modules. But when I try the github actions to
> test an update a module that depends on one updated, it does not recognise
> the most recent module, only a version I changed some time ago.
>
> I have a module called Raku::Pod::Render the latest version is v3.7.5
>
> When I use `zef info "Raku::Pod::Render" ` on my local machine, I get
>
> zef info "Raku::Pod::Render"
> ===> Updating fez mirror: http://360.zef.pm/ <http://360.zef.pm/>
> ===> Updated fez mirror: http://360.zef.pm/ <http://360.zef.pm/>
> ===> Updating p6c mirror:
> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json
> <https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json>
> ===> Updating cpan mirror:
> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json
> <https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json>
> ===> Updated p6c mirror:
> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json
> <https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json>
> ===> Updated cpan mirror:
> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json
> <https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json>
> - Info for: Raku::Pod::Render
> - Identity: Raku::Pod::Render:ver<3.7.5>:auth
> - Recommended By: Zef::Repository::Ecosystems
> - Installed: Yes
> Description: A generic Pod6 Renderer with custom Pod::Blocks, FormatCodes
> for one or more files using templates, provides HTML and MarkDown.
> License: Artistic-2.0
> Source-url: git://github.com/finanalyst/raku-pod-render.git
> Provides: 12 modules
> Support:
> # bugtracker:https://github.com/finanalyst/raku-pod-render/issues
> <https://github.com/finanalyst/raku-pod-render/issues>
> # source:https://github.com/finanalyst/raku-pod-render.git
> <https://github.com/finanalyst/raku-pod-render.git>
> # email:richard@hainsworth.wales <mailto:richard@hainsworth.wales>
> Depends: 14 items
> I have another module called Raku-Pod-Extraction, which "depends on"
> Raku::Pod::Render:v<3.7.5+>
>
> My github workflow file is
>
> name: "Raku"
> on: [ push, pull_request ]
> jobs:
> raku:
> strategy:
> matrix:
> os:
> - ubuntu-latest
> raku-version:
> - 'latest'
> runs-on: ${{ matrix.os }}
> steps:
> - name: Checkout
> uses: actions/checkout@v2
> - uses: Raku/setup-raku@v1
> with:
> raku-version: ${{ matrix.raku-version }}
> - name: Check zef info
> run: zef info "Raku::Pod::Render"
> - name: Install Dependencies
> run: zef install --/test --test-depends --deps-only .
> - name: Install App::Prove6
> run: zef install --/test App::Prove6
> - name: Run Tests
> run: prove6 -I. t
>
> As you can see, I run the zef info line for Raku::Pod::Render. I am getting
> the following response (this happens after I used exactly the same command
> locally)
>
> Run zef info "Raku::Pod::Render"
> ===> Updating fez mirror: https://360.zef.pm/ <https://360.zef.pm/>
> - Info for: Raku::Pod::Render
> - Identity: Raku::Pod::Render:ver<3.7.3>:auth
> - Recommended By: Zef::Repository::Ecosystems
> - Installed: No
> ===> Updated fez mirror: https://360.zef.pm/ <https://360.zef.pm/>
> Description: A generic Pod6 Renderer with custom Pod::Blocks, FormatCodes
> for one or more files using templates, provides HTML and MarkDown.
> ===> Updating rea mirror:
> https://raw.githubusercontent.com/Raku/REA/main/META.json
> <https://raw.githubusercontent.com/Raku/REA/main/META.json>
> License: Artistic-2.0
> ===> Updated rea mirror:
> https://raw.githubusercontent.com/Raku/REA/main/META.json
> <https://raw.githubusercontent.com/Raku/REA/main/META.json>
> Source-url:
> https://raw.githubusercontent.com/raku/REA/main/archive/R/Raku%3A%3APod%3A%3ARender/Raku%3A%3APod%3A%3ARender%3Aver%3C3.7.3%3E%3Aauth%3Cgithub%3Afinanalyst%3E.tar.gz
>
> <https://raw.githubusercontent.com/raku/REA/main/archive/R/Raku%3A%3APod%3A%3ARender/Raku%3A%3APod%3A%3AR
Re: author specification
I'd put it this way: this API has not been stabilized yet. Though at the moment it's coming to some consensus. Currently the only ecosystem with authentication is zef. In order to publish there fez would ask your password once in a while. This is also why all other ecosystems are considered deprecated. Best regards, Vadim Belman > On May 3, 2022, at 11:59 AM, Marcel Timmerman wrote: > > Hi Brad, > >> Auth is for more than just the author. It is for author, authority, and >> authentication. > There is no password or other cryptographic way, so authentication is not > possible. Obviously, I might miss some insight here. > > In the documentation I read; ":auth generally takes the form hosting:ID, as > in github:github-user or gitlab:gitlab-user". For me, hosting is e.g. on > GitHub or Gitlab to store the software, and ecosystems are for spreading the > word, i.e. telling that there is a software available somewhere, and this > somewhere is not important. That is the work for zef to find out. > > And the word 'generally' means that it is just an example, it is in the end > just a string. > Furthermore, there is no mention in the docs of any use other than naming it > in a useful way. No remarks of needing it to login into some ecosystem and no > word about that separator, being a column, or split it up in more than two > fields using an other character. > > Searching through some distributions I find 'zef:lizmat', 'github:MARTIMM', > 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, ccworld1...@gmail.com > <mailto:ccworld1...@gmail.com>, 2291108...@qq.com > <mailto:2291108...@qq.com>', showing that there is absolutely no clear way to > use that field. For me, it means again that the auth field must be completely > free and the same, independent of the ecosystem in use. > >> CPAN can't authenticate github or fez modules, and vice versa. There is a >> reason the field is only the first four letters. > The word 'github' is longer. > >> That they are seen as different modules is an intended feature, not a bug. > I didn't want to say that it was a bug, sorry for the confusion. > >> I would like to know how you would want the system to handle a module from >> me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well. >> (CPAN doesn't allow numbers, otherwise I would have it there to.) > Do you want to write several meta files with different auth fields depending > on the ecosystem you want to send it to? The only thing you can do without > much work is sending a project e.g. to fez and another to cpan but I don't > see the use of spreading your projects over several ecosystems. > > Also for a class you wrote, JSON::Class, what should I write (I took it to > the extreme of course, 'use JSON::Class' would do) > > use JSON::Class:auth; > use JSON::Class:auth; > use JSON::Class:auth; > > All three are getting the same software, or not, when it is someone els-es > auth. > >> What if someone else took a user name on github that matched one on CPAN or >> fez? > That is the point I want to make. Keeping the auth field the same everywhere, > independent of ecosystem, will show that the software is the same everywhere. > If that someone has the same account name as someone else on cpan or fez it > will show a difference in the auth field. > > So, I think there is a lot to ponder over > Regards, > Marcel > >> >> On Mon, May 2, 2022, 3:23 PM Marcel Timmerman > <mailto:mt1...@gmail.com>> wrote: >> Hi, >> >> I was wondering about the 'auth' specification in the meta file or on the >> class/module/package. I was used to specify it as 'github:MARTIMM' because I >> store the stuff on GitHub for all the goodies it offers. Now I see that fez >> wants to start with 'fez:' and when I look at the raku.land site for a >> module of mine I see a remark 'The uploading author of cpan:MARTIMM does not >> match the META author of github:MARTIMM.' because I upload it to CPAN >> nowadays and have never specified somewhere that the auth has become >> 'cpan:MARTIMM'. >> >> I feel that this is not useful (even correct) to pin someone to use an auth >> specification with a defined prefix for some ecosystem one is using. So >> changing to another ecosystem forces that person to change the auth >> everywhere in its code and meta files to get rid of any errors or warnings. >> Besides that, the change of the author on the same code poses the question >> later on, if that code is forked and changed by someone else or that it is >> still the same developer working on it? >> >> Regards, >> Marcel >> >
Re: continuous testing
As long as I'm trying to follow topics, related to continuous testing with github actions, I always see ubuntu-based scenarios. What about macOS and Windows? Do we have rakudo images for these? Best regards, Vadim Belman > On Jan 1, 2022, at 5:14 AM, JJ Merelo wrote: > > Try the new GitHub actions with the recently renovated Docker image. See it > in action, for instance, here: > > https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml > <https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml> > El vie, 31 dic 2021 a las 19:57, Richard Hainsworth ( <mailto:rnhainswo...@gmail.com>>) escribió: > Thanks > > On 31/12/2021 18:27, Fernando Santagata wrote: >> Hi Richard, >> this is a link to the GitHub official documentation: >> >> https://docs.github.com/en/actions <https://docs.github.com/en/actions> >> >> You can also copy a configuration from another project and adapt it to your >> needs. For example this one installs some C libraries, some module >> dependencies and runs the tests: >> >> https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml >> >> <https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml> >> On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth > <mailto:rnhainswo...@gmail.com>> wrote: >> Fernando, >> >> Thanks. >> >> Any link / blog / article about how to set up GitHub action up for Raku? >> >> Regards, >> >> Richard >> >> On 31/12/2021 16:52, Fernando Santagata wrote: >>> Hi Richard, >>> apparently Travis CI has discontinued its free open source plan. >>> I switched to GitHub actions; don't know what's available on other >>> platforms. >>> >>> On Fri, Dec 31, 2021 at 5:43 PM Richard Hainsworth >> <mailto:rnhainswo...@gmail.com>> wrote: >>> I noticed that the .travis files have been removed from some distributions. >>> >>> Also a .circleci file exists in the Raku Docs repo. >>> >>> Is there a preferred / recommended / list of continuous testing >>> environments? >>> >>> Is there a preferred / rapid way to handle Raku modules? >>> >>> Regards, >>> >>> Richard >>> >>> >>> >>> -- >>> Fernando Santagata >> >> >> -- >> Fernando Santagata > > > -- > JJ
Re: file format extensions
rakudoc has been chosen as the official extension long ago. Best regards, Vadim Belman > On Dec 30, 2021, at 11:13 AM, Tom Browder wrote: > > On Thu, Dec 30, 2021 at 06:26 Elizabeth Mattijsen <mailto:l...@dijkmat.nl>> wrote: > +1 from me. Shouldn't that be a .rakudoc file ? :-) > > Or .rakupod?
Re: file format extensions
I also agree that a page on docs would be helpful. But my point for this reply is about renaming POD6. I don't think this makes much sense and barely would ever happen. It is a legacy name, like NQP. Best regards, Vadim Belman > On Dec 30, 2021, at 6:26 AM, Elizabeth Mattijsen wrote: > > +1 from me. Shouldn't that be a .rakudoc file ? :-) > >> On 30 Dec 2021, at 12:20, Richard Hainsworth wrote: >> >> I'm revising how I name files that are included in my modules. With the name >> change to Raku, the file extensions also changed for script and module files. >> >> In addition Jonathan has defined some format extensions for Cro files, and I >> am sure there would be other developers who would like to claim unique >> extension names for files. >> >> This is not a post intended to start a war about file extensions, that is >> whether they should exist in a modern file system. For whatever reason they >> came into being, a significant number of users, such as myself, find them >> useful, if only as a mnemonic for their files' probable contents. >> >> It seems to me a short page in the docs.raku.org would be useful with the >> various file extensions, and so if a developer wanted for a custom file >> extension to be primarily applied to some new module, the way to do would be >> to create a PR on the documentation file. >> >> If this post gets some positive responses, then I'll write the POD6 file for >> inclusion in docs.raku.org and create a PR for inclusion. >> >> [Another naming question would be the name of the markup language - as >> distinct from the file extension - for documentation. For Perl it is POD, >> for Perl6 it was natural to use POD6. POD stands for Plain Old >> Documentation, but I think that POD6 is neither Plain, nor Old. How about >> RDM for Raku documentation markup? ] >> >> There is a wrinkle in that Raku best practice has evolved in line with the >> evolution of perl6 into Raku. So it seems reasonable to have previous file >> formats listed as well. >> >> The following are what I think are the current best practices. Since I have >> been out of circulation for a while, the list is likely not exhaustive and >> may be wrong. I am certain there are other file types I have not included. >> >> For each file type, extensions on the left are earlier, and the extension of >> the far right (after the TAB) is considered best practice >> >> Perl6 / Raku script: .pl, .pl6, .raku >> >> Perl6 / Raku Module: .pm, .pm6, .rakumod >> >> Perl6 / Raku Standalone Documentation (POD6 can be included in a script or >> module file): .pm, .pm6, .pod, .pod6, .rakudoc >> >> NQP file: .nqp >> >> Cro template: .crotmp >> >> >> >> >> >> >
Re: hope we have the distributed computing [Raku]
There is no need to know about Raku development. It'd be enough to know Raku. Best regards, Vadim Belman > On Nov 27, 2021, at 7:59 PM, Piper H wrote: > > I would like to be. But I know nothing about the development of Raku itself, > so I most probably would be the product and test engineer for this project. > > Thanks. > > On Sun, Nov 28, 2021 at 8:53 AM Darren Duncan <mailto:dar...@darrenduncan.net>> wrote: > On 2021-11-27 12:16 a.m., Piper H wrote: > > but in [Raku] why won't we make that a > > distributed computing framework like Spark? Then it will help a lot to the > > data > > programmer who already knows perl. > > I expect a lot from this project. > > Piper, are you offering to lead your proposed project and be the primary > developer working on it? -- Darren Duncan
Re: Different behavior for strings and strings in variables with multi-dispatch using a subset
You overlooked a mistype. The subset expects "wuhn", you pass "whun" instead.
Guess, the subset is wrong about it. :)
Best regards,
Vadim Belman
> On Sep 22, 2021, at 8:39 PM, Joseph Brenner wrote:
>
> In this code I'm using multi-dispatch with a subset type that
> makes string values special: "wuhn", "tew" and "thuree".
>
>use Test;
>
>multi sub whats_my_type (Str $item) {
>return "This is a Str: $item";
>}
>
>subset GoofyNum of Str where { $_ eq any( 'wuhn', 'tew', 'thuree' ) };
>multi sub whats_my_type (GoofyNum $item) {
>return "This is a GoofyNum string: $item";
>}
>
>{
>my ($ret, $arg);
>$ret = whats_my_type('two');
>like $ret, /<< Str >>/, "quoted string argument of 'two' is Str";
>
>$ret = whats_my_type('tew');
>like $ret, /<< GoofyNum >>/, "quoted string argument of
> 'wuhn' is 'goofy'";
>
>$arg = "one";
>$ret = whats_my_type( $arg );
>like $ret, /<< Str >>/, "string in var argument of '$arg' is Str";
>
>$arg = "whun";
>$ret = whats_my_type( $arg );
>like $ret, /<< GoofyNum >>/, "string in var argument of 'wuhn'
> is 'goofy'";
>}
>
>
> I would think all four of these tests should pass, instead I see
> the last one failing: for some reason there's a difference in the
> case of a simple quoted string, and a string inside a variable.
>
> Any comments?
>
>
> raku --version
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
>
> uname -a
> Linux fandango 4.9.0-8-686 #1 SMP Debian 4.9.144-3 (2019-02-02) i686 GNU/Linux
>
Re: fixing the documentation
Hello Marc, The best would be if you propose a PR or open an issue at https://github.com/Raku/doc. Any help with the documentation would most certainly be appreciated as people working on the docs project are overloaded. Best regards, Vadim Belman > On Aug 25, 2021, at 8:09 AM, Marc Chantreux wrote: > > hello people, > > D526P: > https://docs.raku.org/language/5to6-nutshell#index-entry-PERL6LIB-PERL6LIB > DFIM : https://docs.raku.org/language/modules#Finding_installed_modules > DLIB : > https://docs.raku.org/programs/03-environment-variables#index-entry-RAKULIB > > This D526P is deprecated and some RAKULIB details are redundant with > both DFIM and DLIB. > > I would like to propose a patch so: > > * the details of RAKULIB comes in DLIB > * DFIM refers to DLIB > * D526P refers to DFIM > > But D526P asserts something i read nowhere else: > >Note that C is more of a developer convenience in Raku (as >opposed to the equivalent usage of C in Perl) and shouldn't be >used by module consumers as it could be removed in the future. This is >because Raku's module loading isn't directly compatible with operating >system paths. > > Is it still true? if so, should this paragraph be in DFIM? > > regards, > marc >
Re: (sigils are awesome, they say ...) Re: pairs of separators from a string
Sigils mean a lot. For example, they create a context:
my $a = 1,2,3;
my @a = 1,2,3;
$a = ; say $a.raku;
@a = ; say @a.raku;
If you have some (actually, a lot of) spare time you can watch my class from
TRC2021 where I cover a lot about symbols/sigils/object interaction in Raku:
https://conf.raku.org/talk/154 <https://conf.raku.org/talk/154>
https://conf.raku.org/talk/163 <https://conf.raku.org/talk/163>
Best regards,
Vadim Belman
> On Aug 22, 2021, at 8:57 AM, Marc Chantreux wrote:
>
> thanks everyone for sharing,
>
> Vadim,
>
> my ($a, $b) = { @^a[0,2...Inf], @a[1,3...Inf] }.(q<(){}[]>.comb); say $a[0];
> say $b[0]
>
> oh. i never see this direct call of a lambda before but it really makes
> sense! this is the answer i like the most.
>
> i rewrote it my way and this works
>
> my ($a, $b) = { .[0,2…∞], .[1,3…∞] }.(q.comb);
>
> it would be nice if this one will:
>
> my ($a, $b) = { .[0,2…∞], .[1,3…∞] }.: q.comb;
>
> But here is one of the reasons i'm still unconfortable with raku is the
> fact that sigils don't make sense anymore to me (in the contrary of perl
> were sigils means "i want a [$%@] from this").
>
> so as i can't get grid of sigils in this case
>
>my (\a, \b) = { .[0,2…∞], .[1,3…∞] }.(q.comb);
>
> i need to choose a sigil. The way i understand sigils is
> "an optional type specifier". to me
>
>my $truc => my container 'truc' for anything you want
>my @truc => my container 'truc' for something that should mostly
> be understood as indexed
>my %truc => my container 'truc' for something that should mostly
> be understood as associative
>
> so of course i tried
>
> my (@a, @b) = { .[0,2…∞], .[1,3…∞] }.(q.comb);
>
> because i have two lists and two containers. this doesn't work.
> which means @ and $ combines with = to define how things are stored
> but i don't understand how for the moment.
>
> regards,
> marc
>
Re: ^mro_unhidden
I have tried to explain the essential part of this in a comment to the related
issue. Regarding the traits, Elizabeth has mostly covered the subject. Coming
down to the `is hidden` trait, neither Any nor Mu are hidden:
say Any.^hidden; # 0
And, normally, no other class hides them:
say Int.^hides_parent(Any); # 0
Speaking about traits, `is hidden` makes a class hidden by setting
corresponding attribute on its metamodel object. Trait `hides` adds a parent to
the list of hidden parents on the child it is applied to. The second approach
is the way to have a class non-hidden by default but still exclude it from
method dispatch when necessary.
Best regards,
Vadim Belman
> On Aug 21, 2021, at 2:03 PM, Joseph Brenner wrote:
>
> Given and example like this:
>
> class A {}
> class B is A {}
> class D is B {}
>
> say D.^parents(); # ((B) (A))
> say D.^parents( :all ); # ((B) (A) (Any) (Mu))
>
> So, I conclude that Any and Mu are "hidden" as far as ^parents is concerned.
>
> According to the documentation, ^mro_unhidden does this:
>
> "Returns a list of types in method resolution order, excluding
> those that are marked with is hidden."
>
> And yet, what I see is:
>
> say D.^mro_unhidden; # ((D) (B) (A) (Any) (Mu))
>
> So why does this include Any/Mu?
>
> A somewhat related question: How do you check whether a trait is set
> on something?
> Can you get a list of all traits?
>
> raku --version
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
>
Re: pairs of separators from a string
I guess you need something like this:
my ($a, $b) = { @^a[0,2...Inf], @a[1,3...Inf] }.(q<(){}[]>.comb); say $a; say $b
Best regards,
Vadim Belman
> On Aug 21, 2021, at 3:04 AM, Marc Chantreux wrote:
>
> hello,
>
> i would like to get the list of opening (α) and closing
> (ω) separators from this string:
>
>&""''(){}[]
>
> too many years of perl made me think about this solution
> or something alike but it didn't work.
>
> my (\α,\ω) =| map
>{ .[0,2…∞], .[1,3…∞] },
>q&""''(){}[]&.comb;
>
> fixing this is important to me because it illustrate how bad i am to
> comprehend how raku flatten things.
>
> regards,
> marc
>
>
Re: Why does .new initialize?
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?
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: [naive] hash assingment
The discussion took an interesting route. :)
The problem with an array in a hash is the problem of hashes implicitly
itemizing values. Consider the example:
⇒ raku -e 'my %h = a => [1,2,3,4]; say %h.raku; say (%h ==> map({ sqrt $_
})); %h := [1,2,3,4]; say %h.raku; say (%h ==> map({ sqrt $_ }))'
$[1, 2, 3, 4]
(2)
[1, 2, 3, 4]
(1 1.4142135623730951 1.7320508075688772 2)
Sorry for one-liner. The point of the example is that binding to a key avoids
itemization of its RHS if it is a non-itemized object.
Because itemizing in fact means putting things into a Scalar container, then
the fastest thing which resolves the issue with ==> would be de-containerize a
value:
⇒ raku -e 'my %h = a => [1,2,3,4]; say %h.raku; say (%h ==> map({ sqrt $_
})); say (%h<> ==> map({ sqrt $_ }));'
$[1, 2, 3, 4]
(2)
(1 1.4142135623730951 1.7320508075688772 2)
<> here is the decontainerization operator. And it would be the fastest
solution because most others are coercers meaning that the most likely outcome
of .Slip, .List, pipe operator, etc. – would be creation of a new object. With
<> we just pull out the Array from the container with no modifications or
copying.
Note that I say nothing to justify the use of ==>. I simply don't use it.
Best regards,
Vadim Belman
> On Jul 14, 2021, at 8:13 PM, Brad Gilbert wrote:
>
> Honestly I would advise against using ==> at the moment.
>
> For one thing it doesn't even work like it is intended.
> Each side of it is supposed to act like a separate process.
>
> There are also issues with the syntax that are LTA.
> The fact that you have to tell it the left side is actually a list is one
> such issue.
>
> It isn't even all that clearer than just using a method call
>
> > %a .map({.sqrt});
>
> ---
>
> Using ｢.Slip｣ or ｢|｣ prefix works, but is the wrong thing.
> You need to tell it that it is a list, so use ｢.List｣ or ｢@(…)｣
>
> > @(%a) ==> map({.sqrt})
> > %a.List ==> map({.sqrt})
>
> Since a Slip is a type of List, using it works, but for the wrong reasons.
>
>
> On Wed, Jul 14, 2021 at 2:58 PM Aureliano Guedes <mailto:guedes.aureli...@gmail.com>> wrote:
> thank
>
> It is now more clear.
> And I like this notation |%a ==> map({.sqrt});
> less is more sometimes
>
>
>
> On Wed, Jul 14, 2021 at 4:41 PM Daniel Sockwell <mailto:dan...@codesections.com>> wrote:
> To expand slightly on what Clifton said, the reason that
>
> > %a = %a.map: { .sqrt };
> > # (1 1.4142135623730951 1.7320508075688772 2 2.23606797749979)
>
> does what you mean but
>
> > %a{'column1'} ==> map( { .sqrt } )
> > # (2.23606797749979)
>
> does not is that the method .map maps over *each item* in the Array, whereas
> ==> map maps over the Array as *one collection*. When taking the square root,
> an Array needs to be treated as an number, which for Raku means treating it
> as
> a count of how many elements it has (i.e., its length).
>
> So `%a{'column1'} ==> map({.sqrt})` is the same as
> `%a{'column1'}.elems.map({.sqrt})`
>
> If want to map over each item in the Array when using the ==> operator, you
> need to
> slip the items out of the Array before feeding them on. You can do that with
> either
> of the following (equivalent) lines:
>
> > %a{'column1'}.Slip ==> map({.sqrt});
> > |%a{'column1>'}==> map({.sqrt});
>
> (Also, you may already know this, but when the keys of your hash are strings,
> you
> can write %a instead of %a{'column1'} )
>
> Hope that helps!
>
> –codesections
>
>
> --
> Aureliano Guedes
> skype: aureliano.guedes
> contato: (11) 94292-6110
> whatsapp +5511942926110
Raku BOF session at TPRC2021
For the participants of TPRC2021: Raku BOF session is scheduled for Wednesday, Jun 9, 18:00UTC. Zoom link is on the Wiki page at https://github.com/perlconference/tprc-2021-cloud/wiki See you tomorrow! Best regards, Vadim Belman
Re: is there a raku job site?
I think it is totally fine to post here. You could also try posting in r/rakulang on reddit. Best regards, Vadim Belman > On Jun 2, 2021, at 4:19 AM, Theo van den Heuvel wrote: > > Hi gurus, > > I consider hiring a raku consultant, but there does not seem to exist a raku > job site. The perl job site seems to implicitly exclude raku jobs. > I asked but have not heard back. > > Any ideas? Could I post the call in this group? > > thanks, > Theo van den Heuvel >
Re: File::Find using a junction with exclude
As to " but what's that cabbage thing before $c?": we have this great
https://docs.raku.org site. And it has great search capability:
https://docs.raku.org/type/atomicint
https://docs.raku.org/language/unicode_ascii#index-entry-%E2%9A%9B
As to "this completely lost me": there was a mistype and "taking" shoud've been
"talking". Sorry for this.
"Weird/will Ass Thing" made me totally lost as I've no idea what this means.
Best regards,
Vadim Belman
> On May 24, 2021, at 10:11 AM, Andy Bach wrote:
>
> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
> say $c;
>
> I was sort of hanging on by my fingertips (this completely lost me:
> >Or, taking about tricks:
>
> ('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
>
> ) but what's that cabbage thing before $c? Oh, and WAT is" Weird/will Ass
> Thing"?
> From: Vadim Belman mailto:vr...@lflat.org>>
> Sent: Monday, May 24, 2021 8:53 AM
> To: perl6-users mailto:perl6-users@perl.org>>
> Subject: Re: File::Find using a junction with exclude
>
> CAUTION - EXTERNAL:
>
>
> Still ugly but much more reliable trick would be to use a sub and a counter
> variable:
>
> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
> say $c;
>
> Or, taking about tricks:
>
> ('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
>
> Apparently, this one is not ugly by semantics, but by its notation too. Also
> worth noting that the hyper-op is needed here because pointy blocks are not
> auto-threaded over junctions and take them as-is:
>
> -> $v { say $v.WHAT }(1|2); # (Junction)
>
> Best regards,
> Vadim Belman
>
> > On May 24, 2021, at 8:42 AM, Daniel Sockwell
> > wrote:
> >
> >> It can be done without the EVAL:
> >>
> >>> any('a', 'b', 'c').raku.substr(4, *-1).split(',').elems
> >>
> >> 3
> >
> > Yeah, but only at the cost of some fragility:
> >
> >> any('a', 'b,b', 'c').raku.substr(4, *-1).split(',').elems
> > 4
> >
> > I suppose you could do:
> >
> >> any('a', 'b,b', 'c').elems.raku.substr(4, *-1).split(',').elems
> > 3
> >
> > but I'm not sure that's _that_ much better than EVAL – either way, we're
> > depending on the Str
> > representation of inherently non-Str data, which seems like the main sin of
> > EVAL.
> >
> > – codesections
> >
>
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
Still ugly but much more reliable trick would be to use a sub and a counter
variable:
my atomicint $c = 0;
sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
say $c;
Or, taking about tricks:
('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
Apparently, this one is not ugly by semantics, but by its notation too. Also
worth noting that the hyper-op is needed here because pointy blocks are not
auto-threaded over junctions and take them as-is:
-> $v { say $v.WHAT }(1|2); # (Junction)
Best regards,
Vadim Belman
> On May 24, 2021, at 8:42 AM, Daniel Sockwell wrote:
>
>> It can be done without the EVAL:
>>
>>> any('a', 'b', 'c').raku.substr(4, *-1).split(',').elems
>>
>> 3
>
> Yeah, but only at the cost of some fragility:
>
>> any('a', 'b,b', 'c').raku.substr(4, *-1).split(',').elems
> 4
>
> I suppose you could do:
>
>> any('a', 'b,b', 'c').elems.raku.substr(4, *-1).split(',').elems
> 3
>
> but I'm not sure that's _that_ much better than EVAL – either way, we're
> depending on the Str
> representation of inherently non-Str data, which seems like the main sin of
> EVAL.
>
> – codesections
>
Re: File::Find using a junction with exclude
You're wrong in your expectations. Smartmatch as such is implemented by ACCEPTS method of its RHS. It is Junction.ACCEPTS in our case. Unfortunately, the method is not documented for Junction, but it considers itself a boolean context and, correspondingly, collapses the junction. Not it is true with eq which is a normal routine and Raku autothreads over it. It still works well in conditions because they're boolean context and collapse the resulting junction. Best regards, Vadim Belman > On May 23, 2021, at 4:14 PM, Joseph Brenner wrote: > > Junctions continue to surprise me: > >my $junction = any( 'a', 'b', 'c' ); >my $char = 'b'; >say $char ~~ $junction; # True >say $char eq $junction; # any(False, True, False) > >$char = 'e'; >say $char ~~ $junction; # False >say $char eq $junction; # any(False, False, False) > > I would've thought that there'd be no difference there > The smartmatch checks that it's comparing string types, > and does something like an eq on them, right? > So why would going straight to an eq be different? > > But then, there are other cases where junction-in, > junction-out is the only thing that makes sense: > >say $junction ~ 'z'; ># any(az, bz, cz) >
Re: File::Find using a junction with exclude
This: $junction>>.say; works the way it is because the junction is passed as an argument to the hyper operator where the normal rules apply. Try it this way: say $junction>>.say; and it will result in: a b c any((True), (True), (True)) Best regards, Vadim Belman > On May 23, 2021, at 4:12 PM, Joseph Brenner wrote: > > William Michels wrote: > >> my $exclude3 = ( rx/<|w>mothera$/, rx/<|w>camel$/ ); >> my @files3 = find( dir => $loc, type => 'file', exclude => $exclude3>>.any >> ); >> say "Exclude3: ", @files3; >> #Exclude3: ["/Users/me/test_folder/.DS_Store".IO >> "/Users/me/test_folder/godzilla".IO "/Users/me/test_folder/mothera".IO >> "/Users/me/test_folder/rhodan".IO] > > I wasn't really sure what bill was thinking there, because my > impression was that junctions, by design aren't supposed to be > treated as compound data structures, they're a *single* thing but > with multiple values that co-exist with each other in > "superposition". > > For example, you can't get a count of the number of elements in a junction: > >my $junction = any( 'a', 'b', 'c' ); >say $junction.elems; # any(1, 1, 1) > > But then, this actually works: > >$junction>>.say; ># a ># b ># c > > So going the other way, using a hyper operator to create a > junction isn't such a silly thing to look at... > > Though really then this idiom creates an array of multiple any > junctions with single values, which would behave just like the > individual values themselves: > >my $values = < A B C >; >my $junction2 = $values>>.any; >say $junction2; ># (any(A) any(B) any(C)) >
Re: File::Find using a junction with exclude
To my view, this behavior of File::Find is going against DWIM and is certainly
LTA. Anyway, what you you probably is looking for is something like
exclude => { $_ ~~ any(@exclude) }
BTW, the only thing File::Find needs to work with junctions is to declare
:$exclude as Mu. In this case the call to find will not be auto-threaded.
Best regards,
Vadim Belman
> On May 21, 2021, at 4:41 PM, Joseph Brenner wrote:
>
>> I just gave a few other variants a try-- passing a junction in a
> variable, passing a code block containing a function-- without any
> luck.
>
> Sorry, I mean a code block containing a *junction* or course.
>
> Like:
>
> my @exclude = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
> my $any_exclude = any(@exclude);
> my @files = find( dir => $loc, type => 'file', exclude => {
> $any_exclude } );
> say @files;
> # ["/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/mothera".IO
> "/home/doom/tmp/monster_island/rhodan".IO]
>
>
> On 5/21/21, Joseph Brenner wrote:
>> Thanks, yes the actual result is certainly consistent with the
>> junction applied at the top level, and not internally, which is what I
>> was expecting.
>>
>> Is there actually no way to pass a junction in to a function so that
>> it can be used later in an internal smartmach? That's been my rough
>> impression of what junctions are for, a way to have a compound value
>> that's treated as a single one until it's used.
>>
>> I just gave a few other variants a try-- passing a junction in a
>> variable, passing a code block containing a function-- without any
>> luck.
>>
>
Re: Accurate conversion of Num to Rat (and comparing Num and Rat)
For exact match one can use eqv: say 1/10 eqv 0.1e0; # False say 1/10*1e0 eqv 0.1e0; # True Best regards, Vadim Belman > On Apr 6, 2021, at 7:25 PM, Ralph Mellor wrote: > >> 1/10 == 1e1 # True >> >> Aiui this is correct (and to me intuitive) behaviour described here: > > Except A) that's not what the doc says, and B) how does one > compare numbers *without* infection, if that's what's going on? > > So it probably makes sense to ignore at least that part of my > previous email. Maybe the rest of it too. I shouldn't be writing > emails after midnight. Goodnight. > > -- > raiph >
Re: Please create a Raku community channel
Rakudo Weekly cannot serve as an offical channel. First of all, because it is "Rakudo" weekly, not "Raku". There is a good reason for this. Second, because it's weekly and I don't see why its format should be changed. We may need to have more prompt response in certain cases. Third, it's first and foremost is a personal project of Elizabeth, and I wish it remains this way because this is one of the things which makes it so interesting and valuable. Best regards, Vadim Belman > On Mar 14, 2021, at 7:30 AM, yary wrote: > > The Rakudo Weekly blog gives me a sense of what's going on in the Raku world, > when I remember to check it! https://rakudoweekly.blog/about-rakudo-weekly/ > <https://rakudoweekly.blog/about-rakudo-weekly/> > > That site isn't quite what's called for in therms of community discussion and > announcements, but is a decent "organic" overview of what's happening in Raku > lists & blog spaces. > > -y > > > On Sun, Mar 14, 2021 at 3:32 AM Darren Duncan <mailto:dar...@darrenduncan.net>> wrote: > On 2021-03-13 2:27 p.m., Vadim Belman wrote: > > Concerning the accidental duplication of projects, aside of the fact that > > it is dissipation of scarce community resources, the good side is that > > there will be two options to choose from. I will be happy to see both > > project launched. One could eventually become part of the official site, > > the other may be ran independently. One way or another I hope there will be > > more gains from it than loses. > > These projects could be merged if both authors are conducive to it, now that > this is known. > > If there is reason for them to stay separate, I don't see why they can't BOTH > be > official sites, like Version 1 plus Version A, no reason to have to pick one. > > -- Darren Duncan
Re: Please create a Raku community channel
The official one is what you get when go to docs.raku.org. I can hardly imagine an acceptable way to have both versions represented under the same domain. Best regards, Vadim Belman > On Mar 14, 2021, at 3:31 AM, Darren Duncan wrote: > > On 2021-03-13 2:27 p.m., Vadim Belman wrote: >> Concerning the accidental duplication of projects, aside of the fact that it >> is dissipation of scarce community resources, the good side is that there >> will be two options to choose from. I will be happy to see both project >> launched. One could eventually become part of the official site, the other >> may be ran independently. One way or another I hope there will be more gains >> from it than loses. > > These projects could be merged if both authors are conducive to it, now that > this is known. > > If there is reason for them to stay separate, I don't see why they can't BOTH > be official sites, like Version 1 plus Version A, no reason to have to pick > one. > > -- Darren Duncan >
Re: Please create a Raku community channel
My point about the resources were rather an answer to Richard's reaction, as I understood it. Otherwise, I share the view of "more project is better than no projects, even if they duplicate". :) The matter of community definition is a hard one, indeed. To my view we have two different purposes for defining it. First, it's when it comes to any kind of elections. Second, when it comes to distribution of information. Your focus on commit bits is rather related to to the first purpose, as I consider it. But if we think of the second one then wider meaning of community as "all devs using Raku and following its development" would be sufficient and will simplify the task of establishing a channel. Say, we choose to start an official blog (https://news.raku.org perhaps?). It would be under the control of Raku Steering Council. I.e., only RSC decides what is posted there. Technical and organizational implementation details are currently irrelevant. Not only the blog could inform about new releases, administrative actions, but anyone can send a request for posting something, they consider relevant and worthwhile mentioning officially. A new documentation project could be among such topics. Best regards, Vadim Belman > On Mar 14, 2021, at 3:25 AM, JJ Merelo wrote: > > I don't think it's a duplication (or, as might be the case, triplication) of > resources, or a waste of resources. I learned early on that the "resources" > of the community is not, as in a company, a pool with a constant value from > which you, as in yourself, can draw to push forward your favorite project. On > the contrary, it falls on you to try and steer anyone's favorite project in a > direction that could help *your* favorite project, and also to prop up your > project so that it's open to contributions in a way that don't break or > derail it. That's the best you can do. Also, a community with three or four > projects in the same direction (documentation or whatever) is a great > community; at the end of the day, you can profit from all three, even if it's > in a tiny detail or simply on the effort put into implementing a standard. > That said, the initial problem still stands: there's no way to make the whole > community know something that might be important, such as the doc site > dropping from some parts of the internet, or an adoption drive for some > community module, really, whatever. Voting for the RSC... And that's got > several sub-problems > 1. We need to define community. If it's someone with a commit bit in every > repo of the 5 (yes 5) Raku organizations, well, that's a tall order. There > are myriad teams, some people have a commit bit just in one repo. And then > this excludes people who contribute to the community in a different way, from > organizing challenges to curating subreddits through answering questions in > StackOverflow. > 2. Even if you include all and everyone, you need to define what would go > into that channel. As in a logging system, you need to define the severity of > the issue to make the channel really relevant and actionnable. That, of > course, goes against the fact that it needs to be open to everyone, and also > interactive. > 3. There's no single communication channel that's a) used by everyone and b) > accessed by everyone on a hourly, or even daily, basis. > > So there's really no solution to your problem, other than try and tell > everyone, many times, in different channels, whatever the heck you're > interested on, and it will eventually grab the attention of the stakeholders > (and don't have me defining stakeholders...). > > I really appreciate everyone's contributions, I really do. So heartfelt > thanks to all :-) > > Cheers > > JJ > > El sáb, 13 mar 2021 a las 23:27, Vadim Belman ( <mailto:vr...@lflat.org>>) escribió: > > I would like to make an important note here. Up to my knowledge, the new > documentation site project is personal initiative of Alexander (Altai-man) of > which nobody of RSC members was informed about. For this reason it is rather > unlikely that any notification would be issued on any official channel, would > such one existed. I personally got to know about it the moment Alexander > posted his request for help on IRC. > > Apparently, the above paragraph doesn't say that we don't need an official > channel of a kind. I was asking a similar question ~1.5yr ago. As it is with > many other matters, this one needed some time to gain momentum. Perhaps, the > time has come to get it answered. > > Concerning the accidental duplication of projects, aside of the fact that it > is dissipation of scarce community resources, the good side is that there > will be two options to choose from. I wi
Re: Objects, TWEAK and return
At the first glance it looks like bug. Possibly a result of over-optimization.
Worth opening an issue at https://github.com/rakudo/rakudo/issues
Best regards,
Vadim Belman
> On Mar 13, 2021, at 3:29 PM, mimosin...@gmail.com wrote:
>
> Hi,
>
> When working with this week challenge for the PerlWeeklyChallenge
> <https://perlweeklychallenge.org/>, I noticed this behaviour with TWEAK:
>
> This does not work:
> submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )
> });
> }
>
> This works:
> submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )
> });
> return;
> }
>
> It also works with other commands instead of 'return' (like assigning a value
> to a variable). From the examples in the documentation, I am not certain this
> is the expected behaviour.
>
> Thanks for this extraordinary language,
>
> Joan
>
>
> P.S: This is the context where the command appears. Apologies for the
> messy-Raku,
> --
> use Test;
>
> my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast date:
> 1937-07-23)"
> 1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
> 1723781,"Les Miserables Episode 3: The Trial (broadcast date: 1937-08-06)"
> 1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
> 1646043,"Les Miserables Episode 5: The Grave (broadcast date: 1937-08-20)"
> 1714640,"Les Miserables Episode 6: The Barricade (broadcast date: 1937-08-27)"
> 1714640,"Les Miserables Episode 7: Conclusion (broadcast date: 1937-09-03)"';
>
> class Movies {
>
> has $.starttime;
> has $.currenttime;
> has $.filelist;
> has @!show; # ( [ time, show ] )
>
> submethod TWEAK {
> # miliseconds -> seconds
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )
> });
> return;
> }
>
> method what-show() {
> my $position = ( $!currenttime - $!starttime ) % @!show[*;0].sum/1000;
> my ($time, $show);
> for @!show[*;0] -> $show-time {
> $time += $show-time;
> return @!show[$show++;1] if $time > $position;
> }
> }
> }
>
> my $mv = Movies.new(
> starttime => '1606134123',
> currenttime => '1614591276',
> filelist=> $data
> );
>
> is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast date:
> 1937-07-23)"';
Re: Please create a Raku community channel
I would like to make an important note here. Up to my knowledge, the new documentation site project is personal initiative of Alexander (Altai-man) of which nobody of RSC members was informed about. For this reason it is rather unlikely that any notification would be issued on any official channel, would such one existed. I personally got to know about it the moment Alexander posted his request for help on IRC. Apparently, the above paragraph doesn't say that we don't need an official channel of a kind. I was asking a similar question ~1.5yr ago. As it is with many other matters, this one needed some time to gain momentum. Perhaps, the time has come to get it answered. Concerning the accidental duplication of projects, aside of the fact that it is dissipation of scarce community resources, the good side is that there will be two options to choose from. I will be happy to see both project launched. One could eventually become part of the official site, the other may be ran independently. One way or another I hope there will be more gains from it than loses. Best regards, Vadim Belman > On Mar 13, 2021, at 2:21 AM, Richard Hainsworth > wrote: > > This is a request to the Raku Coordinating Council that was elected at the > end of last year. > > Please name a channel where community wide plans or announcements are made. > Or may be establish one. > > I found out yesterday by the intervention of a regular participant in the > community that a new documentation website is being worked on. > > I joined a conversation on the raku-dev IRC and discovered that the plans are > quite far established. Since I have been working full-time for three months > on a project that could (not should!!) serve as the infra-structure of a new > site, I was really quite surprised and I am sure many of you will understand > it was jarring. > > I follow all the conversations on this email list. I have found it very > difficult (due to my own technical incompetence relating to github) to set up > my github preferences to get regular notification about issues. I have also > found that the IRC chats are streams of consciousness that are difficult for > me to manage. > > It seems however, that it is my fault that I was taken by surprise by the > news of a different documentation website and that I should have been > following all the issues on the documentation repo or the problem solving > repo. > > It *IS* reasonable for Raku developers and community organisers to make it > the responsibility of a participant to follow conversations, but I would > suggest that the current scattering of conversations, on the IRC chat, > various github repositories, this email list, is not *optimal* for the > development of a coherent Raku community. It is also - I would suggest - a > waste of human resources if the same objectives are pursued by multiple > enthusiasts without any coordination or communication. > > If the Raku Council were to designate some channel, whether its an email > list, an IRC chat, or a github repo, or maybe a discord or slack or other > channel as the main community resource, then I would make sure I could read > all the messages there and stay in touch with what is happening. > > Hence my request to the Raku council to consider improving communication > between developers and the wider Raku community. > > Regards > > Richard Hainsworth > > aka finanalyst > >
Re: 'CALL-ME' Math problem?
Not in this case. The error happens at run-time. Syntactically the expression
is a valid one because `5(...)` is interpreted as an invocation. Raku
implements invocation protocol a part of which is method 'CALL-ME' defined on a
class:
class Foo {
method CALL-ME(|c) { say "Foo invoked with {c.raku}" }
}
Foo(42, :foo(13));
Foo.new().();
Note that the protocol works for both a type object and its instantiation. This
is what is basically happens in the case of `5(...)`: it falls back to `Int`
and tries to invoke `CALL-ME` on it. One could say that it makes no sense, but
an example with adding a fallback method has been already provided here. And
here is another one follows:
my $foo = 5 but role { method CALL-ME(|c) { say "Int with ", c.raku } };
$foo(13);
The currently produced error, unfortunately, is confusing for beginners. But as
soon as one gains more experience with Raku it makes clear sense instantly.
Best regards,
Vadim Belman
> On Mar 2, 2021, at 9:26 AM, Parrot Raiser <1parr...@gmail.com> wrote:
>
>> Doing so would, of course, be a very bad idea. But still, you _could_.
>
> Something of an understatement, I think. :-)*
>
> Seriously, this made me wonder if inscrutable error messages might be
> clarifed by a (reverse) trace of the last few steps in parsing. That
> would show you what the compiler thought ir was doing.
>
> Would that be a) reasonably practical to implement, and b)
> sufficiently useful to justify the effort?
>
Re: ^methods doesn't show all methods
It's not about gist truncating long lists. After all, when it does so it ends
the output with triple dot.
Yet nobody spotted that not every methods in the list are represented by their
names. Alongside with something like 'elems' there are many
'Method+{is-nodal}.new' entries. This is due to `is nodal` trait mixin a role
into a method object. Why this breaks Routine's gist method I'm not ready to
answer.
The correct output is produced when we explicitly ask for code object name,
i.e. when method .name is used one way or another. One can try this to see the
difference:
say Set.^methods.map: *.gist
say Set.^methods.map: *.name
Best regards,
Vadim Belman
> On Feb 16, 2021, at 3:38 PM, Gianni Ceccarelli wrote:
>
> On 2021-02-16 Joseph Brenner wrote:
>> But I don't see them in the list from .^methods:
>>
>> say $s.^methods;
>>
>> say so $s.^methods.gist.grep(/<>/); # False
>
> ``say`` calls ``.gist``, which produces a *truncated* string
> representation for long lists::
>
>$ raku -e 'say (^1000).List'
>(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
> 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
> 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
> 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ...)
>
> If you grep the list itself, instead of its gist::
>
>$ raku -e 'Set.^methods.map(*.name).grep(/keys/)>>.say'
>keys
>
> --
> Dakkar -
> GPG public key fingerprint = A071 E618 DD2C 5901 9574
>6FE2 40EA 9883 7519 3F88
> key id = 0x75193F88
>
Re: list assignment
Hi, I would like to give a perspective a bit different to what yary provided. Your example here can be golfed down to: my $a = [1,2,3]; my @v = $a; say @v; # [[1,2,3],] The reason for this behavior is $a being a scalar container. Correspondingly, when you assign it to @v the assignment op see a single element, not a positional. So, it behaves correspondingly. Apparently: my @v = [1,2,3]; say @v; Do what's expected. The reason is [1,2,3] on RHS is a positional. It's a non-containerized value. So, if we put one and one together we come to the following assignment: my @v = $a<>; say @v; # [1,2,3] Because by stripping of the container with <> operator we get a positional on RHS. Now, if we unroll it all back your case, the only thing we should remember is that arrays containerize any value assigned into them. I.e.: constant foo = 4; my @v; @v[0] = foo; say 4.VAR.^name; # Int say @v[0].VAR.^name; # Scalar Therefore, when you do @first = @both[0] – it is equivalent to @v = $a in the first example. We have a documentation section on this: https://docs.raku.org/language/list#Itemization Best regards, Vadim Belman > On Jan 19, 2021, at 1:18 PM, Brian Duggan wrote: > > Hi Folks, > > I ran into this situation today, which seems counterintuitive: > > my @one = 1,2,3; > my @two = 4,5,6; > my @both = @one,@two; > my @first = @both[0]; > say @one.raku; > say @first.raku; > > output: > > [1, 2, 3] > [[1, 2, 3],] > > I was expecting @first and @one to be the same. > I discovered that I could instead write either of these -- > > my (@first) = @both[0]; > my @first := @both[0]; > > or I could change the @both assignment to be > > my @both := @one, @two; > > ..but I wonder if there's an idiomatic approach -- or > way of thinking about this -- that makes this flow more > intuitive. > > thanks > Brian >
Re: A nextsame question
Hello,
By "never returns" it's not meant that nextsame redispatches to the next sub
and skips the current stack frame. It only means that no statements following
nextsame will be executed. It's the same semantics as with return. So, the best
way to consider nextsame would be to think of it as of 'return
next-candidate(...)'.
I would say that this is the semantics which cares about the caller. If you put
yourself in the shoes of your code user, imagine that you introspect the multi
in question with 'cando' which gives you the candidate returning a List. It'd
be very confusing to get an Int instead!
Aside of this, the practice of returning so different values for rather similar
arguments doesn't look good for me.
Best regards,
Vadim Belman
> On Jan 19, 2021, at 11:07 AM, Fernando Santagata
> wrote:
>
> Hello,
> I'm trying to understand how nextsame works.
>
> Apparently I started from the wrong assumptions: I thought that once the
> first matched sub in the chain called nextsame, the arguments were matched
> against the following subs regardless of the return value.
> It seems that while the return value is not taken in account during the match
> process, it is checked once the sub return its value and it generates an
> error if the two candidates in the chain have different return types.
>
> The documentation
> (https://docs.raku.org/language/functions#index-entry-dispatch_nextsame
> <https://docs.raku.org/language/functions#index-entry-dispatch_nextsame>)
> reads:
>
> nextsame calls the next matching candidate with the same arguments that were
> used for the current candidate and never returns.
>
> and doesn't mention the return value.
>
> proto test(Str $a, |) {*}
> multi test($a, Str $b --> List) {
> nextsame if $b ~~ /\d+/; # if the second string contains a number
> return $a, $b
> }
> multi test($a, Int() $b --> Int) { return $b } # coerces the second argument
> to Int
>
> say test('hello', 1); # output: 1
> say test('hello', 'goodbye'); # output: (hello goodbye)
> say test('hello', '1'); # error: Type check failed for return value;
> expected List but got Int (1)
>
> Here I expected that in the third call, after the first multi matched, the
> nextsame triggered a match on the second multi, regardless of the return
> value. Instead apparently the match is triggered, but then the return value
> of the first multi (List) is expected from the second multi (which returns an
> Int).
>
> I don't know if this is the desired behavior; if so probably it deserves to
> be documented.
>
> --
> Fernando Santagata
Re: LTA documentation page
And here it comes again, the common mess about Raku and Rakudo. :) The point is that Rakudo doesn't come bundled with documentation about Raku because the former just implements the latter. It's not like it is with perl where `perl` binary and `Perl` are the same and `perl -v` is your current version of Perl. From this point of view, one would have to know the difference between 6.d and 6.l version of Raku because these differences might be overwhelming. Even now it'd be good to know about the differences in role behavior between 6.c/6.d and 6.e. Contrary, one is better not care about the differences between Rakudo 2019.10 and 2020.12 for as long as they both implement same Raku versions. Apparently, I'm not talking about bug compatibility here. So, for as long as one's code always starts with `use v6.d` they really may not be worried about any upcoming Raku language version up until their compiler starts deprecation cycle for 6.d. The task of the online documentation is to allow one to find out what version of Raku introduced a requested feature. We'll most certainly need a section related to versioning and have it pinned at some easy to spot location. And it will be there when our resources allow which must be read as: when somebody find time to do it. Any help is welcome! :) Best regards, Vadim Belman > On Jan 5, 2021, at 9:48 AM, Gianni Ceccarelli wrote: > > On 2021-01-05 Brad Gilbert wrote: >> There really shouldn't be that much difference between what the >> documentation says and how your version works. > > I've worked on machines stuck with perl 5.8 when the online > documentation was for 5.26 > > I'd like to live in a world where: > > * raku is popular and widespread enough that you find old versions it > on old machines > * I won't have to struggle to remember the differences between 6.d and > 6.l > > For now, yes, the online docs are "good enough" (when I have network > connectivity, at least!) > >> Even if rakudoc did install, it would just copy the most recent docs >> as of the time you installed it. > > rakudoc != p6doc > > rakudoc looks at the POD6 in installed distributions / modules > > -- > Dakkar - > GPG public key fingerprint = A071 E618 DD2C 5901 9574 >6FE2 40EA 9883 7519 3F88 > key id = 0x75193F88 >
Re: concurrency of asynchronous events - input from multiple keyboards
As it seems that Audio::PortMIDI lacks non-blocking interface, I think a
solution would be to read events in a dedicated thread and re-submit them into
a Supplier. Something like:
my Supplier $midi-events;
start {
loop {
my $ev = $midi.read;
$midi-events.emit: $ev;
}
}
$midi-events can then be used in your react block. BTW, I think calling method
'poll' must not be needed because `read` should block until actual event is
available. At least this is how I understand the normal order of things.
Best regards,
Vadim Belman
> On Jan 1, 2021, at 1:23 PM, Nathan Gray wrote:
>
> I am working on a small virtual organ program, where I have
> multiple MIDI controller keyboards which can be connected to one
> or more synthesizer channels to emit various sounds
> simultaneously.
>
> At this point, I am able to read events from a single MIDI
> controller and send the events to the correct synthesizer channel
> (I'm using Timidity at the moment).
>
> I would like to read keypresses from the computer keyboard and
> use those to adjust which synthesizers receive which MIDI events.
> In other words, I press a note on my MIDI controller and the note
> plays a sound on the synthesizer I have set up. When I press the
> letter 'a' on my computer keyboard, I would like to add another
> synthesizer, so that subsequent notes played on the MIDI
> controller send events to the original synthesizer and to a new
> synthesizer.
>
> I was able to build a script to read in events from the computer
> keyboard (via the module Term::ReadKey). I read these keypresses
> in a react block with a whenever:
>
>react {
>whenever key-pressed(:!echo) {
># Eventually will connect or disconnect a synthesizer for the
> relevant MIDI controller.
># Currently just prints out the key that was pressed.
>given .fc {
>when 'q' { done }
>default { .raku.say }
>}
>}
>}
>
> The MIDI events are being read via the module Audio::PortMIDI in
> a loop block:
>
>my $pm = Audio::PortMIDI.new;
>my $stream = $pm.open-input($input-device-number, 32);
>my $voice = $pm.open-output($output-device-number, 32);
># Read events from the MIDI controller and write to the synthesizer.
>loop {
>if $stream.poll {
>my @notes = $stream.read(1);
>$voice.write(@notes);
>}
>}
>
> I'm struggling to figure out how to combine the react block for
> the computer keyboard events and the loop block for the MIDI
> events. I would like to be able to accept events from both
> devices concurrently.
>
> It seems like I might need to turn the loop into a Supply of some
> kind, but I'm not sure how I would go about doing that. If I
> understand correctly, once it is a supply, I could add it to the
> react block as another whenever event.
>
> I have found examples of how to create a Supply using a loop and
> a Promise that is kept after a specific amount of time
> (https://stackoverflow.com/questions/57486372/concurrency-react-ing-to-more-than-one-supply-at-a-time),
> but I have not found anything that is polling from a data stream.
>
> My attempt of polling the stream in a whenever block errors out,
> without me ever pressing a key, which makes it seem like it is
> trying to read when there are no keypress events available.
>
>whenever so $stream.poll {
>my @notes = $stream.read(1);
>...
>}
>
> Type check failed for return value; expected Str but got Any (Any)
> in sub with-termios at
> /home/kolibrie/.raku/sources/C758559420AEADF99B8D412BDFADA739CAC14C2A
> (Term::ReadKey) line 20
> in block at
> /home/kolibrie/.raku/sources/C758559420AEADF99B8D412BDFADA739CAC14C2A
> (Term::ReadKey) line 51
>
> Any insights would be greatly appreciated.
>
> -kolibrie
signature.asc
Description: Message signed with OpenPGP
Re: pod6 and markdown
Unfortunately, neither rendered constraints nor image insertions are implemented yet. Or it is so up to my knowledge, at least. I miss these features too sometimes. Best regards, Vadim Belman > On Aug 31, 2020, at 6:56 AM, Fernando Santagata > wrote: > > Hello *, > > I was wondering whether there's a way to tell that a section of pod6 should > be rendered only by a specific renderer. > > My problem is that I want to show a figure in a README.md and I'm using > App::MI6, which builds the README.md file from the pod6 documentation in the > module file. > > As far as I can tell, there's no specific pod6 formatter for a figure; so far > I 've beeninserting raw markdown lines in the pod6 documentation, such as > "", but it's ugly and it would show when other > renderers will be used on the same pod6 file. > > Is there a way to restrict some text to just one renderer, or to insert a > figure or picture in a pod6 file? > > -- > Fernando Santagata
Re: BUILD and TWEAK
Oh, and the thing I forgot to mention: contrary to BUILD and TWEAK, DESTROY is
invoked by underlying backend VM. I.e. by MoarVM, or JVM, or JS because only
the VM knows when exactly an object cease to exists.
Best regards,
Vadim Belman
> On Jul 21, 2020, at 4:53 AM, Richard Hainsworth
> wrote:
>
> Trying to update the documentation on submethod TWEAK - there is nothing.
>
> But the documentation should be accurate and not confusing. So some questions:
>
> In a loop or program, things like BUILD or LEAVE or FIRST are called
> 'phasers'.
>
> By analogy, during the 'build' process of instantiating an object from a
> class, two 'submethod's can be called, viz.
>
> submethod BUILD and submethod TWEAK.
>
> 1) Should these submethods be considered 'phasers' to be consistent with
> other BUILD, LEAVE etc usages?
>
> 2) What actually calls these submethods?
>
> The documentation says 'bless' indirectly calls submethod BUILD. But the
> documentation seems to indicate that 'bless' is not needed to create an
> object.
>
> So what calls the submethods?
>
> 3) Is it correct to say that TWEAK can access all the attributes of the
> object?
>
> 4) How to describe the way the TWEAK of a subclass accesses attributes in the
> parent?
>
> eg
>
> class A { has $.thing }
>
> class B is A { submethod TWEAK { #do something to $.thing in A } }
>
Re: BUILD and TWEAK
> On Jul 21, 2020, at 4:53 AM, Richard Hainsworth > wrote: > > Trying to update the documentation on submethod TWEAK - there is nothing. > > But the documentation should be accurate and not confusing. So some questions: > > In a loop or program, things like BUILD or LEAVE or FIRST are called > 'phasers'. s/BUILD/BEGIN/ BUILD is a constructor. Same applies to TWEAK. Both are invoked at construction time but have different semantics. BUILD must take care of attribute initialization. If not installed, the core installs one for you. TWEAK is invoked at the last stage of construction is is able to tweak object state, as the name suggests. > > By analogy, during the 'build' process of instantiating an object from a > class, two 'submethod's can be called, viz. > > submethod BUILD and submethod TWEAK. > > 1) Should these submethods be considered 'phasers' to be consistent with > other BUILD, LEAVE etc usages? No. A phaser something responsible for a phase in code execution. BUILD, TWEAK, and DESTROY are responsible for object life cycle. BTW, there was once a discussion about a common name for all of them. But I don't remember if there was any consensus reached. In either case, 'constructors' and 'destructors' terms are commonplace. > > 2) What actually calls these submethods? With some level of simplification I can say that BUILD and TWEAK are invoked by method new. There is some indirection level though. > > The documentation says 'bless' indirectly calls submethod BUILD. But the > documentation seems to indicate that 'bless' is not needed to create an > object. 'bless' is kind of a simplified version of 'new'. You can find them in Rakudo src/core.c/Mu.pm. > > 3) Is it correct to say that TWEAK can access all the attributes of the > object? TWEAK can access all attributes of its class and public attributes of parent classes. BEGIN and TWEAK can't use `$.attribute` notation though, only `$!attribute` or `self.attribute`. > > 4) How to describe the way the TWEAK of a subclass accesses attributes in the > parent? It's done same way as accessing any parent method, as described above. Best regards, Vadim Belman
Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
You have so many things messed up in a single mail, it's hard to choose the one to start with. By attempting to install the module myself I suddenly spotted it at once: the module is buggy and need fixing. macOS doesn't support .so format. Instead, it's using own .dylib. It's hard to tell what exactly wrong about the module, but the first guess would be about it using explicit full file name when loading a native lib where it should use just 'libcurl'. With regard to other matters, the most crucial one which may affect you in the future, is a security feature of macOS which only allows loading of dynamic libraries either from system paths like /lib/ or /usr/lib/; or from lib/ dir located in the same subdirectory where the program executable is located. I.e. whatever is installed in /opt/local/bin have access to dynamic libraries in /opt/local/lib. If your rakudo executable is installed somewhere else (~/raku/bin for me) it wouldn't see nothing in /opt/local/lib. This can be fixed by symlinking the files of libs into a location where they're available to raku. I think rakubrew does it automatically for a user; or at least the feature was planned. Another way is to link the files into ~/lib which is also considered by macOS for executables under user's home dir. Best regards, Vadim Belman > On Jul 10, 2020, at 10:00 PM, William Michels via perl6-users > wrote: > > Hello, > > I just updated to Rakudo-2020.06, and while updating many of my > modules to their latest versions I saw an error installing/updating > (Raku) LibCurl. Below, the first few lines of the error seen with > LibCurl::Easy (and EasyHandle): > > ===> Testing: LibCurl:ver<1.0>:auth:api<1> > [LibCurl] # Failed test 'LibCurl::EasyHandle module can be use-d ok' > [LibCurl] # at t/01-load.t line 6 > [LibCurl] # Cannot load native library 'libcurl.so.4' > [LibCurl] # Failed test 'LibCurl::Easy module can be use-d ok' > [LibCurl] # at t/01-load.t line 8 > [LibCurl] # ===SORRY!=== Error while compiling > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > (LibCurl::Easy) > [LibCurl] # Cannot load native library 'libcurl.so.4' > [LibCurl] # at > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > (LibCurl::Easy):2 > > So one caveat is that this install is on an OS which many would > consider to be "MacOS.10.ancient" [I'm posting here and not on Github > because we seem to have a number of Mac users on this mailing-list]. > But the fact of the matter is Raku LibCurl:ver<0.9> worked just fine > with Rakudo-2020.02.1. Furthermore, now that I've downgraded back to > Raku LibCurl:ver<0.9>, LibCurl::Easy works once again on the latest > Rakudo-2020.06. So I really feel the problem is with LibCurl:ver<1.0> > on Macs, and not my particular install. > > Questions for Mac-heads: Do newer versions of MacOS still install > LibCurl as part of the OS? Where does that reside? I know I have > libcurl in the following directories, however 'libcurl.so.4' is > conspicuously absent: > > /opt/local/lib/libcurl.4.dylib > /opt/local/lib/libcurl.a > /opt/local/lib/libcurl.dylib > > Are Mac-users able to use (Raku) LibCurl:ver<1.0> on their (newer) > systems? FYI, I've installed curl independently of MacOS via either > MacBrew or MacPorts, and in fact MacBrew reports upon attempting to > update: "Warning: curl 7.71.1 is already installed and up-to-date". > > Any help appreciated, Thx, Bill. >
Re: perl6 with Rakudobrew
With regard to 'built and installed' – yes, it is. But the purpose of rakudobrew is to build and install many different versions of rakudo and switch between them. The way it implements the task is by installing rakudo in a location which is normally not accessible and then provide means to actually make it available to you depending on what version of rakudo you need at some point in time. I'd very much recommend you carefully read rakudobrew or rakubrew documentation first because otherwise you won't be able to solve your problem. In either case, it is not necessary to have a Windows to test rakudobrew. I'm mostly positive that you'd get same result on a linux to what you get with appveyor. Best regards, Vadim Belman > On Jun 13, 2020, at 5:34 PM, Richard Hainsworth > wrote: > > Vadim, > > Your response is like a whisper in a storm. Perhaps there is meaning to it, > but I have not the ears wherewith to hear it. > > (a) I am trying to find a way to test a Module under Windows when I do not > have access to a Windows machine. So no I do not see how I could follow the > steps of the script manually. That is precisely why I am trying to use > appveyor. Not ideal. No. > > And (b) your words are as perplexing to me as the error messages themselves. > If I were able to understand the error message, I would probably be able to > understand what you wrote, but I can't so I don't. > > If you look at the error message from the Rakudobrew script, it says 'perl6 > is not available'. But a few lines previously, there is the line: > > `Rakudo has been built and installed.` > > And I understand that to mean that perl6 would be available. Note that > 'perl6' is not explicitly used anywhere in my script, so I don't know where > it is appearing. > I appreciate the time you took to read and respond to my email, and I realise > I have made an error and that I truly do not understand entirely what I am > doing, > > but that is precisely why I have written for help. > > Richard > > On 13/06/2020 21:00, Vadim Belman wrote: >> >> Did you ever tried to follow the steps of you script manually? I guess on a >> clean system without pre-installed rakudo you'd get the same result. Because >> `build` only builds a release. When it's ready one needs to `switch` to the >> built. So, no, these two are different. >> >> Best regards, >> Vadim Belman >> >>> On Jun 13, 2020, at 4:57 AM, Richard Hainsworth >> <mailto:rnhainswo...@gmail.com>> wrote: >>> >>> Is the appveyor stanza (see the rakudobrew script below) >>> >>> - rakudobrew build moar %TEST_MOAR% >>> the same as what you are suggesting? >>> >>> Richard >>> On 13/06/2020 02:53, Vadim Belman wrote: >>>> >>>> Not really sure about it, but don't you have to do 'rakudobrew switch >>>> moar-%TEST_MOAR%' after building? rakudobrew doesn't immediately activates >>>> a build. >>>> >>>> Best regards, >>>> Vadim Belman >>>> >>>>> On Jun 12, 2020, at 4:03 PM, Richard Hainsworth >>>> <mailto:rnhainswo...@gmail.com>> wrote: >>>>> >>>>> I have tried two different strategies on appveyor. (I also run a travis >>>>> test for the same Module that passes without a problem). >>>>> >>>>> a) Copying from OpenSSL, which uses rakudo.git (see script below) >>>>> >>>>> b) Copying from GTK::Simple, which uses Rakudobrew (see below) >>>>> >>>>> Both failed for reasons I can't work out. (The final lines are below) >>>>> >>>>> >>>>> Could someone suggest an install stanza that would use the latest >>>>> `rakudo-star-***.msi` installation package? >>>>> >>>>> It would be good to have some samples in the raku documentation. >>>>> >>>>> I can provide my travis script (I use JJ's docker image). >>>>> >>>>> [Rakudobrew] >>>>> >>>>> os: Visual Studio 2017 >>>>> >>>>> platform: x64 >>>>> >>>>> install: >>>>> - '"C:\Program Files (x86)\Microsoft Visual >>>>> Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"' >>>>> - appveyor-retry choco install strawberryperl --allow-empty-checksums >>>>> - SET >>>>> PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH% >>>>> - git c
Re: perl6 with Rakudobrew
Did you ever tried to follow the steps of you script manually? I guess on a clean system without pre-installed rakudo you'd get the same result. Because `build` only builds a release. When it's ready one needs to `switch` to the built. So, no, these two are different. Best regards, Vadim Belman > On Jun 13, 2020, at 4:57 AM, Richard Hainsworth > wrote: > > Is the appveyor stanza (see the rakudobrew script below) > > - rakudobrew build moar %TEST_MOAR% > the same as what you are suggesting? > > Richard > On 13/06/2020 02:53, Vadim Belman wrote: >> >> Not really sure about it, but don't you have to do 'rakudobrew switch >> moar-%TEST_MOAR%' after building? rakudobrew doesn't immediately activates a >> build. >> >> Best regards, >> Vadim Belman >> >>> On Jun 12, 2020, at 4:03 PM, Richard Hainsworth >> <mailto:rnhainswo...@gmail.com>> wrote: >>> >>> I have tried two different strategies on appveyor. (I also run a travis >>> test for the same Module that passes without a problem). >>> >>> a) Copying from OpenSSL, which uses rakudo.git (see script below) >>> >>> b) Copying from GTK::Simple, which uses Rakudobrew (see below) >>> >>> Both failed for reasons I can't work out. (The final lines are below) >>> >>> >>> Could someone suggest an install stanza that would use the latest >>> `rakudo-star-***.msi` installation package? >>> >>> It would be good to have some samples in the raku documentation. >>> >>> I can provide my travis script (I use JJ's docker image). >>> >>> [Rakudobrew] >>> >>> os: Visual Studio 2017 >>> >>> platform: x64 >>> >>> install: >>> - '"C:\Program Files (x86)\Microsoft Visual >>> Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"' >>> - appveyor-retry choco install strawberryperl --allow-empty-checksums >>> - SET >>> PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH% >>> - git clone https://github.com/tadzik/rakudobrew >>> <https://github.com/tadzik/rakudobrew> %USERPROFILE%\rakudobrew >>> - SET PATH=%USERPROFILE%\rakudobrew\bin;%PATH% >>> - rakudobrew build moar %TEST_MOAR% >>> - rakudobrew build zef >>> - cd %APPVEYOR_BUILD_FOLDER% >>> - echo "installing SSL so we can download the dll files" >>> - zef install IO::Socket::SSL >>> - zef --depsonly install . >>> - zef build . >>> >>> build: off >>> >>> test_script: >>> - prove -v -e "raku -Ilib" t/ >>> - zef --debug install . >>> >>> shallow_clone: true >>> [ response from appveyor fail - last lines] >>> ... >>> Generating code >>> Finished generating code >>> Microsoft (R) Program Maintenance Utility Version 14.16.27035.0 >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> +++ Checking for moar NQP version >>> +++ Creating installation directories >>> +++ Removing old files >>> +++ Installing files >>> +++ Preparing installation >>> Installed 13 core modules in 24.63815875 seconds! >>> +++ MOAR BACKEND INSTALLED >>> +++ Installing MOAR launchers >>> +++ Creating Raku executable alias >>> +++ Rakudo installed succesfully! >>> Rakudo has been built and installed. >>> Updating shims >>> Done, moar-2020.05.1 built >>> rakudobrew build zef >>> Cloning into 'zef'... >>> Your branch is up to date with 'origin/master'. >>> rakudobrew: perl6: command not found >>> Command exited with code 1 >>> >>> [Rakudo.git] >>> os: Visual Studio 2017 >>> >>> platform: x64 >>> >>> install: >>> - '"C:\Program Files (x86)\Microsoft Visual >>> Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"' >>> - appveyor-retry choco install strawberryperl --allow-empty-checksums >>> - SET >>> PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH% >>> - appveyor-retry git clone https://github.com/rakudo/rakudo.git >>> <https://github.com/rakudo/rakudo.git> %APPVEYOR_BUILD_FOLDER%\..\rakudo >>> - cd %APPVEYOR_BUILD_FOLDER%\..\rakudo >>> - perl Configure.pl --gen-moar --gen-nqp --backends=moar >>> - nmake install >>> - SET PATH=%APPVEYOR_BUILD_FOLDER%\..\r
Re: perl6 with Rakudobrew
Not really sure about it, but don't you have to do 'rakudobrew switch moar-%TEST_MOAR%' after building? rakudobrew doesn't immediately activates a build. Best regards, Vadim Belman > On Jun 12, 2020, at 4:03 PM, Richard Hainsworth > wrote: > > I have tried two different strategies on appveyor. (I also run a travis test > for the same Module that passes without a problem). > > a) Copying from OpenSSL, which uses rakudo.git (see script below) > > b) Copying from GTK::Simple, which uses Rakudobrew (see below) > > Both failed for reasons I can't work out. (The final lines are below) > > > Could someone suggest an install stanza that would use the latest > `rakudo-star-***.msi` installation package? > > It would be good to have some samples in the raku documentation. > > I can provide my travis script (I use JJ's docker image). > > [Rakudobrew] > > os: Visual Studio 2017 > > platform: x64 > > install: > - '"C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"' > - appveyor-retry choco install strawberryperl --allow-empty-checksums > - SET > PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH% > - git clone https://github.com/tadzik/rakudobrew > <https://github.com/tadzik/rakudobrew> %USERPROFILE%\rakudobrew > - SET PATH=%USERPROFILE%\rakudobrew\bin;%PATH% > - rakudobrew build moar %TEST_MOAR% > - rakudobrew build zef > - cd %APPVEYOR_BUILD_FOLDER% > - echo "installing SSL so we can download the dll files" > - zef install IO::Socket::SSL > - zef --depsonly install . > - zef build . > > build: off > > test_script: > - prove -v -e "raku -Ilib" t/ > - zef --debug install . > > shallow_clone: true > [ response from appveyor fail - last lines] > ... > Generating code > Finished generating code > Microsoft (R) Program Maintenance Utility Version 14.16.27035.0 > Copyright (C) Microsoft Corporation. All rights reserved. > +++ Checking for moar NQP version > +++ Creating installation directories > +++ Removing old files > +++ Installing files > +++ Preparing installation > Installed 13 core modules in 24.63815875 seconds! > +++ MOAR BACKEND INSTALLED > +++ Installing MOAR launchers > +++ Creating Raku executable alias > +++ Rakudo installed succesfully! > Rakudo has been built and installed. > Updating shims > Done, moar-2020.05.1 built > rakudobrew build zef > Cloning into 'zef'... > Your branch is up to date with 'origin/master'. > rakudobrew: perl6: command not found > Command exited with code 1 > > [Rakudo.git] > os: Visual Studio 2017 > > platform: x64 > > install: > - '"C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"' > - appveyor-retry choco install strawberryperl --allow-empty-checksums > - SET > PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH% > - appveyor-retry git clone https://github.com/rakudo/rakudo.git > <https://github.com/rakudo/rakudo.git> %APPVEYOR_BUILD_FOLDER%\..\rakudo > - cd %APPVEYOR_BUILD_FOLDER%\..\rakudo > - perl Configure.pl --gen-moar --gen-nqp --backends=moar > - nmake install > - SET PATH=%APPVEYOR_BUILD_FOLDER%\..\rakudo\install\bin;%PATH% > - SET > PATH=%APPVEYOR_BUILD_FOLDER%\..\rakudo\install\share\perl6\site\bin;%PATH% > - cd %APPVEYOR_BUILD_FOLDER% > - echo "installing SSL so we can download the dll files" > - zef install IO::Socket::SSL > - zef --depsonly install . > - zef build . > > build: off > > test_script: > - prove -v -e "raku -Ilib" t/ > - zef --debug install . > > shallow_clone: true > [rakudo.git - avveyor failure. last lines] > > +++ MOAR BACKEND INSTALLED > +++ Installing MOAR launchers > +++ Creating Raku executable alias > +++ Rakudo installed succesfully! > SET PATH=%APPVEYOR_BUILD_FOLDER%\..\rakudo\install\bin;%PATH% > SET PATH=%APPVEYOR_BUILD_FOLDER%\..\rakudo\install\share\perl6\site\bin;%PATH% > cd %APPVEYOR_BUILD_FOLDER% > echo "installing SSL so we can download the dll files" > "installing SSL so we can download the dll files" > zef install IO::Socket::SSL > 'zef' is not recognized as an internal or external command, > operable program or batch file. > Command exited with code 1 > [end] > > On 12/06/2020 20:15, Vadim Belman wrote: >> I'm still using rakudobrew for myself, it is not a problem. Besides, we >> still install perl6. >> >> What I'd look for is if correct PATH is setup; and check if rakudobrew is >&g
Re: perl6 with Rakudobrew
I'm still using rakudobrew for myself, it is not a problem. Besides, we still install perl6. What I'd look for is if correct PATH is setup; and check if rakudobrew is been used properly. Note that different modes (env or shim) would need different handling. To my understanding, in a container shims are preferable over env. Best regards, Vadim Belman > On Jun 12, 2020, at 2:40 PM, Elizabeth Mattijsen wrote: > > It is my understanding that rakudobrew has been renamed to rakubrew: > https://rakubrew.org Could the be the issue? > >> On 12 Jun 2020, at 14:59, Richard Hainsworth wrote: >> >> I ran into this error using Rakudobrew on appveyor (see after ) >> >> I'm new at using appveyor, so maybe my script is wrong. But I wonder whether >> its because of a name change to raku without a backward alias to perl6. >> >> >> >> Rakudo has been built and installed. >> >> Updating shims >> Done, moar-2020.05.1 built >> rakudobrew build zef >> Cloning into 'zef'... >> Your branch is up to date with 'origin/master'. >> rakudobrew: perl6: command not found >> Command exited with code 1 >
Re: stashing an array in a hash and yanking it back out
Joseph, you've got yourself into a trap I fell into yesterday. %stash.append( :@stuff ) syntax is about calling append method with a named parameter stuff whereas append works with positionals only. So, your case should be written: %stash.append( (:@stuff) ); Which is apparently more cumbersome. In either case, use of colons is not always about saving a character or two. Sometimes it's about readability, sometimes about elegance. Overuse is surely bad, but overuse of anything is bad, for that matter. :) Best regards, Vadim Belman > On Mar 17, 2020, at 1:09 PM, Joseph Brenner wrote: > >> Though I've no idea what those colons are/are not doing. > > Those are "colon pairs" (which I've relearned around three times now...): > > https://docs.raku.org/language/glossary#index-entry-Colon_Pair > <https://docs.raku.org/language/glossary#index-entry-Colon_Pair> > > Except for this colon: > > %stash.append: (rocks => @rocks); > > Which is a short hand for this: > > %stash.append( (rocks => @rocks) ); > > As an aside: it's a minor style point, but I think a lot of > us overuse that trick-- it saves a character, but the explicit > parens are more flexible. > > Notably this works fine, so here it doesn't even save any > characters: > > %stash.append( :@stuff ); > >
Re: stashing an array in a hash and yanking it back out
My reply to Joseph went off the list too. I copy it over here. Here is the key
quote from Joseph's email I was answering to:
So doing that with append would be like this:
%stash.append: (:greek(@greek));
William Michels was wondering if there was a way to avoid
repeating the name twice, speculating that there might be
some way to do that with a 'whateva' *.
My answer follows:
Ok, clear enough. This is as simple as:
%stash.append: (:@greek);
Roughly, colon op doesn't care about sigils and twigils. It takes a symbol and
creates a pair with the key of the symbol. A good example with a bit of Raku
charm:
class Foo {
has @.attr = ;
method foo { %(:@.attr) }
}
say Foo.new.foo; # {attr => [a b c]}
Best regards,
Vadim Belman
> On Mar 16, 2020, at 6:44 PM, Andy Bach wrote:
>
> Vadim clarified for us, off-list:
> > So, you basically needed:
> my %h = :a(1); %h.append: (:b(2));
>
> > Am I correct?
> I think so, I mean, I believe the append method(?) for hashes would solve the
> problem the "whatever star" was attempted to be used for - so:
>>>> > my @monsters = << godzilla grendel wormface blob fingfangfoom tingler >>;
>>>> [godzilla grendel wormface blob fingfangfoom tingler]
>>>> > my @rocks = << marble sandstone granite chert pumice limestone >>
>>>> [marble sandstone granite chert pumice limestone]
>>>> > my %stash = monsters => @monsters
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler]}
>>>> > %stash.append: (:rocks(@rocks));
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks
>>>> => [marble sandstone granite chert pumice limestone]}
>>>> Or:
>>>> > my %stash = monsters => @monsters
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler]}
>>>> > %stash.append: (:rocks => @rocks);
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks
>>>> True => [marble sandstone granite chert pumice limestone]}
>>>> Or:
>>>> > my %stash = monsters => @monsters
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler]}
>>>> > %stash.append: (rocks => @rocks);
>>>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks
>>>> => [marble sandstone granite chert pumice limestone]}
>>>>
> Though I've no idea what those colons are/are not doing. And we can get to
> those "inner" array elements via
> > say %stash[1]
> sandstone
>
>
>
> From: Vadim Belman
> Sent: Friday, March 13, 2020 12:50 PM
> To: Andy Bach
> Cc: William Michels via perl6-users ; Joseph Brenner
> ; Timo Paulssen ; yary
>
> Subject: Re: stashing an array in a hash and yanking it back out
>
>
> There is no mystery whatsoever.
>
> Consider the following:
>
> my %h = "a", 1; # {a => 1}
>
> Then consider this:
>
> say *, *; # **
>
>
> and also:
>
> say *.VAR.WHAT; # (Whatever)
>
> Taking into account that => has tighter precedence than , what you get in:
>
> my %h = *, a => [1,2,3];
>
> is actually the following data structure:
>
> %( Whatever => Pair )
>
> Regarding your use of postcircumfix [ ] on the data, you use it on Pair.
>
> Best regards,
> Vadim Belman
>
>> On Mar 13, 2020, at 11:52 AM, Andy Bach > <mailto:andy_b...@wiwb.uscourts.gov>> wrote:
>>
>> > my %stash = monsters => @monsters, rocks => @rocks
>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks =>
>> [marble sandstone granite chert pumice limestone]}
>> > my @more_rocks = << marble sandstone granite chert pumice limestone >>
>> [marble sandstone granite chert pumice limestone]
>> > my %stash = *, morerocks => @rocks
>> {* => morerocks => [marble sandstone granite chert pumice limestone]}
>> > say %stash{*}
>> (morerocks => [marble sandstone granite chert pumice limestone])
>>
>> So, I'm guessing the display
>> {* => morerocks => [marble sandstone granite chert pumice limestone]}
>>
>> really means something like
>> {* => (morerocks => [marble sandstone granite chert pumice limestone])}
>>
>> maybe?
>> > say @(%stash{*})
>> (morerocks => [marble sandstone granite chert pumice limestone])
>> > say @(%stash{*}).[0]
>> morerocks => [marble sandstone granite chert pumice limestone]
>> > say @(%stash{*}).[
Re: stashing an array in a hash and yanking it back out
Due to rather weird formatting in your message I hardly can understand what is
it all about. But before you can find an answer on how to get the array out of
the hash, try answering the following question: why do you use bare asterisk in
the hash initialization? What is its purpose over there? To me this looks like
the key to all your issues.
With regard to Pair type object, there is a little magic about it:
my $p = a => [1,2]; say $p;
Or, in your case that'd be something like:
my %h = *, a => ; say %h<*>;
Though I'd still insist on reconsidering how you do things.
Best regards,
Vadim Belman
> On Mar 15, 2020, at 5:41 PM, Andy Bach wrote:
>
> >> really means something like
> {* => (morerocks => [marble sandstone granite chert pumice limestone])}
>
> > Taking into account that => has tighter precedence than , what you get in:
> my %h = *, a => [1,2,3];
>
> > is actually the following data structure:
> %( Whatever => Pair )
>
> That's sort of what I said, or, at least, saw.
> > Regarding your use of postcircumfix [ ] on the data, you use it on Pair.
>
> Not quite sure what this means, but is that how you'd get the [ rocks>] array from %stash? I could get the pair back, but not the "inner"
> array of the pair's 2nd partner, so to speak:
> >> say @(%stash{*})
> (morerocks => [marble sandstone granite chert pumice limestone])
> >> say @(%stash{*}).[0]
> morerocks => [marble sandstone granite chert pumice limestone]
> >> say @(%stash{*}).[1]
> Nil
> >> say @(%stash{*}).[0].{morerocks}
> ===SORRY!=== Error while compiling:
> Undeclared routine:
> morerocks used at line 1
>
> >> say @(%stash{*}).[0].[0]
> morerocks => [marble sandstone granite chert pumice limestone]
>
>
> a
>
> From: Vadim Belman
> Sent: Friday, March 13, 2020 12:50 PM
> To: Andy Bach
> Cc: William Michels via perl6-users ; Joseph Brenner
> ; Timo Paulssen ; yary
>
> Subject: Re: stashing an array in a hash and yanking it back out
>
>
> There is no mystery whatsoever.
>
> Consider the following:
>
> my %h = "a", 1; # {a => 1}
>
> Then consider this:
>
> say *, *; # **
>
>
> and also:
>
> say *.VAR.WHAT; # (Whatever)
>
> Taking into account that => has tighter precedence than , what you get in:
>
> my %h = *, a => [1,2,3];
>
> is actually the following data structure:
>
> %( Whatever => Pair )
>
> Regarding your use of postcircumfix [ ] on the data, you use it on Pair.
>
> Best regards,
> Vadim Belman
>
>> On Mar 13, 2020, at 11:52 AM, Andy Bach > <mailto:andy_b...@wiwb.uscourts.gov>> wrote:
>>
>> > my %stash = monsters => @monsters, rocks => @rocks
>> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks =>
>> [marble sandstone granite chert pumice limestone]}
>> > my @more_rocks = << marble sandstone granite chert pumice limestone >>
>> [marble sandstone granite chert pumice limestone]
>> > my %stash = *, morerocks => @rocks
>> {* => morerocks => [marble sandstone granite chert pumice limestone]}
>> > say %stash{*}
>> (morerocks => [marble sandstone granite chert pumice limestone])
>>
>> So, I'm guessing the display
>> {* => morerocks => [marble sandstone granite chert pumice limestone]}
>>
>> really means something like
>> {* => (morerocks => [marble sandstone granite chert pumice limestone])}
>>
>> maybe?
>> > say @(%stash{*})
>> (morerocks => [marble sandstone granite chert pumice limestone])
>> > say @(%stash{*}).[0]
>> morerocks => [marble sandstone granite chert pumice limestone]
>> > say @(%stash{*}).[1]
>> Nil
>> > say @(%stash{*}).[0].{morerocks}
>> ===SORRY!=== Error while compiling:
>> Undeclared routine:
>> morerocks used at line 1
>>
>> > say @(%stash{*}).[0].[0]
>> morerocks => [marble sandstone granite chert pumice limestone]
>> > say @(%stash{*}).[0].[1]
>> Index out of range. Is: 1, should be in 0..0
>> in block at line 1
>>
>> > say @(%stash{*}).[0].[0].perl
>> :morerocks(["marble", "sandstone", "granite", "chert", "pumice",
>> "limestone"])
>> > say @(%stash{*}).[0].perl
>> :morerocks(["marble", "sandstone", "granite", "chert", "pumice",
>> "limestone"])
>>
>>
>> I dunno.
>>
>> From: William Michels via perl6-users
Re: stashing an array in a hash and yanking it back out
There is no mystery whatsoever.
Consider the following:
my %h = "a", 1; # {a => 1}
Then consider this:
say *, *; # **
and also:
say *.VAR.WHAT; # (Whatever)
Taking into account that => has tighter precedence than , what you get in:
my %h = *, a => [1,2,3];
is actually the following data structure:
%( Whatever => Pair )
Regarding your use of postcircumfix [ ] on the data, you use it on Pair.
Best regards,
Vadim Belman
> On Mar 13, 2020, at 11:52 AM, Andy Bach wrote:
>
> > my %stash = monsters => @monsters, rocks => @rocks
> {monsters => [godzilla grendel wormface blob fingfangfoom tingler], rocks =>
> [marble sandstone granite chert pumice limestone]}
> > my @more_rocks = << marble sandstone granite chert pumice limestone >>
> [marble sandstone granite chert pumice limestone]
> > my %stash = *, morerocks => @rocks
> {* => morerocks => [marble sandstone granite chert pumice limestone]}
> > say %stash{*}
> (morerocks => [marble sandstone granite chert pumice limestone])
>
> So, I'm guessing the display
> {* => morerocks => [marble sandstone granite chert pumice limestone]}
>
> really means something like
> {* => (morerocks => [marble sandstone granite chert pumice limestone])}
>
> maybe?
> > say @(%stash{*})
> (morerocks => [marble sandstone granite chert pumice limestone])
> > say @(%stash{*}).[0]
> morerocks => [marble sandstone granite chert pumice limestone]
> > say @(%stash{*}).[1]
> Nil
> > say @(%stash{*}).[0].{morerocks}
> ===SORRY!=== Error while compiling:
> Undeclared routine:
> morerocks used at line 1
>
> > say @(%stash{*}).[0].[0]
> morerocks => [marble sandstone granite chert pumice limestone]
> > say @(%stash{*}).[0].[1]
> Index out of range. Is: 1, should be in 0..0
> in block at line 1
>
> > say @(%stash{*}).[0].[0].perl
> :morerocks(["marble", "sandstone", "granite", "chert", "pumice", "limestone"])
> > say @(%stash{*}).[0].perl
> :morerocks(["marble", "sandstone", "granite", "chert", "pumice", "limestone"])
>
>
> I dunno.
>
> From: William Michels via perl6-users <mailto:perl6-users@perl.org>>
> Sent: Thursday, March 12, 2020 5:44 PM
> To: perl6-users mailto:perl6-users@perl.org>>
> Cc: Joseph Brenner mailto:doom...@gmail.com>>; Timo
> Paulssen mailto:t...@wakelift.de>>; yary
> mailto:not@gmail.com>>
> Subject: Re: stashing an array in a hash and yanking it back out
>
> Thanks yary! The code you posted works perfectly.
>
> Okay, one last question. I tried to use the 'DRY' principle to add
> things to a hash. However, (thinking that a 'whatever star' might
> reduce typing), I came up with an odd "ternary" structure. Can anyone
> explain the last line of code, below?
>
> mbook:~ homedir$ perl6
> To exit type 'exit' or '^D'
> > my @monsters = << godzilla grendel wormface blob fingfangfoom tingler >>;
> [godzilla grendel wormface blob fingfangfoom tingler]
> > my @rocks = << marble sandstone granite chert pumice limestone >>
> [marble sandstone granite chert pumice limestone]
> > my %stash = monsters => @monsters
> {monsters => [godzilla grendel wormface blob fingfangfoom tingler]}
> > my %stash = *, rocks => @rocks;
> {* => rocks => [marble sandstone granite chert pumice limestone]}
>
> Thanks, Bill.
>
>
> On Wed, Mar 11, 2020 at 9:06 PM yary <mailto:not@gmail.com>> wrote:
> >
> > The fat-arrow example makes sense, what this says
> > %stash = rocks => @rocks
> > is "replace %stash in its entirety with key rocks gets value @rocks"
> > anything that used to be in %stash doesn't matter because this assignment
> > (left side) is the entirety of %stash
> >
> > what this says
> > %stash{'rocks'} = @rocks
> > is "replace the slot 'rocks' in %stash with @rocks"
> > This assignment only is for the 'rocks' element of %stash so the other
> > elements remain unchanged.
> >
> > Extending the examples, first 3 lines are unchanged from before
> >
> > > my @monsters = << godzilla grendel wormface blob fingfangfoom tingler >>;
> > [godzilla grendel wormface blob fingfangfoom tingler]
> > > my @rocks = << marble sandstone granite chert pumice limestone >>
> > [marble sandstone granite chert pumice limestone]
> > > my %stash = monsters => @monsters
> > {monsters => [godzilla grendel wormface blob fingfangfoom tingler]
Re: Rakudo Star v2020.01
Neither you need to rename anything Patrick unless it's something purely Rakudo Star related. Whatever is in Rakudo directory will be renamed when time comes. Also, perl6 binaries (or rather links to rakudo binaries) are there for backward compatibility. They will be deprecated with the release of v6.e of Raku language and removed in v6.f. Best regards, Vadim Belman > On Mar 3, 2020, at 6:16 PM, Patrick Spek via perl6-users > wrote: > > On Tue, 3 Mar 2020 16:41:47 -0500 > Parrot Raiser <1parr...@gmail.com <mailto:1parr...@gmail.com>> wrote: > >> I've managed to download 2020.01, and run it with an explicit path, >> but the directory structure that my script used to follow, is broken >> in some way. (I'll investigate further, to see if I can spot the >> change, but a required directory tree might help me find it, if you >> could provide one.) >> >> A fair number of references to "perl6" remain in the directories. How >> many references have to be untangled before it is consistently >> "rakudo"? > > I have no plans currently to go through the existing infrastructure and > rename things. I'm not intimately familiar with the code in Rakudo > Star, and prefer to not touch what isn't broken. If references are > found and can be easily fixed, I'll gladly look into it, though. Of > course, patches to help out are much appreciated as well! > > Also, please note that the language is called Raku, the compiler is > Rakudo. > > -- > With kind regards, > > Patrick Spek > > > www: https://www.tyil.nl/ <https://www.tyil.nl/> > mail: p.s...@tyil.nl <mailto:p.s...@tyil.nl> > pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 > > social: https://soc.fglt.nl/tyil <https://soc.fglt.nl/tyil> > git:https://gitlab.com/tyil/ <https://gitlab.com/tyil/> signature.asc Description: Message signed with OpenPGP
Re: Range on Subsets
UInt is just being handled individually by the core. You can override method
Range by either mixin a role into your subset base type:
constant MyInt = Int but role { method Range { 1...10 } };
subset OneToTen of MyInt where ...;
Or by subclassing Int:
class MyInt is Int { method Range { ... } }
Best regards,
Vadim Belman
> On Jan 28, 2020, at 10:03 AM, Simon Proctor wrote:
>
> So some recent conversations covered the Range method on numeric types like
> Int
>
> So Int.Range gives the range of valid values -Inf^..^Inf which is neat.
>
> Then I thought I'd try UInt.Range and got 0..^Inf
>
> Ah Ha! Thinks I. I have a plan. What if I try this?
>
> my subset OneToTen of Int where { not .defined or 1 <= $_ <= 10 };
> say OneToTen.Range;
>
> And it gives ...
>
> -Inf^..^Inf
>
> And now I'm a bit confused. The Docs say the UInt is just a subset
> https://docs.raku.org/type/UInt <https://docs.raku.org/type/UInt>
>
> So how does it have it's own Range?
>
> --
> Simon Proctor
> Cognoscite aliquid novum cotidie
>
> http://www.khanate.co.uk/ <http://www.khanate.co.uk/>
Re: weirdness with subset on has
At a quick glance, looks like a bug to me. Worth opening a ticket on
https://github.com/rakudo/rakudo
Best regards,
Vadim Belman
> On Jan 12, 2020, at 8:15 PM, Joseph Brenner wrote:
>
> Moving the definition of the subset outside of the class
> covers for the weird behavior...
>
> my @allowed = << alpha beta gamma delta >>;
> my @default = << alpha >>;
> subset Allowed of Str where * eq any( @allowed );
>
> class HasSubset {
> has Allowed @.grk = @default;
> method echo_grk {
> say @!grk.join(" | ");
> }
> }
>
> my $obj = HasSubset.new();
> $obj.echo_grk();
>
> my $obj2 = HasSubset.new( grk => << alpha beta gamma >> );
> $obj2.echo_grk();
>
> my $obj3 = HasSubset.new( grk => << alpha beta rutabaga >> );
> $obj3.echo_grk();
> # value 'rutabaga' fails as expected:
> # Type check failed in assignment to @!grk; expected
> HasSubset::Allowed but got Str ("rutabaga")
>
>
> On 1/12/20, Joseph Brenner wrote:
>> Here's a code snippet that tries to use a subset to constrain the
>> values of an object field (i.e. declared with has). As written, this
>> code works, but only when there's what looks like an irrelevant
>> experimental line in it (labeled "WEIRD ONE"), when that line is
>> commented out it throws an error...
>>
>> class HasSubset {
>> my @allowed = << alpha beta gamma delta >>;
>> my @default = << alpha >>;
>>
>> subset Allowed of Str where * eq any( @allowed );
>>
>> my Allowed $experiment = 'delta'; # WEIRD ONE this line is
>> *needed* to get the following to work...
>>
>> has Allowed @.greek = @default;
>>
>> method echo_greek {
>> say @!greek.join(" | ");
>> }
>> }
>>
>> my $obj = HasSubset.new();
>> $obj.echo_greek();
>>
>> # As written, prints the default: 'alpha'
>> # Without the WEIRD ONE line, you see errors like:
>> ## Type check failed in assignment to @!greek; expected
>> HasSubset::Allowed but got Str ("alpha")
>>
>
Re: Cannot invoke this object (REPR: Null; VMNull)
What rakudo compiler version do you use? Try 2019.11.
Best regards,
Vadim Belman
> On Dec 14, 2019, at 5:31 PM, Paul Procacci wrote:
>
> Ladies/Gents,
>
> I'm perplexed by the error message as stated in the subject.
> It's quite possible I'm doing it wrong.
> What I'm attempting to do is create an attribute of a class that is a Map ...
> who's value is known at compile time; hence the CHECK phaser.
>
> To produce the error it requires two source files, as merging the class and
> the code that invokes the class doesn't occur in an error:
>
> # File lib/A.pm6
>
> class A {
>
> has Map $!pre-compiled = CHECK {
> Map.new: dir("data", test => { $_ eq none('.', '..') and
> "data/$_".IO.d })>>.map({
> .basename => .dir>>.map({
> .basename => .dir>>.basename.Set
> })
> })
> };
>
> method test {
> $!pre-compiled.perl.say;
> }
> }
>
>
> # File: test.pl6
> ---
> use lib ;
> use A;
>
> my A $x .= new;
> $x.test;
>
>
> % ./test.pl6
> Cannot invoke this object (REPR: Null; VMNull)
> in block at /git-repos/test/lib/Loader.pm6 (Loader) line 31
> in method test at /git-repos/test/lib/Loader.pm6 (Loader) line 115
> in method load at /git-repos/lib/Loader.pm6 (Loader) line 132
> in block at ./test.pl6 line 7
>
>
> As stated earlier, when I merge the class and the initialization logic into
> the same source file and run from there, no error occurs.
>
> Am I doing this wrong?
>
> Thanks,
> Paul Procacci
>
> --
> __
>
> :(){ :|:& };:
Re: about 'use v6.d'
Totally wrong. `use v6` specified Raku (formerly Perl6) code and initially thought to be used to distinct perl5 code from perl6. For now I consider it mostly as a decoration except for test files where .t extension is shared between languages. With regard to multiversioning, rakudo currently supports all language releases available so far. So, if one specifies a particular language version like `use v6.c` it means that the code in the file will be compiled using 6.c. It will be done by the same compiler and it has nothing to do with 'multiple versions installed'. Best regards, Vadim Belman > On Dec 13, 2019, at 1:46 PM, ToddAndMargo via perl6-users > wrote: > > On 2019-12-13 01:08, MT wrote: >> In the light of renaming to Raku I was wondering if the statement 'use v6.*' >> is still useful. > > Hi MT, > > If I am not mistaken, `use v6` is only useful if you have more than one > version of Perl6/Raku loaded on your system. I could be wrong though. > > I personally make sure I only run one version. But I am a newbie to Perl6, > so take what I say "lightly". > > :-) > > -T > > Pretty good with the "weasel" words, huh! >
Re: about 'use v6.d'
Hello Marcel, You make certain assumptions, then you make them something like facts and proclaim things based on these. Please, don't! Raku versioning is the same as it was for Perl6. Backward compatibility is the primary concern of the language development. Certain considerations about future language versioning are still possible. But the final decision will not affect backward compatibility – see above. Best regards, Vadim Belman > On Dec 13, 2019, at 4:08 AM, MT wrote: > > Hello all, > > In the light of renaming to Raku I was wondering if the statement 'use v6.*' > is still useful. > > First there is no version 6 of Raku (should be version 0, but that's another > story) and the 'use v5' in the past used for perl5 is also not used anymore > (I think) (it is, I believe, more common to 'use Inline::Perl5'). > > Also the 'd' of the Diwali version is a nice touch but my experience is that > this is not accurate enough. I've used some new things of Raku introduced > somewhere in summer 2019 but the version is still 6d. Also many bugs are > fixed which requires newer versions to run right. > > So I must warn potential users of the software to install the newest Raku > version, otherwise the programs/modules will run into problems. > > It would be nice to have this version extended, or maybe better, the version > spec in META6.json so that the zef module installer could hold back the > installation if the users Raku version is older. It is not enough to let > tests fail on something the Raku compiler cannot handle because it is does > not show that the compiler is too old when zef is installing modules. > > Regards > Marcel >
Re: Question about "colon syntax" for calling other methods on 'self' inside a method
I would say filing an issue might make sense in this case. Here is a related
comment from Jonathan:
https://github.com/rakudo/rakudo/issues/3222#issuecomment-539915286 – and it
explicitly states that $. is a shortcut for method calling. Therefore, use of
colon instead of braces should be a valid construct.
Best regards,
Vadim Belman
> On Nov 18, 2019, at 11:40 AM, yary wrote:
>
> I take that back! What is the dollar sign doing there in the '$.print: ..."
> example?
>
> Try it without the dollar sign. Right now you're calling .print on the
> anonymous variable '$'
>
> -y
>
>
> On Mon, Nov 18, 2019 at 8:38 AM yary <mailto:not@gmail.com>> wrote:
> looks like a bug to me-file an issue on the rakudo GitHub
>
> On Sat, Nov 16, 2019 at 5:29 AM Raymond Dresens <mailto:raymond.dres...@gmail.com>> wrote:
> Hello,
>
> I have a question related to the 'colon syntax' of Raku, which allows
> you to call methods without parenthesis like this:
>
> class Foo
> {
> method print($x, $y)
> {
> say "bar: {$x}, {$y}"
> }
> }
>
> my $a = Foo.new;
>
> $a.print: 3, 5; # ...this is what i mean with "colon syntax" ;)
>
> It is possible to use this syntax to call methods on 'self' as well:
>
> class Bar is Foo
> {
> method printDefault
> {
> self.print: 8, 12
> }
> }
>
> my $b = Bar.new;
>
> $b.printDefault;
>
> I use $. rather than 'self' in order to work with attributes inside
> methods in my classes, well, ... mostly, because it does not seem
> possible to do this (in rakudo, at least version 2019.07.1):
>
> class Baz is Foo
> {
> method printDefault
> {
> $.print: 8, 12
> }
> }
>
> This yields a "Confused" error, stating that it expects a so-called
> 'colon pair'.
>
> Is this intentional? Because I'm kind of confused as well about this,
>
> I can live with this 'syntactical quirk', but I just keep wondering
> about it because I'd personally expect that this "$.methodname: $args"
> variant should "just work" as well...
>
> ...so "what gives"? ;)
>
> Thanks for your insights!
>
> Regards,
>
> Raymond.
> --
> -y
Re: Who's who of the ecosystem?
For general language problems there is special repo on github where one can raise a matter: https://github.com/perl6/problem-solving <https://github.com/perl6/problem-solving>. Note though it's not a bug-reporting resource, but more information about it's purpose can be found in repo's README. Obviously, rakudo compiler issues goes into https://github.com/rakudo/rakudo/ <https://github.com/rakudo/rakudo/>. This would be the best place to open a ticket when one doesn't know where exactly the problem belongs to. Some tickets serve as a ground for new tickets in other repos, where they actually belong. Now, as you specifically mention zef and the question has seemingly arisen as a part of R* discussion, it should be noted that zef is a personal project of Nick Logan and can be found at https://github.com/ugexe/zef <https://github.com/ugexe/zef>. Respectively, for any other module from the ecosystem it's repo could be located. I usually just google for it, but also https://github.com/perl6/ecosystem <https://github.com/perl6/ecosystem> could serve as a source of information. Best regards, Vadim Belman > On Nov 6, 2019, at 9:48 AM, Parrot Raiser <1parr...@gmail.com> wrote: > > Raku is the product of collaboration by many people. Some of these are > well known, but there are many parts of the ecosystem whose mavens are > anonymous or obscure. When a problem arises, it would be nice to be > able to direct them to someone knowledgeable, rather than essentially > yelling them in public and hoping someone responds to the noise. > > Do we have any kind of resource, (web page or whatever), indicating > who might be authoritative on a particular issue? Some names are > fairly well-known, (and may wish they weren't), but topics like the > internals of zef are hard to link to a person or group. >
Re: Rakudo Star 2019.07.1
This is not really zef's "implementation detail". See rakudo sources in src/core.c/CompUnit and grep for 'sha1'. Best regards, Vadim Belman > On Nov 6, 2019, at 9:04 AM, Patrick Spek via perl6-users > wrote: > > The problem is clearly with the Linenoise module, I'll have to look > into that and see if it's something I can fix. > > The path name you see is "an implementation detail" of Zef, I've been > told before. I have no clue how it actually calculates them, and no > idea where to find any documentation on that. That is something I > cannot fix, and as far as I understand, there's no way this will be > changed on the Zef side of things. > > I'm not sure what you mean with "-n vs .n for sub-version ids". If this > is causing issues or unclarities while trying to get Rakudo Star > installed, I'll need some additional information in order to see if > this is something I should fix or even can fix. > > On Tue, 5 Nov 2019 17:15:26 -0500 > Parrot Raiser <1parr...@gmail.com <mailto:1parr...@gmail.com>> wrote: > >> After a few difficulties caused by subtly different paths and version >> identification (like -n vs .n for sub-version ids) the download and >> installation appears to have worked, but trying the REPL produced the >> following error message: >> >> "I ran into a problem while trying to set up Linenoise: Failed to open >> file >> /home/guru/rakudo/rakudo-star-2019.07.1/install/share/perl6/site/dist/91857A0CE92503F53D56DEBB6F633402878D0FF0: >> No such file or directory >> Continuing without tab completions or line editor" >> >> I assume that horrendous filename is a SHA hash if some sort. To >> whoever is involved with that part of the system, is there any chance >> of generating shorter filenames to make understanding and >> communication easier? >> > > -- > With kind regards, > > Patrick Spek > > > www: https://www.tyil.nl/ <https://www.tyil.nl/> > mail: p.s...@tyil.nl <mailto:p.s...@tyil.nl> > pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 > > social: https://soc.fglt.nl/tyil <https://soc.fglt.nl/tyil> > git:https://gitlab.com/tyil/ <https://gitlab.com/tyil/> signature.asc Description: Message signed with OpenPGP
Re: Rakudo Star 2019.07.1
Normally a user is not supposed to see the hashed name. The reason for seeing it is either an internal error or a problem with the path in the message. I would rather tend to consider the latter and recommend checking existence of the directories in the path and their permissions. Best regards, Vadim Belman > On Nov 5, 2019, at 7:15 PM, Parrot Raiser <1parr...@gmail.com> wrote: > > I'm treating this as a test of the process, reporting the problems > created, so that the process can be fixed. Merely hacking up a > solution might give me a better functioning installation, but it would > leave the problem for everyone else. > > The unfriendly filenames are really an additional issue. Ordinarily, > they shouldn't be visible to users, but they complicate reporting and > fixing. > > On 11/5/19, William Michels wrote: >> In a previous installation location, have you tried grepping for: >> "91857A0CE92503F53D56DEBB6F633402878D0FF0" >> >> ...and copying it over to your new 'dist' directory? >> (/home/guru/rakudo/rakudo-star-2019.07.1/install/share/perl6/site/dist/) >> >> The 'dist' directory appears to keep track of modules by version >> number, so I don't believe the string you posted is the "SHA1" hash >> name of the Linenoise module per se. I'm assuming this, because the >> zef command: >> >>> mbook:~ homedir$ zef --sha1 locate >>> 91857A0CE92503F53D56DEBB6F633402878D0FF0 >> >> ...fails to locate the long string you posted. >> >> I'm assuming all these file names are generated by zef. The warning >> already tells you which module the filename pertains to (Linenoise), >> so I guess I'm not understanding the problem. You can locate the your >> Linenoise module using the command below, and work from there. >> >>> mbook:~ homedir$ zef locate Linenoise >> >> HTH, Bill. >> >> REFERENCE: https://github.com/ugexe/zef >> >> >> >> >> On Tue, Nov 5, 2019 at 2:15 PM Parrot Raiser <1parr...@gmail.com> wrote: >>> >>> After a few difficulties caused by subtly different paths and version >>> identification (like -n vs .n for sub-version ids) the download and >>> installation appears to have worked, but trying the REPL produced the >>> following error message: >>> >>> "I ran into a problem while trying to set up Linenoise: Failed to open >>> file >>> /home/guru/rakudo/rakudo-star-2019.07.1/install/share/perl6/site/dist/91857A0CE92503F53D56DEBB6F633402878D0FF0: >>> No such file or directory >>> Continuing without tab completions or line editor" >>> >>> I assume that horrendous filename is a SHA hash if some sort. To >>> whoever is involved with that part of the system, is there any chance >>> of generating shorter filenames to make understanding and >>> communication easier? >>> >>> On 11/5/19, William Michels via perl6-users wrote: >>>> Thank you Patrick! >>>> >>>> On Tue, Nov 5, 2019 at 8:52 AM JJ Merelo wrote: >>>> >>>>> Thanks a lot, Patrick. >>>>> >>>>> El mar., 5 nov. 2019 a las 14:28, Patrick Spek via perl6-users (< >>>>> perl6-users@perl.org>) escribió: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I've seen people ask about 2019.07.1 in multiple avenues, myself >>>>>> included. Since there was little response, I've set out to build it >>>>>> myself. The first results have been made, with a PR on the Rakudo >>>>>> Star >>>>>> repository to fix a number of issues. >>>>>> >>>>>> Additionally, I've uploaded the 2019.07.1 tarball to my servers for >>>>>> people to test[1]. Those looking for a newer version can download >>>>>> this >>>>>> variant, and see if it works for them. If anyone spots any issues, >>>>>> please let me know, either through this mailing list, the GitHub >>>>>> repository[2] or the GitLab repository[3]. I'm trying to track all of >>>>>> these places, and try to resolve all issues people find. >>>>>> >>>>>> I plan to also release a 2019.10 version of Rakudo Star before the >>>>>> end >>>>>> of this year, but whether that's viable depends on the number of >>>>>> severity of the issues people may find. >>>>>> >>>>>> I hope we can continue the Rakudo Star releases on a regular basis in >>>>>> 2020! >>>>>> >>>>>> [1]: https://dist.tyil.nl/raku/rakudo-star/ >>>>>> [2]: https://github.com/rakudo/star >>>>>> [3]: https://gitlab.com/tyil/rakudo-star/ >>>>>> >>>>>> -- >>>>>> With kind regards, >>>>>> >>>>>> Patrick Spek >>>>>> >>>>>> >>>>>> www: https://www.tyil.nl/ >>>>>> mail: p.s...@tyil.nl >>>>>> pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 >>>>>> >>>>>> social: https://soc.fglt.nl/tyil >>>>>> git:https://gitlab.com/tyil/ >>>>>> >>>>> >>>>> >>>>> -- >>>>> JJ >>>>> >>>> >> >
Re: Dynamic export/import of symbols into global namespace
Why would you need this? Mangling with things outside of your lexical scope
isn't one of the best ideas. Perhaps, you could achieve same result with simply
exporting the subset from the module using selective export with `is
export(:tag)`?
Best regards,
Vadim Belman
> On Sep 20, 2019, at 3:32 PM, Paul Procacci wrote:
>
> As the subject suggests, I'd like to dynamically export/import symbols from a
> source file into the global scope of the program. How would one accomplish
> this?
>
> Given the below, it yields an error _which I expect_. How do I dynamically
> pull in the subset 'What'?
>
>
> File: Testing.pm6
> --
>
> subset What of Str;
> class Testing {}
>
>
>
> File: main.pl <http://main.pl/>
> --
> {
> my $c = 'Testing';
> require ::($c);
> my $t = ::($c).new;
> }
>
> my What $x = 'Blah'
>
>
> --
> __
>
> :(){ :|:& };:
Re: Wrap an attribute’s ^get_value method in TWEAK
Here is a quickly hacked together example:
multi trait_mod: (Attribute:D $a, :$xmlattr!) {
my $mname = $a.name.substr(2);
my = my method { say "ATTR($mname):", my \val = $a.get_value(self);
val };
_name($mname);
$a.package.^add_method($mname, );
}
class Foo {
has $.foo is xmlattr;
}
say Foo.new(foo => 42).foo;
It would output:
ATTR(foo):42
42
Best regards,
Vadim Belman
> On Sep 8, 2019, at 8:59 PM, Mark Devine wrote:
>
> Vadim,
>
> Vadim,
>
> Would you be able to expand on how to implement the trait that wraps into
> what is effectively the ‘get_value’ accessor of an attribute? I’m not
> finding enough in the documentation to connect the dots. I’ve looked at
> XML::Class, which does some pretty heavy trait’ing, but my intuition has
> expired.
>
> my role XML-attribute {
> has $attr;
> method get_value () {
> say 'in XML-attribute method get_value with ' ~ $.name;
> $attr;
> }
> method set_value ($) {
> say 'in XML-attribute method set_value with ' ~ $.name;
> $attr = $;
> }
> }
>
> multi sub trait_mod: (Attribute $a, :$xmlattr) {
> say "⟨is xmlattr⟩ has been called with ⟨$xmlattr⟩ on {$a.WHICH}";
> $a does XML-attribute;
> }
>
> class System {
> has Str $.SerialNumber is xmlattr;
> }
>
> say System.new(:SerialNumber('ABCDEFG')).SerialNumber;
>
>
> I’ve twisted myself into a pretzel. I couldn’t even find where a role gets
> ‘$’, but I saw it in JSTOWE’s code so I mimicked.
>
> I need a little more broad-based help on what goes where and when.
>
> Thanks,
>
> Mark
>
> From: Vadim Belman
> Sent: Sunday, September 8, 2019 14:57
> To: Mark Devine
> Cc: perl6-users
> Subject: Re: Wrap an attribute’s ^get_value method in TWEAK
>
> Hi Mark,
>
> get_value won't give you what you expect. It's use is narrowly limited to
> trait 'is handles' and method .perl. Besides, are you sure all of your
> attributes will be considered as belonging to XML? I mean, won't there be
> need for utility attributes serving exclusively internal needs of a class? If
> so, then the best solution is to create a trait for an attribute and have it
> like:
>
> has $.SerialNumber is xmlattr;
>
> The trait would then install an accessor which would do what you need.
>
> Best regards,
> Vadim Belman
>
>
> On Sep 8, 2019, at 12:41 PM, Mark Devine <mailto:m...@markdevine.com>> wrote:
>
> Perl6 Community,
>
> How do I properly wrap an attribute’s ^get_value method in TWEAK? If a
> condition exists, I’d like to wrap all (:local) attributes so that they can
> do some extra work.
>
> The module that I’m working on has classes/attributes for hundreds of fields
> in dozens of different, big XML files -- there’s a lot. And XML is easily
> extended, so I may very well be adding hundreds more attributes in the
> future. I would very much prefer to preserve the automatic accessor behavior
> of ‘has $.attr;’ versus writing a billion set/get accessors myself – truly
> prohibitive. Wrapping seems the elegant/extensible approach.
>
> class System {
> has $.SerialNumber;
> submethod TWEAK {
> for self.^attributes(:local) -> $attr {
> self.$attr.^get_value.wrap: { say 'in ' ~ $attr.name ~ "'s
> get_value"; nextsame; };
> }
> self;
> }
> }
> say System.new(:SerialNumber('ABCDEFG')).SerialNumber;
>
> # OUTPUT: No such method 'CALL-ME' for invocant of type 'Attribute'
>
> I know the above .wrap is probably misguided, but it sort of demonstrates
> what I’m trying to do.
>
> I’m not finding the proper approach. Any hints? Any tutorials? Any
> existing examples in the ecosystem that I could mimic?
>
> Thanks,
>
> Mark
Re: Wrap an attribute’s ^get_value method in TWEAK
Hi Mark,
get_value won't give you what you expect. It's use is narrowly limited to trait
'is handles' and method .perl. Besides, are you sure all of your attributes
will be considered as belonging to XML? I mean, won't there be need for utility
attributes serving exclusively internal needs of a class? If so, then the best
solution is to create a trait for an attribute and have it like:
has $.SerialNumber is xmlattr;
The trait would then install an accessor which would do what you need.
Best regards,
Vadim Belman
> On Sep 8, 2019, at 12:41 PM, Mark Devine wrote:
>
> Perl6 Community,
>
> How do I properly wrap an attribute’s ^get_value method in TWEAK? If a
> condition exists, I’d like to wrap all (:local) attributes so that they can
> do some extra work.
>
> The module that I’m working on has classes/attributes for hundreds of fields
> in dozens of different, big XML files -- there’s a lot. And XML is easily
> extended, so I may very well be adding hundreds more attributes in the
> future. I would very much prefer to preserve the automatic accessor behavior
> of ‘has $.attr;’ versus writing a billion set/get accessors myself – truly
> prohibitive. Wrapping seems the elegant/extensible approach.
>
> class System {
> has $.SerialNumber;
> submethod TWEAK {
> for self.^attributes(:local) -> $attr {
> self.$attr.^get_value.wrap: { say 'in ' ~ $attr.name ~ "'s
> get_value"; nextsame; };
> }
> self;
> }
> }
> say System.new(:SerialNumber('ABCDEFG')).SerialNumber;
>
> # OUTPUT: No such method 'CALL-ME' for invocant of type 'Attribute'
>
> I know the above .wrap is probably misguided, but it sort of demonstrates
> what I’m trying to do.
>
> I’m not finding the proper approach. Any hints? Any tutorials? Any
> existing examples in the ecosystem that I could mimic?
>
> Thanks,
>
> Mark
Re: Rakudo Star 2019.07
Hi Patrick, I think any help would be useful with it. Perhaps, you could make a ticket on https://github.com/rakudo/star/issues <https://github.com/rakudo/star/issues> with your proposals. Best regards, Vadim Belman > On Sep 3, 2019, at 3:03 AM, Patrick Spek via perl6-users > wrote: > > Hi everyone, > > I'm using Rakudo Star to get Perl 6 on my machines. However, it seems > that the latest release is 2019.03, which is half a year old by now. Is > anyone working on a 2019.07 (or different number) release right now, or > are there currently no maintainers for it? > > If it's the latter, can anyone point me to some documentation (if there > is any) on how to make a Rakudo Star release? If it's easily automated, > I can look into setting one up (at least for GNU+Linux users). > > -- > With kind regards, > > Patrick Spek > > > www: https://www.tyil.nl/ > mail: p.s...@tyil.nl > pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 > > social: https://soc.fglt.nl/tyil > git:https://gitlab.com/tyil/ signature.asc Description: Message signed with OpenPGP
Re: Naming a module that deals with the meta-object protocol
Not sure what you mean by 'leaking into CORE', but I wouldn't use Metamodel:: namespace too. My suggestion would be to use Type::SumHOW or Type::Metamodel::SumHOW. The latter is better from namespace structuring point of view unless long names disgust you. Best regards, Vadim Belman > On Apr 8, 2019, at 1:38 PM, Ben Davies wrote: > > I wrote a small sum type module that subclasses > Perl6::Metamodel::SubsetHOW. I was thinking of naming it either > Type::Sum or Metamodel::SumHOW, but Type::Sum doesn't follow the style > Rakudo uses for naming MOP classes, and Metamodel::SumHOW may not be a > good name because it'd leak the module into CORE. What should I call it? >
Re: macOS Mojave 10.14.4, Rakudo Star 2019.03.1, zef install Ddt -> Failed to change the working directory...
There are locations outside of your home dir where one can find 'his' files on any *nix-like OS. /var, /tmp among them. I tried installing Ddt on my MacBook but things went broken with License::Software module. Yet, anyway, carefully looking into your output I see that things are broken at Ddt testing stage. This pretty much excludes zef as a cause of the problem. So, the best thing to do first, as I already suggested, is to report to the module author. Next thing you could do is to force install the module without testing with --/test zef command line option. Best regards, Vadim Belman > On Apr 7, 2019, at 4:12 PM, David Christensen > wrote: > >> 6 квіт. 2019 р. о 22:28 David Christensen пише: >>> perl6-users: >>> >>> I have: >>> >>>macOS Mojave >>>Version 10.14.4 >>>MacBook Pro (Retina, 15-inch, 2015) >>> >>> >>> Today, I downloaded and installed: >>> >>>https://rakudo.org/latest/star/macos >>> >>> into my normal user account per the built-in instructions (including >>> setting PATH). >>> >>> >>> Perl 6 seems to work: >>> >>>2019-04-06 19:20:23 dpchrist@Davids-MBP ~ >>>$ perl6 --version >>>This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03 >>>implementing Perl 6.d. >>> >>> >>> But when I try to install the Ddt package with zef, it appears that zef is >>> trying to operate on system folders (?): >>> >>> 2019-04-06 19:19:34 dpchrist@Davids-MBP ~ >>> $ zef install Ddt >>> ===> Searching for: Ddt >>> ===> Updating cpan mirror: >>> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json >>> ===> Updating p6c mirror: http://ecosystem-api.p6c.org/projects1.json >>> ===> Updated cpan mirror: >>> https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json >>> ===> Updated p6c mirror: http://ecosystem-api.p6c.org/projects1.json >>> ===> Searching for missing dependencies: File::Ignore, >>> License::Software:ver<0.2.0>, Pod::To::Markdown >>> ===> Searching for missing dependencies: Pluggable >>> ===> Testing: File::Ignore >>> ===> Testing [OK] for File::Ignore >>> ===> Testing: Pluggable:ver<0.3>:auth >>> ===> Testing [OK] for Pluggable:ver<0.3>:auth >>> ===> Testing: License::Software:ver<0.2.0>:auth >>># github source https://github.com/kalkin/License-Software needs to end >>> in .git >>> ===> Testing [OK] for License::Software:ver<0.2.0>:auth >>> ===> Testing: Pod::To::Markdown:ver >>> ===> Testing [OK] for Pod::To::Markdown:ver >>> ===> Testing: Ddt:ver<0.5.5>:auth >>> Failed to change the working directory to >>> '/var/folders/r_/lk5svb150bzf2wdvp6ct_t_cgn/T/6aGzXY88az/Foo-Bar': does >>> not exist >>> in block at t/02-generate-test.t line 12 >>> >>> Failed to change the working directory to >>> '/var/folders/r_/lk5svb150bzf2wdvp6ct_t_cgn/T/3CxIelhQKl/Foo-Bar': does >>> not exist >>> in block at t/03-absent-dirs.t line 12 >>> >>> ===> Testing [FAIL]: Ddt:ver<0.5.5>:auth >>> Aborting due to test failure: Ddt:ver<0.5.5>:auth (use --force-test >>> to override) >>> >>> >>> 2019-04-06 19:20:45 dpchrist@Davids-MBP ~ >>> $ zef --version >>> v0.7.1 >>> >>> >>> Suggestions? >>> >>> >>> David > > > On 4/6/19 11:17 PM, Vadim Belman wrote: > > Hi David, > > > > Those are not system but temporary. Unfortunately, I can't check the module > > now as I'm writing from my iPad, but guessing that you should report to the > > module's author. > > > Thanks for the reply. > > > (I find it surprising that there are directories outside of /Users owned by a > normal user account, but find(1) says there are nearly two thousand (!). > Clearly, I am a macOS noob.) > > > Looking for the directory given in the error message, this is the deepest > level that currently exists: > > 2019-04-07 12:37:52 dpchrist@Davids-MBP ~ > $ ls -al /var/folders/r_/lk5svb150bzf2wdvp6ct_t_cgn/T > total 8 > drwx--@ 39 dpchrist staff 1248 Apr 7 12:40 . > drwxr-xr-x@ 5 dpchrist staff 160 Mar 15 22:14 .. > drwx-- 5 dpchrist staff 160 Apr 7 12:32 .AddressBookLocks > drwx-- 2 dpchrist staff64 Apr
Re: Roles are fundamentally broken?
Have you tried printing ^mro of $best_friend? You would be surprised! Instead,
try compiling the following:
role R1 {
method !priv { say "R1::priv" }
}
role R2 {
method !priv { say "R2::priv" }
}
class Foo does R1 does R2 {
}
Oops And this I consider a major problem. I as a developer must not care
about private methods of third-party modules. But I would have to! That's why I
want roles to be something more than mere collection of entitites mixed into a
class.
> On Jan 30, 2019, at 1:47 AM, yary wrote:
>
> > Yet, have a look at my example with private methods
>
> All of the bug reports, code excerts use regular (public) methods. Do you
> have code to share with !private_methods and/or submethods? I just made an
> example, will be at the end of this email
>
> > If accidentally two roles declare same private method – I either must
> > reject using one of them or resolve the conflict manually ...
>
> The docs say what to do if two roles declare the same regular method. I would
> expect the same to hold for private methods, and submethods- the consuming
> class would need to define its own same-named submethod or private method,
> calling the whichever role routine(s) it needs.
>
> it sounds like you'd like to have a role be able to declare some routines
> which only other methods in the role can use- not the consuming class, or any
> other role. Turns out that private methods in roles do the trick!
>
> use v6;
>
> # Turn anything into a public entertainer
> role Diva {
> method captivate () {
> say "tais toi!";
> self.
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # Learn to play
> role Violinist {
> method fiddle {
> say "got sheet music, got rosin...";
> self!bow;
> }
>
> method !bow {
> say ""
> }
> }
>
>
> # cute and playful
> class Puppy {
> method greet {
>say "";
>self!bow;
> }
>
> method !bow {
> say "Bow wow wow!"
> }
> }
>
> my $best_friend=(Puppy.new but Violinist) but Diva;
> $best_friend.greet;
> $best_friend.captivate($best_friend.^lookup('fiddle'));
>
> says
>
> Bow wow wow!
> tais toi!
> got sheet music, got rosin...
>
>
>
> I'm very happy with that behavior. Would like it to be documented.
>
> (And, I'll add comments to your bug tickets now)
> -y
Best regards,
Vadim Belman
Re: Roles are fundamentally broken?
The role must not be a class – that's true. Yet, have a look at my example with
private methods. If accidentally two roles declare same private method – I
either must reject using one of them or resolve the conflict manually... oh,
wait, I have no idea of what is that private method is all about!
Another rare but not overall impossible pattern is when one would like to have
a role method(s) be resolved with MRO. Something like:
class Foo is A is B does R is C { ... }
where re-dispatching would be able to try resolving exactly in the specified
order A -> B -> R -> C. Currently I see only two possible solutions:
- manual qualifiaction:
self.?A::method; self.?B::method; self.?R::method; self.?C::method;
- Create an intermediate dummy class which would do R:
class RClass does R { ... }
class Foo is A is B is RClass is C { ... }
In the second case we would have do something with stubs in R because RClass
would have to resolve them. And if this would require accessing private data on
Foo then the latter would have to trust RClass:
class Foo is A is B is RClass is C {
trusts RClass;
}
Doesn't it look somewhat clumsy??
Oh, and after all, we have submethods! And know what? If you have a submethod
on a Role everything is fine until same name submethod would be required by the
consuming class. In this case the class developer must know explicitly that he
has to call role's submethod and how he has to do it if the submethod is called
externally (similarly to BUILD/TWEAK been called at the construction stage). Or
the calling code must know about the existence of ^roles method and use it.
I don't want roles to become classes. But I wish they'd have more privileges
than they do now. BTW, it is even possible to have both approaches within same
paradigm by having two ways of consuming roles: either through MRO or by mixing
in. A developer could choose which one would do better in a particular
situation.
> I'm not an expert on OO programming, but my understanding of roles is that
> they make it possible to add some behaviors to a class (or to an object)
> while avoiding some of the pitfalls of inheritance, especially of multiple
> inheritance. So, even though I know about punning, I would tend to argue that
> roles are not classes (if they were, well, why would we need to have roles?.
> In fact, I tend to think that they have been designed precisely not to be
> classes and not to exhibit inheritance features, in order to avoid the
> complex dependencies that sometimes arise with inheritance, especially
> multiple inheritance and, more generally, complex inheritance trees. So, in
> this view, roles should probably not need any MRO. If you need inheritance,
> then probably use full-fledged classes. If you don't need inheritance, then,
> possibly, roles may be better suited to what you need.
>
> To me, classes are meant for managing instances and roles for managing
> behaviors and code reuse.
>
> Having said all that, I like to be able to compose some role(s) into another
> role and I have done it a couple of times without encountering any problems,
> as far as I can tell (but these were probably relatively simple cases). I
> don't really see why this should be considered as an anti pattern, although I
> can certainly feel that we should probably not try to ask too much from
> roles, the aim after all is to have something simpler than a class.
Best regards,
Vadim Belman
Re: Roles are fundamentally broken?
> On Jan 29, 2019, at 3:43 AM, Simon Proctor wrote: > > I think part of the issue is that fundamentally Roles are intended to be a > way of doing non inheritance based classes. So composing Roles from other > Roles is an anti pattern. But why? As I stated in my previous reply: isn't it constraining for the purpose of constraining? To me Perl was always TMTOWTDI in first place. The current approach to roles contradicts this principle. Best regards, Vadim Belman
Re: Roles are fundamentally broken?
> On Jan 29, 2019, at 1:32 AM, yary wrote:
>
> https://github.com/rakudo/rakudo/issues/2657
> <https://github.com/rakudo/rakudo/issues/2657> - looks like an outright bug,
> to me.
>
> I don't know about "the big picture" but you hit a not-explicitly-documented
> case.
>
> Referring to
> https://docs.perl6.org/language/objects#index-entry-declarator_role-Roles
> <https://docs.perl6.org/language/objects#index-entry-declarator_role-Roles> -
>
> When a role is applied to a class, the methods of that role are copied into
> the class. If multiple roles are applied to the same class, conflicts (e.g.
> attributes or non-multi methods of the same name) cause a compile-time error,
> which can be solved by providing a method of the same name in the class.
>
Actually this is the part which makes me unhappy. Perhaps, my thinking is
poisoned with Perl5 approach, but I don't consider copying of methods to be
sufficient. Again, I would like to see roles as entities implementing some well
defined behavior. Having them as limited as just a collection of
methods/attributes doesn't make them capable of such job. This is, perhaps, the
only issue of Perl6 which makes me unhappy.
> I'd like it if roles disambiguated same-name application just as classes did.
> Which means, the role they are applied to must have a role with the same name
> explicitly calling the methods it wants- compile time error otherwise. Roles
> would never participate in MRO, because their "flatness" part of their
> attractiveness - there's no guessing which role is providing a method, any
> potential name clash is averted by requiring calling out the role or class
> providing the desired semantics.
Why is it good for roles but not for classes? Would a particular resolution is
ever be needed then class/role-qualified calls are always at our disposal. Yet,
with current design a programmer discovers the need for the resolution (when
using 3rd-party roles) in a hard way – by learning the error messages unless
one could remember all the public methods declared.
Ok, let's assume that public methods must be remembered. But private? The
resolving rule apply to them too! How do I know how they must be resolved
without studying the internals of somebody's code? Which could happen to be
quite complicated! Yet, as a developer, I would expect a private method to be
my method which I can rely upon; and yet – this is not the case.
Unfortunately, I can't instantly recall a couple of other problems I had with
roles previously. In one case I eventually ended up converting to an abstract
class – i.e. instead of declaring method stubs I had to die inside them. There
was simply no other solution which would use role semantics.
This is the whole point of my message. The bugs? They'll be fixed eventually.
Though for me it would be too late perhaps and my code would use another route
to the target. But the fundamental issue will remain: the language has an
entity with artificially limited functionality "because it's conceptually
right". BTW, I consider this a very Java/Python/Pascal way: constraining for
constraining and to dictate the developer the right ways of doing things.
>
> Through that lens, my thoughts on
> https://github.com/rakudo/rakudo/issues/2282
> <https://github.com/rakudo/rakudo/issues/2282> - ought to run without error
> https://github.com/rakudo/rakudo/issues/2496
> <https://github.com/rakudo/rakudo/issues/2496> - my edits/comments
> role X{ method f { say "f" } }
> role Y does X { method g { say "g" } }
> class C does Y {}
>
> C.new.Y::g; # works
> C.new.Y::f; # works
> C.new.X::f; # LTA error. But with roles doing "flat" copying don't have an
> expectation that C knows the name "X",
> # I only expect that C can call method f which it got from Y, and that did
> work.
This looks reasonable. I would suggest you commenting on the bug report. It
would be useful to both the reporter and a core developer who's gonna consider
the report.
Best regards,
Vadim Belman
Roles are fundamentally broken?
Hi all, I have filled another role-related issue today. While the issue is just another bug in the compiler, it stems from the thing which I consider to be a big problem about what a Role is in Perl6. Or, more precisely, from the fact that Role is an entity deprived of its civil rights. What functionality would I expect from a Role? Two things: 1. Define interfaces 2. Define abstract behaviors What Perl6 is currently providing me with? Interfaces – ok; behaviors – only partially. For example, there is no guarantee that a BUILD or TWEAK submethod defined in a Role would ever be run, unless a class does special measures to ensure them be executed. What I expect a Role to be? Perhaps, more of a degraded Class in a way that roles would be able to participate in MRO resolution, for example. In a way that roles must be able to participate in object initialization process equally to classes; after all, isn't this a part of object behavior too? If somebody would like to object by saying that "Role isn't a Class" then think about punning first. Not to mention the ability of declaring per-role 'our' objects which is not critical but would be handy sometimes. Having the roles to be so special seemingly causes lots of unwanted side effects and bugs. For example, https://github.com/rakudo/rakudo/issues/2657, https://github.com/rakudo/rakudo/issues/2496, and https://github.com/rakudo/rakudo/issues/2282 just wouldn't exists with roles being part of MRO. An attribute object would probably have its .package attribute set correctly. And couple of other issues. Basically, at this moment I consider carefully if I need a role or there is another way to implement something. Because what is known for sure now: there will be problems, sooner or later! Maybe somebody could explain clearly why things are the way they are now. I would be very thankful for such information. Perhaps I need a tectonic shift in my understanding of this area. But currently roles are the only thing which really disappoints me in the language design. Best regards, Vadim Belman
Re: POD: linking to a module
I'm not sure if I can jump on that train yet. Lack of time forces me to focus on own project as much as possible. While I could participate in discussions about the format, github support is yet beyond my abilities. > On Jan 16, 2019, at 4:41 PM, Ralph Mellor wrote: > > Hi JJ, > Wouldn't it be useful if Vadim commented on an appropriate GH issue? > If so, which would that be? > https://github.com/perl6/user-experience/issues/35 > <https://github.com/perl6/user-experience/issues/35> ? > https://github.com/perl6/Pod-To-HTML/issues/55 > <https://github.com/perl6/Pod-To-HTML/issues/55> ? > https://github.com/perl6/doc/issues/167 > <https://github.com/perl6/doc/issues/167> ? > Somewhere else? > > -- > raiph > > On Mon, Jan 14, 2019 at 1:07 AM Vadim Belman <mailto:vr...@lflat.org>> wrote: > > >> >> Not to mention different module versions, on top of what you wrote. >> >> Ok, I would think about it. One thing comes to my mind: in Synopsis 26 >> (https://design.perl6.org/S26.html <https://design.perl6.org/S26.html>) >> there is a mention of =config directive. It can be used to define where the >> links must point to. Something like: >> >> =config github:/user/module/tree/master/docs >> >> I'm not sure =config is implemented right now, my money is on NYI. And still >> there's the problem that pod6 or pod-embedded-in-Perl6 is not rendered >> anywhere, I think, not even in modules.perl6.org >> <http://modules.perl6.org/>. Dumping someone in a page full of Pod6 source >> code is LTA. I mean, you can as well create a link to actual, rendered >> documents that you have generated somewhere. > > I know it is not implemented, but it might be at some point. So, perhaps it > makes sense to think out a possible solution? > > As to the format issue – I for myself solved it for now by generating both > .md and .html and writing a script which patches source PODs to point links > at the right version tag on github. Perhaps, this will be the best approach > for a couple of years to come. > > Best regards, > Vadim Belman > Best regards, Vadim Belman
Re: POD: linking to a module
> > Not to mention different module versions, on top of what you wrote. > > Ok, I would think about it. One thing comes to my mind: in Synopsis 26 > (https://design.perl6.org/S26.html <https://design.perl6.org/S26.html>) there > is a mention of =config directive. It can be used to define where the links > must point to. Something like: > > =config github:/user/module/tree/master/docs > > I'm not sure =config is implemented right now, my money is on NYI. And still > there's the problem that pod6 or pod-embedded-in-Perl6 is not rendered > anywhere, I think, not even in modules.perl6.org <http://modules.perl6.org/>. > Dumping someone in a page full of Pod6 source code is LTA. I mean, you can as > well create a link to actual, rendered documents that you have generated > somewhere. I know it is not implemented, but it might be at some point. So, perhaps it makes sense to think out a possible solution? As to the format issue – I for myself solved it for now by generating both .md and .html and writing a script which patches source PODs to point links at the right version tag on github. Perhaps, this will be the best approach for a couple of years to come. Best regards, Vadim Belman
Re: POD: linking to a module
Not to mention different module versions, on top of what you wrote. Ok, I would think about it. One thing comes to my mind: in Synopsis 26 (https://design.perl6.org/S26.html) there is a mention of =config directive. It can be used to define where the links must point to. Something like: =config github:/user/module/tree/master/docs > On Jan 12, 2019, at 2:47 AM, JJ Merelo wrote: > > Actually, we had that functionality, but it was recently eliminated by > Richard Hainsworth since, as a matter of fact, there are no specs on what to > actually do with them. And it was eliminated for several reasons, one of > which is that MetaCPAN does not display Pod6, but the main reason is that > there's no canonical place for module documentation. Some of them are in > docs.perl6.org <http://docs.perl6.org/> (core modules), some of them in > github, some in gitlab... > > Any suggestion is welcome, meanwhile. > > El sáb., 12 ene. 2019 a las 2:22, Vadim Belman ( <mailto:vr...@lflat.org>>) escribió: > Hello, > > How do I properly write a link to a module in a POD documentation? Actually, > the question is even more complex as it might be both a module and a .pod. > > The documentation (https://docs.perl6.org/language/pod > <https://docs.perl6.org/language/pod>) isn't clear on this subject. When it > comes to `L<>` docs are mostly focused on URL or intra-page links. Well, of > course I can pre-generate .md and link to a github page. But hoping that at > some point the modules site will gain functionality similar to metacpan and > will be able to display embedded PODs as pages I'd like to keep this in mind > and do things correctly from the start. Besides, by linking to github I would > also have to always keep in mind updating links to have them pointing at the > correct module version which might be problematic with a big number of links. > > BTW, neither I found a way to generate different content for different output > formats. > > Best regards, > Vadim Belman > > > -- > JJ Best regards, Vadim Belman
POD: linking to a module
Hello, How do I properly write a link to a module in a POD documentation? Actually, the question is even more complex as it might be both a module and a .pod. The documentation (https://docs.perl6.org/language/pod) isn't clear on this subject. When it comes to `L<>` docs are mostly focused on URL or intra-page links. Well, of course I can pre-generate .md and link to a github page. But hoping that at some point the modules site will gain functionality similar to metacpan and will be able to display embedded PODs as pages I'd like to keep this in mind and do things correctly from the start. Besides, by linking to github I would also have to always keep in mind updating links to have them pointing at the correct module version which might be problematic with a big number of links. BTW, neither I found a way to generate different content for different output formats. Best regards, Vadim Belman
Re: Slangs: extending package_declarator problem
Anyway, just after I sent the question a thing crossed my mind it happened to
be a (or the) solution to the problem: the modified grammar has to be applied
to $*LANG alongside with the MAIN slang. But then again, this is what I learned
from add_package_declarator with only vague idea of why it works. Yet, I still
need a confirmation that this is the correct approach either in a form of
extended testing or by a confirmation from an expert.
I know that I'm diggin' in areas, where I don't even have enough expertise. Or,
ad timotimo put is, I'm "operating at the edge of known science". But that is
really the only way to achieve my goal – make things simpler for the user and
the final code more readable by hiding as much as possible under the hood of
the implementation module.
> On Dec 26, 2018, at 7:47 AM, Elizabeth Mattijsen wrote:
>
> This feels like you’re getting into the bleeding edges of MOP. My
> understanding is that a MVMContext is purely a runtime thing. Not sure how
> it comes to be that the MVMContext needs serializing, but that error message
> indicates that the VM is not ready to do that.
>
> So my guess is that somehow during compilation, the MVMContext gets added to
> the SC (Serialization Context) when it shouldn’t.
>
> Most likely Timo Paulssen or Jonathan Worthington can give you better answers.
>
>> On 26 Dec 2018, at 04:26, Vadim Belman wrote:
>>
>> Hi!
>>
>> By playing with slangs I stumbled upon pretty confusing issue. I have a
>> module with a test slang which looks like this:
>>
>> class My::Metamodel::MyHOW is Metamodel::ClassHOW {
>> method compose (|) {
>> note "My compose";
>> nextsame;
>> }
>> }
>>
>> sub EXPORT {
>> use nqp;
>> use NQPHLL:from;
>>
>> my role MySlang {
>> token package_declarator:sym {
>> :my $*OUTERPACKAGE := self.package;
>> :my $*PKGDECL := 'myclass';
>> :my $*LINE_NO := HLL::Compiler.lineof(self.orig(),
>> self.from(), :cache(1));
>> <.kok>
>>
>> <.set_braid_from(self)>
>> }
>> }
>>
>> my role MyActions {
>> method package_declarator:sym(Mu $/) {
>> $/.make( nqp::atkey(nqp::findmethod($/, 'hash')($/),
>> 'package_def').ast );
>> }
>> }
>> $ = $*LANG.refine_slang( 'MAIN', MySlang, MyActions );
>> $*LANG.set_how('myclass', My::Metamodel::MyHOW);
>> {}
>> }
>>
>> And when it's used in a script:
>>
>> use lib '.';
>> use myslang;
>>
>> myclass My {
>> method foo { say "!foo" }
>> }
>>
>> My.new.foo;
>>
>> everything works as expected, I get this output:
>>
>>My compose
>>!foo
>>
>> Then I define a module smodule.pm6:
>>
>> use myslang;
>>
>> myclass Foo {
>> }
>>
>> And load it dynamically with 'require':
>>
>>require ::('smodule');
>>
>> only to get this:
>>
>> My compose
>>===SORRY!===
>>Missing serialize REPR function for REPR MVMContext (BOOTContext)
>>
>> Now I wonder if it's a bug or I'm missing a thing or two in what I'm doing?
>> So far, basic guidelines of adding a new package type were taken from
>> World.nqp add_package_declarator method which does some extra work some of
>> which is clearly not needed in my case; and some perhaps necessary but I
>> don't understand it yet.
>>
>> Best regards,
>> Vadim Belman
>>
>
Best regards,
Vadim Belman
Slangs: extending package_declarator problem
Hi!
By playing with slangs I stumbled upon pretty confusing issue. I have a module
with a test slang which looks like this:
class My::Metamodel::MyHOW is Metamodel::ClassHOW {
method compose (|) {
note "My compose";
nextsame;
}
}
sub EXPORT {
use nqp;
use NQPHLL:from;
my role MySlang {
token package_declarator:sym {
:my $*OUTERPACKAGE := self.package;
:my $*PKGDECL := 'myclass';
:my $*LINE_NO := HLL::Compiler.lineof(self.orig(),
self.from(), :cache(1));
<.kok>
<.set_braid_from(self)>
}
}
my role MyActions {
method package_declarator:sym(Mu $/) {
$/.make( nqp::atkey(nqp::findmethod($/, 'hash')($/),
'package_def').ast );
}
}
$ = $*LANG.refine_slang( 'MAIN', MySlang, MyActions );
$*LANG.set_how('myclass', My::Metamodel::MyHOW);
{}
}
And when it's used in a script:
use lib '.';
use myslang;
myclass My {
method foo { say "!foo" }
}
My.new.foo;
everything works as expected, I get this output:
My compose
!foo
Then I define a module smodule.pm6:
use myslang;
myclass Foo {
}
And load it dynamically with 'require':
require ::('smodule');
only to get this:
My compose
===SORRY!===
Missing serialize REPR function for REPR MVMContext (BOOTContext)
Now I wonder if it's a bug or I'm missing a thing or two in what I'm doing? So
far, basic guidelines of adding a new package type were taken from World.nqp
add_package_declarator method which does some extra work some of which is
clearly not needed in my case; and some perhaps necessary but I don't
understand it yet.
Best regards,
Vadim Belman
Tricks: class cloning
Hi!
Another question to improve understanding of Perl6 internals.
Let's say, I've got an idea of allowing a user to define a 'template' class.
I.e. it wouldn't be used directly, but I could be used as a base for creating a
new one (or a couple of new ones – it would depend). Basically, what is needed
to perform this operation is to create the new class, then copy
methods/attributes from the template and then set those properties I would need
(like parent class, for example). The following code even do some of the job:
class Foo {
...
method foo { ... }
}
my \type = Metamodel::ClassHOW.new_type( name => 'Foo-clone' );
for Foo.^methods(:local) -> $m {
next if $m.?is-hidden-from-backtrace;
type.^add_method( $m.name, $m.clone );
}
type.^compose;
my $inst = type.new;
$inst.foo;
Except that that .foo cannot be called on Foo-clone because it has an implicit
constraint Foo:D for 'self'. I tried re-compose the method signature and pass
it to method's clone:
$m.clone( :$signature );
but ended up with 'unexpected named parameter' error. So far, this is where I
stuck and would like to know if there is a workaround for this?
Basically, what I'm trying to achieve is could also be done by using a role as
a template which could then be applied to the custom class. But roles has a few
restrictions which would make them less flexible.
Best regards,
Vadim Belman
Re: Performance of parallel computing.
You're damn right here. First of all, I must admit that I've misinterpreted the benchmark results (guilty). Yet, anyway, I think I know what's really happening here. To make things really clear I ran the benchmark for all number of workers from 1 to 9. Here is a cleaned up output: Timing 1 iterations of worker1, worker2, worker3, worker4, worker5, worker6, worker7, worker8, worker9... worker1: 22.125 wallclock secs (22.296 usr 0.248 sys 22.544 cpu) @ 0.045/s (n=1) worker2: 12.554 wallclock secs (24.221 usr 0.715 sys 24.936 cpu) @ 0.080/s (n=1) worker3: 9.330 wallclock secs (25.708 usr 1.316 sys 27.024 cpu) @ 0.107/s (n=1) worker4: 8.221 wallclock secs (28.151 usr 2.676 sys 30.827 cpu) @ 0.122/s (n=1) worker5: 7.131 wallclock secs (30.395 usr 3.658 sys 34.053 cpu) @ 0.140/s (n=1) worker6: 7.180 wallclock secs (34.496 usr 4.479 sys 38.975 cpu) @ 0.139/s (n=1) worker7: 7.050 wallclock secs (38.267 usr 5.453 sys 43.720 cpu) @ 0.142/s (n=1) worker8: 6.668 wallclock secs (41.607 usr 5.586 sys 47.194 cpu) @ 0.150/s (n=1) worker9: 7.220 wallclock secs (46.762 usr 11.647 sys 58.409 cpu) @ 0.139/s (n=1) O-O--O-O | | s/iter | worker1 | O=O==O=O | worker1 | 22125229 | -- | | worker2 | 12554094 | 76% | | worker3 | 9329865 | 137%| | worker4 | 8221486 | 169%| | worker5 | 7130758 | 210%| | worker6 | 7180343 | 208%| | worker7 | 7049935 | 214%| | worker8 | 6667794 | 232%| | worker9 | 7219864 | 206%| The plateau is there but it's been reached even before we ran out of all the available cores: 5 workers takes all of the CPU power already. Yet, the speedup achieved is really much less that it'd expected... But then I realized that there is another player on the field: throttling. And that actually makes any other measurements useless on my notebook. This is also an answer to Parrot's suggestion about possible caches involvement: that's not it, for sure. Especially if we take into account that the numbers were +/- the same on every benchmark run. > On Dec 7, 2018, at 12:04, yary wrote: > > OK... going back to the hypothesis in the OP > >> The plateau is seemingly defined by the number of cores or, more correctly, >> by the number of supported threads. > > This suggests that the benchmark is CPU-bound, which is supported by > your more recent observation "100% load for a single one" > > Also, you mentioned running MacOS with two threads per core, which > implies Intel's hyperthreading. Depending on the workload, CPU-bound > processes sharing a hyperthreaded core see a speedup of 0-30%, as > opposed to running on separate cores which can give a speedup of 100%. > (Back when I searched for large primes, HT gave a 25% speed boost.) So > with 6 cores, 2 HT per core, I would expect a max parallel boost of 6 > * (1x +0.30x) = 7.8x - and your test is only giving half that. > > -y > Best regards, Vadim Belman
Performance of parallel computing.
Hi everybody!
I have recently played a bit with somewhat intense computations and tried to
parallelize them among a couple of threaded workers. The results were
somewhat... eh... discouraging. To sum up my findings I wrote a simple demo
benchmark:
use Digest::SHA;
use Bench;
sub worker ( Str:D $str ) {
my $digest = $str;
for 1..100 {
$digest = sha256 $digest;
}
}
sub run ( Int $workers ) {
my $c = Channel.new;
my @w;
@w.push: start {
for 1..50 {
$c.send(
(1..1024).map( { (' '..'Z').pick } ).join
);
}
LEAVE $c.close;
}
for 1..$workers {
@w.push: start {
react {
whenever $c -> $str {
worker( $str );
}
}
}
}
await @w;
}
my $b = Bench.new;
$b.cmpthese(
1,
{
workers1 => sub { run( 1 ) },
workers5 => sub { run( 5 ) },
workers10 => sub { run( 10 ) },
workers15 => sub { run( 15 ) },
}
);
I tried this code with a macOS installation of Rakudo and with a Linux in a VM
box. Here is macOS results (6 CPU cores):
Timing 1 iterations of workers1, workers10, workers15, workers5...
workers1: 27.176 wallclock secs (28.858 usr 0.348 sys 29.206 cpu) @ 0.037/s
(n=1)
(warning: too few iterations for a reliable count)
workers10: 7.504 wallclock secs (56.903 usr 10.127 sys 67.030 cpu) @ 0.133/s
(n=1)
(warning: too few iterations for a reliable count)
workers15: 7.938 wallclock secs (63.357 usr 9.483 sys 72.840 cpu) @ 0.126/s
(n=1)
(warning: too few iterations for a reliable count)
workers5: 9.452 wallclock secs (40.185 usr 4.807 sys 44.992 cpu) @ 0.106/s
(n=1)
(warning: too few iterations for a reliable count)
O---O--O--O---O---O--O
| | s/iter | workers1 | workers10 | workers15 | workers5 |
O===O==O==O===O===O==O
| workers1 | 27176370 | -- | -72% | -71% | -65% |
| workers10 | 7503726 | 262% | --| 6%| 26% |
| workers15 | 7938428 | 242% | -5% | --| 19% |
| workers5 | 9452421 | 188% | -21% | -16% | -- |
--
And Linux (4 virtual cores):
Timing 1 iterations of workers1, workers10, workers15, workers5...
workers1: 27.240 wallclock secs (29.143 usr 0.129 sys 29.272 cpu) @ 0.037/s
(n=1)
(warning: too few iterations for a reliable count)
workers10: 10.339 wallclock secs (37.964 usr 0.611 sys 38.575 cpu) @ 0.097/s
(n=1)
(warning: too few iterations for a reliable count)
workers15: 10.221 wallclock secs (35.452 usr 1.432 sys 36.883 cpu) @ 0.098/s
(n=1)
(warning: too few iterations for a reliable count)
workers5: 10.663 wallclock secs (36.983 usr 0.848 sys 37.831 cpu) @ 0.094/s
(n=1)
(warning: too few iterations for a reliable count)
O---O--O--O--O---O---O
| | s/iter | workers5 | workers1 | workers15 | workers10 |
O===O==O==O==O===O===O
| workers5 | 10663102 | -- | 155% | -4% | -3% |
| workers1 | 27240221 | -61% | -- | -62% | -62% |
| workers15 | 10220862 | 4% | 167% | --| 1%|
| workers10 | 10338829 | 3% | 163% | -1% | --|
--
Am I missing something here? Do I do something wrong? Because it just doesn't
fit into my mind...
As a side done: by playing with 1-2-3 workers I see that each new thread
gradually adds atop of the total run time until a plato is reached. The plato
is seemingly defined by the number of cores or, more correctly, by the number
of supported threads. Proving this hypothesis wold require more time than I
have on my hands right now. And not even sure if such proof ever makes sense.
Best regards,
Vadim Belman
LEAVE/CATCH/return weirdness
Hi,
Let me start with a sample which resembles some real code in my project:
sub bar ( $v ) {
die "don't like it" if $v == 3;
LEAVE (1..2).map: { "ok" };
"[" ~ $v ~ "]"
}
sub foo ( $v --> Str ) {
my $str = bar( $v );
CATCH {
default {
return "«oops»";
}
}
$str
}
sub foobar {
return [~] (1..10).map: {
foo( $_ );
};
}
say foobar;
With this I get the error:
Type check failed for return value; expected Str but got Int (1)
in sub foo at ./fail.p6 line 16
in sub foobar at ./fail.p6 line 21
in block at ./fail.p6 line 25
When LEAVE is commented out I get the expected output:
[1][2]«oops»[4][5][6][7][8][9][10]
Somehow LEAVE substitutes return value from CATCH with 1. What's even more
confusing is that I have no idea where this 1 is coming from!
Moreover, in real code LEAVE belongs to a sub which is one level deeper down
the stack and is been called from bar(). The effect is the same: I get 1
instead of «oops». Further investigation pinned down this miraculous phenomenon
to .map. Any other code within LEAVE, including 'for' loop, makes the whole
thing to work as expected.
I'm strongly convinced that what is observed is a bug. But before reporting it
I'd like to make sure that there is nothing about .map that I don't know about
and that makes the code behave so strange.
Best regards,
Vadim Belman
Re: Run tests only if a module is available
Hi, So far, the only potential solution for you issue would be Test::When. But the needed functionality was declared as 'soon to be implemented' and is not there yet. Perhaps, if you convince Zoffix Znet to complete it... > 11 жовт. 2018 р. о 13:08 Fernando Santagata > написав(ла): > > Hello, > > I wish to run some tests on one module of mine only if there's a certain > third-party module available during installation. > Before I concocted something horrid using try/catch in the INIT phaser, is > there any gentle way to do this? > > Thanks! > > -- > Fernando Santagata Best regards, Vadim Belman
Re: metamorphosis or alchemy?
Actually what I meant was
my Real $x = 3; $x = Nil; $x.WHO.say
What you must read undoubtedly are this:
https://docs.perl6.org/language/containers
<https://docs.perl6.org/language/containers> and this:
https://opensource.com/article/18/8/containers-perl-6
<https://opensource.com/article/18/8/containers-perl-6>
> 16 вер. 2018 р. о 22:31 ToddAndMargo написав(ла):
>
>>>> 16 вер. 2018 р. о 22:11 Curt Tilmes >>> <mailto:c...@tilmes.org>> написав(ла):
>>>>
>>>> It isn't changing anything.
>>>>
>>>> You've still got a box ('container') that can only hold something 'Real'.
>>>>
>>>> You just happen to have a value in that box that is a 'Rat'.
>>>>
>>>> It is perfectly fine to put a Rat value in a Real box, because a Rat is
>>>> also a Real (does the 'Real' role).
>>>>
>>>> You can still stick some other Real in the box, and you still can't stick
>>>> anything that isn't a Real in the box.
>>>>
>>>>
>>>>
>>>> On Sun, Sep 16, 2018 at 10:07 PM ToddAndMargo >>> <mailto:toddandma...@zoho.com>> wrote:
>>>>
>>>>On 09/16/2018 06:50 PM, Curt Tilmes wrote:
>>>>> Note that an object that is a Rat also does Real (see
>>>>> https://docs.perl6.org/type/Rat#Type_Graph)
>>>>>
>>>>> say Rat ~~ Real
>>>>>
>>>>> True
>>>>>
>>>> > Your're making a box that takes a Real, then putting a Rat (that
>>>>also does Real) into that box.
>>>>>
>>>>> It then says "yes, you've got a Rat in there".
>>>>>
>>>>>
>>>>
>>>>Why is it changing thing on the fly when I tell it not to?
>>>> I claim foul !!AA HHH !!!
>>>>
>>> Best regards,
>>> Vadim Belman
>
> On 09/16/2018 07:18 PM, Vadim Belman wrote:
>> I would add on top of Curt's explanation. Try assigning Nil to $x and then
>> ask for its type. You'll get your Real back!
>
>
>
> I am see it but I am not seeing your point:
>
> $ p6 'my Real $x= Nil; dd $x;'
> Real $x = Real
>
> $ p6 'my Real $x= Nil; $x = 3.1415; dd $x;'
> Rat $x = 3.1415
>
> Why is it changing the type on the fly after
> I defined it?
>
Best regards,
Vadim Belman
Re: Rat
You're messing up a type and a method to convert into that type. For example, dd "1.2".Rat will output you a rational whereas dd "1.2" will output a string. Again, search for Rat on docs gives you a line just under the Class section. > 16 вер. 2018 р. о 22:29 ToddAndMargo написав(ла): > > Hi All, > > What in the world are they trying to say here? > > https://docs.perl6.org/routine/Rat >(Numeric) method Rat > >method Rat(Numeric:D: Real $epsilon = 1.0e-6 --> Rat:D) > >If this Numeric is equivalent to a Real, return a Rat which >is within $epsilon of that Real's value. Fail >with X::Numeric::Real otherwise. > > And is this why I can not find a type "Rat"? Because > it is a method? > > Then why does >$ p6 'my Real $x; $x = 3.1415; dd $x;' > Rat $x = 3.1415 > say it is a type "Rat"? > > > Yours in confusion, > -T > Best regards, Vadim Belman
Re: metamorphosis or alchemy?
Actually, typing 'dd' in the searchbox on docs.perl6.org <http://docs.perl6.org/> gives you a long list with dd in 'Reference' section of that list. > > https://docs.perl6.org/routine/dd > 404: Page Not Found > > Search does not work either. > Best regards, Vadim Belman
Re: metamorphosis or alchemy?
I would add on top of Curt's explanation. Try assigning Nil to $x and then ask
for its type. You'll get your Real back!
> 16 вер. 2018 р. о 22:11 Curt Tilmes написав(ла):
>
> It isn't changing anything.
>
> You've still got a box ('container') that can only hold something 'Real'.
>
> You just happen to have a value in that box that is a 'Rat'.
>
> It is perfectly fine to put a Rat value in a Real box, because a Rat is also
> a Real (does the 'Real' role).
>
> You can still stick some other Real in the box, and you still can't stick
> anything that isn't a Real in the box.
>
>
>
> On Sun, Sep 16, 2018 at 10:07 PM ToddAndMargo <mailto:toddandma...@zoho.com>> wrote:
> On 09/16/2018 06:50 PM, Curt Tilmes wrote:
> > Note that an object that is a Rat also does Real (see
> > https://docs.perl6.org/type/Rat#Type_Graph
> > <https://docs.perl6.org/type/Rat#Type_Graph>)
> >
> > say Rat ~~ Real
> >
> > True
> >
> > Your're making a box that takes a Real, then putting a Rat (that also does
> > Real) into that box.
> >
> > It then says "yes, you've got a Rat in there".
> >
> >
>
> Why is it changing thing on the fly when I tell it not to?
> I claim foul !!AA HHH !!!
Best regards,
Vadim Belman
Re: need p5/p6 :: help
> > In Perl 6 culture we never mix them up either, but we also never put subs > into packages by default. The reason Foo::bar notation doesn't work is > because bar isn't in Foo anymore unless you explicitly put it there. > > Larry > Though technically this aspect was clear to me, but to settle things down in my mind completely: for now ordinary (not 'our') sub belongs not to the package object but to the block which belongs to that package. Is it correct way to describe things? Best regards, Vadim Belman
Re: how do I do this index in p6?
Of course constants! constant ACONST = pi; constant $SCONST = "aaa"; Even constant @a = [1,2,3]; though it doesn't affect the actual array content making '@a = []' possible due to the way '=' works in the array context. But constant @a = <1 2 3>; works as expected. I could leave it as a homework for you to find out why! A tip which you wouldn't find in the documentation: '=' in array context does element-by-element assign to the left hand array. > 11 вер. 2018 р. о 20:17 ToddAndMargo написав(ла): > > On 09/11/2018 08:11 AM, yary wrote: >> "Nil... it's a constant, so you have to use =:= to check for equality." > > Constants? I thought we did not have constants! Am I mixing > Perl 5 with Perl 6, again? > Best regards, Vadim Belman
Re: RFE: contains documentation
You're pretty much mistaken here. No documentation can replace a good book. No documentation is capable of providing enough in-depth understanding of The Concept. I am a sleepy kind of person too. But I managed to get through Perl6 Deep Dive by Andrew Shitov in the only possible way: having the book on my iPad and Vim on my notebook. Now I'm considering giving a try to the recently released Learning Perl6 book – as soon as will have any time for this. > 7 вер. 2018 р. о 22:38 ToddAndMargo написав(ла): > > On 09/07/2018 06:25 PM, Curt Tilmes wrote: >> The documentation isn't a tutorial, but is still improving every day. > > For the function it is documenting, it had better be > a tutorial. Otherwise, why would anyone other than a > developer seek its input? Seriously. If you can't > figure it out from the documentation, why bother > with the documentation. > > > Thank you for the book recommendation. I don't do well with > books. I can't stay awake. Head hits the table. > I have to just go and write what I need. Then I learn. Best regards, Vadim Belman
Re: date conversions?
I was once looking for strftime and stumbled over https://gist.github.com/salortiz/051c7a81400522e30a7cf12377c02f70 and https://github.com/supernovus/perl6-datetime-format My choice was in favor of DateTime::Format though. Anyway, often googling with 'perl6 ' might provide one with even more information than expected! > 7 вер. 2018 р. о 18:36 ToddAndMargo написав(ла): > > Hi All, > > I want to convert "2018 Jun 7" into 2018.06.07". > I know I can do this myself, but is there a utility > already written for this? > > https://docs.perl6.org/routine/Date > does not seem to enlighten me. > > Many thanks, > -T > > > -- > ~~ > Computers are like air conditioners. > They malfunction when you open windows > ~~ > Best regards, Vadim Belman
Re: use Moo:from;
> 1. There is currently a bug (or bugs) about wrapped methods – > https://github.com/rakudo/rakudo/issues/2178 > <https://github.com/rakudo/rakudo/issues/2178> > get_value() is unlikely to be wrapped. But potential issues are possible as > it seems that the bug is not only related to method inheritance. > Oops, correction: "get_value() is unlikely to be inherited". Sorry. Best regards, Vadim Belman
Re: use Moo:from;
Here is the problematic points of your code:
1. There is currently a bug (or bugs) about wrapped methods –
https://github.com/rakudo/rakudo/issues/2178
get_value() is unlikely to be wrapped. But potential issues are possible as it
seems that the bug is not only related to method inheritance.
2. set_value() does not what you expect it to do. Actually, you're replacing
attribute's container. Congratulations, now you have untyped attribute! ;) You
could workaround the problem by cloning $.auto_viv_container but I foreseen
side-effects with array and hash attributes.
3. This approach doesn't let clear/trigger/predicate to exists. While the first
two are possible (just don't restore the wrapped get_value and continue to
intercept fetch operations), predicate won't work properly because it must
signal about any store done, including Nil. In other words, there must be a
flag of some kind signaling that attribute was written into.
4. Build must not be called if value was set. And this is where it call comes
to a really surprising point: set_value() is not used to set attribute. As a
matter of fact, it just never used – try grepping the source. There is one
declaraion in moar's CORE.setting and one in Attribute.pm6.
So far, what you've done is similar to my first steps on this road... ;)
> 6 вер. 2018 р. о 04:29 Simon Proctor написав(ла):
>
> Done a bit of noodling about this morning and I got this. And it works
> sort of.
>
> .perl calls the get_value method but the accessor and private value reads
> don't. (I'm guessing this is what you came up against Vadim?)
>
> Still the self deleting wrapper is a fun trick. Best I do some work now
> though.
>
> use v6.c;
>
> role LazyAttr {
> has $.get-wrapper is rw;
> }
>
> multi sub trait_mod: ( Attribute $a, :@lazy [ ] ) {
> $a does LazyAttr;
>
> $a.set_build(
> -> |c {
> $a.get-wrapper = $a.^find_method('get_value').wrap(
> -> $self, $instance {
> my $val = ( $instance );
> $a.set_value( $instance, $val );
> $a.get-wrapper.restore;
> $val;
> }
> );
> Any;
> }
> );
> }
>
> class Test {
>
> sub build-a( $self ) { note "Build A Called"; sleep 1; 5 }
> sub build-b( $self ) { note "Build B Called"; sleep 2; 10 }
>
> has $.a is lazy[];
> has $.b is lazy[];
> }
>
> my $t = Test.new();
>
> say $t.perl;
>
> On Wed, 5 Sep 2018 at 23:45 Vadim Belman <mailto:vr...@lflat.org>> wrote:
> Looking forward to see what you come up with. I do mix in a role into both
> Attribute and ClassHOW. But delving into the core didn't help to find a
> better approach than the one I finally took. Two subtle aspects are to be
> kept in mind: support for roles; and knowing the object attribute is
> belonging to.
>
> > So I have a thought for how to do lazy attributes without Proxy objects. It
> > is late so I'll try and poke about at it tomorrow but I think we can Mixin
> > a role to the Attribute using a trait.
> >
> > The role will track if the attribute was set to a value at build and if not
> > call a block it's given when first read from. This gets round the issue of
> > if we want to set it to Any.
> >
> > I *think* this will work. The stuff I've been doing with Trait::Env would
> > point that way.
> >
>
> Best regards,
> Vadim Belman
>
> --
> Simon Proctor
> Cognoscite aliquid novum cotidie
Best regards,
Vadim Belman
