Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
00:02 kid51 is now known as kid51_at_dinner 00:09 theory joined 00:39 mikehh_ joined 00:41 mikehh left
cotto ~~ 00:56
00:58 kid51_at_dinner is now known as kid51
dalek rrot/tt2118/check_depend: 3569fe3 | jkeenan++ | t/src/checkdepend.t:
Group subroutine declarations together. Delete commented-out code. Small typographic reformatting.
 00:58
01:00 theory left 01:07 dmalcolm left
soh_cah_toa cotto: ping 01:12
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
cotto soh_cah_toa, didn't that already get fixed?
soh_cah_toa cotto: i thought so too
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 ~~
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:20
cotto soh_cah_toa, did you try bisecting where the error first appeared? 01:21
hi bacek_at_work
bacek_at_work aloha, cotto
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
cotto I feel like I'm missing something obvious. 01:31
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:34
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:35
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.
doing that gets the build working for me 01:37
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:40
soh_cah_toa i think i tried #including parrot/parrot.h before. i'll double check 01:41
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:43
except now gcc complains about opcode_t 01:44
cotto parrot.h should be first 01:46
soh_cah_toa still complaining 01:48
oh wait...
going...going...
soh_cah_toa sighs in relief 01:49
cotto winner! 01:50
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:51
s/defined/included/ 01:52
cotto you control where hbdb.h is included
soh_cah_toa alright
cotto no need to be overly defensive about checking what's defined for something internal like that
soh_cah_toa these chains of #include's can get quite lengthy 01:54
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
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 rrot/tt2118/check_depend: 48355d8 | jkeenan++ | t/src/checkdepend.t:
Add kludgey way of excluding file src/nci/extra_thunks from consideration by checkdepend.t.
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:01
cotto it's necessary to run c2str. I'm not seeing any pmcs being rebuilt. 02:02
you can run make corevm to avoid much of the build 02:03
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:06
cotto ok 02:07
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:09
cotto the arguments for ln can be confusing. Think of it like cp. 02:10
source first, destination second
you want to do something like ln -s /usr/bin/ccache /usr/local/bin/gcc
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
let me try though
cotto orly? 02:13
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
cotto ccache.samba.org/manual.html
soh_cah_toa yeah
cotto there you go
soh_cah_toa oh i see
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
that makes sense 02:15
cotto /usr/local/bin should come before /usr/bin
soh_cah_toa yeah, i get it know. it works 02:16
02:16 kid51 left
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:21
cotto readline takes care of some nice things like history and potentially tab completion 02:22
soh_cah_toa ohhh....
cotto I'm not sure why pcc needs to be involved, but I also doubt it slows down the responsiveness of the debugger meaningfully.
you can achieve a similar effect for free by using rlwrap 02:23
soh_cah_toa yeah
isn't that how you use "pir-things" from c code? pcc? specifically, Parrot_pcc_invoke_from_c_args() 02:24
cotto yes
that's how you invoke a method defined in pir from c 02:25
soh_cah_toa alright, so there's an easier way rather than using a filehandle pmc w/ pcc? 02:26
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?
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?
cotto I though we were use libreadline for some reason. 02:31
I guess not.
actually, it's there 02:32
ah. It's only used by the filehandle pmc 02:35
soh_cah_toa that's what i thought
so readline_interactive() uses gnu readline? that's how it's able to have history and stuff? 02:37
cotto looks like it
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
though right now i just need basic io first
cotto soh_cah_toa, actually filehandle is pretty defensive about making readline an optional dependency 02:40
It may be there but it's not guaranteed
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:43
02:59 Khisanth left
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:02
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:03
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:05
cotto soh_cah_toa, it's probably complaining about differing constness 03:08
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:15
cotto there you go 03:16
somewhere, andy is happy 03:17
soh_cah_toa andy...? lester?
cotto soh_cah_toa, yeah 03:18
he does a lot of consting
soh_cah_toa ah yes. const-correctness is always good practice
yuck...except i hate assignments (except NULL's) at the top of a block though. i'll figure something out later 03:19
tcurtis soh_cah_toa: you shouldn't have to assign it when you declare it. 03:23
const char * isn't a const pointer.
soh_cah_toa tcurtis: argv is const
tcurtis: i had to to correct some compiler error
03:24 mtk left
tcurtis soh_cah_toa: are the pointers const or are the pointed-to things const? 03:24
I believe it is the latter.
soh_cah_toa "const char *argv[]" and "char *file"
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?
tcurtis The pointer itself isn't const.
soh_cah_toa hmm, you're right 03:26
why did i think that?
tcurtis Because it's slightly confusing.
soh_cah_toa too much java programming w/ final
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
const pointer to char = char * const foo;
tcurtis Oh well. I suppose that's far from the worst thing about C type syntax. 03:29
03:32 mtk joined
soh_cah_toa true. i've grown to like c's little quirks somehow. in a weird way... ;) 03:45
cotto Stockholm syndrome
soh_cah_toa hey, c does not have me hostage ;) 03:47
cotto That's the Stockholm syndrome at work.
tcurtis has also experienced this feeling regarding C. 03:49
soh_cah_toa ha! actually, maybe it does have me hostage a little bit.
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"
tcurtis: that problem has already been solved
tcurtis: google "BitC" 03:51
soh_cah_toa no, ddg "BitC"
i've fallen in love w/ ddg
cotto ddg is pretty great 03:53
tcurtis sorear: ah, yes, I've been meaning to try BitC. 03:55
cotto allison, ping 03:58
04:01 bubaflub left
Tene BitC seems to be a lot more than just that 04:06
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:07
sorear oh well. 04:08
when I first looked at it 2003-2005ish, it seemed to be mostly s-expression C
cotto never a dull moment
04:11 LordBrain joined, mikehh_ is now known as mikehh
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:12
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.
Tene tcurtis: Sure, it's interesting, just a different sort
mikehh opbots, names 04:14
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:25
hmmm maybe i haven't thought this out enough. 04:26
04:30 soh_cah_toa left 04:46 silug left
allison cotto: pong 04:55
cotto allison, what kind of papers do you look for when researching calling conventions? I'm trying to figure out where to start. 04:56
allison cotto: I tend to go for broadly relevant search terms, and then filter with human sense 04:57
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:58
dalek rrot: 36907a0 | petdance++ | t/steps/auto/ (2 files):
removed unused File::Spec
 04:59
