Camelia, the Perl 6 bug

IRC log for #parrot, 2012-02-22

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:03 travis-ci joined #parrot
00:03 travis-ci [travis-ci] parrot/parrot#76 (master - 33316f8 : Vasily Chekalkin): The build passed.
00:03 travis-ci [travis-ci] Change view : https://github.com/parrot/par​rot/compare/504e599...33316f8
00:03 travis-ci [travis-ci] Build details : http://travis-ci.org/parrot/parrot/builds/717789
00:03 travis-ci left #parrot
00:14 particle joined #parrot
00:31 dmalcolm joined #parrot
00:35 particle1 joined #parrot
00:41 dalek website: ayardley++ | Parrot 4.1.0 "Black-headed Parrot" Released
00:41 dalek website: http://www.parrot.org/news/2012/Parrot-4.1.0
00:54 cotto Is nobody else seeing the checkdepend.t failure?
00:54 whiteknight I haven't tested since yesterday
01:13 alester joined #parrot
01:23 benabik joined #parrot
02:21 dalek parrot.github.com: b309cc8 | alvis++ | README_gh-pages.pod:
02:21 dalek parrot.github.com: Add skeleton on how to hand-roll the parrot.github.com docs and any relevant repositories.
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/b309cc80d3
02:21 dalek parrot.github.com: a634719 | alvis++ | README_gh-pages.pod:
02:21 dalek parrot.github.com: Renamed README_gh-pages.pod to README_release.pod which better indicates the purpose of the document.
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/a63471950b
02:21 dalek parrot.github.com: d35e549 | alvis++ | README_release.pod:
02:21 dalek parrot.github.com: Renamed doc to README_release.pod to better reflect the purpose of the doc.
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/d35e5497e5
02:21 dalek parrot.github.com: 48c88df | alvis++ | README_release.pod:
02:21 dalek parrot.github.com: Partial updates to README_release.pod
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/48c88dfc2a
02:21 dalek parrot.github.com: fcd9af8 | alvis++ | / (434 files):
02:21 dalek parrot.github.com: Remove 4.0.0 docs
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/fcd9af871d
02:21 dalek parrot.github.com: f816802 | alvis++ | / (434 files):
02:21 dalek parrot.github.com: Update to 4.1.0 docs
02:21 dalek parrot.github.com: review: https://github.com/parrot/parro​t.github.com/commit/f816802a03
02:40 dalek parrot: cb82296 | alvis++ | docs/parrothist.pod:
02:40 dalek parrot: Update docs/parrothist.pod to correct the year for 4.0.0 and 4.1.0
02:40 dalek parrot: review: https://github.com/parrot/parrot/commit/cb822965dc
03:05 alvis can someone up op me? thanks.
03:06 travis-ci joined #parrot
03:06 travis-ci [travis-ci] parrot/parrot#77 (master - cb82296 : Alvis Yardley): The build passed.
03:06 travis-ci [travis-ci] Change view : https://github.com/parrot/par​rot/compare/33316f8...cb82296
03:06 travis-ci [travis-ci] Build details : http://travis-ci.org/parrot/parrot/builds/718416
03:06 travis-ci left #parrot
03:13 dalek parrot: 88e81a1 | bacek++ | / (17 files):
03:13 dalek parrot: Merge remote-tracking branch 'origin/cont_reuse'
03:13 dalek parrot: review: https://github.com/parrot/parrot/commit/88e81a1b52
03:14 benabik No idea if this will work...
03:14 benabik opbots, trust alvis
03:14 slavorg But I already trust alvis
03:19 alvis benabik: thanks. let me try to set the topic again ...
03:20 alvis benabik: #parrot says i'm not a channel operator. do you mind setting the topic?
03:20 benabik left #parrot
03:20 benabik joined #parrot
03:20 benabik Minor client error there, clicked close instead of channel info...
03:21 benabik (PEBCAK error, to be precise.)
03:21 benabik alvis: No problem.  4.1.0 "???"
03:21 alvis benabik: here it is: /topic #parrot Parrot 0.4.8 Released | http://parrot.org/
03:22 benabik 0.4.8?
03:22 alvis oops! make that 4.1.0
03:23 benabik Oh, dear...  I lost op when I closed the window.
03:23 benabik opbots, do your job
03:24 * benabik fails.
03:24 alvis yeah, i seem to lose op a'lot. don't know why.
03:24 benabik I think the opbots may be taking unauthorized naps.
03:25 alvis ha!
03:25 alvis well, ok. thanks. i'll try again later. i gotta coupl'a more steps to finish out this release.
03:26 alvis my eight month pregnant wife required my attention, slowing things down a'bit. :)
03:26 benabik alvis: They do tend to do that.
03:42 travis-ci joined #parrot
03:42 travis-ci [travis-ci] parrot/parrot#78 (master - 88e81a1 : Vasily Chekalkin): The build passed.
03:42 travis-ci [travis-ci] Change view : https://github.com/parrot/par​rot/compare/cb82296...88e81a1
03:42 travis-ci [travis-ci] Build details : http://travis-ci.org/parrot/parrot/builds/718530
03:42 travis-ci left #parrot
04:06 Topic for #parrot is now Parrot 4.1.0 "Black-headed Parrot" | http://parrot.org | Log: http://irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
04:10 bacek_at_work ~~
04:33 alvis joined #parrot
04:34 Topic for #parrot is now Parrot 4.1.0 Released | http://parrot.org
04:37 alvis 'k. i, think, i've got this release done, except for two items:
04:38 alvis 1) i do not have administrative access to parrot.org to complete item IX.5. of the 'docs/project/release_manager_guide.pod' and
04:39 alvis 2) the copyright dates in 'docs/html/*.html' still report an ending date of 2011.
04:39 alvis on the former, i need someone to grant me access, and i'll fix it up ...
04:40 alvis and on the later, i'll write a script, hopefully, tomorrow -- though it may be later in the evening -- to fix it. to fix the)
04:41 alvis s/to fix the)//
04:59 particle joined #parrot
05:06 jsut joined #parrot
05:28 jsut_ joined #parrot
06:05 dalek nqp: 052bc4b | moritz++ | tools/build/PARROT_REVISION:
06:05 dalek nqp: bump parrot requirement to 4.1 release
06:05 dalek nqp: review: https://github.com/perl6/nqp/commit/052bc4b116
06:38 dngor joined #parrot
07:37 he joined #parrot
07:47 fperrad joined #parrot
07:54 preflex_ joined #parrot
08:24 mj41 joined #parrot
08:26 lucian joined #parrot
08:53 dngor_ joined #parrot
09:01 dngor joined #parrot
09:31 lucian joined #parrot
10:28 alin joined #parrot
11:01 particle joined #parrot
11:21 JimmyZ joined #parrot
11:57 pmichaud joined #parrot
11:58 PerlJam joined #parrot
12:01 Util joined #parrot
12:01 masak joined #parrot
12:01 Coke joined #parrot
12:15 tadzik joined #parrot
12:57 benabik joined #parrot
13:00 jsut joined #parrot
13:02 benabik o/ #parrot
13:35 dalek rakudo/macros2: 913dc7b | masak++ | src/ops/perl6.ops:
13:35 dalek rakudo/macros2: [perl6.ops] wrote a real comment
13:35 dalek rakudo/macros2:
13:35 dalek rakudo/macros2: moritz++ for noticing.
13:35 dalek rakudo/macros2: review: https://github.com/rakudo/rakudo/commit/913dc7b513
14:33 PacoAir joined #parrot
14:45 dalek rakudo/macros2: 161f188 | masak++ | src/Perl6/Actions.pm:
14:45 dalek rakudo/macros2: [Perl6::Actions] fixed remaining two macro call types
14:45 dalek rakudo/macros2:
14:45 dalek rakudo/macros2: The recent stuff only worked for calling macros as terms.
14:45 dalek rakudo/macros2: Now it works for identifiers, terms, and ops.
14:45 dalek rakudo/macros2: review: https://github.com/rakudo/rakudo/commit/161f188b53
15:01 bluescreen joined #parrot
15:26 whiteknight joined #parrot
15:27 kj joined #parrot
15:31 benabik whiteknight: ping?
15:35 benabik msg whiteknight Love the introspection/PACT article.  I am, in fact, planning to apply for GSoC with that very topic.
15:35 aloha OK. I'll deliver the message.
15:46 dmalcolm joined #parrot
15:48 Psyche^ joined #parrot
16:07 whiteknight benabik: perfect!
16:07 whiteknight benabik: I was hoping you would be in this year. I think that PACT has enough space for at least two non-overlapping projects
16:08 whiteknight but if we had you working on it in dedicated fasion, that would be awesome
16:08 benabik The "non-overlapping" bit might be interesting.
16:08 whiteknight if we can come to some basic agreements about what an Opcode PMC is going to look like, multiple people can build tools and interactions with that common interface
16:09 whiteknight and if we had that, a single mentor could easily cover two projects, which is good considering the lack of mentors we had last year
16:09 benabik I'd love to be able to build upwards to the CFG level by September.
16:09 whiteknight that would be unbelievable
16:09 whiteknight That chart was just off the top of my head. I'm not certain that AST->CFG is a step that is necessary for a compiler
16:10 whiteknight but being able to construct a CFG at some point would be a big help for analysis
16:13 whiteknight we could just as easily serialize AST->Op stream
16:13 benabik The most reasonable (IMnoHO) front end for a generic compiler backend is a CFG.
16:14 whiteknight okay, it is perfectly fine too if that's what you want.
16:14 benabik Providing a generic AST level syntax is really just trying to make people's lives easier.
16:14 benabik But languages trying to do more interesting things may need more interesting ASTs.
16:14 whiteknight If we have a generic AST and a generic CFG step and then transformations all the way down to packfiles, creating a new compiler is as easy as plugging in a parser and a runtime
16:15 benabik Yup.
16:15 whiteknight because if I have, say, a PHP parser written in PHP that generates its own AST, we need a stage to translate it's tree to our AST and then the engine takes care of the rest of it
16:16 benabik Or you can have a PHP AST -> CFG stage instead of going PHP AST -> PACT AST -> CFG.
16:16 whiteknight yeah, that's true. However you want to do the transformation
16:16 whiteknight if we have things like optimizers that only operate on the AST stage, it seems like a bad idea to cut that out
16:17 whiteknight dead code analysis will be easy at the CFG level, but certain other manipulations will happen much better in the AST
16:17 whiteknight and then some peephole optimizations will happen at the opcode/emitter level
16:17 benabik Dead code, constant folding, and more existing things can be done at CFG stages.
16:17 benabik Most compiler optimizations are designed at the CFG level.
16:18 whiteknight Okay, so it seems like the CFG is something that's going to be very central
16:18 benabik I'd think that AST optimizations would really be more macroish thing.  "This AST node actually means this more complicated thing"
16:18 benabik Maybe some basic re-ordering, elimination, etc.
16:18 whiteknight AST level might be more suited for things like macro substitution than optimization then
16:18 benabik But my vision was that everything essential could be done at the CFG level.
16:19 whiteknight ...which would be an amazingly awesome thing to offer out of the box
16:19 benabik Basically, I want to port Hoopl to parrot.
16:19 whiteknight okay
16:19 whiteknight That's as good a design as any
16:20 benabik I like any papers called "Complicated thing made simple"
16:20 whiteknight :)
16:20 dalek rakudo/match-refactor: dd27465 | moritz++ | src/core/Int.pm:
16:20 dalek rakudo/match-refactor: fix signature of an infix:<!=> candidate. No idea if it makes any difference
16:20 dalek rakudo/match-refactor: review: https://github.com/rakudo/rakudo/commit/dd27465036
16:21 benabik And by the time summer comes around I should have my head deep into things like data-flow analysis.
16:21 whiteknight awesome
16:21 benabik But I don't know if a summer is long enough to get that far upwards in the stack.  :-/
16:21 whiteknight yeah, that is the big question
16:22 whiteknight What if we had symbolic op PMCs already, and a serialization/deserialization mechanism for them beforehand?
16:23 whiteknight worded differently, are there any parts of the stack that you think we could and should provide before the summer, to give our GSOC students the most to latch on to
16:23 benabik Oh.  I think there's an opcode PMC already.  It has a lot of useful information, so you might want PACT.Opcode to just have a reference to it and the arguments.
16:23 whiteknight right, that's what I mean
16:24 whiteknight We have a PMC representing an Op. We don't have one representing the grouping of Op+args
16:24 benabik (Which I think would remove the oplib pointer from your article.)
16:24 whiteknight yeah, I was being unnecessarily verbose
16:24 whiteknight not all the readers are going to be as familiar with the system as the great and powerful benabil
16:24 whiteknight benabik*
16:24 benabik hah
16:27 benabik I suppose a basic set of Unit < Sub < Op classes would be a good start point.
16:28 benabik Even if serialization doesn't exist, it would split the job into serialization on the backend and generation on the front.
16:28 whiteknight that's two separate GSOC projects, in my mind
16:28 benabik The trick would be ensuring that those had everything they need at the beginning.
16:29 whiteknight serializing a stream of symbolic ops to packfile is not trivial,
16:29 benabik Yes.  Which is why I worried about getting from PBC all the way up to CFG in a summer.
16:30 benabik Deserialization somewhat exists already, so that could be used as an idea of "what do we need for the classes"
16:30 benabik Going from disarm.winxed to a PACT.Disassembler shouldn't be too much work.
16:30 * benabik knocks on wood.
16:30 whiteknight Okay, let's say that I put together an Instruction and InstructionSerializer PMC type to represent an Opcode+Args and write them to packfile. If we had that before the summer started, what would you be able to do with it?
16:31 whiteknight (If that's a part you're dieing to work on yourself, let me know)
16:32 benabik Well, if we had a _De_serializer and the classes it output, we could have a Serializer as it's own project.  I'd bet there are fun gotchas in that direction that deserialization doesn't have to worry about.
16:32 benabik Oh...
16:32 benabik If we just had something that dealt with a raw stream, you mean?
16:32 benabik Hm....
16:33 whiteknight My plan is to write up the basics as a single dynpmc group, so we would have  Instruction, InstructionSerializer and InstructionDeserializer PMCs in a single loadable library
16:33 whiteknight the serializer would take an Array of Instructions, and the deserializer woudl output the same
16:33 benabik As far as I can tell, it can all be done without more C-level support.
16:33 whiteknight maybe also taking pre-allocated register counts, pre-build constant tables, etc
16:34 whiteknight That's what I'm hoping. Accessing the raw packfile needs to be done in C, everything else can happen at higher levels
16:34 whiteknight and once we have a packfile, we already have tools to write it to file, to load and execute it, etc
16:35 benabik The point of my disasm PoC is that the C level stuff exists.  :-)  I'm pretty sure that the existing Packfile* classes have enough to work with.
16:35 benabik Although I suppose a cleaner interface could be built.  It's not really pretty.
16:35 benabik (Especially the writing side.)
16:38 benabik There are interesting hidden dependencies.
16:39 benabik If a basic serializer existed...  hmmm...
16:39 benabik If we created a basic serializer and a set of classes for a protocol, we could have a complex serializer as one project and a CFG as anothger.
16:40 whiteknight The Packfile* PMCs don't take a friendly interface for ops.
16:40 whiteknight A symbolic Instruction PMC would give us the ability to do round-trim asm/disasm
16:40 whiteknight round-trip
16:41 benabik True, they deal with raw integers which have to be translated in either direction.  Which can be done in-VM.
16:41 whiteknight The serializer might even be able to be written in winxed, if the Packfile PMCs are capable
16:41 whiteknight deserializer is definitely a C-level tool
16:41 benabik Oh?
16:42 benabik disasm.winxed seemed to be doing a pretty capable job.  The biggest gotcha I had left was Key PMCs being unfriendly to build and introspect.
16:43 whiteknight maybe. The system may be more capable than I expect
16:43 whiteknight I really do want the ability to introspect bytecode from an individual sub, Which we defintely don't have now
16:44 whiteknight Sub doesn't have any decent accessor for its bytecode
16:44 benabik The relation between Sub and bytecode is rather loose.
16:44 benabik Which is somewhat helpful, and somewhat not.
16:45 whiteknight The Sub basically has a pointer to bytecode, a start index and and length
16:45 whiteknight we need to be able to get that info back out
16:46 benabik Yes-ish.  I'm very curious what will happen if we have enough optimizations that subs have overlapping bytecode.
16:46 whiteknight We've talked about that a lot before. I think that's disallowed
16:47 whiteknight In any case, if we have a method that says "get me the bytecode for this sub" that sub can eventually be updated to assemble chunks or tease apart overlapping code
16:47 benabik I see no reason it should be.  A DFA with multiple entry points could be output as a sub per entry point where the guts all overlap.
16:47 benabik I'm not sure how often that would come up, but there's no technical reason why it wouldn't work.  :-D
16:48 whiteknight regardless, the abstraction for getting bytecode stands
16:49 benabik Here's what I'd do:
16:49 benabik 1) Build a bare-bones deserializer with the minimal-functional classes needed to represent existing PBCs.
16:49 benabik 2) Build a set of classes to represent PBCs in a "friendly" way.  This is the interface between:
16:49 benabik 3) A more competent serializer.  Handles register counting, constant pools, etc (GSoC?)
16:49 benabik 4) A CFG system that handles more interesting things like register allocation, variables, etc etc.
16:50 benabik Ooops.  I missed something in there...
16:50 benabik 2.5) A basic serializer that uses the classes from 1
16:50 whiteknight okay
16:51 benabik Step 3 is really "convert between the friendly and unfriendly classes"
16:51 benabik If 4 is done without 3, it would just need to do some very basic translation.
16:51 whiteknight yes, that's important. The nicer the interface is, the more people are going to happily use it
16:51 whiteknight We want to wrap the ugly guts in something pretty, and use the pretty where possible
16:52 whiteknight Ideally, what I would like is this: A function that takes (An array of Instructions, an array of PMC constants, an array of String constants, Integers, Floats) and outputs a bytecode
16:52 benabik Right.
16:53 whiteknight If the Instructions contained optional metadata like debug symbols or annotations, those could be added in too
16:53 whiteknight or if we had some null-Instructions which represented annotations but didn't generate actual opcodes, that would work too
16:53 whiteknight whichever
16:53 whiteknight brb, food
16:53 benabik ditto.
17:30 benabik bak
17:30 whiteknight awesome
17:42 whiteknight I think what we want really is an InstructionBlock, which has a name, number of used registers, and an array of opcodes. An array of InstructionBlocks represents a packfile
17:42 whiteknight a single InstructionBlock represents a Sub
17:43 whiteknight var pf = new 'Packfile'; for (var ib in blocks) block.add_to(pf); return self.assemble_packfile(pf, constants, etc)
17:44 whiteknight and to compile a single sub, essentially, we would do this:
17:44 benabik Why label it InstructionBlock instead of Sub? (or SomethingSub or SubSomething)
17:44 whiteknight We already have Sub, and in reality it's not a sub because you can't directly execute it
17:44 whiteknight InstructionBlock is more like SubBuilder than Sub
17:44 benabik Right.
17:45 whiteknight Actually a number of problems in our system stem from the fact that we use the same type to be a Sub as we use to build and serialize a Sub
17:45 benabik Clear introspection requires clear abstractions.
17:45 whiteknight right, and if Sub is anything, it's muddled
17:45 benabik :-D
17:46 benabik Hopefully building clear introspection will help with clear abstractions.
17:47 whiteknight it will be a big motivator
17:47 whiteknight My sincere goal is to build up the abstractions we need so that we can start cleaning the internals with some protection over our heads
17:47 benabik +1k
17:48 whiteknight as far as I am concerned, the Sub should be a simple, read-only wrapper around an invokable chunk of bytecode. Inherently it shouldn't be anything more than that
17:48 benabik brb
17:48 whiteknight The Sub shouldn't have a name associated with it, it shouldn't have namespace info, it shouldn't have multisig info, it shouldn't have anything like that. It's just invokable bytecode
17:49 whiteknight And so instead of having to subclass Sub to get it to do what you want or stop doing what you don't want, you just write a wrapper for it and use that
17:50 whiteknight because Sub is a fundamental core component and should be one of the least magical and least unpredictable things in the system
17:51 whiteknight Then a NameSpace becomes a hash of name->Sub pairs. A multisub becomes a lookup of Sig->Sub Pairs, a Closure becomes a tuple of (Sub,Context) without needing any clones
17:52 whiteknight Coroutine is a wrapper with a Sub, a Context and a state flag. A method is just a Sub in a name->Sub hash inside the metaobject
17:52 whiteknight but that's off the topic a little
17:53 whiteknight If I have a single Sub and I want to store it in a namespace under multiple names, or in a MultiSub under multiple Sigs, I should be allowed to do that and right now you can't
18:00 dngor joined #parrot
18:04 benabik Back again.
18:04 benabik whiteknight: 100% agreed, really.
18:06 benabik Oh!  The most core thing needed to get this working is reasonable in-VM introspection and creation of Key objects.  They're pretty magical at the moment and I don't see a reasonable way to deal with them.
18:11 benabik work &
18:12 lucian joined #parrot
18:17 benabik back
18:17 zack_s joined #parrot
18:18 whiteknight okay, we can work on Key objects
18:19 whiteknight they're linked lists, in case that helps
18:19 benabik I know what they are, there's just limited/no creation or introspection of them.
18:19 whiteknight What kinds of operations do you want to do on them?
18:19 benabik IIRC, there's no way to create a new one in-VM.  That's done solely by IMCC.
18:20 benabik And I'd like to be able to introspect them without them trying to access registers that don't exist.
18:20 whiteknight https://github.com/Whiteknight/parrot-linear-algeb​ra/blob/master/t/testlib/matrixtestfactory.nqp#L7
18:20 whiteknight you can make them in-VM, it's just a nightmare
18:20 benabik What about int register keys?
18:21 benabik Really it's keys with register types that are the problem.
18:21 whiteknight oh, okay. You're right we can't really do anything with those
18:21 benabik And they're required for constructs like `$P0[$I0] = $S0`
18:21 whiteknight yes
18:25 whiteknight https://github.com/parrot/parrot/issues/717
18:26 benabik whiteknight++
18:26 whiteknight feel free to add any details to that ticket that you think are worth remembering
18:28 benabik Just added a note about introspection as well.
18:29 aloha (parrot/parrot) Issues opened : 717 (Need a way to make register-ref Keys from PIR) by Whiteknight : https://github.com/parrot/parrot/issues/717
18:31 dngor joined #parrot
18:37 whiteknight I've added a "PACT" label for tickets on github
18:37 whiteknight If you think of anything else, make a ticket, give it that label and assign it to me
18:37 benabik Cool.
18:39 aloha (parrot/parrot) Issues closed : 426 ([LHF] Add tests for Plumage's Util.nqp) by japhb : https://github.com/parrot/parrot/issues/426
18:41 cotto ~~
18:52 whiteknight hello cotto
18:53 whiteknight I've cleaned up some of the labels in the issue tracker
18:53 whiteknight now we just need a consistent scheme for color-coding them and we're set
19:02 kid51 joined #parrot
19:10 aloha (parrot/parrot) Issues closed : 344 (FileHandle .puts and .print) by Whiteknight : https://github.com/parrot/parrot/issues/344
19:29 dmalcolm joined #parrot
19:33 whiteknight funny/depressing article about kakapo (the birds): http://io9.com/5886679/this-is-the-worst-r​eproductive-strategy-in-the-animal-kingdom
19:36 mj41 joined #parrot
19:39 benabik That's really strange.
19:43 whiteknight it's highly adapted to a specific environment: Where there are no natural predators and where nutrient-rich food is sparse most years
19:44 benabik "... this also might be why more males survived in the wild. Using the claws to try to mate with a cat is still better than just freezing up and hoping the cat loses interest."
19:47 whiteknight sounds like a guy I knew a while back who joined the army
19:47 PerlJam he used his claws to mate with a cat?
19:47 whiteknight it wouldn't surprise me
20:13 bluescreen joined #parrot
20:24 kid51 joined #parrot
20:25 perlite_ joined #parrot
20:44 contingencyplan joined #parrot
20:44 contingencyplan_ joined #parrot
20:59 autark joined #parrot
21:20 dngor_ joined #parrot
21:21 zby_home joined #parrot
21:25 dngor joined #parrot
21:28 dalek nqp: 7b8137f | moritz++ | / (3 files):
21:28 dalek nqp: implement :$var colonpair syntax
21:28 dalek nqp:
21:28 dalek nqp: Also adds a single test.
21:28 dalek nqp: review: https://github.com/perl6/nqp/commit/7b8137fb91
22:10 alin joined #parrot
22:26 lucian joined #parrot
22:58 jsut_ joined #parrot
23:41 davidfetter joined #parrot

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

Parrot | source cross referenced