Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8
Set by moderator on 27 March 2011.
plobsing most library detection does support hinting on the command line 00:00
at configure time
cgaertner turns out I was at fault - no dev version installed
configure now correctly detects gmp 00:01
dukeleto cgaertner: there was this guy named particle that used to be one of our main windows devs, but he is spelunking in somebody else's yak holes these days
00:03 lucian_ left
cgaertner I think I also know why using mingw32-make is necessary: configure pulled in some path with backslash from the perl config and/or the environment 00:04
00:19 silug left
cotto ~~~~ 00:21
oh look. a message. I wonder whom it could be from. 00:22
00:24 lateau joined
bubaflub dukeleto: any thoughts on how i should measure code coverage? i know how to do it in Perl 5... same with ensuring each function has documentation. perhaps brew some of my own scripts? 00:27
cotto bubaflub, what code do you want to make sure is covered? 00:30
bubaflub cotto: my GSoC proposal is to make parrot bindings for GMP - i'd like to be able to check test and doc (POD) coverage of my files
00:31 whiteknight left
cgaertner is there a way to upload a smolder result archive without re-running the tests? 00:31
cotto bubaflub, are you planning on nci bindings or C-level bindings?
bubaflub cotto: i was planning on NCI bindings 00:32
cotto bubaflub, in that case, no current coverage tools exist (afair). The output from the profiling runcore might be shoehorned into coverage data, but its reliance on imcc's data can make its output lta. 00:33
dalek rrot/jit_prototype: 20b9c7c | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Don't load num_constans. We don't need them.
 00:34
