Parrot 1.1.0 Released | parrot.org/ | 322 RTs left | Weekly Priority: Remove Deprecated Items
Set by moderator on 6 May 2009.
dalek cnum-dynpmcs: r27 | darbelo++ | trunk/src/pmc/decnum.pmc:
Raise exceptions only on actual errors.
 00:04
rrot: r38620 | whiteknight++ | branches/gc_api (8 files):
move pobject_lives into the api. Add a new Parrot_gc_ptr_is_pmc api function to hide some internals functions move some other stuff around
 00:11
rrot: r38621 | whiteknight++ | branches/gc_api (57 files):
[gc_api] rename pobject_lives Parrot_gc_mark_PObj_alive
 00:18
Whiteknight thank god for sed 00:21
(never thought I would say that)
darbelo I'm not sure I would admit using sed instead of perl arround here :)
Whiteknight i never was any good at perl command-line one-liners 00:22
darbelo toss your script at s2p then ;) 00:23
then you'd be using perl.
dalek rrot: r38622 | whiteknight++ | branches/gc_api/include/parrot (2 files):
[gc_api] move all the guts of gc_mark_sweep.h into gc_api.h, preparing to delete the former
 00:25
Whiteknight never even heard of s2p 00:27
darbelo it translates sed to perl. 00:28
dalek cnum-dynpmcs: r28 | darbelo++ | trunk/examples/decnum.pir:
Make the decnum example actually show us something useful.
 00:29
darbelo www.perl.com/doc/manual/html/x2p/s2p.html 00:30
Whiteknight good work tonight darbelo 00:33
well, it's night for me
darbelo Thanks. I'll blog about a few discoveries later. Night. 00:34
Whiteknight excellent, looking forward to it! 00:35
goodnight
dalek rrot: r38623 | whiteknight++ | branches/gc_api (7 files):
[gc_api] kill gc_mark_sweep.h file. the public functions are moved into the api, and the private functions into gc_private.h
rrot: r38624 | whiteknight++ | branches/gc_api/src/gc/gc_private.h:
[gc_api] run make headerizer, cleans some things up slightly. Done work for the night
cotto d'oh. I was going to say something nice, but he just left. 00:56
Infinoid There's always next time :) 01:06
I usually run "make test" and "make codetest" in parallel 01:27
When I forget the "code" part on one of those, the results are sometimes spectacular
01:32 confound joined
dalek rrot: r38625 | Infinoid++ | trunk/config/auto/arch.pm:
[config] Apply change from rrauenza++ in TT #653. Apparently r38512 had added the fixup after the string had already been parsed.
 01:34
Infinoid Oh no, lost karma!
Infinoid shakes fist at the ghost of purl 01:35
cotto Infinoid++ 01:36
heh
01:36 kid51 joined
Infinoid heh, cotto++ 01:37
cotto now's the time for any would-be purl impersonators
Infinoid I already had it that way, cotto. 01:39
01:42 dukeleto joined
Infinoid I am now officially unemployed 01:53
Oh well, might as well help break the GC.
cotto Sorry to hear that. 01:55
Infinoid Eh, 'tis the season 01:56
s1n Infinoid: laid off? that's a bummer, sorry to hear 01:58
Infinoid thanks, I'll figure something out 02:00
kid51 t/codingstd/perlcritic.........262/307 Argument "5.010_000" isn't numeric in subroutine entry at /usr/local/lib/perl5/site_perl/5.10.0/Perl/Critic/Document.pm line 139.
don't believe I've seen that warning before.
Infinoid msg whiteknight Hey, breaking the GC looks like fun. Do you have a plan or task list or something? Can I help? 02:01
Oh, ENOPURL
kid51 When I got to parrot.org and search for "YAPC" I don't get any links pertaining to the Parrot workshop preceding the conference -- only links to last year's events. 02:04
It doesn't show up on our little calendar of events thingie, either. 02:05
02:23 dukeleto joined 02:35 janus joined 02:54 qiang joined 02:56 cognominal joined
afk_coke now 03:48
now?
Coke anyone msg masque yet? 03:49
cotto we need purl for that 03:51
03:52 tetragon joined
Coke not msg, /msg 03:52
I just did.
04:08 Andy joined
dalek rrot: r38626 | petdance++ | trunk (2 files):
properly shimmed some arguments
 04:31
