Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling
Set by moderator on 28 May 2009.
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
darbelo "Sounding like yoda, I hate. When a Darth Vader t-shirt wearing I am"? 00:02
jonathan Change We Need. 00:03
purl jonathan: that doesn't look right
jonathan oh, wait..
NotFound darbelo: to be completely sure, we can ask for consensus at tomorrow #ps 00:04
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.
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:07
00:08 bacek_ joined
darbelo It looked to me like bacek's last commits were heading in the opposite direction. 00:10
But that direction is the one I though parrot was supposed to be going in.
pmichaud re-using the destination PMC is very non-useful from a compiler perspective. 00:11
for most languages that we work with, anyway.
NotFound darbelo: that's the problem I see. Having a dest parameter tend to suggest that intention.
pmichaud afk, taking family to dinner 00:12
darbelo But wouldn't PMC-reuse be a good thing, performace-wise?
pmichaud if I have a hll statement like
my $i = (3 + $x) * 4 00:13
which PMC gets the result of the (3 + $x) ?
it's a temporary value
darbelo Yes, when provided a non-reusable dest, add can allocate a new one.
pmichaud but how do we know if the dest is re-usable or not? 00:14
darbelo in this case PMCNULL
NotFound I think that in most cases where you want to reuse the clean solution is to use the inplace ops
pmichaud in other words, I'd have to null out the register before calling the 'add'
darbelo Why null a register? All unused $Pn are PMCNULL 00:15
pmichaud I might want to re-use a PMC register.
rather than have every option go to its own PMC register. That eats up memory unnecessarily.
s/option/operation
clearly we can do a lot better than current code, where some subroutines end up with 1000 PMC registers being used
gotta run -- will chat more later/tomorrow
darbelo ok. 00:16
cotto chromatic has once again awakened my desire for pie.
darbelo pie? where? I want some too! 00:17
darbelo wants his piece of the pie.
00:21 xenoterracide joined
cotto www.economist.com/research/styleGui...age=673903 makes me sad, and I haven't even gotten past the "A" section. 00:25
dalek kudo: 3f839b2 | jnthn++ | src/pmc/perl6multisub.pmc:
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.
kudo: 24460c8 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
cotto darbelo, in chromatic's post on the Modern Perl blog 00:26
dalek kudo: d396ab4 | jnthn++ | src/pmc/perl6multisub.pmc:
One for change that git decdied it'd rather forget about. *sigh*
 00:31
GeJ Hello all. 00:32
purl It's a crazy world, but hello to you too!
GeJ FYI, in parrot/src/oo.c on line 390 there is a trailing space. Without it `make fulltest` PASSes everything. 00:35
should I create a TT for this? 00:37
cotto GeJ, it's an easy fix. I'll take it. 00:45
kid51_afk cotto: I just got it.
cotto I just noticed that it wasn't there.
dalek rrot: r39313 | jkeenan++ | trunk/src/oo.c:
No trailing spaces. GeJ++.
 00:47
01:00 jsut joined
dalek rrot: r39314 | whiteknight++ | branches/io_rewiring (5 files):
[io_rewiring] changes from the weekend. Convert the read and write methods. Lots of fixes throughout
 01:20
