🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
tbrowder__ .tell Voldenet at least for my case, reading a file and generating the large hash is faster than putting it in a module and "use"ing it. i thought the .precomp would be the faster route, but it seems not. i don't have good time stats, but dynamic is definitely faster. 11:20
tellable6 tbrowder__, I'll pass your message to Voldenet
Voldenet tbrowder__: that's surprising, I'd expect static data being loaded a lot faster 11:41
tellable6 hey Voldenet, you have a message: gist.github.com/329ab19a35598953e0...aaf8fd1f05
Voldenet the only good explanation is that generating the hash is cheap, but underlying data structures are somewhat heavy (so static data has the same cost, but with additional cost of loading the file) 11:43
tbrowder__ Voldenet: i may have fooled myself but i'll look closer later 13:02
[Coke] github.com/Raku/doc/blob/main/doc/...kudoc#L142 - this is not rendered as code, but as a paragraph. This is a recent-ish change that is causing several tests to fail in raku/doc 16:07
Not sure if we can craft a whateverable to highlight this, but will try to do a bisect to find it.
most other code blocks in that file? still fine, showing as "code" (That is, with a four space indent on render) 16:08
(rendering is using raku --doc ...) 16:13
lizmat [Coke] and without RAKUDO_RAKUAST=1 I assume 16:21
[Coke] (We only run the extended tests on files that changed, so easy to miss something that changed behavior on an untouched doc file) 16:22
lizmat: correct.
~500 more revisions to check. :)
lizmat fwiw, I stay away from the old pod grammar / actions as far as I can 16:23
[Coke] +1 16:24
crap. 16:28
False alarm - my cache of pod documents was bad.
(yet another reason to move to rakuast processing here, so I don't even need a cache)
lizmat *phew* and: indeed :-) 16:30
[Coke] I *think* the cache is thread safe, but maybe not. I just wiped it, ran the one problematic test (warming the cache), and am now running all of xtest. 16:31
... yup, all fine now. Sorry for the false alarm, liz. 16:32
lizmat no worries :-) 16:33
[Coke] as I recall, my one "blocker" to switching directly to rakuast is that it doesn't mimic --doc 100%. Is that a goal? 16:34
lizmat --doc is identical afaik
[Coke] I can submit tickets for discrepencies I find if you like.
lizmat please do, they *should* produce the same output and do for the spectests that exist
[Coke] ... ok. I thought I had found a lot of discrepencies, but maybe i was comparing against this janky cache.
lizmat well, it took a *lot* of tweaking to get it byte-for-byte the same 16:35
it handles the rakudoc of App::Rak 100%
and that's a relative biggy
[Coke] if nqp::getenvhash()<RAKUDO_RAKUAST> 16:44
will that trigger only if it's truthy, or would a 0 also trigger it?
lizmat m: use nqp; say "foo" if if nqp::getenvhash<RAKUDO_RAKUAST> 16:45
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
if used at line 1
lizmat m: use nqp; say "foo" if nqp::getenvhash<RAKUDO_RAKUAST>
camelia ( no output )
[Coke] I assume that's empty vs. 0, though.
lizmat RAKUDO_RAKUAST=0 raku -e 'use nqp; say "foo" if nqp::getenvhash<RAKUDO_RAKUAST>' 16:46
foo
nope
it's a string, not a number
RAKUDO_RAKUAST= raku -e 'use nqp; say "foo" if nqp::getenvhash<RAKUDO_RAKUAST>'
(no output)
[Coke] Thanks
RAKUDO_RAKUAST=1 raku --doc doc/Language/101-basics.rakudoc gets a compile time error 16:51
... will let this whole thing run to completion and update my gist
lizmat ok, will look at that one: at first sight it is an error in a sorry reporting 16:52
looks like a =table error 16:54
[Coke] If there's a pod6 bug that was previously undetected, I'm OK with updating the doc file. 16:56
lizmat Table has a mixture of visible and invisible column-separator types
in line '$line 'Ana Dave \| 3:0''
line numbers are still off in RakuAST 16:57
in error reporting: NYI
[Coke] # You failed 222 tests of 419
gist.github.com/coke/0c72e45c4f5f4...102b68e085
if it says "error occurred caching" it's a compile time error, if it's a doesn't match, it ran successfully but generated different output 16:58
lizmat line 237, apparently \| is not interpreted as an escaped column divier 17:00
line 237, apparently \| is not interpreted as an escaped column divider
that's a problem in RakuAST that I need to look at :-)
consider that gist assigned to me :-) 17:01
[Coke] I added it as a test in rakudoc to give you something you can run to check progress. 17:05
RAKUDO_AST_DOCS=1 xt/rakuast-compare.rakutest (without the var, it skips everything)
lizmat thanks!
ingy github.com/acmeism/RosettaCodeData I updated this for the first time in years. (Conference driven development! :) 17:48
I had to rewrite the scraping tools, because of RC formatting changes. 17:49
THe good news is everything is a lot more accurate than in the past.
Also I added some simple data analysis tools, and they show Raku is doing well in RC 17:50
gist.github.com/ingydotnet/7082768...833e640118
Perl too! 17:51
[Coke] ingy++ 17:52
[Coke] lizmat: added an option, so you can do this: TEST_FILES=doc/Language/contexts.rakudoc RAKUDO_AST_DOCS=v xt/rakuast-compare.rakutest 18:17
lizmat thanks!
[Coke] would only do it with one test file; but if you do, it also emits a diff.
er, commiting now
looks like X<|Reference,SlurpySentry> is getting rendered. 18:26
lizmat yeah
[Coke] that's prbably a huge number of the issues.
lizmat think I found it, stupid thinko in a recent refactor
and another one bites the dust: github.com/rakudo/rakudo/commit/93dd19f8db 18:31
[Coke] rebuilding... 18:34
lizmat ok, looks like the old doc::to::text is removing whitespace from X<>
so X<foo |bar>baz is rendered as "foobaz" rather than "foo baz" 18:35
tbrowder__ hi, need some help with a test 18:42
[Coke] now at 211 failures down from 222 18:49
gist updated 18:50
tbrowder__ in a module repo i have a /bin/script. i want to run a lives-ok { run "./bin/script" } test. i test it by running raku -Ilib t/test.t and it fails with unable to find a module 19:04
in the test.t i "use Test; use NecessaryModule:" 19:05
the code is public on github.com/tbrowder/FontFactory 19:06
s/:/;/ 19:09
lizmat and if you run it with -I. ?
tbrowder__ ah, i'll try that! 19:15
lizmat generally, when testing a module as a developer, you should use -I. rather than -Ilib 19:17
because -I. allows Raku to interpret the META6.JSON file
tbrowder__ ah, thanks! but it still didn't work on the single run. HOWEVER, using "mi6 test" did work and captured an error in the run. 19:21
tbrowder__ actually, it looks like the failure to find module error was a red herring. reading more closely pointed out another failure msg from the tested script and module, and mi6 more clearly separated the two errors. 19:24
glad to hear progress on the rakupod front! 19:25
lizmat glad to hear you found it
tbrowder__ this sounding board helps! 19:26
lizmat :-)
[Coke] I'm one commit behind HEAD and lizmat has it down to 95 failures so far 19:49
building again...
[Coke] 49... 20:04
rf lizmat: I think docs.raku.org is dead 20:09
lizmat looks alive to me
[Coke] 47 20:10
rf I'm getting 404's on /language/hashmap
lizmat if you're getting a 404, then it's not dead, that's a wrong lnk
*link
and probably worthy of making an issue 20:11
rf Yeah if you look in raku-doc it seems to be effecting other people too
For example the index is hanging
rf Got a new module coming out monday :) 20:22
lizmat nice 20:25
whatnext hello all :) what would you say is the most concise way of doing the following: say I have an arbitrary length array `@a`, and I want to create a new array composed of the first `$N` elements (if more than `$N` exist) or all elements if the length of `@a` is less than `$N` ? 20:50
gfldex m: my @a = ^5; dd @a.head(3); dd @a.head(10); 20:52
camelia (0, 1, 2).Seq
(0, 1, 2, 3, 4).Seq
gfldex Not sure how head will deal with holes tho.
whatnext ah I didn't know about `head` - thanks for the tip. What do you mean by "holes" ? 20:54
gfldex Technically, a Positional may have discontinous indices. Punching holes into Array is hard and requires nqp-trickery; 20:55
So you are unlikely to encounter them.
whatnext ah ok... I think `head` will serve my purpose well then - thanks for that :) 20:56
gfldex whatnext: in case you wish to deal with holes, here is a recipe: gfldex.wordpress.com/2022/09/29/rabbitholeing/ 20:58
whatnext that looks pretty complex! Thanks I will bear it in mind :) 21:02
librasteve m: say my $N = 3; my @a = 0..5; my @b = +@a > $N ?? @a[0..^$N] !! @a; 22:00
Raku eval 3
librasteve my $N = 3; my @a = 0..5; my @b = +@a > $N ?? @a[0..^$N] !! @a; say @b; 22:01
m: my $N = 3; my @a = 0..5; my @b = +@a > $N ?? @a[0..^$N] !! @a; say @b; 22:02
Raku eval [0 1 2]
librasteve m: my $N = 3; my @a = 0..1; my @b = @a.head: $N; say @b; 22:04
Raku eval [0 1]