bacek hi again 04:37
dalek rrot: r38627 | bacek++ | branches/tt631_part3:
Removed tt631_part3 branch. It was merged to trunk
bacek Hey, where is our lovely girl?
dalek tracwiki: v13 | bacek++ | BranchDescriptions 04:44
tracwiki: Drop tt631_part3 branch.
tracwiki: trac.parrot.org/parrot/wiki/Branch...ction=diff
cotto I guess all the karma killed her. 04:52
bacek bad karma... 05:03
cotto: any plans for pmc_pct branch? 05:05
cotto I spent a bunch of time trying to get function pointer attrs working, but I'm putting that off for now. 05:07
Next on the list is generating some meaningful ATTR accessor macros.
Working from the C99 standard turned out to be overkill. 05:08
bacek Ok. I'll take generating vtable functions. 05:10
cotto sounds like a plan
bacek Sorta :) 05:12
cotto enough of one that we won't step on each other's feet 05:15
bacek Agreed 05:16
cotto can regexes be used in nqp? 05:22
bacek cotto: no idea... Probably yes. Grammar is regex anyway. 05:24
05:26 mikehh_ joined
dalek rrot: r38628 | petdance++ | trunk/src/hash.c:
consting and fixing indentation
 05:36
05:51 preflex joined 06:10 gaurav joined 06:34 cognominal joined 07:03 signals joined 07:04 signals left 07:47 purl joined
bacek hi purl! 07:49
purl: good girl
purl thanks bacek :)
bacek horray! She's back! :)
cotto woohoo 07:50
< purl-- > 07:51
for being broken
incoming 07:52
dalek rrot: r38629 | cotto++ | branches/pmc_pct/compilers/pmcc/src (3 files):
[pmcc] add ATTR accessor macro generation
 07:53
cotto still need to figure out function pointer ATTRs and inheritance, but that covers the basics
08:05 iblechbot joined 08:16 contingencyplan joined
bacek cotto++ 08:17
We are getting closer to step 4! :) 08:18
cotto technically yes, but which step 4?
bacek compilers/pmc/TODO :) 08:19
cotto bacek++
profit++
karma profit
purl profit has karma of 6
cotto karma prophet 08:20
purl prophet has karma of 1
bacek profit++ # Need more karma!
afk # kids time
cotto kids are good 08:21
don't forget to feed them. I think they need that.
bacek back 08:48
cotto: oh...
afk # feed kids
cotto btw, how does kangaroo taste? 09:27
cotto suddently wants chicken 09:30
bacek cotto: they are pretty tasty 09:48
ok. Another EPIC FAIL. 10:09
10:09 qiang1 joined
cotto ? 10:09
bacek Trying to parse vtable body independently.
cotto how so? 10:10
bacek Overcomplicated.
I'll try to parse in just in grammar.pg
cotto it looks like figuring out the name of the pmc file being compiled will be interesting too 10:11
although the only reason I need that is so I know where to put the .dump files.
bacek $pmc.name 10:15
cotto no, I mean the actual path to the file, including the filename.
as in src/pmc/file.pmc
although I don't think there's anything wrong with dumping them somewhere else 10:16
bacek Apart from dealing with dynpmc - nothing 10:17
cotto I'll solve it for normal PMCs, then deal with dynpmcs
bacek hey. I created filename/set_filename in emitter.pm. Will they help if we'll use them consistently? 10:18
cotto sure 10:24
we'll need that same info for dumping the .c and .h files anyway 10:27
bacek so, let's use them! :)
cotto obvious++ 10:34
;)
Alright. It's hacky, but inheritance is working. 10:42
and I'm failing a bunch of tests. :{
bacek I'm failing to produce few lines of working code today... Totally stuck... 11:00
11:05 Whiteknight joined
cotto those days happen 11:11
dalek rrot: r38630 | whiteknight++ | branches/gc_api (16 files):
[gc_api] rename the rest of the functions in the API to be Parrot_gc_*, fix some documentation, etc
 11:38
cotto committed 11:40
purl, committed
purl cotto: i'm not following you...
dalek rrot: r38631 | cotto++ | branches/pmc_pct/compilers/pmcc (8 files):
[pmcc] initial version of ATTR inheritance
 11:41
