AlexDaniel oh right, Malformed UTF-8 issue fixed! 00:32
meaning that quotable6 should now work
and also that I have to update rakudo on the server… 00:33
heh, being on the front line again 05:37
*able tests don't pass, have no idea why
masak AlexDaniel: there was a point where I felt 007 was often a canary in the coal mine for new bugs/features in Rakudo. :) less so now, though. 06:13
mostly because I'm slightly less active myself, I think.
AlexDaniel I don't think I'll be able to golf it this time 06:15
no errors, memory usage is ok 06:16
it just hangs
if I remove some of the previous tests it stops hanging
.tell MasterDuke maybe you have some idea. committable.t and benchable.t hang on the first “Did you mean …” test 06:19
yoleaux AlexDaniel: I'll pass your message to MasterDuke.
masak "if I remove some of the previous tests" is always worrying 06:21
try running without the JIT?
AlexDaniel .tell MasterDuke sorry, bisectable.t and benchable.t. So github.com/perl6/whateverable/blob...ble.t#L165 and github.com/perl6/whateverable/blob...ble.t#L142 06:23
yoleaux AlexDaniel: I'll pass your message to MasterDuke.
AlexDaniel .tell MasterDuke it may be associated with Sift4 module, which is problematic by itself… for example, it's still leaking memory.
yoleaux AlexDaniel: I'll pass your message to MasterDuke.
[Tux] This is Rakudo version 2017.08-79-g4b02b8aad built on MoarVM version 2017.08.1-106-gdd04dd80 06:26
csv-ip5xs 1.314 - 1.428
test 10.362
test-t 3.674 - 3.829
csv-parser 12.040
AlexDaniel masak: same without JIT 06:27
masak ok
well, it seems contingent, so bisecting on Rakudo version might not reveal much
AlexDaniel I think it can tell a lot 06:28
.tell jnthn FWIW this is really annoying when running the spectest: RT #132029 07:15
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132029
yoleaux AlexDaniel: I'll pass your message to jnthn.
nine AlexDaniel: a neat trick for a bit of a simpler shell line is: while clear; ./perl6-m -Ilib t/spec/S17-lowlevel/atomic-ops.t ; do true ; done 07:25
AlexDaniel sure 07:26
[Tux] ===> Installing: JSON::Marshal:ver('0.0.13'):auth('github:jonathanstowe') 07:33
and later when installing META6 07:34
# Could not find JSON::Marshal:ver<0.0.7..*> at line 77 in:
zef has a serious versioning problem
nine m: { my Int $test-cont = 42; ?$test-cont; }; { my atomicint $set = 0; start { sleep 1; $set ?= 1 }; until ?$set { } }
camelia A IntLexRef container does not know how to do an atomic load? in block <unit> at <tmp> line 1??
nine There's the golf :)
Posting to the ticket
[Tux] CSV tests started to fail 07:35
# at t/90_csv.t line 260 07:36
# expected: $[["1", "2", "3"], ["2", "a b", ""]]
# got: $[["1", "2", "3"],]
# Failed test 'AOH parse out'
no time to bisect that right now, must leave for $work
AlexDaniel [Tux]: it is github.com/rakudo/rakudo/commit/4b...77b74cd59d 07:50
bisect log: gist.github.com/62a876b09bfecc9aa3...1e384f43ce
double-check with committable: gist.github.com/50bd16934e6bc93ad4...59cf31bf06 07:51
ticket created: RT #132030 07:54
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132030
AlexDaniel .tell jnthn well, this one is possibly more important: RT #132030 07:57
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132030
yoleaux AlexDaniel: I'll pass your message to jnthn.
AlexDaniel marking as blocker
timotimo if that commit changes things, maybe an strace of the test run would be interesting 08:39
AlexDaniel [TuxCM]: ? 08:45
[TuxCM] Adding :!buffer to «$io-in = open $in, :r, :!chomp;» did not help 08:56
on line 1659
thanks for the bisect
timotimo right, it should only matter for handles where isatty returns true 09:03
and no buffer argument whatsoever was passed
jnthn :!buffer is irrelevant for an input handle, as it's only about output buffering
yoleaux 07:15Z <AlexDaniel> jnthn: FWIW this is really annoying when running the spectest: RT #132029
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132029
timotimo iow, that there should already have been buffered anyway
yoleaux 07:57Z <AlexDaniel> jnthn: well, this one is possibly more important: RT #132030
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132030
timotimo oh, that's a good point, too
so something that writes the file you're opening there might be wrong 09:04
forgot to .close something, for example
jnthn clones Text::CSV to have a look
AlexDaniel right
jnthn But I suspect it's going to be a forgotten .close
[TuxCM] is digging .... 09:05
jnthn hm, typing "text csv" on the modules search doesn't find anything 09:06
[TuxCM] csv alone does
jnthn yeah, just odd :)
[TuxCM] adding :!buffer to line 1776 fixes the issue 09:08
jnthn $tmpfn doesn't seem to get closed? 09:09
[TuxCM] line 1888 does a .close
jnthn oh, that's not hte handle
[TuxCM] $io-out is the handle in question
jnthn yeah, confused reading
I note there's various codepaths that look like they can return early, though 09:10
timotimo so maybe add a LEAVE phaser to handle closing? 09:11
jnthn yeah, trying that
Somehow that doesn't do it though 09:13
It closes it too early?
[TuxCM] with that :!buffer added (despite a better fix might be in place), only META6 still fails
jnthn That'll work, but lose a performance benefit on writing CSV to a file, I guess. 09:14
Trouble with doing it with a LEAVE phaser is that in some cases it actually wants to close it earlier
timotimo LEAVE try $fh.close :P 09:15
jnthn This lets it work with buffering: gist.github.com/jnthn/a999df1f89d2...2ca55be806 09:19
[TuxCM] anyone to prod for the zef versioning problem? 09:23
timotimo it's about META6 again 09:25
[TuxCM] yes
timotimo that module did something that caused the complete installation directory to become b0rked 09:26
or something
well, the module did something or zef did something with it
[TuxCM] «zef upgrade» also started failing: gist.github.com/Tux/1fd67a242c11db...66877461f4 09:28
jnthn Commented on RT #132030 09:40
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132030
jnthn Hm, interestingly the atomic fragility looks like a spesh bug 09:48
At least, it goes away under MVM_SPESH_DISABLE=1
In nine++'s golf
Geth roast: 346f058338 | skids++ (committed by Zoffix Znet) | S04-statements/do.t
Fix test that expected pre-GLR behavior. RT##124572. (#305)

  * Fix test that expected pre-GLR behavior. RT##124572.
  * Also test some non-constant-folded conditions
  * Add a comment explaining use of now() to prevent constant folding
  * Actually, makes more sense to add seconds.		 10:06
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=124572
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=124572
dogbert17 jnthn: it also seems to go away with MVM_SPESH_OSR_DISABLE 10:30
jnthn dogbert17: Yeah, fixed already :) 10:31
(By HEAD commit in MoarVM)
nine jnthn: sooo the sleep did not demonstrate a race condition in the code but just gave spesh enough time to replace the code? 10:32
jnthn nine: Yes 10:34
nine Then I guess MVM_SPESH_BLOCKING demonstrated it as well? It's a bit of an irony that the bug showed up in this place of all :)
jnthn Didn't try that, but in theory yes 10:35
Well, or "it depends"
Blocking only means we block on doing spesh once we have filled the spesh log
The thread we start could still assign the value before we did enough loops to fill the log and thus to spesh things 10:36
nine One thing that started to worry me when working on JITed native call: our tests and spec tests are usually very short. So the will be affected by spesh and JIT much less than real world code. 10:39
jnthn Yes, thus why I do runs of them with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
Ditto with NQP/Rakudo builds 10:40
The "no delay" means "spesh code that's cold anyway"
And helps shake out more issues
pmurias m: "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int 11:02
camelia -9223372036854775808?
pmurias ^^ is that a bug?
the Match class is taking the Int method from the NQPMatchRole 11:06
Skarsnik m: "10000000000000000000000000000" ~~ /^(\d+)$/; say $0 11:13
camelia ?10000000000000000000000000000??
Skarsnik bisectable6, "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000 11:14
bisectable6 Skarsnik, Bisecting by output (old=2015.12 new=4b02b8a) because on both starting points the exit code is 0
AlexDaniel, MasterDuke: I'm acting stupid on #perl6-dev. Help me.
Skarsnik, No! It wasn't me! It was the one-armed man! Backtrace: gist.github.com/ebb88e2b94e88edafb...70d728b2ae 11:15
Skarsnik damn
c: "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000 11:17
commitable not here, hm
dogbert17 jnthn: chances are high that you just fixed github.com/MoarVM/MoarVM/issues/653 11:39
jnthn dogbert17: Yes, that's exactly what I fixed :) 12:04
pmurias: Looks like Rakudo should have its own Int candidate that can do the coercion to a bigint
Zoffix Skarsnik: ^ it's back now. You need a commit with `c:` tho 12:07
c: 2017.01 "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000
committable6 Zoffix, ¦2017.01: «True»
Skarsnik c: old "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000
committable6 Skarsnik, ¦old: «Cannot find this revision (did you mean “all”?)»
Skarsnik c: 2015.1 "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000 12:08
committable6 Skarsnik, ¦2015.1: «Cannot find this revision (did you mean “2015.12”?)»
Skarsnik c: 2015.01 "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000
committable6 Skarsnik, ¦2015.01: «True»
Zoffix I'm betting the change came in when Cursor and Match were unified
Skarsnik c: HEAD "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000
committable6 Skarsnik, ¦HEAD(4b02b8a): «False»
Zoffix c.2017.03
Skarsnik dunno why bisectable6 die
Zoffix c: 2017.02,2017.03,2017.04 "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int == 10000000000000000000000000000
committable6 Zoffix, ¦2017.02,2017.03: «True» ¦2017.04: «False»
Skarsnik should be added to roast maybe? 12:09
Zoffix Skarsnik: because it was a weird merge and it can't pick out when it actually broke; it least I recall it having issues with the Match+Cursor introed bugs
Skarsnik: sure, after it's fixed :D 12:12
pmurias Unhandled exception: Missing or wrong version of dependency '/home/pmurias/nqp/install/bin/../share/nqp/lib/MAST/Nodes.nqp' (from 'src/Perl6/Pod.nqp') 12:23
^^ why does that happen?
jnthn pmurias: Hm, thought I fixed that in github.com/rakudo/rakudo/commit/fb...9c649a20c1 12:24
pmurias: It was due to wrong lib search path order in the (non-install) runner though 12:25
pmurias makefiles -= Inf :/ 12:30
pmurias goes to grab some lunch&
jnthn every-makefile-replacement -= 2 * Inf ;)
dogbert17 c: HEAD MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 use Test; { { my sub foo { fail }(); CATCH { default { my $bt = .backtrace; is $bt.list.elems, 4, "we correctly have 4 elements in .list"; }} } } 12:54
committable6 dogbert17, gist.github.com/d262f427671ac6551a...cbe0801228
dogbert17 c: HEAD MVM_SPESH_NODELAY=1 use Test; { { my sub foo { fail }(); CATCH { default { my $bt = .backtrace; is $bt.list.elems, 4, "we correctly have 4 elements in .list"; }} } } 12:55
committable6 dogbert17, gist.github.com/8578c66774e0902aad...182076665d
dogbert17 bad bot 12:56
Geth nqp: ffa3e56f61 | pmurias++ | src/QRegex/Cursor.nqp
Make Int on rakudo's Match return an Int not a nqp level int.

