00:32 ggoebel left 00:54 pmurias left 02:04 TreyHarris left 02:12 vrurg left 02:19 vrurg joined 03:11 ZzZombo_ joined 03:14 ZzZombo left, ZzZombo_ is now known as ZzZombo 03:38 ZzZombo_ joined 03:40 ZzZombo left, ZzZombo_ is now known as ZzZombo 06:49 klapperl joined
Geth_ rakudo/friendlier_resources_file_names: 78e199c248 | (Stefan Seifert)++ | src/core.c/CompUnit/Repository/Installation.pm6
Store resources files by their original name if safe

Windows expects DLL files to have their original name. This required module authors to use workarounds like copying the resource file to a temporary directory.
For the common case of file names using ASCII characters only, we store ... (5 more lines)		 07:19
AlexDaniel nine: are you sure about / being OK? 07:26
rba El_Che: Is there a docker image for Blin already? Where can I find it? 07:47
El_Che: I guess it must be this github.com/nxadm/raku-blin-docker 07:49
nine AlexDaniel: yes, since I only use the basename 2 lines down. It needs to accept / as $file will be something like "resources/libraries/p5helper.so" 08:18
AlexDaniel ah, right 08:22
08:53 jmerelo joined 09:08 sena_kun joined 09:19 MasterDuke left 09:21 Altai-man_ joined 09:23 sena_kun left
|Tux| Rakudo version 2019.07.1-451-g9f433da0d - MoarVM version 2019.07.1-312-g7ecfcc9ba
csv-ip5xs0.720 - 0.736
csv-ip5xs-206.419 - 6.683
csv-parser22.038 - 22.152
csv-test-xs-200.428 - 0.429
test6.727 - 7.444
test-t1.776 - 1.806
test-t --race0.791 - 0.905
test-t-2029.815 - 29.873
test-t-20 --race9.126 - 9.315
 10:55
11:22 sena_kun joined 11:23 Altai-man_ left 11:52 jmerelo left
El_Che rba: rakudo/blin:latest 11:59
tellable6 2019-11-01T08:25:49Z #raku <jmerelo> El_Che thanks.
El_Che rba: use the dblin script: it sets a volume in the right place for the output 12:01
AlexDaniel rba: you have something to run it on? 12:09
I'd really appreciate that :)
lizmat releasable6: status 12:28
releasable6 lizmat, Next release will happen when it's ready. There are no known blockers. 248 out of 451 commits logged (⚠ 9 warnings)
tyil hmm, neither clarkema nor hankache are in this channel, would it be wise to send them an email to inform them of my work on rakudo-star?
releasable6 lizmat, Details: gist.github.com/c6b951422988174a6a...cb59d375ba
lizmat AlexDaniel: is it correct that we don't have support for .raku in the first "raku" release ?
AlexDaniel lizmat: what's support for .raku ?
lizmat the new version of .perl ? 12:29
AlexDaniel ah you mean the method
m: say 42.raku
camelia No such method 'raku' for invocant of type 'Int'. Did you mean any of these?
rand
take

in block <unit> at <tmp> line 1
AlexDaniel m: use v6.e.PREVIEW; say 42.raku
camelia No such method 'raku' for invocant of type 'Int'. Did you mean any of these?
rand
take

