|
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. |
|||
|
00:00
jrtayloriv joined
|
|||
| Whiteknight | darbelo: yeah, that would be awesome too | 00:00 | |
| if we have lots of libraries, we can use plumage to install them | 00:01 | ||
| jonathan | bignums would be liked by Rakudo. | ||
| (people ask if we support them yet now and then) | |||
| darbelo | Sure, plumage already works for decnum-dynpmcs, but I'd like to have big numbers *in parrot* without fhuge exteranl libraries or post install-dependencies. | 00:02 | |
| Whiteknight | jonathan: we'll have much more then that soon | ||
| where "soon" is very relative | |||
| darbelo | Writing it is a pretty big task, but parrot provides a lot of stuff already. | 00:05 | |
| All that's left is the actual numerical coding. | 00:06 | ||
| Whiteknight | right | 00:07 | |
| jonathan | Whiteknight: BTW, the custom binder for Rakudo that I've been working on is coming on nicely. | 00:10 | |
| Whiteknight | custom binder? | ||
| jonathan | Whiteknight: Parameter to signature binder. | 00:11 | |
| darbelo | I'm reasobaly convinced that a PMC using RIAs for 'buckets' and not-really-that-clever algorithms could kick decnum-dynpmcs' ass at integer math. | ||
| jonathan | Whiteknight: So we can bind against Perl 6 signatures directly. | ||
| Whiteknight: It'll get even nicer when we have call_sig :-) | |||
| :call_sig, I mean. | |||
| jonathan is impressed now and then just how many bits of Parrot a language can choose to plug something else in to if it needs to. | 00:12 | ||
| Whiteknight | jonathan: I know exactly how to mplement :call_sig, I want to fix tests on pcc_reapply first though | 00:13 | |
| darbelo | Pluggable everything! | ||
| jonathan | Whiteknight: Oh, sure - and I'm not blocking on it. :-) | ||
| Whiteknight: It'll just be nice when it's there, that's all. :-) | |||
| OK, sleep time... | 00:15 | ||
| cotto_work | clock? | 00:20 | |
| purl | cotto_work: LAX: Tue 5:20pm PDT / CHI: Tue 7:20pm CDT / NYC: Tue 8:20pm EDT / LON: Wed 1:20am BST / BER: Wed 2:20am CEST / IND: Wed 5:50am IST / TOK: Wed 9:20am JST / SYD: Wed 11:20am EST / | ||
| chromatic | Wouldn't it be nice to unify the names of push_float and set_number_native? | 00:24 | |
| cotto_work | + a lot | 00:25 | |
| darbelo | +Inf | ||
| There's a lot of Number/Float confusion in the parrot repo. | |||
| cotto_work | sounds like we need a deprecation notice | 00:26 | |
| darbelo | We allso need to pick the right color for the bikeshed. | ||
| cotto_work hands darbelo a dart | 00:27 | ||
| darbelo throws the dart at the bi-color bikeshed. | |||
| bacek_at_work | cotto_work, we have it already :) | 00:28 | |
| cotto_work, trac.parrot.org/parrot/ticket/866 | |||
|
00:28
rhr joined
|
|||
| darbelo | =item VTABLE nomenclature. [eligible in 1.5] | 00:28 | |
| cotto_work | So it appears we can do it now. | 00:29 | |
| darbelo | That is one big blanket sir. | ||
| chromatic | Do I smell a 1.8 milestone of renaming? Yes we can! | 00:30 | |
| darbelo | Rename everything! Break all languages! Take over *the world*! | 00:32 | |
| cotto_work | hulk smash | 00:34 | |
| chromatic | Hm, CallSignature is already the 18th largest PMC. | 00:48 | |
| darbelo | largest? | ||
| purl | well, largest is picked first | ||
| chromatic | Largest in terms of disk size. At least it's smaller than Capture, .o file wise. | ||
|
00:50
payload joined
|
|||
| darbelo | Hm. I had never actually looked at PMC on-disk sizes before. | 00:50 | |
| chromatic | Everything builds. Let's pass some tests. | 00:52 | |
|
00:59
rhr joined
|
|||
| chromatic | That looks like a success. | 01:01 | |
| dalek | rrot: r41845 | chromatic++ | branches/pcc_optimize_sig (2 files): [PMC] Added Pcc_cell array and counter to CallSignature PMC. |
01:07 | |
| Tene | chromatic: you could add the type indicator flag to the Pcc_cell struct... or is there a reason you're going to store it elsewhere? | 01:10 | |
| cotto_work | chromatic, should your new CallSignature still be extending Capture? | ||
| dalek | rrot: r41846 | chromatic++ | branches/pcc_optimize_sig/t/pmc/callsignature.t: [t] Corrected vtable entry names in CallSignature tests. |
01:11 | |
| rrot: r41847 | chromatic++ | branches/pcc_optimize_sig/src/pmc/callsignature.pmc: [PMC] Refactored CallSignature PMC to store positional arguments in a type-safe CallSignature. Note that the current implementation uses tagged pointers to store type information in a memory-cheap way. It also uses linked lists instead of an array to avoid lots of expensive resizing and copying. Judicious profiling will reveal if either one needs tuning or rethinking. This PMC needs more documentation. Anyone reading this is capable of writing/copying it. |
|||
| treed | holy fuck | ||
| purl | holy fuck is that area dangerous! | ||
| treed | purl, holy fuck is that crazy | ||
| purl | ...but holy fuck is that area dangerous!... | ||
| treed | ... | ||
| chromatic | It extends Capture because I haven't converted away from the Hash yet. | 01:12 | |
| treed | purl, no, holy fuck is that crazy | ||
| purl | okay, treed. | ||
| treed | holy fuck | ||
| purl | i think holy fuck is that crazy | ||
| treed | dammit | ||
| Tene | treed: what's surprising? | ||
| purl | it has been said that surprising is still surprising | ||
| treed | The huge commit memo. | ||
| cotto_work | got it | ||
| Tene | detailed commit messages are good. | ||
| chromatic | If you add 500 lines to a PMC, you'd better write a detailed commit message. | 01:13 | |
| darbelo | purl, no, holy fuck is <reply>That's crazy! | ||
| purl | okay, darbelo. | ||
| darbelo | treed: is that what you were trying to teach purl? | ||
| treed | Nah, I was trying to teach purl to say "Holy fuck is that crazy!" | 01:14 | |
| or s/crazy/$adjective/ | |||
| although that works, too | |||
| Tene | chromatic: you can use the lower three bits like that because it's aligned in memory? | 01:15 | |
| chromatic | Yep. | 01:16 | |
| A compiler stricter than gcc on a platform less lenient than 32-bit x86 ought even to mask off those lower bits when treating it as a pointer, but goodness if that wasn't some weird debugging. | 01:17 | ||
| Whiteknight | we start getting all sorts of SIGBUS on weird platforms, and we know who to yell at | 01:18 | |
| chromatic | Hence I decided to embrace Crazy Macro Fun Time, because hey -- C doesn't have type-safe genericity. | 01:19 | |
| darbelo | Heh. During my (thankfully) brief use of SPARC hardware some years back I used to curse at Linux/x86-32 programmers on a daily basis. | 01:20 | |
|
01:21
kid51 joined
01:22
athomason joined
|
|||
| Whiteknight | type-safe genericity? that's one of those "feature" thingys the perl people are always talking about | 01:22 | |
| dukeleto | Whiteknight: pong | 01:23 | |
| darbelo | Bah! Features are just a different kind of bug. | ||
| dukeleto | darbelo: exactly | 01:24 | |
| Whiteknight | dukeleto: I've already got most of my issues sorted out. | ||
| got two repos on github now! | 01:25 | ||
| Tene | GO WK! | ||
| You'll reach the rank of GIT MASTER any minute now! | |||
| darbelo | Does that mean people can start pulling him? | 01:26 | |
| darbelo pushes the new master :) | 01:27 | ||
| Whiteknight | GIT MASTER? right now I'm shooting for the rank of "GIT doesn't fuck everything up" | 01:28 | |
| not quite there yet, but I'm learning from my mistakes | |||
| dukeleto | Whiteknight: learn to love the directed acyclic graph :) | 01:29 | |
| Whiteknight | yeah, i can feel the love | 01:30 | |
| and on that note, out for the night | |||
| later | |||
| dalek | p-rx: 4d50dbc | pmichaud++ | src/PAST/Compiler-Regex.pir: Adjust zerowidth handling slightly in enumcharlist. |
01:33 | |
| p-rx: 8c37aa5 | pmichaud++ | src/Regex/P6Regex/ (2 files): Refactor backtracking modifiers, add :ratchet modifier. |
|||
| shorten | dalek's url is at xrl.us/bfsaiw | ||
| dalek's url is at xrl.us/bfsai2 | |||
| Tene | pmichaud: is nqp-rx going to fix the zero-width repeated matches bug? | 01:35 | |
| pmichaud | probably | ||
| it should be an easy fix. | |||
| much easier than in pge, at any rate. | |||
| Tene | Okay, thanks for the information. | 01:36 | |
| pmichaud | in PGE it's a real pain to figure out the position where a quantification started. In the new engine, it's actually immediately available at the point of the loop. | ||
| so it should be easy to say "did we advance, if not, fail" | 01:37 | ||
|
01:40
mikehh_ joined
01:45
rhr joined
|
|||
| dalek | rrot: r41848 | jkeenan++ | trunk/docs/book/pir/ch04_variables.pod: Apply patch to documentation submitted in response to posting on list by Vadim Konovalov: trac.parrot.org/parrot/ticket/1104. |
01:46 | |
|
01:55
darbelo left
02:12
tetragon joined,
hercynium joined
|
|||
| dalek | rrot: r41849 | jkeenan++ | branches/auto_libjit (2 files): 1. Following suggestion by Andy Dougherty++, reworked config/auto/libjit.pm it simply says libjit is not found. 2. Move auto::libjit to just before auto::jit. |
02:12 | |
| rrot: r41850 | jkeenan++ | failed to fetch changeset: Merge library_files branch into trunk. Replace EXTRA_TEST_FILES defined in Makefile with @library_files defined in lib/Parrot/Harness/DefaultTests.pm. Cf.: trac.parrot.org/parrot/ticket/1061. |
|||
|
02:23
rhr joined
|
|||
| dalek | TT #1110 created by mikehh++: parrot fails to build with g++ 4.4.1 on Ubuntu 9.10 beta amd64 | 02:28 | |
|
02:29
mikehh joined
|
|||
| mikehh | bah - dropped my internet connection while I was setting up the ticket in trac - had to login again - fortunately most of the info was in my editor | 02:31 | |
| kid51: does the libjit stuff work for amd64 or just i386 as before? | 02:40 | ||
| in other words can I test the branch with amd64 and have any significance | 02:41 | ||
|
02:41
janus joined
|
|||
| kid51 | mikehh: I don't have access to anything 64-bit. So far, I've only tested auto_libjit branch on Linux/i386. | 02:42 | |
| You can test branch on amd64 and see if you duplicate my 'make' failure. | |||
| mikehh | well let me give it a go and see what happens :-} | ||
| chromatic | The pcc_optimize_sig branch could use testing on non-x86 32 bit platforms too. | 02:44 | |
| kid51 | mikehh: I just used your config options on Linux/i386 -- with better results. See TT #1110. | 02:46 | |
| chromatic: Purpose of pcc_optimize_sig branch is ... ? | 02:47 | ||
| chromatic | The pcc_rewiring branch runs one-argument positional function calls 2.5x slower than trunk. | 02:49 | |
| The purpose of the branch is to remove that speed penalty. | |||
| kid51 | What is difference between pcc_optimize_sig and pcc_rewiring branches? | 02:52 | |
| mikehh | kid51: I had no problems building with g++ 4.3 - it is just g++ 4.4 that seems to be a problem | ||
| Tene | kid51: the first is for optimizing the CallSignaure pmc. The second is for implementing and using the callsignature pmc for calling conventions. | 02:53 | |
| kid51 | k. I'll do a Smolder on pcc_optimize_sig on Darwin/PPC. | 02:54 | |
| Tene | kid51: the only test in that branch that matters is t/pmc/callsignature.t | 02:55 | |
|
03:00
plobsing joined
|
|||
| mikehh need to take a break | 03:01 | ||
|
03:04
rhr joined
|
|||
| kid51 | pcc_optimize_sig branch: Darwin/PPC: t/pmc/callsignature.t PASS | 03:12 | |
| kid51 must sleep | |||
| purl | $kid51->sleep(8 * 3600); | ||
|
03:17
s1n joined
|
|||
| dalek | rtcl: 2da712d | coke++ | docs/spectest- (2 files): Spec test run, reclaim last batch of failing tests. |
03:17 | |
| shorten | dalek's url is at xrl.us/bfsawi | ||
| dalek | rrot-plumage: f3eaeb8 | leto++ | : [t] Add tests for exists() and make the harness keep track of total pass... |
03:23 | |
| shorten | dalek's url is at xrl.us/bfsaw9 | ||
| dalek | rrot-plumage: 1c1247d | leto++ | : [t] Add some tests for subst() and refactor the harness a bit |
03:45 | |
| shorten | dalek's url is at xrl.us/bfsa2e | ||
| japhb | dukeleto, hope you don't mind I'm just sitting back and watching the commits roll by, rather than commenting on everything -- you seem to be having fun. :-) | 03:48 | |
|
03:55
plobsing_ joined,
iblechbot joined
|
|||
| dukeleto | japhb: indeed :) | 04:01 | |
| dalek | rrot-plumage: eb31305 | leto++ | : [t] Add tests for join() and split() and detect invalid plans |
04:02 | |
| shorten | dalek's url is at xrl.us/bfsa5b | ||
| Coke | msg allison PGE does NOT build for me. | 04:19 | |
| purl | Message for allison stored. | ||
| Coke | msg allison (it segfaults on pcc_reapply) | ||
| purl | Message for allison stored. | ||
| dukeleto | Coke: do you have a nopaste? | ||
| Coke: which platform? | |||
| purl | I'm running on OS/2 on an Atari, can you help? | ||
| dukeleto kicks purl in the face | |||
| nopaste | "coke" at 72.228.52.192 pasted "useless nopaste for dukeleto++" (1 line) at nopaste.snit.ch/18337 | 04:20 | |
| Coke | dukeleto: linux. | 04:21 | |
| dukeleto | Coke: hmmm. can you do a 'make corevm' ? | ||
| Coke | dukeleto: allison said I didn't have to. =-) | ||
| (yes, corevm make completes) | 04:22 | ||
| dukeleto | Coke: just wondering | ||
| purl | somebody said just wondering was the interpreter itself makes any distinction | ||
| dukeleto | Coke: can you run that command under valgrind? | 04:23 | |
| Coke | dukeleto: fyi, I'm just doing this on feather. | ||
| dalek | rrot-plumage: 407f8ec | leto++ | : [t] Report what invalid plans look like and how many files failed, if any |
||
| shorten | dalek's url is at xrl.us/bfsa69 | ||
| Coke | dukeleto: not easily, due to the sub-makefile. | 04:28 | |
|
04:29
mokurai1 joined
|
|||
| dukeleto | Coke: you should be able to do 'valgrind ../../parrot -o PGE.pbc --output-pbc PGE.pir../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg' from that directory | 04:30 | |
| Coke | dukeleto: after doing two other steps first, yes. | 04:32 | |
| (both adjusted for being run out the wrong dir.) | |||
| dukeleto | who do I have to bribe to get on planet parrot? | ||
| Coke | me, I guess, although the last time I added someone, it didn't stick. | 04:33 | |
| treed | Did I ever appear at all? | 04:36 | |
| dukeleto | msg Whiteknight if you need help moving matrixy to github, let me know | 04:37 | |
| purl | Message for whiteknight stored. | ||
| dukeleto | Coke: i don't show up either, i guess | ||
| dalek | p-rx: b9ea370 | pmichaud++ | src/Regex/P6Regex/Actions.pm: Factor out creation of regex sub for <nibbler> nodes. |
04:44 | |
| p-rx: 3af996e | pmichaud++ | src/Regex/P6Regex/ (2 files): Add regex parameters to named assertions. |
|||
| shorten | dalek's url is at xrl.us/bfsa9m | ||
| p-rx: 9ca78a9 | pmichaud++ | (2 files): Add <before> builtin subrule. |
|||
| shorten | dalek's url is at xrl.us/bfsa9o | ||
| shorten | dalek's url is at xrl.us/bfsa9q | ||
| Coke | dukeleto: it takes some amount of time for it to notice a new feed. | 04:51 | |
| remind me tomorrow, I'll re-ping ask & robrt. | |||
| dukeleto | Coke: ok, I will continue to annoy you tomorrow :) | 04:54 | |
| dalek | p-rx: a3bc5aa | pmichaud++ | (2 files): Add <?> (null) and <!> (fail) assertions. |
04:55 | |
| shorten | dalek's url is at xrl.us/bfsban | ||
| japhb | Man, it is a good night for Plumage, between dukeleto++'s work on the test harness/suite and pmichaud++'s work on nqp-rx. Warms my heart, it does. | 04:57 | |
|
05:05
plobsing joined
|
|||
| dalek | rrot-plumage: 9606ea6 | leto++ | : [t] Test harness can now deal with TAP comments |
05:35 | |
| shorten | dalek's url is at xrl.us/bfsbee | ||
| dalek | rrot-plumage: 1452fd6 | leto++ | : [todo] Add some things that would be nice for the test suite to have |
05:40 | |
| shorten | dalek's url is at xrl.us/bfsbet | ||
|
05:57
JimmyZ joined
06:01
uniejo joined
|
|||
| chromatic | Alrighty, even only that much of CallSignature migrated away from Capture is 14.887% faster. | 06:25 | |
| We create 28.557% fewer PMCs. | 06:26 | ||
| I want to get to 57.114% fewer PMCs. | 06:27 | ||
| That's not even getting rid of CPointer. | 06:29 | ||
| Tene | chromatic: very nice work. | 06:37 | |
| cotto | chromatic, is the next stage to add a Hash* and associated machinery? | 06:38 | |
| chromatic | Yes. | ||
| Well, the next step is to add the elements entry that wouldn't let the other version build, but yes. | 06:39 | ||
| cotto | chromatic, would it make sense to do some/all of this work in Capture? | 06:44 | |
| allison | cotto: it's pretty special-purpose to the CallSignature | 06:45 | |
| that is, it's *typed*, which Capture isn't | |||
| chromatic | What kind of keyed (hashlike) access is necessary? | 06:50 | |
| allison | set keyed, get keyed, and iterate over keys | 06:51 | |
| (which can just be "give me a list of keys") | |||
| really, getting a list of keys would be better than the current way of iterating over the hash | 06:52 | ||
| chromatic | I'm not sure which vtable entry is best for "give me a list of keys". | 06:53 | |
| allison | chromatic: me neither | 06:56 | |
| we can provide a method for PIR access, but that's too slow for access during the call | 06:57 | ||
| chromatic | Iteration it is! | ||
| allison | a function like we use on context will work for C access | ||
| Parrot_get_signature_named | |||
| chromatic: get_iter would also work, but we need iterators for both positionals and named | 06:58 | ||
| chromatic: how about get_attr_str? | |||
| chromatic | I had all of the tests passing on pcc_reapply without making a positional iterator. | 06:59 | |
| allison | chromatic: we're using that for several other PMC pieces of data inside CallSignature already | ||
|
06:59
AndyA joined
|
|||
| chromatic | I didn't add any special iteration support, I mean. | 07:00 | |
| allison | did you have 'elements' returning the number of positional arguments? | ||
| that's what the code currently relies on | 07:01 | ||
| ('elements' on the CallSignature returns the number of positional arguments) | |||
| chromatic | Yes. | 07:02 | |
| allison | for named, the code relies on being able to fetch the internal hash and iterate over it at a very low and very yuckky level | ||
| chromatic | Tests incoming now. | ||
| allison | but, with a list of keys, that could change to something much cleaner, more like the iteration for positional args | ||
| chromatic | I'm going to play the expedience card and make it work with what's there now. | 07:04 | |
| I have no objection to cleaner in the near future. | |||
| dalek | rrot: r41851 | chromatic++ | branches/pcc_optimize_sig (2 files): [PMC] Added elements vtable entry to CallSignature PMC as well as tests. |
07:05 | |
| chromatic | allison, do you know which vtable entries in the Capture PMC iterate over named arguments? | 07:06 | |
| allison | chromatic: none | 07:07 | |
|
07:07
fperrad joined
|
|||
| allison | Capture PMC provides no support for iterating over named arguments | 07:08 | |
| (that's why the code fetches the hash from the CallSignature and iterates over it directly) | |||
| chromatic | Through the hash() method there? | 07:09 | |
|
07:09
iblechbot joined
|
|||
| allison | chromatic: through get_attr_str, for "named" | 07:09 | |
| chromatic: I've avoided calling methods from inside CallSignature | |||
| (speed mostly, but also bootstrapping problem) | 07:10 | ||
| dalek | tracwiki: v15 | kurahaupo++ | ArrayTasklist | ||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfsbkc | ||
| allison | chromatic: got to run to class | ||
| chromatic | Hm. | ||
| That interface is likely to change, because *yergh*. | 07:11 | ||
| allison | chromatic: yes please | ||
| chromatic: worked with what we had, but not pretty | 07:12 | ||
| chromatic: a get_attr_str "named_keys" would be lovely | |||
| chromatic: even if it's stored as a complex string that's split on access | 07:13 | ||
| chromatic | I'm going to return a FixedStringArray because it's simple and... I've read *The Practice of Programming*. | 07:18 | |
| Goodness, I even asked Brian Kernighan about the relevant portion I have in mind. | |||
|
07:19
payload joined
|
|||
| chromatic | We're going to pay O(n) for named access because n < 10 almost almost always here, and I refuse to believe that O(1) here, hash-wise with all of its GCables and iteration and iterator keys, is any cheaper than O(n) for n <= 12. | 07:20 | |
|
07:24
donaldh joined
07:40
donaldh left
07:42
silug joined
08:00
allison joined
08:05
szabgab joined
|
|||
| chromatic | Let me fix GC in the CallSignature PMC and update the 'named' attribute returns with a FixedStringArray, and it's all yours, allison. | 08:10 | |
| allison | chromatic: awesome! | ||
| purl | awesome is, like, a window manager or at awesome.naquadah.org or awesome | ||
| allison | chromatic: free to merge into the pcc_reapply branch? | ||
| chromatic | You'll want to test it first. | 08:11 | |
| 'named' doesn't return a Hash anymore, so your custom iteration there can disappear into something somewhat saner. | |||
| allison | chromatic: aye, and will need to do some code integration | ||
| chromatic | I'm not *quite* certain it's ready to merge, but it's worth inspecting that way. | ||
| allison | chromatic: okay, I'll try it out | ||
| chromatic: if I find anything that's missing, I'll add it as a test in the pcc_optimize_sig branch | 08:12 | ||
| chromatic | Give me about 10 more minutes. | ||
| I'm fixing VTABLE_mark now and VTABLE_destroy in a moment and then a couple of minutes to make 'named' work. | 08:13 | ||
| Otherwise you get a thousand lines of code out of me in a day. | |||
| allison | chromatic: it'll be about 30 minutes before I can get to it | ||
| chromatic | Good. | ||
| Checking in now. | 08:35 | ||
| There are a few interface bits where we might consider exceptions. | 08:39 | ||
| The keyed tests could use some extension as well. | |||
| dalek | rrot: r41852 | chromatic++ | branches/pcc_optimize_sig (2 files): [PMC] Gave CallSignature PMC its own hash component and removed its inheritance Added tests for keyed access. Fixed mark() and destroy() vtable entries for named arguments. Made 'named' attribute access of CallSignature return a FixedStringArray of all named arguments. |
||
| chromatic | There's also no documentation for any of the VTABLE entries I added. | 08:40 | |
| allison | Can add later today | 08:42 | |
| (get it working first) | |||
| time? | |||
| purl | time is 08:34:26 2009 and (did you mean "clock"?) or flowing like a river or the fire in which we burn | ||
| allison | clock? | ||
| purl | allison: LAX: Wed 1:42am PDT / CHI: Wed 3:42am CDT / NYC: Wed 4:42am EDT / LON: Wed 9:42am BST / BER: Wed 10:42am CEST / IND: Wed 2:12pm IST / TOK: Wed 5:42pm JST / SYD: Wed 7:42pm EST / | ||
| chromatic | src/pmc/callsignature.pmc | 914 ++++++++++++++++++++++++++++++++++++++++++++-- | 08:43 | |
| t/pmc/callsignature.t | 247 ++++++++++++ | |||
| 2 files changed, 1121 insertions(+), 40 deletions(-) | |||
| allison | chromatic: figure you're about to drop off, will catch up with you tomorrow | ||
| chromatic: the changes are looking good | 08:44 | ||
| chromatic: thanks! | |||
| chromatic | You should be able to drop in the single PMC file as a replacement and see what happens. | ||
|
08:44
mokurai1 left
|
|||
| allison | yup, I'll just copy it over | 08:44 | |
| and work on the code integration locally | 08:45 | ||
| chromatic | Your VTABLE_get_attr_str(interp, call_obj, "named") will have to change. Otherwise, as far as I know, it's a drop in replacement. | ||
| allison | will check it all in when I get it fitting smoothly | 08:46 | |
| chromatic | Now I'm out. West side. | ||
| allison | catch you later | ||
| allison moves class rooms | 08:50 | ||
|
09:02
allison joined
09:16
allison joined
09:50
bacek joined
10:18
payload joined
10:35
AndyA joined
|
|||
| bacek | o hai | 10:59 | |
| dalek | kudo: 3eceb87 | moritz++ | docs/ChangeLog: [docs] update ChangeLog |
||
| shorten | dalek's url is at xrl.us/bfsb35 | ||
|
11:06
uniejo joined,
kid51 joined
11:31
masak joined
11:33
HG` joined
11:49
whiteknight joined
|
|||
| whiteknight | good morning #parrot | 11:52 | |
| masak squawks happily | 11:54 | ||
|
11:57
bluescreen joined
|
|||
| whiteknight | purl msg dukeleto thanks for the offer. I actually got it loaded onto github last night. I'm sure I'll need plenty of other help later though! | 11:58 | |
| purl | Message for dukeleto stored. | ||
|
12:19
tetragon joined,
dukeleto joined
|
|||
| dukeleto | seems like feather.perl6.nl is down, anybody heard anything? | 12:19 | |
|
12:37
JimmyZ joined
12:46
preflex joined
12:55
payload joined
13:03
Coke joined
|
|||
| Coke | feather is unreachable. | 13:03 | |
| msg allison I didn't use buildframes=0, and feather is now unreachable, so I can't verify. | 13:04 | ||
| purl | Message for allison stored. | ||
|
13:04
ruoso joined
|
|||
| dukeleto | Coke: yes, feather is down right now. i emailed juerd | 13:04 | |
| Coke | I seem to get a lot of admin mail about stef@payrard.net being removed from mailing lists. | 13:08 | |
| stef? | |||
| purl | stef is not you or a purveyor of useless factoids or a mere rumour! or not a mere rumour or cognominal | ||
|
13:09
allison joined
13:22
iblechbot joined
13:31
dalek joined
|
|||
| Coke | ah, right, I stopped working on osx because I needed an installed parrot. :| | 13:32 | |
|
13:32
jonathan joined
13:33
pmichaud joined
|
|||
| Coke | anyone /installing/ on OS X intel? | 13:34 | |
|
13:41
dukeleto_ joined
|
|||
| dukeleto_ | feather is back up | 13:41 | |
| cognominal | Coke, I am so sorry to not have unsubribed my old email address from these mailings list | 13:57 | |
|
13:57
PerlJam joined
|
|||
| Coke | cognominal: oh, no worries, apparently it happens automatically. =-) | 13:57 | |
|
14:01
PacoLinux joined
|
|||
| dalek | TT #1111 created by coke++: cannot build on OSX/intel with --optimize | 14:03 | |
| TT #49 closed by coke++: install email2trac | 14:06 | ||
| TT #526 closed by coke++: create parrot-devel macport | 14:09 | ||
|
14:11
Psyche^ joined
14:14
coke_ joined
|
|||
| dukelet0 | coke_: seems like that is a 10.4 issue | 14:15 | |
| Coke | dukelet0: quite possible. | 14:18 | |
| care to buy me a new imac? =-) | |||
| dalek | rrot: r41854 | allison++ | branches/pcc_optimize_sig/t/pmc/callsignature.t: [pcc] Adding tests for 'exists' opcodes, needed in pcc_reapply branch. |
14:19 | |
| allison | msg chromatic The code looks good. Slurpy hashes are using the 'exists' vtable function, so need that. I added tests for it, just in case you're up before I get back in an hour or so. | 14:25 | |
| purl | Message for chromatic stored. | ||
| Coke | rant: I shouldn't have to have all this boilerplate make crap. | 14:41 | |
| (in partcl) | |||
| Coke will dynamically generate it, Coke supposes. | |||
|
15:07
payload joined
|
|||
| cotto_work | hio | 15:14 | |
| whiteknight | hello cotto_work | 15:18 | |
| Coke | hio | 15:25 | |
| cotto_work | Does someone want to add exists to chromatic's CallSignature so I can stop being tempted to? | 15:26 | |
| nm. It looks like allison just forgot to update the test plan. | 15:27 | ||
| or not | |||
| cotto_work hopes this isn't indicative of how his day will go. | 15:28 | ||
|
15:30
davidfetter joined
|
|||
| dukelet0 reset his bioclock and got up at 5am this morning. yowzer! | 15:31 | ||
| Coke | is there a gitsquash for something git-only, rather than git-svn ? | 15:38 | |
| (I can do the interactive, but it would be nice to have it strip out things that are already pushed upstream from consideration) | 15:39 | ||
| dalek | rtcl: a4b859a | coke++ | config/makefiles/ops.in: Don't build in one dir and then copy to another dir. already complicated rules to accurately reflect how dynext depends on src/ops) |
15:45 | |
| Coke | (git rebase -i origin ?) | ||
| shorten | dalek's url is at xrl.us/bfsc5h | ||
| dukelet0 | Coke: you probably want git rebase -i master | 15:46 | |
| Coke: or git rebase -i origin/master (which should be the same) | |||
| moritz | not the same | 15:47 | |
| origin (or origin/master) sounds much saner than master | |||
|
15:54
mikehh joined
|
|||
| Coke | much easier than with git svn. =-) | 15:57 | |
| mikehh | trunk - pre/post-config, smoke (#29008) PASS, fulltest FAIL at r41854 (see TT #1102) - Ubuntu 9.10 (beta) amd64 | 15:59 | |
| fulltest (testf, testg and testS) (same tests FAIL, same results) | |||
| t/compilers/imcc/syn/macro.t - Failed tests: 2-4 | |||
| t/compilers/imcc/syn/regressions.t - Failed test: 7 | |||
| rest of fulltest passes | |||
|
16:01
darbelo joined
|
|||
| dukelet0 | moritz: if you are working off of the remote 'origin', then master and origin/master are the same, no ? | 16:03 | |
| moritz: duh, no they are not | |||
| moritz | dukelet0: not if you have local commits that you haven't pushed yet | ||
| dukelet0 | moritz: the local 'master' could be ahead of origin/master | ||
| moritz: yeah, I realized that as I typed it. I blame me being sick :) | |||
| moritz | dukelet0: then get well soon ;-) | 16:04 | |
| dukelet0 | moritz: doing my best to, thanks | ||
| mikehh | pcc_reapply - make smoke (#29009) at r41854 - 10,691 ok, 17 failed, 262 todo, 560 skipped and 0 unexpectedly succeeded - Ubuntu 9.10 beta amd64 | 16:18 | |
|
16:23
bluescreen joined
|
|||
| dukelet0 | mikehh: down to 17 failing tests, nice! | 16:31 | |
|
16:40
bluescreen joined
|
|||
| mikehh | dukeleto - 3 or 4 are missed because t/library/coroutine.t - test died after test#2 - bad plan You planned 6 tests but ran 2. | 16:43 | |
| don't know if it failed in test 3 or after exiting test 2 | |||
|
16:50
mokurai joined
16:59
chromatic joined
|
|||
| dukelet0 | mikehh: still, that is a lot better than where we were 1 or 2 weeks ago | 17:08 | |
| whiteknight | much better | 17:10 | |
| nopaste | "mikehh" at 81.149.189.7 pasted "pcc_reapply branch - summary of failures from make fulltest at r41854" (47 lines) at nopaste.snit.ch/18341 | 17:16 | |
|
17:18
fperrad_ joined
17:21
redbrain joined
17:45
joeri joined
|
|||
| Coke | seen pmichaud ? | 17:53 | |
| purl | pmichaud was last seen on #parrot 16 hours, 16 minutes and 36 seconds ago, saying: so it should be easy to say "did we advance, if not, fail" | ||
| jonathan wonders if that was about regex engine or life outlook | 17:58 | ||
| moritz | lol | ||
| chromatic | I hope regex. I've been forgetting to take regular continuations. | ||
| Coke looks forward to when we can do that. | 17:59 | ||
| jonathan | ooh, chromatic :-) | 18:00 | |
| chromatic: You did a change ot the internals of CallSig PMC, yes? | |||
| Coke was just wondering if pmichaud had had any time to work on porting tcl to PCT, but I seriously doubt it. =-) | |||
| jonathan | chromatic: How are the nameds stored within that? | ||
| chromatic: I got the impression from what you wrote, not as a hash, but more flattened? | 18:01 | ||
| chromatic | They're still stored as a hash right now. | 18:02 | |
| jonathan | chromatic: Ah, OK. | 18:03 | |
| chromatic: That can work for me too. | |||
| chromatic | There are weird semantics to work out doing anything else, so this was the minimal change. | ||
| jonathan | chromatic: nod | 18:04 | |
| chromatic | I changed what the 'named' attribute returns for a CallSig though. It used to return the Hash PMC directly. Now it returns a FixedIntegerArray of all of the known named names. | ||
| jonathan | chromatic: FIA? | ||
| purl | rumour has it FIA is at ctx->constants[interp->current_args + 1L]->u.key | ||
| jonathan | Not FixedStringArray? | ||
| chromatic | I'm sorry, yes. FSA. | ||
| jonathan | ah, phew :-) | ||
| chromatic: That's nice, it saves me needing an iterator. | |||
| Or does it use one internally? | |||
| Coke | message pmichaud in nqp-rx, wouldn't it be faster to compare the single position against an ord, rather than doing a single-char substring? | 18:05 | |
| purl | Message for pmichaud stored. | ||
| jonathan | (That is, is there an FSA internally, or one is creted for me?) | ||
| Coke | msg pmichaud (looking at the pir generated for the simple 'abcde*f' example - though no doubt that would start to get wonky for unicode) | ||
| purl | Message for pmichaud stored. | ||
| chromatic | It's created for you. You can destroy it if you want. | 18:06 | |
| jonathan | chromatic: I probably don't need to do that, was just curious it it was meaning yet another PMC created. | 18:07 | |
| The fewer PMCs we've gotta create to bind a signature, the better. | |||
| If there are no named args, what do I get? | |||
| Empty array, or Null PMC? | 18:08 | ||
| chromatic | Good question. | ||
| purl | Yeah, it is. I'm stumped. | ||
|
18:08
mikehh joined
|
|||
| pmichaud | Coke: which part of nqp-rx are you referring to? | 18:08 | |
| chromatic | You get PMCNULL, jonathan. | ||
| Coke | ./p6regex --target=pir > abcde*f | 18:09 | |
| chromatic | I'm not sure if that's right, but that's how I handled it right now. | ||
| pmichaud | Coke: are you referring to the 'e' and 'f' tokens? | ||
| that for single-character strings an ord might be quicker? | |||
| Coke | yes. | ||
| pmichaud | it's a good thought. Do we know that ord comparisons are faster than substring + string compare? | 18:10 | |
| and is it a frequent enough operation to make a difference? | |||
| Coke | ISTR having tested that at some point in the past, but having someone do a benchmark would be instructive. (not you or me.) | ||
| well, in that sample it is. =-) | |||
| pmichaud | I mean, how often do we do single-character comparisons? ;-) | 18:11 | |
|
18:11
KatrinaTheLamia joined,
Util joined
|
|||
| Coke | just something to keep in mind in later optimizations. | 18:12 | |
| pmichaud | sure. | ||
| a bigger optimization will be quantifications of things like \\w, \\s, etc. | |||
| PGE optimized those into single opcodes, nqp-rx doesn't do that yet but I'm planning to enable it in the future. | |||
| jonathan | chromatic: I approve of PMCNULL there. | ||
| chromatic | I'm sure ord is faster than substr + strcmp. | 18:13 | |
| jonathan | chromatic: Because it'd kinda suck to create a PMC to then check is empty and throw away straight off. | ||
| Coke | pmichaud: in the generated PIR, what's the .lex for? | ||
| (same example from the STATUS) | |||
| pmichaud | the cursor is lexically available as $Ā¢ . | ||
| part of the S05 specification. | |||
| just like the match object will be available as $/ | 18:14 | ||
| it doesn't matter in this particular example, but when we have nested closures it will be important | |||
| Coke | k | ||
| also, 'make test' fails for me, presumably because there's a (wrong) path to parrot in the .t shebangs. | 18:15 | ||
| pmichaud | yes, probably. | ||
| I haven't quite figured out how to handle that for installed parrots yet. | |||
| and at the moment there's only one .t :) | |||
| chromatic | jonathan, even at 1:15 am I handled that case correctly. I'm getting good at PMCs. | 18:16 | |
| jonathan | chromatic++ | ||
| :-) | |||
| moritz | can't you just use prove --exec $(PARROT) t/file.t | ||
| in Makefile.in | |||
| pmichaud | that would likely work, yes. | ||
| moritz | and ignore the shebang line | ||
| pmichaud | doesn't help much for running prove from the command line, though. | ||
| jonathan | chromatic: OK, once pcc_reapply lands and we have :call_sig, I'll be able to quite quickly switch to that, I expect. | ||
| chromatic | I think so too. It's pretty straightforward. | 18:17 | |
| Coke | no, but that would fix make test, which is nice. (and .t is slightly better if you assume an installed parrot if you just use #! parrot | ||
| pmichaud | agreed | ||
| I'll undoubtedly make moritz++'s change | 18:18 | ||
|
18:18
msmatsko joined
|
|||
| jonathan | chromatic: Have you assessed performance of pcc_reapply at all? I'm curious what kind of hit - if any - we'll take (or if it'll be a win). | 18:18 | |
| chromatic | I haven't tried with the full CallSig migration. | 18:19 | |
| jonathan | OK. | ||
| chromatic | Still inheriting from Capture and using the Hash component (at least two unnecessary PMCs created for each CallSig), my version was 15% faster. | ||
| I think the migrated version will create some 57% fewer PMCs, though. | 18:20 | ||
| jonathan | My resig branch is making calls and binding params 2-4 times faster at the moment than before I started. | ||
| chromatic | My goal is to double the speed of the branch as currently exists. That gets us within some tuning of trunk. | ||
| jonathan | Ooh, that'll help. :-) | ||
| Ah, OK, so we're lagging trunk ATM. | |||
| But cleaner. | 18:21 | ||
| purl | cleaner is probably with OO (e.g. the planet one thingy) | ||
| pmichaud | jonathan: yes, by about 2x | ||
| jonathan | Ouch. | ||
| But OK. | |||
| That said, if the cost is in the binding, and not in the creation of a :call_sig... | |||
| Erm, of a CallSignature, I mean. | |||
| pmichaud | then Win | ||
| jonathan | And Rakudo is just using the CallSignature | ||
| Then it's a win. | |||
| pmichaud | right | ||
| chromatic | Remember that no one's done any optimization on the branch either. | 18:22 | |
| jonathan | chromatic: Aye. | ||
| chromatic: Same on my one too, really. | 18:23 | ||
| chromatic: Other than optimizations that just come through the overall algorithm/process being more efficient. | |||
| So I figure between potential optimizations in Parrot and potential ones in the new Rakudo binder, we've lots of space for win. | |||
| Coke | potentially related question - how is perl6 going to throw errors about arg mismatches? | ||
| chromatic | slushballs -- no gravel. | 18:24 | |
| jonathan | Coke: Exception. | ||
| purl | exception is A reasonable response to an unreasonable situation. | ||
| Coke | right now in partcl, I basically declare everything as taking a single slurp parameter and then manipulate it myself. | ||
| jonathan | Coke: Rakudo too. :-) | ||
| Coke | (rather than being able to use parrot's exception handling) | ||
| jonathan | Coke: Apart from named slurpy and normal slurpy | 18:25 | |
| Coke: And if there's a problem unpacking it, then I just throw an exception. | |||
| allison | chromatic: PMCNULL is good for no named arguments (cheap) | ||
| jonathan | Woo agreement! | ||
| On pcc_reapply and Rakudo - I suspect Rakudo's C bits will probably need some patching. | 18:28 | ||
|
18:28
AndyA joined
|
|||
| allison | chromatic: I just got settled in for a night's work, do you want me to go ahead and implement 'exists' on CallSignature? | 18:29 | |
| jonathan | However, that patching will be rather different on the resig branch. | ||
| allison | chromatic: looks like that's all I'm missing for a merge into pcc_reapply | ||
| jonathan | Just in case anyone goes ahead and makes the effort on master Rakudo. | ||
| pmichaud | jonathan: I think pcc_reapply won't be landing in parrot trunk before the release. | 18:30 | |
| allison | chromatic: I can work around it, if I know the various get_*_keyed_* operations return PMCNULL when there is no corresponding argument | ||
| chromatic: (which might be cheaper than checking exists a then doing a get anyway | |||
| jonathan | pmichaud: Aye. I was more aiming this at anyone who wanted to test Rakudo against pcc_reapply. | ||
| chromatic | I can add the exists, if you give me 30. | ||
| allison | cool | ||
| jonathan | Like sooner than then. | ||
| pmichaud | jonathan: right | 18:31 | |
| allison finishes eating | |||
| jonathan | Just attempting to minimize waste of resources. :-) | ||
| pmichaud | parrot tends to return PMCNULL for any sort of "non-existent element of aggregate" fetch | ||
| e.g., from Hash or *Array | |||
| allison | pmichaud: some of the old structures still return Undef, so never sure | 18:32 | |
| pmichaud | yes, I'd like to standardize on the PMCNULL behavior | ||
| allison | Undef should probably go away at some point | ||
| jonathan | PMCNULL++ | 18:33 | |
| chromatic | STRINGNULL++ | ||
| jonathan bbiab - food | |||
| pmichaud | in many cases it's easier to just do the fetch and check for PMCNULL than it is to do an explicit existence check beforehand | ||
| allison | pmichaud: it's a good feature to have, even if we don't use it in this particular block of code | 18:34 | |
| Coke | allison: (undef go away), hey, we already removed None... | ||
| allison | pmchaud: (the CallSignature on trunk inherited exists from Capture) | ||
| Coke: definitely progress :) | |||
| Tene | we OBVIOUSLY need to change all uses of Undef to exceptions. | 18:43 | |
| jonathan: have you seen the build failures for rakudo against pcc_reapply? | 18:46 | ||
| jonathan: nopaste.snit.ch/18329 | |||
| dukelet0 | Tene: those look fun | 18:53 | |
| Tene | dukelet0: cardinal and my scheme compiler both compile and pass their tests appropriately on the pcc branch. | 18:54 | |
| dukelet0 | Tene: that is very cool | ||
| Tene: i wonder if Coke has tried partcl on the pcc_reapply branch | |||
|
18:57
kthakore joined
|
|||
| kthakore | chromatic: where is this C stuff!!!! | 18:57 | |
| chromatic | src/pmc/callsignature.pmc | ||
| kthakore | PMC = C ? | ||
| chromatic | preprocessed C, yes. | ||
| jonathan | Tene: The good news: those ones will go away when pcc_reapply rebases against trunk | ||
| Uh, "rebases" ;-) | |||
| Tene: The bad news: even after that, all you'll get is different errors. :-) | 18:58 | ||
| kthakore | chromatic: um sorry I am new to parrot where is the source ? it comes with rakudo right? | ||
| jonathan | (But those ones will actually apply to pcc_reapply ;-)) | ||
| kthakore | win2 | ||
| Tene | kthakore: svn.parrot.org/parrot/branches/pcc...imize_sig/ | ||
| kthakore | Tene: thanks | ||
| jonathan | kthakore: Parrot lives in a separate repository to Rakudo. | ||
| kthakore | jonathan: ah ok | ||
| jonathan | kthakore: Rakudo checks it out when you do Configure.pl with --gen-parrot. | 18:59 | |
| Tene | kthakore: the rakudo configure script has an ... what jonathan said. | ||
| kthakore | Tene: lol | ||
| ok | |||
| thank you | |||
| chromatic: btw major major XS rewrite of SDL has begun. Drop by #sdl some time. I would like to get your thoughts | 19:00 | ||
| chromatic | I browsed your discussion with nothingmuch. I think he's on the right track. I always wanted to make separate .xs files for each subsystem. | ||
|
19:03
msmatsko joined
|
|||
| kthakore | chromatic: thats what we are doing me an acme. ur1.ca/dltk | 19:05 | |
| chromatic: we broke it down to be SDL::* is only bindings to C nothing more nothing less. Because before we where doing to many things with SDL::* | 19:06 | ||
| cotto_work | Tene, it looks like the branch needs PARROT_MAX_ARGS bumped. That's what I'd expect is causing most of those warnings. | 19:09 | |
| include/parrot/op.h | 19:10 | ||
| Tene | What should I bump it to? | ||
| chromatic | 16? | ||
| purl | i guess 16 is such an easy number to multiple or divide by in my head | ||
| cotto_work | 16, like in trunk | ||
| Tene | lemme try it. | 19:11 | |
| cotto_work | permission granted ;) | ||
| it'll probably still fail, but less noisily | 19:12 | ||
| Tene | cotto_work: nope, still got those warnings. | 19:14 | |
| cotto_work | it was worth a shot | ||
| Tene | should I bump it anyway, to match trunk? | ||
| cotto_work | wouldn't hurt, as iirc rakudo needs it | 19:15 | |
| dalek | rrot: r41855 | tene++ | branches/pcc_reapply/include/parrot/op.h: [pcc] Bump PARROT_MAX_ARGS to match trunk. |
19:16 | |
| moritz | perl6.ops:631: error: āstruct parrot_interp_tā has no member named āreturns_signatureā | 19:24 | |
| that's what rakudo build says when trying to build against latest pcc_reapply | 19:25 | ||
| dukelet0 | do we have any tests for PARROT_MAX_ARGS ? | ||
| allison | moritz: does it have an op that's peeking directly at subroutine returns? | ||
| moritz: perhaps something to do with 'wants'? | |||
| jonathan | allison: Oh, sure it is. :-) | 19:26 | |
| allison | so, that'll just need to be updated to pull the call signature object instead | ||
| jonathan | allison: We muddle into the calling conventions in a couple of places. | ||
| allison: It'll certainly have to change to work on pcc_reapply. | |||
| allison | 'returns_signature' is no more | 19:27 | |
| jonathan | allison: Aye. | ||
| allison: That's fine, I saw this lot coming. Things should get a *lot* neater too. :-) | |||
| Tene | jonathan: would it be possible for you to make a rakudo branch that's updated to use pcc_reapply? | 19:29 | |
| allison | Tene: that could help us make sure there aren't unexpected problems | ||
| Tene | jonathan: I'd really like to know that rakudo can work against pcc-reapply, or if not, find and fix the problems. | ||
| jonathan | Tene: I will, but given (a) pcc_reapply won't land before 1.7 and (b) I've got my hands rather full with the resig changes, which heavily influence this, I don't think it's wroth doing for a couple of days yet. | 19:30 | |
| Tene | Okay, thanks. | ||
| jonathan | Tene: Once resig lands in trunk, I'll work on a branch to get it working against pcc_reapply though. | ||
| erm, lands in master :-) | 19:31 | ||
|
19:42
cconstantine joined
|
|||
| kthakore | um | 19:43 | |
| parrot fails to compile | |||
| oops no rakudo does | |||
| mutablevar.c:99: warning: implicit declaration of function | 19:44 | ||
| make: *** [src/pmc/perl6_group.so] Error 1make: *** [src/pmc/perl6_group.so] Error 1 | |||
|
19:50
kthakore joined
19:51
mokurai joined
19:53
AndyA joined
20:05
bacek joined
|
|||
| pmichaud | phone | 20:06 | |
| kthakore | it seems to work now | 20:15 | |
| pmichaud: my phone is not ringing :P stop trying to trick me | 20:16 | ||
| chromatic | allison, I have a question about the 'exists' tests for CallSig. | 20:38 | |
|
20:40
joeri left
|
|||
| Tene | kthakore: mail | 20:41 | |
| kthakore | Tene: whut? I have no mail why you lie ... | 20:42 | |
| Tene | hehehehehe | 20:43 | |
| chromatic | kthakore: pants | ||
| kthakore | chromatic: why you trying to get my pants off?!! | ||
| dalek | rrot: r41856 | chromatic++ | branches/pcc_optimize_sig (2 files): [PMC] Added exists_keyed() and exists_keyed_int() VTABLE entries to check for boolean return values, not any specific value. |
||
| jonathan | .oO( must remember to parse pants like an American, not like the Brit I am ) |
||
| chromatic | Now you'll always wonder how I meant it. | ||
| Tene | chromatic: what's your question about callsig exists tests? | ||
| kthakore | jonathan: how does a Brit parse pants? | 20:46 | |
| chromatic | Tene, I modified the tests; instead of checking for truthiness returned from exists_keyed or exists_keyed_str, they checked for specific values of truthiness. | ||
| jonathan | kthakore: In British English, pants is what you wear underneath what Americans call pants. ;-) | 20:47 | |
| kthakore | jonathan: that just made it worst | ||
| worse | |||
| Tene | I don't know of any reason pcc would want specific values back from exists. | ||
| kthakore | jonathan: I thought thats what underpants was | ||
| moritz | AE pants = BE trousers, no? | 20:48 | |
| jonathan | moritz: right | ||
| chromatic | I don't either. I checked the docs for Capture and they said truthiness, so I changed the tests. | ||
| jonathan | kthakore: In BE we just use "pants" to mean those, normally. :-) | ||
| Tene | chromatic: quick review of pcc diff shows no non-truthy uses of exists. | 20:49 | |
| kthakore | hi moritz | ||
| moritz | \\o/ | ||
| kthakore | moritz: be careful people try to get into your pants here | 20:50 | |
| chromatic | Then the new CallSig PMC on pcc_optimize_sig should work on the pcc_reapply branch. | ||
| Tene | orly? Lemme try it. | ||
| chromatic | I'm trying it too. | ||
| kthakore | ok back to #sdl for hacking ... | ||
| allison | chromatic: you had a question? | 20:51 | |
| moritz | kthakore: no worries, I'm here for for more than 2.5 years already ;-) | ||
| chromatic | Any reason exists_keyed and exists_keyed_str should return anything other than true or false for CallSignature? | ||
| kthakore | moritz: so you are already pants free and just now getting to be open and proud about it | ||
| allison | chromatic: a simple 1/0 is fine, yes | 20:52 | |
| moritz | kthakore: it makes people happy to be proud of what they do - but that pants were your invention ;-) | ||
| jonathan | Oh boy, what have I started. :-) | ||
| cotto_work | You threw a spanner in the works. | 20:53 | |
| Tene | I got "no exists_keyed_str in callsig... realcleaning and rebuilding. | 20:54 | |
| jonathan | It just fell out of me hand and into 'em, sir. Honest. | ||
| kthakore | moritz: Behold I invented PANTS! Bow down to my Awesomeness | ||
| chromatic | Tene, the new CallSig only exists on the pcc_optimize_sig branch. It hasn't merged yet. | 20:55 | |
| kthakore | jonathan: seriously I was going to leave too | ||
| Tene | chromatic: I copied it from that branch to my local branch. | ||
| git checkout pcc_optimize_sig src/pmc/callsignature.pmc | |||
| chromatic | Okay. | ||
| allison | Tene: yes, chromatic is adding the 'exists' feature now | 20:56 | |
| Tene | ah, I missed that. | ||
| kthakore | j #p5p | 20:58 | |
| Tene | if I implement exists_keyed_str, I now get a segfault in parrot_hash_get_idx | 21:02 | |
| chromatic | I already implemented that on the branch. | 21:03 | |
|
21:04
fperrad joined
|
|||
| Tene | chromatic: I see exists_keyed and exists_keyed_int, but not exists_keyed_str | 21:05 | |
| chromatic | Ah, right. | ||
| kthakore | bye guys gtg hom | ||
| home | |||
| chromatic | You have to play the hash_key games that set_integer_keyed_str does. | 21:06 | |
| nopaste | "tene" at 97.117.62.135 pasted "eks for c" (22 lines) at nopaste.snit.ch/18344 | ||
|
21:06
allison joined
|
|||
| chromatic | That should do it, Tene. | 21:06 | |
| nopaste | "tene" at 97.117.62.135 pasted "the next error I get is a segfault because of this code:" (4 lines) at nopaste.snit.ch/18345 | 21:07 | |
| allison | Tene: I've already fixed that | 21:08 | |
| Tene: will check it in when I merge chromatic's code in | |||
| Tene | Okay. Nevermind, then. | ||
| allison | chromatic: my irc client dropped off for a bit there | ||
| chromatic: ready to copy over? | 21:09 | ||
|
21:09
Austin joined
|
|||
| allison | Tene: (that was the old low-level hash iteration, which isn't necessary any more with the nice new implementation) | 21:09 | |
| chromatic | It's ready to merge, yes. | 21:10 | |
| You should run the tests too, but I have confidence. | |||
| allison | okay, trying now | ||
| Tene goes back to real work. | 21:11 | ||
|
21:15
payload joined
|
|||
| allison | chromatic: works fine in pcc_optimize_sig, but still getting "exists_keyed_str() not implemented in class 'CallSignature'" in pcc_reapply | 21:23 | |
| chromatic | Alright, I'll make a test and such there. | ||
| allison | chromatic: checking to make sure copy was clean | 21:24 | |
| chromatic | I know how to make that work. I need food first though. | ||
| Just for fun, here's a 2.59% optimization on pcc_reapply. | |||
| I have another similar optimization in the works. | |||
| allison | chromatic: the weird thing is, I copied over the tests (passing on pcc_optimize_sig) and the two I added are failing on pcc_reapply | 21:25 | |
| chromatic | That is weird for sure. | ||
| dalek | rrot: r41857 | chromatic++ | branches/pcc_reapply/t/src/extend.t: [t] Untodoed test for calling MultiSub from C (r41828). |
21:26 | |
| allison | chromatic: and diff -u says the two files are identical | ||
| rrot: r41858 | chromatic++ | branches/pcc_reapply/src/call/args.c: [PCC] Switched from VTABLE calls with expensive STRING comparisons to direct Parrot_pcc_build_sig_object_returns_from_op(). This improves the fib.pir benchmark by 2.858%. |
|||
| chromatic | Yay, Blazers tickets! | ||
| allison | chromatic: excellent! | ||
| purl | EGG-see-lent! | ||
| chromatic | Preseason and exhibition yes, but free! | 21:27 | |
| allison, it looks like all of the string appending and such to add the return signature is also expensive. | 21:28 | ||
| allison | chromatic: to add the string signature from an op call? | 21:29 | |
| chromatic | Yes. | ||
| allison | chromatic: in theory, we could do away with the string signature if we have the FIA for the signature | ||
| chromatic: but, it'd be nice to get rid of the FIA too | 21:30 | ||
| chromatic: perhaps an integer flag on each array element? | |||
| integer flags, I should say | |||
| chromatic | It looks like all of the string manipulation in Parrot_pcc_build_sig_object_returns_from_op() adds some 7-8% overhead. | ||
| "sheldor is afk" | 21:31 | ||
| allison | chromatic: okay, something to look into | ||
|
21:32
zerhash joined
21:33
Whiteknight joined
|
|||
| Austin | What would cause parrot to just "stop", or at least appear to? | 21:33 | |
| (Of course, with mad cpu usage...) | |||
| Tene | Austin: an infinite loop, of course. | 21:34 | |
| Austin | Sure. But I'm running with trace 1, and if there's a loop, it's internal. | ||
| Tene | yeah | ||
| Austin | As a hint, I'm trying to return from a sub that just updated the namespace it was called from. | 21:35 | |
| Hey. Tene, was it you that had the export/import code for parrot? | |||
| Tene | Austin: yes. | 21:37 | |
| Whiteknight | a sub is changing the namespace it's located in? | ||
| Austin | I borrowed some of that, but I had to hack it some. I needed to just import an already-loaded namespace, not load any bytecode before hand. I was just shortening names in nqp. | 21:38 | |
| Whiteknight, yes. I've got a sub that creates and compiles a set of multimethod trampolines. As a result, when you call it, it adds one entry to the calling namespace. | 21:39 | ||
| Tene | Austin: if you're up for it, the 'parrot' language could use a "have I loaded this bytecode?" cache. | ||
| Austin | Tene: maybe so. But mine was just "this is already loaded. bring the names over here, so I don't have to qualify them." | 21:40 | |
| allison | chromatic: so, apparently, there's no way to call 'exists_keyed_str' from PIR | ||
| chromatic: there's no op version that calls it | |||
| Whiteknight smells a new opcode a'cookin' | |||
| dukelet0 loves me some deep fried opcodes | 21:41 | ||
| allison | Whiteknight: well, the PIR syntax is "$I0 = exists $P1[$I2]" or "$I0 = exists $P1[$S2]", which create an integer key or string (regular) key | 21:42 | |
| the keys are PMCs | |||
| Tene | Austin: there's a method on the Namespace PMC to do that. | ||
| Austin | Tene: Typing "close::Compiler::Debug::Note(...)" was 'teh suck' | 21:43 | |
| Tene | allison: I posted a patch to add that. | ||
| nopaste.snit.ch/18344 | |||
| allison | Tene: to add "exists $P1, $S2"? | ||
| Austin | Yeah. It needed some snazz, which you had put in the exporter stuff. | ||
| allison | Tene: cool, adding now | 21:44 | |
| Tene | I didn't want to commit in the middle of you and c working on it. | 21:48 | |
| allison | Tene: that patch is good | 21:49 | |
| Tene: now I've got Segfault in mark_hash at callsignature.pmc:316 | |||
| Tene | That code looks a little weird. You'd think that the b increment should be in the loop. | 21:51 | |
| chromatic | Hm, it shold. | ||
| Tene | allison: does that fix it for you? | 21:53 | |
| allison | Tene: a return at the top gave me a quick fix, will move the b increment inside the loop | 21:54 | |
| chromatic | Any idea how to test the exists_keyed_str variant? | ||
| allison | chromatic: apparently there is no way to do it from PIR | 21:55 | |
| chromatic | I don't see one either. Pity. | ||
| allison | yes, it is | 21:56 | |
|
21:56
darbelo joined
|
|||
| allison | chromatic: okay, I've got it to the point where the shiny new CallSignature is only failing 1 more test than the old CallSignature, so I'm checking it in | 21:59 | |
|
21:59
cconstantine joined
|
|||
| allison | (we can fix that one test after) | 21:59 | |
| chromatic | Hang on, I fixed a bug. | ||
| r41859 would be good to include. | 22:00 | ||
| allison | chromatic: commit already made, but can copy the fix over | 22:02 | |
| dalek | rrot: r41859 | chromatic++ | branches/pcc_optimize_sig/src/pmc/callsignature.pmc: [PMC] Fixed hash marking in CallSignature PMC, with credit to Tene for |
||
| rrot: r41860 | allison++ | branches/pcc_reapply (3 files): [pcc] Merge in the fast new internals of CallSignature PMC from tests. |
|||
| Tene | allison: I'm checking in the speedup part of r41859 to pcc_reapply. | 22:05 | |
| dalek | rrot: r41861 | tene++ | branches/pcc_reapply/src/pmc/callsignature.pmc: [pcc] Minor speedup copied from r41859 |
||
| allison | ah, somebody beat me to it | 22:06 | |
| (I had already applied moving b->next into the loop earlier | |||
| Tene | I'm going to time a test run in r41855, and then with current. | ||
| chromatic | Looks like about a 20% improvement to me. | 22:11 | |
| jonathan | Whee. | 22:12 | |
| That's pretty good. | |||
|
22:12
Limbic_Region joined
|
|||
| chromatic | We need more, but I'm chipping away. | 22:13 | |
|
22:13
mokurai left
|
|||
| dalek | rrot: r41862 | allison++ | branches/pcc_reapply/src/pmc/callsignature.pmc: [pcc] Add a missing vtable function to CallSignature and reclaim the one extra |
22:15 | |
| purl | well, failing test is with rev. 38923 | ||
| allison | purl: forget failing test | 22:16 | |
| purl | allison: I forgot failing test | ||
|
22:19
jrtayloriv joined
|
|||
| nopaste | "tene" at 97.117.62.135 pasted "old callsig vs new callsig" (17 lines) at nopaste.snit.ch/18346 | 22:21 | |
| chromatic | About 20% then. | 22:23 | |
| Hm, actually closer to 13% there. | |||
| Tene | well, that's all of "make test" | 22:24 | |
| chromatic | Right. | ||
|
22:25
patspam joined
|
|||
| Tene | my pcc-parrot right now takes 1.065s on oofib.pir, while trunk-parrot takes 0.465s | 22:26 | |
| so we're down around the range of 2x vs trunk | |||
|
22:27
Whiteknight joined
|
|||
| dalek | rrot: r41863 | allison++ | branches/pcc_reapply/src/pmc/callsignature.pmc: [pcc] Reordering a few CallSignature vtable functions to match the grouping of |
22:28 | |
| rrot: r41864 | chromatic++ | branches/pcc_reapply/src/call/args.c: [PCC] Rearranged tests for exceptional condition in No functional changes. |
22:48 | ||
| rrot: r41865 | chromatic++ | branches/pcc_reapply/src/call/args.c: [PCC] Swapped a VTABLE call with a macro to set CallSignature's arg_flags in the fib.pir benchmark. |
|||
| darbelo | japhb: ping | ||
| dukeleto | Coke: planet parrot still has no love for me | ||
| the fact that smolder reports expire kind of irks me | 22:49 | ||
| darbelo | diskpace is cheap, but not *that* cheap. | 22:50 | |
| dukeleto | darbelo: yes, but IIRC, that is not configurable in smolder. perhaps it is now, i haven't looked at the source in a while | 22:51 | |
| Tene | dukeleto: I can always make more for you if you'd like. | ||
| dukeleto | Tene: more reports? that doesn't help when a random person submits a smolder report from an exotic platform and then it just goes away after an unspecified amount of time | 22:52 | |
| Tene | dukeleto: oh, so you want *useful* feedback. | ||
| chromatic | Hm, I removed all of the string_sig from Parrot_pcc_build_sig_object_returns_from_op and all (expected) tests still pass. | 22:54 | |
| mikehh | got to re-boot bbiab | 22:55 | |
| dukeleto | Tene: only sometimes :) | 22:56 | |
| allison | chromatic: as I said, we can actually eliminate the string sig once we have the FIA sig | ||
| chromatic: the string sig is there for introspection, but could be built on request from the FIA | 22:57 | ||
| chromatic | There's a 10.093% speed improvement from removing it. | 22:58 | |
| allison | (the early code iterated over string sigs for arg/param handling, but the current code iterates over FIA instead | ||
| chromatic | Nothing I can tell inspects the return sig. | ||
| allison | chromatic: excellent, ditch it | ||
| japhb | darbelo, pong | 22:59 | |
| allison | chromatic: introspection is a user-accessible feature of the PMC | ||
| chromatic: it's the get_string vtable function | |||
| darbelo | japhb: How smart should plumage be about dependencies? And how smart is it now? | 23:00 | |
| chromatic | Sure, I can't remove the signature altogether. | ||
| I only removed appending the return signature. | |||
| allison | chromatic: but, you can avoid building it until it's needed | ||
| chromatic | The next big win is getting rid of all of those CPointers. | ||
| ... but I have a train to catch. | 23:01 | ||
| japhb | darbelo: currently, you can hear the wind whistling through the cavernous space where its brain ought to be. | ||
| dalek | rrot: r41866 | chromatic++ | branches/pcc_reapply/src/call/args.c: [PCC] Removed return signature string handling from produces a 10.093% performance improvement on the fib.pir benchmark. |
||
| darbelo | I kinda expected that :) | ||
| allison | chromatic: if you save 10% with the returns signature, can you save another 10% with the args signature? | ||
| japhb | In the future: as smart as we can possibly make it, but iterating up from current. In other words, I don't want to get all architecture astronaut on the dependency design. (more) | 23:02 | |
| dukeleto | chromatic: looks like I should run a fib.pir benchmark across released parrot versions | ||
| allison | chromatic: catch the train, will catch you tomorrow | ||
| japhb | It's important to have something working ASAP, because people (including me) want to port over proto's projects. (more) | ||
| darbelo | proto? | ||
| purl | proto is to start at the lowest and use the first available. The client should be configurable. or github.com/masak/proto/tree/master | ||
| darbelo | oh, that. | 23:03 | |
| japhb | And from there, we can keep adding smarts and iterating on the dependency handling pretty much as long as we want. | ||
| Like Perl, we want Plumage to eventually feel like an extension of your will, not something that annoys the hell out of you (like, say, yum). | 23:04 | ||
| dukeleto | japhb: so what are the next steps for plumage? | ||
| japhb | dukeleto, glad you asked, I was just about to start talking about that. ;-) | ||
| For me, the two main avenues for immediate work are 1) basic dependency handling -- what we just talked about. 2) starting work on the metadata server. | 23:05 | ||
| I have already gotten a donation of server space/cycles to prototype the latter. | 23:06 | ||
| darbelo | I just got a simple dep-tracking use case. | ||
| japhb | (moritz++ for that) | ||
| darbelo, do tell. Maybe it will be a good starting point. | |||
| darbelo | Whiteknight moved matrixy (his MATLAB on parrot) to here github.com/Whiteknight/matrixy/ | ||
| japhb | darbelo, yeah, saw his post (well, *a* post on the subject -- he does so many I don't know if I've read whatever is his latest post :-) | 23:07 | |
| darbelo | and he's looking to rip out and make standalone the linear algebra libs that matrixy needs. | ||
| japhb | nodnod | ||
| darbelo | (github.com/Whiteknight/parrot-linear-algebra) | ||
| japhb | I'd like to do the same with OpenGL, but I was leaving off on that for a while because OpenGL is an excellent test for the NCI system | 23:08 | |
| OK, so we want to just start supporting that simple one-level dependency? | |||
| darbelo | So, we have 'matrixy' depends-on 'parrot-linear-algebra' | 23:09 | |
| Which is about as straighforward as it gets, but once that works we can build up. | |||
| japhb | All right. Can you commit metadata files for both of those, and I'll make it a priority to hash out a design for handling it properly? | ||
| darbelo | Looking into it now. Will probably need some work on the language itself before it reaches 'buildable'. | 23:11 | |
| japhb | Sure ... but is the library buildable against install-dev parrot? | 23:12 | |
| Even if matrixy itself fails to build, we need the dependency to successfully build in order to test the dep handler properly | 23:13 | ||
| darbelo | Not right now, from what I can see. | ||
| japhb | Got cycles to fix that? ;-) | ||
| darbelo | Diving in as we speak. | ||
| dukeleto | did someone say linear algebra? | 23:14 | |
| darbelo | :) | ||
| dukeleto gets excited | |||
| japhb | awesome | ||
| darbelo | dukeleto: github.com/Whiteknight/parrot-linear-algebra | ||
| dukeleto | darbelo: just saw that! | ||
|
23:14
dolmen joined
|
|||
| darbelo | fortran_helpers.pir | 23:14 | |
| japhb | Now I won't have to write all that when I finally pop a few yaks off my yak shaving stack and get back to 3D fun | ||
| dukeleto | i talked with particle last year about efficient linear algebra routines for parrot | ||
|
23:15
plobsing joined
|
|||
| darbelo really wants to see all sorts of numerical stuff on parrot. | 23:16 | ||
| dukeleto | like, we need an efficient matrix PMC. and if you want to do 'real' linear algebra, efficient PMCs for real and complex matrices | ||
| darbelo: want to help me hack on GSL bindings for Parrot? I promise it will be fun... | 23:17 | ||
| darbelo | Sure, where is it? | ||
| dukeleto | darbelo: in my mind, right now :) But I could have a github repo up in no-time ... | 23:18 | |
| darbelo: i guess it is conceptually similar to decnum-pmcs, except it is going to be more wrapping library functions instead of creating PMCs. perhaps you have some tuits that you can loan me in this area | 23:20 | ||
| japhb | dukeleto, just as long as you provide a method to view the matrices as buffers, so that we can hand the buffer pointer off to other libraries ... like, say, OpenGL .... | ||
| dukeleto | darbelo: GSL is a pure C library. I want to access it's functions from Parrot, perhaps as PMCs, perhaps not. what is the best plan of action to start? | ||
| darbelo: for example, when I wrote Math::GSL ( perl interface to GSL) i started off just getting the special function subsystem working, which has reasonably simple function call signatures | 23:21 | ||
| Tene | dukeleto: write a PIR library wrapping the functions. | 23:22 | |
| dukeleto | darbelo: i don't think that subsystem fits well as a PMC. i just want to use NCI to call functions C functions from PIR | ||
| Tene: that is what I am going after, I guess. can you suggest the simplest example of a PIR library that wraps a C library? | |||
| Tene | github.com/tene/parrot-elementary/ is my example | 23:23 | |
| darbelo | dukeleto: I agree, from what little I know about GSL it looks like a pir wrapper is the way to go. | ||
| Whiteknight | dukeleto: I want to add an efficient matrix PMC | ||
| that's one of the goals of the parrot-linear-algebra package | |||
| dukeleto | darbelo: gsl does have some subsystems that would work as PMCs, but most just need wrapping | ||
| Tene | dukeleto: that library also has some wrapper classes around the obejcts that library makes that may or may not be relevant to you. | 23:24 | |
| darbelo | dukeleto: also see NotFound's mysql wrapper. | ||
| parrot-mysql? | |||
| dukeleto | Whiteknight: i talked about that with particle at the gsoc mentor summit last year. i didn't have the parrot tuits back then to act on what he told me, but now I think I do | ||
| Whiteknight: i am all about numerics on parrot, so consider me 'all-in' on your parrot-linear-algebra and matrixy projects. | 23:25 | ||
| darbelo | purl: parrot-mysql is code.google.com/p/parrot-mysql/ | ||
| purl | OK, darbelo. | ||
| Tene | If all you need to do is manage object points to pass to C functions, you don't need a PMC, just a PIR class. | ||
| s/points/pointers/ | |||
| dukeleto | Tene: each gsl subsystem has slightly different needs. there about 45 subsystems | ||
| japhb | yikes | 23:26 | |
| dukeleto | Tene: parrot-mysql looks like it could be what I need to look at, thanks! | ||
| Whiteknight | dukeleto: awesome! I've got commit bits galore if you want one | ||
| it's going to be a while before either of those projects build or anything, but will be valuable | |||
| Tene | I remember parrot-mysql as doing rather more than just wrapping the C functions. | ||
| dukeleto | Whiteknight: yeah, i would definitely like to have commit bits on your github repos | ||
| Tene | but I don't trust tha tmemory too well. | ||
| dukeleto | Whiteknight: does either project have a test suite yet? | 23:27 | |
| dukeleto loves me some test suites | |||
| darbelo | Whiteknight: matrixy's Configure.pl fails horribly for me, looks like it's assuming a home in the parrot build tree. | ||
| dukeleto | writing the plumage test suite in NQP was really quite fun | ||
| darbelo is collecting commit bits this days. | 23:28 | ||
| dukeleto | japhb: i don't quite know what to work on next on plumage. let me know what needs doin' | ||
| japhb: i am still thinking about how to properly mock out the source code repos so that I can test each plumage command without hitting 'live' servers. or should we just not care and hit live servers in our test suite? something rubs me the wrong way about that | 23:30 | ||
| network issues => failing tests => angry dukeleto | |||
| japhb | dukeleto, let me think on both of those. Have to finish a thought at $day_job first. | ||
| It sounds like I have requests to think about 1) dep handling, 2) testing mocked source repos, 3) more tasks to share. About sum it up, darbelo and dukeleto? | 23:31 | ||
| dukeleto | japhb: currently i am leaning towards changing the URLs in metadata in the test suite, so that it check out/clones from a file:/// protocal repo that lives in the test suite | 23:32 | |
| Whiteknight | Matrixy doesn't build | ||
| dukeleto | japhb: does Plumage::Downloader support file:/// ? | ||
| Whiteknight | 1) it doesn't work against an installed parrot. That needs to be fixed | ||
| japhb | dukeleto, I don't think so, I think it's http-only. | ||
| Whiteknight | 2) It requires CBLAS and CLAPACK libraries, the bindings to which I moved into parrot-linear-algebra as a separate project | 23:33 | |
| dukeleto | japhb: actually, that shouldn't matter. svn and git will be dealing with the URLS, not plumage, correct? | ||
| Whiteknight | so if anybody knows how to make a language build against an installed parrot, I would love to hear about it | ||
| Tene | dukeleto: Plumage::Downloader *should* support all supported url types. It currently doesn't. | 23:34 | |
| darbelo | Whiteknight: I can probably get you building against installed parrot, depending on how attached you are to your current build infrastructure. | ||
| dukeleto | Whiteknight: when you figure that out, please write a blog post about it. many others are in your situation :) | ||
| japhb | dukeleto, and I think we will probably do something similar. But I'm thinking shipping the moral equivalent .tar.gz of small git and svn repos, so that we can extract them locally and use real git and svn commands to access them. | ||
| allison | Whiteknight: it's mainly just a matter of getting your paths right | ||
| Whiteknight: specifically, not assuming the build directory paths | |||
| japhb | dukeleto, how are you going to test dep handling? hmmm, I need to tank on this. | ||
| dukeleto | japhb: yes, that is what I was thinking. we can use essentially empty svn and git repos. we just need to test that they are checked out properly | 23:35 | |
| allison | Whiteknight: Tcl is a good example | ||
| dukeleto | japhb: that question requires beer | ||
| Whiteknight | allison: okay, awesome | ||
| dukeleto, darbelo: you're both "collaborators" on both projects | 23:36 | ||
| I think that's the same as a commit bit | |||
| dukeleto | i am fast approachin the need to write Test::MockObject for Parrot . i hear one of the parrot core committers knows a thing or two about it... | ||
| Whiteknight: yes, it is. thanks! | |||
| Whiteknight | dukeleto: I actually wanted to start a mock framework! | ||
| dukeleto | Whiteknight: we are like two peas in a pod or something today! | ||
| Whiteknight | for serious | 23:37 | |
| dukeleto | scary, even | ||
| Whiteknight | should be relatively easy. Create a PMC type that overloads find_method in some way | 23:38 | |
| hard part will be unpacking arguments, but with :call_sig that won't even be so hard | 23:39 | ||
|
23:43
mokurai joined
|
|||
| Whiteknight | of course, maybe I'm underestimating. I've never made a mock object framework before | 23:46 | |