01:33 rhr joined 01:41 japhb joined 02:40 snarkyboojum joined 02:41 janus joined 02:51 Rhysyngsun joined 02:57 Andy joined 03:03 Theory joined 03:20 donaldh joined 03:29 dukeleto joined 03:30 dukeleto_ joined 03:32 darbelo joined 03:43 tetragon joined 04:05 dukeleto joined 05:14 snarkyboojum left 05:15 snarkyboojum joined 05:38 dukeleto joined 05:46 Theory joined 06:47 HG` joined 07:11 iblechbot joined 07:20 donaldh joined 07:36 barney joined
dalek rrot: r39315 | cotto++ | trunk/examples/languages/abc/src/parser/actions.pm:
[abc] update abc actions (and inline comments) to use $foo.ast instead of $($foo)
 07:52
cotto that was quick
07:53 muixirt joined, Zak joined
muixirt anyone here with some knowledge about the runcores? 08:00
cotto define "knowledge" 08:01
muixirt cotto, do you know what the difference is between them? 08:02
cotto it's about how Parrot runs each opcode
e.g. in the profiling runcore, Parrot keeps track of how much time is spent on each opcode 08:03
muixirt and what is the difference between fast (afaik the default) and, let's say, cgoto 08:04
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
cotto the interesting code (well, part of it) is in src/runcore/cores.c 08:08
runops_fast_core, runops_cgoto_core, etc
muixirt predereferencing means to lookup the code address of the opcode before entering the run loop? 08:09
cotto that sounds consistent with my limited understanding 08:10
muixirt i was wondering how llvm fits in, that gsoc project 08:12
cotto it doesn't, yet
muixirt and i wonder where the benefit lies
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
l1?
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 irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982
cotto but that won't happen for a while 08:14
tewk's gsoc project is just the next step 08:16
assuming he ever shows up and starts on it ;) 08:17
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
s/The/A/
it'll also give us llvm's optimizations for free 08:20
is that what you were hoping to find out? 08:21
muixirt my understanding is that clang compiles those ops and the llvm engine executes the results, but i don't see any benefits 08:22
cotto, just a better understanding 08:23
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:26
muixirt the goal of jit is to eliminate code address lookups, call/branch and return/jump instructions 08:29
compiling ops with clang doesn't necessarily eliminate this overhead 08:31
08:32 mikehh joined
muixirt is clang produced llvm bytecode faster than gcc produced native code? 08:33
cotto I don't remember what the result was. It'd be fairly easy to test. 08:38
either way, I'm off to bed. night 08:39
muixirt good night, and thanks
08:42 bacek joined
bacek oh hai 08:46
muixirt hi bacek 08:47
bacek hi muixirt 08:49
muixirt bacek, can you explain to me the benefits of the upcoming? llvm integration 08:50
dalek rrot: r39316 | bacek++ | branches/no_pmc_reuse:
Branch for clean-up 3-args arithmetic PMCs ops
bacek Get JIT for free?
muixirt i bothered cotto already, see irclog.perlgeek.de/parrot/2009-06-02#i_1202561 08:51
bacek muixirt: Sorry, I cant help with. I didn't follow llvm gsoc project. 08:58
muixirt ok 08:59
dalek rrot: r39317 | bacek++ | trunk/src/pmc/scalar.pmc:
[pmc][cage] Don't reuse dest in Scalar.subtract.
 09:10
rrot: r39318 | bacek++ | trunk/src/pmc/bigint.pmc:
[pmc] Don't reuse dest in BigInt.
bacek oh shi...
(git svn)--
dalek rrot: r39319 | bacek++ | trunk/src/pmc/integer.pmc:
[pmc] Don't reuse dest in Integer
 09:13
rrot: r39320 | bacek++ | trunk (2 files):
[core] Remove Parrot_pmc_try_reuse function. It's dangerous to reuse dest pmc.
rrot: r39321 | bacek++ | trunk/src/pmc/bignum.pmc:
[pmc] No pmc_reuse in BigNum
rrot: r39322 | bacek++ | trunk/src/pmc/bigint.pmc:
[pmc] Fix typo in BigInt.
 09:20
rrot: r39323 | bacek++ | trunk/t/op/arithmetics.t:
[t] Add initial test for 3-args arithmetic dest handling.
rrot: r39324 | bacek++ | branches/no_pmc_reuse:
Remove branch. bacek-- for unconscious.
rrot: r39325 | bacek++ | trunk (6 files):
Revert last 6 commits. They doesn't belong to trunk. bacek--
 09:33
rrot: r39326 | bacek++ | branches/no_pmc_reuse:
Branch for clean-up 3-args arithmetic PMCs ops
 09:37
rrot: r39327 | bacek++ | branches/no_pmc_reuse/src/pmc/bigint.pmc:
[pmc] Don't reuse dest in BigInt.
 09:40
rrot: r39328 | bacek++ | branches/no_pmc_reuse/src/pmc/integer.pmc:
[pmc] Don't reuse dest in Integer
 09:43
rrot: r39329 | bacek++ | branches/no_pmc_reuse (2 files):
[core] Remove Parrot_pmc_try_reuse function. It's dangerous to reuse dest pmc.
rrot: r39330 | bacek++ | branches/no_pmc_reuse/src/pmc/bignum.pmc:
[pmc] No pmc_reuse in BigNum
rrot: r39331 | bacek++ | branches/no_pmc_reuse/t/op/arithmetics.t:
[t] Add initial test for 3-args arithmetic dest handling.
09:56 gaz joined 10:01 viklund joined 10:12 Maddingue joined 10:32 riffraff joined
riffraff in PAST what is the best way to retrieve a function object installed with PAST::Block.new(:name('foo'), :blocktype('declaration') )? 10:39
I know we have find_name in pir but I0m not sure what should happen in my grammar.pm
jonathan riffraff: To call it or to just get hold of it? 10:40
If the second, PAST::Var.new( :name('foo'), :scope('package') )
riffraff no to get hold of it, I am tryng to make my language pass function objects around with a &foo syntax 10:42
so I guess ot shoukd work :)
IIRC I can later cal it by passing it as first arguiment to a PAST::Op :pasttype('call') 10:44
jonathan Yes.
And be sure not to set :name 10:45
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.
dalek rrot: r39332 | bacek++ | branches/no_pmc_reuse/t/op/arithmetics.t:
[t] Generate tests for 3-args arithmetic dest handling.
 10:48
rrot: r39333 | bacek++ | branches/no_pmc_reuse/t/op (2 files):
[t] Move arithmetics tests for PMCs into t/op/arithmetics_pmc.t. Also
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:50
jonathan :-) 10:51
10:55 iblechbot joined 10:56 masak joined
masak Juerd wants me to submit as a bug that Rakudo can't compile on feather. 11:15
is there already such a bug? ISTR there is. 11:16
11:21 donaldh joined 11:22 burmas joined 12:02 Whiteknight joined 12:10 whoppix joined 12:14 patspam joined
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
shall I use :pirflags( to spcify an outer subid?
mh no, looking at pir it seems set up correctly 12:31
12:33 bkuhn joined 12:38 cognominal joined 12:58 ruoso joined, snarkyboojum joined
jonathan riffraff: It should set things up correctly for you automatically, yes. :-) 13:01
Util masak: 2 minutes ago, I built Rakudo on Feather. 13:09
3m08s for `perl Configure.pl --gen-parrot`
1m13s for `make`
0m38s for `make test`
All successful.
`make spectest` has only completed through S02, but all are passing except S02-lexical-conventions/unicode.t
masak: What issue are you having with the Rakudo build (that you referred to 1hour50minutes ago)?
13:09 burmas left 13:11 gryphon joined
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:15
13:18 payload joined 14:08 Andy joined
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
If you want a lexically scoped name you'll need to do something a little different.
riffraff you mean declaring it straight as a variable? 14:23
and then do explicitly do the lookup/calling machinery myself?
s/do the/the/ 14:24
I guess the principle of least surprise centered on me would love a :scope() keyword on block definitions :)
jonathan Hmm 14:28
When I did this in Rakudo I think I did something like:
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
That is, make the block anonymous by not setting a name (make sure blocktype is declaration)
And bind it to a lexical.
14:30 particle joined, masak joined
riffraff yes it's what I was thinking thanks again 14:31
14:41 barney joined 14:43 Theory joined
pmichaud easier is to bind it directly 14:47
PAST::Var.new( :name('mysub'), :isdecl(1), :viviself( ...past block here ... ) ) 14:48
jonathan The viviself is certain to get run? 14:51
OK.
14:51 payload joined
dalek rrot: r39334 | barney++ | trunk/runtime/parrot/library/pcre.pir:
[doc] The sub init() in nowadays in the namespace PCRE?
 14:54
pmichaud yes, viviself is certain to be run because it's a isdecl 15:06
(actually, viviself is always run on any uninitialized symbol)
15:06 PacoLinux joined
pmichaud (the isdecl forces the bind) 15:06
jonathan Ah, ok 15:07
Neat.
Tene Hey, do we have any parroters in Pittsburgh? 15:10
particle not for a few weeks still :)
Tene Sure would have been nice if this class was a few weeks in the direction. 15:11
pmichaud doesn't parse that. 15:12
actually, it parses okay, but my semantic analyzer is totally confused :-)
particle it'd be nice if tene's class was closer to yapc::na
pmichaud ah, thanks.
purl ah, thanks. is it fast enough?
particle ah, thanks. is <reply> 15:13
Tene I thought about going, but iirc it was poorly timed for me. 15:14
particle oh, sorry you won't be there :(
Tene probably next year, though. 15:16
I was pretty sure we had someone who lived there, though... 15:20
15:21 donaldh joined
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
barney www.frappr.com/parrotcoders show nobody, but is probably not current 15:23
dalek rrot: r39335 | NotFound++ | trunk (4 files):
[cage] kill include config.pir usages and example
 15:24
muixirt is away: bbl 15:25
dalek kudo: d03217d | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 395 files, 11346 passing, 2 failing

   S02-lexical-conventions/unicode.rakudo aborted 2 test(s)		 15:26
rrot: r39336 | NotFound++ | trunk/t/compilers/json/from_parrot.t:
[cage] kill include JSON.pir usage in tests
 15:30
kudo: 63cc77c | masak++ | src/setting/Any-str.pm:
[src/setting/Any-str.pm] a new, shorter .bytes implementation
 15:44
NotFound loadlib search logic is dramatically failed 15:58
16:00 darbelo joined 16:12 iblechbot joined
pmichaud #parrotsketch in 132 16:18
16:19 Austin_Hastings joined 16:31 HG` joined 16:34 estrabd joined 16:40 HG`` joined
dalek rrot: r39337 | NotFound++ | trunk (2 files):
[core] quick-fix libtcl loading
 16:54
