half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 6 October 2009.
GeJ dukeleto: thank you. 00:13
TiMBuS wasnt there a parrot function to turn a STRING back into a c string? or am i imagining things 00:14
cotto_work TiMBuS, Parrot_str_to_cstring iirc 00:15
TiMBuS that looks about right
thanks cotto
darbelo TiMBuS: Just don't forget to free it.
cotto_work it's not a very smart function, but cstrings aren't that smart in the first place
np 00:16
darbelo Don't forget to Parrot_str_free_cstring() it, actually. 00:17
TiMBuS ah. yeah i was just grepping for that 00:18
00:19 payload joined
darbelo The thing is: mem_sys_free() works too, but it's better to use Parrot_str_free_cstring() 00:20
TiMBuS does parrot have a way to allocate automatically collected memory? 00:21
cotto_work TiMBuS, if it did, we'd be using it by now. The closest we have is a ManagedStruct.
darbelo PMCs and STRINGS are both garbage collected, it dependnds on what you want to do with them. 00:22
TiMBuS: What are you trying to do? 00:23
TiMBuS oh, i'm just calling some c functions 00:24
darbelo And they want you to allocate a char * for them? 00:25
TiMBuS no they just need a string argument, im assuming STRINGs arent null terminated
coke STRINGS ain't chars.
don't look under the hood. 00:26
-> zz
darbelo TiMBuS: You're stuck with Parrot_str_to_cstring() 00:28
00:29 payload joined
TiMBuS that's fine 00:29
darbelo NotFound++ had a trick for making cstrings 'managed' let me look for it.
It might help you.
cotto_work Didn't allison say "Don't do that."? 00:30
darbelo Se said "Don't do that in the parrot core." 00:31
cotto_work important distinction there
darbelo She also said we should "stop using cstrings". 00:32
TiMBuS wellll im writing a NCI
darbelo TT#1083 If you want inspiration :)
trac.parrot.org/parrot/ticket/1083
The basic idea is to grab an allocated cstring and stick it into a ManagedStruct PMC so that the garbage collector will track it for you. 00:35
TiMBuS that makes sense
i might use it in my next language for when i just pass off certain ops to the stdc lib
00:41 pyrimidine joined 00:44 msmatsko joined 00:45 Zak joined
dalek rrot: r41744 | darbelo++ | trunk/src/io/api.c:
Replace anther 'fake' STRING with a real one.
 00:47
darbelo Ok, ttbot didn't complain. I'm heading out. 00:55
cotto_work w00t
00:55 darbelo left 01:02 rhr joined 01:20 Patterner joined
dalek rrot: r41745 | jkeenan++ | branches/detect_llvm:
Create branch to work on detection of LLVM.
 01:38
rrot: r41746 | jkeenan++ | branches/detect_llvm (4 files):
Rough first draft of code to detect LLVM.
 01:45
01:55 Ruilov joined, rhr joined
dalek rrot: r41747 | jkeenan++ | branches/detect_llvm/config/auto/llvm.pm:
Add inline comments on module design; remove commented-out code.
 01:58
02:10 Andy joined 02:35 janus joined
jrtayloriv moritz, ping 03:13
dalek rrot: r41748 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
[pct]: Add a 'yield' type to POST::Op.
 03:15
03:16 rhr joined
dalek rrot: r41749 | pmichaud++ | trunk/compilers/nqp/src (2 files):
[nqp]: Allow methods to be named "category:sym<...>".
 03:18
