| travis-ci | Rakudo build passed. lizmat 'Merge pull request #846 from Leont/less5 | 01:19 | |
| travis-ci.org/rakudo/rakudo/builds/154996006 github.com/rakudo/rakudo/compare/9...cd84801fbf | |||
| dalek | kudo/nom: aa1ec6f | (Brock Wilcox)++ | / (2 files): Dissallow control commands (next, return, etc) in toplevel REPL * Catch control usage and show error * Switch to instance attributes for out-of-band control values * Merge partial-eval and repl-eval to simplify * Add to repl tests |
01:36 | |
| kudo/nom: dc83730 | hoelzro++ | / (2 files): Merge pull request #847 from awwaiid/repl-no-last Dissallow control commands (next, return, etc) in toplevel REPL 3113465 | (Brock Wilcox)++ | src/core/REPL.pm: Temporarily skip REPL completions for jvm |
|||
| travis-ci | Rakudo build passed. Stefan Seifert 'Make Distribution::Path handle native libraries correctly | 02:55 | |
| travis-ci.org/rakudo/rakudo/builds/155064619 github.com/rakudo/rakudo/compare/9...e6ecbfca26 | |||
| Rakudo build passed. Elizabeth Mattijsen 'Fix RT #127803 | 03:42 | ||
| travis-ci.org/rakudo/rakudo/builds/155083163 github.com/rakudo/rakudo/compare/6...a2ba77d438 | |||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127803 | ||
| lizmat | good *, #perl6-dev | 04:14 | |
| seems like ./perl6-m --profile -Ilib t/harness6 --fudge --tests-from-file=t/spectest.data will reliably segfault withing 20 seconds :-( | |||
| I guess no profile of prove6 anytime soon :-( | |||
| kudo/nom: 74a445a | lizmat++ | src/core/REPL.pm: Merge pull request #848 from awwaiid/repl-jvm-no-completions Temporarily skip REPL completions for jvm |
|||
| kudo/nom: 508192f | lizmat++ | src/core/REPL.pm: Abstract the resetting logic into a sub |
05:35 | ||
| [TuxCM] | This is Rakudo version 2016.08.1-32-g508192f built on MoarVM version 2016.08 | 06:11 | |
| csv-ip5xs 10.046 | |||
| test 15.299 | |||
| test-t 7.307 | |||
| csv-parser 16.346 | |||
| jnthn | lizmat: The SEGV is in some ways the least of the problems. The next one up is that the profiler UI doesn't know how to present data collected from multiple threads so would only give the data from the first one... | 08:37 | |
| lizmat | ah, ok :-( | 08:38 | |
| nine | jnthn: I'm quite sure now that ab6tract's double free crash is because of multiple threads trying to MVM_string_flatten the same string constant concurrently during creation of hashes. | 08:40 | |
| jnthn | Yeah, that function needs to become immutable really | ||
| ab6tract | o/ :) | 08:41 | |
| consolidating the discussion :) | |||
| nine | ETOOMANYCHANNELS :) | ||
| lizmat | gist.github.com/lizmat/1b3c946ae91...025abb019f # where does my $a live in the REPL??? | 09:14 | |
| jnthn: if I want to know the encoding of a $PIO, how do I get that ? | 10:42 | ||
| jnthn | um | 10:45 | |
| Not sure if you want, you'd need to keep track of it in the Perl 6 level handle, Ithink | |||
| *not sure if you can | |||
| gah :) | |||
| lizmat | ok, because: | 10:51 | |
| (open "foo", :bin).comb | |||
| currently gives a Seq of str | 10:52 | ||
| jnthn | Arguably it should give an error :) | ||
| I think we kinda let you pretend things opened with :bin can be read as strings though :S | 10:53 | ||
| dalek | kudo/nom: 87887da | lizmat++ | src/core/IO/Handle.pm: Make IO::Handle.encoding actually work So now you can query the encoding of an IO::Handle. It will return "bin" if you specified :bin when opening the handle. |
12:01 | |
| cygx | o/ | 12:09 | |
| jnthn, lizmat: regarding :bin, cf github.com/rakudo/rakudo/pull/645 and github.com/MoarVM/MoarVM/pull/319 | |||
| the former was a sort of 'minimal viable product' that uses latin1 to fake proper binary handling | 12:10 | ||
| lizmat | hmmm... krunen might be interested in that as well | 12:20 | |
| cygx: thanks for the reminder | 12:21 | ||
| jnthn | This stuff is sorta on my radar | 12:24 | |
| lizmat | jnthn: how do you feel about mixing in a Binary role into IO::Handle to signify binaryness of the handle ? | ||
| krunen | cygx, lizmat: yeah, $fh.read(1)[0] is not very elegant... | ||
| jnthn | As discussed yesterday in #moarvm, it's kinda reached the point where a bunch of I/O stuff needs attention | ||
| cygx | krunen: it was more about the interface, not the implementation | 12:25 | |
| jnthn | And we'll likely pull nearly all string-based I/O ops out. | ||
| cygx | the idea was to allow read/write/seek on any handle (which necessitates invalidating the decode stream) | ||
| jnthn | And expose the VM-based decoding stuff for some common encodings | ||
| cygx | passing :bin would additionally make .getc/.get/... return bytes/blobs instead of strings | ||
| dalek | kudo/nom: 1a03efe | lizmat++ | src/core/IO/Handle.pm: Temporary fix for .comb/.split on binary handles Make it die for now while jnthn / cygx / krunen work out a better way to handle all of this. |
12:26 | |
| jnthn | So essentially MoarVM will just provide binary I/O and we'll pass bytes off to the decoder up at Perl 6 level | ||
| Note that this should make it *easier* for more folks to contribute since we'll be doing more of it in Perl 6 :) | |||
| lizmat | so, please revert the last 2 commits: I see them as stopgaps only | 12:27 | |
| jnthn | A few things are pushing us in this direction. One is the utter fragility of the error handling in async I/O with strings today. | ||
| The other is that it'll be much easier to replace libuv for sync stuff - fixing the longstanding problems using sync file handles and sockets between threads - when we only have binary I/O to worry about down in the VM. | 12:28 | ||
| The other goal along with this is to have an encoding/decoding API that others can implement in modules, so that you can use other encodings besides the bundled ones with Perl 6 I/O. | 12:29 | ||
| krunen | jnthn, by some wierd coincidence I just suggested a similar thing to lizmat a few minutes ago... | 12:30 | |
| jnthn | Also, having streaming decoders handy and uncoupled from I/O will be nice for implementing streaming protocol stuff, e.g. in HTTP where the headers come in and you want to treat them as ASCII or latin-1, but then decode the body bit by bit as it arrives using something else. | ||
| cygx | krunen: well, it is kind of the sane way to do it ;) | 12:31 | |
| jnthn | Pretty much | ||
| The I/O ops that we have now basically exist because they reflect what was in Parrot, and it was far, far easier to just making existing stuff work than to go doing yet another big design job in the middle of porting. :) | |||
| *to just make | 12:32 | ||
| And then cleaning it up never really got near the top of the priority list before now :) | |||
| RabidGravy | jnthn, so much that - real hoop of fire jumping in HTTP::UserAgent to achieve that | 12:33 | |
| (switch decoding methods mid-stream that is) | |||
| jnthn | fwiw, I already have Moar/NQP/Rakudo branches exploring doing this kind of approach for async socket I/O :) | 12:34 | |
| (And yes, help is welcome :)) | 12:35 | ||
| krunen | I'll help | 12:43 | |
| jnthn | OK. The branches in question for exposing the existing decode stream stuff are expose-decode-stream in MoarVM and NQP | 12:45 | |
| ShimmerFairy | jnthn: if binary decoding is passed off to a higher level, where would "text mode" fit in? Is it something an external module would handle, or could the lower levels provide an "alternate" binary stream of the file opened in text mode? | 12:48 | |
| (I only ask because I recently ran into a situation where I had to ponder the difference between C-level binary and text modes) | 12:49 | ||
| cygx | ShimmerFairy: we don't use C stdio, so as far as we're concerned, there's no such thing | 12:52 | |
| jnthn | cygx++ # more succinct answer than I could come up with :) | ||
| ShimmerFairy | cygx: really? does libuv or whatever just make up its own assembler-level IO then? | ||
| jnthn | It just calls the same level of OS APIs that a stdio implementation is done in terms of. | 12:54 | |
| ShimmerFairy | right, "assembler" might have been too specific a word choice :) | ||
| jnthn | Well, sorta kinda, 'cus libuv is mostly dealing in the async APIs. | ||
| cygx throws in the relevant term 'POSIX' | 12:55 | ||
| ShimmerFairy | that situation, btw, was handling GNU checksum files, where they come with a mode flag for each listed file. And P6's text mode isn't the same as C's, so it seems like something you'd have to do manually. | 12:56 | |
| cygx | ShimmerFairy: also note that on POSIX systems, text and binary mode are the same | 12:58 | |
| "The character 'b' shall have no effect, but is allowed for ISO C standard conformance." | |||
| ShimmerFairy | cygx: exactly. GNU's md5sum-style utils use text mode by default on such systems. (But of course that stupidly introduces a problem with Linux->Windows transfer if you're not careful...) | 12:59 | |
| cygx: my problem atm is that Windows' text mode is practically undocumented. I know of the transforms, but critically not if it's encoding dependent. That is, is its "\r\n"->"\n" transformation logical or always "\x13\x10" -> "\x10"? | 13:00 | ||
| cygx | the winapi supports several text modes (_O_TEXT, _O_WTEXT, _O_U16TEXT, ...) | 13:02 | |
| not sure how that maps to stdio | |||
| ShimmerFairy | All I've found is that the newlines are transformed to single "\n" chars for programmer-land, and it treats ^Z as EOF. But that's all I've found so far, there's really not much info on how it works. | 13:04 | |
| cygx | stdio only deals in _O_TEXT and _O_BINARY | ||
| _setmode vs _set_fmode | |||
| disregard that | 13:05 | ||
| you can pass a ccs=UNICODE/UTF-8/... to fopen | |||
| ShimmerFairy | not helping matters is that I'm 110% unfamiliar with Windows :P | 13:06 | |
| cygx | apparently, there's binary, text and translated mode | 13:13 | |
| text mode does CR-LF translation, tranlated mode additionally special-cases CTRL+Z | |||
| ShimmerFairy | interesting | ||
| cygx | if unicode IO functions are used, text mode also does unicode-to-multibyte translation | ||
| ShimmerFairy | cygx: right. I just wish it was better documented for Windows, since I don't what would happen if I tried to open in text mode on an EBCDIC Windows system. I'd hate to have to assume that files are always ASCII-compatible :P | 13:18 | |
| *don't know | 13:19 | ||
| cygx | btw, what's up with the IO role? ALl it does is provide the umask method... | 13:22 | |
| ShimmerFairy | cygx: I find core's roles in general to be nigh-useless, where they could/should be more substantial "interfaces". | 13:23 | |
| e.g. the Positional role does nothing to guarantee the existence of any of the AT-POS family of methods, which feels like an obvious thing. | 13:29 | ||
| jnthn | But that'd be vacuously fulfilled anyway | 13:33 | |
| Because Any implements AT-POS | |||
| hoelzro | lizmat: from what I remember, mys from previous lines live in outer contexts | 14:07 | |
| lizmat | hoelzro: well, they don't show up with OUTERS::.keys :-( | 14:08 | |
| hoelzro | =/ | ||
| hmm...it could be that the context used doesn't live in any pseudo stash available to P6 | 14:09 | ||
| it uses this CTXSAVE thing to save the context at the end of parsing each line | |||
| and then it passes that saved context to the call that evals the subsequent line | 14:10 | ||
| cygx | shouldn't that be OUTER::MY::.keys? | ||
| nine | jnthn: do nqp::objectids survive serialization/deserialization? | 14:14 | |
| dalek | kudo/nom: 575dda1 | (Zoffix Znet)++ | docs/release_guide.pod: Add 2016.08.1 to the list of past releases |
14:15 | |
| jnthn | nine: no | 14:19 | |
| awwaiid | lizmat: I wonder if this is related to dynamic vars (definition, then use on another line) not working in the REPL | 14:50 | |
| lizmat | awwaiid: fwiw, I moved the dynamic vars into the start block | 14:51 | |
| gfldex | m: "file-001.fa".succ.say | 15:30 | |
| camelia | rakudo-moar 575dda: OUTPUTĀ«file-002.faā¤Ā» | ||
| cygx | IO frontend redesign, RFC: gist.github.com/cygx/7d792e09b182a...82663dfddb | 16:23 | |
| [Coke] | RT: 1369; @LARRY: 18; BOOTSTRAP: 4; BUG: 491; BUILD: 11; CONC: 50; DOCS: 1; GLR: 5; IO: 15; JVM: 69; LTA: 119; MATH: 6; NATIVECALL: 15; NEW: 848; NYI: 91; OO: 7; OSX: 6; PERF: 26; POD: 18; PRECOMP: 12; REGEX: 34; REPL: 4; RFC: 54; SEGV: 37; SPESH: 1; STAR: 6; TESTNEEDED: 34; TODO: 10; UNI: 30; UNTAGGED: 288; WEIRD: 3 | 16:35 | |
| I wonder if a monthly challenge would help. like, "get under 1300 tickets before the next release" | 16:44 | ||
| hoelzro | is there a way to unwind the stack in a CATCH handler other than returning from that handler? | 17:00 | |
| cygx | .oO( wrap the whole thing in a loop and call last as appropriate... ) |
17:19 | |
| jnthn | hoelzro: No; CATCH handlers are (by design) run on the stack top, so you've got the dynamic scope of the thrower in place and so resumable exceptions are dead easy (you just don't unwind after) | 17:41 | |
| cygx | jnthn: if you got a minute, would gist.github.com/cygx/7d792e09b182a...82663dfddb mesh with the moarvm-side refactor? | 17:45 | |
| *would | |||
| hoelzro | jnthn: ok, thanks! | 18:02 | |
| awwaiid: I'm wondering if we should slightly modify your change to REPL.pm to call next outside of the CATCH handler to avoid that "return $!control-exception unless $!exception-handled" code | 18:04 | ||
| it works great, but it just feels a little "action at a distance" to me | |||
| cygx | nine: precompilation leaks filehandles as slurp-rest does not close the file | 18:21 | |
| cf github.com/rakudo/rakudo/blob/nom/...tem.pm#L62 | |||
| should I add a close there, or change slurp-rest? | 18:22 | ||
| perhaps add a :$close parameter to slurp-rest, but with what default? | 18:27 | ||
| probably false, same as .lines | 18:32 | ||
| create-moar-runner.pl no longer does the Right Thing as it checks for $*DISTRO eq 'MSWin32', but minw returns 'mswin32' | 18:59 | ||
| *mine | |||
| [Coke] | the least intrusive change would be to add an explicit .close | 19:06 | |
| changing slurp-rest impacts users | |||
| cygx: can you open a ticket for that? | |||
| (the mswin32 thign) | |||
| cygx | [Coke]: I'll send some pull requests shortly | ||
| [Coke]: the change to slurp-rest is non-intrusive is :$close defaults to false | 19:07 | ||
| *if | |||
| [Coke] | it's -less- intrusive; but you're changing an already documented method that's part of roast. | ||
| (the mswin32 thing could be solved with a $*DISTRO ~~ /i 'MSWIN32' / | 19:08 | ||
| er, /:i | |||
| cygx | [Coke]: we already rely on distro names being lowercase elsewhere (in particular, Distro.is-win) | 19:09 | |
| awwaiid | hoelzro: yes, I'd love to get rid of that, but so far haven't figured out a way | 19:16 | |
| /go status | 19:17 | ||
| hoelzro | awwaiid: I can't try it right now (packing up my whole life =/), but what about setting a flag in CATCH and saying "next if $flag;" outside of the CATCH block? | 19:28 | |
| awwaiid | hoelzro: hmm. ok yeah. or another return flag -- the CATCH is there for catching both repl-eval issues and repl-print issues. Maybe that was a premature merging. | 19:47 | |
| hoelzro|phone | awwaiid: well, I wanted to merge it earlier rather than let it sit and forget about it during my move =) | 19:51 | |
| awwaiid | hoelzro|phone: oh you merged it? I thought I did :) hehe | 19:54 | |
| hoelzro|phone | hehe | 19:57 | |
| awwaiid | hoelzro|phone: ohh, you meant the PR | 19:58 | |
| hoelzro|phone: I was talking about merging the CATCH to cover both repl-eval and repl-print | 19:59 | ||
| hoelzro|phone: I very much appreciate the PR merge :) | |||
| hoelzro|phone | =) | 20:27 | |
| awwaiid | hoelzro|phone: worked, github.com/rakudo/rakudo/pull/852 | 20:32 | |
| dalek | kudo/nom: efd880a | timotimo++ | Configure.pl: strongly point out surprising behavior of --gen-* options nobody would expect any installation to happen just by calling Configure.pl; much less potential installation into system-wide directories. |
20:36 | |
| p: 98f93df | timotimo++ | Configure.pl: Warn about --gen-moar installing at Configure time You wouldn't expect anything in the system to change just because you're running a Configure.pl script. |
20:37 | ||
| kudo/nom: bc187b1 | timotimo++ | README.md: point out the potential surprise of --gen-* in README as well. |
20:40 | ||
| hoelzro|phone | awwaiid : awesome, I can maybe look later tonight | 21:29 | |
| dalek | kudo/nom: ebf34aa | lizmat++ | tools/build/create-moar-runner.pl: Fix create-moar-runner.pl for Win32 $*DISTRO always returns lowercase, without whitespace names |
21:39 | |
| kudo/nom: ede7c60 | lizmat++ | src/core/CompUnit/Repository/FileSystem.pm: Make sure we close filehandle after reading See irclog.perlgeek.de/perl6-dev/2016-0...i_13097501 |
21:53 | ||
| kudo/nom: 0f1d039 | lizmat++ | tools/build/create-moar-runner.pl: Better win32 test Plus remove some superstitious parens |
21:54 | ||
| lizmat | good night, #perl6-dev! | ||
| timotimo | gnite lizmat! | ||
| jdv79 | nite | 21:55 | |
| jnthn | 'night, lizmat | 22:02 | |
| dalek | kudo/nom: 0704970 | lizmat++ | src/core/CompUnit/PrecompilationStore/File.pm: Implement part of PR 851, cygx++ Previous commit inadvertenty already implemented the other part. |
||
| timotimo | lizmat devs in her sleep o_O | 22:03 | |
| dalek | kudo/nom: 4efdd94 | cygx++ | src/core/IO/Handle.pm: Add :close flag to IO::Handle.slurp-rest |
22:04 | |
| kudo/nom: 763d678 | lizmat++ | src/core/IO/Handle.pm: Merge pull request #850 from cygx/slurp-rest Add :close flag to IO::Handle.slurp-rest |
|||
| kudo/nom: 85cbb6d | (Brock Wilcox)++ | src/core/REPL.pm: Get rid of dynamic variable by moving CATCH |
22:05 | ||
| kudo/nom: 3a294e9 | lizmat++ | src/core/REPL.pm: Merge pull request #852 from awwaiid/repl-simplify-catching Get rid of dynamic variable by moving CATCH |
|||
| kudo/nom: 6a8278c | lizmat++ | tools/build/create-moar-runner.pl: Adhere to PR 849, cygx++ |
22:09 | ||
| lizmat | really sleep now& | 22:15 |