Parrot 1.6.0 "half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 12 October 2009.
mgrimes wow, I think I got it. To be honest, I really don't understand what the code does, but with a little copy and paste, it seems to work 00:01
Should I submit a patch through the bug tracker? 00:02
jonathan mgrimes: I think that's the right place for patches, yes. 00:03
mgrimes will do. thank.
Austin Rock on, mgrimes!
You got a t/ test case written, too? 00:04
mgrimes yep: t/compilers/imcc/end.t 00:05
Austin Sweet.
mgrimes thanks for the guidance. just pointing me to imcc.l was huge! 00:07
Austin There's always somebody that knows ... 00:08
So now you can get more tests perl->pir-ified, yes?
And I guess the 64-squillion dollar question is, have you submitted a CLA to the Parrot Foundation? 00:13
mgrimes Can hardly wait to use the new feature. 00:16
No CLA yet. Do I really need to submit one? 00:17
chromatic Not for submitting a patch. 00:18
Austin I'm not sure of the rules. To be a "committer" you do. I think if you submit your patch via trac, one of the official committers can look it over, make sure it does or doesn't do whatever it should or shouldn't, and commit it for you.
jonathan -> sleep 00:19
mgrimes Good.
00:20 Wolong_ joined
dalek TT #1118 created by mgrimes++: [PATCH] Added __END__ to pir 00:30
mgrimes I started working on converting t/op/jit.t to pir, and I've gotten to the "2 non jit" which just has two 'print "ok #\\n"' statements. 00:49
How is that testing the jit? Any issues with converting that to ok(1,'...')? 00:50
Austin Should be easy. say "ok #"
Oh.
You got me there.
Maybe they're supposed to get printed really, really fast?
mgrimes lol 00:51
dalek ose: r183 | Austin++ | trunk/ (29 files):
Cleaned up some code. Created special classes for upper reaches of namespace

its root class. (NOTE: There are likely to be some residual problems because of this.)		 00:56
00:57 mgrimes joined 00:58 abqar joined 01:03 hercynium joined
dalek ose: r184 | Austin++ | trunk/close.cfg:
Removed close.cfg from svn
 01:05
01:07 davidfetter joined 01:38 kid51 joined
dalek ose: r185 | Austin++ | trunk/ (14 files):
Replaced close.cfg with close_cfg.tmpl, per red-book. Fixed up *@children init
 02:16
02:25 patspam1 joined 02:41 janus joined 03:17 brooksbp joined
dalek TT #1119 created by mgrimes++: [PATCH] Converted tests from perl to pir 03:51
04:12 desertm4x joined 04:17 mberends joined 04:31 theory joined
dalek p-rx: 66906e8 | pmichaud++ | src/NQP/ (2 files):
More nqp value handling improvements.
 04:42
p-rx: 4778331 | pmichaud++ | src/ (3 files):
Allow Cursors to bind non-Match objects.
shorten dalek's url is at xrl.us/bfszrv
shorten dalek's url is at xrl.us/bfszrx
dalek p-rx: 557d3bf | pmichaud++ | src/ (3 files):
Allow subrules to return non-Cursor objects.
shorten dalek's url is at xrl.us/bfszrz
dalek p-rx: 875be8a | pmichaud++ | src/ (3 files):
Allow cursors to return things other than Regex::Match.
shorten dalek's url is at xrl.us/bfszr3
dalek p-rx: c2b8fd7 | pmichaud++ | src/ (4 files):
Clean up match handling a bit. Allow <foo(...args...)> form of subrule.
p-rx: a27d5d1 | pmichaud++ | (4 files):
Initial steps for operator precedence parsing via
shorten dalek's url is at xrl.us/bfszr5
dalek p-rx: 2a077e8 | pmichaud++ | src/cheats/nqp-grammar.pir:
Add code for .panic and the <O(...)> subrule.
shorten dalek's url is at xrl.us/bfszr7
japhb pmichaud, what is the "magic <O(...)> subrule" about? 04:48
Infinoid, it looks like dalek needs to slow down in #perl6, it's getting flood kicked 04:49
Austin It tells nqp to run in O(...) time. It's a nice way to set optimization levels, and at the same time make it clear to the reader what's going on. 04:51
:->
cotto It's about time that a language made optimization that easy. 04:55
Austin I think it's part of the perl6 spec. S39 - Optimization & Performance 04:56
cotto Why waste time twiddling algorithms and pruning data structures when you can change O(n^2) to O(log n).
Austin BEGIN { O(log n) unless P == NP }; 04:57
What more do you need?
Speaking of P==NP, a buddy of mine mentioned the other day that someone has written a paper describing how the halting problem can be encoded into a financial derivative. The argument seems to be that the derivative then is effectively "encrypted" by this - legal-wise. I didn't catch all the ramifications, but it was certainly bizarre to encounter computational complexity as a legal instrument. 04:59
dalek rrot-plumage: 88106a0 | japhb++ | :
[CORE] Glue.pir: Add unlink()
 05:00
shorten dalek's url is at xrl.us/bfszti
dalek rrot-plumage: fd47591 | japhb++ | :
[CORE] Util.nqp: Add test_dir_writable(); fix typo
shorten dalek's url is at xrl.us/bfsztk
dalek rrot-plumage: 3df70d9 | japhb++ | :
[plumage] Automatically sudo for make install if Parrot's bin dir is not...
shorten dalek's url is at xrl.us/bfsztv
dalek p-rx: a5131aa | pmichaud++ | src/ (4 files):
Split NQP into shared (HLL) and non-shared (NQP) components.
 05:16
shorten dalek's url is at xrl.us/bfszvr
dalek p-rx: b25240b | pmichaud++ | (5 files):
Split NQP into shared (HLL) and non-shared (NQP) components.
shorten dalek's url is at xrl.us/bfszvt
dalek p-rx: 532f8aa | pmichaud++ | .gitignore:
Some .gitignore updates.
shorten dalek's url is at xrl.us/bfszvv 05:17
05:24 mikehh joined
Austin Howdy, mikehh 05:24
05:28 Zak joined
cotto clock? 05:30
purl cotto: LAX: Sun 10:30pm PDT / CHI: Mon 12:30am CDT / NYC: Mon 1:30am EDT / LON: Mon 6:30am BST / BER: Mon 7:30am CEST / IND: Mon 11:00am IST / TOK: Mon 2:30pm JST / SYD: Mon 4:30pm EST /
cotto rakudo: say "it works" 05:38
rakudo it works 05:49
05:57 uniejo joined
cotto seen chromatic 05:57
purl chromatic was last seen on #parrot 5 hours, 39 minutes and 23 seconds ago, saying: Not for submitting a patch.
06:00 patspam joined 06:31 chromatic joined
chromatic Only 34 minutes early. 06:44
cotto chromatic, care for a quick patch review? 06:46
chromatic I'm ready.
cotto (I'm mostly concerned about variable names, as the rest seems to work)
nopaste "cotto" at 74.61.2.46 pasted "Parrot_Sub_get_line_from_pc optimizations for chromatic" (42 lines) at nopaste.snit.ch/18371 06:47
chromatic Modest; how's it perform for you? 06:48
cotto measurable but modest 06:49
chromatic Yeah, a good compiler and a better language would recognize that those constants are hoistable, but getting const for structs and pointers working sanely in C is more work than I can contemplate. 06:50
The only variable name that isn't sufficiently clear to me is offs.
current_annotation seems better, but it's long.
cotto ironically that's not one I changed
chromatic While you're in there.
cotto sure
Do you have any thoughts how I could make that function faster? Before the patch it takes up ~38.74% of the time of the profiling runcore. 06:53
s/of the profiling/of the time spent in the profiling/
chromatic The problem is that our ops have variable sizes. Thus if we store annotations by index, we always have to walk the bytecode to get the current pc's annotation index. 06:54
cotto I'm specifically thinking of optimizations to make the data easier to find, but I don't know packfiles well enough thoroughly understand what the code is doing.
Austin Actually, names i and n in the same loop are failing to convey much in the way of meaning. 06:55
chromatic I think we should use an array-based binary tree, which is O(log n) lookup if we use opcode addresses as keys. 06:56
Insertion time isn't incredibly speedy, but we build that annotation segment once and use it much.
Austin cotto: Is this for compiled code only? 06:57
Or, put another way, can you count on a "compiler" being involved always?
Because you could just build an offset table and do a ragged bsearch for it.
chromatic That's basically the way to do it. 06:58
cotto The speedup is on the order of 10% for non-optimized. 06:59
on oofib.pir
chromatic Stupid C and non optimizability, take that all you armchair language benchmarkers!
cotto really 07:00
Austin What does ADD_OP_VAR_PART() do?
cotto Those changes should make a difference at all, but it's measurable even with --optimize.
chromatic Austin, because our ops have varying numbers of arguments, it has to look up the number of arguments for that op and figure out the address of the *next* op based on that. 07:01
Austin Right, but what's the output?
cotto the last arg, n 07:02
chromatic It increments the last arg.
cotto chromatic, do you have any idea of a better name for n and/or i?
Austin The last arg that I can see is "var_args".
cotto Austin, yes. That's the one that gets incremented. It's 'n' in the macro's definition. 07:03
Austin Ah.
chromatic 'n' might be better as 'op' 07:04
Austin Would it improve things to eliminate 'n' entirely, and recast the loop in terms of base_pc <= pc? 07:07
chromatic Doesn't hurt my feelings.
Austin Also, how often does this function get called?
cotto nor mine, but I need to go to bed and want to commit something before #ps. 07:08
Austin :)
cotto once per op in the profiling runcore
iirc
Austin Oh
Then why not cache the last result in a couple of statics, and only do the one computation?
if (pc is still in this range) { re-use statics } else {do everything over} 07:09
chromatic Threads, for example.
moritz would that skew timing operations?
chromatic Also it's not trivial to test if we've switched bytecode segments. 07:10
Austin That should be thread-safe, chromatic. If a different thread has a pc in the same sub, the results are still valid. We aren't using the same bytes with different entry points, yet, are we?
cotto night 07:11
Austin g'night, cotto
07:12 davidfetter joined
chromatic Sure, now try synchronizing multiple threads writing to that static. 07:12
dalek rrot: r41936 | cotto++ | trunk/src/sub.c:
[profiling] hoist some dereferencing out of a loop in Parrot_Sub_get_line_from_pc

