jdv79 did Zoffix not say he was gonna peace out for a while yet i still see stuff from him. 01:26
he cant stop!
Zoffix Nah, I'm playing Fallout 4 instead of fixing R#1533 01:28
synopsebot R#1533 [open]: github.com/rakudo/rakudo/issues/1533 [RFC][regression][⚠ blocker ⚠] /proc/…/status can no longer be read line by line
Zoffix That's relaxing.
MasterDuke is 4 the newest one? 01:30
yoleaux 16 Feb 2018 07:25Z <brrt> MasterDuke: to be honest I'd expect not
Zoffix Yeah
jdv79 hahaha!
take a vaca man! downtime is good for the self. 01:31
Geth nqp: tbrowder++ created pull request #416:
update docs with more information		 02:32
AlexDaniel omg, that's probably the most difficult issue I had to debug :( 03:07
I'm three modules deep now…
although, well, it's probably more annoying than difficult 03:12
whew! 03:32
6c: gist.githubusercontent.com/AlexDan...C2%25BB.p6 03:33
committable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, gist.github.com/bf42bf14c4d02dabf9...c8e4809549 03:34
AlexDaniel bisect: gist.githubusercontent.com/AlexDan...C2%25BB.p6
bisectable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Bisecting by output (old=2015.12 new=beaad7b) because on both starting points the exit code is 0
AlexDaniel whoops, wrong channel
bisectable6 AlexDaniel, bisect log: gist.github.com/5122ed84d14717f350...195e1d856b
AlexDaniel, (2018-01-26) github.com/rakudo/rakudo/commit/1e...65bd8d5d1f
AlexDaniel kk R#1538 03:39
synopsebot R#1538 [open]: github.com/rakudo/rakudo/issues/1538 [regression][⚠ blocker ⚠] Miscompilation of blocks inside interpolating quote-words
AlexDaniel calls it a day
Zoffix yeah, a QAST::Block gets migrated when it shouldn't 04:09
Zoffix is too sleepy to think about it ATM 04:10
Gonna fix it after a power cycle.
ZofBot: prep the power-down chambers!
ZofBot Zoffix, Half an hour later, in the cab going home, Minnie, half asleep, was aroused by a sudden stiffening of the arm that encircled her waist and a sudden snort close to her ear
Zoffix ah, the parens in the code make it lose in_stmt_mod ann 04:18
well, not lose, but have it set at zero 04:21
Zoffix stresstests a fix 04:29
Geth rakudo: 31ab86838c | (Zoffix Znet)++ | src/Perl6/Grammar.nqp
Fix propagation of in_stmt_mod dynvar value

Fixes R#1538 github.com/rakudo/rakudo/issues/1538
We reset $*IN_STMT_MOD to zero on each statement, but inside a statement mod we can begin a new statement, like what happens in the ticket, when parens are added around the stuff.
Fix by setting it to the value of $*IN_STMT_MOD of the caller
  (we still declare a new $*IN_STMT_MOD dynvar, so that the changes
we make to it inside a statement kept restricted to just it)		 04:45
synopsebot R#1538 [open]: github.com/rakudo/rakudo/issues/1538 [regression][⚠ blocker ⚠] Miscompilation of blocks inside interpolating quote-words
roast: 263a35999f | (Zoffix Znet)++ | MISC/bug-coverage.t
Test closure scoping in statement mod

