00:57 leont left 01:06 lizmat left 02:15 MasterDuke left 02:49 sena_kun joined 02:54 sena_kun left 02:56 sena_kun joined 03:05 sena_kun left 06:55 MasterDuke joined 09:11 lizmat joined 09:13 MasterDuke left 09:28 MasterDuke joined 09:30 lizmat_ joined 09:33 lizmat left 09:54 lizmat_ is now known as lizmat
lizmat do we consider this correct dispatch behaviour? 10:13
m: multi a(Any \a) { dd "Any" }; multi a(+@p) { dd @p }; a (1,2)
camelia "Any"
lizmat I'd say the +@p is narrower than the Any
m: multi a(+@p) { dd @p }; a (1,2) 10:16
camelia Array element = [1, 2]
lizmat is what I'd expect
MasterDuke github.com/rakudo/rakudo/blob/mast...2406-L2410 maybe? 10:19
lizmat "A lack of 10:29
# slurpiness makes the candidate narrower." ???
I guess that explains it... but it feels counter-intuitive to me
MasterDuke dunno. kind of seems right. you're wanting a specific thing vs saying just give me whatever you've got 10:31
lizmat I guess... 10:32
AlexDaniel lizmat: what's the meaning of an infix set operator with a single argument? Is it special-cased and why? 10:50
lizmat m: dd [(&)] 42 10:53
camelia Set.new(42)
lizmat AlexDaniel ^^
there's also the 0 arg case that needs to be handled
m: dd [(&)]
camelia set()
AlexDaniel also, does +@ force creation of a copy of the array? If yes, then that's potentially wasteful for large-ish arrays. If not, then .shift mutates the array passed to the sub. 10:54
zero arg case gives the identity or whatever that's called, that I can kinda understand
MasterDuke did we lose geth?
lizmat m: my @a = 1,2,3; sub a(+@p) { dd @p.shift }; a @a; dd @a 10:55
camelia 1
Array @a = [1, 2, 3]
lizmat yes, I guess we have
lose geth
*lost 10:57
m: sub infix:<foo>($a, $b) { 42 }; dd [foo] # if you want your infixes to be handled correctly by metaops, you need to handle 0 and 1 arg cases as well 11:05
camelia Too few positionals passed; expected 2 arguments but got 0
in sub infix:<foo> at <tmp> line 1
in block <unit> at <tmp> line 1
MasterDuke hm, that's kind of annoying 11:08
lizmat well, reality can be 11:11
MasterDuke can't argue that
lizmat but I guess you will need to add identity to an infix op yourself :-)
or handling of the singleton case 11:12
MasterDuke i wonder how bad it would be to autogenerate candidates that return Nil for the identity case and the given argument for the singleton case
AlexDaniel I don't think it's reality? 11:14
MasterDuke maybe Empty for identity?
AlexDaniel it's the design decision to create single argument special cases
lizmat MasterDuke: well, there you go wrt Nil or Empty 11:17
I think you need to be explicit, and therefore need to define that behaviour yourself
and not let some magic handle it
AlexDaniel which by the way works pretty well, sort of, but then breaks down in case of metaops 11:18
lizmat only breaks down in case of [foo] and [foo] 42 11:19
m: sub infix:<foo>($a, $b) { 42 }; dd [foo] 1,2,3,4,5
camelia 42
lizmat m: sub infix:<foo>($a, $b) { dd $a, $b; 42 }; dd [foo] 1,2,3,4,5
camelia 1
2
42
3
42
4
42
5
42
AlexDaniel well that's exactly the point
lizmat AlexDaniel: so what are you saying? 11:20
AlexDaniel I'm looking at this trap: docs.raku.org/language/traps#Using...t_of_lists
and I don't see a good solution 11:21
MasterDuke yeah, i assume autogenerating them would break/be wrong too many times, but it's the sort of thing where it seems like you could get so close...
AlexDaniel one that doesn't involve completely removing single-argument special cases
but leaving it in makes it very hard to reason about the behavior of core ops and even your own code 11:22
lizmat so do I understand you correctly you want to get rid of the single argument rule? 11:23
AlexDaniel possibly. Any other options? 11:24
lizmat are you ready to say: "for @a.List { " instead of "for @a { " ?? 11:27
because that's the single argument rule in action
AlexDaniel no it isn't 11:28
other languages have that working just fine
in fact in case of Raku there's already @ which should indicate enough info to make it work right
in fact if you changed it to something like `for $a {` 11:29
where $a is an iterable, that doesn't work 11:30
lizmat m: my $foo := my @a = 1,2,3; .say for $foo
camelia 1
2
3
AlexDaniel m: my $a = (42, 50, 30); .say for $a
camelia (42 50 30)
lizmat m: my \foo := my @a = 1,2,3; .say for foo
camelia 1
2
3
lizmat m: sub foo(\a) { .say for a }; foo (1,2,3) 11:31
camelia 1
2
3
AlexDaniel so `for $a` behaving one way or another depends on what exactly?
lizmat whether or not it is eman it
whether or not it is an item
AlexDaniel what's an item? 11:32
lizmat docs.raku.org/routine/item 11:33
AlexDaniel to answer your question, yeah writing something like @$foo would've been fine to me 11:35
but `for @a` will work that way regardless
lizmat well, in *looong* deliberations during the GLR, it was decided there was going to be a single-argument rule
to bring some sanity in the way Raku was handling lists and contexts 11:36
I don't want to go back to the pre-GLR situation with *many* more special cases
and the handling of for loops in those days, was one of them 11:37
AlexDaniel well, working with JSON::Fast still shows that the behavior is completely unpredictable
I don't know if it's JSON::Fast's fault or Raku's
lizmat I happen to know a little bit of the inside of JSON::Fast: so what are you referring to ? 11:38
AlexDaniel but bringing some regularity and removing even more special cases doesn't sound like a terrible idea
lizmat: it's about using JSON::Fast and traversing the data. Maybe timotimo can explain
lizmat ok, well that's opinion and not data 11:39
AlexDaniel ā€¦
yeah not going to have a conversation like that
lizmat neither
timotimo yeah, json::fast puts hashes into items for a bad reason
11:39 leont joined
lizmat timotimo: please elaborate 11:39
timotimo i made it a drop-in replacement for json::tiny
AlexDaniel absolutely ridiculous, you won't listen to anything unless I shove code into your face
lizmat AlexDaniel: that's called data-driven 11:40
AlexDaniel data-driven my arse. Should I now speak in code snippets then?
lizmat AlexDaniel: and I'm not here to be sent off on all sorts of goose chases
if *you* think there is a problem in Raku, then *show* the problem
yes, code snippets, please
of even better: go *fix* the problem 11:41
but you're too busy here doing important arguing
instead of fixing things you said you'd fix: github.com/rakudo/rakudo/issues/3782
which BTW is work, and it's easier to just throw arguments around 11:42
AlexDaniel as if reviewing your PRs isn't
lizmat I did *not* ask for you to review my PRs
AlexDaniel you can review them yourself then, if that's so easy
lizmat earlier, I would just commit to the main branch 11:43
AlexDaniel which was horrible
lizmat people objected to that, so I adapted to making PRs
AlexDaniel and now you're doing your best to piss off the only reviewer you currently have
lizmat well, too bad then 11:44
AlexDaniel that I agree with
lizmat there are plenty of dead PRs by me, if people don't want them, that's too bad
it apparently was a bad idea then
shit happens, I deal with it
I haven't seen you make a PR for a year now 11:46
AlexDaniel and? 11:47
lizmat means you do not want to get your hands dirty and run the risk of review 11:48
11:48 Geth joined
AlexDaniel means I don't have the resources to work more for free 11:49
just had 3 days of continuous livestreaming during the weekend, then there's some prep and still some work to do 11:50
and that's parallel to some hopefully for-profit projects I'm working on on the background
it's nice that you can do this full-time, I can't
I write code every day, but usually for my other projects. 11:51
lizmat yet you still have time to debate basic design decisions here
AlexDaniel in fact, even whateverable recently got a very large rework, that I still need to finish by the way
yes, writing code and doing reviews is different kind of work 11:52
and there shouldn't really be anything wrong with debating design decisions
especially ones that result in traps 11:53
lizmat I'd say there's something wrong with that, and that's the timing 11:54
here and now, you're just taking up your time and my time, and time of the people reading this
knowing that it either won't change anything 11:55
or that you achieve that core developers leave because of your constant sealioning
the time of discussion for those types of design decisions, is long gone 11:56
live with them or don't
AlexDaniel why isn't there a third option? Like, you know, that devs will actually admit the mistake and maybe sketch at least potential long-term plans on how to fix it
and why is the time for discussions like this long gone
lizmat I think the priority is to get a Raku out of the door next year based on RakuAST with the newdisp work, inluding macros and related goodies 11:57
*that* should be the focus
AlexDaniel why
lizmat because that's the consensus of the core developers
AlexDaniel define core developers 11:58
also, what's the point of RSC then if long-term goals and plans are not made by them? 11:59
lizmat that *is* the point
the point *also* is that jnthn left the RSC because *you* were in it 12:00
so, what does *that* tell you ?
12:01 Geth_ joined
AlexDaniel too bad my opinion about technical decisions makes somebody that uncomfortable 12:02
12:02 Geth left
lizmat too bad indeed :-( 12:03
AlexDaniel the reason I ask ā€œwhyā€ is because I don't yet see how RakuAST will change Raku's position overall. OK, maybe we'll get macros, so are people who are not choosing Raku today doing that because it lacks macros? I highly doubt that
lizmat do you think removing the single argument rule will ?? 12:05
AlexDaniel a very consistent language might, yeah 12:06
but thing is, as I mentioned before, compiler and language go hand in hand
lizmat wow 12:07
AlexDaniel so a simpler and more regular language makes it easier to create a great (for example, fast!) compiler
lizmat so we should spend work on: removing the single argument riule, adapt documentation and tests, rewrite books
and then we would have a better language all of a sudden 12:08
wow
AlexDaniel there seems to be an actual need for high-performance languages that feel python-like in terms of dev experience, and Raku could've been a great fit
lizmat and that comes from someone who is willing to spend a *lot* of time on that, great 12:09
12:09 domidumont joined
AlexDaniel well, there's a quick way, and a slow way of getting that :) 12:09
lizmat ah, no, someone who only has time to debate what things should be, *not* have time to implement that
AlexDaniel: please stop doing this
AlexDaniel it has been 5 years since the ā€œfirstā€ language release 12:11
well, almost
and since then? Well, a big chunk (most?) of Rakudo was rewritten in nqp. Wonderful. You also don't see me submitting PRs because I can't justify it for myself obfuscating stuff 12:14
yet the marketing fluff about rakudo being written in raku is still repeated, even though other languages have even more code of the std lib written in the same language 12:15
timotimo not to be too pedantic, but the core setting is still written in raku, just using nqp ops, it's not compiled with the nqp compiler 12:16
lizmat AlexDaniel doesn't care about such technicalities 12:17
nor does he care about the speed gains that brought
it's still too slow
AlexDaniel because words have meaning, if you say that rakudo is mostly written in Raku then there's a thing people expect and understand by that
lizmat words *do* have meaning 12:18
AlexDaniel I want Raku to be successful, but at the current pace it's not happening. I think it's OK to take a pause to think if there's a shortcut
lizmat "too bad my opinion about technical decisions makes somebody that uncomfortable" means you don't care shit about someone who put more than 10 years of their life in Raku / MoarVM
enough to not want to deal with you *or* Raku anymore 12:19
AlexDaniel doesn't mean it was time well spent
lizmat now you've done it
AlexDaniel timotimo: I mean, open github.com/rakudo/rakudo/blob/mast...c/List.pm6 or any other file and see how much of that code you would've written if you were writing Raku 12:20
timotimo i mean, i tend to sprinkle my code with nqp ops to experiment with performance characteristics of rakudo and spesh anyway 12:25
so i'm not the right one to ask here
AlexDaniel ā€¦ right
and I did that too, where every single line being changed to nqp gives crazy speed improvements. github.com/MasterDuke17/Text-Diff-...524f98cdc9 12:26
timotimo yeah
optimizer work is difficult, unfortunately 12:27
AlexDaniel well, I'm not sure about that. Depends on how much you're ready to still and what sacrifices you want to make
lizmat too bad, one of the few people doing that, has been chased away by AlexDaniel
but at least we're having a good debate
AlexDaniel to steal*
lizmat I guess losing the man architect is the correct sacrifice to make 12:28
*main
timotimo not sure about what exactly?
AlexDaniel timotimo: about it being difficult. Say you take LLVM, then how much optimizing would you be doing on your side?
timotimo oh, no, i meant literally working on the optimizer that's built into rakudo 12:29
AlexDaniel sure
timotimo otherwise many tricks where you get speedups by rewriting little bits with nqp ops would be "automatic"
AlexDaniel I recently stumbled upon this article which has a very interesting perspective: towardsdatascience.com/julia-for-g...02b32aef9f 12:30
now, in my view, Julia's tradeoff at compiling everything kinda, um, ahead of time is extremely unfortunate
so much that it makes it unusable for some things
lizmat AlexDaniel: I think you would make a great language designer 12:31
AlexDaniel but then, the article brings an interesting point that for game dev it might not even matter
lizmat so please go off and go design *ANOTHER* language
tobs I thought jnthn leaving the RSC was for health reasons? 12:46
Geth_ Ā¦ problem-solving: lizmat self-assigned Aleks-Daniel Jakimenko-Aleksejev (aka AlexDaniel) is a toxic influence and should be banned from Rakudo github.com/Raku/problem-solving/issues/238 12:47
lizmat tobs: because of the stress of having to deal with AlexDaniel made him burn out 12:48
lizmat steps away from the keyboard to do something else 12:49
12:57 ggoebel joined
ggoebel This seems somehow appropriate... medium.com/@audrey.tang/lessons-i-...f5d8107e34 12:57
13:34 domidumont left 15:17 squashable6 left, squashable6 joined, squashable6 left, squashable6 joined
[Tux] Rakudo version 2020.09-39-ge0e24a8db - MoarVM version 2020.09-8-g60070970c
csv-ip5xs0.847 - 0.906
csv-ip5xs-208.041 - 8.456
csv-parser29.735 - 29.899
csv-test-xs-200.384 - 0.390
test7.481 - 7.906
test-t1.902 - 1.912
test-t --race0.813 - 0.864
test-t-2034.446 - 38.147
test-t-20 --race9.946 - 11.371
 15:43
15:47 sena_kun joined 16:08 vrurg left
sena_kun lizmat++ # weekly! 16:43
lizmat sena_kun: thank you :-)
16:44 Xliff joined 17:19 MasterDuke left 17:28 camelCaser joined 17:42 Altai-man joined 17:44 sena_kun left 18:11 patrickb joined 18:42 radudo joined
radudo > map {:3($_.base(2))%2}, [X+&] ^2**3 xx 2 18:44
what is the function of :3?
timotimo it interprets a string as a number of base 3 18:45
radudo this makes Walsh matrix
timotimo m: say :3("123123")
camelia Cannot convert string to number: malformed ':3' style radix number, expecting '>' after the body in '3:3<12ā053123>' (indicated by ā)
in block <unit> at <tmp> line 1
timotimo m: say :3<123123>
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot convert string to number: malformed base-3 number in '0312ā053123' (indicated by ā)
at <tmp>:1
------> 3say :3<123123>7ā5<EOL>
timotimo lol 18:46
m: say :3("012012")
camelia 140
radudo odd since the final output is base 2
> map {:3($_.base(3))%2}, [X+&] ^2**3 xx 2 18:49
there are no twos
timotimo well, yeah, you're running modulus-2 on the result 18:51
so every 2 becomes a 0
and all multiples of 2 i guess
radudo so why does :3 change result? 18:52
timotimo the number changes drastically
m: say 99; say 99.base(2); say :3(99.base(2)); say :3(99.base(2)) % 2 18:53
camelia 99
1100011
976
0
timotimo re-interpreting 99 as base2, then reading the result as if it were base3 gives 976 where you used to have 99
it used to be 1 + 2 + 32 + 64 and then it became 1 + 3 + 3 ** 5 + 3 ** 6 18:55
radudo thinking...
timotimo i don't know what the walsh matrix is all about, so i don't know why this operation gives you the desired result
radudo np
got it thanks 18:56
fyi map {:3($_.base(2))%2}, [X+&] ^2**3 xx 2 19:03
is the Walsh 3 matrix
the :3 is used as a parity unction 19:04
function
it is golf winner for perl6 Walsh 19:05
ty 19:06
19:06 radudo left
Geth_ rakudo: patrickbkr++ created pull request #3955:
Generate a `rakuw.exe` on Windows		 19:37
19:52 patrickb left 19:58 vrurg joined 20:07 MasterDuke joined 20:08 vrurg left 20:14 Xliff left
Geth_ roast/setops-prec-non: a39ce60b0d | (Elizabeth Mattijsen)++ | 6 files
Add more tests for R#3945
 20:19
linkable6 R#3945 [open]: github.com/rakudo/rakudo/issues/3945 Intersection meta-ops behave like union
21:08 Altai-man left 21:18 Xliff joined, Xliff left, Xliff joined 22:28 lucasb joined 22:51 ggoebel left 23:36 vrurg joined 23:41 vrurg left 23:45 lizmat left 23:48 lizmat joined 23:57 Xliff left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!