03:45 jrtayloriv joined
jrtayloriv Sorry if this already came through -- I got cut off (I've got an unbelievably annoying problem with an ethernet jack that doesn't allow the cable to "clip" into it, so I have to tape it into my laptop, and every now and then the tape comes out ... GRRAAARGH!) 03:47
If I created a closure like: 12my $closure := PAST::Op.new(:inline('%r = newclosure %0'),$past); ... how would I then go about calling it later from a PAST::Op?
(where $past is a PAST::Block representing the body of the sub) 03:48
Tene jrtayloriv: just put the result in a PAST::Op 03:49
jrtayloriv Tene, So just do a PAST::Op 'call' with $closure as the Op's first child? 03:50
Tene Yes. 03:51
jrtayloriv Tene, And I can save $closure into a PAST::Var too right?
Tene Yes.
jrtayloriv excellent, thanks
04:14 Zak joined
dukeleto 'ello 04:52
GeJ H' 05:01
dukeleto GeJ: are you working on pcc_reapply? 05:14
GeJ I'm C illiterate. The best I can do (unless I missed an obvious task I could accomplish, if so please enlighten me) is run tests from time to time and report failures. 05:28
Or for this branch in particular report an important increase of failures.
dukeleto GeJ: yeah, it is kind of rough right now. pcc_reapply does not compile on all platforms, causes infinite loops during the test suite on others, and it only makes sense to do "make corevm" and "make coretest" in pcc_reapply now 05:30
last time I checked, test_more.pir wasn't working, which is blocking me from adding tests 05:31
GeJ: one thing you can do: some error messages relating to function calls changed slightly, which has caused some tests to start failing. if you find those you can fix 'em 05:33
msg japhb looks like plumage expects an installed parrot in a particular hard-coded place 05:34
purl Message for japhb stored.
dalek TT #1096 created by dukeleto++: Plumage requires an installed parrot in a hard-coded place 05:41
rrot: r41750 | dukeleto++ | trunk (2 files):
[TT #1089][t] Convert t/pmc/resizableintegerarray.t to PIR and fix a typo in the implementation, kurahaupo++
 05:48
06:01 chromatic joined 06:02 uniejo joined
japhb dukeleto, huh? Earlier this morning I just tried installing parrot in a different place (from a different build location too, no less) and it worked like a charm 06:19
dukeleto, as long as you run `parrot_nqp Configure.nqp` using the parrot_nqp from the correct parrot, all should be good. 06:20
Man, I hate having to choose between hacking and being even remotely caught up with email ... 06:21
06:22 jrtayloriv joined
moritz jrtayloriv: pong 06:28
06:28 szabgab joined
jrtayloriv moritz, Hey -- for some reason the query -- nqp && closure -- breaks irclog. The first page displays and then the second page, it removes closure from the query (try it) ... and is there any way for me to do boolean search where it will only give results where BOTH words were used in same sentence/line? 06:30
Sorry, first part wasn't clear (2:30am here, and my brain is mush) -- The first results page displays fine, but then when I click '2' to go to second page, it removes "closure" from the query. 06:31
06:32 fperrad joined
moritz jrtayloriv: the search is mostly broken, and I wanted to re-do it properly for some time now, with KinoSearch or another indexing module - so far I haven't got around to it :( 06:32
jrtayloriv No big deal -- just wanted to point it out. (I was just randomly trying things to see if I could get boolean search to work) 06:33
But a beefed up search would rock -- I've found that the irc logs are the best docs, but the search is definitely limiting. 06:34
moritz basically I wanted to wait for the 2.0 version of KinoSearch, but I guess I'll just try out the developer releases instead 06:37
06:37 viklund joined
moritz oooh, there was a dev release on Aug 31 06:37
jrtayloriv looking at their site now ... I'd never heard of it until you mentioned it. 06:38
moritz it's a port of Lucene to perl 06:39
06:40 viklund joined
jrtayloriv cool -- it's got the two things I wanted most: booleans and quoting 06:40
06:41 viklund joined
moritz aye 06:42
and stemming, and other stuff
06:42 viklund joined
dukeleto japhb: i will try again 06:42
moritz japhb: I saw on the parrotsketch logs that you need some hosting... I could offer some if you still need it 06:49
japhb: basically I have access to a server where I can hand out root access; it's a Debian Lenny box 06:50
dukeleto japhb: i see what is going on. if you run it from a parrot that was never meant to be installed (and hence was given no install prefix), it barfs
japhb: but that is mostly my fault
japhb heh 06:51
Yeah, you need to have installed your parrot with `make install-dev`. Same requirement Rakudo has, FWIW.
jrtayloriv I don't really know how to ask this question -- still trying to hash out what I'm trying to do. But basically, I am trying to figure out how to properly expand Scheme macros for my compiler. I was going to add a new stage originally, between parse and past, but I don't know (a) if that's the right way to do it, and (b) how to do it if it is. 06:52
Any recommendations for where to look for examples of such a stage in another HLL compiler? 06:53
dukeleto japhb: yes, you are correct
jrtayloriv I need to expand them before I eval the s-expressions, but I need to have access to lexicals to see if the name of the macro is being shadowed by a more local variable definition. 06:54
japhb As for hosting, moritz, thank you. (I ride Debian testing on my personal machines, so it would at least be familiar territory. :-)
06:54 mberends joined
japhb moritz, but first I want to give Allison a chance to get back to me ... she was going to look into parrot.org hosting ... and asked that I code the metadata server with mod_parrot. :-) 06:56
moritz japhb: sure; feel free to come back to my offer at any time if you need it
you can also use it as a development machine to figure out what modules and other requirements you need on the "real thing" or so 06:57
japhb moritz, that's a good idea 06:58
email or msg me the details, if you like 06:59
07:10 cotto joined
japhb moritz++ # sucker^W victim^W hosting provider 07:10
moritz ;-) 07:12
japhb Oh, which reminds me, moritz, if you've sent in a signed PaFo CLA, send me your Gitorious nick, and I'll add you as a parrot-plumage committer. 07:13
Now, there's something I'm supposed to be doing right now .... Oh right, sleeping. 07:14
g'night, all!
dukeleto japhb: night 07:15
07:40 riffraff joined
dalek TT #1096 closed by dukeleto++: Plumage requires an installed parrot in a hard-coded place 07:40
TT #1097 created by dukeleto++: Plumage fails to compile on case-insensitive file systems 07:47
dukeleto is hacking on plumage. 08:03
dalek rrot: r41751 | mikehh++ | trunk/t/op/cmp-nonbranch.t:
codetest/distro_tests failure - svn properties
08:18 payload joined
dukeleto i am guessing that plumage should have a test suite written in pir and/or nqp 08:25
08:35 allison joined 09:37 Whiteknight joined
Whiteknight good morning #parrot 09:45
mikehh hiya Whiteknight 09:47
Whiteknight hello mikehh
mikehh Test failures with fulltest on testf and testg for t/compilers/imcc/syn/macro.t and t/compilers/imcc/syn/regressions.t 09:55
t/compilers/imcc/syn/macro.t - Failed tests: 2-4 - Non-zero exit status: 3
t/compilers/imcc/syn/regressions.t - Failed test: 7 - Non-zero exit status: 1
All other tests PASS (pre/post-config, smoke (#28657), fulltest) at r41750/1 - Ubuntu 9.04 amd64
in other words the test passes on the other cores just fails -f and -g
with the same failures 09:56
got to go to the store and also fill up the car - bbl and will open a ticket on it 09:58
10:10 jhelwig joined 11:11 allison joined 11:32 mikehh joined
dalek kudo: cf8884d | jonathan++ | src/ (3 files):
Keep the main nominal type and constraint type(s) separated out at parse time. This simplifies signature construction and also avoids creating a bunch of one-elements junctions that we don't really need. Between this and yesterday's refactor, we shave about 10% or so off Rakudo's startup time.
 11:43
shorten dalek's url is at xrl.us/bfquhu
12:01 masak joined 12:02 whiteknight joined
whiteknight good morning again! 12:03
coke afternoon.
purl hmmm... afternoon is when we eat my lunch.
whiteknight coke, where are you at? 12:04
coke Leeds, UK
whiteknight didn't you used to be in NY?
Coke it's only for a week.
whiteknight okay.
moritz there are things called planes, and they allow you to move real fast from NY to UK 12:05
:-)
Coke not fast enough. :P|
12:13 whiteknight joined 12:27 fperrad_ joined 12:34 Ron joined 12:36 payload joined 12:46 quek joined 12:48 Ron_ joined 12:50 Ron joined 13:06 PerlJam joined 13:09 Ron_ joined 13:11 ruoso joined 13:14 allison joined 13:16 slavorg joined 13:49 iblechbot joined
dalek kudo: a0d1e55 | moritz++ | docs/release_guide.pod:
[docs/release_guide.pod] suggest Lisbon.pm
 13:52
shorten dalek's url is at xrl.us/bfqu2d
14:06 jsut_ joined 14:08 szabgab joined 14:11 Andy joined 14:18 Psyche^ joined 14:26 Ryan52 joined 14:33 theory joined
whiteknight slow day today 14:55
japhb legal detail: I offered a commit bit for Plumage to moritz, who responded thus: "I submitted a signed CLA to TPF before parrot foundation existed - I hope that qualifies (at least it qualified for a parrot commit bit ;-)" Is he correct? Were all the pre-PaFo TPF people grandfathered in? 14:59
NotFound japhb: I hope so. If not, I'm not qualified as commiter. 15:00
PerlJam japhb: I'm pretty sure they were.
moritz since the perl foundation assigned their copyright to the parrot foundation, the CLAs should also be inherited that way (though IANAL) 15:01
if it should prove to be a problem, I could also sign and send in a parrot CLA
15:04 xenoterracide joined
japhb moritz, I think you are correct, I just wanted final confirmation -- because, as NotFound pointed out, it *will* come up again. And I'd really rather not force people to do useless busywork. 15:04
PerlJam Allison is probably the one to ask for a more definitive answer. 15:05
moritz japhb: I think for final confirmation you have to ask allison++ (and for that mail works great)
japhb If it turns out that only core Parrot was grandfathered, then we'll have to do the CLA jig, but better to know that now. :-)
email sent 15:12
moritz japhb++
particle all parrot committers must sign a pafo cla 15:18
you can scan it and email it, so no postage necessary 15:19
japhb particle, are you saying that all your original Parrot committers need to do it even to work on core Parrot? That seems borken. 15:20
particle i want signed cla's from all parrot committers
moritz maybe it would make sense to generate a list of all parrot commiters who haven't yet, and write them an email or so?
japhb ugh, I hate paperwork ... 15:21
sorry for stirring up this can of worms, guys.
moritz you're just the message boy, not the bad news he delivers :-) 15:22
particle is it really that difficult? 15:24
read a document, sign it, and email, fax, or mail it. 15:25
and parrot foundation has better protection of parrot's code.
japhb particle, every little impediment, no matter how small, causes hacking to be delayed -- and if the prospective hacker isn't in the mood, they don't bother to get around to it, and potential code is lost. There's nothing that keeps people from jumping through the hoop, but on the modern Internet are a thousand little hoops to jump through, and people tend to focus energy where there are fewer hoops. If this is a truly necessary hoop, then 15:32
fine, no problem. But having spent too many painful hours looking at signup process drop-off charts on various web sites, it's clear that people are amazingly lazy when it comes to "paperwork", even when they plan to devote a huge amount of personal time to the site in question later.
You'd be amazed how often people refuse to do a 10 second task that gets in the way of a 10 hour pile of fun.
particle oh, brother. 15:33
purl brother is probably home. Gotta go. A+
particle in the time it took you to write that, you could have completed the task.
15:35 nopaste joined
particle feel free to put the task off as long as you want, until someone forces you to do it. 15:37
japhb particle, I've already done it. Long ago.
I'm more than average willing to jump through hoops for this project. :-) 15:38
15:38 Ruilov left
japhb I'm talking about *other* potential committers. 15:38
But in any case as I said: If it's legally necessary, that's that.
particle new committers must sign a cla before being granted a commit bit to parrot. 15:39
*a parrot foundation cla
16:17 iblechbot joined 16:24 darbelo joined
cotto time for w3rk 16:28
(or at least that's what I'm trying to convince myself of) 16:29
16:35 kjeldahl_ joined 16:37 cognominal joined
dukeleto 'ello 16:38
jonathan Anyone familiar with the ops compiler know if there's a way to say that I want to only take a non-constant PMC? 16:45
cotto_work good morning 16:46
jonathan, lemme dig
jonathan is digging too :-) 16:47
16:48 payload joined 16:50 nopaste joined
jonathan Ah 16:50
Marking them "inout" supresses it.
Erm, suppresses the constant variants.
cotto_work do you're happy? 16:54
s/d/s/ 16:55
jonathan erm
not yet ;-)
Is there a maximum number of operands that an op may have?
particle a long time ago it was 8 16:57
jonathan omg yes
It still is.
dukeleto is that documented?
jonathan ;^;
particle wow
jonathan But I want 9!!
dukeleto jonathan: please write a failing test :) 16:58
particle recompile.
an op with 9 operands?
cotto_work What about invar?
particle excuse me, don't you want to pass a higher-level data structure to that op?
jonathan No. 16:59
particle sheesh
jonathan If I wanted to do that, I'd not be wanting to take so many operands. :-P
particle what's the op do?
jonathan particle: Tries to set up a signature element Really Fast.
particle: It's slow today because we mess around building up a high level data structure. 17:00
Amongst other things.
particle ah, well if it's capitalized, i understand.
jonathan OK WILL BE!
;-)
It's OK, I'll cope for now. :-)
particle what consequence does it have for parrot overall to raise that limit?
jonathan Probably a memory hit. 17:01
cotto_work wonders why
purl cotto_work wo-wo-wo-wo-wooonders o/~
particle i wonder how much it slows things down, or more likely, uses memory
moritz the usual answer is "more sanity, less speed"
jonathan I was just a tad surprised to run into a hard limit there. 17:02
Thought we'd allocate by the number of things we need.
Since most ops take, like, 2 or 3 operands.
particle whaddayawant, infinite registers *and* infinite operands?
jonathan 9 isn't infinite. ;-)
particle it's approaching infinity, though :P 17:03
jonathan grins and copes with 8 for now.
cotto_work It practically is. It's almost TWO DIGITS.
jonathan "for some values of infinity" :-)
cotto_work (even more in binary)
particle it's two digits in base 8
17:05 chromatic joined 17:07 kurahaupo joined 17:10 nopaste joined
cotto_work btw, it's PARROT_MAX_ARGS in include/parrot/op.h where the limit lives 17:11
jonathan cotto_work: OK, thanks. That's good to know. 17:17
dalek kudo: 30e2cfd | jonathan++ | (4 files):
Add in ops that allow for fast construction of low level signatures.
 17:19
