#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