| Time |
S |
Nick |
Message |
| 00:03 |
|
tcurtis |
~~ |
| 00:22 |
|
|
kid51 left #parrot |
| 00:26 |
|
|
hercynium left #parrot |
| 00:30 |
|
|
kid51 joined #parrot |
| 00:35 |
|
kid51 |
msg Tene Please take a look at http://trac.parrot.org/parrot/ticket/88 |
| 00:35 |
|
aloha |
OK. I'll deliver the message. |
| 00:47 |
|
|
jsut joined #parrot |
| 00:47 |
|
mikehh |
kid51: I was getting a failure earlier with t/tools/dev/headerizer/01_functions.t - Failed test: 51 |
| 00:48 |
|
mikehh |
the change in the re on line 455 of lib/Parrot/Headerizer/Functions.pm is responsible for the error |
| 00:50 |
|
mikehh |
t/tools/dev/headerizer/01_functions.t gets 'PARROT_ASSERT_ARG(( _abcDEF123 )' wants 'PARROT_ASSERT_ARG(_abcDEF123)' from 'ARGFREE_NOTNULL(( _abcDEF123 )())' |
| 00:50 |
|
|
lucian left #parrot |
| 00:50 |
|
mikehh |
line 460, fails line 471 of t/tools/dev/headerizer/01_functions.t |
| 00:52 |
|
pmichaud |
yes, the problem was a caching proxy |
| 00:52 |
|
pmichaud |
I'm able to access trac now |
| 00:52 |
|
|
jsut_ left #parrot |
| 01:25 |
|
|
woosley joined #parrot |
| 01:30 |
|
|
woosley1 joined #parrot |
| 01:33 |
|
|
woosley left #parrot |
| 01:39 |
|
|
bubaflub left #parrot |
| 01:43 |
|
|
woosley1 left #parrot |
| 01:51 |
|
cotto |
~~ |
| 01:53 |
|
kid51 |
mikehh: Can you discuss that with alester/petdance? |
| 01:54 |
|
kid51 |
mikehh: I can't remember all the details of that test right now. |
| 01:54 |
|
kid51 |
It may be as simple as changing the test to match the new expected output. |
| 01:55 |
|
kid51 |
afk |
| 01:59 |
|
|
theory joined #parrot |
| 02:01 |
|
cotto |
soh_cah_toa, how's it going |
| 02:02 |
|
soh_cah_toa |
cotto: well, i made a branch but i can't seem to track it w/ a remote |
| 02:02 |
|
soh_cah_toa |
all i did was 'git branch soh-cah-toa/pdb' |
| 02:03 |
|
cotto |
does git branch tell you that you're on that branch? |
| 02:03 |
|
soh_cah_toa |
yeah |
| 02:03 |
|
soh_cah_toa |
oh wait, i did a checkout -b. sorry |
| 02:04 |
|
cotto |
ok. That's what I usually do. |
| 02:05 |
|
cotto |
What's the problem? |
| 02:06 |
|
soh_cah_toa |
'git checkout -b soh-cah-toa/pdb origin/soh-cah-toa/pdb' complains: |
| 02:06 |
|
soh_cah_toa |
fatal: git checkout: updating paths is incompatible with switching branches. |
| 02:06 |
|
soh_cah_toa |
Did you intend to checkout 'frontend/pdb/origin/soh-cah-toa/pdb' which can not be resolved as commit? |
| 02:07 |
|
|
theory left #parrot |
| 02:07 |
|
cotto |
is there an origin/soh-cah-toa/pdb? |
| 02:07 |
|
cotto |
or are you starting a new branch |
| 02:08 |
|
soh_cah_toa |
i don't know. i'm just doing what docs/project/git_workflow.pod said to do |
| 02:09 |
|
cotto |
You just want to create a branch. You can push it later. |
| 02:10 |
|
soh_cah_toa |
alright. so i have a new branch then |
| 02:10 |
|
kid51 |
git checkout -b soh-cah-toa/pdb ... should suffice |
| 02:10 |
|
soh_cah_toa |
kid51: yeah |
| 02:16 |
|
soh_cah_toa |
cotto: you mentioned that i had to modify interpreter.h. well, i was looking around and cores.c doesn't #include this file yet it uses the constants defined in it. how is that possible? |
| 02:17 |
|
soh_cah_toa |
oh wait...i think it's included indirectly using parrot/embed.h |
| 02:18 |
|
cotto |
soh_cah_toa, yes. It's included indirectly. |
| 02:18 |
|
cotto |
I don't recommend tracing it out unless something goes wrong. |
| 02:19 |
|
cotto |
There are more interesting ways to spend your time. ;) |
| 02:19 |
|
soh_cah_toa |
well, i wasn't sure how to include it w/ my runcore |
| 02:21 |
|
cotto |
soh_cah_toa, you don't need a new file. Just use cores.c |
| 02:21 |
|
soh_cah_toa |
yeah but the code in functions like Parrot_runcore_fast_init() uses things i need in those headers |
| 02:22 |
|
soh_cah_toa |
i was just copying the functions i needed |
| 02:22 |
|
cotto |
Ah. That should be accessible after you run headerizer |
| 02:23 |
|
soh_cah_toa |
h/o...so if i call a function defined in a header that i didn't include, headerizer will #include it for me? |
| 02:23 |
|
cotto |
not quite |
| 02:24 |
|
soh_cah_toa |
agh...i knew it was too good to be true :) |
| 02:24 |
|
cotto |
headerizer looks at the functions you have defined and puts their prototypes in the right places |
| 02:24 |
|
cotto |
either headers or at the beginning of the file where they're defined |
| 02:26 |
|
soh_cah_toa |
hmm...ok |
| 02:37 |
|
soh_cah_toa |
cotto: how can i make it so that you can see my branch? i wanna make sure i did this right so far |
| 02:39 |
|
cotto |
soh_cah_toa, do you have a fork of parrot on github? If so, git push origin branchnamehere should work |
| 02:40 |
|
cotto |
my brain am tired |
| 02:40 |
|
soh_cah_toa |
alright, i'll try that |
| 02:44 |
|
soh_cah_toa |
wait...i made this branch off of parrot/parrot though |
| 02:47 |
|
soh_cah_toa |
should i re-branch from my github fork? i'm not too sure of the difference between github forks and git branches |
| 02:48 |
|
cotto |
I don't think that'll be necessary. |
| 02:48 |
|
soh_cah_toa |
alright but i don't think i can do a 'git push origin soh-cah-toa/pdb' w/o a commit bit |
| 02:48 |
|
cotto |
right |
| 02:49 |
|
benabik |
soh_cah_toa: You should bee able to do something like `git remote add github github_URL` |
| 02:49 |
|
|
bubaflub joined #parrot |
| 02:49 |
|
soh_cah_toa |
benabik: ok |
| 02:52 |
|
soh_cah_toa |
hmmm...it seemed to work but i'm not seeing anything on github |
| 02:53 |
|
benabik |
soh_cah_toa: You then can `git push github branch`. Adding the remote just adds the shortcut. |
| 02:53 |
|
cotto |
looks like your clone got updated |
| 02:53 |
|
soh_cah_toa |
i did 'git push github' and then tried 'git push github soh-cah-toa/pdb' |
| 02:53 |
|
cotto |
er, fork |
| 02:54 |
|
benabik |
I do see a soh-cah-toa/pdb branch on github |
| 02:55 |
|
soh_cah_toa |
benabik: branch from parrot/parrot.git or soh-cah-toa/parrot.git? |
| 02:55 |
|
kid51 |
http://parrot.org/content/i-think-its-time-break : A well-written blog post |
| 02:55 |
|
cotto |
soh_cah_toa, looks like you did something |
| 02:55 |
|
soh_cah_toa |
kid51: thanks |
| 02:55 |
|
|
mtk left #parrot |
| 02:55 |
|
benabik |
soh_cah_toa: In soh-cah-toa/parrot.git |
| 02:55 |
|
soh_cah_toa |
hmm... |
| 02:55 |
|
kid51 |
I will have to re-read it as it is showing me things about debuggers I never knew. |
| 02:56 |
|
|
kid51 left #parrot |
| 02:57 |
|
soh_cah_toa |
well, i see my commit w/ 'git log' but nothing on github. parrot/parrot or soh-cah-toa/parrot |
| 02:58 |
|
cotto |
soh_cah_toa, it |
| 02:58 |
|
cotto |
's there. Look at your branch. |
| 02:58 |
|
soh_cah_toa |
https://github.com/soh-cah-toa/parrot |
| 02:58 |
|
soh_cah_toa |
there? |
| 02:59 |
|
cotto |
https://github.com/soh-cah-toa[…]15b91e9d415b253b1 |
| 02:59 |
|
soh_cah_toa |
b/c that's what i'm looking at |
| 02:59 |
|
cotto |
or https://github.com/soh-cah-toa[…]soh-cah-toa%2Fpdb |
| 03:00 |
|
soh_cah_toa |
oh yeah. wow, that took longer than usual |
| 03:01 |
|
cotto |
btw, I'd recommend against the name "pdb". It has collisions with other debuggers. |
| 03:01 |
|
soh_cah_toa |
yeah, i was worried about that |
| 03:01 |
|
cotto |
that's why we have "parrot_debugger" |
| 03:02 |
|
|
mtk joined #parrot |
| 03:02 |
|
soh_cah_toa |
parrot_debugger seems like too long though. plus i kinda like one word commands w/ no underscores/hyphens |
| 03:02 |
|
soh_cah_toa |
if i have too, i will though |
| 03:02 |
|
cotto |
I appreciate the laziness, especially since you'll be typing it often. |
| 03:02 |
|
soh_cah_toa |
i'm i KISS type of guy |
| 03:03 |
|
cotto |
keep it stupid, stupid? |
| 03:03 |
|
cotto |
;) |
| 03:03 |
|
soh_cah_toa |
ha |
| 03:05 |
|
soh_cah_toa |
if i went the other route of making up a unique name (maybe a bird name, keeping things close), then people may not realize that that's the debugger |
| 03:05 |
|
soh_cah_toa |
hmmm...decisions... |
| 03:06 |
|
cotto |
"debugger_for_parrot_programs" |
| 03:06 |
|
soh_cah_toa |
no confusing that w/ anything else |
| 03:07 |
|
benabik |
d4pp? |
| 03:08 |
|
soh_cah_toa |
numbers in an acronym?! agh! |
| 03:08 |
|
cotto |
this isn't php |
| 03:08 |
|
soh_cah_toa |
you will soon see that i am very anal about style conventions |
| 03:08 |
|
soh_cah_toa |
i have an extreme hatred of things like camel case |
| 03:09 |
|
soh_cah_toa |
i like old school unix style naming conventions short and hard to tell what it stands for |
| 03:10 |
|
soh_cah_toa |
like strpbrk |
| 03:10 |
|
|
particle left #parrot |
| 03:10 |
|
cotto |
perfect. |
| 03:10 |
|
cotto |
ship it |
| 03:11 |
|
soh_cah_toa |
actually, i was talking about the c function :) |
| 03:11 |
|
soh_cah_toa |
how its hard to tell what it stands for. lol |
| 03:11 |
|
|
particle joined #parrot |
| 03:12 |
|
soh_cah_toa |
i've searched far and wide and still don't know what strpbrk() stands for |
| 03:13 |
|
soh_cah_toa |
anyway, i digress. does my code look ok? i don't think headerizer did anything |
| 03:14 |
|
cotto |
soh_cah_toa, I'd put the runcore code in src/runcore/cores.c with the other similar code. The frontend doesn't need any special access to decide which runcore to use. |
| 03:15 |
|
soh_cah_toa |
i just put it there b/c the old debugger was there. i'll fix it |
| 03:15 |
|
soh_cah_toa |
ahh...alright. things are starting to make a little more sense |
| 03:15 |
|
cotto |
note that the old debugger only has main.c in frontend/ |
| 03:17 |
|
soh_cah_toa |
right. now i see that even though i may have my own runcore, parrot still needs to "know" about it |
| 03:17 |
|
cotto |
I'm glad it's starting to make sense. |
| 03:18 |
|
sorear |
soh_cah_toa: I'm pretty sure strpbrk dates from the times when only the first 6 characters in function names were significant |
| 03:20 |
|
soh_cah_toa |
sorear: right |
| 03:20 |
|
cotto |
That was before people had spent decades looking at "creat" |
| 03:20 |
|
soh_cah_toa |
agh! don't get me started |
| 03:20 |
|
soh_cah_toa |
they couldn't just add the extra e?! just one little e?! |
| 03:21 |
|
cotto |
There's a funny commit to "go". |
| 03:21 |
|
cotto |
http://code.google.com/p/go/so[…]c23558b3c480d995f |
| 03:22 |
|
soh_cah_toa |
ha! |
| 03:22 |
|
tcurtis |
soh_cah_toa: http://stackoverflow.com/quest[…]-stand-for/501007 |
| 03:23 |
|
soh_cah_toa |
tcurits: string pointer break? what the heck does that have to do w/ string searching? nothing's "breaking" |
| 03:25 |
|
soh_cah_toa |
cotto: that reminds me. i wanted to mention go. there's been lots of talk about concurrency and i've heard that go implements concurrency quite well. i was wondering if anybody had ever considered looking at go for guidance |
| 03:25 |
|
cotto |
soh_cah_toa, I don't think there's any place we're not glad to steal good ideas from. |
| 03:26 |
|
cotto |
Whether someone's tried I'm not sure. |
| 03:26 |
|
tcurtis |
soh_cah_toa: I believe the idea is that when you see one of the characters, you stop searching or "break". |
| 03:27 |
|
soh_cah_toa |
cotto: i should probably mention it to whiteknight |
| 03:27 |
|
cotto |
soh_cah_toa, sure. If you have a more concrete suggestion, even better. |
| 03:27 |
|
soh_cah_toa |
tcurtis: hmm...it's a far stretch but i can see it |
| 03:27 |
|
cotto |
he's a busy fellow |
| 03:27 |
|
soh_cah_toa |
yeah, no kidding |
| 03:29 |
|
bubaflub |
note to GSoC-ers, all the tax paperwork is due to Google tomorrow |
| 03:29 |
|
soh_cah_toa |
bubaflub: already done. proof of enrollment too |
| 03:29 |
|
bubaflub |
soh_cah_toa++ |
| 03:30 |
|
bubaflub |
it's not a big deal if it's not in, it'll just delay the initial payment till the mid-term |
| 03:30 |
|
dalek |
website: bubaflub++ | Introducing Parrot-GMP |
| 03:30 |
|
dalek |
website: http://www.parrot.org/content/[…]ducing-parrot-gmp |
| 03:30 |
|
soh_cah_toa |
bubaflub: you're a gsoc student too, right? |
| 03:30 |
|
bubaflub |
soh_cah_toa: yep |
| 03:31 |
|
bubaflub |
soh_cah_toa: just uploading my tax forms |
| 03:31 |
|
tcurtis |
soh_cah_toa: quite a stretch, but well... 6 character guaranteed significant in external identifiers doesn't give you a lot of room for self-descriptive names. |
| 03:31 |
|
soh_cah_toa |
tcurits: yeah, there is a bit of a trade off |
| 03:32 |
|
sorear |
yeah, naming all your external identifiers Parrot_api_x_y_z is a non-starter |
| 03:32 |
|
* soh_cah_toa |
bits tongue very hard |
| 03:36 |
|
soh_cah_toa |
cotto: is it worth making my own runcore if it's just an exact copy of the fast runcore? i mean, will i be making a customizations the runcore that make it distinct from the fast runcore? |
| 03:36 |
|
cotto |
soh_cah_toa, you'll definitely be making customizations. |
| 03:37 |
|
soh_cah_toa |
cotto: ok |
| 03:40 |
|
sorear |
why? |
| 03:41 |
|
soh_cah_toa |
sorear: why what? |
| 03:41 |
|
sorear |
why to cotto. |
| 03:42 |
|
cotto |
sorear, he'll need a custom runcore so the debugger can implement breakpoints and other debuggery things |
| 03:48 |
|
soh_cah_toa |
cotto: ok, i think i got it right this time. you tell me |
| 03:48 |
|
* cotto |
looks |
| 03:49 |
|
cotto |
soh_cah_toa, looks about right |
| 03:49 |
|
soh_cah_toa |
cotto: good |
| 03:49 |
|
cotto |
did you get headerizer working or did you add the function declarations manually? |
| 03:49 |
|
soh_cah_toa |
cotto: headerizer |
| 03:50 |
|
cotto |
good. It can be fiddly sometimes but overall it's better than doing that stuff manually. |
| 03:50 |
|
soh_cah_toa |
cotto: definitely |
| 03:51 |
|
soh_cah_toa |
cotto: btw, is it alright if i msg you will you're at work. i don't wanna distract you too much |
| 03:52 |
|
soh_cah_toa |
*while |
| 03:52 |
|
cotto |
soh_cah_toa, I'll let you know if I'm too busy. I'm fortunate to work at a very oss-friendly company. |
| 03:53 |
|
cotto |
As long as I get what I need to do done, they don't mind if I do some parrot stuff. |
| 03:53 |
|
soh_cah_toa |
cotto: that's really awesome |
| 03:54 |
|
cotto |
If the main language weren't PHP it'd be perfect. |
| 03:55 |
|
cotto |
as it is, it'd still take something really amazing to lure me away |
| 03:56 |
|
soh_cah_toa |
cotto: that's so cool. that's definitely my #1 requirement for a job once i'm finished w/ school: foss-friendly |
| 03:57 |
|
soh_cah_toa |
cotto: another thing...i never know when to msg "cotto" or "cotto_work". i seems like you're always on both. does it matter which i msg? you're in a different time zone than me so i don't know when you're working |
| 03:58 |
|
cotto |
soh_cah_toa, GSoC will help then. The good companies will look favorably on GSoC. |
| 03:58 |
|
cotto |
soh_cah_toa, I have both irc clients blink for both names. If you ping one here and I'm around, I'll see it. |
| 03:59 |
|
* tcurtis |
was surprised by how impressed $dayjob seemed by GSoC when he interviewed for it. |
| 04:01 |
|
cotto |
It's good experience with a real software project and effectively demonstrates a certain level of competence. |
| 04:02 |
|
sorear |
maybe next year I'll get in... |
| 04:02 |
|
soh_cah_toa |
i don't think there's any downside to gsoc |
| 04:02 |
|
sorear |
cotto: I take objection to the idea that breakpoints require a custom runcore |
| 04:03 |
|
tcurtis |
sorear: did you apply for it this year? |
| 04:03 |
|
sorear |
tcurtis: no, couldn't find a project |
| 04:03 |
|
cotto |
sorear, what would you suggest? There are certainly other possibilities. |
| 04:03 |
|
sorear |
cotto: using the fast runcore |
| 04:04 |
|
cotto |
sorear, but what tells the interp when to break? |
| 04:04 |
|
sorear |
same thing that every real debugger uses |
| 04:04 |
|
sorear |
a "breakpoint" opcode |
| 04:04 |
|
soh_cah_toa |
yes! |
| 04:04 |
|
|
silug left #parrot |
| 04:05 |
|
sorear |
which generates some kind of resumable control exception |
| 04:05 |
|
sorear |
and/or hands control to a different interp a la parrot-instrument |
| 04:06 |
|
sorear |
we *do* need a special function that can single-step a context |
| 04:10 |
|
soh_cah_toa |
agh...i so wanna be a part of this conversation but i really gotta head off. i'll just check out the irc log tomorrow. cotto, that's the other thing i wanted to talk about - a debug opcode. we'll talk tomorrow. hasta la pasta! |
| 04:10 |
|
|
soh_cah_toa left #parrot |
| 04:23 |
|
|
bubaflub left #parrot |
| 04:28 |
|
sorear |
cotto: other than the runcores themselves, does anything in Parrot want to parse Packfile_Segments in memory? |
| 04:28 |
|
sorear |
pbc_merge and pbc_disassemble don't count because they work only on .pbc files, and the debugger won't modify those |
| 04:36 |
|
cotto |
sorear, why do you ask? |
| 04:38 |
|
cotto |
and by "parse in memory", do you mean parse the contents of a pbc? |
| 04:40 |
|
|
fperrad joined #parrot |
| 04:43 |
|
|
fperrad_ joined #parrot |
| 04:47 |
|
|
fperrad left #parrot |
| 04:47 |
|
|
fperrad_ is now known as fperrad |
| 04:57 |
|
|
jevin left #parrot |
| 04:58 |
|
|
jevin joined #parrot |
| 04:58 |
|
sorear |
on second thought, it doesn't matter |
| 04:59 |
|
sorear |
with x86 debuggers, it's conventional to overwrite the first byte of an instruction (of unknown length) with 0xCC, and leave the rest as invalid opcode data |
| 05:00 |
|
sorear |
but with Parrot it wouldn't be unreasonable to overwrite an n opcode_t instruction with n copies of the breakpoint opcode |
| 05:00 |
|
cotto |
It seems easier to have a specialized runcore. |
| 05:01 |
|
cotto |
I don't see the advantage of overwriting opcodes. |
| 05:02 |
|
cotto |
I guess it'd be handy if you didn't want to switch runcores or had a running program you wanted to debug. |
| 05:07 |
|
sorear |
that, and it's much faster |
| 05:07 |
|
sorear |
no overhead in breakpoint-free code |
| 05:08 |
|
sorear |
if you use a custom runcore, you need a *fast* set data structure to remember where the breakpoints are set |
| 05:11 |
|
|
fperrad_ joined #parrot |
| 05:13 |
|
dukeleto |
~~ |
| 05:13 |
|
|
fperrad left #parrot |
| 05:13 |
|
|
fperrad_ is now known as fperrad |
| 05:15 |
|
cotto |
hi dukeleto |
| 05:15 |
|
dukeleto |
cotto: howdy |
| 05:17 |
|
dukeleto |
cotto: what are you up to? |
| 05:19 |
|
cotto |
dukeleto, looking at M0 ops and trying to figure out what I was thinking. |
| 05:19 |
|
|
fperrad left #parrot |
| 05:20 |
|
cotto |
also looking at how parrot parses cli options and thinking about how to turn it into something reusable |
| 05:26 |
|
cotto |
dukeleto, I'm thinking that mapping a chunk name to a chunk number should be a separate operation from transferring control flow to that chunk. |
| 05:27 |
|
cotto |
Is that sane, and if so what'd be a good name for the op? |
| 05:29 |
|
|
fperrad joined #parrot |
| 05:30 |
|
sorear |
Why? |
| 05:31 |
|
|
theory joined #parrot |
| 05:32 |
|
dukeleto |
cotto: why should it be a seperate operation? |
| 05:32 |
|
dukeleto |
cotto: what is the use case? |
| 05:34 |
|
Tene |
cotto: explain more about what you're trying to do with cli options? |
| 05:36 |
|
cotto |
dukeleto, my assumption was that a chunk index would be the primary means of indicating which chunk control flow should be transferred to. That may not be necessary. |
| 05:36 |
|
Tene |
aloha: msg kid51 I'll try to do that this weekend. |
| 05:36 |
|
aloha |
Tene: OK. I'll deliver the message. |
| 05:36 |
|
cotto |
Tene, I'm thinking about how to make a separate frontend for parrot that knows about profiling-specific options and passes anything else to the normal frontend. |
| 05:36 |
|
|
theory left #parrot |
| 05:38 |
|
cotto |
dukeleto, it actually might make more sense to say that chunk indicies are an implementation detail and that names are the only way to find a chunk. |
| 05:39 |
|
dukeleto |
cotto: i think i like that chunks are identified by their globally unique name only |
| 05:39 |
|
dukeleto |
cotto: and, during parsing, we bomb out if a chunk name is not unique |
| 05:41 |
|
sorear |
cotto: I think you have a combinatorial explosion problem there |
| 05:41 |
|
sorear |
cotto: since we'll also eventually want options that are specific per GC core (nursery size, etc) |
| 05:42 |
|
sorear |
it would be better, I think, to have some kind of metasyntax like --gc-OPTION=VALUE, --run-OPTION=VALUE |
| 05:42 |
|
cotto |
sorear, it's clunky but that might be the best option. |
| 05:42 |
|
sorear |
-Rprof --run-output-file=/path --run-profile-insns=yes |
| 05:44 |
|
cotto |
it's either that, separate frontends, environment variables or a config file |
| 05:45 |
|
cotto |
or a bunch of options that don't apply in all cases but still clutter up the namespace |
| 05:48 |
|
cotto |
a more general way of giving gcs and runcores specific options would be helpful |
| 05:53 |
|
dalek |
parrot/m0-spec: 34d07ac | cotto++ | docs/pdds/draft/pdd32_m0.pod: |
| 05:53 |
|
dalek |
parrot/m0-spec: simplify goto_cs |
| 05:53 |
|
dalek |
parrot/m0-spec: review: https://github.com/parrot/parr[…]commit/34d07ac9dd |
| 05:53 |
|
dalek |
parrot/m0-spec: ef3e7cf | cotto++ | docs/pdds/draft/pdd32_m0.pod: |
| 05:53 |
|
dalek |
parrot/m0-spec: add a note about chunk names |
| 05:53 |
|
dalek |
parrot/m0-spec: review: https://github.com/parrot/parr[…]commit/ef3e7cfd39 |
| 05:55 |
|
sorear |
cotto: consider -Rprof,out=/path,insns=yes |
| 06:01 |
|
cotto |
sorear, I was thinking of something not too different from that |
| 06:02 |
|
cotto |
I still don't like the big long string of junk, but that's what alias is for. |
| 06:05 |
|
sorear |
also think about how this will interact with fakecutables |
| 06:05 |
|
sorear |
hmm. |
| 06:06 |
|
sorear |
if we can make creating interps really cheap, then we could let fakecutables parse their own command line |
| 06:06 |
|
cotto |
that meshes with whiteknight's eventual plan of moving option parsing to pir |
| 06:06 |
|
sorear |
then Rakudo could implement S19 style ++PROFILER ++/PROFILER options and translate them |
| 06:25 |
|
|
silug joined #parrot |
| 06:30 |
|
|
fperrad_ joined #parrot |
| 06:33 |
|
|
fperrad left #parrot |
| 06:33 |
|
|
fperrad_ is now known as fperrad |
| 06:40 |
|
|
fperrad left #parrot |
| 06:40 |
|
|
davidfetter joined #parrot |
| 06:43 |
|
|
fperrad joined #parrot |
| 06:45 |
|
|
mikehh left #parrot |
| 06:53 |
|
|
ShaneC joined #parrot |
| 06:54 |
|
|
silug left #parrot |
| 07:18 |
|
|
mj41 joined #parrot |
| 07:28 |
|
|
baest_ joined #parrot |
| 07:29 |
|
|
baest_ left #parrot |
| 07:31 |
|
|
baest left #parrot |
| 07:34 |
|
bacek |
~~ |
| 07:34 |
|
|
mikehh joined #parrot |
| 07:49 |
|
|
rurban_ joined #parrot |
| 07:50 |
|
|
baest_ joined #parrot |
| 07:52 |
|
|
rurban left #parrot |
| 07:53 |
|
|
rurban_ is now known as rurban |
| 07:56 |
|
tadzik |
good morning |
| 08:46 |
|
|
Kulag left #parrot |
| 08:58 |
|
dalek |
TT #2119 created by mikehh++: t/tools/dev/headerizer/01_functions.t failure |
| 08:58 |
|
dalek |
TT #2119 : http://trac.parrot.org/parrot/ticket/2119 |
| 09:29 |
|
|
silug joined #parrot |
| 10:04 |
|
|
fperrad left #parrot |
| 10:11 |
|
|
silug left #parrot |
| 10:26 |
|
|
jsut_ joined #parrot |
| 10:31 |
|
|
jsut left #parrot |
| 10:42 |
|
|
mtk left #parrot |
| 10:50 |
|
|
mtk joined #parrot |
| 10:57 |
|
|
Coke left #parrot |
| 10:57 |
|
|
Coke joined #parrot |
| 11:02 |
|
|
Psyche^ joined #parrot |
| 11:06 |
|
|
SHODAN joined #parrot |
| 11:07 |
|
|
Patterner left #parrot |
| 11:07 |
|
|
Psyche^ is now known as Patterner |
| 11:08 |
|
dalek |
parrot: 6e704bd | NotFound++ | src/pmc/unmanagedstruct.pmc: |
| 11:08 |
|
dalek |
parrot: don't return NULL STRING* from vtable functions, use STRINGNULL |
| 11:08 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/6e704bdd25 |
| 11:22 |
|
|
lucian joined #parrot |
| 12:12 |
|
|
whiteknight joined #parrot |
| 12:20 |
|
|
mtk left #parrot |
| 12:26 |
|
|
mtk joined #parrot |
| 12:37 |
|
whiteknight |
good morning, #parrot |
| 12:39 |
|
|
Kulag joined #parrot |
| 12:40 |
|
|
silug joined #parrot |
| 12:48 |
|
tadzik |
good afternoon whiteknight |
| 12:55 |
|
whiteknight |
hello tadzik. how are you doing today? |
| 12:55 |
|
|
ambs joined #parrot |
| 12:58 |
|
tadzik |
not bad, Javacoding atm |
| 12:58 |
|
whiteknight |
oh, fun |
| 13:03 |
|
tadzik |
yeah, pretty much. Even more because I couldn't stand jUnit in TDD so I wrote my TAP-friendly package :) |
| 13:04 |
|
|
theory joined #parrot |
| 13:05 |
|
|
fperrad joined #parrot |
| 13:13 |
|
|
bubaflub joined #parrot |
| 13:13 |
|
benabik |
Good morning, #parrot! |
| 13:15 |
|
* benabik |
is finally done with finals! |
| 13:16 |
|
bubaflub |
morning benabik |
| 13:16 |
|
bubaflub |
benabik: how did the finals go? |
| 13:17 |
|
whiteknight |
msg cotto I'm without internet at home for at least a few days, so no hacking (that I can push) for a while. |
| 13:17 |
|
aloha |
OK. I'll deliver the message. |
| 13:19 |
|
benabik |
bubaflub: Pretty good, although I realized I made a stupid mistake on the way out the door. |
| 13:21 |
|
benabik |
bubaflub: Oh, and Rakudo people were discussing using GMP yesterday, so you already have people looking forward to your project. :-D |
| 13:21 |
|
bubaflub |
benabik: cool. maybe i should hang in #perl6 |
| 13:49 |
|
|
theory left #parrot |
| 13:50 |
|
lucian |
allison: ping |
| 13:56 |
|
sorear |
hellloooo benabik ! |
| 13:56 |
|
benabik |
helllooooo sorear! |
| 14:06 |
|
* whiteknight |
just had a total animaniacs deja vu moment |
| 14:09 |
|
|
SHODAN left #parrot |
| 14:10 |
|
|
davidfetter left #parrot |
| 14:21 |
|
|
theory joined #parrot |
| 14:43 |
|
|
theory left #parrot |
| 14:44 |
|
|
davidfetter joined #parrot |
| 14:58 |
|
|
theory joined #parrot |
| 15:00 |
|
dukeleto |
~~ |
| 15:01 |
|
dukeleto |
benabik++ # done with pesky skool stuff |
| 15:03 |
|
dalek |
Heuristic branch merge: pushed 143 commits to parrot/leto/embed_grant by leto |
| 15:10 |
|
cotto |
whiteknight, lame sauce |
| 15:10 |
|
whiteknight |
cotto: tell me about it |
| 15:11 |
|
whiteknight |
I think the lawnmower guy cut the cable yesterday |
| 15:11 |
|
whiteknight |
why the cable was in a place that the lawnmower guy would have access to it, I don't know |
| 15:12 |
|
atrodo |
whiteknight> efficiency |
| 15:12 |
|
* cotto |
hands whiteknight a roll of duct and MacGyver on DVD. |
| 15:12 |
|
atrodo |
cable goes better when exposed to air |
| 15:12 |
|
atrodo |
s/better/faster/ |
| 15:12 |
|
cotto |
er, duct tape |
| 15:12 |
|
whiteknight |
I don't even know if it was the lawnmower guy or not. I only suspect it because of the timing |
| 15:12 |
|
whiteknight |
it could easily be something else weather-related |
| 15:13 |
|
whiteknight |
in any case, I was home yesterday most of the day without internet access, and have about two dozen commits that are unpushed |
| 15:13 |
|
cotto |
whiteknight, you can use git bundle and a thumb drive |
| 15:14 |
|
cotto |
http://progit.org/2010/03/10/bundles.html |
| 15:14 |
|
whiteknight |
yeah, I could do a lot of stuff |
| 15:14 |
|
whiteknight |
I'm thinking instead I might "go outside" and get some "sunlight" |
| 15:15 |
|
whiteknight |
things my wife always talks about, but never does either |
| 15:15 |
|
cotto |
That's also a fine option. |
| 15:18 |
|
|
dod left #parrot |
| 15:18 |
|
|
davidfetter left #parrot |
| 15:19 |
|
dalek |
winxed: r1015 | NotFound++ | trunk/examples/Mysql.winxed: |
| 15:19 |
|
dalek |
winxed: rearrange and improve encoding handling and add a command line option to specify |
| 15:19 |
|
dalek |
winxed: encoding in example Mysql |
| 15:19 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]rce/detail?r=1015 |
| 15:19 |
|
dalek |
website: benabik++ | GSoC 0: School's Out For Summer |
| 15:19 |
|
dalek |
website: http://www.parrot.org/content/[…]chools-out-summer |
| 15:21 |
|
sorear |
cotto: did MacGyver ever have to deal with RF/microwave transmission lines? |
| 15:22 |
|
whiteknight |
I think it's fiber optic |
| 15:22 |
|
cotto |
sorear, probably |
| 15:25 |
|
|
theory left #parrot |
| 15:26 |
|
|
theory joined #parrot |
| 15:28 |
|
cotto |
whiteknight, sorear had that idea that instead of having a specialized frontend for the profiling runcore, we should figure out a metasyntax that allows arbitrary options to be passed to specific subsystems (e.g. gc, runcore) |
| 15:30 |
|
cotto |
something like --Rprofiling:foo=buz:quux=frub |
| 15:31 |
|
cotto |
s/--// |
| 15:31 |
|
cotto |
s/--/-/ |
| 15:31 |
|
cotto |
stupid fingers not cooperating |
| 15:33 |
|
whiteknight |
we could do that. It sounds like a job that is extremely well suited to being written in PIR |
| 15:33 |
|
whiteknight |
although I have no idea how we would go about doing that |
| 15:34 |
|
sorear |
I also had the idea that fakecutables could have a special "parse options" entry point, which is invoked in an "early interpreter", which then creates the "real interpreter" using a parrot-instrument like reflection API |
| 15:34 |
|
|
mj41 left #parrot |
| 15:34 |
|
sorear |
then cotto told me that whiteknight was already wanting to do argument parsing in PIR |
| 15:34 |
|
whiteknight |
sorear: yes, we've kicked around that idea in the past as well |
| 15:34 |
|
whiteknight |
sorear: yes, I would love to do an entire entry program in PIR. like a _crt0 kind of function |
| 15:35 |
|
whiteknight |
we have tools in PIR for loading bytecodes, parsing options, handling exceptions etc. Right now we do all that in C and it's a bear |
| 15:35 |
|
whiteknight |
doing Parrot-related stuff in PIR is the most natural vector for it |
| 15:38 |
|
whiteknight |
look at the code in frontend/parrot/main.c, and tell me most of that crap wouldn't be much better written in PIR |
| 15:38 |
|
whiteknight |
instead of having a natural exception handler, we have to check every single API call for exceptional exit |
| 15:40 |
|
cotto |
You could even cheat and only invoke a second interpreter if the first one gets passed something that needs to be fiddle with interp initialization |
| 15:42 |
|
NotFound |
whiteknight: you can make it simpler by using Parrot_ext_try |
| 15:42 |
|
cotto |
whiteknight, what kind of commits do you have at home? |
| 15:43 |
|
dukeleto |
bubaflub: did you blog yet? |
| 15:44 |
|
bubaflub |
dukeleto: yessir |
| 15:44 |
|
bubaflub |
dukeleto: http://www.parrot.org/content/[…]ducing-parrot-gmp |
| 15:45 |
|
dukeleto |
bubaflub++ |
| 15:45 |
|
dukeleto |
benabik++ |
| 15:45 |
|
dukeleto |
a bloggin' we go |
| 15:45 |
|
sorear |
The main worry I have is that if $USER needs to use $OPTION because in $SITUATION default interpreter initialization fails, we've got a problem |
| 15:45 |
|
NotFound |
Thinking better about it, no, using Parrot_ext_try and functions available for etensions defeats the purpose of being purely embedding interface. |
| 15:46 |
|
dukeleto |
bubaflub: suggestions: add links to your CPAN and github accounts in your blog posts that you mention |
| 15:46 |
|
dukeleto |
bubaflub: links makes the world go around |
| 15:46 |
|
bubaflub |
dukeleto: i'll do that now |
| 15:46 |
|
dukeleto |
bubaflub: and spell out GMP the first time |
| 15:46 |
|
dukeleto |
bubaflub: some people aren't math nerds like us :) |
| 15:47 |
|
bubaflub |
dukeleto: poor people |
| 15:47 |
|
bubaflub |
dukeleto: er, not financially poor, but pitiable people |
| 15:48 |
|
dukeleto |
bubaflub: lulz. Only professorial mathematicians take the vow of poverty. I am part of the 10% of mathematicians that reject that antiquated notion :) |
| 15:48 |
|
dukeleto |
bubaflub: good blog post. did you post to gmp-discuss ? |
| 15:48 |
|
bubaflub |
dukeleto: yep. got my answers. |
| 15:49 |
|
dukeleto |
benabik: i see you are a "cleaned up history" kind of dude :) |
| 15:50 |
|
|
rurban_ joined #parrot |
| 15:50 |
|
benabik |
dukeleto: `git rebase -i` is your friend. :-D |
| 15:51 |
|
cotto |
sorear, can you think of an example? |
| 15:51 |
|
dukeleto |
benabik: i use it lovingly, like a bar of soap... |
| 15:52 |
|
sorear |
cotto: dunno, working around systems idiocy maybe |
| 15:52 |
|
dukeleto |
bubaflub: looks like supporting GMP 4.2.x - 5.x is a good thing to shoot for |
| 15:52 |
|
|
rurban left #parrot |
| 15:52 |
|
bubaflub |
dukeleto: agreed |
| 15:52 |
|
|
rurban_ is now known as rurban |
| 15:52 |
|
dukeleto |
bubaflub: whoever wants it to work on 4.1.x can provide the small patch :) Don't worry about supporting old arcane versions. |
| 15:53 |
|
sorear |
cotto: like say the next version of SELinux decides to disable our default runcore, and $USER wants to play with an old Parrot (from before we implemented workarounds on our end) |
| 15:53 |
|
* lucian |
begins to hate pmc2c |
| 15:54 |
|
dukeleto |
in slightly un-related news, I slayd the dependency hobgoblin yesterday: https://github.com/bioperl/bio[…]33a79bc60cdbaa5d6 |
| 15:54 |
|
dukeleto |
lucian: welcome to the club? |
| 15:55 |
|
lucian |
dukeleto: i'll leave my bike outside, wait a tick |
| 15:57 |
|
* dukeleto |
paints the bikeshed a new coat of clear |
| 15:57 |
|
|
alester joined #parrot |
| 15:58 |
|
whiteknight |
lucian: why hate pmc2c? |
| 15:58 |
|
cotto |
whiteknight, why not? |
| 15:58 |
|
whiteknight |
i mean, I have reasons why I hate it, but I'm wondering what other people think as well |
| 15:59 |
|
sorear |
dukeleto: I don't get it, what was the problem? |
| 15:59 |
|
lucian |
whiteknight: it's the majority of build time for me, i can't read it and it's a huge hack |
| 15:59 |
|
dukeleto |
sorear: just old code that was written at a time where "Test::Warn" was too much of a dependency, but which is now included in the repo |
| 15:59 |
|
lucian |
ah great, parrot doesn't build on osx anymore |
| 16:00 |
|
cotto |
lucian, there's a tt for that |
| 16:00 |
|
dukeleto |
sorear: nothing particularly amazing except a reason to write a funny commit message :) |
| 16:00 |
|
cotto |
something about pcre? |
| 16:00 |
|
lucian |
cotto: nope |
| 16:02 |
|
lucian |
cotto: https://gist.github.com/a4079d13d6cb4f93d383 |
| 16:02 |
|
cotto |
lucian, can you nopaste how it exploded? |
| 16:02 |
|
cotto |
bam |
| 16:03 |
|
whiteknight |
lucian: looks like it's stumbling over an existing installed libparrot |
| 16:03 |
|
cotto |
lucian, looks like you have an old version of libparrot somewhere |
| 16:03 |
|
lucian |
hmm |
| 16:03 |
|
* benabik |
didn't expect to have to resolve a merge conflict first thing. Bleh. |
| 16:03 |
|
lucian |
ah |
| 16:03 |
|
cotto |
though when installing, the libparrot symlink should be updated to the version being installed |
| 16:05 |
|
lucian |
ok, i removed the existing libparrot |
| 16:05 |
|
lucian |
same thing |
| 16:06 |
|
cotto |
did Configure.pl spit out a warning about a possible conflicting libparrot? |
| 16:06 |
|
lucian |
nope |
| 16:06 |
|
cotto |
you might need to reconf |
| 16:07 |
|
cotto |
er, make reconfig |
| 16:07 |
|
lucian |
https://gist.github.com/a4079d13d6cb4f93d383 |
| 16:07 |
|
dukeleto |
benabik: wouldn't rebasing and squashing just before a merge into master be the least amount of work? |
| 16:08 |
|
dukeleto |
benabik: i am still reading your blog post |
| 16:08 |
|
benabik |
dukeleto: I was hoping to merge the last 5 months of work on master into nqp_pct to reduce surprises later. |
| 16:09 |
|
dukeleto |
benabik: so you are starting with bacek++'s branch as a base and working from there? |
| 16:09 |
|
benabik |
dukeleto: Yup. |
| 16:09 |
|
dukeleto |
benabik: good blog post. exactly the kind of stuff we want to hear about |
| 16:10 |
|
dukeleto |
benabik: don't be shy about giving too many details :) |
| 16:10 |
|
benabik |
dukeleto: I figured my blog would be an expanded version of a #ps DID/WILL DO/BLOCKERS report. |
| 16:10 |
|
dukeleto |
benabik: so you will be rebasing like mad on your local branch and pushing to nqp_pct occasionally, which will be stable? |
| 16:10 |
|
dukeleto |
benabik: yes. Exactly. |
| 16:11 |
|
benabik |
dukeleto: Yes. benabik/parrot/nqp_pct will be constantly rebasing on top of parrot/parrot/nqp_pct |
| 16:11 |
|
bubaflub |
lucian: i'm going to try and build on Mac. are you building from HEAD? |
| 16:11 |
|
lucian |
benabik: yeah |
| 16:11 |
|
benabik |
lucian: what? |
| 16:11 |
|
bubaflub |
benabik: probably meant for me. tab complete on b |
| 16:11 |
|
lucian |
sorry, bubaflub |
| 16:12 |
|
lucian |
stop colliding on one char! :) |
| 16:12 |
|
bubaflub |
lucian: yeah, my last build was 56 commits ago. i'm cleaning and building now |
| 16:12 |
|
benabik |
Ah. (I'm only half-paying attention. Wife is in Spring Cleaning mode so I can't just sit in front of IRC.) |
| 16:13 |
|
lucian |
ok, seems to be working now |
| 16:14 |
|
lucian |
we'll see if it finishes |
| 16:14 |
|
bubaflub |
lucian: i just finished building off HEAD on Mac OS X 10.6.7 |
| 16:14 |
|
bubaflub |
lucian: lemme know if it doesn't work, i'll help ya debug |
| 16:15 |
|
cotto |
dukeleto, do you have any unpushed changes to the m0 assembler? |
| 16:15 |
|
lucian |
bubaflub: great, my terminal crashed |
| 16:15 |
|
* lucian |
hates osx a little now |
| 16:16 |
|
lucian |
i thought osx was supposed to be faster and stabler than ubuntu |
| 16:16 |
|
lucian |
i get crashes and lag left and right ... |
| 16:16 |
|
cotto |
dukeleto, nm. it's a trivial change |
| 16:16 |
|
whiteknight |
hate leads to anger. Anger leads to Linux. Linux leads to the darkside |
| 16:16 |
|
lucian |
whiteknight: :D |
| 16:16 |
|
cotto |
not likely to cause any problems |
| 16:17 |
|
dalek |
parrot/m0-spec: c4ca0f2 | cotto++ | docs/pdds/draft/pdd32_m0.pod: |
| 16:17 |
|
dalek |
parrot/m0-spec: rename goto_cs to goto_chunk |
| 16:17 |
|
dalek |
parrot/m0-spec: review: https://github.com/parrot/parr[…]commit/c4ca0f2067 |
| 16:17 |
|
dalek |
parrot/m0-prototype: 3806816 | cotto++ | src/m0/m0_interp.pl: |
| 16:17 |
|
dalek |
parrot/m0-prototype: implement goto and goto_if_eq |
| 16:17 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/3806816ea2 |
| 16:17 |
|
dalek |
parrot/m0-prototype: 4ce8ab2 | cotto++ | src/m0/m0_assembler.pl: |
| 16:17 |
|
dalek |
parrot/m0-prototype: rename goto_cs to goto_chunk in the assembler |
| 16:17 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/4ce8ab2c12 |
| 16:17 |
|
dalek |
parrot/m0-prototype: f292095 | cotto++ | src/m0/m0_interp.pl: |
| 16:17 |
|
dalek |
parrot/m0-prototype: rename/implement goto_chunk |
| 16:17 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/f292095d07 |
| 16:18 |
|
bubaflub |
lucian: i've been using iTerm2 on my work laptop for Mac... it has yet to crash for me |
| 16:18 |
|
bubaflub |
(also ZSH and screen for the win) |
| 16:19 |
|
lucian |
bubaflub: i'm using visor, it's usually ok. everything just feels like fighting through sludge |
| 16:20 |
|
bubaflub |
lucian: yeah, i used visor for a bit but sometimes it would leak memory |
| 16:20 |
|
|
theory left #parrot |
| 16:20 |
|
benabik |
lucian: In my experience OS X can really bog down on a lot of disk I/O. Parallel compile + Spotlight = lag. |
| 16:20 |
|
dukeleto |
lucian: yes, that is the feeling of developing on OS X |
| 16:21 |
|
lucian |
dukeleto: not just developing |
| 16:21 |
|
lucian |
i mean this has a dual core 2.4ghz intel and it's a bit laggier than my 800mhz arm netbook |
| 16:25 |
|
lucian |
haha |
| 16:25 |
|
lucian |
Configure.pl made a folder called ~ in my parrot folder |
| 16:26 |
|
dalek |
parrot/m0-prototype: 6e46928 | cotto++ | src/m0/m0_interp.pl: |
| 16:26 |
|
dalek |
parrot/m0-prototype: finish implementing goto_chunk |
| 16:26 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/6e46928574 |
| 16:28 |
|
|
theory joined #parrot |
| 16:30 |
|
dukeleto |
lucian: that is called the "It Didn't DWIM" folder ;) |
| 16:30 |
|
|
jsut joined #parrot |
| 16:30 |
|
dukeleto |
lucian: a feature coded by Steve Jobs himself |
| 16:31 |
|
lucian |
my linux netbook did the right thing |
| 16:35 |
|
benabik |
Hm. "load_bytecode" couldn't find file 'nqp-setting.pbc' |
| 16:35 |
|
|
jsut_ left #parrot |
| 16:35 |
|
|
theory left #parrot |
| 16:36 |
|
|
theory joined #parrot |
| 16:37 |
|
|
theory left #parrot |
| 16:48 |
|
dalek |
parrot/m0-spec: f977cde | cotto++ | docs/pdds/draft/pdd32_m0.pod: |
| 16:48 |
|
dalek |
parrot/m0-spec: add CHUNK register, leave space for future changes |
| 16:48 |
|
dalek |
parrot/m0-spec: review: https://github.com/parrot/parr[…]commit/f977cde148 |
| 16:48 |
|
dalek |
parrot/m0-prototype: 16d4851 | cotto++ | src/m0/m0_interp.pl: |
| 16:48 |
|
dalek |
parrot/m0-prototype: simplify a context's pc, add a way to get the current chunk's name |
| 16:48 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/16d4851b11 |
| 16:48 |
|
dalek |
parrot/m0-prototype: 8c37cca | cotto++ | src/m0/m0_assembler.pl: |
| 16:48 |
|
dalek |
parrot/m0-prototype: update register numbers in the M0 assembler |
| 16:48 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/8c37ccac55 |
| 16:50 |
|
|
contingencyplan left #parrot |
| 16:51 |
|
lucian |
i don't get parrot's fakecutables. what's their purpose? |
| 16:52 |
|
dukeleto |
lucian: dressing up PIR/PBC as an executable |
| 16:52 |
|
dukeleto |
lucian: so you can ./ it |
| 16:52 |
|
lucian |
but why? you could just do #! for text or that other thing for binary |
| 16:52 |
|
dukeleto |
lucian: wraps PIR/PBC into a C program that executes embedded bytecode, basically |
| 16:52 |
|
lucian |
the one mono and wine use |
| 16:52 |
|
|
contingencyplan joined #parrot |
| 16:52 |
|
dukeleto |
lucian: some dumb operating systems don't have shebang lines |
| 16:53 |
|
lucian |
and is it important to have executables there? python doesn't bother |
| 16:53 |
|
dukeleto |
lucian: the portability gods are fickle |
| 16:53 |
|
lucian |
nor does any other language i can think of |
| 16:53 |
|
dukeleto |
lucian: parrot isn't python :) |
| 16:54 |
|
dukeleto |
lucian: parrot does sacrifice many goats to our portability gods |
| 16:54 |
|
whiteknight |
lucian: is it hurting anybody? |
| 16:54 |
|
lucian |
no, i'm just wondering |
| 16:55 |
|
lucian |
it seems like yet another thing to maintain |
| 16:56 |
|
whiteknight |
it really hasn't been any maintenance. It shares most of the code with the frontend and mostly just works |
| 16:56 |
|
lucian |
i see |
| 16:57 |
|
whiteknight |
eventually, it's the kind of mechanism I would like to use to bootstrap Parrot with |
| 16:57 |
|
whiteknight |
get the entry code written in PIR or something on Parrot, get into Parrot execution earlier |
| 16:57 |
|
lucian |
yes, that would be nice |
| 16:57 |
|
lucian |
it'd be even nicer if GC and other low-level things were written on parrot |
| 16:58 |
|
whiteknight |
I don't think that would be nice at all |
| 16:59 |
|
lucian |
how so? |
| 17:00 |
|
dalek |
parrot/m0-prototype: 9efb984 | cotto++ | / (2 files): |
| 17:00 |
|
dalek |
parrot/m0-prototype: fix interp typo, update hello.m0b with recent register change |
| 17:00 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/9efb984319 |
| 17:00 |
|
dukeleto |
lucian: if by nice, you mean slow, then yes :) |
| 17:00 |
|
lucian |
dukeleto: that's just an assumption without backing :) |
| 17:01 |
|
lucian |
both jikesrvm and pypy have fast GCs, written in not-C |
| 17:01 |
|
dukeleto |
lucian: a GC in a native parrot language really isn't feasiable until we are JITed |
| 17:01 |
|
dukeleto |
lucian: yes, and they have a JIT :) |
| 17:01 |
|
lucian |
of course, jit comes first |
| 17:01 |
|
dukeleto |
lucian: ok, i can agree with you on that point :) |
| 17:01 |
|
lucian |
i'm sort of dreaming |
| 17:01 |
|
dukeleto |
lucian: it isn't a bad thing |
| 17:01 |
|
lucian |
but JITs can do interesting optimisations across system boundaries |
| 17:03 |
|
lucian |
that's part of why i think it'd be nice to first design a system language on parrot, then bother with a better runtime for it (M0, jit, etc.) |
| 17:04 |
|
|
theory joined #parrot |
| 17:04 |
|
dukeleto |
whiteknight: do you use straight markdown for your blog, or jekyll too? |
| 17:04 |
|
dukeleto |
lucian: take a look at Close |
| 17:04 |
|
dukeleto |
Close? |
| 17:04 |
|
whiteknight |
dukeleto: jekyll is the rendering engine. All the text is markdown |
| 17:05 |
|
dukeleto |
aloha, Close? |
| 17:05 |
|
aloha |
dukeleto: Close is http://code.google.com/p/close/ |
| 17:05 |
|
whiteknight |
lucian: That's what I envision Winxed to be |
| 17:05 |
|
lucian |
dukeleto: yeah, i had a look. it's, uh, close to what i'm thinking of |
| 17:05 |
|
whiteknight |
it's a low-level system language for Parrot |
| 17:05 |
|
dukeleto |
Winxed is the new Close |
| 17:05 |
|
lucian |
winxed isn't low-level enough if you ask me, though |
| 17:05 |
|
whiteknight |
I don't see why not. You have access to all the low-level PIR features, inline PIR ops, etc |
| 17:06 |
|
lucian |
right. but no access to raw memory for exampel |
| 17:06 |
|
NotFound |
lucian: One can't be at a lever lowel than non-existence. |
| 17:06 |
|
whiteknight |
PIR doesn't give access to raw memory |
| 17:06 |
|
whiteknight |
winxed is as low as the VM allows it to be |
| 17:06 |
|
lucian |
yes |
| 17:06 |
|
lucian |
but a language to express parrot details would need to be lower level |
| 17:06 |
|
whiteknight |
NotFound: I'm glad you're here. I had a question for you from my hacking yesterday |
| 17:07 |
|
whiteknight |
NotFound: is there any way to make a continuation in winxed? It doesn't seem to like treating labels as first-class citizens |
| 17:07 |
|
dukeleto |
whiteknight: i guess i was thinking of something like this: http://raphinou.github.com/jekyll-base/ |
| 17:07 |
|
NotFound |
Correction: winxed on parrot can't give you access to raw memory. winxedxx will do. |
| 17:07 |
|
benabik |
Winxed : PIR :: C : Assembly. Once M0 becomes the new "lowest level", we might want to create Winxed on M0 |
| 17:08 |
|
NotFound |
whiteknight: labels in pirops must be used as :label |
| 17:08 |
|
whiteknight |
${ :label } ? |
| 17:08 |
|
NotFound |
Winxedxx is winxed --> C++ |
| 17:08 |
|
NotFound |
whiteknight: ${ goto :label } |
| 17:08 |
|
whiteknight |
NotFound: but I don't want to goto. I want a Continuation that I can invoke later |
| 17:09 |
|
NotFound |
whiteknight: then use an op other than goto. |
| 17:09 |
|
whiteknight |
${ set_addr cc, :label } |
| 17:09 |
|
whiteknight |
so that will work? |
| 17:09 |
|
NotFound |
whiteknight: if does not work, let me kow. |
| 17:09 |
|
whiteknight |
okay |
| 17:12 |
|
NotFound |
whiteknight: when you have some example of usage, let me know, and I will think about a possible syntax. |
| 17:12 |
|
whiteknight |
NotFound: Okay. What I'm mostly interested in is creating continuations and jumping around between them |
| 17:12 |
|
* dukeleto |
reads http://tom.preston-werner.com/[…]ike-a-hacker.html again and everything becomes clear |
| 17:12 |
|
whiteknight |
of course, continuations take arguments, so a syntax that allows that would be fantastic |
| 17:13 |
|
whiteknight |
I almost can't imagine such a thing |
| 17:13 |
|
whiteknight |
label(var args): |
| 17:14 |
|
lucian |
dukeleto: interesting. Cory Doctorow described a similar workflow |
| 17:16 |
|
whiteknight |
NotFound: it works. Thanks |
| 17:23 |
|
dalek |
parrot: eb3d7a9 | (Dan Bolser)++ | docs/project/git_workflow.pod: |
| 17:23 |
|
dalek |
parrot: Edited docs/project/git_workflow.pod via GitHub |
| 17:23 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/eb3d7a9475 |
| 17:23 |
|
dalek |
parrot: 8d2e649 | bubaflub++ | docs/project/git_workflow.pod: |
| 17:23 |
|
dalek |
parrot: Merge from dbolser/patch-1 |
| 17:23 |
|
dalek |
parrot: |
| 17:23 |
|
dalek |
parrot: Edited docs/project/git_workflow.pod via GitHub |
| 17:23 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/8d2e6497ef |
| 17:29 |
|
|
dodathome joined #parrot |
| 17:30 |
|
* dukeleto |
is installing ruby gems. Be very afraid. |
| 17:37 |
|
cotto_work |
~~ |
| 17:51 |
|
|
hercynium joined #parrot |
| 17:52 |
|
whiteknight |
https://gist.github.com/983416 |
| 17:53 |
|
whiteknight |
a little bit more timing information. If we remove the faulty recursion limit code, we can recycle the CallContext throughout the loop and see major time savings |
| 17:54 |
|
whiteknight |
It's worth noting that doing a morph on that callcontext doesn't reset it like we think it does |
| 17:54 |
|
whiteknight |
it still trips the recursion limit code eventually |
| 17:55 |
|
whiteknight |
of course, the recursion limit code is...faulty according to my reading of it |
| 17:56 |
|
whiteknight |
dispatch like this, with a recycled CallContext, cuts almost 50% of the time out of a normal PIR dispatch |
| 17:56 |
|
whiteknight |
without recycling, we only save about 10% |
| 17:58 |
|
bubaflub |
whiteknight: could you clarify what the recursion limit code is currently doing and why we can bin it? |
| 17:58 |
|
bubaflub |
(just curious) |
| 17:58 |
|
whiteknight |
we can't bin it |
| 17:58 |
|
whiteknight |
we do have legitimate needs for user-definable recursion limits |
| 17:59 |
|
whiteknight |
but the implementation now is lacking |
| 17:59 |
|
whiteknight |
right now, we test the recursion depth in src/pmc/sub.pmc:invoke, which doesn't seem like the right place to do it (considering we can invoke other things besides Sub) |
| 18:01 |
|
whiteknight |
I can't actually find where we decrement the recursion depth |
| 18:02 |
|
tadzik |
whew, 'evening |
| 18:03 |
|
whiteknight |
okay. I found it. When we create a new CallContext (src/call/context.c:init_context) we set the recursion depth of the new CallContext to the same as the parent |
| 18:03 |
|
whiteknight |
then in Sub.invoke, we increment and test it |
| 18:03 |
|
whiteknight |
Except, we decrement it when we do tailcalls |
| 18:03 |
|
whiteknight |
raise your hand if that sounds wrong to you |
| 18:03 |
|
bubaflub |
raises hand |
| 18:04 |
|
bubaflub |
there should be a few other places that happens as well, right? |
| 18:08 |
|
whiteknight |
no, fewer |
| 18:09 |
|
whiteknight |
we should set the recursion_depth for the new CallContext to the value of the old one +1 |
| 18:09 |
|
whiteknight |
and only check it there |
| 18:09 |
|
whiteknight |
and not spread out the logic through the rest of the system |
| 18:09 |
|
whiteknight |
Sub.invoke shouldn't know or care anything about recursion depth |
| 18:09 |
|
whiteknight |
and the get_params op shouldn't have to be aware of tailcalls |
| 18:10 |
|
whiteknight |
and everywhere else that might cause a recursion should not have to deal with the logic either |
| 18:12 |
|
whiteknight |
although that's not even a great solution either, because we only have a "caller" context in certain situations. |
| 18:14 |
|
whiteknight |
we should add CallContext.init_pmc to take a parent context. CallContext.init will redirect to init_pmc passing interp->ctx |
| 18:14 |
|
|
fperrad left #parrot |
| 18:14 |
|
whiteknight |
that way we always have an accurate recursion count, and can check the depth logic in the same place all the time |
| 18:15 |
|
whiteknight |
and that should work fine with return continuations too, since they wouldn't increase the recursion limit if we aren't recreating them fresh |
| 18:16 |
|
|
fperrad joined #parrot |
| 18:17 |
|
whiteknight |
actually, we would still need to update it in the invoke opcode, incase the CallContext was created earlier and passed down the chain before being used in an invoke |
| 18:17 |
|
whiteknight |
so that's two places |
| 18:17 |
|
whiteknight |
although they could both use the same function |
| 18:21 |
|
bubaflub |
will having that function in only those two places be faster? or "just" correct? |
| 18:23 |
|
|
theory left #parrot |
| 18:24 |
|
whiteknight |
I have to think about it a little bit more, but moving the logic to the correct places is an important step |
| 18:24 |
|
whiteknight |
and making sure the logic can be shared between more codepaths than just Sub.invoke |
| 18:25 |
|
whiteknight |
I think we really do need to talk about breaking CallContext up into two types, like plobsing mentioned |
| 18:27 |
|
whiteknight |
here's the exercise: How much logic can we move from Sub.invoke up into the invokecc opcode? |
| 18:31 |
|
|
Coke left #parrot |
| 18:31 |
|
|
Coke joined #parrot |
| 18:36 |
|
|
hercynium left #parrot |
| 18:39 |
|
|
theory joined #parrot |
| 18:43 |
|
|
dodathome left #parrot |
| 18:44 |
|
|
dodathome joined #parrot |
| 18:45 |
|
|
theory left #parrot |
| 18:45 |
|
|
Coke left #parrot |
| 18:45 |
|
|
Coke joined #parrot |
| 18:51 |
|
sorear |
lucian: shebang handling isn't recursive |
| 18:51 |
|
sorear |
lucian: when you have #!/usr/bin/perl6, that file MUST be a binary executable |
| 18:51 |
|
sorear |
that file = /usr/bin/perl6 |
| 18:53 |
|
|
alester left #parrot |
| 19:12 |
|
|
ambs left #parrot |
| 19:16 |
|
rblackwe |
The YAPC hackathon seems a bit thin. http://www.yapc2011.us/yn2011/[…]Perl6%20Hackathon |
| 19:17 |
|
|
ambs joined #parrot |
| 19:17 |
|
rblackwe |
just planning for flights and wondering if I should stay for it. |
| 19:17 |
|
rblackwe |
Anyone else planning on going? |
| 19:18 |
|
cotto_work |
rblackwe: dukeleto and I will be there. |
| 19:18 |
|
cotto_work |
I think there are others. |
| 19:18 |
|
rblackwe |
cotto_work: Woot! |
| 19:18 |
|
rblackwe |
that is enough thanks |
| 19:18 |
|
cotto_work |
dukeleto: ping |
| 19:18 |
|
PerlJam |
sorear: s/binary// |
| 19:18 |
|
lucian |
sorear: and is that an issue? |
| 19:20 |
|
dukeleto |
rblackwe: many people just haven't found that wiki page yet, methinks |
| 19:20 |
|
cotto_work |
dukeleto: is it a reasonable testing strategy to have a bunch of .m0 files in t/m0/something/ that either output tap or something like "ok"? |
| 19:21 |
|
lucian |
sorear: other than windows support (which is usually handled by registering the interpreter with the shell), i don't see the use-case where shebangs and special binaries don't work |
| 19:22 |
|
rblackwe |
dukeleto: I understand samething happened when I was organizing http://yapc10.org/yn2009/talk/2045 |
| 19:22 |
|
rblackwe |
Parrot Virtual Machine Workshop at YAPC|1- |
| 19:23 |
|
cotto_work |
great showing at that one |
| 19:23 |
|
rblackwe |
about 60 people |
| 19:23 |
|
rblackwe |
so I would say yes |
| 19:24 |
|
sorear |
PerlJam: no. |
| 19:24 |
|
rblackwe |
The wiki did not reflect everyone |
| 19:24 |
|
rblackwe |
Having it before YAPC I think we got people that just showed up early for YAPC. |
| 19:25 |
|
sorear |
hmm, odd |
| 19:25 |
|
rblackwe |
The crazy thing is we got a few people that came really just for PVMW not YAPC. |
| 19:26 |
|
rblackwe |
have to run off to a meeting. Looking forward to the workshop. Thanks all for the parrot/rakudo work! |
| 19:32 |
|
sorear |
well I just tested it and, at least on Linux 2.6.32, you *can* have a shebang script use another shebang script as an interpreter |
| 19:33 |
|
sorear |
either this is new and 2.6.8 didn't support that, or I am just imagining the tests I did back on 2.6.8 |
| 19:33 |
|
PerlJam |
sorear: yep, been that way for a long time. |
| 19:33 |
|
benabik |
I think it works in OS X. |
| 19:33 |
|
sorear |
PerlJam: like "2.6.0" long time or like "V7" long time? |
| 19:34 |
|
PerlJam |
sorear: I'm not sure ... but I think it has worked like that for > 10 years. |
| 19:35 |
|
PerlJam |
long enough ago that I don't remember when it started working. |
| 19:35 |
|
PerlJam |
(or when I *noticed* it working) |
| 19:46 |
|
benabik |
Whee... My merge of master and nqp_pct won't build. GSoC step 1: Debug. |
| 19:54 |
|
benabik |
Ah! nqp_pct won't build either, so it's nothing I did. Time to pester bacek. |
| 19:55 |
|
benabik |
msg bacek I can't get nqp_pct to build. I keep getting ""load_bytecode" couldn't find file 'nqp-setting.pbc'" Any pointers? |
| 19:55 |
|
aloha |
OK. I'll deliver the message. |
| 19:56 |
|
|
Coke left #parrot |
| 19:56 |
|
|
Coke joined #parrot |
| 19:58 |
|
dukeleto |
cotto_work: sure |
| 19:58 |
|
dukeleto |
cotto_work: the more tests the better |
| 19:58 |
|
dukeleto |
cotto_work: we can sort them out later |
| 19:58 |
|
dukeleto |
cotto_work: we need a lot of tests for error conditions |
| 19:59 |
|
dukeleto |
cotto_work: i think we may need to add at least something to the spec about how errors should be thrown from an M0 assembler and interp |
| 20:00 |
|
dukeleto |
benabik: posting the full output of attempting to build nqp_pct to parrot-dev would be good |
| 20:00 |
|
dukeleto |
benabik: bacek++ is a sleepy coding robot now |
| 20:01 |
|
benabik |
dukeleto: Yeah, I didn't figure he'd be awake. I've got a clock open to his timezone. :-D But I also figured that nqp_pct was his work and he might know where to start. |
| 20:04 |
|
PerlJam |
benabik: I think that error means that the .pbc hasn't been copied to runtime/parrot/library |
| 20:05 |
|
benabik |
PerlJam: master builds fine, as does `git merge-base origin/nqp_pct master` So something in nqp_pct is doing it. |
| 20:07 |
|
dukeleto |
benabik: bacek++ often breaks branches and does a long sprint of robot coding to get it building again |
| 20:07 |
|
dukeleto |
benabik: he passed you the baton :) |
| 20:07 |
|
benabik |
dukeleto: robot coding? |
| 20:07 |
|
dukeleto |
benabik: we have a myth that bacek is a magical coding robot |
| 20:08 |
|
dukeleto |
benabik: try to debug the build issue, and report you finds to parrot-dev, with full output attached of any errors/etc |
| 20:08 |
|
cotto_work |
They say if you speak his name three times in the dark, a heisenbug will mysteriously disappear. |
| 20:09 |
|
dukeleto |
benabik: and of course, ask in here first :) |
| 20:09 |
|
dukeleto |
benabik: we still need to video chat, too |
| 20:09 |
|
benabik |
dukeleto: Oh, yes. Buh. Totally forgot about that. |
| 20:12 |
|
|
theory joined #parrot |
| 20:15 |
|
|
whiteknight left #parrot |
| 20:22 |
|
|
dodathome left #parrot |
| 20:28 |
|
|
alester joined #parrot |
| 20:30 |
|
|
mspaulding joined #parrot |
| 20:32 |
|
|
hercynium joined #parrot |
| 20:42 |
|
|
mj41 joined #parrot |
| 20:58 |
|
|
ambs left #parrot |
| 21:04 |
|
dalek |
parrot/m0-prototype: 40ff938 | cotto++ | t/m0/ops/m0_noop.m0: |
| 21:04 |
|
dalek |
parrot/m0-prototype: start adding op-specific M0 tests |
| 21:04 |
|
dalek |
parrot/m0-prototype: review: https://github.com/parrot/parr[…]commit/40ff938137 |
| 21:12 |
|
|
fperrad left #parrot |
| 21:55 |
|
|
hercynium left #parrot |
| 21:57 |
|
|
pjcj left #parrot |
| 21:57 |
|
|
pjcj joined #parrot |
| 22:10 |
|
|
theory left #parrot |
| 22:13 |
|
|
pjcj left #parrot |
| 22:13 |
|
|
pjcj joined #parrot |
| 22:15 |
|
|
pjcj left #parrot |
| 22:16 |
|
|
pjcj joined #parrot |
| 22:18 |
|
|
soh_cah_toa joined #parrot |
| 22:18 |
|
mikehh |
t/tools/dev/headerizer/01_functions.t - Failed test: 51 (fulltest)- See TT #2119 |
| 22:18 |
|
mikehh |
all other tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-20-g8d2e649 |
| 22:18 |
|
mikehh |
Kubuntu 11.04 amd64 (g++ --optimize) |
| 22:20 |
|
|
alester left #parrot |
| 22:20 |
|
|
pjcj left #parrot |
| 22:21 |
|
|
pjcj joined #parrot |
| 22:21 |
|
|
mj41 left #parrot |
| 22:27 |
|
mikehh |
winxed (r1015) builds on parrot (3_4_0-20-g8d2e649) - test/test1/test2 ok - opengl stuff ok now - Kubuntu 11.04 amd64 (g++ --optimize) |
| 22:28 |
|
|
pjcj left #parrot |
| 22:30 |
|
|
pjcj joined #parrot |
| 22:31 |
|
|
jsut_ joined #parrot |
| 22:36 |
|
|
jsut left #parrot |
| 22:43 |
|
dalek |
winxed: r1016 | NotFound++ | trunk/examples/jsonread.winxed: |
| 22:43 |
|
dalek |
winxed: fix and improve example jsonread |
| 22:43 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]rce/detail?r=1016 |
| 22:48 |
|
|
lucian left #parrot |
| 22:53 |
|
|
pjcj left #parrot |
| 22:54 |
|
|
pjcj joined #parrot |
| 22:57 |
|
|
Coke left #parrot |
| 22:57 |
|
|
Coke joined #parrot |
| 22:58 |
|
|
pjcj left #parrot |
| 22:59 |
|
|
pjcj joined #parrot |
| 23:01 |
|
|
pjcj left #parrot |
| 23:02 |
|
mikehh |
rakudo (7860993) - builds on parrot (3_4_0-20-g8d2e649) - make test, make stresstest [roast (32c4ff6)] PASS |
| 23:02 |
|
mikehh |
Kubuntu 11.04 amd64 (g++ --optimize) |
| 23:07 |
|
|
pjcj joined #parrot |
| 23:08 |
|
|
pjcj left #parrot |
| 23:17 |
|
|
pjcj joined #parrot |
| 23:21 |
|
|
ShaneC left #parrot |
| 23:40 |
|
|
bubaflub left #parrot |
| 23:42 |
|
|
bubaflub joined #parrot |
| 23:50 |
|
|
rurban_ joined #parrot |
| 23:52 |
|
|
rurban left #parrot |
| 23:52 |
|
|
rurban_ is now known as rurban |