Closes github.com/rakudo/rakudo/issues/1538 R#1538 Rakudo fix: github.com/rakudo/rakudo/commit/31ab86838c		 04:46
Zoffix *now* I can sleep :D
MasterDuke Zoffix++ 05:08
travis-ci Rakudo build failed. Zoffix Znet 'Fix propagation of in_stmt_mod dynvar value 05:25
travis-ci.org/rakudo/rakudo/builds/342651889 github.com/rakudo/rakudo/compare/b...ab86838c31
buggable Failed to fetch build data
travis-ci Rakudo build passed. Zoffix Znet 'Fix propagation of in_stmt_mod dynvar value 06:07
travis-ci.org/rakudo/rakudo/builds/342651889 github.com/rakudo/rakudo/compare/b...ab86838c31
buggable Failed to fetch build data
[Tux] Rakudo version 2018.01-205-g31ab86838 - MoarVM version 2018.01-94-gc7774e37d
csv-ip5xs0.807 - 0.811
csv-ip5xs-207.716 - 7.718
csv-parser11.770 - 12.014
csv-test-xs-200.423 - 0.454
test8.956 - 9.038
test-t2.491 - 2.576
test-t --race1.077 - 1.150
test-t-2046.186 - 47.368
test-t-20 --race15.860 - 15.860
 10:29
Geth nqp: f27a4abc9a | (Tom Browder)++ | 3 files
update docs with more information

changes to file "docs/built-ins.md":
  + add undocumented subs
  + add undocumented methods on a file handle
... (8 more lines)		 10:35
nqp: 11ba4bad13 | (Tom Browder)++ (committed using GitHub Web editor) | 3 files
Merge pull request #416 from tbrowder/update-docs

update docs with more information
pmurias Zoffix: I guess I need to resume working on my get-rid-of-migration branch, as the whole block migration is an ultra ugly hack and a nest of bugs 11:21
Geth roast: d9d4457e35 | usev6++ | S32-io/pipe.t
[JVM] Skip hanging test
 11:33
nqp: tbrowder++ created pull request #417:
rename IO sub "spew" to "spurt"		 13:00
Zoffix pmurias: yeah, it's pretty fragile. 13:13
dogbert17 'No int attribute reference type registered for current HLL' 15:18
hmm
when running MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S32-num/complex.t 15:19
Geth nqp: jstuder-gh++ created pull request #418:
Rakudo RT#102994: Add flag indicating HLL init status in StaticInfo		 15:25
synopsebot RT#102994 [open]: rt.perl.org/Ticket/Display.html?id=102994 [BUG] State variables are never initialized if the first call of the containing block does not reach them
Geth rakudo: jstuder-gh++ created pull request #1539:
RT#102994: State init vars if not set on first pass
Zoffix :/ ZScript doesn't seem to work right when syncing MoarVM files to VM.. after syncing, I tell it to build MoarVM on the VM, but it tells me it's the latest already :/ 15:31
oh nm... I just had another debug print in code 15:32
AlexDaniel o/ 15:34
Zoffix |
__
need to also to teach it to support multiple build dirs, so I could have a judo build along with moarm rakudo 15:35
I'm making it so that .eof on empty files returns False until a read is performed. 15:39
I hope that's sane.
ZOFVM: Files=1289, Tests=153228, 153 wallclock secs (22.06 usr 3.56 sys + 3288.73 cusr 164.22 csys = 3478.57 CPU) 15:44
Geth rakudo: 6ec3d7ce30 | (Aleks-Daniel Jakimenko-Aleksejev)++ | src/vm/moar/ops/container.c
Revert "Clean up handler successors after throwish ops become non-throwing"