improve some variable names.
Austin Is that an issue? I had the impression threads all had their own cores. 07:13
If so, s/static/interp parasite/
chromatic I'm much more comfortable with it as somehow thread/interpreter local storage. 07:14
Austin Why not as an attachment on the sub. Build a table of pc -> line offsets one time, do a lookup. 07:15
chromatic That's better, but why not build it when we build the annotation structure? 07:16
Austin I don't know what the use case is. 07:17
chromatic I can't think of a case where we want to look in the annotation structure *without* tying it to specific ops.
Austin If we can jam it into the compiled pbc, that's a win. But if we have to support the current format or something, it's doable on the fly.
Do we care about size?
chromatic Within reason, no. 07:18
Austin So a lookup table, then. Offset -> line 07:19
int offset = pc - base_bc; int line = debug_info->sub[subid]->offset2line[offset]; return line; 07:20
chromatic Exactly.
Austin Where's mgrimes at? 07:21
He was just hacking imcc earlier tonight.
:)
chromatic This is worse; this is PBC.
Did you see 300?
Austin Nope.
chromatic Did you read the book?
Austin Like Titanic, I already knew how it was going to end.
Nope.
chromatic Yeah, I have the Battle of Thermopylae trading cards too.
Austin I'm 300-ignorant. 07:22
Laugh
chromatic I'll put it this way: people complain about IMCC because the few people stubborn enough to work on it and I complain about it.
People don't complain about PBC or freeze/thaw because no one's stubborn enough to work on it.
Austin I thought bacek was doing something with PBC generation from pir a few weeks back. 07:23
07:23 joeri joined
chromatic I thought he *was* a Spartan. 07:24
07:24 gaz joined
Austin :) 07:24
Oh Thpartakis!
chromatic Classic whodunit. 07:25
Austin Romani ite domum. Romani ite domum. Romani ite domum. ... 07:27
07:33 fperrad joined 07:34 nopaste joined 07:59 bacek joined
bacek who called my name? 08:02
moritz some name caller :-) 08:04
bacek moritz: :) 08:06
08:14 TiMBuS joined, JimmyZ joined 08:29 bacek_ joined
dalek rrot: r41937 | bacek++ | branches/pcc_reapply/src/pmc/class.pmc:
Set and restore current_object during Class instantiate. Fix benchmark tests.
 08:31
moritz so what's the state of pcc_reapply? can it be merged right after the release? 08:34
bacek_ moritz: mostly. One failing test atm
moritz the threading issue? 08:35
bacek_ moritz: yes. 08:37
moritz: but Rakudo can't be build on branch anyway. 08:39
moritz I know, it pokes the guts too deeply 08:40
allison jonathan: very possibly (references into the constant's table) 08:43
bacek_ allison: question about r41937. Should invoke_from_sig_object always set current_object? 08:45
allison bacek: no, only methods set current_object 08:46
08:47 masak joined
allison bacek: but then in all other cases current_object should be NULL 08:47
bacek: honestly, current_object shouldn't be in the interpreter at all, it should be in the context 08:48
bacek_ allison: it's in context. Sub PMC copy it across. 09:02
But we should remove it from interp anyway 09:03
allison bacek: ah, I was just skimming through the sub code, was skimming past interp->current_cont 09:04
bacek: no 'ext'
bacek: so, just a knee-jerk reaction 09:05
there is no interp->current_context
bacek_ INTERP->current_object
sub.pmc, line 410
allison bacek: that should be removed 09:06
bacek: yes
bacek_ probably during CallSignature/Context unification 09:08
allison bacek: yes, after the current refactor
allison needs breakfast 09:09
bacek just got dinner
allison: btw, we can avoid :call_sig after merging CallSignature and Context. It will be available from interp anyway 09:12
09:14 einstein joined
allison bacek: yes, but we don't want that as the commonly used interface 09:15
bacek allison: why?
allison bacek: it's a pain to use, requires writing ugly code for a simple operation 09:16
bacek: and, getting people to poke into the internals that way makes them more likely to make errors in the process 09:17
bacek: it's the old Huffman coding principle
bacek: if an operation is common, it deserves a simple way of using it
bacek allison: I don't see much difference between ".param pmc sig :call_sig" and ".local pmc sig; sig = interpinfo .PARROT_CURRENT_CONTEXT" 09:18
apart from less code in core
allison bacek: people certainly can use the latter at any time, even if they have real parameters in the subroutine signature 09:19
jonathan Either works for me. OTOH, I'm still going to need to grab the current call sig from C anyway, since in at least one place I need it pre-invoke.
morning, btw
allison bacek: but :call_sig is different, it specifies the signature of the subroutine as taking a single PMC
bacek evening, jonathan :)
allison bacek: it also allows people to pass in a single object as the call signature
bacek: call it an advanced form of :flat 09:20
bacek allison: ah. So it's blocking whole PCC?
allison bacek: aye, it's a back-door for access 09:21
jonathan ŠŸŃ€ŠøŠ²ŠµŃ‚, bacek :-)
allison bacek: also, :call_sig on the param says "don't do any of the usual arg/param processing, I'll do that"
bacek Š” Š“Š¾Š±Ń€Ń‹Š¼ утрŠ¾Š¼, Š”Š¶Š¾Š½Š°Ń‚Š°Š½ :)
jonathan bacek: The point is that PCC doesn't have any work to do.
bacek allison: thats what I mean by " blocking whole PCC" 09:22
allison BTW, jonathan: for your purposes, when you get a raw call signature, would you rather have :flat args already flattened, or left whole for you to flatten your own way?
jonathan It's useful for languages that are insane enough to feel they need their own custom binders.
;-)
allison bacek: yes,
jonathan allison: I was expecting those to have been flattened when building the call_sig 09:23
allison: I can handle it either way though.
allison jonathan: they are now
dalek rrot: r41938 | bacek++ | branches/pcc_reapply/src/call/args.c:
Don't append "Pi" in front of signature if it's already present.
jonathan allison: That works for me.
jonathan allison: The bigger deal is not losing multiple named args when they both have the same name, but you've already suggested I may need my own subclass of CallSignature to make that work. 09:24
allison jonathan: yes, we're not supporting that 09:25
jonathan: duplicate names are an explicit error in Parrot calling conventions
bacek think that we should get rid of Hashes for CallSignature.
Hashes are slow in this case anyway
moritz maybe we can coax perl 6 into adapting the same policy 09:26
allison jonathan: what do you do with duplicate named args?
jonathan: anything useful? 09:27
jonathan: randomly pick one?
bacek moritz: but we have to provide ways to override this behaviour.
moritz: (from parrot side)
allison bacek: we have gotten rid of the internal Hash PMC in CallSignature, but are still using a hashing algorithm internally 09:28
bacek: sure, that's a custom CallSignature object, can do anything
bacek allison: I still see hashes inside CallSignature 09:29
jonathan allison: I think if we have an array parameter and multiple named args binding to it, then it's meant to collect them all into the array.
allison: I don't actually care a lot for the feature myself, tbh.
allison jonathan: I can see that working, but yeah, it's borderline 09:30
jonathan: I can see it leading to some confusion in reading the error messages when duplicate named's are passed accidentally 09:31
jonathan allison: Heh, yeah.
allison: I think there may well be enough arguments against it to make it go away. :-) 09:32
allison jonathan: :)
bacek thinking about std::multi_map from old good C++ world 09:33
dalek tracwiki: v15 | bacek++ | CallingConventionsTasklist 09:34
tracwiki: Strike out couple of implemented items
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfs2xf
09:49 desertm4x joined 10:09 mikehh joined 10:28 mikehh joined 10:32 AndyA joined 10:36 Hunger joined 10:54 Hunger joined 10:55 payload joined 11:01 fperrad_ joined 11:02 cconstantine_ joined 11:08 plobsing joined
einstein does any body know what the current state is off the orderedhash_revamp branch? 11:20
does the inplementation of ordered hash in this implementation work properly? 11:21
11:28 AndyA joined 11:46 mikehh joined 11:53 pancake joined
pancake what's parrot_nqp? 11:53
purl parrot_nqp is just the name of the fakecutable binary
pancake it aborts in my box
moritz there's some trouble with parallel builds and parrot_nqp 11:54
pancake: are you using make -j $something?
pancake no
moritz anyway, parrot_nqp is the executable of the NQP compiler 11:55
pancake ok
dalek rrot: r41939 | allison++ | branches/pcc_reapply/t/pmc/threads.t:
[pcc] Don't compare the constants table to the namespace, as the namespace is
 11:56
