🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
lizmat Files=1351, Tests=117094, 325 wallclock secs (36.65 usr 9.96 sys + 4536.90 cusr 359.92 csys = 4943.43 CPU) 10:05
vrurg: so yeah, the 346 wallclock secs was a fluke
although we seem to have lost about 800 tests since the last time? 10:06
Geth nqp: 2ea01db9dd | (Stefan Seifert)++ | 2 files
Map new ops for unsigned handling

New ops: bindpos_u, atpos_u, atposref_u, iscont_u, assign_u and captureposarg_u		 14:04
vrurg lizmat: ot 14:24
lizmat: sorry... No, it's a fake. I just wrapped some into subtests within a test-assertion.
github.com/Raku/roast/commit/250a246ded 14:27
lizmat I see :-) 15:44
Geth nqp: 7c20873fa4 | (Stefan Seifert)++ | 14 files
Replace flatnamed arg flag by flat | named

No need to have a separate flag when the combination of the existing flags means the same thing. Will free up the flag for other use in MoarVM.		 16:59
gfldex m: sub s(\l where *.^can('rotor'|'iterator')) {}; s([]); 21:54
camelia This type cannot unbox to a native string: P6opaque, Junction
in sub s at <tmp> line 1
in block <unit> at <tmp> line 1
gfldex Am I asking for to much?
lizmat yes 21:58
that basically winds up in NQP land, and NQP land doesn't know about Junctions really 21:59
Geth problem-solving: vrurg++ created pull request #310:
Add resolution document for #135		 22:19
vrurg greppable6: ValueList 22:23
greppable6 vrurg, 35 lines, 3 modules: gist.github.com/23ab16ee883767983c...fc82b437dc
vrurg greppable6: ValueMap 22:24
greppable6 vrurg, Found nothing!
japhb vrurg: Shouldn't that be *Scalar* decontainerization? Or were you implying converting sub-Arrays to sub-ValueLists recursively? 22:26
vrurg japhb: I was keeping in mind "Scalar", as it was always implied by the discussion surrounding Map conversion to non-value type. But you made me confused now... 22:29
japhb Oh dear, I'm now an agent of chaos. 22:30
vrurg You are my dear, you are... :D
japhb :-D
vrurg Though I tend to make it scalar only. Because if go as deep as deconting arrays and hashes, then why stopping there? And where stop then? 22:31
At deeper level we may consider introducing a protocol of converting an object type into a value type. 22:33
But this would require some additional theoretical work. In the mean time it is sufficient for Value* structures to know that they contain the same array, no matter what is Array's content. 22:35
japhb Actually, deep conversion of data structures in both directions would be a useful thing, but yeah, needs thought.
Right. So maybe specify Scalar decontainerization in this doc, and leave other sub-container types open for future expansion? 22:36
vrurg Oh, I'm recalling that codesections started working on immutable data types. That might eliminate the need for deep value-fication.
Yep, thanks for reminding me. I lost track and forgot to update the resolution. :) 22:37
japhb Heh 22:41
vrurg Done. 22:45
Updated with parameterization section and that's probably it for today. 23:03

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!