|
Parrot 0.6.3 "Beautiful Parrot" Released | parrotcode.org/ | 5/649/88 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today Set by moderator on 26 June 2008. |
|||
| kid51 | particle: Do you have any thoughts re rt.perl.org/rt3/Ticket/Display.html?id=56928 ? | 00:06 | |
|
00:09
AndyA joined
|
|||
| jonathan | pmichaud: Guess you ain't. :-) But /msg me and let me know what day works best for Rakudo day this week; Wednesday is maybe best for me, but Thu/Fri are do-able too. But on Thursday evening we have Bratislava.pm tech/social meet, so I'd have less hacking time that day...also, note anything you'd like to see my time spent on. kplzthnxbai. | 00:11 | |
| dalek | r29448 | jkeenan++ | parallel: | 00:15 | |
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29448 | |||
| r29449 | Whiteknight++ | gsoc_pdd09: | 00:27 | ||
| : [gsoc_pdd09] remove some cruft, gross over-simplifications on the sweep code and we're still getting the same problem with a prematurely swept pmc | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29449 | |||
|
00:55
dalek joined
00:59
teknomunk joined
01:13
DietCoke joined
|
|||
| dalek | r29450 | coke++ | trunk: | 01:24 | |
| : [codingstd] add an RT to track issues related to un-todo'ing this policy | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29450 | |||
| r29451 | jkeenan++ | parallel: | |||
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29451 | |||
| r29452 | jkeenan++ | parallel: | 01:31 | ||
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29452 | |||
| r29453 | jkeenan++ | noautopack: | 01:33 | ||
| : Creating noautopack in svn.perl.org/parrot/branches | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29453 | |||
| r29454 | jkeenan++ | noautopack-29452: | |||
| : Tagging trunk at r29452 so that the noautopack can later be synched to it. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29454 | |||
|
01:36
daxelrod joined
01:39
Zaba joined
|
|||
| dalek | r29455 | jkeenan++ | noautopack: | 01:40 | |
| : Remove config step auto::pack and associated test. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29455 | |||
|
01:46
TiMBuS joined
|
|||
| dalek | r29456 | jkeenan++ | parallel: | 01:54 | |
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29456 | |||
| DietCoke | (*&#$ is merging slow. | 02:10 | |
| daxelrod | I first parsed that as "is merging slowly" and was trying to figure out what (*&#$ was. :) | 02:11 | |
|
02:12
sandra_f joined
|
|||
| dalek | r29457 | jkeenan++ | parallel: | 02:14 | |
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29457 | |||
|
02:19
Andy joined
|
|||
| DietCoke | ANDY: HOW IS YOUR CAPS LOCK? | 02:20 | |
| Andy | ROCKIN' | ||
| DietCoke | IZ STILL STUCK? | ||
| (sadly, I actually did that by holding the shift key down while typing.) | 02:21 | ||
| daxelrod | DietCoke: Why is that sad? Haven't you remapped capslock to something more useful? | ||
| Whiteknight never deals in the dark arts of key remapping | 02:22 | ||
| Andy | I'm going to start my plugin branch for ack again. | ||
| DietCoke | I'm too used to using loaner keyboards from work. | ||
| on which I rarely have key-remapping abilitah. | |||
| daxelrod | What OS? | ||
| DietCoke | it's like compiling for C89. | ||
| Andy: good luck, we're all counting on you. | 02:23 | ||
| daxelrod: I don't wish to remap my keys at this time, but thank you. =-) | |||
| daxelrod | :P | ||
| Andy | I've got to concentrate concentrate concentrate... | ||
| Hello? Hello? Hello? | |||
| echo echo echo... | |||
| DietCoke | Why aren't I notified about these things!? | ||
| Whiteknight | if you want to do some work in a branch, i've got a GC in sore shape...\\ | ||
| DietCoke | (switching to the SQL for a moment.) | 02:24 | |
| Andy | Now pitching for Pedro Borbone, Manny Mota Mota Mota | ||
| DietCoke | Whiteknight: , we're not doing your homework for you. esp. when you're getting paid for it! | ||
| (*#@&$ the svn commit is taking longer than the merge. | |||
| Whiteknight | it's not homework, it's for the good of the project! :) | 02:25 | |
| DietCoke was actually going to try to hack on tcl-on-pct tonight, but this svn crap is killing his enthusiasm. | 02:26 | ||
| dalek | r29458 | jkeenan++ | parallel: | 02:27 | |
| : Tests needed SKIP block to work on non-Darwin. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29458 | |||
| r29459 | coke++ | tcl_pct: | 02:28 | ||
| : merge -r28501:29456 from trunk | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29459 | |||
| kid51 | DietCoke: *which* svn crap? | 02:29 | |
| DietCoke | mine. | ||
| dalek | r29460 | jkeenan++ | parallel: | ||
| : Tests needed SKIP block to work on non-Darwin. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29460 | |||
| DietCoke | (merging is slow and cumbersome.) | ||
| and with generated files, also painful. | |||
| kid51: I was having problems with svn.perl.org yesterday. I opened a ticket with perl.org; no response, but it got better a few hours after I did that. | 02:30 | ||
| Whiteknight | merging my branch is going to be a nightmare | 02:31 | |
| kid51 | Yes. If you look at scrollback, you'll see that I complained about getting that for ~ 1 hr yesterday a.m. Barney too, IIRC. | ||
| Whiteknight | i can't keep my grubby hands to myself, I have to monkey around in a bunch of files | ||
| kid51 | But it appeared to clear up. I did many commits later in the day and several this evening. | 02:32 | |
| DietCoke | kid51: I just got an IRC-> email ping about it. | ||
| Whiteknight: make sure you run out of time and force chromatic to merge it. I hear he LOVES merging. | |||
| <duck> | |||
| kid51 | I was getting it in serious proportions back in Dec and Jan. | ||
| DietCoke | so, anyone who doesn't read my blog, guess how much weight I've lost since May. =-) | 02:33 | |
| kid51 | avoirdupois or metric? | ||
| Whiteknight | no, i'll get it merged one way or another | 02:34 | |
| i do plan to be a parroteer after the summer is over | |||
| DietCoke | stones, if you're going to be choosy. =-) | 02:36 | |
| cotto_home | over 9000? | ||
| kid51 | 2 | ||
| DietCoke | 2.9 | ||
| kid51 | v.g. | 02:37 | |
| DietCoke | <bow> | ||
| kid51 | Packy did observe that there was a lot less of you! | ||
| DietCoke | Yah, we've known each other since the very early 90s. I've been much bigger than this. | 02:38 | |
| DietCoke sighs, as he has to refer to SYN05 again. | 02:39 | ||
| DietCoke wants a SYN05 that isn't written from a perl5 perspective. | |||
|
02:40
Zaba_ joined
|
|||
| cotto_home | anyone know what'd be a good target test coverage for the built-in PMCs? | 02:41 | |
| kid51 | cotto_home: test coverage ... as in gcov or Devel::Cover ? | 02:44 | |
| cotto_home | gcov (c-level) | 02:45 | |
| dalek | r29461 | jkeenan++ | parallel: | ||
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29461 | |||
| kid51 | About a year ago, ptc did a run of gcov on my site: | ||
| thenceforward.net/parrot/coverage/c...erage.html | 02:46 | ||
| probably long out of date, but may serve as a point of reference | 02:47 | ||
| cotto_home | make cover still works fine | ||
| it just doesn't cover Perl code, iirc | |||
| kid51 | Ah, but for some Perl code we have kid51's site (where coverage analysis is actually running now, so it won't be available for a half hour or so): thenceforward.net/parrot/coverage/c...erage.html | 02:48 | |
| dalek | r29462 | coke++ | tcl_pct: | 02:49 | |
| : [tcl] puts doesn't take comma-separated args; | |||
| : single quoted strings don't work in tcl. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29462 | |||
| kid51 must sleep | |||
| purl | $kid51->sleep(8 * 3600); | ||
| cotto_home | I have the coverage results from ~300 revisions ago, but it'll be nice not to have to build a more recent version. | 02:50 | |
| dalek | r29463 | rgrjr++ | trunk: | 02:55 | |
| : [CORE] Keep Closure:invoke from breaking what newclosure hath wrought. | |||
| : This is a band-aid for RT#56398 that will be removed along with "autoclose." | |||
| : * include/parrot/sub.h: | |||
| : + Add SUB_FLAG_NEWCLOSURE to sub_flags_enum. | |||
| : * src/sub.c: | |||
| : + (parrot_new_closure): Tag the closures we create. | |||
| : * src/pmc/closure.pmc: | |||
| : + (invoke): Only overwrite sub->outer_ctx if no "newclosure" tag. | |||
| : * MANIFEST, t/op/lexicals-2.t (deleted), t/op/lexicals.t: | |||
| : + Merge lexicals-2.t into lexicals.t [per chromatic], remove "todo" | 02:56 | ||
| : from "RT#56398: Bob's recursion bug" case. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29463 | |||
| DietCoke wonders if anyone who understands PCT is here. | 02:57 | ||
| dalek | r29464 | cotto++ | trunk: | 03:09 | |
| : [pmc] add clone test to fixedbooleanarray | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29464 | |||
|
03:10
bgeron joined,
baest_ joined
03:12
Zaba joined
|
|||
| dalek | r29465 | coke++ | tcl_pct: | 03:13 | |
| : Add a roadmap for this version of tcl. | |||
| : I'm not proud. Feel free to jump in here. =-) | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29465 | |||
|
03:13
teknomunk_ joined
|
|||
| dalek | r29466 | coke++ | tcl_pct: | 03:18 | |
| : [tcl-pct] parse the -nonewline option to puts but ignore it for now. | |||
| : Add a comment about grammar hack closer to the grammar. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29466 | |||
| r29467 | coke++ | tcl_pct: | 03:20 | ||
| : [tcl-pct] puts doesn't actually take expressions, it only understands simple values. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29467 | |||
|
03:21
baest joined
|
|||
| dalek | r29468 | coke++ | trunk: | 03:26 | |
| : [tcl] When testing core tests, use a new version of the 8.5 test suite. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29468 | |||
|
03:40
teknomunk__ joined
04:31
sandra_f joined
04:50
Zaba joined
05:17
Psyche^ joined
06:09
Zaba_ joined
06:13
uniejo joined
|
|||
| dalek | r29469 | cotto++ | trunk: | 06:48 | |
| : [pmc] fix resizablebooleanarray's clone, expand/rewrite associated test | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29469 | |||
|
07:01
Zaba joined
07:13
bacek joined
07:14
masak joined
07:17
barney joined
|
|||
| moderator | "Parrot 0.6.4" release is underway, please update NEWS and PLATFORMS | 07:34 | |
| moderator | "Parrot 0.6.4: St. Vincent Amazon" release is underway, please update NEWS and PLATFORMS | 07:39 | |
|
07:48
uniejo joined
|
|||
| dalek | r29470 | bernhard++ | trunk: | 07:51 | |
| : [build] clean up generated directory lib/Parrot/OpLib | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29470 | |||
|
07:57
iblechbot joined
|
|||
| barney | chromatic++ for editing NEWS | 08:10 | |
| moritz | barney++ # taking care of the release | 08:11 | |
|
08:11
Debolaz joined
|
|||
| barney | pmichaud++ see above | 08:11 | |
| nopaste | "moritz" at 89.13.227.19 pasted "failure in t/tools/dump_pbc.t" (8 lines) at nopaste.snit.ch/13579 | 08:19 | |
| moritz | anyone else seeing that? | ||
| dalek | r29471 | fperrad++ | trunk: | 08:24 | |
| : [Pipp] | |||
| : - add PCRE version | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29471 | |||
|
08:29
bacek joined
08:45
bacek joined
|
|||
| barney wonders whether the Bugday is worth announcing | 08:47 | ||
| moritz | in case of doubt, it is ;-) | ||
| masak | oh, is it Release Day today? | 08:56 | |
| dalek | r29472 | bernhard++ | trunk: | ||
| : [distro] Regenerated MANIFEST.SKIP | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29472 | |||
| moritz | masak: yes | 08:57 | |
| masak | \\o/ | 08:58 | |
|
08:58
Zaba_ joined
|
|||
| moritz | hey, rakudo has +950 passing spectests since last release ;-) | 08:58 | |
| masak | that's really not bad. | 08:59 | |
| [++] @devs | |||
| hm, that's not right :) | |||
| <<++>> @devs | |||
| moritz | @devs >>++; | ||
| masak | ah, right :) | 09:00 | |
| Perl 6 is implemented faster than I can learn it these days :) | |||
| moritz | that's partly true for me as well | 09:01 | |
| for example I never used generics in Perl 6, and they are implemented now | 09:02 | ||
| and all this role and class stuff - I know some of it, but not really in depth | |||
| masak | ah, yes. generics | ||
| is there a convincing use case for generics? I mean, Perl 5 is a very weakly typed language, and suddenly in Perl 6 we have generics. what are they intended for? | 09:03 | ||
| moritz | give the type fetishists what they want? ;-) | 09:04 | |
| masak | hehe | ||
| are there things like Java's <? extends T> and <? super T> in Perl 6's generics capabilities? | |||
| masak has to go read up on Sxx | 09:05 | ||
| moritz | situations like "return something of the same types as you gave me" and "expect two parameters of same type" aren't all that uncommon | ||
| masak | true | 09:06 | |
| moritz | masak: maybe there's also something interesting on www.dlugosz.com/Perl6/ , ISTR that he worked a bit on generics | ||
| masak | good idea | ||
| purl | masak: Good Idea: Stopping to smell the roses. Bad Idea: Stopping to feel the roses. | ||
| masak | purl: your wisdom baffles me sometimes | ||
| purl | masak: excuse me? | ||
| masak | ...and sometimes not. | ||
|
09:42
bacek joined
|
|||
| barney | make fulltest looks fine under Linux | 09:43 | |
| barney is about to commit changes for Parrot 0.6.4 | 09:44 | ||
|
09:45
tuxdna joined
09:55
Zaba joined
|
|||
| dalek | r29473 | bernhard++ | trunk: | 09:55 | |
| : Changes for Parrot release .... | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29473 | |||
|
09:57
tuxdna joined
|
|||
| dalek | r29474 | bernhard++ | trunk: | 09:58 | |
| : [docs] Pop up editor for commit message. Pasting with -m option is dangerous. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29474 | |||
| r29475 | fperrad++ | trunk: | 10:06 | ||
| : [PLATFORMS] | |||
| : - MinGW gcc 3.4.5 updated | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29475 | |||
| r29476 | bernhard++ | trunk: | 10:15 | ||
| : [docs] don't recommend to use '-s',capture more verbose output from 'make' | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29476 | |||
| r29477 | bernhard++ | RELEASE_0_6_4: | 10:50 | ||
| : tagged release 0.6.4 | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29477 | |||
|
10:58
iblechbot joined
11:09
kj joined
11:16
ruoso joined
|
|||
| moderator | "Parrot 0.6.4 "St. Vincent Amazon" Released | parrotcode.org/ | 15/648/80 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today". | 11:20 | |
| dalek | bernhard.schmalhofer@gmx.de | Parrot: | 11:22 | |
| link: www.perlfoundation.org/parrot/index.cgi?parrot | |||
| barney | Parrot 0.6.4 flies, en.wikipedia.org/wiki/St._Vincent_Amazon | 11:44 | |
| moritz | barney++ | 11:45 | |
|
12:03
bacek joined
|
|||
| bacek | congratulations everyone | 12:09 | |
| masak | cheers! | 12:10 | |
| dalek | r29478 | jkeenan++ | parallel: | 12:20 | |
| : Correct wrong no. of tests in plan. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29478 | |||
|
12:21
uniejo joined
|
|||
| dalek | r29479 | jkeenan++ | parallel: | 12:22 | |
| : Consolidate multiple test files per configuration step into a single file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29479 | |||
|
12:26
mj41 joined
|
|||
| bacek | perl6: say log(-1+0i,) | 12:27 | |
| polyglotbot | OUTPUT[0ā¤] | ||
| bacek | perl6: say sqrt(-1+0i,) | 12:29 | |
| polyglotbot | OUTPUT[6.12303e-17+1iā¤] | ||
| moritz | that's better ;) | ||
| barney just bought ticket for YAPC::EU | 12:34 | ||
| moritz | so sad that I can't go there :( | ||
| pmichaud | barney: ping | 12:36 | |
| jonathan: wednesday I'll be gone all day on a business trip, so thu or fri are better | 12:37 | ||
| barney: you now have comaint on the modules in question -- try requesting a reindex | |||
| moritz | pmichaud: you accidentially duplicated the "added generic type declarations" lines in NEWS | ||
| but I noticed only after the release | 12:38 | ||
| pmichaud | moritz: oops. chromatic and I ended up editing NEWS at the same time and so I had to go clean up the conflicts | ||
| and I guess I missed one. | |||
| it's not too bad -- we'll just claim we added generics in two steps. :-) | |||
| "twice as generic as before!" | |||
| moritz | should I remove one? or is NEWS a historical document that shouldn't change in retrospect? | 12:39 | |
| lol | |||
| pmichaud | remove one. | ||
| nopaste | "bacek" at 58.111.0.124 pasted "Complex.log() implementation for pmichaud/moritz" (30 lines) at nopaste.snit.ch/13583 | 12:43 | |
|
12:43
wknight8111 joined
|
|||
| particle | message kid51 re #56928: i haven't built parrot in two weeks, and i trust andy dougherty, so if it looks like it works fire away | 12:43 | |
| purl | Sorry, I've never seen kid51 before. | ||
| dalek | r29480 | moritz++ | trunk: | 12:45 | |
| : [NEWS] removed (nearly) duplicate line | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29480 | |||
| moritz | bacek: I just wonder if they should really go into src/builtins/any-str.pir | ||
| bacek | moritz: actually no. | ||
| And forget this patch for the moment. | 12:46 | ||
| purl | bacek, I didn't have anything matching this patch for the moment | ||
| pmichaud | complex methods we've been putting into Complex | ||
| bacek | It didn't work in 'clean' checkout | ||
| moritz | pmichaud: ok, thanks for clarifying | ||
| bacek: applies cleanly nonetheless, testing now | 12:47 | ||
| pmichaud | =item sqrt should probably read =item log :-) | 12:48 | |
| moritz | pmichaud: already fixed that locally | ||
| bacek | moritz: test will fail | ||
| pmichaud | moritz++ | ||
| moritz | I noticed, yes ;) | ||
| nopaste | "bacek" at 58.111.0.124 pasted "Correct Complex.log() implementation for pmichaud/moritz" (101 lines) at nopaste.snit.ch/13584 | 12:51 | |
| bacek | much better version :) | ||
|
12:52
Zaba joined
|
|||
| bacek | moved log() to any-num | 12:52 | |
| +exported from Complex. | |||
| pmichaud | I've been keeping the functions in alphabetical order inside of any-num.pir | ||
| other than that, the patch looks good. | 12:53 | ||
| bacek | pmichaud: ouch. Didn't notice it. I'll change patch | ||
| pmichaud: 'int()' in wrong place :) | 12:54 | ||
| pmichaud | I left int() next to truncate, though | ||
| since they're really the same thing. | |||
| but I guess it can be alphabetized also. | 12:55 | ||
| barney requested reindexing | |||
| nopaste | "bacek" at 58.111.0.124 pasted "#3 Correct Complex.log() implementation for pmichaud/moritz" (125 lines) at nopaste.snit.ch/13585 | 12:57 | |
| bacek | with reordered functions ( int() as well) | 12:58 | |
| moritz | bacek: ok, I'll smoke & apply | 12:59 | |
| bacek++ | 13:00 | ||
| ./rakudo -e 'say log(-1+0i)' | 13:01 | ||
| 0+3.14159i | |||
| bacek | log10 is harder... I can just '!EXPORT' it... | 13:02 | |
| moritz wonders if we should start implementing the two arg form of log | 13:03 | ||
| and we need to test it | |||
|
13:04
gryphon__ joined
13:05
wknight8111 joined,
Zaba_ joined
|
|||
| bacek | pmichaud: How I can invoke parent's method from child's override? | 13:06 | |
| particle | SUPER:: ?? | 13:07 | |
| pmichaud | there's not a way to do it at present. | ||
| at least, not that I'm aware of. | |||
| do you mean a parent's vtable method or just a parent method? | 13:08 | ||
| (a parent method in PIR) | |||
| bacek | just method | ||
| pmichaud | given that class Foo is a parent of Bar | 13:09 | |
| if you have Foo's protoobject | |||
| you can do | |||
| $P0 = find_method fooproto, 'methodname' | |||
| bar.$P0(...) | |||
| i.e., look up the parent method specifically and invoke it | |||
| bacek | will it work for vtable? like bar.$P0(self,..)? | 13:10 | |
| pmichaud | no, it doesn't work for vtable, since find_method doesn't retrieve vtable methods | ||
| bacek | ok, thanks | ||
| pmichaud | also, you don't need to pass self, since bar is self | ||
| (I meant 'bar' here to be an instance of class Bar) | |||
| bacek | ah, ok. | ||
| pmichaud | so I probably should've said | ||
| self.$P0(...) | |||
| bacek | pmichaud: so, I assume, using this technique we can implement authothreading for Junctions? | 13:12 | |
| override 'find_method' in Junction and construct proper closure on fly. | |||
| Or my thought totally wrong? | 13:13 | ||
| dalek | r29481 | moritz++ | trunk: | ||
| : [rakudo] add Complex log() and re-arranged any-num.pir, bacek++ | |||
| : Patch Curtesy of Vasily Chekalkin <back at bacek.com> | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29481 | |||
| pmichaud | you mean autothreading for methods on junctions? yes, essentially we'll override find_method, I suspect. But even then it'll be a bit tricky. | 13:14 | |
| moritz | can we add bacek to CREDITS to shorten the attribution in the commit messages? | ||
| bacek | moritz: jonathan did it already | ||
| pmichaud | the attributions are supposed to be that way for anyone w/o a commit bit | ||
| at least, that's what I was once told | |||
| moritz | pmichaud: ok | 13:15 | |
| bacek | moritz: and you've made typo in my email :) | ||
| moritz | oh dammit, sorry | ||
| somehow copy&paste doesn't work in the vim instances that "svn ci" spawns | 13:16 | ||
| so I retype it every time, and hope I don't amke a mistake | |||
| moritz-- | |||
| particle | missppeelled "courtesy" also | ||
| bacek | moritz: no worries (It was first phase that I learned to say in all situations in Australia :) | ||
| moritz | me-- again | ||
| bacek | karma me | 13:17 | |
| purl | bacek has karma of 52 | ||
| bacek | karma (me) | ||
| purl | (me) has neutral karma | ||
| bacek | not so bad :) | ||
| pmichaud: I failing to implement 'log10()' for Complex... There is log10 implementation in src/pmc/complex.pmc, but I can't call it from rakudo's Complex.log10 | 13:18 | ||
| pmichaud | I don't see log10 in complex.pmc | 13:21 | |
| moritz | ok, here begins the fun: log(-1i) -> 0-1.5708i. The test checks for 1i*pi*1.5, which is also correct, but on a different complex plane. What should I do? | ||
| should we standardize on one complex plane? or adapt the tests to deal with any complex plane? | 13:22 | ||
| pmichaud | what do most other languages do? To me, standardizing on one complex plane sounds right, but I'd check with p6l | 13:23 | |
| moritz | Mathematica returns the same result as Rakudo | 13:24 | |
| but I don't know if it does so consistently | |||
| bacek | pmichaud: my bad... sorry | 13:25 | |
| perl6: say ((1|2) + (3&4)).perl | 13:27 | ||
| polyglotbot | OUTPUT[get_string() not implemented in class 'Junction'ā¤current instr.: 'infix_junction_helper' pc 7790 (src/gen_builtins.pir:5050)ā¤called from Sub '_block11' pc 67 (EVAL_13:21)ā¤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)ā¤called from Sub | ||
| ..'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir... | |||
| pmichaud | it should be possible to write .perl for Junction | 13:28 | |
| moritz | perl6: say ((1|2) + (3&4)).values | ||
| polyglotbot | OUTPUT[get_string() not implemented in class 'Junction'ā¤current instr.: 'infix_junction_helper' pc 7790 (src/gen_builtins.pir:5050)ā¤called from Sub '_block11' pc 67 (EVAL_13:21)ā¤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)ā¤called from Sub | ||
| ..'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir... | |||
| pmichaud | note that ((1|2) + (3&4)).values would likely still be a Junction | 13:29 | |
| (a List of junctions, anyway) | |||
| Zaba_ | I find the fact that | and & are no more binary or/and kinda confusing | 13:30 | |
| masak | which one takes priority, '|' or '&' ? | ||
| moritz | masak: & probably | ||
| masak | ok, so a list of two | junctions then | ||
| (4|5, 5|6) | 13:31 | ||
| pmichaud | yes, that seems right | 13:32 | |
| masak | there oughta be a method to deeply de-junctify a value | ||
| pmichaud | masak: so, what would we get in the case of the above? | ||
| masak | pmichaud: I don't know exactly. something well-behaved. maybe a List subclass that indicates that it contains and-ed values, and the elements similarly instances of a subclass indicating or-ed values | 13:34 | |
| or if we prefer to not subclass, separate classes for that. or something else. | 13:35 | ||
| perhaps something akin to the inner structure of $/ | |||
| pmichaud | sure, those can work | 13:36 | |
|
13:36
wknight8111_ joined
|
|||
| masak | if the $/ alternative is feasible, I like that one the best | 13:36 | |
| pmichaud | although "a List subclass that indicates that it contains and-ed values" sounds a lot like and(), with the exception of not being a List subclass :-) | ||
| bacek | moritz: autothreading not implemented for Junctions (yet) | ||
| pmichaud | we had autothreading for junctions implemented at one point but it slowed things down a fair bit | 13:37 | |
| so I disabled it until we do more work on dispatching in general | |||
| bacek | pmichaud: why it slowed things? | ||
| masak | pmichaud: the exception being that I can examine a List object, whereas a junction behaves like a value with MPD | ||
| pmichaud | well, I can examine a Junction, too, with: $junc.values[3] | 13:38 | |
| and for "nested junctions", it's then $junc.values[0].values[1] which looks a lot like $/ :-) | 13:39 | ||
|
13:39
britneypire joined
|
|||
| pmichaud | (autothreading on junctions) -- actually, I'm guessing that methods don't autothread over the invocant | 13:41 | |
| now that I think about it a bit more | |||
| so there's no need to overload find_method | |||
| masak | pmichaud: I'm pretty happy with that | ||
| what's the way to test whether what I'm holding is radioac... er, junctive? | |||
| pmichaud | $x ~~ Junction | 13:42 | |
| ? | |||
| masak | but of course. thanks. | ||
| that means that I can write my deep dejunctifier, should I ever need it | |||
| I'm contented. | |||
| bacek | pmichaud: last 4 tests in S29-str/index.t... | 13:47 | |
| Zaba_ | does $x ~~ SomeClass return true whether $x is of SomeClass? | 13:48 | |
| moritz | Zaba_: yes | 13:49 | |
| Zaba_ | nice. | ||
| no .isa()? | |||
| moritz | I think there's .isa also, but ~~ does more | ||
| Zaba_ | I know that ~~ is used for regex matching too | 13:50 | |
| moritz | for example if SomeClass is actually a role, and $x does SomeClass, ~~ will return True and .isa will false | ||
| Zaba_ | oh. | ||
| interesting. | |||
| moritz | so $obj ~~ Type actually checks if "$x is of type Type", for a useful value of "is of type" | 13:51 | |
| Zaba_ | $obj ~~ Something checks whether $obj is of type Something, or does role Something, and that's all? | 13:54 | |
| pmichaud | depends on what Something is, but yes. | 13:55 | |
| moritz | if Something is a type name, yes | ||
|
13:57
jhorwitz joined
|
|||
| dalek | r29482 | pmichaud++ | trunk: | 14:01 | |
| : [rakudo]: spectest-progress.csv update, 95 files, 1695 passing tests | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29482 | |||
| bacek | moritz: around? | 14:02 | |
| purl | nope. | ||
| moritz | bacek: partially | 14:03 | |
| purl | partially is already too much w/o proper locking or shared PMCs | ||
| moritz | purl, forget partially | ||
| purl | moritz: I forgot partially | ||
| moritz | purl, forget around? | ||
| purl | moritz: I forgot around | ||
| pmichaud | barney: let me know if the reindexing fails/succeeds | ||
| jonathan | pmichaud: OK, maybe we make it Friday so I get a full day on it. | 14:04 | |
| pmichaud | jonathan: works for me | ||
| japhb | Congrats to everyone on the Parrot release! | 14:05 | |
| jonathan | (backtrack) methods called on a junction are methods on the junction object itself | ||
| japhb | Anyone happen to know what the news item '+ improved IMCC register allocator' referred to? Improved how? | ||
| nopaste | "bacek" at 58.111.0.124 pasted "2-args log implmentation for moritz" (72 lines) at nopaste.snit.ch/13586 | 14:07 | |
| pmichaud | note that the "2-arg" implementation is really supposed to be done with an optional arg :-) | 14:09 | |
| moritz | does it make a difference? | ||
| jonathan | pmichaud: How's things on the lexicals/closures? I saw the post on p6l... | 14:10 | |
| pmichaud | jonathan: no response on p6l yet. Until I get a response there, I'm not sure I can progress | ||
| moritz: S29 shows log as having a named arg | 14:11 | ||
| bacek | pmichaud: logick is quite different. My first version was with optional arg. But this one is much easy to understand (for me at least) | ||
| jonathan | pmichaud: OK. Bob seems to have put a patch in that keeps us and him happy for now, though. | 14:12 | |
| pmichaud | jonathan: I agree, so I may just let it simmer a while | ||
| jonathan | OK. | ||
| pmichaud | however, I think we may quickly run into difficulty with recursion | ||
| or closures | |||
| purl | Closures make washort's CS teacher happy | ||
| pmichaud | or both | ||
| jonathan | The recursion example that used closures that I hand-compiled worked... :-) | 14:13 | |
| There are other cases though, that I'm not convinced will. Well, I guess we can just find what's broken and add them to tests as fudged. | |||
| Zaba_ | hand-compiled? | 14:14 | |
| jonathan | Zaba_: I took the source in Perl and wrote PIR that was close to what I'd expect it to compile down to. | 14:15 | |
| Zaba_ | aha | ||
| pmichaud | jonathan: I'm worried about something like if cond { $a = &foo; } | 14:16 | |
| jonathan | pmichaud: Does that do a newclosure on foo? | ||
| pmichaud | by definition, the newclosure generated for &foo won't be in the same scope that defines foo | ||
| jonathan | Right. | ||
| NotFound | Someone wants to look at the .parrot_current_rev issue before releasing? | 14:17 | |
| pmichaud | NotFound: I think the release already happened. | ||
| NotFound | Then not ;) | ||
| pmichaud | jonathan: that simple case is why I think that newclosure as presently constituted can't solve our problems | ||
| (unless we do lots of really odd manipulations to move the newclosure operation out of the nested block) | 14:18 | ||
| anyway, on sat/sun I was feeling fairly comfortable that I could come up with a clean spec, but I really need an indication of what happens for the examples I posted to p6l | 14:19 | ||
| jonathan | pmichaud: OK, I think clone is what we actually want to emit. | 14:20 | |
| (for reference taking) | |||
| pmichaud | I agree. | 14:21 | |
| jonathan | OK | 14:26 | |
| Guess we can arrange later on, what I look at on Friday | |||
| pmichaud | I'll have time to think about things while on the planes tomorrow | ||
| jonathan | If you've no particular goals, I may do anonymous classes, which should be easy-ish. | ||
| OK. | |||
| pmichaud | today is a little hectic preparing for trips and getting ready for extended travels starting next week | 14:27 | |
| jonathan | Sure, I'm pretty busy today too. | ||
| pmichaud | originally my trip tomorrow was for one 90 minute meeting. In the past 24 hours it's increased to be four meetings (ranging from 30 mins to 120 mins) | 14:28 | |
|
14:29
cognominal joined,
iblechbot joined
|
|||
| jonathan | Ouch! | 14:30 | |
| pmichaud | well, they all pay pretty well. :-) | ||
| jonathan | Getting paid = good. :-) | 14:31 | |
| pmichaud | afk, errands | 14:33 | |
|
14:35
kjs_ joined
14:37
DietCoke joined
|
|||
| DietCoke | I need some PCT guidance. | 14:38 | |
| ee. | |||
| Tene prods DietCoke | 14:39 | ||
| DietCoke | For tcl, my plan is to fake the non grammar by pretending the builtin functions are originally part of the language syntax. | 14:40 | |
| Tene | Right. | 14:41 | |
| DietCoke | but I don't want to paint myself into a corner when I have to implement [rename], (which lets you rename even the builtins). So I was thinking that I was going to need a sub somewhere that corresponded to the runtime version... but I think if I am going to support changing the grammar anyway (to remove things), I can just make rename support changing the grammar so that [rename puts say] DTRT. | 14:42 | |
| ... so I think I just talked myself down from a ledge there. | |||
| so, "we'll be able to update the grammar at runtime at some point, right?" | |||
| (I also need to allow user defined proces to re-parse themselves if they're invoked after the grammar changes. and also only run one command at a time.) | 14:43 | ||
| NotFound | DietCoke: will not be easier to not trying to fake the non grammar? | 14:45 | |
| DietCoke | also, how do I mark a string literal in a grammar so my action can tell if it was present? | ||
| NotFound: ... I can't parse that. | |||
| Tene | DietCoke: $<foo>='zomglolwtf' ? | 14:46 | |
| NotFound | DietCoke: if tcl parsing is oriented to runtime, trying to do it at compile time can be impossible. | ||
| moritz | DietCoke: don't parse things at the language level you don't have to parse, and internally have a number of parsing helper functions? | ||
|
14:47
Zaba joined
|
|||
| Tene | You could take the approach I'm moving lolcode away from. ;) | 14:48 | |
| pmichaud | back | 14:49 | |
| DietCoke | NotFound, moritz: at which point, what's the point of using PCT? | ||
| NotFound | DietCoke: maybe none. | 14:50 | |
| DietCoke | I will refrain from making a snarky comment about dynamic language support. =-) | ||
| moritz | DietCoke: dunno. | 14:51 | |
|
14:51
teknomunk joined
|
|||
| DietCoke | in trunk, partcl does the runtime dispatch just fine. I was trying to use PCT to provide some pre-compiled versions of the standard builtins. | 14:52 | |
| (rather than having to handroll PIR for everything, which I'm doing now.) | |||
| Abusing the grammar in this fashion seemed a reasonable compromise. I'm open to suggestions. | |||
| NotFound | DietCoke: You can't just call the standard builtins in the same way as user defineds? | 14:53 | |
| DietCoke | yes. I can. see trunk. | 14:54 | |
| NotFound | So what are you trying to do, pre-compile the calls to them? | 14:56 | |
| DietCoke | Trying to unroll them for speed. | ||
| puts $a -could- compile down to "say $P1" if we were clever. | |||
| moritz | HLL JITting ;) | ||
| DietCoke | right now it compiles down to an insane amount of PIR plus the entire tcl runtime. | 14:57 | |
| NotFound | DietCoke: A nigthmare solution can be to make an opcode for each buitin, an have the implementation for that opcode check at runtime if the function has been redefined. | 14:59 | |
| DietCoke | that would involve writing the builtins in C which is even worse than writing them in PIR. =-) | 15:01 | |
| NotFound | You can at the same time build a way to define opcodes implemented in pir ;) | 15:02 | |
| DietCoke | So, anyway, back to my PCT approach. =-) | ||
|
15:06
donaldh joined
|
|||
| DietCoke | tene: something like: 'puts' $<nonewline>=[ '-nonewline'? ] <value> ';' | 15:06 | |
| ? | |||
| pmichaud: should we be calling NQP files ".pm" ? | 15:08 | ||
| (as opposed to ... .nqpm, I suppose.) | |||
| Tene | $<nonewline>=['-nonewline']? is what I was thinking | ||
| or [$<nonewline>='-nonewline']? | 15:09 | ||
| NQP is a subset of Perl 6. All NQP programs are valid Perl programs with the same meaning, yes? | 15:10 | ||
.oO(Should NQP's test suite also be running the tests with rakudo?) |
|||
| DietCoke | Tene: my current annoyance is that all my editors want to treat it as perl5 source. | 15:11 | |
| NotFound | Maybe the answer is "Not Quite" X-) | ||
| moritz | DietCoke: # vim: ft=perl6 | 15:12 | |
| modelines++ | |||
| of course that only works for vim, though | |||
| Tene | I have plans to work on lolcode and cardinal again tonight. | 15:13 | |
| I plan to have lolcode generating a normal AST by the end of the week and completely removing the ugly runtime lookup stuff. | |||
| I should be able to then take that same approach to improve cardinal quite a bit. | 15:15 | ||
| pmichaud | DietCoke: I'm calling them .pm, yes. In theory anything that NQP compiles Perl 6 should be able to compile. | 15:21 | |
| what does [rename] do, exactly? | |||
| if I rename a builtin, does it stay that way permanently? | |||
| DietCoke | moritz: that should be added to the language shell. | ||
| pmichaud: yes. | |||
| pmichaud | so, just replace the existing builtin with the new one | 15:22 | |
| DietCoke | which is fine when everything is runtime dispatch. | ||
| Not so fine if the grammar is at all smart about the builtin processing. | |||
| pmichaud | where "grammar is smart" means...? | ||
| DietCoke | let's say I define [if] in the grammar to take advantage of the if past nodes. | 15:23 | |
| then someone calls rename. | |||
| say, [rename if iffy] | |||
| so if I've added it to the grammar, I have a lot of things to update when that happens, and there may not be a simple builtin func to call at that point. | 15:24 | ||
| (whereas in trunk, everything is a sub. I just change the name of the sub in the main:: namespace.) | |||
| moritz | can you have a symbol table that is updated at parse time? | 15:25 | |
| pmichaud | I'd probably start by not using the if past nodes | ||
| i.e., keep [if] as a runtime op for now | |||
| yes, this might mean that pct is not very useful for tcl | |||
| moritz | then you could parse for an identifer, and check if it's the current name for 'if' | ||
| pmichaud | we don't really have the concept of 'thunks' yet in parrot or pct | 15:26 | |
| DietCoke | I guess I'm not seeing the value of pct for me at all, then. =-) | 15:27 | |
| pmichaud | there might not be one. | 15:28 | |
| once we have protoregexes, though, it might be easier to redefine 'if' | |||
| and other "keyword"-like tokens | |||
| ....actually | |||
| come to think of it | |||
| purl | well, come to think of it is how the zombie monkies come in the night and pluck the brains from unsuspecting children while they sleep | ||
| pmichaud smiles evilly | 15:29 | ||
| you probably don't want to change the grammar as much as you want to change the action method -- the part that produces the PAST | |||
| and *that's* very easy to do. | |||
| DietCoke | I do want to change the grammar. | ||
| pmichaud | because 'if' parses differently after it's been renamed? | 15:30 | |
| oh, because the keyword itself has changed | |||
| so, you want to dynamically look up keywords from a hash or array | |||
| DietCoke | if my grammar has 'puts [$<nonewline>=-nonewline] <value>' before, and someone creates a user defined proc called puts that overrides it, I can't have that nonewline stuff in the grammar anymore. | ||
| pmichaud | okay | 15:31 | |
| you're definitely after protoregexes then | |||
| DietCoke | Was hoping to use PCT to avoid a lot of the manual argument mangling I have to do. | ||
| pmichaud | with a protoregex you'd have term:puts { $<sym> [$<nonewline>=-nonewline] } in the original grammar | ||
| DietCoke | er, I was missing a ? there. | 15:32 | |
| pmichaud | but after someone redefines puts it'd replace that rule with something less specific | ||
| i.e., you'd end up with a derived grammar | |||
| and then parse using the derived grammar. Perl 6 will be doing the same thing. | |||
| DietCoke | I figured in that case, I'd just have a default "command" dispatch, and by removing puts, it would fall back to the current trunk-like behavior. | ||
| pmichaud | that can work also. | 15:33 | |
| is -nonewline part of the grammar normally in Tcl? | |||
| DietCoke | grammar? no. | ||
| it's an argument to puts. | |||
| pmichaud | so why is it parsed specifically in the grammar? | ||
| DietCoke | so I don't have to do by hand when redefining puts isn't something that happens all the time. | 15:34 | |
| pmichaud | can't the default puts (function) simply parse -nonewline as part of its arguments? | ||
| DietCoke | ... I keep having the same conversation over and over here. =-) | ||
| yes. that's what I'm doing in trunk right now. | |||
| pmichaud | I'm missing something. | ||
| DietCoke | I am trying to generate more efficient bytecode. | 15:35 | |
| pmichaud | I'm questioning why 'puts' appears in the grammar at all, if the builtin sub already does the argument processing | 15:36 | |
| DietCoke | I don't want the builtin sub. | ||
| I am forced to have it in trunk. | |||
| pmichaud | you want something more efficient | ||
| okay, I got back to what I said earlier, then | |||
| DietCoke | so puts doesn't appear in trunk's grammar. | ||
| pmichaud | you don't want to do the "more efficient" part in the grammar -- you want to do it in the action methods | ||
| DietCoke | it only appears in the tcl_pct's branch's grammar. | ||
| pmichaud | let the action method decide if it's safe to use the more efficient version or to use the built-in version | 15:37 | |
| moritz | DietCoke: can the rename be traced at compile time? | ||
| DietCoke | and where would I define this more efficient version? | ||
| NotFound | DietCoke: A fast an efficient tcl will not be counter-natural? X-) | ||
| moritz | DietCoke: or can you do stuff like if rand < 0.5 [rename foo bar]? | 15:38 | |
| DietCoke | moritz: sure you cna. | ||
| pmichaud | we don't need to trace the rename at compile time | ||
| unlike many of the other compilers we're working with, tcl's model would likely be "parse one command, execute it" | |||
| DietCoke | (especially if we're running the compiler after every command anyway) | ||
| pmichaud | i.e., it's more of an interpreter than a compiler. | 15:39 | |
| DietCoke | pmichaud: by doing this in the actions, though, i'd always need to have a fallback of a runtime version of a command, no? | ||
|
15:39
cognominal joined
|
|||
| pmichaud | DietCoke: no. | 15:39 | |
| in the actions you can do: the equivalent of | |||
| if sub puts exists then generate past to call that sub | |||
| else generate past to do XYZ directly | |||
| NotFound | pmichaud: Wait for the day I implement a Basic line oriented, able to modify his own code by POKE. That day you'll know what a pure interpreter is X-) | 15:40 | |
| pmichaud | i.e., inside the action methods we can query the state of the current runtime and choose to do different things based on that | 15:42 | |
| DietCoke | pmichaud: I'd need something to keep track of renames and be able to dispatch based on that. the original builtin 'puts' could be renamed to 'say', e.g. That approach might work. So then I could write my "compiled" versions in NQP/past instead of how I do it now. | ||
| pmichaud | DietCoke: correct. | ||
| and PAST even allows inlined PIR segments | |||
| DietCoke | what about user-defined procedures? My original plan was to basically recompile them if someone had called 'rename' anywhere. | 15:43 | |
| (since if they call puts and someone's called rename since the proc was defined, it needs to use the new behavior.) | |||
| pmichaud | DietCoke: it might be worthwhile to keep the PAST tree around | ||
| in fact | |||
| hmmmm | 15:44 | ||
| (thinking) | |||
| I think I have to go back to my earlier comment, that I'd start by doing the builtins as subs and then figure out ways to optimize after that :-) | 15:45 | ||
| DietCoke | "that's trunk" | ||
| pmichaud | yes, I got that part. :-) | 15:46 | |
| DietCoke | except mdiep and I handrolled our own way of optimizing things. | ||
| pmichaud | if you already have the builtins in trunk, then doing a first cut of a simple pct-version is easier too, yes? | 15:47 | |
| DietCoke | not for me, no. =-) | ||
| my pct-fu is "start with a brand new empty shell" | |||
| I would not be averse to someone trying out PCT against tcl as it stands today, but I suspect that'd be non-trivial for me to do. | 15:48 | ||
| pmichaud | this is something I would _love_ to sink my teeth into, honestly, and I probably will at some point. But it'd be late august before I can do it | 15:49 | |
| DietCoke | maybe I can bug tene into doing it. =-) | 15:51 | |
| dalek | r29483 | cotto++ | trunk: | 15:52 | |
| : [pmc] add resizablebooleanarray test, fix codingstd goof | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29483 | |||
| pmichaud | erands -- bbiaw | 15:53 | |
|
16:01
AndyA joined
16:05
Infinoid joined
|
|||
| barney | pmichaud: reindexing worked for the individual module, but search.cpan.org/~bschmal/parrot-0.6.4/ is still said to be unauthorized | 16:12 | |
|
16:14
rlb3 joined
|
|||
| dalek | r29484 | coke++ | trunk: | 16:17 | |
| : update ticket pointer to new system. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29484 | |||
|
16:22
Zaba_ joined
|
|||
| particle | barney: you need to submit a request to reindex iirc | 16:25 | |
| i forget if that's via pause, or if you need to email brian_d_foy et al | |||
| DietCoke | we should write that down if it's not already in the doc. | 16:27 | |
| particle | i think brian wrote a doc about it | ||
| docs/project/pause_guide.pod | |||
| barney | I reindexed parrot-0.6.4.tar.gz. Right now I requested to reinedex parrot-0.6.4.meta | ||
|
16:28
sjansen joined
16:33
julian_ joined
16:37
cjfields joined
|
|||
| dalek | r29485 | julianalbo++ | trunk: | 16:39 | |
| : Update .parrot_current_rev in Configure if possible | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29485 | |||
|
16:43
paco joined
|
|||
| dalek | r29486 | julianalbo++ | trunk: | 16:43 | |
| : Update .parrot_current_rev in Configure if possible-fix | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29486 | |||
|
16:51
Zaba joined
|
|||
| dalek | r29487 | bernhard++ | remove_getfd: | 16:52 | |
| : #48310: [DEPRECATED] getfd opcode | |||
| : Create branch 'remove_getfd' for working on RT #48310 | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29487 | |||
| r29488 | julianalbo++ | trunk: | 16:55 | ||
| : Update .parrot_current_rev in Configure if possible-fix 2 | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29488 | |||
|
16:56
Zaba_ joined
|
|||
| Tene | I don't think I did anything this week for #ps | 16:58 | |
| Tene reads svn log | |||
| orite, lolcode switches for jhorwitz | |||
| purl: parrotsketch? | |||
| purl | parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch | ||
| Tene | 1.5 hr | 16:59 | |
| DietCoke | tene: if you're bored you could figure out why ../../parrot tcl.pbc library/tcltest/tcltest.tcl is losing track of a command name and replacing it with a $P register. | ||
|
17:00
chromatic joined
|
|||
| DietCoke | (or convert tcl in trunk over to using PCT with as little other modifications as possible.) | 17:01 | |
| barney | Tene: or look at RT #56828 | ||
| dalek | r29489 | julianalbo++ | trunk: | 17:02 | |
| : Update .parrot_current_rev in Configure if possible-fix 3 | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29489 | |||
| barney | search.cpan.org/~bschmal/parrot-0.6.4/ is now authorized | 17:03 | |
| moritz | YaY | ||
| dalek | r29490 | moritz++ | trunk: | 17:04 | |
| : [rakudo] add and test Str.trans, cjfields++ | |||
| : Patch courtesy of Chris Fields <cjfields at uiuc.edu> | |||
| : Adds one file to spectest_regression, +37 passing tests | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29490 | |||
| NotFound | That's odd. If I don't make an update after the commit, svn info does not reflect the commited rev number. | ||
| moritz | NotFound: that's because your revision number could be out of date | 17:05 | |
| NotFound: if somebody changed other parts of the repo between your last 'svn up' and 'svn ci' | |||
| NotFound | moritz: but svn knows what is the number, it tells it at commit end. | 17:06 | |
| moritz | NotFound: yes, but the rest of your repo is not in that state | 17:07 | |
| NotFound | Ah, yes, I see the point. | ||
| Tene | DietCoke: and if I'm not bored? | 17:08 | |
| DietCoke | Then I presume you have other things to work on. | 17:09 | |
| NotFound | Someone can test this last commit and tell if Configure.pl shows the correct revision number? | 17:10 | |
| cotto_work | NotFound, looks ok to me on linux/x86 | 17:11 | |
| of course, the arch shouldn't make much difference for something like that | 17:12 | ||
|
17:13
cjfields_ joined
|
|||
| moritz | should Configure.pl print the revision number? | 17:13 | |
| cotto_work | it should be part of Configure.pl's output | 17:14 | |
| dalek | r29491 | coke++ | trunk: | ||
| : [tcl] Remove some useless global lookups (these are now done in the TGE | |||
| : step and are, as far as I can tell, not needed here. All tests pass. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29491 | |||
| NotFound | moritz: It already printed it, I don't touch that part. | ||
| moritz | ah yes | ||
| grep++ ;-) | |||
| NotFound | In any case, it must not print a wrong one. | ||
| DietCoke | cotto_work: it might if he's somehow using the svn binary where we don't have one. | 17:15 | |
| (no clue if he is, though.) | |||
| NotFound | If svn is not used, the package must include a .parrot_current_rev file. | 17:18 | |
|
17:21
Theory joined
|
|||
| DietCoke | if it's a package, it should be a release #, not a rev number we're using to track things. | 17:21 | |
| NotFound | A snapshot package, I mean. | ||
| DietCoke | (unless someone is constructing packages based on svn revision, which would be... odd. | ||
| what is "a snapshot package" ? | 17:22 | ||
| NotFound | A daily snapshot of the repo. | ||
| Infinoid | svn.perl.org/snapshots/parrot/ | ||
| DietCoke | We can probably have robert include that, sure. | 17:23 | |
| moritz | barney: I've seen no announcement on perlmonks.org - are you going to do that also? | 17:27 | |
| NotFound | tjh++ | 17:28 | |
| dalek | r29492 | bernhard++ | remove_getfd: | 17:29 | |
| : [codingstd] Remove hard tab. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29492 | |||
| barney | moritz: I'm not active there, so I skipped that. Please go ahead and announce it there. Same for Reddit, Slashdot ... | 17:30 | |
| moritz | barney: ok, I'll post to perlmonks later | ||
| DietCoke wonders if the .HLL mapping stuff is going to catch anyone's eye. | 17:32 | ||
| barney: wrong branch? | 17:33 | ||
| NotFound | Comments or ideas about pdb renaming? | 17:34 | |
| DietCoke | NotFound: perhaps pbc_debug to stick with our newfound pbc naming scheme. | 17:36 | |
| barney | DietCoke: trunk wasn't up to date | ||
| NotFound | Parrot Byte Code debug? Makes sense. | 17:37 | |
| dalek | r29493 | bernhard++ | trunk: | ||
| : [codingstd] remove hard tab | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29493 | |||
| cotto_work | just out of curiosity, how many people here use awk regularly? | ||
| (N/y) | |||
| NotFound | cotto_work: directly, or by using shell scripts that uses it? | 17:38 | |
| barney | re: pbc_debug Can't we debug PIR as well? | ||
| cotto_work | directly | ||
| NotFound | barney: actually not. | ||
| jhorwitz | DietCoke: what .HLL mapping stuff? | 17:39 | |
| NotFound | But what I mean is that it debugs at bytecode level, so the name makes sense. | ||
| barney | pbc_debug++ | 17:40 | |
| DietCoke | jhorwitz: .HLL_map doesn't seem to work anymore. | 17:43 | |
| jhorwitz | ah | 17:44 | |
| i thought there was progress i didn't hear about... | |||
| but this is anti-progress | |||
| DietCoke | nope. used to work, stopped some thousands of revisions ago. =-) | ||
| I think I'm failing some of the tcl spec tests as a result. | |||
| chromatic: ping | 17:45 | ||
| cjfields_ | I think pmichaud is working on that (.HLL mapping) | ||
| maybe on a branch, but I'm not sure | |||
| DietCoke | he's working on it for -pct- IIRC, not for the .HLL_map directive. | ||
| so PCT can keep track of some of this before things ever get to aprrot. | 17:46 | ||
| DietCoke stares at the mess that parcl is. | |||
| "partcl" | |||
| chromatic | on the phone with Anders Heljsberg | 17:49 | |
| DietCoke | Anders Heljsberg is he lead architect of C# | 17:52 | |
| no, Anders Heljsberg is the lead architect of C# | |||
| purl | okay, DietCoke. | ||
| particle | all we need... c# on parrot. | ||
|
17:55
Zaba joined
|
|||
| NotFound | monoparrot X-) | 17:59 | |
|
18:00
donaldh joined
|
|||
| chromatic | I wouldn't worry about that just yet. | 18:02 | |
|
18:03
Zaba_ joined
|
|||
| DietCoke | I would be happy with anything on parrot at this point. ^_- | 18:04 | |
| chromatic | pancakes? | 18:05 | |
| purl | i guess pancakes is "Don't! take pancakes off my plate and ruin my day." | ||
| DietCoke feels like crap and ponders just going home now. | 18:06 | ||
| moritz | I'll not be available for #parrotsketch tonight | ||
| NotFound | tools/dev/mk_language_shell.pl anything | ||
| That makes you happy? | |||
| DietCoke presumes NotFound is joking. | |||
| particle | moritz: feel free to pre-paste your report | ||
| Tene | Looks like I might not be here for #ps | 18:07 | |
| NotFound | DietCoke: Trying, at least | ||
| pmichaud | I've been working on getting PCT to understand HLL namespaces in preparation for using .HLL and .HLL_map, but I'm not using .HLL_map yet. | 18:10 | |
| (not even in the branch) | |||
| but I'm hoping we can start using it soon. | |||
| thus it better work :-) | 18:11 | ||
|
18:12
wknight8111 joined
|
|||
| DietCoke | pmichaud: pretty sure it's ingored completely these days. | 18:12 | |
| "ignored" | |||
| but I'll be happy to find myself proven wrong. =-) | |||
| NotFound | Did we have some test for it? | 18:13 | |
| chromatic | I remember unbreaking it at least once. | 18:14 | |
| DietCoke | Well, part of the problem is that there's no defined set of what it's supposed to do. (ticket open for that) | ||
| so you may have fixed part of it, but not the part I cared about. | |||
| NotFound | t/library/hllmacros.t ? | ||
| DietCoke | ... that's something else entirely. | ||
|
18:15
Zaba joined
|
|||
| DietCoke | (which I did add tests for, after it lay broken for years. =-) | 18:15 | |
| chromatic | Yeah, it's difficult to unbreak things without tests. | 18:16 | |
| DietCoke | it's hard to write tests without a spec. =-) | 18:17 | |
| (yes, yes, I could just go write the spec. sometimes I like just being the crotchety HLL programmer.) | |||
| chromatic: see tcl's runtime/builtin/list.pir for an example of a HLL_map workaround. | 18:18 | ||
| (at one point, :slurpy gave me a TclList instead of a ResizablePMCArray) | |||
| NotFound | chromatic: did you look at the last messages about RT#39669? | ||
| DietCoke | (trying without it now) | 18:20 | |
| wknight8111 | (unbreaking things)++ | 18:22 | |
| DietCoke | nope, still borked. | ||
| chromatic | NotFound, I think RT #39669 is okay now. | 18:23 | |
| Let me review the tests, but I think you're right. | |||
| NotFound | (closing old tickets)++ | ||
| DietCoke | chromatic: I'll see about adding a test for the particular HLL_map feature that's borked there. | 18:24 | |
| chromatic | NotFound, close it. | ||
| DietCoke, thanks. | |||
| NotFound | Good. | ||
| wknight8111 | "nope, still borked" is like the catch phrase for my entire project | 18:27 | |
| chromatic | #ps in 3 | 18:28 | |
|
18:31
Zaba joined
|
|||
| chromatic | japhb: the register alligator improvements are that it wastes less memory and has a smaller t in its awful O(t * n^8) behavior. | 18:48 | |
| japhb | n^8 ?!? | 18:49 | |
| Holy cow | |||
| purl | Holy cow is here's the play at the plate... holy cow, I think he's gonna make it! | ||
| japhb | I honestly don't think I've ever seen an algorithm between n^5 and 2^n before | 18:50 | |
| I heard about an n^7 once ... | |||
| chromatic | 8 could be an estimate. | 18:51 | |
| t is at least 8 | |||
| n^4 is more likely though. | |||
| japhb | sigh, afk again ... I'll have to ask more about it later, I guess. | 18:52 | |
| chromatic | If you're motivated, you could own it. | ||
|
18:53
wknight8111_ joined
18:56
DietCoke left
19:19
Zaba_ joined
|
|||
| dalek | r29494 | bernhard++ | trunk: | 19:48 | |
| : [docs] Add escape sequence \\" in double quoted strings. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29494 | |||
|
19:54
Zaba joined
|
|||
| dalek | r29495 | allison++ | trunk: | 19:55 | |
| : [pdd] Clarification on literal strings from #parrotsketch meeting. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29495 | |||
| japhb | chromatic_lunchy: motivated, yes. Have time, not so much (I haven't even had OpenGL hacking time, and that's saying something). Still ... is there already an RT open for it? | 20:23 | |
| (er, it == register allocator algorithmic slowness) | 20:24 | ||
|
20:27
iblechbot joined
20:33
Theory joined
21:03
Sartak joined
|
|||
| dalek | r29496 | julianalbo++ | trunk: | 21:06 | |
| : Rename pdb to parrot_debugger after Reini Urban suggestions and later discussion | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29496 | |||
|
21:07
grim_fandango joined
21:11
chromatic joined
|
|||
| chromatic | japhb, no real ticket anywhere. | 21:11 | |
| I sent a message to the list three weeks ago about it. | |||
| japhb | If you've still got it in your sent mail, just resend it to parrotbug. :-) | ||
| NotFound | I think there is a ticket that mentions that some routines are unable to handle register numbers greater than 255 | 21:12 | |
| Beacuse they use an unsigned char for the number. | |||
| Tene | NotFound: limiting registers to 255 keeps that n^8 in the register allocator low. ;) | 21:16 | |
| dalek | r29497 | Whiteknight++ | gsoc_pdd09: | ||
| : [gsoc_pdd09] update to trunk r29495 | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29497 | |||
|
21:19
Zaba joined
|
|||
| chromatic | The problem with the n^8 is that IMCC uses SymReg everywhere for any kind of symbolic entity in PIR, not just registers -- constants, Subs, everything. | 21:20 | |
| NotFound | Tene: don't know if the limit in the amount of registers is reasonable, but the in his numbers is not. | ||
| chromatic | That means when the alligator wants to look at all registers, it has to loop through all of the SymRegs in the current compilation unit and filter out only register registers. | 21:21 | |
| Oh, and if it wants to look at only P-regs or S-regs, it still has to loop. | |||
| And loop. And loop. And loop. | |||
| leo | another historic design flaw - greetinx all | 21:23 | |
| chromatic | Anyway, my conclusion in that message was that fixing it meant rewriting a lot of IMCC, which may not be worth it. | ||
| Whiteknight | ...and that brings us back to the bigger question: How much work needs to be done to make PIRC take over the job? | 21:25 | |
| chromatic | We need a good way to generate PBC in memory or on disk. | 21:26 | |
| POST -> PBC would be most ideal. | |||
| For various reasons which should be obvious. | |||
| leo | register allocation written in PIR???\\ | 21:28 | |
| NotFound | The pdd about pbc format reflects the current state or the intended changes? | ||
| chromatic | Why not write one in PIR? | ||
| leo | speed? | ||
| purl | speed is, like, too subjective, I think | ||
| leo | HA | ||
| soryy, but the best efforts in C so far are slow | 21:31 | ||
|
21:32
Zaba_ joined
|
|||
| leo | with PIR you take a factor of x200 (average interpreter slowdown for Joe Averages's code) | 21:33 | |
| chromatic | Our best efforts in C are algorithmically awful. | ||
| Even the naive allocator. | |||
|
21:34
cjfields joined
|
|||
| leo | there is only compilers/imcc/reg_alloc.c - where are the others? | 21:36 | |
| chromatic | There are two allocators in there. The interesting one is #defined out. | 21:39 | |
| Whiteknight sees a massive need for function-level documentation in reg_alloc.c | 21:44 | ||
| leo | is still the vanilla_reg_alloc in charge? | 21:47 | |
| chromatic | Yes. | 21:50 | |
|
21:57
toft joined
21:59
toft left
|
|||
| leo | well, if there's a faster C algorithm (which is hard) then you could translate that to PIR ;) | 22:00 | |
| chromatic | It wouldn't surprise me if a better implementation of the same algorithm would be faster. | 22:02 | |
| leo | different algorithm, yes | 22:03 | |
| or moving the inner loops re (I,P,N,S) outside | 22:04 | ||
|
22:04
Zaba joined
|
|||
| Whiteknight | is there a standard error-message function I can call that doesn't require an interp parameter? | 22:07 | |
| i know internal_exception does it, but I thought that function was being phased out | 22:08 | ||
|
22:09
Zaba_ joined
|
|||
| chromatic | You don't have an interpreter? | 22:10 | |
| Whiteknight | in config/platforms/win32/env.c:Parrot_setenv | 22:11 | |
| I'm fixing that function up and want to fill in some of the warnings slots, but no interp argument | |||
| NotFound | internal_exception is intended to just die with a more or less nice message, I think. | 22:12 | |
|
22:14
Zaba joined
|
|||
| Whiteknight | yeah, but I heard that internal_exception was being phased out | 22:20 | |
| maybe i misunderstood that error | 22:21 | ||
| NotFound | By the way, GetEnvironmentVariable is macro that can map to the unicode or ansi version. The current Parrot_getenv interface is not able to handle encoding and charset issues. | 22:22 | |
| Whiteknight: maybe a change in name, but we always need a way to say "Completely unable to keep working in a sane way" | 22:23 | ||
| Whiteknight | I'll use internal_exception now, then. We can ack it later if we want to change it | 22:24 | |
| NotFound | Under the current interface, you can only do that, or just ignore the errors. | 22:28 | |
| chromatic | Whiteknight, it gets renamed in pdd25cx. | ||
| NotFound | Not ignoring we can at least know possible problems. | 22:29 | |
| chromatic | At least, if I'm not confusing internal_exception and real_exception. | ||
|
22:34
teknomunk joined,
Zaba_ joined
22:40
Limbic_Region joined
|
|||
| Whiteknight | anybody want to give a second opinion on rt#56968? I think we can close it pretty quick unless there's a problem | 22:42 | |
| I'm going to need to check out pdd25cx and play around with it i guess | 22:44 | ||
|
22:44
Zaba joined
|
|||
| chromatic | Go ahead and remove it, Whiteknight. | 22:50 | |
| Whiteknight | That's all I needed to hear | 22:51 | |
| I found this while trying to clean out my rt backlog, so I'm not shirking my GC duties | 22:52 | ||
| chromatic | You can clean out my RT backlog too. I don't mind. | 22:54 | |
| I'll probably be useless next week too; Foo Camp + working in the office + OSCON = tired. | |||
| NotFound | It hink that if we want a warning function able to be called without an interpreter if mus be declared in extern.h and follows his guidelines. | 22:55 | |
| s/if mus/it must | |||
| chromatic | How do we know which filehandle to print the warning to without an interpreter? | ||
| NotFound | Just ignore, or write something to stderr. | 22:56 | |
| Whiteknight | I agree. last ditch effort -> spam stderr | ||
| at that point, you have bigger problems to solve then proper logging of your output handle | |||
| NotFound | But while we don't know if we want, do not write it. | 22:57 | |
| The function, not the message ;) | 22:58 | ||
| chromatic | Right. | 23:01 | |
| dalek | r29498 | Whiteknight++ | trunk: | 23:05 | |
| : [core] Remove function Parrot_warn_s, which was unused except in a few tests. Also, remove those tests. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29498 | |||
|
23:08
Psyche^ joined
|
|||
| cotto_work | does taking a ticket mean I *will* fix it, or just that I intend to when I get the tuits? | 23:08 | |
| Whiteknight | I've been interpreting it as the late | 23:10 | |
| later * | |||
| NotFound | cotto_work: I think is just way of saying: if you start to work in this, talk with me first, please. | ||
| Whiteknight | or "I'm going to lead the way" | 23:11 | |
| NotFound | At least it is how must be seen, whatever the intention of the owner. | 23:12 | |
|
23:13
kid51 joined
|
|||
| NotFound | The intention, looks like is almost always the second. | 23:13 | |
| When I take the pdb rename some hours ago, it was the first ;) | 23:14 | ||
|
23:21
Zaba_ joined
23:29
ruoso joined
|
|||
| kid51 | purl is apparently no longer handling private messages | 23:37 | |
| Whiteknight | purl is lazy | 23:40 | |
| purl? | 23:41 | ||
| purl | yes, Whiteknight? | ||
| kid51 | purl, why did you tell me: "Sorry, I've never seen particle before."? | 23:43 | |
| purl | kid51: bugger all, i dunno | ||
|
23:46
teknomunk_ joined
|
|||
| dalek | r29499 | jkeenan++ | trunk: | 23:48 | |
| : Merge noautopack branch into trunk per rt.perl.org/rt3/Ticket/Display.html?id=56928. This deletes configuration step auto::pack and an associated test file. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29499 | |||
| r29500 | jkeenan++ | noautopack: | |||
| : Branch has been merged into trunk and is no longer needed at head. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29500 | |||
| r29501 | jkeenan++ | noautopack-29452: | 23:49 | ||
| : Branch to which tag corresponded has been merged into trunk, so tag may be | |||
| : deleted. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29501 | |||
|
23:52
bacek_ joined
|
|||
| dalek | r29502 | jkeenan++ | parallel: | 23:59 | |
| : Correct two errors: "my" variable ... masks earlier declaration in same scope. | |||
| diff: www.parrotvm.org/svn/parrot/revision?rev=29502 | |||