rrot: adcd580 | petdance++ | / (9 files):
removed unnecessary "use File::Spec"
allison cotto: the tricky thing is that Parrot is fundamentally different that most existing approaches
s/that/than/
cotto and M0 is fundamentally different from Parrot's previous approach 05:00
allison aye
but, general techniques still apply
cotto sure. It's not moon magic. 05:01
allison and, things like PIC and JIT will be relevant
cotto What about VM calling conventions? 05:04
allison I mean PIC and JIT will be relevant to the calling conventions 05:05
cotto ok
05:05 klavs joined
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
or to efficiently do multiple dispatch
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
I'm trying to remember the name of his project
cotto was he the one who recommended the prototypes with multiple dispatch paper?
allison I think so, yes 05:08
papers I can hand you later 05:09
but, on general history
Parrot has been through several phases in calling conventions
cotto Getting something working is my current priority now, but getting something that *can* be efficient is next on the list.
allison from "just stuff it in a register" 05:10
to stuff it in a limited range of registers
to stuff it in registers with overflow in a PMC
to what was meant to be an elegant solution where no copies were made and callee just pulled values from caller 05:11
(but actually turned out to be a horrible mess because there were several different ways that callers could pass arguments to callees)
cotto This is highly relevant. 05:12
thanks
allison (and we ended up passing partially consumed varargs around through nasty waves of code)
and in reaction to that mess, we moved on to the current strategy, with a single standard "intermediate storage" location for arguments 05:13
so that caller only has to know how to store things in the standard form 05:14
05:14 klavs left
allison and callee only has to know how to retrieve things from the standard form 05:14
the problem being, that the standard form is GC-able
and so, puts more pressure on the already stressed GC
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
or, by actually making it the context 05:17
either, caller creates the context and directly stores the arguments in registers
or, context has some additional "argument" storage
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:18
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.
allison In Parrot at the moment, it's a lot of work, but it doesn't have to be 05:20
(okay, less work that before the last refactor, but still too much) 05:21
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:22
cotto allison, with or without creating a new call frame? 05:23
Actually, without doesn't make too much sense.
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
This assumes that the callee will know how to pick arguments out of the parent call frame.
05:27 mikehh left
allison the trickiest bit there was calling from C into Parrot 05:27
because the C args are passed differently, and don't exist in a parent context
(that was where the partially consumed varargs came from) 05:28
it's possible to get around it by creating a dummy parent context and stuffing the args there, though
cotto That sounds like a minimally unnatural solution. 05:29
allison hmmm... actually M0 may remove the two major pain points here
since, the intention is to have everything but the lowest level written in itself
cotto yes 05:30
eventually
allison we don't have so much crossing back-and-forth across the C and Parrot level
cotto That's one of the big selling points.
allison so, the greatest pain of direct parent access is calling from or to C 05:31
(basically, the problems we encountered trying out this approach before may not apply) 05:32
and, the advantage of leaving the arguments parent-side, is that it requires absolutely no work
cotto: my brain is fried and got to be up at 6am for conference calls 05:37
05:37 mikehh joined
cotto allison, ok. Thanks for the perspective. 05:38
'night
allison cotto: are you keeping a wiki page of the ideas?
cotto: like, what got you thinking about caller-side?
cotto: or, a blog of running thoughts?
cotto allison, I'm trying to write up a test in the m0-prototype branch. no more formal thoughts though 05:39
allison cotto: that's a good approach 05:40
'night
05:45 theory joined
benabik Huh. nqp-rx doesn't like POST::Sub.new( multi => $multi ) 05:50
Ah, but :multi($multi) works. 05:54
cotto nqp lives up to its name 06:00
or family name, as it were
benabik I hadn't realized NQP had the :name($val) syntax for some reason. 06:02
06:05 klavs joined 06:06 klavs left
dalek rrot/m0-prototype: ae9273a | cotto++ | / (4 files):
initial attempt at a calling conventions test

