[00:03] *** patrickz joined [00:03] patrickb: the reversal got the problem fixed together with Inline::Perl5. Sorry for the false alarm... :( [00:03] vrurg: No problem! [00:06] *** patrickb left [00:24] *** Kaiepi left [00:25] *** Kaiepi joined [00:29] I'm off to bed. o/ [00:40] *** patrickz left [00:40] *** pmurias left [00:50] *** |Tux| left [01:01] *** ZzZombo joined [01:02] *** Xliff joined [01:02] o/ [01:03] Xliff: o/ [01:06] vrurg: \o [01:14] *** Xliff left [01:20] ¦ rakudo: vrurg++ created pull request #3348: New problem solving 103 [01:20] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3348 [01:55] *** |Tux| joined [02:11] .ask pmurias Is there a known bug in JVM backend with nqp::hash()? I'm getting java.lang.NullPointerException and can't find a workaround. [02:11] vrurg, I'll pass your message to pmurias [02:23] *** lucasb left [02:23] ¦ rakudo/master: 67 commits pushed by (Vadim Belman)++ [02:23] ¦ rakudo/master: review: https://github.com/rakudo/rakudo/compare/215cd49845ae...6c15282630e6 [03:13] *** Xliff joined [05:40] *** ZzZombo_ joined [05:42] *** ZzZombo__ joined [05:42] *** ZzZombo__ left [05:43] *** ZzZombo left [05:43] *** ZzZombo__ joined [05:45] *** ZzZombo_ left [06:06] *** Xliff_ joined [06:08] *** Xliff left [06:09] *** ZzZombo__ is now known as ZzZombo [06:46] *** ufobat joined [08:08] *** Kaiepi left [08:16] *** Kaiepi joined [08:20] *** patrickb joined [08:23] Files=1292, Tests=109640, 210 wallclock secs (28.82 usr 8.12 sys + 2957.07 cusr 266.19 csys = 3260.20 CPU) [08:24] .tell AlexDaniel: I'm thinking about improving our rakudo release texts. Several people have wished for a short "only the highlights" text or list. Maybe adding a respective placeholder to https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft and https://github.com/rakudo/rakudo/blob/master/tools/create-release-announcement.p6 might motivate people [08:24] to write a few words when they implemented something noteworthy. What's your thoughts on this? [08:25] patrickb, I'll pass your message to AlexDaniel [09:24] *** ufobat_ joined [09:27] *** ufobat left [09:42] *** pmurias joined [09:42] vrurg: when are you encountering that bug? [09:42] 2019-12-12T02:11:19Z #raku-dev pmurias Is there a known bug in JVM backend with nqp::hash()? I'm getting java.lang.NullPointerException and can't find a workaround. [09:48] *** sena_kun joined [10:54] *** sena_kun left [11:08] *** sena_kun joined [11:12] *** pmurias left [11:14] <|Tux|> nine++; Inline::Perl5 is working again [11:17] :o [11:17] nice! [11:20] <|Tux|> Rakudo version 2019.11-258-g6c1528263 - MoarVM version 2019.07.1-403-g9442b1a7c [11:20] <|Tux|> csv-test-xs-20 0.432 - 0.439 [11:20] <|Tux|> csv-ip5xs 0.720 - 0.735 [11:20] <|Tux|> test-t --race 0.819 - 0.826 [11:20] <|Tux|> test-t 1.756 - 1.771 [11:20] <|Tux|> csv-ip5xs-20 6.376 - 6.684 [11:20] <|Tux|> test 7.402 - 7.577 [11:20] <|Tux|> test-t-20 --race 9.558 - 9.746 [11:20] <|Tux|> csv-parser 22.736 - 24.453 [11:20] <|Tux|> test-t-20 29.736 - 30.631 [12:19] *** pmurias joined [12:26] |Tux|: Actually it was vrurg that fixed Inline:Perl5 again... [12:36] *** pmurias left [12:38] *** pmurias joined [12:44] <|Tux|> vrurg++; # for good measure [12:54] *** sena_kun left [13:09] *** sena_kun joined [13:34] *** ufobat_ is now known as ufobat [13:47] *** pmurias left [13:49] so what's the verdict wrt camelia? seems to be awol for a week now ? [13:49] m: dd "foo".Numeric [13:49] lizmat, rakudo-moar 6c1528263: OUTPUT: «Failure.new(exception => X::Str::Numeric.new(source => "foo", pos => 0, reason => "base-10 number must begin with valid digits or '.'"), backtrace => Backtrace.new)␤» [13:50] m: dd "42foo".Numeric [13:50] lizmat, rakudo-moar 6c1528263: OUTPUT: «Failure.new(exception => X::Str::Numeric.new(source => "42foo", pos => 2, reason => "trailing characters after number"), backtrace => Backtrace.new)␤» [14:02] *** pmurias joined [14:06] *** lucasb joined [14:07] m: dd "".Numeric [14:07] lizmat, rakudo-moar 6c1528263: OUTPUT: «0␤» [14:10] sorry for the noise, but you can't privmsg evalable6 :-( [14:10] you *could* camelia [14:10] who used to host camelia? [14:10] lizmat: you can also privmsg perlbot [14:10] hey AlexDaniel, you have a message: https://gist.github.com/e4419243cbe40809de9efb0420bc45a1 [14:11] where is it though… [14:12] lizmat: you can also join #whateverable and use all the bots there [14:12] yeah, but that still would create linenoise for other people [14:12] that's why I like privmsg camelia so much [14:13] #whateverable is mostly bots [14:13] I don't have to stash my code, and re-compile to see current behaviour [14:15] patrickb: try it [14:15] patrickb: we'll see how it goes [14:17] pmurias: still around? [14:25] vrurg: yep [14:27] pmurias: I didn't managed to golf it down, but the location is src/Perl6/Metamodel/C3MRO.nqp, line 86 [14:28] pmurias: It breaks build, as it turns out. Feels like a regression because a build as of a month-month and a half ago was passing. [14:29] Or something new is triggering it. [14:32] vrurg: that line itself is causing problems? [14:34] Any combination of storing two-level hashes into it. As a single statement, as it is now. Was replacing %!mro with $!mro. Was storing in a few consequent statements. Nothing helps. [14:35] pmurias: I even tried making it a single-level hash. [14:41] vrurg: where is the bug trigged? [14:41] pmurias: It happens when I build jvm backend on macos, fails on CORE.c building. [14:42] What I didn't test yet is linux build. [14:44] vrurg: the bug is caused when executing that line? [14:45] java.lang.NullPointerException in compute_mro (gen/jvm/Metamodel.nqp:1240) [14:45] There is a strange thing though: it always happens before returning from the method. [14:46] Because even when it was a multi-statement assignment, the error was pointing at the last statement. If I was commenting that out then the error pointed at the last uncommented one. [14:54] *** sena_kun left [14:55] pmurias: Linux build dies with the same error. So, it's not platform dependent. [15:08] vrurg: do you have a full stack trace? [15:08] *** sena_kun joined [15:14] pmurias: https://gist.github.com/vrurg/8357c16c419c293e0953240b31ad20f1 [15:15] *** nine left [15:15] Not for the Java side, of course. [15:16] *** nine joined [15:16] vrurg: if I checkout rakudo and run Configure.PL --backends=jvm --gen-nqp I should replicate the problem? [15:17] pmurias: No doubt. [15:19] *** camelia joined [15:19] m: say "I'm back!" [15:20] Well that's not too promising ... [15:20] rakudo-moar 672c5d403: OUTPUT: «I'm back!␤» [15:20] Just took a while to warm up :) [15:20] m: say "much faster now" [15:20] rakudo-moar 672c5d403: OUTPUT: «much faster now␤» [15:21] lizmat: ^^^ [15:21] whee! [15:21] :-) [15:21] Bad news is that I still do not have a clue what the issue was. This was at least the second time that the VM lost its network connection and only a reboot of the host solved it [15:21] nine++ # I presume ? [15:26] nine++ # indeed :-) [15:50] nine: weird things happen all the time, it's not a biggie tbh [15:51] vrurg: I can reproduce it, I'll try to see what could be causing that [15:58] vrurg: the error is misreported [15:59] vrurg: I have to run and I'll look into it later but buy inserting say statements it seems that it's not that hash thing causing errors but something else [16:01] grrr.... so I have the situation that *every* spectest file fails during a make t/spec/foo/bar.t [16:02] but runs without problem with raku t/spec/foo/bar.t [16:02] only response: [16:02] Dubious, test returned 1 (wstat 256, 0x100) [16:02] No subtests run [16:02] suggestions on getting more info ? [16:07] *** pmurias left [16:16] *** patrickb left [16:21] nine jnthn ^^^ ?? [16:22] lizmat: But `make spectest` itself works out fine? [16:23] nope, *all* tests-file fail with "No plan found in TAP output" [16:24] With local changes, or? [16:24] yeah, a rewrite of val() logic :-) [16:26] so there is no way to show the actual test output when doing "make" ? [16:27] lizmat: actually, it runs harness with `--verbosity=1`. [16:27] lizmat: and no redirections of any kind are used. [16:27] Needs TEST_JOBS=1 [16:27] also for a single file make ?? [16:28] oh, probably not in that case [16:28] but that *does* actually give me output :-) [16:32] and something I can use :-) [16:43] *** ZzZombo_ joined [16:43] *** Xliff_ left [16:44] *** ZzZombo left [16:44] *** ZzZombo_ is now known as ZzZombo [16:48] *** robertle joined [16:53] *** sena_kun left [16:59] *** ZzZombo left [17:00] *** ZzZombo joined [17:08] *** sena_kun joined [17:23] *** ExtraCrispy joined [18:42] *** patrickb joined [18:45] I'd like to bring the topic of renaming rakudobrew -> rakubrew up again. [18:46] I'm on the last steps of a huge refactor of rakudobrew. The installation procedure will change, the update procedure will change. It will have a website. [18:46] So anyone migrating from previous rakudobrew to the new one will have to re-setup his installation. [18:47] Also all repositories will change because rakudobrew will move to its own github project. [18:51] I believe having it named rakubrew can help in reducing confusion, especially of newcomers. [18:52] Also (even though I think that's totally irrelevant) it's less typing. :-) [18:53] nine, tadzik, AlexDaniel, whoever wants to join the bikeshedding: ^ [18:54] patrickb: either you're ready to support more compilers if they ever come or it remains rakudobrew. I think it is as simple as this. :) [18:54] *** sena_kun left [18:54] I don't think you need to be ready to support anything [18:55] at least that's what I understood from the last conversations regarding raku/rakudo [18:55] see https://github.com/perl6/problem-solving/issues/124 [18:57] AlexDaniel: I agree it doesn't have much relevance at the moment. My biggest concern is that we are currently throwing around raku and rakudo at the same time. That causes confusion. [18:57] There is Ruby + rubyenv, perl + perlbrew + plenv, python + pyenv. [18:57] That's a concept people expect. [18:58] Calling it rakubrew will bring in even more confusion if it won't play well with other potential compilers. [18:58] People talk about Java. Rarely about Hotspot or J9. [18:58] patrickb: you miss the point that every project mentioned has one single implementation which is the language. [18:59] Ruby has a JVM implementation. Python has JVM and Pypy. [18:59] patrickb: ok, other way around: their executables are named after the language, after all. [19:00] Java has jenv [19:00] I'm find with rakubrew if it won't mind adding any new compiler would it ever pop up on the horizon. :) [19:00] *I'm fine [19:01] Same with raku. We do have a rakudo executable to help us stay clean once multiple implementations show up. But we do provide a `raku`. I'm very convinced that's what people will use. [19:02] patrickb: I already do. :D [19:03] vrurg: May I ask why? [19:03] Drifting away from perl6. Though I better be using rakudo because I often depend on internal implementation. [19:04] My new project specifically tests for 2019.11 compiler release. [19:04] I think renaming to raku will help a big deal in confusing people less, because they immediately understand that rakudo is related to raku. [19:05] ^that statement was about the perl6 -> raku rename [19:05] Maybe. Anyway, `rakubrew -c 3rdparty-implementation` at some point if needed? [19:06] vrurg: I intend to have it support any relevant implementation that pops up. [19:06] I have actually added aliases build -> build-rakudo, download -> download-rakudo in my branch. [19:06] I can tell you another good reason why rakubrew is a good move in your case. It's easier to grasp that it has to be reconfigured. Everything new, you know... [19:07] Rename it. Period. Go for it! :D :D :D [19:08] I hope some tool like this would eventually replace rakudostar and will become the method by default for newbies. [19:08] I at least want this discussion to be noticed by tadzik and nine. They were part of the last iteration. I really don't want to just force the rename over tadzik. [19:09] vrurg: Did you see the staging rakudo.org website? [19:09] *** sena_kun joined [19:09] vrurg: https://stage-rakudo.rakulang.site/ [19:09] It changes some aspects wrt rakudo star [19:12] patrickb: I think if the old project will be archived with BIG RED SENTENCES about where to search for the new location, then no problems, no? [19:13] patrickb: sorry, my English betrays me here. I don't understand what you mean. :( [19:13] sena_kun: I'd think so too. We'll have to do that anyways as the repository changes in every case. [19:14] I think he's talking about the move of the repository / website. We'll have to add a note to the old repository / website to point to the new one. [19:15] patrickb: if you are about renaming the repository, then pls no. creating a new one and pointing old->new is a nice way to do things without confusing everything. [19:15] sena_kun: I don't intend to rename. [19:16] Plan is to add a "rakubrew" project and a "App-Rakubrew" repository. [19:18] patrickb: in a separate github org? [19:18] AlexDaniel: Yes [19:18] why everyone wants to create a separate github org for every single project? What am I missing? [19:18] AlexDaniel: Where would you put it? [19:19] AlexDaniel: propose to use Raku org? I'd be in support of that. [19:19] patrickb: https://github.com/Raku [19:19] patrickb: ^^^ :D [19:19] * sena_kun increments using raku org for new projects [19:19] yeah and also we should start moving stuff, I know I promised it before but I'm currently low on time [19:19] AlexDaniel: That would give it "official" character. That would a tiny bit stomp on alternative projects. [19:20] patrickb: alternative projects can also be moved to Raku, I see no problem [19:20] There once was a pl6env project. I can't find any reference to it anymore. Seems the author has removed it completely including the repo. [19:21] https://github.com/skaji/p6env <- this? [19:21] sena_kun: Thanks! Then I was wrong! I'm kind of relieved. [19:21] yw [19:22] I don't think that having everything in a single org stops anyone from doing anything [19:22] having stuff in different orgs is an everyday nuisance [19:22] patrickb: about "official" character - from my point of view, making it under `raku` org itself makes it pretty official. and a separate org means it is something like a separate kind of tool. [19:23] if you consider something to be your own project that you want to have full control of, then sure, fine [19:23] I don't have a very strong opionion on whether this gets it's own org or not. [19:23] but otherwise /Raku should be the default location [19:27] especially if you call it rakubrew, IMHO [19:29] Seems people favor having it in /raku. I'm ok with that. [20:16] Another bikeshedding topic: Any reason I should use a version number other than a single integer for rakubrew? (It's a Perl 5 project) [20:23] *** pmurias joined [20:29] patrickb: you mean `rakubrew --version` --> '10`? [20:31] I think that doesn't exist yet, not sure if `--version` is even needed. I'll mainly use it to guide the self-update process. Might also display it on the website. [20:32] I don't want to place a big emphasis on the version from the user perspective. They are meant to always just use the latest version. [20:33] patrickb: I'd stick to what Version understands. [20:37] vrurg: the raku Version class seems to be fine with integers. [20:37] m: my $v = Version.new: '1'; $v.Str [20:37] rakudo-moar 672c5d403: ( no output ) [20:38] m: my $v = Version.new: '1'; say $v.Str [20:38] rakudo-moar 672c5d403: OUTPUT: «1␤» [20:38] patrickb: I meant Perl's Version. But it should be fine with it too. [20:41] vrurg: This? https://metacpan.org/pod/CPAN::Version [20:42] *** robertle left [20:43] patrickb: oh, sorry, it's just 'version', without the first capitalization. [20:45] I'm having a hard time finding documentation for it. https://metacpan.org/pod/version < this states 'version' was added in Perl 5.10. perldoc is silent about it... [20:45] patrickb: perl -wE 'use version; my $v = version->declare("1") works fine. [20:45] perldoc version – works for me. [20:47] vrurg: For me this returns the same documentation i just linked. Anyways, thanks for checking! [20:48] np [20:49] patrickb: what do you think about something like `rakubrew default` which would install what rakudostar currently installs? I.e. latest release, zef and a bunch of most useful modules. [20:50] I have implemented a 'download' that installs a precompiled rakudo which already includes zef. [20:51] I do oppose preinstalling modules slightly (and the entire rakudo star concept for that matter). It encourages not learning how to use a module installer and the ecosystem in general. [20:53] patrickb: Don't push on a user. Get him involved first. Give him an easy start. Most of them will proceed from the moment on. [20:54] Sidenote: That rakubrew download option takes about 3-5 seconds to get a raku installed and ready to use. (I'm using a local rakudo.org, so download times are minimal, but still). [20:54] Be like a drug dealer: give him the first dose free! ;) [20:55] *** sena_kun left [20:55] Best thing to do, from my point of view, is to install some bare bones set of modules. When installation is done print a message like "want more? Do 'zef install Module'" [20:56] vrurg: Thinking about it. Could call it 'install-star-bundle'. [20:57] Long and unclear. Must be short and easy to remember. `install-default`, `install-base`. But definitely not 'star' because my view is that rakudostar would be gone at some point. [21:00] I think we should keep the number of different module bundles as low as possible. Currently we only have the star bundle as a defined set of modules. [21:01] We might work towards a model similar to how perl handles it - having a very official base set of modules. [21:01] Then 'install-base' would be a fitting name. [21:02] But I don't like the idea of just throwing out another - different - module compilation. [21:05] patrickb: Try to step aside of own experience. Put yourself into shoes of a beginner. He needs a quick start, a playground. Give it to him! [21:06] Wether he'd stick with Raku after that or not – it's out of our hands. But if we push on him from the start to learn one thing after another – that'd might scary them away. [21:08] *** sena_kun joined [21:11] ¦ nqp: vrurg++ created pull request #591: An attempt to fix nqp-runtime.jar dependency [21:11] ¦ nqp: review: https://github.com/perl6/nqp/pull/591 [21:12] .ask pmurias Could you pls try and see if https://github.com/perl6/nqp/pull/591 fixes nqp-runtime.jar problem? [21:12] vrurg, I'll pass your message to pmurias [21:13] m: BEGIN @*ARGS = "2*10**3"; sub MAIN(Int:D $a) { dd $a } # TIL I learned that this actually works [21:14] rakudo-moar 672c5d403: OUTPUT: «IntStr.new(2000, "2*10**3")␤» [21:18] oh wow [21:18] * moritz surprised [21:18] then I guess the other crazy stuff works too [21:23] m: BEGIN @*ARGS = "-1/-2*-10**+10"; sub MAIN(Rat:D $a) { dd $a } [21:23] rakudo-moar 672c5d403: OUTPUT: «RatStr.new(0.00000000005, "-1/-2*-10**+10")␤» [21:24] yes... the wonders of val() [21:24] which I'm refactoring atm, should become at least 2x as fast [21:25] .oO( also 2x as incompatible (hopefully?) ) [21:25] just kidding :) [21:26] well, I think the Failures will become less informative in the sense that they only show where it went wrong [21:26] not what was expected [21:26] but that could still change :-) [21:29] m: dd <-1/-2*-10**+10> [21:29] rakudo-moar 672c5d403: OUTPUT: «RatStr.new(0.00000000005, "-1/-2*-10**+10")␤» [21:29] *** [Tux] left [21:31] IIRC there are even weirder cases with complex numbers :) [21:32] m: dd <2*10**3+2*10**3i> # indeed [21:32] rakudo-moar 672c5d403: OUTPUT: «ComplexStr.new(<2000+2000i>, "2*10**3+2*10**3i")␤» [21:35] m: dd <-2*-10**+3-2*-10**+3i> [21:35] rakudo-moar 672c5d403: OUTPUT: «ComplexStr.new(<2000+2000i>, "-2*-10**+3-2*-10**+3i")␤» [21:35] there was also a bug somewhere letting you have the minus sign twice [21:35] maybe it's already fixed, I'm not sure [21:35] probably not... but who knows :-) [21:43] *** [Tux] joined [21:48] *** pmurias left [21:48] *** sena_kun left [21:54] *** pmurias joined [22:01] * lizmat is off to watch the BBC and get depressed :-( [23:08] *** vrurg left [23:08] *** vrurg joined [23:13] *** pmurias left [23:34] *** pmurias joined [23:47] I wonder why rakudo still builds against moar 2019.07.1?