11:56 Hunger joined
dalek TT #1120 created by allison++: [CAGE] More rigorous testing for constant tables across threads 11:56
11:58 whiteknight joined
whiteknight good morning #parrot! 11:58
allison good morning, whiteknight
11:59 mgrimes joined
whiteknight hello allison, how are you today? 12:02
allison very well
whiteknight: you? 12:03
purl you is very bed in engrish too
allison thanks, purl
purl no worries allison
whiteknight tired. My wife was a bridesmaid in a wedding this weekend, so between rehearsal/rehearsal dinner/preparations/wedding/reception I was too busy 12:04
allison yes, those events tend to keep you running 12:05
whiteknight did you see the awesome progress in the pcc_reapply branch this weekend?
we were down to only one test failure when I logged off yesterday 12:06
allison whiteknight: I did, yes, very impressed!
whiteknight: that one failure is gone, but I modified the test
whiteknight what was the root cause there? 12:07
allison whiteknight: it's a pretty buggy test (fails on various runcores)
whiteknight yeah, I noticed that
allison whiteknight: it expects the constants table and the namespace to always store the same sub object
which is true in the main interpreter 12:08
mikehh there were still failures in benchmark_tests - haven't tested this morning
doing so now
allison but, in the thread the namespace and the sub object stored in it are cloned
while the constants table remains the same
whiteknight okay, that's what I figured the issue was 12:09
allison mikehh: okay, thanks, I'm just running fulltest now
whiteknight but then why does that test pass in trunk but not in brnach?
allison whiteknight: it can be argued that either a) the constants table should be cloned, b) the namespace and sub object shouldn't be cloned or c) all sub access should be going through the namespace rather than directly through the constants table 12:10
(i.e. what if the namespace is dynamically changed?)
whiteknight My opinion there is that the NameSpace probably shouldn't be cloned 12:11
but the real question is why the test was failing in the branch.
I didn't see any real changes to the NameSpace PMC or the cloning behavior
allison whiteknight: still digging into that, but the time spent on this is seeming less and less useful, when it looks more like we've revealed a preexisting bug than caused one 12:12
whiteknight okay, gotcha
if it passes, and we're mergable, I say to just focus on that instead
allison mikehh: got t/pmc/os.t failure in testr
whiteknight: aye, it's passing the part of the test that's enabled, just skipping one part of the test, and I added a ticket for that part 12:13
mikehh running the tests now
allison mikehh: mkay, weird, I get the failure in 'testr' in 'fulltest', but can't duplicate it running 'make testr' directly 12:21
12:22 bluescreen joined
mikehh testr PASSed in fulltest 12:28
in fact fulltest Passed all tests 12:30
allison mikehh: excellent!
purl EGG-see-lent!
allison mikehh: I'll try a realclean
mikehh so as of now r41939 all tests PASS in pcc_reapply branch for me - Ubuntu 9.10 beta amd64 12:31
moritz purl: forget excellent
purl moritz, I didn't have anything matching excellent
moritz purl: forget excellent!
purl moritz, I didn't have anything matching excellent
12:32 ruoso joined
mikehh pcc_reapply branch - All tests PASS (pre/post-config, smoke (#29190), fulltest) at r41939 - Ubuntu 9.10 (beta updated) amd64 12:33
Coke skips review!
(how refreshing.)
whiteknight all tests pass!?! I 12:37
've been waiting to hear that for weeks
jonathan Wow!
Nice work, all!
whiteknight not time for congratulations quite yet. Still need to merge it and fix all the performance issues 12:38
jonathan whiteknight: Oh, for sure. But it's an achievement to have reached this point too. :-) 12:39
whiteknight true
jonathan I think Parrot has just achieved a register allocation failure too. :-/
whiteknight a lot of people with a very focused prolonged effort got us to this point.
jonathan Investigating.
whiteknight damnit! Who the hell is even making changes in trunk right now? 12:40
the branch is where the party is
jonathan whiteknight: Oh, I doubt this is new...
whiteknight oh, okay
jonathan whiteknight: If it is that.
whiteknight: I'm struggling to believe it really is that. But I'm also struggling to see why the address of something in a P register would change betwen two points where I don't set anything to that register. 12:41
moritz threads! 12:42
purl threads is probably ithreads, Thread is 5.005 threads (older)
jonathan moritz: There's the small issue that I only have one thread running, afaik... 12:43
:-P
mikehh looking at the fulltest log I get 2 TODO passes in testS
Test Summary Report 12:45
-------------------
t/op/debuginfo.t (Wstat: 0 Tests: 8 Failed: 0)
TODO passed: 7
t/pmc/threads.t (Wstat: 0 Tests: 14 Failed: 0)
TODO passed: 13
Files=215, Tests=6028, 57 wallclock secs ( 2.94 usr 0.63 sys + 43.84 cusr 22.42 csys = 69.83 CPU)
Result: PASS
einstein I found a litte but nasty bug which could cause problem in system.c->trace_mem_block
whiteknight einstein: do tell! 12:46
that whole file is a nasty little bug
moritz did anybody benchmark PGE in trunk and pcc_reapply branch?
whiteknight :)
einstein prefix = mask & buffer_min; should be prefix = maks & (buffer_min < pmc_min ? buffer_min : pmc_min); 12:47
Coke does the no-or-mostly-no-failures-in-pcc-reapply still need buildframes=0?
mikehh and t/pmc/threads.t has a TODO pass 13 in testC 12:48
whiteknight t/pmc/threads.t:13 is the devil
einstein it is a small one but in certain condition this can cause nasty problems
allison mikehh: yes, I commented out a part of t/pmc/threads.t that was failing before in trunk 12:49
mikehh should I remove those TODO's or are we going to do some more work on that
whiteknight einsein: ah, that is pretty obscure
but yes, I can see that being a proble
einstein could you make the small change and patch it into the trunk? 12:50
whiteknight einstein: could you make a ticket? I'm not really able to make changes or test them at work 12:51
einstein ok i will do
whiteknight thanks 12:52
pcc_reapply build still fails on win32 12:56
src/nci_test.c:750: Undefined reference to 'PMCNULL' 12:57
the parrot executable builds, but this stupid test library does not
and without that apparently I can't run coretest
jonathan whiteknight: It fails when compiling the C file or when linking? 12:58
Any warnings?
whiteknight jonathan: when linking
no warnings that I can see, at least none in this file
dalek TT #1121 created by jessevdam++: system.c trace_mem_block small bug
whiteknight although for some reason it appears to be linking that library with g++ instead of gcc like everything else in the build 12:59
that's weird
oh nevermind, it linked libparrot with g++ too for some reason
jonathan whiteknight: Is libparrot referenced in the link line?
In the same was as for the Parrot executable? 13:00
whiteknight don't know, already closed the window and am trying something different
jonathan ah, ok :-)
whiteknight sorry
jonathan np 13:02
Am I right in thinking that PASM output is broken? 13:03
That is, taking PIR and seeing what PASM it emits?
moritz I think somebody mentioned that here last week, yes 13:04
jonathan aww
Makes it a tad harder to see whether I've actually got a regalloc issue. 13:05
moritz have fun inspecting the byte code
jonathan :'( 13:08
whiteknight PASM output from PIR has always been broken, I think 13:10
and I have no idea why
jonathan: no, libparrot is not included in the link for libnci_test.dll 13:11
purl okay, whiteknight.
whiteknight goddamnit purl! 13:12
jonathan whiteknight: That may well be the issue. 13:13
Hmm
tmp = wrapper.'get_outer'()
Why on earth would this line affect the value of another symbolic register?
Commenting it out means a totally unrelated register...doesn't get changed. 13:14
whiteknight what type is wrapper?
jonathan a Sub, or some subclass of it.
whiteknight and is this in branch or trunk?
jonathan Working against Parrot trunk.
Thing is, I think it works without my other Rakudo changes. :-S 13:15
I just can't see what on earth it's doing.
whiteknight what is tmp then, a context? 13:17
jonathan No, should just be the outer sub. 13:18
whiteknight you could be corruping memory somewhere, overwriting the register storage
jonathan Could be.
Just tyring to work out how/where.
whiteknight right
jonathan And what has changed that's caused this.
whiteknight what project are you trying to work on right now?
(personal curiosity) 13:19
jonathan Rakudo
whiteknight right, which project in rakudo
jonathan I'm trying to deal with the last remaining test failures in the resig2 branch.
So it can be merged.
whiteknight oh, okay
jonathan Preferably regressing on as little as possible.
Somehow the .wrap implementation has got broken. 13:21
Which is the bit I'm trying to work out at the moment.
13:26 mj41_ joined 13:28 bluescreen joined
whiteknight yay! building on win32 again 13:29
and testing now...
jonathan I think this will count as one of the worst patches I ever commit... 13:32
gist.github.com/213359
The worst bit is that it actually works.
13:45 pancake joined
pancake parrot fails the build on scratchbox 13:45
i get an illegal instruction with ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir
whiteknight illegal instruction? 13:47
purl well, illegal instruction is "fcomi" or a perl's way of saying "You done messed up good, boy!'"
whiteknight don't see too many of those around here
pancake yep, it's an immigrant
qemu: uncaught target signal 4 (Illegal instruction) - core dumped 13:48
any idea about how to debug this without ptrace? (qemu-arm doesnt supports ptrace)
13:52 payload joined, JimmyZ joined 14:08 Andy joined 14:09 PacoLinux joined
dalek TT #1122 created by mgrimes++: [PATCH] Convert more tests from perl to pir 14:21
14:29 payload joined 14:48 payload joined
dalek rrot: r41940 | cotto++ | trunk/src/hash.c:
[hash] typo fix in docs
 14:53
