Parrot 4.8.0 "Spix's Macaw" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 20 September 2012.
pmichaud I just discovered something 00:03
earlier versions of Parrot had stdout as unbufferred
*unbuffered
i.e., completely unbuffered 00:06
4.8.0 is buffering stdout
(and that's why the logic didn't exist in the old system)
gist.github.com/3797212 # sample program 00:09
when I run that program under 4.6.0, the "abc: " appears immediately, followed by "def" two seconds later. 00:10
When I run the program under 4.8.0, "abc: def" appears 2 seconds after the program starts.
kid51 Which -- or what -- is the desired behavior? 00:13
Would different Parrot users -- i.e., different HLLs -- have a different understanding of "desired"?
pmichaud kid51: most systems I've used assume stdout to be line buffered, which is what 4.8.0 seems to be doing. 00:14
however, from a regressions perspective, since stdout has apparently been unbuffered in parrot for several years... I dunno.
kid51 Do we know which commit introduced the buffering? 00:15
pmichaud I suspect it was the io branch merge 00:16
io_rewrite
the fix in 1fe3b78 doesn't seem very standard, though. It appears to flush stdout on *any* call to readline, not just those for the standard input filehandle. 00:22
so, the 4.8.0 behavior isn't what I'd expect either. 00:23
00:31 benabik joined
ttbot Parrot 1fe3b78b MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/98506 00:38
whiteknight pmichaud: I'll take your word for it, but there definitely was some code in the old system to set up buffering on stdout 00:47
so, the old code lied 00:48
Un-buffering stdout can be done trivially if you want
dalek rrot: 959499b | dukeleto++ | docs/binaries/parrot.pod:
[doc] Add copyright line back
 00:57
rrot: 2c8d7e2 | dukeleto++ | .travis.yml:
[travis] Add our coding standard and manifest tests
01:05 kid51_ joined 01:08 travis-ci joined
travis-ci [travis-ci] parrot/parrot#604 (master - 2c8d7e2 : Jonathan "Duke" Leto): The build was broken. 01:08
[travis-ci] Change view : github.com/parrot/parrot/compare/1...8d7e24db86
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2590709
01:08 travis-ci left 01:37 perlite_ joined
ttbot Parrot 2c8d7e24 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/98550 02:29
03:13 l3l1p joined 03:47 l3l1p joined
dalek rrot/rurban/json-utf16-gh845: 988986b | rurban++ | / (41 files):
Merge branch 'master' into rurban/mime-base64-utf8-gh813+gh814

Fixed conflict in:
  \tChangeLog		 03:49
