| TimToady | MasterDuke: the next step in that process is passing back fates via the current match object rather than via a cached thread context array | 01:20 | |
| we also need to redo the thing I did once that made fate numbers unique across the entire process | 01:21 | ||
| (or otherwise find a way to qualify fate numbers by context) | 01:22 | ||
| then we can return the extra information and pass it down to the next level in a way that it can look at and bypass the rescan | |||
| MasterDuke | TimToady: so it's not a completely trivial undertaking? | 01:23 | |
| TimToady | um, no... | ||
| or I'd'a done it by now :) | |||
| MasterDuke | heh. timotimo's description did seem a little too easy | 01:24 | |
| TimToady | I think he was channeling something I said in one of my talks, where I kinda glossed over the hard bits :) | 01:25 | |
| TimToady was gonna tackle it in September, but has been fighting a cephalic shingles flareup, which makes him temporarily stupider | 01:26 | ||
| well, I hope it's temporary :) | |||
| MasterDuke | ha. pretty sure i'm not up for the hard bits in anything named *nfa* | ||
| TimToady | there are other things we can do there as well | 01:27 | |
| caching the first decision based on initial character would cut down the number of initial states we have to examine, for instance | |||
| MasterDuke has never heard of cephalic shingles before, but it doesn't sound pleasant | |||
| TimToady | well, it's why I was blind in one eye for 14 years till I got a cornea transplant | 01:28 | |
| this time we prevented it from getting back into my eye, yay | |||
| it's just a bit distracting to feel like one side of one's head is on fire if you so much as touch it | 01:29 | ||
| MasterDuke | understandably | 01:30 | |
| hopefully not the side you sleep on if you normally sleep on your side | 01:32 | ||
| TimToady | well...I would prefer to think that sleep disruption explains the stupidity more than that my trigeminal nerve is drilling holes in my brane... :) | 01:34 | |
| TimToady should go eat some dinner if he doesn't want to become even stupiderer... | 01:40 | ||
| Geth | rakudo: skids++ created pull request #1178: Implement metamethod shorthand syntax (RT#131478) |
02:25 | |
| synopsebot | RT#131478 [new]: rt.perl.org/Ticket/Display.html?id=131478 Warning about $. when using metamethod | ||
| Geth | rakudo: skids++ created pull request #1179: Fix for RT#128054 and RT#126569 ... needs experienced review ... |
03:13 | |
| synopsebot | RT#128054 [open]: rt.perl.org/Ticket/Display.html?id=128054 [PARSER] In a string enclosed in parens, a {}-interpolation can't access the topic $_ of a statement modifier | ||
| RT#126569 [new]: rt.perl.org/Ticket/Display.html?id=126569 [BUG] xx-repeated expression enclosed in parens can't access the topic $_ of a statement modifier | |||
| lizmat | good *, #perl6-dev | 07:44 | |
| yoleaux | 3 Oct 2017 22:29Z <tyil> lizmat: was this your doing? :p ghostbin.com/paste/t9opu | ||
| 01:30Z <Zoffix> lizmat: In case the "your doing" line needs context; there appeared to be new error, but it's our standard behaviour: irclog.perlgeek.de/perl6/2017-10-03#i_15252868 | |||
| lizmat | Files=1226, Tests=75554, 387 wallclock secs (17.10 usr 6.09 sys + 2624.29 cusr 263.26 csys = 2910.74 CPU) | 08:06 | |
| .tell tyil the ghostbin seems to be out of order, so I have no idea what you mean :-( | 08:07 | ||
| yoleaux | lizmat: I'll pass your message to tyil. | ||
| AelxDnaiel | squashable6: next | 08:22 | |
| squashable6 | AelxDnaiel, ⚠🍕 Next SQUASHathon in 2 days and ≈1 hour (2017-10-07 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day | ||
| Zoffix | lizmat: it just said "ssh : nqp not found; cloning" | 10:20 | |
| geekosaur | because shell error messages are not error messages, and because you know it happens to be something that is expected in some cases and therefore everyone does, yes | 10:42 | |
| Zoffix | and because you didn't read the chat log where the guy said he'll try to improve it on the weekend, yes | 10:55 | |
| pmurias | jnthn: a declaration_static code ref and it's clones share the lexical scope? | 11:48 | |
| timotimo | "outer" is part of the static frame in moarvm i believe | 11:51 | |
| so yeah, should | |||
| pmurias hates the autoclosing scope hack | 12:03 | ||
| timotimo | i don't know what you mean? | 12:04 | |
| pmurias | when you use a lexical scope that doesn't exist yet MoarVM makes up a "fake" one | 12:08 | |
| timotimo | i didn't know that | ||
| pmurias | m: class Foo {...};Foo.foo; class Foo {my $foo = 123; method foo() {say($foo)}}; Foo.foo | 12:09 | |
| camelia | (Any) 123 |
||
| jnthn | pmurias: Most typically that means that we're going to take care of closure cloning ourselves | ||
| As Rakudo does with Block.clone | |||
| timotimo | ah | 12:11 | |
| jnthn | pmurias: If you hate it enough you'll implement something you do like that solves the same problems but somehow better ;-) | 12:13 | |
| pmurias | jnthn: I think it's the problems it solves that I hate :) | 12:14 | |
| the bugs that are worked around with autoclosing I think I'll have to fix at some point to emit decent code | 12:18 | ||
| user code using scopes that don't exit yet is unfortunate | 12:20 | ||
| jnthn: from testing things it seems when you clone a declaration_static that has an already set outer scope you get a closure that doesn't get affected by outer scope updates but when you clone one that doesn't have it set yet, it shares it? | 12:24 | ||
| Zoffix | squashable6: status | 15:18 | |
| squashable6 | Zoffix, ⚠🍕 Next SQUASHathon in 1 day and ≈18 hours (2017-10-07 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day | ||
| Zoffix | m: «"mark ticket LHF and explain how to fix it" "fix it yourself and make a bug sandwich"».pick.say | 15:19 | |
| camelia | fix it yourself and make a bug sandwich | ||
| Zoffix | Well, you can't argue with a bot. | ||
| buggable: tag lhf | |||
| buggable | Zoffix, There are 4 tickets tagged with LHF; See fail.rakudo.party/t/LHF for details | ||
| Zoffix | hm OTOH we could use more LHFs | 15:20 | |
| ZofBot: man, 2015 Zoffix was such a n00b | 15:23 | ||
| ZofBot | Zoffix, I am supposed to write a document xD damn :) it's dinner time here first www | ||
| Zoffix | Anyone with OSX who can try running this: perl6 -e 'say (await start { qx/echo foo/ }).perl' | 15:26 | |
| Does it output "foo\n" or something else? rt.perl.org/Ticket/Display.html?id...et-history | |||
| [Tux] | This is Rakudo version 2017.09-203-g98fae3d84 built on MoarVM version 2017.09.1-553-ga4fef0bd | ||
| csv-ip5xs 1.216 - 1.238 | |||
| test 9.773 - 9.786 | |||
| test-t 3.224 - 3.269 | |||
| csv-parser 0.906 - 0.919 | |||
| Zoffix | .ask AlexDaniel so what makes a ticket LHF? I figured out a fix for a couple of tickets (e.g. #125818 )and marked them LHF and commented the fix... but now I think that's kinda lame and people wouldn't wanna do these already-solved tickets. | 15:40 | |
| yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
| synopsebot | RT#125818 [open]: rt.perl.org/Ticket/Display.html?id=125818 [LHF] error message: Inf.base(16) | 15:41 | |
| buggable | New CPAN upload: Foo-Bar-Perl6-0.10.tar.gz by TBROWDER www.cpan.org/authors/id/T/TB/TBROW....10.tar.gz | 15:45 | |
| New CPAN upload: Foo-Bar-Perl6-0.10.zip by TBROWDER www.cpan.org/authors/id/T/TB/TBROW...6-0.10.zip | |||
| New CPAN upload: Foo-Bar-Perl6-1.2.3.tar.gz by TBROWDER www.cpan.org/authors/id/T/TB/TBROW...2.3.tar.gz | |||
| New CPAN upload: Foo-Bar-Perl6-1.2.3.zip by TBROWDER www.cpan.org/authors/id/T/TB/TBROW...-1.2.3.zip | |||
| Zoffix wonders why those URLs are 404s.... | 15:48 | ||
| Does Perl6 assume the source code files are UTF-8? Or does it try to guess? | 15:49 | ||
| Like, on the language level. There's a ticket to implement EVAL Buf where Buf is converted using the same methods as if it were bytes from source file.... wonder what that process is for source files | 15:50 | ||
| timotimo | i think it assumes | 15:51 | |
| we do have a commandline flag i believe | 15:52 | ||
| --encoding=mode specify string encoding mode | |||
| it doesn't say that it's for the input, though | |||
| but it just passes that to the open function when reading from the filename | 15:53 | ||
| ilmari | Zoffix: whatever mirror www.cpan.org is resolving to for you (and me) hasn't caught up yet | ||
| timotimo | i got that from nqp's HLL/Compiler, btw | ||
| ilmari | cpan.metacpan.org has them | 15:54 | |
| cpan.metacpan.org/authors/id/T/TB/...DER/Perl6/ | |||
| they're both fastly, but presumably different origins, and different expiry policies | |||
| pmurias | jnthn: re question, I figured it out from reading the MoarVM source how it works | 15:55 | |
| Zoffix | Thanks. | 15:56 | |
| .tell AlexDaniel never mind. I changed my mind. The hunter does not give up their prey. Raaaaawwwrr \o/ | 16:09 | ||
| yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
| AlexDaniel | Zoffix: for me personally, the fact that someone came up with a solution in their head does not discourage me from working on a ticket | 16:11 | |
| yoleaux | 15:40Z <Zoffix> AlexDaniel: so what makes a ticket LHF? I figured out a fix for a couple of tickets (e.g. #125818 )and marked them LHF and commented the fix... but now I think that's kinda lame and people wouldn't wanna do these already-solved tickets. | ||
| 16:09Z <Zoffix> AlexDaniel: never mind. I changed my mind. The hunter does not give up their prey. Raaaaawwwrr \o/ | |||
| synopsebot | RT#125818 [open]: rt.perl.org/Ticket/Display.html?id=125818 [LHF] error message: Inf.base(16) | ||
| AlexDaniel | and you never know if this solution actually works | ||
| Zoffix | Well, I tested it :) | 16:12 | |
| jnthn | pmurias: Ah, glad you got it figured. Was busy with $other-job. :) | ||
| AlexDaniel | then you might have as well committed it instead of leaving a comment :D | ||
| Zoffix: maybe RT #126669 is a good example of that. Somebody investigated a little bit and proposed a solution. There's no code but it's very clear what has to be done. Great LHF ticket IMO | 16:14 | ||
| japhb | Zoffix: To me LHF means two things: 1. Fixes that require little effort given their value, 2. Fixes that are small enough to help someone onramp to contributing to a code base without getting frustrated. Basically just enough to learn how to PR, write a test, mark a bug fixed, etc., and get a quick rush of happy brain chemistry. | ||
| synopsebot | RT#126669 [open]: rt.perl.org/Ticket/Display.html?id=126669 [LHF][LTA] error with "need 6"/"use 6" (no "v") | ||
| AlexDaniel | “of that” – a good example of a LHF ticket | ||
| Zoffix wouldn't get happy brain chemistry by being the delivery boy for a fix someone else created :) | 16:15 | ||
| ZofBot: I guess we're different that way! | |||
| ZofBot | Zoffix, 5x faster than the top one, testing it only for numbers under 1000 gist | ||
| japhb | Zoffix: That's why it's valuable to have *both* "solution-described, just do the footwork" and "solution unknown but expected easy" LHF bugs. | 16:16 | |
| That way beginners can pick which to do. | |||
| AlexDaniel | yeah | ||
| Zoffix | m: say Blob ~~ Cool | 16:17 | |
| camelia | True | ||
| Zoffix | m: say utf8 ~~ Cool | ||
| camelia | False | ||
| Zoffix | Isn't utf8 a more precise Blob that surely can be a Cool? | ||
| japhb | .oO( utf8 may think it's cool, but Cool disagrees. ) |
||
| Zoffix | m: say [.^mro, .roles] with "x".encode | ||
| camelia | No such method 'roles' for invocant of type 'utf8'. Did you mean any of these? does roll in block <unit> at <tmp> line 1 |
||
| Zoffix | m: say [.^mro, .^roles] with "x".encode | ||
| camelia | [((utf8) (Any) (Mu)) ((Blob[uint8]) (Positional[T]) (Stringy))] | ||
| jnthn | m: (supply loop { emit Bool.pick }).tap: *.say | 16:18 | |
| camelia | ( no output ) | ||
| jnthn | m: react whenever (supply loop { emit Bool.pick }) { .say } | 16:19 | |
| camelia | ( no output ) | ||
| Zoffix | Blob ~~ Cool being True seems off; Blob is a role, Cool is a class. Why does it give True? :S | ||
| jnthn | Zoffix: Not sure, seems odd to me also | ||
| timotimo | yeah with a { } around the inner loop it works | 16:20 | |
| Zoffix | m: say role Meows is repr("VMArray") is array_type(int) {} ~~ Cool | ||
| camelia | True | ||
| Zoffix | hm, ok | ||
| jnthn | m: react whenever (supply { loop { emit Bool.pick } }) { .say } | 16:21 | |
| m: (supply { loop { emit Bool.pick } }).tap: *.say | |||
| timotimo: heh, nice catch | |||
| timotimo | (wait for it) | ||
| jnthn | I guess it's not sinking | ||
| timotimo | it relies on sinking to work? | 16:22 | |
| camelia | (timeout)True False False True True True False True False False False True True False False True True False False False True True False False True True False False False False False False Fa… |
||
| (timeout)False True True True True False False True False False False True True False True False True False False True False True False True False False True False False False True False Tru… |
|||
| jnthn | Well, more like sink context I guess | ||
| lazy loop { ... } is a thing | |||
| timotimo | m: react whenever (supply emit "hi") { .say } | ||
| camelia | hi | ||
| timotimo | mhm | ||
| m: react whenever (supply { lazy loop { emit Bool.pick } }) { .say } | 16:23 | ||
| m: react whenever (supply eager loop { emit Bool.pick }) { .say } | |||
| m: react whenever (supply sink loop { emit Bool.pick }) { .say } | |||
| Zoffix | man, someone should make camelia multi-threaded. You guys are blocking the bot for me :) | 16:24 | |
| camelia | (timeout)False True True False False True True False False True False False False False True True False True False True True True True True False False False True True True False False True… |
||
| (timeout)True True False True True True False False True True True False True True True False False False False False True True False False False True False False False True True True False… |
|||
| (timeout)True False True True True True False True True True False True True True True False True True False False False False True True True False True True True True False True False Tru… |
|||
| timotimo | m: react whenever (supply lazy loop { emit Bool.pick }) { .say } | 16:25 | |
| hm, all of these work, eh? | |||
| camelia | (timeout)False True False False True False True False True True True True False False True False False True True False False True False False True False False True True False False False Fal… |
||
| Geth | roast: 0e9d6ff7c2 | (Jonathan Worthington)++ | S17-procasync/stress.t Test for RT #122709 |
16:36 | |
| synopsebot | RT#122709 [open]: rt.perl.org/Ticket/Display.html?id=122709 [CONC][BUG] `await`ing a Promise in a different thread sometimes hangs | ||
| Zoffix | Well, I now see why EVAL(Buf) was never implemented... :) it's src/core/control.pm before stuff like Blob or Stringy (or Positional, I'm guessing) are defined.... | 17:38 | |
| Wonder if it even needs to be this early | 17:39 | ||
| Block.pm uses it, but I think it'll be already if it's post-delcared or something | 17:40 | ||
| ZOFFLOP: t/spec/S17-supply/unique.t t/spec/S11-modules/nested.t | 17:48 | ||
| ZOFVM: Files=1276, Tests=152529, 156 wallclock secs (22.81 usr 3.45 sys + 3353.48 cusr 233.36 csys = 3613.10 CPU) | 17:49 | ||
| Geth | rakudo/nom: 38186fcdf7 | (Zoffix Znet)++ | src/core/Real.pm Improve error on Inf.base Fixes RT#125818: rt.perl.org/Ticket/Display.html?id=125818 |
17:58 | |
| synopsebot | RT#125818 [open]: rt.perl.org/Ticket/Display.html?id=125818 [LHF] error message: Inf.base(16) | ||
| Zoffix | not ok 3 - .message matches /'Cannot coerce NaN to an Int'/ | 18:23 | |
| # Failed test '.message matches /'Cannot coerce NaN to an Int'/' | |||
| # at SETTING::src/core/Any-iterable-methods.pm line 672 | |||
| # Expected: /'Cannot coerce NaN to an Int'/ | |||
| # Got: Cannot convert NaN to Int: | |||
| We really should do something with tests like these :/ | 18:24 | ||
| Gah, it was 2016 Zoffix that added them. | 18:26 | ||
| 6.c-errata fails for me t/spec/S04-phasers/end.t | 18:41 | ||
| But seems due to this: github.com/perl6/roast/commit/e29b...3c1a7d28cc | 18:42 | ||
| I mean. errata test tests for bitshifted code while master doesn't. :| | |||
| And for some reason t/packages/Test/Util.pm doesn't get recompiled or something | 18:43 | ||
| nope, not it. tossed all .precomp dirs and the issue still there :S | |||
| Oh, it's damn September Zoffix breaking stuff | 18:46 | ||
| ZofBot: that guy's starting to piss me off | |||
| ZofBot | Zoffix, I'm a bit surprised it allows it, but I guess the actual constraint is loose enough that you get away with it if you never made an instance of the class | ||
| AlexDaniel | .tell MasterDuke maybe RT #123926 is for you | 18:47 | |
| yoleaux | AlexDaniel: I'll pass your message to MasterDuke. | ||
| synopsebot | RT#123926 [new]: rt.perl.org/Ticket/Display.html?id=123926 [BUG] LTA error message without Levenshtein distance suggestion when mistyping enum value in signature in Rakudo | ||
| Zoffix | With github.com/perl6/roast/commit/0940...d986c01f22 | ||
| 6.c-errata t/spec/S17-supply/basic.t fails. | 18:48 | ||
| Geth | nqp: fb1e5ccd39 | usev6++ | 10 files [jvm] Update stage0 for modified core op 'div_i' |
||
| nqp: 6dc507f35e | usev6++ | 2 files [jvm] Die with 'Division by zero' in div_i, try 2 Without this change a division by zero led to a Java exception: java.lang.ArithmeticException: / by zero For some reasons that didn't work well with 'dies-ok'. As a result t/nqp/059-nqpop.t was blowing up on the jvm backend. With this patch 'make test' is clean, again. Also, the error message is now identical to the other two backends. |
|||
| bartolin hopes he got the stage0 thing right, this time | |||
| Zoffix | AlexDaniel: Looks like this needs to be applied to 6.c-errata but cherry-pick fails and I'm too lazy to fix the conflicts: github.com/perl6/roast/commit/7ece...4d30343bca | 18:50 | |
| Or rather, I'm too deep down the rabbit hole for it. | |||
| I went in with this to fix Inf.base(16) LTA error lol :) I guess I'm glad I didn't leave it as LHF | |||
| AlexDaniel | I'll cherry-pick it now | 18:51 | |
| Geth | roast/6.c-errata: 559661b979 | (Zoffix Znet)++ | 2 files Fix broken test function usage No change in the behaviour being tested. The `is_run` routine comes from Test::Util, which was recently updated. The updated version does not expect the user to do the bit shifting business on the exit code. Fix by removing that stuff from the tests that use this routine. [1] github.com/perl6/roast/commit/0940...d986c01f22 |
18:53 | |
| Zoffix | ZOFVM: Files=1276, Tests=152541, 160 wallclock secs (22.61 usr 3.57 sys + 3423.62 cusr 243.30 csys = 3693.10 CPU) | 19:00 | |
| Geth | rakudo/nom: 2e72652826 | (Zoffix Znet)++ | src/core/Exception.pm Implement X::Numeric::CannotConvert exception It's a generic exception to throw when a numeric cannot be converted to something (gonna use it for Inf -> Int coercion). Ideally, X::Numeric::Real would be removed and this exception be used in its place, but there are 6.c-errata tests expecting X::Numeric::Real to exist, so I left it in as just an empty subclass of X::Numeric::CannotConvert |
19:02 | |
| rakudo/nom: f04bd1d617 | (Zoffix Znet)++ | src/core/Num.pm Fail with a typed exception when failing Num.Int |
|||
| roast: fcee82fcff | (Zoffix Znet)++ | 2 files Do not test for exact error message text The tests are not part of 6.c-errata. The actual message changed due to removed article. Change tests to look for proper typed exception instead. |
|||
| travis-ci | NQP build passed. usev6 '[jvm] Die with 'Division by zero' in div_i, try 2 | 19:04 | |
| travis-ci.org/perl6/nqp/builds/283328904 github.com/perl6/nqp/compare/3b135...c507f35e28 | |||
| Geth | roast: 48ea502f0d | (Zoffix Znet)++ | S32-num/base.t Test Inf/NaN.base throws useful error RT#125818: rt.perl.org/Ticket/Display.html?id=125818 Rakudo fix: github.com/rakudo/rakudo/commit/38186fcdf7 github.com/rakudo/rakudo/commit/2e72652826 github.com/rakudo/rakudo/commit/f04bd1d617 |
19:06 | |
| synopsebot | RT#125818 [open]: rt.perl.org/Ticket/Display.html?id=125818 [LHF] error message: Inf.base(16) | ||
| Geth | roast/6.c-errata: a4c41c25a2 | (Jonathan Worthington)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | S17-supply/basic.t Remove tests with some odd exepctations They claimed to cover RT #123477, and there are indeed tests in this file that cover that issue. However, these tests went further: they expected not only that the protocol would be enforced from the point of view of an individual tap (which is what the RT ticket was using), but also that this would carry over to future taps of the same Supply. ... (10 more lines) |
19:08 | |
| synopsebot | RT#123477 [resolved]: rt.perl.org/Ticket/Display.html?id=123477 Supply.done doesn't seem to terminate anything | ||
| AlexDaniel | “exepctations” huh… | ||
| Zoffix | :) | ||
| AlexDaniel | it feels like it could have figured it out by itself. I wonder if there's some flag to make the diff try harder | 19:10 | |
| it's exactly the same chunk of code being removed, but I guess it got confused because everything below that chunk was different | 19:11 | ||
| whatever | |||
| Zoffix | .in 6h check if we can change X::Numeric::CannotConvert's $.target.^name to just $.target, which the .^name bit done by the user, if needed | 19:12 | |
| yoleaux | Zoffix: I'll remind you on 5 Oct 2017 01:12Z | ||
| Zoffix | .botsnack | 19:13 | |
| yoleaux | :D | ||
| Zoffix | \o/ no more synopsebot stealing snacks :) | ||
| synopsebot: botsnack | |||
| synopsebot | Zoffix, om nom nom nom | ||
| Zoffix | :) | ||
| Zoffix & | |||
| gfldex | is the new JIT already active by default? | 20:12 | |
| Zoffix | Yes, AFAIUI | ||
| lizmat hasn't seen any speedups yet, just a slower make spectest :-( | 20:17 | ||
| jnthn | Spectest is the worst case for pretty much any optimization except those that improve startup time | 20:26 | |
| Test.pm is about the only thing that gets hot-ish, and in most cases the test is over before we've time to compute the optimized version | |||
| lizmat | jnthn: which then also is true for any short-lived batch jobs :-( | 20:27 | |
| because that's what the spectest basically is :-( | 20:28 | ||
| jnthn | Well, yes and no | ||
| heh, short-lived batch job...where's the batch? :P | 20:29 | ||
| But such jobs are rarely scheduled 16+ at a time, anyway | |||
| Which is the other thing: we may well have moved the optimization to another thread so wallclock time is less impacted by us doing more optimization work...but if you have a bunch of processes doing that it'll be much more noticable. | 20:31 | ||
| Zoffix | I thought the merge wasn't expected to bring any speedups but will let us add more optimizations in the future | 20:33 | |
| merge of moar-jit branch I kean | |||
| *mena | |||
| >_< | |||
| jnthn | Zoffix: Yeah, it's largely new infrastructure that will do a bit better at some things, but we're hardly exploiting it at all yet | 20:35 | |
| But it likely does cost some more cycles already, which spectest will be more sensitive to | |||
| lizmat: You may or may not find that MVM_SPESH_DISABLE=1 make spectest (and a tweak of the jobs) wins, if spectest time is a drag for you | 20:36 | ||
| lizmat | jnthn: will try in a mo | 20:37 | |
| timotimo | wowza, how did the precomp file for Format::Lisp turn up 275 megabytes | 20:45 | |
| jnthn | o.O | 20:46 | |
| timotimo | i stumbled upon it while looking for stuff to move from my internal drive to my external drive | 20:47 | |
| hm, i want to give moarvm a mode that skips the first up to 128 bytes until it finds the magic string | 20:48 | ||
| for --dump | |||
| my system is misbehaving :\ | 20:51 | ||
| gfldex | I do see a slight speedup on the box with many cores | 20:52 | |
| timotimo | i think it's from the process i had segfaulting | 20:54 | |
| japhb | Why doesn't the new JIT give immediate improvements? From comments above and previously, my mental model is "More startup time, more effort spent to produce the jitted code, and not as many ops with JIT definitions." | 20:57 | |
| Is that correct, or is there something else? | 20:58 | ||
| timotimo | the exprjit is a part of the template jit. anything it can't handle it'll just fall back to the template jit | ||
| but it tries to gobble up multiple pieces of bytecode in one go | 20:59 | ||
| japhb | "template jit" ~~ "old jit"? | ||
| timotimo | aye | ||
| japhb | So it wasn't a wholesale replace but an add-on? | ||
| Ah | |||
| timotimo | yup | ||
| japhb | So that indicates that only the first two pieces of my mental model could apply: startup time, and effort spent per jitted block | 21:00 | |
| dogbert2 | lizmat: have noticed that parsetime is up 30-50% on some spectest files when comparing with 2017.07 | 21:01 | |
| japhb | (Since # of ops jitted would by design no less than before) | ||
| *would be | |||
| timotimo | there's now also a "cost function" to tune so that it selects the best way to turn what it thinks should be done into actual assembly language pieces | 21:02 | |
| are you good at reading assembly? i'm not :) | |||
| japhb | timotimo: Can you give an example? | 21:03 | |
| lizmat | make spectest: 370 seconds, with MVM_SPESH_DISABLE=1 308 seconds | ||
| jnthn: ^^^ | |||
| jnthn | There you are then | ||
| japhb | (I was quite good at reading Intel-format assembly, but I never got in the habit of reading gas-format) | ||
| timotimo | japhb: you can get it to spit out actual binary dumps into a folder, along with an index file that tells you what is what | ||
| japhb | I meant, can you explain what the cost function actually tunes? What options is it trying to decide between? | 21:05 | |
| Geth | rakudo/nom: cef3bf3e75 | (Elizabeth Mattijsen)++ | 2 files Take 2 on getting $/ info into auto-generated methods - make sure we null out current-match at end of compilation as well - --profile now shows the line of the class definition |
||
| jnthn | japhb: The expression JIT takes a tree representing the program to produce and "tiles" it. Those tiles determine the assembly that's produced. | 21:06 | |
| japhb: The costs drive tile selection, the aim being to pick the set of tiles of lowest cost | |||
| japhb | jnthn: I remember that from brrt's early explanations ... ah, OK | ||
| timotimo | brrt gave an example at one point, i don't remember what exactly it was | ||
| japhb | jnthn: So it doesn't do exhaustive search, but he's tuning the tiling equivalent of A*'s cost function? | 21:07 | |
| jnthn | japhb: And the costs are based on how expensive executing that tile is likely to be (things like instruction count, memory access, etc.) | ||
| japhb | hmmm | ||
| jnthn | I suspect the paper is referenced somewhere | ||
| gfldex | how are the chances to the the JIT output caches alongside precompiled bytecode? | ||
| timotimo | low, gfldex | 21:08 | |
| japhb | Is it aware of the interactions between neighboring tiles? Meaning, because reading a line of memory is likely cheaper the next time you do it? | ||
| timotimo | i think only if you make big enough tiles to cover something like that? not sure | 21:09 | |
| japhb | Ah, OK. | ||
| jnthn | japhb: I didn't dig into it that deeply yet, tbh; brrt would of course know the details :) | ||
| japhb wonders how deep the rabbit hole before one can contribute there | 21:10 | ||
| timotimo | brrt hopes it doesn't go very deep | ||
| japhb keeps typing sentences that are missing | |||
| jnthn | Pretty sure citeseerx.ist.psu.edu/viewdoc/downl...p;type=pdf is the paper brrt implemented it from | 21:11 | |
| japhb | .oO( "I see you shiver with antici-" ) |
||
| timotimo | japhb: you could have a look at the expr files | 21:12 | |
| jnthn | I read through the docs and while understanding the exact details of the tiling algo is likely quite deep, actually writing tiles and assigning costs is eaiser; the docs suggest how to do that | 21:13 | |
| japhb | What is the granularity of the fallback to the template JIT? Does the new JIT fall back if it can't JIT an entire block? I'm noticing that there are only a few tiles defined, especially among math ops. | 21:15 | |
| jnthn | Per basic block, I believe | ||
| japhb | Hmmmm. | 21:16 | |
| timotimo | getting multiple BBs into one go is a future goal | ||
| oh | 21:17 | ||
| this is about falling back | |||
| the exprjit kicks in at the beginning of every BB and tries to get as much as it can | |||
| it can fall back right in the middle of a BB | |||
| jnthn | I guess it'll do better once we fuse BBs at the end of spesh, too | 21:19 | |
| Especially since I went on a BB honesty rampage in the summer :) | |||
| timotimo | i imagine it could | ||
| japhb | timotimo: So the BB will have half code generated by exprjit and then half by template JIT? | ||
| timotimo | yeah, i've stumbled over many spesh graphs with series of fully empty BBs | ||
| that is correct | |||
| jnthn | japhb: Yeah, that's what the code looked to be doing to me | ||
| There's an instruction iterator, it eats all it can, and then leaves the test to the template JIT | |||
| japhb | Interesting. I wonder how he bridges the register allocation .... | 21:20 | |
| Geth | rakudo: Tyil++ created pull request #1180: Check configuration file's existence before opening |
21:22 | |
| timotimo | japhb: i'd assume "spill everything" | ||
| jnthn gone for a bit, or maybe until the morning :) | 21:26 | ||
| o/ | |||
| timotimo | japhb: you can also look at the jit log to see it spit out graphviz graphs for individual pieces | 21:27 | |
| tyil | I just opened github.com/rakudo/rakudo/pull/1180/files, would adding a message like "No pre-existing configuration file found at <path>" be appreciated instead of it silently skipping that path? | 21:36 | |
| [Coke] | s/configuration file/installed file/ maybe. | 21:44 | |
| tyil | [Coke]: added and pushed that to the pr | 21:46 | |
| timotimo | this looks for nqp binaries, right? | 21:47 | |
| tyil | I dont know that much, just that it generated the warning described in the pr comment | 21:48 | |
| and someone recommended me to try and fix it, so thats what I'm trying | |||
| timotimo | i see | 21:49 | |
| travis-ci | Rakudo build failed. Zoffix Znet 'Implement X::Numeric::CannotConvert exception | 22:43 | |
| travis-ci.org/rakudo/rakudo/builds/283335906 github.com/rakudo/rakudo/compare/3...7265282694 | |||
| buggable | [travis build above] ☠ All failures are due to: failed make test (1 failure). Across all jobs, only t/04-nativecall/13-cpp-mangling.t test file failed. | ||
| timotimo | japhb: if you wanna, maybe takedispatcher would be a nice place to start. i see it break off the exprjit a bunch of times | 22:47 | |
| though from grepping and tallying up it looks like atkey_o is the top instruction that stops the exprjit in its tracks | 22:51 | ||
| looking closer at the jit log pays off, though. for example, band_i occurs a bunchton, but almost always in front of an if_i or unless_i | 22:56 | ||
| i.e. immediately preceding the end of a bb | |||
| mudman | squash: status | 23:11 | |
| squashable6 | mudman, ⚠🍕 Next SQUASHathon in 1 day and ≈10 hours (2017-10-07 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day | ||
| timotimo | japhb: i have an idea for how to get more info about bytecode offsets in the bin files, let's see if i can get it to work | 23:35 | |
| japhb | timotimo: Ah, thank you. | 23:43 | |
| ++timotimo | |||
| timotimo | okay, huh, it's a lot more complicated than i thought ... of course | ||
| Geth | rakudo/nom: fab0667f76 | (Patrick Spek)++ | tools/lib/NQP/Configure.pm Check for the config file's existence before trying to open it |
||
| rakudo/nom: f1908a6855 | (Patrick Spek)++ | tools/lib/NQP/Configure.pm Add output line indicating a file is not found |
|||
| rakudo/nom: a28c00a1f3 | (Zoffix Znet)++ (committed using GitHub Web editor) | tools/lib/NQP/Configure.pm Merge pull request #1180 from Tyil/resolve-not-found-warning Check configuration file's existence before opening |
|||
| tyil | \o/ | 23:44 | |
| timotimo | i thought i could just ask dasm what the current insert position for the bytecode buffer is after each tile emitted its stuff | 23:45 | |
| brrt would know if it's possible to get the actual asm bytecode offset at that stage, and how to do it reliably | 23:46 | ||
| bedtime for now, though | 23:53 | ||
| japhb: you should be able to test pre-/post-merge performance with the MVM_JIT_EXPR_DISABLE env var |