rrot: r38632 | whiteknight++ | branches/gc_api (2 files):
[gc_api] Remove the last non-api functions from gc_api.c. With that, the GC *should be* properly encapsulated. Now we just need to refine the boundary.
 11:45
12:01 Whiteknight joined
cotto Whiteknight, ooc when's that branch going to merge? 12:03
Whiteknight soon, hopefully 12:04
why, you blocking on it?
cotto nope. just curious
12:05 mikehh joined
dalek rrot: r38633 | whiteknight++ | branches/gc_api (7 files):
[gc_api] move some logic from src/pmc_freeze.c to the gc api, because it was monkeying around in the arenas. I'm still not entirely happy about how pmc_freeze breaks GC encapsulation, need to work on that
 12:05
rrot: r38634 | cotto++ | branches/pmc_pct/compilers/pmcc/src (4 files):
[pmcc] add support for (simple) function pointer ATTRs
Whiteknight cotto: I could probably merge within a few hours, it's stable now and I don't have a finite todo list 12:08
the longer I keep the branch open, the more I will do
dalek rrot: r38635 | cotto++ | branches/pmc_pct/compilers/pmcc/src/nodes.pir:
[pmcc] fix test failure from previous commit
 12:09
cotto but the longer you keep it open, the less fun it'll be to merge 12:10
time for a nap 12:13
12:22 kid51 joined
dalek rrot: r38636 | whiteknight++ | branches/gc_api (4 files):
[gc_api] Add a function to the API to explicitly free a PMC header, to prevent pmc.c from having to deal with Small_Object_Pool structures directly.
 12:25
12:28 masak joined
masak oh hai, I'm having build fails with Parrot since chromatic's r38577 optimisation. 12:29
I'm on Darwin. getting "Bus Error" when trying to compile Perl6Grammar.pir
cotto smolder? 12:32
purl it has been said that smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
dalek rrot: r38637 | whiteknight++ | branches/gc_api (4 files):
[gc_api] add a new api function Parrot_gc_free_string_header, use that to get references of Small_Object_Pool out of src/string/api.c. Also, use API functions in retcontinuation PMC to preserve encapsulation
 12:35
12:39 rdice joined 12:40 rg1 joined
masak chromatic: gist.github.com/109252 12:46
dalek rrot: r38638 | whiteknight++ | branches/gc_api (3 files):
[gc_api] add two new api functions to get the number of active sized buffers, and total sized buffers.
 12:48
rrot: r38639 | whiteknight++ | branches/gc_api (4 files):
[gc_api] Small_Object_Pool and Small_Object_Arena structures are now gc-private and are not used or visible outside the GC
 12:58
rrot: r38640 | whiteknight++ | branches/gc_api (3 files):
[gc_api] Add new API functions to get the number of GC mark and collect runs, use them to reduce access to the Arenas structure outside the GC
 13:11
rrot: r38641 | whiteknight++ | branches/gc_api (3 files):
[gc_api] add more api functions to control access to the Arenas structure
 13:18
a: 28ba481 | fperrad++ | src/pmc/luastring.pmc:
fix build with Parrot r38536 (tt631_part2 merge)
 13:48
a: c0a72c1 | fperrad++ | src/pmc/lua (4 files):
s/interp/INTERP/g
13:49 pfig joined
dalek kudo: f2557a8 | pmichaud++ | Configure.pl:
Fix bug with Configure.pl's 'make clean' on Win32. (azawawi++)
 13:57
13:58 cognominal joined
dalek rrot: r38642 | jkeenan++ | trunk/tools/dev/branch_status.pl:
Change way version is specified to pass perlcritic.t. (This is more likely to be a Perl::Critic bug than our bug. Cf.: rt.cpan.org/Ticket/Display.html?id=45892.). Also, 'use feature' is not needed once we've specified 5.10 (per 'perldoc -f use').
 14:01
purl dalek: that doesn't look right
rrot: r38643 | whiteknight++ | branches/gc_api (8 files):
[gc_api] move Arenas struct into gc_private.h. It is no longer directly accessible from outside the GC system. Notice also that the block/unblock routines are no longer macros, they are now regular API functions.
 14:04
14:14 tetragon joined 14:27 s1n joined
dalek rrot: r38644 | fperrad++ | trunk/config/auto/gmp/gmp_c.in:
[config] fix compilation on Windows