It doesn't run correctly yet but it tries really hard. It does assemble, which is progress.		 06:22
cotto msg klavs If you think you'll eventually want a commit bit, you should sign and send in a CLA ( www.parrot.org/sites/www.parrot.org...ot_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.
dalek rrot/m0-spec: 62c85d9 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
make a few changes to allow implementing CPS with call frames
 06:26
cotto sleep
06:41 silug joined 06:55 theory left 07:16 jtpalmer_ left 07:18 jtpalmer joined 07:25 jtpalmer left, mj41 joined 07:29 klavs joined 07:31 jtpalmer joined 07:47 klavs left 08:12 dod joined 08:13 klavs joined 09:12 klavs left, particle1 joined 09:16 particle left 09:40 fperrad joined 09:48 klavs joined 10:00 nopaste left 10:06 nopaste joined 10:13 woosley left 10:30 klavs left 10:35 JimmyZ joined 10:42 ambs joined 11:13 mtk left 11:14 klavs joined 11:20 mtk joined 11:22 woosley joined 11:28 klavs left 11:29 klavs joined, arnsholt left, arnsholt joined 11:37 woosley left 11:38 dod left, klavs left 11:41 klavs joined 11:43 dod joined 11:44 ambs left 11:45 ambs joined 11:49 dmalcolm joined 12:05 whiteknight joined
whiteknight good morning, #parrot 12:11
ls 12:15
fail
atrodo ENOTYOURTTY
whiteknight ETOOEARLYINTHEMORNING 12:20
I use the same color scheme for my terminal and my IRC client, so my poor brain gets confused 12:21
12:31 LordBrain left 12:34 contingencyplan left 12:35 contingencyplan joined 12:41 smash joined
smash hello everyone 12:42
whiteknight good morning, smash 12:45
13:14 klavs left 13:16 bubaflub joined 13:17 particle1 is now known as particle 13:28 dmalcolm left 13:35 klavs joined 13:40 jsut left 13:48 hercynium joined 13:51 klavs left, klavs joined 14:15 redicaps joined 14:20 theory joined
dalek nxed: r1047 | NotFound++ | trunk/winxed (2 files):
write to output instead of using an intermediate StringHandle in the non-