rrot/rurban/json-utf16-gh845: f50380b | rurban++ | / (5 files):
[GH #845] Fix data_json \\unnnn encoding

  \\u needs to be encoded as utf16 char, not utf8 because they
are binary different. E.g. \\u00a2 is 0xc2a2 in utf8.
Add utf16_chr vtable method for the Parrot_utf16_encoding. Add unicode tests to data_json.
04:00 MikeFair joined 05:17 contingencyplan joined 05:51 l3l1p joined
pmichaud gist.github.com/3798179 # comments welcomed. I'm going to bed now but will read scrollback in the morning when I awaken. 06:04
I also added a related comment to issue #874 about the fix that was committed earlier 06:05
afk, sleep
07:27 jlaire joined 07:33 Psyche^ joined 08:46 lucian joined 11:16 preflex joined 12:20 mtk joined 13:10 jlaire joined
dalek kudo/nom: 031a497 | jonathan++ | src/core/traits.pm:
Ensure &trait_mod:<is>.onlystar == True.
 13:14
kudo/nom: fdf347b | jonathan++ | src/Perl6/World.pm:
Scatter some native types in Perl6::World.
kudo/nom: 14f0230 | jonathan++ | src/ (3 files):
Implement binding with declarators.

This gets things like 'my (:$a, :$b) := foo()' style things working.
kudo/nom: 6f71e7e | jonathan++ | t/spectest.data:
Run S02-names-vars/signature.t.
kudo/nom: 64a2e83 | jonathan++ | src/ (5 files):
Implement 'is hidden' and 'hides'.
kudo/nom: c2e6b2a | jonathan++ | t/spectest.data:
Run S12-class/interface-consistency.t.
13:15 bluescreen joined 13:21 benabik joined
rurban msg whiteknight please read pmichaud's gist and comment about new IO buffering. He is worried about all handles and streams, and a "correct" fix for readline. readline should check even if write_buffer is empty if the out handle is buffered or not. Only STDOUT is handled now. Do we get a non-empty write_buffer on non-STDOUT? 13:39
aloha OK. I'll deliver the message.
pmichaud rurban: I have another test case coming up. 13:43
rurban msg whiteknight please see also our discussion of STD* buffering on #perl6 13:57
aloha OK. I'll deliver the message.
14:04 benabik joined, Khisanth joined
dalek kudo/nom: fea947c | jonathan++ | docs/ChangeLog:
A couple of ChangeLog entries.
 14:04
14:09 benabik_ joined
pmichaud msg whiteknight see also latest updates/comments to ticket #847 14:11
aloha OK. I'll deliver the message.
14:23 brrt joined 14:26 l3l1p joined
brrt blegh, designing an instruction set is hard 14:28
Coke hopes "profit" is one of the instructions. 14:31
brrt that would be awesome
14:33 PacoAir joined
brrt nah, i was hoping to build something in-between m0 and pir 14:38
but thats hard
Coke is there a working m0? I know we had some in progress earlier. 14:43
brrt depends on what you mean by working 14:44
Coke dunno 14:47
if parrot exposed m0 at this point, would w consider that an internal format? would nqp be able to target it, or would there have to be a PIR level? woudl there be a new pir-like level that wasn't pir instead? lower level? 14:48
pmichaud in many ways, nqp isn't really interested in PIR as it exists today. I think that creating an m0 that tries to replicate PIR as it exists now would be more of a distraction than a help. 14:51
brrt basically, my complaint about m0, if any, is that it is so low-level it is basically useless
dalek p: 29b1d0c | jonathan++ | src/QRegex/P5Regex/Actions.nqp:
Toss qalt_nfas from P5Regex.

Alternations are always sequential.		 14:53
p: 7033a27 | jonathan++ | src/QRegex/P5Regex/ (2 files):
Basic positional capture support.

Seems to get the numbering done the p5 way, at least for basic cases.
p: 6c47c7b | jonathan++ | t/p5regex/ (2 files):
Some basic p5regex capture tests.
brrt i.e., if different compilers all compiled down to m0, they could never truly be made to interoperate
Coke does m0 proscribe calling conventions?
brrt not if i recall correctly 14:54
Coke if we had something that hid the calling conventions, would that be enough?
brrt not really
tadzik m0 wasn't supposed to be something to target, iirc
brrt you need 'data conventions' too, but that is more tricky than it sounds
tadzik just something easily jitable, due to low number of opcodes
and then there's m1 which compiles to m0, or something 14:55
brrt tadzik: in which case, you need a higher-level representation that may not be easily jittable
but which is easy to compile hll into, and more interestingly, easy to optimise
because if javascript can be made to run quickly, any language can 14:56
14:56 benabik joined
tadzik brrt: that's what m1 is about 14:56
(was?)
brrt m1 would then have to be a reasonable target for compilation 14:59
15:00 benabik_ joined
tadzik that was my understanding, yes 15:01
brrt my understanding was that m1 would be some c-alike
as in, for humans 15:02
tadzik that's how it looks
hm
Coke ... didn't someone already do that also?
tadzik so maybe someone wanted a compiler toolkit generating m0
or something
tadzik shrugs
I don't believe this will happen actually :(
brrt shame 15:03
anyway, that was why i wanted to implement a set that was high-level enough to enforce calling and data conventions 15:08
which is hard
brrt was sure he could find the design document of m0 15:10
github.com/parrot/parrot/blob/m0/d...d32_m0.pod 15:12
here it is
15:16 dmalcolm joined 15:17 l3l1p joined
rurban For me m0 is just a simple LLVM rewrite, without all the infrastructure and optimizations of LLVM. Why bother 15:20
If we want to create jit-near microcode and jit it with llvm, we need to create llvm .bc not m0 bytecode. 15:22
Coke is llvm supported on all platforms we currently target? 15:23
rurban I have no idea
it runs on most processors, but not on vms
mips also not 15:24
brrt i definetly see the value in something low-level to pir
rurban oh, mips is supported. and ia64 also, so vms would run 15:25
dalek rrot: c2c9597 | dukeleto++ | MANIFEST:
[t] Update manifest to make manifest tests happy
rurban uh, utf16->to_encoding(asciistring) => ucs2 ? 15:27
Oh, I see. optimization 15:29
Coke rurban: which parts of parrot coudl be swapped out for llvm tools/code? 15:45
rurban Parts of the runtime 15:46
But I'm mostly seeing potential for a better nqp backend based on vmkit, than parrot. 15:47
It's the calling convention and string handling which is awful. and almost not fixable
ttbot Parrot c2c95972 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/98615 15:52
16:12 preflex_ joined 17:06 NotFound joined 17:07 preflex_ joined 17:10 brrt joined 18:13 tuxit joined 18:20 contingencyplan joined, schmooster joined 18:31 benabik joined 19:18 davidfetter joined 19:23 brrt joined
dalek kudo/nom: 2d0e2de | pmichaud++ | t/spectest.data:
Remove extra copy of integration/rule-in-class-Str.t added by 19d7cd2b9a.
 19:24
19:40 preflex joined 19:58 zby_home joined 19:59 bluescreen joined 20:15 benabik joined
dalek rrot/rurban/bitwise_uni-gh848: f88d598 | rurban++ | src/pmc/string.pmc:
[cage] Typo in the string.pmc trans method pod
 20:49
rrot/rurban/bitwise_uni-gh848: 04f1986 | rurban++ | src/string/encoding/utf16.c:
Micro-optimize utf16_chr by checking 0 beforehand
rrot/rurban/bitwise_uni-gh848: 6c41a21 | rurban++ | / (4 files):
[GH #848] Support unicode strings for bitwise ops

bands, bors, bxors and bnots understand now more multi-byte strings.
Old docs: Performs a bitwise C<OR> on two Parrot strings, performing type and encoding conversions if necessary. Returns the result as a new string.
Added now: Same encodings are compared bitwise. Different two-byte encodings are first converted down to latin1, and if that fails upgraded to ucs2 and if that fails to ucs4. 2 byte <=> 4 byte conversion is not supported, thus e.g. utf8->utf16 fails. But 2 byte to 1 byte is attempted.
rrot/rurban/json-utf16-gh845: 1313cd4 | rurban++ | compilers/data_json/data_json/pge2pir.tg:
GH #845 use ucs2 not utf16 for json \\u values

This is safer.
rrot/rurban/json-utf16-gh845: 274df5d | rurban++ | src/string/encoding/ucs2.c:
GH #845 Add ucs2_chr for data_json
p: f12484a | pmichaud++ | / (2 files):
Back PARROT_REVISION down to 4.4.0, bump VERSION to 2012.09.1
 20:53
rurban I'm off now for a few hours. 20:55
dalek kudo/nom: acf8f17 | pmichaud++ | / (3 files):
Bump NQP revision to 2012.09.1, restore IO::Socket::INET to use older Parrot interface, disable IO::Socket::INET tests in spectest.
 21:10
kudo/nom: 5c5b15b | pmichaud++ | / (2 files):
Revert a bit more of 71fc9c to get sockets to work as they did in 2012.08.
kudo/nom: 81cd16f | pmichaud++ | docs/ChangeLog:
Update ChangeLog for 2012.09.1.
kudo/nom: cbe6eea | pmichaud++ | docs/announce/2012.09.1:
Add announcement for 2012.09.1 .
 21:21
kudo/nom: 5f876d7 | pmichaud++ | docs/release_guide.pod:
Update release_guide.pod with 2012.09.1 release.
 21:22
kudo/nom: 7d227de | pmichaud++ | VERSION:
[release] bump VERSION
 21:28
22:52 whiteknight joined
whiteknight good evening, #parrot 22:54
23:00 bluescreen_ joined
whiteknight I cannot, for the life of me, figure out how the previous IO system was accomplishing this buffering behavior 23:09
23:14 l3l1p joined
whiteknight actually, I think I know what it's doing: it doesn't look like stdout is being buffered at all in the old system 23:26
...which makes some sense if I'm reading this right
pmichaud: ping 23:28
dalek rrot: 3260e22 | Whiteknight++ | src/io/api.c:
Undo a prospective fix from rurban++. We don't want to flush stdout every time we read from any filehandle.
rrot: 2922c18 | Whiteknight++ | src/io/api.c:
On second read through, it doesn't appear that the old IO system had a write buffer on stdout. Take that away in the new system to try and fix some rakudo issues reported by pmichaud++
pmichaud whiteknight: pong 23:34
whiteknight pmichaud: those last two commits might fix your stdout buffering issues 23:35
I ran a test locally, when you get a chance can you confirm it with Rakudo?
pmichaud well, it could be tested with the pir code in the issue, too :)
whiteknight yes, that's what I did. If that's enough testing, then we can call the ticket complete 23:36
pmichaud yes. however, we have another problem with standard input that needs resolving too. 23:37
so far I haven't been able to duplicate it on any of my systems, but it's been reported by Coke, jnthn, and TimToady so I'm fairly confident the bug exists
oh, and moritz :) 23:38
I'll try master now
whiteknight okay, those are all trustworthy sources 23:39
what's the bug?
pmichaud when reading lines of input, none of them are delivered to the program until EOF is sent
whiteknight hmm, that would seem to be a definite bug
23:40 travis-ci joined
travis-ci [travis-ci] parrot/parrot#606 (master - 2922c18 : Whiteknight): The build was fixed. 23:40
[travis-ci] Change view : github.com/parrot/parrot/compare/c...22c188143b
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2602966
23:40 travis-ci left 23:46 benabik joined
pmichaud whiteknight: 2922c18 seems to leave the standard output unbuffered again. 23:48
(i.e., yes, it's the behavior before 4.8.0, but not necessarily the behavior we'll want)
whiteknight yeah, I'm just trying to get back to the same baseline. io_cleanup1 did not intend to make many breaking changes 23:50
but yes, we want to do the right thing going forward
apparently I have some backlogging to do about expected behaviors 23:51
dalek Heuristic branch merge: pushed 45 commits to parrot/rurban/mime-base64-utf8-gh813+gh814 by rurban 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!