test_3020.c:29: warning: implicit declaration of function `SetErrorMode' test_3020.c:29: warning: nested extern declaration of `SetErrorMode' test_3020.c:29: error: `SEM_NOGPFAULTERRORBOX' undeclared (first use in this function) test_3020.c:29: error: (Each undeclared identifier is reported only once test_3020.c:29: error: for each function it appears in.)		 14:53
14:55 masak joined
Infinoid masak: So your "item" pointer is NULL. Any chance you can check what the "size" value was? 15:04
Looking at r38577, I think it must be some kind of corruption, which means it might be tricky to debug, but we might as well look up the obvious stuff first 15:05
masak Infinoid: teach me how to check, and I'll check. 15:06
dalek rrot: r38645 | whiteknight++ | branches/gc_api (4 files):
[gc_api] some basic cleanups. Rename some stuff to be better, documentation, fix some mis-matched data types
 15:07
Infinoid You used gdb to get that backtrace, right?
At the same place you had typed "bt" or "backtrace", type "print size"
masak Infinoid: ok. 15:13
masak does that
Infinoid Thanks.
Which version of parrot are you using?
Just to verify what's going on, does this patch (upcoming nopaste) get things building for you? 15:14
nopaste "infinoid" at 76.215.211.232 pasted "[PATCH] masak: debugging patch, does this crash?" (26 lines) at nopaste.snit.ch/16505
masak one thing at a time :) 15:15
Infinoid hehe
masak getting size for you first.
Infinoid The code changed by r38577 has a couple of code paths, one optimized and one normal. One weird thing is, chromatic's commit message made it sound like it used the optimized case in all cases, but in reality, it enabled *both* code paths. The above nopaste disables the non-optimized path, which I think may have been his intention 15:16
masak as to version, I'm running r38577.
the first one that fails for me.
Infinoid ok, thanks 15:17
masak 'print size' gives '$1 = 12945440' 15:19
jonathan
.oO( that's a big size )
 15:20
masak that's what it says.
15:20 Theory joined
Infinoid Wow, sounds like the PMC is definitely corrupt (or not an RPA to begin with) 15:20
masak trying patch now. 15:21
Infinoid Thanks. If it works, I won't be able to explain why, but it fixes the only thing about r38577 which looks suspicious to me 15:22
dalek kudo: 95aab9d | jnthn++ | src/builtins/assign.pir:
Implement hash versions of hyper operators.
jonathan If there's PMC corruption, a -G can be worthwhile too.
masak no need for exact explanations. I just want it to work so I can compile Rakudo. :)
masak Infinoid: it worked. 15:23
purl Of course it worked
masak purl: shut up.
purl make me
masak assaults purl
Infinoid purl, die in a fire
purl HALP
Infinoid masak++ # I'll check in a cleaner version of that 15:24
masak Infinoid++ # thanks for the help
jonathan purl++ # putting up a fun-to-watch fight
dalek rrot: r38646 | whiteknight++ | branches/gc_api/src/gc/api.c:
[gc_api] rearrange some things so they're in a reasonable order
 15:26
Infinoid masak: r38648 15:28
dalek rrot: r38647 | Infinoid++ | trunk/config/auto/gmp/gmp_c.in:
[cage] c_indent.t fix.
 15:30
masak Whiteknight: ping
rrot: r38648 | Infinoid++ | trunk/src/pmc/retcontinuation.pmc:
[PMC] According to masak++, r38577 causes a SIGBUS on darwin.

The r38577 commit log suggests that the optimized path was enabled in all cases. But in reality, *both* paths were being executed. This patch disables the non-optimized path. I can't tell you why this fixes it, but apparently it does.
Infinoid msg chromatic Can you review r38648 when you get the chance? I don't understand the code well enough to know whether it was the right fix. Thanks!
purl Message for chromatic stored.
dalek rrot: r38649 | jhorwitz++ | trunk/docs/embed.pod:
replace call to internal Parrot_Class_instantiate with VTABLE_instantiate
 15:39