16:54 hudnix joined
dalek rrot: r39338 | NotFound++ | trunk/examples/tcl/tcltkdemo.pir:
[cage] kill include TclLibrary.pir usage in example
 17:00
17:30 semar joined 18:01 AndyA joined 18:11 mberends joined
dalek rtcl: r412 | coke++ | trunk/lib/Parrot/Test/Tcl.pm:
Close the output file so that ./parrot can write to it safely.
 18:17
rtcl: r413 | coke++ | trunk/t/cmd_cd.t:
be a little more lenient on the homedir check.
 18:22
rtcl: r414 | coke++ | trunk/ (3 files):
ignore generated files
18:25 jhorwitz joined
jonathan j/oin #parrotsketch 18:27
18:27 allison joined 18:31 chromatic joined
allison moritz always shows up as gray in Chatzilla, not sure why 18:38
Util NotFound++ # for prompt work last week on TT#710 and TT#717. Thanks much! 18:41
NotFound Util: thanks 18:42
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.
NotFound Util: I don't think about the fix for TT #710 as a workaround: The implementation can be improved, though.
dalek rrot: r39339 | coke++ | trunk/src/pmc/coroutine.pmc:
[docs] make the docs match the pmclass declaration
Util NotFound: I agree. I oversimplified in my #ps report. 18:45
NotFound No prob
pmichaud Coke: Can you confirm that TT #715 has been fixed for you?
Whiteknight allison: Also, on page 79 the section is titled "GARBAGE", which I think is an error 18:47
pmichaud On TT report 16, can we add the "owner" column? 18:48
where "we" means "someone other than me"
Util pmichaud: I will add it to TTR 16 18:49
pmichaud Util++ # thanks
Util pmichaud: done, and yw 18:52
allison Whiteknight: yes, that's the chapter I'm not quite done with yet 18:56
allison spilled breakfast all over the counter and had to clean it up, back 19:00
particle don't cry, it looks like milk, but it's only soy milk. 19:03
pmichaud ...breakfast?
pmichaud wonders what tz allison++ is in at the moment :-)
19:04 japhb joined 19:09 david joined
allison pmichaud: notionally in Pacific time, but I work better at night, so tend to live timeshifted 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. :-)
Tene the same, module s/kids/work/ 19:13
dalek TT #732 created by coke++: Coroutine contexts not getting freed 19:14
19:14 radish joined 19:20 donaldh joined 19:32 afk_coke joined 19:37 iblechbot joined 19:40 Maddingue joined
chromatic Ah, found one context leak in Coroutine. 19:41
19:45 gryphon joined
chromatic Hm, Hello, World in PBC is suddenly more expensive. 19:54
allison chromatic: after fixing the leak? 19:56
chromatic This only measures startup time, no leaks.
It wasn't precisely a leak either, just double-marking a context as alive. That could be spendy.
NotFound Looks like assign_pmc in Sub does not unref his context 19:58
And does not ref the assigned one
chromatic That might do it. 20:00
dalek rrot: r39340 | chromatic++ | trunk/src/pmc/coroutine.pmc:
[PMC] Fixed Coroutine PMC's mark vtable entry to avoid unnecessary work (such
 20:05
