Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge
Set by moderator on 23 October 2009.
00:01 darbelo joined
pmichaud_ so, the only piece I'm missing is how to specify a type as that last argument 00:01
chromatic bacek, the only thing I could find that uses get_string there was the MMD tuple creation in CallSig's own get_pmc.
pmichaud_ and perhaps that just argues that we really want the last argument to be a type more than an object to be cloned
japhb pmichaud_, and there I've got nothing yet. Brain still too fuzzy
pmichaud_ I like the potential power of "object to be cloned", but the common case is "create a new object of this type" 00:02
bacek chromatic: indeed. Let me finish testing and I'll commit lazy string_sig creation
chromatic: and then we can fix MMD to use raw arguments instead
pmichaud_ and typical code generation really wants that "new object of this type" to be specified as a constant somehow. 00:03
darbelo Whiteknight: pong
chromatic bacek, the only thing I don't see this doing is marking named arguments by appending 'n' in the signature.
Austin So you're back to specifying the hll-mapped role you want to request? 00:04
japhb pmichaud_, the only two ideas I have in that direction are: 1. double the ops again. Ew. 2. Have the default arg be a thunk to be called to get the default. Whether that's a win depends on how often code in the wild needs to use the default.
bacek chromatic: it's not required for MMD.
00:04 zak_ joined
Whiteknight darbelo: I'm starting to prototype the 2D matrix PMC. I'm trying to figure out a good way to do indexing 00:04
pmichaud_ Austin: actually, I'm looking at $P0 = vivify_lex '%foo', ['Hash'] 00:05
and
$P1 = vivify $P0, 'key', ['Undef']
Austin So the HLL can't change its mind about what default type to use?
pmichaud_ no, but I'm not sure that's all that important. The "change its mind part" was more along the lines of one HLL being able to signal to another HLL what type to use 00:06
Austin Ah
pmichaud_ for example, a library running in the 'parrot' namespace being able to create objects for callers coming from the 'mylang' hll namespace
Austin When you mentioned that before, the little man in my head that pulls all the levers just said "forget this," an quit. (It's been muscle memory only for the last half hour or so) 00:07
pmichaud_ Both P6object and PCT run into issues like this, because they provide methods that are often called from other hll namespaces, and we want those methods to be able to act as if they were in the foreign hll namespace. 00:08
so, when something from a toolkit creates an "integer", it ends up creating an integer that is correctly mapped according to its HLL caller type.
If the vivification type is hard-coded into the PIR, there's less opportunity for that to occur.
Austin So fetch is: fetch Pagg, Pkey, Pdfltkey ? 00:09
darbelo Whiteknight: Have you considered using keyed access with a FIA?
pmichaud_ maybe.
bacek purl: (6518415064 - 5795672288) / 6518415064 * 100
purl 11.0877071942162
bacek 11%!!!
Austin 1/9th
pmichaud_ as I said, I really like the clone semantics, I just can't figure out how to get the common "make me an object of this type" semantics, short of creating a new one of those objects at the beginning of each sub, or doing a set of lookups at the beginning of each sub 00:10
Austin bacek: What did you do?
Whiteknight darbelo: I was thinking of something very similar to that
bacek chromatic: you was wrong. It's 11%, not 5-6 :)
Austin: drop creating stirng_sig in PCC
Austin bacek: congrats
pmichaud_ in some sense I guess the "set of lookups" at the beginning of each sub feels like the best way to go, but I'm not sure I like it. 00:11
japhb pmichaud_, this may sound a little odd, but how about having the last arg be a label?
Austin pmichaud_: How could a local library know the type to create using fetch?
japhb That way we only do the lookups and default when needed? 00:12
or, instead of a label,
have a pre-op that sets the label to use to default, like setting an exception handler
chromatic I don't mind underestimating this way.
pmichaud_ Austin: I must be getting tired -- I didn't follow your question. 00:13
Austin japhb: I don't get it. An example?
pmichaud_ japhb: label -- interested.
*interesting.
japhb OK, still fighting through the fuzz here,
Austin pmichaud_: In the case where hll A calls B, how could B provide an A-centric type via fetch?
Whiteknight darbelo, dukeleto: I just pushed a prototype of the PMC. bare bones. check it out
darbelo Whiteknight: I've been thinking about this and the way I see it being the most efficient is to keep the PMC's data in 'cblas-native' format, with as little conversion as possible in inter-PMC operations.
pmichaud_ Austin: B can find out the hll of its caller
darbelo Whiteknight: Ohh. I'll ckeck it out.
japhb but something like:
pmichaud_ then B can find out A's hll_mapping 00:14
Whiteknight darbelo: the way we do storage isn't as important right now as the way we do indexing
japhb push_def_handler default_array
pmichaud_ then B can choose/create a fetch argument that is consistent with that mapping
Whiteknight but you're right, CBLAS internal format would be nice
japhb fetch aggregate, key
...
default_array:
pmichaud_ japhb: here's an examle
japhb afk for just a sec, damn
pmichaud_ actually, japhb, now that I'm looking at it, I think that using a label is basically what PAST does now. 00:15
we just avoid the "if null" check.
Austin pmichaud_: That argues that fetch should take a pmc or a type name, instead of a role sentinel.
pmichaud_ Austin: I've been wanting to have role sentinels in addition to pmcs
to avoid having to always look up the pmc
(I don't have a good way to do it, which is why I'm falling back to "okay, let's just eat the cost of looking up the pmc")
darbelo Whiteknight: Yeah, maily I was thinking of Complex there, FLOATVAL is just a double. 00:16
pmichaud_ actually, I think I know what I want to do here.
first, all of this discussion has been *incredibly* useful.
Whiteknight darbelo: yes, I think we are going to have to have multiple PMC types
japhb Oh, duh! I think I see a solution!
pmichaud_ waits for japhb's solution.
Austin disbelieves. 00:17
japhb fetch aggregate, key, label_for_SUCCESS
pmichaud_ disbelieves also, but hopes.
japhb do_default
label_for_success:
pmichaud_ japhb: that's what PAST does now.
japhb pmichaud_, yep.
pmichaud_ so no advantage to what we have now. :-)
dalek rrot: r42057 | bacek++ | trunk/src (2 files):
Stop building string_sig in build_sig_object functions.