16:13 pfig joined
Whiteknight damnit, I tried to merge my branch to trunk and I developed a test failure 16:27
before I go crazy, is anybody else seeing failures on t/pmc/packfiledirectory.t? 16:28
Infinoid It passes in trunk for me 16:33
Which branch? 16:34
Whiteknight gc_api branch 16:51
it passes in the branch too, but when I merge with trunk I get the test failure
masak: pong 16:52
Infinoid I just tried rebasing gc_api on top of trunk, and got a double free error compiling PGE
Whiteknight oh, I must not have committed that fix yet 16:53
masak Whiteknight: the Perl 6 wikibooks thing. I'm given to understand that you've written much of it.
Whiteknight Infinoid: committing that one now 16:54
masak: Yes, I think I've written nearly all of it
but it's out of date now
Infinoid Whiteknight: I've got valgrind output that shows me that your branch changes perturb r38577 somehow; it's accessing an already-freed RetContinuation PMC. Is your fix related to that?
masak Whiteknight: yes. that was part of my point.
dalek rrot: r38650 | whiteknight++ | branches/gc_api/src/pmc/retcontinuation.pmc:
[gc_api] fix for retcontinuation pmc to avoid double-free
masak I'm finding factual inaccuracies in it, or out-of-date things. 16:55
Infinoid heh, cool. Whiteknight++
masak I'd contribute, but I'm slightly uncomfortable with the fact that commits might be left sitting around without being approved.
16:56 Theory joined
masak Whiteknight: this section, f'rex, is way off: en.wikibooks.org/wiki/Perl_6_Progra...t_Matching 16:56
Whiteknight masak: Yeah, probably is. I really need to get back to work on that book and get things improved 17:00
if you send me suggestions/patches I'll implement them for you
masak Whiteknight: as I said, I'd be happy to contribute directly, if I were only a bit more clear on what gets approved and when. 17:01
Whiteknight: I'm used to changes to wikis/svn/git appearing directly.
Whiteknight masak: Nothing gets "approved". All your changes go live immediately on the wiki
masak Whiteknight: it's been a while since I committed to it. 17:02
Whiteknight: last time I did, things had to be approved.
Whiteknight I dont ever remember that being the case, did you log in?
masak aye.
I wouldn't go so far as calling it "off-putting", but it does create a barrier.
Whiteknight yeah, if you're logged in all changes should appear immediately
masak Whiteknight: maybe you're an owner of the book and I'm not. 17:03
or some other difference like that.
Whiteknight nope, no such concept as "owner" or anything.
masak Whiteknight: trying now.
Whiteknight okay, awesome. let me know how it works
(i'll kick some butts if it gives you trouble)
masak Whiteknight: "Edits will be incorporated into the stable version once an authorised user reviews them. The draft is shown below. 1 change awaits review." 17:06
Whiteknight oh, that's an anti-vandalism thing. your edit is visible to all logged-in users
masak ok. I understand the need for protection against vandalism on a public wiki. 17:07
just wondering with what kind of regularity you tend to go actually approving edits. 17:08
Whiteknight pretty regular, we have teams of page-reviewers
masak sounds good.
I'll see if I can make some more sweeping reviews of the text soon. 17:09
Whiteknight Great! masak++ We need all the help on that book we can get
17:10 jhorwitz joined
dalek rrot: r38651 | coke++ | trunk/t/compilers/imcc/syn/regressions.t:
Add a test for TT #654
 17:11
Whiteknight okay, I have to disappear for now. later
17:37 pfig joined 17:47 rdice joined 18:48 pfig joined 18:51 Khisanth joined 18:53 pfigz joined 19:01 pfig joined 19:02 Whiteknight joined 19:03 pfigz_ joined 19:12 Eevee joined
dalek rrot: r38652 | whiteknight++ | branches/gc_api (82 files):
[gc_api] merge to trunk from 38520:38575. The error hasn't appeared yet
 19:22
rrot: r38653 | whiteknight++ | branches/gc_api (84 files):
[gc_api] merge to trunk HEAD (38652). found the error
 19:35
Whiteknight prepare yourselves.... 20:02
dalek rrot: r38654 | whiteknight++ | trunk (132 files):
[gc_api] Behold! Parrot is entering an age of slightly less lousy GC! Merging the gc_api branch into trunk, all tests pass.
 20:05
jonathan *gulp* 20:24
:-)
dalek kudo: 67581ac | jnthn++ | src/classes/Code.pir:
Remove duplicate .count method, spotted by jhorwitz++.
jonathan hopes this will make it easier to play with other GC schemes.
20:40 Eevee joined 21:00 register joined 21:04 Theory joined
register where is twek? 21:07
moritz did you mean tewk? 21:08
register yes sorry
i meant tewk
Infinoid Whiteknight: I had to leave for a while, but I'm back. After your double free fix, I have a merged git branch here which seems to test fine 21:26
dalek kudo: 70c5195 | moritz++ | (4 files):
track changed parrot function name
kudo: 7d581a5 | moritz++ | src/pmc/objectref_pmc.template:
forgot one old function name
Whiteknight yeah, I had to comment out a line of code in retcontinuation.pmc:invoke
I'm gdb'ing it right now to figure out why that line causes a failure in packfiledirectory.t 21:27
Infinoid what's the line? (is it checked in?)
things seem to be working fine for me (gentoo/amd64)
oh, it's already merged. nevermind 21:28
Whiteknight Infinoid: it's like 103 21:34
uncomment it, and t/pmc/packfiledirectory.t fails with a segfault
"it's line 103"
I think you've made an edit in that general area recently, removing the "#if NDEBUG" conditional 21:36
Infinoid yeah 21:37
r38648 was my fixup of chromatic's removal of that stuff (r38577)
Whiteknight in the branch I moved most of the code from that section into the Parrot_gc_free_pmc_header, so it should be doing an identical operation 21:38
Infinoid I still don't get a failure in t/pmc/packfiledirectory.t in current trunk, even with that line uncommented 21:45
21:47 pfig joined 21:50 pfigz joined
dalek rrot: r38655 | Infinoid++ | trunk/src/runcore/cores.c:
[core] Fix the following warnings:

