🦋 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 |
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 | ||
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. |
16:59 | |
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 |
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 | ||
23:30
linkable6 joined
|