|
Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | merge html_cleanup (talk to Coke), merge gc_* branches, fix/replace/optimize hashing Set by moderator on 10 August 2010. |
|||
|
00:00
Psyche^ joined
|
|||
| dalek | kudo: 73a7674 | masak++ | : <pre>m src/core/Buf.pm <pre style='white-space:pre-wrap;width:81ex'>[Buf] added prefix/infix ~^, infix ~& and infix ~|</pre> |
00:00 | |
| darbelo | chromatic: Looks good to me. For after the release anyway. | 00:02 | |
| chromatic | Right. Want to try that experimental opcode in a branch? | ||
| darbelo | Sure. I still have some tweaks to unshared_buffers to make. | 00:03 | |
| So, prbably tomorrow-ish | |||
| chromatic | Sounds good. | 00:04 | |
| darbelo | Although anything that makes the rakudo build's memory usage less pathological will likely benefit that as well. | 00:05 | |
| chromatic | True. I'm still of mixed feelings about getting rid of shared buffers. | 00:06 | |
| dalek | kudo: bef86ee | masak++ | : <pre>m t/spectest.data <pre style='white-space:pre-wrap;width:81ex'>[t/spectest.data] added S03-operators/buf.t</pre> |
||
| darbelo | I'm experimenting with the tuning, right now. If I make compacting more aggressive I can build rakudo under 300mb of mem, but it'll take about hour. | 00:08 | |
| chromatic | How fast is your machine? | 00:10 | |
| darbelo | At the branch point, it builds in ~8 minutes, for comparison. | 00:11 | |
| chromatic | Ouch. | ||
| jnthn | I'll take the extra memory usage over an hour long build. :-) | 00:12 | |
| darbelo | Yeah. Me too. | ||
| chromatic | If that opcode works though.... | ||
| jnthn | Yes, that should result in a load less string headers. | 00:13 | |
| darbelo | jnthn: OTOH, kid51 can't build at all without some memory usage reductions, which is what made start experimenting along this line. | ||
|
00:27
jsut joined
00:46
gbacon joined
|
|||
| dalek | rrot: r48518 | darbelo++ | branches/unshared_buffers (67 files): Sync with trunk. |
00:52 | |
|
01:13
theory joined
01:34
chromatic joined
01:35
Andy joined
01:46
kid51 joined
|
|||
| dalek | rrot: r48519 | chromatic++ | branches/substr_eq_at: Created branch to experiment with substr_eq_at opcode |
01:58 | |
|
02:05
tcurtis joined
02:10
Chandon joined
02:12
jimk joined
02:24
mj41 joined
|
|||
| dalek | rrot: r48520 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c: Typo fix. |
02:31 | |
| purl | hmmm... typo fix is in documentation (perlapi), not a comment | ||
| luben | good morning parrot | 02:40 | |
| Andy | proof please? gist.github.com/526305 | 02:45 | |
|
02:48
janus joined
|
|||
| Andy | Any comments? | 02:50 | |
| purl | Any comments is appriciated =) or punt! | ||
| dafrito is reading :) | 02:51 | ||
| Andy | kthx | ||
| tcurtis | Looks good. No grammar- or typos that I notice. | 02:52 | |
| dafrito | Yeah, I don't see anything glaring | 02:54 | |
| Perhaps this could read better? "if Perl 6 programmers wanted vim to support Perl 6, they had a perl6.vim file that got passed around" | |||
| Andy | Reload, I updated that. | ||
| I just edited the file | 02:55 | ||
| tcurtis | wait... Perl has a "static" keyword now? | 02:56 | |
| dafrito | "because of updates of all the Perl-related support files" Should one of those 'of' be 'for'? | ||
| Andy | eek, state | 02:57 | |
| STATE | |||
| thanks. | |||
| TiMBuS | i would like vim to detect filetype based on mimeinfo =/ | 02:59 | |
| all my perl 6 files are application/perl6 | |||
| sorear | What OS are you on? | ||
| dafrito | Andy: You could also put a link for "Template Toolkit" if you want | ||
| TiMBuS | ubuntu linux | ||
| Andy | TiMBuS: How are you storing mimeinfo? | ||
| perlbuzz.com/2010/08/vim-73-supports-perl-6.html published | 03:00 | ||
| thanks | |||
| TiMBuS | er, im not sure of the specifics Andy. I used associgate to add the magic (in the past I modified a mime.magic file but i cant recall where it was stored...) | 03:03 | |
| sorear | you mean /etc/magic.mime? | 03:11 | |
| TiMBuS | nah, looks like it was /usr/share/mime | 03:12 | |
| and associgate adds to /usr/local/share/mime | |||
|
03:17
atrodo joined
|
|||
| dalek | rrot: r48521 | chromatic++ | branches/substr_eq_at (7 files): [str] Added API to find substring in string. may help PCT require far fewer new STRING headers. |
04:26 | |
| rrot: r48522 | chromatic++ | branches/substr_eq_at (5 files): [ops] Added substr_eq_at ISSI op for PCT. |
|||
| cotto | msg khairul minor typo in the op instrumentation page: "If $get_raw is pass and is true" | 04:55 | |
| purl | Message for khairul stored. | ||
| dukeleto | cotto: pong | 04:58 | |
| cotto | dukeleto, Does it matter if a student keeps working on a project after the pencils down date? | 05:00 | |
| i.e. would that just mean that all evaluation doesn't take the extra work into consideration? | 05:01 | ||
| chromatic | Know any so-called professional programmers who always make their estimates? me neither. | 05:02 | |
| cotto is surprised he was able to remember his question. | |||
| dukeleto | cotto: yes, that is fine | 05:13 | |
| cotto | msg khairul The class instrumentation page should probably explain what a call sig is and where to find out more about it. | ||
| purl | Message for khairul stored. | ||
| cotto | dukeleto, great. Thanks. | ||
| dukeleto | cotto: the final evalution should only take into account stuff done before the pencils down. We should encourage all students to keep working well after that :) | 05:14 | |
| cotto | It'll only really matter for the survey anyway. There's very little my student could do at this point to avoid passing. | 05:15 | |
| dukeleto | cotto: sounds good | 05:17 | |
| cotto | msg khairul Other than those suggestions, the docs are looking good. When you put your code on github, make sure the use guide goes with it. | 05:23 | |
| purl | Message for khairul stored. | ||
|
05:27
jsut_ joined
06:05
uniejo joined
06:34
preflex joined
07:43
fperrad joined
|
|||
| luben | chromatic, ping | 08:18 | |
| chromatic | pong | 08:19 | |
| luben | I have made experiments with hashes | ||
| added paged allocation for buckets | |||
| it is slower here | |||
| here is it: luben.spnet.net/gitweb/ | 08:20 | ||
| chromatic | I think we should address the indirection of our hashing functions before we make progress on optimizing our hashes. | ||
| luben | the paged allocation branch is "single-paged" | 08:21 | |
| chromatic | Instead of function pointers for key/value hashing, set the type of a hash for the most common types and hard-code the comparison/hashing functions. | ||
| luben | yes, this will give us better performace | 08:22 | |
| chromatic | There's too much overhead there so it dwarfs any improvements we make in allocation/reallocation/bucket distribution. | ||
| luben | in the benchmaks for hashes, the ones that use C macros or C++ templates are fastest (they do not use any indirection) | 08:23 | |
| chromatic | This is one place where I wish we could use C++. | ||
| luben | yes | 08:24 | |
| I will be offline for 2 weeks - going on vacation. When I come back I will continue | |||
| chromatic | Excellent, this would be good for 2.8. | 08:25 | |
| luben | yes | ||
| moritz | luben++ | ||
| luben | from my branches "hash-iter-macros" is ready/tested | ||
| chromatic | I'll apply it as soon as 2.7 comes out. | ||
| luben | If somebody could clone it, because in 7-8 hours I will whitch off the PC here | 08:26 | |
| Or I could atach a patch to the ticet | 08:27 | ||
| *ticket | |||
| chromatic | A patch is the easiest. | ||
| must sleep now | 08:28 | ||
| thanks for your work | |||
|
08:48
AndyA joined
09:43
gbacon joined
10:10
JimmyZ joined
10:45
aloha joined
10:56
lucian joined
11:42
NotFound joined
|
|||
| NotFound | Hi | 11:43 | |
|
11:54
ruoso joined
|
|||
| jnthn | I'm told Rakudo's core.pm compilation is nomming lots and lots of RAM again. Wonder if recent tuning has notched things a little too far along the RAM/CPU trade-off scale. | 12:08 | |
|
12:10
whiteknight joined
|
|||
| whiteknight | good morning, #parrot | 12:18 | |
| szabgab | if I am not mistaken parrot also uses the public smolder server | ||
| if so, anyone knows what happened to it? | |||
| smolder.plusthree.com/ does not seem to respond | |||
| NotFound | whiteknight: pon | 12:25 | |
| g | |||
|
12:29
elmex_ joined
13:11
allison joined
13:19
gbacon joined
13:27
Paul_the_Greek joined
|
|||
| Paul_the_Greek | Hey ho! | 13:27 | |
| purl,messages | 13:28 | ||
| ping cotto | 13:29 | ||
| dalek | rrot: r48523 | coke++ | branches/substr_eq_at/src/ops/experimental.ops: Add a pod description for this opcode. |
13:32 | |
| whiteknight | NotFound: how do I load a library in winxed? I can't find an example | 13:34 | |
|
13:39
Paul_the_Greek joined
|
|||
| Paul_the_Greek | ping anyone | 13:39 | |
| whiteknight | ? | 13:40 | |
| Paul_the_Greek | Just checcking to see if I'm really connected. | ||
| whiteknight | signs point to yes | 13:41 | |
| Paul_the_Greek | Downloaded XChat onto my wife's laptop. Flakey wifi connection here. | ||
| whiteknight: Do you know why PMC attribute groups are allocated separately from other fixed-size blocks? | 13:42 | ||
| whiteknight | how differently? I thought they used the fixed-size allocator? | 13:43 | |
|
13:54
Paul_the_Greek joined
|
|||
| Paul_the_Greek | whiteknight: Are you still here? | 13:54 | |
| ping cotto | 13:56 | ||
| ping anyone | 14:01 | ||
| moritz | pong | ||
| Paul_the_Greek | Hey moritz. Just trying to get this chat program to work. Got a flakey wifi connection. | ||
|
14:03
bubaflub joined
|
|||
| Paul_the_Greek | Hey bubaflub. | 14:04 | |
| purl | bubaflub is Bob Kuo, mailto:bobjkuo@gmail.com | ||
| bubaflub | hello Paul_the_Greek | ||
| moritz | purl is very noisy | ||
| Paul_the_Greek | Yes, he is chatty. | 14:05 | |
| Memory management question, anyone? | 14:08 | ||
| moritz | we need to improve it! | 14:09 | |
| that's how much I know about it :) | |||
| Paul_the_Greek | I think I can speed up PMC attribute allocation. | ||
| Logging off and back on ... | 14:12 | ||
|
14:13
Paul_the_Greek joined
|
|||
| Paul_the_Greek | Cool! | 14:13 | |
| moritz | Paul_the_Greek: btw you can also use the IRC logs at irclog.perlgeek.de/parrot/today for reading here if your connection is not stable | ||
| Paul_the_Greek | I'll do that. I just don't want to pop off in the middle of conversations and annoy everyone. | 14:14 | |
| Be back later. | 14:16 | ||
| dalek | kudo: 2f18a49 | pmichaud++ | : <pre>m src/Perl6/Grammar.pm <pre style='white-space:pre-wrap;width:81ex'>Fix precedence of numeric bitshift operators; fixes RT #77232 (masak++).</pre> |
14:29 | |
|
14:45
Andy joined
15:12
chromatic joined
|
|||
| pmichaud | chromatic: just sent email about substr_eq_at | 15:17 | |
| chromatic | I'm reading it and trying to understand it before breakfast. | 15:19 | |
| The "before breakfast" part may be a mistake. | |||
| pmichaud | if I can help demystify it, let me know. :) | 15:28 | |
| the key is that it's more like C's strncmp than anything else. | 15:30 | ||
| i.e., only compare up to n characters | |||
| where 'n' is implied by the length of the token string argument (i.e., the one we're searching for) | |||
| chromatic | What you want or what it's doing? | ||
| pmichaud | what I want | 15:31 | |
| what it's doing seems to be more like strcmp with an offset | |||
| chromatic | Right. | 15:32 | |
| pmichaud | perhaps a better way of phrasing what I want is: strncmp with an offset | ||
| in C, it'd be strncmp(s1 + offset, s2, strlen(s2)) | 15:33 | ||
| and then for equality I'd look for zero as the return value | 15:34 | ||
| if we want the number of characters to be compared to be explicit in the opcode, that'd be fine with me also | |||
| i.e., it could be | 15:35 | ||
|
15:35
Paul_the_Greek joined
|
|||
| pmichaud | $I0 = strncmp $S0, $S1, offset, length | 15:35 | |
| chromatic | That's what the code does... supposedly. | ||
| pmichaud | I don't think it honors length | ||
| chromatic | ascii_compare does when the encodings are the same, as they are here. | 15:36 | |
| Paul_the_Greek | Memory management question? | ||
| chromatic | go ahead, Paul_the_Greek. | ||
| Paul_the_Greek | Why is there one set of fixed-size pools for PMC attributes and another set for everything else? | 15:37 | |
| Is it just for efficiency? | |||
| chromatic | Good question. That might have been the desire. | ||
| pmichaud | in the branch, I'm getting | ||
| $I0 = substr_eq_at "hello", "he", 0 | |||
| say $I0 | |||
| 1 | |||
| if substr_eq_at is returning cmp semantics, that should be zero. | 15:38 | ||
| Paul_the_Greek | I think I might be able to speed up allocating PMC attributes. | ||
| pmichaud | I *think* what it's doing is looking at the 'l' following the "he" and saying "oh, the first string is greater" and thus returning 1. | 15:39 | |
| i.e., it's not stopping the comparison after the first two chars. | |||
| chromatic | The return value processing is wrong. | ||
| Paul_the_Greek | If it returns -1/0/1, why is it called 'substr_eq'? | 15:40 | |
| pmichaud | Paul_the_Greek: noted, it should be 'cmp' | ||
| chromatic | That... is a different problem. | ||
| I believe I've fixed the return value; I'm running the tests to make sure. | 15:41 | ||
| pmichaud | chromatic: can you nopaste the diff? | ||
| nopaste | "chromatic" at 192.168.1.3 pasted "pmichaud: the patch" (14 lines) at nopaste.snit.ch/22830 | 15:42 | |
| chromatic | It's not completely right, but it passes your test cases. | ||
| pmichaud | looking | 15:43 | |
| Paul_the_Greek | Why the compare ret_val < 0? | 15:44 | |
| pmichaud | I have the same question | 15:45 | |
| seems like one can more usefully do | |||
| Paul_the_Greek | Does memcmp return something other than -1? | ||
| pmichaud | return memcmp(lhs->strstart + offset, rhs->strstart, rhs->strlen) | ||
| Paul_the_Greek | Yeah. | ||
| chromatic | It was the cheapest, easiest patch. | 15:46 | |
| Paul_the_Greek | Why not just 'return retval;' ? | 15:47 | |
| pmichaud | Paul_the_Greek: because min_len will be wrong in that case | ||
| chromatic | I was too lazy to type man memcmp. | ||
| pmichaud | there are a few edge cases that this code doesn't quite handle | 15:48 | |
| chromatic | Right. | ||
| Paul_the_Greek | But if the only negative value of retval is -1, then the comparison is pointless. | ||
| pmichaud | oh oh oh oh | 15:49 | |
| Paul_the_Greek | Maybe I don't have memcmp correct in my mind. | ||
| pmichaud | this whole approach isn't going to quite work | ||
| chromatic | Right. | ||
| pmichaud | the ascii_compare function itself doesn't have a usable 'n' limit | ||
| chromatic | I'm not sure it needs one. | ||
| I've been using the size of the smaller string. | 15:50 | ||
| pmichaud | that doesn't quite work | ||
| because $I0 = substr_eq_at 'ab', 'abc', 0 | |||
| shouldn't show them as being equal | |||
|
15:50
tcurtis joined
|
|||
| pmichaud | while | 15:50 | |
| $I0 = substr_eq_at 'abc', 'ab', 0 | |||
| should | |||
| be "equal" | 15:51 | ||
| chromatic | Ah, right. | ||
| Reusing ascii_compare isn't going to work so well here. | |||
| pmichaud | right | ||
| there really needs to be a strncmp equivalent | 15:52 | ||
| chromatic | pmichaud, if you commit these test cases (and the interface you prefer for this), I'll make them pass. | ||
| Paul_the_Greek | Is that how the regular compare works? | ||
| pmichaud | chromatic: would an opcode name of "strncmp_at" seem to be appropriate? | ||
| chromatic | Fine with me, if it works for PCT. | 15:53 | |
| Paul_the_Greek | Once you delimiter the substring, then the compare should work the same. | ||
| moritz | why the 'n' ? | ||
| pmichaud | moritz: because I need to limit the length of the comparison | ||
| look, here's the use case | |||
| moritz | pmichaud: ok, I thought the limit was implicit | ||
| pmichaud | src = "given xyz { when 1 { ... } }" | ||
| moritz | I know the use case, yes | 15:54 | |
| pmichaud | moritz: oh. I'm thinking maybe it's more general to have the caller supply 'n' instead of it being inferred | ||
| moritz | wfm | ||
| Paul_the_Greek | Optional n, as in substr, right? | ||
| pmichaud | for the case of comparing against a constant string, the length is statically known at compiletime | ||
| i.e., instead of | |||
| $I0 = strncmp_at $S0, $S1, offset # length is implied as length($S1) | 15:55 | ||
| I think | |||
| $I0 = strncmp_at $S0, "when", offset, 4 # length is explicit | |||
| Paul_the_Greek | Are you using a substring of $1 or $2? | ||
| pmichaud | $1 | 15:56 | |
| Paul_the_Greek | Then shouldn't the offset and length apply to $1? | ||
| pmichaud | Paul_the_Greek: yes | ||
| (although the length should probably apply to both) | |||
| Paul_the_Greek: if you're suggesting a different order of arguments, I'd be agreeable | |||
| Paul_the_Greek | So if the length is missing, it's the tail of $1 starting at offset. | ||
| pmichaud | no | ||
| essentially I need an opcode that does the same as the following in C: | 15:57 | ||
| i = strncmp(s1 + offset, s2, n) | |||
| Paul_the_Greek | Okay, so it's not a substring of $1, just a tail of $1. | ||
| pmichaud | one can look at it that way, yes | ||
| one can also look at it as being a substring of n characters of $1 and end up with the same results | 15:58 | ||
| Paul_the_Greek | You're sure you don't want strcmp(substr($1, offset, n), $2) ? | ||
| pmichaud | we're just trying to avoid creating the separate substring | ||
| strcmp(substr($1, offset, n), $2) is what we do now. | |||
| Paul_the_Greek | Not if *$1 < n | ||
| Sorry, *$2 < n | |||
| Oh, this is in addition to that. Got it. | 15:59 | ||
| pmichaud | right | ||
| currently to do a token comparison, we generate | |||
| $S1 = substr src, offset, n | |||
| $I0 = iseq $S1, "when" | |||
| NotFound | whiteknight: the load_bytecode and loadlib predefined functions of winxed are equivallente of the opcodes with the same name. | 16:00 | |
| pmichaud | but the problem with that approach is that we end up creating a new substring for every token comparison | ||
| actually, I'll be a bit more precise | |||
| currently we generate | |||
| $S1 = substr src, offset, 4 | |||
| Paul_the_Greek | So what is wrong with the existing op code? | ||
| pmichaud | $I0 = iseq $S1, "when" | 16:01 | |
| Paul_the_Greek | This one: strcmp(substr($1, offset, n), $2) is what we do now. | ||
| pmichaud | that's not an opcode. | ||
| that's the equivalent C semantic | |||
| Paul_the_Greek | Sorry, now I understand. | ||
| pmichaud | the opcodes are what I just wrote -- substr followed by iseq | ||
| Paul_the_Greek | Why not make the new opcode do that? | 16:02 | |
| pmichaud | Paul_the_Greek: that's what we're doing | ||
| I'm proposing instead: | |||
| $I0 = strncmp_at src, "when", offset, 4 | |||
| with the difference that $I0 returns -1/0/+1 instead of just 0/1 | 16:03 | ||
| Paul_the_Greek | We're going in circles. Does $4 specify the length of the substring of src, or the length of the comparison? | ||
| pmichaud | in this case I'd let $4 be the length of the comparison. (more) | ||
| chromatic | The length of the comparison, because the op knows the lengths of both strings. | 16:04 | |
| pmichaud | for my use cases, it doesn't matter though, since $4 would always be the known length of $2 | ||
| but for a more general-purpose operator, having it follow strncmp semantics ('n' is the length of the comparison) seems more useful. | |||
| Paul_the_Greek | But might it be more generally useful if $4 was the length of the substring? | ||
| pmichaud | Paul_the_Greek: I doubt it. | 16:05 | |
| and I'm not sure what "length of the substring" means here. | |||
| Paul_the_Greek | If the tail of $1 is shorter than $4, then $4 cannot be used as the comparison length. | ||
| pmichaud | why not? | ||
| strncmp does it | |||
| in that case, assuming the prefixes are equal, we'd get back -1 | |||
| because the lhs is less than the rhs | |||
| Paul_the_Greek | Because then you would compare more characters than are in the tail of $4. | ||
| pmichaud | you stop comparing if $1 is shorter. | 16:06 | |
| Paul_the_Greek | Right, so $4 is not necessarily the comparison length. But if that's the semantics of strncmp, then I'm raising a red herring. | ||
| pmichaud | basically $4 says "compare at most n characters" | 16:07 | |
| if either of the source strings doesn't have enough, then that stops the comparision | |||
| Paul_the_Greek | Limited by the length of both strings, I presume. Sorry for belaboring this. | ||
| pmichaud | chromatic: since Parrot already has cmp_str, perhaps this should be cmp_str_at ? | 16:08 | |
| chromatic | Makes sense. | ||
| pmichaud | oh, but it wants an 'n' in there somewhere. | ||
| cmp_str_n_at ? cmp_str_at_n ? | 16:09 | ||
| I guess the latter -- and the underscores hint at the arguments. | |||
| Paul_the_Greek | ncmp_str_at ? | ||
| chromatic | I don't know if we need the n; for PCT's purposes, it's superfluous, right? | ||
|
16:09
allison joined,
bacek joined
|
|||
| pmichaud | yeah, PCT doesn't really care. I'll go with cmp_str_at, and we'll just know that the 'n' argument is required for now. | 16:10 | |
| Paul_the_Greek | pmichaud: Thanks for putting up with my questions. | ||
| pmichaud | or perhaps it should be cmp_substr_at | ||
|
16:10
aloha joined
|
|||
| pmichaud | Paul_the_Greek: thanks for helping us clarify exactly what we want/is meant | 16:10 | |
| chromatic | Does that help write test cases? | 16:11 | |
| pmichaud | yes | ||
| I'm writing test cases now. | |||
| will commit shortly, then have to run an errand. | |||
| szabgab | hi, can someone help me understanding the status of languages on Parrot? | 16:12 | |
| I looked at the link bitbucket.org/allison/pynie/ and Pynie seems to be stuck 5 month ago | |||
| allison | szabgab: yes, I'm the only Pynie developer, and yes, I haven't had time to work on it lately | 16:13 | |
| szabgab | hi allison | ||
| allison | szabgab: it's current status is "starting over from scratch" | ||
| moritz | the curse of being involved in too many projects/activities, I guess | ||
| allison | szabgab: because it depends on the old NQP | ||
| Paul_the_Greek | Pynie is? | 16:14 | |
| moritz | huh? most things can be quite easily adopted | ||
| allison | Python on Parrot | ||
| moritz | to nqp-rx | ||
| szabgab | so does that mean the Python community has no much interest / tuits to give a hand? | ||
| (we could send them a box of tuits :) | |||
| Paul_the_Greek | You can buy those? | ||
| allison | moritz: except that Pynie was a) not a great implementation to start with and b) originally an implementation of 2.5, not 3.x | ||
| kthakore | szabgab: how do you buy those? | ||
| Paul_the_Greek: gosh you beat me | 16:15 | ||
| :p | |||
| allison | szabgab: the Python community is very interested in it, but not in contributing to it | ||
| szabgab | Paul_the_Greek: kthakore you have to come to a YAPC to get them :) | ||
| allison | szabgab: my current thought is to redo Pynie as a Parrot backend for PyPy | ||
| szabgab | allison: thanks, is there any other language (except Perl 6) that is being actively developed for Parrot? | 16:16 | |
| allison | szabgab: kill two birds with one stone in getting a parser for Python, and getting an active Python community for the implementation | ||
|
16:16
ruoso joined
|
|||
| szabgab | Cardinal last changed in May | 16:17 | |
| Paul_the_Greek | I presume the compiler tools can deal with a whitespace language? | ||
| szabgab | maybe implement Python as a Perl 6 regex? | ||
| allison | szabgab: that depends on whether "active" means "activity equal to Perl 6" and whether "language" means only major languages | ||
| pmichaud | (whitespace language) actually, that ended up being far simpler than I had expected | ||
| Paul_the_Greek | I'm amazed. | ||
| pmichaud | it fell almost directly out of the python (2.5) specification | ||
|
16:18
davidfetter joined
|
|||
| szabgab | allison: I don't have hard definition for active and it does not have to be major | 16:18 | |
| arnsholt | szabgab: I'm working on a Prolog, but it's slow going since I have to do other stuff (like working on my degree =) as well | ||
| allison | szabgab: then yes, there are lots of active languages on Parrot | ||
| Paul_the_Greek | Speaking of languages, but not HLLs, what is the long-term plan for the PIR assembler? | 16:19 | |
| szabgab | I am interviewing in Hungarian (!) about Perl 6 and they also asked about Parrot | ||
| Paul_the_Greek | Cool. | ||
| kthakore | szabgab: I will get there soon ish | 16:20 | |
| szabgab | so I am trying to figure out what to say | ||
| kthakore | szabgab: next summer I will definately plan for it | ||
| ok work | |||
| szabgab | arnsholt: prolog is not listed on www.parrot.org/languages ? | 16:21 | |
|
16:21
theory joined
|
|||
| arnsholt | No, it's relatively recent (I started in May or so) | 16:22 | |
| So I just haven't gotten around to adding it to the page | |||
| Also, it's currently somewhat useless as I'm still working on figuring out how do the implementation (also figuring out the semantics of Prolog beyond what I need to write Prolog programs) | 16:23 | ||
| szabgab | kthakore: here isa temporary round tuit: Ź | 16:24 | |
| Paul_the_Greek | That came out as a square tuit on my display. | ||
| moritz thinks that prolog compiler writing is less obvious than for procedural languages | |||
| arnsholt | Yeah, Prolog has its quirks | 16:25 | |
| szabgab | Paul_the_Greek: something about square pegs and round holes? | 16:26 | |
| arnsholt | Thankfully I have a good guide to getting backtracking and such working in a CPS style from a book by Paul Graham (On Lisp) though | ||
| Currently I'm fighting a bit with Parrot's continuations though | |||
| moritz | I guess they fight back :-) | 16:27 | |
| Paul_the_Greek | Once I learn more about Parrot, I might consider implementing my language on it. That would be fun. | 16:28 | |
| arnsholt | Indeed they do. I have an idea how I might be able to fix it though | ||
| Just need the time to do it | |||
| Paul_the_Greek: I have several ideas of languages Parrot needs =) | |||
| Paul_the_Greek | I use my own personal language for writing everything for my work. The rest of the world doesn't need it. :D | 16:29 | |
| szabgab | Paul_the_Greek: your langauge? you mean Greek ? | ||
| Would be nice to have a spoken language implemnetd on Parrot :) | 16:30 | ||
| Paul_the_Greek | Greek is good, but not for programming. | ||
| moritz | hey, in Greek you can use lambda calculus, beta reductions, ... :-) | 16:31 | |
| pmichaud | chromatic: tests committed as t/op/substr_cmp.t in r48524 | 16:32 | |
| Paul_the_Greek | The language would have lots of epsilons, too. | ||
| szabgab | I see pmichaud is trying to fight our noise :) | 16:33 | |
| chromatic | Thanks, will have them passing later today. | ||
| pmichaud | chromatic: excellent. I can then quickly test them on nqp and come up with a rough estimate of performance change (if any) | ||
| davidfetter | szabgab, just the person i'm looking for! :) | 16:34 | |
| got a minute re: CPAN & SuSE? | |||
| Paul_the_Greek | pmichaud: Do we have performance tests for various aspects of Parrot? | 16:35 | |
| pmichaud | Paul_the_Greek: nafaik | ||
| particle | like, benchmarks? | ||
| Paul_the_Greek | Er, right, the word would be benchmark. | ||
| dalek | rrot: r48524 | pmichaud++ | branches/substr_eq_at/t/op/substr_cmp.t: [substr_cmp]: Add tests for proposed/experimental cmp_str_at opcode. |
||
| particle | alioth, the debian language shootout | ||
| Paul_the_Greek | Looking up ... | 16:36 | |
| particle | i wonder if someone would write nqp versions of those benchmarks, if that would help | ||
| chromatic | I still think we need NQP and parsing specific benchmarks. | ||
| Paul_the_Greek | Do we have a start-up benchmark? | 16:37 | |
| particle | we have a 'time to compile rakudo' benchmark | ||
| Paul_the_Greek | Oh, that's good. | 16:38 | |
| If I try to improve PMC attribute allocation, I'll need a benchmark. | |||
| pmichaud | question: Even with the proposed cmp_str_at opcode, I can also get NQP to optimize single-character comparisons to use the 'ord' opcode. Would 'ord' still be significantly better than cmp_str_at to warrant that optimization? | ||
| chromatic | darbelo might be able to answer that question. | 16:39 | |
| Paul_the_Greek, see examples/benchmarks/*pir | |||
| I like oofib.pir. | |||
| pmichaud | I'm guessing "likely yes" | ||
| after lunch I think I'll go ahead and put that optimization into nqp and see if it's a significant win | |||
| after looking at the generated code for rakudo's parser, I'm thinking it could be very significant | 16:40 | ||
| Paul_the_Greek | Is the ord index known to be valid? | ||
| Thanks, chromatic. | |||
| pmichaud | there are a lot of generated 1-character constant string comparisons | ||
| afk, lunch | 16:41 | ||
| Paul_the_Greek | pmichaud: Check out the number of substr , , 1 in the system. | ||
| pmichaud | Paul_the_Greek: yes, that's what I was pointing to | 16:44 | |
| (really gone now) | |||
| Paul_the_Greek | chromatic: What are the future plans for the PIR assembler? Continue work on IMCC? | 16:47 | |
| chromatic | I'm curious to see how PIRATE turns out. | ||
| Paul_the_Greek | Is it a new assembler for PIR? | 16:48 | |
| chromatic | Yes. | 16:49 | |
| davidfetter | is the production version scheduled for mid-september? | ||
| Paul_the_Greek | Who is working on it? | 16:50 | |
| chromatic | bacek has been working on it. | ||
| davidfetter | say, around the 19th? | ||
| Paul_the_Greek | Is it much different from IMCC? | 16:53 | |
| chromatic | It's written in NQP. | 16:54 | |
| Paul_the_Greek | Does it have fancy macros or simple ones? | ||
| chromatic | I don't know that. | ||
|
16:59
DrForr joined
17:02
brianwisti joined
|
|||
| Paul_the_Greek | chromatic: Who is the current memory management expert, if any? | 17:03 | |
| chromatic | A handful of us: me, whiteknight, bacek, whoever else pokes in there. | 17:04 | |
| Paul_the_Greek | Okay, then I'll ask everyone if I have any questions. | ||
|
17:10
jsut joined
17:20
cotto_work joined
|
|||
| cotto_work | ~~ | 17:25 | |
|
17:25
plobsing joined
|
|||
| dalek | rrot: r48525 | NotFound++ | trunk/src/pmc/null.pmc: [cage] reorganize and improve pod of Null PMC |
17:28 | |
| dukeleto | I am seeing t/library/pg.t fail on trunk on linux | 17:35 | |
| (datura)(~/svn/parrot)$ git | 17:36 | ||
| git github_post_receive git-receive-pack git-shell git-spread git-upload-archive git-upload-pack | |||
| (datura)(~/svn/parrot)$ git | |||
| dukeleto facepalms | |||
| gist.github.com/527377 is the failing t/library/pg.t output | 17:37 | ||
| dalek | rrot: r48526 | NotFound++ | trunk/src/pmc (5 files): [cage] update headerizing |
17:44 | |
| kudo: b647188 | pmichaud++ | : <pre>m build/PARROT_REVISION <pre style='white-space:pre-wrap;width:81ex'>Bump PARROT_REVISION in preparation for Parrot release.</pre> |
17:56 | ||
|
17:57
cotto_work joined
|
|||
| tcurtis cannot get installed parrot to work lately. | 17:57 | ||
|
17:57
gbacon joined
|
|||
| tcurtis | I keep getting packfile version errors. Even nuking my previous parrot install didn't help. | 17:57 | |
| nopaste | "NotFound" at 192.168.1.3 pasted "PLA multiply example in winxed" (28 lines) at nopaste.snit.ch/22832 | 18:02 | |
| NotFound | msg whiteknight nopaste.snit.ch/22832 PLA multiply example in winxed | 18:03 | |
| purl | Message for whiteknight stored. | ||
| plobsing | tcurtis: PBC_COMPAT was bumped, you have to remake any and all .pbc files to run them on a new parrot. | 18:04 | |
| tcurtis | plobsing: would nuking my parrot installation (rm -rf $PREFIX/lib/parrot) and realcleaning not do that? | 18:05 | |
| plobsing | it depends. For example, if you're trying to use non-core pbc files (eg: rakudo), they would not be remade by default. | 18:07 | |
| but I would expect it to work for core. | |||
| cotto_work | reconfig should work | 18:08 | |
|
18:08
s1n joined
|
|||
| tcurtis | Even parrot with no args and parrot_config do it for me. I'll try again tonight after GSoC pencils down and see if I can figure out what [I am doing || is going] wrong. | 18:09 | |
| plobsing | try a clean checkout perhaps? | 18:10 | |
| tcurtis will do. | |||
|
18:14
AndyA joined
18:16
Paul_the_Greek joined
18:17
kurahaupo joined
|
|||
| pmichaud | odd datapoint.... switching nqp-rx to use 'ord' instead of 'substr' for single-character literal comparisons did not appear to significantly improve rakudo compile time. | 18:27 | |
|
18:27
AndyA joined
18:31
ruoso joined
|
|||
| whiteknight | Notfound++ | 18:31 | |
| dalek | ee-optimization: f270ec3 | tcurtis++ | : <pre>m docs/Tree/Optimizer.pod <pre style='white-space:pre-wrap;width:81ex'>Fix typo.</pre> |
18:32 | |
| tcurtis | O.o | ||
| dalek | ee-optimization: 198314c | tcurtis++ | : <pre>+ docs/Tree/Optimizer/Pass.pod <pre style='white-space:pre-wrap;width:81ex'>Add docs for Tree::Optimizer::Pass. Last commit before I tag pencils down.</pre> |
18:38 | |
| whiteknight | tcurtis++ | ||
| html-- | |||
| Paul_the_Greek | pmichaud: Weird. | 18:39 | |
| pmichaud | Paul_the_Greek: I'm guessing it's overwhelmed by other factors | 18:40 | |
| tcurtis wonders how the HTML is getting in there. | |||
| pmichaud | tcurtis: I'm thinking github may have changed the format of their rss feed | ||
| and that dalek hasn't caught up | |||
| Paul_the_Greek | pmichaud: Did you time this against the system that shares substrings or one that does not? | ||
| whiteknight | you know, github does have service hooks for IRC. We don't need dalek, we could ask github to automatically report commits to here | ||
| pmichaud | Paul_the_Greek: ? | 18:41 | |
| cotto_work | but does it do karma? | ||
| pmichaud | I timed it against parrot trunk, substring version versus ord version | ||
| Paul_the_Greek | pmichaud: I don't know whether the trunk still has shared substrings or not. | ||
| pmichaud | Paul_the_Greek: I don't know either.... but since nqp-rx (and rakudo) always tend to work against parrot trunk, that's my basis for comparison | 18:42 | |
| Paul_the_Greek | It has to allocate a string header one way or the other. | ||
| pmichaud | ord requires allocation of a string header? | 18:43 | |
| that would be..... odd | |||
| Paul_the_Greek | No, substr. | ||
| pmichaud | right | ||
| chromatic | If the comparison is against a string literal, that string literal will always be a constant string literal in the bytecode. | ||
| Paul_the_Greek | Sorry to be a pest: Can someone tell me where DPOINTER is defined? | 18:45 | |
| pmichaud | the patch I made changes, e.g. | ||
| $S11 = substr target, pos, 1 | 18:46 | ||
| plobsing | Paul_the_Greek: include/parrot/config.h | ||
| pmichaud | ne $S11, '#', fail | ||
| to | |||
| $I11 = ord target, pos | |||
| ne $I11, 35, fail | |||
| Paul_the_Greek | plobsing: Thanks. That must be generated; not available in online browser. | 18:47 | |
| plobsing | Paul_the_Greek: 'make tags-{vi,emacs}' makes it really easy to find these things | 18:48 | |
| Paul_the_Greek | plobsing: I'm on my wife's laptop at the beach, so can only look online. Easy pie at home. | 18:49 | |
| That's why I apologized for being a pest. ;) | |||
| dalek | rrot: r48527 | NotFound++ | trunk/t/op/string.t: fix and improve substr oob tests |
18:50 | |
| rrot: r48528 | plobsing++ | trunk/src/packout.c: eliminate useless var |
|||
| rrot: r48529 | NotFound++ | trunk/t/op/string.t: test for substr null string |
|||
| chromatic | pmichaud, five of your new tests still fail, but I should have them passing in a few minutes. | 18:55 | |
| pmichaud | chromatic: excellent | 18:56 | |
| tcurtis created pencils-down tags in both tree-optimizations repo and simple-optimizations repo. | |||
| Paul_the_Greek | pmichaud: That's a testament to the speed of substr if your optimization doesn't help much. | 18:57 | |
| pmichaud | Paul_the_Greek: I think it's more that there are other factors that swamp the difference. It's also very possible/likely that LTM is avoiding a lot of unnecessary checks. | ||
| Paul_the_Greek | Well, it's been a tough day so far, so time for a nap. | 18:59 | |
| cotto_work | tcurtis: not a bad idea | 19:01 | |
| dalek | rrot: r48530 | chromatic++ | branches/substr_eq_at (5 files): [ops] Renamed substr_eq_at op to cmp_str_at. |
19:07 | |
| rrot: r48531 | chromatic++ | branches/substr_eq_at (4 files): [str] Added length to Parrot_str_compare_offset. |
|||
| chromatic | pmichaud, r48532 should work for you now. | 19:14 | |
| pmichaud | chromatic++ # will try it shortly | ||
| same branch? | |||
| chromatic | Yes. | 19:15 | |
| bubaflub | hey GSoC-ers, pencils-down time has already passed and the final student evaluations are on Melange now | 19:18 | |
| dalek | p-rx: e91bc31 | pmichaud++ | : <pre>m build/PARROT_REVISION <pre style='white-space:pre-wrap;width:81ex'>Bump PARROT_REVISION to be closer to 2.7.0 release.</pre> |
19:19 | |
| p-rx: 90e0bcd | pmichaud++ | : <pre>m src/PAST/Compiler-Regex.pir <pre style='white-space:pre-wrap;width:81ex'>Refactor case-insensitive literals in preparation for other improvements.</pre> |
|||
| p-rx: 6ab1f66 | pmichaud++ | : <pre>m src/PAST/Compiler-Regex.pir <pre style='white-space:pre-wrap;width:81ex'>Optimize single-character constant literal tests to use 'ord' instead of 'substr'.</pre> |
|||
| p-rx: 2a8a5a9 | pmichaud++ | : <pre>m src/stage0/HLL-s0.pir m src/stage0/P6Regex-s0.pir m src/stage0/Regex-s0.pir </pre> <pre style='white-space:pre-wrap;width:81ex'>Update bootstrap.</pre> |
|||
| rrot: r48532 | chromatic++ | branches/substr_eq_at/src (2 files): [str] Fixed cmp_str_at opcode. encodings as well as unsanitized length parameters, but all of Patrick's tests pass now. |
19:24 | ||
| cotto_work | a cookie to anyone who can get the trac github plugin working | 19:39 | |
| dalek | rrot: r48533 | chromatic++ | branches/substr_eq_at (2 files): [str] Sanitized Parrot_str_compare_offset. Additional tests welcome. |
19:41 | |
|
19:43
kurahaupo joined
|
|||
| pmichaud | chromatic: I added some more (failing) tests for cmp_str_at -- there are some problems when comparing ascii vs. unicode operands | 19:46 | |
| oh, I'll have to merge with r48533.... just a sec | 19:47 | ||
| chromatic | That means string iteration, but I can write that loop. It's easy. | ||
| pmichaud | committed, r48534 | 19:52 | |
| dalek | rrot: r48534 | pmichaud++ | branches/substr_eq_at/t/op/substr_cmp.t: [str]: Added some (failing) tests for experimental cmp_str_at with mixed unicode+ascii operands. |
19:58 | |
| chromatic | Fix coming in 30 seconds, pmichaud. | 20:04 | |
| pmichaud | chromatic: okay! | 20:05 | |
| chromatic | r48535 should do it. | 20:06 | |
| dalek | rrot: r48535 | chromatic++ | branches/substr_eq_at (2 files): [str] Enabled Unicode in Parrot_str_compare_offset. Ideally the STRING parameters can go const again with some cleverness. |
20:14 | |
|
20:22
kurahaupo joined
20:23
hercynium joined
20:25
davidfetter joined
20:28
kurahaupo joined
|
|||
| pmichaud | chromatic: with cmp_str_at I seem to get no significant speedup or slowdown in building Rakudo's core.pir (which is the biggest/meanest test I can throw at it for now). I'm not sure why. | 20:53 | |
| I think I will need to retrace my steps and make sure I'm measuring what I think I'm measuring. | |||
| I can tell that Rakudo is definitely using cmp_str_at.... just don't see any significant speedup as a result. | 20:54 | ||
| chromatic | That's strange, unless the memory cost of mixed encoding iteration is significant. | ||
| pmichaud | There might be fewer gcables created.... but I'm not suite sure how to measure that. | ||
| moritz | do you know how of it is called? | ||
| pmichaud | moritz: cmp_str_at gets called a lot -- basically anytime rakudo wants to match a keyword longer than one character | 20:55 | |
| s/rakudo/the parser/ | |||
|
20:55
whiteknight joined
|
|||
| moritz | which is... for all operators and terms, right? | 20:55 | |
| pmichaud | and statements | ||
| purl | statements is not recommended. | ||
| cotto_work | forget statements | ||
| purl | cotto_work: I forgot statements | ||
| pmichaud | purl, forget statements | ||
| purl | pmichaud, I didn't have anything matching statements | ||
| chromatic | How difficult is it to have PCT emit matching encodings for the substrings to compare? | 20:56 | |
| pmichaud | at the time the parser is compiled, it doesn't know the encoding of the source | ||
| chromatic | Perl 6 programs tend to use fixed-8 though, right? | 20:57 | |
| pmichaud | iso_8859_1, generally | ||
| because of Ā« and Ā» | |||
| and any codepoint outside of latin-1 means that the source is utf8 (more) | 20:58 | ||
| chromatic | As a quick test, can you emit those substrings as iso-8859-1 encodings? | ||
| pmichaud | I might be able to do it | 20:59 | |
| oh, that won't help | |||
| because core.pm has Ā« and Ā» in it, it's definitely going to be parsed as utf8 | |||
| oh, wait, or latin-1 | 21:00 | ||
| jnthn | Do we actually have it as utf8 while parsing? | ||
| pmichaud | just a sec, let me see if it falls into latin 1 | ||
| jnthn | Do we have a fixed width encoding that we can just always explode stuff into? | ||
| pmichaud | jnthn: PCT tries to recode source as ascii or iso-8859-1 if it can. If it cannot, it's pretty much stuck with utf8. | ||
| jnthn | Oh. :-( | ||
| pmichaud | jnthn: no fixed width encoding is reliable enough yet, and it requires ICU. | ||
| let me see if core.pm at least ends up as iso-8859-1. | 21:01 | ||
| jnthn | Ugh, OK | ||
| nopaste | "chromatic" at 192.168.1.3 pasted "pmichaud, jnthn: this isomorphism appears to work" (14 lines) at nopaste.snit.ch/22835 | 21:05 | |
| jnthn | That looks...scary. | ||
| pmichaud | surely you mean iso88591 there instead of utf8 ? | ||
| ummm, wait | 21:06 | ||
| under what circumstances would we get into the ascii compare function if the lhs is utf8 encoded? | |||
| I could see using memcmp if lhs is ascii and rhs is iso88591 | 21:07 | ||
| chromatic | Yeah, I have lhs and rhs backwards there. | ||
| || rhs->encoding == Parrot_fixed_8_encoding_ptr) { | 21:09 | ||
| That's much saner. | |||
| pmichaud | agreed, I feel better about that one. | ||
| it wouldn't be correct if there are two charsets using fixed_8, though. | |||
| chromatic | This is me not pleased with the Cartesian product of our encodings and character sets. | 21:10 | |
| pmichaud | seems like it'd be better to check the rhs for iso-8859-1 charset | 21:11 | |
| instead of checking the encodings | |||
| (or perhaps check both) | |||
| there are (were) a few other places in the strings code that tended to take a shortcut like that | 21:12 | ||
| okay, I converted the parser to use iso-8859-1:"const string" instead of just "const string" | 21:13 | ||
| let's see if it gives any improvement | |||
| chromatic | Checking the rhs charset for iso-8859-1 works too. | ||
| pmichaud | nope, still no significant change. | 21:15 | |
| less than 0.5 second out of 160 | |||
| that seems very strange. | 21:16 | ||
| chromatic | It does. | 21:17 | |
| purl stays quiet | |||
| jnthn | purl: you should do that much more often. :-) | ||
| purl | jnthn: excuse me? | ||
|
21:23
tadzik joined
|
|||
| chromatic | If I had Callgrind output from before and after the changes, I'd have a better sense of what's happening. | 21:23 | |
| A sandwich wouldn't hurt either though. | |||
| pmichaud | yeah, I was thinking something similar. | ||
| I'll push my changes into branches and then we can perhaps track things down from there. | |||
|
21:26
Paul_the_Greek joined
|
|||
| pmichaud tries a basic test with rakudo, has a serious "wtf?" moment | 21:31 | ||
| Paul_the_Greek | What's up? | 21:32 | |
|
21:32
bubaflub joined
|
|||
| pmichaud | okay | 21:32 | |
|
21:32
lucian joined
|
|||
| pmichaud | found it -- forgot an option. | 21:33 | |
| I'm convinced that when Rakudo is parsing core.pm to generate core.pir, it's using iso-8859-1 as the source encoding. | |||
| chromatic | darbelo should put his pencil down soon, so perhaps he can look in on this with us. | ||
| pmichaud | well, I'm going to need a break shortly -- and I'd like to get the Nil fixes into rakudo before the release | 21:34 | |
| also, looking at this code convinces me that I can improve nqp-rx a fair bit even without the opcode, so I'd like to get those improvements in before the parrot release | |||
| chromatic | If your code is available in branches, we can play with that. | ||
| pmichaud | so I may move to that for the rest of the evening and pick up with cmp_str_at again tomorrow | ||
| chromatic | Fine by me. What's "a fair bit" in your estimation? | 21:35 | |
| pmichaud | don't know.... but I can avoid quite a lot of unnecessary method calls | ||
| I can optimize the debugging calls out of the hot codepaths | |||
| the nqp-rx version that makes use of the cmp_str_at opcode is the 'cmp_str_at' branch of the nqp-rx repo | 21:36 | ||
| you have to build the parrot branch separately, then configure nqp-rx with --parrot-config=... to get it to use it | |||
| oh | |||
| I can also push my changes to the parrot branch | 21:37 | ||
| just a sec | |||
| that'd be easier | |||
| r48536 | 21:39 | ||
| just use that version of Parrot to build Rakudo | |||
| (or any other code that you wish to test) | |||
| chromatic | Thanks. | 21:41 | |
| pmichaud | afk for a short while | ||
|
21:44
Administrator_ joined
21:51
Paul_the_Greek joined
21:52
seatek joined
21:54
davidfetter joined
|
|||
| dalek | rrot: r48536 | pmichaud++ | branches/substr_eq_at/ext/nqp-rx/src/stage0 (4 files): [nqp-rx]: Push nqp-rx that uses cmp_str_at for substring comparisons. |
21:54 | |
|
22:08
darbelo joined
22:18
tcurtis joined
|
|||
| Paul_the_Greek | Here's a question: When I get back home after vacation, what's the best way to update my local copy? | 22:30 | |
| cotto_work | Paul_the_Greek: did you see that I fixed the conflicts and applied your patch?> | ||
| mikehh | Paul_the_Greek: as in svn update | 22:31 | |
| Paul_the_Greek | cotto! You made my vacation.I was dreading sorting it all out when I returned. I thanked you in the ticket. | ||
| cotto_work | What else do you have going, and are those things in separate checkouts? | 22:32 | |
| Paul_the_Greek | I have two further tickets with patches pending. Would you like the links? | ||
| They are much simpler. | 22:33 | ||
| cotto_work | I can find them. | ||
| Are they all you have? | |||
| Paul_the_Greek | New math opcodes and cleanup of a lexical function. | ||
| cotto_work | The reason I ask is because it might be simpler to clobber all local changes once those patches are committed. | 22:34 | |
| (mainly to avoid dealing with conflicts from the pobj.h changes) | |||
| Paul_the_Greek | I have other local changes in the works. Those would be clobbered, too. Easiest to save the files off to the side and then merge in my changes? | ||
| For example, I have some new tests. | 22:35 | ||
| cotto_work | you can revert individual files too | ||
| Don't spend your vacation worrying about it. We'll get you sorted out if you want help. | 22:36 | ||
| Paul_the_Greek | Oh, I'm a happy camper. You dealt with the one I was dreading. | ||
| ++Cotto++ | |||
| cotto_work | I'm glad to have it in the past. | ||
| Paul_the_Greek | From now on, if I comment the crap out of a file, I'll ask for it to be committed immediately. | 22:37 | |
| cotto_work | and I'll be less of a slacker | ||
| Paul_the_Greek | In the process, I think I found a way to speed up PMC attribute allocation. I'll take a look when I return. | ||
| Hey, you can't look at everything immediately. | 22:38 | ||
|
22:39
ash_ joined
|
|||
| Paul_the_Greek | My first task will be to figure out why PMC attributes are allocated separately from other fixed-size objects. I think it's just an efficiency thing. | 22:40 | |
| cotto_work | whiteknight, bacek or chromatic might be able to answer that question | 22:41 | |
| Paul_the_Greek | chromatic thought it was efficiency, too. | ||
| There is an odd bit of hacking to select the PMC attribute vector index that I think we can eliminate. | 22:42 | ||
|
22:44
allison joined
22:45
kurahaupo joined
22:47
lucian joined
22:49
dngor_ joined
|
|||
| Paul_the_Greek | After a tough day, time for ice cream. Thanks again, cotto. | 22:49 | |
| cotto_work | thanks for the documentation | 22:50 | |
|
23:00
workbench joined
23:03
kid51 joined
|
|||
| kid51 | msg darbelo Thanks for noting my concerns about our inability to compile Rakudo on smaller machines. | 23:04 | |
| purl | Message for darbelo stored. | ||
| kid51 | NotFound++ for providing docs for two .pmc files. | 23:05 | |
| mikehh | yes excellent! | 23:08 | |
| purl | Smithers, release the hounds! | ||
|
23:09
ruoso joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48536 - Ubuntu 10.04 amd64 (gcc with --optimize) | 23:10 | |
| kid51 | mikehh: Now if we can get all the *other* folks to do their part on the .pmc documentation :-) | 23:11 | |
| mikehh | kid51: :-} - doin' fulltest runs gettin' ready for the release, then I will think of our next major documentation project... | 23:13 | |
| kid51: have you done a PPC fulltest recently? | 23:15 | ||
| In fact I would appreciate fulkltest results from anyone here, especially on some different platforms, maybe some MSWin ones | 23:17 | ||
|
23:18
aloha joined
|
|||
| kid51 | mikehh: Across five timezones, you read my mind. It's in progress -- hopefully done within an hour. | 23:22 | |
| Anyone available to glance at trac.parrot.org/parrot/changeset/48492: Paul_the_Greek's documentation additions? | 23:23 | ||
| cotto applied patch but requested additional eyes; looks fine to me; I'd like to close ticket. | |||
|
23:24
dngor_ joined
|
|||
| cotto_work | I'd like eyes familiar with the GC code who can verify that the comments are accurate. | 23:25 | |
| kid51 | cotto_work: Perhaps you should CC: one of our many GC experts on that ticket! ;-) | 23:28 | |
| perhaps whiteknight? | 23:29 | ||
| cotto_work | I'll see if I can find someone to bug about it. | ||
| seen whiteknight | 23:30 | ||
| purl | whiteknight was last seen on #parrot 4 hours, 49 minutes and 4 seconds ago, saying: you know, github does have service hooks for IRC. We don't need dalek, we could ask github to automatically report commits to here | ||
| cotto_work | whiteknight, ping | ||
| mikehh | looks ok to me, but you probably need a perusal by chromatic, bacek or our esteemed chief architect | ||
|
23:34
Paul_the_Greek joined
|
|||
| kid51 | msg whiteknight I have cc-ed myself on TT #1744, but don't have any particular insight. Will try to look at it more closely later in week. | 23:34 | |
| purl | Message for whiteknight stored. | ||
| Paul_the_Greek | What is 2.7 named? | 23:35 | |
| cotto_work | We'll find out soon. | 23:36 | |
| Paul_the_Greek | How are they named? | ||
|
23:36
bacek joined
|
|||
| cotto_work | It's determined entirely by the release manager. | 23:36 | |
| Paul_the_Greek | Aha. That's fun. | 23:37 | |
|
23:37
aloha joined
|
|||
| kid51 | Paul_the_Greek: All related to parrots, the birds. If you have nothing better to do on your vacation, you can assemble a comprehensive list of parrot species/breeds for future releases. :-) | 23:38 | |
| Paul_the_Greek | How long have you worked on Parrot, cotto? | ||
| cotto_work | something liek 2.5 years | ||
| *like | |||
| mikehh | I have been tending towards Australian King. a parrot that resides where our chief coding robot resides | 23:39 | |
| Paul_the_Greek | Have we had the Macaw release yet? | ||
| cotto_work | docs/parrothist.pod lists past releases | 23:40 | |
| Paul_the_Greek | Does anyone do Parrot as their $work? | ||
| bacek appears with flames and smokes | 23:41 | ||
| kid51 | No, but my hunch is that there are those among us who manage to do Parrot *during* $work ... | ||
| kid51 is not among them :-( | |||
| Paul_the_Greek | "Release formerly known as Prince" ? | 23:42 | |
| bacek | cotto, r48492 looks good. You can close ticket :) | ||
| cotto_work | bacek++ | ||
| Paul_the_Greek | I work for myself, so $work blurs with @play. | 23:43 | |
| cotto_work | done | ||
| mikehh | bacek: do you have a parrot you want to honour? | ||
| bacek | mikehh, nope. | ||
| Paul_the_Greek | A Parrot Looks at 40? | 23:44 | |
| cotto_work | PROTIP: it doesn't have to be a real parrot | ||
| bacek | breakfast and dayjob time. | ||
| See ya | |||
| Paul_the_Greek | Where is bacek? | 23:45 | |
| purl | bacek is THE MANIAC or some sort of magical coding robot or probably not mailto:pmichaud@pobox.com or mailto:thebacek@gmail.com or blazing new trails | ||
| cotto_work | sydney iirc | 23:46 | |
| dalek | TT #1605 closed by cotto++: Documentation for buffers in include/parrot/pobj.h is outdated. | ||
| TT #1605: trac.parrot.org/parrot/ticket/1605 | |||
| Paul_the_Greek | Man, the idea of distributed participation is no joke. | ||
| mikehh | dat is why we is gonna move to git probably :-} | 23:47 | |
| Paul_the_Greek | Wait, he closed my ticket before I was done. | 23:48 | |
| cotto_work | That's not one of the many reasons I've heard so far. | ||
| Paul_the_Greek: tickets are a renewable resource. You can open a new one (or reopen the old one). | |||
| Paul_the_Greek | I read the Git book over the past few days. It looks like it will be pretty cool. | 23:49 | |
| mikehh | Paul_the_Greek: Documentation is *never* done, it is a WIP | ||
| Paul_the_Greek | I'll reopen it when I return with my brand spankin' new Memory Internals doc. | ||
| There do seem to be no lack o' tockets. | 23:50 | ||
| cotto_work | And you can get karma for working on any one of them. | ||
| mikehh | well for opening and closing them :-} | 23:51 | |
| cotto_work | and if someone say Paul_the_Greek++ | ||
| Paul_the_Greek | I'm really a ++x kind of guy, rather than an x++ guy. | 23:52 | |
| I like to be fetched after I'm incremented. | |||
| cotto_work | purl isn't | ||
| Paul_the_Greek | purl++ | ||
| cotto_work | purl-- | 23:53 | |
| purl | cotto_work: what? | ||
| cotto_work | (she cheats) | ||
| plobsing | dec purl | ||
| Paul_the_Greek | I wonder what it says about a person whether they use ++x or x++ ? | ||
| purl -= 1 | 23:54 | ||
| purl | Paul_the_Greek: sorry... | ||
| sorear | "the" Git book? | ||
| la la purl-- | |||
| Paul_the_Greek | Yes, I got a book on Git and read it. Reasonably clear about most things. | ||
| Very clever with the 160-bit hash. | |||