src/runcore/cores.c:418: warning: comparison between signed and unsigned		 21:59
Whiteknight really? Then I wonder what thehell is wrong with my checkout
rrot: r38656 | Infinoid++ | trunk (6 files):
[cage] Some codetest fixes.
Infinoid something different about our machines perhaps
got a backtrace? 22:00
Whiteknight what machine are you on? I'm Ubuntu 9.04, x86-64
Whiteknight is getting a backtrace right now
Infinoid gentoo x86-64
Whiteknight nopaste? 22:02
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "Whiteknight" at 69.249.200.13 pasted "packfiledirectory.t failures for Infinoid++" (67 lines) at nopaste.snit.ch/16511
Whiteknight I printed out the contents of some of the parameters too, the "value" pmc has 0xdeadbeef for it's vtable 22:03
actually, I guess that makes sense since it should be an integer, right?
Infinoid no, integer pmcs still have vtables 22:04
otherwise VTABLE_get_integer() wouldn't work :)
if its vtable is 0xdeadbeef, it probably means it was recycled but something else still had a pointer to it 22:05
though... what that has to do with explicit freeing of retcontinuations, I dunno
Whiteknight I just traced through, and the code before and after the branch in src/pmc/retcontinuation.pmc:invoke does exactly the same stuff 22:08
the same lines of code are executed in the same order
So I dont know why prior to the merge the test passes for me, and afterwards it fails
Infinoid some change in trunk, I guess 22:09
Whiteknight yeah
Infinoid at the time of the crash, does your pmc pointer value change every time you run it?
Whiteknight which pointer value?
p value?
Infinoid nah, pmc 22:10
usually when I have to debug this kind of crash, I end up having to set a watchpoint... but the linux kernel seems to randomize stack or heap locations and I have to turn that off before I can reliably set a watchpoint
Whiteknight just ran it 5 times, diffrent each time
I'm no good with watchpoints
Infinoid it's a pain anyway. would help to boil down the test case first 22:11
dalek rrot: r38657 | cotto++ | branches/pmc_pct/compilers/pmcc/src/emitter/pmc.pm:
[pmcc] only generate ATTR-related code when there are ATTRs
 22:12