14:55 Zak joined 14:57 Psyche^ joined 15:02 rdice joined
whiteknight pcc_reapply: all tests pass on win32 (except the ones that don't pass in trunk anyway) 15:12
cotto yay for caching! 15:16
15:19 iblechbot joined
dalek rrot: r41941 | cotto++ | trunk (2 files):
[profiling] add a pc->line number cache to the profiling runcore

time spent in Parrot_Sub_get_line_from_pc, reducing it from ~38% to ~0%.
  (parrot_hash_get is at about 2.74%.) This will cause a slowdown for programs
without many loops, but such programs are not likely to be profiled in the first place.		 15:21
15:25 hercynium joined
whiteknight cotto++ 15:26
dalek rrot: r41942 | whiteknight++ | branches/pcc_reapply/config/gen/makefiles/root.in:
[pcc] update makefile so that libnci_test.dll builds properly on win32. Don't know why this isn't happening already, but this was breaking the build
 15:31
15:38 donaldh joined 15:41 zostay joined
dalek kudo: 1f16505 | moritz++ | README:
[README] mention win32 builds
 15:42
shorten dalek's url is at xrl.us/bfs37r
15:45 Austin joined
cotto_work I see my counterpart's been active ;) 15:49
16:06 theory joined 16:36 bacek joined
cotto_work hi bacek_at_work 16:42
s/_at_work//
bacek cotto_work: I'll be at work soon... 16:46
cotto_work clock?
purl cotto_work: LAX: Mon 9:46am PDT / CHI: Mon 11:46am CDT / NYC: Mon 12:46pm EDT / LON: Mon 5:46pm BST / BER: Mon 6:46pm CEST / IND: Mon 10:16pm IST / TOK: Tue 1:46am JST / SYD: Tue 3:46am EST /
cotto_work I guess that magical coding robots don't need much sleep. 16:47
speaking of magical robots: jwz.livejournal.com/1107303.html 16:48
bacek cotto_work: sigh... We have big production release at 5AM...
cotto_work urg
16:49 mikehh joined
Austin cotto_work: nice video. I have to agree with the guy that asks why they haven't weaponized it yet. Don't they *want* a billion-dollar grant from the Air Force? 16:59
17:03 donaldh left
cotto_work It looks like the parallel build is br0ken in pcc_reapply 17:05
dalek rrot-plumage: 68f1caa | japhb++ | :
[plumage] Dependency resolution step 1: showdeps command
shorten dalek's url is at xrl.us/bfs4jv
whiteknight stupid build 17:12
how goes it Austin? 17:16
how is Close coming along?
Austin It's getting closer.
:)
whiteknight yay! puns.
cotto_work groans
Austin I just now stumbled on this error from PCT: rtype not set 17:17
I must be making progress if I can make PCT break, no?
17:18 payload joined
bacek_at_work good morning. fsvo good 17:19
whiteknight hello bacek_at_work
bacek_at_work whiteknight, hi
whiteknight pcc_reapply is passing all tests now 17:20
Austin How goes the production release, bacek?
whiteknight so we did good work this weekend!!
Austin Congratulations, WhiteKnight.
cotto_work isn't that because some tests got todo
'd though?
whiteknight the one test that was marked TODO was busted anyway
bacek_at_work Austin, it's going.
dalek p-rx: eb3ae12 | pmichaud++ | src/cheats/hll-grammar.pir:
Add some comments and documentation to hll-grammar.pir .
 17:27
