🦋 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.
00:06 reportable6 left 00:10 linkable6 joined 03:13 frost joined 04:08 reportable6 joined 04:24 [Coke] left, [Coke] joined 06:08 reportable6 left 06:10 reportable6 joined 09:55 evalable6 left, linkable6 left, evalable6 joined 09:56 linkable6 joined
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
10:56 evalable6 left, linkable6 left, linkable6 joined 10:58 evalable6 joined 11:30 Altai-man joined 11:41 Altai-man left 11:42 Altai-man joined 12:07 reportable6 left 13:10 reportable6 joined
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
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
14:29 frost left
lizmat I see :-) 15:44
15:53 shinto joined 16:34 carlmasak joined
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.
17:08 Core5549 joined 17:11 shinto left 17:16 shinto joined, Core5549 left 17:18 shinto left 17:25 shinto joined 17:52 carlmasak100 joined 17:54 carlmasak left 18:01 carlmasak100 is now known as carlmasak, carlmasak left 18:08 reportable6 left 18:17 nine_ is now known as nine 19:09 reportable6 joined 19:11 Core6356 joined, shinto left 19:12 shinto joined 19:14 Core2487 joined 19:15 Core4335 joined, Core6356 left 19:16 Core9796 joined 19:17 shinto left 19:18 Core2487 left 19:19 Core4335 left 19:29 Altai-man left 20:29 evalable6 left, linkable6 left 20:31 evalable6 joined 20:45 shinto joined 20:46 Core3143 joined 20:49 Core9796 left 20:50 shinto left
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
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
23:30 linkable6 joined