Whiteknight chromatic is going to be unhappy that I borked up his optimization 22:14
Infinoid sounded like his optimization was borked on darwin anyway :) 22:15
cotto He said it was "slightly dangerous".
Infinoid I had asked him to review my fix, as I dunno the code very well
Whiteknight actually, I think I just had a suspicion about what may be causing it
we're manually freeing the RetContinuation PMC, but we're not NULLing out the pointer to it in the Context structure 22:16
Infinoid but when you do NULL out the pointer in the Context structure, you get SIGBUS on darwin :)
Whiteknight that's particularly strange to me. We shouldn't get SIGBUS on a structure field access, the compiler should properly align that 22:17
Infinoid The SIGBUS didn't happen until way later, and it was just untracable memory corruption. masak++ narrowed it down by bisecting old revisions
Whiteknight I don't want to null out the pointer to the context, I want to null out the pointer in the context to the PMC 22:18
Infinoid some (apparently completely unrelated) PMC pointer was NULL when it shouldn't have been
Whiteknight goes digging
Infinoid gist.github.com/109252 was his backtrace
(but it doesn't clear things up much) 22:19
Whiteknight no
Infinoid he ended up with an RPA that had a NULL pointer to the item[] array, and a size (number of members) value of 12945440 22:20
Whiteknight that's quite strange indeed 22:30
so a null pointer deref in darwin raises SIGBUS instead of SIGSEG?
Infinoid apparently... the two are pretty similar 22:32
jonathan Whenever I've debugged problems along these lines, it's often tended to boil down to 22:33
Infinoid they both mean "there isn't any memory mapped to that address range, dork", for varying values of "mapped"
jonathan Something still references a PMC but isn't telling the GC about it. 22:34
So the memory gets re-used for something else
And you get corruption from the two things trying to do different things with the PMC.
Infinoid indeed 22:35
jonathan In this case, my suspicion is that the RetContinuation is still referenced in some way, or at some point during the re-cycle the GC ends up thinking it is claimable.
Infinoid I'm wary about the whole idea of explicitly freeing PMCs, for this reason
especially since we don't refcount them
jonathan If they are explicitly created and freed within a given scope and have no chance to escape it ain't so bad. 22:36
But otherwise it's dangerous.
Particularly with RetContinuations, which can in their life time cease to be RetConts.
Infinoid I'm not even really sure what a RetContinuation *is*, but I had been assuming (from previous hacks in this code) that there's some sort of guarantee that there's only one reference to it
jonathan (e.g. when they are upgraded to full ones) 22:37
Infinoid But apparently there isn't.
jonathan That may be the intention. The failing here may be that the code doesn't check if the PMC was upgraded to a full continuation.
If you recycle something that got upgraded you're probably quite screwed. 22:38
(It's done as a v-table swap.)
Infinoid You're way over my head. Are there some docs I can read so I can understand without slowing you down? :)
(I'm not sure why or when you'd do that morph, or exactly what it means)
jonathan I've mostly gone on reading the code when I've been debugging stuff in that area more than reading docs. :-| 22:39
As far as I can grasp it, the idea of a RetContinuation is that it's "one shot" - that is, we'll only ever invoke the continuation once and we're done. 22:40
Which is the case for a straightforward thing-that-invokes-then-returns.
And when you start getting contexts referecning each other in more complex ways, that return continuation needs to become a full one.
I think some copying then takes place, or at least referencing incrementation on the contexts (since those are ref-counted). 22:41
Whiteknight well, my idea didn't pan out
Infinoid Do you create a RetContinuation when invoking a new sub, then? And convert to a Continuation when you somehow end up making a closure out of it?
jonathan And we change the vtable pointer to Continuation from RetContinuation.
As far as I can understand it, yes.
Infinoid Makes sense, thanks 22:42
jonathan Anyway, the point is that in the lifecycle of a call, you can't rely on something that once was a RetContinuation staying as one.
Whiteknight but if it's not a retcontinuation anymore, then it wont call retcontinuation:invoke and therefore won't be explicitly freed
but you're right, something still is pointing to this object
jonathan Whiteknight: I can't quite tell exactly what's going on in this case, but I think it's something along these lines. 22:43
Infinoid Would boiling down the test case help?
Whiteknight Infinoid: I imagine so 22:48
what really needs to happen, I think, is to trace through a subroutine call and take note of all the places where a RetContinuation PMC is examined 22:49
and make sure that all those pointers are killed before explicitly freeing the retcontinuation
Infinoid
.oO(wouldn't it be nice if we had a nice GC system to do all that hard work for us)
 22:50
jonathan Oh, hmm 22:51
Whiteknight: Did you change the call to destroy and the free to Parrot_gc_free_pmc_header(interp, SELF); ? 22:53
Does that also call destroy?
If not we at least would leak memory.
You're right though. If we make it into invoke of the retcontinuation pmc, I don't see any code path between then and the freeing that would get us an extra reference. 22:54
Whiteknight: Also, when we free a normal continuation, we do 22:57
if (cc->from_ctx)
Parrot_free_context(interp, cc->from_ctx, 1);
In the destroy vtable mthod.
In a RetContinuation we don't do that.
Whiteknight: Oh, false alarm. 22:58
When a continuation is upgraded it takes on an additonal reference to the context.
So it balances ups.
So in conclusion, nothing jumps out as me at wrong in that department. 23:01
Whiteknight yeah, I didn't see anything obvious either 23:13
(sorry about delay, was eating)
when do RetContinuations upgrade to Continuations? 23:14
I know that it does happen, but I dont know in what situation
jonathan Look up (IIRC) retc_invalidate 23:15
When there is an outer I think they do.
But there may be other cases too. 23:16
Ah, maybe for with co-routines also.
Whiteknight oh, like in a tailcall?
okay, that makes good sense
jonathan I don't think a tail call would do it.
I mean :otuer
*:outer
If you have one of those you can make a closure.
Whiteknight okay 23:17
jonathan: Does rakudo build properly on Parrot HEAD now? 23:26
I want to make sure the GC refactor didn't bork anything higher up the chain
I did some testing, but I don't think I did enough 23:27
szbalint masak++ 23:28
23:28 kid51 joined
jonathan Whiteknight: Let me pull and check. 23:28
erm, svn up
ETOOMUCHGIT 23:29
szbalint git svn rebase? :)
jonathan I never got to trying git svn yet. :-)
No idea how that works on Windows.
*Windows
For better or worse, my contributions to Parrot these days are relatively few, mostly smallish bug fixes. 23:30
dalek rrot: r38658 | jkeenan++ | branches/splint:
Following discussion with petdance, removing a branch which hasn't been touched in 22 months.
jonathan So don't deal with svn branches so much now that Rakudo moved over to git. 23:31
Whiteknight you're lucky, branches are TEH EVILZ!
jonathan Yeah, I don't admire git's learnability, but it's branch management is good. 23:32
kid51 has no problem with svn branches. 23:33
szbalint svn branches become nasty when your directory that you branch contains >100MB or so, before that it's fine I guess. 23:34
bacek good morning from future 23:36
cotto: around?
cotto bacek, nope
this is a bot
bacek cotto: it's good. Then I can brake pmc_pct branch
cotto cotto's bot gives you permission 23:37
jonathan ponders testing the bot's intelligence
cotto, bacon?
bacek cotto: good gir^W bot
cotto want
jonathan OK, it's intelligent. :-)
bacek cotto: swine flu
purl swine flu is the Swine Flu of our times!
cotto prefer bacon 23:38
jonathan purl sets a low standard. :-)
purl jonathan: huh?
bacek It's intelligent :)
cotto: ok. I broke c_body emitting.
in r38659 23:39
cotto go crazy. I don't have any pending work.
dalek rrot: r38659 | bacek++ | branches/pmc_pct/compilers/pmcc (5 files):
Initial parsing of VTABLE macros such as SELF, SUPER, etc. Emitting is broken
 23:40
cotto afk
(and the bot too)
davidfetter
.oO(and your little dog, too!)
 23:42
bacek want multi-dispatch in NQP... 23:54
jonathan bacek: Arity based? 23:55
bacek jonathan: PIR style. Even with manual supply of ":multi([Foo])" 23:56
dalek rrot: r38660 | bacek++ | branches/pmc_pct/compilers/pmcc/src/emitter/c.pir:
Sligtly better c_body emitting
 23:57
rrot: r38661 | bacek++ | branches/pmc_pct/compilers/pmcc/t/06-body.t:
Fix test
bacek "sub foo :multi(_,['PAST';'Op']) { ... }"
something like this. Then I can write PMC compiler purely in NQP
jonathan bacek: Ah, you're walking the PAST tree? 23:59
bacek jonathan: yes.
jonathan bacek: Ah. That's not a common thing for other languages to do, so it's not so surprising you're finding it a pain point.
(Since most want to then just go down to PIR.)
bacek I'm emitting C code :)
jonathan Aye.

Powered by Cro and the Raku® Programming Language.

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

Thank you!