Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-25

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 snarkyboojum joined #parrot
00:07 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32824), fulltest) at r45165 - Ubuntu 9.10 amd64 (g++ with --optimize)
00:08 kid51 mikehh:  In trunk, I am getting failures in 'make buildtools_tests':  specifically, tests t/tools/ops2pm/09 thru 11.
00:09 kid51 mikehh:  These failures disappear when I call 'make opsrenumber'
00:09 kid51 mikehh:  Can you confirm this?  Thanks.
00:10 kid51 These tests passed at r 45048 but were failing by r45106
00:14 dalek parrot: r45166 | petdance++ | trunk/src/gc (3 files):
00:14 dalek parrot: more const correctness in GC land
00:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45166/
00:14 dalek rakudo: dfbd1d5 | jonathan++ | src/Perl6/Grammar.pm:
00:14 dalek rakudo: 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.
00:14 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​fbd1d5e707765c5d853710592b98e724e828193
00:15 mikehh kid51: yes 9-11 fail with op set_result_info_p: sequence mismatch: ops.num 227 vs. core.ops 1250
00:16 mikehh kid51: never run those test before - what else am I missing
00:19 mikehh kid51: and yes they pass after make opsrenumber
00:19 kid51 They were formerly part of perl Configure.pl --test
00:19 kid51 But there were objections, so we moved them to run post make, on a voluntary basis.
00:19 kid51 Am bisecting now
00:20 Essobi joined #parrot
00:24 riffraff joined #parrot
00:25 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?
00:26 dalek rakudo: e673638 | jonathan++ | src/pmc/perl6multisub.pmc:
00:26 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​673638b9ac925586ffd2e5c569febc07b551d2d
00:26 kid51 It's a kind of obscure requirement.
00:26 sorear Well, I thought I ran 'make test'
00:27 kid51 You did, no doubt.  This is not included in 'make test'.
00:27 kid51 And since we don't add/subtrace ops codes very often, it's quite possible that plobsing didn't know this requirement either.
00:27 kid51 Don't lose any sleep over this.
00:27 kid51 But do do 'make realclean' and reconfigure and rebuild.
00:28 sorear That would have caught this?
00:28 * sorear did not know about 'make realclean'
00:28 kid51 'make realclean' removes all files generated by Configure.pl as well as all those generated by 'make'
00:29 mikehh kid51: these tests should then be part of fulltest
00:29 Coke +1. fulltest can be slow and thorough.
00:29 kid51 So, any time we change what gets generated in the Makefile(s) -- which is relatively often -- you need to make realclean and reconfigure
00:30 kid51 Coke:  No disagreement from me there :-)
00:30 * kid51 edits config/gen/makefiles/root.in
00:31 kid51 Does anyone have a preference as to where in the sequence of tests in 'make fulltest' this should sit?
00:31 kid51 (After run_tests seems good to me)
00:32 dalek parrot: r45167 | jkeenan++ | trunk (2 files):
00:32 dalek parrot: At r45089, ops codes were added but 'make opsrenumber' was not run.  Doing so now and committing result.
00:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45167/
00:34 * kid51 does 'make fulltest' with buildtools_tests included
00:37 kid51 'make fulltest' being thorough and .... slow, kid51 wanders off in search of beer
00:41 mikehh I run it with TEST_JOBS=40 which cuts the time down considerably, but NOT -j as this causes conflicts
00:42 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 kid51 besides, computer programs ought to allow time for beer
00:44 chromatic Parallel testing should help IO-bound tests, even if you don't have a multicore machine.
00:45 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
00:46 mikehh sorry that's 940
00:49 dalek parrot: r45168 | petdance++ | trunk (5 files):
00:49 dalek parrot: more const correctness and dropping of unused args
00:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45168/
00:54 abqar joined #parrot
00:59 theory joined #parrot
01:05 dalek parrot: r45169 | jkeenan++ | trunk/config/gen/makefiles/root.in:
01:05 dalek parrot: Per suggestion from mikehh++ and Coke++, add 'buildtools_tests' to 'make fulltest' targets.
01:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45169/
01:05 dalek parrot: r45170 | jkeenan++ | trunk/MANIFEST.SKIP:
01:05 dalek parrot: Needed to regenerate SKIP after changing a directory's svn:ignore properties.
01:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45170/
01:08 hercynium joined #parrot
01:21 dalek parrot: r45171 | mikehh++ | trunk/src/gc/gc_ms.c:
01:21 dalek parrot: fix codetest failure - there should be one space or a newline after a comma
01:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45171/
01:25 allison I've got a segfault on Ubuntu karmic compiling PGE
01:25 allison recent? known?
01:26 chromatic Everything was fine for me as of r45163.
01:31 dalek rakudo: 99c4bcf | jonathan++ | src/ops/perl6.ops:
01:31 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​9c4bcf9eb8fcdf42da5a100c750fe6ec2998921
01:31 dalek rakudo: 626ee20 | jonathan++ | build/PARROT_REVISION:
01:31 dalek rakudo: Bump us up to the latest Parrot version to get memory leak fixes by (Parrot team)++.
01:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​26ee2080dfe571e6492384ca7510af6542925ce
01:38 allison a double realclean seems to clear it on one box, trying the other
01:55 patspam joined #parrot
01:58 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 Mokurai1 joined #parrot
02:04 chromatic ... and there's another memory leak fixed.
02:12 dalek joined #parrot
02:15 cotto joined #parrot
02:16 khai joined #parrot
02:23 bubaflub joined #parrot
02:30 eternaleye joined #parrot
02:44 dalek joined #parrot
03:00 ekiru joined #parrot
03:31 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:34 Coke moment.
03:36 Coke ekiru: fixed in svn.
03:38 dalek parrot: r45172 | coke++ | trunk/docs/intro.pod:
03:38 dalek parrot: sync snippet with main source,  thanks to ekiru++
03:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45172/
03:48 Andy joined #parrot
04:12 janus joined #parrot
04:35 tcurtis joined #parrot
05:00 dalek parrot: r45173 | cotto++ | branches/profiling_testing​/t/profiling/profiling.t:
05:00 dalek parrot: [profiling] add some more profiling test cases
05:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45173/
05:00 sorear joined #parrot
05:30 cotto What's a nice phrase for "skip to the next foo"?
05:32 cotto or "this is the next foo"
05:38 allison keywords, or descriptive phrases?
05:39 allison "following"
05:40 allison keywords: hard to beat "next"
05:40 sorear subsequent
05:43 allison "succeeding"
05:46 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:47 sorear nextsame;
05:56 ruoso joined #parrot
05:57 cotto It's an interesting exercise to make something intuitive and obvious.
06:00 Util joined #parrot
06:08 cotto night
07:10 uniejo joined #parrot
07:19 dalek parrot: r45174 | chromatic++ | trunk/src/embed.c:
07:19 dalek parrot: [src] Fixed a compilation warning about an unused return value in
07:19 dalek parrot: Parrot_compile_string().
07:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45174/
07:19 dalek parrot: r45175 | chromatic++ | trunk/src/packfile.c:
07:20 dalek parrot: [src] Fixed a memory leak in pf_debug_new(), where creating a Debug PackFile
07:20 dalek parrot: allocated debug mappings which get overwritten unilaterally later.  Not
07:20 dalek parrot: creating them here avoids that.
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45175/
07:20 dalek parrot: r45176 | chromatic++ | trunk/src/pmc/imageio.pmc:
07:20 dalek parrot: [PMC] Tidied code in ImageIO PMC, and NULLed out the freed PackFile in its
07:20 dalek parrot: destroy vtable.
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45176/
07:20 dalek parrot: r45177 | chromatic++ | trunk/src/packfile.c:
07:20 dalek parrot: [src] Fixed a long-standing memory leak of where directories appended to other
07:20 dalek parrot: PackFiles.
07:20 purl packfiles are the representation of bytecode.
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45177/
07:20 dalek parrot: r45178 | chromatic++ | trunk/src/extend.c:
07:20 dalek parrot: [src] Fixed yet another Parrot_pcc_split_signature_string() memory leak.  I
07:20 dalek parrot: won't miss this difficult-to-use-correctly function when it disappears.
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45178/
07:20 moritz chromatic++
07:21 dalek rakudo: 633c096 | moritz++ | t/spectest.data:
07:21 dalek rakudo: run the new S12-class/stubs.t
07:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​33c0963e6651cb06521c0e5f1ba4019bc345739
07:22 chromatic There are still some leaks, but I don't know if they're Parrot or Rakudo at this point.
07:23 sorear yay
07:23 jhelwig joined #parrot
07:23 sorear purl, ignore dalek
07:23 purl sorear: excuse me?
07:25 moritz chromatic: at least rakudo now builds again in a ulimit of 1G virtual memory
07:25 moritz chromatic: so it brought at least an improvement of factor 1.5
07:26 chromatic I think one of the Rakudo ops leaks too.
07:27 sorear I'm suprised it's this easy.
07:27 chromatic allocate_signature, perhaps.
07:27 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
07:28 chromatic I suspect those also exist.
07:29 moritz the compilation to PAST nodes keeps the complete match tree around
07:29 moritz although it really would just need the source string + position information
07:30 moritz it uses :node($/) for convenience
07:30 chromatic ... and there's one leak in Rakudo.
07:38 dalek rakudo: 5ab33a1 | chromatic++ | src/pmc/p6lowlevelsig.pmc:
07:38 dalek rakudo: [PMC] Fixed a memory leak in P6LowLevelSig PMC's destroy.  Note that the
07:38 dalek rakudo: allocation in the allocate_signature dynop should move into the init_int
07:38 dalek rakudo: VTABLE, to make such leaks easier to track.
07:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​ab33a198b50798ed4a4a4f5026a880b93110316
07:38 dalek rakudo: 1828116 | chromatic++ | t/spectest.data:
07:38 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
07:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​82811610abd7b1a5e87b9b8e1450e4b6a0a4874
07:49 iblechbot joined #parrot
07:55 dalek rakudo: 0afbf11 | moritz++ | build/PARROT_REVISION:
07:55 dalek rakudo: bump PARROT_REVISION again to get more memory fixes in parrot, chromatic++
07:55 dalek rakudo: Now rakudo compiles again with a ulimit -v of 1G.
07:55 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​afbf1105c6252e8797cc8b6e8b67241cbd88f21
07:59 snarkyboojum joined #parrot
08:07 riffraff joined #parrot
08:13 * sorear wonders what to call a Parrot SNOBOL4
08:24 silug joined #parrot
08:30 bacek joined #parrot
08:30 bacek o hai
08:35 Austin sorear: In english, "ps" is a valid dipthong.
08:35 Austin So: psnobol
08:35 Austin Or maybe "perl 0.1"
08:35 Austin err.  0.4
08:39 sorear no, no, not Perl
08:39 sorear SNOBOL, despite its application domain, is actually one of the least Perl-like practical dynamic languages ever invented
08:39 sorear which is why I want to implement it on Parrot
08:39 sorear as a test of our flexibility
08:40 nopaste "Austin" at 68.39.12.202 pasted "Sorted list of tickets, for whiteknight++" (63 lines) at http://nopaste.snit.ch/20077
08:40 Austin msg whiteknight I've made that sorted list of my open tickets per your request. See  http://nopaste.snit.ch/20077
08:40 purl Message for whiteknight stored.
08:41 Austin sorear: Snobol is all about strings and patterns, and has a bizarre syntax hostile to all human life.
08:41 Austin How is that not like perl?
08:41 wagle_ joined #parrot
08:43 dalek rakudo: a93b9a5 | moritz++ | t/spectest.data:
08:43 dalek rakudo: we now pass assign.t again, including some tests for different precdence of item and list assignment
08:43 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​93b9a5e9d00509357ae37025253114f21f1d694
08:43 sorear perl doesn't have failure continuations or completely unrestricted go to or dynamically scoped macros
08:43 sorear snobol doesn't have block structure or any kind of namespacing or filehandles
08:44 sorear snobol uses tied variables for I/O
08:44 sorear and had a fully general FFI in the 60s...
08:44 sorear LOAD('SIN(REAL)REAL','MATHLIB')
08:44 sorear *EXAMPLE FROM DOCUMENTATION
09:01 snarkyboojum joined #parrot
09:05 dalek kakapo: d997e3a | austin++ | src/ (3 files):
09:05 dalek kakapo: Added find_method to Opcode.nqp.
09:05 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
09:05 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/d997e3a024614a123f0a48a4422f55a9e67a98fa
09:05 dalek kakapo: 1c9685a | austin++ |  (22 files):
09:05 dalek kakapo: 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:05 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
09:05 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/1c9685a188572b7def55c0679fd67a4edcefb188
09:31 AndyA joined #parrot
09:38 payload joined #parrot
09:51 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32828), fulltest) at r45178 - Ubuntu 9.10 amd64 (g++ with --optimize)
09:54 bacek msg mj41 Looks like TapTinder is unconscious.
09:54 purl Message for mj41 stored.
09:55 ttbot Parrot trunk/ r45177 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/238418.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
09:56 bacek erm... It's not what I mean...
10:12 mj41 bacek: There is a bug in tt client. http://github.com/mj41/TapTinder/issues/#issue/1  Starting all manually again :-(.
10:14 bacek mj41, no worries. I just want to let you know that one of my most popular page to check is "down" :)
10:39 dalek parrot: r45179 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
10:39 dalek parrot: [distutils] add smoke with harness
10:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45179/
11:27 Infinoid sorear++ # should be a good project
11:27 clinton joined #parrot
11:48 cotto joined #parrot
11:59 whiteknight joined #parrot
12:20 Coke (least perl like languages) or, you could help me with tcl.
12:20 payload joined #parrot
12:32 whiteknight good morning #parrot
12:35 lucian joined #parrot
12:37 ruoso joined #parrot
12:59 lucian_ joined #parrot
13:08 cosimo joined #parrot
13:13 khai joined #parrot
13:19 theory joined #parrot
13:28 AndyA joined #parrot
13:30 iblechbot joined #parrot
14:02 riffraff joined #parrot
14:09 Mokurai1 joined #parrot
14:16 * Austin sings, "Send lawyers, guns, and money..."
14:17 AndyA joined #parrot
14:21 whiteknight And I'm down on my luck
14:22 Austin :)
14:22 Austin Good morning, Whiteknight.
14:22 whiteknight good morning Austin
14:22 whiteknight I grew up listening to the Hank Williams Jr version of that song
14:22 Austin Heh
14:23 Austin I didn't know he had recorded it..
14:23 whiteknight I didn't know he didn't write it for a long time
14:23 Austin Youtube is my friend...
14:25 Austin Hmm...
14:25 Austin Gonna give that one a pass. I like the Zevon version better.
14:25 whiteknight you ever had that feeling that you wish a compiler could emit a "programmer is incompetent" warning?
14:25 Austin God, no!
14:25 whiteknight and then we set all warnings to become errors, and anybody who can't build a program gets fired
14:26 Austin I'm with you there.
14:28 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
14:29 Austin That's what you get for not having here-docs in your language.
14:29 whiteknight C# Has heredocs
14:29 whiteknight no excuses
14:29 whiteknight 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
14:29 whiteknight or anything else
14:29 purl i guess anything else is going to be even worse.
14:33 Coke http://www.boingboing.net/2010/​03/23/kyrgyz-computer-educ.html
14:34 whiteknight nice
14:37 Austin Kids: Everybody above me in this thread is probably at least 30 years old. :)
14:39 whiteknight I can't wait till I'm 30. That will be awesome
14:40 Austin Thirty is when you turn your negativity 180 degrees.
14:41 Austin 29: "Man, everybody older than me is such an idiot...How is that possible?"
14:41 Austin 30: "Man, everybody younger than me is so freaking dumb. How does the species survive?"
14:41 whiteknight most of the people younger than me are idiots too
14:42 whiteknight apparently, I'm dancing on the point of a needle :)
14:42 PerlJam all people are idiots until they prove themselves otherwise
14:42 whiteknight PerlJam++
14:42 PerlJam and even then people will lapse into idiocy on occasion even if they are a genius
14:43 PerlJam (and people who know grammar well can't even construct a good sentence :)
14:44 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 dalek joined #parrot
14:55 patspam joined #parrot
14:59 dalek joined #parrot
15:09 khai left #parrot
15:12 khairul joined #parrot
15:13 uniejo joined #parrot
15:37 dalek nqp-rx: becd0e9 | duff++ |  (3 files):
15:37 dalek nqp-rx: remove un-perly fatarrow extension
15:37 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/b​ecd0e9ea6541b6862cea49c93f296becb6f0585
15:43 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 whiteknight and .dll
15:45 NotFound whiteknight: 31 is worse that 30, is when "thirtysomething" starts.
15:46 whiteknight good to know. I have several years before I have to find that out
15:48 NotFound I feel young, I'm downloading firmware for NDS card :)
15:51 davidfetter joined #parrot
15:57 moritz where can I find an example of iterating a hash in PIR?
15:58 Coke t/pmc/hashiterator.t
15:59 Coke hurm. no. bad example.
15:59 NotFound moritz: $ winxed -c -e 'var a= {}; for (var b in a) say(b);' ; cat __eval__.pir
15:59 Coke try t/pmc/hash.t //iter_over_hash
16:00 moritz or even better... I have an object of a subtype of Capture (which is both an array and a hash)
16:00 moritz and I have an array and a hash
16:01 moritz and I want to fill the slots of the Capture thing from the array and the hash
16:01 moritz is there a faster way than iterating over both?
16:01 Coke not unless capture has some sort of magic method. checking.
16:01 Coke this is the parrot builtin Capture ?
16:01 moritz aye
16:02 Coke nope, I don't see any convenience methods.
16:02 moritz so  $P0 = iter my_hash  # gives me the keys, right?
16:02 Coke (and all they'd do is the iteration internally anyway, since poking into Hash's guts would be rude.)
16:02 Coke moritz: aye.
16:02 moritz Coke: thanks
16:02 Coke but for array, it gives you the values. =-)
16:03 Coke Which seems to me to be bad, forcing you to know what you're iterating over.
16:03 moritz in this case I know :-)
16:31 moritz is there an example how I can write and call constructors in PIR?
16:32 moritz pmc/object-meths.t has some simple calls to new ['Classname']
16:32 moritz but I'd need something which passes arguments
16:33 Coke I think you want the init_pmc vtable, which is invoked with:
16:33 Coke new ['Classname'], $P0
16:33 moritz so I'd write
16:33 moritz .sub 'new' :vtable('init_pmc')
16:34 moritz .param foo :named
16:34 moritz and then call that as new ['Classname'], 'foo' => 3
16:34 NotFound But his uselfuness for pir classes is limited, because it always try to initialize atributes from the $P0 keys
16:34 Coke you can't use named args there, I think.
16:35 Coke I think you'd have to explicitly pass pass a hash or other container.
16:35 Coke (since vtables ain't methods)
16:35 Coke though you could, of course, just have a method named "new" that wasn't invoked with the 'new' opcode.
16:36 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
16:36 moritz Coke: but it does seem to get invoked with the 'new' opcode
16:37 Coke *boggle*
16:37 moritz oh, and this class uses P6metaclass
16:37 moritz don't know if that makes any difference
16:37 NotFound docs/compiler_faq.pod, line 505
16:38 NotFound "Or you can specify the constructor method by setting the BUILD property of the class PMC:"
16:39 iblechbot joined #parrot
16:40 Coke moritz: unfortunately, I have no idea how p6metaclass works. =-)
16:40 Coke do you have sample code that shows new ['foo'] invoking the 'new' method?
16:49 chromatic joined #parrot
17:03 kjeldahl_ joined #parrot
17:24 whiteknight hello chromatic
17:26 chromatic morning/afternoon
17:32 whiteknight chromatic: did pluggable runcores ever get implemented?
17:32 whiteknight I remember some talk about it, don't remember the verdict or outcome
17:33 whiteknight 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.
17:34 whiteknight okay
17:34 cotto_work They also can't register runcore-specific CLI options.
17:34 whiteknight cotto_work: what do you mean by that?
17:35 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.
17:36 whiteknight ok
17:40 whiteknight what if we used a built-in compounded option, like --runcore-args="foo,bar,baz"
17:42 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:43 cotto_work What's your interest in pluggable runcores?
17:45 Coke chromatic: TT #1489 is unresolved for me on feather, even with r45179
17:45 Coke dalek?
17:45 purl dalek is #parrot's spammy little rss bot or (see: dalek plugins)
17:46 dalek parrot: r45180 | chromatic++ | trunk/src/pmc/eval.pmc:
17:46 dalek parrot: [PMC] Made Eval PMC destroy its contained PackFile_Segment.  This fixes a
17:46 dalek parrot: memory leak.
17:46 purl memory leak is http://blogs.sun.com/roller/pag​e/kto?entry=the_art_of_leaking or http://blog.jrock.us/articles/P​lugging%20a%20leaky%20whale.pod
17:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45180/
17:46 dalek parrot: r45181 | chromatic++ | trunk/compilers/imcc/parser_util.c:
17:46 dalek parrot: [IMCC] Made imcc_compile() free the generated PackFile if a compilation error
17:46 dalek parrot: occurs.  This removes a memory leak.
17:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45181/
17:46 chromatic Coke, r45181 should help, but I think we have to clean up compact_pool for the big benefits.
17:47 Coke I'm still confused as to how it can panic if ulimit -m is "unlimited"
17:49 chromatic "unlimited" means "There's no *software* limit"
17:52 Coke er, and there seems to be plenty of swap left. I'm wondering if there is a per-process OS limit.
17:52 Coke (but if ulimit doesn't snow me that, what does?)
17:55 darbelo joined #parrot
18:02 dalek parrot: r45182 | NotFound++ | trunk/compilers/imcc/parser_util.c:
18:02 dalek parrot: [cage] add a cast to make c++ happy
18:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45182/
18:03 dalek TT #1129 closed by coke++: segfault in clone_key_arg (due to pcc refactor)
18:03 dalek TT #1129: http://trac.parrot.org/parrot/ticket/1129
18:08 dukeleto joined #parrot
18:08 dukeleto 'ello
18:09 whiteknight hello duke
18:17 lucian joined #parrot
18:39 clinton joined #parrot
18:58 payload joined #parrot
19:09 dalek parrot: r45183 | chromatic++ | trunk/src/multidispatch.c:
19:09 dalek parrot: [mmd] Fixed still another Parrot_pcc_split_signature_string() memory leak.
19:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45183/
19:13 bacek joined #parrot
19:27 cotto_work hio bacek
19:28 bacek Morning cotto
19:29 sorear Coke: ulimit -m is maximum residency; it never causes allocations to fail, instead it causes them to hit swap earlier
19:29 sorear Coke: you want ulimit -v, or maybe -d
19:30 dalek rakudo: 9a4cabb | chromatic++ | src/ (2 files):
19:30 dalek rakudo: [ops] Moved P6LowLevelSig initialization to the PMC out of allocate_signature
19:30 dalek rakudo: op into the PMC itself.
19:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​a4cabb08b96e5362ea3ba5888843486e51e6812
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
19:36 Coke sorear: $ ulimit -v
19:36 Coke 524288
19:37 Coke that looks damning. =-)
19:37 moritz you need twice as much for building rakudo
19:37 moritz just tried with 0.9G => no chance
19:37 moritz (on an amd64 machine)
19:37 Coke I don't seem to be overriding -v on feather.
19:38 fperrad joined #parrot
19:39 moritz I can't even ssh to feather1 right now
19:39 moritz port 22: Connection refused
19:39 Coke I just hit feather.
19:40 Coke (same box)
19:40 moritz feather2 and 3 work for me
19:41 PerlJam feather1 doesn't like you
19:41 moritz ah, works now
20:05 joeri joined #parrot
20:08 dukeleto joined #parrot
20:11 perlpilot joined #parrot
20:15 Util joined #parrot
20:17 PerlJam joined #parrot
20:17 mikehh joined #parrot
20:31 allison joined #parrot
20:36 dukeleto so how do we make progess on rakudo's memory problems?
20:37 moritz dukeleto: so far chromatic++ has thrown his awesome wizardry at the problem
20:37 dukeleto moritz: good to hear
20:37 moritz dukeleto: and reduced the memory footprint during compilation by at least a factor of 1.5
20:38 NotFound chromatic++
20:38 dukeleto chromatic++
20:38 chromatic I'm trying to fix memory leaks in Rakudo PMCs now, but I'm not getting their debugging symbols in Valgrind output.
20:40 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
20:40 chromatic ==25876==    at 0x4006F5B: calloc (vg_replace_malloc.c:418)
20:40 chromatic ==25876==    by 0x40AE75B: mem_sys_allocate_zeroed (alloc_memory.c:114)
20:40 chromatic ==25876==    by 0x435457E: ???
20:40 chromatic ==25876==    by 0x43565FF: ???
20:40 chromatic ==25876==    by 0x4014F5E: Parrot_invokecc_p (core.ops:385)
20:42 chromatic If I could figure out what those ??? are....
20:42 perlpilot those pesky ??? functions are hard to find
20:43 chromatic Let's see if Callgrind/Kcachegrind help.
20:44 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:45 tewk I'm surprised valgrind can't find symbols, is the rakudo .so stripped?
20:45 chromatic --db-attach=yes?
20:45 Coke it is possible that recent changes to config/auto/warnings.pm might be responsible for that.
20:45 Coke s/to/related to/
20:45 * Coke checks rakudo...
20:45 chromatic tewk, it may be that it doesn't know where to find perl6_group.so
20:46 chromatic 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
20:47 nopaste "bacek" at 114.73.4.225 pasted "Top count of objects during compilation of Rakudo's core.pm" (9 lines) at http://nopaste.snit.ch/20095
20:49 bacek about one million of PMC arrays.
20:49 bacek 230000 hashes
20:49 particle many used for pcc, i suppose
20:50 chromatic Probably a lot of Captures.
20:50 bacek 245000
20:50 particle and NameSpace
20:50 purl well, NameSpace is the internal namespace for things like $c->forward and template paths, anyway or  hll:X::Y, but yes.
20:50 bacek 74 and 76 are Integer and String
20:51 Coke how much of that is "can't use non-pmcs for attrs"
20:51 bacek particle, nope.
20:51 bacek Coke, ?
20:51 purl it has been said that Coke, is that an error message that you saw?
20:51 particle bacek: doesn't NameSpace has-a Hash?
20:52 * particle needs to check the source to verify what that relationship is now
20:53 dalek joined #parrot
20:53 dalek parrot: r45184 | mikehh++ | trunk/runtime/parrot/library/distutils.pir:
20:53 dalek parrot: fix codetest failure - pod syntax
20:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45184/
20:53 bacek particle, yes. But there is not so many NameSpaces during compilation
20:55 perlpilot bacek: what are the other classes?
20:55 purl the other classes are in the same directory.
20:56 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.
20:56 particle look at ...what's that pasm file? runtime/parrot/include/???.pasm for the other pmc#->pmcname
20:56 bacek Coke, ah... Probably yes
20:56 Coke (so this forces a lot of pmc_news that wouldn't otherwise have to happen.)
20:57 bacek particle, include/parrot/core_pmcs.h
20:57 particle well, that'll do, too
20:59 bacek So. About 2M PMCs allocated.
21:00 bacek every PMC is 20 bytes.
21:00 bacek (on 32 bits)
21:00 chromatic A lot of those get recycled though.
21:00 bacek chromatic, it's live set
21:01 plobsing joined #parrot
21:01 ash_ joined #parrot
21:02 bacek 40 megabytes for headers. For integer arrays, let say, 100 bytes per array.
21:03 bacek another 50 MB
21:04 bacek PMC arrays: 500000 * 100 - another 50 MB
21:05 bacek something wrong with my assumptions...
21:05 bacek Ah, no.
21:05 bacek There is 250MB of strings.
21:05 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?
21:05 cotto_work Woohoo!  We have another prospective gsoc student.
21:06 moritz cotto_work: do you mean ash_?
21:06 bacek So, live set should be around 500MB.
21:06 bacek dukeleto, VTABLE_push_string
21:06 cotto_work moritz, yes
21:06 cotto_work oh.  He's here.  Hi ash_
21:06 ash_ hi
21:06 dukeleto bacek: are embedders supposed to call VTABLE_* functions? can you give an example nopaste?
21:07 bacek dukeleto, yes. VTABLE_push_string(interp, pmc);
21:07 dukeleto bacek: thanks!
21:07 theory joined #parrot
21:09 tcurtis joined #parrot
21:09 darbelo bacek: doesn't push_string() take a STRING?
21:09 dalek parrot: r45185 | petdance++ | trunk/src/gc (3 files):
21:09 dalek parrot: fixing more consts and ARGxx() macros
21:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45185/
21:09 darbelo VTABLE_push_string(interp, pmc, str);
21:09 plobsing what about Parrot_PMC_push_* in src/extend.c?
21:10 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
21:12 dukeleto plobsing: yes, just saw that
21:12 plobsing I'm adding it as we speak
21:12 dukeleto plobsing++ # you rock
21:14 dukeleto ash_: your LLVM gsoc proposal sounds exciting
21:14 plobsing yeah, +1
21:15 ash_ should I add more goals for the deliverables timeline?
21:15 ash_ i don't know exactly how to describe the project in smaller chunks :P
21:16 dukeleto ash_: yes, add more goals. you can always fiddle/rearrange the timeline later
21:16 dukeleto ash_: Work on a JIT compiled system for x86, x86_64, PPC, and PPC64 architectures. <-- needs to be split up
21:16 moritz ash_: and add times for some goals
21:16 dukeleto ash_: which arch will you do first? which are most important? you might not be able to do all during the summer
21:16 moritz (it doesn't matter much if you miss them later on)
21:17 moritz 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
21:18 moritz week 3-4: initial infrastructure; calling the simplest function should now work on one architecture
21:18 moritz etc.
21:18 moritz then later on refinements, more architecture
21:18 davidfetter joined #parrot
21:18 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
21:18 moritz and it shows that you have really thought about what's necessary for such a project
21:19 moritz great. /me shuts up now :-)
21:19 ash_ any other comments would be useful
21:19 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.
21:20 plobsing 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
21:20 ash_ yeah, thats one of the area's where parrot overlaps with llvm functionality, i was going to have
21:21 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
21:22 ash_ and the llvm integrates with libffi, so its possible to do NCI stuff directly from llvm
21:22 eternaleye joined #parrot
21:22 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?
21:23 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:24 ash_ 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?
21:25 moritz perlpilot: parrot-dev mailing list
21:25 ash_ i sent mine to the parrot-dev mailing list
21:25 perlpilot danke
21:25 cotto_work That's an unofficial proposal, right?  istr that proposals won't be accepted officially until the 30th +/-.
21:25 cotto_work (not that it matters a great deal)
21:26 perlpilot yeah, this is the "discuss with mentoring org"  time right now
21:26 perlpilot actual application period starts March 29
21:27 ash_ http://socghop.appspot.com/document/sho​w/gsoc_program/google/gsoc2010/timeline has the 2010 timeline if your curious
21:27 GodFather joined #parrot
21:27 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32847), fulltest) at r45184 - Ubuntu 9.10 amd64 (g++ with --optimize)
21:28 Whiteknight joined #parrot
21:30 eternaleye joined #parrot
21:32 ttbot Parrot trunk/ r45186 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/239748.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/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
21:32 dukeleto plobsing: src/extend_vtable.o: In function `Parrot_PMC_push_string':
21:32 dukeleto /home/jurosz/tt2-tapir2/client-data/Parr​ot-trunk-temp/src/extend_vtable.c:2584: multiple definition of `Parrot_PMC_push_string'
21:33 dukeleto src/extend.o:/home/jurosz/tt2-tapir2/clien​t-data/Parrot-trunk-temp/src/extend.c:879: first defined here
21:34 Whiteknight dukeleto: is the parrot-dev list the correct forum for those submissions?
21:34 Whiteknight If so, I have a response for ash_ that needs sending
21:35 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
21:37 plobsing dukeleto: wtf. how did that compile on my machine?
21:37 Whiteknight ash_: okay, talk here it is
21:38 Whiteknight 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?
21:38 plobsing hmmm... no
21:38 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
21:39 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
21:39 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
21:39 dukeleto Whiteknight: i think ash_ is working on setting down what will be done each week of gsoc
21:39 Whiteknight dukeleto: yeah, and that would be perfect
21:39 dukeleto plobsing: yeah, got no clue about that
21:39 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
21:39 plobsing dukeleto: I think they're ripe for deprecation
21:39 dukeleto Whiteknight: we have been berating ash_ with questions and clarifications, if you backlog the 20 mins before you just joined :)
21:40 Whiteknight dukeleto: backlog!?! But I want to say my criticisms now!
21:40 * Whiteknight goes off to backlog :)
21:42 dalek parrot: r45186 | plobsing++ | trunk (2 files):
21:42 dalek parrot: add Parrot_PMC_push_string
21:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45186/
21:43 payload joined #parrot
21:44 Whiteknight It's my understanding that LLVM takes care of all the cross-platform nonsense
21:44 Whiteknight so ash_ won't have to work on one platform at a time
21:45 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
21:45 ash_ it works on others, but they aren't extensively tested
21:45 plobsing does parrot explicitly support any platforms not in that list?
21:46 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
21:46 Austin Parrot's goal is to support every platform on which it is possible to perform binary arithmetic.
21:47 Austin 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
21:48 cotto_work 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
21:48 darbelo dukeleto: Off-hand I know of x86 amd64 sparc (or was it sparc64?) and arm
21:48 dukeleto where is this list of platforms described?
21:48 ash_ http://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
21:49 Austin Ever since they implemented IP over bongo drums, the support requirements have been growing..
21:49 cotto_work dukeleto, PLATFORMS in svn root
21:49 ash_ s/has a/has a list/
21:50 dukeleto cotto_work: duh. thanks
21:50 cotto_work which we should be updating now that a supported release is coming up
21:51 cotto_work s/we/people with interesting platforms/
21:56 NotFound I've built parrot for Maemo, but I don't think my build can qualify as 'supported'
21:57 dalek parrot: r45187 | plobsing++ | trunk (2 files):
21:57 dalek parrot: revert r45186
21:57 dalek parrot: Parrot_PMC_push_string was already provided. plobsing--
21:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45187/
21:58 ash_ plobsing: where there any major problems with your libjit stack frame builder?
21:58 iblechbot joined #parrot
21:59 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.
22:00 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)
22:01 plobsing 2) a return value sign-extension bug in libjit.
22:02 plobsing that's about it. I kind of got distracted by the zillion other things that Parrot needs
22:04 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:06 dalek rakudo: db9c0ea | chromatic++ | src/pmc/perl6multisub.pmc:
22:06 dalek rakudo: [PMC] Fixed a memory leak in Perl6MultiSub of candidate constraints and types.
22:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​b9c0ea7cf35a3fff5ca00f8b3bfc5e196d29c92
22:06 dalek rakudo: 4b7dbf3 | chromatic++ | src/pmc/perl6multisub.pmc:
22:06 dalek rakudo: [PMC] Tidied code in Perl6MultiSub PMC; no functional changes.
22:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​b7dbf3f10a14fd055ee8e5b9bdffde192743ac8
22:08 cotto_work :q
22:08 dukeleto purl, forget a couple
22:08 purl dukeleto: I forgot couple
22:09 plobsing why is Parrot_VTABLE part of the API?
22:09 plobsing it seems very very wrong
22:11 Whiteknight plobsing: yeah, it's easy to get distracted by all the millions of things Parrot needs
22:11 Whiteknight at least we're never bored!
22:11 plobsing specifically, why should an embedder or an extender be able to Parrot_PMC_set_vtable?
22:12 Whiteknight vtable overrides for custom classes?
22:12 Whiteknight I don't even know what that function is
22:12 Whiteknight Oh, wait. Dynpmcs
22:14 plobsing Whiteknight: the api doesn't let you modify VTABLES. they are opaque to that API.
22:14 plobsing all you can do is get a type's vtable and set a pmc's vtable
22:15 plobsing which is basically only usable as an awkward and error prone way of type-casting AFAICT
22:15 dalek parrot: r45188 | plobsing++ | trunk/DEPRECATED.pod:
22:15 dalek parrot: deprecate duplicate vtable-calling functions in src/extend.c
22:15 dalek parrot: the right functions to call are in src/extend_vtable.c
22:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45188/
22:24 cotto_work plobsing, make sure you file a ticket for those deprecations
22:25 cotto_work 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
22:32 dalek parrot: r45189 | plobsing++ | trunk/DEPRECATED.pod:
22:32 dalek parrot: deprecate Parrot_VTABLE
22:32 dalek parrot: doesn't currently provide functionality that should be available outside core
22:32 dalek parrot: can be revived later to provide legitimate functionality
22:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45189/
22:34 dalek TT #1530 created by plobsing++: [DEPRECATION] Parrot_PMC_* in src/extend.c
22:34 dalek TT #1530: http://trac.parrot.org/parrot/ticket/1530
22:35 dalek winxed: r440 | julian.notfound++ | trunk/examples/pirado.winxed:
22:35 dalek winxed: refactor common parts of call and return instructions in pirado
22:35 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=440
22:46 riffraff joined #parrot
22:50 dalek TT #1531 created by plobsing++: [DEPRECATION] Parrot_VTABLE
22:50 dalek TT #1531: http://trac.parrot.org/parrot/ticket/1531
23:14 Coke plobsing: I'm looking at 1531 - what is Parrot_VTABLE?
23:14 plobsing it's an opaque pointer
23:14 plobsing representing a VTABLE
23:14 Coke japhb: if I knew that, I would have put it in the ticket.
23:14 Coke s/ticket/reply/
23:14 plobsing --This line, and those below, will be ignored--
23:15 plobsing M    src/extend.c
23:15 plobsing M    include/parrot/extend.h
23:15 japhb Coke, sorry, thought you were referring to something "well known" that I just missed.
23:15 plobsing sorry, unintended paste
23:15 cotto_work That's what they all say.
23:16 Coke japhb: random fixes chromatic has done.
23:16 japhb Ah, fair enough.
23:17 japhb Are we down at the level that Rakudo will compile in under a GB of RAM?
23:18 Coke Iunno.
23:18 * japhb is doing a recompile himself
23:19 * japhb gets really annoyed at software/servers that can't pin his crappy DSL line
23:20 chromatic 32-bit, definitely under a GB.
23:20 japhb Good!
23:20 * japhb checking amd64 now
23:23 ash_ joined #parrot
23:29 Whiteknight chromatic++
23:32 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:33 cotto_work Yay for leaks!  Moreso for fixing them.
23:34 chromatic That said, I still don't trust compact_pool.
23:40 cognominal joined #parrot
23:43 tcurtis joined #parrot
23:50 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.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced