Camelia, the Perl 6 bug

IRC log for #parrot, 2011-06-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 kid51 is now known as kid51_at_dinner
00:09 theory joined #parrot
00:39 mikehh_ joined #parrot
00:41 mikehh left #parrot
00:56 cotto ~~
00:58 kid51_at_dinner is now known as kid51
00:58 dalek parrot/tt2118/check_depend: 3569fe3 | jkeenan++ | t/src/checkdepend.t:
00:58 dalek parrot/tt2118/check_depend: Group subroutine declarations together.  Delete commented-out code.  Small typographic reformatting.
00:58 dalek parrot/tt2118/check_depend: review: https://github.com/parrot/parrot/commit/3569fe3a23
01:00 theory left #parrot
01:07 dmalcolm left #parrot
01:12 soh_cah_toa cotto: ping
01:17 cotto soh_cah_toa, poing
01:17 soh_cah_toa cotto: have you ever seen the "expected specifier-qualifier-list" error from gcc before? actually, it's "expected specifier-qualifier-list before 'hbdb_t'" to be exact
01:17 cotto soh_cah_toa, didn't that already get fixed?
01:17 soh_cah_toa cotto: i thought so too
01:19 cotto that should probably be a pointer to hbdb_t rather than stuffing a whole hbdb_t into the interp
01:19 bacek_at_work ~~
01:20 soh_cah_toa cotto: ah, yes. i'll try that. though it's weird that's it's showing up now since it's always been a non-pointer
01:21 cotto soh_cah_toa, did you try bisecting where the error first appeared?
01:21 cotto hi bacek_at_work
01:21 bacek_at_work aloha, cotto
01:22 cotto soh_cah_toa, that won't fix the error but is still a good idea
01:22 soh_cah_toa cotto: no, i'm not too familiar w/ git-bisect. i'm pretty sure it appeared after i defined some new types in src/hbdb.c
01:27 woosley joined #parrot
01:31 cotto I feel like I'm missing something obvious.
01:34 soh_cah_toa cotto: i know. i'm gonna try bisecting. it doesn't seem too hard. though how do i revert to a previous commit so i can see whether it's good? git-reset?
01:35 cotto soh_cah_toa, I think it has to do with the headers you're including in hbdb.h .  Note that debugger.h doesn't include anything.
01:36 soh_cah_toa cotto: don't i need parrot/parrot.h for opcode_t and stdio.h for FILE?
01:36 cotto I think the key is to not include any #defines in hbdb.h and ensure that when you include it in a C file, that you include parrot/parrot.h first.
01:37 cotto doing that gets the build working for me
01:40 cotto the problem is that hbdb.c was including hbdb.h but not parrot.h, so some of the types that hdbd.h weren't getting defined
01:41 soh_cah_toa i think i tried #including parrot/parrot.h before. i'll double check
01:43 soh_cah_toa here's what i got. frontend/hbdb/main.c #includes hbdb.h before parrot.h. src/hbdb.c as well and i removed all the other #includes. parrot/hbdb.h #includes nothing. i'm still seeing failure
01:44 soh_cah_toa except now gcc complains about opcode_t
01:46 cotto parrot.h should be first
01:48 soh_cah_toa still complaining
01:48 soh_cah_toa oh wait...
01:48 soh_cah_toa going...going...
01:49 * soh_cah_toa sighs in relief
01:50 cotto winner!
01:51 soh_cah_toa ok, good. but since hbdb.h uses FILE's and opcode_t's, should i at least test that those two are defined before including them rather than relying on that i include parrot.h before hbdb.h everywhere?
01:52 soh_cah_toa s/defined/included/
01:52 cotto you control where hbdb.h is included
01:52 soh_cah_toa alright
01:52 cotto no need to be overly defensive about checking what's defined for something internal like that
01:54 soh_cah_toa these chains of #include's can get quite lengthy
01:58 cotto I tend to fiddle and forget.
01:58 soh_cah_toa and another thing...is it possible to stop all the pmc2c's and c2str's from being run everytime i compile after making any changes to src/hbdb.c? i thought maybe ccache would help but i'm having other problems w/ linking to gcc
02:00 cotto soh_cah_toa, if you're having problem, pmc2c and c2str probably aren't causing them. Can you nopaste what you're seeing?
02:00 dalek parrot/tt2118/check_depend: 48355d8 | jkeenan++ | t/src/checkdepend.t:
02:00 dalek parrot/tt2118/check_depend: Add kludgey way of excluding file src/nci/extra_thunks from consideration by checkdepend.t.
02:00 dalek parrot/tt2118/check_depend: review: https://github.com/parrot/parrot/commit/48355d8eec
02:01 soh_cah_toa cotto: it's not really an error or anything. it's just that they're run when i don't want them to
02:02 cotto it's necessary to run c2str.  I'm not seeing any pmcs being rebuilt.
02:03 cotto you can run make corevm to avoid much of the build
02:06 soh_cah_toa it was when i ran 'make hbdb'. though i can't seem it replicate it now. oh well, i'll figure out how to some other time
02:07 cotto ok
02:09 soh_cah_toa about ccache though. i can't seem to find anything on the web about this. when i run 'sudo ln -s ccache /usr/bin/gcc' from within /usr/bin it complains that /usr/bin/gcc already exists which makes sense. did you get anything like this before?
02:10 cotto the arguments for ln can be confusing.  Think of it like cp.
02:10 cotto source first, destination second
02:10 cotto you want to do something like ln -s /usr/bin/ccache /usr/local/bin/gcc
02:12 soh_cah_toa i know ln is a pain. that's weird b/c that's backwards from what the ccache manual said
02:12 soh_cah_toa let me try though
02:13 cotto orly?
02:14 cotto the ccache manual says the same thing
02:14 soh_cah_toa oh wait. no it's not. you just add the full path for ccache. whoops
02:14 cotto http://ccache.samba.org/manual.html
02:14 soh_cah_toa yeah
02:14 cotto there you go
02:14 soh_cah_toa oh i see
02:14 soh_cah_toa i want the link in another directory in my $PATH. it's NOT the same one that gcc's in and it has to be before /usr/bin
02:15 soh_cah_toa that makes sense
02:15 cotto /usr/local/bin should come before /usr/bin
02:16 soh_cah_toa yeah, i get it know. it works
02:16 kid51 left #parrot
02:21 soh_cah_toa i noticed that parrot_debugger calls 'readline_interactive' using pcc to get its command input. this seems kinda...out of the way...when a simple fgets() would suffice. is there any advantage to using it over fgets()?
02:22 cotto readline takes care of some nice things like history and potentially tab completion
02:22 soh_cah_toa ohhh....
02:22 cotto I'm not sure why pcc needs to be involved, but I also doubt it slows down the responsiveness of the debugger meaningfully.
02:23 cotto you can achieve a similar effect for free by using rlwrap
02:23 soh_cah_toa yeah
02:24 soh_cah_toa isn't that how you use "pir-things" from c code? pcc? specifically, Parrot_pcc_invoke_from_c_args()
02:24 cotto yes
02:25 cotto that's how you invoke a method defined in pir from c
02:26 soh_cah_toa alright, so there's an easier way rather than using a filehandle pmc w/ pcc?
02:28 cotto you could call the readline function directly.  I can't say offhand why the current debugger does it that way, but code reuse may have something to do with it.
02:28 soh_cah_toa directly? how?
02:29 cotto same way you call any other C function
02:29 soh_cah_toa is there some Parrot_io_readline_interactive() function i don't know about?
02:31 cotto I though we were use libreadline for some reason.
02:31 cotto I guess not.
02:32 cotto actually, it's there
02:35 cotto ah.  It's only used by the filehandle pmc
02:35 soh_cah_toa that's what i thought
02:37 soh_cah_toa so readline_interactive() uses gnu readline? that's how it's able to have history and stuff?
02:37 cotto looks like it
02:39 soh_cah_toa so then i could use libreadline if i wanted to. i remember someone telling me not to in the beginning b/c of dependency issues but looking through NEWS it looks like libreadline is supported anyway
02:39 soh_cah_toa though right now i just need basic io first
02:40 cotto soh_cah_toa, actually filehandle is pretty defensive about making readline an optional dependency
02:40 cotto It may be there but it's not guaranteed
02:43 soh_cah_toa well, if readline_interactive() has history at least, that's good enough for me. anything else is just bells and whistles that i don't necessarily need right away
02:59 Khisanth left #parrot
03:02 tcurtis soh_cah_toa: I believe it has history if readline is available at configure-time (and not explicitly disabled by the (I think) --without-readline option to configure).
03:03 soh_cah_toa tcurtis: i see. so gnu readline is a dependency but if it's not installed the build doesn't fail. you just don't get the nice things it provides for readline_interactive()
03:05 soh_cah_toa cotto: btw, did you notice that "assignment discards qualifiers from pointer target type" warning when compiling? it's referring to the line: file = argv[argc - 1];. i thought it was ok to have expressions within brackets since c89? or maybe it's c99, now i'm not sure
03:08 cotto soh_cah_toa, it's probably complaining about differing constness
03:15 soh_cah_toa cotto: you're right. if i change "file" to a const char * then declare and define it at the same time, it shuts up
03:16 cotto there you go
03:17 cotto somewhere, andy is happy
03:17 soh_cah_toa andy...? lester?
03:18 cotto soh_cah_toa, yeah
03:18 cotto he does a lot of consting
03:18 soh_cah_toa ah yes. const-correctness is always good practice
03:19 soh_cah_toa yuck...except i hate assignments (except NULL's) at the top of a block though. i'll figure something out later
03:23 tcurtis soh_cah_toa: you shouldn't have to assign it when you declare it.
03:23 tcurtis const char * isn't a const pointer.
03:23 soh_cah_toa tcurtis: argv is const
03:23 soh_cah_toa tcurtis: i had to to correct some compiler error
03:24 mtk left #parrot
03:24 tcurtis soh_cah_toa: are the pointers const or are the pointed-to things const?
03:24 tcurtis I believe it is the latter.
03:24 soh_cah_toa "const char *argv[]" and "char *file"
03:25 tcurtis Change file to "const char *file" and assign to it whenever you want.
03:25 soh_cah_toa i need to assign it there though, right?
03:25 tcurtis The pointer itself isn't const.
03:26 soh_cah_toa hmm, you're right
03:26 soh_cah_toa why did i think that?
03:26 tcurtis Because it's slightly confusing.
03:26 soh_cah_toa too much java programming w/ final
03:27 tcurtis I think char const * is also pointer to const char rather than const pointer to char, which is even more confusing.
03:27 soh_cah_toa yes
03:27 soh_cah_toa const pointer to char = char * const foo;
03:29 tcurtis Oh well. I suppose that's far from the worst thing about C type syntax.
03:32 mtk joined #parrot
03:45 soh_cah_toa true. i've grown to like c's little quirks somehow. in a weird way... ;)
03:45 cotto Stockholm syndrome
03:47 soh_cah_toa hey, c does not have me hostage ;)
03:47 cotto That's the Stockholm syndrome at work.
03:49 * tcurtis has also experienced this feeling regarding C.
03:49 soh_cah_toa ha! actually, maybe it does have me hostage a little bit.
03:50 * tcurtis also regularly makes plans to make a low-level language with S-expression syntax in order to not have to write C, but usually gets stuck on formatting type declarations.
03:50 sorear C is a nice little language.  it could be improved, but "the good is the enemy of the best"
03:50 sorear tcurtis: that problem has already been solved
03:51 sorear tcurtis: google "BitC"
03:51 soh_cah_toa no, ddg "BitC"
03:51 soh_cah_toa i've fallen in love w/ ddg
03:53 cotto ddg is pretty great
03:55 tcurtis sorear: ah, yes, I've been meaning to try BitC.
03:58 cotto allison, ping
04:01 bubaflub left #parrot
04:06 Tene BitC seems to be a lot more than just that
04:07 Tene sorear, tcurtis: also, "Please Note: BitC has just made a transition from a LISP-like (s-expression) syntax to a more conventional syntax. The specification and the web site haven't caught up yet, and of course some of the published papers predate the change. "
04:08 sorear oh well.
04:08 sorear when I first looked at it 2003-2005ish, it seemed to be mostly s-expression C
04:08 cotto never a dull moment
04:11 LordBrain joined #parrot
04:11 mikehh_ is now known as mikehh
04:12 tcurtis Tene: true, but it also appears at a glance to be a low-level language with a powerful type system that isn't a theorem prover, which is also something I've been looking for.
04:13 sorear TALs are fun
04:13 tcurtis well, actually, it does look like it has some support for verification, but it's at least less intimidating than ATS.
04:13 Tene tcurtis: Sure, it's interesting, just a different sort
04:14 mikehh opbots, names
04:25 LordBrain does parrot support lazy data structures directly? or do the lazy languages which compile to parrot have to do that work on their own? I have a feeling that if laziness has to go thru more layers of translation it might have an artificial disadvantage.
04:26 LordBrain hmmm maybe i haven't thought this out enough.
04:30 soh_cah_toa left #parrot
04:46 silug left #parrot
04:55 allison cotto: pong
04:56 cotto allison, what kind of papers do you look for when researching calling conventions?  I'm trying to figure out where to start.
04:57 allison cotto: I tend to go for broadly relevant search terms, and then filter with human sense
04:58 Util LordBrain: Parrot directly supports Continuations, which are important to many sorts of lazyness, but does not (I think) provide any lazy DS. I suppose you could write a Dynamic PMC. If you named a particular lazy DS, we could reply more precisely.
04:59 dalek parrot: 36907a0 | petdance++ | t/steps/auto/ (2 files):
04:59 dalek parrot: removed unused File::Spec
04:59 dalek parrot: review: https://github.com/parrot/parrot/commit/36907a010c
04:59 dalek parrot: adcd580 | petdance++ | / (9 files):
04:59 dalek parrot: removed unnecessary "use File::Spec"
04:59 dalek parrot: review: https://github.com/parrot/parrot/commit/adcd580161
04:59 allison cotto: the tricky thing is that Parrot is fundamentally different that most existing approaches
04:59 allison s/that/than/
05:00 cotto and M0 is fundamentally different from Parrot's previous approach
05:00 allison aye
05:00 allison but, general techniques still apply
05:01 cotto sure.  It's not moon magic.
05:01 allison and, things like PIC and JIT will be relevant
05:04 cotto What about VM calling conventions?
05:05 allison I mean PIC and JIT will be relevant to the calling conventions
05:05 cotto ok
05:05 klavs joined #parrot
05:06 allison that is, our choice of calling conventions affects how easy (or even possible) it is to use optimization techniques like PIC/JIT
05:06 allison or to efficiently do multiple dispatch
05:07 allison do you remember the guy we met last year when we had a parrot meeting with jim keenan? working in efficient multiple-dispatch?
05:07 allison I'm trying to remember the name of his project
05:07 cotto was he the one who recommended the prototypes with multiple dispatch paper?
05:08 allison I think so, yes
05:09 allison papers I can hand you later
05:09 allison but, on general history
05:09 allison Parrot has been through several phases in calling conventions
05:09 cotto Getting something working is my current priority now, but getting something that *can* be efficient is next on the list.
05:10 allison from "just stuff it in a register"
05:10 allison to stuff it in a limited range of registers
05:10 allison to stuff it in registers with overflow in a PMC
05:11 allison to what was meant to be an elegant solution where no copies were made and callee just pulled values from caller
05:11 allison (but actually turned out to be a horrible mess because there were several different ways that callers could pass arguments to callees)
05:12 cotto This is highly relevant.
05:12 cotto thanks
05:12 allison (and we ended up passing partially consumed varargs around through nasty waves of code)
05:13 allison and in reaction to that mess, we moved on to the current strategy, with a single standard "intermediate storage" location for arguments
05:14 allison so that caller only has to know how to store things in the standard form
05:14 klavs left #parrot
05:14 allison and callee only has to know how to retrieve things from the standard form
05:14 allison the problem being, that the standard form is GC-able
05:14 allison and so, puts more pressure on the already stressed GC
05:16 cotto and here we are
05:16 allison it could be possible to alleviate that by making the intermediate storage a special "short-lived" GC-able like we talked about for contexts
05:17 allison or, by actually making it the context
05:17 allison either, caller creates the context and directly stores the arguments in registers
05:17 allison or, context has some additional "argument" storage
05:18 allison having the caller take responsibility for setting up the context and arguments and things is problematic though, because it doesn't allow for variation
05:19 allison Like, if the caller always creates a context, what about an NCI call, where you don't actually want to do anything but pass arguments along to a C function?
05:19 cotto It'll be much easier to make the callee do the work once I understand the work that needs to be done.
05:20 allison In Parrot at the moment, it's a lot of work, but it doesn't have to be
05:21 allison (okay, less work that before the last refactor, but still too much)
05:22 allison cotto: what's the absolute smallest amount of work you can get away with and still have M0 pass arguments and execute the function?
05:23 cotto allison, with or without creating a new call frame?
05:23 cotto Actually, without doesn't make too much sense.
05:25 cotto With is what I'm finding out now.  So far it involves allocating, initializing and activating a call frame, then activating the parent call frame when control flow returns to the chunk.
05:25 cotto This assumes that the callee will know how to pick arguments out of the parent call frame.
05:27 mikehh left #parrot
05:27 allison the trickiest bit there was calling from C into Parrot
05:27 allison because the C args are passed differently, and don't exist in a parent context
05:28 allison (that was where the partially consumed varargs came from)
05:28 allison it's possible to get around it by creating a dummy parent context and stuffing the args there, though
05:29 cotto That sounds like a minimally unnatural solution.
05:29 allison hmmm... actually M0 may remove the two major pain points here
05:29 allison since, the intention is to have everything but the lowest level written in itself
05:30 cotto yes
05:30 cotto eventually
05:30 allison we don't have so much crossing back-and-forth across the C and Parrot level
05:30 cotto That's one of the big selling points.
05:31 allison so, the greatest pain of direct parent access is calling from or to C
05:32 allison (basically, the problems we encountered trying out this approach before may not apply)
05:32 allison and, the advantage of leaving the arguments parent-side, is that it requires absolutely no work
05:37 allison cotto: my brain is fried and got to be up at 6am for conference calls
05:37 mikehh joined #parrot
05:38 cotto allison, ok.  Thanks for the perspective.
05:38 cotto 'night
05:38 allison cotto: are you keeping a wiki page of the ideas?
05:38 allison cotto: like, what got you thinking about caller-side?
05:38 allison cotto: or, a blog of running thoughts?
05:39 cotto allison, I'm trying to write up a test in the m0-prototype branch.  no more formal thoughts though
05:40 allison cotto: that's a good approach
05:40 allison 'night
05:45 theory joined #parrot
05:50 benabik Huh.  nqp-rx doesn't like POST::Sub.new( multi => $multi )
05:54 benabik Ah, but :multi($multi) works.
06:00 cotto nqp lives up to its name
06:00 cotto or family name, as it were
06:02 benabik I hadn't realized NQP had the :name($val) syntax for some reason.
06:05 klavs joined #parrot
06:06 klavs left #parrot
06:22 dalek parrot/m0-prototype: ae9273a | cotto++ | / (4 files):
06:22 dalek parrot/m0-prototype: initial attempt at a calling conventions test
06:22 dalek parrot/m0-prototype:
06:22 dalek parrot/m0-prototype: It doesn't run correctly yet but it tries really hard.  It does
06:22 dalek parrot/m0-prototype: assemble, which is progress.
06:22 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/ae9273a02b
06:25 cotto msg klavs If you think you'll eventually want a commit bit, you should sign and send in a CLA ( http://www.parrot.org/sites/www.​parrot.org/files/parrot_cla.pdf ).  Your contributions will still be welcome if you don't, but it's a requisite for direct commit access on github.
06:25 aloha OK. I'll deliver the message.
06:26 dalek parrot/m0-spec: 62c85d9 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:26 dalek parrot/m0-spec: make a few changes to allow implementing CPS with call frames
06:26 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/62c85d9a5d
06:26 cotto sleep
06:41 silug joined #parrot
06:55 theory left #parrot
07:16 jtpalmer_ left #parrot
07:18 jtpalmer joined #parrot
07:25 jtpalmer left #parrot
07:25 mj41 joined #parrot
07:29 klavs joined #parrot
07:31 jtpalmer joined #parrot
07:47 klavs left #parrot
08:12 dod joined #parrot
08:13 klavs joined #parrot
09:12 klavs left #parrot
09:12 particle1 joined #parrot
09:16 particle left #parrot
09:40 fperrad joined #parrot
09:48 klavs joined #parrot
10:00 nopaste left #parrot
10:06 nopaste joined #parrot
10:13 woosley left #parrot
10:30 klavs left #parrot
10:35 JimmyZ joined #parrot
10:42 ambs joined #parrot
11:13 mtk left #parrot
11:14 klavs joined #parrot
11:20 mtk joined #parrot
11:22 woosley joined #parrot
11:28 klavs left #parrot
11:29 klavs joined #parrot
11:29 arnsholt left #parrot
11:29 arnsholt joined #parrot
11:37 woosley left #parrot
11:38 dod left #parrot
11:38 klavs left #parrot
11:41 klavs joined #parrot
11:43 dod joined #parrot
11:44 ambs left #parrot
11:45 ambs joined #parrot
11:49 dmalcolm joined #parrot
12:05 whiteknight joined #parrot
12:11 whiteknight good morning, #parrot
12:15 whiteknight ls
12:15 whiteknight fail
12:15 atrodo ENOTYOURTTY
12:20 whiteknight ETOOEARLYINTHEMORNING
12:21 whiteknight I use the same color scheme for my terminal and my IRC client, so my poor brain gets confused
12:31 LordBrain left #parrot
12:34 contingencyplan left #parrot
12:35 contingencyplan joined #parrot
12:41 smash joined #parrot
12:42 smash hello everyone
12:45 whiteknight good morning, smash
13:14 klavs left #parrot
13:16 bubaflub joined #parrot
13:17 particle1 is now known as particle
13:28 dmalcolm left #parrot
13:35 klavs joined #parrot
13:40 jsut left #parrot
13:48 hercynium joined #parrot
13:51 klavs left #parrot
13:51 klavs joined #parrot
14:15 redicaps joined #parrot
14:20 theory joined #parrot
14:24 dalek winxed: r1047 | NotFound++ | trunk/winxed (2 files):
14:24 dalek winxed: write to output instead of using an intermediate StringHandle in the non-
14:24 dalek winxed: installed driver.
14:24 dalek winxed: This way it uses a lot less memory and bootstrap can be done again in less
14:24 dalek winxed: powered systems.
14:24 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=1047
14:27 theory left #parrot
14:41 theory joined #parrot
14:42 jsut joined #parrot
14:45 benabik morning
14:47 whiteknight hello benabik
14:48 mtk left #parrot
14:53 mtk joined #parrot
14:56 whiteknight http://www.johndcook.com/stand_alone_code.html
15:04 theory left #parrot
15:11 cotto princess doamba needs my help
15:12 cotto If Super Mario Bros. has taught me anything, it's that helping princesses is always a good idea.
15:12 particle1 joined #parrot
15:16 whiteknight and that no matter how hard you try, she's always chillin' in another castle
15:16 particle left #parrot
15:16 dmalcolm joined #parrot
15:18 whiteknight why does Koopa have so many castles? And what happens to them all when the housing market goes down, and the mortgages are all underwater?
15:18 whiteknight If he's got enough money to build, stock, staff, and operate all those castles, what does he need a princess for?
15:19 whiteknight I think she only has one castle
15:19 NotFound whiteknight: public relations. Look at Monaco.
15:19 whiteknight :)
15:20 cotto You can never have enough castles.  When you're at zero you think one would be really great, but once you get it that other castle down the street starts to look really good.
15:20 cotto It's a vicious cycle.
15:26 cotto Cool news: the people behind The Architecture of Open Source Applications ( http://www.aosabook.org/en/index.html ) are producing a second volume with a chapter about Parrot.
15:27 cotto dayjob time
15:35 particle1 is now known as particle
15:45 whiteknight oh, so the sequel is about what not to do?
15:46 whiteknight :) no, we do have some good architectural ideas
15:47 benabik Design good, implementation bad?
15:48 benabik Or perhaps, "pretty architecture, but are you sure a single 2x4 can hold up the entire second floor"?  ;-)
15:50 whiteknight the overall design of parrot has always been good: modular architecture, pluggable components, subclassibility, leave the details to the HLL
15:50 whiteknight those are all good things
15:50 whiteknight we have good separation of subsystems, usually encapsulated through PMC wrappers or similar
15:51 benabik We just want to take certain subsystems out back and put them out of our misery.  IMCC--
15:52 benabik (Just hit a subtle bug in something I wrote and get to rely on imcc--'s line numbers again...0
15:55 benabik aloha, karma imcc
15:55 aloha benabik: imcc has karma of -17.
15:56 cotto_work I found a use for pasm.
15:56 cotto_work Its syntax highlighting works nicely for M0.
15:56 whiteknight yay! our cruft is being useful
15:56 whiteknight benabik: in many cases, the architecture theory is much better than the architecture practice
15:57 whiteknight IMCC was an error of convenience. It's current state was not the plan
15:57 whiteknight actually its current state, architecturally speaking, is not so bad. It's much better encapsulated than it ever used to be
15:57 NotFound If the architecture was worse, you can't know that the badness lies on imcc ;)
15:57 benabik NotFound: Toché
15:58 benabik NotFound: Er, touché, even
16:00 redicaps left #parrot
16:08 dod left #parrot
16:21 bubaflub left #parrot
16:25 mj41 left #parrot
16:26 dukeleto ~~
16:30 dukeleto incoming
16:30 cotto_work oh noes
16:30 cotto_work where's my umbrella
16:32 dalek parrot/m0-prototype: 060b494 | dukeleto++ | t/m0/m0_assembler.t:
16:32 dalek parrot/m0-prototype: Make a test diagnostic message more useful
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/060b494d68
16:32 dalek parrot/m0-prototype: 4eff688 | dukeleto++ | t/m0/m0_assembler.t:
16:32 dalek parrot/m0-prototype: Add coverage for command line argument to m0 assembler
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/4eff68812f
16:32 dalek parrot/m0-prototype: 19c59c3 | dukeleto++ | t/m0/ (2 files):
16:32 dalek parrot/m0-prototype: Add coverage for detecting invalid M0 symbolic register names
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/19c59c3791
16:32 dalek parrot/m0-prototype: 644daa0 | dukeleto++ | t/m0/ (2 files):
16:32 dalek parrot/m0-prototype: Add more coverage for detecting invalid registers
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/644daa0f13
16:32 dalek parrot/m0-prototype: e9e48dc | dukeleto++ | t/m0/ (2 files):
16:32 dalek parrot/m0-prototype: Add coverage for a goto with an invalid label
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/e9e48dcbbb
16:32 dalek parrot/m0-prototype: 89fa31c | dukeleto++ | t/m0/ (2 files):
16:32 dalek parrot/m0-prototype: Add test coverage for invalid opcode detection
16:32 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/89fa31c4db
16:32 dukeleto those commits were from 30,000 ft
16:37 whiteknight awesome
16:38 cotto_work dukeleto: there's some breakage because I'm trying to get a minimal calling conventions example working in t/m0/integration/m0_poke_caller.m0 .  My plan is to fix everything else once that test works.
16:40 particle1 joined #parrot
16:42 dodathome joined #parrot
16:42 bubaflub joined #parrot
16:42 cotto_work dukeleto: be careful with that file.  atm it seems to quickly eat all available memory.
16:43 particle left #parrot
16:47 JimmyZ left #parrot
16:47 cotto_work dukeleto: how would I make a warning like 'Use of reference "ARRAY(0x88c08f8)" as array index at src/m0/perl5/m0_interp.pl line 445.' fatal?
16:48 dukeleto cotto_work: hmm
16:48 lucian joined #parrot
16:49 dukeleto cotto_work: use warnings FATAL => qw( all );
16:49 dukeleto cotto_work: also, we may want to use http://search.cpan.org/~adamk/Test-No​Warnings-1.02/lib/Test/NoWarnings.pm
16:50 cotto_work dukeleto: thanks
16:50 cotto_work dukeleto++
16:50 lucian uh, 'morning
16:51 cotto_work If that happens in the M0 interp, it's probably a good indicator that something's wrong.
16:52 particle1 is now known as particle
16:54 whiteknight good morning, lucian
16:54 lucian whiteknight: it is 5:54 pm, so assign appropriate amounts of salt
16:56 whiteknight 5:54 am?
16:57 whiteknight seen rohit_nsit08
16:57 aloha rohit_nsit08 was last seen in #parrot 2 days 2 hours ago saying "Coke_: hello".
17:00 lucian whiteknight: pm
17:00 davidfetter joined #parrot
17:08 mj41 joined #parrot
17:12 whiteknight 5:54 is my least favorite of all the 5:5x minutes
17:12 dalek parrot: a8eb161 | dukeleto++ | t/ (2 files):
17:12 dalek parrot: Merge pull request #135 from ligne/nci-errors
17:12 dalek parrot:
17:12 dalek parrot: avoid NCI-related test failures.
17:12 dalek parrot: review: https://github.com/parrot/parrot/commit/a8eb161802
17:13 dukeleto msg kid51 why are you asking for patches attached to trac tickets when you have a merge button in front of you?
17:13 aloha OK. I'll deliver the message.
17:13 whiteknight probably for local testing
17:13 whiteknight merge button doesn't test locally
17:14 dalek parrot: e9b3e89 | jkeenan++ | lib/Parrot/SHA1.pm:
17:14 dalek parrot: [codingstd] Correct misformulation of copyright line; keep test happy.
17:14 dalek parrot: review: https://github.com/parrot/parrot/commit/e9b3e894c7
17:14 dalek parrot: e161100 | jkeenan++ | t/ (2 files):
17:14 dalek parrot: Merge branch 'master' of git@github.com:parrot/parrot
17:14 dalek parrot: review: https://github.com/parrot/parrot/commit/e16110098b
17:16 dukeleto whiteknight: that is a reasonable reason. I guess I am not reasonable.
17:17 lucian bah, parrot appears to have a mind of its own
17:17 whiteknight lucian: lolwat?
17:17 whiteknight s/a mind of its own/a bug somewhere/
17:18 lucian whiteknight: i think attribute caching is messing me up
17:18 whiteknight that's entirely likely
17:18 lucian it is deterministic at least, i guess
17:18 whiteknight those caches are nothing but trouble
17:18 lucian the cache itself appears to work correctly
17:18 lucian but my __getattribute__ doesn't appear to work correctly at all
17:18 whiteknight yes, but it would be nice to clear them or turn them off or something
17:19 lucian yes, for testing
17:19 whiteknight our magical future 6model-based object system will have the ability to avoid caches entirely if you want
17:19 lucian yes, of course. i'll see to that
17:20 whiteknight The more I think about 6model, the more I don't understand how we've lived so long without it
17:20 whiteknight or something like it
17:20 jnthn__ Avoiding caches is easy. You don't publish one.
17:20 jnthn__ ;)
17:20 lucian whiteknight: well, i don't quite understand why something similar isn't already in
17:21 whiteknight backwards compatibility. Deprecation policy.
17:21 lucian i'm not criticising, just surprised. implementing dynamic objects over static ones is established science
17:21 whiteknight The sheer number of broken features for which we have test coverage
17:21 whiteknight or the number of bugs on which our HLLs depend, knowingly or unknowingly
17:21 rohit_nsit08 joined #parrot
17:21 rohit_nsit08 hello #parrot
17:22 whiteknight hello rohit_nsit08
17:22 rohit_nsit08 whiteknight: hi
17:22 whiteknight rohit_nsit08: what time do you normal have meetings with coke? I'm being your mentor today
17:22 whiteknight at least for the meeting
17:23 rohit_nsit08 whiteknight: we prefer contacting by mails as the work hours are not very common between us
17:23 rohit_nsit08 gmail chat also sometimes
17:24 whiteknight rohit_nsit08: okay. Meeting now?
17:24 rohit_nsit08 didn't had many meetings though, I was getting into cafe's parser code and code generator , the lack of documentation is posing some minor problems
17:24 whiteknight anything I can help with?
17:25 rohit_nsit08 ya, I was having some design problem, how should I prepare the base for code generator , I mean the steps needed to ensure less problems later
17:26 rohit_nsit08 I went through winxed's code as it is quite familiar to javascript to some respect for this
17:26 rohit_nsit08 It helped
17:26 rohit_nsit08 in getting how to set up it on parrot vm
17:27 dukeleto rohit_nsit08: have you blogged recently?
17:27 rohit_nsit08 i'm currently trying to implement support for basic features this week  and try object and functions in next week
17:28 dalek TT #2129 created by ligne++: pbc_to_exe:  missing runtime dependency
17:28 dalek TT #2129: http://trac.parrot.org/parrot/ticket/2129
17:28 dalek TT #935 closed by dukeleto++: PASM and PBC exit codes not correctly detected by Parrot::Test
17:28 dalek TT #935: http://trac.parrot.org/parrot/ticket/935
17:28 rohit_nsit08 dukeleto: hi, ya I did it on my blog
17:29 dukeleto rohit_nsit08: can you send emails to parrot-dev when you post a gsoc blog post? That would help us keep track of it
17:29 rohit_nsit08 dukeleto: doing it on parrot now, my internet connection is facing some, problem so using friends system
17:29 dukeleto rohit_nsit08: also, are you on planet parrot? http://planet.parrotcode.org
17:29 dukeleto rohit_nsit08: ok
17:30 rohit_nsit08 dukeleto:ya , I'll pos on developer list regularly from now, It took some time to get back into the code after exam break :-)
17:33 rohit_nsit08 dukeleto: won't be a problem from now
17:37 rohit_nsit08 left #parrot
17:42 benabik Okay.  I'm missing something:  `my $islexical := $node.lexical(); if $islexical { ... }`  The `...` code never gets run.
17:44 whiteknight is the node thingy a lexical?
17:44 benabik It is sometimes.
17:44 benabik Original code was `.local int islexical ; islexical = node.'lexical'() ; unless islexical goto outer_done`
17:45 benabik But it's never running even for the lexical blocks.
17:45 whiteknight combine that down: "if $node.lexical { ... }"
17:45 whiteknight maybe somethign is getting messed up in the assignment
17:45 benabik the value gets used later.
17:45 benabik But good idea.
17:45 whiteknight ALL MY IDEAS ARE GOOD
17:46 whiteknight well, at least a few of them
17:46 atrodo whiteknight++
17:46 whiteknight NQP uses binding, not assignment for :=
17:46 whiteknight so if the variable that $lexical is bound to changes, $lexical changes
17:47 whiteknight if you suspect that's an issue, you could do something like "my $lexical := pir::clone__PP($node.lexical);"
17:47 benabik whiteknight: It's binding to the return value of a function, not another variable.
17:48 whiteknight benabik: and what is that function returning, a reference to an attribute on $node?
17:48 whiteknight all that it "returns" is a pointer to an object. $lexical becomes the same pointer
17:48 whiteknight so if the value of the attribute or whatever changes, $lexical might change too
17:49 benabik whiteknight: It's somewhat close to $node{'lexical'}.
17:49 benabik whiteknight: And I don't think it's changing out from under me.
17:49 whiteknight okay, so that's all that matters
17:50 whiteknight do a "pir::say($lexical)" in there to see what it really thinks it is
17:50 whiteknight if you see non-false things, you know there's a problem with $lexical or the condition
17:50 whiteknight if you see only falsey things, you have a problem in $node.lexical()
17:51 benabik 111111111001101111011...
17:51 whiteknight okay
17:51 whiteknight so then we have entered the twilight zone
17:51 benabik Excellent!  Confusion is spread.
17:52 benabik Okay, it is entering the block.  Crud.  The code in there just isn't working?  Time to dig more.
17:53 rohit_nsit08 joined #parrot
17:53 whiteknight okay, that's slightly less bad
17:53 whiteknight brb walk
17:55 benabik ...  It's initializing all the variables at the top of the block so `my $old := $*VAR; my $var := $new' puts an Undef in $old.  :-(
17:56 benabik That's the issue.
17:56 benabik Sorry  `my $old := $*VAR; my $*VAR := $new`
18:07 whiteknight weird
18:08 sorear yeah, that doesn't work.
18:09 whiteknight it probably tries to autovivify $*VAR by putting undef into it?
18:09 whiteknight I don't see why that wouldn't work otherwise
18:09 benabik whiteknight: Exactly.  And it does it at the beginning of the block instead of at the my decl
18:12 whiteknight wonderful
18:12 whiteknight i loves me some autovivification
18:18 dukeleto we should do something with Parrot+IPv6 for world ipv6 day
18:20 davidfetter .oO(PL/TCP)
18:21 whiteknight when is ipv6 day?
18:21 benabik Huh.  Awesome.  $*SUB not found.  Gaarg
18:29 lucian left #parrot
18:32 lucian joined #parrot
18:42 dalek website: rohit_nsit08++ | CorellaScript: Parsing JavaScript
18:42 dalek website: http://www.parrot.org/content/c​orellascript-parsing-javascript
18:45 rohit_nsit08 dalek: thanks, I have given the link to main post in this one.
18:47 whiteknight rohit_nsit08++
18:50 bubaflub rohit_nsit08++ - i was wondering how your project was going
18:56 rohit_nsit08 bubaflub: hi
18:57 bubaflub rohit_nsit08: done with all your exams?
18:59 rohit_nsit08 bubaflub: yup. hmm... was waiting for something better result , so couldn't post frequently
18:59 rohit_nsit08 had to revise earlier work as well
18:59 rohit_nsit08 I hate exams in between work :-)
18:59 bubaflub rohit_nsit08: i hear ya.  glad to see you blogging and coding.
19:00 rohit_nsit08 bubaflub: I was referring to dragon book for code generator but don't think that will be enough. any suggestion?
19:00 benabik sorear: If `my $old := $*VAR; my $*VAR := $new` doesn't work, do you know a way to get the old value of a contextual while declaring a new one?
19:00 lucian left #parrot
19:01 bubaflub rohit_nsit08: hmmmm... not totally sure.  i've read through the ANTLR book (http://pragprog.com/titles/tpantl​r/the-definitive-antlr-reference) though that is specific to ANTLR compiler generator
19:01 lucian joined #parrot
19:03 rohit_nsit08 bubaflub: thanks, I'll have look into it.
19:03 rohit_nsit08 bubaflub: so how is your project going ?
19:03 bubaflub rohit_nsit08: i'm sure others here will have some suggestions.  you could send an email to parrot-dev to ask.
19:03 bubaflub rohit_nsit08: good!  so far most of the code and the docs are generated.
19:03 rohit_nsit08 I'm writing a mail to _Coke regarding it
19:04 rohit_nsit08 bubaflub: awesome!
19:05 rohit_nsit08 bubaflub: using any tool for documentation?
19:05 bubaflub rohit_nsit08: yep, i'll need some more in depth documentation and a test suite, but it's looking good so far.
19:05 lucian bubaflub: cool
19:05 lucian i'm stalled
19:06 bubaflub rohit_nsit08: i'm using POD, which are just specially formatted comments.  i'll also have stand alone docs like README and INSTALL and what not.
19:06 bubaflub lucian: bummer.  stuck on Winxed stuff?
19:07 lucian bubaflub: i don't really know. i have some mysterious bugs, that may be parrot bugs
19:07 whiteknight lucian doesn't get stuck. He mercifully lets the code rest between beatings
19:08 rohit_nsit08 bubaflub: ya, I have option of using available documentation generators for javascript, seems good on tests.
19:08 bubaflub rohit_nsit08: i'd recommend using whatever is used in JavaScript - makes it easier for other JS devs to use it
19:09 lucian whiteknight: heh. torturing code is an interesting concept
19:09 benabik I'm just getting tortured by code.
19:09 rohit_nsit08 bubaflub: that's true :-)
19:09 SteveH joined #parrot
19:10 tcurtis ~~
19:15 SteveH left #parrot
19:15 whiteknight hello tcurtis
19:15 whiteknight how goes the project?
19:18 mj41 left #parrot
19:19 tcurtis whiteknight: Slow going these last couple of weeks due to finals, but the last of those is tomorrow.
19:19 whiteknight awesome. Finals are such a bummer
19:21 tadzik finals are paradise
19:21 tadzik 3 finals in one week? Phew. And 3 attempts on each one. Paradise
19:21 dukeleto ~~
19:21 whiteknight 3 attempts? wtf?
19:21 tadzik I have 2 exams tomorrow and 4 on friday, 3 of them are deadly
19:21 tadzik twice in June, last one in September :)
19:21 dukeleto msg allison i have time to talk about m0 stuff today
19:21 aloha OK. I'll deliver the message.
19:22 tcurtis whiteknight: Does Rosella have anything for providing a read-only view on an array?
19:23 cotto_work #ps in 67
19:23 allison dukeleto: you catch the backscroll from cotto and I last night?
19:24 allison dukeleto: a little on calling conventions
19:24 cotto_work dukeleto: +1.  good stuff
19:24 dalek website: benabik++ | GSoC 3: My God, It's Full of Goto
19:24 dalek website: http://www.parrot.org/content​/gsoc-3-my-god-its-full-goto
19:26 whiteknight tcurtis: not specifically. Easy enough to add
19:27 cotto_work whiteknight: you might be interested too. http://irclog.perlgeek.de/p​arrot/2011-06-07#i_3873547
19:27 whiteknight cotto_work: I'm always interested
19:28 cotto_work time for noms
19:29 atrodo allison, cotto> am I off base in thinking that having an explicit "this is another argument" opcode would be of benefit for jit?
19:30 allison hmmm... well for a JIT you want a prebaked list of parameters at compile time
19:31 allison translating from runtime opcodes to compile-time parameters can be tricky
19:31 allison (we did have "add an argument" opcodes in one incarnation of Parrot)
19:32 allison having a single opcode of a complete list of arguments with argument signature is easier to chew up and JIT
19:32 dukeleto allison: i will backlog
19:32 whiteknight I want to get back to the "add an argument" opcodes
19:33 allison whiteknight: they were expensive
19:33 whiteknight the single set_params opcode and its family are horrible
19:33 whiteknight allison: I suspect things will be a little different now with current PCC. With specialized ops, we aren't building GCable signature PMCs anymore
19:34 whiteknight fill_params calls vtable ops on the CallContext internally. that's no more expensive than a push or pop operation on the CallContext
19:34 whiteknight allison: http://whiteknight.github.com/201​1/05/12/pcc_refactor_timings.html
19:34 whiteknight (I have data to support the idea)
19:34 allison whiteknight: yah, but "add an op" isn't only expensive because of the storage, it's also expensive because you have to perform the same operation multiple times, instead of doing it once
19:34 allison with no opportunity for optimization
19:35 atrodo allison> i'm having trouble wrapping my head around m0 would work
19:35 allison atrodo: there are several options for M0, no final answer yet
19:36 whiteknight There are plenty of opportunities for optimization if we can reuse CallContexts in hotpaths
19:36 whiteknight or preconstruct parts of them and store the CallContext in the constants table, instead of an encoded signature array
19:36 atrodo allison> example?  I guess I've got the mental barrier of how a 3 arg opcode can list all the arguments and a signature
19:37 * dukeleto has backlogged
19:38 allison most simplistic is 1 arg as signature, 1 arg as an aggregate of args
19:38 allison but, that's assuming you need any opcode for signatures and args at all
19:38 allison M0 is very, very basic
19:39 allison the most fundamental level
19:39 allison so, really all you have is "invoke"
19:39 bluescreen joined #parrot
19:40 allison and all argument handling is done in regular standard opcodes for creating objects, setting/getting arguments, and calling methods
19:40 allison actually, you might not even have invoke
19:40 allison (as an opcode)
19:40 allison because that can be a method or vtable function
19:41 allison (there's not really much difference between method and vtable function at that level)
19:41 theory joined #parrot
19:41 theory left #parrot
19:41 theory joined #parrot
19:42 tcurtis allison: How do you call a method without invoke?
19:42 ambs_ joined #parrot
19:43 ambs left #parrot
19:43 allison tcurtis: it's turtles all the way down :)
19:43 ambs_ is now known as ambs
19:43 whiteknight tcurtis: same way the machine does: goto
19:43 atrodo I assume abuse of goto is involved
19:43 allison atrodo: it's not abuse at the machine code level, that's just how control flow is done
19:44 allison atrodo: our fancy subroutines, and if blocks and for loops are just abstractions over goto
19:44 NotFound Oh, I got it, "basic" ----> GOTO
19:45 allison atrodo: now, it's nice to protect the programmer from goto, but M0 isn't at the programmer level
19:45 allison atrodo: it's the implemention *behind* what the programmer sees
19:45 NotFound The next level will have GOSUB.
19:46 ambs_ joined #parrot
19:47 allison whiteknight: I like the pcc refactor work. I think we can make much deeper improvements in M0, when we aren't trying to fit in with current dispatch.
19:47 atrodo allison> true, although I had hoped that m0 would provide more magic than just goto
19:47 ambs left #parrot
19:47 ambs_ is now known as ambs
19:48 benabik atrodo: M0 = no magic  :-D
19:48 whiteknight allison: Sure. I'm certain the M0 mechanisms and optimizations will be different from PIR
19:48 allison whiteknight: that was one of my frustrations in the earlier calling conventions refactors, being hamstrung by existing code.
19:48 whiteknight at the PIR level, we can get rid of set_params and friends for a net performance win at the PIR level.
19:48 NotFound atrodo: assemblers can provide some magic, not but the machine code it assembles to.
19:48 allison atrodo: magic comes in at M1 and higher
19:48 atrodo i knew magic was the wrong word to use
19:48 NotFound s/not but/but not
19:49 allison atrodo: mmm... I think magic fits
19:49 allison atrodo: by whatever name, M0 doesn't do much, which is intentional
19:50 atrodo but to me, the concept of a function, arguments and invokable is a low level concept appropriate for m0
19:51 allison whiteknight: I'd be curious to see tests on the same refactors using NCI, etc
19:51 lucian magic is a common word for abstraction
19:51 allison whiteknight: a lot of the complexity in the current dispatch is precisely because we don't make all calls from PIR->PIR
19:52 whiteknight allison: Yes, that would be a good set of tests to run. I suspect at the very least the speed does not decrease. NCI still builds CallContexts
19:52 NotFound In most machines codes a function call is push something to stack + goto, calling conventions are... conventions.
19:52 allison whiteknight: and a lot of assumptions that work fine for PIR->PIR just don't work in Parrot
19:52 whiteknight yeah, but that's the beauty of CallContext: It doesn't matter what puts stuff into it, only that the stuff ends up in it
19:52 ambs left #parrot
19:52 whiteknight and if we can make it faster to put stuff into a CallContext, it's a win for all recipients
19:53 allison That's for C->PIR, but there's also PIR->C
19:53 allison and C->C
19:53 atrodo lucian> but using the word magic invoked a reaction about the word, not necessarily what i was trying to express
19:53 whiteknight allison: is same. PIR->C sstill builds a CallContext. The way the CallContext is decoded by NCI is a little different, but not by much
19:54 allison whiteknight: yah, we regularized a lot in the last refactor
19:54 lucian atrodo: sure, it's a controversial term. ruby people have this annoying tendency to overuse it
19:54 NotFound atrodo: you can call it midiclorians if you prefer.
19:54 whiteknight allison: right. It's time we start leveraging those wonderful refactors
19:54 whiteknight because we aren't utilizing them at all now for the optimization potential
19:56 allison whiteknight: I'm not sure asking embedders to directly unpack a CallContext is the right answer
19:56 allison whiteknight: it's a pretty unfriendly interface
19:56 whiteknight allison: No need. We still have the C API functions for it and the embedders can still use those functions as-is
19:57 whiteknight We don't need to refactor all parts, just change the way PIR puts things into a CallContext, and the way PIR takes things out of it
19:57 whiteknight the C side doesn't change one iota
19:57 whiteknight code generators like pmc2c can also do a lot to hide changing interfaces from most embedders
19:58 preflex left #parrot
19:58 NotFound Please don't reinvent XSub tools.
19:58 whiteknight and at the PIR level, the ".param" syntax will just unpack to a different sequence of PASM instructions, so that's transparent
19:58 whiteknight sugared method and function calls too
19:59 whiteknight one of the very few times when I am going to express happiness about PIR syntax sugar
20:00 preflex joined #parrot
20:01 allison whiteknight: I guess I probably can't really comment without looking at the code
20:01 allison whiteknight: will leave that to cotto (wish I had time)
20:01 benabik I really need a solution to `my $old := $*VAR ; my $*VAR := $new`.  Anyone have any ideas?
20:03 whiteknight benabik: use a different variable
20:03 whiteknight create $*VAR_temp. Set $*VAR := $*VAR_temp after everything else is initialized
20:03 whiteknight or save the old $*VAR into a safe place, munge it, then restore
20:04 benabik whiteknight: Save and restore is supposed to be exactly what contextuals are supposed to avoid, I thought.
20:04 whiteknight benabik: you're not in Perl6. You're in not-quite-perl6
20:04 whiteknight the nuances of contextuals have been left out of the "not-quite" part
20:05 benabik Sad that it works in PIR, but not NQP.
20:05 whiteknight as Yoda might say: Problem solve the damn you must
20:05 whiteknight Alternatively, submit a patch for NQP-rx to not do that thing you don't want
20:06 NotFound benabik: as someone said, adding another level of indirection solves all problems.
20:08 klavs left #parrot
20:08 theory_ joined #parrot
20:11 dalek parrot: 5e12529 | dukeleto++ | t/src/e (2 files):
20:11 dalek parrot: Merge branch 'leto/embed_grant'
20:11 dalek parrot: review: https://github.com/parrot/parrot/commit/5e12529607
20:13 theory left #parrot
20:13 theory_ is now known as theory
20:15 benabik Sad little PIR block.
20:19 soh_cah_toa joined #parrot
20:21 ambs joined #parrot
20:24 rohit_nsit08 left #parrot
20:25 soh_cah_toa cotto_work: ping (quick question)
20:27 cotto_work soh_cah_toa: ping (quick answer)
20:27 soh_cah_toa cotto_work: what do you think is a decent sized buffer for command input? i was thinking 128 bytes
20:28 cotto_work soh_cah_toa: that's fine.  It's easy to change later (or it should be).
20:28 whiteknight soh_cah_toa: why do you need an input buffer?
20:28 cotto_work If you make it 5M, you'll still only need one.
20:28 soh_cah_toa whiteknight: well how else am i gonna store what the user enters?
20:28 whiteknight soh_cah_toa: how are you reading it in? Are you using a FileHandle PMC?
20:29 whiteknight actually, nevermind. I have to pack up and go
20:29 whiteknight left #parrot
20:29 soh_cah_toa alright
20:30 cotto_work soh_cah_toa: are you planning on moving your branch to parrot's github repo?
20:30 cotto_work #ps in 0
20:30 soh_cah_toa cotto_work: sure, i just don't know how
20:30 cotto_work soh_cah_toa: try to catch dukeleto.  He'
20:30 bubaflub left #parrot
20:30 cotto_work ll be able to walk you through it.
20:30 bubaflub joined #parrot
20:30 soh_cah_toa ok
20:30 cotto_work or point you in a useful direction.
20:30 davidfetter left #parrot
20:32 dalek parrot: 7a29a33 | mikehh++ | MANIFEST.SKIP:
20:32 dalek parrot: re-generate MANIFEST.SKIP
20:32 dalek parrot: review: https://github.com/parrot/parrot/commit/7a29a33b9e
20:32 dalek parrot: 159838f | mikehh++ | src/gc/api.c:
20:32 dalek parrot: move =cut to get t/codingstd/c_function_docs.t to pass - docs still needed
20:32 dalek parrot: review: https://github.com/parrot/parrot/commit/159838f58c
20:35 alester joined #parrot
20:47 theory left #parrot
20:57 lichtkind joined #parrot
20:58 lichtkind how far is the mo/lorito rewrite?
21:02 dodathome left #parrot
21:05 dukeleto lichtkind: the m0 spec is still be tweaked
21:07 lichtkind dukeleto: so its in preparation but my geuss that lorito and mo is the same thing was right?
21:07 sorear lorito is a very fuzzy concept
21:07 sorear it's more of a "next generation Parrot" programme
21:07 lucian lichtkind: from what i understand, lorito is the whole project
21:07 cotto_work lichtkind: kind of.  Lorito is M0 plus an object model and whatever's needed to support it.
21:07 lucian and m0 is a part of it
21:08 lichtkind thank you guys
21:08 cotto_work lichtkind: np
21:08 lichtkind i maybe ask some more dull questions too want to write an perl 6 update article
21:08 sorear Lorito is M0, rewriting Parrot to use M0, the M0 object model, the M0-enabled JIT, PIRATE, maybe other things we haven't discovered yet
21:09 lichtkind ah so m0 is the new basis and lorita the project to let parrot stand on that new basis
21:09 cotto_work lichtkind: that's not a bad way of looking at it
21:10 sorear pretty much
21:10 sorear Lorito came first, though
21:10 cotto_work M0 is an actual virtual machine specification.
21:10 sorear Lorito was a project to re-imagine Parrot
21:10 cotto_work dukeleto and I are working on implementing a prototype.
21:14 lichtkind any other important parrot news (since last year) ? :)
21:17 sorear Parrot's joke GC has been overhauled, and is now generational by default, in addition to not segfaulting on long lists anymore
21:17 lucian sorear: and it seems to actually work :)
21:18 sorear jnthn__ is developing a replacement for our current Object and Class PMCs, one that will support more languages natively
21:18 sorear lucian: hey, the old one worked.  you could actually tell the difference between -g ms and -g inf.  Most of the time.
21:18 mikehh I think there might be missing writ barriers but otherwise ok
21:18 mikehh write
21:19 lucian sorear: what i mean is that i can't manage to confuse it into forgetting objects
21:19 sorear Many improvements have been made to loading stuff from packfiles
21:20 sorear IMCC is better encapsulated, like a cyst forming around a parasite
21:20 sorear Cardinal and Pynie have been resurrected, we could see real use of non-Perl code on Parrot by the end of GSoC
21:20 mikehh IMCC needs a new a new approach/to be replaced or something
21:21 sorear we're in a time of great promise right now.
21:21 cotto_work there are some interesting gsoc projects going on too
21:25 lichtkind what means generational GC im not so deep into that?
21:26 sorear much faster and more memory efficient
21:27 lucian lichtkind: http://www.google.com/url?url=http://en.wikipe​dia.org/wiki/Garbage_collection_(computer_scie​nce)%23Generational_GC_.28ephemeral_GC.29&​rct=j&q=wiki+generational+gc&usg=AFQjC​NH0ZLVyA4FF_mfSLmIPt6C0Xcd_TA&sa=X&ei=​l5fuTbibEdC7hAe4tc2hCQ&ved=0CCUQygQwAA
21:27 lucian bah, stupid google link
21:27 lichtkind thank you
21:27 lucian lichtkind: http://en.wikipedia.org/wiki/Garbage_colle​ction_(computer_science)#Generational_GC_.28ephemeral_GC.29
21:31 ambs left #parrot
21:33 lichtkind how much faster?
21:33 lichtkind im am very glad to hear the good new
21:34 lichtkind the nasty journalist question would be its because you feel the possibility of raudo to port to CRL or even JVM?
21:35 dukeleto lichtkind: what exactly is your nasty journalist question?
21:36 lichtkind it would be: is you recent progress driven by the  possibility of rakudo to port to CRL or even JVM?
21:37 cotto_work Parrot isn't yet to the point where we don't need to focus on improving performance.
21:38 dukeleto lichtkind: i would say that M0 is driven by the need for a JIT compiler, but we are very aware of Rakudo supporting multiple backends
21:38 lucian lichtkind: also, the design of M0 doesn't preclude it from potentially running on JVM/CLR itself
21:39 cotto_work M0 is a big part of our long-term goal of removing some longstanding bottlenecks.
21:40 lichtkind yes thats the way i read the parrot docs
21:40 sorear lichtkind: parrot doesn't really care that much what Rakudo does
21:40 lichtkind but you know that ugly journalists always after politics :)
21:40 mikehh sorear: not entirely true
21:41 lichtkind i would also think so
21:41 sorear and Rakudo, AFAIK, has never been talking about abandoning Parrot
21:41 lichtkind since rakudo is the primary purpose of parrot
21:41 cotto_work sorear: I don't agree.  I want Parrot to provide as good a platform as possible for Rakudo.
21:41 bluescreen left #parrot
21:42 lichtkind yes never about abandoning , just talked about to to be locked
21:42 jnthn__ lichtkind: The ugly journalists are probably still too busy with Weiner's weiner to worry about Parrot. :-) Anyway, work on making Rakudo run on additional (*not* replacement) backends isn't a possibility, it's work in progress.
21:42 sorear the CLR and JVM ports are, AFAIK, intended more to support exotic environments where hosting 10^5 lines of C89 is infeasable
21:42 sorear e.g. WP7
21:43 lichtkind i dont understand wp 7 ?
21:43 jnthn__ Perl has long been "run anywhere". These days, VMs are important "anywheres", so Rakudo wants to run on all of them. But one thing at a time. :)
21:43 lucian lichtkind: windows phone 7 i believe
21:43 lichtkind i alsways was a fanboy of the archtitectural possibilities but there was at  a time a feeling being stuck
21:43 lichtkind im glad that this is overcome
21:45 NotFound I was thinking WordPerfect.
21:47 lichtkind but you have no measurement how much faster the new GC is?
21:48 cotto_work lichtkind: how much faster it is depends very heavily on the workload
21:48 lucian lichtkind: benchmarks have shown an average of 30% i believe, but sometimes much, much better
21:51 lichtkind than you
21:51 lucian lichtkind: but don't take my word for it, there were some blog posts about it
21:52 cotto_work lichtkind: if you want a good workload, look at the core.pm step of the Rakudo build.
21:56 lucian_ joined #parrot
21:57 sorear lichtkind: before, building Rakudo filled up all 2.375 GB of real+swap memory I have installed and OOMed
21:57 sorear lichtkind: after generational_gc landed, I can now build it in 320MB, leaving enough free to have a responsive system
21:58 lucian_ of course, parrot itself gobbles up a lot of memory in general
22:00 lucian left #parrot
22:00 lucian_ is now known as lucian
22:01 lichtkind sorear: whst id OOMed?
22:01 lucian lichtkind: out of memory
22:01 lichtkind oom prevention program?
22:02 sorear program runs out of memory, program ends with an error
22:02 lichtkind ah, thanks
22:02 linge joined #parrot
22:08 benabik minor nqp-rx enhancement: https://gist.github.com/1013096
22:08 bubaflub benabik: does that fix the lexical problem you were having before?
22:08 benabik Declare variables where they were declared.  This fixes my `my $old := $*VAR; my $*VAR := $new`
22:08 benabik bubaflub: Yes
22:10 bubaflub benabik: fantastic.  you should ping jnthn__ or pmichaud to get the patch accepted
22:11 hercynium left #parrot
22:11 sorear benabik: -1.  that code isn't supposed to work.
22:11 benabik sorear: Why not?
22:11 lichtkind thank you again guys i will come back with more questions :)
22:12 benabik sorear: I don't see why NQP moves where I declare the variable.
22:12 fperrad left #parrot
22:13 sorear benabik: because in Perl 6, variables are always declared at ENTER time
22:14 benabik That is both surprising and irritating.
22:14 sorear this is related to what makes declaring subs after using them work
22:15 benabik Allowing `$x; my $x` seems like an error.
22:16 sorear jnthn__: ping
22:17 jnthn__ sorear: pong
22:17 * jnthn__ reads...
22:17 jnthn__ yes, the ENTER time bit is right
22:18 jnthn__ I suspect we should die at compile time about the $x usage before declaration.
22:19 sorear jnthn__: benabik's actual problem is say $*FOO; my $*FOO = 6
22:19 arnsholt Wouldn't that cause problems with dynamic vars?
22:19 jnthn__ Guess the first one would print undef or something
22:19 benabik It will "say" undef
22:19 arnsholt Since my $*foo establishes a new binding
22:19 sorear jnthn__: please explain to benabik why it has to.  my cogent-explanation-generator isn't working today.
22:20 jnthn__ If NQP supported it, my $*FOO := $*OUTER::FOO; would do what benabik wants.
22:20 jnthn__ cah
22:20 jnthn__ I meant
22:20 jnthn__ my $*FOO := $*CALLER::FOO;
22:21 jnthn__ Anyway, "Allowing `$x; my $x` seems like an error." - this is correct
22:21 jnthn__ But so should be allowing $*x; my $*x
22:21 benabik When there's an "outer" $*x, that seems to make perfect sense to me.
22:22 jnthn__ A ticket on https://github.com/perl6/nqp/ is wlecome
22:22 benabik Hence me trying to use it.
22:22 jnthn__ benabik: No, that's not allowed in Perl 6.
22:22 jnthn__ benabik: STD gives you a nice error if you try to use it for that.
22:22 jnthn__ NQP doesn't yet, I'm afraid.
22:22 benabik Bah.
22:22 benabik I vaugely understand the language decision, it's just hideously inconvenient for me right now.
22:23 jnthn__ Does Parrot have an op for "look for a caller lexical, but skip n frames@?
22:24 jnthn__ I know there's find_caller_lex__PS
22:24 benabik I think pir::find_dynamic_lex skips the current lexpad...
22:24 jnthn__ oh, it's find_dynamic_lex...
22:24 * jnthn__ checks
22:24 benabik There is also a find_caller_lex
22:25 jnthn__ Whatever $*FOO compiles to uses one that looks in the current frame too
22:25 benabik The description the docs appears to say otherwise, but eh.
22:26 benabik It does seem to search current lexpad, but the doc says "search through callar lexpads".
22:26 jnthn__ find_dynamic_lex may do it
22:27 benabik No, because $*FOO in nqp-rx does compile to it and that's not how nqp-rx works.
22:28 arnsholt benabik: A workaround should be to use two blocks where you have one
22:28 jnthn__ hmm
22:28 arnsholt { my $old = $*foo; { my $*foo = $new; } }
22:29 jnthn__ arnsholt: ah, yes
22:29 benabik arnsholt: I'd like that better if that inner block wasn't 100 lines, but yes
22:29 arnsholt It's not aesthetically optimal, but hopefully it'll do what you want with a minimum of fuss
22:29 jnthn__ I ever used that workaround before, come to think of it...
22:29 arnsholt benabik: Yeah, that's what I was afraid of
22:29 jnthn__ *even
22:29 NotFound I told you before, all can be solved by adding another level ;)
22:30 arnsholt But hopefully your fiddling with $*foo is located pretty close to the top, in which case a judiciously placed comment should go a long way
22:33 * benabik is wondering if the extra level of indentation is worse than three lines of PIR to create the variable where I need it.
22:34 arnsholt Heh. Good question =)
22:34 hudnix left #parrot
22:42 jnthn__ benabik: If you do that, please comment what NQP you really want. I can look at adding $*CALLER::FOO at some point. Again, please do ticket it.
22:44 benabik jnthn__: Sounds like $*CALLER::FOO is what I'd really like, but I guess I'll live with the block for now.  Poking at ticket now.
22:52 lichtkind left #parrot
22:54 jnthn__ benabik: thanks
22:54 jnthn__ sleep &
22:55 alester left #parrot
23:04 whiteknight joined #parrot
23:05 cotto_work ohai whiteknight
23:05 whiteknight lolhi cotto_work
23:08 whiteknight what's happenin?
23:13 dalek parrot/m0-prototype: 2e54781 | cotto++ | / (2 files):
23:13 dalek parrot/m0-prototype: make calling conventions test less wrong, but still wrong
23:13 dalek parrot/m0-prototype:
23:13 dalek parrot/m0-prototype: Also, hijack print_n to dump a register and exit.
23:13 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/2e54781dbb
23:29 theory joined #parrot
23:32 whiteknight tcurtis: ping
23:39 kid51 joined #parrot
23:44 tcurtis whiteknight: pong
23:44 tcurtis aloha, seen darbelo
23:44 aloha tcurtis: darbelo was last seen in #parrot 11 days 2 hours ago joining the channel.
23:45 whiteknight tcurtis: Rosella does have functionality to make a value immutable
23:45 whiteknight it doesn't currently support arrays, but it's trivial to ad
23:45 whiteknight add
23:49 whiteknight actually, I may do that now while I'm looking at the code

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

Parrot | source cross referenced