fib.pir
japhb no null check.
Austin 2->1 ops
japhb but OK, fine, genius is fleeting. ;-) 00:18
pmichaud_ there's still a null check, it's just being done inside of the fetch opcode instead of separately
japhb pmichaud_, your idea was?
pmichaud_ I don't think the null check provides that much benefit
japhb pmichaud_, yes, understood.
dalek rrot-linear-algebra: 58cb4dc | Whiteknight++ | src/pmc/NumMatrix2D.pmc (2 files):
add a prototype of a 2D matrix PMC for proof-of-concept
japhb sigh
pmichaud_ actually, in the vivify case the label form avoids a null-check and a bind
but still, not a huge benefit
darbelo Whiteknight: You are going for 'allocate storage on assignement' there, right?
pmichaud_ my idea is summed up in one word: "wait" 00:19
a lot of this discussion is predicated on the code that NQP produces now
japhb blinks
Whiteknight darbelo: I haven't thought about allocation yet
Austin has never been good at waiting.
pmichaud_ but NQP produces code that is based on older ideas about how Perl 6 would work
and a lot of those ideas are no longer valid
I'm thinking about the fetch and vivify opcodes at the moment, and I'm guessing that NQP likely won't need them anyway
Whiteknight Matrixy requires resizable matrices, but allows for preallocation as an optimization
pmichaud_ other languages might be able to use them, but NQP won't
Whiteknight so if matrices were fixed-size, we could implement a relatively fast copy 00:20
Austin 8-O
pmichaud_ so perhaps the thing to do is to wait and see what NQP-rx develops, and look at the code it generates
Austin I'll bite. Why won't nqp use them?
pmichaud_ it would use them, but only for aggregate and package lookups 00:21
Austin Sure.
pmichaud_ and I think we'll find that's a much smaller percentage than the example that you were looking at
where every lexical fetch was generating 4+ opcodes
in the future, NQP lexical fetches will be one opcode
(find_lex)
Austin My example combined two things: lexical fetches and (package/aggregate) fetches.
pmichaud_ looks at the example again
the example in the ticket only showed lexical 00:22
00:22 kj joined
darbelo The two approaches that make sense to me are: The default init() can allocate a 'big enough for most uses' buffer, that we grow as needed. Or, init() leaves the thing empty, and we allocate storage on first assignement, when we know how big the thing will be. 00:23
pmichaud_ oh, in the ticket it also says 00:24
Austin pmichaud_: True. But the "load, unless_null $Px, vivify_, default, vivify_YY:" pattern is the same for lexical loads and aggregates.
pmichaud_ "we expect about a 2-3% reduction is pbc size (pir lines != opcode words) and a corresponding 2-3% increase in execution speed. "
Austin So my grep caught them both.
darbelo I can argue it both ways, but it'll depend on what our typical use case will be.
pmichaud_ my question is how many of those patterns were lexical lookups
anyway, with
Austin Right. That I didn't count.
pmichaud_ "we expect about a 2-3% reduction is pbc size (pir lines != opcode words) and a corresponding 2-3% increase in execution speed. "
purl i already had it that way, pmichaud_.
Whiteknight darbelo: I like the second idea. I think they should start empty, and then become fixed-size on assign
pmichaud_ ...why would a 2-3% reduction in pbc size result in a 2-3% increase in execution speed? That doesn't follow from my experience. 00:25
ttbot Parrot trunk/ r42057 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/120439.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
chromatic My guess is that the execution improvement will be about half of the size improvement. 00:26
pmichaud_ I'm guessing even less.
when I moved CodeString and Capture from being written in PIR to being written in C (essentially combining multiple operations into a single C method), I didn't get near that level of performance increase 00:27
darbelo Whiteknight: How does matrixy handle it's matrices now? Does it reuse storage on any operations?
Austin The size estimates were based on the original proposed 'vivify' op, which is now defunct.
Whiteknight darbelo: right now it uses nested RPAs, and allows resizing 00:28
pmichaud_ Austin: sure, size might be reduced by 2-3%, but there's no corresponding performance increase
Whiteknight in-place resizing
chromatic CodeString suffers from its use of METHOD.
kj good evening
purl Ah, evening. The tumultuous mind tarries and contemplates, reveling in the silence afforded by the diurnal proletariat. Good evening, indeed.
pmichaud_ chromatic: I think that's a bit of a wash (but could be wrong)
at any rate, we took what were several dozen opcodes and put them into C
bacek purl: (8505314725 - 5795672288) /8505314725 * 100 00:29
chromatic and cross the C/PIR boundary, which is never fast.
purl 31.8582265866711
pmichaud_ is the C/PIR boundary that much more expensive than a PIR-PIR call?
chromatic Oh yes.
pmichaud_ interesting.
Austin pmichaud_: The library has grown slightly. It now has 1411 occurrences of "find_lex" and 1415 of ", vivify_".
bacek speaking of speed: fib.pir is 31% faster now comparing to post pcc merge :)
Austin Suggesting there are 4 places where aggregates are accessed.
pmichaud_ Austin: right 00:30
chromatic bacek, we have another 19% to go then.
pmichaud_ so in the new NQP, you would end up with 1411 occurrences of find lex and 4 occurrences of vivify
bacek chromatic: it will tough...
Austin Won't you be vivifying parameters?
pmichaud_ which makes me think I'm essentially correct that lexical lookups swamp all other forms
parameters are already vivified, by definition
i.e., they come in as arguments supplied by the caller 00:31
Austin foo(My::symbol::name)
It's how I create nulls.
pmichaud_ My::symbol::name takes care of the vivification before calling foo
Whiteknight oi! This is such a pain. We have so many places where we really need access to two integers: size, resize, index/get, index/set, etc
and the VTABLE interface is basically useless for it 00:32
Austin I just use a symbol name that doesn't exist, and the lookup returns null.
darbelo Whiteknight: It rezises the R(RPA)A on *shrinking* matrices?
pmichaud_ that will likely change in the new NQP
bacek chromatic: can we reuse Sub's RetContinuation?
Whiteknight darbelo: No, not yet anyway
Austin Man, you mean my is_null function will become useless?
:(
Whiteknight Matrixy has a really bad implementation, that's why I'm rewriting it
Austin All that work, for naught.
chromatic bacek, manual recycling?
pmichaud_ it will become much better
my $foo := PIR::null
bacek chromatic: caching inside Sub and reusing 00:33
pmichaud_ (which will execute the null opcode and bind $foo to the result)
bacek chromatic: it's about 35% of all time spent in fib.pir
chromatic I see that.
I don't think we can recycle that so easily. Our subs are re-entrant.
darbelo Whiteknight: Oh, I was just checking for behaviur we might want to preserve.
pmichaud_ anyway, I figure that if you pass NULL as an argument to a subroutine, you have a reason for wanting it to be NULL and NQP shouldn't be vivifying it for you. 00:34
Austin :)
FWIW, those four places where the aggregate accesses occur get run a whole lot.
pmichaud_ sure, but I don't think we're saving much in terms of execution speed there
bacek chromatic: what about using TLS for it? 00:35
chromatic TLS?
purl TLS is Transport Layer Security or the Times Literary Supplement or the latest version of SSL (3.1 or something like that) or Thread Local Storage or at en.wikipedia.org/wiki/Transport_Layer_Security or required for XMPP
Whiteknight darbelo: we need a function to copy the buffer from one size to another (bigger or smaller)
and with that, we can resize pretty easily
pmichaud_ either the elements exist, in which case we branch, or they don't exist, in which case we create a new object. That's the same in all the scenarios we've posited.
bacek chromatic: Thread Local Storage
Austin I'm thinking that my code might be deficient in aggregate accesses, because I've gone out of my way to put everything together as method calls.
chromatic I'd rather explore merging Context and RetCont.
Whiteknight chromatic: true! 00:36
pmichaud_ it's only a question of whether the branch is occurring in PIR or if it's occurring inside of an opcode
darbelo Whiteknight: We could, with some extra bookkeeping, avoid the shrink operation and save on memory allocation.
pmichaud_ i.e., I'd think that fetch/vivify are really only improving our .pbc size, not really increasing code speed 00:37
dalek TT #1141 created by kjs++: Parrot API changes breaks PIRC
pmichaud_ we're just saving the cost of opcode dispatch; I'm not sure how much that is.
Whiteknight darbelo: agreed. I'm storing x/y sizes, so we can shrink those bounds without reallocating the underlying storage
Austin I think that's what everyone else is agonizing over right now :)
pmichaud_ ?
"everyone else"? 00:38
you mean the pcc cost? that's subroutine dispatch, not opcode dispatch
Austin Ah.
pmichaud_ that's the cost of the invoke opcode, not the cost of opcodes in general :-)
bacek chromatic: interesting... We have 1M calls to Parrot_allocate_context and 1M calls to new_ret_continuation. Allocate context is heavier than new_ret_continuation. But context takes ~7% vs 35% for continuation. 00:39
pmichaud_ the fact that fixing invoke to be faster results in double-digit performance improvements just indicates how much of parrot execution is being swamped by the cost of subroutine dispatch :-)
bacek chromatic: something is terribly wrong here...
chromatic I'm sure that varies depending on PObj allocation.
darbelo Whiteknight: And (for cblas, at leat) we can take advantage of the 'Row-Major'/'Column-Major' C/FORTRAN thing to avoid most transposing.
chromatic It just so happens that in this particular order, the GC runs more often for pmc_new with RetCont than pmc_new with Context. 00:40
Whiteknight darbelo: ATLAS supports flags for rowmajor/colmajor operations
Austin Anyway, back on topic: You're saying that fetch is essentially only needed for aggregate accesses, since PCT will be smarter about lexicals. What about vivify?
pmichaud_ since NQP will be smarter about lexicals.
bacek chromatic: sounds reasonable...
pmichaud_ NQP will be able to assume that lexicals are vivified upon declaration. 00:41
darbelo That makes the MATLAB a' operation trivially cheap.
pmichaud_ there is no other vivification for lexicals.
vivification for aggregates would still be the same as now
darbelo And, from what little MATLAB I remember ' was used fairly heavily.
pmichaud_ i.e., fetch the element, branch unless null, build a new element, bind in the aggregate 00:42
Whiteknight darbelo: so the question is this: do we want to resize dynamically (grow when accessed but never shrink) or do we want to specify a fixed size ahead of time
I'm thinking now that dynamic resizing might be best
darbelo Whiteknight: I agree.
pmichaud_ the only significant difference between "fetch" and "vivify" is that vivify also does a bind
Austin Sure. 00:43
So when will nqprx land?
pmichaud_ (which should answer chromatic's question about how to implement the vivify opcode, should we decide we want to do that)
Whiteknight darbelo: Okay, I'm going to throw together a prototype of that
pmichaud_ I'll have variables done this weekend.
Whiteknight we can modify it later
bacek chromatic: nope. gc_ms_more_traceble_objects called only ~4000 times.
chromatic pmichaud_, does this obviate the experimental fetch opcode?
pmichaud_ chromatic: for the moment, it seems yes.
I need to think about it a bit more.
darbelo I won't have many tuits over the weekend, but I'll most assuredly be all over that on monday. 00:44
pmichaud_ I really like the idea of having opcode support for lvalue versus rvalue semantics, because I agree that the code we generate from PAST for it looks really ugly and inefficient
Whiteknight darbelo: that way we can do resizing (at a cost), and we can support preallocating which will be cheaper 00:45
pmichaud_ adding fetch/vivify makes the code look less ugly, but it's not significantly more efficient.
chromatic We could benchmark it.
00:45 zak_ joined
pmichaud_ I wouldn't rip out the experimental ops just yet, no. 00:46
benchmarking it would be good -- I could put together a quick benchmark fairly quickly.
chromatic If you have callgrind installed, that's the way to check performance.
pmichaud_ I do, and yes, it is.
dalek rrot: r42058 | chromatic++ | trunk/src/pmc/retcontinuation.pmc:
[PMC] Enabled (experimental) recycling of RetContinuation PMC when it gets

RetCont PMC will merge with Context soon, but until then, this is a nice improvement that's easy to revert if it causes problems.		 00:47
pmichaud_ the _other_ optimization I've been considering is to make PAST smarter about knowing when it needs to re-fetch a lexical in the first place
for example, right now we fetch a lexical on every use 00:48
thus:
my $b := $a + $a * 3
darbelo Ok, gotta go now.
pmichaud_ does two fetches of $a, along with creating (separate) temporaries for each if it hasn't already been vivified somehow
but if PAST can analyze the code path to determine that the second $a has to be the same thing as the first, then it can re-use the register it got from the first fetch 00:49
instead of doing a re-fetch
of course, we have to have some way for the compiler to signal "hey, it's possible for re-binds to take place here", so that it doesn't perform that optimization. 00:50
dalek TT #1141 closed by kjs++: Parrot API changes breaks PIRC
Coke msg bacek fperradmsg bacek, I isolate a problem with r42039, see nopaste.snit.ch/18440
purl Message for bacek stored.
ttbot Parrot trunk/ r42058 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120490.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ the other optimization I'm really looking for is to be able to determine when a block can be inlined instead of generating a separate parrot sub 00:51
bacek Coke: too late. I already fixed it :)
pmichaud_ for example:
if $b > 3 { say($b); }
doesn't really require a separate parrot sub for the block
right now it doesn't check for the case of "no new lexicals here, okay to inline" 00:52
(or other reasons why a block might not be safe to inline)
dalek rrot: r42059 | kjs++ | trunk/compilers/pirc/src/bcgen.c:
[pirc] fix some Parrot API invocations, particularly passing STRINGs instead of C strings
 00:53
