Camelia, the Perl 6 bug

IRC log for #parrot, 2012-04-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 nbrown_ whiteknight: thanks, I'll be sure to ask them next time I see them
00:01 nbrown_ I just read it after I'd used signed integer types and was wondering if I should got change them to unsigned types
00:01 nbrown_ *go
00:07 whiteknight allison: ping
00:08 allison whiteknight: pong
00:08 whiteknight allison: We've got a GSOC student interested in security sandboxing. Do you have any particular ideas for such a thing?
00:09 allison whiteknight: yes, there's a few different pieces
00:09 allison subclassing NameSpace is one simple one
00:09 whiteknight allison: I knew you were a good person to ask :)
00:09 allison and protected execution contexts is another
00:10 allison (where code can only modify variables from the current context)
00:11 whiteknight Do we want to do that at the Context level, or do we want it at the interp level and spawn child interps?
00:12 whiteknight eventually I'd love to delete the NameSpace PMC, so projects involving subclassing it don't excite me too much :(
00:14 allison The interp level is good for a sandbox that uses no external libraries.
00:15 allison So, would be interesting to work on exactly what the sandboxed interp has access to outside of its own environment.
00:16 allison Another aspect is restricting what libraries can be loaded.
00:16 allison And restricting what ops can be run.
00:16 allison (Like, no file I/O or network access may be desirable.)
00:17 allison I wouldn't suggest tackling the whole array of sandboxing in one GSOC project.
00:17 whiteknight no, we're going to try for something modular. I suspect we'll get some fundamentals done but not much else
00:18 allison Aye. Like pick one aspect or feature with a clear set of implementation tasks and deliver that.
00:18 whiteknight I'm thinking we make a SecurityContext structure and attach it to the interp, then we can check certain flags and fields to determine if certain operations are acceptable
00:18 allison That could work.
00:19 whiteknight unless you have a better idea
00:19 allison There'd have to be no way to edit the Security Context from within the sandboxed interp.
00:20 allison Any data structure for marking the current execution as "secured", and for attributes on what kind of restrictions are in place, would be fine.
00:21 allison The biggest headache will be catching all the places where code might slip out of the sandbox.
00:21 whiteknight There are so many ways we could go about doing this
00:22 allison At this point, Parrot is largely about an implicit contract about how things are done.
00:22 allison It doesn't prevent you from doing things outside the norm, it just provides no guarantees about what might happen.
00:23 allison With a security sandbox, it's a complete reversal. It permits a tiny set of allowed activities, and makes anything outside that set impossible.
00:24 allison I suggest taking a look at apparmor for inspiration.
00:24 whiteknight so if we have a security context that can be set from Parrot_interp_new, but can't be modified by that interp at all, that would be a decent start?
00:25 whiteknight I mean, the student is going to have to put together a proposal in 5 days, so I want something that is straight-forward and uncontroversial because we won't have lots of time to think it through before we get sort of set on a particular path
00:25 whiteknight Even if it's unnecessarily simple at first
00:26 whiteknight if we share that same structure on the context, and the context by default inherits from the parent interp but can be made more restrictive would that be good?
00:27 allison yes, that seems like a good start
00:28 whiteknight then we can do bit flags for certain classes of operations, and lists for things like path white and black lists for loading and FileHandle operations, etc?
00:30 whiteknight (I haven't spent nearly so much time thinking about security as I have about other roadmap items)
00:30 dalek joined #parrot
00:33 benabik Hopefully even if I don't work on 6model, my proposal is good food for thought for someone else to implement.
00:40 benabik Puffin was the Python on Parrot project from last summer, right?
00:44 whiteknight yes
00:46 plobsing joined #parrot
00:55 benabik This proposal is much harder to write.  Not surprising given that I haven't spent the last 8 months thinking about it.
00:58 aloha (parrot/parrot) Issues closed : 453 ([RFC] Deprecate Eval PMC) by allisonrandal : https://github.com/parrot/parrot/issues/453
01:03 whiteknight hmm... it doesn't say who closed the ticket
01:16 whiteknight it's about time for me to get too bed. I need some rest after the productive weekend
01:18 Justin joined #parrot
01:19 Justin hello
01:20 d4l3k_ joined #parrot
01:30 mdupont joined #parrot
01:38 aloha (parrot/parrot) Issues opened : 753 (M0 c new ops) by nbrown : https://github.com/parrot/parrot/issues/753
01:54 benabik Alright.  6model proposal submitted.
01:56 benabik As mentioned, that proposal is not as well thought out as the PACT one.  Not entirely sure how well that plan will survive contact with the enemy.
02:01 Justin fast
02:02 benabik I have the advantage of understanding the projects already.
02:11 dalek joined #parrot
02:26 dalek parrot/m0: 23c7154 | nbrown++ | src/m0/c/ (2 files):
02:26 dalek parrot/m0: Add a simplistic way to pass most of the *_n tests
02:26 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/23c71543df
02:26 dalek parrot/m0: c51c2c9 | nbrown++ | src/m0/c/m0_ops.c:
02:26 dalek parrot/m0: add the set op
02:26 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/c51c2c9674
02:26 dalek parrot/m0: 86b55be | nbrown++ | src/m0/c/m0_ops.c:
02:26 dalek parrot/m0: use int64_t pointers so that the convert functions handle negative numbers correctly
02:26 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/86b55be129
02:26 dalek parrot/m0: e21d417 | dukeleto++ | src/m0/c/ (2 files):
02:26 dalek parrot/m0: Merge pull request #753 from nbrown/m0-c-new-ops
02:26 dalek parrot/m0:
02:26 dalek parrot/m0: M0 c new ops
02:26 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/e21d417823
02:29 aloha (parrot/parrot) Issues closed : 753 (M0 c new ops) by nbrown : https://github.com/parrot/parrot/issues/753
03:01 dalek joined #parrot
03:39 nopaste joined #parrot
03:51 d4l3k_ joined #parrot
03:54 Justin left #parrot
04:17 kurahaupo joined #parrot
04:42 d4l3k_ joined #parrot
04:55 dalek parrot/m0: 2a1224a | jimmy++ | src/m0/c/m0_ops.c:
04:55 dalek parrot/m0: remove typecheck, it should be done by complie time(i.e: M1/PIR => M0), not in runtime. also removed duplicate function.
04:55 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/2a1224ab0f
05:33 d4l3k_ joined #parrot
06:25 d4l3k_ joined #parrot
06:34 Timbus joined #parrot
07:15 d4l3k_ joined #parrot
07:23 fperrad joined #parrot
07:46 cosimo joined #parrot
07:47 cosimo joined #parrot
07:54 cosimo joined #parrot
08:06 d4l3k_ joined #parrot
08:16 bacek joined #parrot
08:16 bacek ~~
08:17 tadzik hello bacek
08:17 moritz \o
08:17 bacek aloha tadzik, moritz
08:27 lucian joined #parrot
08:31 dalek rakudo/nom: d344e96 | moritz++ | src/core/Rat.pm:
08:31 dalek rakudo/nom: fix thinko in Int <=> Rat
08:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d344e96f6a
08:31 dalek rakudo/nom: 68e7f8f | moritz++ | src/Perl6/ (2 files):
08:31 dalek rakudo/nom: rename $=POD to $=pod
08:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/68e7f8ffed
08:57 d4l3k_ joined #parrot
09:36 schm00ster joined #parrot
09:50 d4l3k_ joined #parrot
09:56 schm00ster joined #parrot
10:10 JimmyZ joined #parrot
10:11 JimmyZ hello, #parrot
10:12 JimmyZ joined #parrot
10:15 benabik joined #parrot
10:21 __mayank joined #parrot
10:22 __mayank left #parrot
10:43 d4l3k_ joined #parrot
11:07 nbrown joined #parrot
11:10 nbrown_ joined #parrot
11:16 nbrown_ good morning parrot, is jimmy from github around?
11:17 nbrown_ I see that my commit last night wasn't current with respect to the m0 branch (oops) but I think the last commit is a mistake
11:17 nbrown_ It seems to revert some of the progress we were making on getting the m0 c implementation to pass the tests
11:19 nbrown_ I'm going to try to merge the two histories and get m0 passing tests again, but if someone else wants to take a look at the last couple of m0 commits and let me know if I'm totally off base, I'd really appreciate it
11:28 nbrown joined #parrot
11:35 d4l3k_ joined #parrot
11:37 nbrown upon a closer look at the recent commits by jimmy, I'm a little confused. There are 4 register types: INSP and I thought S & P were supposed to be treated like pointers while I & N were supposed to be treated like values.
11:39 nbrown jimmy seems to have treated all of them like pointers. Which is the correct interpretation of the spec?
11:39 benabik joined #parrot
11:40 dalek joined #parrot
11:40 nbrown msg: dukeleto can you look at my questions about the recent commits made by me and jimmy and tell me how to proceed?
11:40 nbrown msg dukeleto can you look at my questions about the recent commits made by me and jimmy and tell me how to proceed?
11:40 aloha OK. I'll deliver the message.
11:42 nbrown msg dukeleto the backlog begins at http://irclog.perlgeek.de/p​arrot/2012-04-02#i_5383487
11:42 aloha OK. I'll deliver the message.
11:44 JimmyZ hello nbrown
11:44 contingencyplan joined #parrot
11:45 JimmyZ nbrown: I'm here
11:45 nbrown JimmyZ: hello
11:45 nbrown JimmyZ: oh, I wasn't sure if you were jimmy from github
11:46 JimmyZ nbrown: yes, jimmy is me too
11:46 nbrown JimmyZ: awesome
11:46 nbrown JimmyZ: I was trying to make m0 work and was getting a little confused about your recent commits and my approach
11:48 JimmyZ nbrown: yes, m0 is controversial
11:48 nbrown JimmyZ: I thought that the integer and numeric register types were supposed to be treated as values and you seem to be treating them as pointers
11:48 JimmyZ nbrown: I want to treat them as values
11:49 JimmyZ nbrown: and I want to split them, instead of all in registers[256]
11:50 nbrown JimmyZ: so you're trying to do something more than just implement the spec as written?
11:50 JimmyZ nbrown: spec is not always right
11:51 JimmyZ nbrown: the consts doesn't have type flag
11:51 nbrown JimmyZ: I know it's not always right, but I was trying to implement it as close to the spec as possible to identify where it was wrong
11:51 nbrown JimmyZ: I'm not sure that consts need one
11:51 JimmyZ and so does deref
11:52 JimmyZ nbrown: but deref needs to know
11:52 nbrown JimmyZ: my code handled that assuming that user only used floating point consts with floating point registers, integer with integer, etc
11:53 moritz which is very reasonable for something as low-level as m0
11:53 nbrown exactly
11:54 d4l3k_ joined #parrot
11:54 JimmyZ nbrown: my code something likes '*(double *)' is wrong too, and I'm working hard to change it
11:55 nbrown JimmyZ: that's actually going to be required to treat the uint64_t register correctly when doing numeric math
11:56 nbrown JimmyZ: well, something like it
11:56 nbrown JimmyZ: the problem is you're treating the uint64_t regester like it's a uint64_t*
11:57 JimmyZ nbrown: yes, it's wrong, and I'm working hard to change it
11:57 nbrown yes, but I'm not sure how it applies to this conversation
11:58 nbrown JimmyZ: from my perspective, your email wants to change some of the m0 design fundamentals laid out in the spec. I just want to implement them
11:59 nbrown JimmyZ: is that a fair assessment?
12:00 JimmyZ nbrown: currently, M0 is more like stack based, we can't do 'add_i I3, 1234, 3566', we must use set_imm, and I want to change it.
12:01 JimmyZ nbrown: parrot is register based , and I want to borrow things like regs which handles INSP from parrot.
12:01 nbrown JimmyZ: that's fine, but it will still need to support 'add_i I3, I1, I3', right?
12:02 nbrown JimmyZ: How will you borrow that from parrot?
12:03 JimmyZ nbrown: yes, and M0 doesn't do any type check at runtime, that should be done by compile time.
12:04 JimmyZ nbrown: But I hope M0 don't lose type info, that is, strong type。
12:05 nbrown JimmyZ: and that's a fine argument, but if you look at the 'bug' you fixed in add_i, I think you set the result register to the address of the result and not the result itself
12:05 JimmyZ nbrown: https://github.com/parrot/parrot/blob​/master/include/parrot/context.h#L15
12:05 nbrown that's my issue with your commits
12:05 JimmyZ nbrown: that's what I want to borrow
12:07 JimmyZ nbrown: yes, because M0 lose type info at the beginning, and I want to add it.
12:08 nbrown JimmyZ: but you're still storing an address and not the result. Isn't that the definition of storing a pointer and not a value?
12:08 JimmyZ nbrown: so add_i and add_n will use value directly eventually。
12:08 nbrown My commits did that now
12:08 nbrown JimmyZ: I don't understand why you want to borrow that union
12:08 nbrown JimmyZ: I thought m0 strings were a simpler thing
12:09 JimmyZ nbrown: for example:
12:14 JimmyZ m0_op_mod_iII {  frame->registers.i[ops[1]] = frame->registers.i[ops[2]] %  frame->registers.i[ops[3]]; }
12:14 JimmyZ m0_op_mod_iiI {  frame->registers.i[ops[1]] = frame->registers.i[ops[2]] %  [ops[3]; }
12:14 JimmyZ m0_op_mod_iii {  frame->registers.i[ops[1]] = ops[2] %  [ops[3]; }
12:14 JimmyZ m0_op_mod_nNN {  frame->registers.n[ops[1]] = frame->registers.n[ops[2]] %  frame->registers.n[ops[3]]; }
12:14 JimmyZ m0_op_mod_nNi {  frame->registers.n[ops[1]] = frame->registers.n[ops[2]] %  ops[3]; }
12:15 nbrown JimmyZ: ok, that would remove the pointer stuff I was doing
12:15 nbrown JimmyZ: but that deviates a bunch from the m0 spec
12:15 nbrown JimmyZ: you're changing the definition of the registers
12:15 JimmyZ nbrown: and frame->registers.n[ops[2]] = 233.55
12:16 JimmyZ nbrown: the spec tries to make M0 being stack based.
12:16 nbrown JimmyZ: I'd love to see your spec updates to show how you want to do all of this and get consensus
12:16 nbrown JimmyZ: so?
12:16 betterworld joined #parrot
12:16 JimmyZ nbrown:  parrot is register based :)
12:17 nbrown JimmyZ: actually, i don't see it as stack based
12:17 nbrown JimmyZ: the spec is register based in my mind
12:17 nbrown JimmyZ: the only stacks you see in the spec are the call frame stacks
12:18 nbrown JimmyZ: your proposed changes don't change that
12:18 nbrown JimmyZ: unless there's another piece that I'm missing
12:18 JimmyZ nbrown: parrot allows  something like 'add_i I3, 222, 666 '
12:18 JimmyZ nbrown: M0 must use set_imm every time now
12:19 nbrown JimmyZ: yes, but that doesn't make m0 stack based
12:19 nbrown JimmyZ: I'd love to continue this chat, but my oil change is done and I need to get to work
12:19 JimmyZ nbrown: but use 3 times op :)
12:20 nbrown JimmyZ: thanks for the chat. feel free to leave more messages, I will backlog
12:20 nbrown JimmyZ: ahhhh, you're true issue is that you want to be able to use immediate modes. That doesn't imply stack versus register in my mind
12:20 nbrown JimmyZ: have a great day and talk to you later
12:20 whiteknight joined #parrot
12:21 JimmyZ nbrown: thanks you too
12:22 whiteknight good morning, #parrot
12:23 JimmyZ good morning whiteknight, I just talked to nbrown, tell me if I was in the wrong way.
12:23 whiteknight JimmyZ: I'm not the M0 expert, you can say anything you want :)
12:26 PacoAir joined #parrot
12:27 jjore joined #parrot
12:27 dalek parrot/bacek/unmerge_context: c15e96a | bacek++ | / (44 files):
12:27 dalek parrot/bacek/unmerge_context: Readd CallSignature pmc and fix few build errors
12:27 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/c15e96ab1c
12:27 dalek parrot/bacek/unmerge_context: 8e9dff3 | bacek++ | compilers/imcc/imc (3 files):
12:27 dalek parrot/bacek/unmerge_context: Rebuild imcc
12:27 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/8e9dff368f
12:28 dalek parrot/bacek/unmerge_context: 5709296 | bacek++ | src/call/pcc.c:
12:28 dalek parrot/bacek/unmerge_context: Hack invoke_from_sig_object. It should be killed anyway imho
12:28 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/570929624b
12:28 dalek parrot/bacek/unmerge_context: 7bb3ef5 | bacek++ | src/ops/core_ops.c:
12:28 dalek parrot/bacek/unmerge_context: Ugly hack to enable build
12:28 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/7bb3ef5974
12:33 JimmyZ whiteknight: :)
12:36 whiteknight bacek++
12:43 d4l3k_ joined #parrot
13:14 JimmyZ joined #parrot
13:16 JimmyZ nbrown: yes, I want to use immediate modes, and remove type convention in most ops(i.e: add_i, add_n)
13:24 atrodo JimmyZ> From my understanding, that convention is of needing to use set_imm is also very prevalent in RISC
13:27 JimmyZ atrodo: I can't follow you. Do you mean that convertion in set_imm is very prevalent
13:28 JimmyZ atrodo: sorry, I don't know english well enough
13:29 atrodo JimmyZ> Well, my use of English isn't that well either... Yes, from my understanding, the use of memory pointers inside instructions is more CISC like then RISC
13:33 JimmyZ atrodo: I think I agree with you. I would like to reduce using pointers
13:33 JimmyZ bbl
13:33 d4l3k_ joined #parrot
13:34 lucian whiteknight: about GSoC, i don't know if i qualify, but i'd be willing to be a backup mentor
13:34 lucian whiteknight: for python/js projects
13:35 whiteknight lucian: You're not eligible to be a student anymore?
13:35 lucian whiteknight: i graduated last year, i'm working now
13:35 whiteknight lucian: Oh that's a shame. I'd have loved to see what you could accomplish given another summer
13:36 whiteknight lucian: But yes, you definitely qualify
13:36 lucian well if i get a better job, i might have some more free time
13:36 lucian and now i'm more jaded, so more willing to let others do work for me :)
13:37 lucian i'll add myself to some tasks at https://github.com/parrot/parrot​/wiki/Summer-of-Code-Task-Ideas
13:37 lucian or rather, one i think
13:39 lucian whiteknight: i added myself just to jaesop, hope that isn't intruding on your pet project
13:39 whiteknight oh no, that's perfectly fine!
13:40 moritz having a backup mentor increases the chances for that project
13:40 moritz so not an intrusion at all
13:40 whiteknight I don't want it to be just my project, I would love for other people to get involved eventually
13:40 lucian ok, i've requested to be a mentor on melange as well
13:46 whiteknight awesome, thanks
13:46 whiteknight lucian
13:46 whiteknight lucian++
13:47 * moritz would love to see the 6model-in-core proposal by benabik++ getting sponsored
13:47 moritz though his other proposal is good too
13:47 moritz ETOOMANYGOODCHOICES
13:48 lucian i'd like to see that happen, but don't have the skills to help
13:48 lucian i don't know perl or nqp at all, and i don't know C very well either
13:56 whiteknight I haven't heard any python-related projects this year, unfortunately
13:56 whiteknight Without 6model, I worry that any python work is a non-starter
13:57 whiteknight Ruby is the same way
13:57 whiteknight If benabik doesn't do 6model over the summer, I will
14:00 JimmyZ it gives me an impression that 6model  will make parrot more simple, and M0 will be dead.
14:00 moritz I'd rather hope that 6model will make M0 easier to do
14:02 whiteknight no, 6model and M0 are not enemies
14:03 whiteknight they will help each other
14:06 * moritz imagines several parrot subystems being at war with each other, and then realizes that this might be surprisingly close to reality
14:07 Coke PARROT ROYALE
14:11 whiteknight it's mostly GC versus all the other systems which allocate too much memory
14:12 moritz and namespaces and IMCC vs. sanity
14:13 moritz subs vs. Priniciple of Least Surprise
14:13 whiteknight When Parrot has 6model, killing namespaces is one of the next highest priorities on my list
14:15 nine Kill it! Kill it dead!
14:15 whiteknight srsly
14:17 dalek parrot/m0: 3c62ec9 | jimmy++ | / (3 files):
14:17 dalek parrot/m0: borrow Regs struct from parrot, break M0 test now
14:17 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/3c62ec9385
14:17 dalek parrot/m0: 405d94d | jimmy++ | / (9 files):
14:17 dalek parrot/m0: Merge branch 'm0' of github.com:parrot/parrot into m0
14:17 dalek parrot/m0:
14:17 dalek parrot/m0: Conflicts:
14:17 dalek parrot/m0: src/m0/c/m0_ops.c
14:17 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/405d94d4d9
14:20 dalek parrot/m0: 9e8ddd7 | jimmy++ | src/m0/c/ (2 files):
14:20 dalek parrot/m0: remove unused code
14:20 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/9e8ddd78dc
14:25 d4l3k_ joined #parrot
14:37 dalek joined #parrot
15:04 dmalcolm joined #parrot
15:28 dalek joined #parrot
15:45 particle joined #parrot
16:02 benabik ...  My ears are burning.
16:03 tadzik what did you listen to?
16:03 whiteknight METAL
16:03 tadzik that would've been good I guess
16:06 Justin joined #parrot
16:07 benabik Have we really only had three proposals submitted?  I know I did two...  :-/  Although I guess there'll be a rush at the end of the week.  College students like submitting at the deadline.
16:08 whiteknight Yeah, the end of the week is when we get the most
16:08 Justin im working on mines now. good afternoon everyone
16:08 whiteknight that's certainly not all the students I've talked to or drafts that I've seen in personal email
16:08 whiteknight Good morning Justin
16:08 Justin i apologize about yesterday I tried to move to a different building before they closed early
16:09 whiteknight Justin: It's okay, people are in and out of here all day
16:20 dalek joined #parrot
16:26 benabik re: my proposals.  I'm happy working on either.  If people really want me working on 6model, I'll dig into it.  I personally think I'd be more productive on PACT, but wanted to have a second option in in case someone else wanted to pick that up.
16:27 whiteknight benabik: whichever you don't work on, I will work on. So it doesn't really matter :)
16:27 whiteknight benabik: so long as I can get your occasional feedback on the road not traveled, of course
16:28 benabik Off course.  I'd hoped that both could be taken as a roadmap for someone else to move along.  Feel free to crib notes off either to advice yourself or other students.  :-)
16:28 benabik Or to lambast me for not thinking something through.  That's always an option.
16:28 moritz then we should set benabik on PACT
16:29 moritz seems like the most productive road to me in that case
16:29 whiteknight moritz: that's my thinking. He's uniquely qualified for that
16:29 whiteknight I'm equally unqualified for both :)
16:29 benabik There are others interested in that project, so I didn't want to force anyone off of it.
16:29 whiteknight benabik: no, nobody else has expressed a serious interest in it yet
16:30 _mayank joined #parrot
16:33 benabik Well, in case there is.  :-)  While I'm tempted to declare PACT my precious and boot everyone off so that I can peruse my vision, if any other people are interested in it, I'm happy to let them and just try to back seat drive.  :-)
16:44 jjore_ joined #parrot
17:11 dalek joined #parrot
17:18 lucian_ joined #parrot
17:30 Justin joined #parrot
18:02 d4l3k_ joined #parrot
18:03 Justin joined #parrot
18:43 dalek joined #parrot
18:44 tadzik joined #parrot
18:48 Coke joined #parrot
18:48 PerlJam joined #parrot
18:48 pmichaud joined #parrot
18:48 masak joined #parrot
18:53 dalek joined #parrot
18:53 Util joined #parrot
18:58 mtk joined #parrot
19:11 dalek joined #parrot
19:15 tadzik joined #parrot
19:16 masak joined #parrot
19:16 pmichaud joined #parrot
19:16 PerlJam joined #parrot
19:16 Coke joined #parrot
19:18 mtk joined #parrot
19:22 Util joined #parrot
19:25 mtk joined #parrot
19:41 dalek rakudo/nom: 8ead1e8 | jonathan++ | src/Perl6/Metamodel/BaseType.pm:
19:41 dalek rakudo/nom: Enable parents to handle :excl and :all options for things that compose BaseType. Fixes .^methods on enums bustage.
19:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8ead1e8cfd
19:50 Justin joined #parrot
19:51 Justin left #parrot
19:51 Justin joined #parrot
19:55 lucian_ joined #parrot
21:50 cotto ~~
22:35 kid51 joined #parrot
23:17 Justin joined #parrot
23:26 kurahaupo joined #parrot
23:43 benabik ~~
23:44 nbrown joined #parrot
23:48 nbrown cotto: are you around? I'd like to chat about m0
23:49 whiteknight joined #parrot
23:55 whiteknight good evening, #parrot
23:56 nbrown good evening
23:56 benabik o/ whiteknight

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

Parrot | source cross referenced