Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:09 lucasb left 01:12 ggoebel left 03:55 grayrider joined 03:56 grayrider left 04:47 ufobat left
lizmat Files=1275, Tests=108166, 206 wallclock secs (26.60 usr 7.57 sys + 2883.92 cusr 281.38 csys = 3199.47 CPU) 04:53
[Tux] Rakudo version 2019.03.1-660-g9b639961c - MoarVM version 2019.05-93-g80bc744fa
csv-ip5xs0.692 - 0.713
csv-ip5xs-205.199 - 5.460
csv-parser23.605 - 23.775
csv-test-xs-200.432 - 0.437
test7.067 - 7.362
test-t1.831 - 1.871
test-t --race0.849 - 0.884
test-t-2029.356 - 30.959
test-t-20 --race9.844 - 9.997
 06:13
07:21 patrickb joined 08:45 squashable6 left 08:48 squashable6 joined, ChanServ sets mode: +v squashable6 10:39 gfldex joined
Geth rakudo: taboege++ created pull request #3021:
Warn when x..^* range is used as subscript		 10:47
12:14 ggoebel joined 12:28 squashable6 left 12:31 squashable6 joined 12:52 squashable6 left 12:55 squashable6 joined 13:54 pamplemousse joined 14:26 pamplemousse left, pamplemousse joined
dogbert17 a bit OT but perhaps someone missed this news: www.raspberrypi.org/products/raspb...4-model-b/ 14:37
[Coke] ... and I bought one. :P 14:53
14:56 lucasb joined
dogbert17 [Coke]: the 4 Gig one? 14:59
15:44 pamplemousse left 15:45 pamplemousse joined 15:57 MasterDuke left
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue Ambiguity in slicing with Ranges / WhateverCodes github.com/perl6/problem-solving/issues/50 16:05
16:19 patrickb left 16:36 vrurg joined
[Coke] got the 4g with a kit from cana. 16:36
16:37 MasterDuke joined 17:16 patrickb joined 17:17 squashable6 left, squashable6 joined 17:45 AlexDaniel joined
AlexDaniel releasable6: status 18:06
releasable6 AlexDaniel, Next release will happen when it's ready. 6 blockers. 262 out of 660 commits logged (⚠ 1 warnings)
AlexDaniel, Details: gist.github.com/62ed128cef3ca634bd...7dac6fd0dc
18:13 patrickb left
dogbert17 AlexDaniel: how's the release work going? 18:35
Kaiepi got a rudimentary implementation of wchar_t, wint_t, char16_t, and char32_t implementation working! 🎉 (just on moarvm for the time being) 18:38
this is a hell of a lot more work than i originally thought when i tried implementing it around a year ago 18:39
vrurg .tell timotimo I remember about your request. If it's still actuall I could try looking into it. But cannot promise much as my laptop has been sent out for repair and might not be back until Friday. 18:40
yoleaux vrurg: I'll pass your message to timotimo.
Kaiepi for wide string support i'd probably need to create a wide string repr right?
for nativecall i mean 18:43
timotimo don't we already have support for that? 18:45
yoleaux 18:40Z <vrurg> timotimo: I remember about your request. If it's still actuall I could try looking into it. But cannot promise much as my laptop has been sent out for repair and might not be back until Friday.
timotimo strings are already turned into c-strings and back anyway when going through nativecall
since nothing likes our internal representation of strings
Kaiepi cstrs use char * on moar so no 18:48
there isn't really a good way to handle them currently since the size and what sign wchar_t and wint_t are heavily dependent on the platform and char16_t and char32_t are always unsigned 16 and 32 bit ints, while uint16 and uint32 aren't necessarily 18:50
also char16_t and char32_t are mangled differently iirc
timotimo ugh 18:54
but that sounds more like a different setting for CString rather than a whole new repr 18:55
Kaiepi how would i set that up? 18:57
also just to show how ridiculous wchar_t and wint_t are, this is what src/platform/wchar.h looks like atm fpaste.scsys.co.uk/585137 19:01
on other backends it's way easier to implement 19:02
though i can't actually implement it on the js backend without making changes to one of its dependencies
vrurg timotimo: if you could remind me about details of your request? A ticket, perhaps? 19:03
AlexDaniel dogbert17: slowly 19:14
lizmat: now I'm even more confused 19:20
lizmat: “0..^* is NOT the same as ^*” yea but you'll get the same elements, right? 19:21
m: say (^10)[0..^*]
camelia (0 1 2 3 4 5 6 7 8 9)
AlexDaniel m: say (^10)[^*]
camelia (0 1 2 3 4 5 6 7 8 9)
AlexDaniel so how come 35b69f074 should be reverted if it made things more consistent 19:22
TreyHarris Is there a way these days to do an incremental HTML build of perl6/doc? I had one mismatched pair of POD angle brackets, and I don't want it to rebuild everything 19:24
AlexDaniel TreyHarris: maybe file a ticket? 19:25
TreyHarris AlexDaniel: just searched and found one. It's closed, though; maybe it should stay open? github.com/perl6/doc/issues/2668 19:26
AlexDaniel TreyHarris: done 19:27
Trey
TreyHarris Hah
AlexDaniel: we stepped on each other
AlexDaniel TreyHarris: there seems to be a lot of progress on the doc build process (GSoC project), so I think that will be resolved soon-ish
TreyHarris Cool.
I introduced a site-breaking commit once a couple years ago because I thought it was tiny and mostly a copy-paste from another file and therefore safe, but I didn't realize the tag I copied started with guillemets, and I ended it with a >. Since then I've been hesitant to push without rebuilding, but it takes forever 19:29
dogbert17 AlexDaniel: made a comment on R#3015 19:30
synopsebot_ R#3015 [open]: github.com/rakudo/rakudo/issues/3015 [BLOCKER][regression] Some issue in LMDB module
AlexDaniel dogbert17: doesn't it suggest that the module itself is in the wrong? 19:31
dogbert17 AlexDaniel: perhaps, it would be interesting to hear what timotimo thinks 19:55
timotimo i'm sure you think that would be interesting now, but don't say i haven't warned you if it comes to pass! 19:57
just kidding
what's up?
dogbert17 timotimo: can you take a quick peek at the comments to R#3015 19:58
synopsebot_ R#3015 [open]: github.com/rakudo/rakudo/issues/3015 [BLOCKER][regression] Some issue in LMDB module
timotimo should elems just return 0 for unconcrete objects? 20:00
it feels a little more like that should be a high-level thing we'd do
lizmat m: dd Mu.elems
camelia No such method 'elems' for invocant of type 'Mu'. Did you mean 'bless'?
in block <unit> at <tmp> line 1
timotimo i.e. implement a multi elems on CArray for CArray:U
m: dd Any.elems
camelia 1
lizmat m: dd Any.elems
camelia 1
timotimo oh, that thing
m: dd List.elems
lizmat ah, yes...
camelia 1
timotimo m: dd Array.elems
camelia 1
timotimo um 20:01
hold on
elems on a CArray isn't sensible in all cases anyway
only if it's managed
so, did the test so far expect to get 0 back or something? 20:02
calling elems on a CArray until that patch would have been reading garbage data 20:03
lizmat m: sub a(Real() $a) { }; dd &a.signature # looks like Real() is missing from the .perl of the signature
camelia :($a)
timotimo c: ca322cf^ use NativeCall; CArray[uint8].elems.say for ^100 20:04
committable6 timotimo, gist.github.com/386513710915de0ddb...6f2dd19def
timotimo Failed to create directory '/home/bisectable/.perl6/short' with mode '0o777': Failed to mkdir: Read-only file system
ha
so anyway. until that patch, it seems like elems on an undefined array gave 0 20:06
which would also be changed by making it match what Array.elems does with an undefined object 20:07
i scared everybody off :( 20:12
ugexe i wonder why it fails to create that directory when you aren't doing anything that should require new precompilation 20:13
it must be doing a -I lib or something 20:14
timotimo pretty possible; that should be find-out-able
c: ca322cf^ use nqp; say nqp::clargs
committable6 timotimo, ¦ca322cf^: «===SORRY!===␤No registered operation handler for 'clargs'␤ «exit code = 1»»
ugexe even still i'd expect it to point to ./precomp, not ~/.perl6
timotimo what's that called again ...
oh damn, it's not mapped, it's only directly emitted as a QAST::VM node in the code 20:15
dogbert17 timotimo: I'm watching a film on TV only showing up during commercials :) 20:24
trying your snipper above on 2018.12 returns a lot of '65207712' 20:26
*snippet
and it changes with each run 20:27
lizmat m: my @a = ^10; dd @a["a"..*] 21:04
camelia ()
lizmat hmmm...
timotimo yeah, it's reading unrelated memory 21:18
dogbert17 I guess that means your fix is good :) 21:20
btw, how are you going to survive tomorrow, some parts of Europe will be getting 35 degrees 21:21
tobs m: my @a = ^10; dd @a["a"..Inf] 21:23
camelia ()
tobs hah, it hangs here 21:24
as opposed to the one with ..*
21:25 squashable6 left, squashable6 joined, ChanServ sets mode: +v squashable6 21:26 pamplemousse left
lizmat dogbert17: we had 35.9 here today 21:36
tomorrow only 32 :-) 21:37
jnthn 36C forecast here tomorrow :( 21:39
"only" 32 here today and I could barely think
21:48 dogbert11 joined 21:49 krunen left 21:50 krunen joined, dogbert17 left 22:17 tobs left 22:35 tobs joined
AlexDaniel dogbert11: it's pretty cold here, so I won't mind if some of that heat reaches us… 22:44
22:53 pamplemousse joined 22:55 lucasb left 23:13 squashable6 left 23:18 squashable6 joined, ChanServ sets mode: +v squashable6 23:40 pamplemousse left
vrurg jnthn: are still available? 23:49
*are you
jnthn vrurg: Sleeping soon, but around for another 10 mins 23:51
Got any easy questions? :-)
vrurg One question. Is it supposed behavior that CORE.<letter> cannot add new symbols and only overrides existing ones?
I mean, if I add a sub in CORE.d/CORE.e – it's not available compile time. 23:52
jnthn No, it should be able to add new subs/types also
I thought CORE.d sort-of already did that, in that it replaces `await`'s proto and has a completely new candidate set 23:53
vrurg Ok, it's a bug then. Would try to get some help tomorrow, perhaps.
jnthn I'm not sure why we'd not be able to resolve new ones
What's the symptom?
vrurg Multi-dispatches are extended with new candidates, it's ok. 23:54
jnthn Yes, but I believe CORE.d completely replaces the candidates.
vrurg Added, say, sub for-e-only. Dumping CORE:: reveals the symbol is not there. Surely, referring it in the code ends up with compiler error.
jnthn Yes, new proto: github.com/rakudo/rakudo/blob/mast...it.pm6#L11
vrurg Replacing seemingly works too. 23:55
It's only new ones which are ignored.
jnthn Hm, that sounds like it's - at some point - looking in the wrong place
I wonder if CORE:: is somehow resolving to the outermost setting
vrurg And I'm not touching a subject of replacing a role. Not before your bedtime. :) 23:56
jnthn Well, you can, but none of the types in the outer setting are going to do it ;)
vrurg I'll try to do as much diagnosis as possible. Though have like 40-45 minutes left for this.
Yeah, I guess so. It's about changing QuantHash and looks like all consumers are to be added to CORE.e too. But, again, that's another matter. 23:57
jnthn Occurs to me that actually SETTING and CORE are kind of tricky, because when we have 6.d/6.e going on, they actually need to represent the symbols from a range of nested lexical scopes, perhaps.
And I bet that isn't happening. 23:58
But that introspection issue aside, I'd still expect the new sub to be "normally" visible
Maybe the same problem does crop up elsewhere, though
vrurg Ok, leave it for now. All I needed to make sure is that it's not expected. Now, it's a good excersise to dig into that code too. :) Thanks and g'night! 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!