This way it uses a lot less memory and bootstrap can be done again in less powered systems.		 14:24
14:27 theory left 14:41 theory joined 14:42 jsut joined
benabik morning 14:45
whiteknight hello benabik 14:47
14:48 mtk left 14:53 mtk joined
whiteknight www.johndcook.com/stand_alone_code.html 14:56
15:04 theory left
cotto princess doamba needs my help 15:11
If Super Mario Bros. has taught me anything, it's that helping princesses is always a good idea. 15:12
15:12 particle1 joined
whiteknight and that no matter how hard you try, she's always chillin' in another castle 15:16
15:16 particle left, dmalcolm joined
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
If he's got enough money to build, stock, staff, and operate all those castles, what does he need a princess for?
I think she only has one castle 15:19
NotFound whiteknight: public relations. Look at Monaco.
whiteknight :)
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
It's a vicious cycle.
Cool news: the people behind The Architecture of Open Source Applications ( www.aosabook.org/en/index.html ) are producing a second volume with a chapter about Parrot. 15:26
dayjob time 15:27
15:35 particle1 is now known as particle
whiteknight oh, so the sequel is about what not to do? 15:45
:) no, we do have some good architectural ideas 15:46
benabik Design good, implementation bad? 15:47
Or perhaps, "pretty architecture, but are you sure a single 2x4 can hold up the entire second floor"? ;-) 15:48
whiteknight the overall design of parrot has always been good: modular architecture, pluggable components, subclassibility, leave the details to the HLL 15:50
those are all good things
we have good separation of subsystems, usually encapsulated through PMC wrappers or similar
benabik We just want to take certain subsystems out back and put them out of our misery. IMCC-- 15:51
(Just hit a subtle bug in something I wrote and get to rely on imcc--'s line numbers again...0 15:52
aloha, karma imcc 15:55
aloha benabik: imcc has karma of -17.
cotto_work I found a use for pasm. 15:56
Its syntax highlighting works nicely for M0.
whiteknight yay! our cruft is being useful
benabik: in many cases, the architecture theory is much better than the architecture practice
IMCC was an error of convenience. It's current state was not the plan 15:57
actually its current state, architecturally speaking, is not so bad. It's much better encapsulated than it ever used to be
NotFound If the architecture was worse, you can't know that the badness lies on imcc ;)
benabik NotFound: Toché
NotFound: Er, touché, even 15:58
16:00 redicaps left 16:08 dod left 16:21 bubaflub left 16:25 mj41 left
dukeleto ~~ 16:26
incoming 16:30
cotto_work oh noes
where's my umbrella
dalek rrot/m0-prototype: 060b494 | dukeleto++ | t/m0/m0_assembler.t:
Make a test diagnostic message more useful
 16:32
rrot/m0-prototype: 4eff688 | dukeleto++ | t/m0/m0_assembler.t:
Add coverage for command line argument to m0 assembler
rrot/m0-prototype: 19c59c3 | dukeleto++ | t/m0/ (2 files):
Add coverage for detecting invalid M0 symbolic register names
rrot/m0-prototype: 644daa0 | dukeleto++ | t/m0/ (2 files):
Add more coverage for detecting invalid registers
rrot/m0-prototype: e9e48dc | dukeleto++ | t/m0/ (2 files):
Add coverage for a goto with an invalid label
rrot/m0-prototype: 89fa31c | dukeleto++ | t/m0/ (2 files):
Add test coverage for invalid opcode detection
dukeleto those commits were from 30,000 ft
whiteknight awesome 16:37
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:38
16:40 particle1 joined 16:42 dodathome joined, bubaflub joined
cotto_work dukeleto: be careful with that file. atm it seems to quickly eat all available memory. 16:42
16:43 particle left 16:47 JimmyZ left
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:47
dukeleto cotto_work: hmm 16:48
16:48 lucian joined
dukeleto cotto_work: use warnings FATAL => qw( all ); 16:49
cotto_work: also, we may want to use search.cpan.org/~adamk/Test-NoWarni...arnings.pm
cotto_work dukeleto: thanks 16:50
dukeleto++
lucian uh, 'morning
cotto_work If that happens in the M0 interp, it's probably a good indicator that something's wrong. 16:51
16:52 particle1 is now known as particle
whiteknight good morning, lucian 16:54
lucian whiteknight: it is 5:54 pm, so assign appropriate amounts of salt
whiteknight 5:54 am? 16:56
seen rohit_nsit08 16:57
aloha rohit_nsit08 was last seen in #parrot 2 days 2 hours ago saying "Coke_: hello".
lucian whiteknight: pm 17:00
17:00 davidfetter joined 17:08 mj41 joined
whiteknight 5:54 is my least favorite of all the 5:5x minutes 17:12
dalek rrot: a8eb161 | dukeleto++ | t/ (2 files):
Merge pull request #135 from ligne/nci-errors

avoid NCI-related test failures.
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.
whiteknight probably for local testing
merge button doesn't test locally
dalek rrot: e9b3e89 | jkeenan++ | lib/Parrot/SHA1.pm:
[codingstd] Correct misformulation of copyright line; keep test happy.
 17:14
rrot: e161100 | jkeenan++ | t/ (2 files):
Merge branch 'master' of git@github.com:parrot/parrot
dukeleto whiteknight: that is a reasonable reason. I guess I am not reasonable. 17:16
lucian bah, parrot appears to have a mind of its own 17:17
whiteknight lucian: lolwat?
s/a mind of its own/a bug somewhere/
lucian whiteknight: i think attribute caching is messing me up 17:18
whiteknight that's entirely likely
lucian it is deterministic at least, i guess
whiteknight those caches are nothing but trouble
lucian the cache itself appears to work correctly
but my __getattribute__ doesn't appear to work correctly at all
whiteknight yes, but it would be nice to clear them or turn them off or something
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
lucian yes, of course. i'll see to that
whiteknight The more I think about 6model, the more I don't understand how we've lived so long without it 17:20
or something like it
jnthn__ Avoiding caches is easy. You don't publish one.
;)
lucian whiteknight: well, i don't quite understand why something similar isn't already in
whiteknight backwards compatibility. Deprecation policy. 17:21
lucian i'm not criticising, just surprised. implementing dynamic objects over static ones is established science
whiteknight The sheer number of broken features for which we have test coverage
or the number of bugs on which our HLLs depend, knowingly or unknowingly
17:21 rohit_nsit08 joined
rohit_nsit08 hello #parrot 17:21
whiteknight hello rohit_nsit08 17:22
rohit_nsit08 whiteknight: hi
whiteknight rohit_nsit08: what time do you normal have meetings with coke? I'm being your mentor today
at least for the meeting
rohit_nsit08 whiteknight: we prefer contacting by mails as the work hours are not very common between us 17:23
gmail chat also sometimes
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
whiteknight anything I can help with?
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:25
I went through winxed's code as it is quite familiar to javascript to some respect for this 17:26
It helped
in getting how to set up it on parrot vm
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
dalek TT #2129 created by ligne++: pbc_to_exe: missing runtime dependency 17:28
TT #2129: trac.parrot.org/parrot/ticket/2129
TT #935 closed by dukeleto++: PASM and PBC exit codes not correctly detected by Parrot::Test
TT #935: trac.parrot.org/parrot/ticket/935
rohit_nsit08 dukeleto: hi, ya I did it on my blog
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
dukeleto rohit_nsit08: also, are you on planet parrot? planet.parrotcode.org
rohit_nsit08: ok
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:30
dukeleto: won't be a problem from now 17:33
17:37 rohit_nsit08 left
benabik Okay. I'm missing something: `my $islexical := $node.lexical(); if $islexical { ... }` The `...` code never gets run. 17:42
whiteknight is the node thingy a lexical? 17:44
benabik It is sometimes.
Original code was `.local int islexical ; islexical = node.'lexical'() ; unless islexical goto outer_done`
But it's never running even for the lexical blocks. 17:45
whiteknight combine that down: "if $node.lexical { ... }"
maybe somethign is getting messed up in the assignment
benabik the value gets used later.
But good idea.
whiteknight ALL MY IDEAS ARE GOOD
well, at least a few of them 17:46
atrodo whiteknight++
whiteknight NQP uses binding, not assignment for :=
so if the variable that $lexical is bound to changes, $lexical changes
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.
whiteknight benabik: and what is that function returning, a reference to an attribute on $node? 17:48
all that it "returns" is a pointer to an object. $lexical becomes the same pointer
so if the value of the attribute or whatever changes, $lexical might change too
benabik whiteknight: It's somewhat close to $node{'lexical'}. 17:49
whiteknight: And I don't think it's changing out from under me.
whiteknight okay, so that's all that matters
do a "pir::say($lexical)" in there to see what it really thinks it is 17:50
if you see non-false things, you know there's a problem with $lexical or the condition
if you see only falsey things, you have a problem in $node.lexical()
benabik 111111111001101111011... 17:51
whiteknight okay
so then we have entered the twilight zone
benabik Excellent! Confusion is spread.
Okay, it is entering the block. Crud. The code in there just isn't working? Time to dig more. 17:52
17:53 rohit_nsit08 joined
whiteknight okay, that's slightly less bad 17:53
brb walk
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:55
That's the issue. 17:56
Sorry `my $old := $*VAR; my $*VAR := $new`
whiteknight weird 18:07
sorear yeah, that doesn't work. 18:08
whiteknight it probably tries to autovivify $*VAR by putting undef into it? 18:09
I don't see why that wouldn't work otherwise
benabik whiteknight: Exactly. And it does it at the beginning of the block instead of at the my decl
whiteknight wonderful 18:12
i loves me some autovivification
dukeleto we should do something with Parrot+IPv6 for world ipv6 day 18:18
davidfetter
.oO(PL/TCP)
 18:20
