|
🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
|
01:41
lizmat_ joined
01:45
lizmat left
04:48
MasterDuke left
|
|||
| [Tux] | jdv: tux.nl/Talks/CSV6/speed5.html | 06:56 | |
| and that page is refreshed on every timing run | 06:57 | ||
|
07:32
lizmat_ left,
lizmat joined
07:33
guifa left
|
|||
| ab5tract | lizmat: Good point. And probably more evidence that first should behave like map. | 07:35 | |
| Related: am I crazy or did .kv used to output ([$k,$v], ...)? | |||
| lizmat | maybe before the GLR | ||
| ab5tract | yeah, if so it's been a looong time | 07:40 | |
| there was a .kxxv at that time too | |||
| ah, nope, that's a Baggy/Mixxy feature | 07:44 | ||
| lizmat | m: .say for <a a b b c c c>.Bag.kxxv # indeed | 07:45 | |
| camelia | b b c c c a a |
||
| ab5tract | yeah, looks like it was pre-GLR: "Note that C<kv %hash> returns the same as C<zip(keys %hash; values %hash)>" | 08:00 | |
| m: my %hash = ("x" X~ 1..5) Z=> 1..5; dd zip(%hash.keys, %hash.values) | |||
| camelia | (("x1", 1), ("x4", 4), ("x5", 5), ("x3", 3), ("x2", 2)).Seq | ||
| ab5tract | conceptually I kind of preferred it that way, to be honest | 08:01 | |
| but I will not stand in the way of history here :) | |||
| lizmat: should there be a ticket for fixing first to match map semantics? | 08:03 | ||
| lizmat | perhaps a problem solving one ? | 08:04 | |
| ab5tract | ok, will try to get around to that later today | 08:05 | |
| Geth | rakudo/main: 967d1a5a47 | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod Fix scoping issue in NativeCall This was probably broken with 46a8f32472ea1d158b , but I have no idea why I didn't spot this before in make test :-( |
10:15 | |
|
10:19
sena_kun joined
|
|||
| Geth | rakudo/main: 2e05fe4d9a | (Elizabeth Mattijsen)++ | 6 files Replace outdated references to another language |
10:20 | |
| rakudo/main: aec7a49d01 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Fixups.rakumod RakuAST: V<> semantics shouldn't extend a whole paragraph As spotted by Coke++ |
11:00 | ||
| lizmat | m: (^Inf).reverse # that should just not infiniloop | 12:34 | |
| camelia | ( no output ) | ||
| lizmat | m: dd (^Inf).reverse # that should just not infiniloop | ||
| camelia | (timeout) | 12:35 | |
| Geth | rakudo/main: 5eb1da8c26 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.e/Fixups.rakumod Add Cool.nomark in 6.e (#5562) As suggested in github.com/Raku/problem-solving/issues/427 Notes on implementation: - Cool.nomark converts to string and delegates to Str.nomark - in Str.nomark: check if empty string, return invocant if so ... (8 more lines) |
12:54 | |
| rakudo/main: 26f1c49463 | (Elizabeth Mattijsen)++ | src/core.c/Range.rakumod Make (^Inf).reverse fail rather than infiniloop |
13:38 | ||
| ugexe | should it really not infiniloop? | 14:21 | |
| 1..Inf infiniloops as well | |||
| indeed might seem a bit weird to see every value is 'Inf', but maybe that is correct? | 14:22 | ||
| to be clear i'm not saying it is, i just know there seem to be non-intuitive rules for what to expect from infinities | 14:23 | ||
| non-intuitive mathematical rules^ | 14:24 | ||
| m: say (-Inf..0).reverse.reverse.raku | 14:28 | ||
| camelia | Failure.new(exception => X::Cannot::Lazy.new(action => ".reverse", what => "Seq"), backtrace => Backtrace.new) | ||
| ab5tract | ugexe: it seems like a case we can trivially catch in RakuAST, throwing an exception that it will infiniloop. The user would then be free to catch and resume if that’s something that they actually want | 15:13 | |
|
15:42
Geth left,
Geth joined
|
|||
| Geth | nqp/r1373: 4 commits pushed by ab5tract++ | 16:04 | |
| ab5tract | git and I are in a bit of a fight today, it seems | 16:05 | |
| Geth | nqp/r1373: 454ef9dfba | ab5tract++ | 2 files Add open mode constants This is useful for HLLs to check the (simple) open mode of a BOOTIO. Simple here means only the ro/wo/rw part of the mode, so no information about append/truncate/etc. |
16:06 | |
| nqp: ab5tract++ created pull request #822: Add open mode constants |
16:07 | ||
| lizmat | ab5tract: the JVM ones need to be added at the end per item, due to JVM restrictions, if I re.ember correctly | ||
| Geth | rakudo/r1373: 91eeaa20d0 | ab5tract++ | src/core.c/IO/Handle.rakumod Move the open mode detection down a layer This allows us to remove the additional instance variable from IO::Handle in order to avoid adding additional weight/complexity to an already unwieldy core class. This depends on changes in MoarVM (M#1803) and NQP (N#822). |
16:08 | |
|
16:08
finanalyst joined
|
|||
| linkable6 | M#1803 [open]: github.com/MoarVM/MoarVM/pull/1803 Provide some mechanisms for introspecting file mode | ||
| linkable6 | N#822 [open]: github.com/Raku/nqp/pull/822 Add open mode constants | ||
| ab5tract | lizmat: ah, thanks for the heads up. in fact, I debated on including them... right now they aren't used at all | 16:09 | |
| lizmat | well, if they won't be on the JVM backend, then best to exclude them | ||
| ab5tract | let me check how comprehensible the current error message is in JVM | 16:10 | |
| I wonder if zoffix is smiling somewhere, watching his bug reports get fixed | 16:15 | ||
| he surely could get things to break | |||
| 20% of the open issues originate from him | 16:16 | ||
| lizmat | I'm pretty sure they also fixed a decent number of them | 16:17 | |
| ab5tract | yeah, roughly 50/50 balance between open and closed | 16:26 | |
| jdv: how careful are we WRT jvm during releases? | 16:29 | ||
| because `rakubrew build jvm 2024.04` just blew up on me | 16:30 | ||
| m: m: my $x = 42; .= flip with $x | 16:31 | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Preceding context expects a term, but found infix .= instead. at <tmp>:1 ------> m: my $x = 42; .=⏏ flip with $x |
||
| ab5tract | m: my $x = 42; .= flip with $x | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Preceding context expects a term, but found infix .= instead. at <tmp>:1 ------> my $x = 42; .=⏏ flip with $x |
||
| ab5tract | m: Q| my $x = 42; .= flip with $x |.AST.EVAL.say | 16:32 | |
| camelia | ===SORRY!=== Error while compiling /home/camelia/EVAL_0 Preceding context expects a term, but found infix .= instead. at /home/camelia/EVAL_0:1 ------> my $x = 42; .=⏏ flip with $x |
||
| jdv | ab5tract: we are not | 16:41 | |
| ab5tract | ack | ||
| jdv | [Tux]: thanks | 16:42 | |
| ab5tract | yet another longstanding issue fixed in RakuAST! R#2295 | 17:17 | |
| linkable6 | R#2295 [open]: github.com/rakudo/rakudo/issues/2295 [consistency][Fixed in RakuAST] Blocks don't get parametarized with return type | ||
| lizmat | nice! | 17:18 | |
| m: dd { :42a, :666b }.antipairs | 17:42 | ||
| camelia | (666 => "b", 42 => "a").Seq | ||
| lizmat | m: dd { :42a, :666b }.hyper.antipairs | ||
| camelia | ((:a(42)) => 0, (:b(666)) => 1).Seq | ||
| lizmat | should we consider this difference a bug ? | ||
| or is this a consequence of .hyper considering its invocant to be an Iterable, and thus in the case of an Associative, would produce Pairs | 17:45 | ||
| ab5tract | hmmm | 17:52 | |
| since this | 17:54 | ||
| m: dd |{ :42a, :666b }.hyper | 17:55 | ||
| camelia | :a(42) :b(666) |
||
| ab5tract | and this | ||
| m: dd |{ :42a, :666b } | |||
| camelia | :a(42) :b(666) |
||
| ab5tract | are the same, I would lean towards bug | ||
| but then again, the explanation about invocant iterable makese sense to me | 17:59 | ||
| and probably my test cases are mostly irrelevant to the question, in retrospect, except inasmuch as to demonsrate that a user might expect a symmetry of behavior here | 18:04 | ||
| lizmat | another interesting find: | 18:13 | |
| m: dd (^Inf).iterator.is-lazy | |||
| camelia | Bool::True | ||
| lizmat | m: dd (^Inf).hyper.iterator.is-lazy | ||
| camelia | Bool::False | ||
| lizmat | and thus: | 18:14 | |
| m: dd (^Inf).elems | |||
| camelia | Failure.new(exception => X::Cannot::Lazy.new(action => ".elems", what => ""), backtrace => Backtrace.new) | ||
| lizmat | m: dd (^Inf).hyper.elems | ||
| camelia | (signal XCPU) | ||
| lizmat | wow :-) | 18:15 | |
| ab5tract | never seen that signal before :O | 18:16 | |
|
18:53
sena_kun left
19:11
sena_kun joined
|
|||
| ab5tract | SEQUENCE.rakumod is a helluva drug | 19:19 | |
| lizmat | tell me about it | ||
| ab5tract | any idea why '# don't sink return of take()' ? | 19:20 | |
|
19:21
finanalyst left
19:24
finanalyst joined
|
|||
| Geth | nqp/r1373: 56cd9e4dd1 | ab5tract++ | src/vm/moar/QAST/QASTOperationsMAST.nqp Add open mode constants This is useful for HLLs to check the (simple) open mode of a BOOTIO. Simple here means only the ro/wo/rw part of the mode, so no information about append/truncate/etc. |
19:32 | |
| nqp/main: 9cf971726a | ab5tract++ | src/vm/moar/QAST/QASTOperationsMAST.nqp Add open mode constants This is useful for HLLs to check the (simple) open mode of a BOOTIO. Simple here means only the ro/wo/rw part of the mode, so no information about append/truncate/etc. |
|||
| lizmat | ab5tract: what would that mean | 19:38 | |
| ab5tract | I have no clue, but the consequences of sink context are still a blind spot for me | 19:39 | |
| lizmat | well, sink context makes "for" workl | ||
| *work | |||
| ab5tract | Maybe it's to avoid useless use errors... | 19:40 | |
| or worries, rather | |||
| but its also plain weird to me that the taken values aren't, like, used for anything | 19:41 | ||
| lizmat | they are gathered ? | ||
| ab5tract | ah, right, duh! | 19:42 | |
| but then why assign the result of take into unused temporary variables? I think that's what threw me off re: the take semantics | 19:43 | ||
| lizmat | because otherwise it *would* get sunk | ||
| ab5tract | well, I know a surefire way to see what blows up without them :) | ||
| lizmat | re sink: | ||
| remember that: | 19:44 | ||
| m: for ^3 { .say } | |||
| camelia | 0 1 2 |
||
| lizmat | is really: | ||
| m: (^3).map({ .say }).iterator.sink-all | |||
| camelia | 0 1 2 |
||
| lizmat | under the hood | ||
| ab5tract | hmm.. | 20:01 | |
| wait.. does `take` work by throwing an exception? :O | 21:49 | ||
| ugexe | yes - stackoverflow.com/a/43333653/1772220 | 21:59 | |
|
22:00
finanalyst left
|
|||
| ab5tract | is that a major factor in how we generally consider gather/take to be unusably slow? | 22:06 | |
| lizmat | it's one factor, yes | 22:07 | |
| ab5tract | "unusably' is a bit uncharitable | ||
| lizmat | for the same reason I try to refrain from return / next / last in hot code | 22:08 | |
| ab5tract | now it's starting to all click together | 22:25 | |
|
22:34
sena_kun left
|
|||
| ab5tract | now I'm reminded of a blog series about writing a text adventure using exceptions.. | 22:41 | |
| gfldex | ab5tract: I found sink-context very useful indeed: gfldex.wordpress.com/?s=sink | 22:42 | |
| ab5tract | gfldex: thanks for the reference, will check these posts out | 22:44 | |
| Geth | rakudo/r1399: ae6ccdc310 | ab5tract++ | src/core.c/Rakudo/SEQUENCE.rakumod Fix memory leaking in infinity-bound ... It's simple: there's no reason to involve the `righti` iterator at all. Remove that, et voila, no memory leak for inifinite sequences. There are only two possible `righti` for infinities: ... (11 more lines) |
23:05 | |
| ab5tract | RT#131829 (just curious if it works) | 23:09 | |
| Geth | rakudo/r1399: 24057e69cd | ab5tract++ | src/core.c/Rakudo/SEQUENCE.rakumod Fix memory leaking in infinity-bound ... It's simple: there's no reason to involve the `righti` iterator at all. Remove that, et voila, no memory leak for inifinite sequences. There are only two possible `righti` for infinities: ... (11 more lines) |
23:14 | |
| rakudo: ab5tract++ created pull request #5569: Fix memory leaking in infinity-bound ... |
|||
| ab5tract | that's probably all for tonight :) | 23:16 | |