Re: Any sign of a fix for the 10 second compile time?
Todd What you are asking for is not a bug, but a part of the current stage of design. It will probably get quicker. However, the biggest part of the timing is the compilation - as you have noticed. When you precompile a module, it stores the byte code. Then it runs quite well. Now it IS possible to set up a precomp store of your own, but isn't worth the hassle. zef does all of that for you. So the best thing is to find a way to get zef to install your modules. Naturally if you change anything in them, you will need to bump the version number in the META6.json file and then reinstall. Failure problems with zef, so long as your module compiles, involves good housekeeping. zef will look for tests and run them. I cannot program anything now without tests, they are SOOO useful. Then the structure of the module directory has to be right. But once you have got things working once, it becomes much easier. I have a directory called .perl and inside it is just a META.json which lists in the depends field all my favourite modules. Then I use zef to install deps. On 01/08/2020 01:08, ToddAndMargo via perl6-users wrote: On 2020-07-31 16:40, Tom Browder wrote: On Fri, Jul 31, 2020 at 5:38 PM ToddAndMargo via perl6-users wrote: Todd, a couple of questions: 1. In your modules that change all the time, do have "use lib ...;" statements in any of them? No. If I do, they crash # use lib '/home/linuxutil/p6lib'; # may not be precompiled; calling program must take care of this Just for "-O fun", set up your modules as if they were to be public, i.e., add a META6.jso for the module collection. The collection being "/path/to/MyModules" and in MyModules create: META6.json # create it and add all your modules in it just like you were going to publish the whole mess. ./lib/ # my modules as moved or duped from "/home/linuxutil/p6lib" t/ 00-meta-test.t # some basic test to check your META6.json file Then, in dir "/path/to/MyModules" try: $ zef install . # <== that's a DOT/PERIOD, i.e., the current directory If that works, then you should be able to "use" them from your program. -Tom Hi Tom, I am really after is what I originally asked. Is this issue any closer to being solved? And is there a bug I can get myself Cc'ed on to. When I get a chance at it again, I will will look into the workaround. Thank you. What compiles in 1/2 seconds on Perl 5 should not take 18 seconds on Perl 6. It is the "parse" stage this is the issue. $ time raku --stagestats -c GetUpdates.pl6 Stage start : 0.000 Stage parse : 18.405 Stage syntaxcheck: Syntax OK real 0m18.449s user 0m20.673s sys 0m0.223s
Re: Any sign of a fix for the 10 second compile time?
On Sat, Aug 1, 2020 at 12:30 Richard Hainsworth wrote: > What you are asking for is not a bug, but a part of the current stage of > design. It will probably get quicker. Richard, you should find an appropriate place in the docs and add a section on setting up your personal zef repo. Thanks. -Tom
DBIish tries to hijack NativeLibs?
Hello, I was trying to reinstall NativeLibs when I noticed this: $ zef install --force-install --/test NativeLibs ===> Searching for: NativeLibs ===> Updating cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json ===> Updating p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json ===> Updated p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json ===> Updated cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json ===> Installing: DBIish:ver<0.6.1> ^^ Why does zef try to install DBIish instead? This works fine, the only difference is that I'm specifying the module's version: zef install --force-install --/test 'NativeLibs:ver<0.0.7>' Any explanation for this unusual behavior? (BTW, right now DBIish fails to install, but I guess you know, since the test on Travis-CI fails.) -- Fernando Santagata
zef: too many files in ~/.raku/short
Hello, I found out that on my system at a certain point zef was unable to read the content of ~/.raku/short and because of that to install any other module. According to zef there were too many files in that directory and indeed there were a lot of subdirectories. I don't know what happened, because I try to keep my installation lean and I uninstall old versions of all the modules that I update. Is it possible that zef failed to update that directory content when, I don't know, a module fails to install or something like that, leaving behind unused directories? Has that happened to anyone else? -- Fernando Santagata
Re: Any sign of a fix for the 10 second compile time?
Tom, I was not clear. I didn't intend to say/mean a different **zef** repo, but a different Precompilation Cache. I have done this with Pod::From::Cache. If you think this is worth discussing in the docs, let me know. On the other hand, I recompiled raku to make a change, and it needed access to the existing zef repo, so I symlinked the ../site directory to the one that zef uses. So ... I suppose it might be possible to hack something simply by changing symlinks. Not sure it would be a neat way of doing things. Besides, zef and raku have environment variables that should handle this. I haven't looked at how to do this neatly yet. Richard On 01/08/2020 19:33, Tom Browder wrote: On Sat, Aug 1, 2020 at 12:30 Richard Hainsworth mailto:rnhainswo...@gmail.com>> wrote: What you are asking for is not a bug, but a part of the current stage of design. It will probably get quicker. Richard, you should find an appropriate place in the docs and add a section on setting up your personal zef repo. Thanks. -Tom
Re: Any sign of a fix for the 10 second compile time?
$ time raku --stagestats -c GetUpdates.pl6 Stage start : 0.000 Stage parse : 18.405 Stage syntaxcheck: Syntax OK real0m18.449s user0m20.673s sys0m0.223s On 2020-08-01 10:30, Richard Hainsworth wrote: What you are asking for is not a bug, but a part of the current stage of design. It will probably get quicker. For "not a bug but we are working on it", the tracking site is https://github.com/Raku/problem-solving Do you know if the slow parser has got an open tracker? Thank you for the work around in the mean time. I will suffer with the slow parser for now as I do not want to get zef involved at the moment. -T
Re: 2020.07 just hit
For every Unicode operator, there's a "Texas" ASCII equivalent (==) for ≡ but... none that I can find for ≢ is this an oversight or am I not finding it? -y On Wed, Jul 22, 2020 at 3:06 PM Aureliano Guedes wrote: > Nice, Daniel, > > But, I admit, sometimes I don't like too much some symbols not too > intuitive to do on the keyboard like ≡ and ≢ > > Here, I see a lot of codes with weirdo symbols and I need to search how to > do. Anyway, the operator itself seems nice. > > On Wed, Jul 22, 2020 at 12:42 AM wrote: > >> > $ raku --version >> > This is Rakudo version 2020.07 built on MoarVM version 2020.07 >> > implementing Raku 6.d. >> > Whats is new?? >> >> Release notes are at >> https://github.com/rakudo/rakudo/blob/master/docs/announce/2020.07.md >> >> I'm most excited for new the Unicode operators, ≡ and ≢ (though the >> permutations speedup >> is pretty cool too). >> > > > -- > Aureliano Guedes > skype: aureliano.guedes > contato: (11) 94292-6110 > whatsapp +5511942926110 >
Re: 2020.07 just hit
There doesn't need to be an ASCII equivalent of ≢, because you can combine (==) with the ! metaop to come up with !(==) On Sat, Aug 1, 2020 at 4:58 PM yary wrote: > For every Unicode operator, there's a "Texas" ASCII equivalent > (==) for ≡ > but... none that I can find for ≢ > is this an oversight or am I not finding it? > > -y > On Wed, Jul 22, 2020 at 3:06 PM Aureliano Guedes < > guedes.aureli...@gmail.com> wrote: > >> Nice, Daniel, >> >> But, I admit, sometimes I don't like too much some symbols not too >> intuitive to do on the keyboard like ≡ and ≢ >> >> Here, I see a lot of codes with weirdo symbols and I need to search how >> to do. Anyway, the operator itself seems nice. >> >> On Wed, Jul 22, 2020 at 12:42 AM wrote: >> >>> > $ raku --version >>> > This is Rakudo version 2020.07 built on MoarVM version 2020.07 >>> > implementing Raku 6.d. >>> > Whats is new?? >>> >>> Release notes are at >>> https://github.com/rakudo/rakudo/blob/master/docs/announce/2020.07.md >>> >>> I'm most excited for new the Unicode operators, ≡ and ≢ (though the >>> permutations speedup >>> is pretty cool too). >>> >> >> >> -- >> Aureliano Guedes >> skype: aureliano.guedes >> contato: (11) 94292-6110 >> whatsapp +5511942926110 >> >
Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")
This made me want to try a contrived puzzle, use 'fff' to show things
between a "start" and 2nd "mark" line. That is, print any line below not
marked with "!" at the start
$ cat example.txt
!ignore me
Start
hi print me
yes!
Mark
still print me
Mark
!ignore this line
!this line too
Start
We're back!
Mark
Still here!
Start
haha that Start does nothing
going to end it now
Mark
!bye bye don't see me!
Let's see...ooh that was easy!!
raku -ne '.say if "Start" ff ($_ eq "Mark" && ++$ %% 2)' example.txt
That increments the anonymous state variable $ and then checks if it is
divisible by 2, so that only every 2nd Mark returns True
Don't know if I'll ever need it, fun to have it.
-y
On Tue, Jul 28, 2020 at 7:09 PM Brad Gilbert wrote:
> A regex doesn't have to match the entire string.
>
> 'abcd' ~~ / bc /
> # ｢bc｣
>
> A string has to match exactly with the smart-match. (`ff` and `fff` do
> smart-match)
>
> 'abcd' ~~ 'bc' # False
> 'abcd' ~~ 'abcd' # True
>
> A string inside of a regex only makes that a single atom, it does not make
> it match like just a string.
>
> 'abcd' ~~ / 'bc' /
> # ｢bc｣
>
> 'aBaBaB' ~~ / aB+ /
> ｢aB｣
>
> 'aBaBaB' ~~ / "aB"+ /
> ｢aBaBaB｣
>
> In fact a string inside of a regex doesn't do much more than square
> brackets.
>
> 'aBaBaB' ~~ / [aB]+ /
> ｢aBaBaB｣
>
> If you want the regex to match fully, add a beginning of string and end of
> string marker.
>
> 'abcd' ~~ / ^ bc $ /
> # Nil
>
> 'abcd' ~~ / ^ abcd $ /
> # ｢abcd｣
>
> ---
>
> Since `ff` can begin and end at the same time, the following is turning on
> and off at almost every iteration of the loop after it starts.
>
> $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/
> ;' startling.txt
> on star
> on off start
> on off startl
> on off startli
> on off startlin
> on off startling
>
> On Tue, Jul 28, 2020 at 1:43 PM William Michels
> wrote:
>
>> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
>> operators in Raku to me!
>>
>> I have to admit that I'm still fuzzy on the particulars between "ff"
>> and "fff", since I am not familiar with the sed function. I can
>> certainly understand how useful these functions could be to 'pull out
>> all PGP signatures' from a file (which was the Perl5 example given in
>> the Oracle Linux Blog). So I can now pull out the html "head" section
>> from the page _ https://raku.org/fun/ _ (saved locally as file
>> "fun.txt") using the following Raku code:
>>
>> user@mbook:~$ raku -ne '.put if Q[] ff Q[]' fun.txt
>>
>>
>>
>>
>> Raku is optimized for fun!
>>
>>
>>
>>
>>
>>
>>
>>
>> user@mbook:~$
>>
>> What I'm less clear on is how the code below is functioning. I first
>> print out file named "startling.txt" with 'cat': it's supposed to
>> stand in for a text delimited linewise by "header 1", "header 2", etc.
>> After the 'cat' example, I show three examples with Perl(v5.26.3) and
>> three examples with Raku(2020.06), generally comparing literal vs
>> regex arguments.
>>
>> The first two Perl5 examples returns nothing; the third Perl5 example
>> returns everything after the "star" line. For the Raku code, the
>> 'DWIMmiest' output below is the first Raku example, which returns two
>> lines, "star" and "start". This is what I expected/desired. But I'm
>> not really understanding what's happening with the other 2 Raku
>> examples (which return everything after the "star" line):
>>
>> user@mbook:~$ cat startling.txt
>> s
>> st
>> sta
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>>
>> user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt
>> user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt
>> user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt
>> star
>> start
>> user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$
>>
>> I'm all in favor of improving the "ff" and "fff" functions in Raku
>> over their Perl5 counterparts, but I'm hoping to gain a better
>> (mnemonic?) way of remembering the expected return values with literal
>> vs regex arguments.
>>
>> Any assistance appreciated, Bill.
>>
>>
>>
>>
>>
>>
>> On Sun, Jul 26, 2020 at 10:04 AM Larry Wall wrote:
>> >
>> > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
>> > : In the above two cases ff and fff would behave identically.
>> > :
>> > : The difference shines when the beginning marker can look like the end
>> > : marker.
>> >
>> > The way I think of it is this: You come to the end of "ff" sooner, so
>> you
>> > do the end
Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")
Hi Yary, Nice code!
The general approach of using an anonymous counter is useful to me. Below
are examples when I only want to recover the first one or two blocks of
text starting with "Start" and ending with "Mark" (nota bene: I took your
example text and deleted the blank lines):
user@book:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) fff ($_ eq
"Mark" && $++ < 1);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) ff ($_ eq
"Mark" && $++ < 1);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) fff ($_ eq
"Mark" && $++ < 2);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
Start
We're back!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) ff ($_ eq
"Mark" && $++ < 2);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
Start
We're back!
Mark
Still here!
Start
haha that Start does nothing
going to end it now
Mark
!bye bye don't see me!
user@mbook:~$
I guess I have to say--I'm still a little surprised by the last result
using the "ff" infix operator. I'd appreciate knowing why "ff" and "fff"
behave differently in the last two examples, since the beginning marker
doesn't look anything like the end marker (suggesting they should act
identically). Also, is there a simpler way to write the conditional?
Thx, Bill.
On Sat, Aug 1, 2020 at 4:04 PM yary wrote:
>
> This made me want to try a contrived puzzle, use 'fff' to show things
between a "start" and 2nd "mark" line. That is, print any line below not
marked with "!" at the start
>
> $ cat example.txt
>
> !ignore me
>
> Start
>
> hi print me
>
> yes!
>
> Mark
>
> still print me
>
> Mark
>
> !ignore this line
>
> !this line too
>
> Start
>
> We're back!
>
> Mark
>
> Still here!
>
> Start
>
> haha that Start does nothing
>
> going to end it now
>
> Mark
>
> !bye bye don't see me!
>
>
> Let's see...ooh that was easy!!
>
> raku -ne '.say if "Start" ff ($_ eq "Mark" && ++$ %% 2)' example.txt
>
>
> That increments the anonymous state variable $ and then checks if it is
divisible by 2, so that only every 2nd Mark returns True
>
> Don't know if I'll ever need it, fun to have it.
>
> -y
>
>
> On Tue, Jul 28, 2020 at 7:09 PM Brad Gilbert wrote:
>>
>> A regex doesn't have to match the entire string.
>>
>> 'abcd' ~~ / bc /
>> # ｢bc｣
>>
>> A string has to match exactly with the smart-match. (`ff` and `fff` do
smart-match)
>>
>> 'abcd' ~~ 'bc' # False
>> 'abcd' ~~ 'abcd' # True
>>
>> A string inside of a regex only makes that a single atom, it does not
make it match like just a string.
>>
>> 'abcd' ~~ / 'bc' /
>> # ｢bc｣
>>
>> 'aBaBaB' ~~ / aB+ /
>> ｢aB｣
>>
>> 'aBaBaB' ~~ / "aB"+ /
>> ｢aBaBaB｣
>>
>> In fact a string inside of a regex doesn't do much more than square
brackets.
>>
>> 'aBaBaB' ~~ / [aB]+ /
>> ｢aBaBaB｣
>>
>> If you want the regex to match fully, add a beginning of string and end
of string marker.
>>
>> 'abcd' ~~ / ^ bc $ /
>> # Nil
>>
>> 'abcd' ~~ / ^ abcd $ /
>> # ｢abcd｣
>>
>> ---
>>
>> Since `ff` can begin and end at the same time, the following is turning
on and off at almost every iteration of the loop after it starts.
>>
>> $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/
;' startling.txt
>> on star
>> on off start
>> on off startl
>> on off startli
>> on off startlin
>> on off startling
>>
>> On Tue, Jul 28, 2020 at 1:43 PM William Michels
wrote:
>>>
>>> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
>>> operators in Raku to me!
>>>
>>> I have to admit that I'm still fuzzy on the particulars between "ff"
>>> and "fff", since I am not familiar with the sed function. I can
>>> certainly understand how useful these functions could be to 'pull out
>>> all PGP signatures' from a file (which was the Perl5 example given in
>>> the Oracle Linux Blog). So I can now pull out the html "head" section
>>> from the page _ https://raku.org/fun/ _ (saved locally as file
>>> "fun.txt") using the following Raku code:
>>>
>>> user@mbook:~$ raku -ne '.put if Q[] ff Q[]' fun.txt
>>>
>>>
>>>
>>>
>>> Raku is optimized for fun!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> user@mbook:~$
>>>
>>> What I'm less clear on is how the code below is functioning. I first
>>> print out file named "startling.txt" with 'cat': it's supposed to
>>> stand in for a text delimited linewise by "header 1", "header 2", etc.
>>> After the 'cat' example, I show three examples with Perl(v5.26.3) and
>>> three examples with Raku(2020.06), generally comparing literal vs
>>> regex arguments.
>>>
>>> The first two Perl5 examples returns nothing; the third Perl5 example
>>> returns everything after the "star" line. For the Raku code, the
>>> 'DWIMmiest' output below is the first Raku example, which returns two
>>> lines, "star" and "start". This is what I expected/desired. But I'm
>>> not rea