rrot: r39341 | chromatic++ | trunk/src/pmc/eventhandler.pmc:
[PMC] Simplified EventHandler PMC's mark vtable entry (reusing its parent) and
rrot: r39342 | NotFound++ | trunk/include/parrot/sub.h:
[cage] drop spurious semicolon after do ... while (0) macro guard
 20:09
chromatic There's one. 20:18
dalek rrot: r39343 | chromatic++ | trunk/src/pmc/sub.pmc:
[PMC] Fixed context reference count updating in assign_pmc vtable (kudos to
 20:19
particle NotFound++ doesn't want kudos, he wants karma! 20:22
NotFound All your karma are belong to me! 20:23
chromatic karma NotFound
purl notfound has karma of 340
chromatic karma chromatic
purl chromatic has karma of 2043
chromatic Ah, I see.
particle karma particle
purl particle has karma of 1540
particle particle has been lazy 20:24
dalek cnum-dynpmcs: r73 | darbelo++ | trunk/src/pmc/decnum.pmc:
It looks like reusing dest wasn't such a good idea fter all.
 20:29
20:31 Austin_Hastings joined
Austin_Hastings Guten abend, #parrot. 20:32
dalek rrot: r39344 | chromatic++ | trunk/src/pmc/sub.pmc:
[PMC] Fixed context refcounts in Sub's clone vtable entry.
 20:36
muixirt is back (gone 05:19:15) 20:44
chromatic Coroutine probably leaks context refs in its clone too. 20:48
NotFound chromatic: That clone change will not double free the context when original and clone gets destroyed? 20:50
chromatic It shouldn't; the ref count on the original's contexts increases too. 20:51
20:51 eternaleye joined
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:55
dalek kudo: fc01cda | jnthn++ | tools/benchmark.pl:
Add postfix:<++> test to the set of benchmarks.
 20:57
chromatic It's -1 to the destination's previous contexts, +1 to the destination's new contexts.
NotFound Ah, the pmc_new'ed can have contexts, I see now. 20:59
chromatic It may or may not.
NotFound chromatic: in assign_pmc outer_ctx must not also be increased/freed ? 21:01
chromatic I'm not sure. 21:03
NotFound And BTW, it has no protection against self assign.
chromatic In which case it could free its own context and BOOM. 21:04
True.
NotFound We can either add the protection, of add ref before freeing
chromatic The latter sounds simpler, though worth a comment. 21:05
NotFound Must go now. I'll do tomorrow if you don't before. 21:07
chromatic I'm trying to track down the memory leak of Parrot_sub attributes in the Sub PMC. 21:08
Something overwrites them.
jonathan chromatic: Not just assign? 21:12
chromatic: And which ones is it overwriting? 21:13
chromatic I can't tell which ones. 21:17
assign_pmc looks like it does the right thing.
So does clone.
jonathan Are we leaking the entire attribute strucutre? 21:18
Or just some things referenced by it?
chromatic The entire attribute structure. 21:19
jonathan OK.
chromatic Something replaces Sub's PMC_data wholeheartedly.
jonathan A sub can magically become a Closure, could that be the source of the issue?
Oh, wait, not a Closure
chromatic Let me check the Closure PMC.
jonathan I think Closure PMC went away?
chromatic You're right.
jonathan oh! 21:20
I was thinking just of this line
ccont->vtable = interp->vtables[enum_class_Continuation];
Which is a vtable swap but probably not what we look for.
chromatic The Sub remains a Sub. 21:21
jonathan chromatic: This might be a bit off 21:23
In get_string we do
Parrot_sub *sub; 21:24
PMC_get_sub(INTERP, SELF, sub);
In destory we do
Parrot_sub *sub;
GET_ATTR_sub(INTERP, SELF, sub);
Are those two macros really doing the same thing?
(this is in sub.pmc)
chromatic I believe so. 21:25
jonathan yeah, looks like it to me too
Just felt like a slight red flag... 21:26
Two different macros for something that looks like it's the same thing.
chromatic: Are you observing this only with Rakudo, or in Parrot generally? 21:27
chromatic Partcl has it too.
jonathan Ok.
chromatic 0xb78ec670 0x9da88b0 Sub D 21:28
0xb78ec670 0xa195598 Sub N
The first pointer is the PMC, the second is the sub attribute.
The name is the PMC type and the character is Destruction or New.
Somewhere in between creation and destruction, that PMC's sub attribute changed.
dalek nie: r69 | isop44++ | trunk/ (4 files):
list comprehensions
 21:30
purl list comprehensions are lovely.
chromatic It's a Sub PMC created through Class's instantiate (and PMCProxy's instantiate) though. 21:33
dalek nie: r70 | isop44++ | trunk/Lib/test/parrot/listcomps.py:
Add another list comprehension test
 21:35
jonathan They create Sub PMCs? Oh, hmm
chromatic If you've subclassed Sub, yes. 21:36
jonathan Rakudo certainly does that. 21:37
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
I tried writing one myself but somehow failed.
Mr. Bender, your son has what we call "stupid fingers".
jonathan Hmm, moment then. :-) 21:39
21:40 Limbic_Region joined 21:42 Theory joined
nopaste "jonathan" at 85.216.157.73 pasted "for chromatic" (18 lines) at nopaste.snit.ch/16770 21:43
jonathan chromatic: Are any of those two interesting?
chromatic No leaks there.
jonathan Damm. 21:44
chromatic Rakudo must do something more interesting.
jonathan Yes, probably.
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.
jonathan Let me look.
chromatic: ah yes 21:46
So we call !fixup_routine_type to re-bless a block into its new class.
nopaste "jonathan" at 85.216.157.73 pasted "!fixup_routine_type" (17 lines) at nopaste.snit.ch/16771 21:47
jonathan It does that.
rebless_subclass is a dynop.
It would be the first thing I'd blame.
Apart from, you mentioned tcl also has the issue, and that dynop is Rakudo specific...
chromatic That doesn't explain why Tcl has a similar problem....
jonathan Right. 21:48
particle similar, or same?
jonathan But that's how we tend to go from Parrot sub to a Rakudo one.
chromatic Hm, no.
Tcl and Rakudo have a similar problem losing contexts to invoke, but not this problem.
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:49
chromatic Please go ahead. 21:50
jonathan chromatic: rebless_subclass would almost certainly result in that pointer being changed.
21:50 Whiteknight joined
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?"
jonathan chromatic: Yes.
21:51 bacek joined
chromatic Then I need food first. 21:51
Limbic_Region Ok - 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)
particle chromatic: your lack of brains can help you here
Limbic_Region is there another place I should be looking?
particle Limbic_Region: that's what README has been for, traditionally 21:52
chromatic Yes, but L~R has a point.
particle makes sense to put the info on the web
much friendly for dumb new users
Limbic_Region a truly novice would likely reach for the binary
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
knowing that they have to go get MinGW or have MSVC++ before they can even do anything might be an eye opener
Is the svn repo browserable? I would like to read the README 21:54
chromatic svn.parrot.org/parrot/trunk/README. 21:55
no dot on the end
Whiteknight keeps seeing reasons why contexts should be garbage collectable
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.
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
jonathan chromatic: Ah, I think I see what's going on.
21:58 Ademan joined
jonathan chromatic: Well, yes, the point of the op is to do just that. 21:58
chromatic: But the PMC_data in question shoulda been copied somewhere else.
Thing is, I think it misses something...
Whiteknight jonathan and chromatic: where are you guys looking?
chromatic Rakudo's custom ops; rebless_subclass.
jonathan Damm, this hurts my head... :-/ 21:59
Limbic_Region oh, wait - nevermind, the Readme_Win32.pod is adequate
Whiteknight oh yeah, I've looked at that code before. Evil 22:00
jonathan Tell me about it. 22:01
purl rumour has it it is not
Limbic_Region ok - other than suggesting perhaps link to the readme's from the download page, I return you to your regularly scheduled programming
jonathan ooh 22:02
oh, wait, no.
jonathan keeps thinking he's spotted a problem and then realizes, no, that's right... 22:03
(I think we were disassociating vtable and pmc_data but we ain't, we copy the bunch of pointers all together.)
chromatic Overwriting the pointers in the instantiated proxy seems wrong. 22:06
22:07 Theory joined
jonathan How so? 22:07
We are doing a shuffle-around, but in the end we get three PMCs still.
(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.
Whiteknight good morning GeJ
Util What PASM or PIR is equivalent to Perl 5's `$foo = -s 'MyFile'`? 22:10
Good morning GeJ
Whiteknight what is -s again?
Util filesize
purl filesize is probably 75K
Whiteknight There is a filestat method somewhere, I think 22:11
purl forget it
purl Whiteknight: I forgot it
Whiteknight purl forget filesize
purl Whiteknight: I forgot filesize
Whiteknight I mean fstat
Util Whiteknight: thanks, that got me heading in the right direction. stat() is in io.ops. 22:17
Whiteknight ah, that's what I was thinking about 22:18
dalek kudo: 50f15ae | pmichaud++ | src/parser/ (2 files):
Clean up handling of self-accessors and parameters. Fixes RT #61988.
 22:19
kudo: c907d37 | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
bacek good morning. Purl, shut up 22:20
bacek reading #ps log
Util Good morning, bacek 22:21
bacek Good morning, Util 22:22
darbelo points irclog.perlgeek.de/parrotsketch/200...#i_1204005 out to bacek.
bacek pmichaud++ is right. Plus name C<dest> is bloody misleading. 22:23
darbelo Oh wait, I meant i_1204029 22:24
chromatic You get three PMCs still, but if you've overwritten a pointer to malloc()ed memory, you have a leak. 22:29
bacek I'm slightly disappointed... 22:31
jonathan chromatic: OK, but we're meant to end up with the all pointers intact. 22:32
22:32 rg joined
jonathan chromatic: Since there are still 3 data pointers pointing to the things they used to. 22:32
(At least, that's the intention.)
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.
Hey, that message applies to two conversations.
bacek Huffman encoding ftw
chromatic Line 74 instantiates a Sub through its PMCProxy. 22:34
That Sub mallocs some memory for its attributes.
Line 83 allocates a PMC directly. It doesn't have PMC_data defined.
jonathan chromatic: That's only to be used as a temporary too.
Think of swapping a and b 22:35
You introduce a temp.
temp = a; b = a; a = temp;
This is (meant to be) the same logic but a 3-way shuffle.
chromatic Okay. Let me ask you a silly question you know the answer two.
Do you call destroy on the temp?
jonathan No.
chromatic s/two/to/
jonathan But I'd not expect to. 22:36
Whiteknight ditto
chromatic How else are you going to free the memory?
Whiteknight the memory from the temp has been copied to b
chromatic in its PMC_data?
jonathan Note that what gets stored in temp gets copied back elsewhere.
Whiteknight destroying temp destroys the data in b
jonathan temp never ends up being the only thing referencing the data.
(by the end) 22:37
particle temp = a; a = b; b = c; c = temp; 22:38
jonathan The shuffle is like this: 22:39
Before After
------ -----
proxy value
value new_ins
new_ins proxy
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.
Which contains both the vtable and the data pointer.
So the data and the vtable should always be staying associated.
memmove(proxy, value, sizeof (PMC)); 22:41
chromatic Then why isn't it freeing that memory?
jonathan That, I don't know the answer to. 22:43
Even the flags are copied as part of the PMC though.
Otherwise I would have suspected some active destory not set issue.
Though given the types of PMC in question here they all have one, so... 22:44
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.
Tene pmichaud: ping 22:48
pmichaud Tene: just heading out the door -- I'll be back later tonight though. 22:52
darbelo asoprofarma.com.ar 23:08
crap, typed into the wrong window.
23:09 snarkyboojum joined 23:18 tetragon joined 23:20 donaldh joined
chromatic jonathan, perhaps the problem is in setting attributes to Undef. 23:22
Hm, no, not there. 23:26
nopaste "bacek" at 122.110.13.103 pasted "chromatic, forget about L1." (27 lines) at nopaste.snit.ch/16774 23:33
dalek rrot: r39345 | whiteknight++ | branches/aio_prototype:
Removing unused branch, not needed
23:33 patspam joined 23:37 kid51 joined
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 irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982
bacek chromatic: now it correctly produces "42 0 42 42". fsvo correctly... 23:43
dalek rrot: r39346 | bacek++ | trunk (7 files):
Merge no_pmc_reuse branch into trunk.
chromatic No autoboxing evident there, but still confused reference/value semantics. 23:45
bacek indeed. 23:46
dalek rrot: r39347 | bacek++ | branches/no_pmc_reuse:
Removing branch. Merged into trunk
 23:47
bacek and I can't see how to enforce one of this semantics.
Anyway, $dayjob time.
see you soon 23:48
chromatic Yeah, I'm giving up on this memory leak for now.
I can't reproduce it in a small program.
23:53 skids joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!