in block <unit> at <tmp> line 1
AlexDaniel lizmat: yup we don't have it
lizmat hmmm... how would you feel if I added that before the release? 12:30
AlexDaniel lizmat: that said, we won't even have `raku` binary, and it seems to a bit more difficult to make that happen
lizmat ok, so we should consider this the last Perl 6 release then ?
AlexDaniel “The `.perl` method should be deprecated in 6.f, and removed in 6.g. It should be replaced by a `.raku` method, which will be specified in 6.e” 12:31
jnthn It's not a Raku nor a Perl 6 release, but a Rakudo release.
AlexDaniel so you can add .raku I guess, but it should only be in 6.e.PREVIEW? At least that's how I understand it 12:32
jnthn It's a method, so you can't put it behind a language pragma
lizmat jnthn: point taken, but if the release claims it is implementing raku
AlexDaniel like, at all?
lizmat it should have a .raku method
don't you think? 12:33
AlexDaniel there's no announcement file committed yet, but yeah, I guess it's the right time to discuss changes to it
jnthn AlexDaniel: No; read the documentation on language versioning for an explanation.
AlexDaniel one thing that will be changed is “Rakudo Perl 6” → “Rakudo” 12:34
jnthn lizmat: I don't really follow that argument; even the PR didn't promise it until the point 6.e is releasd; of course we can do it earlier than that, but it's just one of many things, which will surely be spread over multiple releases.
AlexDaniel because Rakudo Raku doesn't really sound great anyway
jnthn AlexDaniel: Agree just "Rakudo" 12:35
AlexDaniel jnthn: ok, but, “This release implements 6.c and 6.d versions of the Perl 6 specification”, I think it should just say “Raku specification”, even though 6.c and 6.d releases were perl 6 12:36
jnthn lizmat: I think it's low risk to add a `method raku() { self.perl }` in Mu, though we might want to straighten out the whole "what if people start overriding .raku" issue before we do that.
AlexDaniel but I'm not entirely sure about that one
jnthn lizmat: I think we *did* specify a way forward on that in the PR, and it probably wants more testing than than we can really do before this release.
AlexDaniel: Hm, that's an interesting one. :) 12:37
AlexDaniel: I suspect we can just say "Raku specification" there 12:38
I don't think anyone is going to nit-pick it that much :) 12:39
AlexDaniel “This document lists changes in Raku 6.e language from Perl 6.d version” github.com/perl6/roast/blob/a1125e...nce/6.e.md
personally I wouldn't even say that 12:40
something like “from 6.d version” should be enough
jnthn "from the", but yes 12:41
fwiw, the Comma release yesterday did the first baby steps towards Raku (recognizing, though not yet creating, files with the new extensions, and also recognizing a raku executable as a valid interpreter). 12:43
tyil nice 12:44
I updated the README.md for the rakudo-star repo earlier today to refer to Raku instead of Perl 6
need to set up an FTP server in my cluster so I can make GitLab CI automatically upload releases to my server 12:45
AlexDaniel yeeeeeaaah… it's going to be a long journey
jnthn When I do the Cro release this afternoon I'll do some initial docs/website updating to mention Raku also. 12:46
AlexDaniel jnthn++
jnthn lunch, bbiab 12:48
12:54 pmurias joined
pmurias .tell MaterDuke haven't use that thing 12:55
tellable6 pmurias, I haven't seen MaterDuke around, did you mean MasterDuke?
pmurias .tell MasterDuke I haven't used that thing
tellable6 pmurias, I'll pass your message to MasterDuke
13:01 lucasb joined 13:02 ggoebel joined
Geth_ rakudo: 7cf73de0d4 | (Elizabeth Mattijsen)++ | src/core.c/Mu.pm6
Implement a .raku method placeholder for now