p-rx: b596526 | pmichaud++ | src/ (4 files):
Add quote_EXPR subrule, start to handle various combinations for
shorten dalek's url is at xrl.us/bfs4nq
shorten dalek's url is at xrl.us/bfs4ns
dalek p-rx: 5648720 | pmichaud++ | src/ (5 files):
OPP first step -- parse a term.
shorten dalek's url is at xrl.us/bfs4nu
dalek p-rx: f4c2dcb | pmichaud++ | src/ (2 files):
Add a termstack, some infix grammar rules.
shorten dalek's url is at xrl.us/bfs4nw
dalek p-rx: 0bd524c | pmichaud++ | src/ (4 files):
OPP: first stage of handling infix tokens
shorten dalek's url is at xrl.us/bfs4ny
dalek p-rx: 74835b5 | pmichaud++ | src/ (4 files):
Add some precedence to the operator tokens, fix operator spec parsing.
shorten dalek's url is at xrl.us/bfs4n2
treed What is nqp-rx?
Aww, purl doesn't know.
japhb treed: a rewrite of NQP and PGE
treed Oh! This is that.
Neat.
japhb Indeed!
Austin purl, nqp-rx is a rewrite of NQP and PGE. 17:34
purl OK, Austin.
cotto_work whiteknight, whatever happened to your proposal for libjit- and llvm-based frame builders? Are you going ahead with that? 17:35
Austin FWIW, "rtype not set" in this particular case meant: Don't write self.declarator := ...; but rather write self.declarator(...) because it's a method.
whiteknight cotto_work: yes. pcc_reapply has been priority
cotto_work glad to hear it
it's also excessively nice to see all tests passing in pcc_reapply 17:37
jonathan Is pcc_reapply likely going to get merged after the next release 17:40
?
As in, shortly after?
whiteknight jonathan: yes
that's the plan anyway
jonathan Excellent.
whiteknight and then we can focus on performance issues in trunk
tomorrow at #ps would be a good time to talk about it more 17:41
and then after the release we can have a merge frenzy
cotto_work Heh. I've been enough out of the loop that I didn't even realize how soon the release is when I made those earlier commits.
whiteknight yeah, tomorrow is dukeleto, I think 17:42
jonathan \\o/ 17:43
Also, looks like Rakudo's signature re-working will land in master in a couple of hours.
A few days ahead of the Rakudo release. :-) 17:44
After that's in, I'll start a branch to focus on getting it to build against pcc_reapply.
whiteknight okay. If it's priority I can probably add :call_sig within afew hours tonigh 17:45
jonathan whiteknight: I was thinking of doing it in two steps.
First just make it build and work with the slurpies, as it uses now.
And then when that will fly and pass the tests, do call_sig, which should make us faster. 17:46
whiteknight I may add :call_sig soon anyway. It's going to be very easy I think
jonathan whiteknight: Sure, my point was, don't sweat over it. :-) 17:47
It'll be great to have.
whiteknight okay, awesome
17:47 payload joined
jonathan :-) 17:47
You'll do it on the caller side as well as the callee, yes? 17:48
(when you get to it, that is)
whiteknight caller side? How would that work?
like, specify an existing CallSignature to use?
jonathan whiteknight: foo($P1 :call_sig)
whiteknight: Right. So consider the case where I'm delegating.
allison whiteknight: they can pass in any object to use as the call signature
whiteknight gotcha. That should be relatively easy to add as well 17:49
jonathan I don't want to take a call signature apart only to build a new one with the same stuff in. :-)
whiteknight in set_params, if the input PMC type is a CallSignature, use that directly instead of creating a new one
jonathan Sounds about right. 17:50
break, bbs
whiteknight ok
Allison: are there any other of these "special" parameter types that we might want to add? 17:51
being able to specify the caller Sub, or a Context or something in a parameter might be interesting
allison whiteknight: I'd hold off until we have a specific use for it (can always add features later, harder to remove them). 17:53
whiteknight: we're planning to unify context in to call signature, so that'll be the same option
whiteknight Okay, what I'm mostly asking about in a roundabout way is whether to make this mechanism general or specific to this case
cotto_work allison, with all the fancy stuff that pcc does, is it possible that it'll be faster for a language with C-style function calls to do its own processing? 17:54
17:55 fperrad_ joined
allison cotto: if the language only uses simple positionals, it's pretty cheap 17:55
cotto: the expense comes when you use the fancy features
cotto_work ok
allison cotto: and we can do more to make the simple case even cheaper 17:56
whiteknight we have the pretty algorithm now, there is plenty we can do to make it faster all around
cotto_work I'm sure there are many optimizations lurking in all that freshly-written code.
whiteknight and more importantly, we have a lot of developers empowered to make those changes
cotto_work very yes
allison aye 17:57
cotto_work and it's much more discoverable for the rest of us 17:58
nopaste "pmichaud" at 72.181.176.220 pasted "operator precedence parsing in nqp-rx" (38 lines) at nopaste.snit.ch/18372 17:59
whiteknight pmichaud: looks awesome 18:00
Allison: do we want any particular rules concerning :call_sig? I'm thinking it should be the one and only parameter
that makes a lot of short-circuiting logic cleaner, I think 18:01
allison yes, other args or params would be an error
whiteknight okay. Perfect. I could have that added tonight then if no issues come up
(or wait till after the merge too)
allison work on it tonight, but don't commit it 18:02
(keep the scope creep down on the branch)
it's a small feature, can be committed right after the merge
dalek p-rx: 9083197 | pmichaud++ | src/ (2 files):
Refactor the opstack and termstack to hold Match objects instead of cursors.
 18:03
shorten dalek's url is at xrl.us/bfs4tb
dalek p-rx: ecc6416 | pmichaud++ | src/cheats/hll-grammar.pir:
Add left associativity to precedence parser.
shorten dalek's url is at xrl.us/bfs4td
dalek p-rx: 5b872f0 | pmichaud++ | src/ (3 files):
Reduce higher predecence operators immediately.
shorten dalek's url is at xrl.us/bfs4tf
dalek p-rx: 0428b85 | pmichaud++ | src/cheats/hll-grammar.pir:
Remove some debugging code.
shorten dalek's url is at xrl.us/bfs4th
whiteknight fair enough, I'll put together a patch 18:04
dalek rrot-plumage: 950fede | japhb++ | :
[CORE] Glue.pir: Add readdir(); add missing SYNOPSIS entry for unlink()
 18:13
