Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 darbelo Just to be sure: Reusing the destination is bad. Non-in-place operations should unconditionally pmc_new() themselves a place for the result.
00:01 NotFound I hate to sound like Yoda when wearing a Darth Vader T-shirt
00:02 darbelo "Sounding like yoda, I hate. When a Darth Vader t-shirt wearing I am"?
00:03 jonathan Change We Need.
00:03 purl jonathan: that doesn't look right
00:03 jonathan oh, wait..
00:04 NotFound darbelo: to be completely sure, we can ask for consensus at tomorrow #ps
00:06 NotFound Well, today in my localtime
00:06 pmichaud darbelo: that is the current interpretation of the add, sub, etc. opcodes for the standard Parrot PMCs, yes.
00:07 pmichaud It is _possible_ that the *dest parameter is being left in so that a different set of PMCs could (re)adopt the earlier interpretation.  I can imagine languages where that would be very useful.
00:08 bacek_ joined #parrot
00:10 darbelo It looked to me like bacek's last commits were heading in the opposite direction.
00:10 darbelo But that direction is the one I though parrot was supposed to be going in.
00:11 pmichaud re-using the destination PMC is very non-useful from a compiler perspective.
00:11 pmichaud for most languages that we work with, anyway.
00:11 NotFound darbelo: that's the problem I see. Having a dest parameter tend to suggest that intention.
00:12 pmichaud afk, taking family to dinner
00:12 darbelo But wouldn't PMC-reuse be a good thing, performace-wise?
00:12 pmichaud if I have a hll statement like
00:13 pmichaud my $i = (3 + $x) * 4
00:13 pmichaud which PMC gets the result of the (3 + $x) ?
00:13 pmichaud it's a temporary value
00:13 darbelo Yes, when provided a non-reusable dest, add can allocate a new one.
00:14 pmichaud but how do we know if the dest is re-usable or not?
00:14 darbelo in this case PMCNULL
00:14 NotFound I think that in most cases where you want to reuse the clean solution is to use the inplace ops
00:14 pmichaud in other words, I'd have to null out the register before calling the 'add'
00:15 darbelo Why null a register? All unused $Pn are PMCNULL
00:15 pmichaud I might want to re-use a PMC register.
00:15 pmichaud rather than have every option go to its own PMC register.  That eats up memory unnecessarily.
00:15 pmichaud s/option/operation
00:15 pmichaud clearly we can do a lot better than current code, where some subroutines end up with 1000 PMC registers being used
00:15 pmichaud gotta run -- will chat more later/tomorrow
00:16 darbelo ok.
00:16 cotto chromatic has once again awakened my desire for pie.
00:17 darbelo pie? where? I want some too!
00:17 * darbelo wants his piece of the pie.
00:21 xenoterracide joined #parrot
00:25 cotto http://www.economist.com/research​/styleGuide/index.cfm?page=673903 makes me sad, and I haven't even gotten past the "A" section.
00:25 dalek rakudo: 3f839b2 | jnthn++ | src/pmc/perl6multisub.pmc:
00:25 dalek rakudo: Improve Perl6MultiSub's caching. The main performance win is that we can cache multi-method dispatch requests as well as multi-sub dispatch ones. We also lazily create the MMD caches so we don't allocate them at all for multis that never get invoked (was cheap anyway so a very minor win). Finally, we cache a little later, so that if we get down to one candidate through an C<is default> then sometimes we cna cache that result too.
00:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​f839b2806b7e9f57e5b772a952593fbb7eb8b87
00:25 dalek rakudo: 24460c8 | jnthn++ | :
00:25 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
00:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​4460c8df76860a9b65499bf264adf4fe180d944
00:26 cotto darbelo, in chromatic's post on the Modern Perl blog
00:31 dalek rakudo: d396ab4 | jnthn++ | src/pmc/perl6multisub.pmc:
00:31 dalek rakudo: One for change that git decdied it'd rather forget about. *sigh*
00:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​396ab4231107f37dcf0a5d9ecdebce602a454a6
00:32 GeJ Hello all.
00:32 purl It's a crazy world, but hello to you too!
00:35 GeJ FYI, in parrot/src/oo.c on line 390 there is a trailing space. Without it `make fulltest` PASSes everything.
00:37 GeJ should I create a TT for this?
00:45 cotto GeJ, it's an easy fix.  I'll take it.
00:45 kid51_afk cotto:  I just got it.
00:45 cotto I just noticed that it wasn't there.
00:47 dalek parrot: r39313 | jkeenan++ | trunk/src/oo.c:
00:47 dalek parrot: No trailing spaces. GeJ++.
00:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39313/
01:00 jsut joined #parrot
01:20 dalek parrot: r39314 | whiteknight++ | branches/io_rewiring (5 files):
01:20 dalek parrot: [io_rewiring] changes from the weekend. Convert the read and write methods. Lots of fixes throughout
01:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39314/
01:33 rhr joined #parrot
01:41 japhb joined #parrot
02:40 snarkyboojum joined #parrot
02:41 janus joined #parrot
02:51 Rhysyngsun joined #parrot
02:57 Andy joined #parrot
03:03 Theory joined #parrot
03:20 donaldh joined #parrot
03:29 dukeleto joined #parrot
03:30 dukeleto_ joined #parrot
03:32 darbelo joined #parrot
03:43 tetragon joined #parrot
04:05 dukeleto joined #parrot
05:14 snarkyboojum left #parrot
05:15 snarkyboojum joined #parrot
05:38 dukeleto joined #parrot
05:46 Theory joined #parrot
06:47 HG` joined #parrot
07:11 iblechbot joined #parrot
07:20 donaldh joined #parrot
07:36 barney joined #parrot
07:52 dalek parrot: r39315 | cotto++ | trunk/examples/languages/a​bc/src/parser/actions.pm:
07:52 dalek parrot: [abc] update abc actions (and inline comments) to use $foo.ast instead of $($foo)
07:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39315/
07:52 cotto that was quick
07:53 muixirt joined #parrot
07:53 Zak joined #parrot
08:00 muixirt anyone here with some knowledge about the runcores?
08:01 cotto define "knowledge"
08:02 muixirt cotto, do you know what the difference is between them?
08:02 cotto it's about how Parrot runs each opcode
08:03 cotto e.g. in the profiling runcore, Parrot keeps track of how much time is spent on each opcode
08:04 muixirt and what is  the difference between fast (afaik the default) and, let's say, cgoto
08:07 cotto fast vs cg vs cgp is about the low-level details.  fast is a simple while loop, cg uses computed gotos, cgp does that plus predereferencing, which I don't quite understand
08:07 * muixirt looks at src/runcore/main.c but isn't a C coder
08:08 cotto the interesting code (well, part of it) is in src/runcore/cores.c
08:08 cotto runops_fast_core, runops_cgoto_core, etc
08:09 muixirt predereferencing means to lookup the code address of the opcode before entering the run loop?
08:10 cotto that sounds consistent with my limited understanding
08:12 muixirt i was wondering how llvm fits in, that gsoc project
08:12 cotto it doesn't, yet
08:12 muixirt and i wonder where the benefit lies
08:13 cotto I think the long-term plan is to rewrite much of Parrot (PMCs and ops) in an intermediate language that can be compiled down to llvm bytecode or C.
08:13 cotto l1?
08:13 purl l1 is probably a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550 or http://rt.perl.org/rt3/Ticket/D​isplay.html?id=39313#txn-471982
08:14 cotto but that won't happen for a while
08:16 cotto tewk's gsoc project is just the next step
08:17 cotto assuming he ever shows up and starts on it ;)
08:19 cotto The benefit in using llvm as the jit backend is that we don't have to bother maintaining lots of fragile and one-off per-cpu jit code.
08:19 cotto s/The/A/
08:20 cotto it'll also give us llvm's optimizations for free
08:21 cotto is that what you were hoping to find out?
08:22 muixirt my understanding is that clang compiles those ops and the llvm engine executes the results, but i don't see any benefits
08:23 muixirt cotto, just a better understanding
08:26 cotto The eventual goal is to turn HLL code into llvm bytecode.  Using clang just means that Parrot's running llvm bytecode, rather than generating it.
08:29 muixirt the goal of jit is to eliminate code address lookups, call/branch and return/jump instructions
08:31 muixirt compiling ops with clang doesn't necessarily eliminate this overhead
08:32 mikehh joined #parrot
08:33 muixirt is clang produced llvm bytecode faster than gcc produced native code?
08:38 cotto I don't remember what the result was.  It'd be fairly easy to test.
08:39 cotto either way, I'm off to bed.  night
08:39 muixirt good night, and thanks
08:42 bacek joined #parrot
08:46 bacek oh hai
08:47 muixirt hi bacek
08:49 bacek hi muixirt
08:50 muixirt bacek, can you explain to me the benefits of the upcoming? llvm integration
08:50 dalek parrot: r39316 | bacek++ | branches/no_pmc_reuse:
08:50 dalek parrot: Branch for clean-up 3-args arithmetic PMCs ops
08:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39316/
08:50 bacek Get JIT for free?
08:51 muixirt i bothered cotto already, see http://irclog.perlgeek.de/p​arrot/2009-06-02#i_1202561
08:58 bacek muixirt: Sorry, I cant help with. I didn't follow llvm gsoc project.
08:59 muixirt ok
09:10 dalek parrot: r39317 | bacek++ | trunk/src/pmc/scalar.pmc:
09:10 dalek parrot: [pmc][cage] Don't reuse dest in Scalar.subtract.
09:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39317/
09:10 dalek parrot: r39318 | bacek++ | trunk/src/pmc/bigint.pmc:
09:10 dalek parrot: [pmc] Don't reuse dest in BigInt.
09:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39318/
09:10 bacek oh shi...
09:10 bacek (git svn)--
09:13 dalek parrot: r39319 | bacek++ | trunk/src/pmc/integer.pmc:
09:14 dalek parrot: [pmc] Don't reuse dest in Integer
09:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39319/
09:14 dalek parrot: r39320 | bacek++ | trunk (2 files):
09:14 dalek parrot: [core] Remove Parrot_pmc_try_reuse function. It's dangerous to reuse dest pmc.
09:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39320/
09:14 dalek parrot: r39321 | bacek++ | trunk/src/pmc/bignum.pmc:
09:14 dalek parrot: [pmc] No pmc_reuse in BigNum
09:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39321/
09:20 dalek parrot: r39322 | bacek++ | trunk/src/pmc/bigint.pmc:
09:20 dalek parrot: [pmc] Fix typo in BigInt.
09:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39322/
09:20 dalek parrot: r39323 | bacek++ | trunk/t/op/arithmetics.t:
09:20 dalek parrot: [t] Add initial test for 3-args arithmetic dest handling.
09:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39323/
09:20 dalek parrot: r39324 | bacek++ | branches/no_pmc_reuse:
09:20 dalek parrot: Remove branch. bacek-- for unconscious.
09:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39324/
09:33 dalek parrot: r39325 | bacek++ | trunk (6 files):
09:33 dalek parrot: Revert last 6 commits. They doesn't belong to trunk. bacek--
09:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39325/
09:37 dalek parrot: r39326 | bacek++ | branches/no_pmc_reuse:
09:37 dalek parrot: Branch for clean-up 3-args arithmetic PMCs ops
09:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39326/
09:40 dalek parrot: r39327 | bacek++ | branches/no_pmc_reuse/src/pmc/bigint.pmc:
09:40 dalek parrot: [pmc] Don't reuse dest in BigInt.
09:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39327/
09:43 dalek parrot: r39328 | bacek++ | branches/no_pmc_reuse/src/pmc/integer.pmc:
09:44 dalek parrot: [pmc] Don't reuse dest in Integer
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39328/
09:44 dalek parrot: r39329 | bacek++ | branches/no_pmc_reuse (2 files):
09:44 dalek parrot: [core] Remove Parrot_pmc_try_reuse function. It's dangerous to reuse dest pmc.
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39329/
09:44 dalek parrot: r39330 | bacek++ | branches/no_pmc_reuse/src/pmc/bignum.pmc:
09:44 dalek parrot: [pmc] No pmc_reuse in BigNum
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39330/
09:44 dalek parrot: r39331 | bacek++ | branches/no_pmc_reuse/t/op/arithmetics.t:
09:44 dalek parrot: [t] Add initial test for 3-args arithmetic dest handling.
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39331/
09:56 gaz joined #parrot
10:01 viklund joined #parrot
10:12 Maddingue joined #parrot
10:32 riffraff joined #parrot
10:39 riffraff in PAST what is the best way to retrieve a function object installed with PAST::Block.new(:name('foo'), :blocktype('declaration') )?
10:39 riffraff I know we have find_name in pir but I0m not sure what should happen in my grammar.pm
10:40 jonathan riffraff: To call it or to just get hold of it?
10:40 jonathan If the second, PAST::Var.new( :name('foo'), :scope('package') )
10:42 riffraff no to get hold of it, I am tryng to make my language pass function  objects around with a &foo syntax
10:42 riffraff so I guess ot shoukd work :)
10:44 riffraff IIRC I can later cal it by passing it as first arguiment to a PAST::Op :pasttype('call')
10:44 jonathan Yes.
10:45 jonathan And be sure not to set :name
10:45 jonathan If there's no name set on the PAST::Op and it's a call pasttype then it'll use the first child as the thing to call.
10:48 dalek parrot: r39332 | bacek++ | branches/no_pmc_reuse/t/op/arithmetics.t:
10:48 dalek parrot: [t] Generate tests for 3-args arithmetic dest handling.
10:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39332/
10:48 dalek parrot: r39333 | bacek++ | branches/no_pmc_reuse/t/op (2 files):
10:48 dalek parrot: [t] Move arithmetics tests for PMCs into t/op/arithmetics_pmc.t. Also
10:48 dalek parrot: properly handle absence of BigInt and BigNum.
10:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39333/
10:50 riffraff thanks, I had this working in my tiny language (i am now writing a new one) but I had forgotten how I got it :)
10:51 jonathan :-)
10:55 iblechbot joined #parrot
10:56 masak joined #parrot
11:15 masak Juerd wants me to submit as a bug that Rakudo can't compile on feather.
11:16 masak is there already such a bug? ISTR there is.
11:21 donaldh joined #parrot
11:22 burmas joined #parrot
12:02 Whiteknight joined #parrot
12:10 whoppix joined #parrot
12:14 patspam joined #parrot
12:29 riffraff mh, I uncovered a bug in my code: I am always defining functions in the package scope even though syntax wise they appear as nested functions, they work as closures if called from inside the surrounding function but are still available globally
12:29 riffraff shall I use :pirflags( to spcify an outer subid?
12:31 riffraff mh no, looking at pir it seems set up correctly
12:33 bkuhn joined #parrot
12:38 cognominal joined #parrot
12:58 ruoso joined #parrot
12:58 snarkyboojum joined #parrot
13:01 jonathan riffraff: It should set things up correctly for you automatically, yes. :-)
13:09 Util masak: 2 minutes ago, I built Rakudo on Feather.
13:09 Util 3m08s for `perl Configure.pl --gen-parrot`
13:09 Util 1m13s for `make`
13:09 Util 0m38s for `make test`
13:09 Util All successful.
13:09 Util `make spectest` has only completed through S02, but all are passing except S02-lexical-conventions/unicode.t
13:09 Util masak: What issue are you having with the Rakudo build (that you referred to 1hour50minutes ago)?
13:09 burmas left #parrot
13:11 gryphon joined #parrot
13:15 Util masak: if it is the "out of memory" issue, I think that r39176 (TT #688) resolved it for all GCC platforms, including Feather.
13:18 payload joined #parrot
14:08 Andy joined #parrot
14:21 riffraff jonathan, yeah it seems to setup :outer correctly. Still, the inner function appears to be available in the top scope
14:21 jonathan Yes, it is still installed as a symbol in the namespace
14:21 jonathan If you want a lexically scoped name you'll need to do something a little different.
14:23 riffraff you mean declaring it straight as a variable?
14:23 riffraff and then do explicitly do the lookup/calling machinery myself?
14:24 riffraff s/do the/the/
14:24 riffraff I guess the principle of least surprise centered on me would love a :scope() keyword on block definitions :)
14:28 jonathan Hmm
14:28 jonathan When I did this in Rakudo I think I did something like:
14:29 jonathan PAST::Op.new( :pasttype('bind'), PAST::Var.new( :name('foo'), :scope('lexical'), :isdecl(1) ), ...the block here and don't set its name... )
14:29 jonathan That is, make the block anonymous by not setting a name (make sure blocktype is declaration)
14:29 jonathan And bind it to a lexical.
14:30 particle joined #parrot
14:30 masak joined #parrot
14:31 riffraff yes it's what I was thinking thanks again
14:41 barney joined #parrot
14:43 Theory joined #parrot
14:47 pmichaud easier is to bind it directly
14:48 pmichaud PAST::Var.new( :name('mysub'), :isdecl(1), :viviself( ...past block here ... ) )
14:51 jonathan The viviself is certain to get run?
14:51 jonathan OK.
14:51 payload joined #parrot
14:54 dalek parrot: r39334 | barney++ | trunk/runtime/parrot/library/pcre.pir:
14:54 dalek parrot: [doc] The sub init() in nowadays in the namespace PCRE?
14:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39334/
15:06 pmichaud yes, viviself is certain to be run because it's a isdecl
15:06 pmichaud (actually, viviself is always run on any uninitialized symbol)
15:06 PacoLinux joined #parrot
15:06 pmichaud (the isdecl forces the bind)
15:07 jonathan Ah, ok
15:07 jonathan Neat.
15:10 Tene Hey, do we have any parroters in Pittsburgh?
15:10 particle not for a few weeks still :)
15:11 Tene Sure would have been nice if this class was a few weeks in the direction.
15:12 * pmichaud doesn't parse that.
15:12 pmichaud actually, it parses okay, but my semantic analyzer is totally confused :-)
15:12 particle it'd be nice if tene's class was closer to yapc::na
15:12 pmichaud ah, thanks.
15:12 purl ah, thanks. is it fast enough?
15:13 particle ah, thanks. is <reply>
15:14 Tene I thought about going, but iirc it was poorly timed for me.
15:14 particle oh, sorry you won't be there :(
15:16 Tene probably next year, though.
15:20 Tene I was pretty sure we had someone who lived there, though...
15:21 donaldh joined #parrot
15:21 particle jhorwitz and whiteknight are close to philly, but i don't know any parrot hackers in pit
15:21 Whiteknight yeah, I'm "close" but a few hours away
15:23 barney http://www.frappr.com/parrotcoders show nobody, but is probably not current
15:24 dalek parrot: r39335 | NotFound++ | trunk (4 files):
15:24 dalek parrot: [cage] kill include config.pir usages and example
15:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39335/
15:25 * muixirt is away: bbl
15:26 dalek rakudo: d03217d | pmichaud++ | docs/spectest-progress.csv:
15:26 dalek rakudo: spectest-progress.csv update: 395 files, 11346 passing, 2 failing
15:26 dalek rakudo: Failure summary:
15:26 dalek rakudo:     S02-lexical-conventions/unicode.rakudo aborted 2 test(s)
15:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​03217d71d60e9038360bc2d8930fca70acb60a1
15:30 dalek parrot: r39336 | NotFound++ | trunk/t/compilers/json/from_parrot.t:
15:30 dalek parrot: [cage] kill include JSON.pir usage in tests
15:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39336/
15:44 dalek rakudo: 63cc77c | masak++ | src/setting/Any-str.pm:
15:44 dalek rakudo: [src/setting/Any-str.pm] a new, shorter .bytes implementation
15:44 dalek rakudo: Patch submitted by Klaus Bruessel (Muixirt++).
15:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​3cc77c5dd0949d5281798db4e14c3d7aa3c917a
15:58 NotFound loadlib search logic is dramatically failed
16:00 darbelo joined #parrot
16:12 iblechbot joined #parrot
16:18 pmichaud #parrotsketch in 132
16:19 Austin_Hastings joined #parrot
16:31 HG` joined #parrot
16:34 estrabd joined #parrot
16:40 HG`` joined #parrot
16:54 dalek parrot: r39337 | NotFound++ | trunk (2 files):
16:54 dalek parrot: [core] quick-fix libtcl loading
16:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39337/
16:54 hudnix joined #parrot
17:00 dalek parrot: r39338 | NotFound++ | trunk/examples/tcl/tcltkdemo.pir:
17:00 dalek parrot: [cage] kill include TclLibrary.pir usage in example
17:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39338/
17:30 semar joined #parrot
18:01 AndyA joined #parrot
18:11 mberends joined #parrot
18:17 dalek partcl: r412 | coke++ | trunk/lib/Parrot/Test/Tcl.pm:
18:17 dalek partcl: Close the output file so that ./parrot can write to it safely.
18:17 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=412
18:22 dalek partcl: r413 | coke++ | trunk/t/cmd_cd.t:
18:22 dalek partcl: be a little more lenient on the homedir check.
18:22 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=413
18:22 dalek partcl: r414 | coke++ | trunk/ (3 files):
18:22 dalek partcl: ignore generated files
18:22 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=414
18:25 jhorwitz joined #parrot
18:27 jonathan j/oin #parrotsketch
18:27 allison joined #parrot
18:31 chromatic joined #parrot
18:38 allison moritz always shows up as gray in Chatzilla, not sure why
18:41 Util NotFound++ # for prompt work last week on TT#710 and TT#717. Thanks much!
18:42 NotFound Util: thanks
18:44 Whiteknight allison: page 61 of the book PDF has a typo "c<add_one>" is visible
18:44 purl Sorry, I don't know 61's email address.
18:44 NotFound Util: I don't think about the fix for TT #710 as a workaround: The implementation can be improved, though.
18:44 dalek parrot: r39339 | coke++ | trunk/src/pmc/coroutine.pmc:
18:44 dalek parrot: [docs] make the docs match the pmclass declaration
18:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39339/
18:45 Util NotFound: I agree. I oversimplified in my #ps report.
18:45 NotFound No prob
18:45 pmichaud Coke:  Can you confirm that TT #715 has been fixed for you?
18:47 Whiteknight allison: Also, on page 79 the section is titled "GARBAGE", which I think is an error
18:48 pmichaud On TT report 16, can we add the "owner" column?
18:48 pmichaud where "we" means "someone other than me"
18:49 Util pmichaud: I will add it to TTR 16
18:49 pmichaud Util++  # thanks
18:52 Util pmichaud: done, and yw
18:56 allison Whiteknight: yes, that's the chapter I'm not quite done with yet
19:00 * allison spilled breakfast all over the counter and had to clean it up, back
19:03 particle don't cry, it looks like milk, but it's only soy milk.
19:03 pmichaud ...breakfast?
19:03 * pmichaud wonders what tz allison++ is in at the moment :-)
19:04 japhb joined #parrot
19:09 david joined #parrot
19:11 allison pmichaud: notionally in Pacific time, but I work better at night, so tend to live timeshifted
19:11 pmichaud :-)
19:11 pmichaud My system wants to do the same, but kids tend to blow that to pieces.  So I tend to live sleep-deprived.  :-)
19:13 * Tene the same, module s/kids/work/
19:14 dalek TT #732 created by coke++: Coroutine contexts not getting freed
19:14 radish joined #parrot
19:20 donaldh joined #parrot
19:32 afk_coke joined #parrot
19:37 iblechbot joined #parrot
19:40 Maddingue joined #parrot
19:41 chromatic Ah, found one context leak in Coroutine.
19:45 gryphon joined #parrot
19:54 chromatic Hm, Hello, World in PBC is suddenly more expensive.
19:56 allison chromatic: after fixing the leak?
19:56 chromatic This only measures startup time, no leaks.
19:56 chromatic It wasn't precisely a leak either, just double-marking a context as alive.  That could be spendy.
19:58 NotFound Looks like assign_pmc in Sub does not unref his context
19:58 NotFound And does not ref the assigned one
20:00 chromatic That might do it.
20:05 dalek parrot: r39340 | chromatic++ | trunk/src/pmc/coroutine.pmc:
20:05 dalek parrot: [PMC] Fixed Coroutine PMC's mark vtable entry to avoid unnecessary work (such
20:05 dalek parrot: as marking its context twice, once here and once in Sub's mark).
20:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39340/
20:05 dalek parrot: r39341 | chromatic++ | trunk/src/pmc/eventhandler.pmc:
20:05 dalek parrot: [PMC] Simplified EventHandler PMC's mark vtable entry (reusing its parent) and
20:05 dalek parrot: removed an unnecessary destroy vtable entry (reusing its parent).
20:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39341/
20:09 dalek parrot: r39342 | NotFound++ | trunk/include/parrot/sub.h:
20:09 dalek parrot: [cage] drop spurious semicolon after do ... while (0) macro guard
20:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39342/
20:18 chromatic There's one.
20:19 dalek parrot: r39343 | chromatic++ | trunk/src/pmc/sub.pmc:
20:19 dalek parrot: [PMC] Fixed context reference count updating in assign_pmc vtable (kudos to
20:19 dalek parrot: NotFound for diagnosing the problem).
20:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39343/
20:22 particle NotFound++ doesn't want kudos, he wants karma!
20:23 NotFound All your karma are belong to me!
20:23 chromatic karma NotFound
20:23 purl notfound has karma of 340
20:23 chromatic karma chromatic
20:23 purl chromatic has karma of 2043
20:23 chromatic Ah, I see.
20:23 particle karma particle
20:23 purl particle has karma of 1540
20:24 particle particle has been lazy
20:29 dalek decnum-dynpmcs: r73 | darbelo++ | trunk/src/pmc/decnum.pmc:
20:29 dalek decnum-dynpmcs: It looks like reusing dest wasn't such a good idea fter all.
20:29 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=73
20:31 Austin_Hastings joined #parrot
20:32 Austin_Hastings Guten abend, #parrot.
20:36 dalek parrot: r39344 | chromatic++ | trunk/src/pmc/sub.pmc:
20:36 dalek parrot: [PMC] Fixed context refcounts in Sub's clone vtable entry.
20:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39344/
20:44 * muixirt is back (gone 05:19:15)
20:48 chromatic Coroutine probably leaks context refs in its clone too.
20:50 NotFound chromatic: That clone change will not double free the context when original and clone gets destroyed?
20:51 chromatic It shouldn't; the ref count on the original's contexts increases too.
20:51 eternaleye joined #parrot
20:55 NotFound The clone function do +1 and -1. Destruction of both is -1 -1. Supposing the initial count was 1, the result is -1
20:57 dalek rakudo: fc01cda | jnthn++ | tools/benchmark.pl:
20:57 dalek rakudo: Add postfix:<++> test to the set of benchmarks.
20:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​c01cdaea0ad648a5390bcedf78ce02f9930b5a6
20:57 chromatic It's -1 to the destination's previous contexts, +1 to the destination's new contexts.
20:59 NotFound Ah, the pmc_new'ed can have contexts, I see now.
20:59 chromatic It may or may not.
21:01 NotFound chromatic: in assign_pmc outer_ctx must not also be increased/freed ?
21:03 chromatic I'm not sure.
21:03 NotFound And BTW, it has no protection against self assign.
21:04 chromatic In which case it could free its own context and BOOM.
21:04 chromatic True.
21:04 NotFound We can either add the protection, of add ref before freeing
21:05 chromatic The latter sounds simpler, though worth a comment.
21:07 NotFound Must go now. I'll do tomorrow if you don't before.
21:08 chromatic I'm trying to track down the memory leak of Parrot_sub attributes in the Sub PMC.
21:08 chromatic Something overwrites them.
21:12 jonathan chromatic: Not just assign?
21:13 jonathan chromatic: And which ones is it overwriting?
21:17 chromatic I can't tell which ones.
21:17 chromatic assign_pmc looks like it does the right thing.
21:17 chromatic So does clone.
21:18 jonathan Are we leaking the entire attribute strucutre?
21:18 jonathan Or just some things referenced by it?
21:19 chromatic The entire attribute structure.
21:19 jonathan OK.
21:19 chromatic Something replaces Sub's PMC_data wholeheartedly.
21:19 jonathan A sub can magically become a Closure, could that be the source of the issue?
21:19 jonathan Oh, wait, not a Closure
21:19 chromatic Let me check the Closure PMC.
21:19 jonathan I think Closure PMC went away?
21:19 chromatic You're right.
21:20 jonathan oh!
21:20 jonathan I was thinking just of this line
21:20 jonathan ccont->vtable = interp->vtables[enum_class_Continuation];
21:20 jonathan Which is a vtable swap but probably not what we look for.
21:21 chromatic The Sub remains a Sub.
21:23 jonathan chromatic: This might be a bit off
21:23 jonathan In get_string we do
21:24 jonathan Parrot_sub *sub;
21:24 jonathan PMC_get_sub(INTERP, SELF, sub);
21:24 jonathan In destory we do
21:24 jonathan Parrot_sub *sub;
21:24 jonathan GET_ATTR_sub(INTERP, SELF, sub);
21:24 jonathan Are those two macros really doing the same thing?
21:24 jonathan (this is in sub.pmc)
21:25 chromatic I believe so.
21:25 jonathan yeah, looks like it to me too
21:26 jonathan Just felt like a slight red flag...
21:26 jonathan Two different macros for something that looks like it's the same thing.
21:27 jonathan chromatic: Are you observing this only with Rakudo, or in Parrot generally?
21:27 chromatic Partcl has it too.
21:27 jonathan Ok.
21:28 chromatic 0xb78ec670 0x9da88b0 Sub D
21:28 chromatic 0xb78ec670 0xa195598 Sub N
21:28 chromatic The first pointer is the PMC, the second is the sub attribute.
21:28 chromatic The name is the PMC type and the character is Destruction or New.
21:28 chromatic Somewhere in between creation and destruction, that PMC's sub attribute changed.
21:30 dalek pynie: r69 | isop44++ | trunk/ (4 files):
21:30 dalek pynie: list comprehensions
21:30 purl list comprehensions are lovely.
21:30 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=69
21:33 chromatic It's a Sub PMC created through Class's instantiate (and PMCProxy's instantiate) though.
21:35 dalek pynie: r70 | isop44++ | trunk/Lib/test/parrot/listcomps.py:
21:35 dalek pynie: Add another list comprehension test
21:35 jonathan They create Sub PMCs? Oh, hmm
21:35 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=70
21:36 chromatic If you've subclassed Sub, yes.
21:37 jonathan Rakudo certainly does that.
21:38 chromatic It'd be a lot easier to debug this if I had a 15 line PIR program which subclassed Parrot's Sub PMC and instantiated an instance of that... hint hint.
21:38 chromatic I tried writing one myself but somehow failed.
21:38 chromatic Mr. Bender, your son has what we call "stupid fingers".
21:39 jonathan Hmm, moment then. :-)
21:40 Limbic_Region joined #parrot
21:42 Theory joined #parrot
21:43 nopaste "jonathan" at 85.216.157.73 pasted "for chromatic" (18 lines) at http://nopaste.snit.ch/16770
21:43 jonathan chromatic: Are any of those two interesting?
21:43 chromatic No leaks there.
21:44 jonathan Damm.
21:44 chromatic Rakudo must do something more interesting.
21:44 jonathan Yes, probably.
21:44 purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look  Because \ an asshole.
21:44 jonathan Let me look.
21:46 jonathan chromatic: ah yes
21:46 jonathan So we call !fixup_routine_type to re-bless a block into its new class.
21:47 nopaste "jonathan" at 85.216.157.73 pasted "!fixup_routine_type" (17 lines) at http://nopaste.snit.ch/16771
21:47 jonathan It does that.
21:47 jonathan rebless_subclass is a dynop.
21:47 jonathan It would be the first thing I'd blame.
21:47 jonathan Apart from, you mentioned tcl also has the issue, and that dynop is Rakudo specific...
21:47 chromatic That doesn't explain why Tcl has a similar problem....
21:48 jonathan Right.
21:48 particle similar, or same?
21:48 jonathan But that's how we tend to go from Parrot sub to a Rakudo one.
21:48 chromatic Hm, no.
21:48 chromatic Tcl and Rakudo have a similar problem losing contexts to invoke, but not this problem.
21:49 Limbic_Region hmm - been several months since I have touched parrot/rakudo and have subsequently built a new machine.  Anyone mind if I play the part of "dumb new user" which isn't too far from the truth?
21:50 chromatic Please go ahead.
21:50 jonathan chromatic: rebless_subclass would almost certainly result in that pointer being changed.
21:50 Whiteknight joined #parrot
21:50 particle dumb old user masquerading as a dumb new user
21:50 chromatic Isn't this code you said "I don't want to touch it, because it's haunted and it will eat my brains?"
21:50 jonathan chromatic: Yes.
21:51 bacek joined #parrot
21:51 chromatic Then I need food first.
21:51 Limbic_Region Ok - http://www.parrot.org/download  doesn't really go into what to do after a checkout - what tools need to be present on the system to even build (Win32 here) or optionally what libraries might be helpful (ICU, GMP, etc)
21:51 particle chromatic: your lack of brains can help you here
21:51 Limbic_Region is there another place I should be looking?
21:52 particle Limbic_Region: that's what README has been for, traditionally
21:52 chromatic Yes, but L~R has a point.
21:52 particle makes sense to put the info on the web
21:52 particle much friendly for dumb new users
21:52 Limbic_Region a truly novice would likely reach for the binary
21:53 Limbic_Region but I am thinking someone that is a perl programmer that wants to try their hat at Rakudo might assume they should be able to figure it out
21:53 Limbic_Region knowing that they have to go get MinGW or have MSVC++ before they can even do anything might be an eye opener
21:54 Limbic_Region Is the svn repo browserable?  I would like to read the README
21:55 chromatic https://svn.parrot.org/parrot/trunk/README.
21:55 chromatic no dot on the end
21:55 * Whiteknight keeps seeing reasons why contexts should be garbage collectable
21:56 Whiteknight I have a dream, a dream of a world where contexts clean up their own damn selves
21:56 chromatic jonathan, the problem is on line 95; it overwrites PMC_data.
21:57 pmichaud in my experience, the README file is the one that is guaranteed not to ever be read.  :-)
21:57 Limbic_Region oh, make needs to be listed as a pre-requisite - Windows XP doesn't ship with a make.exe, not even the old 1.x version
21:57 jonathan chromatic: Ah, I think I see what's going on.
21:58 Ademan joined #parrot
21:58 jonathan chromatic: Well, yes, the point of the op is to do just that.
21:58 jonathan chromatic: But the PMC_data in question shoulda been copied somewhere else.
21:58 jonathan Thing is, I think it misses something...
21:58 Whiteknight jonathan and chromatic: where are you guys looking?
21:58 chromatic Rakudo's custom ops; rebless_subclass.
21:59 jonathan Damm, this hurts my head... :-/
21:59 Limbic_Region oh, wait - nevermind, the Readme_Win32.pod is adequate
22:00 Whiteknight oh yeah, I've looked at that code before. Evil
22:01 jonathan Tell me about it.
22:01 purl rumour has it it is not
22:01 Limbic_Region ok - other than suggesting perhaps link to the readme's from the download page, I return you to your regularly scheduled programming
22:02 jonathan ooh
22:02 jonathan oh, wait, no.
22:03 * jonathan keeps thinking he's spotted a problem and then realizes, no, that's right...
22:03 jonathan (I think we were disassociating vtable and pmc_data but we ain't, we copy the bunch of pointers all together.)
22:06 chromatic Overwriting the pointers in the instantiated proxy seems wrong.
22:07 Theory joined #parrot
22:07 jonathan How so?
22:07 jonathan We are doing a shuffle-around, but in the end we get three PMCs still.
22:09 jonathan (The pointers from the instantiated proxy, end up in what was new_ins, which should then get GC'd later on.)
22:09 GeJ Good morning everyone.
22:09 Whiteknight good morning GeJ
22:10 Util What PASM or PIR is equivalent to Perl 5's `$foo = -s 'MyFile'`?
22:10 Util Good morning GeJ
22:10 Whiteknight what is -s again?
22:10 Util filesize
22:10 purl filesize is probably 75K
22:11 Whiteknight There is a filestat method somewhere, I think
22:11 Whiteknight purl forget it
22:11 purl Whiteknight: I forgot it
22:11 Whiteknight purl forget filesize
22:11 purl Whiteknight: I forgot filesize
22:11 Whiteknight I mean fstat
22:17 Util Whiteknight: thanks, that got me heading in the right direction. stat() is in io.ops.
22:18 Whiteknight ah, that's what I was thinking about
22:19 dalek rakudo: 50f15ae | pmichaud++ | src/parser/ (2 files):
22:19 dalek rakudo: Clean up handling of self-accessors and parameters.  Fixes RT #61988.
22:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​0f15ae96c37ccfa42beee5effbadca0aaa0f715
22:19 dalek rakudo: c907d37 | pmichaud++ | :
22:19 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
22:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​907d37ddd8007006f5570f237f07875d43d5b8b
22:20 bacek good morning. Purl, shut up
22:20 * bacek reading #ps log
22:21 Util Good morning, bacek
22:22 bacek Good morning, Util
22:22 * darbelo points http://irclog.perlgeek.de/parr​otsketch/2009-06-02#i_1204005 out to bacek.
22:23 bacek pmichaud++ is right. Plus name C<dest> is bloody misleading.
22:24 darbelo Oh wait, I meant i_1204029
22:29 chromatic You get three PMCs still, but if you've overwritten a pointer to malloc()ed memory, you have a leak.
22:31 bacek I'm slightly disappointed...
22:32 jonathan chromatic: OK, but we're meant to end up with the all pointers intact.
22:32 rg joined #parrot
22:32 jonathan chromatic: Since there are still 3 data pointers pointing to the things they used to.
22:32 jonathan (At least, that's the intention.)
22:33 bacek I can't understand how writers of some mysterious language can reuse dest PMC even if core parroters can't.
22:33 chromatic I don't see how that can possibly work.
22:33 chromatic Hey, that message applies to two conversations.
22:33 bacek Huffman encoding ftw
22:34 chromatic Line 74 instantiates a Sub through its PMCProxy.
22:34 chromatic That Sub mallocs some memory for its attributes.
22:34 chromatic Line 83 allocates a PMC directly.  It doesn't have PMC_data defined.
22:34 jonathan chromatic: That's only to be used as a temporary too.
22:35 jonathan Think of swapping a and b
22:35 jonathan You introduce a temp.
22:35 jonathan temp = a; b = a; a = temp;
22:35 jonathan This is (meant to be) the same logic but a 3-way shuffle.
22:35 chromatic Okay.  Let me ask you a silly question you know the answer two.
22:35 chromatic Do you call destroy on the temp?
22:35 jonathan No.
22:35 chromatic s/two/to/
22:36 jonathan But I'd not expect to.
22:36 Whiteknight ditto
22:36 chromatic How else are you going to free the memory?
22:36 Whiteknight the memory from the temp has been copied to b
22:36 chromatic in its PMC_data?
22:36 jonathan Note that what gets stored in temp gets copied back elsewhere.
22:36 Whiteknight destroying temp destroys the data in b
22:36 jonathan temp never ends up being the only thing referencing the data.
22:37 jonathan (by the end)
22:38 particle temp = a; a = b; b = c; c = temp;
22:39 jonathan The shuffle is like this:
22:39 jonathan Before    After
22:39 jonathan ------    -----
22:39 jonathan proxy     value
22:39 jonathan value     new_ins
22:39 jonathan new_ins   proxy
22:40 chromatic Okay.  How do you know value can destroy new_ins's allocated data properly?
22:40 jonathan Because we copy the entire PMC structure.
22:40 jonathan Which contains both the vtable and the data pointer.
22:40 jonathan So the data and the vtable should always be staying associated.
22:41 jonathan memmove(proxy, value, sizeof (PMC));
22:41 chromatic Then why isn't it freeing that memory?
22:43 jonathan That, I don't know the answer to.
22:43 jonathan Even the flags are copied as part of the PMC though.
22:43 jonathan Otherwise I would have suspected some active destory not set issue.
22:44 jonathan Though given the types of PMC in question here they all have one, so...
22:44 jonathan If you want to try calling VTABLE_destroy on anything, it's new_ins, but I don't see why that wouldn't be subject to normal garbage collection and destruction.
22:48 Tene pmichaud: ping
22:52 pmichaud Tene:  just heading out the door -- I'll be back later tonight though.
23:08 darbelo asoprofarma.com.ar
23:08 darbelo crap, typed into the wrong window.
23:09 snarkyboojum joined #parrot
23:18 tetragon joined #parrot
23:20 donaldh joined #parrot
23:22 chromatic jonathan, perhaps the problem is in setting attributes to Undef.
23:26 chromatic Hm, no, not there.
23:33 nopaste "bacek" at 122.110.13.103 pasted "chromatic, forget about L1." (27 lines) at http://nopaste.snit.ch/16774
23:33 dalek parrot: r39345 | whiteknight++ | branches/aio_prototype:
23:33 dalek parrot: Removing unused branch, not needed
23:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39345/
23:33 patspam joined #parrot
23:37 kid51 joined #parrot
23:38 darbelo bacek: L1?
23:38 purl L1 is a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550 or http://rt.perl.org/rt3/Ticket/D​isplay.html?id=39313#txn-471982
23:43 bacek chromatic: now it correctly produces "42 0 42 42". fsvo correctly...
23:43 dalek parrot: r39346 | bacek++ | trunk (7 files):
23:43 dalek parrot: Merge no_pmc_reuse branch into trunk.
23:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39346/
23:45 chromatic No autoboxing evident there, but still confused reference/value semantics.
23:46 bacek indeed.
23:47 dalek parrot: r39347 | bacek++ | branches/no_pmc_reuse:
23:47 dalek parrot: Removing branch. Merged into trunk
23:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39347/
23:47 bacek and I can't see how to enforce one of this semantics.
23:47 bacek Anyway, $dayjob time.
23:48 bacek see you soon
23:48 chromatic Yeah, I'm giving up on this memory leak for now.
23:48 chromatic I can't reproduce it in a small program.
23:53 skids joined #parrot

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

Parrot | source cross referenced