So that the first release of Rakudo with some references to Raku, also has the .raku method working. In the future, all .perl methods in core will be renamed to .perl, and Mu.perl will then call self.perl.		 13:19
13:21 Altai-man_ joined 13:23 sena_kun left 13:43 sena_kun joined 13:45 Altai-man_ left 13:55 ggoebel left 13:57 Ulti joined 14:31 ExtraCrispy joined
vrurg jnthn: I have commited simplified implementation into R#3272. Could you please tell if it's ok with you or you still object? 14:34
jnthn vrurg: Will try and get to it soon; working on Cro release first. 14:35
vrurg No rush. Reminding you because I can imagine how overloaded you're and how easy it is to forget minor stuff. :) 14:36
jnthn On the upside, November is looking a bit less overloaded...in theory :) 14:37
vrurg A theory is yet to be proved first... ;) 14:38
14:50 pmurias left 14:51 pmurias joined 15:02 ExtraCrispy left 15:03 ExtraCrispy joined 15:11 ExtraCrispy left, ExtraCrispy joined 15:19 ExtraCrispy left 15:22 ExtraCrispy joined 15:23 ExtraCrispy left 15:24 ExtraCrispy joined 15:43 Altai-man_ joined 15:45 sena_kun left
timotimo Unhandled exception: Too many positionals passed; expected 0 arguments but got 1ppPPPPppPPPPPPPPPppPP 16:22
at SETTING::src/core.c/ThreadPoolScheduler.pm6:896 (/home/timo/perl6/install/share/perl6/runtime/CORE.c.setting.moarvm:)
(the ppppps are output from the script in question)
lizmat yikes 16:24
timotimo that's the "async" example of Terminal::Print
fwiw, i've seen this a couple months ago already 16:25
so not a recent regression or anything
16:28 Kaeipi joined 16:29 Kaiepi left
japhb timotimo: Is it a bug in T::P or in Rakudo? 16:29
timotimo if you can make the thread pool scheduler do that with just regular methods on it, then that's a rakudo bug 16:30
japhb Ah, hadn't read what you said carefully enough. Yeah, I agree. 16:31
If you say: react { whenever A { ... }; whenever B { ...; done } } -- is the 'done' supposed to exit from just 'whenever B' or from the react? 16:33
jnthn `done` will terminate the `react`; you use `last` for just one of them. 16:43
lizmat could it be that Travis is still reporting build failures to #perl6-dev? 16:45
jnthn lizmat: Yes, it seems it is 16:53
Might be possible to change in the .travis.yml; can't remember
lizmat yup: irc.freenode.net#perl6-dev" 16:59
Geth_ rakudo: 54e0aceecc | (Elizabeth Mattijsen)++ | .travis.yml
Make sure that Travis reports to #raku-dev
 17:00