bubaflub cotto: ok, maybe something to hack on in the meantime? i think a POD checker is easier than the actual test coverage one
something for me to hack on in the meantime
that is
cotto more eyeballs on it can't hurt 00:36
bubaflub cotto: agreed. just didn't want it to sound like i was volunteering anyone 00:37
cotto: i'd love a Devel::Cover type tool for parrot, doesn't even have to be that fancy
dukeleto: once more, with feeling: gist.github.com/890669 00:40
00:50 kid51 joined
kid51 cgaertner: perldoc lib/Parrot/Harness/Smoke.pm has the command you're looking for 00:51
bubaflub: Have you had any results with our 'make cover' target?
bubaflub kid51: it was my understanding that just called gcov for C files 00:52
kid51 True. Looking for something else?
cgaertner kid51: thanks 00:53
kid51 cgaertner: our Smolder instance is flaky, so you often have to use that command.
bubaflub kid51: yeah, i'll be doing NCI bindings in PIR and PIR tests - i'd like to see how much of my code those tests cover 01:00
kid51 bubaflub: Understood. And, no, we don't have such tools. Coverage analysis tools for PIR would be a *tremendous* GSOC project -- and that work might have benefits for profiling tools, which we also need. 01:02
Remember that of the various things which Rakudo folks identified as needing from Parrot, profiling tools are the ones we have 01:03
*least* addressed
bubaflub kid51: yeah, my main focus is the NCI bindings. i think i could get together some perl scripts that would analyze the PIR source and tell me which functions have POD docs
kid51: but as for actually testing which lines get run -- i think that would require another run core with separate annotations
and a big ole hash telling me how many times each one was run
kid51 Well, we already have tests for presence of POD.
t/codingstd/pmc_docs.t, IIRC 01:04
bubaflub kid51: well, that one is done.
kid51: i'll need to modify this slightly because i'll be analyzing raw PIR, but this is pretty much exactly what i need 01:05
01:08 Coke left
soh_cah_toa here's my revised proposal: gist.github.com/889795 01:23
kid51 bubaflub: If you would like to open a Trac ticket with a subject like "Parrot needs coverage analysis tools for PIR source fields," please do so. 01:26
bubaflub kid51: sounds great. will do
cotto bubaflub, can you put line breaks in so that it's not necessary to scroll? If you're using vim (with it's All Text on Firefox), you can do it per paragraph with gqq 01:27
bubaflub soh_cah_toa: that looks great. i'm looking forward to a nice debugger
cotto: the gist of the proposal to google? 01:28
soh_cah_toa yay!
cotto bubaflub, yes
er, soh_cah_toa
so many students
soh_cah_toa yeah, i know 01:29
cotto though the current indents work well with the raw view, so it's not bad
soh_cah_toa good 01:30
kid51 "Parrot's current user base is mostly composed of Perl programmers and so will the debugger's."
Hmm ...
cotto soh_cah_toa, I don't think it's accurate to say that most of Parrot's developers are Perl hackers.
soh_cah_toa well wasnt the project started from perl 6?
kid51 Yes, but "perl" suggests more perl 5 01:31
cotto soh_cah_toa, it's grown since then
soh_cah_toa hmm...what would be more politically correct?
kid51 "Apart from Parrot developers themselves, Parrot's current users and people involved in the creation of the next generation of dynamic programming languages. (Example: the Rakudo implementation of Perl 6.) 01:32
"
soh_cah_toa yeah, much better
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#13346) fulltest) at 3_2_0-96-gb7cf686 - Ubuntu 10.10 i386 (gcc-4.5 --optimize --gc-gms)
kid51 ... users are people involved ...
soh_cah_toa yeah, i figured 01:33
kid51 (After all, most Perl 5 programmers, including Perl 5 core developers, have little awareness of Parrot these days -- not that they particularly need to.)
Which leads me to mention: I submitted a talk proposal to YAPC::NA::2011 for a presentation on Parrot as open source community project and process. 01:34
No word yet as to acceptance. 01:35
soh_cah_toa neat, would you be giving the presentation? 01:36
plobsing kid51++ 01:37
bubaflub kid51: very nice, my talk about GSoC and Perl for YAPC::NA::2011 was accepted. i'll see ya there.
cotto same for mine
soh_cah_toa i'm jealous...i'd love to go but the travel would interfere w/ gsoc 01:39
bubaflub: what's your presentation on?
01:40 cgaertner left
bubaflub soh_cah_toa: i did GSoC with the perl foundation two years ago and wrote Math::Primality. it'll be a bit about the GSoC process, a bit about hte module, and a bit about how i moved from baby perl to releasing my first module 01:40
soh_cah_toa i'd actually like to hear that. i hope i can find a video on youtube afterwards 01:41
02:13 silug joined
bubaflub soh_cah_toa: i'll try and put the slides up somewhere 02:15
goodnight, #parrot
02:15 bubaflub left 02:17 kid51 left
mikehh rakudo (405afa9) - builds on parrot (3_2_0-96-gb7cf686) - make test, make spectest_smolder[(#13350), roast (5c48821)] PASS - Ubuntu 10.10 i386 (gcc-4.5 --optimize --gc-gms) 02:18
27,636 ok, 0 failed, 606 todo, 1,799 skipped and 0 unexpectedly succeeded
02:25 benabik joined
dukeleto ~~ 02:41
02:55 soh_cah_toa left 03:40 Eduardow left 03:46 theory joined
cotto atrodo, ping 03:51
04:20 woosley joined 04:44 Andy_ left 04:55 ShaneC left 05:00 theory left 05:06 ShaneC joined 05:10 jsut_ joined 05:15 jsut left
dalek rrot/m0-spec: 42d1d02 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a conditional goto, misc minor fixes
 05:18
rrot/m0-spec: b4d721f | cotto++ | docs/pdds/draft/pdd32_m0.pod:
break bytecode, variables and metadata into a distinct chunk
rrot/m0-spec: 5ce4d86 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
we're doing explicit control flow, so remove the pc-manipulating version
rrot/m0-spec: dc48037 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
spell out the text-based version of M0 bytecode
 05:19
05:20 Eduardow joined
cotto dukeleto, ping 05:29
06:02 jsut joined 06:06 jsut_ left 06:17 fperrad joined 06:50 cosimo left
cotto review appreciated 07:00
dalek rrot/m0-spec: 209746e | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add semi-formal descriptions of all ops' semantics
cotto also, how did it get to be midnight? 07:01
msg dukeleto please review the m0 spec. It's pretty close to final as far as I can tell. 07:02
aloha OK. I'll deliver the message.
cotto msg atrodo please review the m0 spec. It's pretty close to final as far as I can tell.
aloha OK. I'll deliver the message.
07:09 rurban_ joined 07:11 rurban left, rurban_ is now known as rurban 07:16 bacek joined
dalek rrot/m0-spec: 05cbcb9 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add noop, add op numbers, move control flow to the beginning of the docs so ops are listed by number
 07:17
cotto bacek_at_work, I'm off to sleep, but I'd appreciate your review of the m0 spec. I think it's pretty close to done. 07:18
or bacek
07:21 mtk left 07:28 mtk joined
cotto msg plobsing When you have a few minutes, please review the m0 spec and let me know what you think. It's pretty close to final as far as I can tell. 07:29
aloha OK. I'll deliver the message.
dalek rrot/m0-spec: 589c9c8 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
various POD fixes
 07:37
07:40 JimmyZ joined
dalek rrot/m0-spec: 4f14e50 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
trailing spaces
 07:44
07:56 contingencyplan left 08:34 lateau1 joined 08:35 lateau left
JimmyZ msg cotto I left some comment on github.com/parrot/parrot/commit/05cbcb99b4, FYI. 08:39
aloha OK. I'll deliver the message.
08:46 JimmyZ left 09:45 lateau1 left, woosley left 09:59 ambs joined 10:08 woosley joined
bacek ~~ 10:15
moritz ..
10:24 Coke joined 10:25 ShaneC left 10:53 Eduardow left 11:26 lucian joined 11:30 mtk left
dalek rrot/opsc_llvm: d6710e7 | bacek++ | runtime/parrot/library/LLVM/ (3 files):
Mass add 'multi' to enforce check of types by PCC. Also remove some 'Str' and 'Int' because they are not supported by nqp/parrot
 11:32
rrot/opsc_llvm: fb03753 | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Wrap LLVM::Builder.call result into LLVM::Value
rrot/jit_prototype: 1b1c47f | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Implement registers
rrot/jit_prototype: 6d12eb5 | bacek++ | runtime/parrot/library/LLVM/ (3 files):
Mass add 'multi' to enforce check of types by PCC. Also remove some 'Str' and 'Int' because they are not supported by nqp/parrot
rrot/jit_prototype: e2eaf76 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Rework variables in %jit_context to store pointers.

This is preparation for proper handing of assignments.
rrot/jit_prototype: fd4926d | bacek++ | compilers/opsc/src/Ops/JIT.pm:
DRY: move loading of registers into separate function.
rrot/jit_prototype: cd5674e | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Wrap LLVM::Builder.call result into LLVM::Value
11:34 mtk joined 11:47 mtk left 11:48 mtk joined
mikehh bacek: ping 11:53
11:55 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
dalek rrot: 3fb52ac | mikehh++ | src/pmc/structview.pmc:
add default: to switch(s) to cut down on compiler warnings
 12:14
Coke good *, parrot 12:32
12:33 whiteknight joined
whiteknight tadzik: ping 12:35
12:36 darbelo joined, darbelo left 12:37 darbelo joined
mikehh whiteknight: I have been trying to clear up compiler warnings 12:38
whiteknight mikehh++
mikehh whiteknight: what do you do in the situation such as int i; size_t n; ... for (i = 1; i < n; i++) -> generates signed/unsigned warning 12:39
whiteknight I would try for (i = 1; ((size_t)i) < n; i++) 12:40
or if possible, change i to a size_t
size_t isn't obscure, per se, but when people use it there is typically a specific reason 12:41
mikehh we have quite a few cases of comparing an int to size_t
whiteknight msg tadzik I saw your proposal gist on github. I think I know the answer, but is that proposal for the TPF or for PaFo?
aloha OK. I'll deliver the message.
whiteknight mikehh: Do you have a list or anything? Some of those may be "safe" where we know the values involved aren't going to set off signed/unsigned comparison effects 12:42
others may be subtle bugs
12:43 bubaflub joined
darbelo whiteknight: Some compilers can mis-optimize signed-unsigned mismatches into subtle bugs :) 12:44
12:44 plobsing left
whiteknight darbelo: that's my point. We need to figure out on a per-case basis what the expectations are on the values, and make sure we fix each warning appropriately 12:45
mikehh I think I will compile a list of the warnings and usage 12:46
12:55 JimmyZ joined 12:56 JimmyZ left
tadzik whiteknight: for TPF. It's from epo.means.no/gsoc2011/ideas 13:06
whiteknight tadzik: okay, that's what I thought. Goodluck with it 13:08
tadzik whiteknight: thank you. Got any comments, criticism, ideas? 13:10
whiteknight tadzik: I will, if you want :) I'm murderlizing another proposal right now
in the good way
tadzik whiteknight: oh, I'd love to see your opinions 13:13
whiteknight: I'm still having some trouble with adjusting the schedule
whiteknight schedules are hard. No question about that
what's so hard about it is that you need to think about it before the project ever starts, but then it's going to be used during the project to measure your success 13:14
at least, it will be one metric for measuring success
I don't know what the TPF people want to see, but I want to see the students put a lot of thought into it, to make sure they have some kind of understanding of the possible pitfalls, but also of the things they are responsible for
lucian 7 weeks in gsoc right? 13:17
whiteknight I thought it was 12
lucian really? hmm
last year it was 7
whiteknight that short? I'm not sure I remember it being so short 13:18
lucian ah, you're right 13:20
on last year's timeline there were 7 official weeks for coding
13:21 wagle left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#13388) fulltest) at 3_2_0-97-g3fb52ac - Ubuntu 10.10 i386 (g++-4.5) 13:27
13:29 lucian_ joined 13:30 bluescreen joined
whiteknight coding this year seems to be from May 24 - Aug 22 13:30
so that's about 12 weeks 13:31
Of course, student proposals are accepted a month prior to that, so if the intrepid student wanted to start writing code early, unbeknownst to us, I guess that isn't a problem
13:31 lucian left
whiteknight that could be 16 weeks of coding, if the cards are played right 13:31
of course, I would never suggest anybody break the rules... 13:32
13:32 lucian joined
tadzik ...a time travelers? /o\\ 13:33
13:33 plobsing joined 13:35 lucian_ left
tadzik I need to try this time traveling. You will know that I succeeded if Parrot gets accepted for GSoC 13:37
mikehh switching to amd64 - bbiab 13:42
13:42 mikehh left
whiteknight tadzik++ 13:46
tadzik see? I told you 13:47
13:54 mikehh joined
whiteknight tadzik: I posted some comments on your gist. I hope they are helpful to you 13:58
tadzik whiteknight: just reading them. They are indeed, thank you very much for that! 13:59
whiteknight tadzik: I'm sure you know the importance of tests and docs. Many students coming fresh out of school have never heard of them
so I put a little bit of emphasis on their inclusion in the proposals, just to make sure everybody understands what the requirements are 14:00
but you're a perl6 guy.
you know all that stuff inside and out
you could probably teach me a few things about testing :)
14:01 cotto left
tadzik whiteknight: well, I thought that when applying to a Perl Foundation they know that testing is a obligatory part of the code, if not the prerequisite :) But of course I should mention that. And I _really_ doubt your last statement :) 14:02
PerlJam "to *a* Perl Foundation"? We've got more than one? :) 14:03
tadzik anyway, do you know how are mentors chosen? Does an organization assign mentors, or I am to convince one? 14:04
PerlJam: oh, I had that typo in my proposal too :)
there it was "a Parrot project"
14:04 bluescreen left
whiteknight tadzik: last year mentors were assigned 14:04
moritz tadzik: people just apply as mentors to an organization, the admin accepts or rejects then
tadzik moritz: well, I meant how are students assigned to the mentors 14:05
moritz tadzik: and when proposals are chosen, you are assigned a mentor. If you state a preference, it will make the assignment process easier, in case it's not obvious
PerlJam tadzik: people volunteer to mentor certain proposals or areas of interest
tadzik oh-oh, I'm so excited :}
moritz in the last years the possible mentors for the Perl 6 tasks (jnthn, masak, me, pmichaud) discussed things, and came to solution that suited everybody 14:06
and our admins basically just signed off our result
which is the best for the admin, because it's the least work :-)
tadzik (: 14:07
moritz it's a good idea if people who know the problem domain discuss the choice of mentors
14:09 bluescreen joined
tadzik I'm curious for the TPF proposal template includes the "Have any of them offered to mentor 14:09
your project?
...in the mentor section. Pardon my broken paste
PerlJam tadzik: it's a check to see if you're communicating.
14:10 cotto joined
PerlJam :-) 14:10
tadzik so it's a trap? :)
cotto ~~ 14:11
PerlJam tadzik: Well .... do you know who the domain expert is? Have you talked with them? and finally ... do they like your proposal?
PerlJam reads tadzik's proposal. 14:12
tadzik yes yes and how can I know :) 14:13
moritz doesn't know who the domain experts are, but those that responded so far have been favorable :-)
PerlJam I think you can safely assume that the authors for S26 are "domain experts" :) 14:16
s/for/of/
moritz so, TheDamian
tadzik is scared 14:17
moritz the chances of him mentoring a gsoc project is close to 0%, I think
PerlJam Oh, I thought TimToady was co-author on that one too
moritz: he'd make a terrible mentor anyway I think. Too intimidating :) 14:18
whiteknight being mentored by TimToady would be great
14:18 cogno joined
dalek nxed: r880 | NotFound++ | trunk/winxed_installed.winxed:
refactor installable driver and add option --target to it
 14:19