shorten dalek's url is at xrl.us/bfs4ut
dalek rrot-plumage: 20d3533 | japhb++ | :
[plumage] Dep. handling 2: Separate missing projects v. unrecognized dep...
shorten dalek's url is at xrl.us/bfs4uv
dalek rrot-plumage: 14fc150 | japhb++ | :
[plumage] Add projects command to list known projects
shorten dalek's url is at xrl.us/bfs4ux
whiteknight loves watching the commits roll through
it's so exciting when things are happenig
japhb whiteknight, yeah, it's a good day, isn't it? :-)
18:16 mikehh joined
dukeleto 'ello 18:20
whiteknight hello dukeleto
ready for your big day tomorrow?
dukeleto tomorrow is release day, anything I should know about, to add to the release notes?
whiteknight it should be an easy month for release notes, much of the focus was in the pcc_reapply branch
18:21 darbelo joined
dukeleto whiteknight: trying my best. I am chilling in the airport right now, waiting to go to SFO and then the GSoC summit on Wed 18:21
whiteknight lucky
dukeleto whiteknight: yes, seems so
whiteknight I'm sitting at work, waiting to go back to work tomorrow
cotto_work whiteknight, nothing to do? 18:22
whiteknight cotto_work: lots of work to do
but nothing else
purl nothing else is counting how many hours scrottie's computer has been on! SMART rules!
18:25 payload joined
dukeleto the pcc_reapply branch fails to build without an installed parrot already present. can someone fix that? 18:26
nopaste "dukeleto" at 67.88.206.98 pasted "pcc_reapply fails at without an installed parrot" (5 lines) at nopaste.snit.ch/18373 18:27
dukeleto gotta board soon
cotto_work dukeleto, are you using -j with make? 18:28
whiteknight that can't be true, I don't ever install Parrot and it works on my machine
cotto_work I saw a similar problem with a parallel build earlier today
whiteknight hates makefile problems 18:29
whiteknight hates makefiles
18:29 fperrad_ joined
makefiles hate whiteknight 18:33
darbelo ;) 18:34
whiteknight ah, poetic irony
darbelo whiteknight: Do you have a tasklist of TODO for matrixy or parrot-linear-algebra? 18:35
whiteknight darbelo: nothing formal, no. I talked about it on my blog recently. 18:36
Maybe we should come up with a roadmap for those projects
One thing we could start on immediately would be to create that 2-D matrix PMC type
if you have any ideas about that, I would love to hear them 18:37
because right now Matrixy is using nested RPAs, and that's a huge mess
Also, we're going to need something better if we want to properly support Cell arrays 18:38
darbelo Not many ideas, I was expecting matrixy to be harder to get going. It was a case of "Wait. I'm done? Where do I go from here?"
whiteknight I have't even tried, but do the tests work and all? 18:40
The tests that rely on the libraries won't pass, of course
darbelo I only tried the fakecutable/REPL
And only did very basic stuff there, multiplied vectors, etc. 18:42
darbelo barely recalls any MATLAB
whiteknight the hardest part about Matlab to reproduce is all the syntax, which can be a little weird. 18:44
I think Matrixy faithfully reproduces the whitespace handing, and the function dispatcher is working well too 18:45
next big steps are variadic input/output arguments, and then supporting Cell arrays
and structures
once that's done, syntax is mostly complete and we can write all the rest in M itself 18:47
darbelo self-hosting++ 18:49
nopaste "darbelo" at 200.49.154.173 pasted "matrixy test output." (29 lines) at nopaste.snit.ch/18374 18:50
18:50 desertm4x joined
darbelo Seems to work, but I don't know where that "error: Direct creation of Iterator" is coming from. 18:51
whiteknight that is weird. Never saw that error before 18:52
and more tests should have run, there are like 2 dozen test files
oh, did you make test?
darbelo nope, just ran individual test files. 18:53
whiteknight oh, okay 18:54
ah, I know. These files come from before the iterators refactor by bacek++ 18:55
so we're using the wrong syntax for some of our helper functions somewhere
need to replace all "new 'Iterator'" to use "iter" opcode
darbelo I haven't fixed the harness yet. So, make test fails horribly, but I probably can do that today. 18:56
whiteknight src/internals/stdio.pir contains a few instances of "new 'Iterator'" that need to be fixed 18:58
darbelo src/builtins/sum.pir has another one. 18:59
whiteknight those are the ones probably borking up the test output
yeah, just goes to show how old some of this code is
darbelo And yet, it worked with minor tweaks. 19:00
It's a nice change from breaking partcl and rakudo every week.
19:00 Ron joined
whiteknight we definitely need to write proper bindings for CBLAS and CLAPACK in parrot-linear-algebra first 19:04
We might also want to have bindings for GSL as well
I don't know what all libraries people might want, or what's sticktly "in scope" 19:05
darbelo dukeleto had ideas about that.
whiteknight ...and he's probably on a plane now
there are a lot of ways we could go about it, even if we just look at CBLAS 19:06
like we could create a matix PMC type that contains bindings for all the CBLAS routines internally, as methods and stuff 19:07
or we could provide raw NCI bindings and a dumb PMC type and let the PIR programmers worry about the details
desertm4x I would prefer the first one. 19:08
But actually, one of the things that worries me most is the fact that there are lots of different types of matrices (even having different packing formats). 19:09
whiteknight right, that's what I'm worried about 19:10
the average user might not know whether they have a diagonal matrix, or a hermitian matrix, etc. And then nothing gets dispatched to the correct functions
of course, most of them are optimizations 19:11
19:12 bacek joined
darbelo handling sparse matrices gracefully is more of a need thatn an optimization for matrixy. 19:12
whiteknight Matlab syntax does require sparse matrices
desertm4x yes, but general sparse matrices are a bit out of scope as they are not well supported by LAPACK
whiteknight so we could end up with a few PMC types: 2DNumber, 2DComplex, 2DSparseNumber, 2DSparseComplex, etc 19:13
desertm4x: true. Of course, we could provide translation routines Sparse<->Dense
desertm4x Yes, that's actually what MATLAB does when multypling a sparse matrix and a dense matrix, for example, I think. 19:14
whiteknight So all the LAPACK bindings could convert automatically
right
desertm4x What I wanted to say is that we need a different library for sparse matrices and that this is probably not the first step, though we should consider it when thinking about the data types, etc. 19:15
whiteknight do libraries for that exist?
nevermind, ACML 19:16
desertm4x Well, MATLABs implementation for sparse matrices is proprietary, I think, but I do not know exactly.
whiteknight me either 19:18
darbelo Octave has sparse matrices, we could take a look at that. 19:19
whiteknight Yes, I really should look more at the Octave source for some of these things
I don't want to steal from them wholesale, but it would be nice to see how they do it 19:20
PerlJam You could look at how PDL does its magic too 19:22
whiteknight I always forget about PDL
but I suspect they are using a lot of XS evilness that I don't want to deal with
PerlJam could be.
darbelo "XS: evilness that I don't want to deal with." 19:23
19:24 ash_ joined
dalek rrot-plumage: 483e9e1 | japhb++ | :
[CORE] Glue.pir: Add append() I/O function; Util.nqp: Add set_from_array...
 19:30
whiteknight Matrixy currently stores everything in nested ResizablePMCArrays. And for every BLAS call has to rearrange those data items into a dumb buffer for the function call and then ack out again afterwards
dalek rrot-plumage: 10a25e1 | japhb++ | :
[plumage] Dep. handling 3: Remember installed projects; use them to reso...
shorten dalek's url is at xrl.us/bfs5bf
shorten dalek's url is at xrl.us/bfs5bh
whiteknight at the very least we want a solution that doesn't have these algorithmic problems 19:31
darbelo Ouch. 19:32
whiteknight right
so I'm thinking we do two things: (1) PMC types that implement buffer storage, use BLAS library calls to implement some VTABLEs, and add a few methods as well as necessary 19:33
19:33 Zak joined
whiteknight and (2) proper NCI bindings for PIR so other people can play with those if they are interested 19:33
since LAPACK calls are going to be tricky, we will probably want to keep them as bindings and not integrate them into the PMC directly 19:34
desertm4x Yes. 19:35
whiteknight otherwise we would end up with a PMC type that has hundreds of methods, or something equally lousy 19:36
darbelo We should leverage the vtable interface as much as possible there. Methods have a speed penalty. 19:37
whiteknight very true. VTABLE_add, VTABLE_multiply, VTABLE_divide would all be good to implement directly
VTABLE doesn't really have a good interface for specifying rectangular coordinates though 19:38
brb 19:39
19:39 zerhash joined 19:42 whiteknight joined
whiteknight back 19:43
darbelo Say, have you given any thought to plot()? 19:44
whiteknight we should probably decide which libraries we want to target
darbelo: no. Not at all
none of that graphics stuff is going to be doable for a while 19:45
darbelo is all about the pretty pictures.
;)
whiteknight yeah
desertm4x =)
whiteknight well, I think moritz was doing some cool SVG libraries for Perl6, so we could import his library
and I know proper Tk bindings are in the pipeline somewhere 19:46
Octave taps into GNUPlot, so maybe we could do the same 19:47
desertm4x Concerning the matrix PMC, CBLAS is the only option. Using LAPACK within the PMC is not a good idea, in my opinion (though I do not have any experience about what is good and bad when talking about PMCs). 19:50
19:50 joeri left
desertm4x We may also should think about implementing a separate vector PMC, especially to avoid confusion about norms. 19:51
whiteknight desertm4x: Right, but which BLAS implementation do we want to use? CBLAS? ATLAS? GSL?
vector PMC would be very very good, so long as we had a solid way to convert 19:52
or a PMC with an "is_vector" flag
because we need row and column vectors
19:53 pnate joined
desertm4x Yes, but that could also be a "transposed" flag or we could implicitly treat it as a vector if either the number of rows or columns is 1. 19:53
ash_ i think there is an issue with make test on at least OS X 10.6.1, with a fresh checkout, the first time i run it, it gives me an error, is this a known issue? for some reason if you run make test again, it works fine, but the first time it gives me an error 19:56
darbelo ash_: Can you nopaste the error?
19:57 mikehh joined
desertm4x Do we need to decide which BLAS implementation we use? Can't we detect the one that is available if one is available? 19:57
darbelo I'd go for cblas.
whiteknight if we can detect, that would be best 19:58
ash_ darbelo: nopaste.com/p/a8EsOqgAl
whiteknight but then we would need to add in checks to the configure/build process
darbelo GSL is a lot more than a BLAS, and I don't have anything other than those two on my platform ;)
ash_ pnate had the same issue, paste.lisp.org/display/88921
whiteknight so let's come up with a Configure.pl script that attempts to detect CBLAS. Once we have that, we can try to extend it to discover other implementations as well 19:59
desertm4x Sounds good to me. 20:00
darbelo +1
purl 1
darbelo purl: die in a fire. 20:01
purl HALP
darbelo ash_: That's one odd failure. Can you open a trac ticket for it? 20:02
ash_ sure 20:03
its happened on 2 OS X 10.6.1 computers, don't know how long its been going on, we both had the trunk checked out too
whiteknight okay, I think CBLAS is a good bet then 20:12
desertm4x Yes, I think it's widely-used as well. 20:13
20:15 kurahaupo joined
whiteknight ok. I think that's enough information for us to really get started 20:16
which is good, since I have to pack up and go home now
desertm4x Yes, in the long term we still should think about matrix types and sparse matrix formats, but a dense full matrix type is the thing we need first anyway. 20:17
whiteknight true
tonight I'll update the README file, and then create a CREDITS file where we can all "sign in" 20:18
kurahaupo desertm4x: How does a tensor differ from a fixed-size numeric array?
whiteknight tensor is more then 2D
kurahaupo (Yes, that's why I said "tensor" rather than "matrix" or "vector") 20:19
darbelo throws his colection of 1D tensors away.
moritz actually a tenso is a mathematical object that follows certain transformation properties
*tensor
whiteknight Okay, I am signing off and heading home. Talk to you guys later
moritz so not every matrix is a tenso
r
but there are also 3-dim tensors
kurahaupo moritz: point taken 20:20
purl Hey, give that back!
desertm4x kurahaupo, so you are interested in differences between a matrix and a fixed-size numeric array? 20:25
dalek TT #1123 created by ash.gti++: Make Test errors on OS X 10.6.1 20:29
kurahaupo ļ»ædesertm4x: yes please. Have been looking at the implementation of arrays and realising that variable-sized arrays are bad for thread-safety vs performance 20:30
(fixed-sized arrays are better, but only if we "do it right") 20:32
dalek ose: r186 | Austin++ | trunk/ (18 files):
Got function marshalling working better.
 20:35
ose: r187 | Austin++ | trunk/src/Slam/Visitors/FunctionMarshalling.nqp:
Got function marshalling working better. (Now with FunctionMarshalling.nqp)
ose: r188 | Austin++ | trunk/ (2 files):
Added NamespaceDefinition - models the input code structure better than
desertm4x I do not know much about fixed-size arrays yet, but internally the data is stored similarly. The matrix allows more types than there are fixed-size arrays for, as far as I can see, for example. And operations are defined quite differently. I do not see too much these containers have in common actually, but maybe I'm just missing your point. 20:36
dalek ose: r189 | Austin++ | trunk:
Ignoring close.cfg now that close_cfg.tmpl is working.
 20:39
rrot-plumage: ad0dd7d | japhb++ | :
[plumage] Dep. handling 4: Automatically install project dependencies be...
 20:40
shorten dalek's url is at xrl.us/bfs5ni
japhb I'm thinking that the code that maintains and updates the metadata (basically, server-side stuff) can be in "real" Perl 6, unlike the code that uses the metadata (client-side stuff), which is all in NQP and PIR. Anyone disagree? 20:45
Tene, dukeleto, darbelo: feel highlighted and look up a line.
kurahaupo ļ»ædesertm4x: the internal implementation of a fixed-sized 2D array of number-like things is basically identical to a Matrix, or at least should be if we do arrays right.
moritz japhb: no objections, just make sure are explicit about the Rakudo version you're using 20:46
kurahaupo (The trick is treatment of arrays as *values* rather than *containers*. Which also makes multithreading go faster -- MUCH faster.)
japhb moritz, how do you mean?
moritz japhb: like "current rakudo from git" or "latest release" or "release $xy" or whatever 20:47
it still has incompatible changes occasionally
japhb moritz, Ah, I get it. Yes, understood.
darbelo We target moving targets on top of moving targets ;) 20:52
japhb darbelo, BTW, as of latest commit, you should be able to express the dependency between matrixy and the library project, and plumage will DTRT. 20:53
darbelo japhb++ #Adding new feature for me to break. 20:54
japhb heh
21:14 bluescreen joined
dalek rrot-plumage: 0c082d3 | japhb++ | :
[TOOLS] Add README introducing news tools/ directory
 21:19