jnthn And shipped to CPAN 17:02
japhb jnthn: Hmmm, I was seeing some behavior last night that indicated done was ending just one whenever, which didn't seem right to me, so now I need to go back and think if I'm dreaming. 17:31
What's the intended behavior for 'die' dynamically inside the whenever? As in: sub foo { die "boo!" }; react { whenever { ...; foo() } } 17:32
jnthn All taps are closed, and the exception is rethrown at the place that did the `react` 17:33
japhb OK, hmmm, thank you.
17:37 donaldh joined 17:46 Altai-man_ left
rba Hmm. Does Perl fall into depression? blogs.perl.org/users/yuki_kimoto/20...ffers.html 17:48
18:39 donaldh left 18:52 donaldh joined
tyil running `make spectest` of rakudo star on gitlab ci has failing tests for S02-magicals/KERNEL.rakudo.moar 18:56
is this a current known issue, or is it something to figure out
and if so, how would I start figuring it out ;~;
the gitlab ci build log is at gitlab.com/tyil/rakudo-star/-/jobs/339624111
19:00 donaldh left
AlexDaniel tyil: so, which tests are 39-40? 19:08
19:08 donaldh joined
AlexDaniel tyil: it's likely a stupid test that needs to be fixed 19:08
well, it could also be a bug in rakudo 19:09
m: dd $*KERNEL.signal("SIGHUP"), is $*KERNEL.signal("HUP") 19:10
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
is used at line 1
tyil I have no clue ;~;
AlexDaniel m: dd $*KERNEL.signal("SIGHUP"), $*KERNEL.signal("HUP")
camelia 1
1
19:10 lucasb left
AlexDaniel I think these two 19:11
tyil: so, can we somehow run this in their environment? perl6 -e 'dd $*KERNEL.signal("SIGHUP"), $*KERNEL.signal("HUP")' 19:12
and see the output
also add $*KERNEL.signal(SIGHUP) in there, because it compares to that 19:14
tyil AlexDaniel: hmm, I could add a stage that just runs a shellscript to run those commands 19:18
I can't directly execute into a gitlab ci environment i think
19:19 MasterDuke joined
AlexDaniel tyil: also, in theory it could be a flapper. I have never seen this test file flap ever, so it's probably not it, but just confirming that the test fails consistently is also a good step 19:20
MasterDuke .
tellable6 2019-11-01T12:55:30Z #raku-dev <pmurias> MasterDuke I haven't used that thing
AlexDaniel rba: soo… can we get blin running somewhere? :)
pmurias MasterDuke: www.graalvm.org/docs/graalvm-as-a-...ump-graphs 19:25
19:26 donaldh left
MasterDuke pmurias: hm. 'It is available as a separate download on Oracle Technology Network and requires accepting the Oracle Technology Network Developer License.'. not sure i can get access then. have you tried it? 19:26
pmurias: or more to the point, how are you figuring out where our stuff is slow? 19:27
pmurias MasterDuke: tried it months ago, but as far as I remember it was annoying to use on a laptop screen 19:29
samcv AlexDaniel, i should get the release done this weekend. this last week work has been pretty hectic 19:32
AlexDaniel samcv: well, we have a problem…
samcv: kawaii used to run blin, but they're offline-ish for the last few days 19:33
samcv ah ok
AlexDaniel samcv: so I still don't know if we're ok, actually
samcv: El_Che made a docker image to make running blin easier, and rba also looked at it 19:34
El_Che: can you just rerun it once with a bit more space available?
El_Che: just to get the release going
El_Che AlexDaniel: whould nfs make it a lot slower? 19:36
AlexDaniel El_Che: I don't think it will, if it does, just bump the number of threads 19:37
--nproc=16 or whatever
japhb AlexDaniel: We've had a lot of signals that this is one of our more reliable releases in recent memory, especially on the MoarVM side, and we've fixed lots of Rakudo bugs too. It may be worth just beginning the release process, recognizing that we may have to do a point release if anyone finds anything major after the fact. 19:38
(Not trying to dissuade anyone from doing Blin reports, more just saying it need not be a hard blocker to e.g. samcv if she has time to do the MoarVM release now, but won't later.)
AlexDaniel samcv: oh yeah that's true 19:39
samcv: ↑ just do it if you won't be able to later
El_Che AlexDaniel: looking at vms, I only have with a few cores availaible
if it's ok to take it longer to run, I don't mind running it
AlexDaniel El_Che: yeah, no problem
japhb: but, also, every new release is much more reliable than the previous one 19:40
japhb: and even though I agree with your point, I think not introducing new issues is sometimes more important than fixing old ones 19:41
El_Che AlexDaniel: so what are the parameters needed?
japhb AlexDaniel: Not always in my experience. And a fair amount of effort was spent for this particular release really trying to fix all the GC and rooting bugs we could find. nine++ did quite an amazing amount of work as I recall.
El_Che I had this: "-old=2018.06 --new=2018.09 Foo::Regressed Foo::Regressed::Very Foo::Dependencies::B-on-A"
japhb AlexDaniel: I concede that point, which is why I think rolling back the largest of the IPv6 addressing changes made sense. But that's been done. 19:42
AlexDaniel El_Che: no arguments
El_Che ok, will launch it now
AlexDaniel El_Che: it'll default to --old=2019.07.1 --new=HEAD and all modules in the ecosystem
japhb: anyway, don't worry, we'll get it out eventually 19:43
japhb: one of the reasons it's going that slow is that I don't have enough juice left in me for working on releases 19:45
so I didn't test things early enough
japhb: kawaii was supposed to be the new release manager, but they're currently busy with other life things, so the position is still open :) 19:46
japhb: github.com/rakudo/rakudo/blob/mast...ses-so-far 19:48
rba AlexDaniel, El_Che: maettu has a server around. not sure how much capacity. Yet we need to do docker setup first... How urgent is it? 19:50
AlexDaniel japhb: I did manage to pump out 2018.12, 2019.03 and even some releases before that while being neck deep working on my Master's thesis
rba: well, if El_Che's run finishes then no problem and we'll get the release going, but we'll need it for the release after this one 19:51
japhb: but still, it was more than two years, please send help :)
rba AlexDaniel: When is the release after the release? 19:52
AlexDaniel rba: 2019.12, hopefully
19:57 donaldh joined
AlexDaniel El_Che: when it finishes, all I need is a zip of the output/ folder 19:58
20:08 donaldh left, donaldh joined
pmurias MasterDuke: there is a gpl2 version of that graph visualizer: ssw.jku.at/General/Staff/TW/igv.html 20:12
MasterDuke: I don't have a good way of finding what is slow, thus far I have been mostly guessing and inserting @TruffleBoundary for things that shouldn't get partial evaluated 20:13
MasterDuke thanks, i'll check it out 20:15
El_Che AlexDaniel: ok, got docker running on a centos7 vm 20:33
way harder than apt-get install on ubuntu :)
It's running, but on 2 (fast) threads, so it will take a file 20:35
AlexDaniel: will make the zip available when ready 20:36
⏳ 52 out of 1343 modules processed 20:42
:)
⏳ 105 out of 1343 modules processed 20:48
AlexDaniel that's gonna take a while… 20:51
El_Che my home "server" is not faster, it's a Celeron NUC with 2 threads 20:52
(that fast enough for all the containers and services it runs :) ) 20:53
20:56 donaldh left 20:57 donaldh joined
Geth_ nqp/truffle: b5f10c21f0 | (Daniel Green)++ | src/vm/jvm/Truffle.nqp
[truffle] Add nqp::const
 21:01
