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)