shorten dalek's url is at xrl.us/bfs5s6
darbelo Mmmmm, tasty, tasty dog food! 21:25
cotto_work cachegrind has some interesting output 21:26
21:30 cconstantine joined
cotto_work Wow. Looking at Parrot_Sub_get_line_from_pc before those changes, the cache misses are epic. 21:37
I need to buy the valgrind and kcachegrind guys a pizza or something. 21:40
darbelo cotto++ # profiling *after* commiting. 21:41
cotto_work I profiled before committing. I just wanted to see if cachegrind would have helped. 21:42
Answer: yes.
21:43 mokurai joined
darbelo It's a very cool tool. But they aren't getting any pizza out of me until it's ported to OpenBSD ;) 21:44
cotto_work nm. misread
21:44 mokurai left, mokurai joined
dalek kudo: b1ffd35 | jonathan++ | src/classes/Routine.pir:
Epic hack to work around an apparent Parrot register allocation bug. Gets us passing more of wrap.t.
 21:49
shorten dalek's url is at xrl.us/bfs5y4
dalek kudo: aa20505 | jonathan++ | src/builtins/control.pir:
The various other refactors mean that callsame and nextsame can now become way simpler.
shorten dalek's url is at xrl.us/bfs5y6
dalek kudo: 7c28f95 | jonathan++ | src/classes/Routine.pir:
Add comment about why we have the p6i_copy workaround, as suggested my moritz++.
shorten dalek's url is at xrl.us/bfs5y8
dalek kudo: e0c6910 | jonathan++ | src/ (3 files):
Correct our hanlding of package blocks somewhat. They're now immediate blocks, as per spec. This does, along the way, also fix the lexicals and classes bugs.
shorten dalek's url is at xrl.us/bfs5za
dalek kudo: f55aa6f | jonathan++ | src/parser/signature.pm:
Fix for named unicode parameters, hopefully.
shorten dalek's url is at xrl.us/bfs5zc
dalek kudo: b641d31 | jonathan++ | src/binder/bind.c:
Do capture types for invocants. Fixes my last failing test on 32-bit ICU-less.
shorten dalek's url is at xrl.us/bfs5ze
dalek kudo: 3819f41 | jonathan++ | src/binder/bind.c:
Awesomimze the error messages in the new signature binder.
shorten dalek's url is at xrl.us/bfs5zp
dalek kudo: 1d15716 | jonathan++ | :
Merge branch 'resig2'
shorten dalek's url is at xrl.us/bfs5zr
21:53 athomason joined
dalek kudo: fca32d8 | jonathan++ | build/Makefile.in:
Try to unbreak parallel build.
 21:54
shorten dalek's url is at xrl.us/bfs52f
darbelo japhb: ping 21:56
japhb darbelo, pong 22:07
22:07 hercynium joined
darbelo I started playing with the deps in plumage. 22:08
japhb and?
darbelo I caused a failure in the fetching of the dep and the build kept going.
japhb That's odd ... oh, duh, yes, I know why that error was not being transmitted back. OK, will deal with that in a bit, sorry. 22:09
japhb trying to keep toddler from causing major damage to self or house 22:10
darbelo Heh, self is manageable, house is a lost cause.
japhb afk for a while, buit will backlog 22:13
22:19 Whiteknight joined
Whiteknight good afternoon, Parrot 22:23
cotto_work hi Whiteknight
Whiteknight hello cotto_work
I hate Piper and Tweety 22:26
and I don't know how to tell xchat to ignore them forever
cotto_work Window -> ignore list ? 22:27
Whiteknight do I want to block ~robert@x3.develooper.com? 22:29
cotto_work Tweety!*@*.*
As you'd expect, that blocks Piper. 22:30
darbelo Piper was offline for a while, right?
cotto_work wasn't paying attention
22:31 mikehh joined
Whiteknight piper and tweety were both offline for a while 22:31
how do I update my local git repo to match changes made on github? 22:32
darbelo git pull? 22:33
purl git pull is not slow.
darbelo is probably missing something here.
Whiteknight oh damnit, I was in the wrong directory
nevermind
...no, still not working 22:35
darbelo nopaste the error? 22:37
jonathan Note for anyone interested: what's in Rakudo master is now ready to be branched so we can get it running under pcc_reapply. 22:38
I'll probably start looking at that in a day or two if nobody beats me to starting on it. :-)
22:38 kid51 joined
nopaste "Whiteknight" at 69.249.176.251 pasted "git error for darbelo++" (4 lines) at nopaste.snit.ch/18376 22:39
darbelo Whiteknight: try it without the git@... 22:40
just 'git pull'
Whiteknight same error 22:41
darbelo Or with a capital W in Whiteknight. But your local copy should already know where it came from.
Whiteknight it didn't come from github, mine is the original and I pushed to github
darbelo Then try with the capital 'W' 22:42
Whiteknight that did it 22:43
I must be retarded
darbelo github usernames look like they are case sensitve.
Whiteknight I want to set up that in the config, but that's probably a battle for a different day 22:45
22:48 cognominal joined
dukeleto 'ello 22:50
Whiteknight hello dukeleto
dukeleto made it to SFO, after some rain delays 22:51
Whiteknight Can't open perl script "/usr/local/lib/parrot/1.6.0-devel/tools/dev/gen_makefile.pl": No such file or directory
you see that error darbelo? 22:52
22:52 cognominal joined
darbelo Hmm, matrixy? 22:52
Whiteknight yeah, matrixy
oh, I only did make install, probably needed install-dev 22:53
jonathan Forgot to make install-dev ?
damm too slow :)
Whiteknight at was it
dukeleto cotto_work: yes, I was using -j with make 22:56
cotto_work: is -j not working on pcc_reapply ? 22:57
cotto_work dukeleto, no afaict 22:59
I'
d hack on it but I can't commit from here. ;)
dukeleto cotto_work: ok. /me is backlogging 23:00
cotto_work is fat-fingered today
dukeleto is cloning matrixy for the first time, w00t 23:01
first time on this machine, i guess. 23:02
darbelo dukeleto++
23:02 patspam joined
dukeleto really needs to start prepping for the release 23:03
which docs should I be reading? #lazyirc
dalek p-rx: 2188043 | pmichaud++ | src/cheats/regex-cursor-protoregex.pir:
Empty protoregexes return a fail.
 23:04