This reverts commit baa1393b6d51eef60cca06cd6bb22574f0a30cd3.
Rhesolves #1535.		 15:55
synopsebot RAKUDO#1535 [open]: github.com/rakudo/rakudo/issues/1535 [regression][⚠ blocker ⚠] Some difference between implicit and explicit return
Zoffix ZOFFLOP nqp: t/concurrency/01-thread.t 15:58
FFS, again 16:04
it's killing zscript trying to build stuff -_- 16:05
dogbert17 AlexDaniel: do you get an error if you run MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S32-num/complex.t ? 16:10
AlexDaniel c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD chdir ‘sandbox/roast’; run ‘perl6’, ‘S32-num/complex.t’ 16:16
committable6 AlexDaniel, gist.github.com/350167fced9b7d4588...4427b97e2d 16:17
AlexDaniel dogbert17: what error are we looking for? 16:18
dogbert17 No int attribute reference type registered for current HLL 16:20
I get it after a bunch of 'WARNING: unhandled Failure detected in DESTROY.' 16:22
Zoffix (that last part is R#1502 ) 16:23
synopsebot R#1502 [open]: github.com/rakudo/rakudo/issues/1502 Failure.DESTROY warning sometimes warns when Failure was technically handled
AlexDaniel dogbert17: locally same output, some WARNINGs but otherwise everything is ok 16:25
dogbert17 strange, I'd better rebuild with the latest changes, you reverted something 16:26
it's like this 16:27
No int attribute reference type registered for current HLL
in any at ./blib/Perl6/BOOTSTRAP.moarvm line 1
in sub proclaim at /home/dogbert/repos/rakudo/install/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E (Test) line 705
in sub is at /home/dogbert/repos/rakudo/install/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E (Test) line 174
in block <unit> at t/spec/S32-num/complex.t line 219
AlexDaniel c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD^ chdir ‘sandbox/roast’; run ‘perl6’, ‘S32-num/complex.t’ 16:31
committable6 AlexDaniel, gist.github.com/daf5cfa1034bb9150e...9a0a487a5f
AlexDaniel last revert makes no difference it seems 16:32
dogbert17 gah, I guess we'd better ignore it then until I can come up with something more reliable 16:34
c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD^ chdir ‘sandbox/roast’; run ‘perl6’, ‘S32-num/complex.t’ 16:35
committable6 dogbert17, gist.github.com/4849e77d44dd28d134...b27363a574
AlexDaniel c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD~5..HEAD chdir ‘sandbox/roast’; run ‘perl6’, ‘S32-num/complex.t’ 16:37
committable6 AlexDaniel, gist.github.com/d2577b9a0ace701f14...3bb14902b3
timotimo looking forward to comments on my perl6-users mailing list thread 16:40
dogbert17 added gdb output to G#1540 16:54
i.e. R#1540 16:55
synopsebot R#1540 [open]: github.com/rakudo/rakudo/issues/1540 [SEGV] Some snippet that segfaults
dogbert17 perhaps something for timotimo
timotimo it's weird that it'd crash on that line; does the object seem sane? 16:57
dogbert17 timotimo: no 16:59
(gdb) p obj
$1 = (MVMObject *) 0xffffffff
timotimo oh, yeah, that doesn't look right
can you try MVM_dump_bytecode(tc)? 17:00
dogbert17 (gdb) p MVM_dump_bytecode(tc)
00000 sp_getarg_o loc_0_obj, 0 17:01
00001 set loc_2_obj, loc_0_obj
00002 wval loc_3_obj, 0, 12
00003 sp_p6ogetvc_o loc_4_obj, loc_2_obj, 4, sslot(1)
00004 sp_decont loc_4_obj, loc_4_obj
00005 -> return_o loc_4_obj
$2 = void
timotimo okay so we were grabbing data off of an offset from that other object
that wval is probably left-over un-eliminated stuff from before that opt 17:02
is this supposed to be the "instance" method? 17:03
oh, no, it's foo
actually something called from foo. could be the dump_bytecode is inaccurate
(it's unreliable for some reason i haven't figured out properly yet) 17:04
dogbert17 timotimo: setting MVM_SPESH_DISABLE=1 make the SEGV go away 17:06
*makes
timotimo this is on all master commits?
looks like 17:07
looks like the bytecode you dumped is the supplier method 17:08
dogbert17 aha
timotimo interestingly, locally it crashes already at the p6ogetvc_o op 17:11
dogbert17 timotimo: I'm on 32 bit atm if that makes a difference 17:12
timotimo so the code is trying to call a method that requires an instance on a type object and that explodes, right? 17:14
and it totally is a type object 17:15
so spesh has done an optimization it didn't get away with
Geth roast: 96209b89af | usev6++ | 3 files
[JVM] Fudge some newly added tests
 17:16
dogbert17 interesting 17:20
do you have to check the spesh logs?
timotimo i'm checking them as we speak
i don't actually see the accessor method in here at all though 17:23
ah, that's because i was looking for instance where i should have been looking for supplier 17:24
well that's bad
looks like we just turn an access into an optimized access even when we *know* the object is a type object anyway 17:25
cool. 17:29
this might be the right fix
timotimo makes stresstest 17:30
Zoffix bartolin: you around?
bartolin: what's wrong with this line in Java: `eof = fc.size() > 0 && fc.position() >= fc.size();`. I would've though it'd set `eof` to either `true` or `false`, but some tests fail. But if I rewrite it as `if (eof = fc.size() > 0 && fc.position() >= fc.size()) eof = true else eof = false` then it works fine 17:31
timotimo dogbert17: can you run all the necessary tests with the commit i just pushed to moarvm to check if it's sane? i gotta go AFK right now 17:33
dogbert17 timotimo: will do, thx 17:42
Zoffix gah... last compile stage for JVM; if the bug ain't fixed on it, I'm leaving it. This is too annoying. 17:50
right. still broken. it can get bent 18:04
waste of time
Geth roast: ed59a994cc | (Zoffix Znet)++ | S32-io/io-cathandle.t
Fix EOF proptests on CatHandle with empty files

On zero-size files, we need to perform at least one read for EOF to be set.		 18:13
timotimo dogbert17: it looks like i got a passing stresstest locally, except for a bug that must have been fixed since i last pulled rakudo
Geth nqp: 43d4336974 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 2 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...6-g8d94732 8d94732 Fix eof detection on zero-size files 720705d don't optimize getattr unless known concrete		 18:20
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...6-g8d94732
rakudo: af4dfe827c | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 3 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....9-g43d4336 43d4336 [MoarVM Bump] Brings 2 commits 11ba4ba Merge pull request #416 from tbrowder/update-docs f27a4ab update docs with more information
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...6-g8d94732 8d94732 Fix eof detection on zero-size files 720705d don't optimize getattr unless known concrete
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....9-g43d4336
Zoffix I got a clean stresstest when bumps were being made 18:21
dogbert17 timotimo: agreed, stresstest worked fine on my 32 bit vm
timotimo great 18:22
is this getting into the release that's almost upon us?
Geth roast: 3ac8e0b8ae | (Zoffix Znet)++ | S16-io/eof.t
Test EOF on zero-size files and reads on /proc

Covers github.com/rakudo/rakudo/issues/1533 R#1533
Rakudo fix: github.com/MoarVM/MoarVM/commit/8d94732aad
   github.com/perl6/nqp/commit/43d4336974
   github.com/rakudo/rakudo/commit/af4dfe827c
synopsebot R#1533 [open]: github.com/rakudo/rakudo/issues/1533 [RFC][regression][⚠ blocker ⚠] /proc/…/status can no longer be read line by line
dogbert17 timotimo: I believe so yes 18:24
AlexDaniel timotimo: yes definitely
I mean, you answered that question yourself by comitting to master :) 18:25
Zoffix++
Zoffix ZOFLOP nqp t/concurrency/01-thread.t 18:32
Failed tests: 23-24
timotimo oh, right 18:35
well, i committed to moarvm master, but it could have been that the release-intended bump had already happened
i couldn't pay much attention :(
AlexDaniel that's ok, we can always adjust 18:36
timotimo no, it's okay to have that commit in there
AlexDaniel I mean, if something goes wrong :)
timotimo: what's your opinion on github.com/rakudo/rakudo/issues/1534 ? 18:37
timotimo: that's the last official blocker
Zoffix says SPESH Broken frame: 2402. 18:39
bartolin Zoffix: hmm, the first line looks right to me, too. do you have a gist with the code you tried and the failed tests, maybe? 18:40
yoleaux 20 Jan 2018 13:33Z <psch> bartolin: spectest looks a bit worse than yours at first glance: gist.github.com/anonymous/30ba5ed2...ac2dfe92e2
AlexDaniel bartolin: github.com/rakudo/rakudo/issues/1541 18:41
bartolin ah, thanks. I'll take a look at it later 18:42
Zoffix bartolin: I gave up on it and filed github.com/rakudo/rakudo/issues/1541 with that patch, EOF doesn't seem to be detected any more; at least with `./perl6-j -e 'say "starting"; my $fh := IO::CatHandle.new: <f.txt e.txt f2.txt>; "$_".say for $fh.lines'` where f.txt and f2.txt are files with some text and e.txt is an empty file; this is basically golf of first subtest of S32-io/io-cathandle.t
proptests
timotimo haha, opening those text files in chrome and scrolling past a certain point has mildly hilarious results 19:54
Zoffix ? 19:55
It stops rendering text? 19:56
timotimo first rectangular or maybe square portions are all jumbled up 20:04
then there's almost all black, but white vertical lines in different combinations
Zoffix I didn't see that on Windows Chrome, though I closed it while it was still loading, 'cause I didn't want it to nom all my RAM
timotimo right 20:06
bartolin .tell Zoffix i wasn't able to fix the EOF issue on JVM, yet. I *think* we need something like eof_reported in MoarVM, so that 'read' and friends can report back to the FileHandle when they encounter eof. on a related note: if you modify FileChannel.java it should be enough to do 'make install' for nqp -- no need to recompile rakudo to test your changes. 21:56
yoleaux bartolin: I'll pass your message to Zoffix.
Zoffix bartolin: I thought `eof` attribute was already that, innit? It is set by read methods when they find no more data to read, just like eof_reported on MoarVM 21:59
bartolin Zoffix: yes, but if i'm not mistaken, it's a different instance of 'eof' that is set by read methods 22:00
Zoffix 0.o
bartolin but take that with a grain of salt, i'm tired and 'll go to bed now 22:01
Geth 6.d-prep: 6772d4e4a5 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Clarify title of the `@` == :D proposal
 22:13