ttbot Parrot trunk/ r42059 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120509.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 00:55
pmichaud_ afk for a while
dalek rrot: r42060 | kjs++ | trunk/compilers/pirc/src/pirop.c:
[pirc] 'fix' op-signature calculator for stand-alone key operands, as in 'new Packfile?'
 00:56
00:58 Zak joined
pmichaud_ chromatic: in fetch/vivify, how hard would it be for the last parameter to be a type instead of an object to be cloned? 00:59
i.e.:
ttbot Parrot trunk/ r42060 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120540.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 01:00
pmichaud_ $P0 = fetch $P1, 'key', ['Hash']
chromatic That's easy.
pmichaud_ I might want that.
I'm thinking that the aggregate cases are sufficient to warrant fetch/vivify
chromatic In addition to or instead of what's there now?
pmichaud_ I was thinking it would need to be "instead of"
if "in addition" is possible, what's the downside? 01:01
kthakore hello folks is there a place of nightly Rakudo/Parrot tarballs?
pmichaud_ kthakore: there aren't nightly tarballs for rakudo, but you can always get a tarball from github
chromatic The downside is more op variants, but they're easy to create.
pmichaud_ we can distinguish a constant ['Foo'] from other PMCs? 01:02
chromatic Yes, that's a Key.
pmichaud_ there's been some speculation it might not be a Key someday
still workable?
kthakore pmichaud_: ok. thanks
pmichaud_ kthakore: just go to rakudo's github page, click the "download" button, and you can get a current tarball or zip 01:03
chromatic If it's constant at compile time, that's reasonably easy.
I might have to experiment some though.
pmichaud_ chromatic: okay, good to know.
For now I think I want "instead of" 01:04
someday I might want "in addition to", but that can be off in the nebulous future
so
chromatic Instead of is easy.
pmichaud_ fetch $P0, $P1, key, ['Foo']
vivify $P0, $P1, key, ['Foo']
dalek rrot-linear-algebra: 2d8fbeb | Whiteknight++ | src/pmc/NumMatrix2D.pmc (2 files):
expand the matrix pmc a little bit. Add a resize function. Resizing is inefficient, so there is motivation to preallocate
pmichaud_ fetches $P1[key] into $P0, and if it doesn't exist it creates a new instance of ['Foo'] and returns that 01:05
in the vivify opcode case, creating a new instance of ['Foo'] also does a set_pmc_keyed on $P1[key] for the newly created object
kthakore pmichaud_: I am justing going to cron git pull and tar it myself :) Thanks
pmichaud_ kthakore: that works, although you'd also want to skip the .git directories. 01:06
chromatic pmichaud_, if you give me a patch to t/op/fetch.t, I can make the other work.
kthakore pmichaud_: oh crap ... yeah ... thanks
pmichaud_ chromatic: okay, I'll send along a patch. Might be a few hours before I can do that -- have other things I have to do here now.
chromatic Ditto.
pmichaud_ there's no rush on fetch/vivify for me at the moment, I won't get to using them in PAST/NQP until Sunday at the earliest. 01:07
PerlJam kthakore: git help archive
pmichaud_ but I think having them will make code gen a lot cleaner, and that's likely worthwhile on its own.
if nothing else, it keeps people from looking at it and going "Ewwww...." 01:08
okay, gotta run. Thanks.
kthakore PerlJam: that saves time thanks 01:10
Whiteknight okay, now I just need to figure out how build this damn PMC
dalek rrot-linear-algebra: 8c86b73 | Whiteknight++ | src/pmc/NumMatrix2D.pmc (2 files):
add resize function (thought I already did) and fix the exception that gets thrown
Coke seen kid51? 01:14
purl kid51 was last seen on #parrot 23 hours, 43 minutes and 36 seconds ago, saying: must sleep
Coke bacek: you added a file but didn't update the manifest. 01:16
this tends to break the build. :P
bacek Coke: *sigh* 01:17
chromatic Oh, MANIFEST... I've loved you since I was a child. They're always trying to take you away from me. Why? Because you're busy work... and they have... the SPACE! MADNESS! 01:19
01:20 tokuhirom joined
Whiteknight don't even say nice things about MANIFEST in jest 01:23
chromatic I wasn't aware that proximity to original Ren and Stimpy scripts could reflect well on MANIFEST.
Whiteknight ah, that's where it was from 01:24
knew it sounded a little familiar
I haven't seen Ren and Stimpy in years
chromatic You were in for serious mockery if you didn't recognize even the name "Ren and Stimpy". 01:25
dalek rrot-linear-algebra: 6ecabdb | Whiteknight++ | src/pmc/NumMatrix2D.pmc (2 files):
actually pretend to do the resizing function correctly
 01:28
