Zoffix | ZOFFLOP: t/spec/S11-modules/nested.tt | 00:28 | |
ZOFVM: Files=1280, Tests=152658, 152 wallclock secs (20.89 usr 3.29 sys + 3266.20 cusr 168.23 csys = 3458.61 CPU) | |||
m: use <t/spec/packages/>; | 00:29 | ||
camelia | 5===SORRY!5=== Error while compiling <tmp> Undeclared routine: use used at line 1 |
||
Zoffix | weird that appears to silently succeed in roast test files | ||
oh I get it | 00:30 | ||
m: use </tmp>; use Meow | |||
camelia | ===SORRY!=== Could not find Meow at line 1 in: /home/camelia/.perl6 /home/camelia/rakudo-m-inst-1/share/perl6/site /home/camelia/rakudo-m-inst-1/share/perl6/vendor /home/camelia/rakudo-m-inst-1/share/perl6 CompUnit::Rep… |
||
Zoffix | It thinks it might be a routine but my module use crashes before it can complain about routine | ||
ZOFVM: Files=1280, Tests=152672, 208 wallclock secs (21.12 usr 3.38 sys + 3410.68 cusr 166.75 csys = 3601.93 CPU) | 00:57 | ||
t/spec/S17-channel/stress.t took its sweet time this run | |||
Geth | rakudo/nom: df01ad97e5 | (Zoffix Znet)++ | src/core/ThreadPoolScheduler.pm Fix lockup when scheduling with degenerate delays - If delay is smaller than 0.001s (including negatives), translate that to zero - Do not warn about too-low timer resolutions if delay is zero, since zero delays have proper meaning - If interval is smaller than 0.001s (including negatives), translate that to 0.001s and warn Fixes hangs when Promise.at is given a time in the past or .in is given a negative value. |
01:00 | |
rakudo/nom: 031f8cf77c | (Zoffix Znet)++ | t/05-messages/10-warnings.t Test Supply.interval with low values warns |
|||
roast: baa8ccbb30 | (Zoffix Znet)++ | 3 files Test Promise.in/at/Supply.interval with degenerate delays Rakudo fix: github.com/rakudo/rakudo/commit/df01ad97e5 |
01:01 | ||
MasterDuke | Zoffix: "inlcuding" | 01:02 | |
Geth | rakudo/nom: e4c32b3a01 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/ThreadPoolScheduler.pm Fix typo in comment; MasterDuke++ |
01:04 | |
nqp: 81c890c8b6 | (Zoffix Znet)++ | tools/build/MOAR_REVISION Bump MoarVM |
01:20 | ||
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...2-g676723d | |||
rakudo/nom: 4f5fc520da | (Zoffix Znet)++ | tools/build/NQP_REVISION Bump NQP |
01:21 | ||
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....8-g81c890c 4c37007296 | (Zoffix Znet)++ | t/02-rakudo/10-nqp-ops.t RT#132300: rt.perl.org/Public/Bug/Display.html?id=132300 |
|||
synopsebot | RT#132300 [open]: rt.perl.org/Ticket/Display.html?id=132300 [SEGV] say nqp::getlexdyn('&DEPRECATED') | ||
BenGoldberg wonders why quietly is only documented in docs.perl6.org/language/control#quietly and not as a normal routine. | 04:02 | ||
nine | \o | 05:49 | |
yoleaux | 2 Oct 2017 06:32Z <brrt> nine: i've been meaning to make all JIT errors nonfatal | ||
14 Oct 2017 12:09Z <Zoffix> nine: I moved geth to hack. Something was wrong with the geth box. GitHub couldn't connect and I couldn't telnet to geth port's either (said connection refused). I tried restarting geth several times and connecting using localhost to geth's listener worked, but not from outside network. So I stopped the geth service on geth box (but did not remove it entirely) and set up a geth service on hack and | |||
14 Oct 2017 12:09Z <Zoffix> nine: moved webhooks of all of our repo's to hack's geth. | |||
AlexDaniel` | #131780, #128172, #131780 | 07:29 | |
synopsebot | RT#128172 [new]: rt.perl.org/Ticket/Display.html?id=128172 [SEGV] perl6 crash, double free or corruption | ||
RT#131780 [open]: rt.perl.org/Ticket/Display.html?id=131780 [Double Free] Crash while running test | |||
[Tux] | This is Rakudo version 2017.09-438-g4c3700729 built on MoarVM version 2017.09.1-605-gbedc8511 | 08:01 | |
csv-ip5xs 1.179 - 1.237 | |||
test 8.621 - 9.323 | |||
test-t 3.093 - 3.267 | |||
csv-parser 11.916 - 12.646 | |||
gfldex | jnthn: even without any Seq I get errors. Hit chance is >1% tho. | 08:24 | |
jnthn_ | . | 08:53 | |
jnthn | spectesting the merge of hyper-race-rework | 08:59 | |
yoleaux | 17 Oct 2017 22:58Z <gfldex> jnthn: is .cache.hyper itself not threadsafe or are are multiple .cache calls on the same Seq unsafe? (And how the hell do I doc that?) | ||
jnthn | Then will merge | ||
.tell gfldex Multiple .cache calls on the same Seq | |||
yoleaux | jnthn: I'll pass your message to gfldex. | ||
Geth | rakudo/nom: 16 commits pushed by (Jonathan Worthington)++ review: github.com/rakudo/rakudo/compare/4...2580a0a6fb |
09:04 | |
roast/master: 12 commits pushed by (Jonathan Worthington)++ review: github.com/perl6/roast/compare/baa...ba2c8037df |
|||
jnthn | Enjoy. I'll probably not be about much the rest of today. | ||
buggable | New CPAN upload: Sparrowdo-RemoteFile-0.0.1.tar.gz by MELEZHIK cpan.metacpan.org/authors/id/M/ME/...0.1.tar.gz | 09:31 | |
Zoffix | \o/ | 09:59 | |
.tell BenGoldberg 'cause quietly is a control thing, not a routine :) | 10:00 | ||
yoleaux | Zoffix: I'll pass your message to BenGoldberg. | ||
Zoffix | Turns out windows stresstest doesn't really hang but just takes ages: Files=1214, Tests=75079, 3061 wallclock secs (10.09 usr + 1.83 sys = 11.92 CPU) Here's full list of failures on 2017.09-361-g484f987: gist.github.com/zoffixznet/bab4b29...bca2fbf85f | 10:20 | |
Geth | roast: 53eef69a2a | (Zoffix Znet)++ | S02-literals/quoting.t Make S02-literals/quoting.t pass on Windows - Turn on utf8 code page for cmd.exe when using utf8 - Simplify command of new test so we don't have to deal with arg quoting problems |
10:38 | |
Zoffix | one down $n to go | 10:42 | |
Proper failure in the next file | 10:47 | ||
RT#132012 (last comment) | |||
synopsebot | RT#132012 [open]: rt.perl.org/Ticket/Display.html?id=132012 [ANNOYING] Numeric values of signals are wrong (say +SIGUSR1) | ||
travis-ci | Rakudo build failed. Zoffix Znet 'Bump NQP' | 11:10 | |
travis-ci.org/rakudo/rakudo/builds/289303461 github.com/rakudo/rakudo/compare/e...5fc520daa5 | |||
buggable | [travis build above] ✓ All failures are due to: GitHub connectivity (1 failure). | ||
dogbert2 | t/spec/S02-literals/quoting.t ..................................... Dubious, test returned 1 (wstat 256, 0x100) | 12:31 | |
Failed 1/191 subtests | |||
what have I missed? | |||
Zoffix | I might've messed it up for non-windows boxes | 12:34 | |
Ah | 12:35 | ||
Geth | roast: 26aa7dacd5 | (Zoffix Znet)++ | S02-literals/quoting.t Fix clash of quoter char with path separator |
12:37 | |
Zoffix | dogbert2: ^ fixed | ||
dogbert2 | Zoffix++ | 12:38 | |
Zoffix | Looks like NativeHelpers::Blob is failing on latest rakudo travis-ci.org/zoffixznet/perl6-Rem...1354-L1375 | 13:27 | |
No new commits since April and it works fine on my boxes | 13:31 | ||
(with older rakudos on em) | |||
Oh, yeah, rakudobug. See it | 13:32 | ||
I guess it's safe to say there ain't no tests for this new pointer arithmetic feature :P | 13:33 | ||
ZofBot: how do you know it works? | |||
ZofBot | Zoffix, [Exit Page | ||
Zoffix | Oh, I stand corrected. Tests went in with the feature; they just don't test all the new methods | 13:37 | |
japhb | Zoffix: So you have a fix pending for Rakudo that will unbreak NativeHelpers::Blob? Or am I misunderstanding? | ||
timotimo | sounds like it to me | ||
Zoffix | japhb: yes | ||
japhb | Excellent, thank you Zoffix. That's been blocking my rebuild-all runs for a while now. | 13:39 | |
Zoffix | :o | ||
"a while" is at most 11 days, right? | 13:40 | ||
japhb: is there a ticket? | |||
damn google.. turned off my VM while I was stresstesting :( | 13:42 | ||
for some reason my test ain't covering the bug :/ | 13:47 | ||
ZOFFLOP: t/spec/S17-procasync/kill.t | |||
Ah, it got "use lib" | 13:51 | ||
Geth | rakudo/nom: 2fba0ba0d5 | (Zoffix Znet)++ | 2 files Remove UInt type constaint on TypedPointer.add In our very own class we use negative Ints with it. Possibly fixes one of the issues with NativeHelpers::Blob |
13:53 | |
Zoffix | japhb: ===> Install [OK] for NativeHelpers::Blob:ver<0.1.10>:auth<github:salortiz> | 13:57 | |
So I hope that fixes the issue you were havving as well | |||
timotimo | doesn't dbiish require NativeHelpers::Blob to work? | ||
Zoffix | timotimo: yeah, that's where I found the failure; my module uses DBIish | 13:58 | |
timotimo | right | ||
Zoffix | The bug was introed 11 days ago | ||
travis-ci | Rakudo build passed. Zoffix Znet 'Test getlexdyn op does not segfault | 14:03 | |
travis-ci.org/rakudo/rakudo/builds/289307575 github.com/rakudo/rakudo/compare/4...3700729679 | |||
buggable | New CPAN upload: Sparrowdo-RemoteFile-0.0.2.tar.gz by MELEZHIK cpan.metacpan.org/authors/id/M/ME/...0.2.tar.gz | 14:11 | |
japhb | Zoffix: Sorry, had to commute to bus stop. Anyway, yes, that timing is about right. I'll start another rebuild now. | 14:12 | |
Zoffix: Success! | 14:32 | ||
Man, startup time is lousy and variable on this box: 151-182 ms for `time perl6 -e ''` | 14:33 | ||
timotimo | :< | 14:35 | |
ilmari | doesn't rakudobrew do make -j by default? | 14:36 | |
timotimo | don't think so | ||
Zoffix | japhb: I get 0m0.366s on this box :) | 14:38 | |
32bit | |||
timotimo | perl6 -e '' takes between 0.10s and 0.09s; i don't have more precise measurements available :( | 14:40 | |
ilmari | 140-150ms here | 14:41 | |
(freshly built moar-blead) | |||
timotimo | turning off the jit makes it show 0.09 more often than 0.10, otherwise it's 0.10 more often | ||
japhb | timotimo: Interesting, that sounds like the JIT might need some warmup time tuning or so. | 14:56 | |
Zoffix: Ow. Though I'm not terribly surprised that we're pretty slow on 32 bit. | |||
timotimo | the thing is that many things it does will pay off a lot more once there's an actual user program to be parsed | 14:58 | |
japhb is looking forward to trying it on his home laptop, which is considerably faster than his old work computer (which is eligible for refresh, but who has time to futz around with a new work computer?) | 14:59 | ||
timotimo: I just meant, might be worth moving the horizon at which it does something either earlier (so it's at least even in terms of time spent on the empty program) or later (so it doesn't waste much time on super-short programs) | 15:01 | ||
timotimo | thing is, the jit is completely off on its own thread, and shouldn't do much at all | ||
actually, the spesh worker still kicks off new work after moarvm has already started its teardown | 15:02 | ||
japhb | D'oh | 15:03 | |
timotimo | might want to have something in there to do an early abort in that case | ||
but it's not actually a cost for startup | |||
though perhaps it takes that long because it's joining the foreground thread | 15:06 | ||
cool, now it's always at 0.9 | 15:11 | ||
huh. i don't actually see it shut down earlier from the telemetry log though | 15:14 | ||
japhb, Zoffix, please try moarvm's "spesh_faster_shutdown" branch | 15:20 | ||
Zoffix is too busy with other stuff | 15:21 | ||
timotimo | fwiw, i don't expect this to make any difference in actual use cases | 15:22 | |
but the "startup time" will be a more accurate number | 15:23 | ||
tbrowder | nqp question, please: is "unit class Foo; # followed by Foo class guts" allowable for an nqp class module? | 15:27 | |
Zoffix | nqp: unit class Foo; | 15:28 | |
camelia | Confused at line 2, near "unit class" at gen/moar/stage2/NQPHLL.nqp:707 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:panic) from gen/moar/stage2/NQP.nqp:919 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/nqp.moarvm:comp_unit) from gen/mo… |
||
Zoffix | Nope | ||
tbrowder | thnx | ||
Zoffix | buffering seems weird. Looks to kick in only after some output and then instead of buffering it checks to see if a `print` would fit into a buffer and if it doesn't it prints it all (I thought it'd fill the buffer, print it, and put the rest into a new buffer) | 15:45 | |
c: temp.perl6.party/z.txt | |||
committable6 | Zoffix, I cannot recognize this command. See wiki for some examples: github.com/perl6/whateverable/wiki/Committable | ||
Zoffix | c: HEAD temp.perl6.party/z.txt | 15:46 | |
committable6 | Zoffix, Successfully fetched the code from the provided URL. | ||
Zoffix, ¦HEAD(2fba0ba): «123456789|» | |||
Zoffix | Here, I got a 1000byte buffer but the first 10-byte print makes it through; the rest are buffered | ||
c: HEAD temp.perl6.party/z2.txt | 15:47 | ||
committable6 | Zoffix, Successfully fetched the code from the provided URL. | ||
Zoffix, ¦HEAD(2fba0ba): «123456789|123456789|» | |||
Zoffix | And here I got an 8-byte buffer, so I expected 16-bytes of data written, but it wrote out all 20 | ||
jnthn | Why would something that's trying to optimize output spend time breaking stuff up that's over its buffer size? | 15:55 | |
It'd be a bunch of memcpy for something | |||
*for nothing | |||
And the same number of syscalls | 15:56 | ||
Zoffix | OK. What about the first one. Is there a reason why first print misses the buffer? | 15:58 | |
jnthn | Yes. We have tests that try to write to a file handle and expect the write to die immediately if the handle isn't writable | 15:59 | |
When I put stuff into a buffer and did the write later, those would fail | |||
Zoffix | Ah. Cool | 16:00 | |
jnthn | There may or may not be a better option | ||
timotimo | does writing 0 bytes have different failure modes, or just "writing 0 bytes is wrong"? | 16:40 | |
Zoffix used `.print: ''` as a workaround in tests | 16:43 | ||
jnthn has a resolve fest of hyper/race tickets :) | 17:04 | ||
timotimo | yeah! | 17:05 | |
jnthn | timotimo: Not sure about the 0 bytes thing. | ||
May be worth a try, it'd get rid of the surprise. | |||
otoh, it'd be a syscall for nothing instead of a syscall that we could do something useful with :P | |||
timotimo | aye | 17:06 | |
Zoffix leans towards leave the surprise in in trade for perf | 17:07 | ||
jnthn | dinner time o/ | 17:11 | |
[Coke] | oooh, one of the closed hyper tickets is mine. | 17:30 | |
Zoffix | ZofBot: hype the hyper | 17:32 | |
ZofBot | Zoffix, To shallow- Mercy on me! have a great dispositions to cry | ||
Zoffix | m: say 8192.log: 2 | 17:35 | |
camelia | 13 | ||
Zoffix | What's the magicness of 8192 magic constant? It's used as default buffer size | ||
Like, why that number | |||
m: say 0x100000 | 17:36 | ||
camelia | 1048576 | ||
Zoffix | And this is our in-buffer. | ||
m: say 0x2000 | |||
camelia | 8192 | ||
Zoffix | Is that an arbitrary? Kinda hoping to make :in-buffer and :out-buffer to default to same number for ease of rememberiong | 17:37 | |
[Coke] | I assume it's just because power-of-two | 17:42 | |
(but i am not the right person to ask. :) | |||
ugexe | its a pretty common buffer size in other languages | 17:43 | |
Zoffix | ugexe: for both both of those numbers? | ||
ugexe | for recv type buffers | 17:44 | |
input i'm not sure | |||
Zoffix | 0x100000 for input and 0x2000 for output | ||
ok | |||
I'll just leave them as is | 17:45 | ||
Flipping through IO::Handle guts... For :in-buffer, in binary handles, it'll only affect .slurp. I think I'll spec it as :in-buffer use for binary handles is up to implementations and just make the slurp use the in-buffer size instead of 0x100000 chunks it currently uses | 18:04 | ||
And we can define it more specific in later language versions, if needed. | |||
Zoffix & for a few hours | |||
b2gills | Zoffix: 4096 is the page size of most operating systems, and 8192 is twice that. | 19:46 | |
Zoffix | Is that good or bad? | 20:03 | |
moritz | good | 20:06 | |
Zoffix | Is four times the size better? Why specifically 2? | 20:14 | |
Also, why 0x100000 for input and not two pages? | 20:15 | ||
jnthn | It's largely just the usual trade-off between time and memory | 20:17 | |
Well, and latency | |||
Zoffix | Ah | 20:18 | |
jnthn | There's not really a "one size fits all" | ||
japhb | .ask nine Should nqp/rakudo bump their moarvm version to catch your nativecall jit improvements? I would think we should test more before the release, unless it needs more work to be stable again. | 20:55 | |
yoleaux | japhb: I'll pass your message to nine. | ||
Zoffix | japhb: ? I don't see any recent work on that. | ||
yoleaux | 20:37Z <tyil> Zoffix: thats fine too, but as it stands its only causing confusion, so I want to change that at least (I highlighted it to your bot by accident) | ||
Zoffix | Last bump was last night. | 20:56 | |
jnthn | Was committed to MoarVM this mroning | ||
*morning | |||
Zoffix | ah, k, now I see it :) | 20:57 | |
Zoffix bumps | |||
ZOFFLOP: t/spec/S17-procasync/kill.t | 21:09 | ||
Geth | nqp: 254d590bf4 | (Zoffix Znet)++ | tools/build/MOAR_REVISION Bump MoarVM |
||
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...8-ge051ee3 | |||
rakudo/nom: ff063e7b53 | (Zoffix Znet)++ | tools/build/NQP_REVISION Bump NQP |
21:10 | ||
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....9-g254d590 | |||
Zoffix | ZOFFLOP: t/spec/S17-promise/nonblocking-await.t | 22:23 | |
Oh, actually disregard that. The test "hung" and failed 'cause I had some stuff already running on port 3333 it's trying to use | 22:24 | ||
Geth | roast: cf6f2959d7 | (Zoffix Znet)++ | S17-promise/nonblocking-await.t Use a less-likely-to-be-in-use port Test just hangs and then fails if a port is in use and something harder to type at random might not be as likely in use (maybe? :)) |
22:26 | |
rakudo/nom: f9c10c2145 | (Zoffix Znet)++ | src/core/IO/Handle.pm Implement knob for tweaking handle output buffer - Rename[^1] "buffer" open arg to "out-buffer", as we'll be adding another knob for input buffer. The "buffer" will remain under deprecation warning for 3 releases (it was available for just 1 release) [1] irclog.perlgeek.de/perl6-dev/2017-...i_15307167 |
22:28 | ||
roast: 1a7b5f6130 | (Zoffix Znet)++ | S32-io/buffering.t Test output buffering Rakudo impl: github.com/rakudo/rakudo/commit/f9c10c2145 |
22:29 | ||
jnthn | (port conflict) phew, glad it wasn't something harder :) | 22:43 | |
timotimo | we could (should?) build something more robust than hardcoding pseudorandom port numbers in all tests that do network stuff | 22:50 | |
jnthn | That would be nice | 22:54 | |
travis-ci | Rakudo build passed. Zoffix Znet 'Remove UInt type constaint on TypedPointer.add | 22:57 | |
travis-ci.org/rakudo/rakudo/builds/289519414 github.com/rakudo/rakudo/compare/2...ba0ba0d58b | |||
timotimo | having my RSI flare up in the ~2 weeks before a "big" release like this one is extra frustrating :| | 22:58 | |
watching the react-redux introduction video series up on egghead.io; i can now tell that in my last react-using project there should have been many more connect() and mapStateToProps/mapDispatchToProps spread over the whole project | 23:09 | ||
jnthn | :) | 23:15 | |
'night o/ | |||
timotimo | gnite jnthn | ||
Zoffix | \o | ||
Geth | roast: a99c1d5ae1 | (Zoffix Znet)++ | 2 files Rename buffering test file Gonna stuff input buffering tests to another file |
23:27 | |
Zoffix | wonder if buffering stuff Just Works™ on CatHandles | 23:28 | |
japhb | Hmmm, HTTP::UserAgent testing blew up on a build right after the MoarVM bump | 23:47 | |
Zoffix | Was it failing before? | 23:50 | |
IRC::Client is totally busted on recent rakudos | |||
timotimo | i saw an IRC::Client meta-ticket i think? | ||
Zoffix | IRC::Client | 23:51 | |
RT#132191 | |||
synopsebot | RT#132191 [new]: rt.perl.org/Ticket/Display.html?id=132191 [REGRESSION] Possible rakudo regression (issues with IRC::Client) | ||
Geth | rakudo/in-buffer: 3fcd74abf0 | (Zoffix Znet)++ | src/core/IO/Handle.pm Implement input buffering knob in IO::Handle - Simply lets user tweak the size of the buffering we already had - On binary handles, applicable only to chunks read by slurp |
23:59 | |
Zoffix | (too tired to thinks straight to write tests for this; gonna finish it off tomorrow) |