Camelia, the Perl 6 bug

IRC log for #parrot, 2011-08-23

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 tcurtis whiteknight: sure. What timeframes would be most convenient for you?
00:02 whiteknight how long do you think such a walkthrough would take?
00:06 whiteknight I have a decent idea about how it all works, I'm mostly trying to figure out what needs to be done on both the input and output sides
00:06 theory joined #parrot
00:10 tcurtis Hmm... I am unusued to estimation of how long explaining things takes, but I think I could probably explain its current state in at most 30 minutes.
00:11 whiteknight okay. Have time tonight?
00:13 whiteknight I'm trying the build now. Looks like it's missing a file MergeRedundantTransitions.winxed
00:13 whiteknight LALR/Generator/MergeRedundantTransitions.winxed
00:14 tcurtis Ah, yes. I had added that temporarily and forgotten to remove it when it became unnecessary.
00:15 tcurtis I'll fix and push that momentarily.
00:17 dalek lalrskate: 22ecc4d | tcurtis++ | setup.winxed:
00:17 dalek lalrskate: Fix no longer necessary file being included in the build.
00:17 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/22ecc4d3ca
00:18 tcurtis As far as having time tonight, yes, though preferably not immediately. Would 8:30PM CDT(approximately one hour and ten minutes from now) work for you?
00:20 whiteknight yeah, sounds good to me
00:21 whiteknight I finally got it building and testing, which is good
00:21 whiteknight I did a lot of half-assed hacking on rosella, which prevented me from building and installing it locally until I fixed it
00:33 dalek rakudo/nom: b0d942e | Coke++ | t/spectest.data:
00:33 dalek rakudo/nom: track failure mode
00:33 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b0d942ee1b
00:39 benabik o/
00:40 whiteknight hello benabik
00:41 benabik whiteknight: What's up?
00:41 whiteknight benabik: not too much. you?
00:42 benabik whiteknight: Just spent an hour or so moving mulch.
00:43 whiteknight fun tims
00:43 whiteknight times
00:44 benabik Also trying to get these random pile of thoughts in my head about PACT into some kind of readable shape.
00:45 whiteknight benabik: I am looking forward to what else you have to say about it. I started drafting a blog post of my own, but also don't have all my ideas solidified
00:48 benabik whiteknight: Do we have a PDD or other doc describing packfiles?
00:48 whiteknight benabik: maybe, but I'm sure it's no good
00:48 benabik whiteknight: Found it
00:49 whiteknight where?
00:49 benabik docs/parrotbyte.pod
00:49 benabik I'll also consult the Packfile* PMCs.
00:51 whiteknight These things all need more documentation, but at the same time I don't really like the design of too much of this stuff and most of it is going to change
00:51 whiteknight well, it's not just that *I* don't like the design. Enough people don't
00:52 benabik I note that the Packfile PMC says it's a parser for .pbc files, but I don't see a way to load a packfile into one.
00:59 benabik Although I guess I could pass the value from PackfileView.get_pointer into Packfile.set_pointer.
01:00 whiteknight yeah
01:00 benabik Or load the pbc into a string and pass it to Packfile.unpack.
01:00 benabik Interesting.
01:00 whiteknight we could add a method to Packfile like "set_view" or something
01:00 whiteknight it's trivial to do. You could do it yourself if you were feeling adventurous
01:01 benabik I'm curious about disassembling pbc files…  pbc_disassemble doesn't really give useful output.
01:01 whiteknight no, it does not
01:02 whiteknight the problem is that PIR compilation is destructive. We can't get back anything like the original after we compile it
01:02 whiteknight PIR uses :immediate subs to run during compilation to create constants. We don't have a way besides with :immediate subs to put arbitrary constants in the constants table
01:02 benabik Well, I want to change that.  :-D
01:02 whiteknight so we can't disassemble a PBC file which contains complex constants
01:03 whiteknight right. So what we need is a syntax to assemble complex constants, then we can disassemble into that syntax
01:06 benabik At the very least, I'm trying to consider what the lowest level of PACT should be.
01:07 benabik Under POST is PIR…  But I'm wondering if the bytecode route would benefit from something between POST and PBC.
01:07 benabik Something that is extremely close to the structure of the packfile.
01:07 whiteknight PAST is the abstract syntax layer, POST is the layer tailored to the output format
01:07 whiteknight so if POST isn't what PBC needs, then we need something better than POST, or we need to modify POST
01:08 whiteknight but I don't think we need to add another layer
01:08 benabik Well, PACT is about modifying things.  :-D
01:08 whiteknight true, but I don't want to just add crap for the sake of adding crap
01:11 benabik If there's a OO layer there, we can disassemble to it, do introspection, etc etc.
01:11 benabik I want each transformation to be as simple as possible.
01:11 whiteknight we do need PAST, or something like PAST to represent the syntax of the input
01:11 benabik Right.
01:12 whiteknight and we probably do want something tree-like to represent the structure of the output
01:12 whiteknight it doesn't have to be POST. We can create a new tree interface and give it a fun new acronym
01:12 benabik I'm pondering: PAST -> POST -> flattened POST -> output...
01:13 benabik POST currently does things like bury subs inside subs.
01:13 whiteknight now, the packfile PMCs are the end goal, but they aren't necessarily the best API to use. We could add an abstraction layer API for them
01:13 whiteknight benabik: can we change POST to not do that?
01:14 whiteknight or do we sincerely need a flattening step?
01:15 benabik There are several post-POST steps we could do.  Fun transformations like SSA form or simple things like register allocation.
01:15 benabik (I'm not convinced that PAST::Compiler is the best place to do register allocation.)
01:16 whiteknight so what does POST get us, if not these things like register allocation, instruction transformation, and logical ordering of executable blocks?
01:17 benabik Currently, POST is mostly a tree-structured form of PIR.
01:18 benabik PAST::Compiler does the register allocation, instruction bits, etc etc.  POST::Compiler is largely serialization.
01:20 whiteknight isn't PAST a tree-structured form of PIR?
01:20 whiteknight I thought I understood the differences here a little better, but from what you're saying things aren't where I would expect them to be
01:20 benabik No, it's a higher level thing.  It's a semantic tree.
01:20 benabik There's a PAST tree for "a loop"
01:21 benabik POST trees contain labels, conditionals, and jumps.
01:22 dalek parrot: c52abd8 | jkeenan++ | config/init/hints/darwin.pm:
01:22 dalek parrot: Remove import of File::Which, which is no longer needed.
01:22 dalek parrot: review: https://github.com/parrot/parrot/commit/c52abd8ed9
01:23 whiteknight gotcha. Okay. So the abstraction layer is not quite where I was hoping it would be
01:23 benabik POST trees contain a _lot_ of strings that are intended to be concatenated into PIR in the right order.
01:26 benabik I'm also just pondering what's needed.
01:30 soh_cah_toa joined #parrot
01:30 benabik Here we go…  http://www.cs.uaf.edu/~cs631/notes/node5.html
01:31 whiteknight the point about nested subs really bothers me
01:31 benabik 6 phases:  Lexing, Syntax, Semantics, Intermediate Code, Optimization, Code Gen.
01:31 whiteknight I wonder why it does that
01:31 rfw joined #parrot
01:31 whiteknight lexing and syntax create the PAST tree. Semantics and intermediate code create POST. then we optimize POST and use it to generate output code
01:32 benabik Syntax generates parse tree.
01:32 benabik Semantic is PAST.
01:32 benabik Intermediate Code is POST.
01:33 benabik I'm thinking about leaving POST in a tree-like state and then as "optimization" steps doing things like dealing with register allocation, temporary values, etc etc.
01:34 whiteknight register allocation definitely should be happening in POST or later
01:34 bubaflub joined #parrot
01:40 benabik My thought is that POST would be a tree containing opcodes, then we'd flatten it down over a couple of phases into a just a list of subs containing a list of ops.  And then a code gen phase outputs PIR/bytecode.
01:40 benabik This may not be faster than currently, but I hope is more amenable to alteration and optimization.
01:42 whiteknight I'm going to need to think about it more. There are a lot of things that have to go into this
01:42 benabik Yes.
01:42 whiteknight closures really are the pain in the ass, I think
01:42 benabik …  Yes.
01:42 benabik And no.
01:45 soh_cah_toa whiteknight: you saw my message?
01:46 whiteknight soh_cah_toa: recent message? I don't think so
01:46 soh_cah_toa from aloha. sent it last night
01:46 whiteknight Oh, I might have gotten it earlier, but I don't remember what
01:47 whiteknight I wish aloha kept records until you deleted them
01:47 soh_cah_toa well, whatever. i was just wondering if you looked at the spec yet? it's mostly designed for a c compiler and it needs to be parrot-ized
01:48 whiteknight oh yes, the spec. I did look at it
01:48 whiteknight a lot of the parrotization will fall out when we start implementing
01:49 soh_cah_toa that's another thing. i'm not sure where to begin b/c all the PAST::* and HLL-whatever classes are so vast and unfamiliar to me
01:49 rfwalrus joined #parrot
01:50 whiteknight don't worry about PAST. PAST might be up in the air at this point
01:50 benabik PAST is likely PAST for the near future.
01:50 whiteknight where we need to start is in the packfile subsystem. src/packfile/*
01:50 soh_cah_toa ok
01:50 whiteknight We add the new segment to the packfile machinery, including the necessary API for writing and reading it
01:50 whiteknight then, we add support to IMCC to write to it
01:51 whiteknight then we add tools that read from it
01:51 whiteknight rewriting things in src/sub.c and src/debug.c to use it instead of the old debug segment
01:51 whiteknight then, remove the old debug segment and do a little dance
01:51 whiteknight then, delete IMCC
01:52 soh_cah_toa ok good
01:52 benabik beer++
01:52 soh_cah_toa so i guess that'd require rewriting the PackfileDebugSegment PMC?
01:53 soh_cah_toa or whatever it's called
01:53 whiteknight we'll make a new segment, and a new wrapper PMC for it
01:53 whiteknight that way the transition from one to the other will be smoother
01:53 soh_cah_toa ah, ok
01:53 benabik +1
01:53 benabik +10 if I'm allowed.  :-D
01:53 soh_cah_toa :)
01:54 rfw joined #parrot
01:54 whiteknight msg tcurtis I'm heading to bed now. We'll talk tomorrow. I'll be online most of the day, just come get me when you have time
01:54 aloha OK. I'll deliver the message.
01:54 whiteknight and with that, I'm out for the night
01:54 benabik 'night!
01:54 soh_cah_toa alright, see ya
01:54 whiteknight goodnight
01:56 tcurtis msg whiteknight Sorry about not contacting you tonight. I didn't wish to interrupt your discussion about POST.
01:56 aloha OK. I'll deliver the message.
01:56 tcurtis ~~
01:59 rfwalrus joined #parrot
02:00 bubaflub joined #parrot
02:03 benabik Okay, a cold beer is nice after hard work, but it makes writing a coherent blog post more difficult.
02:04 benabik (Mostly because I'm more relaxed and distractible.)
02:16 rfw joined #parrot
02:23 dalek winxed: 585ddb8 | NotFound++ | winxedst1.winxed:
02:23 dalek winxed: optimize integer == 0 and != 0 in conditions
02:23 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/585ddb8b5f
02:31 allison how "optional" is libffi?
02:32 benabik allison: It makes NCI easier.
02:32 allison benabik: this is more of a packaging question
02:33 allison that is, for the Debian/Ubuntu packages we can require it, and then it's always built with it
02:33 allison otherwise, we need a flag to make sure it's never built with it
02:33 allison because currently, it's built with it on some architectures (when libffi just happens to be installed), and then breaks
02:34 benabik allison: Parrot can be compiled without it, but that makes NCI harder.  It's a tradeoff.
02:34 benabik I'm not sure which is preferable.
02:34 allison harder doesn't really matter here
02:34 allison faster or smaller does
02:34 NotFound With it is preferable. a lot.
02:36 NotFound With it, nci can be used with pure pir modules. Without it, you need to require a C compiler and provide the wrappers.
02:37 NotFound And 'pure pir' in that sense includes nqp and winxed.
02:39 allison does libffi get rid of the large stack of precompiled thunks for various signatures?
02:40 NotFound It does not need it, but I'm not sure if the build process avoids its compiling and linking.
02:43 plobsing allison: we have a flag to force-dissable libffi usage in Configure.pl: --without-libffi
02:44 plobsing likewise we have flags to dissable the building of the large library of builtin thunks: --without-core-nci-thunks and --without-extra-nci-thunks
02:45 benabik plobsing: And with libffi and without thunks, NCI works correctly, ne?
02:45 plobsing benabik: yes, it should
02:45 benabik woot
02:46 plobsing but not everyone has libffi
02:46 plobsing and libffi is much less efficient than the thunks
02:46 allison plobsing: in packaging we get to decide if everyone has libffi or not
02:46 allison plobsing: so, the question is which flags to use
02:46 NotFound For debian and ubuntu is just a matter of apt-get install libffi
02:47 allison plobsing: and, the hard thing is that we have to decide once for everyone
02:47 plobsing I would advise to force the usage of libffi in the case of packaging, since it maximizes utility
02:47 NotFound Me too
02:47 allison and then --without the nci thunks?
02:47 plobsing if you want to cut down on some code size and a couple hundred gcables at startup, then sure
02:48 plobsing they don't add value to a system with libffi
02:48 allison NotFound: it's not even that hard (apt-get install), it's just an automatic dependency in the packaging
02:49 NotFound Yes, I was fooling myself into a developer point of view, not final user.
02:49 plobsing like I alluded to earlier, the thunks are more efficient. but if you're looking for efficiency in your VM<->C barrier, you are doing it wrong
02:49 allison plobsing: well, we are doing it wrong, but we'll fix it :)
02:50 allison plobsing: how much less efficient?
02:50 plobsing the thunks require heap allocation where the thunks could do it on the stack
02:50 allison which requires heap allocation?
02:50 allison libffi?
02:51 plobsing yes. sorry, I'm communicating poorly for some reason.
02:51 allison heap allocation is generally preferable for a stackless VM
02:51 NotFound I think that the eficiency of something that just doesn't work is debatable ;)
02:51 plobsing allison: heap allocation is not preferable when calling into a C function
02:52 plobsing we want to stay off the stack while we are staying in the VM. as soon as we are on our way out (or as we are on our way in), all bets are off.
02:52 allison plobsing: it does require remunging to the stack, yes
02:53 plobsing the code path to make even a simple PCC->FFI call is rather complicated. the thunks are rather straightforward.
02:54 plobsing we build up the call arguments for a call to get_params. then we build up a call for the actual function. then we build up a call for set_returns.
02:55 plobsing these are all variable arity calls
03:00 allison is Rakudo faster or slower with libffi?
03:00 plobsing as a result, I count 9 separate heap allocations that occur to call a single NCI function through libffi (src/nci/libffi.c:call_ffi_thunk)
03:01 plobsing vanilla Rakudo doesn't make ffi calls. it stays inside the VM.
03:01 allison that sounds like a lot of unfortunate overhead, but then it may have very little effect
03:02 plobsing I think we have a libgmp benchmark somewhere that would be a more realistic guage of how this affects NCI users
03:02 plobsing who was the gsoc student working on gmp bindings again?
03:02 benabik bubaflub?
03:02 allison something in Rakudo is triggering libffi (I know from the failures it's causing), but it could be the VM itself
03:02 plobsing what?
03:03 allison either way, it will have a performance effect
03:03 allison the current failure of Rakudo on Debian
03:03 allison it's caused by parrot being built with libffi
03:03 plobsing is it rakudo or rakudo* (which includes an NCI wrapping library, and presumably tests for such)
03:03 allison but run on a machine that doesn't have libffi installed
03:04 allison (because the build machine just happened to have it, but the packaging doesn't require it)
03:04 plobsing is that a runtime error or a startup error. missing .so sounds like it should fail at startup.
03:06 allison I'm not sure which they're packaging (rakudo or rakudo*)
03:06 allison http://bugs.debian.org/cgi-b​in/bugreport.cgi?bug=636944
03:07 plobsing compile time error
03:08 plobsing when parrot is configured to use libffi, the headers will include ffi.h, the lack of which prevents the compilation of any parrot extensions
03:09 plobsing that is not Rakudo making use of NCI functionality
03:09 allison so, Parrot and Rakudo both should have build-depends on libffi
03:09 allison but not runtime depends
03:10 plobsing I would be surprised if doing that worked
03:10 plobsing like I said earlier, I would expect a missing .so to be a startup failure
03:10 allison you should never need .h files at runtime
03:10 plobsing Parrot and Rakudo should both build-depends on libffi-dev
03:11 plobsing and runtime-depends on libffi
03:11 plobsing need the .so for runtime, not the headers
03:11 allison it's not a missing .so
03:11 allison "ffi.h: No such file or directory
03:11 allison compilation terminated."
03:11 plobsing it will be when you try to run it
03:11 allison try to run what?
03:11 plobsing parrot or rakudo
03:12 allison you mean the compiled .so from perl6_group?
03:13 allison remember, the compilation is done once, then all the .so files are installed on every machine precompiled
03:13 allison build-depends are only required on the build machine
03:13 allison it doesn't make sense to require ffi.h on every machine that installs the precompiled files
03:14 plobsing no, but if parrot is built against libffi, the .so is required to run parrot
03:14 allison you mean the libffi.so, not perl6_group.so?
03:15 plobsing yes. libffi.so is required to execute parrot if parrot is configured with libffi support
03:15 allison if so, then agreed
03:15 allison what isn't required for runtime depends is libffi-dev
03:16 plobsing agreed. which leads to build-depends on libffi-dev, but runtime-depends on libffi only.
03:16 plobsing then again, this arrangement would prevent building of any parrot extensions outside the debian module system
03:16 plobsing which may or may not be desirable
03:17 allison libparrot-dev could require libffi-dev
03:18 plobsing that makes sense
03:18 allison (and preventing parrot extensions outside the debian module system from building isn't desirable)
03:19 JimmyZ joined #parrot
03:19 allison I'll run with that
03:19 benabik But you'd need to install libparrot-dev to build extensions anyway, so if it depends on libffi-dev, that seems optimal.
03:19 allison long-term, do you think it's likely that libffi will replace the old thunks?
03:20 allison benabik: yes, that was our conclusion too
03:20 rfw joined #parrot
03:22 plobsing allison: based on recent developments, I doubt my views on NCI are consistent with the majority of users and I'd like to see someone else take over. beyond that, I don't know, and I'm trying not to care.
03:23 allison plobsing: your views are pro or against libffi?
03:24 allison plobsing: or, something else entirely?
03:24 plobsing allison: overarching philosophy of how it should work
03:24 plobsing it includes the libffi question
03:25 allison and, by recent developments, do you mean M0?
03:25 benabik Sometimes #parrot seems to be full of people who don't like parrot but keep working on it anyway for some inexplicable reason.
03:25 plobsing no, I mean the problem we had with rakudo/zavolaj this spring, and other, lesser comments and actions
03:27 allison benabik: it's a grand tradition that goes all the way back to the beginning of parrot :)
03:27 allison benabik: the very first people who worked on parrot didn't like it and didn't want to work on it ;)
03:27 benabik allison: This seems less than optimal…  Although it may explain the odd mishmash of features.
03:28 benabik ;-)
03:28 plobsing benabik: I like parrot. I like the vision. There are many facets to parrot. I just am not being helpful delivering what the majority apparently wants, so I move elsewhere where I may be prductive.
03:29 allison benabik: nah, the odd mishmash of features is a completely different cause: many cooks over many years
03:29 allison plobsing: I'm not sure rakudo counts as the majority
03:29 benabik allison: AFAICT, it is the majority of parrot users.
03:30 allison benabik: I sometimes wonder if rakudo devs would be happier just running off and writing their own VM, but hate to suggest it to them
03:31 plobsing allison: perhaps I'm mistaken, but a number of other users have made motions in similar directions
03:31 benabik allison: I'm sure they'll get around to it at some point.
03:32 allison benabik: perhaps. It would be an ironic circularity :)
03:33 allison plobsing: one thing Parrot has plenty of room for is multiple different ways of implementing an idea
03:33 allison plobsing: don't feel like you're standing in the way of progress because you think a little different
03:34 allison plobsing: your idea may prove to be absolutely critical in the not-to-distant future
03:34 allison plobsing: parrot is a slim core, with lots of room for varying extensions
03:34 allison plobsing: and will only become more so after M0
03:35 allison plobsing: there is no "majority" and no "one right way"
03:35 allison plobsing: it's a toolkit
03:35 bubaflub joined #parrot
03:36 plobsing I have plenty of ideas. NCI is only one side of Parrot. One that has a higher politiking/promotion to hacking ratio than I'd like to deal with. there are other, less user-visible sides to hack on with much less hassle.
03:39 allison plobsing: fair enough
03:40 allison got to put the kid to bed, biab
04:15 bubaflub joined #parrot
04:54 * allison thinks there must be some universal rule about falling asleep while putting the kids to bed
05:04 sorear most parents live on the same time zone as their kids-they-have-to-put-to-bed
05:07 SHODAN joined #parrot
06:17 fperrad joined #parrot
06:35 mj41 joined #parrot
06:41 * davidfetter has a new kid
06:42 davidfetter he showed up 5 weeks early
06:42 * davidfetter still kinda blown away
07:02 Eclesia joined #parrot
07:02 Eclesia hi
07:05 dalek winxed: 7f77058 | NotFound++ | / (3 files):
07:05 dalek winxed: fix new keyed with argument in stage 0
07:05 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/7f7705807f
07:10 TiMBuS joined #parrot
07:13 preflex joined #parrot
07:24 mj41 joined #parrot
07:33 not_gerd joined #parrot
07:33 not_gerd good morning, #parrot
07:36 NotFound joined #parrot
07:38 not_gerd msg kid51 some info on the state of gerdr/msys: http://gerdr.github.com/on-parro​t/state-of-the-msys-branch.html
07:38 aloha OK. I'll deliver the message.
07:44 jsut_ joined #parrot
07:51 dalek winxed: d6ebd68 | NotFound++ | winxedst1.winxed:
07:51 dalek winxed: optimize == 0 and != 0 also for non int operands
07:51 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/d6ebd68ab9
07:58 lucian joined #parrot
09:28 slavorgn joined #parrot
09:32 dalek rakudo/nom: 89e9ef2 | tadzik++ | src/ (2 files):
09:32 dalek rakudo/nom: Make --doc take optional value, defaulting to 'text'
09:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/89e9ef27b4
09:38 JimmyZ joined #parrot
09:47 SHODAN joined #parrot
10:46 ambs joined #parrot
11:09 not_gerd joined #parrot
11:31 Kulag joined #parrot
11:57 Kulag joined #parrot
12:07 atrodo =~
12:07 whiteknight joined #parrot
12:09 whiteknight good morning, #parrot
12:10 Eclesia hi whiteknight
12:11 cotto hio
12:12 tadzik hello Parrots
12:12 cotto aloha, clock?
12:12 aloha cotto: LAX: Tue, 05:12 PDT / CHI: Tue, 07:12 CDT / NYC: Tue, 08:12 EDT / UTC: Tue, 12:12 UTC / LON: Tue, 13:12 BST / BER: Tue, 14:12 CEST / TOK: Tue, 21:12 JST / SYD: Tue, 22:12 EST
12:12 cotto none of those look right
12:12 cotto ;)
12:13 tadzik BER looks right, and not because it looks like BEER :)
12:13 atrodo Uh oh, cotto is in an alternate dimension.  watch out!
12:14 whiteknight hello Eclesia
12:15 cotto btw, jnthn++ gave a really slick talk about a Perl 6 grammar debugger that he wrote at yapc::eu: http://tinyurl.com/grammar-debugger
12:16 cotto bug him to port it to nqp if it sounds exciting
12:16 moritz see also: http://www.jnthn.net/articles.shtml
12:17 cotto that too
12:21 not_gerd it would be helpful if the error message 'error:imcc:No such file or directory' mentioned the path name...
12:22 whiteknight not_gerd: yes, I think we have a ticket open for that
12:22 whiteknight actually, let me take a look now, since I'm reminded of it
12:23 moritz we at least have a ticket for reporting file name in incompatiable PBC version error
12:26 not_gerd how do I print a Parrot string (ie STRING) from C?
12:27 cotto not_gerd, gdb, Parrot-internal C or Parrot-external C?
12:27 not_gerd cotto: Parrot-internal C
12:27 cotto Parrot_sprintf_c with %Ss
12:28 cotto actually, that doesn't sound right.
12:28 whiteknight that's right
12:28 whiteknight not_gerd: are you working on that error message? I'm working on it right now
12:28 plobsing not_gerd: Parrot_io_putps
12:29 not_gerd whiteknight: just wanted to add some debug output
12:29 whiteknight okay
12:30 whiteknight bleh, I forgot to configure with --maintainer
12:34 dalek parrot: 965e04d | Whiteknight++ | compilers/imcc/imc (2 files):
12:34 dalek parrot: When IMCC can't find a file, actually tell the user the name of the file that can't be found. not_gerd++ for the find.
12:34 dalek parrot: review: https://github.com/parrot/parrot/commit/965e04db8b
12:37 bluescreen joined #parrot
12:46 cotto Is that all it took?  I thought it was a much harder fix than that.
12:47 cotto whiteknight++ not_gerd++
12:49 moritz mostly unrelated, but recently I've had this idea that error messages that mention relative paths should also mention the current working directory
12:49 dalek parrot: 7cd618a | Whiteknight++ | t/compilers/imcc/syn/file.t:
12:49 dalek parrot: fix a test file that helpfully did a verbatim full-text match of the error message, to guarantee we never added more helpful information to it
12:49 dalek parrot: review: https://github.com/parrot/parrot/commit/7cd618a3d4
12:49 whiteknight moritz: patches welcome, but that doesn't sound like a fun thing to work on
12:50 moritz whiteknight: indeed, and I don't intend to pursue it right now
12:50 * cotto tries to go back to sleep
12:50 moritz whiteknight: but it's worth keeping it in the back of the mind, everything that helps people to better understand errors is potentially useful
12:51 not_gerd is there a better way to resume an aborted build (after fixing some code) than `make clean`?
12:51 not_gerd if not, I need a faster machine..
12:51 JimmyZ ccache?
12:52 moritz not_gerd: `make`
12:52 tadzik oh, I wish we had ccache for compiling Rakudo :)
12:52 moritz tadzik: well, if you configure parrot to use ccache, rakudo does it do :-)
12:53 whiteknight moritz: no question. I'm not saying it isn't useful. We have to weigh the usefulness against the amount of effort it takes to implement. Some fixes are easy. Some, not
12:53 not_gerd moritz: I get PackFile_Header_validate error when I try that...
12:53 moritz ... for compiling the PMCs and ops :-)
12:53 not_gerd might be unrelated, though
12:53 not_gerd I'm just wondering where my debug output went :(
12:55 whiteknight where did you put it?
12:57 not_gerd I'm working on adding MSYS path translations to Parrot_io_open() and added `Parrot_io_putps(interp, _PIO_STDOUT(interp), path);` to my `#ifdef __MSYS__` block
12:58 tadzik moritz: hmm, did you try that?
12:59 moritz tadzik: yes, but it doesn't really speed up anything, because the huge bottleneck is setting compilation
13:00 tadzik I see
13:02 whiteknight not_gerd: I would expect that to work, unless something is getting redirected
13:02 whiteknight _PIO_STDERR should work too, and is less likely to be mangled
13:04 not_gerd I think STDOUT got somehow redirected into the bytecode file, and that's why the validation failed later on
13:04 not_gerd it works with STDERR
13:11 bubaflub joined #parrot
13:14 ambs_ joined #parrot
13:32 benabik o/
13:32 dalek rakudo/nom: 4f6018b | tadzik++ | src/Perl6/Grammar.pm:
13:32 dalek rakudo/nom: Allow any number of colonpairs in Pod block configuration
13:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4f6018b539
13:32 dalek rakudo/nom: 380494c | tadzik++ | / (3 files):
13:32 dalek rakudo/nom: Parse Pod block configuration and store it in Pod::Block.config. Add tests.
13:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/380494cfbc
13:35 atrodo not_gerd> ping
13:36 not_gerd atrodo: pong
13:36 atrodo not_gerd> finally catching you about the m0/lorito topic
13:37 atrodo Your observations don't surprise me much.  It was designed when we still had the nebulous topic of Lorito and didn't have m0
13:37 Eclesia left #parrot
13:38 atrodo Designed with the requirements at the time, which were to be minimal, simple, and powerful enough to implement all of C's basic functions
13:41 not_gerd Ii's an interesting choice that Parrot guts will be m0-based - that's not generally done on other VMs (PyPy excluded)
13:42 not_gerd without a JIT, you'll have to pay the dispatch penalty a lot more...
13:45 atrodo Yep, but it has the potential to solve a lot of outstanding speed issues for parrot.
13:45 atrodo I'm still not sure if it's the right trade offs, but I think the simplification of the parrot guts is understated.
13:46 atrodo Making the guts more approachable make the entire project more approachable.  I've steered clear of using parrot as a target for many years because it was so difficult for me to grok why things were done a certain way
13:47 whiteknight the question of "why" is often very disappointing. I don't suspect many of the biggest infelicities in parrot have an underlying reason
13:48 whiteknight a lot of things just happened, in response to things that users claimed they just needed
13:48 atrodo whiteknight> I always suspected that was the case, but I need to know how and the why seemed to be entangled in the answer
13:48 atrodo s/need/needed/
13:49 not_gerd also, has there been any discussion on m0/gc interaction?
13:49 atrodo That and pasm/pir was the interface.  I'm sure you know how that went, whiteknight
13:49 whiteknight yes, very well
13:50 not_gerd in particular, if we want HLLs to generate m0 (we want that?), and also assuming local variables should be mapped to m0 registers, there need to be a way to attach meta-information to registers
13:51 atrodo not_gerd> for instance?
13:51 not_gerd the gc needs to know which registers hold PMCs, and other HLLs (eg Perl6) might want to attach type information/constrants to local variables
13:51 moritz don't assume that local variables map directly to registers
13:52 moritz I mean, some of them may
13:52 moritz but most don't
13:57 benabik The first thing I see a lot of people say about M0 is "if HLLs generate M0".  We should probably decide if we want that and make a clear statement about it in the design doc.  I've always been under the impression that HLLs should care about M0 in the future as much as they care C today.
13:57 tadzik true
13:57 not_gerd so what do HLLs generate? PIR?
13:57 tadzik well, pir is supposed to generate m0, isn't it?
13:58 JimmyZ well, maybe pir, maybe pbc, maybe M0
13:58 tadzik and pir is supposed to be trashed as well istr, so maybe just PAST, which will be turned to m0/pbc
13:58 tadzik well, HLLs do generate PAST now, mostly
13:58 moritz but PASTs isn't as expressive as PIR
13:59 benabik moritz: There's always inline nodes…  :-/
13:59 moritz so much for abandoning PIR
14:00 atrodo My vote has been for m0 and pbc available for HLLs to use
14:00 not_gerd how does the current system work, ie how do you go from PAST to something that's actually exected?
14:00 tadzik if that's through some toolkit, +1
14:00 tadzik not_gerd: PAST compiler generates pir, pir gets compiled to pbc
14:00 benabik Technically PAST::Compiler generates POST, POST::Compiler generates PIR.
14:01 NotFound If m0 is very low level and we allow HLLs to generate it, security arenas and validity checks can become a nightmare.
14:02 benabik Security isn't really Parrot's strong suit.
14:02 atrodo NotFound> That's my worries about it.  There's never been many concerns raised around m0 bytecode and security, and when I've seen it come up, it's been very dismissive
14:02 atrodo benabik> You can say that again.
14:03 atrodo Which is very disappointing.
14:03 benabik "that again"?
14:03 benabik ;-)
14:03 atrodo Touche
14:08 whiteknight what we haven't had a lot of are specific use cases and examples of what users need from a security system
14:09 whiteknight lots of people are expecting somebody else to figure out what's needed, design a solution, and implement it
14:09 benabik whiteknight: As I progress with PACT, I think "invalid bytecode shouldn't crash the system" will start to come up.  :-D
14:09 whiteknight benabik: and how do you avoid that without tanking performance?
14:10 whiteknight have a second validation tool that nobody will run? checksums that will be easy to change, and will still lead to crashes?
14:11 whiteknight we could definitely teach the packfile pmcs how to validate packfiles on creation. that does ignore the idea of a creepy attacker with hand-crafted pbc files
14:11 atrodo whiteknight> And that's the issue with Parrot's security.  No one wants to take a stab at it because performance is put at such a higher priority
14:12 tadzik I suppose performance is currently much more hurting issue than security
14:12 whiteknight atrodo: we are driven in large part by what users are asking for. Users are asking for security, and in some cases giving us specific benchmarks that need improvements
14:12 moritz iirc dukeleto wanted some pretty specific security features for PL/Parrot
14:12 whiteknight no users are giving us use-cases for security that we can reach for
14:13 moritz let me state a simple one
14:13 moritz I run p6eval
14:14 moritz I'd like to be able to tell rakudo that it's not allowed to read files except from it's installation directory
14:14 dalek rakudo/nom: 276bfeb | tadzik++ | / (5 files):
14:14 dalek rakudo/nom: Parse =config directives properly
14:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/276bfeb0d2
14:14 moritz and it's not allowed to write any files, or open sockets, or fork
14:14 tadzik and call C code
14:14 tadzik s/and/or/ probably
14:15 whiteknight moritz: and those restrictions need to happen at the parrot level? Many of those things sound like they would almost be better handled by Rakudo
14:16 moritz whiteknight: depends on what you mean by "better"
14:16 whiteknight for example, a flag in your file handle type, or telling p6eval that it can't compile code that creates certain types
14:16 not_gerd whiteknight: so PL/Parrot would need to special-cased for every language?
14:16 atrodo whiteknight> Yes.  Because it's not just Rakudo that wants those security measures.  It's every HLL should be able to ask for the same level of security
14:16 not_gerd that would somehow defeat its purpose, methinks
14:16 whiteknight moritz: yes, it does depend on what I mean by that word
14:16 moritz whiteknight: for me it's "better" if parrot does it, in that I as a HLL developer don't have to work hard to get the feature
14:16 whiteknight atrodo: we can build in things like that to our own opcode sets, or our own built-in pmc types. But rakudo provides many of its own
14:16 atrodo moritz> And probably get it wrong
14:17 whiteknight when somebody else runs C code outside the parrot core, we have no defense against it. I can't tell parrot to prevent you from running arbitrary C code in one of your own extensions
14:17 moritz and I don't expect that part to be secure
14:17 atrodo whiteknight> What about systems that accepts PBCs?  Like imagine a parrot applet
14:17 moritz but currently you can only do harm in rakudo through parrot's IO subsystem
14:18 whiteknight moritz: okay, but Rakudo is a great example in that it has a *lot* of custom code
14:18 whiteknight atrodo: what about it?
14:18 atrodo whiteknight> what about security with those systems?  PL/Parrot being a perfect example.
14:19 whiteknight atrodo: again, what about it?
14:19 atrodo How would you purpose to secure it?
14:19 whiteknight secure it from what? From whom? What is and is not considered "secure"?
14:20 whiteknight if security means "We should be able to restrict IO". tjat
14:20 whiteknight that's a flag that we can set
14:20 whiteknight and I suspect people want more than a simple flag
14:20 moritz whiteknight: some people want constraints on memory and CPU usage too
14:20 NotFound Some upper level must stablish a security arena and its policys, parrot must provide the mechanic to allow that.
14:20 atrodo Malicious users.  In all aspects.  Outside users should never be able to do things that the users in control don't want them to.
14:20 whiteknight if it means we should be able to toggle on or off certain opcodes or vtables, that's a simple API that people can say "turn this off"
14:21 whiteknight atrodo: so you have malicious users with the ability to execute arbitrary PBC files, and it's parrot's job to be the last line of defense?
14:21 whiteknight atrodo: at that point, the battle is long over
14:22 atrodo whiteknight> Then what's the difference between a pbc and .jar?  Has java already lost the battle then?
14:22 whiteknight if we have a security subsystem that allows certain features to be toggled, and the attacker has access to modify those settings, who cares what the PBC contains?
14:23 whiteknight now, if what we want is the ability to speculatively load packfiles and verify them before we commit their contents to the global environment, that's something that we can do
14:23 NotFound The feature of toggling that features is the first that need access control.
14:24 whiteknight NotFound: so we would have certain features in Parrot that would require system user permissions to perform?
14:25 NotFound whiteknight: some upper level has control, it stablishes the policy and call controlled code, probably on a secondary intrepreter/runner/thread/whatever.
14:25 whiteknight I'm not saying that we can't do security, or that we shouldn't, or anything like that. What I'm saying is that it's hard to do and people keep saying "what about applets" or "we need security" without putting forward a lot of specifics
14:25 whiteknight and there are going to be trade-offs. We need users to tell us exactly what they are willing to give back, or go without
14:28 whiteknight because if we start implementing security, and we start to see regressions anywhere in the spectrum, you can be damned sure we're going to hear about it and have to have some kind of emergency intervention to "fix" a release the day before it ships
14:28 NotFound I think that before attempting to implement something we should have a better design of the interpreter/thread/context thing.
14:28 whiteknight or if we put in security, and it isn't 100% what somebody wants, they're going to have to implement their own versions and put together ugly workarounds to get past the parrot version, and then complain that Parrot doesn't do what users need
14:30 atrodo whiteknight> moritz gave a very simple example and very specific features.  The response was "rakudo should do it".  I now have no hope that parrot will ever have any security worth anything if that's the response given.  I'm out of this.
14:30 whiteknight atrodo: that was not the response. I said it sounds like those are things Rakudo could do better, becuase of the nature of Rakudo
14:31 whiteknight Rakudo has a lot of custom C code, and Parrot can't secure that. That means Rakudo is going to have at least two security systems in place, which it will need to manage
14:31 whiteknight other HLLs or projects are hardly in the same situation
14:31 moritz none of the C code in rakudo is security relevant
14:32 whiteknight Rakudo currently has it's own custom object model, so Parrot cannot prevent the creation of specific object types, or prevent the call of specific object methods
14:32 moritz (for this type of security at least)
14:32 whiteknight Rakudo has custom Ops, which Parrot can't secure, prevent, or replace
14:32 whiteknight Parrot can put in all the security in the world, and very little of it will be able to help Rakudo
14:33 moritz whiteknight: rakudo does all its IO through parrot's IO, which means that it instatiates parrot PMCs
14:33 moritz whiteknight: which are not 6model based at all
14:33 whiteknight moritz: like I said, we can do something about IO. That's trivial really, depending on the solution we want
14:33 whiteknight I am highly skeptical that it is going to be more than a drop in the bucket of Rakudo security needs
14:33 NotFound I don't think that disabling opcodes, vtables or pmcs is the better way to set barriers. Subsystems can do, and we can ask HLLs to use that subsystems
14:34 whiteknight NotFound: Right. That's easy to do, for types and things that Parrot core provides
14:34 whiteknight but again, almost nobody uses 100% parrot core stuff. Everybody has custom code they're calling, or custom classes, or custom NCI bindings
14:35 NotFound NCI is a big issue here.
14:35 whiteknight It seems stupid to me, and maybe that's just my problem, for us to secure 50% of things and tell users that they are on their own
14:36 PacoLinux_ joined #parrot
14:37 whiteknight or give some kind of guarantee that Parrot is safe, so long as you don't choose to run any code that isn't safe
14:39 atrodo whiteknight> As a epilogue, it's an extremely frustrating subject for me because I've had to pass on two major projects simply because parrot has no security and no easily accessible framework for adding security measures
14:40 whiteknight to secure Parrot core, and to hell with extension code, we would need: the ability to restrict certain opcodes, the ability to prevent creation of certain PMC types, the ability to restrict certain methods and/or vtables on PMCs, the ability for two-stage loading of packfiles, and the ability to prevent a child interp from interacting with a parent interp
14:40 * JimmyZ would like to see a detailed rfc lists  that users want what security parrot offers
14:40 whiteknight atrodo: I understand the frustration. I do. I would like to have these features, and would certainly work to implement them, if we knew exactly what was needed and what users expected
14:41 whiteknight JimmyZ: I would like that too
14:42 whiteknight the fact that, I think, many of these security features are tightly coupled with various refactors and fixes I already have planned is a good thing
14:43 whiteknight Here are some simple questions we need answered: Do we want security at the whole VM level, at the level of individual interpreters, or at the level of the context?
14:43 dalek rakudo/nom: df376ba | tadzik++ | src/Perl6/Grammar.pm:
14:43 dalek rakudo/nom: Allow any non-whitespace string as a =config type identifier. Fixes S26 parsing
14:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/df376bab86
14:44 whiteknight are users willing to give up the current NameSpace system, or allow radical backwards-incompatible changes to it?
14:44 PacoLinux_ joined #parrot
14:44 whiteknight how are we supposed to verify a pbc file, besides tests for basic structure conformity or checksums?
14:45 JimmyZ well, I don't think security features is important things now
14:45 whiteknight does a single binary of Parrot need to be both securable and open depending on settings, or can we use different compilations for different usages?
14:45 not_gerd can I add a header to platform/win32 or is there a better place to put a macro which needs to be used from several platform-specific files?
14:46 not_gerd no other platform dir contains any header files...
14:46 whiteknight how do we handle security issues on Windows? On embedded devices? when Parrot is embedded into a larger program with its own settings?
14:46 JimmyZ can we steal some ideas from java?
14:46 whiteknight we can
14:46 JimmyZ or can parrot
14:46 whiteknight if what they do is good
14:47 JimmyZ if they are better than parrot :)
14:47 whiteknight if they are better than what parrot would eventually do on it's own
14:47 whiteknight I don't want to copy a design that is not better than something we could do ourselves
14:49 whiteknight M0 is going to decrease our reliance on binary extensions, which is good for security. However, it is going to increase our dependence on FFI, which is bad
14:50 whiteknight namespace and bytecode refactors are going to do a lot for security, but the transition is going to be very messy, and lead to lower bytecode loading performance, probably
14:50 * JimmyZ pays more attention to threads, 6model on parrot, PCC
14:50 whiteknight threads raises a whole other bag of worms. If we have a lock-based concurrency model, it will be trivial and undetectable for a malicious user to craft bytecode in such a way that it deadlocks
14:51 whiteknight or hell, in 4 lines of code I can write an infinite loop that would lock up a machine and make it vulernable to DOS attacks
14:52 whiteknight figuring out exactly what is meant by security is important, because there are lots of different, unrelated things to think about and we can't protect everything from every attack
15:07 dalek rakudo/nom: 8336468 | pmichaud++ | NOMMAP.markdown:
15:07 dalek rakudo/nom: Add <!before> to NOMMAP.
15:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/833646872f
15:14 dukeleto ~~
15:31 whiteknight dukeleto: We're talking security today. I know you had some ideas from your PL/Parrot work. Want to share your thoughts?
15:40 dmalcolm joined #parrot
15:49 dalek rakudo/nom: 3f57585 | jonathan++ | src/Perl6/Actions.pm:
15:49 dalek rakudo/nom: Be sure to apply traits for regexes with the same ordering we do methods.
15:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3f57585494
15:49 dalek rakudo/nom: 0999de1 | jonathan++ | src/Perl6/Actions.pm:
15:49 dalek rakudo/nom: Action method for trait_mod:<will>.
15:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0999de1e7b
15:52 dukeleto whiteknight: sure. PL/Parrot needs a lot more security than Parrot provides natively, so I had to fake some of it
15:52 whiteknight dukeleto: What I'm really looking for are some of the specifics. What exactly needs to be secured and how?
15:53 dukeleto Parrot has some vague idea of "opcode groups", but they never make it out of the build system. For instance, I want to be able to disable all file I/O in a given Parrot interp
15:53 dukeleto whiteknight: instead of doing this hackery: https://github.com/leto/plparrot​/blob/master/plparrot_secure.pir
15:53 whiteknight okay, so we need to be able to disable certain opcodes. I assume we also need to be able to disable certain PMC types?
15:53 rurban joined #parrot
15:54 whiteknight ewww...
15:54 dukeleto whiteknight: the pmc's that I care about are just wrappers around opcodes, so I think if the opcodes are removed, then that would be enough
15:54 whiteknight okay, we don't want that
15:54 dukeleto whiteknight: yeah, that is one of the hackiest hacks I've ever done
15:55 whiteknight dukeleto: but even in the case of FileHandles, you can call methods on FileHandle that write to output handles without calling any ops
15:55 dukeleto whiteknight: also, interps should not know anything about each other, and definitely I should not have to pass in the first ever created interp to create subsequence interps. I created a TT about that a while back (as well as for opcode groups)
15:55 whiteknight any ops besides normal method calls
15:55 whiteknight yeah, the interp parent thing is a problem with the threading system, and it's going to stay until we rip out or fundamentally refactor threading
15:56 whiteknight okay, so let's say I have a new PMC type SandboxInterp, which is like an ordinary interpreter in that it assumes it is the top-level and doesn't try to access a parent interp for anything
15:56 dukeleto whiteknight: it would be preferable to be able to disable opcodes at compile time, i.e. when PL/Parrot is compiled. Not sure exactly how that would work.
15:56 dukeleto whiteknight: i like it
15:57 whiteknight so I can create a new SandboxInterp, initialize it, have the parent toggle certain settings like you do in your example (but with an official API), and then set it loose
15:57 dukeleto whiteknight: it would also be nice to disable or selectively disable network IO
15:57 dukeleto whiteknight: that sounds very pleasant
15:58 whiteknight dukeleto: We can do the same trick for Socket PMC as you do there for File and FileHandle
15:58 whiteknight again, with a better API
15:59 dukeleto whiteknight: indeed. I think Socket PMC inherits from FileHandle, so that is covered in my hacky example, iirc
16:00 dukeleto whiteknight: removing the ability to eval code in an interp would be another thing, i.e. the interp can only load already-existing bytecode and PIR, but cannot compile new code at runtime. Again, not sure how hard that would be
16:01 whiteknight okay, so SandboxInterp would have methods on it to remove or replace certain types by name. It would have methods to remove or replace compregs
16:01 dukeleto actually, I can't decide if plparrot_secure.pir is the hackiest thing I've ever done, or plparrot_make_sausage() https://github.com/leto/plparr​ot/blob/master/plparrot.c#L531
16:02 whiteknight you know, these are code examples you should probably keep secret :)
16:03 dukeleto whiteknight: yeah, i think that went out the window when I pushed to github. My only defense is that without the power of whiskey, that code would not exist.
16:03 whiteknight so is that what we need for security, just the ability to create and modify sandboxes?
16:03 whiteknight that seems thin to me
16:04 dukeleto whiteknight: it surely would greatly increase the current security features of parrot now, which are basically nil
16:04 whiteknight The whiteknight/frontend_parrot2 branch is going to be a big help in that regard, because we can change all these settings from a PIR bootstrap instead of through a complicated C API
16:04 whiteknight although I don't have an ETA yet for that branch
16:05 dukeleto whiteknight: whiskey gave me the fortitude to read all the postgres header files to reverse engineer all that junk, and then I never went back to refactor and make the code pretty. One of these days...
16:05 whiteknight whiskey: is there anything it can't do?
16:05 dukeleto whiteknight: i like not having to do stuff from C
16:05 whiteknight I rewrote the parrot frontend in winxed. I'm a bit of a fanatic
16:06 theory joined #parrot
16:07 whiteknight dukeleto: in the time it would take me to put together a sandboxing solution like I described, could we have some concrete plans for where to go next? You said it was a good start, but would it really be a building block for the system we ultimately want?
16:08 whiteknight or, would it be a distraction from the best possible system?
16:08 benabik "I'm going to open my laptop.  If the code isn't refactored in an hour, send more whiskey."
16:09 whiteknight "you know what? Just send more whiskey"
16:11 dukeleto whiteknight: would love to get your feedback on http://trac.parrot.org/parrot/ticket/1500
16:11 dukeleto whiteknight: it is an old TT that needs love
16:11 dukeleto whiteknight: as well at this one http://trac.parrot.org/parrot/ticket/1697
16:13 dukeleto whiteknight: and if you could comment on my "not needing a parent interp" TT, describing your sandbox api, that would be awesomesauce: http://trac.parrot.org/parrot/ticket/1880
16:16 dukeleto whiteknight: if you had that sandbox solution, that would motivate me to hack on PL/parrot more, and give it a proper security model, which in turn would probably point out some missing features from the Parrot-side, and start a nice code-design whirlpool
16:17 not_gerd can I rely on the fact that Parrot_str_free_cstring() just calls mem_sys_free() on its argument?
16:18 whiteknight not_gerd: no. It won't always, depending on the GC. Only use it if you have a cstring you got from a Parrot string
16:19 whiteknight not_gerd: in the future we might cache them, so free_cstring won't actually do anything
16:19 whiteknight or we might not, so call it anyway to avoid leaks
16:20 dukeleto whiteknight: looks like this thread patch fell through the cracks, and might fix our intermittent netbsd failing threads test. Can you take a look at it? http://trac.parrot.org/parrot/ticket/1340
16:22 dalek TT #1917 closed by dukeleto++: Parrot_api_make_interpreter() cause a crash when another interpreter ...
16:22 dalek TT #1917: http://trac.parrot.org/parrot/ticket/1917
16:29 whiteknight threading needs to be deleted, not patched
16:32 davidfetter joined #parrot
16:32 whiteknight and before anybody suggests otherwise, we have version control and will always have a record in case we want to salvage some ideas from it
16:34 contingencyplan joined #parrot
16:37 not_gerd I'm off for now, but I would appreciate it if someone took a look at https://github.com/gerdr/parrot/commit/7​9ff8855b4f215ba570616f918c1ac16fe2aff2d and told me if there's a gross violation of Parrot conventions
16:39 whiteknight not_gerd++
16:41 dukeleto whiteknight: +1 to deprecating current threads. But seemingly we should have a replacement ready before ripping it out. But yes, it isn't really worth fixing at this point.
16:42 * jnthn__ figures m0 has a threading plan worked out.
16:42 jnthn__ well, hopes.
16:44 whiteknight dukeleto: that's the same thing people have been saying. Let's just keep the garbage around until we have non-garbage to replace it with
16:45 whiteknight and then, we can keep the garbage and non-garbage around together, so we can make a smooth transition
16:47 whiteknight jnthn__: We have lots of ideas floating around. Most of them deal only peripherally with M0
16:57 Eclesia joined #parrot
16:57 Eclesia hi
16:57 whiteknight hello Eclesia
17:04 Eclesia hi bubaflub, found the fix on gmp ?
17:04 bubaflub Eclesia: not yet.  going to need some more info from your system parrot.
17:04 Eclesia sure, just ask and how to get those
17:12 dukeleto jnthn__: i don't think m0 has a threading spec yet
17:12 dukeleto whiteknight: i understand your frustration. We ripped out the old JIT without having a smooth transition, so there is precedent for not keeping around "garbage"
17:13 dukeleto whiteknight: i think we need to see if anybody is using the current threads at all. I really don't know.
17:20 ligne joined #parrot
17:25 cotto_work ~~
17:26 dalek TT #2179 closed by jkeenan++: Bug in setup-parrot-3.6.0.exe broke PATH
17:26 dalek TT #2179: http://trac.parrot.org/parrot/ticket/2179
17:30 mj41 joined #parrot
17:32 autark joined #parrot
17:33 mj41 joined #parrot
17:37 Coke benabik: (Sometimes #parrot seems to be full of people who don't like parrot but keep working on it anyway for some inexplicable reason.) ... Wow. I think you just summed up my entire involvement. ;)
17:46 nopaste "coke" at 192.168.1.3 pasted "bikeshed changelog" (18 lines) at http://nopaste.snit.ch/73950
17:50 Coke So, originally, changelog was "changes" which happened intra-release, and were per user. Now all that is in news, which is per release. I honestly don't think we need to note the user or the date at all - those are in parrothist, anyway.
17:51 nopaste "coke" at 192.168.1.3 pasted "bikeshed changelog" (17 lines) at http://nopaste.snit.ch/73951
17:51 Coke anything in changelog that predates that can keep its date/name marker.
17:56 mikehh joined #parrot
17:58 whiteknight did anybody else in the area just feel an earthquake?
17:59 atrodo if by area, you mean eastern us, nope
18:00 cotto_work http://earthquake.usgs.gov/earthquakes/
18:00 whiteknight 5.8 in virginia. definitely shook our building
18:01 Coke FYI, we have 86 releases mentioned in NEWS.
18:01 dalek rakudo/nom: c8be361 | tadzik++ | src/Perl6/Pod.pm:
18:01 dalek rakudo/nom: Fix Pod::Config regression
18:01 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c8be361ca9
18:01 dalek rakudo/nom: 16bad5c | tadzik++ | / (2 files):
18:01 dalek rakudo/nom: Allow multi-line Pod block configuration
18:01 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/16bad5c0f7
18:05 not_gerd joined #parrot
18:07 cotto_work From what I remember, the reason given for keeping the current threading code around wasn't that someone's likely to be using it, rather that there might be enough useful code to benefit a proper implementation.
18:08 plobsing the platform abstractions might be useful, but the stuff for working with interps and the PMC types are utter garbage
18:09 bubaflub can't we just delete it since we have source control?  we can always resurrect it later.
18:09 whiteknight like I said, it's not like we're deleting the entire history
18:10 whiteknight the platform abstraction stuff is decent, but it's also a relatively small portion of the total
18:10 plobsing I'd argue that even the platform abstractions, while useful, could be recreated in about 1 person-day of reading win32/posix docs
18:11 cotto_work plobsing: weren't you the one who was advocating keeping the existing code around for possible future reuse?
18:12 plobsing I advocated keeping around the platform abstractions. I've since changed my mind. I reserve the right to do that from time to time.
18:12 whiteknight plobsing is one of the big reasons I haven't jumped on it yet
18:12 cotto_work Certainly.  Anyone may reserve the right to change his or her mind at any time.
18:12 * whiteknight adds this to the pile of "branches I need to create"
18:13 cotto_work If you're going in the wrong direction, progress means turning around.
18:15 whiteknight I love branches where most of the work is Ctrl+A and Del
18:15 whiteknight makes me feel warm and fuzzy inside
18:15 plobsing git rm is always fun to use
18:18 whiteknight rm -rf /
18:18 whiteknight MUAHHAHAHAHA
18:18 plobsing rm: it is dangerous to operate recursively on `/'
18:18 plobsing rm: use --no-preserve-root to override this failsafe
18:19 plobsing too bad
18:19 whiteknight oh yeah, I forgot they added that
18:19 plobsing even if they didn't I don't have the perms
18:19 Eclesia1 joined #parrot
18:20 whiteknight if you have physical access to the machine, almost exactly the same result can be obtained with a hammer and a chisel, with or without perms
18:20 whiteknight of course, you will need to buy a new drive
18:20 atrodo whiteknight> apparently, some people felt it out here.  At least that's what my wife has told me
18:20 whiteknight atrodo: I've heard reports as far away as toronto, but I don't know how accurate they are
18:20 whiteknight NYC definitely
18:21 whiteknight I work in a very old stone-and-brick building, so I got the hell out
18:21 plobsing true, but I still think it is a good idea not to run with perms required to blow away your machine unless and until you need to do important configure-y stuff.
18:23 bubaflub my Pittsburgh co-workers had to evacuate their office building
18:24 plobsing whiteknight: Didn't feel anything in Waterloo ON (~1hr from T.O.)
18:25 whiteknight that's good. It's nice to hear a sane, first-hand account
18:34 rohit_nsit08 joined #parrot
18:35 rohit_nsit08 hello #parrot
18:35 tadzik hello rohit_nsit08
18:36 rohit_nsit08 tadzik: hello
18:37 dalek rakudo/nom: 6ad7834 | moritz++ | tools/build/Makefile.in:
18:37 dalek rakudo/nom: fix bug from 19cfd13 that made Sub !~~ Callable
18:37 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6ad7834182
18:38 theory left #parrot
18:39 whiteknight hello rohit_nsit08
18:42 rohit_nsit08 whiteknight: hello, have submitted the final report on gsoc site, but was having doubt about what should I do now , I am willing to finish my work as corella is still not complete
18:42 whiteknight rohit_nsit08: I haven't tested it recently. I will have to look at it
18:42 whiteknight rohit_nsit08: can you write a short summary about what is done and what needs to be done?
18:43 rohit_nsit08 yes sure,'
18:43 dalek parrot: a136a32 | fperrad++ | tools/dev/mk_inno.pl:
18:43 dalek parrot: [win32] fix TT#2179
18:43 dalek parrot: review: https://github.com/parrot/parrot/commit/a136a32840
18:49 Coke http://jmckinley.posterous.c​om/dc-earthquake-devastation
18:49 Coke I think the pencils down date marks the end of code-to-be-considered-for-evaluation.
18:49 cotto_work Coke: that's my understanding
18:49 Coke Doesn't mean you cannot keep working in that repository.
18:50 Coke if that's it, might be worth doing a tag of GSOC_PENCILS_DOWN_2011 or something.
18:51 NotFound In the automake mailing list I've seen a suggestion of creating a new branch to keep working, and let the original branch intact for the evaluation.
18:52 cotto_work Coke++ # that link made my officemates happy
18:53 Coke cotto_work: I opened it actually fearing the worst!
18:53 Coke NotFound: that would also work; as long as there is some way to say "this is what goes to google".
18:53 bubaflub NotFound, Coke, and rohit_nsit08: previous years of GSoC we could keep working in the original repo even on the original branch; you are simply required to upload only the code that was written between the start and the end date.
18:54 bubaflub if you're in git, you can filter your commits by start date and end date and then generate a huge diff and upload it to Google
18:54 Coke bubaflub: aye. tag just makes it pretty. ;)
18:54 bubaflub agreed.
18:55 rohit_nsit08 hmm.. got it .
18:55 tadzik I used git log 'HEAD@{23-05-2011}'..'HEAD@{22-08-2011}' -p --author='Tadeusz Sośnierz'
19:14 whiteknight rohit_nsit08: hey, I'm looking at the corellaScript repo, and I don't see the source code for your PIR code generator
19:14 whiteknight is that not checked in?
19:16 soh_cah_toa joined #parrot
19:20 rohit_nsit08 whitknight: ?? wait , let me check , all the PIR codegen functions contain the code for PIR generation
19:21 whiteknight rohit_nsit08: so corella.js is the code generation source? There isn't an original file somewhere?
19:21 Coke is corella.js a generated file?
19:21 Coke ah, too slow.
19:22 rohit_nsit08 corella.js is the original compiler file except the bottom code which is for testing it on node
19:23 rohit_nsit08 the topmost portion contains the parser and after that are the tree node generating functions
19:23 rohit_nsit08 below that are the PIRcodegen functions
19:23 rohit_nsit08 program execution starts from the "Program" node
19:23 whiteknight okay, so that's the file you wrote, and there aren't original files anywhere?
19:24 rohit_nsit08 my code is actually in the code generator part , in the original functions I have tried to get PIR
19:24 rohit_nsit08 by reading the tree and than executing the code generator functions on the specific nodes
19:25 davidfetter joined #parrot
19:25 rohit_nsit08 the parser and node generating part is similar to the "cafe" compiler's parser.js file
19:26 rohit_nsit08 but it was using commonjs libraries somewhere so I removed them
19:26 * Coke hurls: http://www.modernperlbooks.com/mt/2011​/08/no-policy-can-save-wrong-code.html
19:26 PacoLinux_ joined #parrot
19:26 Coke a sad read.
19:27 atrodo Coke> I was just reading it
19:27 atrodo A sad read indeed
19:29 lucian joined #parrot
19:29 rohit_nsit08 whiteknight: it is the corella.js file that needs to be compiled at the end , class folder contains the js data types
19:30 whiteknight yeah, I saw that. I'm just making sure I'm not missing anything
19:30 whiteknight rohit_nsit08: and you used the cafe grammar for javascript, right?
19:31 rohit_nsit08 ya the same grammar, It was taking time to understand the whole grammar from various books, so I finally decided to go with the same grammar, but I did cross checked it with ecmascript
19:33 whiteknight okay
19:35 Eclesia1 left #parrot
19:36 rohit_nsit08 whiteknight : Isn't there any standard that checks whether a grammar is complete or not, I mean is it possible that cafe's grammar is not exactly what javascript is?
19:36 whiteknight rohit_nsit08: no automated way. The only way we would know is to run lots of tests
19:36 cotto_work #ps in now
19:40 rohit_nsit08 whiteknight: tests as in ? like I tested different codes and studied the AST generated and I tried to get PIR from the same AST . Don't think it was the best way though
19:41 schmooster joined #parrot
19:41 whiteknight rohit_nsit08: I'm sure there are test suites somewhere for other JS implementations
19:47 cotto_work nine: if you're online, we're doing our weekly meeting in #parrotsketch
19:50 rohit_nsit08 whiteknight: ya , actually I was thinking about the grammar part. and it can only be tested after we have a compiler using that grammar
19:50 whiteknight right
19:50 lucian joined #parrot
19:53 lucian joined #parrot
19:55 dalek winxed: f5c6f7c | NotFound++ | winxedst (2 files):
19:55 dalek winxed: implement predefined constant __DEBUG__, harcoded to false for a now
19:55 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/f5c6f7c736
20:01 rohitnsit08 joined #parrot
20:01 rohitnsit08 left #parrot
20:06 whiteknight NotFound++
20:15 rurban joined #parrot
20:27 PacoLinux_ joined #parrot
20:50 dalek parrot: 2268530 | cotto++ | config/gen/makefiles/root.in:
20:50 dalek parrot: don't assume $(MAKE) == make in release
20:50 dalek parrot:
20:50 dalek parrot: make release is broken on windows/msvc.  This makes it a little less broken.
20:50 dalek parrot: review: https://github.com/parrot/parrot/commit/22685301f8
20:50 davidfetter joined #parrot
20:52 Coke cotto++
20:52 Coke that was on my list of things to get around to. ;)
20:55 cotto_work Coke: that's not the last step.
20:55 cotto_work I wish I could fix it further, but I've spent a lot of time on Parrot stuff already and need to do what $dayjob is paying me to do.
21:02 * Coke will do a make release on windows after killing NEWS.
21:02 dalek TT #2183 closed by cotto++: sha256 problem encountered during 'make release'
21:02 dalek TT #2183: http://trac.parrot.org/parrot/ticket/2183
21:02 cotto_work Coke++
21:06 dalek winxed: 3004909 | NotFound++ | winxed (3 files):
21:06 dalek winxed: implement setting __DEBUG__ in stages and non installed driver
21:06 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/300490908f
21:13 dalek winxed: cebd3a8 | NotFound++ | winxed_installed.winxed:
21:13 dalek winxed: implement setting __DEBUG__ in installed driver
21:13 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/cebd3a84d2
21:14 dalek winxed: 1938085 | NotFound++ | pir/winxed_ (2 files):
21:14 dalek winxed: update installable files
21:14 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/1938085ba1
21:27 dalek parrot: b84af47 | NotFound++ | ext/winxed/ (2 files):
21:27 dalek parrot: update winxed snapshot to 1938085ba1:
21:27 dalek parrot: * namespace operator
21:27 dalek parrot: * __DEBUG__ predefined constant - --debug command line option
21:27 dalek parrot: review: https://github.com/parrot/parrot/commit/b84af4773f
21:34 allison BTW, a long time ago we talked about a Parrot test suite that could be run on an *installed* Parrot.
21:35 allison AFAIK, there's been no work on it, but I need it now for packaged Parrot.
21:35 allison The Rakudo packagers keep finding issues in the installed Parrot, because they are building their own packages on to depend on it.
21:36 allison These are often small install problems, that could have easily been identified by even a simple test suite.
21:36 allison But they aren't discovered before I upload the Parrot packages, because I run the test suite on the Parrot build directory, not on the installed Parrot.
21:42 particle joined #parrot
21:45 NotFound allison: the winxed tests exercise a lot of parrot features, and can be run from a installed parrot.
21:45 cotto_work Would such a test suite just be another makefile target that ran against whichever parrot is in the $PATH?
21:48 cotto_work or more precisely, whichever parrot_config is in the path
21:54 allison cotto_work: ideally, yes, they would be able to be run against any parrot, including one specified with a command-line flag to pick out a specific parrot_config
21:54 allison cotto_work: which means, they could even be run against parrot in the build directory
21:54 cotto_work something like make test parrot_config=/usr/local/foo/bin/parrot_config
21:55 allison (no point in wasting tests by limiting them to only running on an installed parrot)
21:55 allison aye
21:56 allison cotto_work: it could be make install_test parrot_config=/path...
21:56 allison cotto_work: if we still have some tests that can only run in the build directory
21:57 cotto_work allison: how urgent is this?
21:57 allison cotto_work: it's affected every package I've built so far this year, so it's enough of a priority for me that I'm willing to invest some time in it
21:58 allison cotto_work: if we have a clear consensus on how to do it that makes the most sense for Parrot
21:58 allison (or, something roughly approximating consensus)
22:00 allison NotFound: the winxed tests are a good first stab, but over time I'd like to expand the test suite with regression tests from real issues we've found in various language implementations
22:00 allison NotFound: so, I really want a sensible place to hang the tests within the core Parrot test suite
22:02 mj41_nb joined #parrot
22:04 NotFound We may need a special purpose harness that does not depend on standard handling of shebang lines.
22:23 cotto_work allison: you can always start a branch.  We can maintain a whitelist or blacklist of tests that work (or don't) with an installed parrot.
22:31 davidfetter joined #parrot
23:03 bubaflub joined #parrot
23:13 dalek rakudo/nom: 54e85a2 | tadzik++ | src/Perl6/ModuleLoader.pm:
23:13 dalek rakudo/nom: Accept .pm6 as a module file extensions, prefer it to .pm if both are present
23:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/54e85a20b1
23:23 kid51 joined #parrot
23:51 kid51 aloha, clock?
23:51 aloha kid51: LAX: Tue, 16:51 PDT / CHI: Tue, 18:51 CDT / NYC: Tue, 19:51 EDT / UTC: Tue, 23:51 UTC / LON: Wed, 00:51 BST / BER: Wed, 01:51 CEST / TOK: Wed, 08:51 JST / SYD: Wed, 09:51 EST
23:59 Topic for #parrot is now Trac maintenance Aug 24 17:00 UTC | Parrot 3.7.0 "Wanda" | http://parrot.org | Log: http://irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
23:59 Topic for #parrot is now Trac maintenance Wed Aug 24 17:00 UTC | Parrot 3.7.0 "Wanda" | http://parrot.org | Log: http://irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced