|
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. |
|||
| Tene | all of the thread.t tests that fail fail with a segfault. | 00:02 | |
| Whiteknight | threading is definitely something Parrot needs to work on | 00:04 | |
| there is a lot of cruft floating around, we really need to figure out what all we have | |||
| Tene | the run_clone method that's failing isn't defined as a METHOD, it's set up at runtime with register_nci_method() | 00:07 | |
| looks like it dates back to 'creiss' in 2006 | 00:09 | ||
| I've never seen that name before. | |||
| seems like it needs significant updates. | 00:10 | ||
| dalek | TT #1106 created by Austin_Hastings++: Cannot presently dump Class pmcs | 00:16 | |
| Whiteknight | what are all these "features" things that people keep wanting? | ||
| cotto_work | They're like bugs, except they work. | 00:17 | |
|
00:33
preflex joined
|
|||
| Whiteknight | urg, why are all those threading tests on pcc_reapply failing? | 00:36 | |
| and why are so many of these stupid failing tests in perl5? | 00:37 | ||
| cotto_work | because nobody ever goes there | 00:39 | |
| (not that you didn't already know that) | |||
| Whiteknight | the threading system should really be a higher priority then people have made it out to be | 00:44 | |
| we would be making a big mistake if we shipped 2.0 without good, stable, scalable threading support | |||
| cotto_work | That'll be a challenge. | 00:46 | |
|
00:56
rhr joined
01:08
rhr joined
01:33
rhr joined
|
|||
| dalek | p-rx: 5045605 | pmichaud++ | (6 files): Handle positional (numbered) captures. |
01:34 | |
| shorten | dalek's url is at xrl.us/bfr4j3 | ||
|
01:35
kid51 joined
|
|||
| dalek | p-rx: 032c58a | pmichaud++ | t/p6regex/rx_ (5 files): Add remaining test files from PGE (not active/configured yet). |
01:40 | |
| shorten | dalek's url is at xrl.us/bfr4mi | ||
| Whiteknight | the failure in t/pmc/codestring.t makes no sense to me | 01:42 | |
| I just traced through it in gdb and the result value looked correct | |||
| dalek | rrot: r41836 | jkeenan++ | branches/auto_libjit: Create a branch to test plobsing's patch in |
01:44 | |
| Whiteknight | urg, this codestring failure is turning out to be dfficult to debug | 01:52 | |
| Tene | Whiteknight: I looked at it, and I can confirm that when I changed the return(intval -1) to return(intval 42), it successfully returned 42 | 01:58 | |
| so there's a problem with returning a constant -1 from a method, or something. | |||
| Whiteknight | well that's horrible | 02:00 | |
|
02:01
msmatsko joined
|
|||
| Tene | Quite! | 02:01 | |
| Whiteknight | okay, well I'm out of time for the night. Goodnight | ||
| Tene | Goodnight. | ||
|
02:02
rhr joined
|
|||
| kid51 | Why is dalek so slow? | 02:22 | |
| dalek | rrot: r41837 | jkeenan++ | branches/auto_libjit (19 files): Apply in branch plobsing's patch submitted in 1. Move config step gen::libjit up to 4th last step. 2. Add SVN properties and rebuild MANIFEST. |
02:23 | |
| p-rx: 76c694d | pmichaud++ | src/Regex/P6Regex/Actions.pm: Add aliased assertion captures. |
02:26 | ||
| shorten | dalek's url is at xrl.us/bfr4ue | ||
| dalek | p-rx: 4481429 | pmichaud++ | src/Regex/P6Regex/ (2 files): Handle simple binding aliases. |
||
| shorten | dalek's url is at xrl.us/bfr4ug | ||
|
02:32
mikehh joined
02:35
janus joined,
rhr joined
|
|||
| Tene | dalek isn't slow, it's delayed. | 02:41 | |
| speed and offset are distinct. | |||
|
02:52
rhr joined
02:56
jsut joined
03:28
JimmyZ joined
03:29
rhr joined
04:01
preflex joined
|
|||
| dalek | p-rx: 568cc9b | pmichaud++ | src/ (3 files): Allow PAST::Regex subrule nodes to have arguments to pass to the subrule. |
04:09 | |
| shorten | dalek's url is at xrl.us/bfr5ap | ||
|
04:21
preflex joined
|
|||
| dalek | p-rx: 3de5a4f | pmichaud++ | src/ (2 files): Add alias capturing of non-subrules. |
05:06 | |
| p-rx: f00fd0d | pmichaud++ | src/Regex/P6Regex/Grammar.pm: Allow spaces in character class compositions. |
|||
| shorten | dalek's url is at xrl.us/bfr5f4 | ||
| p-rx: 8743056 | pmichaud++ | src/Regex/P6Regex/Actions.pm: Add character class composition. |
|||
| shorten | dalek's url is at xrl.us/bfr5f6 | ||
| dalek's url is at xrl.us/bfr5f8 | |||
|
05:21
japhb joined
05:33
KatrinaTheLamia joined
06:00
uniejo joined
06:18
KatrinaTheLamia joined
06:39
kyle_l5l joined
|
|||
| dukeleto | 'ello | 06:53 | |
|
07:31
JimmyZ joined
07:32
bacek joined
|
|||
| bacek | o hai | 07:33 | |
| JimmyZ | bacek: hello | 07:35 | |
| purl | salut, JimmyZ. | ||
| bacek | G'Day JimmyZ | ||
| what current status of pcc_reapply? | |||
| dukeleto | how do I import subs from a PBC (Test/More.pbc) to the current namespace in NQP? | 07:38 | |
| nopaste | "moritz" at 87.176.59.93 pasted "Error summary from pcc_reapply for bacek++" (19 lines) at nopaste.snit.ch/18325 | 07:41 | |
| bacek | moritz: thanks | 07:42 | |
| Tene | bacek: the next thing that needs fixed, IMO, is parrot_config | 07:53 | |
| bacek | Tene: it's one line fix. | 07:54 | |
| Tene | dukeleto: for now, you use ~3 lines of embedded PIR, or add it to glue.pir | ||
| dukeleto: 'sec | |||
| bacek | Tene: config_lib_pasm.in, line 14. Replace "null P1" with "P1 = new 'Undef'" | 07:55 | |
| Tene | bacek: why hasn't that already been committed? | ||
| bacek | Tene: I'm not so magical as someone thinks | ||
| Tene | bacek: that is to say, I heard someone saying earlier that you had a workaround for the problem. Is there some problem with that fix, or did I misunderstand? | 07:56 | |
| nopaste | "tene" at 24.10.252.130 pasted "pir import for dukeleto++" (4 lines) at nopaste.snit.ch/18326 | ||
| Tene | dukeleto: if you put that in a sub in glue.pir, fetch the caller namespace and pass it as a second argument to import() | 07:57 | |
| bacek | Tene: it's probably hiding something else. Or just proper fix for previous undefined behaviour. I'm not sure. That's why I didn't commit it | ||
| Tene | dukeleto: erm, not a second argument, a named argument :named('targetns') | ||
|
07:57
baest joined
|
|||
| nopaste | "tene" at 24.10.252.130 pasted "import sub for dukeleto++" (9 lines) at nopaste.snit.ch/18327 | 08:01 | |
| Tene | bacek: with that applied, I can build and pass all of the tests in my scheme compiler. | 08:02 | |
| bacek | Tene: SHIP IT! | 08:03 | |
| dalek | rrot: r41838 | tene++ | branches/pcc_reapply/config/gen/config_pm/config_lib_pasm.in: [pcc] Use undef instead of null in config_lib. bacek++ |
08:06 | |
| Tene | bacek: trying to build rakudo... | 08:10 | |
| rakudo mostly builds... ten fails at the end. | |||
| nopaste | "tene" at 24.10.252.130 pasted "rakudo pcc build failure" (31 lines) at nopaste.snit.ch/18328 | ||
| Tene | although, that's out-of-date rakudo | 08:11 | |
| moritz | Tene: that looks very much like the resig branch, not trunk | ||
| or at least like a Makefile from that branch | |||
| Tene | moritz: Oh! You're right! | ||
| moritz | and that's known not to build on linux right now (except with modifications to the makefile) | 08:12 | |
| Tene | Lemme try again, except not stupid this time. | ||
| dukeleto | Tene: when I import from within a Q:PIR block, it will be visible from NQP? | 08:13 | |
| nopaste | "tene" at 24.10.252.130 pasted "real rakudo build failure" (284 lines) at nopaste.snit.ch/18329 | ||
| Tene | dukeleto: yes. If you run the code in my first paste from Q:PIR, it will work. | 08:14 | |
| dukeleto | Tene: i just saw the nopaste | 08:15 | |
| dalek | rrot-plumage: 341bf8b | leto++ | : [t] Properly test some exit codes using Test::More |
08:16 | |
| shorten | dalek's url is at xrl.us/bfr5re | ||
| Tene | dukeleto: I pasted two times. Once with code for Q:PIR, and again with code to put in an 'import' sub in glue.pir, if you wanted to do it that way. | ||
| Ooo, failure in imcc! | 08:17 | ||
| Tene sleep now. | 08:19 | ||
| dukeleto | Tene++ # thanks for the import help! | 08:20 | |
| dalek | rrot-plumage: 6c37408 | leto++ | : [t] Properly import functions from Test::More and add some tests using l... |
08:21 | |
| shorten | dalek's url is at xrl.us/bfr5ri | ||
| mikehh | pcc_reapply - make smoke #28955 at r41838 - 10,691 ok, 17 failed, 262 todo, 560 skipped and 0 unexpectedly succeeded | 08:25 | |
| dalek | rrot-plumage: 375dbe8 | leto++ | : [t] Add basic tests for usage |
08:26 | |
| shorten | dalek's url is at xrl.us/bfr5rz | ||
|
09:15
payload joined
|
|||
| dalek | tracwiki: v9 | kurahaupo++ | ArrayTasklist | 09:57 | |
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr5yj | ||
|
09:57
donaldh joined,
donaldh left
|
|||
| dalek | p-rx: 348b39f | pmichaud++ | src/Regex/constants.pir: Turn some magic constants into symbols. |
10:03 | |
| p-rx: 45fcb57 | pmichaud++ | (2 files): Convert to use symbols instead of magic numbers. |
|||
| shorten | dalek's url is at xrl.us/bfr5zg | ||
| shorten | dalek's url is at xrl.us/bfr5zi | ||
| dalek | p-rx: bdc43da | pmichaud++ | src/Regex/Cursor.pir: Revise !mark_commit to preserve capture stack. |
||
| shorten | dalek's url is at xrl.us/bfr5zk | ||
| dalek | p-rx: 1987a95 | pmichaud++ | (4 files): Add cut-rule token. |
||
| shorten | dalek's url is at xrl.us/bfr5zn | ||
| dalek | p-rx: 105b3e0 | pmichaud++ | src/PAST/Compiler-Regex.pir: More replacing magic numbers with symbolic constants. |
10:09 | |
| shorten | dalek's url is at xrl.us/bfr5zt | ||
| mikehh | trunk - pre/post-config, smoke (#28589) PASS,fulltest FAIL at r41838 (see TT #1102) - Ubuntu 9.10 (beta) amd64 | 10:16 | |
| 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 | |||
|
10:49
payload joined
10:51
payload joined
10:53
payload joined
11:29
tetragon joined,
tetragon_ joined
11:34
tetragon joined
11:36
masak joined
11:46
kid51 joined
|
|||
| dalek | kudo: 609cc25 | moritz++ | src/classes/Object.pir: make the get_integer vtable class .Int; fixes RT #69738 |
11:47 | |
| shorten | dalek's url is at xrl.us/bfr564 | ||
|
12:01
bluescreen joined
12:06
mokurai left
|
|||
| Coke | All these priorities being set are nice. What about my segfaults? =-) | 12:32 | |
| dalek | kudo: 3d1afed | moritz++ | src/setting/Operators.pm: give more awesome error message for infinite ranges |
12:33 | |
| shorten | dalek's url is at xrl.us/bfr6c6 | ||
| Coke | msg pmichaud (and other sixers) I have a lead on someone in the UK who is interested in putting together some multimedia tutorials and thinking about p6 as a "intro language" curriculum. | 12:37 | |
| purl | Message for pmichaud stored. | ||
|
12:37
bluescreen joined
|
|||
| moritz | oh cool | 12:37 | |
|
12:40
tokuhirom________ joined
12:41
whiteknight joined
|
|||
| Coke | moritz: I am going to give some feedback and encourage him to repost to a list. =-) | 12:48 | |
|
12:49
JimmyZ joined
|
|||
| moritz | Coke: +1 | 12:49 | |
| purl | 1 | ||
| moritz | purl: brain the size of an atom, and all used up for joining IRC channels | 12:50 | |
| purl | moritz: sorry... | ||
| Coke | purl, dirac? | ||
| purl | it has been said that dirac is at sourceforge.net/projects/dirac | ||
| Coke | purl, dirac was also paul. | ||
| purl | Coke: huh? | ||
| Coke | ha! look at comment #2 there. | ||
| (purl's url) | 12:51 | ||
| jonathan | lol...review fail | ||
| whiteknight | good morning #parrot | 12:54 | |
| fail? "Fuck you" is a very valid review | 13:00 | ||
| :) | |||
| masak | yeah, but thumbs up + "fuck you"? | 13:01 | |
|
13:01
bluescreen joined
|
|||
| masak | Infinoid: yes, if the commit looks right, please merge. | 13:03 | |
| Coke wonders if it's just him or if feather is getting slow. | 13:04 | ||
| if I'm using the sha1 to identify revs and want something human-friendly, is --short mostly safe? | 13:06 | ||
| (e.g. to replace the numbers in column 2 here:) github.com/partcl/partcl/blob/maste...ogress.csv | |||
| shorten | Coke's url is at xrl.us/bfr6gm | ||
| dalek | rtcl: 329ce26 | coke++ | tools/tcl_test.pl: Just pull from the known repo where the wiki lives. |
13:13 | |
| rtcl: d034e86 | coke++ | (2 files): We are using git for version control now, can't use svn/git-svn to get a rev. |
|||
| shorten | dalek's url is at xrl.us/bfr6hn | ||
| dalek's url is at xrl.us/bfr6hp | |||
| whiteknight | it's so cute when the bots have like a little conversation with each other? | ||
| dalek's url? | |||
| purl dalek's url? | |||
| purl | whiteknight: bugger all, i dunno | ||
|
13:15
whiteknight joined
|
|||
| Coke | shorten didn't need to shorten that. | 13:26 | |
| purl | That URL is at xrl.us/bfr6iq | ||
| Coke | [::facepalm::] | ||
| sadly, xrl.us doesn't reuse short urls. | 13:27 | ||
|
13:31
barney joined
|
|||
| whiteknight | purl msg allison I can't get pcc_reapply to build on win32. src/nci_test.c gives me errors about PMCNULL being undefined. I'm wondering if you've seen that error before. | 13:39 | |
| purl | Message for allison stored. | ||
| Coke | whiteknight: missing an include? | 14:01 | |
| (why do we have a _test file in src?) | 14:02 | ||
| whiteknight | no idea | ||
|
14:12
Psyche^ joined
14:13
shockwave joined
|
|||
| dalek | tracwiki: v10 | coke++ | ArrayTasklist | 14:13 | |
| tracwiki: add some comments. | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| tracwiki: v5 | coke++ | AllHackathons | |||
| tracwiki: trac.parrot.org/parrot/wiki/AllHac...ction=diff | |||
| tracwiki: v4 | coke++ | ItsABughunt | |||
| tracwiki: trac.parrot.org/parrot/wiki/ItsABu...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr6qg | ||
| dalek's url is at xrl.us/bfr6qi | |||
| dalek's url is at xrl.us/bfr6qk | |||
|
14:19
schmalbe joined
|
|||
| Coke | shorten, you're an idiot | 14:20 | |
| shorten, owner? | |||
| purl, shorten? | |||
| purl | shorten is a bot interface to metamark.net/ or shortens long urls in the channel or shortens shorter urls in /msgs or made by ask or thefeed.no/marcus/archives/000327.html # osx service or deaf to repetition or metamark.net/bot | ||
| Coke | shorten =~ s/or thefeed.no/marcus/archives/000327.html # osx service// | 14:21 | |
| dalek | rrot: r41839 | mikehh++ | branches/pcc_reapply/src/call/args.c: codetest fix - missing function documentation |
14:23 | |
| mikehh | I just set it up so that it passes codetest ( amke make -j test etc) - I think the documentation in src/call/args.c should be reviewed | 14:25 | |
| Coke: src/nci_test.c - shared library used for testing the Native Call Interface | |||
| s/amke/make/ above | 14:26 | ||
|
14:27
hachi_ joined
|
|||
| mikehh | Coke: it is in trunk | 14:27 | |
| jonathan | (bug where calling things from c that tailcall leads to segfault in Parrot)-- | 14:30 | |
| Coke | mikehh: yes. but why is a testing file in src/ | 14:33 | |
| should be in t/, neh? | |||
| mikehh: argh. | 14:34 | ||
| mikehh: scratch that argh. | |||
|
14:35
fperrad joined
14:39
jrtayloriv joined
14:47
theory joined
|
|||
| Coke | msg dukeleto - if you can figure out why commit messages are not showing up from github on partcl-commits, I'll give you a cookie. | 14:59 | |
| purl | Message for dukeleto stored. | ||
|
15:03
allison joined
15:05
whoppix joined
|
|||
| moritz | wow, the amount of failed tests in the pcc_reapply branch is impressively low | 15:11 | |
| 15 or so | |||
| Coke | what the holy (*&#. partcl-commits just got spammed by someone. no github email, but spam. :| | 15:20 | |
| jonathan | moritz: Really? | ||
| Nice! | |||
| Coke | msg dukeleto it's working no. no cookie for you! =-) | 15:22 | |
| purl | Message for dukeleto stored. | ||
|
15:23
payload joined
|
|||
| Coke | moritz: are you counting failures where N tests were planned but only N-M were run? | 15:30 | |
| I'm seeing hundredes of failures. | 15:31 | ||
| (in pcc_reapply) | |||
| mikehh | Coke: it's been around for at least six years - the first entry in trac svn revision log is r5205 leo | ||
| Coke in fact that was a change to r5204 - (checked in by leo, 6 years ago) | 15:32 | ||
| Coke | mikehh: ... yes. | ||
| that doesn't mean it /belong/s there. | |||
| mikehh | probably not :-} | ||
| Coke | I just figured if he was looking at the file anyway, now might be a good time to put it where it belongs. | ||
|
15:34
bluescreen joined
15:43
Andy joined
|
|||
| moritz | Coke: I ccounted the errors as shown in failure summary | 15:49 | |
| Coke | moritz; look for lines like: | 15:54 | |
|
15:54
nnunley joined
|
|||
| Coke | Parse errors: Bad plan. You planned 76 tests but ran 4. | 15:55 | |
| there's 64 potential failures right there. | |||
| (yes, it could just be one.) | |||
|
16:03
payload joined
16:24
cotto_work joined
16:27
chromatic joined
16:31
HG` joined
16:32
kurahaupo joined,
mikehh joined
|
|||
| dalek | p-rx: 8276d6c | pmichaud++ | src/ (4 files): Add null/fail PAST::Regex nodes (as subtype of 'anchor' pasttype). |
16:34 | |
| shorten | dalek's url is at xrl.us/bfr7gg | ||
| dalek | p-rx: 3cc84fe | pmichaud++ | (4 files): Add :ignorecase/:i modifier for literals. |
||
| shorten | dalek's url is at xrl.us/bfr7gi | ||
|
16:41
msmatsko joined
16:54
einstein joined
16:58
ruoso joined
|
|||
| mikehh | got to reboot - bbiab | 17:04 | |
| Tene | Coke: I don't get any failures like that. | 17:07 | |
| dalek | tracwiki: v11 | kurahaupo++ | ArrayTasklist | 17:08 | |
| tracwiki: notes on thread safety, exponential resizing | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr7pe | ||
| Coke | tene: I get tons. | 17:11 | |
| are you using buildframes=0 ? | |||
| (I was not) | |||
| nopaste | "tene" at 24.10.252.130 pasted "My test results summary for Coke++" (14 lines) at nopaste.snit.ch/18330 | ||
| Tene | So I guess I get that once in t/library/coroutine.t for 4 tests. | 17:12 | |
| nopaste | "Coke" at 72.228.52.192 pasted "my test failures for Tene++" (71 lines) at nopaste.snit.ch/18331 | 17:13 | |
| Tene | The frame builder hasn't ever worked on my platform anyway, coke. | ||
| Coke | k. | ||
| Just saying, it's not as rosy here. | |||
| Tene | Coke: failures with the frame builder aren't related to algorithmic failures of the pcc refactor. | 17:14 | |
| Coke | I have no idea what these failures are from. | ||
| I just mentioned that as I've seen kid51++ mention it. | |||
| Tene | That's the remnants of oldjit. | 17:15 | |
| Coke | if there are failures in the branch that aren't in trunk, I'd say they are at least slightly related. =-) | ||
| Tene | the NCI frame builder, which we expect to remove shortly after the upcoming release, hasn't been updated in the branch to use the new calling conventions API. | 17:16 | |
| dalek | tracwiki: v12 | kurahaupo++ | ArrayTasklist | 17:18 | |
| tracwiki: notes on applicability of uninitialized resizable arrays; more details on "fully general" arrays | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr7re | ||
| Coke | ok. So those failures are real, then. | 17:20 | |
| you just don't happen to be tripping them on your platform. | 17:21 | ||
| yes? | |||
| Tene | Depends on who you ask, and what your tolerance for semantic dickery is. ;) | 17:22 | |
| pmichaud | lunchtime, #ps in 68 | ||
| Tene | (more) | ||
| whiteknight | I made an offer last night that if we ripped the frame builder out directly after the release, that I would guarantee a replacement by 1.8 | 17:25 | |
| nobody took me up on it | |||
| Tene | Yes, they need to be either fixed or the frame builder removed. The people working on PCC haven't addressed it yet because they've been more worried about getting PCC working correctly first, and everyone hates the frame builder, and the most-likely person to work on it, WK, hates it SO VERY MUCH, and now there's politics, which is perfectly legitimate because he can choose what he spends his very-appreciated volunteer time on, but ... | ||
| ... doesn't help the state of the branch or whatever. | |||
| Coke | whiteknight: I don't understand. what's to stop you from working on it in a branch? | 17:26 | |
| where you can rip it out and replace it and then there's no risk to anyone? | |||
| Tene | whiteknight: Your offer was that you would fix the frame builder failures if (what you said) | ||
|
17:26
Austin joined
|
|||
| Tene | as I remember it, yes? | 17:27 | |
| whiteknight | Yes. What I really said was that I would fix it now and make the failures go away, AND provide a replacement by 1.8, IF I was allowed to rip it out directly after the release | ||
| Austin | heh | 17:28 | |
| whiteknight | What I'm looking for is some kind of commitment that people are actually ready to take the next step | ||
| it's a leap of faith to rip it out without having a replacement ready immediately | |||
| Austin | Isn't that what branches are for? | ||
| whiteknight | Austin: it's not a matter of where I work, it's a matter of when | 17:29 | |
| I have tuits available to do X task in Y timeframe. No tuits after Y timeframe | |||
| Austin | Ahh. | ||
| Coke | whiteknight: so why not do it in a branch, no faith required? | 17:30 | |
| then if you happen to miss the mark, it's in a state where a) trunk is unaffected, and b) someone can pick it up. | |||
| Austin | Look, just give the baby up for adoption. A child shouldn't have to compete with JIT compilation for daddy's attention... | ||
| Coke | so do it now, in a branch. You can start even before the release. | ||
| whiteknight | maybe I'm not explaining entirely correctly | ||
| Austin | Then you'll have lots of time available. | 17:31 | |
| Coke | I'm certainly confused. | ||
| Austin | :) | ||
| Coke | I'm willing to believe it's me. =-) | ||
| whiteknight | It's a tit-for-tat deal. I'll fix the frame builder test failure now, in exchange, I get to pull out the frame builder after 1.7 | ||
| This being a FOSS project, and me having no obligations besides my own desires, I'll do something I don't want in exchange for doing something I do want | 17:32 | ||
| pmichaud | what prevents you from pulling out the frame builder after 1.7 anyway? | ||
| i.e., I'm not seeing the obstacle. | |||
| dalek | p-rx: 2cd0942 | pmichaud++ | src/Regex/P6Regex/ (2 files): Add :sigspace support. Fix up comment parsing. |
||
| shorten | dalek's url is at xrl.us/bfr7ud | ||
| whiteknight | pmichaud: people have said we shouldn't pull it out until we have a replacement ready | 17:33 | |
| Tene | pmichaud: chromatic and allison will complain if he removes the frame builder without already having a replacement. That is, they object to having trunk in a no-frame-builder state at all. | ||
| Austin | pmichaud: Do multi-methods hide entire inherited names, or just hide inherited multi signatures? That is, can I have Parent::multi(_, Foo) and derive Child, with Child::multi(_, Bar), and still call Child.multi($foo) okay? | ||
| Tene | and WK doesn't want to make the replacement in a branch. | ||
| Coke | whiteknight: I think you're making this into a fight when it doesn't have to be. | ||
| whiteknight | right, and I'm not going to do what I've been told not to do. Hence, my bargain to change things | ||
| I'm not fighting | |||
| Coke | why not do all this in a branch, then? | ||
| pmichaud | whiteknight: you can certainly remove the frame builder in a branch. | ||
| nobody will object to that. | |||
| whiteknight | that's not the issue | 17:34 | |
| pmichaud | we're not seeing the issue. | ||
| whiteknight | that's fine, it's my issue | ||
| pmichaud | Austin: in Parrot I think that multi-methods hide entire inherited names. | ||
| Coke | ok. I vote against doing it in trunk, fwiw. | ||
| pmichaud | Austin: in Perl 6 they don't. | ||
| Coke | I just don't see why this has to be in trunk. | ||
| whiteknight | Coke: it doesn't matter where development happens. It can happen in a branch | 17:35 | |
| Austin | pmichaud: Okay. Is this a p6object thing? Is there some obvious way to "uplift" the masked methods? | ||
| Coke | ... then I completely fail to see the problem. | ||
| why can you not do this in a branch, then? | |||
| pmichaud | Austin: It's parrot. | ||
| whiteknight | I can do this in a branch. Location is not the problem | ||
| Coke | that is, what's stopping you? | ||
| Austin | Coke: I think the issue is commitment to incorporating the changes. | ||
| Coke | without knowing what the replacement will look like, how can we agree? | 17:36 | |
| whiteknight | exactly | ||
| Coke: because any replacement is better then what we have | |||
| an empty file is better | |||
| Austin | If he rips out the code, and everybody says, "Well, we are going to work on Unicode in this release. Maybe in a few months" that would suck. | ||
| pmichaud | Austin: that particular behavior of methods is entirely Parrot. P6object doesn't try to modify Parrot's metaobject model in that way. | ||
| Tene | Coke: I think it's something like "If I do it in a branch, then people can ignore th elack of a frame builder and potentially keep using the old one; if it's in trunk, then it's everyone's problem." | ||
| Coke | right. i don't want a problem. | ||
| whiteknight | no problems | ||
| Coke | sure, ripping it out without a plan more concrete than 'we'll improve it' seems to be a problem to me. | 17:37 | |
| Austin | pmichaud: Okay. (I sort of conflate p6object w/ parrot, here.) | ||
| whiteknight | there is a general plan about replacing the frame builder. I made a bid to fix some bugs in exchange for changing around the timeline a little. No takers, things go the way they are going | ||
| no harm, no foul | |||
| Tene | Coke: WK sees the existing frame builder as BAD CODE, and removing it completely to be an improvement. Others disagree. | ||
| whiteknight | I'll spend my tuits elsewhere, I have plenty of other projets to work on | ||
| Tene | Coke: for example, every architecture other than non-darwin x86 works "fine" witout it. | ||
| Coke | elsewhere than parrot, or in parrot? | ||
| whiteknight | In Parrot | ||
| GC, IO, IMCC/PIRC, Matrixy, etc. | 17:38 | ||
| PCC is still going to need lots of love too, after this branch lands | |||
| Tene | Coke: and this isn't the first time that oldjit has stalled otherwise-promising development. | ||
|
17:39
joeri joined
|
|||
| Coke | Tene: s/oldjit/old crappy placeholder code/ in general. | 17:39 | |
| pmichaud | whiteknight: in my experience, good code gets adopted into trunk pretty quickly, provided it's not a violation of the deprecation policy | ||
| Tene | Coke: the main objection comes from chromatic, who sees the precompiled NCI thunks as more evil than the frame builder, even though we still have to use the precompiled thunks on every other platform. | 17:40 | |
| pmichaud | so, either you're saying that what you propose to write won't be good code, or that it violates the deprecation policy | ||
| Tene | pmichaud: afaict, removing the frame builder wouldn't violate deprecation policy. | ||
| Austin | pmichaud: If I do a find-method on the multi name, I get the parent's multi, right? So could I then clone it and add the extras, then add-method the cloned multi? | ||
| whiteknight | no. I'm still not being too clear | ||
| Coke | maintaining 2 bits of evil code is worse than 1 bit, and if we're eventually going to be using something else entirely anyway, I fail to see the point of keeping it. | ||
| PerlJam | Tene: got a link to some place where chromatic explains that himself? | ||
| Tene: (precompiled thunks evil) | 17:41 | ||
| pmichaud | Austin: we do things like that in Rakudo, yes (more) | ||
| Tene | PerlJam: irc logs from yesterday. the summary is that *HALF* of our startup time is because of precompiled thunks, and half of the cost of every PMC. | ||
| whiteknight | pmichaud: frame builder is causing failures in pcc_reapply. There are two options: fix it or kill it. People would like to fix it so we have a frame builder in place for the 1.7 release (more) | ||
| PerlJam | Tene: ah, thanks. | ||
| purl | ah, thanks. is it fast enough? | ||
| pmichaud | Austin: another possibility would be to have a fallback method in the subclass that is :multi() (no args) and forwards to the parent method | ||
| chromatic | I consider that a regression at least on x86. | ||
| whiteknight | I want to kill it. So I say that I will fix it for 1.7, in exchange for being able to kill it directly thereafter | ||
| Austin | pmichaud: multi(), or multi(_) on self? | 17:42 | |
| whiteknight | the issue isn't killing it or not, it's when we do it. I'll fix the failures now, in exchange for killing it soon | ||
| pmichaud | Austin: either might work. Depends on the semantics you'd like. | ||
| whiteknight | as opposed to me not fixing it now (maybe somebody else will) and we kill it later | ||
| Coke | whiteknight: ah. you're not saying you'll write a replacement. | ||
| whiteknight | Coke: I will, that's part of my deal sweetener | ||
| Coke | you're saying you'll make the branch work so we can kill it more quickly and then not replace it? | ||
| chromatic | Exactly. | 17:43 | |
| Tene | Coke: he's also committing to writing a replacement, but wants the frame builder removed regardless. | ||
| whiteknight | and I provide a replacement in 1.8 | ||
| Coke | whiteknight: because we are volunteers, I don't see why you have to do it in this order. | ||
| pmichaud | so let me attempt to summarize | ||
| Coke | if we assume we need a frame builder, and we rip it out, and then something happens to your plans between 1.7 and 1.8... what then? | ||
| whiteknight | that way not a single release goes out the door without a frame builder AND we kill code I hate at the earliest possible moment | ||
| pmichaud | actually, I won't attempt it. | 17:44 | |
| whiteknight | Coke: that's where the leap of faith comes in | ||
| I didn't say it was a perfect offer | |||
| and I'll be working on JIT anyway, just on a different timeframe otherwise | 17:45 | ||
| in any case, it's not a big deal | |||
| Coke | ok. so, back to my "I have more tests failing in pcc_reapply than tene". chromatic: removing buildframes is a regression? | 17:46 | |
| whiteknight | in terms of performance it's a regression | 17:47 | |
| chromatic | Every failing test in pcc_reapply right now is a regression. | ||
| Coke | ok. we have no guarantees on performance, and the HLLs are already pretty slow. what's the slowdown factor? | ||
| chromatic | Parrot takes twice as long to start. | ||
| Coke | chromatic: if we switch the default sense on --buildframes, do most of those failures go away? | 17:48 | |
| whiteknight | we know that registering hundreds of NCI thunks is a huge slowdown | ||
| chromatic | the shared library is 30% larger | ||
| Coke | ok. size is not something we guarantee between releases... | ||
| chromatic | I don't know about "most" but "many" do. | ||
| cotto_work | chromatic, is this a case of things getting worse before they can get better? | ||
| chromatic | If we can't fix the frame builder on the branch and it would block merging, then yes cotto_work. | ||
| whiteknight | ...or a case of it getting better before it gets awesome? | 17:49 | |
| dalek | tracwiki: v13 | kurahaupo++ | ArrayTasklist | 17:50 | |
| tracwiki: validity of negative indeces | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr7wu | ||
| allison | I'm okay with disabling buildframes for the merge, if we can't fix by the day after 1.7 | 17:51 | |
| (though fixing it would be nice) | |||
| whiteknight | we're merging after 1.7? | ||
| (not that I expect we could reasonably be in before) | 17:52 | ||
| allison | I can't really test fixing it, since buildframes doesn't do anything on the platforms I have access to | ||
| yes, because a bigger concern is the speed of CallSignature | |||
| whiteknight | ok | ||
| allison | this gives chromatic time to work on it before we merge, or at least before 1.8 | ||
| chromatic | I don't mind trying to fix the frame builder in the branch, but I haven't for two reasons. | 17:53 | |
| allison | so we don't have a release hit by that slowdown | ||
| chromatic | 1) I think CallSignature is a bigger priority | ||
| Tene | allison: I could give you access to an x86 box. | ||
| allison | agreed | ||
| whiteknight | do we have any numbers on the slowdown? | ||
| chromatic | 2) I'm not confident of doing it before the branch passes tests appropriately | ||
| whiteknight | like, how bad it is? | ||
| chromatic | 2.5 times slower, by the fib.pir benchmark. | ||
| allison | 2) also agreed | ||
| whiteknight | chromatic: Agreed, fixing tests is higher priority | ||
| 2.5 times !?!? | |||
| holy crap | |||
| purl | only in the Vatican, my friend | ||
| chromatic | That's for passing only one positional argument. | ||
| It gets worse O(n) per arguments. | 17:54 | ||
| dalek | tracwiki: v14 | coke++ | ArrayTasklist | ||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr7xr | ||
| whiteknight | Oi vey! | ||
| chromatic | That's almost all GC pressure. | ||
| whiteknight | well, that's something we need to address ASAP | ||
| I didn't realize it was so bad | |||
| allison | whiteknight: see the CallSignature refactor items on the tasklist page | 17:55 | |
| chromatic | I'm working on a CallSignature refactor in a branch. | ||
| I'll poke at that today. | |||
| allison | (added to flesh out what I said in a recent conversation with chromatic) | ||
| kurahaupo | Earlier it was mentioned that a "general purpose array PMC" that could hold any value without needing a PMC would be a win. As ļ»æI'm looking at refactoring the PMC's that implement arrays in various ways, would you like me to work on that as a starting point? | ||
| whiteknight | I can take a look at the refactor too | ||
| Austin | pmichaud: Is there a way to do "find_method" on a class, without having an instance? Barring that, is there a way to access the MRO from PIR? I know there's a C method, but I can't find any exposure of it. | 17:56 | |
| pmichaud | yes, it's possible to find the MRO | 17:57 | |
| dalek | tracwiki: v14 | whiteknight++ | CallingConventionsTasklist | ||
| tracwiki: Move the CallSignature refactors section up a little bit because it's higher priority then other stuff | |||
| tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr7zg | ||
| Austin | (without reimplementing C3?) | ||
| :) | |||
| pmichaud | the question of find_method on class objects came up in design meeting a couple of weeks ago -- let me check | 17:58 | |
| Coke | kurahaupo: who mentioned that? | ||
| I would imagine that in order to handle any of SNIP types... you'd need something like a PMC. | |||
| (so why not just use that if you need multiple types?) | |||
| Austin | Coke: Probably to avoid the cost of creating the pmc. | 17:59 | |
| kurahaupo goes hunting in #parrot logs ... | |||
| Coke | Austin: ok. so now you have... what. a C struct? | ||
| that can contain any of the 4 types? | |||
| whiteknight | chromatic: refactors look good, but we're definitely going to want to make sure that CallSignatures and the arguments therein are accessible from PIR | ||
| Coke | and isn't GC'able? | ||
| whiteknight | otherwise jonathan and pmichaud might murder us | ||
| Austin | I'd guess something like the flyweight pattern, with the array tracking type externally. | 18:00 | |
| allison | whiteknight: the array and hash interfaces are the defined way to access the arguments | ||
| Coke | Austin: if the type is tracked externally, what's the array contain, void *s ? | ||
| allison | whiteknight: as in, the refactor has to support the same interface, but the internals can be anything | ||
| whiteknight | allison: so long as we give them a way, I just want to make sure we don' lose sight of that | 18:01 | |
| gotcha | |||
| Austin | Coke: I have no idea. A union, maybe? | ||
| kurahaupo | coke: discussion between allison and chromatic circa 2009-10-10T07:43Z | ||
| Coke | Austin: ah, that's what I meant when i said struct. | ||
| whoops. | |||
| pmichaud | Austin: (find_method) --- there's a find_method method (note, not opcode) that walks the MRO of a class object | ||
| Austin | Coke: Your guess is as good a mine. :$ | ||
| pmichaud: Aha! You rock. Thanks. | 18:02 | ||
| Coke | I am unconvinced that a constructing such a beast is worth it, unless it means we can kill all the *<type>* variants. | ||
| moritz | kurahaupo: you can make links to individual lines on irclog.perlgeek.de/parrot/2009-10-10 by clicking on the time in the left column | ||
| pmichaud | src/pmc/class.pmc:1960 (or thereabouts, I haven't svn up'd in a while) | ||
| Austin | pmichaud: Based on what you've told me so far, I'm guessing that parrot multi-method resolution stops with the first *name* that it finds in the MRO, rather than searching for other like-named multi's with closer matching arglists. Does this sound reasonable? | 18:03 | |
| pmichaud | there's also a way to find out all of the parent classes (mro order) by using 'all_parents' with the inspect opcode. | 18:04 | |
| Coke | kurahaupo: that conversation appears to be related specifically to CallSignature. | ||
| pmichaud | Austin: that's been my experience, yes. | ||
| kurahaupo | discussion starts roughly at irclog.perlgeek.de/parrot/2009-10-10#i_1588983 | ||
| pmichaud | Austin: it stops resolution at the first name encountered. | ||
| Austin | pmichaud: Really? I looked for all_parents, but didn't find it exported. | ||
| Coke | I could be mistaken, though. | ||
| pmichaud | Austin: $P0 = inspect classobj, 'all_parents' # I think | 18:05 | |
| P6object uses it, so you could look there for an example. | |||
| Austin | Nope, I'm wrong. It's not in the POD, but it is in the code. (What I get for running perldoc instead of less, I suppose.) | ||
|
18:05
hachi joined
|
|||
| pmichaud | oh yes, it's not in the POD. I remember noticing that when I went looking for it a few weeks ago also :) | 18:06 | |
| Austin | :) | ||
|
18:06
mikehh joined
|
|||
| kurahaupo | coke: yes, discussion was about improving performance of CallSignatures | 18:07 | |
| whiteknight | do we have any leads or ideas about fixing the remaining test failures on pcc_reapply? | 18:08 | |
| I had them running in the debugger last night, and didn't even understand the problem | |||
| for the one test, t/pmc/codestring.t, the one method was clearly returning -1, but that was not the resul | 18:12 | ||
| I suspect it's an issue of sign extension, but haven't tried a fix | |||
| dalek | p-rx: f650cd5 | pmichaud++ | STATUS: Update STATUS. |
||
| shorten | dalek's url is at xrl.us/bfr74y | ||
| allison | whiteknight: my guess on the threads failures is that there's some code in the threads implementation that's still handling args/returns in the old way | 18:13 | |
| whiteknight | so I guess we need to march into the belly of that beast somewhere then | 18:14 | |
| allison | whiteknight: indeed | 18:15 | |
| t/op/lexicals_28.pir seems to be a failure in the argument or return handling logic | 18:16 | ||
| that is, it's not correctly detecting the end of the positional arguments or results array | |||
| whiteknight | yeah, I stared at that file for a while and couldn't figure out what was going wrong | ||
| allison | t/library/coroutine.t has a different error now | 18:17 | |
| more specific | |||
| "flattened return on a non-array" | |||
| whiteknight | urg | ||
| allison | it may simply be a case of something accessing the flags for the wrong element | 18:18 | |
| whiteknight | or the new system accessing things in a different order from the old system | ||
| dalek | rtcl: c27357b | coke++ | tools/spec_info.pl: git revisions aren't numeric. |
||
| allison | (which seems to happen whenever the index is updated without re-looking up the flags | ||
| shorten | dalek's url is at xrl.us/bfr75r | ||
| dalek | rtcl: 9bade3a | coke++ | docs/spectest- (2 files): Record another spec test run. |
||
| shorten | dalek's url is at xrl.us/bfr75t | ||
| whiteknight | which, for named returns filling unfilled positionals, is a very real possibility | ||
|
18:19
bacek joined
|
|||
| allison | whiteknight: I've been going around restricting the scope of the flags variables, so they're only created when needed, and not lingering around to trap some unwary line of code | 18:19 | |
| whiteknight: ordering conflicts is another possibility, aye | 18:20 | ||
| whiteknight | especially if old PIR code is expecting certain orders of things | ||
| allison | t/op/calling.t is three very different erros | 18:21 | |
| errors | |||
| whiteknight | It creates a bit of an issue because named arguments are stored in an order-less hash, but are used to fill positional arguments | ||
| pmichaud | btw, within the next few days I expect I'll be at a point where benchmarking nqp-rx would be very useful | ||
| s/benchmarking/profiling/ | |||
| allison | #59 is caused by calling get_results directly inside the label of a continuation | ||
| whiteknight | that should be .get_results(), right? | ||
| allison | I have some code that almost fixes that, | ||
| pmichaud | so if someone can do some profiling, or let me know how to do it, that might be very interesting/helpful. | ||
| whiteknight | pmichaud: I probably can help | 18:22 | |
| cotto_work | pmichaud, add -Rprofiling to the parrot cli | ||
| whiteknight | although I shouldn't be the only one, I'm a profiling n00b | ||
| pmichaud tries it on existing pge test. | |||
| allison | whiteknight: yes, but I suspect get_results or .get_results would have the same effect in this case. It's an order of operations problem | ||
| pmichaud | (svn up, rebuild, sigh) | ||
| cotto_work | the final bit of output will tell you the next step | 18:23 | |
| allison | t/op/calling_61.pir looks like a return handling bug | ||
| pmichaud | cotto_work: thanks | ||
| will report soon (after building) | |||
| cotto_work | pmichaud, I hope you find code useful. | ||
| pmichaud | if not, you'll hear about it :) | 18:24 | |
| cotto_work | great | ||
| whiteknight | mikehh: when did the 9.10 beta come out? | 18:25 | |
| allison | whiteknight: t/op/calling_47.pir looks like it's not returning values from tailcall properly | 18:27 | |
| whiteknight | was that the failure in tailcall from an NCI method? | 18:28 | |
| whiteknight doesn't have his dev machine here so he cant look at all these | |||
| mikehh | I got it Friday 2nd but didn't install until this week | ||
| whiteknight | and it doesn't build on win32 right now | ||
| dalek | TT #1107 created by Austin_Hastings++: Opcode get_class has failed assertion with garbage input | ||
| Austin | What do you think, Lewis - is this snake poisonous? Well, Clark, go ahead and step on it and then we'll know. | 18:29 | |
| whiteknight | "garbage input"? Well, there's your problem | ||
| allison | whiteknight: it's a PIR Sub, don't think it's NCI related | ||
| whiteknight | allison: okay, I must be thinking of the wrong one then | 18:30 | |
| chromatic | #ps in 1 | ||
| dalek | tracwiki: v1 | chromatic++ | StructPruning | ||
| tracwiki: Created page with suggestions for parrot_interp_t and PackFile | |||
| tracwiki: trac.parrot.org/parrot/wiki/Struct...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr78u | ||
| whiteknight | #ps in 0 | 18:31 | |
| pmichaud | does pprof2cg.pl generally take a long time? | ||
|
18:31
schmalbe left
|
|||
| pmichaud | cotto_work: profiler seems to work just fine, thanks! | 18:36 | |
| chromatic | It takes a long time, yes. | ||
| cotto_work | good to hear | 18:37 | |
|
19:04
payload joined
19:13
joeri joined
|
|||
| Tene | Testing cardinal against pcc branch... | 19:24 | |
| cardinal compiles fine with pcc branch. | 19:26 | ||
| allison | Tene: sweet! | ||
| Tene | running tests now | ||
| allison: if you can come up with any ideas about the rakudo build failures, I'll look at them tonight. | |||
| allison | Tene: do you have a nopaste of the failures? | 19:27 | |
| Tene | Yes... | ||
| nopaste.snit.ch/18329 | |||
| dalek | p-rx: fee0b48 | pmichaud++ | build/Makefile.in: Add test_loud Makefile target. |
||
| shorten | dalek's url is at xrl.us/bfr8hz | ||
| dalek | p-rx: 302f7f2 | pmichaud++ | src/ (2 files): Add ability to use ? and ! with enumerated character lists <?[abc]> and <![def]> |
||
| shorten | dalek's url is at xrl.us/bfr8h3 | ||
| Tene | Really busy with $work right now, so can't actually look at anything. | 19:28 | |
| chromatic | Any thoughts on whether CallSignature should use a single array for INSP types or one array for each? | ||
| Tene | I'd personally attempt the former first. | ||
| allison | Tene: okay, will leave you a message for later if I turn anything up | ||
| bacek | good morning | ||
| allison | chromatic: we have to preserve the order of all elements, not just the relative order of each type | 19:29 | |
| chromatic: so I'd lean toward a single data structure | |||
| bacek | chromatic: single array is better. Just because get_foo_keyed_int will be simpler | ||
| chromatic | We have to preserve the order of all elements? | 19:30 | |
| bacek | for "manual" handling with HLL | ||
| allison | as in, we need to know that a subroutine was called with a PNSINS order if it was | ||
| Coke | I remember back when parrot /didn't/ keep track of that! | 19:31 | |
| fun times. | |||
| allison | recovering that from a P, NN, I, SS order is a pain | ||
| chromatic | I don't remember when Parrot ever kept track of that. | ||
| Coke | ... order of arguments? | ||
| chromatic | Right. | ||
| Unless you mean for PCCINVOKE char * signatures. | |||
| Coke | huh. I think you and I might be talking about different things, then. | ||
| allison | yes, as we learned from experience back when arguments were stored directlyin registers | ||
| dukeleto | Coke: what is up with the partcl test suite ? | 19:32 | |
| allison | chromatic: it does currently track that order in the call state struct | ||
| Coke | dukeleto: github.com/partcl/partcl/commit/9ba...09eb355e72 | ||
| shorten | Coke's url is at xrl.us/bfr75t | ||
| Coke | I'm trying to track down if that's me or parrot. | ||
| chromatic | Okay, I'll test for a single array now then. | ||
| Coke | (running against the last known good run of parrot at r41575 | ||
| chromatic | What happens when the first element in the array is an INTVAL and someone wants it as a Float, String, or PMC? | 19:33 | |
| allison | chromatic: to put it really simply, if it's one array, we can just iterate over that array for argument processing, if it's multiple arrays, we'll have to do clever bookeeping and swapping between the two | ||
| s/two/four/ | |||
| chromatic | I don't understand what you mean by bookkeeping. | ||
| allison | chromatic: automatically boxed as a PMC | 19:34 | |
| converted as a Float or String | |||
| Coke | mannnn is svn slow. | ||
| chromatic | Conversion on access then. | ||
| allison | chromatic: keeping track of how far along we are in all 4 arrays while iterating | ||
| chromatic | Oh, you iterate over it with an Iterator instead of keeping an external index? | 19:35 | |
| Tene | chromatic: I think she's thinking that you would use compact arrays instead of sparse. | ||
| Coke does an svn up -r<foo> and gets a checksum mismatch on a file. that's a new one. | |||
| Tene | cardinal passes its test suite as expected with pcc branch. yay. | ||
| Coke | and it's repeatable. nice. | 19:36 | |
| chromatic | I was going to use arrays, but then I decided that linked lists would be much, much simpler and almost never a performance issue. | ||
| Whereas reallocating and copying to make arrays work well is more complex than we need right now. | |||
| I can write a correct and performant array system, but... meh. | |||
| allison | Tene: yes, I was | ||
| chromatic | Mostly my question was "Does PNSINS mean 0:P 1:N 2:S 3:I 4:N 5:S?" and it sounds like yes. | 19:37 | |
| allison | yes | ||
| whiteknight | problem comes from named arguments though | 19:38 | |
| I suggest that they be stored in the array directly, too. No need for a hash | |||
| allison | whiteknight: not necesarily, the could be stored in the same place, but have another layer of index added | ||
| whiteknight | that's what I was thinking | ||
| allison | as in, string index | 19:39 | |
| and, flagged in such a way that they don't get pulled into an iteration over positional args | |||
| whiteknight | that way, using named args for a missing positional would happen in a consistent order AND be relatively quick | ||
| chromatic | Or the hash value could be the struct in the array. | ||
| whiteknight | if named values don't fill in for positional values in a consistent way, that behavior is worthless | 19:40 | |
| bacek | allison: is interp->current_args (and other stuff) not used anymore? | ||
|
19:40
szabgab joined
|
|||
| allison | bacek: yes, there are quite a few c structs that can be pruned in the branch | 19:40 | |
| mainly interp and context | 19:41 | ||
| bacek | allison: good. It still accessed in Parrot_mmd_arg_tuple_func | ||
| looks like it's leftover which should be removed. | 19:42 | ||
| allison | bacek: aye, it's not set in set_args anymore, so it will be null | ||
| whiteknight | I suspect Parrot_mmd_arg_tuple_func should use CallSignature instead | 19:43 | |
| bacek | allison: can I just rip out this function? | ||
| allison | bacek: what calls it? | ||
| whiteknight | but, if it's been using the wrong thing all this time and hasn't caused failures, maybe it needs to die | ||
| bacek | whiteknight: there is _from_sigobj variant | ||
|
19:43
iblechbot joined
|
|||
| bacek | allison: looks like no one | 19:43 | |
| allison | bacek: then rip away | ||
| bacek | allison: multisub... | 19:44 | |
|
19:45
payload left
|
|||
| allison | bacek: it's called from Parrot_mmd_sort_manhattan | 19:46 | |
| bacek | allison: sort_manhattan called only from MultiSub afaik | ||
| but it should call _by_sig_pmc anyway | 19:47 | ||
| allison | bacek: yes, those other calls should be updated to be the same as 'invoke' | ||
| bacek | allison: yes, ripping now. | ||
| whiteknight | KILL! | ||
| allison | bacek: I'm guessing that the other vtable functions aren't tested | 19:48 | |
| bacek: because if they were, they'd be getting failures now | |||
| bacek | allison: indeed... | ||
| purl | indubitably | ||
| whiteknight | maybe we need more tests for MultiSub then | ||
| bacek | MultiSub is good candidate for weekly test target. | ||
| chromatic | It was a target a couple of weeks ago. | 19:49 | |
| treed | Tene: Minus the three tests that have been failing for a while? | ||
| whiteknight | hello treed | ||
| treed | 'lo | ||
| treed just got back from lunch. | |||
| or are those passing with the PCC branch too? | 19:50 | ||
| treed has a meeting in 9 minutes. | 19:51 | ||
| Tene | treed: three tests tat failed to compile. | 19:53 | |
| treed | yeah, same as before | 19:54 | |
| dalek | rrot: r41840 | bacek++ | branches/pcc_reapply/src/call/args.c: [cage] Don't use const pointers in from_continuation functions. They are not const |
||
| treed | at some point, I'd like some help in tracking that down | ||
| treed | it really seems like a parrot problem | ||
| allison | Tene: the Rakudo error is really odd, it's a mismatch in the number of arguments passed to an op | ||
| Tene: but likely related to the warning "warning: excess elements in array initializer" | 19:55 | ||
| bacek | time to go. See you soon. | ||
| dalek | rrot: r41841 | bacek++ | branches/pcc_reapply (7 files): Prune parrot_interp_t struct. Also remove old version of mmd_sort_manhattan function which doesn't work anymore |
19:57 | |
| chromatic | INCOMIGN | 19:58 | |
| INCOMING | |||
| purl | somebody said INCOMING was pause.perl.org/incoming/ | ||
| dalek | rrot: r41842 | chromatic++ | branches/pcc_optimize_sig/t/pmc/callsignature.t: [t] Added tests for push/pop and indexed access of INSP types in CallSignature. |
20:01 | |
| Coke | msg dukeleto looks like it's not a parrot problem. (old parrot that worked before fails with current partcl) | ||
| purl | Message for dukeleto stored. | ||
| rrot: r41843 | chromatic++ | branches/pcc_optimize_sig/t/pmc/callsignature.t: [t] Added CallSignature tests for storing all indexed values in a single array |
|||
| rrot: r41844 | chromatic++ | branches/pcc_optimize_sig/t/pmc/callsignature.t: [t] Added boxing/unboxing tests for positionals stored in CallSignature PMC. |
|||
| dukeleto | Coke: yay | 20:03 | |
| Coke | not for me! =--) | 20:05 | |
| Austin | pmichaud: I have a sub called Class::find_method. This invokes 7 $class.find_method($name) after chasing around for a bit setting up $class and $name. Apparently, this is recursive, despite Class:: being a module rather than a class in NQP. Is this a bug, or am I missing something? | 20:06 | |
| Austin sings "When you're chewing on life's gristle, don't grumble: give a whistle! And this'll help things turn out for the best." | 20:09 | ||
|
20:09
joeri left
|
|||
| moritz | always look on the bright side of life *whistle* *whistle* | 20:10 | |
| pmichaud | in NQP, "Class" isn't usually a Parrot class object. | ||
| but, more to the point, I'm not sure exactly what you're trying to do or expect. | 20:11 | ||
| Austin | (incidentally, this record's available in the foyer...) | ||
|
20:11
mokurai joined
|
|||
| whiteknight has to leave. Later | 20:11 | ||
| chromatic | That's too bad. The Holy Grail was under his seat. | ||
| pmichaud re-reads Austin's description, looking for understanding. | 20:12 | ||
| Austin | Pmichaud: What I'm trying to do is resolve the class object, then call find_method on it. And that all works, so I refactored it out of another sub into a "find_method" sub that I could call. | ||
| pmichaud | and by "class object" you mean "Parrot class object", as opposed to P6object/NQP protoobjects? | 20:13 | |
| Austin | I mean whatever comes back from get_class. I'm stealing heavily from P6object.pir | 20:14 | |
| So when $class isa 'String', I call get_class, then that doesn't work, so I split('::') on it, then call get_namespace, then call get_class on that. | 20:15 | ||
| Coke | dukeleto - bug introduced here (2d301e4f8217ec0c7dd76e6445aa23c391ce32f8 is first bad commit | ||
| Austin | And *that* is in $class. So then I call $class.get_class() and I wind up back in my sub, rather than off in C someplace like I expected. | ||
| Coke | (which is, of course, a relatively invasive change.) | ||
| pmichaud | okay, if you're using get_class, that's a Parrot object | ||
| Austin | Sorry. $class.find_method -- not get_class | 20:16 | |
| pmichaud | if you put a sub into the Class namespace, either imcc or the method objects might be confusing it | ||
| Austin | That's what I was thinking - this might be a bug. | ||
| Because the generated PIR does not declare this sub as :method, so why dispatch to it? | 20:17 | ||
| pmichaud | because Parrot still thinks it's a good idea to have methods listed in the namespace | ||
| Tene | Austin: my first suspicion is that it's due to :methods going into the namespace | ||
| pmichaud | and for built-in PMC types (such as Class), they might look in the namespaces for methods no matter what. | 20:18 | |
| Tene | so when you put yours into the namespace, maybe it ends up clobbering th eold method | ||
| Austin | Hunh. | ||
| Tene | that's just a guess | 20:19 | |
| Austin | So the method call on builtin::Class is doing a namespace lookup? | ||
| pmichaud | found the bug | ||
| Tene | but, probably related to the :methods in namespaces thing. | ||
| pmichaud | seems to be unrelated | ||
| nopaste coming | 20:20 | ||
| dukeleto starting writing small parrot blog post which is now becoming epic | |||
| nopaste | "pmichaud" at 72.181.176.220 pasted "subs in namespaces automatically treated like methods #1" (16 lines) at nopaste.snit.ch/18332 | 20:21 | |
| pmichaud | note that foo isn't declared :method | ||
| moritz | this is quite like perl 5 :/ | 20:22 | |
| Austin | This is a bug, right? | 20:23 | |
| pmichaud | I'd say yes. | ||
| And i suspect it happens only for the builtin PMC types | |||
| testing | |||
| Austin | You want to fill out the ticket, or shall I? | ||
| pmichaud | you can. my tickets tend to get warnocked. | 20:24 | |
| Austin | :) | ||
| nopaste | "pmichaud" at 72.181.176.220 pasted "works for non-PMC types" (18 lines) at nopaste.snit.ch/18333 | ||
| dukeleto | whoa, I wish I would have found this guide to NQP sooner: en.wikibooks.org/wiki/Parrot_Virtua...Quite_Perl | 20:28 | |
| shorten | dukeleto's url is at xrl.us/bfr8th | ||
| Austin | Thanks, pmichaud++ for the quick examples. TT#1108 | 20:30 | |
| dalek | TT #1108 created by Austin_Hastings++: Subs in "built-in PMC" namespaces are treated as PMC methods | 20:33 | |
| Austin sings "Time has passed, I'd forgotten; Mother Nature does wonderful things. I thought nothing could stop me from lovin' you, but time changes everything." | 20:35 | ||
| Hmm.. new issue - MultiSub does not support get_namespace. :( | 20:38 | ||
| W00t! Trampolines work. | 20:42 | ||
| dukeleto likes jumping on trampolines | 20:44 | ||
| Austin likes automatically generating them. | 20:45 | ||
| dukeleto | parrot hacktivity blog post: leto.net/dukeleto.pl/2009/10/parrot...eport.html | 20:52 | |
| shorten | dukeleto's url is at xrl.us/bfr8yp | ||
| dalek | TT #1109 created by Austin_Hastings++: MultiSub PMC does not support get_namespace method | ||
|
20:58
Whiteknight joined
21:02
bluescreen joined
21:04
TonyC joined
|
|||
| chromatic | Helpful tip: don't include the parameter name when writing the return type in a C function signature. | 21:04 | |
|
21:17
hudnix joined
21:18
AndyA joined
|
|||
| dalek | kudo: 54cfe42 | pmichaud++ | docs/spectest-progress.csv: spectest-progress.csv update: 452 files, 27836 (72.8% of 38211) pass, 0 fail |
21:21 | |
| shorten | dalek's url is at xrl.us/bfr85s | ||
|
21:27
KatrinaTheLamia joined,
AndyA joined
|
|||
| dalek | rrot-plumage: e2f0d58 | leto++ | : [t] Add basic tests for plumage info |
21:40 | |
| shorten | dalek's url is at xrl.us/bfr88p | ||
| chromatic | Oh right, pointer tagging only works if you tag the pointers. | 21:53 | |
|
21:53
Whiteknight joined
|
|||
| dalek | rrot-plumage: 87306d9 | leto++ | : [t] Add some tests for default behavior and when input args are not valid |
21:56 | |
| shorten | dalek's url is at xrl.us/bfr9an | ||
| dukeleto | how does one properly mock tests which fetch/configure/install software (such as plumage)? sounds like I need to include dummy svn/git repos in my test suite | 22:04 | |
|
22:08
darbelo joined
|
|||
| dalek | rrot-plumage: 20d64f5 | leto++ | : [t] More tests for invalid projects |
22:12 | |
| shorten | dalek's url is at xrl.us/bfr9dd | ||
|
22:15
patspam joined
|
|||
| dalek | tracwiki: v27 | dukeleto++ | CallingConventionsOverview | 22:24 | |
| tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfr9er | ||
| dalek | rrot-plumage: 7a0c81a | leto++ | : [tasks] Remove 'teach dalek about gitorious' from tasklist, darbelo++, i... |
22:50 | |
| shorten | dalek's url is at xrl.us/bfr9hw | ||
| japhb | dukeleto++ # Constant plumage commits | 22:51 | |
| Coke | hurm. should git revert -n <sha1> leave me in a state where there's nothing to commit? | 22:53 | |
| Tene | Coke: no. | 22:54 | |
| Whiteknight | dukeleto: ping | ||
| Tene | Coke: 'revert' is for making an 'undo' commit. | ||
| commit the reverse of some different commit. | |||
| you want reset | |||
| git reset --hard HEAD | |||
| will do | 22:55 | ||
| Coke | Yes. I want to revert a commit. | ||
| but I don't want to commit it immediately. I just want to undo <sha1> | |||
| Tene | Coke: -n will apply the change to your working directory *and* the index. | 22:56 | |
| so it's like you then did git add ... | |||
| Coke: if you want to un-add everything, then do your git- revert and then run git reset --mixed HEAD | 22:58 | ||
| Coke | I think I got it. I just did a reset and then did a revert sans -n. I can always remove that commit before git push if it doesn't work out. | 22:59 | |
| ... but it does. shame. no test failures in 'make test', but it killed spectest. | 23:00 | ||
| is there an easy way to see what commits I have locally that aren't in the repo I cloned from? | 23:01 | ||
| diff master? | 23:02 | ||
| darbelo | Did partcl's svn branches get pulled into github? | 23:03 | |
| Coke | darbelo: looks like, yes. | ||
| darbelo | Guess I'll have to get back to work then :) | ||
| chromatic | Testing CallSignature is difficult because if there are bugs, tests won't work. | 23:05 | |
| Tene | Coke: git log master.. | ||
| Coke | that shows my local master, yes? | 23:06 | |
| Tene | Coke: that's the abbreviated form of master..HEAD | ||
| Coke | <blank stare> | ||
| Tene | Coke: try origin/master.. instead then | 23:07 | |
| Coke | ah. 'git cherry origin' looks promising. | 23:08 | |
| Tene++ | 23:09 | ||
| dalek | rtcl: b455eb2 | coke++ | runtime/ (5 files): Revert "PIR cleanup and some refactoring of call_chain manipulation" |
23:14 | |
| shorten | dalek's url is at xrl.us/bfr9kn | ||
| Coke | yay, git, saving me from myself. | 23:15 | |
| Whiteknight | I have a local git repo. How do I put it on github? | 23:22 | |
| their documentation seems to describe every other operation under the sun | |||
| dalek | p-rx: 982f190 | pmichaud++ | src/Regex/P6Regex/Actions.pm: Clean up handling of initial negated character class subrule. |
23:26 | |
| shorten | dalek's url is at xrl.us/bfr9na | ||
| pmichaud | Whiteknight: just a sec | 23:28 | |
| it's github.com/guides/import-an-existing-git-repo | 23:29 | ||
| Whiteknight | that's exactly what I was looking for! Thanks pmichaud++ | 23:30 | |
| Yay! I have a repo on github! | 23:35 | ||
| darbelo | Whiteknight: Where? Where? | ||
| chromatic | Ha, CallSignature is starting to pass its tests. | 23:36 | |
| Whiteknight | github.com/Whiteknight/matrixy | ||
| darbelo | Matrixy? I haden't heard of it before. How awesome is it? | 23:37 | |
| darbelo barely remembers his MATLAB | 23:40 | ||
| Whiteknight | It needs a lot of work, I haven't really touched it in months | 23:45 | |
| I need to come up with a clever name for a linear algebra library bundle for Parrot | 23:47 | ||
| because that's the next repo I'm creating | |||
| darbelo | I've been wanting to do some numerical work on parrot for a while, throw that url at me when it's created. | ||
| Whiteknight | darbelo: help me come up with a good name | ||
| and by "help me", I mean "do it for me" :) | 23:48 | ||
| darbelo | "plap" | ||
| Whiteknight | sexy | ||
| Austin | Convect | ||
| darbelo | Parrot's Linear Algebra Package | ||
| Austin | conure , vectors, convex | ||
| Whiteknight searches wikipedia for some kind of bird that has something to do with matrix multiplication... | |||
| github.com/Whiteknight/parrot-linear-algebra | 23:49 | ||
| Whiteknight got tired of trying to be clever | 23:50 | ||
| Austin | l-a-p-d ? | 23:53 | |
| Whiteknight | yeah, and I could get a bunch of T-Shirts that say LAPD on them | 23:54 | |
| darbelo wants to get parrot 'native' big numbers. | 23:59 | ||