|
01:33
MasterDuke joined
|
|||
| MasterDuke | looking at the differences between `..` and `xx` some more. `say (reduce * * *, (1993 xx 10_000)) %% 2` has 10001 calls to `pull-one` in `class OneValueTimes does PredictiveIterator`, which makes sense. but `say (reduce * * *, (1 .. 10_000)) %% 2` has 10001 calls to `push-exactly` in `class IntRange does PredictiveIterator`, which also makes sense, | 01:38 | |
| but then 50005 or 40004 calls to a bunch of other Iterator and List methods, which doesn't make sense | |||
| huh. `say (1 .. 10_000).reduce(* * *) %% 2` only has 30003 and 20002 calls of the various Iterator and List methods | 02:17 | ||
| i'm guessing it really does come down to the signature of sub reduce. the `+list` is reifying the Range. seems unfortunate | 03:16 | ||
| Geth | roast: 9fa7778bc6 | (Tom Browder)++ (committed using GitHub Web editor) | 2 files Add tests for log2 |
09:43 | |
| timo | so, is there any kind of tool yet that analyzes the dependencies between precompiled files? specifically, i'd like to have something that installs every raku-* debian package and makes sure the precomped files that end up on disk can be loaded with the rakudo package that is installed along with it | 09:57 | |
| lizmat | there isn't afaik | 09:58 | |
| ugexe ^^ ? | |||
| timo | unrelated to zef, though there are implications for like, cleaning up old precomp files where the rakudo and nqp runtime files (ModuleLoader.moarvm and such) of the right version aren't around any more so they can't possibly (?) be loaded | 10:00 | |
| lizmat | there's raku.land/zef:lizmat/Repository::P...p::Cleanup | 10:01 | |
| timo | ah, interesting i will give that a look | ||
| my primary concern right now is that we don't get into a situation any more where debian may give you packages with precomps that can't be loaded successfully | 10:02 | ||
| so, i think i might now maybe understand why liz is having regular trouble with "missing or wrong version of dependency" when she doesn't nuke her prefix? is it because the runtime/ folder has just one set of files? | 10:04 | ||
| lizmat | fwiw, I nuke my install dir after every NQP bump | ||
| I also found that a sure way to mess up your installation, is to run "perl Configure.pl --gen-moar --make-install" more than once without nuking the install dir | 10:06 | ||
| timo | i wonder if there's a way we can get your workflow to suck less for you? but i'm also wondering why we're trying to load incompatible precomps in the first place? | 10:11 | |
| lizmat | I suspect dependency checking still has some gremlins in it | 10:12 | |
| timo | you know, we literally generate the code in the "dependencies+deserialize" frame | 10:15 | |
| we can do whatever the heck we want in it | |||
| like, what if we introduce an HLL symbol that we check at the very start before doing anything else | |||
| lizmat | for what ? | 10:16 | |
| timo | bailing out more safely/sanely if we're being loaded for an incompatible set of compiled rakudo files | ||
| lizmat | well, more info would be good :-) | 10:19 | |
|
11:06
ab5tract left
|
|||
| timo | i must say, the error you get when your moar or nqp is out of date relative to MOAR_COMMIT / NQP_COMMIT is super hard to read | 11:18 | |
| lizmat | agree :-) | 11:19 | |
| Geth | rakudo/main: e08f6e0ba3 | (Elizabeth Mattijsen)++ | src/core.c/INTERPOLATE.rakumod Add support for "any" junctions in regex interpolation Fixes #4136 |
11:26 | |
| timo | now if we introduce something where you can give a piece of helpful information to identify a build with during rakudo compilation, that could go into the error message | ||
| Geth | roast: 45508ac933 | (Elizabeth Mattijsen)++ | S05-interpolation/regex-in-variable.t Add test for #4136 |
11:33 | |
| timo | hm. sprintf is supposed to reuse the results of parsing the grammar right? | 12:27 | |
| lizmat | it doesn't in pre-RakuAST: runs the grammar *every* time | 12:31 | |
| timo | oh, that's a rakuast-only feature | ||
| lizmat | actually, it's available atm in 6.e as zprintf | ||
| timo | neat, let me give that a shot | 12:32 | |
| nqp_run_nfa after zprintf: 0.22% - 14.270110608 seconds time elapsed | 12:35 | ||
| nqp_run_nfa with sprintf: 9.94% - 30.878792527 seconds time elapsed | 12:38 | ||
| lolsob | |||
| this is "zef list > /dev/null" | |||
| gist.github.com/timo/a449313a12a46...1b68fed5d2 - my pc isn't at rest right now, so my timings may be wildly inaccurate. i would appreciate if someone were to apply this patch on top of zef and tried before/after of "zef list > /dev/null" and maybe some other zef commands as well? | 12:53 | ||
| (don't forget precomp time on the first run) | 12:54 | ||
| lizmat | I don't need to test: you will see even better results than with zprintf :-) | 12:59 | |
| make it a PR :-) | 13:00 | ||
| timo | barely better timing than zprintf | 13:11 | |
| but doesn't need "use v6.e.PREVIEW" so i thought it was safer to put into zef | |||
| lizmat | indeed | 13:16 | |
| timo | github.com/ugexe/zef/pull/575 | 13:19 | |
| Geth | roast: 82fbddefb0 | (Elizabeth Mattijsen)++ | S12-methods/defer-next.t Re-activate &?ROUTINE.dispatcher tests for #4157 |
13:31 | |
| rakudo/lizmat-Instant-DateTime: 27d72dde86 | (Elizabeth Mattijsen)++ | src/core.c/Instant.rakumod Make Instant.DateTime coercer take timezone into account As implicitely suggested in R#4169 No spectest fail, but still feels like it needs more scrutiny before being merged |
13:56 | ||
| linkable6 | R#4169 [open]: github.com/rakudo/rakudo/issues/4169 Instant.DateTime doesn't respect timezone of the OS | ||
| Geth | rakudo: lizmat++ created pull request #5660: Make Instant.DateTime coercer take timezone into account |
||
| timo | instant datetime, just add water | 13:59 | |
| lizmat | .oO( and some sunshine ) |
||
| afk for a few hours& | |||
|
15:00
ab5tract joined
16:50
MasterDuke left
17:10
ab5tract left
|
|||
| Geth | roast: cdc1b23c95 | (Elizabeth Mattijsen)++ | S32-temporal/DateTime.t Add tests for #4175 |
17:17 | |
| rakudo/main: ea5a74d24d | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add test for #4193 |
17:31 | ||
| rakudo/main: b56ba4c581 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add test for #4198 |
17:45 | ||
| bartolin | I asked that the other day, but maybe it went unnoticed: is it a known problem that integration/advent2012-day21.t (from roast) hogs up all memory very fast? I see that on my machine (FreeBSD 14.1) | 18:08 | |
|
18:10
dogbert17 joined
|
|||
| patrickb | At least I was unaware. Is that file run by default? | 18:22 | |
| bartolin | it's part of the make target "stresstest", I think | 18:25 | |
| github.com/Raku/roast/blob/cdc1b23...data#L1392 | 18:26 | ||
| it wasn't a problem in the past (when I ran stresstest regularly). I even bumped up the memory for my vm, but it became unresponsive soon after the tests from that file were started | 18:29 | ||
| patrickb | Interface design bikeshedding round: I want to extend Proc::Async. 3 bits of info: pty = yes / no, rows = no of rows, cols = no of cols. Ideas: `:pty(:cols(80), :rows(24))`, `:pty(%(:cols(80), :rows(24)))`, `:pty, :pty-rows(24), :pty-cols(80)`` | 18:54 | |
| timo | and pty-rows and pty-cols will be rw? | 18:55 | |
| patrickb | Good question. If they are rw then the last version makes most sense, but it's kinda ugly. | 18:56 | |
| Most (all?) attributes on Proc::Async are ro. So I guess that's a non issue. | 18:57 | ||
| Hm. Still unsymmetric if I have pty / pty-cols / pty-rows as attributes. | 18:58 | ||
| But having pty as a list of pairs as attributes it's pretty non-standard. | 19:00 | ||
| Oh, almost forgot, there will also be a `method resize-pty($cols, $rows)`. But that's for after the thing got started. (But doesn't hurt to allow it to modify the attributes before starting.) | 19:02 | ||
| Actually, I think I'll make the pty-rows and pty-cols private. I can't guarantee that the values will remain correct (as the size could be modified by outsiders). | 19:04 | ||
| So apart from being a bit strange, I like `:pty(:cols(80), :rows(24))` best. Any opposing opinions? | 19:06 | ||
| (Btw. My little terminal emulator is slowly coming together. Many missing pieces, but it was quite easy to get fancy stuff like vim and htop kinda work.) | 19:07 | ||
| timo | neat! | 19:24 | |
| i don't think i have good taste in terms of API design here | 19:25 | ||
| you can make pty-cols and pty-rows "properties", i.e. an "method ... is rw" that returns a Proxy.new with STORE and FETCH | |||
| on the other hand, i assume it will happen often enough that you change both rows and cols at the same time, and don't want to send sigwinch twice | 19:26 | ||
| perfect time to mis-use a Complex value :D | |||
| patrickb | I'm not a big fan of Proxy here. That suggests to the user it's a simple assignment, while it actually does fancy stuff like pinging a PTY which then usually causes the child to do a full relayout / draw dance. | 19:32 | |
| Geth | roast: usev6++ created pull request #864: Disable test file that hogs up all memory |
19:43 | |
| rakudo: usev6++ created pull request #5661: [JVM] Unbreak module loading |
19:54 | ||
| timo | you know, that's fair, yeah | 20:02 | |
| Geth | roast/add-log2-test-file: 55c808c89a | (Tom Browder)++ | 2 files Add tests for log2 |
20:56 | |
| roast/add-log2-test-file: 4b32f4d6f3 | (Tom Browder)++ | S32-num/complex-logarithms.t Add new test file for roast issue #862 |
|||
| roast: tbrowder++ created pull request #865: Add log2 test file |
21:41 | ||
|
23:24
ab5tract joined
|
|||