AlexDaniel OK, so right now I'm seeing no issues besides github.com/rakudo/rakudo/issues/1534 22:39
Zoffix \o/ 22:40
AlexDaniel everything else seems to be alright
changelog is already available here: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 22:41
kind of, I still want to tweak it a little bit, but people should feel free to edit things they don't like now
(or just tell me what to fix) 22:42
Zoffix AlexDaniel: this was a fix for a bug introed after last release, so I don't think it needs to be in changelog: "Fixed where optimization for Junction args [264a1a27]" and this one "Added native type post-inc/dec to pre- optimization", if it matters, should say "native `num`". The `int` opt already existed in past. This work just made the int one to not apply to custom user subs and added support for `num` 22:52
opt in the process
ooohhhh
And I just now realized this....
m: use nqp; my int32 $x = 42; dd nqp::objprimspec($x) 22:53
camelia 0
Zoffix m: use nqp; my int32 $x = 42; dd nqp::objprimspec(int32)
camelia 1
Zoffix m: use nqp; my int32 $x = 42; dd nqp::objprimspec(int16)
camelia 1
Zoffix Oh, nm, I thought different-sized ints had different objprimspec
AlexDaniel ok 22:56
lucasb AlexDaniel: that's is the full changelog or is it missing the last recent commits? 23:02
AlexDaniel let's see…
lucasb I didn't see a mention of the feature Zoffix++ implemented: github.com/rakudo/rakudo/commit/1d...f000388b26 23:03
AlexDaniel releasable6: changelog gist.githubusercontent.com/AlexDan...tfile1.txt
releasable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Unknown changelog format
AlexDaniel releasable6: changelog gist.githubusercontent.com/AlexDan...tfile1.txt 23:04
releasable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, 198 out of 207 commits logged
AlexDaniel, Details: gist.github.com/a334f9d9746de43c6b...4c2103e9cf
AlexDaniel lucasb: you are right!

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!