Whiteknight I spent more of my formative years in front of Ren and Stimpy than the guidance councelor thought was healthy
chromatic Watching the first season in its entirety is unhealthy. 01:29
Whiteknight powedered toast man, rubber nipples, anthropomorphic mud skippers, etc. they all ruined me
jsut don't pee on the electric fence 01:30
Whiteknight "what do you want to drink?" "MEAT!" 01:31
"no sir, I don't like it"
dalek rrot: r42061 | bacek++ | trunk/src/pmc/callsignaturereturns.pmc:
[core][cage] Add CallSignatureReturns.destroy.
 01:33
rrot: r42062 | bacek++ | trunk (2 files):
Use FixedSizeStorage in CallSignatureReturns for small amount of returns. Give us another ~1.5% of performance
rrot: r42063 | bacek++ | trunk/MANIFEST:
[cage] Add callsignaturereturns.t into MANIFEST. Coke++, MANIFEST--
rrot-linear-algebra: ab6446f | Whiteknight++ | src/pmc/NumMatrix2D.pmc (2 files):
fix a stupid typo
 01:34
Whiteknight yay! the fixed-size allocator swoops in to save the say again!
bacek oookey... I can't spot any other big improvements without merging CallSignature and Context (and probably RetContinuation)
Whiteknight it's like the Zorro of performance
Austin sings "When nature's callin', don't be stallin' - use your common sense! Take it slow, find a place to go, but DON'T whiz on the electric fence!" 01:36
ttbot Parrot trunk/ r42061 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120603.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Parrot trunk/ r42063 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120605.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Austin The opcode 'time' returns a Num, but is that in seconds, or what?
01:37 mikehh joined, Zak joined
chromatic bacek, how are we versus when we started? 01:40
Coke Austin: that eventually just invokes system time() 01:41
Austin Ah.
bacek chromatic: almost same as 2 hours ago - ~32% faster comparing to pcc merge.
Coke Austin: (presuming I read that right. I may not)
Austin :)
bacek chromatic: I can retest it
chromatic Did you see my ~5% improvement? 01:42
Whiteknight I'll show you my 5% improvement
Coke svn latest just segfaulted building PGE on osx 10.4/intel.
re-testing...
is there a better way to see if $N1 is a NaN other than stringifying? 01:44
bacek chromatic: oops, missed it.
Whiteknight Coke: I feel like we should have an isnan opcode 01:45
plobsing isn't NaN the only number where $N1 != $N1
?
Coke Whiteknight: I would tend to agree. esp since I have to do the stringify check a lot. 01:46
(hurm. segfault is not repeatable.) 01:47
dalek rtcl: d04804f | coke++ | src/mathops.pir:
Improve usage errors and nan handling for several procs in ::tcl::mathop
Austin Okay, I've found a bug someplace. 01:49
Or spectacularly bad gc performance. 01:50
nopaste "bacek" at 114.73.162.96 pasted "Performance tests:" (11 lines) at nopaste.snit.ch/18442 01:54
bacek purl: (8505247882 - 5372280006)/8505247882*100 01:55
purl 36.8357033147785
bacek purl: (6958440380 - 4637738821) / 6958440380 * 100 01:56
purl 33.3508865818579
bacek chromatic: 36% with GC involved, 33% without.
Austin Wow. My problem seems to be a pir compiler problem. :( 01:58
bacek 3519952820 at 1.4 on fast core... 02:04
(5372280006 - 3519952820) / 3519952820 * 100 02:05
purl 52.6236367565858
bacek *sigh*
We are doing something wrong...
chromatic: r42058 epically broke TapTinder. 02:07
dalek rtcl: 77b55f1 | coke++ | docs/spectest_skips:
mathop no longer segfaults.
 02:09
mikehh bacek: and me - /src/pmc/callsignature.pmc:421: error: ISO C90 forbids mixed declarations and code 02:16
02:17 Zak joined 02:36 janus joined 02:39 mikehh joined 02:43 bacek joined
bacek mikehh: thanks for spotting codetest failure. 02:46
dalek rrot: r42064 | bacek++ | trunk/src/pmc/callsignature.pmc:
[cage] Reorganise CallSignature.get_string variable initialisation to prevent compiler warnings.
 02:47
ttbot Parrot trunk/ r42064 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120717.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 02:50
Austin Anyone know if imcc is O(n**2) or something? 02:57
02:57 mikehh_ joined
bacek Austin: it can be even n**n... 02:59
Austin That's optimistic.
I just created a pair of subs with 100,000 x 3-line code paragraphs.
It's taking a while to compile.
bacek Austin: .annotate? 03:00
purl rumour has it .annotate is described in PDD19, but there's some lower-level details in PDD13
Austin Nope.
bacek just plain .sub;noop;.end?
Austin Just some perl that emits $Pxx = find_lex '$what' ; unless_null $Pxx, branch ; $Pxx = new ['Undef'] ; branch over and over and over. 03:01
03:02 mikehh joined
bacek Austin: I suspect register allocator in IMCC 03:03
Austin Yeah, it's been like an hour. 03:04
I think I'll kill that.
10,000 wasn't too bad - maybe 2 minutes or so.
bacek Austin: try always use $P0 03:05
Austin I am always using $P11.
bacek hmmm... So, it's something different. 03:06
nopaste "Austin" at 98.235.55.43 pasted "make_fetches() sub" (18 lines) at nopaste.snit.ch/18443
Austin The vivify_$label is increasing, but everything else is contant. 03:07
There. 10k fetches took 3m4.4s to compile. 03:08
I'll try 11k, see what that says. 03:09
03:09 mikehh joined
dalek tracwiki: v17 | kurahaupo++ | ArrayTasklist 03:12
tracwiki: Add reference to RT#56718</a>; tidy page
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
Austin That takes 3m47s, a difference of 43s. 03:13
purl, 227 / 184.0
purl 1.23369565217391
Austin purl, 1.1 **2 03:14
purl 1.21
Austin purl, 1.2**2
purl 1.44
bacek yay, O(N^2)
Austin purl, 184 * 1.44
purl 264.96
Austin I'm running 12000. We'll see if it takes ~ 4m25s 03:15
SCIENCE!!!
purl science is testable
Austin www.weebls-stuff.com/toons/science/ 03:17
Science, plus epilepsy.
5m17s 03:20
But with flash in the background. :(
4m8s with minimal activity. 03:24
I'm going for N**2
On the number of labels? Or conditionals? 03:25
Or number of opcodes?
purl number of opcodes is not tightly connected to execution speed.
Austin Replacing my matches with 'noop' line-for-line is <1s to compile. Ergo, not on LOC. 03:26
dalek rrot: r42065 | mikehh++ | trunk/compilers/pirc/src (2 files):
fix codetest failures - trailing spaces and linelength
 03:27
ttbot Parrot trunk/ r42065 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120762.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
bacek Austin: labels? 03:29
purl labels are really pretty.
Austin Yeah, I'm working my way towards that.
Putting back a single $P11=find_lex '$foo' followed by 3x noop (12000 times) compiled in 16 s
Putting back $P11 = find_lex, then noop, then $P11 = new ['Undef'], noop compiled in 1m2s 03:30
dalek rrot: r42066 | mikehh++ | trunk/t (2 files):
set svn properties
 03:31
Austin Now I'm making the branch be to a single, constant label at the bottom: unless_null, goto done
ttbot Parrot trunk/ r42066 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120786.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
03:32 mikehh joined
Austin I'm wondering if there's a symbol table that just gets lsearched. 03:32
03:35 colomon joined
Austin It's fun when the test case fails. Embarassing, but fun. 03:36
It's fun when the test case fails. Embarassing, but fun. 03:37
Still compiling the everything-does-goto-done file. 03:38
7m36s
Probably due to other stuff on the system.
dalek rrot: r42067 | mikehh++ | trunk/t/pmc/callsignaturereturns.t:
fix test failure - 2 tests were run
Austin I got rid of the unless_null, and brought back the various labels (now all unreferenced.) 03:39
03:40 JimmyZ joined
ttbot Parrot trunk/ r42067 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120822.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 03:41
dalek rrot: r42068 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
 03:42
Austin 2m51s for that.
03:43 mikehh joined
Austin So creating labels doubles the compilation time, even when they aren't referenced. 03:43
ttbot Parrot trunk/ r42068 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120843.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Austin Creating branches causes some kind of N**M, where M ~ 2, behavior. 03:44
Probably trying to shrink the offsets.
Or dorking around with blocks. 03:45
mikehh Has dalek gone to sleep? 03:55
dalek rrot: r42069 | mikehh++ | trunk/src/ops/experimental.ops:
fix codetest failure - opcode documentation errors
mikehh still missing 4 previous commits 03:57
ttbot Parrot trunk/ r42069 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/120889.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 03:58
mikehh messages
Austin What does "invalid arg type in named portion of args" mean?
Coke mikehh: (sleep) "just for a little while." 04:02
-> (23:57) From Koan, to random: - ['hip','hip'] (it's a hip hip array!) 04:04
*groan*
mikehh I think my connection is a bit wonky 04:13
chromatic Yes, everything with a name (label, register, sub, whatever) goes in the same hash in IMCC. 04:20
Register allocation performs a *linear scan* of that hash. 04:21
Austin Ah.
That explains the N**2 behavior;
chromatic It's technically worse than that, but yes.
I stopped counting at N^2 and realized that fixing that meant rewiring most of IMCC besides the parser (and parts of the parser). 04:22
Austin :)
Well, it does serve to encourage modular design. 04:23
But it makes profiling harder.
mikehh trunk - pre/post-config, smoke (#29353) PASS, fulltest FAIL at r42069 - Ubuntu 9.10 (beta updated) amd64
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
Austin s/profiling/ performance analysis/
mikehh needs a bit of a break 04:50
05:36 tokuhirom joined 06:05 eternaleye joined 06:07 TiMBuS joined 06:15 eternaleye joined 06:36 Zak joined 06:48 fperrad joined
chromatic msg whiteknight Does compact_pool actually do anything useful for us now? 06:50
purl Message for whiteknight stored.
07:00 bacek joined 07:12 desertm4x joined 07:17 desertm4x_ joined 07:42 cotto joined
cotto hi 07:42
and good night
dalek rrot: r42070 | chromatic++ | trunk/src/interp/inter_create.c:
[interp] Fixed a memory leak by freeing the interpreter's gc_sys pointer.
 07:53
rrot: r42071 | chromatic++ | trunk/src/gc (3 files):
[GC] Moved Parrot_gc_free_attributes_from_pool() into src/gc/api.c and made it

modest (1.656%) performance improvement to fib.pir.		 07:54
ttbot Parrot trunk/ r42071 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121006.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 07:55
Parrot trunk/ r42070 darwin-thread-multi-2level make error tt.ro.vutbr.cz/file/cmdout/121010.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 07:58
08:02 Zak joined
chromatic I don't care for that Windows box. 08:03
dalek rrot-linear-algebra: fbb3baf | (Markus Mayr)++ | src/pmc/NumMatrix2D.pmc:
Fixed some minor issues and added the VTABLE function *get_string. I tested this version against parrot and actually used it. Resizing and *get_string work now, but I did not figure out yet, how to use set and get.
 08:24
chromatic Hm, we're within 8% of trunk. 08:33
pre-merge
08:34 colomon joined
chromatic 7.252% 08:35
purl 0.07252
moritz speed wise? 08:52
chromatic Yes. 08:53
6.571% now, by my measure. 08:55
Another clever hack will get us there. 09:00
dalek rrot: r42072 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
[PMC] Used attribute access instead of elements() vtable call where speed is a

Tidied code.		 09:02
rrot: r42073 | chromatic++ | trunk/src/pmc/callsignaturereturns.pmc:
[PMC] Added allocate_initial_values() static function to CallSignatureReturns

This gives another 0.729% speed improvement on fib.pir because this is the most common use of this PMC.
chromatic --runcore=fast on the command line gives us another 2.119% improvement.
ttbot Parrot trunk/ r42073 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121116.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 09:05
Parrot trunk/ r42072 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/121133.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 09:09
mikehh trunk - pre/post-config, smoke (#29356) PASS, fulltest FAIL at r42073 - Ubuntu 9.10 (beta updated) amd64 09:36
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
mikehh gotta go to the store - bbl 09:38
dalek rrot: r42074 | chromatic++ | trunk/src/gc/api.c:
[GC] Deleted apparent vestigial setting of PObj_is_special_flag in
ttbot Parrot trunk/ r42074 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121229.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 09:40
09:44 iblechbot joined 09:49 payload joined 09:50 kj joined, chromatic joined
chromatic msg bacek Crazy hack idea: CallSigRet has enough storage space for a single return pointer *without allocating anything else*. 09:52
purl Message for bacek stored.
Infinoid drive-by crazy. 09:59
10:05 desertm4x joined
dalek rrot: r42075 | kjs++ | trunk/compilers/pirc/src (5 files):
[pirc] first C-string argument converted into STRING. Needs lots of hacks currently, to keep things working. Currently all strings are stored twice: once as a STRING, once as a C string. Once all is converted to STRINGs, the C-string stuff can be removed.
 10:10
ttbot Parrot trunk/ r42075 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121305.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 10:13
10:30 baest joined 10:36 xenoterracide joined 10:38 kj_ joined 10:39 payload joined 10:58 payload joined 11:12 Whiteknight joined
Whiteknight good morning #parrot 11:21
Austin Guten Morgen, WhiteKnight. 11:22
Whiteknight purl msg chromatic: I believe compact pool still is used to manage STRING memory. I'll look into it but I don't think we have stopped using it
purl Message for chromatic stored.
Whiteknight hello Austin
kj good morning 11:23
Whiteknight hello kj
kj hi Whiteknight 11:24
11:36 joeri joined 11:54 bacek joined
bacek o hai 11:54
Whiteknight hello bacek 11:55
bacek msg chromatic It's really crazy idea. I like it!
purl Message for chromatic stored.
bacek hi Whiteknight
msg chromatic more crazy idea: we can add 3 fields value0, value1, value2 to store first 4 values without additional allocations. 12:02
purl Message for chromatic stored.
bacek purl: (5132872970 - 3088400055) / 5132872970 * 100 12:03
purl 39.8309665356865
12:08 ruoso joined
Whiteknight desertm4x++ # Work on parrot-linear-algebra Matrix PMC 12:09
purl msg darbelo: know anything about dynpmcs? We need to get the src/pmc/NumMatrix2D.pmc in parrot-linear-algebra added to the makefile. Then, we can start adding tests and stuff 12:11
purl Message for darbelo stored.
Whiteknight with this PMC working, next step is to start migrating Matrixy to use it instead of the nested RPAs nonsense 12:14
and we can start adding CBLAS bindings, which is key 12:24
bacek msg chromatic Do you have anything personal against diamond inheritance? We can easily create "pmclass ParrotContext extend Context extend CallSignature" almost with no code changes. 12:32
purl Message for chromatic stored.
12:33 mokurai left, flh joined 12:36 allison joined 12:40 jan joined
mikehh trunk - pre/post-config, smoke (#29358) PASS, fulltest FAIL at r42075 - Ubuntu 9.10 (beta updated) amd64 12:44
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
dalek a: 4450684 | unknown++ | src/pmc/lua (3 files):
fix segfault
 12:45
a: a0384cc | unknown++ | .gitignore:
ignore *.patch
a: 3223771 | unknown++ | t/lua-TestMore:
update submodule lua-TestMore
rrot: r42076 | bacek++ | trunk/src/pmc/callsignaturereturns.pmc:
[cage] Remove CallSignatureReturns.push_pointer.
 12:46
rrot: r42077 | bacek++ | trunk/src/pmc/callsignaturereturns.pmc:
[doc] Update CallSignatureReturns pod.
 12:49
ttbot Parrot trunk/ r42077 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121549.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 12:51
Parrot trunk/ r42076 darwin-thread-multi-2level make error tt.ro.vutbr.cz/file/cmdout/121552.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 12:54
13:56 plobsing joined 14:02 szabgab joined
dalek rrot: r42078 | kjs++ | trunk/compilers/pirc/src (3 files):
[pirc] remove STRING member of %union in parser for now; it doesn't work yet.
 14:40
ttbot Parrot trunk/ r42078 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121760.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 14:43
kj anybody around on windows who can spare a minute? 14:47
14:51 Psyche^ joined
dalek TT #906 closed by kjs++: [PIR] Assignment syntactic sugar restricted to destination parameters 14:54
14:56 fperrad joined
dalek rtcl: b617453 | coke++ | docs/spectest- (2 files):
another spectest - reclaim mathop.test
 14:57
a: 21c7436 | fperrad++ | src/lib/luatable.pir:
table.insert throws an error when too many arg
 15:05
rrot: r42079 | kjs++ | trunk/compilers/pirc/src/pircompunit.c:
[pirc] check duplicate declarations of .lex'icals. Implementation of TT1073
 15:06
ttbot Parrot trunk/ r42079 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121815.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 15:07
dalek TT #1113 closed by coke++: segfault in ?? 15:11
15:14 Psyche^ joined
dalek rrot: r42080 | kjs++ | trunk/compilers/pirc/src/pircompunit.c:
[pirc] clean up code a bit, remove need for another auto var in set_lex_flag(); only set the .lex flag on a target if it wasn't done so already
 15:19
TT #906 reopened by coke++: [PIR] Assignment syntactic sugar restricted to destination parameters 15:21
kj Coke: hi
Coke: ok, got your comment in the ticket. never mind! 15:22
ttbot Parrot trunk/ r42080 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121867.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 15:23
15:28 payload joined
dalek rrot: r42081 | kjs++ | trunk/compilers/pirc/src/pircompunit.c:
[pirc] add function doc for a (static) function; the constructor for key_entry objects
 15:29
ttbot Parrot trunk/ r42081 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/121910.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 15:32
15:43 theory joined
PacoLinux I have core dumped with latest parrot in linux : pastebin.com/m680d2510 15:54
15:59 chromatic joined
Coke kj - i was going to make you reopen it, but apparently replying to was sufficient. =-) 16:04
kj Coke: well i can see in a way you want it open, but (1) the desired/required behaviour has been specced in pdd19, (2) the behavior has been implemented in PIRC, and (3), it's a wontfix for IMCC... 16:07
...for which the ticket was opened.
Coke the ticket is opened for /parrot/ 16:15
purl Hmm. No matches for that, Coke.
Coke and parrot can't do that yet.
it was opened for imcc because pirc didn't exist when the ticket was opened.
16:24 particle joined
mikehh trunk - pre/post-config, smoke (#29359) PASS, fulltest FAIL at r42081 - Ubuntu 9.10 (beta updated) amd64 16:39
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
IOW we have three failing tests at the moment - two of which are the same test in different runcores 16:40
PacoLinux with --optimize, parrot dont do core dump 16:53
mikehh PacoLinux: I haven't tested without --optimize for ages - maybe I need to try 16:54
16:58 davidfetter joined
Coke PacoLinux: do you mean, that /without/ optimize, parrot doesn't core dump? 17:33
PacoLinux without optimize does core dump : pastebin.com/m680d2510 17:34
chromatic hm. 17:41
Confirmed.
I think I've fixed it too. 17:53
18:14 theory joined
flh I'm playing with the new (shiny) PCC, but I think I need to know a bit more about continuations in Parrot to go on 18:15
can I use any PMC which can be invoked as a continuation? 18:16
chromatic I think so, but I'm not sure what you're asking. 18:21
flh it looks like Parrot has a default "Continuation" PMC which only restores a few settings in the context 18:22
chromatic Right. 18:23
flh I want to do more complicated things when a sub returns
18:24 nbrown_ joined
chromatic What do you have in mind? 18:24
flh So I'm writing my own Sub PMC and my own Continuation PMC: when MySub is invoked, it actually sets MyContinuation as someone's continuation (not sure yet about that "someone")
I'm trying to implement something like that : take a sub f which takes an argument and returns a sub, which itself takes another argument 18:26
in PIR, I would write something (equivalent) to (f(first_arg))(second_arg)
chromatic You want your sub to return somewhere else, based on the continuation you pass in? 18:27
flh but I want f(first_arg, second_arg) to work: so I'm writing my own sub which handles the "too many params" case, and sets a continuation which will actually call the result on the remaining argument
I think the answer to your question is yes: I want the sub to return somewhere else 18:28
chromatic Makes sense. 18:29
flh actually, I've just seen the returncc opcode: it does "goto ADDRESS(dest)", where "dest" is given by invoke'ing the continuation 18:30
I'll just pretend I haven't seen the tailcall opcode, which seems to expect more things about the continuation 18:31
parrot doesn't have a "stack" of continuations, right?
chromatic Right. It's a graph. 18:33
dalek rrot: r42082 | chromatic++ | trunk/src/pmc/retcontinuation.pmc:
[PMC] Fixed RetContinuation recycling in invoke() by invalidating the from

build in PGE, created by r42058. This also requires that the RetCont's from_ctx pointer can't point to the same place as its to_ctx, or else the wrong context gets nulled out. Something may not set the from_ctx pointer correctly before invoking the RetCont.
18:34 nopaste joined
flh sorry, I'm not sure to understand what you mean by a "graph" of continuations 18:35
it seems that each context has only one continuation (stored "current_cont") 18:37
ttbot Parrot trunk/ r42082 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/122120.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 18:43
dukeleto languages? 18:48
purl rumour has it languages is trac.parrot.org/parrot/wiki/Languages
18:50 Zak joined
mikehh ok that works - r42082 builds and tests without --optimize 18:54
dalek tracwiki: v102 | dukeleto++ | Languages 18:58
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
19:08 mokurai joined
mikehh trunk - pre/post-config, smoke (#29360) PASS, fulltest FAIL at r42082 - Ubuntu 9.10 (beta updated) amd64 19:26
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
dalek TT #1142 created by mikehh++: test 12 of t/pmc/eval.t fails in testr (passes in other runcores) 19:28
19:34 joeri left
Coke I am having trouble with parrot r42082 19:38
installs fine, but then building partcl fails with:
PackFile_unpack: This Parrot cannot read bytecode files with version 5.3. 19:39
Parrot VM: Can't unpack packfile /home/coke/sandbox/parrot/runtime/parrot/library/PGE.pbc.
19:43 eternaleye joined 19:45 nbrown_ joined
mikehh just updated my Ubuntu 9.10 beta and it requires a restart - bbiab 19:46
19:54 mikehh joined
chromatic By my measurements, that's 0.546% faster than pre-merge. 20:20
dalek rrot: r42083 | chromatic++ | trunk/src/gc/mark_sweep.c:
[GC] Tidied code and rearranged a couple of branch conditions. No functional
purl somebody said changes was part of the communication in a release, and should involve actual human thought
rrot: r42084 | chromatic++ | trunk/src/call/args.c:
[PCC] Replaced vtable calls to FIA when passing and returning with macro

least a 3.207% speed improvement on the fib.pir benchmark.
ttbot Parrot trunk/ r42083 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/122247.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 20:29
Parrot trunk/ r42084 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/122248.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
dalek rrot: r42085 | chromatic++ | trunk/src/gc/api.c:
[GC] Allowed Parrot_gc_allocate_fixed_size_storage() to look up fixed-size pool

there's a pool already created. This gives fib.pir a 1.592% performance increase.		 20:37
purl it has been said that increase is from processing gains.
20:39 colomon joined 20:40 kurahaupo joined
ttbot Parrot trunk/ r42085 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/122325.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 20:46
20:48 kthakore joined 20:59 bacek joined
chromatic bacek, time for one more benchmark. 21:00
mikehh chromatic: one of the things I wanted to do this weekend was to try and remove skipped tests - TODO if possible or check if they pass 21:01
any suggestions where I should start 21:02
chromatic Anything related to the JIT core is low-hanging fruit. 21:03
If you can get rid of arch-specific skips, that's good too.
mikehh ok I'll start there 21:04
chromatic must run; will backlog
mikehh according to my latest smolder report #29362 at r42085 - 11,203 ok, 0 failed, 260 todo, 572 skipped and 0 unexpectedly succeeded 21:08
21:09 TiMBuS joined
mikehh that's 572 skipped tests to check :-} (that's not including the ones in fulltest) 21:09
bacek good morning 21:10
purl: (8505247882 - 4831058690)/8505247882*100 21:12
purl 43.1990841769096
bacek purl: 4831058690/3088400055*100 21:13
purl 156.425935888024
bacek msg chromatic trunk is 43.2% faster then after merge, still 56% slower that 1.4 21:14
purl Message for chromatic stored.
21:17 Austin joined
mikehh hi bacek - less that two hours to go before morning for me and then they go back from BST to GMT or whatever 21:18
bacek mikehh: day light saving? 21:21
mikehh we lose it in a couple of hours here 21:22
bacek think that Day Light saving is most useless idea... 21:23
mikehh trunk - pre/post-config, smoke (#29362) PASS, fulltest FAIL at r42085 - Ubuntu 9.10 (beta updated) amd64
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr (Segmentation fault)
the remainder of fulltest passes
ok - I am going to TODO thos tests for the moment 21:24
those
bacek mikehh: try to steal autounfudge.pl from Rakudo 21:25
21:28 mikehh joined 21:31 ruoso joined
dalek TT #1143 created by bacek++: examples/benchmarks/overload.pir requires rewriting. 21:32
21:39 mikehh joined
Coke seen moritz? 21:56
purl moritz was last seen on #parrot 13 hours, 4 minutes and 10 seconds ago, saying: speed wise?
Coke verrrry big rain here. 21:59
moritz re
Coke moritz: OHAI. 22:00
any chance you can install infinoid svn-bisect CPAN package for me?
moritz OMGIZCOKE
Coke (if not, I can just build my own perl )
infinoid's, that i.s
moritz takes a look at the dependencies 22:01
Infinoid what huh? who's installing me from CPAN where? 22:02
moritz Coke: installed 22:05
purl installed is easy as well.
moritz at least App::SVN::Bisect, hope that's fine
moritz -> sleep
Coke yes, moritz++ 22:12
Infinoid wow, that is some serious rain. 22:15
Coke Infinoid: did you check the radar or somethign? 22:18
22:20 bacek joined
Coke bisecting... 22:22
purl hmmm... bisecting is a lot harder than I expected
Coke no, bisecting is easy if you use svn-bisect
purl okay, Coke.
Coke Infinoid++ 22:23
Infinoid: add svn-bisect run so I can kill my module! =-)
Infinoid Coke: it was raining cats and dogs here when I said that 22:29
domestic pets are dangerous when they fall from the sky. 22:30
Coke aha. bacek broke the build.
bacek Coke: no way! it was chromatic!
Coke bacek: trac.parrot.org/parrot/changeset/42055 breaks installed PGE. 22:31
(which breaks partcl.)
trying with HEAD minus that rev.
bacek "Installed PGE"?
Coke yes. I can no longer build partcl using the installed PGE at that point. 22:32
complains about invalid bytecode version. 22:33
bacek hmm... I just successfully build partcl on my box from parrot trunk.
Coke using partcl from github? 22:34
bacek Coke: Hey. Did you make realclean after r42038?
(yes, from github)
Coke bacek: i /always/ make realclean.
22:34 joeri joined
bacek Coke: it's... weird... I broke PBC compatibilty in r42038... 22:35
Coke retrying with head...
damnit, it works again. 22:37
I mean, YAY.
bacek :)
Coke I am tempted to track down when it was re-fixed, but iznotworthit.
bacek++ # trying it to make sure.
bacek gotta go. It's my kids birthday party today. 22:40
see you!
dalek tracwiki: v39 | bacek++ | ParrotQuotes 22:41
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
Coke me kicks off YA spec test run. 22:47
dukeleto is hanging out in a parrallelization session at the gsoc conf. anybody have any questions they want asked? 22:51
22:52 mokurai joined
Austin kicks the @#$%@#%@# C3 algorithm. 22:57
23:03 Whiteknight joined
Whiteknight good evening #parrot 23:05
23:11 Eevee joined
dukeleto 'ello 23:12
Austin sings "Boom di yada, boom di yada, boom di yada, boom di yada.." 23:16
Props to Stephen Hawking for appearing in a campfire girls video... 23:17
23:18 mikehh joined
Whiteknight hello dukeleto, Austin 23:20
Austin Stupid cache. 23:21
Hello Whiteknight
Whiteknight ls 23:24
Austin ls?
purl ls: cannot access /dev: Input/output error
Austin :)
botsnack
purl :)
Whiteknight ...typed that in the wrong window 23:25
Austin Really?
Coke or, "ww"
23:34 kj joined
dalek rrot-linear-algebra: c9a372f | Whiteknight++ | src/pmc/NumMatrix2D.pmc:
add some stub methods to the PMC
 23:38
rrot-linear-algebra: f3e3e20 | Whiteknight++ | config/Makefile.in:
add some stuff to the makefile which I blantantly (and ignorantly) stole from Rakudo. I don't even know what this does, but it seems like a good start
23:44 eternaleye joined
Whiteknight anybody around here have strong makefile-foo? 23:50
specifically, I'm looking to build a dynpmc into a library
23:51 patspam joined
dukeleto 'ello 23:54
plobsing Whiteknight: isn't it the same as any other C file?
23:55 joeri left
Coke Whiteknight: partcl does that. 23:55
look for the section ## pmcs
dukeleto Whiteknight: looks like you have been working hard on parrot-linear-algebra, i hope I can start hacking on it soon
Whiteknight plobsing: it uses the Pmc2c file to translate the PMC file into C code 23:57
and I'm not entirely sure how that happens, since all the examples I've seen are more complicated then I expected them to be
dukeleto: yeah, I think we have a good prototype for the matrix PMC in place now 23:58
dukeleto Whiteknight: exciting! 23:59
purl i heard exciting was good enough.

Powered by Cro and the Raku® Programming Language.

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

Thank you!