Move the Int method from NQPMatchRole to NQPMatch so that rakudo will use the more correct bignum using Int method from Cool.		 13:46
robertle what's the right way to do reflection? I am currently using can() to get the accessor of an attribute by it's name, and I can call that. but it also would like to know if the attribute is Listy or a scalar. how can I do that? 14:46
Skarsnik $obj or Class.^attributes to get a table of the attributes 14:48
m: say IO::Path.^attributes;
camelia ()?
Skarsnik m: say Int.^attributes; 14:49
camelia (bigint $!value)?
Skarsnik m: say Int.^attributes.WHAT;
camelia (List)?
Skarsnik hm
timotimo don't forget you can also $myinstance."$attributename"()
Skarsnik should this be an Array[Attributes] ?
timotimo, is that not just a method call to the attribyte accessor? 14:50
timotimo yes
[Coke] jnthn: github.com/jnthn/p6-io-socket-asyn.../issues/19 (a real bug this time, not a META bug. :)
jnthn [Coke]: Urgh :( 14:53
Can you include the SSL library version also?
[Coke] This after a nuke-everything-from-orbit reinstall of rakudo HEAD to avoid dep hell.
jnthn (the libssl one, I mean) 14:54
timotimo wow, that was easy
[Coke] jnthn: openssl @1.0.2l (devel, security) (checking for an update in ports now) 14:55
lizmat Files=1223, Tests=67677, 290 wallclock secs (11.13 usr 4.76 sys + 1961.08 cusr 204.06 csys = 2181.03 CPU) 15:58
Geth rakudo/nom: c39db87895 | (Elizabeth Mattijsen)++ | src/core/Set.pm
A null byte was intended, Zefram++
 16:08
timotimo lizmat: don't we still have to replace null bytes in our strings with something escaped? so you can't write strings with a nullbyte in them and pretend they are multiple consecutive elements 16:10
lizmat timotimo: as long as we keep using strings for .WHICH values, we cannot prevent confusion, just obfuscate the possibilities for it (somewhat) 16:14
m: sub a(*@a) { dd @a }; a Nil
camelia [Nil]?
lizmat m: sub a(**@a) { dd @a }; a Nil
camelia [Any]?
lizmat that last one is a bit counter-intuitive and the issue behind RT #132032 16:15
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132032
timotimo we can. escaping is a thing that works. 16:16
lizmat timotimo: maybe I'm not understanding what you mean by escaping 16:23
I've looked at Zefram's proposal, but that will cause a massive performance drop 16:24
affecting all QuantHashes and object hashes
this needs to be done at the VM level, afaics 16:25
timotimo we only have to escape a string if it has a \ or nullbyte in it, which gives us a decent enough fast path and slow path 16:28
[Coke] jnthn: re the alpn support, looks like it's supposed to be in 1.0.2 17:05
jnthn Oh...right, think I'm confusing versions 17:06
The issue you reported is nothing to do with ALPN though, fwiw
(I don't yet know what it is, alas) 17:07
[Coke] ... I just reran that test and it worked. 17:08
jnthn Yeah, I suspect it's heisenbug-y
Which gives me hope I might be able to reproduce it with enough load/runs too
[Coke] trying to get something to chew up the CPU and will try again. 17:09
jnthn ok; back after dinner :)
[Coke] yup, did a zef install in another window, then it died again.
ugexe recently been figuring out I can't casually use | for Slip as much as I thought - notably with positional arguments 18:03
m: my $bytes = Buf.allocate(1000000); say buf8.new($bytes.Slip).bytes; say buf8.new(|$bytes).bytes;
camelia 1000000?Too many arguments in flattening array.? in block <unit> at <tmp> line 1??
AlexDaniel heh, what's wrong with github… 18:04
“We are investigating issues loading stylesheets”
okay
Skarsnik AlexDaniel, I hate this gumbo crash :) 18:08
AlexDaniel Skarsnik: yes. Me too.
Skarsnik I can't even make it crash on my vm now x) 18:09
I changed the script to my $response = "index.html".IO.slurp; 18:14
not sure if that should change something, but it does not want to crash on the rakudo I working on
(I just added some printf to trace nc cal) 18:15
Zoffix ugexe: note that the two are different in that context. | in argument list isn't prefix:<|>, it's special sauce. And $bytes.Slip sends just one argument 18:18
(special sauce => special compiler handling that calls secret methods .FLATTENABLE_HASH and .FLATTENABLE_LIST) 18:21
ugexe yeah, i was thinking the limit applied only to named arguments for some reason
and have historically reached for | because .Slip looks off to me (i want to see .slip but i understand why its like this) 18:23
AlexDaniel heh, *ables were misbehaving today? :) 19:29
bisect: "10000000000000000000000000000" ~~ /^(\d+)$/; say $0
bisectable6 AlexDaniel, On both starting points (old=2015.12 new=c39db87) the exit code is 0 and the output is identical as well
AlexDaniel, Output on both points: «?10000000000000000000000000000?»
AlexDaniel err, already fixed? 19:30
bisect: "10000000000000000000000000000" ~~ /^(\d+)$/; say $0.Int
bisectable6 AlexDaniel, Bisecting by output (old=2015.12 new=c39db87) because on both starting points the exit code is 0
AlexDaniel ah
bisectable6 AlexDaniel, bisect log: gist.github.com/5eefdbf975e6d19f27...d5bedd0070
AlexDaniel, (2017-04-15) github.com/rakudo/rakudo/commit/c0...70427291df
AlexDaniel o_o
nah xD 19:31
Zoffix Already fixed but still need nqp bump
AlexDaniel hm… some troubles when building c01ebea0a0dc 19:32
Skarsnik: ? this is why it failed today. The build is there but it's broken
c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD use Test; { { my sub foo { fail }(); CATCH { default { my $bt = .backtrace; is $bt.list.elems, 4, "we correctly have 4 elements in .list"; }} } } 19:33
committable6 AlexDaniel, ¦HEAD(c39db87): «not ok 1 - we correctly have 4 elements in .list?# Failed test 'we correctly have 4 elements in .list'?# at /tmp/1ErKgNSqLK line 1?# expected: '4'?# got: '3' «exit code = 1»»
AlexDaniel dogbert17: the syntax is different ?
dogbert17: env variables first, then revision
dogbert2 AlexDaniel: thx 19:34
c: HEAD use Test; { { my sub foo { fail }(); CATCH { default { my $bt = .backtrace; is $bt.list.elems, 4, "we correctly have 4elements in .list"; }} } }
committable6 dogbert2, ¦HEAD(c39db87): «ok 1 - we correctly have 4elements in .list»
AlexDaniel dogbert2: also: github.com/perl6/whateverable/issues/228 19:37
samcv good * 20:12
ugexe where do values like @nqp::libdir@ get set for Configure.pl ? 21:54
and Makefile-*.in
timotimo i imagine that's a "namespace" populated from nqp --show-config? 21:55
in fact, that already has the nqp:: and moar:: prefixes in it
ugexe i see 21:58
i'm trying to get rakudo/nqp/moar to build on windows when there is a space in the path... its not pretty 21:59
timotimo oof 22:03
i believe [Coke] worked on this in the past
there's potentially still a "spaceless" branch to be found in git
ugexe i have what should be a mostly working branch, except for nqp::libdir giving me the RHS of a path split on a space 22:10
Geth nqp/heapsnapshot_binary_format: e85bb796a3 | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
support the new heapsnapshot API

No longer returns an object we have to dump ourselves. Instead we pass a filename at the beginning where snapshots will be stored immediately, with shared data (strings, types, static frames) appended at the end.		 23:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!