shorten dalek's url is at xrl.us/bfqv9h
dukeleto particle: is/should the default max args to an opcode of 8 be documented somewhere? 17:30
particle yes, it should be. 17:31
heck, it should be configure-time modifiable if you ask me. 17:32
17:35 nopaste joined 17:38 einstein joined
cotto_work btw, changing that value to 16 yields no measurable slowdown in oofib fwiw. 17:40
whiteknight besides in IMCC, I can't really imagine that there would be any effect of having a limit of 16 operands 17:41
that number doesn't come into play during execution at all 17:42
the big question is: how inefficient is IMCC's algorithm for parsing operands. If it's O(N^10) we're not going to want to increase the limit too much
but if it's (more likely) O(n^2) or something, and that's only the worst case in a search for a missing opcode, the performance isn't an issue 17:43
cotto_work Without knowing imcc
's way of doing that, I'd say +1 to setting the limit to 16 to make jonathan happy 17:44
darbelo Well, if it's an IMCC-only thing you can measure it rather easily.
Just a matter of running a PIR file with lots of ops through calgrind before and after. 17:46
cotto_work It wouldn't be a bad idea to have a test op with the maximum number of params just to make sure we don't have some ugly corner case lurking. 17:47
whiteknight test case is a good idea 17:49
of course, as soon as we change the limit jonathan is going to want an op that takes 17 parameters :) 17:50
17:50 nopaste joined
whiteknight if you give a mouse a cookie... 17:50
cotto_work We'll throw him over that bridge when we come to it.
chromatic I'm backlogging, but ERGH. 17:51
whiteknight I sense a disturbance in the force, as if chromatic is displeased and then is silent
chromatic Variable-sized ops are the opposite of walking bytecode fast. 17:52
whiteknight we have variable-sized opcodes now
and fixed-size opcodes are the opposite of making bytecode small 17:53
...of course, we could get around both those issues by making opcodes have a fixed number of operands but creating a "dummy" op that only serves as a placeholder for making additional arguments available to the master op 17:55
18:01 allison joined 18:03 joeri joined
chromatic If we can make Lorito ops a fixed size (three arg form), I'm happy. 18:06
18:10 nopaste joined
cotto_work allison, what are your thoughts on bumping the maximum number of params an op can take? Rakudo apparently wants 9 and the current limit is 8. 18:17
allison cotto: these are for dynamic ops? yes, we should allow more 18:18
cotto: I'd say go for 16 next, to keep the binary boundary
18:20 nopaste joined
allison cotto: I doubt we'll need to go for 32 18:20
cotto: (or by that time we may be on Lorito, and have no limit) 18:21
whiteknight chromatic: I agree. fixed-size ops for lorito is a very very good idea
cotto_work I don't want to see one of those 32-param ops.
whiteknight in lorito-world, PBC will only really serve as a compressed interchange format anyway
cotto_work I shouldn't commit from work, but anyone with a commit bit should feel free to bump PARROT_MAX_ARGS in include/parrot/op.h to 16. 18:23
allison chromatic: fixed-size in general seems unlikely, but a fixed size of one (the call signature) is easily possible
NotFound I'm looking at rakudo generated pir and see a lot of things like: "unless_null $P21, vivify_30 | new $P21, "Failure" | vivify_30:" Maybe a new_if_null opcode can speed up and reduce size.
whiteknight cotto: on it
chromatic Fixed-size in general seems to work for many, many other machines, virtual and otherwise.
allison chromatic: are you talking about Lorito's core ops, or the ops defined on top (written in Lorito ops)? 18:24
cotto_work jonathan, there you go.
whiteknight r41752 18:25
darbelo cotto_work: All your code are belong to MS?
chromatic Lorito's core ops.
allison chromatic: if it's the former, I agree, because it's a tightly controlled set
cotto_work darbelo, only what I write while I'm on the clock.
allison chromatic: aye, agreed
whiteknight for lorito I like the idea of three-argument ops 18:26
jonathan cotto_work: Thanks.
allison 3 may not be enough (depending on how low-level we make them), but 8 certainly would be 18:27
dynamic ops, on the other hand likely will need more flexibility
chromatic Three. Fixed size.
dalek rrot: r41752 | whiteknight++ | trunk/include/parrot/op.h:
[ops] bump PARROT_MAX_ARGS from 8 to 16 to allow for a new class of overly-complicated ops. cotto++
whiteknight LLVM ops are, I believe, three-argument ops.
almost all RISC machines are too 18:28
chromatic libJIT too.
whiteknight lots of good literature about optimizing those
yes
allison chromatic: <shrug> we'll see. It's a restriction on complexity in one part of the system, and worth it if it gains us in optimizations. But, if it costs us too much complexity in another part of the system, it's worth sacrificing.
chromatic Read the code that looks for bytecode annotations. 18:30
allison Horrible code now is not prove that the same job couldn't be done with better code.
chromatic I can make that horrible code O(log n) +- some constant.
Fixed-size opcodes make that horrible code non horrible and O(1). 18:31
See also: non-local fixups.
See also: bytecode splicing.
(important for tracing JIT)
whiteknight lucky for us, a lot of extremely low-level operations lend themselves nicely to three-arg form 18:32
chromatic Exactly. There's a reason it's common. 18:33
allison Like I said, we'll see. Changes to the bytecode are pretty long-term planning.
whiteknight yes
18:39 HG` joined 18:40 nopaste joined 18:45 viklund joined 18:51 Zak joined 18:56 mokurai joined 19:00 nopaste joined
darbelo Hmm. I'm seeing failures in t/compilers/imcc/syn/macro.t 19:23
dukeleto darbelo: yeah, in fulltest? 19:24
darbelo Yup.
dukeleto darbelo: i was seeing those in trunk as well
darbelo They pass when I prove -v the file.
Same for you? 19:25
chromatic It's a difference in runcores for the line number bugs I fixed yesterday.
moritz seen Infinoid
purl Infinoid was last seen on purl 5 days, 9 hours, 28 minutes and 32 seconds ago, saying: <private message> [Oct 2 09:49:08 2009]
darbelo The tests expect the number to be wrong?
chromatic The tests expect the numbers to be right for all runcores. 19:27
I'm not sure why they're wrong in this case.
NotFound /parrot --runcore=fast t/compilers/imcc/syn/macro_2.pir 19:32
Null PMC access in get_string()
current instr.: 'test' pc -1 ((unknown file):-1)
Doesn't match Null PMC access .*current instr.*:5 19:33
chromatic That's strange, as the fast runcore is also the default runcore. 19:34
Or should be.
19:34 joeri left
NotFound Looks like in linux amd64 is not. 19:34
19:35 nopaste joined
chromatic see src/runcore/main.c lines 127 and 143. 19:35
NotFound chromatic: putting a printf in Parrot_runcore_switch I see a call with fast followed by a call with slow 19:44
chromatic Hm.
NotFound Using --runcore=fast I see two calls with fast
19:45 nopaste joined
chromatic What if you change compilers/imcc/main.c:358 to: 19:46
INTVAL core = PARROT_FAST_CORE;
NotFound That way I get two calls with fast in both cases 19:49
(with or without --runcore=fast)
chromatic Okay. Now we need to fix several testf failures. 19:50
nopaste "darbelo" at 200.49.154.173 pasted "Can our win32 users give this a test?" (73 lines) at nopaste.snit.ch/18251 19:51
NotFound t/op/annotate.t fails with that change
chromatic Several tests do. 19:52
whiteknight apparently I'm a group manager for the linked in group now 19:55
cotto_work With great power comes great responsibility.
darbelo And great potetntial for abuse.
Tene am I in that group? I don't log into linkedin often. 19:58
mikehh fulltest failures with testf, testg and testS - these cores all FAIL the same tests
t/compilers/imcc/syn/macro.t - Failed tests: 2-4
t/compilers/imcc/syn/regressions.t - Failed test: 7
All other tests PASS (pre/post-config, smoke (#28676), rest of fulltest) at r41752 - Ubuntu 9.04 amd64
dalek rrot: r41753 | darbelo++ | trunk/src/io (4 files):
Change string-internals poking via ->strstart to poking via Buffer_bufstart().
 19:59
purl dalek: that doesn't look right
pmichaud phone 20:00
20:01 nopaste joined
chromatic NotFound, mikehh nopaste.snit.ch/18252 20:02
NotFound chromatic: a general solution can be setting in the runloop data a pointer to the pc variable. 20:05
That way forbids optimizing pc into a register, though. 20:06
whiteknight but we don't need to optimize it into a register in that case either, I don't think 20:07
chromatic The nopaste does that. 20:08
whiteknight Tene: I dont know if you are in the group or not. I don't know your real name :) 20:09
Unless it's somethin obvious like Tene Teneson, which I doubt
20:10 nopaste joined
NotFound The functions for setting and switching runcore are lame, they convert from numeric to string to numeric for no good reason. 20:13
whiteknight lame indeed
and on that note.. 20:14
whiteknight leaves
chromatic Backwards compatibility.
purl i think backwards compatibility is overrated. or important
20:17 xenoterracide_ joined
mikehh chromatic: the patch gets fast core through but -g and -S still FAIL 20:20
make test PASSes but the specific tests fail in _S and -g 20:22
chromatic Same tests?
mikehh t/compilers/imcc/syn/macro.t - Failed tests: 2-4 and t/compilers/imcc/syn/regressions.t - Failed test: 7 20:23
in both cores but now -f PASSes
20:24 ruoso joined
mikehh with that patch that is 20:24
20:30 nopaste joined
mikehh but make testf now fails t/op/debuginfo.t - Failed tests: 1, 7-8 20:34
chromatic Doesn't testf run the fast core? 20:38
NotFound opcode_t *current_pc; /* program counter of Sub invocation */ 20:42
This comment is realistic?
chromatic Sort of.
It's not really a counter and it's not just Sub invocation, but the spirit of the comment is right. 20:43
NotFound I think that the field name without any comment is clearer than that.
chromatic Makes sense. 20:44
cotto_work +1
purl 1
cotto_work < purl-- >
NotFound Well, my idea is: change that opcode_t * to an opcode_t **, and we only need to set it at the start of the runloop.
Coke purl += sqrt(i)
purl Coke: sorry...
20:45 nopaste joined
chromatic I'd have to see code to be sure of that, but it's worth trying. 20:46
mikehh, t/op/debuginfo.t has some workarounds for the fast core, but they're unnecessary now.
Tene okay, let's see if I can send mail to parrot-dev or not... I remember having some kind of trouble in the past. 20:47
I just replied to Phil... let's see how long it takes to go through.
Oh, immediately. That's different from what I remembered. That's nice. :)
20:49 cotto_work left, cotto_work joined
NotFound Thinking better, it can't work. runloops for context of continuations can be gone. 20:49
chromatic Even still, keeping a pointer to the current opcode in the interpreter seems like a hack. 20:53
"Oh, it *must* be faster, because we're not dereferencing two pointers to read it!"
dukeleto Tene: any word on test_more.pir on pcc_reapply ? 20:54
Tene dukeleto: last night mostly didn't happen for me. No word. 20:55
I'm more hopeful about tonight.
chromatic For introspection to work reliably, we need to know the current opcode we're executing in the PBC. That's all.
dukeleto Tene: cool, just checking
Tene: did you see the branches that i pushed to plumage on gitorious? code review? 20:58
Tene dukeleto: I didn't. 20:59
NotFound The reverse way can work: using a pointer to the context current_pc instead of having a pc and updating from it in each runloop iteration.
21:00 nopaste joined
NotFound Also bad idea, the current context can change inside the loop. 21:01
chromatic We need to store the pc in one and only one place, I suspect. 21:03
21:07 Whiteknight joined 21:10 nopaste joined
japhb dukeleto, why branch for a change to the partcl metadata? 21:10
dukeleto, and why does OS X have problems with Glue.pir being in the repo root?
dukeleto japhb: Plumage and plumage conflict. there is a TT, one sec
darbelo plumage has trac? 21:11
dukeleto japhb: i make topic branches for everything. that is how I roll
Whiteknight I love when new users get interested in parrot!
dukeleto darbelo: i just started making plumage TT's, no one told me not to :)
jdv79 what's the possibility of doing stuff like tracing jit compiling to machine code?
dukeleto japhb: trac.parrot.org/parrot/ticket/1097 21:12
jdv79 basically the stuff the js guys are doing with tracemonkey and v8.
missing an "and" in there.
japhb darbelo, AFAICT, there's no problem at the moment with just piggy backing on the Parrot Trac, since it will be folded into Parrot someday anyway
dukeleto japhb: i organized PIR files into pir/ and then the problems went away 21:13
japhb dukeleto, ah, yes, brain dead file systems. Tene gets no biscuit today. ;-)
chromatic jdv79, that's one of the goals of Lorito.
japhb dukeleto, how about 'lib' instead? 21:14
dukeleto japhb: yes, I agree. os x's filesystem should die in a fire while suffocating Steve Jobs
japhb: sure, doesn't matter to me. See, this is why I made a topic branch ;)
japhb In fact, I was considering making a src/ dir, with src/lib/ underneath.
The top level would just be the SHOUTING FILES, Configure.nqp, src/, and metadata/ . 21:15
darbelo src++
japhb And maybe leave probes/ at the top level too, I guess, since it's not really part of src/
darbelo likes src/ 21:16
japhb Would you mind re-branching with that layout in mind?
And feel free to merge the one commit for the partcl metadata fix back to master. ;-)
dalek tracwiki: v106 | whiteknight++ | WikiStart 21:17
tracwiki: + more info about more hackathons
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/bfqxye
japhb dukeleto, see above # forgot to use your nick
dukeleto japhb: sure.
japhb: you want src/lib, correct?
japhb yeah, src/plumage.nqp, src/lib/Glue.pir, src/lib/Plumage/Downloader.pir 21:18
Tene Whiteknight: did the hackathon targets mentioned during #ps get added anywhere?
21:20 nopaste joined
Whiteknight Tene: did just now 21:20
AllHackathons on the wiki
dalek tracwiki: v1 | whiteknight++ | AllHackathons
tracwiki: + info about hackathons past and prsent
tracwiki: trac.parrot.org/parrot/wiki/AllHac...ction=diff
shorten dalek's url is at xrl.us/bfqxyv
Whiteknight When does 2.0 come out? 21:25
darbelo one month after 1.9? 21:26
PerlJam Whiteknight: isn't it on the roadmap? 21:28
Whiteknight PerlJam: yeah, but I'm really lazy 21:29
plus, I was hoping somebody would just know the answer off the top of their head :)
PerlJam Whiteknight: oh, the answer is ... it's on the roadmap :)
21:30 nopaste joined 21:40 nopaste joined
Whiteknight really wishes that parrot-dev emails replied to the whole list by default 21:40
allison Whiteknight: January
Coke that'sprobably adjustable.
Whiteknight is really tired of sending a reply to just one person
allison: thanks, but my email already went out without a date in it 21:41
...and it only went to one person
>:(
Coke I don't seem to have this problem, but I use gmail.
Whiteknight I use gmail too
darbelo Some mailers have reply-to-all functionality.
moritz or even reply-to-list 21:42
Whiteknight darbelo: yes, but I never remember to click it
because all the other mailing lists I belong to have reply-to-list as the default
GeJ Good morning everyone 21:44
Whiteknight good morning GeJ 21:45
GeJ Heya Whiteknight
purl i heard Whiteknight was mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
Whiteknight allison: Do I need to fill out a Parrot CLA?
21:46 Zak joined
jrtayloriv I'm trying to figure out how to expand Scheme macros in my compiler. I don't think I can just add another stage and expand them before the 'past' stage, because I need to have access to the lexical environment, since local variables can mask the names of macros. For instance: pastebin.ca/1602550 ... I can create a macro named "replace" and shadow it with a local variable of that name. 21:46
So basically, I'm confused as to how to go about doing this. Can I somehow have a "second grammar" that is specifically for expanding macros? (Does that even make sense?) 21:48
moritz jrtayloriv: not quite... I don't think lisp macros are expanded at text level 21:49
but rather at AST level
jrtayloriv moritz, Right -- that's why I can't do it before past stage -- I need to do it during past 21:50
sorry, I don't know right word for what I am after
purl after is about getting a side effect
allison Whiteknight: yes
jrtayloriv purl forget after
purl jrtayloriv: I forgot after
moritz jrtayloriv: right, durinig PAST stage, not in a new stage (I think)
allison Whiteknight: (that is, yes, you need to fill out a Parrot CLA)
jrtayloriv moritz, But I'm trying to figure out how to check that the define-syntax definition is syntactically correct. 21:51
My grammar.pg just parses source text into s-expressions -- it doesn't deal with keywords like define or define-syntax
Those are defined as variables in the top-level environment 21:52
moritz so you need to post-pone some syntax checks to the PAST level
jrtayloriv moritz, Yes, that's what I'm asking how to do. Are there any code examples I can look at for this?
moritz looks at the rakudo sources 21:53
21:53 mokurai left
Whiteknight jrtayloriv: expand them at runtime 21:54
call back into your compiler object to compile them at runtime with the dynamic executing environment
moritz is that how lisp macros are supposed to work? 21:55
jrtayloriv moritz, (you asking about the example I posted?) Scheme macros are different from Lisp macros
moritz I didn't see the example you posted
jrtayloriv moritz, Oh, sorry -- yes, they should be expanded at run time -- local vars can shadow the names of macros. 21:56
moritz then forget everything I said ;-) 21:57
jrtayloriv Really? Then I was totally on the wrong track -- I thought you were saying that ... /me is confused 21:58
Whiteknight, Did you mean expand them during 'eval' stage? 21:59
21:59 mokurai joined 22:00 nopaste joined
jrtayloriv The problem is that I need to expand them and then generate the past for the expressions that they expand to. 22:00
allison dukeleto: around?
Whiteknight jrtayloriv: yeah, I think a runtime eval would be best for those 22:01
moritz jrtayloriv: so you want to separate the text->s-exprs and the s-expr->PAST stages?
Whiteknight I don't know Scheme, so ignore most of what I say
moritz and that's why you want a new stage?
makes some kind of sense :-)
dukeleto allison: howdy 22:03
purl hi, dukeleto.
allison dukeleto: I've just committed the hack I mentioned yesterday
dukeleto: you can now go ahead with test develoment on the pcc_reapply branch
dukeleto: we'll fully switchover to the new return handling when it passes the tests 22:04
22:04 Zak joined
dalek rrot: r41754 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Keep the old code in place for testing development, while we finalize the
 22:04
allison dukeleto: (but this way Tene and I can collaborate on the return handling at the same time)
jrtayloriv moritz, I'm not clear on the terminology, so bear with me ... the text->s-expr and s-expr->past stages are two different things. text->sexpr is where I take the text and break it up into either lists or literals, which have no meaning yet ... then when I do sexpr->past is when I say things like "the first element of this list is the symbol 'define' which is currently mapped to a builtin primitive, so build the past for that" ... 22:05
Whiteknight I haven't seen any commits on the return handling stuff lately
dukeleto allison: thanks, that is awesome 22:06
Whiteknight anything joe schmoe code monkey can do to help?
dukeleto allison++
Whiteknight that is, joe schmoe code monkey who doesn't know how returns work?
moritz jrtayloriv: right
allison Whiteknight: a code review on fill_results
dukeleto Whiteknight: write CallSignature tests
Whiteknight allison: On it!
allison Whiteknight: that's what I've been doing, fixing logic errors a few at a time
moritz but the default for a HLLCompiler is to translate directly from text to PAST 22:07
22:07 nopaste joined
moritz and that's what you're trying to change, right? 22:07
jrtayloriv yes
moritz ok
jrtayloriv (i think -- I'm not quite clear on it yet)
allison Whiteknight: the basic idea is that it's the same as the algorithm we worked out for fill_params, except that we're looping over the results array and the returns flags, instead of the args array and params flags
jrtayloriv I'm trying to get help getting clear on it ;) 22:08
moritz so I know what you want, and why you want it
just not how to do it :/
jrtayloriv I've been unable to find any examples or docs that come close to what I'm trying to do, but I'm fairly certain that it's the right way to go about it. 22:09
allison Whiteknight: named returns are going to need slightly different logic, though. It might be worth another pseudocode round
jrtayloriv Just about everything I've read on Scheme compilers/interpreters is saying this is how it should be done
moritz jrtayloriv: did you try perldoc compilers/pct/src/PCT/HLLCompiler.pir yet?
jrtayloriv s/perldoc/less/ and yes
moritz so 22:10
you need to add a stage after parseactions, I suppose 22:11
jrtayloriv OK I know how to add a stage, I think, I just don't know what my stage should do exactly, and what it would be operating on. That's what I was originally going to do, but then I convinced myself that I should somehow try to do it during past ...
Perhaps it's time for some more headscratching time for me.
moritz I think you should it organize like this: 22:12
jrtayloriv I had parse->expand_syntax->past
moritz in the parseactions phase you just reduce the match objects to lists of lists
and then in the new stage you do lists of lists -> past
but I'm currently at loss about the details too 22:13
jrtayloriv My original idea was to somehow make the second stage look like "lists of lists -> expanded lists of lists" 22:14
and then in past stage do "expanded lists -> past"
But like I said, I think I just need to stare at it longer, because I'm not even sure if what I'm saying right now is any more meaningful than "bdj9335kdkf" 22:15
moritz that's compile time macro expansion
if that's what your language specs, that's fine 22:16
jrtayloriv moritz, Thanks for the help -- I'm off to read more about exactly when the expansion happens, so I can come back with clearer question. 22:18
moritz jrtayloriv: you're welcome. I hope somebody more competent can answer then ;-) 22:19
22:20 nopaste joined
Whiteknight allison: prior to last weekend, I haven't pseudocoded since undergrad 22:22
so I'm happy to flex that muscle a little more :)
22:23 patspam joined
darbelo pseudocodes in C 22:24
Whiteknight darbelo: Normally I call all my pseudocode "perl" 22:27
and the best part is that it runs!
darbelo Whiteknight: What's the prize on your frame-builder contest? 22:28
s/prize/no-prize/g 22:29
Whiteknight darbelo: free Parrot T-Shirt
22:30 nopaste joined
darbelo I'm looking at DynASM now, ant it loks pretty easy to hack one up. 22:30
Does it have to work post pcc_realply or is current trunk ok? 22:31
Whiteknight DynASM? 22:32
darbelo Part of the lua jit.
luajit.org/dynasm.html 22:34
Whiteknight ah yes, okay 22:35
(so many JIT engines, so little brain space)
darbelo it's x86-only, which sucks. But if there's a free T-Shirt, I'm all for it ;) 22:37
Whiteknight that's the attitude!
darbelo That's how I got into SoC ;) 22:38
22:38 TonyC joined
moritz hey, I also got a free t-shirt from SoC this year, and I was only a backup mentor 22:38
darbelo That's why I got my commit bit. So I can get the shirt without having to code next year ;) 22:39
Whiteknight moritz: me too. Thanks Darbelo!
dukeleto lulz. people go crazy over those shirts
Whiteknight I don't think I have paid for a new tshirt in about 10 years. People keep giving them to me for free 22:40
22:40 nopaste joined
moritz I did mentor a student last year, though 22:40
darbelo Whiteknight: Same here, except I just keep wearing the old ones.
;)
moritz dukeleto: actually of all the geek t-shirts I own, people most often ask me about the SoC ones 22:41
"did you really participate, or did you get that from somewhere else?"
darbelo "Nah, I stole it from some dude's laundry basket." 22:42
22:42 jsut_ joined
moritz or people expect that I bought it from ebay or so 22:42
dukeleto moritz: that is funny. just say that you do LH's laundry :)
Whiteknight I don't understand how anything could work if we turned off argment checking exceptions in Parrot
moritz ;-)
Whiteknight I suspect there would be segfaults everywhere, for every violation 22:43
I can't think of a single benefit
moritz my girlfriend works for Puma, I don't need to buy any t-shirts at all ;-)
Whiteknight moritz: lucy! 22:44
lucky!
moritz aye
Whiteknight I mean, we have :optional and :slurpy parameters, I don't know why we would also need to implicitly pass the wrong number of parameters without warning 22:45
moritz for enhanced confusion mode on April 1st
22:50 nopaste joined
dalek rrot: r41755 | mikehh++ | branches/pcc_reapply/src/call/args.c:
fix codetest failures - trailing spaces, line length and for( to for (
 22:53
23:00 nopaste joined 23:01 nopaste joined 23:03 jsut joined 23:05 payload joined
dalek rrot: r41756 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
[pcc] remove XXX note, we don't need to worry about :flat here
 23:09
23:10 nopaste joined
Whiteknight is going to be so happy when it's time to unify args and returns 23:11
darbelo February?
purl i guess February is not the best month to visit Mtl. A bit cold, you know...
cotto_work RSN 23:12
darbelo Hmm. We should start taking notes of what we want to deprecate for the January release. 23:13
I have "In place string modification." on my kill-list. 23:14
23:16 Zak joined
cotto_work string mutability? 23:17
darbelo The opposite, I want inmutable strings.
cotto_work right. You want to kill string mutability.
darbelo Yes. 23:18
Some of the work is already done for COW, but there's still a lot of copying arround "Just in case it's modified by someone else." 23:19
23:20 nopaste joined
darbelo It's likely to speed us up. 23:20
Whiteknight immutable strings would probably be a performance win
but making it work with our current memory management scheme is going to be a headache
of course, our current string manager is a headache already, so no change 23:21
darbelo Whiteknight: Making it *attemptable* requires a pretty big deprecation notice in 2.0
Whiteknight of course, that's a bit of semantic change for us, so you want to make sure that's cool with allison et al first 23:22
23:26 TonyC joined 23:30 nopaste joined 23:33 TonyC joined 23:35 TonyC joined 23:36 TonyC joined 23:40 nopaste joined
dalek rrot: r41757 | mikehh++ | trunk (3 files):
clear up some compiler warnings from r41602
 23:42
mikehh messages 23:46
cotto_work massages 23:47
purl You have no massages waiting.
mikehh pity - I could do with one :-} 23:48
cotto_work from purl?
mikehh if she is a good girl :-}
purl thanks mikehh :)
darbelo purl: are you a good girl? 23:49
purl :)
mikehh darbelo: done anything on decimal_dynpmcs recently - you mentioned quad I think? 23:53
darbelo ENOTUITS
But I can probably finish that this week. 23:54
mikehh have to try and send you some :-}
you moved it into plumage? 23:56
darbelo First project to correctly complete the fetch-build-test-install cycle :) 23:57
japhb mikehh, well, plumage can happily install it, but of course it remains in a separate repo ....
23:57 kid51 joined 23:58 chromatic joined
Whiteknight allison: ping 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!