Parrot 4.2.0 "Ornithopter" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 21 March 2012.
nbrown_ whiteknight: thanks, I'll be sure to ask them next time I see them 00:00
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
*go
whiteknight allison: ping 00:07
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?
allison whiteknight: yes, there's a few different pieces 00:09
subclassing NameSpace is one simple one
whiteknight allison: I knew you were a good person to ask :)
allison and protected execution contexts is another
(where code can only modify variables from the current context) 00:10
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:11
eventually I'd love to delete the NameSpace PMC, so projects involving subclassing it don't excite me too much :( 00:12
allison The interp level is good for a sandbox that uses no external libraries. 00:14
So, would be interesting to work on exactly what the sandboxed interp has access to outside of its own environment. 00:15
Another aspect is restricting what libraries can be loaded. 00:16
And restricting what ops can be run.
(Like, no file I/O or network access may be desirable.)
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
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
allison That could work.
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.
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:20
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
allison At this point, Parrot is largely about an implicit contract about how things are done. 00:22
It doesn't prevent you from doing things outside the norm, it just provides no guarantees about what might happen.
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:23
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?
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
Even if it's unnecessarily simple at first
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:26
allison yes, that seems like a good start 00:27
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:28
(I haven't spent nearly so much time thinking about security as I have about other roadmap items) 00:30
00:30 dalek joined
benabik Hopefully even if I don't work on 6model, my proposal is good food for thought for someone else to implement. 00:33
Puffin was the Python on Parrot project from last summer, right? 00:40
whiteknight yes 00:44
00:46 plobsing joined
benabik This proposal is much harder to write. Not surprising given that I haven't spent the last 8 months thinking about it. 00:55
aloha (parrot/parrot) Issues closed : 453 ([RFC] Deprecate Eval PMC) by allisonrandal : github.com/parrot/parrot/issues/453 00:58
whiteknight hmm... it doesn't say who closed the ticket 01:03
it's about time for me to get too bed. I need some rest after the productive weekend 01:16
01:18 Justin joined
Justin hello 01:19
01:20 d4l3k_ joined 01:30 mdupont joined
aloha (parrot/parrot) Issues opened : 753 (M0 c new ops) by nbrown : github.com/parrot/parrot/issues/753 01:38
benabik Alright. 6model proposal submitted. 01:54
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. 01:56
Justin fast 02:01
benabik I have the advantage of understanding the projects already. 02:02
02:11 dalek joined
dalek rrot/m0: 23c7154 | nbrown++ | src/m0/c/ (2 files):
Add a simplistic way to pass most of the *_n tests
 02:26
rrot/m0: c51c2c9 | nbrown++ | src/m0/c/m0_ops.c:
add the set op
rrot/m0: 86b55be | nbrown++ | src/m0/c/m0_ops.c:
use int64_t pointers so that the convert functions handle negative numbers correctly
rrot/m0: e21d417 | dukeleto++ | src/m0/c/ (2 files):
Merge pull request #753 from nbrown/m0-c-new-ops

M0 c new ops
aloha (parrot/parrot) Issues closed : 753 (M0 c new ops) by nbrown : github.com/parrot/parrot/issues/753 02:29
03:01 dalek joined 03:39 nopaste joined 03:51 d4l3k_ joined 03:54 Justin left 04:17 kurahaupo joined 04:42 d4l3k_ joined
dalek rrot/m0: 2a1224a | jimmy++ | src/m0/c/m0_ops.c:
remove typecheck, it should be done by complie time(i.e: M1/PIR => M0), not in runtime. also removed duplicate function.
 04:55
05:33 d4l3k_ joined 06:25 d4l3k_ joined 06:34 Timbus joined 07:15 d4l3k_ joined 07:23 fperrad joined 07:46 cosimo joined 07:47 cosimo joined 07:54 cosimo joined 08:06 d4l3k_ joined 08:16 bacek joined
bacek ~~ 08:16
tadzik hello bacek 08:17
moritz \\o
bacek aloha tadzik, moritz
08:27 lucian joined
dalek kudo/nom: d344e96 | moritz++ | src/core/Rat.pm:
fix thinko in Int <=> Rat
 08:31
kudo/nom: 68e7f8f | moritz++ | src/Perl6/ (2 files):
rename $=POD to $=pod
08:57 d4l3k_ joined 09:36 schm00ster joined 09:50 d4l3k_ joined 09:56 schm00ster joined 10:10 JimmyZ joined
JimmyZ hello, #parrot 10:11
10:12 JimmyZ joined 10:15 benabik joined 10:21 __mayank joined 10:22 __mayank left 10:43 d4l3k_ joined 11:07 nbrown joined 11:10 nbrown_ joined
nbrown_ good morning parrot, is jimmy from github around? 11:16
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
It seems to revert some of the progress we were making on getting the m0 c implementation to pass the tests
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:19
11:28 nbrown joined 11:35 d4l3k_ joined
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:37
jimmy seems to have treated all of them like pointers. Which is the correct interpretation of the spec? 11:39
11:39 benabik joined 11:40 dalek joined
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
msg dukeleto can you look at my questions about the recent commits made by me and jimmy and tell me how to proceed?
aloha OK. I'll deliver the message.
nbrown msg dukeleto the backlog begins at irclog.perlgeek.de/parrot/2012-04-02#i_5383487 11:42
aloha OK. I'll deliver the message.
JimmyZ hello nbrown 11:44
11:44 contingencyplan joined
JimmyZ nbrown: I'm here 11:45
nbrown JimmyZ: hello
JimmyZ: oh, I wasn't sure if you were jimmy from github
JimmyZ nbrown: yes, jimmy is me too 11:46
nbrown JimmyZ: awesome
JimmyZ: I was trying to make m0 work and was getting a little confused about your recent commits and my approach
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
JimmyZ nbrown: I want to treat them as values
nbrown: and I want to split them, instead of all in registers[256] 11:49
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
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
JimmyZ: I'm not sure that consts need one
JimmyZ and so does deref
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
moritz which is very reasonable for something as low-level as m0 11:53
nbrown exactly
11:54 d4l3k_ joined
JimmyZ nbrown: my code something likes '*(double *)' is wrong too, and I'm working hard to change it 11:54
nbrown JimmyZ: that's actually going to be required to treat the uint64_t register correctly when doing numeric math 11:55
JimmyZ: well, something like it 11:56
JimmyZ: the problem is you're treating the uint64_t regester like it's a uint64_t*
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
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:58
JimmyZ: is that a fair assessment? 11:59
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:00
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?
JimmyZ: How will you borrow that from parrot? 12:02
JimmyZ nbrown: yes, and M0 doesn't do any type check at runtime, that should be done by compile time. 12:03
nbrown: But I hope M0 don't lose type info, that is, strong type怂 12:04
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: github.com/parrot/parrot/blob/mast...text.h#L15
nbrown that's my issue with your commits
JimmyZ nbrown: that's what I want to borrow
nbrown: yes, because M0 lose type info at the beginning, and I want to add it. 12:07
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怂
nbrown My commits did that now
JimmyZ: I don't understand why you want to borrow that union
JimmyZ: I thought m0 strings were a simpler thing
JimmyZ nbrown: for example: 12:09
m0_op_mod_iII { frame->registers.i[ops[1]] = frame->registers.i[ops[2]] % frame->registers.i[ops[3]]; } 12:14
m0_op_mod_iiI { frame->registers.i[ops[1]] = frame->registers.i[ops[2]] % [ops[3]; }
m0_op_mod_iii { frame->registers.i[ops[1]] = ops[2] % [ops[3]; }
m0_op_mod_nNN { frame->registers.n[ops[1]] = frame->registers.n[ops[2]] % frame->registers.n[ops[3]]; }
m0_op_mod_nNi { frame->registers.n[ops[1]] = frame->registers.n[ops[2]] % ops[3]; }
nbrown JimmyZ: ok, that would remove the pointer stuff I was doing 12:15
JimmyZ: but that deviates a bunch from the m0 spec
JimmyZ: you're changing the definition of the registers
JimmyZ nbrown: and frame->registers.n[ops[2]] = 233.55
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
JimmyZ: so?
12:16 betterworld joined
JimmyZ nbrown: parrot is register based :) 12:16
nbrown JimmyZ: actually, i don't see it as stack based 12:17
JimmyZ: the spec is register based in my mind
JimmyZ: the only stacks you see in the spec are the call frame stacks
JimmyZ: your proposed changes don't change that 12:18
JimmyZ: unless there's another piece that I'm missing
JimmyZ nbrown: parrot allows something like 'add_i I3, 222, 666 '
nbrown: M0 must use set_imm every time now
nbrown JimmyZ: yes, but that doesn't make m0 stack based 12:19
JimmyZ: I'd love to continue this chat, but my oil change is done and I need to get to work
JimmyZ nbrown: but use 3 times op :)
nbrown JimmyZ: thanks for the chat. feel free to leave more messages, I will backlog 12:20
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
JimmyZ: have a great day and talk to you later
12:20 whiteknight joined
JimmyZ nbrown: thanks you too 12:21
whiteknight good morning, #parrot 12:22
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 12:27 jjore joined
dalek rrot/bacek/unmerge_context: c15e96a | bacek++ | / (44 files):
Readd CallSignature pmc and fix few build errors
 12:27
rrot/bacek/unmerge_context: 8e9dff3 | bacek++ | compilers/imcc/imc (3 files):
Rebuild imcc
rrot/bacek/unmerge_context: 5709296 | bacek++ | src/call/pcc.c:
Hack invoke_from_sig_object. It should be killed anyway imho
 12:28
rrot/bacek/unmerge_context: 7bb3ef5 | bacek++ | src/ops/core_ops.c:
Ugly hack to enable build
JimmyZ whiteknight: :) 12:33
whiteknight bacek++ 12:36
12:43 d4l3k_ joined 13:14 JimmyZ joined
JimmyZ nbrown: yes, I want to use immediate modes, and remove type convention in most ops(i.e: add_i, add_n) 13:16
atrodo JimmyZ> From my understanding, that convention is of needing to use set_imm is also very prevalent in RISC 13:24
JimmyZ atrodo: I can't follow you. Do you mean that convertion in set_imm is very prevalent 13:27
atrodo: sorry, I don't know english well enough 13:28
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:29
JimmyZ atrodo: I think I agree with you. I would like to reduce using pointers 13:33
bbl
13:33 d4l3k_ joined
lucian whiteknight: about GSoC, i don't know if i qualify, but i'd be willing to be a backup mentor 13:34
whiteknight: for python/js projects
whiteknight lucian: You're not eligible to be a student anymore? 13:35
lucian whiteknight: i graduated last year, i'm working now
whiteknight lucian: Oh that's a shame. I'd have loved to see what you could accomplish given another summer
lucian: But yes, you definitely qualify 13:36
lucian well if i get a better job, i might have some more free time
and now i'm more jaded, so more willing to let others do work for me :)
i'll add myself to some tasks at github.com/parrot/parrot/wiki/Summ...Task-Ideas 13:37
or rather, one i think
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!
moritz having a backup mentor increases the chances for that project 13:40
so not an intrusion at all
whiteknight I don't want it to be just my project, I would love for other people to get involved eventually
lucian ok, i've requested to be a mentor on melange as well
whiteknight awesome, thanks 13:46
lucian
lucian++
moritz would love to see the 6model-in-core proposal by benabik++ getting sponsored 13:47
though his other proposal is good too
ETOOMANYGOODCHOICES
lucian i'd like to see that happen, but don't have the skills to help 13:48
i don't know perl or nqp at all, and i don't know C very well either
whiteknight I haven't heard any python-related projects this year, unfortunately 13:56
Without 6model, I worry that any python work is a non-starter
Ruby is the same way 13:57
If benabik doesn't do 6model over the summer, I will
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
whiteknight no, 6model and M0 are not enemies 14:02
they will help each other 14:03
moritz imagines several parrot subystems being at war with each other, and then realizes that this might be surprisingly close to reality 14:06
Coke PARROT ROYALE 14:07
whiteknight it's mostly GC versus all the other systems which allocate too much memory 14:11
moritz and namespaces and IMCC vs. sanity 14:12
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
nine Kill it! Kill it dead! 14:15
whiteknight srsly
dalek rrot/m0: 3c62ec9 | jimmy++ | / (3 files):
borrow Regs struct from parrot, break M0 test now
 14:17
rrot/m0: 405d94d | jimmy++ | / (9 files):
Merge branch 'm0' of github.com:parrot/parrot into m0

Conflicts:
  \tsrc/m0/c/m0_ops.c
rrot/m0: 9e8ddd7 | jimmy++ | src/m0/c/ (2 files):
remove unused code
 14:20
14:25 d4l3k_ joined 14:37 dalek joined 15:04 dmalcolm joined 15:28 dalek joined 15:45 particle joined
benabik ... My ears are burning. 16:02
tadzik what did you listen to? 16:03
whiteknight METAL
tadzik that would've been good I guess
16:06 Justin joined
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:07
whiteknight Yeah, the end of the week is when we get the most 16:08
Justin im working on mines now. good afternoon everyone
whiteknight that's certainly not all the students I've talked to or drafts that I've seen in personal email
Good morning Justin
Justin i apologize about yesterday I tried to move to a different building before they closed early
whiteknight Justin: It's okay, people are in and out of here all day 16:09
16:20 dalek joined
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:26
whiteknight benabik: whichever you don't work on, I will work on. So it doesn't really matter :) 16:27
benabik: so long as I can get your occasional feedback on the road not traveled, of course
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
Or to lambast me for not thinking something through. That's always an option.
moritz then we should set benabik on PACT
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
I'm equally unqualified for both :)
benabik There are others interested in that project, so I didn't want to force anyone off of it.
whiteknight benabik: no, nobody else has expressed a serious interest in it yet
16:30 _mayank joined
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:33
16:44 jjore_ joined 17:11 dalek joined 17:18 lucian_ joined 17:30 Justin joined 18:02 d4l3k_ joined 18:03 Justin joined 18:43 dalek joined 18:44 tadzik joined 18:48 Coke joined, PerlJam joined, pmichaud joined, masak joined 18:53 dalek joined, Util joined 18:58 mtk joined 19:11 dalek joined 19:15 tadzik joined 19:16 masak joined, pmichaud joined, PerlJam joined, Coke joined 19:18 mtk joined 19:22 Util joined 19:25 mtk joined
dalek kudo/nom: 8ead1e8 | jonathan++ | src/Perl6/Metamodel/BaseType.pm:
Enable parents to handle :excl and :all options for things that compose BaseType. Fixes .^methods on enums bustage.
 19:41
19:50 Justin joined 19:51 Justin left, Justin joined 19:55 lucian_ joined
cotto ~~ 21:50
22:35 kid51 joined 23:17 Justin joined 23:26 kurahaupo joined
benabik ~~ 23:43
23:44 nbrown joined
nbrown cotto: are you around? I'd like to chat about m0 23:48
23:49 whiteknight joined
whiteknight good evening, #parrot 23:55
nbrown good evening 23:56
benabik o/ whiteknight

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!