Geth_ ¦ problem-solving: vrurg assigned to jnthn Issue export trait must operate with declared package name github.com/perl6/problem-solving/issues/142 02:19
02:29 Voldenet left 02:36 Voldenet joined, Voldenet left, Voldenet joined
Geth_ rakudo: vrurg++ created pull request #3388:
Export packages by user given names		 02:48
vrurg .ask jnthn if you have a few spare minutes, I'd like you to have a look at 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
tellable6 vrurg, I'll pass your message to jnthn
03:11 Xliff joined
Xliff . 03:11
tellable6 2019-12-29T02:23:09Z #raku <vrurg> 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
Xliff vrurg: OK, so let's remove some complexity and write a single wrapper and pin it right before object compose? 03:28
.tell vrurg OK, so let's try another tack --> github.com/Xliff/Method-Also/blob/...so.pm6#L16 03:29
tellable6 Xliff, I'll pass your message to vrurg
vrurg 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:31
Xliff vrurg: OK. Well that's another option I can try after this one. 03:32
vrurg: Good luck with your problem.
vrurg 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
Xliff Hmmm.... How can I refer to "self" in the body of .^add_method ?
vrurg Xliff: Just use self. :) It points to the MOP object. The first argument would point to the Raku typeobject you operate upon. 03:34
Xliff Yeah. I want the raku typeobject, not the MOP 03:35
vrurg `.^` calls are equivalent to obj.HOW.method(obj)
vrurg was confused with this concept for a while too. :)
Xliff So... 03:37
o.^add_method($alias, -> |c { o."{ $not-alias }"( |c.list.skip(1), |c.hash ) } 03:38
^^ Passes tests! \o/
04:00 Merfont joined, Kaeipi left 05:07 evalable6 left 05:09 evalable6 joined 07:52 vrurg left 08:38 sena_kun joined
lizmat Files=1294, Tests=109635, 210 wallclock secs (27.83 usr 8.18 sys + 2964.15 cusr 268.96 csys = 3269.12 CPU) 10:30
10:41 sena_kun left 10:56 sena_kun joined 10:57 Voldenet left 11:04 Voldenet joined, Voldenet left, Voldenet joined 11:09 Voldenet left 11:15 Voldenet joined, Voldenet left, Voldenet joined
lizmat m: dd i 12:39
camelia <0+1i>
lizmat m: dd <i>
camelia "i"
lizmat should that also be a allomorph, or not ?
note: some spectests break when <i> becomes an allomorph 12:40
12:41 sena_kun left
AlexDaniel lizmat: I think that's a weird question to ask 12:52
< > feature is completely unpredictable so it doesn't matter
if spectests break then don't touch it
lizmat I don't think you can generally say that 12:54
spectests have been known to be wrong, or depend on buggy behaviour
and to be able to specify "i" on the command line to indicate 0+1i, could be considered a useful feature 12:55
12:55 sena_kun joined
Geth_ rakudo: efadff2a39 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Fix "expected IO::Handle:D but got IO::Handle" in parallel test runs

When a process tries to precompile a dependency and finds that a different process already does (e.g. test files run in parallel), it closes the precompilation unit as to not leak the open file handle. However when it tries to use the generated precomp file, it didn't re-open the file handle, because the $!initialized flag on the precomp unit stayed on True. Fix by re-setting $!initialized, so we actually try to open the file again.		 12:57
nine Glad I got rid of that. make test failing once after every change to NativeCall got on my nerves... 12:58
lizmat nine++
AlexDaniel: tests failing such as:
m: use Test; is-deeply "Camelia".comb, <C a m e l i a> 13:00
camelia ok 1 -
lizmat # expected: $("C", "a", "m", "e", "l", ComplexStr.new(<0+1i>, "i"), "a")
# got: $("C", "a", "m", "e", "l", "i", "a")
AlexDaniel 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
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…
but that test is a good one
lizmat m: use Test; is-deeply "Camelia".comb, ("C","a","m","e","l","i","a") # proper testing
camelia ok 1 -
AlexDaniel it shows that you shouldn't do that change
lizmat I think it shows that the test writer didn't fully understand < a b c >'s functionality 13:02
AlexDaniel yeah, that's right 13:03
and that's something we never think about, somehow
that the language should be predictable and easy to understand
lizmat but what about: 13:04
m: dd +"42.2e10" 13:05
camelia 422000000000e0
lizmat m: dd +"-i"
camelia Failure.new(exception => X::Str::Numeric.new(source => "-i", pos => 1, reason => "base-10 number must begin with valid digits or '.'"), backtrace => Backtrace.new)
lizmat m: dd +"Inf"
camelia Inf
lizmat this is also val() processing
AlexDaniel those who need complex numbers will figure out how to get their “i” parsed 13:07
sourceable6: val(‘42’) 13:08
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/efad...s.pm6#L236
AlexDaniel 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]
so you can be expecting a defined Int passed as an argument
which is a reasonable expectation, I think
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:11
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
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
I do think that we should be focusing on making raku easier to understand and learn 13:16
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
quick thoughts on the topic: < > should be a string splitter, « » shouldn't exist, and val should have very simple and well defined functionality 13:19
you can move val's functionality into something else, call it laxval or whatever 13:21
and then don't use it by default anywhere, of course :) 13:23
lizmat 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
AlexDaniel lizmat: no 13:25
lizmat no?
AlexDaniel the use is what, doing calculations?
if so then slap a calculator on MAIN's arguments
don't pass a crazy IntStr into user's code 13:26
lizmat but you want MAIN(Int $a) to work
AlexDaniel yeah, calculate and pass a pure Int
maybe something that can be done in a module
MAIN::Calculator or whatever 13:27
lizmat it can already be done in a module
AlexDaniel lizmat: yes
so which “use” are we talking about then?
a lot of software allows calculations in fields 13:28
e.g. in image processing software you can often do some basic math
lizmat the fact that you can use MAIN with non-Str types in candidates' signuatures
AlexDaniel that's fine and useful, but val() is not that
lizmat: yeah, I agree 13:29
but should you be able to pass :100[10] ?
when there's Int:D in a signature?
lizmat yeah, that's a question
you can atm
AlexDaniel I know, and that's exactly my point, you shouldn't be able to do that 13:30
lizmat so what is your stance on allomorphs in general ? 13:33
AlexDaniel I have to run now, sry 14:01
lizmat: allomorphs in general are fine, I think 14:03
lizmat: as long as it's expected that you will get one 14:04
lizmat so how would you create them then ?
AlexDaniel by the way 14:05
m: sub foo(Int() $a) { say $a.WHAT }; foo(‘:100[10]’)
camelia (Int)
AlexDaniel this is something I would have expected MAIN to do
I'm not sure where this difference comes from 14:06
lizmat Str.Int calls Numeric, and that uses val() processing
AlexDaniel but at least you got an Int
lizmat well, essentially Str.Int is really Str.Numeric.Int
also afk& 14:09
AlexDaniel there's definitely some practical use for IntStrs but we should figure out what it is exactly 14:12
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…
also we currently don't allow stuff like `my Int() $x` 14:15
once it's implemented it can change a bit what people use and how they expect things to behave 14:16
but yeah, it's a good question, what's the actual benefit of IntStr's 14:17
they allow Strs to pass through your code until you do any numeric operation with them 14:18
but why? 14:19
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, AlexDaniel left, AlexDaniel joined 19:55 dogbert11 joined 19:56 stoned75 joined
stoned75 hi ! 19:56
19:58 dogbert2 left
stoned75 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 ? 19:59
I made a PR from my clone :) 20:09
sena_kun stoned75: there is no preferred way, but for docs it is simply easier to make it from original repo 20:15
stoned75 ok, noted. thanks! 20:26
20:40 sena_kun left
Geth_ nqp: 21eab30285 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
[MoarVM Bump] Brings 4 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g2ac1fa27f 2ac1fa27f Fix race condition with multi threaded NativeCall users e224567df Update ChangeLog for 2019.12 release ae66545c7 Fix segfaults after callbacks originating in JIT compiled calls to native code 41708648c Revert "Workaround for segfault somehow caused by NativeCall callbacks"		 20:52
rakudo: a5fdf1d3ca | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
[NQP Bump] 21eab3028 [MoarVM Bump] Brings 4 co […]

NQP bump brought: github.com/perl6/nqp/compare/2019....g21eab3028
20:56 sena_kun joined
Geth_ rakudo: 131d253a20 | (Christian Bartolomäus)++ | src/core.c/Rakudo/Iterator.pm6
[JVM] Restore old implementation of 'lazy gather'

The performance optimization of 971174f4d8 broke things on the JVM backend. This is a known problem with nqp::null getting HLLized showing up again -- cmp. github.com/rakudo/rakudo/issues/1613		 21:23
21:37 stoned75 left
lizmat bartolin++ 21:46
21:55 moritz left, moritz joined
Geth_ roast: 2cc22d24d6 | (Elizabeth Mattijsen)++ | S32-str/val.t
Also test with just a space after expression
 22:12
22:29 stoned75 joined 22:42 sena_kun left 22:56 sena_kun joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!