[02:19] ¦ problem-solving: vrurg assigned to jnthn Issue export trait must operate with declared package name https://github.com/perl6/problem-solving/issues/142 [02:29] *** Voldenet left [02:36] *** Voldenet joined [02:36] *** Voldenet left [02:36] *** Voldenet joined [02:48] ¦ rakudo: vrurg++ created pull request #3388: Export packages by user given names [02:48] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3388 [02:57] .ask jnthn if you have a few spare minutes, I'd like you to have a look at https://github.com/perl6/problem-solving/issues/142. It's really simple problem but requires a little change in `is export` semantics and therefore needs a review. [02:57] vrurg, I'll pass your message to jnthn [03:11] *** Xliff joined [03:11] . [03:11] 2019-12-29T02:23:09Z #raku Xliff no, it won't work this way because you'd need to override RoleToClassApplier and somehow make the default compose use it which is... er... hard considering that the default is part of the core MOP. :) [03:11] *** Xliff left [03:12] *** Xliff joined [03:28] vrurg: OK, so let's remove some complexity and write a single wrapper and pin it right before object compose? [03:29] .tell vrurg OK, so let's try another tack --> https://github.com/Xliff/Method-Also/blob/proto-role-fix-again/lib/Method/Also.pm6#L16 [03:29] Xliff, I'll pass your message to vrurg [03:31] Xliff: sorry, I'm busy with another problem now. But I would insist that the way to go for you is to override add_concretization and deal with concrete roles which would a bit later be applied to the class with RoleToClassApplier. [03:32] vrurg: OK. Well that's another option I can try after this one. [03:32] vrurg: Good luck with your problem. [03:33] The reason is that add_concretization knows the target class we operate upon, so you would have access to class' proto method if it exists. [03:33] Hmmm.... How can I refer to "self" in the body of .^add_method ? [03:34] Xliff: Just use self. :) It points to the MOP object. The first argument would point to the Raku typeobject you operate upon. [03:35] Yeah. I want the raku typeobject, not the MOP [03:35] `.^` calls are equivalent to obj.HOW.method(obj) [03:35] * vrurg was confused with this concept for a while too. :) [03:37] So... [03:38] o.^add_method($alias, -> |c { o."{ $not-alias }"( |c.list.skip(1), |c.hash ) } [03:38] ^^ Passes tests! \o/ [04:00] *** Merfont joined [04:00] *** Kaeipi left [05:07] *** evalable6 left [05:09] *** evalable6 joined [07:52] *** vrurg left [08:38] *** sena_kun joined [10:30] Files=1294, Tests=109635, 210 wallclock secs (27.83 usr 8.18 sys + 2964.15 cusr 268.96 csys = 3269.12 CPU) [10:41] *** sena_kun left [10:56] *** sena_kun joined [10:57] *** Voldenet left [11:04] *** Voldenet joined [11:04] *** Voldenet left [11:04] *** Voldenet joined [11:09] *** Voldenet left [11:15] *** Voldenet joined [11:15] *** Voldenet left [11:15] *** Voldenet joined [12:39] m: dd i [12:39] rakudo-moar 672c5d403: OUTPUT: «<0+1i>␤» [12:39] m: dd [12:39] rakudo-moar 672c5d403: OUTPUT: «"i"␤» [12:39] should that also be a allomorph, or not ? [12:40] note: some spectests break when becomes an allomorph [12:41] *** sena_kun left [12:52] lizmat: I think that's a weird question to ask [12:52] < > feature is completely unpredictable so it doesn't matter [12:52] if spectests break then don't touch it [12:54] I don't think you can generally say that [12:54] spectests have been known to be wrong, or depend on buggy behaviour [12:55] and to be able to specify "i" on the command line to indicate 0+1i, could be considered a useful feature [12:55] *** sena_kun joined [12:57] ¦ rakudo: efadff2a39 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6 [12:57] ¦ rakudo: Fix "expected IO::Handle:D but got IO::Handle" in parallel test runs [12:57] ¦ rakudo: [12:57] ¦ rakudo: When a process tries to precompile a dependency and finds that a different [12:57] ¦ rakudo: process already does (e.g. test files run in parallel), it closes the [12:57] ¦ rakudo: precompilation unit as to not leak the open file handle. However when it tries [12:57] ¦ rakudo: to use the generated precomp file, it didn't re-open the file handle, because [12:57] ¦ rakudo: the $!initialized flag on the precomp unit stayed on True. [12:57] ¦ rakudo: Fix by re-setting $!initialized, so we actually try to open the file again. [12:57] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/efadff2a39 [12:58] Glad I got rid of that. make test failing once after every change to NativeCall got on my nerves... [12:58] nine++ [12:58] AlexDaniel: tests failing such as: [13:00] m: use Test; is-deeply "Camelia".comb, [13:00] rakudo-moar 672c5d403: OUTPUT: «ok 1 - ␤» [13:00] # expected: $("C", "a", "m", "e", "l", ComplexStr.new(<0+1i>, "i"), "a") [13:00] # got: $("C", "a", "m", "e", "l", "i", "a") [13:00] lizmat: anything can be considered a useful feature, doesn't mean that it won't hurt in other ways. I don't know if in an ideal world < > would exist at all [13:01] lizmat: being able to pass non-integers on a command line is a security risk by itself anyway [13:01] in this case we're talking about Complex numbers and honestly most people don't care about them… [13:01] but that test is a good one [13:01] m: use Test; is-deeply "Camelia".comb, ("C","a","m","e","l","i","a") # proper testing [13:01] rakudo-moar 672c5d403: OUTPUT: «ok 1 - ␤» [13:01] it shows that you shouldn't do that change [13:02] I think it shows that the test writer didn't fully understand < a b c >'s functionality [13:03] yeah, that's right [13:03] and that's something we never think about, somehow [13:03] that the language should be predictable and easy to understand [13:04] but what about: [13:05] m: dd +"42.2e10" [13:05] rakudo-moar 672c5d403: OUTPUT: «422000000000e0␤» [13:05] m: dd +"-i" [13:05] rakudo-moar 672c5d403: OUTPUT: «Failure.new(exception => X::Str::Numeric.new(source => "-i", pos => 1, reason => "base-10 number must begin with valid digits or '.'"), backtrace => Backtrace.new)␤» [13:05] m: dd +"Inf" [13:05] rakudo-moar 672c5d403: OUTPUT: «Inf␤» [13:05] this is also val() processing [13:07] those who need complex numbers will figure out how to get their “i” parsed [13:08] sourceable6: val(‘42’) [13:08] AlexDaniel, https://github.com/rakudo/rakudo/blob/efadff2/src/core.c/allomorphs.pm6#L236 [13:10] lizmat: but if we're talking about examples, here's one [13:10] perl6 -e 'sub MAIN(Int:D $a) { spurt “file-with-id-$a”, 42; }' :100[10] [13:10] so you can be expecting a defined Int passed as an argument [13:10] which is a reasonable expectation, I think [13:11] and all is fine unless you forget that any time you use your defined int in string context it can be something completely else [13:12] yeah, you can of course argue that the programmer in this case is an idiot and “didn't fully understand” something [13:12] but on a scale of predictability this is somewhere in the “wtf?” range [13:15] last time I proposed simplifying something people wondered why there's so much talk about removing things lately [13:15] and honestly I don't have enough energy for that [13:16] I do think that we should be focusing on making raku easier to understand and learn [13:17] and yes that includes removing a bunch of bloat that doesn't bring enough value [13:17] but good luck convincing people that this is the direction we should go, they'd much rather add even more features [13:19] quick thoughts on the topic: < > should be a string splitter, « » shouldn't exist, and val should have very simple and well defined functionality [13:21] you can move val's functionality into something else, call it laxval or whatever [13:23] and then don't use it by default anywhere, of course :) [13:24] fwiw, I can see the use if val() processing in %*ENV and command line parameters [13:24] I tend to agree that val processing in general for < a b c > might be a WAT for a lot of people [13:25] lizmat: no [13:25] no? [13:25] the use is what, doing calculations? [13:25] if so then slap a calculator on MAIN's arguments [13:26] don't pass a crazy IntStr into user's code [13:26] but you want MAIN(Int $a) to work [13:26] yeah, calculate and pass a pure Int [13:26] maybe something that can be done in a module [13:27] MAIN::Calculator or whatever [13:27] it can already be done in a module [13:27] lizmat: yes [13:27] so which “use” are we talking about then? [13:28] a lot of software allows calculations in fields [13:28] e.g. in image processing software you can often do some basic math [13:28] the fact that you can use MAIN with non-Str types in candidates' signuatures [13:28] that's fine and useful, but val() is not that [13:29] lizmat: yeah, I agree [13:29] but should you be able to pass :100[10] ? [13:29] when there's Int:D in a signature? [13:29] yeah, that's a question [13:29] you can atm [13:30] I know, and that's exactly my point, you shouldn't be able to do that [13:33] so what is your stance on allomorphs in general ? [14:01] I have to run now, sry [14:03] lizmat: allomorphs in general are fine, I think [14:04] lizmat: as long as it's expected that you will get one [14:04] so how would you create them then ? [14:05] by the way [14:05] m: sub foo(Int() $a) { say $a.WHAT }; foo(‘:100[10]’) [14:05] rakudo-moar 672c5d403: OUTPUT: «(Int)␤» [14:05] this is something I would have expected MAIN to do [14:06] I'm not sure where this difference comes from [14:06] Str.Int calls Numeric, and that uses val() processing [14:06] but at least you got an Int [14:06] well, essentially Str.Int is really Str.Numeric.Int [14:09] also afk& [14:12] there's definitely some practical use for IntStrs but we should figure out what it is exactly [14:13] I think that by design there were certain expectations on how people will use < > feature [14:13] but do people actually use it that way? I don't think so… [14:15] also we currently don't allow stuff like `my Int() $x` [14:16] once it's implemented it can change a bit what people use and how they expect things to behave [14:17] but yeah, it's a good question, what's the actual benefit of IntStr's [14:18] they allow Strs to pass through your code until you do any numeric operation with them [14:19] but why? [14:33] *** AlexDaniel left [14:41] *** sena_kun left [14:56] *** sena_kun joined [16:31] *** dogbert2 left [16:32] *** dogbert2 joined [16:41] *** sena_kun left [16:57] *** sena_kun joined [18:08] *** |Tux| left [18:11] *** |Tux| joined [18:39] *** vrurg joined [18:42] *** sena_kun left [18:57] *** sena_kun joined [19:36] *** AlexDaniel joined [19:36] *** AlexDaniel left [19:36] *** AlexDaniel joined [19:55] *** dogbert11 joined [19:56] *** stoned75 joined [19:56] hi ! [19:58] *** dogbert2 left [19:59] I'd like someone to review a commit in doc repository. Should I do I PR from a branch in my own clone the repository or can I do a PR on a branch I would create in the origin doc repository. what's the prefered way ? [20:09] I made a PR from my clone :) [20:15] stoned75: there is no preferred way, but for docs it is simply easier to make it from original repo [20:26] ok, noted. thanks! [20:40] *** sena_kun left [20:52] ¦ nqp: 21eab30285 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION [20:52] ¦ nqp: [MoarVM Bump] Brings 4 commits [20:52] ¦ nqp: [20:52] ¦ nqp: MoarVM bump brought: https://github.com/MoarVM/MoarVM/compare/2019.11-99-g7ab23a1b8...2019.11-103-g2ac1fa27f [20:52] ¦ nqp: 2ac1fa27f Fix race condition with multi threaded NativeCall users [20:52] ¦ nqp: e224567df Update ChangeLog for 2019.12 release [20:52] ¦ nqp: ae66545c7 Fix segfaults after callbacks originating in JIT compiled calls to native code [20:52] ¦ nqp: 41708648c Revert "Workaround for segfault somehow caused by NativeCall callbacks" [20:52] ¦ nqp: review: https://github.com/perl6/nqp/commit/21eab30285 [20:52] ¦ rakudo: a5fdf1d3ca | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION [20:52] ¦ rakudo: [NQP Bump] 21eab3028 [MoarVM Bump] Brings 4 co […] [20:52] ¦ rakudo: [20:53] ¦ rakudo: NQP bump brought: https://github.com/perl6/nqp/compare/2019.11-32-gac4b11d43...2019.11-33-g21eab3028 [20:53] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a5fdf1d3ca [20:56] *** sena_kun joined [21:23] ¦ rakudo: 131d253a20 | (Christian Bartolomäus)++ | src/core.c/Rakudo/Iterator.pm6 [21:23] ¦ rakudo: [JVM] Restore old implementation of 'lazy gather' [21:23] ¦ rakudo: [21:23] ¦ rakudo: The performance optimization of 971174f4d8 broke things on the JVM [21:23] ¦ rakudo: backend. This is a known problem with nqp::null getting HLLized [21:23] ¦ rakudo: showing up again -- cmp. https://github.com/rakudo/rakudo/issues/1613 [21:23] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/131d253a20 [21:37] *** stoned75 left [21:46] bartolin++ [21:55] *** moritz left [21:55] *** moritz joined [22:12] ¦ roast: 2cc22d24d6 | (Elizabeth Mattijsen)++ | S32-str/val.t [22:12] ¦ roast: Also test with just a space after expression [22:12] ¦ roast: review: https://github.com/perl6/roast/commit/2cc22d24d6 [22:29] *** stoned75 joined [22:42] *** sena_kun left [22:56] *** sena_kun joined