Camelia, the Perl 6 bug

IRC log for #parrot, 2008-12-23

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:16 ruoso joined #parrot
00:21 apple-gunkies joined #parrot
00:51 dalek r34263 | pmichaud++ | trunk/languages/perl6/src (2 files):
00:51 dalek : [rakudo]:  refactor more "list methods" from Mapping into Any
00:51 dalek review: http://xrl.us/3248b
00:55 apple-gunkies joined #parrot
01:11 ewilhelm_ joined #parrot
01:14 particle1 joined #parrot
01:19 apple-gunkies joined #parrot
02:00 Coke pmichaud: I am glad that I am probably one of the few people who will ever want to say "anyone" to your statement about nested sub definitions.
02:01 Tene Coke: eh?
02:01 purl Get off my lawn!
02:01 Coke tene: feh?
02:01 purl feh is ricocheting
02:03 Coke cj?
02:03 purl i heard cj was a soylent donut or from Poulsbo, WA or AIM:carljcollier or mailto:jabber:cjcollier@seattlewireless.net or mailto:MSN:cjcollier@colliertech.org or mailto:cjcollier@colliertech.org
02:03 Coke yup, that's him.
02:06 * Coke wonders at facebook.
02:10 tetragon joined #parrot
02:16 kid51 joined #parrot
02:17 dalek r34264 | jkeenan++ | trunk/t/tools/ops2pm:
02:17 dalek : Jiggle the tests until more of them pass.
02:17 dalek review: http://xrl.us/4auuf
02:25 apeiron joined #parrot
02:26 pmichaud Tene: I think I've decided that for the short term we're not going to worry about NEXT/LAST/REDO handlers in PCT just yet.
02:26 pmichaud the various loop types do need to catch the loop exceptions and dtrt, though.
02:35 TiMBuS is there a reason this would segfault for an op? int a = VTABLE_get_integer(interp, VTABLE_get_pmc_keyed_int(interp, $3, 0));
02:35 pmichaud depends on what the get_pmc_keyed_int is returning.
02:35 TiMBuS $3 is a resizablepmcarray, and im certain its got a value in it, and its an Integer
02:36 Coke and what $3 is, though that'd be harder to screw up.
02:36 pmichaud ...any tailcalls involved?  ;-)
02:36 * pmichaud tries his new heuristic.
02:36 TiMBuS nope, at least not directly
02:37 particle1 msg barney barney++ # nice work with the "pir injection" technique for .HLL :)
02:37 purl Message for barney stored.
02:37 pmichaud ...pir injection?
02:37 TiMBuS i guess ill just screw around until the error shows itself
02:39 particle1 make PAST::Stmts.new( $past, PAST::Op.new( :inline( "_block11()\n.end\n.HLL 'Pipp'\n.sub 'anon'" ) ));
02:39 pmichaud ick.
02:39 Coke I'd split that into 2 lines, and step through them. Also, grab the backtrace. Also, does it go away with -G?
02:39 * pmichaud adds HLL to PCT.
02:40 TiMBuS caught it. whoops that was my bad, was assigning to uninit'd pointer
02:41 TiMBuS the joy of coding in c
02:43 particle1 pmichaud: seems rakudo's failing some inf/nan spectests on win32
02:43 particle1 i haven't read all the recent commits, so i'm not precisely sure what's changed
02:43 particle1 i'll nopaste the report...
02:49 particle1 ...later...afk &
02:57 Coke particle: are they the same inf/nan errors that fail for parrot itself?
03:01 * pmichaud guesses yes.
03:33 dalek r34265 | pmichaud++ | trunk/compilers/pct/src/POST (2 files):
03:33 dalek : [pct]:  .HLL support part 1 -- 'hll' attribute in POST nodes.
03:33 dalek review: http://xrl.us/4gsbq
03:38 ewilhelm joined #parrot
03:39 kid51 ewilhelm ping
03:40 ewilhelm kid51, pong?
03:41 kid51 Hi.  Do you have anything to add to http://rt.perl.org/rt3/Tic​ket/Display.html?id=57320 ?  (I think you opened it, originally.)
03:41 ewilhelm haven't been following too closely.  does it no longer do `mkdir /tmp/t` ?
03:41 dalek r34266 | pmichaud++ | trunk/compilers/pct/src/PAST (2 files):
03:41 dalek : [pct]:  .HLL support part 2 -- .hll in PAST::Block nodes.
03:41 dalek review: http://xrl.us/4hpyh
03:42 pmichaud msg barney you should be able to set :hll('...')  on PAST::Block to put blocks into a different .HLL .
03:42 purl Message for barney stored.
03:44 kid51 ewilhelm:  [parrot] 514 $ grep mkdir t/perl/Parrot_IO.t
03:44 kid51 [parrot] 515 $
03:44 dalek r34267 | pmichaud++ | trunk/docs/pdds:
03:44 dalek : [pct]:  Update pdd26_ast.pod with 'hll' attribute on PAST::Block .
03:44 dalek review: http://xrl.us/4hxrp
03:44 kid51 No 'mkdir' at all.
03:44 kid51 uses File::Temp::tempdir().
03:44 ewilhelm kid51, that sounds good
03:45 kid51 anyone:  Do we not have an IRC channel topic set right now?  Or have my settings gotten screwed up?
03:45 kid51 ewilhelm:  Thanks.  I will close the ticket.
03:45 * ewilhelm sees no topic
03:47 Topic for #parrotis now Parrot 0.8.2 "Feliz Loro" Released http://www.parrot.org/news/2008/Parrot-0.8.2
03:48 kid51 ... for lack of a better idea ;-)
03:48 ewilhelm thanks
03:50 kid51 Re:  Win32 math errors:  http://rt.perl.org/rt3/Tic​ket/Display.html?id=52198
03:57 * kid51 must sleep
03:57 purl $kid51->sleep(8 * 3600);
04:02 elmex_ joined #parrot
04:10 pdcawley joined #parrot
04:21 MariachiElf joined #parrot
04:22 ChrisDavaz joined #parrot
04:31 flw joined #parrot
04:32 flw joined #parrot
05:04 tetragon joined #parrot
05:09 masak joined #parrot
05:09 petdance joined #parrot
05:53 ChrisDavaz joined #parrot
06:25 MariachiElf joined #parrot
06:32 Tene pmichaud: next/last/redo work in rakudo in the branch.  Should we just merge for now and deal with the handlers later?
06:37 pmichaud I still want to avoid the throwing of the exceptions.
06:37 pmichaud They aren't needed.
06:37 pmichaud (I should say "the forced throwing of the exceptions")
06:38 pmichaud Just posted a draft article at http://use.perl.org/~pmichaud/journal/38134  -- comments and suggestions welcome.
06:38 pmichaud (I'm also planning to send it to rakudo.org and perl6-users mailing list.)
06:44 nopaste "tene" at 166.70.38.237 pasted "pmichaud: so like this?" (41 lines) at http://nopaste.snit.ch/15074
06:44 Tene ... wait, that doesn't work.
06:46 * masak likes the article
06:47 * pmichaud posts.
06:47 masak enthusiastic Perl 6 coders are what we need.
06:47 masak the more, the better.
06:53 dalek r34268 | tene++ | branches/pctloop/compilers/pct/src/PAST:
06:53 dalek : [pct]: Use a goto instead of an exception in one place.
06:53 dalek review: http://xrl.us/4y9eg
06:53 pmichaud Tene: I'm falling asleep at my keyboard, so pctloop will be the first thing I look at tomorrow morning.
06:55 pmichaud afk # sleep
06:59 Theory joined #parrot
07:07 * masak wrote a short summary: http://use.perl.org/~masak/journal/38135
07:07 masak hope that's ok. :)
07:37 Theory joined #parrot
08:04 iblechbot joined #parrot
08:55 barney joined #parrot
09:25 ask_ joined #parrot
09:42 donaldh joined #parrot
09:53 dalek r34269 | bernhard++ | trunk/languages/pipp/src/pct:
09:53 dalek : [Pipp] Use the nifty hll attribute on PAST::Block.
09:53 dalek : Unbreak 'require_once'. pmichaud++
09:53 dalek review: http://xrl.us/5dyee
09:56 ask_ joined #parrot
09:58 dalek r34270 | bernhard++ | trunk/languages/pipp/t/embed:
09:58 dalek : [Pipp] Reenable example with function lookup.
09:58 dalek review: http://xrl.us/5eaom
10:12 particle joined #parrot
10:17 ask_ joined #parrot
10:39 alvar joined #parrot
10:57 Zaba joined #parrot
11:38 ruoso joined #parrot
11:41 Lorn joined #parrot
12:00 TiMBuS joined #parrot
12:04 GeJ joined #parrot
12:10 dalek r34271 | bernhard++ | trunk (2 files):
12:10 dalek : Trac#75: Add file ext/Parrot-Embed/t/pipp.t with most test cases commented out.
12:10 dalek review: http://xrl.us/5orh9
12:44 ChrisDavaz joined #parrot
13:01 szabgab barney: thanks
13:03 barney szabgab: I submitted https://trac.parrot.org/parrot/ticket/85, as 'eval' is not found in the 'pipp' hll root namespace
13:06 tetragon joined #parrot
13:06 szabgab barney: yeah, I hope things start to move on the embedding front now so in a few days/weeks I'll be able to write Padre::Plugins in other languages, not only perl 5
13:10 petdance joined #parrot
13:30 dalek r34272 | bernhard++ | trunk/languages/pipp/src (7 files):
13:30 dalek : [Pipp] Avoid the implicit downcasing of the HLL name.
13:30 dalek : Prepare for using the '_pipp' hll root namespace for Pipp internals.
13:30 dalek review: http://xrl.us/5toim
13:44 ask_ joined #parrot
13:47 dalek r34273 | bernhard++ | trunk/languages/pipp/src:
13:48 dalek : [Pipp] Move some internal functions into the '_pipp' hll root namespace.
13:48 dalek review: http://xrl.us/5vdji
13:50 petdance joined #parrot
13:50 ffwonko joined #parrot
13:52 Theory joined #parrot
14:01 particle1 joined #parrot
14:10 Coke I tend to think of xrl.us as a scarce resource; do we really need to use it here?
14:10 Coke is http://www.parrotvm.org/svn​/parrot/revision?rev=34273 really too long?
14:12 pmichaud not for me.  As long as it doesn't trigger one of the other bots that "helpfully" shortens it for us.
14:18 jonathan pmichaud: What's status of use/initload things?
14:18 jonathan And rakudoreg stuff?
14:18 * jonathan is too lazy to backlog several days worth
14:19 pmichaud use/initload is finished
14:19 pmichaud I'm *much* happier with what we have now.
14:20 jonathan ok, good
14:20 dalek r34274 | bernhard++ | trunk/languages/pipp/src (2 files):
14:20 jonathan Did those get updated into the branch?
14:20 pmichaud I was going to do rakudoreg stuff next, but ended up attacking spectests.
14:20 dalek : [Pipp] Set the scope of the superglobals to 'package' in the TOP-Block.
14:20 dalek : Beware that there are still local symbol scope declarations the override the
14:20 dalek : declaration in TOP.
14:20 dalek review: http://xrl.us/5xcxk
14:20 * barney likes  http://www.parrotvm.org/svn​/parrot/revision?rev=34273
14:20 pmichaud (updated into branch)  short answer, no -- I figure it might be easier to start a new branch and then bring rakudoreg updates into that new branch
14:21 jonathan maybe
14:21 jonathan I don't have svn 1.5 on this laptop...
14:21 jonathan Guess I can upgrade though.
14:24 pmichaud well, that's part of what makes the new branch easier -- don't need svn 1.5 to do it
14:25 jonathan In that case, it's your job, 'cus I don't understand pre-1.5 branch management. :-)
14:25 pmichaud okay, I'll do that part, but basically it's:
14:25 Wknight8111 joined #parrot
14:25 pmichaud svn copy https://svn.perl.org/parrot/trunk https://svn.perl.org/parrot/branches/rakudoreg2   # create new branch
14:26 jonathan I can do that bit. :-)
14:26 pmichaud svn co https://svn.perl.org/parrot/branches/rakudoreg2 # check out copy
14:26 pmichaud cd rakudoreg2
14:26 pmichaud # figure out starting revision of rakudoreg branch
14:27 dalek r34275 | Whiteknight++ | trunk/src:
14:27 pmichaud svn merge -r $rev:head https://svn.perl.org/parrot/branches/rakudoreg
14:27 dalek : [Patch] remove a little bit of logic redundancy. A smart compiler probably ignored this already, but I don't count on all compilers being smart. jimmy++
14:27 dalek review: http://xrl.us/5xefb
14:27 pmichaud where $rev is the starting revision of the rakudoreg branch.  That can be determined quickly by using svn log --stop-on-copy
14:28 pmichaud ...but instead of doing a all-at-once merge, I was just going to look at the diffs and recreate them in the new branch
14:28 jonathan OK.
14:28 pmichaud I probably won't get to it for another couple of hours, though, as I told Tene I'd work on loops this morning.
14:28 jonathan There's a better chance of you not screwing it up. :-)
14:28 jonathan Oh, that's fine.
14:28 pmichaud I've also decided to implement find_lex_contextual and store_lex_contextual ops.
14:28 jonathan I'm sorta in holiday mode, have a load of family around, am seeing various UK friends etc.
14:29 jonathan So only getting snatches of hacking time.
14:29 jonathan Oh, cool.
14:29 jonathan Context vars. :-)
14:29 pmichaud yes -- I've come up with about a half-dozen immediate use cases for them, so I'm going to stick 'em into NQP.
14:29 pmichaud (and PCT)
14:29 jonathan Great.
14:29 Wknight8111 pmichaud++
14:29 donaldh joined #parrot
14:30 jonathan I may well dig into S14.
14:30 pmichaud and although I could probably make something work without the new opcodes, it's so much more straightforward with the ops that I'm just going to do it that way.  :-)
14:30 jonathan Oh yes, I can imagine.
14:30 jonathan Not to mention faster at runtime.
14:31 pmichaud Sam Vilain sent a message to parrot-dev, gist of the message was "Rakudo needs a better install, line numbers in error messages, less error trace information, debugger, avoid VM spiraling out of control"
14:32 pmichaud so "line numbers in error messages" (bytecode annotations) would be good to work on if you get a chance :-)
14:32 jonathan Line numbers in error messages is already in progress.
14:32 pmichaud I'll likely do that part of the PGE refactor this week.
14:32 jonathan Great.
14:32 jonathan I want to land the Parrot changes for it early Jan.
14:32 pmichaud so it'll be ready when the bytecode annotations come in.
14:33 jonathan Good.
14:33 flh joined #parrot
14:33 jonathan Better install - sorta depends on sorting it out for Parrot first.
14:34 jonathan less error trace information - more is useful for now, IMO.
14:35 jonathan though we won't want to incldue the stuff below Rakudo level in backtraces.
14:36 jonathan debugger - more important things to focus on right now, IMO, but I'd very happily see someone working on it if they wanted to.
14:36 jonathan VM spiraling out of control - usually we gotta fix this on a case by case basis...
14:37 * jonathan is trying to find the original message
14:41 barney find_lex_contextual()  can that be used for checking wether a lexical is already declared ?
14:42 gryphon joined #parrot
14:45 jhorwitz joined #parrot
14:46 jonathan barney: In the dynamic scope.
14:51 contingencyplan joined #parrot
14:51 * Coke needs to add a sanity check to the spec_test tool tcl runs that verifies we're running against a /clean/ copy of the spec tests.
14:52 Coke accidentally passed something.
14:53 PerlJam Coke: gas?  :)
14:53 Coke a spec test.
14:54 jonathan lol
15:01 * Coke shares a horrible joke from a coworker.
15:01 Coke A SQL query goes into a bar, walks up to two tables and says, "Can I join you?"
15:01 jonathan *GROAN*
15:02 Coke ... that's what I said.
15:10 Andy eeenteresting: http://smallcode.weblogs.us/20​06/08/22/fast-strlen-function/
15:10 shorten Andy's url is at http://xrl.us/5zqc4
15:11 Andy Duff's device + anding for equality
15:26 dalek r34276 | pmichaud++ | trunk/languages/perl6/docs:
15:26 dalek : [rakudo]: spectest-progress.csv update: 264 files, 5833 passing, 0 failing
15:26 dalek review: http://xrl.us/52k8r
15:26 jonathan Wow. 6,000 coming soon?!
15:26 pmichaud maybe.
15:26 pmichaud I probably hit a lot of the low-hanging fruit this past weekend.
15:27 jonathan *nod*
15:27 jonathan Sure, but having a sweep out of that lot now and then can be a good thing.
15:27 jonathan The stuff you've done all needed doing at some point.
15:28 pmichaud right now I don't have a good feel for what we need to be working on to pass more tests, though.
15:28 pmichaud I guess there's a fair bit of S05 stuff that needs doing.
15:29 barney When adding a 'lexical' PAST::Var to a PAST tree:   Can I say     :isdecl(1)   unless already declared ?
15:29 nopaste "pmichaud" at 72.181.176.220 pasted "spectests by synopsis, 2008-12-23" (16 lines) at http://nopaste.snit.ch/15076
15:29 pmichaud right now having multiple :isdecl(1)'s in a block causes problems for Parrot.
15:30 jonathan pmichaud: Doing parameter stuff would let us at least close some tickets.
15:30 jonathan It won't win us hundreds of tests maybe, but some for sure.
15:31 pmichaud jonathan: agreed.
15:31 pmichaud in reviewing the test suite I didn't see anything (other than S05 stuff) that might win us hundreds of tests
15:31 jonathan Once you get that in place I will mostly likely not be that far behind with the unpacking stuff, 'cus it's -Ofun ;-)
15:31 pmichaud of course, that only includes tests that are in t/spec .  There may still be tests in t/  (not t/spec/) that need migration.
15:32 PerlJam barney: On the first day of a christmas my true-love gave to me ... a PAST::Var in a PAST tree.
15:32 jonathan *nod*
15:32 barney Can I use  find_lex   for checking whether a var is already declared?  Or do I have to search the blocks, like in the Squaak tutorial ?
15:33 pmichaud barney: find_lex is runtime, search blocks sounds like compile-time
15:33 pmichaud so...?
15:33 purl Yeah, so?
15:33 * barney wants a big PAST::Block, not a small PAST::Var
15:33 PerlJam barney: what are you implementing?
15:34 barney PHP variables, which are not declared.
15:34 contingencyplan joined #parrot
15:35 PerlJam so, you're doing the auto-declare-on-first-use dance?
15:35 barney yep
15:35 pmichaud barney:  you want to be using the PAST::Block.symbol table then
15:36 pmichaud when you encounter a variable, check the Block's symbol table to see if it's already defined.  If yes, generate a normal PAST::Var node. (more)
15:36 pmichaud If no, then generate a PAST::Var node with :isdecl(1) and put it at the beginning of the block, and mark an entry in the .symbol table.  Then generate a normal PAST::Var node.
15:39 barney Does that work with symbols in symbol tables in outer blocks?
15:40 pmichaud are you trying to handle the case of nested subs?
15:41 pmichaud I haven't done much nested subs in PHP.... but if you have    function a() {   $x = 1;   function b() { $x = 2 } }    then the $x that is in b() doesn't refer to the same $x as function a(), right?
15:42 barney Kind of. Currently I only have superglobals in TOP Block, that I declared as 'package' vars. All other vars should be lexicals, so that I can support closures
15:43 PerlJam PHP does closures?
15:43 pmichaud anyway, I'm trying to come up with a case where a variable needs to be checking its outer blocks.
15:44 pmichaud (and not coming up with one.)
15:44 barney pmichaud: In 5.3 there is a 'use' syntax, that says which vars should be taken from the outer scope
15:44 pmichaud how does one declare a local var, then?
15:44 pmichaud (haven't seen 5.3 at all.)
15:45 barney in functions all vars are local, unless they have been declared with 'use'
15:45 pmichaud so 'use' explicitly means "check the outer scope"
15:45 pmichaud ?
15:46 barney yes
15:46 PerlJam barney: does it just look in the immediately outer scope or does it keep looking outward until it finds the var or runs out of scopes?
15:46 pmichaud okay, for a 'use' statement then you simply put an entry in PAST::Block.symbol that indicates that the lexical is already declared.
15:46 pmichaud That prevents subsequent references from creating a new lexical in the PAST::Block, and PAST will default to using the lexical from its outer scopes.
15:47 pmichaud i.e., 'use' is "suppress :isdecl for this variable in this block"
15:48 pmichaud you still don't need to check the outer scopes :-).  Unless of course someone has "use $x"  and $x doesn't exist in any outer scopes -- I don't know if that's an error (or should be).
15:48 barney PerlJam: the 'use' is only for anonymous subs, I suppose for deeply nested anonymous subs it keeps on looking
15:49 barney pmichaud: At this point I can live with a runtime error
15:50 pmichaud anyway, the "magic" for making this work is to use the PAST::Block.symbol tables to keep track of variables.
15:50 pmichaud In fact, that's what allows you to not have to put a :scope attribute on every PAST::Var node.
15:50 barney k
15:51 pmichaud so, in PHP,  "global $foo"   should do the equivalent of   $past.'symbol'('$foo', :scope('package'));
15:51 barney I'll add the :isdecl(0) for the 'use'ed vars and for the superglobals
15:51 pmichaud (where $past is the node for the PAST::Block)
15:52 pmichaud any later references to "$foo"  simply do   PAST::Var.new( :name('$foo') )
15:52 pmichaud (well... after doing the lexical check we described earlier)
15:55 barney pmichaud: Currently I think that "global $foo" would be $past.'symbol'('$foo', :scope('lexical'))
15:55 nopaste "pmichaud" at 72.181.176.220 pasted "code for PHP variables" (10 lines) at http://nopaste.snit.ch/15077
15:55 pmichaud ...why lexical?
15:56 barney or look up only one level
15:57 pmichaud is that because globals need capturing in a closure?
15:57 barney I think that working with lexicals simplifies handling of functions that are defined in required files.
15:58 pmichaud well, you can definitely do global variables as lexical also
15:58 pmichaud where are you storing the global?
15:58 barney 'require' being basically a function call
15:59 barney a global in  a required file is, AFAIK, only global to the required file. So that makes is look like a lexical.
16:00 pmichaud that doesn't sound familiar.
16:00 barney Where files and function are lexical boundaries, but { } is not
16:01 pmichaud oh.
16:01 pmichaud the symbol is scoped to the file, but the variable lifetime isn't.
16:01 pmichaud because in a required file, if I say   "global $foo"  then I'm talking about the same $foo that all of my other files that do "global $foo" are referencing.
16:02 pmichaud I'm not creating a new $foo that is local to the file.
16:02 pmichaud basically files just serve as another function boundary.
16:03 pmichaud (even to the point of 'return' meaning 'exit this file')
16:07 flh joined #parrot
16:08 barney I haven't thought about 'global' yet. Maybe I need to put them into a 'package' and initialize from the lexical
16:09 pmichaud that works too.  Anyway, I'd focus on lexicals to begin with. I think the answer lies in making use of the PAST::Block.symbol table (which is why it's there, of course :-)
16:14 ask_ joined #parrot
16:14 flh hi everyone
16:14 purl Howdy, flh, you fantastic person you.
16:15 masak joined #parrot
16:16 flh I had a question about pir: I'm trying to write a function which expects a fixed number of arguments, but when given less arguments, it returns a new function which waits for the rest
16:17 donaldh joined #parrot
16:17 flh and I'm afraid I don't know how to start writing such a thing...
16:17 pmichaud flh:  ah, that's currying.  :-)
16:17 apple-gunkies self.curry() ?
16:17 flh sure, I'm playing with the ocaml language :)
16:18 pmichaud in Rakudo we do it using lexicals.
16:18 * barney was reading up on http://de.php.net/global    The toplevel scope seems to be special for 'global'
16:19 flh I knew I should have asked earlier
16:20 pmichaud the code that Rakudo uses (in Perl 6 it's the ".assuming method") is languages/perl6/src/classes/Code.pir line 132.
16:20 contingencyplan_ joined #parrot
16:23 flh thanks!
16:24 contingencyplan_ joined #parrot
16:27 pdcawley joined #parrot
16:29 PerlJam What's the difference between creating objects using PMCs vs. straight PIR?  Why choose one over the other?  Is it strictly speed?  Are there some capabilities that one has and the other does not?
16:30 pmichaud PerlJam: you mean the difference between writing a new PMC type versus doing "newclass" in PIR?
16:30 Coke tcl has a form of currying like "interp alias {} foo {} if 1"; then whenever you say "foo {puts hi}", it's like you had typed "if 1 {puts hi}". (if you're testing, it's a way to run things all the time, or skip, depending on the alias.); I was pleasantly surprised I could do this with proc foo {args} { uplevel 1 "if 1 $args" } with partcl already.
16:30 PerlJam pm: right.
16:30 contingencyplan__ joined #parrot
16:30 Coke (it's not really currying. Though tcl has that with 'apply', which I also need to hack on.)
16:31 pmichaud the primary difference at the moment is that PMCs give you the ability to do things in C, while Objects limit you to PIR.
16:31 Coke if you want the best of both worlds, you could theoreticaly do a base in PMC and provide methods in PIR.
16:31 Coke (though ISTR that kind of mixin has issues atm.)
16:32 pmichaud Coke: that works for the most part -- we do it a fair bit in Rakudo.
16:32 Coke ah, cool.
16:32 pmichaud what's tougher to handle is overriding vtable methods in a PMC
16:32 contingencyplan_ joined #parrot
16:32 Coke I find it helpful to use PIR for cases where I want attributes.
16:34 Wknight8111 PIR vtable overrides definitely have problems
16:34 Wknight8111 at least, some of them do
16:35 contingencyplan joined #parrot
16:36 * barney is back after dinner
16:39 tomyan left #parrot
16:47 PerlJam pm: ping
16:51 contingencyplan_ joined #parrot
16:55 mberends joined #parrot
16:56 davidfetter joined #parrot
17:24 particle joined #parrot
17:27 donaldh Hi, I'm looking for advice trying to debug a GC crash.
17:29 alvar joined #parrot
17:29 donaldh I have a p6 sub that typically crashes in pobject_lives. With -G it runs to completion. With --runcore=gcdebug it _appears_ to infinite loop.
17:30 pmichaud PerlJam: pong
17:31 donaldh In the debugger, it's looping through runops_gc_debug_core but I can't tell if it's just repeating the exact same loop or not.
17:31 donaldh Are there any helpful tools in the GC debugging armoury?
17:32 PerlJam pm: Could you explain the 'for' pasttype a little more?  It seems to only be used in two places: cardinal and rakudo.  rakudo's usage seems complicated by comparison to cardinal.
17:34 PerlJam pm: also, all of the other pasttypes seem to operate on individual nodes (which may be aggregates), while the 'for' pasttype talks about iterating over it's first child.   That seems odd to me right nwo.
17:34 PerlJam s/nwo/now/
17:35 pmichaud pj:  iterating over an aggregate is fairly common.  PHP does it, Perl 6 does it, Ruby does it, and I think Python does also.
17:35 pmichaud so that's what 'for' represents.
17:36 PerlJam right, that makes sense.  I guess it's just that there don't seem to be "arrays" in PAST.
17:36 pmichaud even 'for' doesn't really iterate over arrays -- it uses iterators.  :-)
17:37 pmichaud I suppose it would make more sense if 'for' took an iterator as its first child instead of an aggregate, though.
17:39 pmichaud anyway, having it automatically construct an iterator from an aggregate is useful, so I might keep it the way it is.
17:39 * pmichaud rationalizes.  :-)
17:44 Wknight8111 donaldh: You have a test case?
17:48 dalek r34277 | pmichaud++ | branches:
17:48 dalek : New branch for 2nd attempt at loop refactoring.
17:48 dalek review: http://xrl.us/6fbd3
17:49 Coke donaldh: chromatic has some tips on debugging GC in parrot.
17:49 Coke I'd start there.
17:49 Coke http://www.google.com/search?rlz=1C1CHMP_​en-USUS299US303&sourceid=chrome&i​e=UTF-8&q=chromatic+parrot+gc+debug
17:49 shorten Coke's url is at http://xrl.us/6fhkf
17:53 * Coke wonders if he can make a parrot Interp == tcl's [interp]
18:03 Wknight8111 Coke, you're probably going to have to subclass it
18:03 Whiteknight joined #parrot
18:05 rurban joined #parrot
18:09 donaldh sorry, afk
18:09 Whiteknight 'salright.
18:12 flh joined #parrot
18:19 pmichaud #ps in 11
18:20 Whiteknight w00t
18:21 dalek r34278 | Whiteknight++ | trunk/src/stm:
18:21 dalek : [STM] Added a note here about how the debug definition for STM_TRACE is not C89 compliant, and linked to the ticket where we are discussing the issue.
18:21 dalek review: http://xrl.us/6h3ti
18:26 nopaste "donaldh" at 213.123.171.12 pasted "Whiteknight: weather.p6 test case uses ext/SQLite3" (14 lines) at http://nopaste.snit.ch/15078
18:27 donaldh Whiteknight: any sqlite db with >100 rows should cause it.
18:28 dalek r34279 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST:
18:28 dalek : [pct]:  Initial version of loop_gen, 'until' using 'loop_gen'.  NQP tests pass.
18:28 dalek review: http://xrl.us/6iqhj
18:32 allison joined #parrot
18:33 dalek r34280 | bernhard++ | trunk/languages/pipp/src/pct (2 files):
18:33 dalek : [Pipp] Start with keeping track whether a variable is declared.
18:33 dalek review: http://xrl.us/6jcjw
18:34 Whiteknight donaldh, you might have to ask chromatic about this. I'm not too good with Rakudo or SQL stuff
18:34 donaldh :D
18:35 pmichaud #ps in -5
18:35 pmichaud (as in 5 minutes ago)
18:35 apeiron joined #parrot
18:35 Coke irclog?
18:35 purl i guess irclog is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:36 PacoLinux joined #parrot
18:37 chromatic joined #parrot
18:40 dalek r34281 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST:
18:40 dalek : [pct]:  Switch 'while' to use loop_gen, refactor 'until'.
18:40 dalek review: http://xrl.us/6j35e
18:41 particle how do i get access to parrot's coverity reports?
18:41 chromatic I send your contact information to Coverity.
18:44 particle aha. send away!
18:49 ambs joined #parrot
18:52 Whiteknight so we don't use STM?
18:52 particle no, never worked on win32 anyway
18:53 chromatic It relies on the old threading model too.
18:53 Whiteknight Really? what was holding it back on Win32? Who was working on it?
18:53 Coke ... and we haven't ripped it out?
18:53 particle it was a gsoc project from 2-3 years ago
18:53 Coke wasn't it a SOC project?
18:53 Coke Whiteknight: let that BE A LESSON TO YOU! =-)
18:53 particle was mostly integrated, but never fully integrated since threads was still in prototype
18:53 particle we have no tuits to get it working before 1.0
18:54 particle it's not critical, so we rip it out and address it later
18:54 Whiteknight I've got tuits, I didn't realize it wasn't working
18:54 Coke Whiteknight: (tuits) hey, where's my shiny new GC? =-)
18:54 Whiteknight i'm practically made of tuits. Sleep is for lesser men
18:54 Whiteknight GC is in the pipeline
18:54 particle gc is critical
18:54 szabgab chromatic: do I need to try to nag you regerding the Parrot::Embed issues ?
18:55 Whiteknight I'm working on GC, had a few GC-related commits this week
18:55 particle rip out stm, get gc working, get docs ready for 1.0, then take a look at stm
18:55 * Coke apologies to chromatic, but your ballot has already been cast. there's no papertrail.
18:55 Whiteknight docs are too out of date. We should rip them out too :)
18:56 particle i'll let you get the karma for that ;)
18:57 Whiteknight no, can't rip out docs. We'll just have to start going through them slowly
18:58 particle we can, however rip out stm. we^Wyou ripped out your gc, after all. :)
19:00 allison Whiteknight: yes, we can't simply rip out docs without reviewing them, but I suspect many of the current doc files will be ripped out
19:01 allison Whiteknight: or merged into other doc files
19:01 Whiteknight i was joking about the docs. I'm not going to rip them out, I'm going to slowly fix them
19:01 particle of course you are, and we might even help
19:02 dalek r34282 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST:
19:02 dalek : [pct]:  Move repeat_until to use the loop_gen code.
19:02 dalek review: http://xrl.us/6obbz
19:02 particle allison: any thoughts as to how long a sockets impl might take in ideal developer hours?
19:03 allison particle: about 3 days
19:03 allison the core infrastructure is there, but needs the PMC on top
19:04 allison BTW, we have no tests for the socket implementation
19:04 ask_ joined #parrot
19:04 allison we have no code using the sockets implementation
19:04 particle yeah, that's a good place to have contributors
19:04 particle we have examples using sockets
19:04 Coke allison: tcl was using tcpstream
19:05 ambs left #parrot
19:05 Coke so, barney, is your question answered? =-)
19:10 dalek r34283 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST:
19:10 dalek : [pct]:  Refactor repeat_while to use loop_gen.
19:10 dalek review: http://xrl.us/6pe34
19:11 Whiteknight particle, which runcores were you planning to rip out?
19:12 particle cgp, for one
19:12 Whiteknight we don't use cgp? I thought we did
19:12 particle it's gcc-only
19:12 chromatic We almost never test these runcores.
19:13 particle we need 1.0 to be *stable*
19:13 Coke cage test: find failing smoke tests and skip them on the reporting platform.
19:13 particle if we're not testing parts of parrot, like rarely used runcores and gc impls, we can't guarantee stability
19:17 allison particle: and frankly, many of those will never be used in their current state (or anything even vaguely resembling their current state), so we might as well scrap them
19:18 particle i'll gen some tickets after my errands
19:18 particle btw osuosl will host smolder for us
19:18 allison particle: excellent!
19:18 * purl plays air guitar
19:18 particle i'm scheduling install for january
19:19 Whiteknight by that logic, we should rip out JIT too since it's got spotty platform coverage and isn't oft-tested
19:19 chromatic It's tested on platforms where it generates our NCI thunks.
19:19 pmichaud actually, I think JIT is the default build.
19:19 particle jit's a different beast
19:19 Coke works for me. I never use JIT. =-)
19:19 pmichaud (on platforms that support it)
19:20 allison Whiteknight: the JIT is good enough to keep
19:20 allison Whiteknight: we do have it on our roadmap for a substantial revamp later, though
19:21 chromatic LLVM++
19:21 allison chromatic: yes, that's one of our primary possibilities
19:22 chromatic There's also Adobe's Nanojit, if you like Forth and Python.
19:22 Coke gnu lightning?
19:24 rurban cd branches; svn up... D ... D ... Out of memory - terminating application. !!!
19:25 rurban I have experience with gnu lightning
19:25 rurban Our JIT is better
19:25 Whiteknight if cgp is gone, whats the next fastest core? switch?
19:26 chromatic Runcore overhead isn't our biggest performance problem by any means.
19:26 Whiteknight perhaps not, but it's not something we should ignore
19:26 Coke be nice to have callgrind output so we could know for sure.
19:27 Coke I'd rather make that a higher priority than keeping multiple runcors of undeterminate value.
19:29 Whiteknight particle, you going to create tickets for all the things that are slated for removal? Be good to take stock if there are a lot of things on the chopping block
19:29 allison Coke: yes
19:29 Coke (more tickets makes it easier to divvy up the work, also.)
19:34 ask- joined #parrot
19:48 rurban_ joined #parrot
19:48 Coke allison++ #ps
19:52 particle coke: DEPRECATED.pod is pretty big, looking now :(
19:52 Coke particle: imagine how much bigger it was!
19:53 Whiteknight let's hope this GC branch goes more smoothly now then it went over the summer
19:53 Coke +1
19:53 purl 1
19:53 Coke purl is also captain obvious
19:53 purl okay, Coke.
19:54 allison Whiteknight: breaking the changes down into small sets will certainly help
19:57 Whiteknight here's hoping
19:59 barney Is there a 'Recent changes' button in https://trac.parrot.org/parrot/wiki ?
20:00 particle https://trac.parrot.org/parrot/wiki/RecentChanges
20:04 particle how do we get parrot docs displayed on parrot.org?
20:04 particle should we have a cron job for make html?
20:05 Coke if we're going to put the docs on the site, we should have version #'d docs.
20:06 Coke have one for daily updates from trunk; have one that corresponds to the last devel and last stable release.
20:08 particle yes, agreed
20:09 Coke even just having trunk for now works, just need to make sure we leave a space for devel/stable
20:10 Coke if there's a space we could ftp the files to, we can setup a cron job on feather.
20:13 Coke particle: one down.
20:13 dalek r34284 | coke++ | trunk (5 files):
20:13 dalek : Eliminate [DEPRECATED] runtime/parrot/library/Parrot/Capture_PIR.pir
20:13 Coke here's something: experimental.ops should probably be empty at 1.0
20:13 dalek : was only referenced by one language, but it wasn't being used.
20:13 dalek review: http://xrl.us/6v5ny
20:19 particle looks like we can delete some non RELEASE_ tags... http://svn.perl.org/parrot/tags/
20:19 particle i hoped that "make release" included the html docs, but it seems it does not
20:19 particle which means we can't just pull them from the release tarballs :(
20:20 particle however, we can set up a dir at ftp.parrot.org for uploading docs
20:22 particle ftp-osl.osuosl.org actually
20:33 chromatic joined #parrot
20:34 Aisling joined #parrot
20:49 dalek r34285 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
20:49 dalek : [jit_h_files] move functions from the first part of the .h file to the .c file, along with a few duplicated macros. Compiles.
20:49 dalek review: http://xrl.us/6zm6w
20:50 Whiteknight we can change make release to include the docs/html targets
20:51 Coke chromatic: any gotchas ripping out PIC?
20:52 Coke (and/or the ops that rely on it?)
20:53 chromatic You break all predereferenced runcores.
20:53 chromatic Other than that, none.
20:53 chromatic I think you break JIT too.
20:53 Coke ah. breaking jit is bad, since I can't fix it.
20:54 Coke perhaps a branch on this one
20:54 Whiteknight branch++
20:56 dalek r34286 | coke++ | branches:
20:56 dalek : RT #60048. -  remove polymorphic inline cache.
20:56 dalek review: http://xrl.us/62eie
20:58 Coke chromatic: pic.ops should also go, neh?
20:58 chromatic I think that can go safely.
20:58 * Coke sees a bunch of references to PIC lying about in t/conf* tests.
20:59 chromatic That's probably the -fPIC flag for cc.
20:59 Whiteknight later
21:00 Coke chromatic: ... no, sadly.
21:00 Coke things testing ops generation that happened to refer to pic.ops.
21:02 dalek r34287 | chromatic++ | trunk (4 files):
21:02 dalek : [ops] Removed deprecated add_io_event opcode.
21:02 dalek review: http://xrl.us/62toq
21:02 chromatic So much for the triumph of hope over experience.
21:03 dalek r34288 | chromatic++ | trunk/config/auto:
21:03 dalek : [config] Added -funit-at-a-time to GCC flag detection to avoid inlining
21:03 dalek : warnings on GCC 4.3.x.
21:03 jan joined #parrot
21:03 dalek review: http://xrl.us/62wqr
21:04 Coke ... PIC has lots of hooks everywhere.
21:04 chromatic What doesn't?
21:04 chromatic Some of these features look like abstraction and encapsulation got drunk and vomited all over our source code.
21:07 * Coke is amazed how much of this code he has touched without understanding what it does.
21:07 Coke "remove B. build. does it compile? repeat."
21:10 Coke i haz a parrot that builds. running make test...
21:11 Coke remove pic is requiring deleting a LOT more than the two *.c files mentioned in the ticket.
21:11 Coke *removing
21:12 chromatic Yep.
21:16 Coke only 5 test failures in 'make test'.
21:16 chromatic Now try make testC
21:17 Coke committing first.
21:18 dalek r34289 | coke++ | branches/remove_pic (15 files):
21:18 dalek : First machete hack at removing PIC. 5 failures in 'make test':
21:18 dalek : t/pmc/packfile                          (Wstat: 512 Tests: 11 Failed: 2)
21:18 dalek :   Failed tests:  7, 9
21:18 dalek : t/run/options                           (Wstat: 768 Tests: 26 Failed: 3)
21:18 dalek :   Failed tests:  22-24
21:18 dalek review: http://xrl.us/64x3v
21:19 dalek r34290 | chromatic++ | trunk/src (2 files):
21:19 dalek : [JIT] Added checks for the return values of some system calls when writing
21:19 dalek : stabs files.
21:19 dalek review: http://xrl.us/64yrd
21:19 Coke I am not sure testC works on osx/intel anyway. does it?
21:20 Coke hurm. somewhat.
21:21 chromatic It should.
21:22 dalek r34291 | coke++ | branches/remove_pic/t/pmc:
21:22 dalek : don't expect PIC anymore.
21:22 dalek : He's gone to live at the farm.
21:22 dalek review: http://xrl.us/642gh
21:24 dalek r34292 | coke++ | branches/remove_pic/src:
21:24 dalek : eliminate some PIC that otherwise borks 'make testC'
21:24 dalek review: http://xrl.us/6445b
21:24 Coke running 'make testC' now; at least some tests are passing...
21:24 Coke (no failures yet.)
21:25 Coke do have a hang, though.
21:26 chromatic I'm not surprised.
21:27 chromatic You're probably not getting parameters in a function.
21:28 dalek r34293 | chromatic++ | trunk/src:
21:28 dalek : [src] Improved casts of functions loaded through Parrot_dlsym().  See RT
21:28 dalek : #61038 (reported by Jarkko Hietaniemi).
21:28 dalek review: http://xrl.us/65bcz
21:29 dalek r34294 | coke++ | branches/remove_pic/compilers/imcc:
21:29 dalek : remove apparently (now) unused struct member
21:29 dalek review: http://xrl.us/65d6m
21:30 Coke ok. I'm done with remove_pic for the next short while if someone wants to play cleanup.
21:31 Coke (that's about the limit of what I can remove without being forced to understand what I'm doing.)
21:31 chromatic Is make testC totally broken?
21:31 chromatic How about make testg?
21:32 Coke testC runs about 4 test files to completion before hanging.
21:33 Aisling joined #parrot
21:33 chromatic Figured.
21:33 Coke testg gets further.
21:33 chromatic Removing the PIC files altogether relegates just about every other runcore to the scrap heap of history.
21:34 Coke ... was that an expected result of removing src/pic.c ?
21:34 Coke it certainly seems to mesh with earlier discussions about removing things we don't use.
21:35 chromatic That's what I meant when I said "You're going to break every predereferenced runcore if you do that."
21:35 Coke Yes, but is that a problem?
21:35 Coke I'm happy to rip out code. =-)
21:35 Coke if you want to add a note to the ticket about which runcores this obviates, I can make an effort to kill them in the branch.
21:36 Coke (assuming this is the desired direction)
21:36 Coke testg seems to be fine, btw.
21:36 chromatic We haven't deprecated any runcores yet.
21:36 Coke but it follows logically from removing PIC, neh?
21:37 Coke If so, then lets get a ruling and throw it on the heap for removal right after january.
21:37 chromatic Only because the PIC implementation sucks in terms of encapsulation.
21:37 Coke ok. I don't have the brainz to fix it, just to kill it.
21:39 chromatic No one else understands it either.
21:39 chromatic Someone's going to have to dig into it and play around with it to do anything other than delete it.
21:39 ask_ joined #parrot
21:39 chromatic That doesn't have to be me.  In fact, it would be really nice if it weren't me.
21:39 Coke if we're talking about potentially eliminating other runcores, let's just rm it all.
21:40 Coke If no core committers have the time to maintain this, and we have a bunch of stuff to do before 1.0...
21:40 chromatic And it's not like the code is brilliant or clean enough that it's worth keeping around either.
21:41 chromatic Alright, I'm convinced.
21:41 Coke Could you write up a note to the list with a list of which cores would be affected by this?
21:42 Coke I can rip them all out in branch, which can then land after the january release.
21:42 chromatic Everything other than the default core, the nearly-useless profiling core, and the gc-debug core.
21:42 chromatic I'm not sure about the JIT core.
21:42 Coke well, I'd hate to break JIT, you know?
21:42 Coke (even though I can't use it myself.)
21:43 Coke ok. Given that, I'll write something up.
21:43 chromatic The JIT core doesn't really help us now.
21:43 dalek r34295 | chromatic++ | trunk (2 files):
21:43 dalek : [src] Fixed function decorations on unimplemented encoding functions to
21:43 dalek : demonstrate that they really do not return now.
21:43 dalek review: http://xrl.us/67cco
21:44 Coke is there JIT in the regular core?
21:44 chromatic On supported platforms, we use JIT to generate NCI thunks, rather than relying on the contents of src/nci.c.
21:45 Coke I'm not sure what that means, exactly, but it sounds like we can live without -j then.
21:46 chromatic We use JIT in the default core on certain platforms, but the JIT runcore doesn't add a lot.
21:46 chromatic It's messy, difficult to maintain, undocumented, and incomplete.
21:53 kid51 joined #parrot
22:02 Whiteknight joined #parrot
22:07 GeJ Good morning everyone
22:07 TiMBuS joined #parrot
22:08 chromatic Any objections to making Parrot IO PMCs upgrade to buffered mode when you peek on them?  I have a working patch.
22:11 dalek r34296 | Whiteknight++ | branches/pdd09gc_part1 (2 files):
22:11 dalek : [pdd09gc_part1] add the new GC to the makefile, and add it as an option to src/gc/memory.c
22:11 dalek review: http://xrl.us/7at9t
22:14 chromatic Can any Windows hacker run t/src/compiler.t without the skipall and tell me if we've fixed our linking problems?
22:15 nopaste "particle" at 76.121.106.245 pasted "rakudo spectest failure summary" (8 lines) at http://nopaste.snit.ch/15080
22:15 particle chromatic: i'll take a look now
22:15 dalek r34297 | chromatic++ | trunk/t/src:
22:15 dalek : [t] Removed a test of imcc_compile_pir() as Parrot_compile_string() does a much
22:15 dalek : better job and we already expose that anyway.  See RT #61154 for the
22:15 dalek : motivation.
22:15 dalek review: http://xrl.us/7ay6r
22:18 chromatic particle, how about also t/dynpmc/foo.t ?
22:19 particle i need to reconfig/build head first, but it's in the queue
22:20 chromatic Thanks.  I'm reviewing untouched tickets now.  Closed 2.
22:20 chromatic Have a patch for one, depending on if we can convince allison it's a good idea (which it is).
22:21 particle buffering stdin?
22:21 particle oh, any io
22:22 chromatic Exactly.
22:23 particle i've got a number of build warnings, some of which are probably easy fixes. wanna ticket?
22:24 chromatic I see a bunch of warnings too (building with -O2).  Let me start cleaning mine up, then I can work on yours.
22:25 particle ok, i'm linking now.
22:26 particle # compiler_5.obj : error LNK2001: unresolved external symbol _PMCNULL
22:27 particle still haven't resolved link errors on windows
22:28 chromatic I thought we exported PMCNULL.
22:28 chromatic Maybe we need the PMC_is_null() function there.
22:29 particle PMC_IS_NULL() is used in those tests
22:30 chromatic Swap that for PMC_is_null() and see if that helps.
22:31 particle same error, all tests
22:33 chromatic That's strange.
22:33 chromatic See include/parrot/interpreter.h:891.
22:33 chromatic Is that not the case on your machine?
22:34 particle #define PARROT_CATCH_NULL 1
22:35 particle #if PARROT_CATCH_NULL
22:35 particle PARROT_DATA PMC * PMCNULL;   /* Holds single Null PMC */
22:36 particle i'll try adding PARROT_EXPORT to that
22:36 chromatic Yes, but the source code of the test doesn't refer to PMCNULL at all.
22:36 dalek r34298 | Whiteknight++ | branches/pdd09gc_part1 (7 files):
22:36 dalek : [pdd09gc_part1] fix makefile, make headerizer, add a few macros, and a few small changes to get this bad boy to compile
22:36 dalek review: http://xrl.us/7cw4k
22:36 particle #if PARROT_CATCH_NULL
22:36 particle #  define PMC_IS_NULL(pmc) ((pmc) == PMCNULL || (pmc) == NULL)
22:37 chromatic Is that outside of the PARROT_IS_CORE guard?
22:38 chromatic Doesn't look like it.
22:41 particle 'tis not, indeed.
22:51 nopaste "donaldh" at 213.123.171.12 pasted "crash backtrace from perl6 code - recursive fail_if_type_exists for "Grammar"." (337 lines) at http://nopaste.snit.ch/15081
23:00 donaldh Not sure if my GC crash is actually a GC crash. Looks more like Rakudo misbehaving and causing GC to crash.
23:01 particle what's the source look like?
23:01 diakopter greek?
23:01 purl greek is probably nice too, I hear. or illlegible to idiots who can't read Greek. or illegible to geniuses who can't read Greek or greek to me
23:07 bacek_ joined #parrot
23:10 nopaste "donaldh" at 213.123.171.12 pasted "p6 source causing crash" (12 lines) at http://nopaste.snit.ch/15082
23:28 Theory joined #parrot
23:29 Zaba joined #parrot
23:30 dalek r34299 | chromatic++ | trunk/include/parrot:
23:30 dalek : [include] Removed a trailing comma in an enum, which picky C compilers hate
23:30 dalek : (reported by Jarkko).
23:30 dalek review: http://xrl.us/7im2p
23:40 donaldh Hmm. Bad memory profile for rakudo. A piece of PIR that runs a SQLite query and prints ~18000 rows maxes out at 6MB when run with -G. The equivalent in Rakudo maxes out at 1.6GB
23:42 donaldh s/maxes/tops/
23:43 particle left #parrot
23:44 chromatic PGE/PCT/Rakudo use more STRINGs and PMCs.  If you disable garbage collection, Parrot won't reuse them.
23:45 donaldh Sure. I'm just realising how much pressure Rakudo is putting on GC.
23:57 dalek r34300 | chromatic++ | trunk/src:
23:57 dalek : [src] Switched some bzero() system calls to use memset(), as the former is
23:57 dalek : deprecated.  While doing so, cleaned up some potential memory overflows thanks
23:57 dalek : to the wrong type used in a macro, and tidied some code.
23:57 dalek review: http://xrl.us/7na7g
23:58 pmichaud rakudo is somewhat constrained by the architecture Parrot provides, unfortunately.
23:59 dalek r34301 | pmichaud++ | branches/pctloop2/compilers/pct/src/PAST:
23:59 dalek : [pct]:  Switch 'for' to use loop_gen code.
23:59 dalek review: http://xrl.us/7nmhp

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

Parrot | source cross referenced