MasterDuke in nqp, if i have a bigint type object, how do i get the string 'bigint'? 01:40
timotimo $object.HOW.name($object) usually 01:46
MasterDuke ooh, timotimo++ 02:05
babydrop: perl6.wtf hasn't been regenerated since oct 10? 02:10
s: help 02:41
SourceBaby MasterDuke, Something's wrong: ␤ERR: ===SORRY!=== Error while compiling -e␤Undeclared routine:␤ help used at line 6␤␤
MasterDuke s: help? 02:42
SourceBaby MasterDuke, Something's wrong: ␤ERR: ===SORRY!=== Error while compiling -e␤Unable to parse expression in argument list; couldn't find final ')' ␤at -e:6␤------> put sourcery( help⏏? )[1];␤ expecting any of:␤ infix␤ infix stopper␤
MasterDuke s: Attribute, 'perl' 02:47
SourceBaby MasterDuke, Sauce is at github.com/rakudo/rakudo/blob/345f...Mu.pm#L527
babydrop MasterDuke: yeah, because the update script fails when merging moarvm master onto the branch with coverage support 09:36
Or at least that was the case last I ran it a month or so ago... Seems to have reached stage parse right now. 09:55
MasterDuke: oh, it builds the first one just for fun. Still fails the same: gist.github.com/zoffixznet/695ee7f...34ad903068 10:01
MasterDuke: and this is the point of when, I guess: gist.github.com/zoffixznet/6420204...udo-sh-L23 10:02
(that's the script I run to update perl6.wtf)
dalek kudo/nom: db9ae22 | (Zoffix Znet)++ | src/core/Str.pm:
Update name of param in a comment
 10:17
[Tux] This is Rakudo version 2016.11-166-g345f6a714 built on MoarVM version 2016.11-44-g8e24145d 10:22
csv-ip5xs 3.332
test 14.924
test-t 6.647
csv-parser 14.060
dalek kudo/nom: 8e3cbc6 | (Zoffix Znet)++ | src/core/Str.pm:
Fix a number of issues in parse-base() error reporting

  - Fix missing sign in error message
  - Fix incorrect char referenced if invalid char is the first char of
   fractional part of the number
  - Fix incorrect char referenced in negative numbers, when the
   invalid char is in fractional portion of the message
Fixes RT#130298: rt.perl.org/Ticket/Display.html?id=130298		 11:37
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130298
babydrop makes the "Fry" meme with "Not sure whether Awesome Errors cause too much programming bugs or I'm just a crappy programmer" 11:38
dalek ast: 33edc14 | (Zoffix Znet)++ | S32-str/parse-base.t:
Extra tests for parse-base() errors

  - Fix broken tests that checked for signless string for negative numbers
  - Add extra tests to cover the ticket[^1] and fixes[^2]
  [1] RT#130298: rt.perl.org/Ticket/Display.html?id=130298
  [2] github.com/rakudo/rakudo/commit/8e3cbc67db
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130298
kudo/nom: 3dd2916 | MasterDuke17++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Add .gist, .perl, and .Str to BOOTSTRAPATTR

Fixes RT77070, rt.perl.org/Ticket/Display.html?id=77070		 12:23
rakudo/nom: c4a6011 | lizmat++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
rakudo/nom: Merge pull request #943 from MasterDuke17/RT77070
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=77070
dalek rakudo/nom: 12:24
p: af0e5fd | (Pawel Murias)++ | src/vm/js/nqp-runtime/bootstrap.js:
[js] Fix stuff found by 'make js-lint'.
 12:26
p: 3e71bfe | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] Use ES6 class syntax when adding internal REPR specific methods.`
nine Results of yesterday's ecosystem smoke test: niner.name/perl6/ecosystem/2016-12-08.html 12:30
yoleaux2 8 Dec 2016 17:52Z <pyrimidine> nine: in case you miss this in the backlog: Inline::Perl5 broke with github.com/rakudo/rakudo/commit/b2...25688487ca
nine .tell pyrimidine Thanks a lot! Will dig from there. 12:31
yoleaux2 nine: I'll pass your message to pyrimidine.
babydrop I was gonna say looks pretty green 12:34
... until I started scrolling :)
nine Feels like one could fix half the breakage by fixing JSON::Name 13:31
babydrop it passses for me on 2016.11-144-gbc13bb5 :/ 13:35
(installed with zef)
nine I just see lots of "Could not find JSON::Name at line". The same for Encode 13:36
According to emmentaler only 15 more modules fail their tests with the lexical_module_loading branch. And one even starts passing :) 15:06
jnthn: ^^^
babydrop I recall there was a gist explaining what that branch was about... does anyone have the URL? 15:21
nine gist.github.com/niner/70f7b46eefb7...6bea11efeb 15:24
babydrop Thanks.
We don't have any sort of "data dumper" type of thing to look into QAST generated by a Perl6/Actions method do we? I wanna see what this QAST ends up lookin' like: github.com/rakudo/rakudo/blob/c4a6....nqp#L7843 16:24
and --target=ast has a ton of stuff, I'm unsure what is what 16:25
timotimo we do have .dump or what's it called
that's what gets used to dump --ast 16:26
babydrop looks into that
timotimo a big part of the dumped stuff is things like "want"
i mean the wantness mechanics in general
babydrop note($past.dump); did the trick 16:39
psch huh, so apparently we call Cursor.INTERPOLATE at least three times for /^(@a)*?$/ 18:42
buuut, @a = <a b bc cd>, so it seems we want to call it four times, because we have to backtrack once..?
which means i need to get one level higher to set the backtracking, which is good because i have no idea how to figure out if we are allowed to backtrack at the spot where my debug-say is sitting... :S 18:43
hm, i did try setting .backtrack on the QAST::Regex that calls INTERPOLATE though... 18:48
babydrop What's QAST::Op.new( :op('p6store'), for ? 18:55
psch babydrop: calling nqp::p6store 18:56
babydrop ehehe... well, yeah, I figured as much but is nqp::p6store documented somewhere? I don't see it in github.com/perl6/nqp/blob/master/d...s.markdown
psch babydrop: try rakudo/docs/ops.markdown 18:57
babydrop Thanks
psch babydrop: not all nqp:: ops are defined in nqp
babydrop well, it's listed... but without description. p6store(Mu $container, Mu $value) I guess that just stores $value in $container 18:58
psch pretty much, it has some more logic like "can we do this on VM-level or do we need to call .STORE" basically
it's in rakudo/src/vm/moar/Perl6/Ops.nqp 18:59
babydrop Thanks.
m: dd infix:<,>(42) 19:06
camelia rakudo-moar c4a601: OUTPUT«42␤»
babydrop What's the purpose of this idiom? github.com/rakudo/rakudo/blob/nom/...7768-L7772 19:07
Why is infix:<,> called?
dalek kudo/nom: 524368c | lizmat++ | src/core/Rakudo/Internals/VMBackedDecoder.pm:
Revert "Simplification of LAST block"

This reverts commit 58cdfd80b30444ba4755bb3fa0992f0f449f8a9e.
The change was not semantically identical and caused problems in some situations.
psch babydrop: the comment right above doesn't make sense to you? 19:09
lucasb ($/,) = $result 19:10
explain like I'm 5, please :)
the comment is hard to understand :)
lizmat m: dd (42,) 19:11
camelia rakudo-moar c4a601: OUTPUT«(42,)␤»
lizmat in other words: put 42 into a List
afk again&
psch m: my $x = 1, 2; say $x
camelia rakudo-moar 524368: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 2 in sink context (lines 1, 1)␤1␤»
psch m: my ($x,) = 1, 2; say $x
camelia rakudo-moar 524368: OUTPUT«1␤»
babydrop lizmat: do you recall if .match returning a Slip was done for some good reason?
m: dd 'foo'.match: /d/, :g;
camelia rakudo-moar 524368: OUTPUT«slip()␤»
babydrop star: dd 'foo'.match: /d/, :g;
camelia star-m 2016.10: OUTPUT«()␤»
psch babydrop: :g returns something listy because otherwise we'd need a different approach to truthiness 19:12
lizmat babydrop: no idea, that predates my involvement :-)
afk&
babydrop OK
psch babydrop: there was a lot of discussion between me and TimToady somewhere in spring/summer 2015 or so i think..? 19:13
babydrop psch: about what?
psch babydrop: nested match objects instead of a list of match objects from :g
babydrop star: (dd 'foo'.match: /d/, :g).^name 19:14
camelia star-m 2016.10: OUTPUT«()␤»
babydrop star: (dd 'foo'.match: /d/, :g).^name.say
camelia star-m 2016.10: OUTPUT«()␤Nil␤»
babydrop star: ('foo'.match: /d/, :g).^name.say
camelia star-m 2016.10: OUTPUT«List␤»
psch committable6: 2015.5 ("foo" ~~ m:g/(.)/).^name.say
committable6 psch, ¦«2015.5»: Cannot find this revision
babydrop psch: ok, thanks for ($_,) thing. I guess I read that as the op being run first
psch committable6: 2015.05 ("foo" ~~ m:g/(.)/).^name.say
committable6 psch, ¦«2015.05»: List
psch committable6: 2015.01 ("foo" ~~ m:g/(.)/).^name.say
committable6 psch, ¦«2015.01»: List
psch well, maybe it's even older
or we had List from the start and didn't change it 19:15
i forget
babydrop psch: but the question is 2016.11 vs 2016.10
lucasb bisectable6: old=2016.10 new=HEAD die if 'foo'.match(/d/, :g) ~~ Slip
bisectable6 lucasb, Bisecting by exit code (old=2016.10 new=524368c). Old exit code: 0
lucasb, bisect log: gist.github.com/a7b60bcf6fb4ab9fea...468dc531e6
lucasb, (2016-10-23) github.com/rakudo/rakudo/commit/b7...e8f5c77f41
psch well, it's Slip since 2016.10 at least 19:16
lucasb since Oct 23 actually
after the 2016.10 release
psch oh, right, there's one inbetween that didn't die
well, a few, scattered
...oh duh
it's bisect so it's not in chronological order
lucasb hehe 19:17
babydrop stops confusing everyone and just changes it back to List in hopes of clean spectest run and fixed bug
psch babydrop: fwiw, lizmat++ *should* know why it's Slip instead of List now... :)
psch keeps getting sidetracked so badly /o\ 19:18
this regex backtracking/interpolation thing is weird though
as in, i don't get how Cursor.INTERPOLATE gets called multiple times in the first place 19:22
and the fact that it gets called as many times as we'd try to match something from the array when we don't backtrack just adds to that
i mean, that might be a coincedence
actually, i think conceptionally the problem with INTERPOLATE is that we're actually doing the match inside of it 19:36
which means we move .pos which each submatch, but we don't save a previous-matches stack
...at least if i am not misreading this, but it seems to fit the observed behavior 19:37
s/which/with/ 19:38
dalek rakudo/nom: 5476d60 | (Zoffix Znet)++ | src/core/Str.pm: 19:51
rakudo/nom: Make .match(:g) return empty List on match failure
rakudo/nom:
rakudo/nom: As a side-effect of Great .match Refactor[^1], .match(:g) on failure
rakudo/nom: to match was changed from returning an empty List to returning
rakudo/nom: an Empty (which is a slip). As a consequence, the idiom of
rakudo/nom: nqp::p6store( nqp::call(&infix:<,>, $/), $_) (where $/ is the slip), in
rakudo/nom: Perl6/Actions that handle S:g/// resulted in an empty list, rather than
rakudo/nom: the actual original string, which is the cause of the bug in the ticket[^3]
rakudo/nom:
rakudo/nom: During the G.mR, the .comb on failure was also changed to return an Empty,
rakudo/nom: instead of empty Seq. This commit affects that behaviour as well,
babydrop rakudo/nom: returning an empty List instead.
rakudo/nom:
rakudo/nom: [1] github.com/rakudo/rakudo/commit/b7201a8f223
rakudo/nom: [2] github.com/rakudo/rakudo/blob/c4a6...7796-L7803
rakudo/nom: [3] rt.perl.org/Ticket/Display.html?id=130289
github.com/rakudo/rakudo/commit/5476d60
dalek ast: 12b7712 | (Zoffix Znet)++ | S05-substitution/subst.t:
Test S:g/// returns original string on failure to match

RT#130289: rt.perl.org/Ticket/Display.html?id=130289 Rakudo fix: github.com/rakudo/rakudo/commit/5476d60
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130289
babydrop raaawrr... a successful bug hunt 19:52
babydrop eats a bug sandwich
Yummy
japhb
.oO( "I WILL EAT YOU LIKE A BUG SANDWICH, MAGGOT!" )
 19:59
yoleaux2 6 Dec 2016 13:27Z <jnthn> japhb: The current scheduler is decidedly over-simplistic; it's not far off being "the simplest thing that could possibly work". Scalability is also a little bit limited by `await` not yet being non-blocking, which in turn makes us need a lot more real threads than we should.
6 Dec 2016 13:34Z <jnthn> japhb: Also, we never actually put stuff on the main application thread; it's not part of the pooling mechanism. Any jank you're seeing is probably due to plain old contention with other threads to get scheduled, or possibly GC stop-the-world leading to long pauses (though profiles I've looked at suggested the world-stopping ain't all that costly).
6 Dec 2016 13:35Z <jnthn> japhb: Also be clear, when I say "contention with other threads to get scheduled", these are real kernel threads, so it's the OS scheduler, not something in Rakudo. Rakudo's job is more to pick a smarter number of such threads to do CPU-bound stuff.
japhb jnthn++ # Clear explanation as usual
babydrop ZOFVM: Files=1204, Tests=130260, 140 wallclock secs (20.58 usr 3.24 sys + 3177.20 cusr 270.29 csys = 3471.31 CPU) 20:43
[Coke] ZOFVM? 20:44
psch some EC2 instance i think? 20:45
[Coke] ah, oh.
babydrop irclog.perlgeek.de/perl6-dev/2016-...i_13352721
And you can search the log to get all the values over time: irclog.perlgeek.de/perl6-dev/searc...mp;q=ZOFVM
Though I find the variance in them to be quite crazy so the data's quality is prolly sucky 20:46
tbrowder gfldex: FYI, "zef upgrade Typesafe::XHTML::Writer" shows that the module in the ecosystem is still version 0.1.0. Same with uninstall and install--no change in version detected by zef. I made my fork current and all is well test-wise. Maybe the ecosystem hasn't caught up yet. 22:29
ugexe tbrowder: try `zef update` first 22:31
tbrowder aha, will do...
ugexe: that did it, thanks. got to remember to do that--maybe a cron job is better than memory 22:33
ugexe tbrowder: you can also edit the resource/config.json (copy to ~/.zef/config.json) and switch this block (github.com/ugexe/zef/blob/master/r...n#L12-L18) with the block under it (#L19-L32) 22:38
that will let the 2nd block get searched first, which means the auto-update 22:39
tbrowder okay, that's easier! thanks
ugexe otherwise "Text::XHTML::Writer" gets searched for as "Text::XHTML::Writer:ver<*>", which the cached storage (the first block) fulfills 22:40
`zef "Text::XHTML::Writer:ver<0.1.1>" --force` would have worked too 22:41
--force probably not needed actually
tbrowder doesn't --force result in no tests? 22:42
ugexe but I will skip the cached storage for `zef upgrade XXX`, that is not expected 22:43
it would run the tests yeah, but it isn't needed there (only with modules you are installing over with version '*') 22:44
tests run but results ignored^
tbrowder ok, i've updated my own .zef/config.json as you suggested 22:45
psch jnthn: btw, i need a different angle for state vars on nqp-j 23:04
jnthn: think is
*thing 23:05
jnthn heh, that's my regular typo :P
yoleaux2 14:49Z <dogbert17> jnthn: It looks as if github.com/rakudo/rakudo/commit/58...0f449f8a9e breaks t/spec/S17-procasync/no-runaway-file-limit.t. Is it ok with you if we revert that fix?
jnthn dogbert17_: Think that revert already happened...
psch jnthn: org.perl6.nqp.runtime.CallFrame copies state vars from the static code info into the coderef
jnthn: or, well, clones them
CallFrame.java:149-157 23:06
semantically this looks identical to the corresponding moar code to me
jnthn Into the coderef?
psch yeah, cr.oLexState
jnthn Or into the callframe?
psch well, both actually
jnthn Yeah
Well...
Hm
Oh :(
I suspect that what you're running up against is that Moar and the JVM have slightly different closure models 23:07
psch jnthn: right, the only thing that kinda looks like the right solution to me gives us a fresh clone *after the first access*
jnthn Meaning that we don't have clones in all of the same places :(
psch so i have to dig through the whole closure clone semantics..? 23:08
i had tried cloning the static code info, cause that kinda seemed like the right idea at the time
that died with something-or-other being null, i think something in the tc
jnthn I think the JVM backend still has that priorInvocation thingy 23:09
At some point, though, the way we deal with closures on Moar and JVM diverged.
psch yeah, that's still around i think
jnthn The idea being to figure it out on Moar, then get it ported to the JVM 23:10
psch i'm by far not confident in my understanding there to get that ported
as in, i'm not sure i can understand what we're doing on moar -- mostly because i wouldn't know where to look -- nor where that stuff goes on the jvm
jnthn Not sure I'm in much of a better place :P
Well, I know what goes on on Moar
But it was long enough ago I forget what I changed and what the differences are :( 23:11
I do know Moar has no priorInvocation thingy
psch hrm :/
jnthn I'm pretty sure that declaration_static and immediate_static came to exist at the same time I did this work
And I think it went something along the lines of, JVM treats them the same as declaration and immediate 23:12
psch okay, so git log around the time of the ref of the blame of the declaration of those two functions..?
jnthn Well, I think they're branches in the compilation of QAST::Var
But yeah
psch ah, okay
jnthn My rough memory of it is that 23:13
The takeclosure op in Moar got thrown out
psch istr that arnsholt tried removing priorInvocation about a year back or so..?
anyway
jnthn Or rather
The code-gen of it became a noop
In favor of us doing something smarter with immediate vs immediate_static
As an added incentive, I think we have some thread safety problems on JVM that boil down to insufficient closure cloning that these changes would also fix. 23:14
psch right, so this might be necessary for Proc::Async anyway
jnthn And various other things, yeah 23:15
Long story short, if we get that wrong, all kinds of bets are off
psch yeah, i think we already got it pretty wrong and are wasting a lot of what the jvm could bring in async perf
i mean, the state var bit is just plain wrong, and priorInvocation apparently is a crutch that doesn't work quite right 23:16
...although i don't really get what exactly is going on there sooo
alright, so i'll dig around somewhere in the vicinity of the gitrefs that touch the QAST var_decls you mentioned and see if i can figure out what changed in moar 23:17
and how that translates to jvm
can i assume sufficient confidence in the semantics that we don't need more experimentation on moar to figure them out better..? :) 23:18
jnthn Well, we will need further tweaks down the line
But they'll build upon what's already there
Not go in a different direction
psch alright, that's good enough for me 23:19
jnthn Essentially, Rakudo's Perl6::Actions inserts a whole load of clone calls today
But it'd be nice if they could be inserted by the QAST::Compiler
psch hm, but that falls out of shifting from nqp::takeclosure to having the right var_decl types?P 23:21
-P
jnthn Yes 23:23
Or at least, it can do :)
It's just that we have code objects at the Perl 6 level that need taking care of
psch right, i'll try and dig around along these lines :) 23:25
not today though heh
jnthn Yeah, it's late here, I should go rest soon :) 23:26
psch yup, same here, thanks for the pointers
jnthn Welcome. :) 23:32
MasterDuke jnthn: re method caching with wheres. i looked through src/Perl6/Metamodel/BOOTSTRAP.nqp a bit, but never even figured out where to start experimenting. do you happen to have the next level pointer at hand? 23:40
oops, just saw he left for the night 23:41
.ask jnthn re method caching with wheres. i looked through src/Perl6/Metamodel/BOOTSTRAP.nqp a bit, but couldn't figure out why/where/how where clauses precluded caching. do you happen to have the next level pointer at hand? 23:47
yoleaux2 MasterDuke: I'll pass your message to jnthn.
AlexDaniel committable6: 2016.10..2016.11 die if 'foo'.match(/d/, :g) ~~ Slip
committable6 AlexDaniel, gist.github.com/b6101e7f79a64123f3...399023c0d0 23:50
AlexDaniel psch: ↑ that's the best “chronological” order you can get now :) 23:52
psch: not that the commit hashes are grouped by the output, but inside every group they are kind of left to right
you don't really have a chronological order in git history anyway due to merges and stuff… 23:53
psch: but generally, yea, if you want to run something on a couple of hundreds commits, committable can do it :)
there's some reasonable limit but the range between two releases will usually be OK 23:54
note* 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!