|
#parrot Parrot 2.2.0 "Like Clockwork" Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix compact_pool shenanigans | Fix HLL bugs (TT #389, #1040) | Prioritize Rakudo Needs Set by moderator on 20 March 2010. |
|||
|
00:07
snarkyboojum joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32824), fulltest) at r45165 - Ubuntu 9.10 amd64 (g++ with --optimize) | 00:07 | |
| kid51 | mikehh: In trunk, I am getting failures in 'make buildtools_tests': specifically, tests t/tools/ops2pm/09 thru 11. | 00:08 | |
| mikehh: These failures disappear when I call 'make opsrenumber' | 00:09 | ||
| mikehh: Can you confirm this? Thanks. | |||
| These tests passed at r 45048 but were failing by r45106 | 00:10 | ||
| dalek | rrot: r45166 | petdance++ | trunk/src/gc (3 files): more const correctness in GC land |
00:14 | |
| kudo: dfbd1d5 | jonathan++ | src/Perl6/Grammar.pm: While %tight_or is indeed list associative, because of the way we compile short-circuit || and //, we need to have them marked as left associative. Fixes RT#73774. |
|||
| mikehh | kid51: yes 9-11 fail with op set_result_info_p: sequence mismatch: ops.num 227 vs. core.ops 1250 | 00:15 | |
| kid51: never run those test before - what else am I missing | 00:16 | ||
| kid51: and yes they pass after make opsrenumber | 00:19 | ||
| kid51 | They were formerly part of perl Configure.pl --test | ||
| But there were objections, so we moved them to run post make, on a voluntary basis. | |||
| Am bisecting now | |||
|
00:20
Essobi joined
00:24
riffraff joined
|
|||
| kid51 | r45089 was the culprit: ops codes were added to src/ops/ops.num but 'make opsrenumber' was not run | 00:25 | |
| sorear | was that my fault? | ||
| dalek | kudo: e673638 | jonathan++ | src/pmc/perl6multisub.pmc: Reviewed Rakudo C bits for memory leaks due to missing frees in the few places we mem_allocate. Found one missing mem_sys_free, though 'sadly' on a rarely followed code path (only affected code using junctions). |
00:26 | |
| kid51 | It's a kind of obscure requirement. | ||
| sorear | Well, I thought I ran 'make test' | ||
| kid51 | You did, no doubt. This is not included in 'make test'. | 00:27 | |
| And since we don't add/subtrace ops codes very often, it's quite possible that plobsing didn't know this requirement either. | |||
| Don't lose any sleep over this. | |||
| But do do 'make realclean' and reconfigure and rebuild. | |||
| sorear | That would have caught this? | 00:28 | |
| sorear did not know about 'make realclean' | |||
| kid51 | 'make realclean' removes all files generated by Configure.pl as well as all those generated by 'make' | ||
| mikehh | kid51: these tests should then be part of fulltest | 00:29 | |
| Coke | +1. fulltest can be slow and thorough. | ||
| kid51 | So, any time we change what gets generated in the Makefile(s) -- which is relatively often -- you need to make realclean and reconfigure | ||
| Coke: No disagreement from me there :-) | 00:30 | ||
| kid51 edits config/gen/makefiles/root.in | |||
| Does anyone have a preference as to where in the sequence of tests in 'make fulltest' this should sit? | 00:31 | ||
| (After run_tests seems good to me) | |||
| dalek | rrot: r45167 | jkeenan++ | trunk (2 files): At r45089, ops codes were added but 'make opsrenumber' was not run. Doing so now and committing result. |
00:32 | |
| kid51 does 'make fulltest' with buildtools_tests included | 00:34 | ||
| 'make fulltest' being thorough and .... slow, kid51 wanders off in search of beer | 00:37 | ||
| mikehh | I run it with TEST_JOBS=40 which cuts the time down considerably, but NOT -j as this causes conflicts | 00:41 | |
| kid51 | mikehh: I don't have any multicore machines, so I don't get any meaningful speedup from TEST_JOBS, -j or the like | 00:42 | |
| besides, computer programs ought to allow time for beer | |||
| chromatic | Parallel testing should help IO-bound tests, even if you don't have a multicore machine. | 00:44 | |
| Coke | but... beer! | 00:45 | |
| mikehh | kid51: ah well - my desktop is a 4 core Phenom 840 with 8GB ram, my last fulltest was timed as - real 9m22.627s | ||
| sorry that's 940 | 00:46 | ||
| dalek | rrot: r45168 | petdance++ | trunk (5 files): more const correctness and dropping of unused args |
00:49 | |
|
00:54
abqar joined
00:59
theory joined
|
|||
| dalek | rrot: r45169 | jkeenan++ | trunk/config/gen/makefiles/root.in: Per suggestion from mikehh++ and Coke++, add 'buildtools_tests' to 'make fulltest' targets. |
01:05 | |
| rrot: r45170 | jkeenan++ | trunk/MANIFEST.SKIP: Needed to regenerate SKIP after changing a directory's svn:ignore properties. |
|||
|
01:08
hercynium joined
|
|||
| dalek | rrot: r45171 | mikehh++ | trunk/src/gc/gc_ms.c: fix codetest failure - there should be one space or a newline after a comma |
01:21 | |
| allison | I've got a segfault on Ubuntu karmic compiling PGE | 01:25 | |
| recent? known? | |||
| chromatic | Everything was fine for me as of r45163. | 01:26 | |
| dalek | kudo: 99c4bcf | jonathan++ | src/ops/perl6.ops: Fix up the bind_signature op patch from a couple of days ago. I said it looked very dubious at the time and we wre just getting lucky. Seems I was right. Hopefully this is the proper fix. |
01:31 | |
| kudo: 626ee20 | jonathan++ | build/PARROT_REVISION: Bump us up to the latest Parrot version to get memory leak fixes by (Parrot team)++. |
|||
| allison | a double realclean seems to clear it on one box, trying the other | 01:38 | |
|
01:55
patspam joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32826), fulltest) at r45171 - Ubuntu 9.10 amd64 (gcc with --optimize) | 01:58 | |
|
01:58
Mokurai1 joined
|
|||
| chromatic | ... and there's another memory leak fixed. | 02:04 | |
|
02:12
dalek joined
02:15
cotto joined
02:16
khai joined
02:23
bubaflub joined
02:30
eternaleye joined
02:44
dalek joined
03:00
ekiru joined
|
|||
| ekiru | The explanation of the PIR factorial example in docs/intro.pod seems to be out of sync with the actual example code. It refers to a line ".local pmc result, factorial" which isn't present in the example code. | 03:31 | |
| Coke | moment. | 03:34 | |
| ekiru: fixed in svn. | 03:36 | ||
| dalek | rrot: r45172 | coke++ | trunk/docs/intro.pod: sync snippet with main source, thanks to ekiru++ |
03:38 | |
|
03:48
Andy joined
04:12
janus joined
04:35
tcurtis joined
|
|||
| dalek | rrot: r45173 | cotto++ | branches/profiling_testing/t/profiling/profiling.t: [profiling] add some more profiling test cases |
05:00 | |
|
05:00
sorear joined
|
|||
| cotto | What's a nice phrase for "skip to the next foo"? | 05:30 | |
| or "this is the next foo" | 05:32 | ||
| allison | keywords, or descriptive phrases? | 05:38 | |
| "following" | 05:39 | ||
| keywords: hard to beat "next" | 05:40 | ||
| sorear | subsequent | ||
| allison | "succeeding" | 05:43 | |
| cotto | It's a keyword and 'next' is a good word. Is there a more concise way to say "the next thing of this type" than next_of_type? | 05:46 | |
| sorear | nextsame; | 05:47 | |
|
05:56
ruoso joined
|
|||
| cotto | It's an interesting exercise to make something intuitive and obvious. | 05:57 | |
|
06:00
Util joined
|
|||
| cotto | night | 06:08 | |
|
07:10
uniejo joined
|
|||
| dalek | rrot: r45174 | chromatic++ | trunk/src/embed.c: [src] Fixed a compilation warning about an unused return value in |
07:19 | |
| rrot: r45175 | chromatic++ | trunk/src/packfile.c: [src] Fixed a memory leak in pf_debug_new(), where creating a Debug PackFile creating them here avoids that. |
|||
| rrot: r45176 | chromatic++ | trunk/src/pmc/imageio.pmc: [PMC] Tidied code in ImageIO PMC, and NULLed out the freed PackFile in its |
|||
| rrot: r45177 | chromatic++ | trunk/src/packfile.c: [src] Fixed a long-standing memory leak of where directories appended to other |
|||
| purl | packfiles are the representation of bytecode. | ||
| rrot: r45178 | chromatic++ | trunk/src/extend.c: [src] Fixed yet another Parrot_pcc_split_signature_string() memory leak. I |
|||
| moritz | chromatic++ | ||
| dalek | kudo: 633c096 | moritz++ | t/spectest.data: run the new S12-class/stubs.t |
07:21 | |
| chromatic | There are still some leaks, but I don't know if they're Parrot or Rakudo at this point. | 07:22 | |
| sorear | yay | 07:23 | |
|
07:23
jhelwig joined
|
|||
| sorear | purl, ignore dalek | 07:23 | |
| purl | sorear: excuse me? | ||
| moritz | chromatic: at least rakudo now builds again in a ulimit of 1G virtual memory | 07:25 | |
| chromatic: so it brought at least an improvement of factor 1.5 | |||
| chromatic | I think one of the Rakudo ops leaks too. | 07:26 | |
| sorear | I'm suprised it's this easy. | 07:27 | |
| chromatic | allocate_signature, perhaps. | ||
| sorear | I was completely expecting there to be no real leaks but only bad retention patterns in the parser, and I would need to write a memory profiler to fix them | ||
| chromatic | I suspect those also exist. | 07:28 | |
| moritz | the compilation to PAST nodes keeps the complete match tree around | 07:29 | |
| although it really would just need the source string + position information | |||
| it uses :node($/) for convenience | 07:30 | ||
| chromatic | ... and there's one leak in Rakudo. | ||
| dalek | kudo: 5ab33a1 | chromatic++ | src/pmc/p6lowlevelsig.pmc: [PMC] Fixed a memory leak in P6LowLevelSig PMC's destroy. Note that the VTABLE, to make such leaks easier to track. |
07:38 | |
| kudo: 1828116 | chromatic++ | t/spectest.data: Merge branch 'master' of git@github.com:rakudo/rakudo |
|||
|
07:49
iblechbot joined
|
|||
| dalek | kudo: 0afbf11 | moritz++ | build/PARROT_REVISION: bump PARROT_REVISION again to get more memory fixes in parrot, chromatic++ |
07:55 | |
|
07:59
snarkyboojum joined
08:07
riffraff joined
|
|||
| sorear wonders what to call a Parrot SNOBOL4 | 08:13 | ||
|
08:24
silug joined
08:30
bacek joined
|
|||
| bacek | o hai | 08:30 | |
| Austin | sorear: In english, "ps" is a valid dipthong. | 08:35 | |
| So: psnobol | |||
| Or maybe "perl 0.1" | |||
| err. 0.4 | |||
| sorear | no, no, not Perl | 08:39 | |
| SNOBOL, despite its application domain, is actually one of the least Perl-like practical dynamic languages ever invented | |||
| which is why I want to implement it on Parrot | |||
| as a test of our flexibility | |||
| nopaste | "Austin" at 68.39.12.202 pasted "Sorted list of tickets, for whiteknight++" (63 lines) at nopaste.snit.ch/20077 | 08:40 | |
| Austin | msg whiteknight I've made that sorted list of my open tickets per your request. See nopaste.snit.ch/20077 | ||
| purl | Message for whiteknight stored. | ||
| Austin | sorear: Snobol is all about strings and patterns, and has a bizarre syntax hostile to all human life. | 08:41 | |
| How is that not like perl? | |||
|
08:41
wagle_ joined
|
|||
| dalek | kudo: a93b9a5 | moritz++ | t/spectest.data: we now pass assign.t again, including some tests for different precdence of item and list assignment |
08:43 | |
| sorear | perl doesn't have failure continuations or completely unrestricted go to or dynamically scoped macros | ||
| snobol doesn't have block structure or any kind of namespacing or filehandles | |||
| snobol uses tied variables for I/O | 08:44 | ||
| and had a fully general FFI in the 60s... | |||
| LOAD('SIN(REAL)REAL','MATHLIB') | |||
| *EXAMPLE FROM DOCUMENTATION | |||
|
09:01
snarkyboojum joined
|
|||
| dalek | kapo: d997e3a | austin++ | src/ (3 files): Added find_method to Opcode.nqp. |
09:05 | |
| kapo: 1c9685a | austin++ | (22 files): Added :subid generation for multisubs. Added get_parrotrole, began refactoring some attribute code in P6metaclass. Renamed Matchers Null, Boolean (IsNull, TrueFalse). Added NameSpace.fetch. Made RSA.append return self. |
|||
|
09:31
AndyA joined
09:38
payload joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32828), fulltest) at r45178 - Ubuntu 9.10 amd64 (g++ with --optimize) | 09:51 | |
| bacek | msg mj41 Looks like TapTinder is unconscious. | 09:54 | |
| purl | Message for mj41 stored. | ||
| ttbot | Parrot trunk/ r45177 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/238418.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) | 09:55 | |
| bacek | erm... It's not what I mean... | 09:56 | |
| mj41 | bacek: There is a bug in tt client. github.com/mj41/TapTinder/issues/#issue/1 Starting all manually again :-(. | 10:12 | |
| bacek | mj41, no worries. I just want to let you know that one of my most popular page to check is "down" :) | 10:14 | |
| dalek | rrot: r45179 | fperrad++ | trunk/runtime/parrot/library/distutils.pir: [distutils] add smoke with harness |
10:39 | |
| Infinoid | sorear++ # should be a good project | 11:27 | |
|
11:27
clinton joined
11:48
cotto joined
11:59
whiteknight joined
|
|||
| Coke | (least perl like languages) or, you could help me with tcl. | 12:20 | |
|
12:20
payload joined
|
|||
| whiteknight | good morning #parrot | 12:32 | |
|
12:35
lucian joined
12:37
ruoso joined
12:59
lucian_ joined
13:08
cosimo joined
13:13
khai joined
13:19
theory joined
13:28
AndyA joined
13:30
iblechbot joined
14:02
riffraff joined
14:09
Mokurai1 joined
|
|||
| Austin sings, "Send lawyers, guns, and money..." | 14:16 | ||
|
14:17
AndyA joined
|
|||
| whiteknight | And I'm down on my luck | 14:21 | |
| Austin | :) | 14:22 | |
| Good morning, Whiteknight. | |||
| whiteknight | good morning Austin | ||
| I grew up listening to the Hank Williams Jr version of that song | |||
| Austin | Heh | ||
| I didn't know he had recorded it.. | 14:23 | ||
| whiteknight | I didn't know he didn't write it for a long time | ||
| Austin | Youtube is my friend... | ||
| Hmm... | 14:25 | ||
| Gonna give that one a pass. I like the Zevon version better. | |||
| whiteknight | you ever had that feeling that you wish a compiler could emit a "programmer is incompetent" warning? | ||
| Austin | God, no! | ||
| whiteknight | and then we set all warnings to become errors, and anybody who can't build a program gets fired | ||
| Austin | I'm with you there. | 14:26 | |
| whiteknight | like this gem I'm staring at now, which uses StringBuilder.Append almost two hundred times to add a javascript code string literal to a webpage | 14:28 | |
| Austin | Heh | ||
| That's what you get for not having here-docs in your language. | 14:29 | ||
| whiteknight | C# Has heredocs | ||
| no excuses | |||
| And plus, it's an ASPX website, he could have added the code directly to the webpage, or created a .js file and included it | |||
| or anything else | |||
| purl | i guess anything else is going to be even worse. | ||
| Coke | www.boingboing.net/2010/03/23/kyrgy...-educ.html | 14:33 | |
| whiteknight | nice | 14:34 | |
| Austin | Kids: Everybody above me in this thread is probably at least 30 years old. :) | 14:37 | |
| whiteknight | I can't wait till I'm 30. That will be awesome | 14:39 | |
| Austin | Thirty is when you turn your negativity 180 degrees. | 14:40 | |
| 29: "Man, everybody older than me is such an idiot...How is that possible?" | 14:41 | ||
| 30: "Man, everybody younger than me is so freaking dumb. How does the species survive?" | |||
| whiteknight | most of the people younger than me are idiots too | ||
| apparently, I'm dancing on the point of a needle :) | 14:42 | ||
| PerlJam | all people are idiots until they prove themselves otherwise | ||
| whiteknight | PerlJam++ | ||
| PerlJam | and even then people will lapse into idiocy on occasion even if they are a genius | ||
| (and people who know grammar well can't even construct a good sentence :) | 14:43 | ||
| whiteknight | that happens most often when you put the person in front of a keyboard in the comments section of a YouTube video | 14:44 | |
|
14:44
dalek joined
14:55
patspam joined
14:59
dalek joined
15:09
khai left
15:12
khairul joined
15:13
uniejo joined
|
|||
| dalek | p-rx: becd0e9 | duff++ | (3 files): remove un-perly fatarrow extension |
15:37 | |
| whiteknight | you know what I love? typing "svn up", and having to wait 10 minutes as dozens of .exe, .o, and .doc files download to my computer | 15:43 | |
| and .dll | |||
| NotFound | whiteknight: 31 is worse that 30, is when "thirtysomething" starts. | 15:45 | |
| whiteknight | good to know. I have several years before I have to find that out | 15:46 | |
| NotFound | I feel young, I'm downloading firmware for NDS card :) | 15:48 | |
|
15:51
davidfetter joined
|
|||
| moritz | where can I find an example of iterating a hash in PIR? | 15:57 | |
| Coke | t/pmc/hashiterator.t | 15:58 | |
| hurm. no. bad example. | 15:59 | ||
| NotFound | moritz: $ winxed -c -e 'var a= {}; for (var b in a) say(b);' ; cat __eval__.pir | ||
| Coke | try t/pmc/hash.t //iter_over_hash | ||
| moritz | or even better... I have an object of a subtype of Capture (which is both an array and a hash) | 16:00 | |
| and I have an array and a hash | |||
| and I want to fill the slots of the Capture thing from the array and the hash | 16:01 | ||
| is there a faster way than iterating over both? | |||
| Coke | not unless capture has some sort of magic method. checking. | ||
| this is the parrot builtin Capture ? | |||
| moritz | aye | ||
| Coke | nope, I don't see any convenience methods. | 16:02 | |
| moritz | so $P0 = iter my_hash # gives me the keys, right? | ||
| Coke | (and all they'd do is the iteration internally anyway, since poking into Hash's guts would be rude.) | ||
| moritz: aye. | |||
| moritz | Coke: thanks | ||
| Coke | but for array, it gives you the values. =-) | ||
| Which seems to me to be bad, forcing you to know what you're iterating over. | 16:03 | ||
| moritz | in this case I know :-) | ||
| is there an example how I can write and call constructors in PIR? | 16:31 | ||
| pmc/object-meths.t has some simple calls to new ['Classname'] | 16:32 | ||
| but I'd need something which passes arguments | |||
| Coke | I think you want the init_pmc vtable, which is invoked with: | 16:33 | |
| new ['Classname'], $P0 | |||
| moritz | so I'd write | ||
| .sub 'new' :vtable('init_pmc') | |||
| .param foo :named | 16:34 | ||
| and then call that as new ['Classname'], 'foo' => 3 | |||
| NotFound | But his uselfuness for pir classes is limited, because it always try to initialize atributes from the $P0 keys | ||
| Coke | you can't use named args there, I think. | ||
| I think you'd have to explicitly pass pass a hash or other container. | 16:35 | ||
| (since vtables ain't methods) | |||
| though you could, of course, just have a method named "new" that wasn't invoked with the 'new' opcode. | |||
| NotFound | The docs mention some BUILD property, but I think is a long time deprecated idea | 16:36 | |
| moritz | Coke: that's what I tried | ||
| Coke: but it does seem to get invoked with the 'new' opcode | |||
| Coke | *boggle* | 16:37 | |
| moritz | oh, and this class uses P6metaclass | ||
| don't know if that makes any difference | |||
| NotFound | docs/compiler_faq.pod, line 505 | ||
| "Or you can specify the constructor method by setting the BUILD property of the class PMC:" | 16:38 | ||
|
16:39
iblechbot joined
|
|||
| Coke | moritz: unfortunately, I have no idea how p6metaclass works. =-) | 16:40 | |
| do you have sample code that shows new ['foo'] invoking the 'new' method? | |||
|
16:49
chromatic joined
17:03
kjeldahl_ joined
|
|||
| whiteknight | hello chromatic | 17:24 | |
| chromatic | morning/afternoon | 17:26 | |
| whiteknight | chromatic: did pluggable runcores ever get implemented? | 17:32 | |
| I remember some talk about it, don't remember the verdict or outcome | |||
| I certainly don't see any examples, if it is possible | 17:33 | ||
| chromatic | They're indeed pluggable, but we never made them dynamically loadable. | ||
| whiteknight | okay | 17:34 | |
| cotto_work | They also can't register runcore-specific CLI options. | ||
| whiteknight | cotto_work: what do you mean by that? | ||
| chromatic | Suppose you want the profiling output to write to a given filename. | 17:35 | |
| cotto_work | If you want to configure a runcore, you have to use a hard-coded CLI option or something like an environment variable. | ||
| whiteknight | ok | 17:36 | |
| what if we used a built-in compounded option, like --runcore-args="foo,bar,baz" | 17:40 | ||
| cotto_work | That could work. We could pretty easily make it use the name of the runcore so that --profililng="foo=bar,buz=biz" would just pass those options to the right runcore or freak out if the runcore didn't exist. | 17:42 | |
| What's your interest in pluggable runcores? | 17:43 | ||
| Coke | chromatic: TT #1489 is unresolved for me on feather, even with r45179 | 17:45 | |
| dalek? | |||
| purl | dalek is #parrot's spammy little rss bot or (see: dalek plugins) | ||
| dalek | rrot: r45180 | chromatic++ | trunk/src/pmc/eval.pmc: [PMC] Made Eval PMC destroy its contained PackFile_Segment. This fixes a |
17:46 | |
| purl | memory leak is blogs.sun.com/roller/page/kto?entry...of_leaking or blog.jrock.us/articles/Plugging%20a...0whale.pod | ||
| rrot: r45181 | chromatic++ | trunk/compilers/imcc/parser_util.c: [IMCC] Made imcc_compile() free the generated PackFile if a compilation error |
|||
| chromatic | Coke, r45181 should help, but I think we have to clean up compact_pool for the big benefits. | ||
| Coke | I'm still confused as to how it can panic if ulimit -m is "unlimited" | 17:47 | |
| chromatic | "unlimited" means "There's no *software* limit" | 17:49 | |
| Coke | er, and there seems to be plenty of swap left. I'm wondering if there is a per-process OS limit. | 17:52 | |
| (but if ulimit doesn't snow me that, what does?) | |||
|
17:55
darbelo joined
|
|||
| dalek | rrot: r45182 | NotFound++ | trunk/compilers/imcc/parser_util.c: [cage] add a cast to make c++ happy |
18:02 | |
| TT #1129 closed by coke++: segfault in clone_key_arg (due to pcc refactor) | 18:03 | ||
| TT #1129: trac.parrot.org/parrot/ticket/1129 | |||
|
18:08
dukeleto joined
|
|||
| dukeleto | 'ello | 18:08 | |
| whiteknight | hello duke | 18:09 | |
|
18:17
lucian joined
18:39
clinton joined
18:58
payload joined
|
|||
| dalek | rrot: r45183 | chromatic++ | trunk/src/multidispatch.c: [mmd] Fixed still another Parrot_pcc_split_signature_string() memory leak. |
19:09 | |
|
19:13
bacek joined
|
|||
| cotto_work | hio bacek | 19:27 | |
| bacek | Morning cotto | 19:28 | |
| sorear | Coke: ulimit -m is maximum residency; it never causes allocations to fail, instead it causes them to hit swap earlier | 19:29 | |
| Coke: you want ulimit -v, or maybe -d | |||
| dalek | kudo: 9a4cabb | chromatic++ | src/ (2 files): [ops] Moved P6LowLevelSig initialization to the PMC out of allocate_signature |
19:30 | |
| sorear | Coke: also, allocations will fail if the space of possible pointer values is exhausted. This happens after 1-3 GB on most x86 OSes, since the kernel lives in the same address space as user code. Beware of fragmentation if large allocations are being made | ||
| Coke | sorear: $ ulimit -v | 19:36 | |
| 524288 | |||
| that looks damning. =-) | 19:37 | ||
| moritz | you need twice as much for building rakudo | ||
| just tried with 0.9G => no chance | |||
| (on an amd64 machine) | |||
| Coke | I don't seem to be overriding -v on feather. | ||
|
19:38
fperrad joined
|
|||
| moritz | I can't even ssh to feather1 right now | 19:39 | |
| port 22: Connection refused | |||
| Coke | I just hit feather. | ||
| (same box) | 19:40 | ||
| moritz | feather2 and 3 work for me | ||
| PerlJam | feather1 doesn't like you | 19:41 | |
| moritz | ah, works now | ||
|
20:05
joeri joined
20:08
dukeleto joined
20:11
perlpilot joined
20:15
Util joined
20:17
PerlJam joined,
mikehh joined
20:31
allison joined
|
|||
| dukeleto | so how do we make progess on rakudo's memory problems? | 20:36 | |
| moritz | dukeleto: so far chromatic++ has thrown his awesome wizardry at the problem | 20:37 | |
| dukeleto | moritz: good to hear | ||
| moritz | dukeleto: and reduced the memory footprint during compilation by at least a factor of 1.5 | ||
| NotFound | chromatic++ | 20:38 | |
| dukeleto | chromatic++ | ||
| chromatic | I'm trying to fix memory leaks in Rakudo PMCs now, but I'm not getting their debugging symbols in Valgrind output. | ||
| moritz | afaict rakudo should just use parrot's compiler options | 20:40 | |
| chromatic | ==25876== 424 bytes in 37 blocks are definitely lost in loss record 26 of 26 | ||
| ==25876== at 0x4006F5B: calloc (vg_replace_malloc.c:418) | |||
| ==25876== by 0x40AE75B: mem_sys_allocate_zeroed (alloc_memory.c:114) | |||
| ==25876== by 0x435457E: ??? | |||
| ==25876== by 0x43565FF: ??? | |||
| ==25876== by 0x4014F5E: Parrot_invokecc_p (core.ops:385) | |||
| If I could figure out what those ??? are.... | 20:42 | ||
| perlpilot | those pesky ??? functions are hard to find | ||
| chromatic | Let's see if Callgrind/Kcachegrind help. | 20:43 | |
| tewk | chromatic, run valgrind with gdb and gdb will tell you the addresses shared libraries are loaded at. that + nm should help you find actual functions | 20:44 | |
| I'm surprised valgrind can't find symbols, is the rakudo .so stripped? | 20:45 | ||
| chromatic | --db-attach=yes? | ||
| Coke | it is possible that recent changes to config/auto/warnings.pm might be responsible for that. | ||
| s/to/related to/ | |||
| Coke checks rakudo... | |||
| chromatic | tewk, it may be that it doesn't know where to find perl6_group.so | ||
| I don't see a line for "reading syms for...." | 20:46 | ||
| Coke | this shouldn't matter, but @optimize@ might need to be added in now to the Mak.in | ||
| nopaste | "bacek" at 114.73.4.225 pasted "Top count of objects during compilation of Rakudo's core.pm" (9 lines) at nopaste.snit.ch/20095 | 20:47 | |
| bacek | about one million of PMC arrays. | 20:49 | |
| 230000 hashes | |||
| particle | many used for pcc, i suppose | ||
| chromatic | Probably a lot of Captures. | 20:50 | |
| bacek | 245000 | ||
| particle | and NameSpace | ||
| purl | well, NameSpace is the internal namespace for things like $c->forward and template paths, anyway or hll:X::Y, but yes. | ||
| bacek | 74 and 76 are Integer and String | ||
| Coke | how much of that is "can't use non-pmcs for attrs" | 20:51 | |
| bacek | particle, nope. | ||
| Coke, ? | |||
| purl | it has been said that Coke, is that an error message that you saw? | ||
| particle | bacek: doesn't NameSpace has-a Hash? | ||
| particle needs to check the source to verify what that relationship is now | 20:52 | ||
|
20:53
dalek joined
|
|||
| dalek | rrot: r45184 | mikehh++ | trunk/runtime/parrot/library/distutils.pir: fix codetest failure - pod syntax |
20:53 | |
| bacek | particle, yes. But there is not so many NameSpaces during compilation | ||
| perlpilot | bacek: what are the other classes? | 20:55 | |
| purl | the other classes are in the same directory. | ||
| bacek | perlpilot, dunno. Other counts are less than 10000. | 20:56 | |
| Coke | bacek: It's my understand that your pmc has an attribute that is an int, it must be an Integer. | ||
| particle | look at ...what's that pasm file? runtime/parrot/include/???.pasm for the other pmc#->pmcname | ||
| bacek | Coke, ah... Probably yes | ||
| Coke | (so this forces a lot of pmc_news that wouldn't otherwise have to happen.) | ||
| bacek | particle, include/parrot/core_pmcs.h | 20:57 | |
| particle | well, that'll do, too | ||
| bacek | So. About 2M PMCs allocated. | 20:59 | |
| every PMC is 20 bytes. | 21:00 | ||
| (on 32 bits) | |||
| chromatic | A lot of those get recycled though. | ||
| bacek | chromatic, it's live set | ||
|
21:01
plobsing joined,
ash_ joined
|
|||
| bacek | 40 megabytes for headers. For integer arrays, let say, 100 bytes per array. | 21:02 | |
| another 50 MB | 21:03 | ||
| PMC arrays: 500000 * 100 - another 50 MB | 21:04 | ||
| something wrong with my assumptions... | 21:05 | ||
| Ah, no. | |||
| There is 250MB of strings. | |||
| dukeleto | it seems that Parrot_ResizablePMCArray_push_string is only ever mentioned in resizablepmcarray.pmc, and not in any header file, so us lowly embedders can't get at it from C. Is this a hole in the API? | ||
| cotto_work | Woohoo! We have another prospective gsoc student. | ||
| moritz | cotto_work: do you mean ash_? | 21:06 | |
| bacek | So, live set should be around 500MB. | ||
| dukeleto, VTABLE_push_string | |||
| cotto_work | moritz, yes | ||
| oh. He's here. Hi ash_ | |||
| ash_ | hi | ||
| dukeleto | bacek: are embedders supposed to call VTABLE_* functions? can you give an example nopaste? | ||
| bacek | dukeleto, yes. VTABLE_push_string(interp, pmc); | 21:07 | |
| dukeleto | bacek: thanks! | ||
|
21:07
theory joined
21:09
tcurtis joined
|
|||
| darbelo | bacek: doesn't push_string() take a STRING? | 21:09 | |
| dalek | rrot: r45185 | petdance++ | trunk/src/gc (3 files): fixing more consts and ARGxx() macros |
||
| darbelo | VTABLE_push_string(interp, pmc, str); | ||
| plobsing | what about Parrot_PMC_push_* in src/extend.c? | ||
| chromatic | I think those are the blessed ones to use, yes. | 21:10 | |
| plobsing | I notice that Parrot_PMC_push_string is documented but does not exist ATM | ||
| dukeleto | plobsing: yes, just saw that | 21:12 | |
| plobsing | I'm adding it as we speak | ||
| dukeleto | plobsing++ # you rock | ||
| ash_: your LLVM gsoc proposal sounds exciting | 21:14 | ||
| plobsing | yeah, +1 | ||
| ash_ | should I add more goals for the deliverables timeline? | 21:15 | |
| i don't know exactly how to describe the project in smaller chunks :P | |||
| dukeleto | ash_: yes, add more goals. you can always fiddle/rearrange the timeline later | 21:16 | |
| ash_: Work on a JIT compiled system for x86, x86_64, PPC, and PPC64 architectures. <-- needs to be split up | |||
| moritz | ash_: and add times for some goals | ||
| dukeleto | ash_: which arch will you do first? which are most important? you might not be able to do all during the summer | ||
| moritz | (it doesn't matter much if you miss them later on) | ||
| so maybe write something like week 1-2: configure steps for building parrot with llvm support | 21:17 | ||
| ash_ | well, when you construct a module, you can choose the execution engine, which is either the default one, which compiles down to native code, or the JIT Execution engine, which doesn't directly end up being native code, but the modules leading up to the execution engine are interchangeable | ||
| moritz | week 3-4: initial infrastructure; calling the simplest function should now work on one architecture | 21:18 | |
| etc. | |||
| then later on refinements, more architecture | |||
|
21:18
davidfetter joined
|
|||
| moritz | it just looks much more professional if you have a timem line | 21:18 | |
| ash_ | moritz: got ya, i'll try to break that out into a more detailed explanation | ||
| moritz | and it shows that you have really thought about what's necessary for such a project | ||
| great. /me shuts up now :-) | 21:19 | ||
| ash_ | any other comments would be useful | ||
| plobsing | I'm kind of confused by the AoT frame builder deliverable. We already sort of have one - nci_thunk_gen. Unless you mean some kind of persistent cache of JITed thunks. | ||
| Also, if you're feeling ambitious, our call-in (as opposed to call-out) NCI system is pretty much a joke at this point. | 21:20 | ||
| dukeleto | ash_: just list out each week of gsoc and what you think you will be working on in each week | ||
| ash_ | yeah, thats one of the area's where parrot overlaps with llvm functionality, i was going to have | ||
| dukeleto | ash_: that will of course change once you start working, but having a solid plan always helps when you have to change your plan :) | 21:21 | |
| ash_ | the llvm has its own bytecode format, and all, so i was going to have the AoT compiler dump the llvm specific ones, instead of the parrot ones, so you could use the lli to run the code instead of parrot | ||
| and the llvm integrates with libffi, so its possible to do NCI stuff directly from llvm | 21:22 | ||
|
21:22
eternaleye joined
|
|||
| ash_ | dukeleto: sure, i'll try to write out each week, as best i can estimate | 21:22 | |
| plobsing | wait, are we talking about a frame builder or a full out Parrot->LLVM translation system? | ||
| ash_ | well, a frame builder, but I should be able to dump the stack frame and link against the parrot libraries, as imported libs, i think | 21:23 | |
| i don't see why that wouldn't work, but that is kinda a far off goal for the end, to dump the IR form of the stack frame, that shouldn't be difficult | 21:24 | ||
| perlpilot | where are the gsoc proposals? | ||
| moritz | perlpilot: parrot-dev mailing list | 21:25 | |
| ash_ | i sent mine to the parrot-dev mailing list | ||
| perlpilot | danke | ||
| cotto_work | That's an unofficial proposal, right? istr that proposals won't be accepted officially until the 30th +/-. | ||
| (not that it matters a great deal) | |||
| perlpilot | yeah, this is the "discuss with mentoring org" time right now | 21:26 | |
| actual application period starts March 29 | |||
| ash_ | socghop.appspot.com/document/show/g...0/timeline has the 2010 timeline if your curious | 21:27 | |
|
21:27
GodFather joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32847), fulltest) at r45184 - Ubuntu 9.10 amd64 (g++ with --optimize) | 21:27 | |
|
21:28
Whiteknight joined
21:30
eternaleye joined
|
|||
| ttbot | Parrot trunk/ r45186 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/239748.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) | 21:32 | |
| dukeleto | ash_: you are doing great by submitting your proposal to the list and discussing it on irc. keep up the good work | ||
| plobsing: src/extend_vtable.o: In function `Parrot_PMC_push_string': | |||
| /home/jurosz/tt2-tapir2/client-data/Parrot-trunk-temp/src/extend_vtable.c:2584: multiple definition of `Parrot_PMC_push_string' | |||
| src/extend.o:/home/jurosz/tt2-tapir2/client-data/Parrot-trunk-temp/src/extend.c:879: first defined here | 21:33 | ||
| Whiteknight | dukeleto: is the parrot-dev list the correct forum for those submissions? | 21:34 | |
| If so, I have a response for ash_ that needs sending | |||
| japhb | Coke, I'm a bit lagged on email and just came across your comment that "some parrot memory issues [...] were recently fixed". What got fixed, and how much of an improvement did it make? | 21:35 | |
| ash_ | I am here if you want to talk here, or i could join #soc-help | ||
| plobsing | dukeleto: wtf. how did that compile on my machine? | 21:37 | |
| Whiteknight | ash_: okay, talk here it is | ||
| ash_: My first concern is that this project isn't enough to fill a whole summer | 21:38 | ||
| dukeleto | plobsing: did you do a realclean? | ||
| plobsing | hmmm... no | ||
| Whiteknight | ash_: What I would really like to see (and you are going to need to have anyway) is a clear timeline for what you are planning to do and when | ||
| ash_ | yeah, i have heard i need to put more detail into the stack frame builder | 21:39 | |
| Whiteknight | ash_: so if you have 8 weeks worth of work in your timeline, that should be clear, and if there is extra time, you may need to pad out your plan | ||
| plobsing | second wtf: why do we have functions in src/extend.c that basically duplicate (with slightly different names) functions in src/extend_vtable.c | ||
| dukeleto | Whiteknight: i think ash_ is working on setting down what will be done each week of gsoc | ||
| Whiteknight | dukeleto: yeah, and that would be perfect | ||
| dukeleto | plobsing: yeah, got no clue about that | ||
| Whiteknight | I'm just having a hard time seeing how it would take 8 weeks to do it, but I may be over simplifiying or missing some details | ||
| plobsing | dukeleto: I think they're ripe for deprecation | ||
| dukeleto | Whiteknight: we have been berating ash_ with questions and clarifications, if you backlog the 20 mins before you just joined :) | ||
| Whiteknight | dukeleto: backlog!?! But I want to say my criticisms now! | 21:40 | |
| Whiteknight goes off to backlog :) | |||
| dalek | rrot: r45186 | plobsing++ | trunk (2 files): add Parrot_PMC_push_string |
21:42 | |
|
21:43
payload joined
|
|||
| Whiteknight | It's my understanding that LLVM takes care of all the cross-platform nonsense | 21:44 | |
| so ash_ won't have to work on one platform at a time | |||
| Austin | And if you believe that .... | 21:45 | |
| ash_ | LLVM does do some cross-platform stuff, but its only 'well supported' on x86, x86-64, PPC, and PPC64 | ||
| it works on others, but they aren't extensively tested | |||
| plobsing | does parrot explicitly support any platforms not in that list? | ||
| cotto_work | sparc | 21:46 | |
| dukeleto | plobsing: where is the list of parrot supported platforms? I have heard of what OS's we support, but not the platforms | ||
| Austin | Parrot's goal is to support every platform on which it is possible to perform binary arithmetic. | ||
| If there is a sufficiently complex analog wristwatch out there somewhere, parrot will support it. | 21:47 | ||
| cotto_work | arm and alpha are on the extra platforms list | ||
| Austin, especially if it's an embedded device running inside a stuffed parrot. | 21:48 | ||
| dukeleto | cotto_work: yes! I am gonna put my embedded linux gadget inside of a stuffed parrot now | ||
| darbelo | dukeleto: Off-hand I know of x86 amd64 sparc (or was it sparc64?) and arm | ||
| dukeleto | where is this list of platforms described? | ||
| ash_ | llvm.org/Features.html has a supported platform, but I have seen on their mailing list and a few other places they say that some platform support is not as well tested as those 4 i listed | ||
| Austin | Ever since they implemented IP over bongo drums, the support requirements have been growing.. | 21:49 | |
| cotto_work | dukeleto, PLATFORMS in svn root | ||
| ash_ | s/has a/has a list/ | ||
| dukeleto | cotto_work: duh. thanks | 21:50 | |
| cotto_work | which we should be updating now that a supported release is coming up | ||
| s/we/people with interesting platforms/ | 21:51 | ||
| NotFound | I've built parrot for Maemo, but I don't think my build can qualify as 'supported' | 21:56 | |
| dalek | rrot: r45187 | plobsing++ | trunk (2 files): revert r45186 |
21:57 | |
| ash_ | plobsing: where there any major problems with your libjit stack frame builder? | 21:58 | |
|
21:58
iblechbot joined
|
|||
| plobsing | ash_: a couple | 21:59 | |
| purl | i think a couple is attending an Art exhibit and they are looking at a portrait that has them a little taken aback. The picture depicts 3 very black, very naked men sitting on a park bench; 2 have a black penis and the one in the middle has a pink penis. | ||
| ash_ | purl is special, just thought i'd say that... | 22:00 | |
| plobsing | 1) NCI generated old PCC signatures. It still does in trunk. I intend to fix that soon (before any gsoc student tries to make a frame builder) | ||
| 2) a return value sign-extension bug in libjit. | 22:01 | ||
| that's about it. I kind of got distracted by the zillion other things that Parrot needs | 22:02 | ||
| ash_ | alright, thanks, i am going to look at all of whats involved with the stack frame builder and flush out my timeline more | 22:04 | |
| dalek | kudo: db9c0ea | chromatic++ | src/pmc/perl6multisub.pmc: [PMC] Fixed a memory leak in Perl6MultiSub of candidate constraints and types. |
22:06 | |
| kudo: 4b7dbf3 | chromatic++ | src/pmc/perl6multisub.pmc: [PMC] Tidied code in Perl6MultiSub PMC; no functional changes. |
|||
| cotto_work | :q | 22:08 | |
| dukeleto | purl, forget a couple | ||
| purl | dukeleto: I forgot couple | ||
| plobsing | why is Parrot_VTABLE part of the API? | 22:09 | |
| it seems very very wrong | |||
| Whiteknight | plobsing: yeah, it's easy to get distracted by all the millions of things Parrot needs | 22:11 | |
| at least we're never bored! | |||
| plobsing | specifically, why should an embedder or an extender be able to Parrot_PMC_set_vtable? | ||
| Whiteknight | vtable overrides for custom classes? | 22:12 | |
| I don't even know what that function is | |||
| Oh, wait. Dynpmcs | |||
| plobsing | Whiteknight: the api doesn't let you modify VTABLES. they are opaque to that API. | 22:14 | |
| all you can do is get a type's vtable and set a pmc's vtable | |||
| which is basically only usable as an awkward and error prone way of type-casting AFAICT | 22:15 | ||
| dalek | rrot: r45188 | plobsing++ | trunk/DEPRECATED.pod: deprecate duplicate vtable-calling functions in src/extend.c |
||
| cotto_work | plobsing, make sure you file a ticket for those deprecations | 22:24 | |
| I doubt they'll be controversial but it's good to have a designated place for discussion. | 22:25 | ||
| plobsing | cotto_work++ sure thing. thanks for the reminder | ||
| dalek | rrot: r45189 | plobsing++ | trunk/DEPRECATED.pod: deprecate Parrot_VTABLE can be revived later to provide legitimate functionality |
22:32 | |
| TT #1530 created by plobsing++: [DEPRECATION] Parrot_PMC_* in src/extend.c | 22:34 | ||
| TT #1530: trac.parrot.org/parrot/ticket/1530 | |||
| nxed: r440 | julian.notfound++ | trunk/examples/pirado.winxed: refactor common parts of call and return instructions in pirado |
22:35 | ||
|
22:46
riffraff joined
|
|||
| dalek | TT #1531 created by plobsing++: [DEPRECATION] Parrot_VTABLE | 22:50 | |
| TT #1531: trac.parrot.org/parrot/ticket/1531 | |||
| Coke | plobsing: I'm looking at 1531 - what is Parrot_VTABLE? | 23:14 | |
| plobsing | it's an opaque pointer | ||
| representing a VTABLE | |||
| Coke | japhb: if I knew that, I would have put it in the ticket. | ||
| s/ticket/reply/ | |||
| plobsing | --This line, and those below, will be ignored-- | ||
| M src/extend.c | 23:15 | ||
| M include/parrot/extend.h | |||
| japhb | Coke, sorry, thought you were referring to something "well known" that I just missed. | ||
| plobsing | sorry, unintended paste | ||
| cotto_work | That's what they all say. | ||
| Coke | japhb: random fixes chromatic has done. | 23:16 | |
| japhb | Ah, fair enough. | ||
| Are we down at the level that Rakudo will compile in under a GB of RAM? | 23:17 | ||
| Coke | Iunno. | 23:18 | |
| japhb is doing a recompile himself | |||
| japhb gets really annoyed at software/servers that can't pin his crappy DSL line | 23:19 | ||
| chromatic | 32-bit, definitely under a GB. | 23:20 | |
| japhb | Good! | ||
| japhb checking amd64 now | |||
|
23:23
ash_ joined
|
|||
| Whiteknight | chromatic++ | 23:29 | |
| chromatic | There are still plenty of leaks for anyone who wants to run some of the PIR tests. In particular, PackFiles aren't yet clean. | 23:32 | |
| cotto_work | Yay for leaks! Moreso for fixing them. | 23:33 | |
| chromatic | That said, I still don't trust compact_pool. | 23:34 | |
|
23:40
cognominal joined
23:43
tcurtis joined
|
|||
| japhb | The peak values that I saw in top while compiling Rakudo's src/gen/core.pm on amd64 is 980m VIRT and 867m RES. That's about 600-700 MB smaller than a few days ago. | 23:50 | |