| Geth | perl6-pod-to-bigpage: c99f51cd96 | (Zoffix Znet)++ (committed using GitHub Web editor) | META6.json Add `perl` key to meta file Closes #3 |
00:02 | |
| perl6-pod-to-bigpage: 2c8ec5f9cf | (Zoffix Znet)++ | 3 files Don't run network tests by default Fixes #4 |
00:07 | ||
| perl6-pod-to-bigpage: e721ef3556 | (Zoffix Znet)++ | lib/Pod/To/BigPage.pm6 Remove trailing whitespace |
00:19 | ||
| perl6-pod-to-bigpage: b4dd4433e6 | (Zoffix Znet)++ | lib/Pod/To/BigPage.pm6 Reword chain of .substs with .trans |
00:20 | ||
| Zoffix | ZofBot: good grief | ||
| ZofBot | Zoffix, html> | ||
| Zoffix | ZofBot: exactly! | ||
| ZofBot | Zoffix, One other difference between the "s///" and " | ||
| Zoffix sets Pod::To::BigPage on fire | 00:26 | ||
| The same bullshit as the $COLON stuff in htmlify.p6 | 00:27 | ||
| One of the billion places it .substr()-escapes markup—as opposed to doing something sane—it escapes `>`, but seems to double-escape `<` | 00:28 | ||
| samcv | oh no | 00:41 | |
| Zoffix | found it | ||
| samcv | what's it doing? this is diff from the URL problem right? we're talking about Pod::To::BigPage | ||
| Zoffix | Yeah, different. I'm fixing perl -pi -e 's/(\s*(?:multi\s+)?(method|sub|submethod)\s*([^\s({]+)[^{]+\{)/$1 nqp::say("$2 $3");/g' | 00:42 | |
| I mean fixing github.com/perl6/doc/issues/1285 | |||
| samcv | eek | 00:43 | |
| timotimo | the horizontal scrolling in that document is the worst thing i've ever seen in a html site | 00:46 | |
| Zoffix | oh. never noticed it before | ||
| Geth | perl6-pod-to-bigpage: 181945faa5 | (Zoffix Znet)++ | lib/Pod/To/BigPage.pm6 Consolidate markup escape code |
00:53 | |
| perl6-pod-to-bigpage: c24177f6ee | (Zoffix Znet)++ | 2 files Fix double-escape of `<` in code Fixes github.com/perl6/doc/issues/1285 P.S.: There are likely more double-escape bugs in this codebase. Needs a saner review/rewrite |
|||
| Zoffix | gah, doesn't fix it entirely. There's still markup chunks all over the place in code blocks | 00:54 | |
| Zoffix gives up with it | 00:55 | ||
| Geth | perl6-pod-to-bigpage: 2628454c34 | (Zoffix Znet)++ | .travis.yml Fix travis choking with panda By using zef |
02:42 | |
| MasterDuke_ | Zoffix: hope you don't mind, made a couple editing suggestions on your recent doc commits (i think the reifying and Proc.kill ones) | 02:47 | |
| Zoffix | MasterDuke_++ thanks | 02:54 | |
| Geth | nqp: MasterDuke17++ created pull request #358: Align JVM x operator with MoarVM x operator |
03:51 | |
| nqp: bccace7fe8 | MasterDuke17++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java Align JVM x operator with MoarVM x operator Do the same error checks (except with different max values depending on the limitations of the specific VM). |
04:39 | ||
| nqp: 90995169a4 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java Merge pull request #358 from MasterDuke17/repeat_operator_enhancement_for_jvm Align JVM x operator with MoarVM x operator |
|||
| rakudo/bugfix/osx-unstuck-precomp: a9f252c0f9 | (Nick Logan)++ | src/core/CompUnit/PrecompilationRepository.pm Fix stuck precomp on osx |
04:57 | ||
| rakudo/bugfix/osx-unstuck-precomp: 182b17061c | (Nick Logan)++ | src/core/CompUnit/PrecompilationRepository.pm Fix stuck precomp on osx |
05:01 | ||
| rakudo: ugexe++ created pull request #1076: Fix stuck precomp on osx |
05:04 | ||
| roast: ad567d7577 | (Zoffix Znet)++ | S02-types/pair.t Test Pair.ACCEPTS |
05:10 | ||
| Zoffix | Well, I'm tossing fixed-Seq-is-deeply and I guess we'll live with brokenish is-deeply for the foreseeable future | 05:35 | |
| And tossing better-test-pm6; the pain of wasting time on it is dull and forgotten by now :) | 05:36 | ||
| .ask TimToady can `uncurse` branch be deleted from Rakudo's repo now? | 05:37 | ||
| yoleaux | Zoffix: I'll pass your message to TimToady. | ||
| Geth | rakudo/nom: 096bc17cd5 | (Zoffix Znet)++ (committed using GitHub Web editor) | lib/Test.pm6 Add note explaining why is-deeply is buggish |
05:41 | |
| [Tux] | This is Rakudo version 2017.04.3-173-g5e6b38789 built on MoarVM version 2017.04-57-g8d8a09b9 | 05:54 | |
| csv-ip5xs 3.227 | |||
| test 12.861 | |||
| test-t 4.319 - 4.361 | |||
| csv-parser 13.275 | |||
| Geth | roast: 15d52ffb46 | (Zoffix Znet)++ | S32-list/combinations.t Remove trailing whitespace |
06:16 | |
| roast: 1424793070 | (Zoffix Znet)++ | S32-list/combinations.t Add more .combinations tests; skids++ Closes #110 |
06:22 | ||
| roast: 9fad95d9ec | (Zoffix Znet)++ | S32-list/combinations.t Use `is-deeply` instead of `is` and `.perl` |
|||
| Zoffix | :/ wonder why zef's install fails like this. IIRC it's the second time I see travis do that: travis-ci.org/perl6/doc/jobs/229373754 | 06:25 | |
| buggable: speed 10 | 06:26 | ||
| buggable | Zoffix, ▆▅▂▃▂▁▃▂▂▂ data for 2017-05-02–2017-05-06; range: 4.276s–4.571s; 5% faster | ||
| Zoffix | sweet | ||
| samcv | Zoffix, ok pages with % work now too | 08:30 | |
| and so do pages that end with URI percent encoding, cause that was messed up too if it percent encoded and that was the very last thing in url | 08:31 | ||
| not sure what the server setup is to access .html files without .html | |||
| dogbert17 | m: my $a = Numeric.new; say $a + 0 # another oldie | 12:07 | |
| camelia | MoarVM panic: Memory allocation failed; could not allocate 131072 bytes | ||
| timotimo | that infini-recurses? | 12:09 | |
| dogbert17 | yup | 12:10 | |
| will fix a gist | 12:11 | ||
| can't see why it should recurse though | 12:12 | ||
| heh, my 'p MVM_dump_backtrace' recurses as well with a gazillion 'from SETTING::src/core/Numeric.pm:191 (./CORE.setting.moarvm:infix:<+>)' | 12:15 | ||
| the original report points out that instantiating an abstract class is a bad idea. RT #126112 | 12:16 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=126112 | ||
| dogbert17 wonders what the proper way to fix this might be | 12:30 | ||
| timotimo: are you still around? | 13:21 | ||
| where can I find the src for 'nqp::unbox_n'? Using grep hasn't been particulary successful. | 13:23 | ||
| to be more specific, I'm looking for the code which makes this rounding | 13:27 | ||
| m: pi.say | |||
| camelia | 3.14159265358979 | ||
| dogbert17 | i.e. RT #127184 | 13:28 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=127184 | ||
| MasterDuke_ | dogbert17: try MoarVM/src/6model/reprs/P6num.c:56: | 13:37 | |
| lizmat | . | 13:42 | |
| yoleaux | 5 May 2017 13:50Z <Zoffix> lizmat: would you check this commit github.com/rakudo/rakudo/commit/5e6b38789a ? It fixes the bug, but I fixed it more by attrition that knowing what I'm doing. | ||
| dogbert17 | hi MasterDuke_ & lizmat | 13:45 | |
| lizmat | dig o/ | ||
| dogbert17 :-) | |||
| dogbert17 | do you think that RT #127184 should be fixed? | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=127184 | ||
| lizmat | dogbert17: I would say yes | 13:47 | |
| m: 3.14159265358979 == pi | |||
| camelia | WARNINGS for <tmp>: Useless use of "==" in expression "3.14159265358979 == pi" in sink context (line 1) |
||
| lizmat | m: say 3.14159265358979 == pi | ||
| camelia | False | ||
| lizmat | dogbert17: ^^^ feels troublesome, so yes, :-) | 13:48 | |
| dogbert17 | hoping it's some kind of LHF but I'm often horribly wrong about things like that :) | 13:49 | |
| lizmat | perhaps it's as easy as changing a printf somewhere :-) | ||
| dogbert17 | that's what I was hoping :) | ||
| lizmat | .tell Zoffix it feels to me that you fixed the problem by making things unnecessarily eager | 13:53 | |
| yoleaux | lizmat: I'll pass your message to Zoffix. | ||
| Zoffix | . | 14:06 | |
| yoleaux | 13:53Z <lizmat> Zoffix: it feels to me that you fixed the problem by making things unnecessarily eager | ||
| Zoffix | m: sub (*@){}(gather { say "hi here" }); @ = gather { say "hi there" } | 14:07 | |
| camelia | hi here hi there |
||
| Zoffix | lizmat: yeah, it's basically the slurpy is like the @-sigiled var now. So, the fix should be reverted? | 14:08 | |
| lizmat | not sure yet, pretty distracted at the moment :-) | ||
| Zoffix | samcv: thanks, though I see `..^` op is still unreacheable from the search box; it leads to docs.perl6.org/routine/..%5E | 14:09 | |
| lizmat: OK, I'll leave it in your hands then :) If it's bad, please revert it (and refudge the test for it) | |||
| lizmat | Zoffix: okidoki :-) | 14:10 | |
| dogbert17 | lizmat: any idea where to look for this 'printf'? | 14:11 | |
| lizmat | dogbert17: sadly, no | ||
| samcv | Zoffix, that should be fixed. by the latest commit. | 14:12 | |
| dogbert17 finds it difficult to navigate the sources | |||
| samcv | so not sure why it's not working | ||
| MasterDuke_ | dogbert17: you might have better luck following the p6box_s | ||
| dogbert17 | MasterDuke_: thx, I'll give it a shot | 14:13 | |
| MasterDuke_ | i think the unbox_n is just giving you the num, and the p6box_s is stringifying it | ||
| dogbert17 | cool, let's see if that makes finding things easier | 14:14 | |
| Zoffix | samcv: does it need the same `.html` fix like the plain `..`? The page gives me stuff if I append .html to it | 14:15 | |
| samcv | yes it has code to do that right now. i'm going to try altering it slightly | ||
| dogbert17 | hmm, no trace of it in nqp/src nor in MoarVM/src | 14:16 | |
| MasterDuke_ | dogbert17: the p6* ops are in rakudo | ||
| Zoffix | dogbert17: you looking for sprintf impl? | 14:17 | |
| dogbert17: basically this: github.com/perl6/nqp/blob/master/s...printf.nqp | 14:18 | ||
| dogbert17 | Zoffix: looking at RT #127184 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=127184 | ||
| Zoffix | "Dan the Bit-Picking Rakudo Monger" :/ | 14:19 | |
| Zoffix would've hoped the "Monger" thing would've stayed with Perl 5 :P | |||
| dogbert17 | MasterDuke_: perhaps src/vm/moar/ops/perl6_ops.c might be the place then | 14:21 | |
| MasterDuke_ | yep, turns out it just calls MVM_repr_box_str though | 14:22 | |
| Zoffix | m: (pi*10000000000000000).say | 14:24 | |
| camelia | 3.14159265358979e+16 | ||
| Zoffix | m: (1.234567890123456789012345e0).say | ||
| camelia | 1.23456789012346 | ||
| dogbert17 | might that be found in src/6model/reprconv.c | ||
| Zoffix | dogbert17: well yeah and eventually in github.com/MoarVM/MoarVM/blob/mast...onv.c#L561 but that takes MVM_String looks like | 14:25 | |
| So it's already in Str format by then? | |||
| dogbert17 | the plot thickens | 14:26 | |
| Zoffix | And there it takes `cur_op` but it's not used anywhere in the body? huh? github.com/rakudo/rakudo/blob/nom/...ops.c#L213 | ||
| I guess GET_REG(tc, 2).s) is what does the thing, eh? So the .s is what converts it? | 14:27 | ||
| MasterDuke_ | `#define GET_REG(tc, idx) (*tc->interp_reg_base)[*((MVMuint16 *)(cur_op + idx))]`, so it's using the cur_op | 14:28 | |
| Zoffix | dogbert17: seems the bug is in unbox_n op. Maybe here somewhere? github.com/MoarVM/MoarVM/blob/mast...#L482-L493 | 14:30 | |
| Zoffix gives up the guessing | |||
| dogbert17 | m: say sprintf("%.13f", pi) | 14:31 | |
| camelia | 3.1415926535898 | ||
| dogbert17 | m: say sprintf("%.14f", pi) | ||
| camelia | 3.14159265358979 | ||
| dogbert17 | m: say sprintf("%.15f", pi) # ? | ||
| camelia | 3.141592653589790 | ||
| dogbert17 | Zoffix: perhaps this is not a LHF as I was hoping | 14:32 | |
| Zoffix | Dunno. What's the attribute_offsets? Feels like adding another position in P6opaque.c for num is all that's needed | 14:36 | |
| Zoffix chuckles at repr_data->ass_del_slot | 14:37 | ||
| dogbert17 | :) | ||
| m: say sprintf("%.15f", 3.141592653589793) # fishy | |||
| camelia | 3.141592653589790 | ||
| Zoffix | It ends up just a num at the end, right? | ||
| s: 1.1, 'Str', \() | 14:38 | ||
| SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/096b...nal.pm#L79 | ||
| Zoffix | Oh wait | 14:39 | |
| dogbert17 | ? | ||
| Zoffix | s: 1.1, 'Num', \() | ||
| SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/096b...nal.pm#L48 | ||
| Zoffix | Yeah, just nqp::div_In | ||
| So the extra digit at the end just gets lost | |||
| Maybe. It's just a guess that nqp::sprintf doesn't know how to handle rats so it just numifies them | 14:40 | ||
| Zoffix & | |||
| dogbert17 fixes a pot of coffee | 14:41 | ||
| MasterDuke_ | jnthn: i refactored made_feed to do the .ast in the loop and call .panic on the un-ast'ed part, but it's still putting the caret at the EOL. i don't think i've ever played around with this error mark positioning before, so not sure what i did wrong | 15:36 | |
| when you've got a minute, here's a diff of my changes gist.github.com/MasterDuke17/c1316...a405b00eb3 | 15:38 | ||
| ugexe | nine: i dunno why github.com/rakudo/rakudo/pull/1076 works, but I'm pretty sure i've been working around that bug when launching procs in zef for 2 years now | 15:49 | |
| my workaround has always been to reorder the logic for reading/closing :out/:err until it works | 15:51 | ||
| oh i can reproduce | 15:59 | ||
| perl6 -e 'my $proc = shell q|perl6 -e "die q!oo! xx 1000000;"|, :out, :err; my @out = $proc.out.lines.unique;' | |||
| s/:err// and it no longer freezes | |||
| note that the size of the error must matter as well | 16:01 | ||
| geekosaur | um, yes? | 16:02 | |
| that's a deadlock | 16:03 | ||
| if the unread output on the pipe connected to its stderr is larger than the OS pipe buffer then the child process will block waiting for the pipe to become writable; the parent is probably doing a waitpid() on all children, which will never finish because of the blocked child. only way around it is read the pipe or forcibly terminate the child with a signal | 16:04 | ||
| this is the open3 problem documented for perl 5 and python, among others | 16:05 | ||
| ugexe | that sure sounds like the case to me | ||
| the original problem i only faced on osx, but the repro above (which exaggerates the error message size) also affects non-osx | 16:06 | ||
| geekosaur | or maybe prevent perl 6 from waiting for all outstanding children; I don't know if that happens at perl 6 level or libuv though | ||
| ugexe | it this specific to stderr, or can the reverse also be true (stdout)? | 16:07 | |
| geekosaur | both, tes | ||
| *yes | |||
| ugexe | ouch | 16:08 | |
| geekosaur | (also I think you'll see it more easily on OS X because the pipe buffer is 64K, but on Linux it's something like 256K) | ||
| ugexe | i | 16:11 | |
| and i dont think there is a way to know which pipe to read first is there? | 16:12 | ||
| jnthn | MasterDuke_: Hm, that patch looks to do the change I suggested, so a little curious it doesn't end up pointing at the correct stage. | 16:16 | |
| MasterDuke_ | yea | 16:17 | |
| oops | |||
| jnthn | I don't see any obvious mistake in there | ||
| MasterDuke_ | yeah, i thought it would | ||
| fwiw, updated the gist with the error output | 16:18 | ||
| jnthn | Could also try $_.PRECURSOR.panic($error) | 16:21 | |
| Though I don't know exactly what that does :) | |||
| ugexe: fwiw, Proc::Async avoids the problem by delivering the input as it's received on each handle | 16:22 | ||
| geekosaur | correct | 16:26 | |
| also it could well be both that need to be read. best is to read in threads and forward the important part to the main thread (or use a Supply to feed it) | |||
| which only defers the problem in some sense but you now control the buffering *and* you can reliably kill the main thread without it blocking on the others | 16:27 | ||
| MasterDuke_ | jnthn++ that did it | 16:28 | |
| ugexe | jnthn: but introduces the problem of not existing for jvm yet :( | 16:44 | |
| TimToady | PRECURSOR puts the eject symbol at the .from rather than the .pos | 17:45 | |
| yoleaux | 05:37Z <Zoffix> TimToady: can `uncurse` branch be deleted from Rakudo's repo now? | 17:46 | |
| TimToady | Zoffix: yes | 17:47 | |
| MasterDuke_ | Zoffix: Geth seems to have died | 18:10 | |
| i just created github.com/rakudo/rakudo/pull/1077 a couple minutes ago, but there hasn't been an announcement here | 18:11 | ||
| Geth | rakudo: MasterDuke17++ created pull request #1077: Make feed compile errors better |
18:25 | |
| Zoffix | Geth: uptime | 18:27 | |
| Geth | Zoffix, 3 days, 2 hours, 4 minutes, and 45 seconds | ||
| Zoffix | might've been hook delay. | 18:28 | |
| Restarted it anyway | |||
| nine | ugexe: what geekosaur said also matches my experience and understanding of this issue. I do wonder however if it's really necessary to capture STDERR. I've had to remove that capturing whenever I've worked on precomp stuff as it caused the hang issue and changed the order of debug output which is really confusing. | 19:49 | |
| Geth | rakudo/nom: 182b17061c | (Nick Logan)++ | src/core/CompUnit/PrecompilationRepository.pm Fix stuck precomp on osx |
||
| rakudo/nom: 824cfa3517 | niner++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationRepository.pm Merge pull request #1076 from rakudo/bugfix/osx-unstuck-precomp Fix stuck precomp on osx |
|||
| dogbert17 | m: use nqp; nqp::say(nqp::unbox_n(3.141592653589793e0)) | 21:34 | |
| camelia | 3.14159265358979 | ||
| dogbert17 still trying to find where the stringification of 'doubles' occurs | 21:35 | ||
| timotimo | dogbert17: have you seen "smart_stringify"? | 21:36 | |
| dogbert17 | timotimo: no what's that? | ||
| pmurias | dogbert17: a MoarVM op that does stringification of stuff in nqp | 21:37 | |
| dogbert17 | timotimo: as you can see above, one digit is unnecessarily lost and I'm trying to figure out where | ||
| pmurias: but where's the implementation, the code in src/vm/jvm/NQP/Ops.nqp isn't quite what I'm looking for | 21:40 | ||
| is it in MoarVM? | |||
| pmurias | dogbert17: what backend do you want to fix it in? | 21:41 | |
| src/vm/jvm is for the JVM backend | |||
| dogbert17 | pmurias: MoarVM, see the example a few lines above | 21:42 | |
| pmurias | dogbert17: I would look into the coerce_ns op in the MoarVM | ||
| dogbert17 | pmurias, thx will look | ||
| pmurias: btw it's RT #127184 | 21:43 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=127184 | ||
| pmurias | dogbert17: if you look into the MVM_coerce_n_s you will find a hardcoded 15 digits in the snprintf | 21:45 | |
| dogbert17 | pmurias++ | ||
| otoh, 15 digits whould be enough if we're talking decimals only | |||
| still, the 'problem' must be there | 21:46 | ||
| now I now where to point gdb :), thx for all the help | 21:47 | ||
| timotimo | dogbert17: of course you can just always stringify as much precision is there. but then you'll get 0.30000000000000001943 instead of 0.3 | 22:04 | |
| dogbert17 | a double should be able to handle 3.141592653589793 | 22:10 | |
| I believe that I see a problem though | 22:11 | ||
| if I 'snprintf(buf, 64, "%.5g", n)' i get 3.1416\0 which is one decimal less that what I'm asking for | 22:12 | ||
| s/that/than/ | |||
| seems to me as if the terminating nul 'steals' one of my five decimals | 22:13 | ||
| timotimo | shouldn't, though | 22:15 | |
| dogbert17 | how do you explain the result when using "%.5g"? Am I misunderstanding something? | 22:17 | |
| timotimo | i'm not good at printf, but could it be about leading minus? | 22:18 | |
| samcv | i usually experiment until it does the right thing :P | ||
| dogbert17 | I can try | ||
| if I try with 'double pi = -3.141592653589793e0' and the format string "%.5g" I get -3.1416\0 | 22:21 | ||
| only four decimals ... | 22:22 | ||
| printf("%.5", 3.141592653589) gives 3.1415 hmm | 22:26 | ||
| aha, when using 'g' or G in the format string the number after the decimal point means "the | 22:29 | ||
| maximum number of significant digits for g and G conversions | |||
| changing the 'g' to an 'f' should fix it I think | 22:35 | ||
| m: say 2.718_281_828_459_045_23e0 | 23:04 | ||
| camelia | 2.71828182845905 | ||
| dogbert17 | m: say 2.718_281_828_459_045_231e0 | ||
| camelia | 2.71828182845905 |