whiteknight when is ipv6 day? 18:21
benabik Huh. Awesome. $*SUB not found. Gaarg
18:29 lucian left 18:32 lucian joined
dalek website: rohit_nsit08++ | CorellaScript: Parsing JavaScript 18:42
website: www.parrot.org/content/corellascrip...javascript
rohit_nsit08 dalek: thanks, I have given the link to main post in this one. 18:45
whiteknight rohit_nsit08++ 18:47
bubaflub rohit_nsit08++ - i was wondering how your project was going 18:50
rohit_nsit08 bubaflub: hi 18:56
bubaflub rohit_nsit08: done with all your exams? 18:57
rohit_nsit08 bubaflub: yup. hmm... was waiting for something better result , so couldn't post frequently 18:59
had to revise earlier work as well
I hate exams in between work :-)
bubaflub rohit_nsit08: i hear ya. glad to see you blogging and coding.
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
bubaflub rohit_nsit08: hmmmm... not totally sure. i've read through the ANTLR book (pragprog.com/titles/tpantlr/the-def...reference) though that is specific to ANTLR compiler generator 19:01
19:01 lucian joined
rohit_nsit08 bubaflub: thanks, I'll have look into it. 19:03
bubaflub: so how is your project going ?
bubaflub rohit_nsit08: i'm sure others here will have some suggestions. you could send an email to parrot-dev to ask.
rohit_nsit08: good! so far most of the code and the docs are generated.
rohit_nsit08 I'm writing a mail to _Coke regarding it
bubaflub: awesome! 19:04
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.
lucian bubaflub: cool
i'm stalled
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
lucian: bummer. stuck on Winxed stuff?
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
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
lucian whiteknight: heh. torturing code is an interesting concept 19:09
benabik I'm just getting tortured by code.
rohit_nsit08 bubaflub: that's true :-)
19:09 SteveH joined
tcurtis ~~ 19:10
19:15 SteveH left
whiteknight hello tcurtis 19:15
how goes the project?
19:18 mj41 left
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
tadzik finals are paradise 19:21
3 finals in one week? Phew. And 3 attempts on each one. Paradise
dukeleto ~~
whiteknight 3 attempts? wtf?
tadzik I have 2 exams tomorrow and 4 on friday, 3 of them are deadly
twice in June, last one in September :)
dukeleto msg allison i have time to talk about m0 stuff today
aloha OK. I'll deliver the message.
tcurtis whiteknight: Does Rosella have anything for providing a read-only view on an array? 19:22
cotto_work #ps in 67 19:23
allison dukeleto: you catch the backscroll from cotto and I last night?
dukeleto: a little on calling conventions 19:24
cotto_work dukeleto: +1. good stuff
dalek website: benabik++ | GSoC 3: My God, It's Full of Goto
website: www.parrot.org/content/gsoc-3-my-go...-full-goto
whiteknight tcurtis: not specifically. Easy enough to add 19:26
cotto_work whiteknight: you might be interested too. irclog.perlgeek.de/parrot/2011-06-07#i_3873547 19:27
whiteknight cotto_work: I'm always interested
cotto_work time for noms 19:28
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:29
allison hmmm... well for a JIT you want a prebaked list of parameters at compile time 19:30
translating from runtime opcodes to compile-time parameters can be tricky 19:31
(we did have "add an argument" opcodes in one incarnation of Parrot)
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
whiteknight I want to get back to the "add an argument" opcodes
allison whiteknight: they were expensive 19:33
whiteknight the single set_params opcode and its family are horrible
allison: I suspect things will be a little different now with current PCC. With specialized ops, we aren't building GCable signature PMCs anymore
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
allison: whiteknight.github.com/2011/05/12/p...mings.html
(I have data to support the idea)
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
with no opportunity for optimization
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
whiteknight There are plenty of opportunities for optimization if we can reuse CallContexts in hotpaths 19:36
or preconstruct parts of them and store the CallContext in the constants table, instead of an encoded signature array
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
dukeleto has backlogged 19:37
allison most simplistic is 1 arg as signature, 1 arg as an aggregate of args 19:38
but, that's assuming you need any opcode for signatures and args at all
M0 is very, very basic
the most fundamental level 19:39
so, really all you have is "invoke"
19:39 bluescreen joined
allison and all argument handling is done in regular standard opcodes for creating objects, setting/getting arguments, and calling methods 19:40
actually, you might not even have invoke
(as an opcode)
because that can be a method or vtable function
(there's not really much difference between method and vtable function at that level) 19:41
19:41 theory joined, theory left, theory joined
tcurtis allison: How do you call a method without invoke? 19:42
19:42 ambs_ joined 19:43 ambs left
allison tcurtis: it's turtles all the way down :) 19:43
19:43 ambs_ is now known as ambs
whiteknight tcurtis: same way the machine does: goto 19:43
atrodo I assume abuse of goto is involved
allison atrodo: it's not abuse at the machine code level, that's just how control flow is done
atrodo: our fancy subroutines, and if blocks and for loops are just abstractions over goto 19:44
NotFound Oh, I got it, "basic" ----> GOTO
allison atrodo: now, it's nice to protect the programmer from goto, but M0 isn't at the programmer level 19:45
atrodo: it's the implemention *behind* what the programmer sees
NotFound The next level will have GOSUB.
19:46 ambs_ joined
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, ambs_ is now known as ambs
benabik atrodo: M0 = no magic :-D 19:48
whiteknight allison: Sure. I'm certain the M0 mechanisms and optimizations will be different from PIR
allison whiteknight: that was one of my frustrations in the earlier calling conventions refactors, being hamstrung by existing code.
whiteknight at the PIR level, we can get rid of set_params and friends for a net performance win at the PIR level.
NotFound atrodo: assemblers can provide some magic, not but the machine code it assembles to.
allison atrodo: magic comes in at M1 and higher
atrodo i knew magic was the wrong word to use
NotFound s/not but/but not
allison atrodo: mmm... I think magic fits 19:49
atrodo: by whatever name, M0 doesn't do much, which is intentional
atrodo but to me, the concept of a function, arguments and invokable is a low level concept appropriate for m0 19:50
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
allison whiteknight: a lot of the complexity in the current dispatch is precisely because we don't make all calls from PIR->PIR
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.
allison whiteknight: and a lot of assumptions that work fine for PIR->PIR just don't work in Parrot
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
whiteknight and if we can make it faster to put stuff into a CallContext, it's a win for all recipients 19:52
allison That's for C->PIR, but there's also PIR->C 19:53
and C->C
atrodo lucian> but using the word magic invoked a reaction about the word, not necessarily what i was trying to express
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
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
NotFound atrodo: you can call it midiclorians if you prefer.
whiteknight allison: right. It's time we start leveraging those wonderful refactors
because we aren't utilizing them at all now for the optimization potential
allison whiteknight: I'm not sure asking embedders to directly unpack a CallContext is the right answer 19:56
whiteknight: it's a pretty unfriendly interface
whiteknight allison: No need. We still have the C API functions for it and the embedders can still use those functions as-is
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
the C side doesn't change one iota
code generators like pmc2c can also do a lot to hide changing interfaces from most embedders
19:58 preflex left
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
sugared method and function calls too
one of the very few times when I am going to express happiness about PIR syntax sugar 19:59
20:00 preflex joined
allison whiteknight: I guess I probably can't really comment without looking at the code 20:01
whiteknight: will leave that to cotto (wish I had time)
benabik I really need a solution to `my $old := $*VAR ; my $*VAR := $new`. Anyone have any ideas?
whiteknight benabik: use a different variable 20:03
create $*VAR_temp. Set $*VAR := $*VAR_temp after everything else is initialized
or save the old $*VAR into a safe place, munge it, then restore
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
the nuances of contextuals have been left out of the "not-quite" part
benabik Sad that it works in PIR, but not NQP. 20:05
whiteknight as Yoda might say: Problem solve the damn you must
Alternatively, submit a patch for NQP-rx to not do that thing you don't want
NotFound benabik: as someone said, adding another level of indirection solves all problems. 20:06
20:08 klavs left, theory_ joined
dalek rrot: 5e12529 | dukeleto++ | t/src/e (2 files):
Merge branch 'leto/embed_grant'
 20:11
20:13 theory left, theory_ is now known as theory
benabik Sad little PIR block. 20:15
20:19 soh_cah_toa joined 20:21 ambs joined 20:24 rohit_nsit08 left
soh_cah_toa cotto_work: ping (quick question) 20:25
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
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?
cotto_work If you make it 5M, you'll still only need one.
soh_cah_toa whiteknight: well how else am i gonna store what the user enters?
whiteknight soh_cah_toa: how are you reading it in? Are you using a FileHandle PMC?
actually, nevermind. I have to pack up and go 20:29
20:29 whiteknight left
soh_cah_toa alright 20:29
cotto_work soh_cah_toa: are you planning on moving your branch to parrot's github repo? 20:30
#ps in 0
soh_cah_toa cotto_work: sure, i just don't know how
cotto_work soh_cah_toa: try to catch dukeleto. He'
20:30 bubaflub left
cotto_work ll be able to walk you through it. 20:30
20:30 bubaflub joined
soh_cah_toa ok 20:30
cotto_work or point you in a useful direction.
20:30 davidfetter left
dalek rrot: 7a29a33 | mikehh++ | MANIFEST.SKIP:
re-generate MANIFEST.SKIP
 20:32
rrot: 159838f | mikehh++ | src/gc/api.c:
move =cut to get t/codingstd/c_function_docs.t to pass - docs still needed
20:35 alester joined 20:47 theory left 20:57 lichtkind joined
lichtkind how far is the mo/lorito rewrite? 20:58
21:02 dodathome left
dukeleto lichtkind: the m0 spec is still be tweaked 21:05
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
it's more of a "next generation Parrot" programme
lucian lichtkind: from what i understand, lorito is the whole project
cotto_work lichtkind: kind of. Lorito is M0 plus an object model and whatever's needed to support it.
lucian and m0 is a part of it
lichtkind thank you guys 21:08
cotto_work lichtkind: np
lichtkind i maybe ask some more dull questions too want to write an perl 6 update article
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
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
sorear pretty much 21:10
Lorito came first, though
cotto_work M0 is an actual virtual machine specification.
sorear Lorito was a project to re-imagine Parrot
cotto_work dukeleto and I are working on implementing a prototype.
lichtkind any other important parrot news (since last year) ? :) 21:14
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 :)
sorear jnthn__ is developing a replacement for our current Object and Class PMCs, one that will support more languages natively 21:18
lucian: hey, the old one worked. you could actually tell the difference between -g ms and -g inf. Most of the time.
mikehh I think there might be missing writ barriers but otherwise ok
write
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
IMCC is better encapsulated, like a cyst forming around a parasite 21:20
Cardinal and Pynie have been resurrected, we could see real use of non-Perl code on Parrot by the end of GSoC
mikehh IMCC needs a new a new approach/to be replaced or something
sorear we're in a time of great promise right now. 21:21
cotto_work there are some interesting gsoc projects going on too
lichtkind what means generational GC im not so deep into that? 21:25
sorear much faster and more memory efficient 21:26
lucian lichtkind: www.google.com/url?url=http://en.wi...CCUQygQwAA 21:27
bah, stupid google link
lichtkind thank you
lucian lichtkind: en.wikipedia.org/wiki/Garbage_colle...eral_GC.29
21:31 ambs left
lichtkind how much faster? 21:33
im am very glad to hear the good new
the nasty journalist question would be its because you feel the possibility of raudo to port to CRL or even JVM? 21:34
dukeleto lichtkind: what exactly is your nasty journalist question? 21:35
lichtkind it would be: is you recent progress driven by the possibility of rakudo to port to CRL or even JVM? 21:36
cotto_work Parrot isn't yet to the point where we don't need to focus on improving performance. 21:37
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
cotto_work M0 is a big part of our long-term goal of removing some longstanding bottlenecks. 21:39
lichtkind yes thats the way i read the parrot docs 21:40
sorear lichtkind: parrot doesn't really care that much what Rakudo does
lichtkind but you know that ugly journalists always after politics :)
mikehh sorear: not entirely true
lichtkind i would also think so 21:41
sorear and Rakudo, AFAIK, has never been talking about abandoning Parrot
lichtkind since rakudo is the primary purpose of parrot
cotto_work sorear: I don't agree. I want Parrot to provide as good a platform as possible for Rakudo.
21:41 bluescreen left
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.
sorear the CLR and JVM ports are, AFAIK, intended more to support exotic environments where hosting 10^5 lines of C89 is infeasable
e.g. WP7
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. :)
lucian lichtkind: windows phone 7 i believe
lichtkind i alsways was a fanboy of the archtitectural possibilities but there was at a time a feeling being stuck
im glad that this is overcome
NotFound I was thinking WordPerfect. 21:45
lichtkind but you have no measurement how much faster the new GC is? 21:47
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
lichtkind than you 21:51
lucian lichtkind: but don't take my word for it, there were some blog posts about it
cotto_work lichtkind: if you want a good workload, look at the core.pm step of the Rakudo build. 21:52
21:56 lucian_ joined
sorear lichtkind: before, building Rakudo filled up all 2.375 GB of real+swap memory I have installed and OOMed 21:57
lichtkind: after generational_gc landed, I can now build it in 320MB, leaving enough free to have a responsive system
lucian_ of course, parrot itself gobbles up a lot of memory in general 21:58
22:00 lucian left, lucian_ is now known as lucian
lichtkind sorear: whst id OOMed? 22:01
lucian lichtkind: out of memory
lichtkind oom prevention program?
sorear program runs out of memory, program ends with an error 22:02
lichtkind ah, thanks
22:02 linge joined
benabik minor nqp-rx enhancement: gist.github.com/1013096 22:08
bubaflub benabik: does that fix the lexical problem you were having before?
benabik Declare variables where they were declared. This fixes my `my $old := $*VAR; my $*VAR := $new`
bubaflub: Yes
bubaflub benabik: fantastic. you should ping jnthn__ or pmichaud to get the patch accepted 22:10
22:11 hercynium left
sorear benabik: -1. that code isn't supposed to work. 22:11
benabik sorear: Why not?
lichtkind thank you again guys i will come back with more questions :)
benabik sorear: I don't see why NQP moves where I declare the variable. 22:12
22:12 fperrad left
sorear benabik: because in Perl 6, variables are always declared at ENTER time 22:13
benabik That is both surprising and irritating. 22:14
sorear this is related to what makes declaring subs after using them work
benabik Allowing `$x; my $x` seems like an error. 22:15
sorear jnthn__: ping 22:16
jnthn__ sorear: pong 22:17
jnthn__ reads...
yes, the ENTER time bit is right
I suspect we should die at compile time about the $x usage before declaration. 22:18
sorear jnthn__: benabik's actual problem is say $*FOO; my $*FOO = 6 22:19
arnsholt Wouldn't that cause problems with dynamic vars?
jnthn__ Guess the first one would print undef or something
benabik It will "say" undef
arnsholt Since my $*foo establishes a new binding
sorear jnthn__: please explain to benabik why it has to. my cogent-explanation-generator isn't working today.
jnthn__ If NQP supported it, my $*FOO := $*OUTER::FOO; would do what benabik wants. 22:20
cah
I meant
my $*FOO := $*CALLER::FOO;
Anyway, "Allowing `$x; my $x` seems like an error." - this is correct 22:21
But so should be allowing $*x; my $*x
benabik When there's an "outer" $*x, that seems to make perfect sense to me.
jnthn__ A ticket on github.com/perl6/nqp/ is wlecome 22:22
benabik Hence me trying to use it.
jnthn__ benabik: No, that's not allowed in Perl 6.
benabik: STD gives you a nice error if you try to use it for that.
NQP doesn't yet, I'm afraid.
benabik Bah.
I vaugely understand the language decision, it's just hideously inconvenient for me right now.
jnthn__ Does Parrot have an op for "look for a caller lexical, but skip n frames@? 22:23
I know there's find_caller_lex__PS 22:24
benabik I think pir::find_dynamic_lex skips the current lexpad...
jnthn__ oh, it's find_dynamic_lex...
jnthn__ checks
benabik There is also a find_caller_lex
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.
It does seem to search current lexpad, but the doc says "search through callar lexpads". 22:26
jnthn__ find_dynamic_lex may do it
benabik No, because $*FOO in nqp-rx does compile to it and that's not how nqp-rx works. 22:27
arnsholt benabik: A workaround should be to use two blocks where you have one 22:28
jnthn__ hmm
arnsholt { my $old = $*foo; { my $*foo = $new; } }
jnthn__ arnsholt: ah, yes 22:29
benabik arnsholt: I'd like that better if that inner block wasn't 100 lines, but yes
arnsholt It's not aesthetically optimal, but hopefully it'll do what you want with a minimum of fuss
jnthn__ I ever used that workaround before, come to think of it...
arnsholt benabik: Yeah, that's what I was afraid of
jnthn__ *even
NotFound I told you before, all can be solved by adding another level ;)
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:30
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:33
arnsholt Heh. Good question =) 22:34
22:34 hudnix left
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:42
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:44
22:52 lichtkind left
jnthn__ benabik: thanks 22:54
sleep &
22:55 alester left 23:04 whiteknight joined
cotto_work ohai whiteknight 23:05
whiteknight lolhi cotto_work
what's happenin? 23:08
dalek rrot/m0-prototype: 2e54781 | cotto++ | / (2 files):
make calling conventions test less wrong, but still wrong

Also, hijack print_n to dump a register and exit.		 23:13
23:29 theory joined
whiteknight tcurtis: ping 23:32
23:39 kid51 joined
tcurtis whiteknight: pong 23:44
aloha, seen darbelo
aloha tcurtis: darbelo was last seen in #parrot 11 days 2 hours ago joining the channel.
whiteknight tcurtis: Rosella does have functionality to make a value immutable 23:45
it doesn't currently support arrays, but it's trivial to ad
add
actually, I may do that now while I'm looking at the code 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!