Camelia, the Perl 6 bug

IRC log for #parrot, 2011-04-04

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 woosh left #parrot
00:04 whiteknight NotFound: new syntax looks awesome. I can't wait to start using it in Rosella. All we need now are multis...
00:06 soh_cah_toa does nqp have any perl modules i could use for reading pbc?
00:07 soh_cah_toa i've been reading some perl6 articles to get used to nqp syntax but now i need to know how i can use w/ parrot
00:08 sorear you should use the Packfile PMCs for that
00:08 soh_cah_toa okay
00:09 soh_cah_toa but i don't know how to declar pmc variables in nqp. all i have to go on is perl6 resources
00:09 soh_cah_toa *declare
00:10 soh_cah_toa i asked around last night and it sounded like there really aren't many tutorials for nqp
00:10 kid51 is now known as kid51_at_dinner
00:16 whiteknight soh_cah_toa: NQP does have a test suite that you can mine for details
00:16 whiteknight soh_cah_toa: or you can ask here and we'll help you
00:21 soh_cah_toa well, how would i declare a pmc variable in nqp? my $pmc .= new PMC ? okay, well how do i find out what methods can i use?
00:25 mikehh left #parrot
00:26 soh_cah_toa i mean, are there any nqp/perl modules i can dig through? ext/nqp-rx/t and ext/nqp-rx/src haven't been too helpful
00:27 theory joined #parrot
00:28 whiteknight soh_cah_toa: two ways
00:28 whiteknight if you define the type in NQP code, it has a protoobject. So if you have a class My::Class, you create a new one as My::Class.new()
00:28 bacek_at_work soh_cah_toa, my $pmc := pir::new("Foo")
00:28 bacek_at_work soh_cah_toa, for parrot-only pmcs
00:28 soh_cah_toa alright
00:28 whiteknight if you have a type built-in to parrot, or defined in an alternate object model, do what bacek says
00:30 soh_cah_toa alright, suppose i say: my $pmc := pir::new("pmc"); how can i find out what methods i can call?
00:32 lucian left #parrot
00:34 soh_cah_toa i'm starting to doubt whether i can use nqp for the debugger b/c there's no decent tutorial for it
00:37 bacek_at_work soh_cah_toa, for pir::new("foo") semantic is purely parrot-driven. Which mostly mean RTFS of foo.pmc :(
00:39 mikehh joined #parrot
00:39 soh_cah_toa alright, so the pmc's i can use in nqp are defined in src/pmc?
00:40 bacek_at_work soh_cah_toa, yes.
00:40 soh_cah_toa alright, now that is what i was looking for. thanks
00:41 bacek_at_work soh_cah_toa, it's also applicable to pir, winxed, etc.
00:56 soh_cah_toa i was just going to ask that. okay, good
00:57 soh_cah_toa what's a singleton pmc?
00:58 plobsing what indeed?
00:59 plobsing it is an old strategy to implement a singleton pattern in PMCs (every instance is actually the same instance). It has recently come underscrutiny for being crufty.
01:00 soh_cah_toa i'm not surprised. i see no practical advantage for that
01:03 dalek parrot/jit_prototype: b20b8dd | bacek++ | compilers/opsc/src/Ops/JIT.pm:
01:03 dalek parrot/jit_prototype: Use less pir.
01:03 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/b20b8dded6
01:10 dalek Rosella: 7f61f41 | Whiteknight++ | s (2 files):
01:10 dalek Rosella: Add in an alternate method for making decorators. Inheriting from Rosella.Decorate.Decorator allows transparent find_method fallback to a decorated target object. In essence, it treates the target object like a super-object for find_method
01:10 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/7f61f41861
01:10 dalek Rosella: 11e9b77 | Whiteknight++ | src/decorate/Decorator.winxed:
01:10 dalek Rosella: remove cruft from Decorator. Implement stubs for get_attr_str and set_attr_str. These don't work because we aren't walking the mro. Object.find_method walks the MRO, get/set_attr_str do not (go figure, inconsistency?). Refactor find_method, keeping in mind that we can no longer do direct attribute access
01:10 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/11e9b77851
01:13 dalek Rosella/gh-pages: 31e3323 | Whiteknight++ | index.md:
01:13 dalek Rosella/gh-pages: Add note about future-proofing being a design goal of Rosella
01:13 dalek Rosella/gh-pages: review: https://github.com/Whiteknig​ht/Rosella/commit/31e33234f7
01:15 kid51_at_dinner is now known as kid51
01:27 jsut joined #parrot
01:28 whiteknight left #parrot
01:32 jsut_ left #parrot
02:13 kid51 left #parrot
02:32 petdance joined #parrot
02:43 bubaflub left #parrot
02:44 soh_cah_toa left #parrot
03:09 cotto petdance, have you started playing with the new pcc 1.0 release?
03:09 petdance no
03:09 petdance what's pcc?
03:09 cotto portable c compiler
03:11 cotto their site seems to be down atm
03:13 mikehh petdance: I have tried to use splint a couple of times recently on parrot - failed - any suggestions?
03:14 petdance How do you mean you failed?
03:14 cotto mikehh, if it's a simple fix to make it build, feel free to commit.  Otherwise, you can file a pcc bug.
03:15 cotto apparently it chokes on libav too
03:15 mikehh petdance: every time I tried it reports something like cannot find some ffi item and exits
03:16 petdance Did you run "make splint"?
03:16 mikehh yes and tried other variants
03:17 petdance If you want me to help you, we can work on it.
03:18 mikehh include/parrot/parrot.h:82:19: Cannot find include file ffi.h on search path: ./include;./include/pmc;include/pmc;co​mpilers/ast;/usr/include;/usr/include
03:18 mikehh Preprocessing error. (Use -preproc to inhibit warning)
03:18 petdance How did you install splint?
03:18 petdance What OS are you on?
03:19 petdance Please nopaste the entire output.  Or make a gist.
03:19 mikehh with apt-get I think
03:21 nopaste "mikehh" at 192.168.1.3 pasted "output from make splint" (37 lines) at http://nopaste.snit.ch/39436
03:22 dalek Heuristic branch merge: pushed 900 commits to parrot/lorito by cotto
03:24 benabik That's a lot of commits.
03:24 cotto Happily that branch doesn't touch much.  Git handled it like a champ.
03:24 mikehh petdance: that's on Ubuntu 10.10 i386 - perl 5.12.3 - gcc 4.5
03:24 cotto git++
03:25 petdance oh
03:25 petdance you have to run a full make first, mikehh
03:25 jrtayloriv joined #parrot
03:26 mikehh I am pretty sure I did
03:26 mikehh but I will try again without extra options
03:26 petdance This suggests you did not: find: ‘src/{gc,io,packfile,string}/*.c’: No such file or directory
03:27 mikehh yeah, don't know what that means
03:27 dalek parrot: cce61fa | petdance++ | compilers/imcc/cfg. (2 files):
03:27 dalek parrot: Made blocks_are_connected be static, and localized a variable
03:27 dalek parrot: review: https://github.com/parrot/parrot/commit/cce61fa05d
03:27 petdance It means it oculdn't find the .c files to check
03:28 mikehh date && time perl Configure.pl --test --configure_trace
03:29 mikehh sorry wrong window
03:37 mikehh petdance: I did make realclean, config as above, make world, make splint - got the same result as the nopast
03:37 petdance huh
03:37 petdance what happens if you just run that find statement from the command line?
03:39 mikehh get a list of files
03:41 mikehh find src/*.c src/{gc,io,packfile,string}/*.c -type f
03:41 mikehh src/core_pmcs.c
03:41 mikehh src/datatypes.c
03:41 mikehh src/debug.c
03:41 mikehh thru
03:42 mikehh src/string/encoding.c
03:48 petdance 00
03:48 petdance 0HMM
03:48 petdance ARGH
03:49 petdance SO wonder why that doesn't work under make.
03:49 petdance what if you run that command directly from the command line?
03:49 mikehh ok - I'll give it a try
03:50 petdance or in a shell script, for simplicity
03:52 petdance I'm looking at pcc right now
03:53 cotto petdance, you can access their site?
03:53 petdance Nope
03:53 cotto ok.  I thought my isp was insane for a moment.
03:55 benabik It might be the shell make uses doesn't recognize {a,b,c}
03:55 mikehh petdance: does not have that Cannot find bit but fails in the same way
03:55 mikehh include/parrot/parrot.h:82:19: Cannot find include file ffi.h on search path: ./include;./include/pmc;include/pmc;co​mpilers/ast;/usr/include;/usr/include
03:55 mikehh Preprocessing error. (Use -preproc to inhibit warning)
03:55 mikehh Preprocessing error for file: /home/mhu/t.parrot/src/core_pmcs.c
03:55 mikehh < more preprocessing .   In file included from src/core_pmcs.c:10
03:55 mikehh *** Cannot continue.
03:56 petdance benabik: That's pretty likely!
03:56 petdance I'll get rid of it
03:56 petdance benabik++
04:00 mikehh the file ffi.h is in /usr/include/i686-linux-gnu/
04:02 dalek parrot: e938612 | petdance++ | config/gen/makefiles/root.in:
04:02 dalek parrot: Don't use curly brackets
04:02 dalek parrot: review: https://github.com/parrot/parrot/commit/e938612237
04:02 petdance mikehh: try pulling that and ee if it works better
04:11 mikehh petdance: 'k I'll give it a go - I somehow need to get etc/ld.so.conf included in my build -> include /etc/ld.so.conf.d/*.conf
04:14 petdance That doesn't sound right, but ok
04:15 petdance bbiab
04:15 petdance left #parrot
04:21 petdance joined #parrot
04:26 * mikehh seriously need to sleep = it's getting close to 5:30 am here
04:38 ShaneC left #parrot
04:58 dalek parrot: 114d897 | petdance++ | src/embed/api.c:
04:58 dalek parrot: Use STREQ() for string comparisons, instead of incorrectly using strcmp as a boolean
04:58 dalek parrot: review: https://github.com/parrot/parrot/commit/114d897d40
05:37 petdance left #parrot
05:40 contingencyplan left #parrot
05:42 cotto dukeleto, ping
05:42 dalek parrot/lorito: a31a6bd | cotto++ | src/dynoplibs/ (3 files):
05:42 dalek parrot/lorito: add M0 prototype dynops, now with 75% more sharp edges
05:42 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/a31a6bdfe1
05:42 cotto seen dukeleto
05:42 aloha dukeleto was last seen in #perl6 2 hours 38 mins ago joining the channel.
05:49 cotto msg dukeleto I'm in your branch, prototyping stuff.
05:49 aloha OK. I'll deliver the message.
05:50 benabik cotto: Are we just implementing M0 in PBC now?  That'll be a fun bootstrapping step...  PBC on M0 on PBC.
05:50 jrtayloriv left #parrot
05:50 cotto benabik, that's just to get a handle on how close to complete it is
05:50 benabik cotto: You're fibbing.  It's PIR all the way down.  :-D
05:51 cotto I could be.  I'm never quite sure.
05:51 contingencyplan joined #parrot
05:52 cotto I just want something runnable for now.
05:53 benabik Prototypes are good.  I was just reading a paper that said to plan to throw the first implementation away since you'll probably have to do it anyway.  :-)
05:55 cotto benabik, exactly
05:55 cotto eventually something has to be useful, but often you don't know what you want until you're written something else
06:01 theory left #parrot
06:10 NotFound Winxed is a counter-example. The first implementation of the stage 0 was just an example of parsing, and it kept evolving until today.
06:10 NotFound Stage 1, I mean.
06:12 NotFound Well, you can plan to throw it, but you can change your mind ;)
06:39 jrtayloriv joined #parrot
07:00 dalek parrot/lorito: 987fb06 | cotto++ | t/dynoplibs/m0proto.t:
07:00 dalek parrot/lorito: add a test for m0 prototype ops
07:00 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/987fb061e5
07:00 dalek parrot/lorito: 9543274 | cotto++ | src/dynoplibs/m0proto.ops:
07:00 dalek parrot/lorito: various minor fixes to m0 ops
07:00 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/9543274575
07:00 dalek parrot/lorito: 371acc7 | cotto++ | src/dynoplibs/m0proto.ops:
07:00 dalek parrot/lorito: switch to FFA for m0 ctx storage, commit various crimes against C to make it work
07:00 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/371acc7e3d
07:00 dalek parrot/lorito: 31ce228 | cotto++ | t/dynoplibs/m0proto.t:
07:00 dalek parrot/lorito: add some further tests for non-crashing
07:00 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/31ce228eae
07:08 ShaneC joined #parrot
07:44 contingencyplan left #parrot
08:14 cotto left #parrot
09:25 woosh joined #parrot
09:38 woosh left #parrot
09:51 Eduardow left #parrot
10:07 lucian joined #parrot
10:15 bacek left #parrot
10:15 dafrito_ joined #parrot
10:17 dafrito left #parrot
10:20 bacek joined #parrot
10:32 ambs joined #parrot
10:36 ambs_ joined #parrot
10:41 ambs left #parrot
10:41 ambs_ is now known as ambs
10:57 ambs_ joined #parrot
11:02 ambs left #parrot
11:02 ambs_ is now known as ambs
11:24 plobsing left #parrot
11:29 ShaneC left #parrot
11:55 Patterner left #parrot
11:55 Psyche^ joined #parrot
11:55 Psyche^ is now known as Patterner
12:16 UltraDM joined #parrot
12:18 plobsing joined #parrot
12:23 whiteknight joined #parrot
12:27 mtk joined #parrot
12:28 ambs_ joined #parrot
12:28 benabik left #parrot
12:28 whiteknight good morning, #parrot
12:30 lucian good day
12:30 whiteknight hello lucian, how are you doing today?
12:31 lucian i'm supposed to be working on a dozen different things at the same time ...
12:31 ambs left #parrot
12:31 ambs_ is now known as ambs
12:34 dalek parrot/jit_prototype: c0b5399 | bacek++ | t/compilers/opsc/21-jit-files.t:
12:34 dalek parrot/jit_prototype: Don't use Parrot_api functions until I figure out what they are doing to ->api_jmp_buf.
12:34 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/c0b539943a
12:37 dalek parrot/jit_prototype: f448688 | bacek++ | t/compilers/opsc/21-jit-files.t:
12:37 dalek parrot/jit_prototype: Comment-out unused variable.
12:37 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/f448688e0e
12:38 whiteknight bacek: having api troubles?
12:40 plobsing left #parrot
12:41 bubaflub joined #parrot
12:42 plobsing joined #parrot
12:43 bacek whiteknight, not really. It's mostly API + NCI trouble
12:43 whiteknight bacek: okay, I designed that api_jmp_buf system, so let me know if you have any questions
12:44 ambs_ joined #parrot
12:45 atrodo lucian> ping
12:45 lucian atrodo: pong
12:46 ambs left #parrot
12:46 ambs_ is now known as ambs
12:46 bacek whiteknight, check my last commit. Without it "prove t/compilers/opsc/21*" exits with status 1. Because ->api_jmp_buf get clobbered somehow
12:47 atrodo lucian> I saw your comments about Lorito in the log last night, I was curious about what your thoughts on it were
12:47 JimmyZ joined #parrot
12:47 lucian atrodo: well, so far I've found the M0 spec flawed
12:48 atrodo lucian> so not the concept, just what's on the table now?
12:48 lucian it strives to be as simple as possible, at the expense of performance
12:48 lucian atrodo: mostly, yes
12:48 whiteknight bacek: api_jmp_buf is a single field in the interp, and is set on every API call
12:48 atrodo lucian> that makes sense.  Do you have specific examples off hand?
12:48 lucian there were ideas to not expose jumps, and play around with the PC. i don't see how a jit can figure out it should emit a jmp from PC fiddling
12:48 whiteknight those api functions can only be called by embedders, not from inside parrot
12:49 whiteknight bacek: I need to make it a linked-list for proper nesting
12:49 mtk left #parrot
12:49 lucian atrodo: also, maths operations are severely lacking, compared to the native platforms. again, i don't see how a JIT could figure out repeated sub is division (that's not exactly what was going on, but similar)
12:50 bacek whiteknight, may be. But for jit_prototype PackFile_load_bytecode is good enough. I just want to write as little C code as possible :)
12:50 atrodo lucian> so what you're saying is you'd prefer to see a few more ops that would help a jit know what the intentions were?
12:50 lucian atrodo: i think instead of being the least common denominator, i think M0 should be the "most" common denominator when it comes to the expresiveness of he assembly
12:50 whiteknight bacek: yes, that's a good first step
12:50 whiteknight bacek: I'll make the api reentrant and nestable soon
12:51 lucian atrodo: yes, pretty much. i'd like to see M0 mirror actual JIT targets (llvm, nanojit, x86, arm)
12:51 bacek whiteknight, excellent. Than I can switch to less-magic-functions :)
12:51 atrodo (less-magic)++
12:51 ambs_ joined #parrot
12:51 whiteknight api_jmp_buf gives the interpreter someplace to go if we have an unhandled exception
12:52 atrodo lucian> I'll agree with that, there's a point when simplicity is too simple
12:53 lucian atrodo: so perhaps look at llvm, jvm, x86, arm and find the least common denominator subset (even that i bet is bigger than M0)
12:53 plobsing left #parrot
12:53 lucian then add ops that are impossible to JIT for one particular platform otherwise
12:54 ambs__ joined #parrot
12:54 mtk joined #parrot
12:54 lucian things like SIMD
12:54 lucian i don't know how they'd look like in M0
12:54 lucian but a JIT must have knowledge of SIMD to effectively and efficiently generate code for SSE, NEON and friends
12:54 ambs left #parrot
12:54 ambs__ is now known as ambs
12:55 atrodo lucian> that'd be hard to see, but it's a good point
12:55 lucian atrodo: i don't know, perhaps i'm entirely wrong. i'm no expert
12:55 lucian but i have read of the pains others have endured writing JITs of all kinds
12:56 atrodo lucian> any other qualms with lorito/m0?
12:57 lucian atrodo: not really, no
12:57 ambs__ joined #parrot
12:57 lucian i'd just rather not see parrot get yet another jit system ripped out
12:57 ambs_ left #parrot
12:57 atrodo Yea, it needs one
12:58 lucian i agree with cotto_work++ that llvm should certainly not be the only target
12:58 lucian but i disagree with him on the size of M0
12:59 atrodo certainly.  I'd also like to see C not be the only possible target as well
12:59 lucian thousands of ops is insane. but a couple hundred for a fast jit seems ok
13:00 atrodo Aye.  I'd actually like to see less than a hundred.  Something a normal person can keep in their head pretty easily
13:00 lucian how many does ARM thumb have? i think it's a few hundred
13:01 atrodo good question
13:01 lucian but yeah, fewer is ideal
13:01 ambs left #parrot
13:01 ambs__ is now known as ambs
13:01 woosh joined #parrot
13:01 lucian so programmer convenience for M0 shouldn't matter at all, i agree with the goals on that
13:01 lucian no one should ever write M0 by hand
13:01 lucian but performance? i think that's matters very much for M0
13:02 lucian also for security, M0 has to be expressive enough to be able to ban, say, all I/O ops
13:02 atrodo Not by hand no, but compiler writers and parrot hackers will need to be able to grasp it
13:02 lucian sure, not *too* hard
13:02 atrodo lucian> that's one thing I'm staunchly in agreement with.  Unless m0 is completely inaccessible to the end user
13:03 lucian java's security system is a nice research project, but it sort of sucks
13:03 lucian i've looked a bit into how PyPy does sandboxing, and it's interesting
13:04 lucian untrusted code runs in a process that can make no system calls, just write stdout and read stdin
13:04 whiteknight parrot definitely needs a sandboxing system. Of course, we need a design for such a system before we start writing code for it
13:04 lucian but that's perhaps tooe xpensive
13:04 atrodo I don't like java's at all, but that python system sounds interesting
13:05 lucian well, java's isn't that bad. they ban classes of jvm bytecode and java classes
13:05 lucian the first bit sounds interesting for M0
13:05 whiteknight I think the prevailing idea about Parrot is that M0 won't have any security whatsoever, but different dialects or subsets or M1 will disallow certain operations
13:05 atrodo except when you can escape the sandbox with a variable change
13:05 whiteknight so we could use an M1 dialect with no system calls for untrusted code
13:06 lucian whiteknight: what do HLLs compile to? not M0?
13:06 whiteknight lucian: depends. The currently compile down to PIR/PBC. That's just one possible dialect of M1
13:06 whiteknight I see no reason why that wouldn't continue
13:06 atrodo whiteknight> That only works if M1 is the only thing talking to M0
13:06 lucian whiteknight: right. but what if others use M0?
13:06 atrodo as soon as you let others compile to M0, you have to include security
13:07 lucian i see M0 as analogous to hardware-level assembly, and M1 as a C equivalent
13:07 lucian am i wring?
13:07 whiteknight lucian: safety features only work if people use them. If you write unsafe code, you can't expect Parrot will inject safety for you
13:07 whiteknight or, if you call an unsafe library from safe code, you get the same effects. caveat emptor
13:07 lucian whiteknight: no, but i could expect to be able to mark a chunk of bytecode as "no system calls"
13:08 plobsing joined #parrot
13:08 whiteknight lucian: depends. Do you mark it at compile time? Do you verify that mark before execution?
13:09 lucian whiteknight: i'd guess so. if unsafe, only allow execution of non-I/O non-system-call bytecode
13:09 lucian and have input and output ops to communicate with the controller
13:09 whiteknight lucian: the question is, do we want parrot to make an "is this safe?" check on every single opcode dispatch for every single program?
13:09 whiteknight Or, as I would prefer, do we do the verification of safety ahead of time?
13:10 atrodo whiteknight> define when "ahead of time" is.  Compile time?
13:10 lucian whiteknight: it needs to read the bytecode at some point. if the discrimination is done on ops alone (not arguments), then it can be checked in one go
13:10 whiteknight Either we generate code with known safety properties, and trust that those properties were handled by the compiler, or we add in a verifier that can look at the PBC and determine safety before execution at runtime
13:10 lucian whiteknight: i like the latter a lot more
13:10 whiteknight atrodo: any time before execution. Can be at compile time or runtime. Each make different degrees of safety guarantee
13:11 atrodo whiteknight> You can never trust what the user gives you.  if you want to prevent malice, you must do it at run time
13:11 lucian but it could be at M0 compilation time, sure
13:11 whiteknight lucian: if we tell the compiler to generate safe code, then sign the bytecode to prevent tampering, we get a good effect with zero runtime cost
13:11 lucian whiteknight: which compiler? if it's the M0 assembler, i agree
13:11 whiteknight atrodo: true. So we can add an ahead-of-time verifier. For safety your application may only use the ops in M1-safe dialect, etc
13:12 lucian whiteknight: and what exactly is M1?
13:12 atrodo lucian> PIR
13:12 whiteknight lucian: any language that compiles directly to M0
13:12 lucian whiteknight: then it's inherently unsafe
13:12 whiteknight the idea is that M1 will be intermediate forms like PIR/PBC. Things that compile to M1 are called M2, etc
13:13 lucian whiteknight: i see. i was thinking of your M2 compiling to M0
13:13 whiteknight lucian: people can take whatever path they want, but if they avoid M1, they lose the benefits and properties of M1
13:13 lucian is that check so expensive? it only needs to happen when reading in bytecode
13:13 whiteknight all we can do is provide the tools
13:14 whiteknight a check at runtime before execution is probably not bad, especially if we can inform the verfier with things like annotations from the compiler and digital signatures
13:14 lucian i can't see a compelling reason for having two levels
13:14 whiteknight per-op checks during execution is bad
13:14 bluescreen joined #parrot
13:14 lucian yes, that would be bad
13:14 atrodo whiteknight> I agree, it has to be at a segment-ish level
13:14 lucian especially because it couldn't JIT
13:14 whiteknight right
13:15 plobsing an M0 verifier will not be as capable as an M1 verifier and will likely need to be of sufficiently higher complexity (both code and runtime) in order to even come close
13:15 bubaflub i know that PL/Parrot has *some* security features
13:15 plobsing M1 -> M0 destroys information
13:15 lucian plobsing: is it important information if you just disallow system calls?
13:15 ambs_ joined #parrot
13:16 plobsing lucian: not all system calls are created equal
13:16 whiteknight plobsing is exactly right. M0 is designed more for performance and flexibility. safety is not a concern of the M0 design
13:16 whiteknight M0 are the primitives in which more advanced systems are implemented
13:16 lucian plobsing: and sandboxed code shouldn't do any of them
13:16 plobsing futex and writev are very different from a security perspective
13:17 plobsing lucian: are you saying I can only have all or nothing? that's not a very attractive security model.
13:18 ambs__ joined #parrot
13:18 lucian plobsing: the approach i was thinking of was having an explicit "angel" guard untrusted code, marshalling all system calls
13:18 lucian sandboxed code can output and input
13:18 lucian of course, that's only one approach
13:19 ambs left #parrot
13:19 ambs__ is now known as ambs
13:20 lucian plobsing: then, you can be sure that by default sandboxed code can't do damage
13:20 lucian no need for a complex verifier, the app developer decides what's safe
13:20 mikehh one of the first computers I worked on was the CDC 6000 series - it had a very interesting architecture
13:21 ambs__ joined #parrot
13:21 ambs_ left #parrot
13:22 * lucian reads
13:22 atrodo mikehh> how so?
13:22 mikehh all CPU operations were essentially register based, there were basically 8 X registers, 8 A registers
13:22 lucian http://en.wikipedia.org/wiki/CDC_6000_series
13:23 mikehh Setting A registers A1-A6 loaded the appropriate X register from memory, setting A6,A7 saved the register to memory
13:24 mikehh all arithmetic and logic ops were performed between X registers
13:25 ambs left #parrot
13:25 ambs__ is now known as ambs
13:25 mikehh furthermore all I/O was performed by separate (10 in early models) PPs which
13:25 mikehh copied to and from memory - the CPU had no I/O
13:26 mikehh the op system was controlled from PP0
13:28 benabik joined #parrot
13:33 lucian mikehh: so as a parallel, parrot could have an explicit "interpreter" for I/O ops?
13:33 benabik G'morning, #parrot
13:34 * lucian waves
13:34 * moritz particles
13:34 Coke ENOPARTICLE
13:35 benabik o/~ The best part of waking up is #parrot in my comp. o/~
13:36 JimmyZ left #parrot
13:36 mikehh lucian: yes, just a thought, it was very effieient in its day 40+ years ago
13:36 lucian mikehh: yes, i can imagine
13:37 lucian mikehh: what i was thinking is allowing application developers to do that
13:37 lucian your own application is trusted, implicitly
13:37 mikehh I never understood why that concept was never really used in modern architecture
13:38 lucian you might want plugins to be not trusted, so you have a guard to marshall all their calls
13:38 lucian mikehh: because few care about security. look at C
13:39 lucian plobsing: atrodo: my idea may be crap, my point is that perhaps there needn't be yet another layer on top of M0. PIR, winxed, rakudo, pynie could all compile down to M0
13:39 mikehh lucian: not just the security aspects, all I/O is separate, ops are mostly register based
13:40 atrodo lucian> I agree with you.  I think M0 should be another type of bytecode that parrot can consume
13:40 lucian mikehh: sure, that's what i'm saying. the "guard" or "angel" is the only thing sandboxed code can do I/O with
13:40 atrodo mikehh> not all that unlike m0 in theory
13:40 lucian mikehh: or it could be at a lower level as you're saying
13:41 mikehh you can then have load ops, store ops and all arithmetic, logic etc. is register to register
13:42 mikehh and you would need separate address calculation ops
13:43 mikehh maybe/maybe not
13:43 lucian mikehh: it sounds deliciously modular, but may be impractical indeed
13:44 mikehh and then separate I/O processes, with a different interpreter
13:45 mikehh the I/O can handle most of the security aspects
13:45 lucian mikehh: or just memory-isolated threads
13:46 mikehh lucian: I was thinking of keeping I/O completely separate from core ops
13:47 lucian mikehh: in a separate process?
13:47 Eduardow joined #parrot
13:47 mikehh lucian: yes
13:48 lucian mikehh: can't it be done with a separate thread only?
13:48 lucian what would the downsides be
13:49 moritz you'd need some kind of IPC
13:49 atrodo doing io in a separate thread would be tricky if you don't have more than 1 thread
13:49 moritz which would be implemented as IO, mostl likely :-)
13:50 atrodo IO all the way down
13:50 moritz (or how reliable does shared memory work arcross operating systems?)
13:50 lucian that's what i'm saying, memory shared between threads works reliably everywhere
13:51 mikehh have a shared/lockable memory area for I/O buffers
13:53 mikehh core threads can use shared memory (or not) - all I/O in I/O buffers - I/O threads deal with that
13:54 mikehh could be slow on a single core machine, but not many of them around now
13:55 atrodo mikehh> what about embedded devices?
13:55 mikehh even 'phone processors are going multi-core
13:56 mikehh most new ARM and Atom processors are moving to multi-core
13:57 PacoLinux joined #parrot
13:58 lucian mikehh: what about existing devices
13:58 lucian the scheduling overhead might just be too much
13:58 mikehh is parrot ready enough for them?
13:59 mikehh and are we going to port parrot to all existing devices
13:59 moritz surely not all :-)
13:59 ambs_ joined #parrot
14:00 mikehh parrot is not really production ready yet, so we should look to the future :-}
14:00 lucian i have plenty of single-core machines
14:01 lucian anyway, it's an interesting idea
14:01 lucian but the I/O threads will be idling most of the time anyway
14:01 lucian so perhaps cooperative threads can work too
14:01 alin joined #parrot
14:01 lucian CPS should help
14:01 moritz mikehh: when you always look into the future, you forget the presence
14:01 moritz mikehh: remember that parrot does have users
14:01 moritz independently of whether you call it "production ready" or not
14:02 frodwith left #parrot
14:02 mikehh moritz: yes, but how many are operating on single-core machines?
14:02 benabik mikehh: Multi-core, while common, is not universal.
14:03 moritz mikehh: I don't know. We don't collect machine statistics from all HLL users
14:03 mikehh moritz: I know I am not, and I don't think you are
14:03 moritz mikehh: what we get is usually feedback from developers, and that is biased towards stronger machines
14:03 ambs left #parrot
14:03 ambs_ is now known as ambs
14:03 benabik OTOH, most single-core machines can deal with multi-threading without a major loss of efficiency.
14:03 moritz mikehh: so the simple answer is "we don't know, and thus shouldn't assume"
14:04 mikehh moritz: kid51 has a old Mac he tests on, but how many perl6 users try out single-core machines - maybe laptops, but new ones are nearly all multi-core
14:05 moritz mikehh: again, we don't know.
14:05 lucian benabik: i challenge that assertion
14:05 lucian mikehh: i just bought a single-core netbook, brand new
14:05 moritz mikehh: I know that sorear stopped hacking rakudo because compilation took too long (and too much memory). Doesn't sound like a huge many-core server.
14:06 mikehh lucian: does it run parrot?
14:07 lucian mikehh: yep
14:07 lucian mikehh: ARM Cortex-A8, 800mhz
14:07 whiteknight lucian: surely one counter-example does not disprove the trend
14:08 whiteknight for good or bad, multi-core is the direction almost all chip manufacturers are heading
14:08 moritz no. But neither do statements like "most modern..." prove it.
14:08 lucian whiteknight: of course not. but multi-core is for parallelism, not concurrency
14:08 mikehh moritz: yes it takes far too much memory at the moment, I don't think separating I/O would cause a problem there
14:08 lucian whiteknight: even on multi-core, idling threads just create more scheduling waste
14:09 lucian if threads idle, they shouldn't exist
14:09 mikehh lucian: all operating systems have a degree of parallelism
14:09 whiteknight I'm not saying anything about threading. Only pointing out that, whether we want it or not, multi-core is the future of computing
14:10 mikehh lucian: depends on what resources they are using, eg event monitoring
14:11 mikehh whiteknight: yes, but even single-core requires some parallelism
14:13 benabik lucian: Which assertion? The loss of efficiency?
14:14 lucian mikehh: well, in most cases thread scheduling overhead is deadly at around 2000 threads
14:14 lucian benabik: yes
14:15 mikehh lucian: was not looking at that many, if you have that many you should have a separate core or more dedicated to scheduling
14:15 lucian mikehh: or not have them in the first place :)
14:16 benabik lucian: Implementing async IO as a thread using blocking IO should cost (IO + 2 thread switches), and a thread switch is generally lighter weight than a context switch.
14:16 lucian threads waiting for I/O has been repeatedly show to be a bad idea
14:16 lucian mikehh: but i really like the idea of a semantic "process" handling I/O
14:16 mikehh lucian: well I tend to think you need to go to the erlang model or something
14:16 UltraDM left #parrot
14:17 lucian mikehh: what do you want people to do with threads?
14:17 lucian mikehh: in general, on parrot
14:17 benabik lucian: But depending on how you use threads, you can turn all the thread switching into just function calls.  "create_worker_thread(function)" becomes "function()", just run the IO functions in thread every time "add_IO_request" is called, etc.
14:18 lucian benabik: but the scheduling overhead of that one thread can be felt with lots of threads
14:18 mikehh lucian: yeah - I have been thinking about something like that for while (separating I/O)
14:19 mikehh lucian: and no - I have been reading a lot of anti-thread articles recently - different modelks are available
14:19 benabik lucian: Yes. I will agree creating many threads will be very very bad.  But one or two event handling threads rarely kills performance.
14:19 lucian benabik: i see that as a workaround for the lack of proper async I/O, and it's ok for that
14:20 lucian mikehh: heh. well, threads are good for CPU parallelism. they're a low-level feature for that
14:20 lucian but the I/O guard processes need not be threads, i think
14:20 mikehh lucian: some of the $work I have been doing is on HPC - mostly using MPI
14:21 lucian benabik: GLib's gio does that, and it works out alright if you otherwise strictly use threads for parallelism (not concurrency)
14:22 mikehh lucian: which is why I am advocating separating out I/O, however we do it - monads anyone
14:24 plobsing left #parrot
14:24 lucian mikehh: of course, attention should be kept to I/O perf
14:27 mikehh ok - I am going to switch to 11.04 beta and see if I can figure out how to build perl 5.12.3
14:27 mikehh libraries are in different places and config does not seem to pick them up
14:27 ambs left #parrot
14:27 mikehh bbiab
14:28 JimmyZ joined #parrot
14:28 plobsing joined #parrot
14:29 mikehh left #parrot
14:41 Tene lucian: Sorry, this weekend didn't work out at all for me.  I'll try again tonight.  :(
14:41 theory joined #parrot
14:41 lucian Tene: what for?
14:41 lucian reading or talking?
14:41 Tene lucian: responding to your 6model/python inquiry
14:42 cotto joined #parrot
14:43 lucian Tene: ok
14:43 * Tene finally goes to sleep, about 8 hours later than planned, for a short nap before going to work. :/
14:46 bubaflub left #parrot
14:48 rohit_nsit08 joined #parrot
14:49 rohit_nsit08 whiteknight: hello, good morning
14:49 whiteknight hello rohit_nsit08
14:49 rohit_nsit08 whiteknight:  what is finite automation in lexical analysis?
14:49 whiteknight that's a very big question!
14:51 rohit_nsit08 i read it's something similar to finite state machine we use in digital design but couldn't find any good reference on it.
14:52 whiteknight rohit_nsit08: it's mostly implicit. You don't actually have a "state", but you enter different flow paths when you get different inputs
14:53 rohit_nsit08 whiteknight: hmm didn't get that, u mean there are no states?
14:54 rohit_nsit08 whiteknight: i read about in the context of lexer that, when it reads the source code and converts it into tokens , this conversion is done with the help of finite automation.
14:55 whiteknight rohit_nsit08: let's say we have two tokens in a language "foo" and "function"
14:55 rohit_nsit08 whiteknight: okay
14:55 whiteknight if we are lexing and we find an "f", we are in a state "foo or function"
14:55 whiteknight then if we find "fo", we are in state "foo", and need to finish it
14:56 rohit_nsit08 hmm.. so they are like parallel paths and lexer switches between them based on the next input?
14:56 whiteknight so we have a state, based on the letters we have already found
14:56 whiteknight right
14:57 rohit_nsit08 hmm..the concept is very similar to finite state machine
14:58 rohit_nsit08 whiteknight: i updated my blog yesterday :-) i thinking to use it to keep track of my current work.
14:58 whiteknight rohit_nsit08: link?
14:59 whiteknight rohit_nsit08: blogging is an important part of GSoC
14:59 rohit_nsit08 whiteknight: http://rohitnsit08.blogspot.com
14:59 rohit_nsit08 whiteknigt: i'm writing my proposal in the form of blog post loll
14:59 whiteknight excellent
14:59 rohit_nsit08 thanks
15:11 mikehh joined #parrot
15:11 bubaflub joined #parrot
15:18 dmalcolm joined #parrot
15:18 rohit_nsit08 whiteknight: i submitted my proposal yesterday, u said there is some ranking system. Can students know about their ranks?
15:19 moritz rohit_nsit08: I don't think so. And the ranking only starts after the submission deadline
15:19 whiteknight rohit_nsit08: I don't know the details, but I think the ranking is just for keeping notes
15:20 whiteknight mentors give points to applications, but those points aren't the only thing that matters. It's just to keep track
15:20 moritz aye; in the end a consensus is needed
15:20 whiteknight rohit_nsit08: We will be giving feedback as the process continues
15:20 whiteknight moritz is correct
15:20 rohit_nsit08 moritz: Hi, okay.
15:20 whiteknight rohit_nsit08: and even if we have a great proposal, we still need to find a mentor, and we still need to have an available slot
15:20 rohit_nsit08 whiteknight: ya i understand that :-)
15:26 cotto_work ~~
15:36 cotto_work Cool.  I have some interest in my trac/github fork.
15:41 plobsing left #parrot
15:44 bubaflub cotto_work: link?
15:44 cotto_work bubaflub: https://github.com/mickelangelo/github-trac
15:45 cotto_work bubaflub: it looks like he's trying to integrate a bunch of forks of that plugin.
15:48 bubaflub cotto_work: great
15:49 frodwith joined #parrot
15:55 jnthn_ In case it's of interest to anyone here: I did a talk at OSDC.TW that looked at building compilers with NQP and some basic 6model bits; slides: http://www.jnthn.net/papers​/2011-osdc.tw-compiler.pdf and code: http://www.jnthn.net/papers/2​011-osdc.tw-compiler-code.zip
15:58 whiteknight jnthn++
15:59 jnthn_ I'll try and sort out the 6model documentation situation in the next week or so.
15:59 frodwith left #parrot
16:00 whiteknight jnthn_: We would really appreciate it. At least one GSoC project may be using 6model intimately
16:00 jnthn_ I'm aware there's plenty of confusion about how to use it, and what it actually provides/intends to provide.
16:00 jnthn_ OK, which one?
16:00 jnthn_ I know somebody wants to work on PDL-ish stuff (the S09 bits).
16:00 whiteknight lucian's Python compiler
16:00 jnthn_ Ah, OK
16:00 whiteknight if he decides to go that route, which I do not know he will
16:00 jnthn_ I saw that post. It's one of the things that told me "I really must document this stuff more" :)
16:01 whiteknight Tene will be using it in Cardinal too, though I don't know a timeframe for that
16:01 frodwith joined #parrot
16:01 whiteknight We're going to want an improved object model for JavaScript too, though we probably won't do anything object model related this summer
16:01 jnthn_ Yes, I've already answered a few of Tene++'s questions and added a repr that was suitable.
16:02 jnthn_ I think the repr I added for Cardinal will - at first blush - be fine for Python too.
16:02 whiteknight I suspect the JavaScript case will be special, because we can just use Hash instead of Object
16:02 jnthn_ And probably also for JavaScript.
16:02 * PerlJam hopes that guy succeeds with making Perl  6 more PDLy
16:02 jnthn_ (Hash instead of Object) That misses the point of what 6model exists to do :)
16:02 whiteknight although we will probably want a wrapper which can take a JavaScript "object" and make it more suitable to use from a language which separates methods and attributes
16:03 jnthn_ Using a hash for storage is a representation decision
16:03 jnthn_ You still want the think to act like an object otherwise.
16:03 jnthn_ So it's just choosing the correct representation.
16:04 jnthn_ s/think/thing/
16:05 jnthn_ Rakudo's default representation will be P6opaque, but that's not suitable for various other languages that really just want a dictionary of attributes that looks hash-ish.
16:05 jnthn_ You can even have representations that do hybrid things: optimized storage for compile-time kmown attributes, and a fallback, lazily allocated hash for ones that come into existence at runtime. :)
16:06 frodwith left #parrot
16:06 moritz iirc that's what V8 uses as an optimization
16:06 jnthn_ IIRC, V8 is a little more complex than that, but yes, it's along those lines.
16:07 frodwith joined #parrot
16:07 jnthn_ V8 also tracks transitions an object make and can "rebless"
16:07 jnthn_ We don't have the mechanism for that in 6model yet.
16:07 jnthn_ Probably in a month or two we will.
16:07 frodwith left #parrot
16:07 jnthn_ I'm trying to see if I can get the same primitive to handle that and mix-ins.
16:08 jnthn_ BTW, languages where the methods are just attributes are easy. They just have a REALLY straightforward implementation of the add_method meta-method that sets an attribute. :)
16:08 frodwith joined #parrot
16:09 jnthn_ If JavaScript, your meta-object is probably a singleton.
16:09 darbelo joined #parrot
16:09 jnthn_ To a first unoptimized approximation, anyways.
16:10 moritz do you compile method calls to <attribute_lookup><invoke>?
16:10 moritz or to a method call, and add a custom dispatcher?
16:10 frodwith left #parrot
16:10 moritz the latter sounds more cross-HLL robust
16:10 whiteknight moritz: it shouldn't matter. find_method will look for an attribute with the same name, and return null if that attribute isn't invokable
16:11 frodwith joined #parrot
16:11 jnthn_ moritz: The term "custom dispatcher" really needs to go away.
16:11 jnthn_ It's just a "dispatcher" :)
16:11 moritz whiteknight: ah, so it's just find_method and not a whole dispatcher
16:11 whiteknight right
16:11 jnthn_ find_method *is* a dispatcher pretty much.
16:12 jnthn_ Well, or delegation to one.
16:12 whiteknight right, minus the part where we actually execute what we find
16:12 jnthn_ Yeah
16:12 jnthn_ 6model largely follows the Parrot model for now, fwiw
16:12 moritz "no trial, no jury, straight execution" :-)
16:12 jnthn_ find_method chooses what we'll dispatch to
16:12 whiteknight that "for now" part sounds ominous
16:12 jnthn_ And then actually invoking that is a separate step.
16:13 frodwith left #parrot
16:13 jnthn_ whiteknight: Oops, I didn't mean for it to.
16:13 jnthn_ whiteknight: fwiw, 6model in the CLR follows the Parrot model of separate find and invoke too.
16:14 jnthn_ whiteknight: I haven't really felt strongly that this needs to change.
16:14 jnthn_ You have to do both steps *somewhere*.
16:14 whiteknight okay, good. Not because I want more things to be the parrot-way, but because that separation is generally good design, methinks
16:14 jnthn_ Yes, I'm fairly comfortable with that design.
16:15 whiteknight Part of me wishes we had a "port Parrot to 6model" GSoC project in the works
16:15 jnthn_ It just makes it harder to write deferal-y stuff.
16:15 whiteknight but I worry that such a project would be far too huge an undertaking
16:15 jnthn_ It would be.
16:15 jnthn_ We should slip 6model in gradually.
16:15 jnthn_ Not in one big bang.
16:15 whiteknight jnthn_: is there a gradual way? Could you put together even a general outline of how that kind of conversion would take place?
16:16 whiteknight our current system is so tangled, I worry it's going to be impossible to excise parts of it
16:18 darbelo Given a sufficiently large axe, excision is always possible.
16:20 jnthn_ whiteknight: Something like, 1) make the 6model stuff available in Parrot at all, 2) create meta-objects that provide Parrot's current class semantics so it's a small-ish step to switch over much code, and hope many people take that path, 3) get PMCs to be 6model objects, 4) hope Class and Object PMCs can go away by this point, or just turn them into simple things that delegate to 6model to give people more time to switch away.
16:21 jnthn_ Somewhere along the line, the methods/namespace relationship and the class registry need to go away.
16:21 jnthn_ imho, anyway
16:21 jnthn_ :)
16:23 jnthn_ I think the biggest mis-understanding at the moment is that people seem to think 6model is an implementation of a bunch of OO-ish stuff. In reality, it's a bunch of building blocks to let you build your languages view of OO.
16:23 jnthn_ *language's
16:25 PerlJam It wouldn't hurt to add that outline and a short description to the gsoc ideas page.
16:25 PerlJam (especially if you broke it out into 2 or 3 projects)
16:25 jnthn_ You can see it like HLL::Grammar/HLL::Actions. It doesn't try to define the grammar for your language, but it does give you ways to parse identifiers, an OPP, quoted construct parser, etc.
16:26 whiteknight jnthn_: okay, so basic strategy is to get 6model into the core first, then start removing Object/Class?
16:26 whiteknight I like that plan well enough
16:27 PerlJam how many gsoc proposals has PaFo gotten?
16:27 whiteknight That's a good question
16:27 lucian jnthn_: you might be interested in what PyPy does, similar to v8 in some respects http://morepypy.blogspot.com/2010/11/effi​ciently-implementing-python-objects.html
16:27 whiteknight PerlJam: I think we had 6 proposals submitted as of this morning
16:27 PerlJam cool
16:28 whiteknight but I know of other students who have show interest but haven't put anything up on the google-melange site
16:28 plobsing joined #parrot
16:28 PerlJam TPF only appears to have 2 submitted though I've heard tell of several others in the works.
16:29 darbelo We should encourage students to submit to melange as soon as possible.
16:29 jnthn_ lucian: Thanks, looks like a good article
16:29 lucian jnthn_: i've allocated the 1st week of gsoc to investigating 6model, or falling back to a custom map-for-attributes option if that fails
16:29 jnthn_ whiteknight: Well, the PMCs become real objects part is important too :)
16:29 whiteknight yes, 6 submissions right now: rohit_nsit08, lucian, soh_cah_toa, bubaflub, benabik, and joehms22
16:29 jnthn_ lucian: OK, when is that "first week"?
16:30 lucian jnthn_: i won't necessarily do it then, might be earlier
16:30 * benabik needs to severely redo his proposal.
16:30 PerlJam lucian: I think jnthn is asking so he knows by when to have the docs done (or mostly done)  :)
16:30 whiteknight WE NEED THEM YESTERDAY!
16:30 lucian PerlJam: i see
16:30 PerlJam or even started :)
16:30 lucian whiteknight: +1
16:30 whiteknight or, whenever
16:30 whiteknight :)
16:31 jnthn_ PerlJam: Yes, that :)
16:31 benabik whiteknight: Not very funny...  I'm really working hard to fit time to do proposals in between homework. :-/
16:31 lucian jnthn_: http://www.google-melange.com​/gsoc/events/google/gsoc2011
16:31 lucian either community bonding period (might be busy with my dissertation then) or after start
16:31 jrtayloriv left #parrot
16:31 PerlJam jnthn: Have you signed up to be a mentor for TPF gsoc?
16:31 lucian jnthn_: so late april/may
16:32 benabik_ joined #parrot
16:32 PerlJam jnthn_: or for PaFo gsoc
16:32 PerlJam ?
16:32 jnthn_ PerlJam: Not yet
16:32 benabik left #parrot
16:32 benabik_ is now known as benabik
16:32 jnthn_ brb, laundry
16:33 bubaflub left #parrot
16:34 whiteknight benabik: I was talking about jnthn and his documentation
16:35 benabik Ah. Juy poor timing on my part then. Nearly had a heart attack.
16:35 benabik whiteknight: ^^
16:37 jnthn_ back
16:37 Coke 6 proposals to PAFO, 2 to TPF
16:37 dukeleto ~~
16:37 jnthn_ PerlJam: I got interest in doing PDL stuff in Perl 6 and offerred to mentor it.
16:37 jnthn_ s/got/saw/
16:38 Coke dukeleto, whiteknight: I assume "hold off voting" until you say how it's working this year?
16:38 dukeleto Coke: i expect those numbers to increase this week. It is all about procrastination
16:38 * PerlJam wonders if he should even apply to be a mentor for PaFo gsoc
16:38 dukeleto PerlJam: yes, please.
16:38 dukeleto PerlJam: we need as many mentors as we can get
16:39 PerlJam I just feel so out of touch with Parrot these days.
16:39 benabik dukeleto: Or prioritization. I have very little time for things not due tomorrow.
16:39 cotto_work PerlJam: mentors don't need to be omniscient
16:39 Coke PerlJam: one of the proposals involves POD, so there you go.
16:40 PerlJam okay, okay.  I just applied  :)
16:40 dukeleto PerlJam: awesome!
16:40 davidfetter joined #parrot
16:47 * dukeleto adds gsoc ideas to our ideas page
16:49 whiteknight jnthn++: That presentation was very nice
16:49 jnthn_ :)
16:49 jnthn_ It's *so* nice that you can write the whole compiler in a HLL now :)
16:50 whiteknight dukeleto: what ideas?
16:54 dukeleto whiteknight: i am stealing some GCI ideas and making them bigger
16:54 dukeleto whiteknight: for instance, embedding parrot in a browser
16:55 whiteknight oh, nice
16:55 whiteknight dukeleto: I don't know if any of them will be used this year, but I think we should keep a list like that available all year
16:55 whiteknight we should merge that into our BigProjectIdeas page
16:55 dukeleto whiteknight: yes
16:57 dukeleto whiteknight: you have any other ideas bouncing around?
16:58 whiteknight nothing in particular, I haven't been thinking about it really
16:58 whiteknight I was brainstorming ideas pretty hard, until we got huge turnout
16:58 benabik_ joined #parrot
16:58 benabik left #parrot
16:58 benabik_ is now known as benabik
17:00 bubaflub joined #parrot
17:01 whiteknight msg cotto_work I'm looking at Parrot-Instrument now. It appears all tests are segfaulting in the same place. Looks GC related (something on the free-list is clearly not free). I suspect GC write barriers are the cause
17:01 aloha OK. I'll deliver the message.
17:01 whiteknight or, lack thereof
17:01 dalek tracwiki: v41 | dukeleto++ | GSoc2011
17:01 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=41&amp;action=diff
17:01 dalek tracwiki: v42 | dukeleto++ | GSoc2011
17:01 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=42&amp;action=diff
17:02 dukeleto whiteknight: should http://docs.parrot.org/parrot/de​vel/html/docs/embed_new.pod.html exist ?
17:02 dukeleto whiteknight: http://docs.parrot.org/parrot/​devel/html/docs/embed.pod.html seems to think it should
17:02 whiteknight there is an embed_new.pod file in the repo
17:02 whiteknight either the link is wrong or the new version isn't being htmlified
17:03 Coke new docs are not automatically html-ified.
17:03 whiteknight well there's your problem
17:03 Coke (depends on the directory it's created in. new pdds should be, e.g.)
17:03 Coke checking...
17:05 dalek parrot: f64d532 | Coke++ | docs/index/developer.json:
17:05 dalek parrot: Generate html for embed_new docs.
17:05 dalek parrot: review: https://github.com/parrot/parrot/commit/f64d5323d2
17:05 whiteknight Coke++
17:05 Coke probably want to fix the reference in embed.pod so it's actually a link.
17:06 Coke (note that I didn't fix the website, just 'make html' -it'll show up after the next release.)
17:07 alin left #parrot
17:09 cotto_work whiteknight: I'm here
17:09 spinclad left #parrot
17:10 cotto_work That sounds as likely as anything.
17:10 whiteknight cotto_work: I'm idly looking over the source for the .pmc files now, looking for places to insert write barriers
17:10 cotto_work whiteknight: I'm sure you'll find some.  parrot-instrument has some very unusual PMCs.
17:11 whiteknight there are certain parts where I'm pretty certain I do not like the design
17:11 whiteknight but that's neither here nor there
17:11 whiteknight important is getting the damn thing to work
17:12 whiteknight then making sure it's capable of supporting a new debugger
17:12 cotto_work yes
17:12 benabik left #parrot
17:12 JimmyZ left #parrot
17:14 * dukeleto begs people to add more gsoc ideas
17:14 whiteknight do we not have enough?
17:14 dukeleto whiteknight: no, we don't
17:14 dukeleto whiteknight: more is better
17:14 whiteknight are there students circling around in need of an idea?
17:15 dukeleto whiteknight: lots of students are trolling ideas pages right now, the few days before the deadline
17:15 dukeleto whiteknight: ideas are still valuable, for gsoc or not, so I just like having lots of ideas
17:15 whiteknight ok
17:15 dukeleto whiteknight: there are plenty of crazy smart students trying to decide on an organization, and we want something that piques their interest
17:16 whiteknight okay, I'll see what I can come up with today
17:16 PerlJam dukeleto: how do those students even know to look at our pages?
17:16 whiteknight there's a link from the GSoC page
17:16 PerlJam (who's advertising?)
17:17 dalek tracwiki: v43 | dukeleto++ | GSoc2011
17:17 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=43&amp;action=diff
17:22 mj41 joined #parrot
17:30 dukeleto PerlJam: i try to advertise, via twitter and identi.ca, and there are links from the main GSoC page
17:30 dukeleto the more help I get, the better
17:33 dalek tracwiki: v189 | jimmy++ | WikiStart
17:33 dalek tracwiki: add 6model link
17:33 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=189&amp;action=diff
17:38 ShaneC joined #parrot
17:41 cotto_work Do we have a task to do something with 6model on Parrot?  Moving wholesale is too big for a summer, but it seems like a useful subset of the task (e.g. initial implementation and poc) could be completed.
17:42 dukeleto cotto_work: perchance
17:42 dukeleto cotto_work: 6model has fuzzy edges
17:43 cotto_work It's in nqp already.
17:47 dukeleto cotto_work: sure, but can you come up with a student project that is completable in 3.5 months and is well-defined ?
17:48 dalek parrot-instrument: 3c33584 | Whiteknight++ | src/dynpmc/instrument (6 files):
17:48 dalek parrot-instrument: sprinkle in some GC write barriers in places that look important. Appears to have no effect on test suite
17:48 dalek parrot-instrument: review: https://github.com/Whiteknight/pa​rrot-instrument/commit/3c33584118
17:49 dalek tracwiki: v1 | jimmy++ | 6model
17:49 dalek tracwiki: init 6model stuff
17:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki​/6model?version=1&amp;action=diff
17:49 dalek tracwiki: v2 | jimmy++ | 6model
17:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki​/6model?version=2&amp;action=diff
17:49 dalek tracwiki: v3 | jimmy++ | 6model
17:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki​/6model?version=3&amp;action=diff
17:49 dalek tracwiki: v4 | jimmy++ | 6model
17:49 whiteknight cotto_work: I was just talking to jnthn about this. He suggests a good course of action is to get 6model code into Parrot along side our existing object model. Then we can start migrating Object and Class guts to it
17:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki​/6model?version=4&amp;action=diff
17:49 cotto_work whiteknight: that's a sensible approach that's served us well in the past
17:49 whiteknight cotto_work: the more I think about it, that's probably the best. We have to figure out how to expose 6model to PIR code without conflicting with Class, however
17:50 whiteknight I wouldn't want to introduce a "6modelClass" type, for instance. It should have a name that we would be happy to keep long term
17:53 cotto_work whiteknight: can you think of a way to expose m0-related constants to pir in a way that's less noisy than "m0_add_i ctx, .M0_I1, .M0_I2, .M0_I3"?
17:54 cotto_work ideally "m0_add_i ctx, i1, i2, i3"
17:55 whiteknight what do you mean "m0-related constants"?
17:57 cotto_work names for m0 registers
18:00 cotto_work I'm prototyping M0 in pir dynops.
18:00 whiteknight oh, okay
18:00 whiteknight if you're trying to prototype it in PIR, you're just going to have to deal with some pain
18:00 whiteknight .M0_I1 looks fine to me
18:18 cotto_work or will I?
18:28 dodathome joined #parrot
18:31 davidfetter_ joined #parrot
18:34 soh_cah_toa joined #parrot
18:35 davidfetter left #parrot
18:35 davidfetter_ is now known as davidfetter
18:37 cognominal left #parrot
18:43 mtk left #parrot
18:45 cognominal joined #parrot
18:47 lucian 127 ops hmm https://developer.mozilla.org/En/Nanojit/LIR
18:49 mtk joined #parrot
18:53 lucian i can't figure out whether nanojit can be used for function jiting
18:53 whiteknight like Parrot function jitting?
18:56 lucian whiteknight: sure. from what i'm reading, it may only be any good for tracing jits
18:57 lucian which ain't bad at all, but with possibly less potential
18:57 lucian (most js jits use both)
18:57 whiteknight I see no reason why NanoJIt couldn't do Parrot subs, based on what I am seeing here
18:57 whiteknight it has call ops
18:58 whiteknight it has the jump ops that Parrot CPS would use
18:58 whiteknight nanoJIT has everything we would need
18:59 lucian hmm. webkit's squirrelfish extreme at first did "context threaded jit", which is a pasting jit essentialy
18:59 whiteknight it does have the extra barrier guards too. Parrot could use that to JIT individual subs, then jump out when the sub exited
18:59 * lucian needs to read some more
19:03 lucian whiteknight: there's something i read, about moz moving to webkit's codegen, or similar
19:04 lucian whiteknight: ah http://blog.mozilla.com/dmandelin​/2010/02/26/starting-jagermonkey/
19:05 lucian whiteknight: from what i'm reading, it appears they'd picked most of the low-hanging fruit with interpretation
19:06 lucian i don't understand how JSCore's assembler is better, though
19:08 lucian whiteknight: right, should've read through the end
19:08 lucian JSCore does no optimisations at all
19:08 lucian but it's very fast
19:13 lucian i still don't get why nanojit couldn't have the optimisations turned off
19:34 theory left #parrot
19:35 theory joined #parrot
19:36 frodwith joined #parrot
19:37 bubaflub left #parrot
19:38 spinclad joined #parrot
19:47 ambs joined #parrot
19:47 dukeleto frodwith: welcome!
19:48 frodwith hey dukeleto.
19:49 mj41 left #parrot
19:50 bbatha joined #parrot
19:57 dalek parrot/lorito: 644a53b | cotto++ | / (3 files):
19:57 dalek parrot/lorito: add a header with an m0 register name->number enum
19:57 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/644a53bc86
19:57 dalek parrot/lorito: 339c95f | cotto++ | / (2 files):
19:57 dalek parrot/lorito: add the necessary magic to generate pasm consts from an enum
19:57 dalek parrot/lorito:
19:57 dalek parrot/lorito: Right now this results in things like q<m0_add_i ctx, .M0_I1, .M0_I2, .M0_I3>
19:57 dalek parrot/lorito: which is a bit too noisy for non-generated code.
19:57 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/339c95f7d3
19:57 dalek parrot/lorito: 614523a | cotto++ | / (2 files):
19:57 dalek parrot/lorito: use a bit of macro hackery to make M0 ops look nicer
19:57 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/614523a48b
19:57 dalek parrot/lorito: 2bb961a | cotto++ | t/dynoplibs/m0proto.t:
19:57 dalek parrot/lorito: make register use a little more consistent
19:57 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/2bb961ae96
20:03 bubaflub joined #parrot
20:04 bluescreen left #parrot
20:14 dukeleto cotto_work: rock on!
20:14 dukeleto it is nice to see somebody else hacking on the lorito branch
20:15 hercynium joined #parrot
20:16 cotto_work dukeleto: it's nice to get something that can run, incomplete though it is.
20:18 bluescreen joined #parrot
20:19 dukeleto cotto_work: as my math advisors used to tell me: "something is better than nothing"
20:19 dukeleto cotto_work: i have been living under a rock for the last few days, and have not had much time to hack on parrot or gsoc stuff
20:20 dukeleto cotto_work: but it looks like we have an array of good proposals. Of course, I want more :)
20:20 cotto_work dukeleto: of course.
20:21 cotto_work I'm a little surprised that we have as many as we do by this point.  I know that if I were participating, I'd have only a vague idea of what I wanted to do by now.
20:22 lucian cotto_work: you'd be surprised
20:22 lucian my first GSoC i was totally lost
20:23 lucian ended up writing a proposal even i was impressed with
20:23 whiteknight the feedback process is extremely helpful
20:24 lucian that too
20:24 moritz TPF only has two proposals by now
20:25 lucian also, one gets extremely excited when offered a free hand and money
20:25 lucian uh, i may have gotten that idiom wrong
20:26 whiteknight the money is definitely nice
20:27 whiteknight left #parrot
20:27 lucian yep. i've been pleasantly surprised however to find most fellow students more interested in pursuing their beloved project than the money
20:28 bubaflub lucian: the money is nice, but contributing to open source and advancing the project is much more fun
20:28 bubaflub in my eyes the money just makes play-time possible
20:28 lucian bubaflub: exactly. and i'm glad most GSoC folk actually feel that way
20:29 lucian i'd expect gold diggers to get disqualified fast, too
20:29 lucian enthusiasm reeks
20:30 bubaflub lucian: we are violent agreement
20:31 plobsing left #parrot
20:31 dukeleto the money seems to be mostly un-important to students from wealthier countries, but $5K USD is a lot of money in some countries. It is more than the average yearly salary of most citizens.
20:32 dukeleto bubaflub: how are those GMP bindings?
20:32 * dukeleto cracks the whip and starves the hounds
20:32 bubaflub dukeleto: working, though i can't get the mpz_get_string quite right
20:32 lucian dukeleto: it's quite a lot for me too, but i guess i'm not a typical case
20:32 bubaflub dukeleto: i'm thinking about doing it in Winxed and Rosella
20:33 dukeleto lucian: it is a lot for any student in any country. "un-important" is quite right
20:33 dukeleto bubaflub: interesting
20:33 dukeleto bubaflub: there are performance considerations
20:34 dukeleto bubaflub: will it be a mixture of PIR and Winxed ?
20:34 bubaflub dukeleto: it might be.  the ncidef2pir could give us the basic PIR bindings
20:34 bubaflub dukeleto: and then the object stuff in Winxed
20:35 dukeleto bubaflub: create a github issue for your problem with get_string and add any error output, stacktraces that you have
20:35 dukeleto bubaflub: if you are talking about having a low-level PIR access and higher-level Winxed access: Yes.
20:35 lucian i've sort of come to the conclusion lately that you can't really do proper C bindings without a C compiler
20:35 dukeleto bubaflub: i just don't want to force the performance penalty of Winxed on people if they care about speed
20:35 lucian i'm too lazy to write a second proposal, though :)
20:35 bubaflub dukeleto: i could also have Winxed compile down to PIR
20:36 woosh left #parrot
20:36 dukeleto bubaflub: yes. but generated PIR is not as efficient, yet.
20:36 bubaflub dukeleto: ok.  i think it's best to make the definition file, use ncidef2pir to generate the lowest level bindings possible in PIR
20:36 dukeleto bubaflub: but if you generate bytecode, i guess that comes out in the wash
20:37 bubaflub dukeleto: consumers can then use those functions as PIR
20:37 dukeleto bubaflub: yes, i like that
20:37 bubaflub dukeleto: or they can use the Winxed GMPz object for conveience
20:37 dukeleto bubaflub: i think you need a very low-level interface to GMP in PIR, and then you can build up a nicer/friendlier/slower interface from any HLL that you want
20:38 dukeleto bubaflub: but concentrate on the low-level interface first. You need a foundation that can be built upon.
20:38 NotFound dukeleto: What winxed performance penalty?
20:38 dukeleto NotFound: i don't know specifics, I just assume. Perhaps I am making an ASS out of U and ME.
20:38 bbatha left #parrot
20:39 dukeleto NotFound: there wouldn't be a penalty for loading bytecode, but there would be for running Winxed scripts that interface to GMP
20:39 dukeleto NotFound: and I just want both to be an option
20:40 NotFound dukeleto: winxed is a compiler, you don't need to run scripts if you don't want to.
20:44 dukeleto http://google-opensource.blogspot.com/2011/0​3/parrot-foundation-reflects-on-google.html
20:44 dukeleto i just found that. Don't know how I missed it.
20:44 dukeleto NotFound: i buy that
20:45 dukeleto bubaflub: i would say that just keep the actual loading of stuff via NCI in PIR, and you can use winxed or whatever to hack on higher-level bindings
20:45 bubaflub dukeleto: sounds great.
20:45 bubaflub dukeleto: i'll make a note of it in my proposal on melange tonight
20:47 dukeleto bubaflub: but create a gh issue for the get_string bug you are running into
20:47 NotFound BTW I'm not a mentor but I'll be happy to help with any winxed related task or doubts.
20:47 bubaflub dukeleto: okey dokey.
20:48 bubaflub NotFound: you going to be around over the summer?
20:48 dukeleto bubaflub: this is the meta-plan: Everytime you get stuck for more than 15 minutes on one thing, create a github issue and describe it in detail, then hack on something else
20:48 atrodo NotFound> Why is winxed not a GSoC project?
20:48 dodathome left #parrot
20:48 bubaflub dukeleto: roger that.
20:48 lucian dukeleto: i thought winxed was supposed to be exactly at the same level of abstraction as pir
20:48 NotFound bubaflub: I'm always areound.
20:48 dukeleto bubaflub: when you get stuck on code, switch over to docs/tests, and vice versa
20:48 dukeleto lucian: no
20:48 dukeleto lucian: winxed is javascript-ish
20:49 dukeleto lucian: i would say the syntax sugar is sweeter in winxed
20:49 bubaflub lucian: i'd like to use Winxed because object stuff is easier than PIR
20:49 bubaflub lucian: also, syntax is a bit nicer
20:49 lucian dukeleto: sure, syntax. but i don't see how it's slower
20:49 lucian i don't see where the overhead is
20:49 dukeleto lucian: yes, we already figured that out. It comes out in the wash when you compile to bytecode
20:50 tadzik I wish pct had code generation as good as winxed
20:50 NotFound atrodo: I've not imagined any Winxed task able to be a GSoC project.
20:51 NotFound Also, Winxed is my toy, I don't want other kids playing with it ;)
20:51 lucian NotFound: rewrite everything that's PIR to Winxed?
20:51 bubaflub NotFound: ah, that's why it's on SVN (-:
20:51 atrodo NotFound> Well, that makes all my arguments to make it GSoC moot :D
20:52 NotFound bubaflub: that's just an historic accident. These guys convinced me to use svn, then they switched to git :D
20:52 bubaflub hahaha.  nice.
20:52 dukeleto NotFound: if you think of a gsoc idea, I can write it up
20:52 cotto_work NotFound: I'm not sure how you could see our use of svn as a convincing argument for its use.
20:52 dukeleto NotFound: surely there is some low-hanging-fruit that can be expanded into a 3.5 month project?
20:53 NotFound cotto_work: just because it was better than cvs.
20:53 atrodo I'm sure winxed docs could use some love
20:53 bubaflub NotFound: if you'd ever like help converting to Git on GitHub, let me know
20:53 cotto_work NotFound: ok.  It's hard to argue against that.
20:54 NotFound dukeleto: the problem is that there is no long term plan, I design features while implementing them.
20:55 bbatha joined #parrot
20:56 NotFound But if you desperately want a suggestion for a task, here is one: write a Winxed (in its actual state) compiler targeting jvm.
20:56 cotto_work NotFound: be careful.  That's what happened to PHP.
20:57 dalek tracwiki: v44 | dukeleto++ | GSoc2011
20:57 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=44&amp;action=diff
20:57 lucian NotFound: that'd involve porting lots of parrot guts, wouldn't it?
20:57 NotFound cotto_work: I don't know much PHP, but my impresion is that they designed features *after* implementig them ;)
20:58 NotFound lucian: most probably.
20:58 lucian NotFound: no, they just didn't bother
20:58 cotto_work NotFound: or that
20:58 lucian NotFound: what does this do in php: $a = array(1, 2, 3)[1];
20:59 NotFound lucian: I guess $a = 2 ?
20:59 lucian NotFound: no. it's a syntax error
20:59 lucian expressions aren't always expressions in php
20:59 NotFound Oh, nize.
21:00 lucian you have to do $v = array(1, 2, 3); $a = $v[1];
21:00 lucian when someone first told me that, i didn't believe them till i tried myself
21:00 NotFound I think winxed stage 0 still has some pitfalls like that.
21:01 NotFound And probably will ever have, but it's only a bootstrap tool.
21:03 NotFound $ winxed -e 'say([1, 2, 3][1]);' \n 2
21:04 NotFound $ winxed --stage=0 -e 'say([1, 2, 3][1]);' \n ##eval##:1: Syntax error: Expected ')' (found: '[' )
21:04 NotFound Yeah, the same :D
21:05 lucian NotFound: heh. congratulations, your throw-away compiler is as good as php's
21:05 NotFound He
21:06 lucian i'm not sure if it's praise or not
21:07 NotFound At least it can disagnose the problem.
21:08 lucian indeed. tried in php?
21:08 bubaflub lucian: php
21:08 bubaflub <?php $a = array(1, 2, 3)[1]; echo $a; ?>
21:08 bubaflub Parse error: syntax error, unexpected '[' in - on line 2
21:08 NotFound I don't think I have a php cli installed.
21:08 cotto_work probably for the best
21:10 lucian bubaflub: yeah, a bit worse
21:12 dalek tracwiki: v45 | dukeleto++ | GSoc2011
21:12 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=45&amp;action=diff
21:14 spinclad left #parrot
21:18 * dukeleto just did a lot of gsoc stuff
21:20 bubaflub dukeleto++
21:28 rohit_nsit08 left #parrot
21:31 ambs left #parrot
21:31 dalek parrot/jit_prototype: 16e2eec | bacek++ | t/compilers/opsc/21-jit-files.t:
21:31 dalek parrot/jit_prototype: Refactor test to expose "runloop" explicitely.
21:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/16e2eec407
21:31 dalek parrot/jit_prototype: dc87ca6 | bacek++ | / (2 files):
21:31 dalek parrot/jit_prototype: Add Ops::JIT.module to access generated LLVM module. Rework test to initialize engine once only
21:32 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/dc87ca6a97
21:32 bacek aloha humans
21:34 davidfetter is now known as humans
21:34 humans aloha bacek
21:34 humans is now known as davidfetter
21:34 bacek :)
21:37 bluescreen left #parrot
21:54 bubaflub left #parrot
21:56 bbatha left #parrot
21:56 perlite left #parrot
21:58 kid51 joined #parrot
21:58 perlite joined #parrot
22:00 bbatha_ joined #parrot
22:00 soh_cah_toa so i've been doing some nqp hacking to see if it's suitable for the debugger project and i have a few questions...
22:01 PacoLinux left #parrot
22:01 dukeleto soh_cah_toa: ask 'em
22:01 soh_cah_toa nqp doesn't have a traditional perl module system. you don't say "use Foo::Bar; my $for := Foo::Bar.new();" instead the objects available are the pmcs in src/pmc right?
22:02 dukeleto soh_cah_toa: in general, you don't need to ask to ask in here :)
22:02 soh_cah_toa agh, meant to say $foo
22:02 dukeleto soh_cah_toa: not quite. NQP does have a basic kind of object
22:02 dukeleto soh_cah_toa: i would read the source of Plumage (which is written in NQP) to see a nice application written on top of NQP
22:02 dukeleto soh_cah_toa: you can have "modules" in NQP
22:03 moritz nqp-rx doesn't have 'use' though
22:03 moritz (nqp does)
22:03 dukeleto soh_cah_toa: which are basically just nqp files that you "use", but it is called something different
22:03 dukeleto moritz: touche
22:03 dukeleto moritz: in either language, tho, you can "drop down" to PIR
22:03 dukeleto soh_cah_toa: ^^^
22:03 soh_cah_toa what's the difference between nqp and nqp-rx?
22:03 dukeleto soh_cah_toa: Q:PIR in nqp, iirc
22:04 dukeleto i am saying nqp to mean the newer flavor, nqp-rx
22:04 dukeleto soh_cah_toa: nqp-rx is a newer implementation of nqp that has nice features like regexen
22:04 lucian soh_cah_toa: nqp is un-cool and square
22:04 soh_cah_toa okay
22:04 dukeleto soh_cah_toa: rx stands for "regex"
22:04 dukeleto soh_cah_toa: you want to use nqp-rx
22:04 lucian soh_cah_toa: nqp-rx isn't
22:04 lucian btw, i'm finding i'm almost liking perl6. shocking, to me
22:04 tadzik well, the New nqp is nqp, not nqp-rx
22:05 dukeleto lucian: OH THE HUGE MANATEE
22:05 dukeleto tadzik: it is all very confusing
22:05 tadzik yeah
22:05 soh_cah_toa yeah me too. it still feels like a different language though
22:05 dukeleto nqp was called nqp originally, then the newer nqp was called nqp-rx, but now we are calling nqp-rx nqp and you have to say "the old nqp" to mean the nqp before nqp-rx. Can't we afford a new name?
22:05 soh_cah_toa it almost feels like another languages based off of perl
22:06 dukeleto soh_cah_toa: NQP = Not Quite Perl 6, i.e. a desugared subset of Perl 6
22:06 soh_cah_toa too many nqp's!
22:06 cotto_work "snqp"
22:06 dukeleto soh_cah_toa: so yes, it should feel perlish :)
22:06 cotto_work still not quite perl 6
22:06 lucian ENQPSTACKOVERWLOW
22:06 dukeleto cotto_work: i like where you are going with this
22:07 dukeleto yet another nqp = yanqp
22:07 soh_cah_toa another thing...the pir::new() statement. am i right in assuming that anything prefixed w/ pir:: is a pir opcode?
22:07 dukeleto soh_cah_toa: yes
22:07 lucian ENOTQUITEERROR
22:08 soh_cah_toa okay. is that just the syntax or is there a pir namspace and pir::something is it's fully qualified name?
22:09 dukeleto soh_cah_toa: it is syntax to access PIR
22:09 cotto_work It could progress.  not quite perl  6 -> still not quite perl 6 -> not entirely unlike perl 6 -> pretty close to perl 6 -> ...
22:09 dukeleto soh_cah_toa: Q:PIR { ... } means that ... is PIR and pir::xxx means you are calling the xxx PIR opcode
22:09 lucian cotto_work: scheme's towers come to mind
22:10 dukeleto my god, it's made of onions!
22:10 cotto_work dukeleto: I don't know how I feel about that op.  We had enough trouble with hcf.
22:10 soh_cah_toa okay. by the same respect, is there a Q:PASM { ... } ?
22:10 * dukeleto apologizes to Arthur C. Clarke
22:10 dukeleto soh_cah_toa: no
22:10 soh_cah_toa okay
22:10 dukeleto soh_cah_toa: humans shouldn't write PASM unless you are an unlucky person
22:11 cotto_work dukeleto: +1
22:11 soh_cah_toa everyone says that but i don't think it's that bad really
22:11 soh_cah_toa i enjoy low level stuff
22:11 dukeleto soh_cah_toa: don't ask the definition of an unlucky person, unless you want to become one :)
22:11 soh_cah_toa haha
22:11 dukeleto soh_cah_toa: that ain't the point
22:11 dukeleto soh_cah_toa: PIR is low enough. PASM is just desugarred PIR
22:11 dukeleto soh_cah_toa: it is unnecessarily painful for the developer
22:12 dukeleto soh_cah_toa: you should always code in PIR and above
22:12 dukeleto soh_cah_toa: makes sense?
22:12 soh_cah_toa aw man, so i can't do my gsoc proposal in binary?
22:12 lucian of course, personal opinion differs. i'd remove pir from the list of reasonable choices
22:12 dukeleto soh_cah_toa: for instance, you have to manually keep track of registers in PASM. You don't want to have to do that.
22:12 * dukeleto goes to the post office
22:14 lucian soh_cah_toa: however, PIR is still assembly. the fullness of that fact only hits you when you try to do some flow control
22:14 soh_cah_toa yeah, what the heck...goto's?
22:15 soh_cah_toa anywhere that goto is necessary is assembly
22:15 lucian yeah, you get goto. want something else? tough
22:16 * tcurtis doesn't consider C to be quite assembly.
22:17 * tcurtis does consider goto to be occasionally necessary for proper error handling in C.
22:17 lucian tcurtis: sure. that's C's fault :)
22:17 soh_cah_toa tcurits: yeah but goto's aren't necessary in c. they only acceptable place for them is in nested loops
22:17 lucian soh_cah_toa: actually, they're very good for interpreters
22:17 davidfetter where else would you put one? :P
22:17 soh_cah_toa really? well, i don't know much about writing interpreters
22:18 soh_cah_toa but that's why i'm here
22:18 lucian soh_cah_toa: it's intuitive. opcode dispatch means jumping around into your interpreter code, which is C
22:19 lucian you could do a switch, but it's not as straightforward or fast
22:19 * lucian doesn't know much about writing interpreters either
22:20 soh_cah_toa though i did make a c interpreter a long time ago. it was far from efficient though
22:20 tcurtis They're nice for error handling in general. Much nicer that nested ifs.
22:20 tcurtis s/that/than/
22:21 soh_cah_toa tcurtis: you mean the goto statement?
22:21 tcurtis soh_cah_toa: Yes.
22:21 darbelo As an aside. The efficient 'clever goto' technique of interpreter implementation isn't actually standard C.
22:22 soh_cah_toa hmmm...i suppose. just one if w/ several goto's inside
22:22 soh_cah_toa ahh...the age old flame war. to goto or not to goto?
22:22 darbelo It's based on 'computed gotos' which are about 30% more harmful to control flow purist :)
22:23 * lucian shoves fingers in ears and starts yelling at darbelo
22:24 soh_cah_toa ha
22:25 darbelo Although if you really want to traumatize people you can spring some of gcc's more esoteric C extensions on them.
22:25 lucian darbelo: it's in CPython as a configure option, so i mark it as ok in my head
22:26 soh_cah_toa b/c cpython said so? ;)
22:26 lucian soh_cah_toa: YEAH
22:26 lucian actually, because lots and lots of people use it in practice and it's fine
22:27 darbelo In my experience, most's people define 'portable C' as 'GCC compiles it on several platforms' :)
22:27 lucian darbelo: yep. enough for me :)
22:28 soh_cah_toa ha. yeah me too
22:28 whiteknight joined #parrot
22:28 lucian CPython does this the right way, which is nice
22:29 lucian darbelo: but in fact, i think on many compilers you get a speedup with gotos anyway
22:29 lucian even if it's not precomputed goto
22:29 soh_cah_toa all this talk of python...maybe i'll pick up a python book after gsoc.
22:30 wknight8111 joined #parrot
22:30 tcurtis soh_cah_toa: for an example of what I was talking about with C error handling using goto: https://gist.github.com/902605
22:30 lucian soh_cah_toa: i'm afraid i exude the stuff
22:30 darbelo Probably. IIRC cotto had a paper which did some comparisons on various dispatch mechanisms, computed goto was the fastest, and dumb switch was the slowest.
22:31 dalek parrot/jit_prototype: c1dbe0f | bacek++ | t/jit/jitted.ops:
22:31 dalek parrot/jit_prototype: Add PCC ops to jitted.ops.
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/c1dbe0f55e
22:31 dalek parrot/jit_prototype: ac5d73b | bacek++ | t/compilers/opsc/data/07.pir:
22:31 dalek parrot/jit_prototype: Add test for simple PCC calls.
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/ac5d73ba36
22:31 dalek parrot/jit_prototype: 50e04be | bacek++ | runtime/parrot/library/LLVM/Type.pm:
22:31 dalek parrot/jit_prototype: [llvm] Add Type.opcode_t
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/50e04bea55
22:31 dalek parrot/jit_prototype: dbdc85f | bacek++ | runtime/parrot/library/LLVM/Module.pm:
22:31 dalek parrot/jit_prototype: [llvm] Add stubs for handling Module.global
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/dbdc85f339
22:31 dalek parrot/jit_prototype: 8ab0fe5 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
22:31 dalek parrot/jit_prototype: Add few more variable and function aliases to Ops::JIT
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/8ab0fe54db
22:31 dalek parrot/jit_prototype: f5806fb | bacek++ | compilers/opsc/src/Ops/JIT.pm:
22:31 dalek parrot/jit_prototype: Implement calculation of special ops size
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/f5806fb96d
22:31 dalek parrot/jit_prototype: 1116095 | bacek++ | compilers/opsc/src/Ops/Trans/C.pm:
22:31 dalek parrot/jit_prototype: Add CUR_OPCODE define back. It's acually used
22:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/1116095f02
22:31 darbelo All of which is mostly irrelevant to parrot, since we are too slow in other places for this kind of optimization to give any sort of benefit :)
22:32 soh_cah_toa tcurits: after your labels, all you have is a function call. wouldn't it be easier to just call the function within the if block?
22:32 lucian darbelo: true. and depending on JIT style, fast interpretation might not matter
22:32 dalek parrot/opsc_llvm: 5a77625 | bacek++ | / (3 files):
22:32 dalek parrot/opsc_llvm: Revert "link libLLVM only to llvm_engine.so, not to libparrot"
22:32 dalek parrot/opsc_llvm:
22:32 dalek parrot/opsc_llvm: This reverts commit b704d9e17d9ac71c26e17e51caf43167e3b62f73.
22:32 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/5a7762539b
22:32 dalek parrot/opsc_llvm: 8cf3d99 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
22:32 dalek parrot/opsc_llvm: [llvm] Add Type.opcode_t
22:32 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/8cf3d99029
22:32 dalek parrot/opsc_llvm: 3ba281e | bacek++ | runtime/parrot/library/LLVM/Module.pm:
22:32 dalek parrot/opsc_llvm: [llvm] Add stubs for handling Module.global
22:32 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/3ba281ee92
22:33 tcurtis soh_cah_toa: I could, but I'd have to call foo_cleanup() in three places and foo_bar_cleanup in two.
22:33 pjcj left #parrot
22:33 lucian soh_cah_toa: think of it as try/catch/finally, but crap
22:34 tcurtis And in actual cases, you sometimes get more than two things that could go wrong in a single function.
22:34 darbelo Everything can go wrong in every single function :)
22:35 soh_cah_toa alright, i see your case. but then it comes back to the old "performance vs. readability" trade off
22:36 soh_cah_toa i prefer readability and let the compiler handle any optimizations
22:37 soh_cah_toa to each his own though...
22:38 soh_cah_toa on a completely different and previous subject...does anyone know what the Q in Q:PIR { ... } stands for?
22:40 tadzik Quote probably
22:40 soh_cah_toa i don't like using constructs because "that's the way it is". i like to know what i'm typing
22:40 pjcj joined #parrot
22:40 soh_cah_toa tadzik: that was my first guess
22:44 wknight8111 left #parrot
23:05 hercynium left #parrot
23:10 tcurtis soh_cah_toa: well, actually, the goto-style shouldn't be a significant performance difference. It's useful because it avoids duplicated code which is a maintainability and readability win.
23:11 bubaflub joined #parrot
23:21 * tcurtis may be excessively biased against nested if's by his use of 8-space tabs for indentation on most personal code.
23:23 sorear soh_cah_toa: yes, it stands for 'quote'
23:23 cotto_work 8-space tabs?  You think you know a guy...
23:23 cotto_work ;]
23:23 bacek_at_work ~~
23:23 dmalcolm left #parrot
23:25 tcurtis cotto_work: Truthfully, it's mostly just that I've been using vim without any configuration as my primary editor lately. :)
23:26 lucian tcurtis: that's a double-sin!
23:26 lucian first you use 8 spaces, then you don't customise vim
23:27 lucian you may require penance
23:28 tcurtis lucian: But the 8-space tabs are a consequence of the unconfigured vim.
23:29 lucian tcurtis: exactly!
23:29 lucian you're even breaking causality! :)
23:32 tcurtis :) I almost got away with it, too.
23:33 dalek parrot/lorito: 6d0e704 | cotto++ | src/dynpmc/m0ctx.pmc:
23:33 dalek parrot/lorito: make register use a little more consistent
23:33 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/6d0e704ddd
23:33 dalek parrot/lorito: 781dd89 | cotto++ | src/dynpmc/ (3 files):
23:33 dalek parrot/lorito: make m0ctx "work"
23:33 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/781dd89619
23:34 dalek parrot/lorito: bf688af | cotto++ | src/dynoplibs/m0proto.ops:
23:34 dalek parrot/lorito: add some TODOs
23:34 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/bf688af415
23:37 kid51 is now known as kid51_at_dinner
23:39 petdance joined #parrot
23:41 darbelo left #parrot
23:47 lucian left #parrot
23:48 petdance so how do I look at whiteknight/imcc_compreg_pmc ?
23:48 whiteknight all squinty-like
23:49 petdance It's a remote branch
23:49 petdance and I don't know how to look at that
23:49 whiteknight if you have git, do a git checkout whiteknight/imcc_compreg_pmc
23:49 petdance Right, I have git
23:49 petdance and I'm normally on origin/master
23:50 petdance ah, ok
23:50 petdance I'm gonna splint it
23:50 whiteknight awesome
23:50 whiteknight petdance++
23:54 mikehh petdance: I finally managed to get make splint to run - needed to set C_INCLUDE_PATH=/usr/include/i686-linux-gnu to pull in ffi.h
23:54 petdance huh, ok
23:55 mikehh I am now testing Ubuntu 11.01 beta i386 - will let you know
23:56 mikehh petdance: also I had to load Perl::Critic::Deprecated to get Perl::Critic::Bangs to work (well tests - haven't run it yet)
23:57 petdance yeah, that needs to get shipped.
23:57 petdance that's been fixed.
23:57 mikehh bah Ubuntu 11.04 beta

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

Parrot | source cross referenced