shorten dalek's url is at xrl.us/bfs6cj
dalek p-rx: 2d1ddd7 | pmichaud++ | src/ (5 files):
Add prefix: and postfix: processing.
shorten dalek's url is at xrl.us/bfs6cm
cotto_work dukeleto, docs/project/release_manager_guide.pod 23:05
dukeleto cotto_work++
23:05 cconstantine joined
cotto_work it's surprisingly easy, if time-consuming 23:07
dukeleto done backlogging. I missed lots of matrixy talk! Vector, Matrices, Tensors, oh MY! 23:09
dalek p-rx: 7574241 | pmichaud++ | src/NQP/ (2 files):
Verify that right associativity is working (it is).
 23:10
shorten dalek's url is at xrl.us/bfs6c8
dukeleto Whiteknight, darbelo: GSL has binding to BLAS built in. if we target GSL, we get those for free, along with 45 other subsystems
Whiteknight this is true
But GSL has a lot of stuff we won't necessarily use 23:11
I think it's the best idea to stick to the BLAS API, and detect multiple implementations like GSL
dukeleto Whiteknight: it has lots of stuff that we might not want in the beginning, but there is probably 10 subsystems or so that we really want
Whiteknight true
dukeleto broken link in release guide: trac.parrot.org/parrot/wiki/ParrotRoadmap 23:12
where should that be?
Whiteknight report 14
hold on
trac.parrot.org/parrot/report/14
dukeleto if anybody has pdates to NEWS, CREDITS, PLATFORMS, RESPONSIBLE_PARTIES, DEPRECATED.pod 23:13
let me know
updates, even
Whiteknight: that link looks the same as trac.parrot.org/parrot/roadmap
Whiteknight: should the first link in the release guide be the same as the first? 23:14
so, should I ask people to stop committing anything non-release-related about now?
at least to trunk 23:15
darbelo dukeleto: probably.
Whiteknight I don't know
dalek p-rx: 29c3519 | pmichaud++ | src/ (4 files):
Add circumfix: .
shorten dalek's url is at xrl.us/bfs6d3
cotto_work dukeleto, I might need to revert something, but yes it'd be a good idea 23:16
for future reference, it'd have been a better idea on Saturday 23:17
moderator Parrot 1.7.0 "African Grey" is coming soon, no non-release-related commits to trunk, please | Test CallSignature PMC | pcc_reapply is almost there! trac.parrot.org/parrot/wiki/Callin...nsOverview 23:20
cotto_work dukeleto, I think that name's been taken 23:21
nm.
dukeleto cotto_work: it isn't in parrothist
darbelo parrothist? 23:22
dukeleto cotto_work: i consulted docs/parrothist.pod
cotto_work parrothist is docs/parrothist.pod
darbelo purl: parrothist is docs/parrothist.pod
purl i already had it that way, darbelo.
Whiteknight urg, we have to fix this test harness 23:23
darbelo Whiteknight: I'm looking at it now-
Whiteknight darbelo++
I just fixed that iterator issue
dukeleto looks like 'bytecode testing framework' and 'prune c data structures' are not happening before tomorrow. should I remove the 1.7 milestone from them?
Whiteknight and added a CREDITS file, which you should sign
cotto_work I really shouldn't be surprised at how long it takes to run rakudo hello world with profiling under valgrind
darbelo Ugh. 23:24
dukeleto 'prune c data structures' is quite an ambiguous TT, no wonder it has been kicked around so much
darbelo Well, we did some pruning. But not enough. 23:25
chromatic was supposed to put some notes on the wiki about that. 23:26
Whiteknight all tests successful Ubuntu 9.04, x86_64
cotto_work darbelo, at least I'm not trying that with Druid. ;)
but yeah, it'll be a while
wow. 20 minutes or so and valgrind dies with a bus error 23:28
darbelo ouch
dukeleto cotto_work: maybe run valgrind on valgrind on ... 23:29
darbelo Or write an x86 emulator in parrot and ... 23:30
cotto_work I don't even want to think about that. 23:32
darbelo It could even self-host! 23:33
dalek rrot: r41943 | dukeleto++ | trunk/docs/project/release_manager_guide.pod:
[cage] Fix Parrot roadmap link in Release Manager Guide
 23:35
mikehh dukeleto: All tests PASS (pre/post-config, smoke (#29194), fulltest) at r41942 - Ubuntu 9.10 (beta updated) amd64 23:37
Whiteknight dalek isn't tracking matrixy commits
at least, it hasn't noticed any of my changes yet tonight 23:38
darbelo Hmm. I added it to the languages page, but it looks like that's not enough. 23:39
Somebody should ping Infinoid about it.
Whiteknight Infinoid: ping 23:40
dukeleto mikehh++ # thanks!
23:43 ash_ joined 23:44 plobsing joined
cotto_work it looks like the profiling optimizations make rakudo less painful to profile. 23:47
probably at the expense of memory 23:48
23:48 payload joined
jonathan Given developers mostly profile rather than uses, I'm not sure that extra memory for faster profiling results is a bad trade-off, unless it's like, unusably more. :-) 23:48
cotto_work: I just landed a big branch in Rakudo. Startup is still really quite slow, though. I'd be really interested to know where we spend our time. 23:49
cotto_work it makes a hash with ~30000 elements for rakudo hello world
jonathan Oh?
Wow.
cotto_work (pointer/int pairs)
jonathan That's kinda...impressive. 23:50
"impressive"
cotto_work basically one per unique pc value
Whiteknight how do I commit to my github repo? Do I always have to do "git push origin master"?
jonathan cotto_work: oh, you mean the profier does
cotto_work: Sorry, it's kinda late her. :-)
*here
cotto_work jonathan, yes
you don't say ;)
jonathan cotto_work: OK, phew. I thought you menat Rakudo makes a hash like that on startup. ;-) 23:51
cotto_work nope. I'm pretty rakudo-agnostic.
dukeleto somebody throw me something that they want to so in NEWS or Changelog
cotto_work "improved HLL profiling" 23:52
s/improved/faster/
dukeleto why is NEWS not in POD, but some other crazy format ?
cotto_work because we've always done it that way 23:53
bacek_at_work Whiteknight, just git push
Whiteknight bacek_at_work: not git dcommit or something like that? 23:55
dukeleto Whiteknight: dcommit is a git-svn thing
Whiteknight: what are you trying to do
cotto_work: that is an explanation, but not a reason ;) 23:56
bacek_at_work Whiteknight, just commit, just push, just git without svn perversions
Whiteknight dukeleto: I'm just trying to figure out workflow
every time I try to commit, it gives me some weird message and I have to git add first
23:57 tokuhirom_________ joined
cotto_work It's an underscore party! 23:57
darbelo Whiteknight: you *do* have to git add <FILE> before commiting. 23:59
or using commit -a

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!