tyil AlexDaniel: gitlab.com/tyil/rakudo-star/-/jobs/339822743 output of gitlab.com/tyil/rakudo-star/blob/d...n/debug.sh 21:04
no hurry to look at or comment, since its p late
pmurias MasterDuke: why have a bunch of := instead of using a nqp::hash?
AlexDaniel tyil: ok there's our problem 21:05
tyil undeclared name HUP?
AlexDaniel no
tyil the 1 value
?
AlexDaniel no, 1 is actually right 21:06
tyil I have no clue what I'm looking at, sorry ;~;
AlexDaniel tyil: basically, there are different ways to get the signal value
tyil: normally the table looks kinda like this: man7.org/linux/man-pages/man7/signal.7.html 21:07
scroll to “Signal numbering for standard signals”
tyil ah
AlexDaniel the values on some platforms can be different, which this whole thing is a bit hard
so .signal("SIGHUP") and .signal("HUP") resolve to 2, I assume incorrectly 21:09
and .signal(SIGHUP) is right
Geth_ nqp/truffle: 8f8739cf8f | (Daniel Green)++ | src/vm/jvm/Truffle.nqp
[truffle] Simplify nqp::const with an nqp::hash...

literal instead of a bunch of bindings.
AlexDaniel damn.
did we have any updates to signals thing lately?
I remember some fixes not too long ago, but not recently 21:10
MasterDuke pmurias: no good reason. i had a typo at first and thought maybe they weren't supported that early because of how %type_names was created right above
AlexDaniel tyil: can you file a bug report, please? This is not right :( 21:11
tyil on github.com/rakudo/rakudo?
AlexDaniel yeah 21:13
it's a moarvm issue I think, but rakudo/rakudo is a good default choice
tyil: so something about populating the signal values is wrong 21:15
tyil: if you can also get the output of this it'd be awesome: dd Signal.enums
m: dd Signal.enums
camelia Map.new((:SIGABRT(6),:SIGALRM(14),:SIGBREAK(0),:SIGBUS(7),:SIGCHLD(17),:SIGCONT(18),:SIGEMT(0),:SIGFPE(8),:SIGHUP(1),:SIGILL(4),:SIGINFO(0),:SIGINT(2),:SIGIO(29),:SIGKILL(9),:SIGPIPE(13),:SIGPROF(27),:SIGPWR(30),:SIGQUIT(3),:SIGSEGV(11),:SIGSTKFLT(16)…
Geth_ nqp/truffle: 683564d003 | (Paweł Murias)++ | src/vm/jvm/Truffle.nqp
[truffle] Use a nqp::hash literal instead of a bunch of assignments
 21:16
AlexDaniel tyil: also what's `uname -a` there?
tyil I'll add a dd for signals and uname -a to that script
and re-run it
sadly, that'll take 15 odd minutes since it rebuilds the tarball and recompiles everything from scratch again 21:17
AlexDaniel hmmmmmmmmmm but SIGHUP is actually correct, isn't it
tyil yes
it's the quoted variants that seem off
AlexDaniel m: dd $*KERNEL.signals 21:18
camelia Array @!signals = [Any, Signal::SIGHUP, Signal::SIGINT, Signal::SIGQUIT, Signal::SIGILL, Signal::SIGTRAP, Signal::SIGABRT, Signal::SIGBUS, Signal::SIGFPE, Signal::SIGKILL, Signal::SIGUSR1, Signal::SIGSEGV, Signal::SIGUSR2, Signal::SIGPIPE, Signal::SIG…
AlexDaniel tyil: ↑ that is probably more important 21:19
github.com/rakudo/rakudo/blob/54e0...#L132-L163 21:20
what is this??
tyil raku code?
AlexDaniel yeah… but why is it there?
the signal values are populated in moarvm
why do we even have these ugly hacks in rakudo 21:21
tyil that I don't know
AlexDaniel qx/kill -l/
… 21:22
maybe I'm misunderstanding something, but this stuff just shouldn't be there
jnthn MoarVM and NQP goes fine, then nmake chokes 21:40
oops
Hmm, maybe a problem for release: I can't build Rakudo HEAD on Windows (MSVC toolchain)
Swap those lines around :P 21:41
The lines in error look like: 21:42
m-install-post::
!ifndef DESTDIR
@echo(+++ Cleaning up outdated MOAR files)@
@noecho@$(RM_F) C:\consulting\MoarVM\install\share\nqp\lib\Perl6\Actions.moarvm
Um, with an empty line before the last one
If I fix the indentation and remove the empty line, it is happier, it seems 21:43
Then at make install time, this happens: 21:46
+++ Preparing installation
===SORRY!===
Cannot find method 'load_module' on object of type NQPMu
lizmat that feels like a submodule update issue 21:49
jnthn The last time I built Rakudo on Windows on this machine, there was no configure submodule :) 21:51
Created github.com/rakudo/rakudo/issues/3273
lizmat yeah, perhaps try with a clean checkout ?
jnthn Well, guess a git clean should do the job 21:53
grr, now I have to fix the Makefile again :)
OK, I did have a dirty tree in some way, as the error changed 21:56
Now it's a Makefile screw-up again
+++ Cleaning up outdated MOAR files)@
The filename, directory name, or volume label syntax is incorrect.
NMAKE : fatal error U1077: 'noecho@"C:\Perl64\bin\perl.exe"' : return code '0x1'
21:58 donaldh left 21:59 donaldh joined, donaldh_ joined
jnthn OK, it works with those things fixed. Ticket updated. 22:00
The build system is too clever for me to understand these days, so I'll leave this for somebody who knows it better. :)
The actual reason I was building in the first place was to see if I could replicate the async SSL module issue 22:01
22:03 donaldh left
vrurg jnthn: I was away... No idea how you managed to get unexpanded makefile. 22:05
Did you run Configure.pl and how? 22:06
22:06 donaldh_ left
Geth_ rakudo: 7e7aa2626b | (Vadim Belman)++ | tools/templates/moar/Makefile.in
Added missing @expand()@

Clean up receipe was inserted as-is, unexpanded.		 22:16
vrurg jnthn: ^ that fixes the bug. 22:17
Geth_ ¦ rakudo: vrurg self-assigned Problems building Rakudo with MSVC toolchain on Windows github.com/rakudo/rakudo/issues/3273 22:19
El_Che AlexDaniel: ⏳ 515 out of 1343 modules processed <--- faster than thought 22:23
AlexDaniel: it looks like Blin is sometimes using ssh: "��� Testing Package::Updates (new) 22:33
The authenticity of host 'github.com (140.82.118.3)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)?
vrurg El_Che: some modules use git@github scheme for repos. 22:36
El_Che: that where you get it from.
El_Che vrurg: that will break Blin (or at lease require additional setup, like a .ssh/config
)
AlexDaniel El_Che: uhhh 22:37
vrurg El_Che: it also breaks some user experience as few cannot be installed by zef.
El_Che I can add it to the image, but I'll leave it running for now
AlexDaniel El_Che: yeah I guess it needs to be worked around, but iirc it shouldn't be a big issue
greppable6: git@github 22:38
greppable6 AlexDaniel, 736 lines, 679 modules: gist.github.com/d4a210bfc1a71e2189...7765b5a17d
AlexDaniel hmm…
vrurg That's too many.
AlexDaniel El_Che: yeah I believe we'll need a workaround :( 22:39
without it it's probably making whole trees untestable
El_Che ok, implementing it now 22:43
lots of ssh it seems 22:44
rebuilding the image 22:45
AlexDaniel: we're at "⏳ 712 out of 1343 modules processed", so it's a pitty to stop it. I'll rerun it after it finish it with the ssh fix 23:23
(if you think it's useless without the ssh fix, I'll just ctrl+c it
jnthn vrurg: That was quick turnaround. :) I'll test it. 23:24
It at least fixes the first part of the problem :) 23:25
Wow, I wonder how that didn't bust stuff for other makes... 23:26
vrurg++ 23:28
vrurg jnthn: because it was a recent change and this part is activated only if outdated files are found. Most people are on the new directory layout already. 23:30
So, you're possible the last of the old generation. ;)
*possibly
jnthn It fits; I'd not done a Windows build on this machine in probably a year. :) 23:31
Will see if I can figure out what's going on with that async SSL bug at some point during the weekend. 23:32
vrurg jnthn: do you remember if there is any symbol merging happens on deserialization of longnamed classes? I'm trying to look at R#3075 again and I see that the problem is that a unit with one class gets unmerged stash from another unit with another class only because their names start with Amazon::AWS::EC2. 23:35
jnthn Um, I think I can point you at a probably interesting place to look, if nothing else...
vrurg jnthn: that might be helpful. I'm trying to follow repossession lead, but so far don't see a clue. 23:36
jnthn github.com/rakudo/rakudo/blob/3f69...y.pm6#L332 23:37
I think that code was at some point moved into CORE.setting, meaning it could actually just do an nqp::istype against Stash rather than look at the name :)
(It used to be in module loader, I think.) 23:38
vrurg That's exactly where I'm now.
Geth_ nqp: 2ca92a2f09 | MasterDuke17++ (committed using GitHub Web editor) | docs/ops.markdown
Fix link to Serialization context doc section
jnthn OK :)
vrurg Hope it is because then it'd be easier to fix. Thanks! 23:39
jnthn: BTW, regarding .?+ family of operators – perhaps it would make sense to put them under experimental pragma? 23:41
jnthn Ah, the additional ones? Hmm, I should really review that PR... 23:54
I guess experimental works, but we'd need to make a decision about them at some point 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!