moritz whiteknight: TimToady mentioned once that he mentored on project (a 5-to-6 translater written in haskell), and that his mentoring was a desaster
PerlJam although ... tadzik was talking about time travel earlier ... perhaps he's ready for TheDamian :)
whiteknight moritz: maybe it's a disaster, but every meeting with your mentor would start with a humorous anecdote 14:20
tadzik yeah, I've been alredy mentored by him thrice for the last 5 minutes. Supercool :)
14:28 Andy_ joined
PerlJam for a company that "doesn't do stupid" they sure do have a lot of stupid in melange. 14:31
cotto On the one hand, yes. On the other, the melange devs don't have as much to work with as you'd think. 14:34
atrodo cotto> how so?
cotto from my understanding, melange is mostly a volunteer project that google happens to use. I don't believe that anyone's paid to work on it. 14:35
cotto goes to work
atrodo If that's the case, that makes sense. But why wouldn't google bring it in house if they use it every year for gsoc? 14:36
dalek rrot/m0-spec: a0e3cdb | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add register scheme, remove/rework some other bits
PerlJam and since they're spending ~$5million or so on gsoc, why wouldn't they spend a few thousand of dev time to do it right?
atrodo PerlJam> Exactly. Although, maybe the "not broke, don't fix" has come into play 14:37
PerlJam Not broke?!?!?
atrodo fsvo broke
PerlJam *every* year people complain about it. (but I guess since they continue to use it, the ill will generated is negated?) 14:38
atrodo PerlJam> That's what I would guess
14:40 cogno left
moritz it seemed to work fine last year, after some fiddling 14:42
whiteknight I think some students work on melange over the summer 14:57
www.google-melange.com./gsoc/org/go...11/melange 15:03
15:05 bluescreen left 15:07 mtk0 joined 15:08 mtk left
atrodo I thought they had students work on melange last year as well 15:08
whiteknight probably
15:09 rurban_ joined 15:11 rurban left, rurban_ is now known as rurban
cotto_work ~~ 15:15
15:16 wagle joined 15:22 bluescreen joined 15:24 mtk0 left 15:25 mtk joined 15:29 lucian_ joined 15:31 lucian left
tadzik whiteknight: I've updated my schedule according to your notes, could you take a look in some spare time? 15:39
whiteknight yeah, sure
tadzik thank you
that reminded me of the optional goals you mentioned 15:40
added now 15:42
whiteknight tadzik: I like the colorscheme on your tadzik.github.com page :) 15:43
tadzik oh, you can clearly see that I like yours too. That reminds me I haven't even said Thank You, shame on me 15:44
whiteknight++
whiteknight it's okay, that wasn't my work either. I got the colors from a friend of mine who is a graphics guy
I'm not colorblind, but you would never know from the color choices I make
15:45 bluescreen left
whiteknight tadzik: the new timeline looks much nicer. 15:45
tadzik well, I can differ the "pretty" from "awful", but somehow my own ideas always end up in the latter part
good to hear
whiteknight tadzik: is that parser going to be a built-in part of Rakudo, or a separate tool? 15:46
tadzik there is this test coverage issue in the last point, as there is no way to test the coverage of the Perl 6 code
moritz tadzik: I've read a nice book, "design for non-designers". It doesn't cover color schemes, but for me it was an eye-opener in other regards
15:46 rohit_nsit08 joined
tadzik whiteknight: built-in. I thought I made that clear, seems I can improve on that field too 15:46
lucian_ small update gist.github.com/891481 15:47
15:47 bacek left
rohit_nsit08 whiteknight: hello 15:47
whiteknight lucian++ I'll look at it now
rohit_nsit08: good morning
rohit_nsit08 good morning :-) ,
benabik Morning, #parrot.
whiteknight good morning benabik 15:48
tadzik whiteknight: note "the significant part of the Rakudo compiler itself"
whiteknight loves GSoC season :)
tadzik: yes, I see that now
tadzik: that's actually an awesome feature, I wish other languages had that
ability to access documentation from the code it's written in. Very hand
handy
tadzik python have their """, they're quite cool
benabik Heh. I'll probably have a couple proposals written by tonight. Have a could bits of schoolwork to finish first. :-/
moritz for pod you actuallye need a Perl 6 parser around, weird as it sounds :-)
tadzik the Declarator Blocks will be even more awesome though, so I'm ok with that :) 15:49
whiteknight moritz: No, I believe it
I was working on a C# project a while back that had a GUI with tooltips that popped up when you rested your mouse on it
and I was so upset that I had to write normal documentation AND tooltips, often right next to each other, and couldn't borrow
but .NET makes it impossible to access documentation from the code 15:50
rohit_nsit08 whiteknight: thanks for taking out time to make comments, i think i should wait for 1 or 2 days before submitting my proposal on google, so that i can get more comments on it and make it more precise
lucian_ you can hack it up with something like javadoc, but it's dreadful
whiteknight rohit_nsit08: that's okay. Take your time and get lots of feedback 15:51
NotFound whiteknight: maybe you can use attributes for that.
moritz whiteknight: actually that was one of the points. The second was that when I was actually writing some POD for a Perl 6 class, I noticed that I repeated all routine signatures (once in code, once in POD)
cotto_work I don't think proposals submitted via melange are final until the deadline.
whiteknight NotFound: yeah, I ended up using lots of attributes in that project
cotto_work There's no reason not to submit early and often. 15:52
moritz and signatures can contain arbitrary code
whiteknight moritz: and the ability to generate live help from the documentation is amazing
tadzik lucian_: I like the snowboarding note in your Proposal :) Very nice
moritz sub do_stuff(&callback = sub { }) { ... }
lucian_ tadzik: i figured i should be completely honest :)
dalek nxed: r881 | NotFound++ | trunk/winxed (2 files):
add target 'include' suggested by plobsing++, only available from installed
nxed: r882 | NotFound++ | trunk/pir/winxed_ (2 files):
update installable files
moritz that callback default could contain arbitrary Perl 6 code :-)
moritz so, no references to signatures without a full parser
tadzik lucian_: makes me want to mention Rabbit-Samurai comic books :) 15:54
lucian_ tadzik: whooosh 15:55
rohit_nsit08 whiteknight: got an assignment to finish, will catch u later. bye
whiteknight later 15:56
rohit_nsit08 ya in 2,3 hours
15:56 contingencyplan joined
rohit_nsit08 have to submit that in morning :-( 15:56
tadzik I have an exam tomorrow, but got to GSoCited to think about it :) 15:57
whiteknight yeah, it's an exciting time 15:59
16:00 bluescreen joined
dalek sella: 08b0d45 | Whiteknight++ | / (3 files):
Add in the ability to imitate isa and isa_pmc in the proxy library, now that Parrot has that capability. Add tests. Fix fallback in Proxy.Controller to do something sane in the isa_pmc case
 16:03
lucian_ has dissertation work to do. and write two games
whiteknight: i'd appreciate a second opinion on gist.github.com/891481 when you have time
16:03 lucian_ is now known as lucian
whiteknight lucian: what is your dissertation about? 16:04
lucian whiteknight: mobile SDK that itself is a mobile application 16:05
so you can build mobile apps directly from your mobile device
whiteknight oh fun
building apps? There's an app for that
benabik And it can't get approved on Apple's app store. :-/ 16:06
whiteknight Sup dawg, I herd you like apps. So we put an sdk in yo app so you can make apps while you app
cotto_work seen jimmyz
clunker3 JimmyZ was last seen on #parrot 7 hours, 27 minutes and 28 seconds ago, saying: msg cotto I left some comment on github.com/parrot/parrot/commit/05cbcb99b4, FYI.
aloha jimmyz was last seen in #perl6 3 hours 11 mins ago joining the channel.
whiteknight :)
oh clunker3, when will you ever learn? 16:07
cotto_work I wish I knew who owned it.
16:07 hercynium joined
cotto_work It's lta to keep kicking a bot without knowing who to talk to about it. 16:07
lucian benabik: whiteknight: i don't care much about apple 16:08
although phonegap apps do get accepted
whiteknight cotto_work: have you tried a whois on it, before kicking? 16:09
lucian an iphone dev could use this sdk on his iphone, the submit the finished app from his mac
benabik clunker3 appears to be in the Netherlands
PerlJam clunk3 appears to be connecting via somewhere in the netherlands.
cotto_work I don't remember seeing anything useful.
whiteknight nice
PerlJam benabik: jinx!
atrodo good think I read before I typed 16:10
moritz cotto_work: don't just kick it, ban it
atrodo any way to see if anyone else on the irc network has the same ip? 16:11
whiteknight it's a member of several perlish chatrooms. I'm sure we could ask around in those places
@#toolchain, @#smoke, @#perlworkshop.nl, @#perl-qa, @#p5p, @#msopensource, #itrc, @#dbi, #dbd-sqlite, @#bot-test, and @#amsterdam.pm
NotFound I'll be worried if it will be on @#skynet 16:12
dalek nxed: r883 | NotFound++ | trunk/winxed (2 files):
add target include to non installed driver
 16:13
atrodo irclog.perlgeek.de/parrot/2008-05-19#i_298780
apparently, this is an old problem 16:14
cotto_work atrodo: I want to steal your brains. 16:15
atrodo: can you take a look at the m0 draft?
atrodo cotto_work> I'm rather attached to my brain, although if I do infact have multiples, I suppose I don't need the extras 16:16
(but yes, it's on my lunch list to do)
cotto_work atrodo: thanks.
whiteknight lucian: I added some quick comments
lucian thanks
whiteknight: hmm 16:18
whiteknight hmm?
lucian whiteknight: isn't pdd31 dead? 16:19
whiteknight not dead. Still draft.
atrodo asking clunker3 for help gives me www.xs4all.nl/~hmbrand/clunker3.html 16:20
whiteknight it's not perfect, but several compiler objects follow it, in part
the bigger part of the question was about whether your compiler would be able to be imported as an object into other programs
moritz atrodo: that would be Tux 16:21
lucian whiteknight: not until it's bootstrapped
moritz I'll ask him to remove clunker3 permanently
whiteknight lucian: Okay, are you aiming for full bootstrapping by the end of the summer? 16:22
cotto_work moritz: thank you 16:23
lucian whiteknight: not particularly, only if things go very well 16:25
whiteknight okay, that's what I was thinking
lucian whiteknight: the only CPython-only bit is the 'ast' module 16:26
if that gets rewritten to pure python, it should bootstrap
whiteknight okay. Do you have a link to the source code or documentation for that module?
your proposal shows up when I google search for "CPython ast module" on the first page 16:27
tadzik oh, they do index github quite often, don't they
lucian whiteknight: oh. docs.python.org/library/compiler.html 16:29
this is in py2
whiteknight: docs.python.org/release/3.0.1/libra...ml#compile docs.python.org/release/3.0.1/library/ast.html 16:30
and the link in my proposal
tadzik and my axe
sorry, could not resist
16:30 pmichaud joined
whiteknight lucian: okay. It doesn't look huge, but big enough that we don't want to play with it over the summer 16:31
16:31 pmichaud left
lucian whiteknight: yeah, sort of what i thought 16:31
16:32 pmichaud joined
whiteknight once we have a python compiler which outputs PIR (or any other parrot language), we can use that to take things to the next level. Your project is the key central component 16:32
because like you said, other people can write the key components in python later, and then we can start bootstrapping more aggressively 16:33
lucian yeah, i'm actually sort of expecting someone to try and rewrite ast in pure python over gsoc
the object system is a sore point, though 16:34
whiteknight have you heard any specific project proposals ot that effect?
16:34 cgaertner joined
whiteknight yeah, a proper object system might have to wait until later, unless everything goes your way 16:34
cgaertner hello #parrot
whiteknight hello cgaertner 16:35
lucian: are you a committer?
a parrot committer?
lucian whiteknight: no
i can write it all in winxed, on top of parrot hashes
and with enough work it'll be fully python compatible
whiteknight okay. If you need anything changed in parrot core, let us know early 16:36
obviously we're constrained by the deprecation policy, but changes that don't immediately run afoul of that can go in quickly to support your work
lucian whiteknight: i don't really know what i want 16:37
parrot's Object thing seems entirely useless
cgaertner what does the vtable function invoke() return? the value has type opcode_t*, but what *IS* it?
whiteknight s/seems/is/
lucian right. 6model, i don't know
whiteknight cgaertner: opcode_t is the compiled PBC instructions
cgaertner: a PBC is a huge array of opcode_t. The current instruction is a pointer into that array 16:38
cotto_work not quite
16:38 estrabd joined
NotFound The main problem I found while doing test for protoptype based objects is the method cache, it is not easy to avoid it. 16:38
whiteknight not quite, but close enough for this explanation
cgaertner whiteknight: after or before execution of the sub?
cotto_work ok
whiteknight cgaertner: invoke returns where the flow should go 16:39
plobsing would be nice if we could avoid working with raw opcode_t pointers where possible. conceptually, a bytecode location is a segment and an offset.
whiteknight cgaertner: it's tricky because there are two types of sub. a sub defined in PIR jumps to the beginning of a sub
plobsing perhaps invoke should return that in stead
lucian NotFound: right. but parrot Objects are entirely wrong for most dynamic languages they way i see it. classes don't even seem to be objects themselves
whiteknight a native function, like an NCI, returns the address where to go after the function is called
lucian: Classes are PMCs, but they make a few weird semantic decisions that make them....weird to use 16:40
lucian whiteknight: but they aren't Objects
whiteknight no, not Objects
lucian there you go. in most dynamic languages, they are
whiteknight and, if I remember correctly, Class can't be subclassed from PIR
lucian it's hart so simulate it
cgaertner whiteknight: somewhat confusing, but reasonable once you think about the interaction VM/native code
whiteknight lucian: Well, Object is just a type of PMC with most of the same behavior
lucian s/hart so/hard to/
whiteknight in Parrot, Object is just a weird wrapper type that tries to map user-defined behaviors to PMC calls 16:41
lucian hmm
NotFound All workarounds I've tried finally blocks on the method cache.
whiteknight let me say the word "weird" a few more times
lucian NotFound: can that be disabled?
whiteknight no
lucian that's dumb
anyway, what other options are there?
whiteknight we could try to add in a way to disable it
lucian besides 6model which is risky to target
NotFound Maybe we can add a flag to the Class PMC to disable it. 16:42
whiteknight NotFound: if we can make Class subclassable, we could do that kind of stuff much more cheaply
we could have a lot of win by subclassing Class
benabik lucian: How's 6model risky?
lucian benabik: it appears very unsuitable for python, and nothing but perl6 uses it
NotFound whiteknight: the problem is that Class and Object internals are abused from lots of places. 16:43
cgaertner Class isn't subclass-able - that's... unfortunate
whiteknight I think the "unsuitable for python" designation is undeserved. As I understand 6model, it's very low-level and language agnostic
NotFound: exactly
16:43 davidfetter joined
whiteknight NotFound: What's interesting is that we could probably *improve* performance if we properly encapsulated those things 16:43
benabik whiteknight: That matches my understanding. 16:44
lucian whiteknight: i don't really know, i've just read the docs. the descriptions sounded very discouraging
atrodo cotto_work> reading the newest m0-spec now
whiteknight lucian: maybe not. Maybe we need another option
lucian: I've been hopeful that we would be able to build a diverse set of object models on top of 6model
not without some major grunt work, of course
NotFound whiteknight: yes, but to do it is small steps we probably must to decrease performance by disabling local tiny optimizations. 16:45
lucian whiteknight: perhaps. but it should be stress-tested against weird, different object systems
whiteknight NotFound: we could have subclasses of Object which did different caching, did less searching for vtable overrides, made fewer assumptions, etc
lucian personally, i couldn't care less about speed
whiteknight NotFound: yes, short term would see problems, but in the end we would see big benefits
NotFound: Depending on application, 90% of Parrot objects might never use vtable overrides 16:46
lucian whiteknight: for example, i also don't see how 6model could support CLOS
whiteknight so if we create an Object subclass which never looks for them, we save huge
NotFound I'm sure a lot of rakudo guys will cry loudly for any small speed decrease.
lucian goes to help make food. brb10min
whiteknight NotFound: So we do the decrease and subsequent increase in a branch
NotFound: I think Rakudo is using their own object model now anyway, so it doesn't matter
NotFound: They might gain performance, if we stop making assumptions that our object model is the only one 16:48
dalek rrot/m0-spec: 85b4904 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add register aliases in disassembled bytecode segments, various other fixes
 16:49
benabik whiteknight: Rakudo hasn't moved to 6model yet, AFAIK. They're still using parrot-nqp, I think.
cotto_work atrodo: ^
atrodo: thanks!
whiteknight benabik: that may be true. I haven't been keeping track of their progress. I'm not entirely certain that they've been dependent on Object for all their uses anyway
benabik: github.com/rakudo/rakudo/blob/mast...opaque.pmc 16:50
benabik: it looks like they're using their own Object subclass now anyway
atrodo cotto_work> the registers is new, so I have some questions on it, and how it works 16:51
cotto_work atrodo: fire away
atrodo cotto_work> first, I don't understand where the 64k slots comes from
benabik whiteknight: Yes. It's still a subclass of Parrot's object for now. I haven't seen much movement towards putting it on 6model, although I think that's coming soon as NQP seems to have begun to stabilize. 16:52
cotto_work that's the variables table. Since get_var is used to access it, there can be a maximum of 256*256 slots directly accessible to m0 ops.
atrodo the registers live in the context as slots 0-255, with a few being special? Do I understand that right? 16:54
cotto_work atrodo: yes
16:54 benabik left, benabik joined
atrodo then you have another bank of registers attached to the context as slots 0-64k? 16:55
cotto_work that's the variables table. I guess I didn't define how that's accessible to a context. 16:56
NotFound TT #1857 -> Who can update the nqp-rx bootstrap pir files? 16:58
atrodo So, when I create a new context, does the variables table get copied (or "copied") for the new context from the file? 16:59
or does a context share the same variables table with all the contexts using a particular code segment? 17:00
cotto_work I'm picturing variables getting COW'd per-context as they get changed from what's originally in the file. 17:02
atrodo: are you adding these questions to the spec or should I? 17:03
atrodo cotto_work> I'm trying to understand what's going on with it right now
cotto_work atrodo: ok. I'll make sure that the spec addresses what you bring up.
atrodo cotto_work> So if I understand the variables tables, on the one side it's to load constants (that can be changed) from the bytecode and on the other side it's the scratchpad area 17:05
right?
cotto_work atrodo: exactly. 17:06
That's why it's not a contstants table.
*constants
atrodo cotto_work> And if I understand it correctly as well, it's just pointers and numbers in the variables table, right? There's no typing that goes on for each slot 17:08
So, for instance, if I do add_i 5,6,7, and 6 was a pointer, 5 would end up being the addres of the pointer plus the value of 7 17:09
cotto_work atrodo: yes. Typing is by convention. You can do add_i N0, N1, PC and it'd run.
not a good idea, but possible
atrodo cotto_work> besides that giving me the willies and slightly scary, i'll try to come back to that issue 17:10
cotto_work afk 3m
atrodo Wow, I read that as 3 months
benabik atrodo: I've seen away messages like that. Friend of mine left his computer on during vacation once: "Idle for: 1 month, 12 days" or something like that. 17:12
atrodo benabik> haha, excellent use of electricity there 17:13
cotto_work going to mars. bbs
lucian no power management, i take it
atrodo fsvo soon
davidfetter very envious of vacations of this duration, having taken his very first paid vacation last month 17:14
benabik lucian: Was a linux box ~2000. Suspend wasn't exactly stable, IIRC.
lucian i see
plobsing NotFound: I'm not sure if this is a parrotbug or a winxedbug, but 'winxed -I src' does not work as intended. I need to use 'winxed -I src/' to achieve the desired result.
17:14 rurban left
benabik davidfetter: Well, was a summer vacation during college. Easier to take long trips when you're not expected to be anywhere for three months. 17:14
atrodo cotto_work> I wonder if that extra level of indirection is needed. For instance, what if you accessed the variables table through the context intead 17:15
cotto_work> although, i'm not sure how many more questions that opens up as well 17:16
cotto_work atrodo: yes. The amount of indirection is a concern.
NotFound plobsing: If I remember well is an over simplification in the parrot side, to avoid worrying about lots of corner cases. 17:18
cotto_work I'm looking forward to writing an interp that can print 101. 17:19
17:20 ShaneC joined 17:23 ShaneC left
atrodo cotto_work> I choose the route to have a "load_const" opcode that allowed easy loading from from another segment 17:25
Although, being able to use the current context to load it might accomplish the same thing
cotto_work atrodo: I'm thinking of chunks (bytecode segment + variables table + metadata segment) as roughly analogous to a sub. 17:26
atrodo cotto_work> right, so do I, although my prototype is a little more rigid in it's working 17:28
cotto_work What's the use case for one code segment fiddling directly with another's variables table? 17:29
atrodo Oh, I think I explained that poorly. In my prototype you can't. You load consts from the context's associated constant segment and have access to another segment as a shared data segment 17:32
lucian is back 17:34
whiteknight: are you familiar with 6model? 17:35
whiteknight not as familiar as I would like 17:38
eventually I need to close up the windows, lock the doors, and spend a weekend just playing with it
lucian right. so much more familiar than me 17:39
whiteknight :)
lucian are you familiar with python's object system?
whiteknight even less
although I'm gathering that it's not entirely dissimilar to JavaScript
lucian not entirely, i suppose
whiteknight if you ignore the part about cloning a prototype
lucian objects are almost big hashes, like javascript ones 17:40
whiteknight right
lucian methods are just attributes that happen to be callable
similar to how you'd do it in js too, i guess
whiteknight right, those are the similiarities I think I have seen 17:41
benabik lucian: Identical to JS. The prototype is basically just a set of default attributes.
lucian also, just like in js you can change things at runtime
17:41 darbelo left
lucian benabik: the description is handwavy, so not quite identical 17:41
of course in python you also get classes, and a bunch of other things
benabik lucian: Handwavium is the magic ingredient that makes any computer language work. 17:42
lucian so knowing this, how would it be mapped to 6model?
6m seems to assume that objects will have methods, for example
benabik Although there are separate functions to find attributes and methods, I don't think there's a reason that methods and attributes can't share a namespace. The method cache is a bit of a problem, but I don't think it has to be populated. 17:44
benabik has spent a little bit of time following NQP's conversion to 6model.
lucian hmm. i guess i wouldn't mind getting the method cache populated eventually, and have the cache invalidated when attributes change 17:45
the issue i see is that python makes no difference between methods and other attributes
they're all references to objects
whiteknight: i might re-allocate week 1 to deciding 6model vs custom 17:46
whiteknight that does sound like the perfect kind of topic to explore during the community bonding period 17:47
or, even start on it now in anticipation
benabik object.method() is basically object[method].invoke() or similar?
lucian i don't really have time for it now
benabik: it's literally object.__dict__['method_name'].__call__()
whiteknight lucian: my only point is that you don't need to wait 17:48
lucian whiteknight: right
benabik: any object with a __call__ method can serve as a method. also, self is passed explicitly
whiteknight so __call__ is not an object itself? 17:49
lucian whiteknight: it's a function, so it is an object itself as well 17:50
whiteknight ok
17:50 dmalcolm joined
lucian anything you can get a reference to is an object 17:50
i'd say "everything is an object" but it wouldn't be quite true, since if statements aren't
benabik There has to be something in there that prevents it from becoming __call__._call__.__call__... 17:51
whiteknight yeah, that's my point
lucian benabik: there is, at some point it's defined function
that is, one of them will be a function with bytecode to execute 17:52
benabik Ah. So it calls __call__ iff it can't find bytecode for the object?
lucian benabik: sort of, yes
the main exception is native code
whiteknight so the __call__ method of __call__ itself is native code? 17:54
or do we hit native code bfore that point?
17:54 ShaneC joined
whiteknight actually, that's an implementation detail which probably doesn't matter 17:54
benabik I'd imagine the __call__ method of a compiled function is native.
17:54 jevin left
benabik Which gets passed the function object as it's first parameter. 17:55
lucian whiteknight: uh, it's interpreter code
benabik: not quite
benabik: the interpreter special-cases "native" code. you can check the source 17:57
benabik lucian: It would have to. But when you use object.__dict__('method'), I'd imagine that you'd get an object back that has the bytecode in it and whose __call__ attribute is the "run bytecode" builtin. 17:58
lucian benabik: yes, roughly 17:59
benabik Can built a very complex language with very few builtins that way. It's fairly elegant.\\ 18:00
lucian yes, it is
benabik The explicit self parameter even makes those builtins simpler to write, even if I'm not a fan of it.
atrodo cotto_work> I'm also very concerned about security and stability (segfaultable) at this point
lucian benabik: that too. it also makes a lot of other things easier 18:01
benabik: for example, super calls. you could do SuperClass.__init__(self, bla...)
where SuperClass is the parent class, __init__ is its constructor
atrodo is self set as the last object that had a lookup?
cotto_work atrodo: M0 lives at a level similar to C. Security should be built on top of M0.
atrodo cotto_work> Even if we're passing m0 bytecode around? 18:02
plus I like to think we can make the world better than C, but that's beside the point
18:02 jsut_ joined
benabik lucian: It just makes the basic case of writing code more tedious. I hate writing self over and over again. And forgetting the self parameter makes code go boom. 18:02
lucian: But I agree that it makes many cases of meta-programming pretty.
lucian benabik: meh, i guess that's something one gets over
btw, it also makes multi-dispatch trivial 18:03
cotto_work atrodo: I'm open to suggestions. Pointers imply pointer abuse, and I don't think we can do without pointers and still have the same power as C.
lucian and fully native
cotto_work: i like cyclone's fat pointers
atrodo cotto_work> one idea chromatic had at one point was instead of C pointers, use array indexes into a PMC table 18:04
lucian in cyclone, fat pointers allow arithmetic, but do bound checks around it
cotto_work lucian: at runtime or compile-time? 18:05
benabik lucian: It makes the things that average programmers don't worry about easy but adds to every programmer's workload. I understand it and even appreciate the elegance, but it's not a language design decision I like.
atrodo lucian> cyclone.thelanguage.org/wiki/Cyclon...s#Pointers ?
lucian cotto_work: the actual checks happen at runtime
cotto_work How does that affect runtime performance? It sounds expensive.
lucian atrodo: yeah
cotto_work: i don't really know, cyclone is half-dead 18:06
pointer arithmetic is strongly discouraged in general in cyclone
so the idea is it should happen rarely
cotto_work lucian: that's unfortunate. I'm certainly not above stealing from it though.
18:07 jsut left
lucian cotto_work: it is a very nice C replacement, design-wise 18:07
it's pretty much impossible to segfaults it
atrodo except these tables probably won't be cast as pointers since it'd be mixed types
18:08 rohit_nsit08 left
lucian cotto_work: there are some related research papers, and the creator(s) might be willing to discuss it 18:08
atrodo but the concept is pretty cool
cotto_work In general, such pointer-safety strikes me as the kind of thing that should be done on top of M0. 18:10
lucian cotto_work: we've disagreed before about M0's "thickness" :) 18:11
atrodo I'd argue the other way. I think pointer safety (and security) is important enough to include at the ground level
lucian some hardware helps with such pointer checks
cotto_work lucian: I'm not adamantly opposed to the idea.
atrodo especially if we're interpreting any random m0 code we're given 18:12
cotto_work but segfaulting is only one kind of bad thing that malicious code can do
lucian to me, anything that common hardware can do at the assembly-level should be doable from M0. that way, JITs can either emulate missing behaviour or use the native one
atrodo if we had only one M1 that we controled, that could be doable
lucian cotto_work: sure, but pointer checks removes more problems than just segfaults
cotto_work (Don't misconstrue me as saying that because we can't solve all problems, we shouldn't try to solve some. Unsegfaultable M0 would be nice.) 18:14
lucian personally, i think C is unsuitable for writing systems 18:15
Cyclone is much better, and some VMs are even better
so if M0 mirrored Cyclone rather than C, i'd be happy 18:16
atrodo cotto_work> PMCs are just blocks of memory at this point, right? Would a PMC have any kind of header that is guaranteed to be there? 18:18
cotto_work lucian: are you thinking about more than just cyclone's pointers?
atrodo: the P and S registers point to chunks of memory. M0 makes no further assumptions. 18:19
lucian cotto_work: i don't think anything else is relevant to parrot
but there's a lot of pointer stuff in there
cotto_work Too bad cyclone never took off. It'd be nice to see it used in some kind of production environment. 18:20
lucian indeed.
there's a bunch of pointers, pointer-array stuff, pointer-struct stuff, exceptions
oh, and let 18:21
cotto_work exceptions?
lucian yeah, pretty cool
cotto_work: in here cyclone.thelanguage.org/wiki/Cyclon...rogrammers
atrodo cotto_work> What I'm thinking is, we have a (probably per-interp) array of equal sized pmc headers and a PMC reference is an index into that array
Then each header contains the only pointer to the actual data 18:22
lucian there's also some polymorphism stuff, but again not relevant to parrot
cotto_work That looks like a very useful page. Expect plundering.
lucian also, cyclone.thelanguage.org/wiki/Papers 18:24
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#13406) fulltest) at 3_2_0-97-g3fb52ac - Kubuntu 10.10 amd64 (g++-4.5 --optimize --gc-gms)
atrodo lucian> I wish I had less to do at work, that looks like something I should read intently
cotto_work I figure I'll have to declare the M0 spec
"final" at least 5 times before it becomes true. 18:25
It feels really good to get to the first time.
#parrotsketch in 124 18:26
atrodo cotto_work++ for the reminder 18:27
cotto_work let's see if dukeleto remembers this week 18:28
dukeleto tries to remember 18:29
18:29 jevin joined 18:31 plobsing left 18:35 zby_home joined 18:36 Eduardow joined 18:45 darbelo joined
cotto_work hio darbelo. 18:50
planning on another round of gsoc?
darbelo Not really. Not as a student, anyway. 18:55
I could probably try mentoring someone, but I'm not sure I'm qualified for that. 19:00
whiteknight darbelo: not qualified? Do you have any idea who you are? 19:01
darbelo I thought I did, but now you are making me doubt it :) 19:03
PerlJam whiteknight++ using self-doubt as a motivator ;) 19:04
lucian he's very crafty, that one 19:05
dukeleto darbelo: you definitely could be a mentor 19:08
darbelo: if you are not up for being a "formal" mentor, then definitely an informal mentor
whiteknight darbelo: In fact, sign up now or I will taunt you and remove your precious karma 19:09
do it
dukeleto msg Coke yes, parrot is using parrot-dev for gsoc-related stuff
aloha OK. I'll deliver the message.
darbelo Ok, ok. Where do I sign up?
benabik I offered to mentor in git a while back. I'm not one of the 'main' developers, but I knew my way around the code and I had time.
dukeleto cotto_work: i will take a look at m0 soon 19:11
benabik: libgit2 bindings for parrot would be pretty cool
benabik dukeleto: Not a bad idea, although not sure how'd it get used. 19:13
lucian benabik: write a better UI to replace 'git'
benabik lucian: There's probably going to be several git2 projects this summer, although I think their aim is to just move existing CLI onto libgit2 19:15
lucian benabik: at the very least that, i'd hope
but the way i see it, that's only for backwards compat
the the existing CLI is horrible, someone should make a new, better one 19:16
19:16 bubaflub left
lucian take hints from hg and bzr 19:16
NotFound Drop vocals and call it 'gt'? 19:17
benabik lucian: The nice thing about git is that it exposes the internals on the CLI. There have been several shell wrappers to git that gave different interfaces. No small number of their concepts have been absorbed into git.git
lucian NotFound: good idea, that
benabik: i wouldn't call that nice 19:18
dukeleto benabik: it would allow programmatic access to git repo from Parrot and languages built on Parrot
s/git repo/git repos/
lucian benabik: it's "nice" since it didn't do the proper thing, to provide an actual lib
benabik lucian: It was originally a series of shell scripts itself, so writing a library would have been... overkill. And the existent core makes several assumptions that are hostile to turning it directly into a library. Hence libgit2. 19:20
lucian benabik: sure, i know. i find the whole thing silly
benabik dukeleto: I've added it to my ideas list and may turn it into a GSoC proposal if I ever finish the review for school. 19:21
cotto_work dukeleto: thanks 19:24
benabik lucian: Silly maybe, but it works. :-D 19:25
lucian benabik: badly
look at the UI 19:26
benabik lucian: The pretty wide adoption seems to indicate it works just fine for most people. 19:27
dukeleto lucian: i prefer patches and tarballs, myself
lucian benabik: adoption is rarely an indication of quality
it's mostly "linus said you're stupid and ugly if you don't use it"
meh, the discussion is sort of pointless 19:28
benabik lucian: It's an indication of functionality... Most people don't use things that don't work. I'm not saying it's the best, I just disagree that it's bad.
lucian: Fair enough
Coke solidifies his irc-view of lucian. ;)
lucian it just pains me to see people invest so much in a dvcs with such a bad UI, when there's significantly better around
Coke: how so?
Coke lucian: you dislike many things. 19:29
lucian Coke: of course, what sort of designer/programmer would i be otherwise?
Coke nttawwt.
benabik "Perfect is the enemy of good."
(Although nice to aim for.) 19:30
lucian benabik: i never said perfect, just better :)
darbelo dukeleto: So, where do I sign in order to mentor?
Coke darbelo: www.google-melange.com/gsoc/homepag...e/gsoc2011 19:31
lucian Coke: i especially dislike things that have obvious and fixable flaws 19:32
darbelo Oh, I thought you were keeping some parrot-side bookkeeping.
cotto_work Awesome. github is hiring a libgit2 hacker. 19:33
benabik lucian: Not sure why you think it's so horrible, but sure. I've found VCS UI to be 90% identical for everything, the major difference being the underlying model.
lucian benabik: it's not quite so identical. perhaps i took too many ui/ux design modules 19:34
benabik lucian: add, diff, log, init, commit, pull, push. 90% of my tasks can be performed in either with neigh-identical command lines. 19:36
lucian benabik: merge, revert, fork, branch 19:37
cotto_work Interesting. It looks like he was previously a gsoc student. 19:40
19:40 bubaflub joined 19:41 mberends joined
dukeleto cotto_work: github has been paying last years GSoC student to continue working on libgit2 19:41
cotto_work: his gsoc project turned into a github job. Not bad.
cotto_work Good for him, great for the oss world.
benabik lucian: And that's where you get into differences in the underlying model. Git, hg and bzr have different ideas about how branching and merging works. In those areas git's UI is very directly related to the underlying model. The last few versions of git have had some strong direction towards making simple things simple while keeping hard things possible.
cotto_work I was pretty surprised to find out that libgit.a was the closest thing to an api that git had. 19:42
lucian benabik: perhaps git's model is bad if it can't be translated to a UI that makes sense
benabik cotto_work closest thing to an API that git has is the command line. Designed to transmit data over STDIN/OUT. 19:43
lucian: I'm still not sure why you assert it doesn't make sense. 19:46
lucian benabik: have you used hg or bzr significantly?
benabik lucian: No. Used hg for a bit to interact with one project, but found it a somewhat frustrating experience. 19:47
lucian benabik: hmm. most operations in hg are a lot simpler than in git
like merging with a branch in a remote repo 19:48
Coke for you and allison, this is apparently true.
benabik lucian: Simpler than "git pull URL branch"?
lucian benabik: except that doesn't always work in git
NotFound I hope you are not planning to switch repo machinery one more time. 19:49
lucian benabik: with hub on top, it's great
allison I'm coming to the conclusion that source control systems are like programming languages: different ones fit with different brains
PerlJam allison: All tools are that way.
benabik lucian: I'm not sure when that wouldn't work other than fetch or fetch failures.
allison hg and bzr do fit better with mine than git does
benabik *fetch or merge
PerlJam allison: *especially* tools you're likely to use often
lucian benabik: hmm, i'll have to dig that horrible example
cotto_work NotFound: unless something comes along that's as much more amazing that git as git is as svn, it's unlikely. 19:50
lucian allison: well, that happens with a lot of tools
cotto_work thinks he broke English
lucian don't get me wrong, git is much, much better than svn
cotto_work files a bug
atrodo I could never grasp why or how cvs did anything. Then I read about git for about an hour (when it was pretty new) and it all made sense
benabik apologies for hijacking the channel.
lucian and it's an ok dvcs. just crappier UI that the competition
allison cotto_work: English segfaults a lot 19:51
lucian allison: cotto_work: and most of us have GCs in english
atrodo allison> they should really fix that bug. For years, it's been SEGFAULT
allison lucian: chomsky would agree with you 19:52
cotto_work atrodo: easy. Step 1: engineer a virus that fixes people's brains.
allison Step 2: watch the virus mutate...
atrodo Step 3: Horror Film 19:53
allison Step 4: yay, brains can segfault too! :)
NotFound We should switch to more advanced terminology. Instead of segfault we should talk about "software singularity". 19:55
cotto_work allison: if you have a few spare cycles, I'd appreciate you taking a look at the M0 spec and letting me know how many things I've got horribly wrong.
benabik Okay, I should really buckle down on this review so I can buckle down on GSoC proposals.
cotto_work github.com/parrot/parrot/blob/m0-s...d32_m0.pod 19:56
allison cotto_work: sure, will take a look now 19:57
Coke drops a hint that he hopes his ubuntu netbook is usable again soon. :)
mikehh #ps in 30 minutes 19:59
lucian Coke: me too! 20:00
Coke: mine's ARM and can't play video yet ... or not freeze for a long time
20:01 bacek joined
cotto_work g'day bacek 20:01
atrodo: how far from the M0 spec is the assembler for your Lorito prototype? Do you think it'd be easier to use it as a starting point or to start from scratch? 20:07
allison cotto_work: +1 on extreme continuation-passing-style 20:08
cotto_work allison: what's the motivation behind that? 20:09
allison cotto_work: oh, side comment as I'm reading
cotto_work: from the Design Goals section 20:10
cotto_work allison: I mean "What's the motivation for pervasive CPS?"
allison cotto_work: to permanently eliminate the inferior runloop problem 20:11
cotto_work: as well as the security flaws associated with stack breakage
cotto_work: and opening up the door to more Erlang-like concurrency implementations
whiteknight that's what I'm most hopeful for. The concurrency implications are the most profound 20:12
allison cotto_work: the starting milestones are very sensible, achievable 20:13
that's good
cotto_work: what's the motivation on the fixed number of registers in Contexts? simplicity of allocation? 20:15
cotto_work: it can also increase pressure on the GC, so a bit of a balance
cotto_work that and the ability to put instructions into 4 bytes.
If bytecode segments correspond roughly to subs, I don't see 62 of each INSP being a difficult limit to work with. 20:16
*INSP register 20:17
allison cotto_work: it's worth making that explicit in the doc, as it's a pretty big change back to an earlier stage of design 20:20
cotto_work allison: yes. I've added it to my notes to make that explicit. 20:21
allison cotto_work: cool
bubaflub whiteknight: thanks for the comments on my gist. i'm going to do one more update and update the submitted proposal 20:22
whiteknight bubaflub++
20:22 fperrad left
cotto_work A big part of the value of having other people look at the spec is finding where I haven't mentioned my assumptions. 20:22
tadzik did somebody apply to Language Interop already?
cotto_work tadzik: what do you mean? 20:23
atrodo cotto_work> As the differences stand today, it'd probably be easier to restart. With some changes, we could get the two close enough to make my prototype work
allison> My understanding was that as long as we had embedders/extenders that the inferior loop problem would exist 20:24
tadzik cotto_work: there's a GSoC task for Language Interoperabitily, I wonder if somebody's interested in this for I'd really like to see that done
allison atrodo: there's a difference between "I'm calling out to a C library and get C-like behavior" and "I randomly get C-like behavior at odd points in my pure-Parrot code" 20:25
cotto_work tadzik: ah. You don't have to do one of those tasks. They're just suggestions.
tadzik: trac.parrot.org/parrot/wiki/ParrotG...11Students
tadzik cotto_work: yeah I know, I just wonder if that will be done in the near time 20:26
atrodo allison> when you put it that way, that makes more sense
whiteknight tadzik: That's Tene's big project. You should definitely talk to him about ideas
cotto_work tadzik: if you're interested, please add yourself to that page. 20:27
tadzik cotto_work: I'll be applying to the Pod parses for Rakudo Perl 6 probably
20:28 plobsing joined 20:29 whiteknight left
mikehh #ps time 20:29
20:30 Eduardow left
benabik Hm. Can't edit the students page. Should I just mention things to add to that page for me here? 20:31
cotto_work benabik: what's your account on trac?
benabik benabik. I'm creative with usernames. 20:32
cotto_work benabik: try now
benabik Hey look, an edit button. cotto++ 20:33
cotto_work Sorry about requiring manual intervention. We've had an excess of trac spam recently.
20:33 soh_cah_toa joined
benabik cotto_work: No problem. Would rather have to poke someone than deal with dalek constantly telling me I need to buy something. ;-) 20:34
dalek rrot/opsc_llvm: aa6f66d | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Merge Builder.insert_into_builder and _with_name versions into one.
rrot/opsc_llvm: 05f30bb | bacek++ | runtime/parrot/library/LLVM/ (2 files):
Made to always be named parameter for consistency
rrot/opsc_llvm: 0e06465 | bacek++ | runtime/parrot/library/LLVM/PassManager.pm:
Remove useless Str
20:37 lucian_ joined 20:38 lucian left 20:39 lucian_ is now known as lucian 20:43 lucian_ joined, perlite left, ambs left 20:45 perlite joined 20:46 lucian__ joined 20:48 lucian left, lucian__ is now known as lucian
dalek tracwiki: v8 | benabik++ | ParrotGSoC2011Students 20:50
tracwiki: trac.parrot.org/parrot/wiki/ParrotG...ction=diff
21:00 donaldh joined 21:02 cgaertner left 21:04 lucian_ left 21:05 wagle left, cgaertner joined
dalek tracwiki: v9 | cotto++ | ParrotGSoC2011Students 21:06
tracwiki: fix formatting
tracwiki: trac.parrot.org/parrot/wiki/ParrotG...ction=diff
benabik oops
cotto_work easy mistake, easy fix
21:07 darbelo left
allison cotto_work: oh, I just realized you were talking about a fixed number of registers in ops, when I was talking about the fixed number of registers in the context 21:07
cotto_work allison: I don't see those as being different. An instruction can address any of the 256 registers in a context. 21:08
allison cotto_work: so you were talking about the context, and not the fixed number of arguments to ops 21:09
(which is a much smaller number than 256) 21:10
cotto_work yes, exactly 3 per op
allison is $0 intended as a register, agnostic of type? 21:11
cotto_work allison: yes
allison (i.e. could be any of INSP)
in the case of SP, is $0 actually the string/object pointer? 21:13
cotto_work SP?
ah
yes 21:14
allison as opposed to I and N
hmmm... it might be easier if the notation were something like R0, R1, etc
atrodo oh, i just thought of something. sizeof(N) != sizeof(ISP) 21:15
allison (or at least, less likely to expect $0 to be the actual value for SP)
cotto_work One problem is that I'm not sure if we can avoid having both C-style strings and full object strings. 21:16
allison C-style strings are really just arrays of ints
(though, compact ones0
)
cotto_work right
dalek rrot/opsc_llvm: e055329 | bacek++ | runtime/parrot/library/LLVM/Constant.pm:
Fix LLVM::Constant signatures.
 21:17
allison cotto_work: that's not so bad
cotto_work It's inevitable if M0 doesn't know anything about the object model though.
dalek rrot/jit_prototype: aa6f66d | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Merge Builder.insert_into_builder and _with_name versions into one.
rrot/jit_prototype: 05f30bb | bacek++ | runtime/parrot/library/LLVM/ (2 files):
Made to always be named parameter for consistency
rrot/jit_prototype: 0e06465 | bacek++ | runtime/parrot/library/LLVM/PassManager.pm:
Remove useless Str
rrot/jit_prototype: c46a38e | bacek++ | / (3 files):
Merge branch 'opsc_llvm' into jit_prototype
allison cotto_work: it's more a question of how low-level to make M0's strings
cotto_work: or, whether to make Lorito's strings fundamental primitives at the M0 level 21:18
21:18 soh_cah_toa left
bacek For the record: LLVM doesn't have "strings". It's just "int8*" 21:18
NotFound We can also say that C strings doesn't exists. 21:19
lucian do other jit bakends do? (this includes x86) they don't afaik
would it be smart to have them? i'd guess yes
cotto_work allison: I tried to be explicit in op descriptions when the value of the register is used vs when it's dereferenced.
lucian not sure at which abstraction layer
allison cotto_work: honestly, I think it was just the $ that was confusing me, I'm too conditioned by Perl to expect that to be a variable 21:20
cotto_work allison: That's funny. I adopted the notation from our .ops files hoping that it'd be familiar. 21:21
allison cotto_work: hmmm... in the ops files I think of $0 as the "variable" when it's S or P too 21:22
it's not, but then the syntactic sugar pretty much hides that fact 21:23
drifting off a bit into bikeshedding here :) R0 is familiar from compiler literature 21:25
cotto_work: so at M0, it has the ability to store P and S, but not to operate on them 21:27
cotto_work: which makes sense, as they're more complex, composed data-types
21:27 lucian left
allison cotto_work: and therefore need more complex, composed operations 21:28
21:28 lucian joined 21:31 jsut joined
dalek rrot/jit_prototype: 50bd6be | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Fix merge error.
 21:34
rrot/jit_prototype: 1353044 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Rework handling of variables (including registers) to be more generic on LHS of assignements.
lucian allison: time to chat about pynie a little? 21:35
allison lucian: sure
lucian allison: there's a proposal draft, let me find a link
21:35 jsut_ left
lucian i was wondering whether there are better options for the object system than a custom one 21:35
6model appears to be what everyone looks forward to 21:36
dalek rrot/opsc_llvm: 0b16604 | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Fix merge error.
 21:38
allison lucian: it basically boils down to the implementor's inspiration 21:39
lucian: if 6model inspires you, then it's reasonable to target it
lucian allison: hmm. i mostly can't understand whether it's flexible (or mature) enough 21:41
allison lucian: mature, probably not (yet); flexible, the only way to find out is to try
lucian allison: proposal gist.github.com/891481 21:42
cotto_work or talk to jnthn
allison lucian: there's two sides to it, if you try it out with the understanding that you'll just chuck it if it isn't flexible enough, then it's very low risk 21:43
21:43 wagle joined, bluescreen left
lucian allison: i was thinking of maybe allocating week 1/2 to trying both 6model and custom/winxed and then comparing 21:44
not sure if that's a waste a time or not
allison cotto_work: asking jnthn will say what features 6model plans to offer, but that's still only assessing potential, not an actual test
lucian: not a waste of time at all, in fact, I'd say that's an excellent use of time 21:45
lucian allison: right. ok, i'll work it into the timeline
allison lucian: this proposal is shaping up nicely 21:51
lucian cotto_work: it might be useful to explain how python's object system works to someone with good knowledge of 6model
Tene tadzik: I'd love to chat about HLL interop. Let me know when you're available over the next day or two, and I'll try to find some time.
lucian allison: thanks. feel free to comment either on gh or here
allison lucian: one thing you might do is spread the tasks from the first 7 weeks over weeks 8-12
lucian Tene: likely not tommorow, certainly thursday
allison lucian: and then put the "bonus" tasks in separate section "if time permits" 21:52
Tene tadzik: I'm on the tail end of moving to a new apartment, so I'm pretty busy today, but should be able to schedule some time.
lucian allison: right
allison lucian: right now weeks 1-7 look quite ambitious, so you might as well spread them into a "sustainable pace"
Tene lucian: are you saying that you also want to talk about HLL interop, or are you saying that you know tadzik's schedule?
cotto_work lucian: that's what I was thinking. Explain to jnthn how Python's object system works (if he doesn't know) and ask him how well 6model would handle it. 21:53
21:53 wagle left
lucian Tene: i'm saying i don't have time tomorrow, but i should have time from thursday on 21:53
Tene lucian == tadzik?
21:53 wagle joined
lucian rather likes xchat 21:53
Tene: no
Tene: oh, silly me
cotto_work It strikes me as the kind of think that'd take someone with deep 6model knowledge several orders of magnitude less time to answer than someone without.
lucian Tene: i'm stupid
cotto_work *thing 21:54
lucian Tene: i'd talked to you about interop some time ago, hence my confusion. sorry
Tene lucian: I'm also glad to talk to you about HLL interop, if you've been thinking about or would like to work on that. :) 21:55
lucian: tadzik was asking about working on HLL interop for gsoc a little while ago, is what I was responding to.
lucian: 6model can handle python's object system very well. I'd need to know more of your specific criteria or concerns to speak to its maturity for your use right now. 21:57
jnthn would be *better* to talk to about that, but I can probably answer many of your questions if you can't get time with him for some reason.
lucian Tene: my concern from what i've read is that 6model assumes there are methods, and python only has attributes that can be callable 21:58
jnthn_: ping 21:59
Tene lucian: personally, I'd expect a python object model to expose method calls, to aid HLL interop. The object model would just look in the attribute store for a callable object and return that as the method to use. That's certainly not a requirement, though. If you don't want to support methods, then you just have those parts of the API throw exceptions. There's no problem there. 22:00
6model supports whatever method semantics you want, including "none". 22:01
lucian Tene: hmm. and what's 6model's plan for interop? 22:02
many useful languages don't even have something that looks like methods
22:03 wagle left
Tene lucian: If objects from that language don't have methods, then those objects just don't have methods. That's not a notably special case. 22:04
lucian: however those languages can work with their own objects, you can do that.
lucian Tene: right. and other languages that consume libraries in that language have to deal with it?
Tene lucian: ack, AFK, I'm 4 minutes late for a meeting.
lucian: We'll chat about this later. :) 22:05
lucian ok, bye
allison: Tene's words of wisdom sound encouraging
allison lucian: excellent! :) 22:06
lucian of course, he may be overly optimistic :)
i'd really much prefer to not have to implement inheritance myself, or later rewrite everything for 6model 22:07
NotFound Using current parrot objects you just need to override find_method... and fins some way to avoid method cache problems. 22:12
s/fins/find 22:13
22:13 bbatha joined
lucian NotFound: that if it were otherwise any good for python :) 22:13
22:17 cgaertner left
dalek nxed: r884 | NotFound++ | trunk/winxedst1.winxed:
clean a bit the literal string parsing functions
 22:18
cotto_work allison: thanks for your thoughts on the M0 spec. 22:20
22:21 davidfetter left
allison cotto_work: glad to help. Overall it's really solid. 22:21
cotto_work: good work going into that
cotto_work allison: thank you. 22:22
allison: what do you think about trying to steal some pointer-safety ideas from Cyclone? lucian brought up the idea and it sounds intriguing. 22:23
allison cotto_work: well worth looking into 22:24
22:24 wagle joined
allison cotto_work: Parrot needs to offer unique value to be appealing, and the two biggest potential selling points are speed and security 22:25
22:25 plobsing left
lucian i've told cotto_work++ this before, i find M0 overly simple 22:25
cotto_work Having m0 bytecode be essentially immune to certain kinds of errors/attacks sounds really attractive.
lucian cotto_work: PyPy has a sandbox with interesting properties, also segfault immune 22:28
cotto_work My favorite point of Parrot is the potential for HLL interop, but that's not a feature that will get Parrot running in production environments.
I'm looking forward to getting into this.
22:28 wagle left
lucian i'm interested in interop almost to the point of not caring much about parrot performance 22:29
22:29 wagle joined
benabik It needs at least moderate performance for the interop to be useful. 22:31
22:31 hercynium left
lucian if it matches CPython, i'll be satisfied 22:31
22:32 bubaflub left
lucian goes to bed 22:34
22:35 lucian left 22:36 plobsing joined 22:44 donaldh left 22:49 mtk left
bacek_at_work ~~ 22:53
Tene lucian: My most common planning failure is excess optimism. I would not be surprised to discover that I'm overly optimistic.
22:53 mtk joined
Tene bacek_at_work: did you see the llvm comments here? qinsb.blogspot.com/2011/03/unladen-...ctive.html 22:54
bacek_at_work Tene, yes. It was quite interesting.
benabik Tene: A bit late, lucian was heading to bed. 22:55
Tene benabik: I know. I've seen many people who are only intermittently connected use the irc logs to search for mentions of their nick while they were gone. 22:56
benabik Tene: Ah. Not a horrible idea, that.
Tene benabik: a better idea, IMO, is to just always be connected and have your IRC client log mentions of your nick. That's what I do, at least. That's not for everybody, though. 22:57
bacek_at_work: Haha, I see several people have been sending you links to that for a while. :) 23:00
dalek nxed: r885 | NotFound++ | trunk/winxedst1.winxed:
use heredoc for multiline predef bodies and change a bit body expansions
bacek_at_work Tene, at least 4 oh them :)
23:03 plobsing left 23:10 particle left
dalek rrot/opsc_llvm: d1b4ccd | bacek++ | config/auto/llvm.pm:
Use llvm_config from Configure.pl parameters instead of hardcoded "llvm-config"
 23:32
23:33 dmalcolm left
cotto_work goes home 23:35
23:35 kid51 joined 23:36 Andy_ left
kid51 ~~ 23:38
23:40 davidfetter joined 23:41 dmalcolm joined, dmalcolm left 23:50 kid51 is now known as kid51_at_dinner 23:55 bbatha left 23:56 whiteknight joined 23:58 particle joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!