Camelia, the Perl 6 bug

IRC log for #parrot, 2009-08-28

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 mokurai joined #parrot
00:00 Whiteknight the exceptionhandler.t test pass?
00:03 Whiteknight haha, I used mk_native_pbc, the packfile tests are all still failing, and now 4 new tests are failing too
00:03 darbelo Say, is there any way to find the a PMC's class from the value of vtable->base_type ?
00:04 Whiteknight sortof
00:04 Whiteknight if it's a builtin type, you can figure it out. It's one of the enum_class_* values
00:04 bacek exceptionhandler.t works
00:05 Whiteknight awesome
00:05 bacek World Domination getting close :)
00:05 bacek Definitely $dayjob time.
00:05 darbelo Eh, at least I'll find out if it's a built in type. I'll go ack that.
00:05 bacek bb
00:32 dalek rakudo: 81d6216 | pmichaud++ |  (6 files):
00:32 dalek rakudo: Move prefix:<-> into the setting.
00:32 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​1d6216f5681a0ada0f6bc4eb0419950e030b486
00:32 darbelo Ok, it's Dec*Context destruction that segfaults, but I can't figure out what I'm doing wrong.
01:18 TiMBuS joined #parrot
01:21 dalek rakudo: d0b88cf | pmichaud++ | Configure.pl:
01:21 dalek rakudo: Check for some more needed Parrot files during Configure.pl .
01:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​0b88cf04a18714c1bbf7b2ad625e6d01ba4bc69
01:21 dalek rakudo: 586076e | pmichaud++ |  (5 files):
01:21 dalek rakudo: Move prefix:<~> into setting.
01:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​86076e86a1dd9d7a593342d86efdd5105db7b91
01:23 mokurai left #parrot
01:26 nopaste "bacek" at 211.29.157.151 pasted "Interesting failure for Whiteknight++ to look :)" (27 lines) at http://nopaste.snit.ch/17709
01:28 mokurai joined #parrot
01:40 theory joined #parrot
01:55 darbelo left #parrot
02:06 davidfetter joined #parrot
02:11 rhr joined #parrot
02:28 zostay joined #parrot
02:34 japhb joined #parrot
02:35 janus joined #parrot
02:37 mokurai joined #parrot
02:46 dalek rakudo: aab4bf9 | pmichaud++ | src/classes/ (3 files):
02:46 dalek rakudo: infix:<===> should not be defined in terms of infix:<==> or infix:<eq>.
02:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​ab4bf9ad6dcd1aa10ae5faa13855c44b00951f1
03:04 Andy joined #parrot
03:28 dalek rakudo: f351f60 | pmichaud++ |  (4 files):
03:28 dalek rakudo: Move infix:<ne>, infix:<!eq>, infix:<!=>, and infix:<!==> into setting.
03:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​351f6099c2b0b83a9a8ef70d0fe5bf940125b29
03:32 Coke joined #parrot
03:41 dukeleto joined #parrot
03:48 dalek partcl: r640 | coke++ | wiki/SpecTestStatus.wiki:
03:48 dalek partcl: massive update after running 'unfudge' (tools/tcl_test.pl --skip)
03:48 dalek partcl: many things that used to fail in tcl are now segfaulting instead.
03:48 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=640
03:50 dukeleto hola
03:52 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40835 - Ubuntu 9.04 amd64 (g++)
03:52 mikehh hi there
03:54 mikehh rakudo (f351f60) builds on parrot r40835, make test / make spectest (up to r28093) PASS - Ubuntu 9.04 amd64 (g++)
03:55 mikehh rakudo (f351f60) - t/spec/S05-match/capturing-contexts.rakudo - TODO passed: 14
03:59 mokurai joined #parrot
04:05 mikehh partcl r640 builds on parrot r40835 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (g++)
04:06 mikehh Coke: running make spectest in partcl
04:07 nopaste "dukeleto" at 72.11.81.253 pasted "blizkost fails to compile on darwin/perl 5.10.0" (97 lines) at http://nopaste.snit.ch/17710
04:07 dukeleto oops, wrong channel
04:31 dukeleto what does "positional inside named args at position 3" mean?
04:35 Coke ISTR the spec for PCC dictates where in the arg list named args can go.
04:35 Coke foo(1,2,3) has 3 positional args.
04:35 dukeleto is there an equivalent of warn() in parrot ?
04:36 Coke not really. "printerr" helps.
04:36 Coke I think the warning has to do with the .param listing: I think all the :named have to come at the end.
04:36 Coke there's a PDD about that.
04:37 Coke pdd03, line#246
04:38 dukeleto coke++
04:44 cognominal joined #parrot
04:47 dukeleto is there something like warn Dumper [ $foo ] for parrot ?
04:47 Coke look at the data dumper lib.
04:48 Coke .macro dumper(dingus) load_bytecode 'dumper.pbc' load_bytecode 'PGE/Dumper.pbc' $P9999 = get_root_global ['parrot'], '_dumper' $P9999(.dingus)
04:48 Coke .endm
04:49 dalek partcl: r641 | coke++ | wiki/SpecTestStatus.wiki:
04:49 dalek partcl: svn up parrot by one, reclaim a few more tests.
04:49 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=641
04:49 dalek partcl: r642 | coke++ | trunk/config/PARROT_VERSION:
04:49 dalek partcl: This version avoids a few more segfaults.
04:50 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=642
04:50 dukeleto coke++
04:50 dukeleto jonathan: ping
04:56 dalek parrot: r40836 | dukeleto++ | trunk/t/op/gc.t:
04:56 dalek parrot: [TT #950][t] Convert t/op/gc.t to PIR, jrtayloriv++
04:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40836/
04:56 dalek TT #950 closed by dukeleto++: [PATCH]: Convert Perl tests to use test_more.pir for t/op/gc.t
04:57 dukeleto why does load_bytecode silently fail when it can't find the file? I find that highly annoyting
04:57 dukeleto annoying even
04:57 Coke old battle between return null and throw exception.
04:59 mikehh partcl make spectest - still get 4 -> !! child died with signal 11, without coredump
05:01 Coke mikehh: which version of parrot?
05:02 purl which version of parrot are you using?
05:02 mikehh partcl mathop, between magcat and namespace (fails straight away), subst and while-old
05:02 mikehh parrot r40835 - Ubuntu 9.04 amd64 (g++)
05:03 Coke hurm. at r40826, namespace.test did not segfault for me.
05:03 dukeleto coke: A method named '__dump' already exists in class 'PGE;Match'. It may have been supplied by a role. :(
05:04 Coke dukeleto: what kind of objects are you trying to dump?
05:04 Coke (if not PGE, you don't have to use the PGE/Dumper)
05:04 mikehh Coke: not namespace - the test between msgcat and namespace - it doesn't say which one it is
05:04 dukeleto Coke: ResizableStringArray or things that contain them
05:05 Coke mikehh: ah!
05:05 Coke that's 'info'. the output is odd on that one, yes.
05:06 dukeleto Coke: i get that error even when not loading 'PGE/Dumper.pbc' . it might be loaded by blizkost already
05:07 Coke mikehh: hurm. none of those failed for me at 40825. running another check at 40826.
05:07 Coke (of parrot)
05:07 Coke danke.
05:08 mikehh Coke: I logged the results - do you want it?
05:09 Coke not today; thanks for running the tests.
05:09 mikehh 'k
05:11 mikehh anyway will run some more tests later
05:14 Coke (&*#$ tests pass when run standalone but segfault when run in 'tools/spec_info.pl' :P
05:18 bacek_at_work Coke: I've got "good" news for you. PGE use some uninitilised values inside...
05:21 Coke ... which might be causing my occasional segfaults?
05:22 bacek_at_work Coke: it can be
05:24 Coke seems like parrot could warn us when we use a register that didn't have a value assigned to it.
05:25 Coke (during compilation, even.)
05:26 Coke if you could fix it, I'd appreciate it. =-)
05:26 Coke (your report, not my wishlist)
05:29 cotto particle or jonathan, ping
05:30 dukeleto Coke: depends on the register, right?
05:30 dukeleto Coke: $P0 should return PMCNULL if nothing is there, correct?
05:33 bacek_at_work It's INT registers.
05:35 dukeleto there are things, at least from C-land, that you can check to see how many regs of a certain type exist. the debugger uses them
05:36 dukeleto i found that in the debugger, if you attempt to print a register, and disable the check for looking if that many registers of that type exist, you just get random garbage data back
05:51 dukeleto joined #parrot
06:02 uniejo joined #parrot
06:06 dukeleto joined #parrot
06:10 rbaumer joined #parrot
06:17 desertm4x joined #parrot
06:33 HG` joined #parrot
06:59 kjeldahl joined #parrot
07:00 uniejo joined #parrot
07:01 mrsaturn joined #parrot
07:04 iblechbot joined #parrot
07:04 rbaumer joined #parrot
07:08 dukeleto joined #parrot
07:21 mokurai joined #parrot
07:24 dukeleto seen jnthn
07:24 purl I haven't seen 'jnthn', dukeleto
07:24 dukeleto seen jonathan
07:24 purl jonathan was last seen on #parrot 21 hours, 53 minutes and 42 seconds ago, saying: Ah, broken copy op woulda caused problems in Rakudo for sure. It's used very heavily.
07:28 dukeleto msg jnthn i have created some issues for blizkost at http://github.com/jnthn/blizkost/issues
07:28 purl Sorry, I've never seen jnthn before.
07:28 dukeleto msg jonathan i have created some issues for blizkost at http://github.com/jnthn/blizkost/issues
07:28 purl Message for jonathan stored.
07:28 GeJ Good morning everyone
07:29 dukeleto GeJ: good localtime()
07:29 cotto hi dukeleto
07:30 dukeleto cotto: werd up
07:30 cotto are you on windows by chance?
07:31 dukeleto cotto: thankfully, no ;)
07:32 dukeleto cotto: i can test stuff on linux/os x/freebsd for you, if that helps
07:32 cotto nope.  I need some win32-specific code tested.
07:33 cotto I should see about getting my XP VM running again.
07:34 cotto It's hard to find anyone who's got a windows box ready for testing.
07:40 dukeleto cotto: you need to talk to alias in #msopensource
07:40 cotto dukeleto, good idea.  Ironically I helped get that started.
07:40 dukeleto cotto: have you heard of the farm of windows boxen that CPAN developers have access to now? they have every permutation of win32 that you could want, with VNC access to them all
07:40 dukeleto cotto++
07:41 cotto yeah
07:41 dukeleto i have a login but haven't utilized it much yet because I haven't touched windows in a long while
07:45 cotto Looks like I'll need a CPAN id.
07:48 cotto It'd be really ironic if I couldn't get a access because I'm not a Perl 5 hacker.
07:51 he BTW, did anyone pick up and commit the patch for NetBSD FP handling I posted here the other day?
07:53 cotto he, can you renopaste it?  I'll commit it if it's sane and nobody else already did.
07:56 he sure.
07:57 dukeleto cotto: say that you will be testing Blizkost and you will be in the clear :)
07:57 nopaste "he" at 158.38.152.119 pasted "Patch to fix FP variant selection for the NetBSD math library" (44 lines) at http://nopaste.snit.ch/17711
07:58 dukeleto he: i saw that and liked it, but didn't try it
07:59 he It's a patch applied to 1.5.0; needed it for the self-tests to pass on NetBSD/i386 when I updated the pkgsrc package.
08:01 cotto he, I assume make test passes with that patch applied?
08:01 cotto I'd test it, but a patch to that file can only effect netbsd.
08:02 dalek parrot: r40837 | cotto++ | trunk/config/gen/platform/netbsd (2 files):
08:02 dalek parrot: [platform] netbsd fp variant selection fix from he++
08:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40837/
08:02 rbaumer joined #parrot
08:11 he cotto: yes, make test passes with it applied (I uploaded a smoke test; look for the latest netbsd test)
08:12 he thanks, btw.
08:12 cotto thanks for the patch, he
08:31 mj41 cotto: I can probably setup some VMware Windows box for Parrot developers. Not sure if our university has some Server licenses. Probably yes, for development (no production, no comercial).
08:31 cotto mj41, that'd be great
08:32 mj41 irc://irc.perl.org/msopensource can't help ?
08:32 cotto ideally we could get in with Alias' CPAN Testing Lab, but any access would be helpful
08:32 cotto I've pinged Alias.
08:36 mj41 WinXP Professional is not problem, but it's one user at one time only.
08:37 cotto That'd be fine.
08:37 payload joined #parrot
08:44 dalek parrot: r40838 | dukeleto++ | trunk/docs/book/pct/ch03_compiler_tools.pod:
08:44 dalek parrot: [cage] Fix some typos in docs/book/pct/ch03_compiler_tools.pod
08:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40838/
08:47 dalek parrot: r40839 | fperrad++ | trunk/tools/dev/fetch_languages.pl:
08:47 dalek parrot: [languages] add blizkost
08:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40839/
09:23 cotto joined #parrot
09:33 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40839 - Ubuntu 9.04 amd64 (gcc)
09:35 cotto joined #parrot
09:45 mikehh rakudo (7666e92) builds on parrot r40839, make test / make spectest (up to r28096) PASS - Ubuntu 9.04 amd64 (gcc)
09:47 MoC joined #parrot
09:54 mikehh partcl r642 builds on parrot r40839 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (gcc)
09:55 dukeleto mikehh++
09:58 mikehh messages
09:59 mikehh dukeleto: how did you get on with the NaN stuff
10:00 dukeleto mikehh: complex NaN is still broken, some rounding NaN is still broken. but I wrote a bunch of tests :)
10:01 dukeleto the fact that complex numbers don't obey NaN is the broken-ness
10:01 mikehh tests good - dukeleto++
10:01 dukeleto so you can get NaN+5i and such
10:01 dukeleto but you have to be tricky
10:03 mikehh so you can get a NaN calculating the real part which does not effect the i part (or vice versa)
10:03 mikehh affect
10:04 dukeleto mikehh: yep
10:04 donaldh joined #parrot
10:04 dukeleto mikehh: see t/op/inf_nan.t for all the fun details :)
10:05 mikehh will have a look
10:07 dukeleto when a Numeric PMC register containing NaN is cast down to an Integer register, internal things go south and a machine-dependent number is returned (-2147483648 on my system)
10:07 dukeleto and the Complex PMC knows nothing of NaN
10:09 mikehh do we have any standards to follow on this?
10:10 mikehh what does ieee 794 (I think) have to say
10:10 dukeleto actually it is just for a plain numeric register, not a pmc numeric, that it happens. at least that is what the tests are for. numeric pmc's probably have the same issue, but those tests aren't written yet :)
10:10 dukeleto mikehh:ieee754
10:11 dukeleto mikehh: it probably has a lot to say ;)
10:11 mikehh yup that's right
10:15 dukeleto also, there are many "flavors" of ieee754, 1985, 1987 and 2008. i am just going to assume that parrot would like to support 2008 unless someone can explain why that would be a bad idea
10:15 dukeleto mikehh: http://www.validlab.com/754R/nonabe​lian.com/754/comments/Q754.129.pdf is the draft for 2008, the actual pdf requires a login
10:16 dukeleto mikehh: it has documentation about quiet and singalling NaN, woohoo
10:16 * dukeleto realizes he is one of the few people who gets excited about NaN
10:21 dukeleto wow, ieee754 thinks up some crazy shit to do with NaN's, this is scary :|
10:30 cognominal joined #parrot
10:30 mikehh dukeleto: was just looking at http://speleotrove.com/decimal/ which has been updated since he last looked
10:40 mikehh looked in the t/op directory - loads of files - need to look after a make realclean :-}
10:45 mikehh my editor nearly had a fit - invoked swap - I thought it had died - t/op -> 2,333 items, totalling 3.2 MB
10:46 dukeleto mikehh: lots of generated files :)
10:47 mikehh especially after running fulltest -> testr whivh generates .pbc files as well
10:47 mikehh which
10:47 dukeleto i think -2147483648=ilogb('NaN'), that is actually one of the failure modes in ieee754
10:48 * dukeleto needs sleep
11:03 desertm4x joined #parrot
11:04 dalek TT #954 created by dukeleto++: Inf/NaN from ieee754-2008
11:20 donaldh joined #parrot
12:07 dalek partcl: r643 | coke++ | trunk/docs/spectest- (2 files):
12:07 dalek partcl: update spectest data;
12:07 dalek partcl: - try to run everything that completes.
12:07 dalek partcl: - includes some segfaults from previously passing tests, skipping those in next
12:07 dalek partcl: commit.
12:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=643
12:07 dalek partcl: r644 | coke++ | wiki/SpecTestStatus.wiki:
12:07 dalek partcl: 14!? more segfaulting tests with latest parrot.
12:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=644
12:08 Coke ok. there are now /forty one/ partcl spec tests that are segfaulting.
12:08 Coke out of 137.
12:09 Coke 41/137
12:09 purl 0.299270072992701
12:09 Coke so, 30%.
12:11 szbalint ouch
12:16 ruoso joined #parrot
12:16 cosimo joined #parrot
12:16 whiteknight joined #parrot
12:19 whiteknight good morning #parrot
12:25 NotFound whiteknight: what do you said about kicking asses?
12:25 whiteknight I said you're doing it
12:26 NotFound Soemones's ass, or bug's ass?
12:26 whiteknight bugs ass
12:26 NotFound Ah, nice
12:26 whiteknight and generally being awesome
12:27 NotFound Thanks
12:27 szabgab joined #parrot
12:29 quek joined #parrot
12:49 Coke NotFound, whiteknight : with notfounds last fixes, I get most of my spec tests back, but I'm now up to 41 spec test segfaults in partcl.
12:50 Coke After $DAYJOB today, I'll try to track some of them down more specfically, but for now, the list of segfaults is on the partcl wiki at SpecTestStatus if anyone wants to go segfault hunting.
12:50 Coke (I run against an optimized parrot; some of those may revert to assertion errors in a non-opt parrot)
12:51 NotFound Coke: partcl uses asignment to Undef, isn't it?
12:52 Coke I believe we do, yes.
12:52 NotFound I'm looking at that now, looks broken to me even if it pass tests
12:53 Coke the concept, or the current impl?
12:53 NotFound Impl
12:54 Coke ok. I'm surprised that I don't have MORE failures if that's borked, but I'm happy to test (or show you a test that's failing right now)...
12:55 Coke if-old is probably the shortest test on the list. (build parrot, install it, build partcl, then you can: "./tclsh t_tcl/if-old.test"
12:55 NotFound I'm testing now an attempt of ix.
12:55 Coke ix?
12:55 purl ix is boring i mean professional programming magazine :)
12:55 NotFound fix
12:55 Zak joined #parrot
13:49 whiteknight kid51 ping
13:53 whiteknight purl msg kid51 I don't think I'm going to make it up to NYC in September. My wife is having a baby shower then so we have to be in town. Sorry!
13:53 purl Message for kid51 stored.
13:53 Coke there's a nyc thing in september? hurm.
13:54 whiteknight not a "thing". I was supposed to be in town on unrelated business
13:55 whiteknight well, my wife was supposed to be in town and I was in charge of driving her there (and back again)
13:55 Coke ahhh.
13:55 whiteknight which would have left me in NYC with nothing to do for an afternoon
14:00 quek left #parrot
14:06 rbaumer joined #parrot
14:11 kid51 joined #parrot
14:12 Coke kid51: hio
14:12 kid51 hello
14:12 purl hello, kid51.
14:14 Andy joined #parrot
14:16 NotFound I think I've found a serious bug: the stacktop for GC marking is not set when calling PackFile_fixup_subs
14:18 Coke I don't know what that means, but woot. =-)
14:18 kid51 msg pmichaud Please see  https://trac.parrot.org/pa​rrot/ticket/936#comment:9 re 'make install' problems.
14:18 purl Message for pmichaud stored.
14:21 Psyche^ joined #parrot
14:21 NotFound Coke: it may mean that with a two line change most segfaults wil disappear
14:21 Coke NotFound: I'd be excited to test that patch.
14:27 cosimo joined #parrot
14:27 nopaste "NotFound" at 213.97.96.43 pasted "Set stacktop in packfile fixups" (22 lines) at http://nopaste.snit.ch/17714
14:27 NotFound Well, 3 lines ;)
14:28 Coke YOU DIRTY LIAR!
14:29 Coke </humor>
14:31 Coke bah. when pbc2exe was failing, I created a shell script called 'mytcl' that wrapped the call to parrot. I should have called it tclsh; my fingers type that all the time now.
14:32 Coke NotFound: util.test gets past the original segf.
14:33 Coke so this was a GC bug?
14:33 Coke woot: util.test:      Total   290     Passed  130     Skipped 128     Failed  32
14:33 NotFound Coke: maybe *the* GC bug
14:34 Coke damnit, I was going to finally post a ranty blog entry on partcl complaining about the (&#$ segfaults. you stole my thunder!
14:34 Coke (I will do an unfudge run and see if this magically fixes everything. =-)
14:35 NotFound Not everything, but maybe a lot of tests can be unskipped
14:38 Coke fixed 2/3 so far. 38 to go. =-)
14:38 NotFound Coke: 2/3 of partcl segfaults?
14:39 Coke I have run the test for 3 spec tests that were segfaulting, 2 no longer segf with your patch.
14:39 Coke (will take a while to run the remaining 38 tests that were segfaulting.)
14:39 NotFound Not so bad :)
14:41 Coke (esp since I'm just running all 72 skipped tests, some of which are looong.)
14:41 ewilhelm joined #parrot
14:41 kid51 whiteknight ping
14:42 whiteknight pong
14:44 kid51 Thanks for prodding on tt509_install_files branch.  Am testing wayland's last patch.  Will post results and ask for comments and testing on systems/situations that don't support symlinks.
14:45 whiteknight gotcha
14:45 kid51 Also, sorry NYC trip is off?
14:45 whiteknight yeah, plans got changed that weekend
14:45 kid51 whiteknight:  Had you given any thought to the Victory brewery tour on Sat Sept 12?
14:45 Coke NotFound: OOC, did tcl prod you to find that segfault maker, or did you just find it during code analysis, or...?
14:46 whiteknight kid51: you going to that?
14:46 kid51 I was thinking of driving down for that.
14:46 kid51 It falls into the Excuses to Get Out of Town Department.
14:46 whiteknight that's actually right down the road from where I work, the wife of the guy who owns Victory works with me
14:47 kid51 It's being organized by ABE.pm, but I believe details have also been posted on Phila.pm list
14:47 whiteknight yeah, I've seen the emails flying bye
14:48 kid51 Well, keep it in mind and I'll ping you about it right after Labor Day.
14:48 whiteknight when is labor day?
14:48 kid51 Mon Sep 7
14:48 * whiteknight is not nearly as good with a calendar as he is with a keyboard
14:48 whiteknight okay
14:53 NotFound Coke: I looked at the backtrace of the test you said me
14:53 NotFound whiteknight: take a look at my last nopaste
14:56 dalek parrot: r40840 | jkeenan++ | branches/tt509_install_fil​es/lib/Parrot/Install.pm:
14:56 dalek parrot: Applying patch submitted by wayland++ in https://trac.parrot.org/parrot/attach​ment/ticket/509/symlink_copier.patch.  Needs testing in non-symlinkable situations.
14:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40840/
15:03 kid51 So, we can use testing (perl Configure.pl --prefix=/home/user/some_safe_directory && make manifest_tests && make && make install && make install-dev) of the tt509_install_files branch on Win32 and also on, e.g., Linux w/FAT32 filesystems.  See TT509.
15:19 mokurai joined #parrot
15:27 theory joined #parrot
15:35 Coke NotFound: looking good here, though it'll take some time to go through all the tests; anything stopping you from applying that?
15:45 nopaste joined #parrot
16:05 dalek TT #936 closed by pmichaud++: "make install" doesn't install PCT
16:05 pmichaud msg kid51  Added note to #936, closed ticket, thanks!
16:05 purl Message for kid51 stored.
16:08 Coke NotFound: the segfaults are still squishy. (util.test ran to completion by itself; in the spec test, boom.
16:09 Coke as part of the spec test, that reclaims 12 test files out of 41 segfaults, though.
16:14 kjeldahl joined #parrot
16:18 NotFound Coke: not so bad, I'll commit it now
16:20 darbelo joined #parrot
16:22 dalek parrot: r40841 | NotFound++ | trunk/src/packfile.c:
16:22 dalek parrot: [gc] mark stacktop in PackFile_fixup_subs
16:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40841/
16:23 darbelo NotFound: while you're looking at segfaults. decnum-dynpmcs is still seeing segfaults during interpreter destruction.
16:24 NotFound darbelo: Are you using auto_attrs in the pmcs?
16:25 darbelo Nope. and attr_size is correctly set to 0, from what I've been able to see it segfaults when calling VTABLE_destroy()
16:25 MoC joined #parrot
16:26 darbelo If I remove the active_destroy flag everything is fine.
16:26 JimmyZ joined #parrot
16:27 NotFound darbelo: What trunk release is merged into that branch?
16:28 darbelo I'm working against trunk. decnum-dynpmcs is my GSoC project.
16:28 yath joined #parrot
16:28 yath heya
16:28 darbelo purl: decnum-dynpmcs?
16:28 purl decnum-dynpmcs is http://code.google.com/p/decnum-dynpmcs/ or a 2009 GSoC porject or a set of 'big' decimal arithmetic types for parrot.
16:28 NotFound Ah, ok, I was mixing things in my head.
16:29 yath the docs for PCT tell me to use mk_language_shell.pl for building a scaffold, but i can't find that on a halfway recent parrot...
16:29 yath what should i use instead?
16:30 pmichaud you might need "install-dev" for parrot
16:30 pmichaud afk # lunch
16:30 yath euh, i was not going to do make install* or so..
16:31 nopaste "darbelo" at 200.49.154.172 pasted "The segfault." (15 lines) at http://nopaste.snit.ch/17716
16:33 darbelo NotFound: removing either the active_destroy flag OR the singleton declaration for the PMC fixes the segfault.
16:36 darbelo Thing Is I can't find anywhere in the pmc-destruction code where singleton-ness is checked for or where it should matter at all.
16:36 Coke <sigh> partcl's 'make test' is now failign after updating parrot.
16:37 darbelo Coke: does partcl use any sigleton PMCs with the active_destroy flag set?
16:38 Coke ... and now it's not. wtf. I swear, someone with root on feather is messing with me.
16:39 Coke darbelo: not unless it's a core pmc.
16:39 darbelo Coke:
16:40 darbelo Coke: Then you can feel lucky. There's at leat one parrot bug that isn't biting you.
16:41 NotFound Someone should write "Singleton considered harmful"
16:42 darbelo I sort of did, back when I started using them :)
16:43 darbelo http://www.parrot.org/content/singleto​ns-how-create-them-and-way-abuse-them.
16:43 NotFound darbelo: you can try to use Parrot_atexit for the destruction.
16:44 dalek partcl: r645 | coke++ | wiki/SpecTestStatus.wiki:
16:44 dalek partcl: unfudge some tests thanks to NotFound++
16:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=645
16:44 dalek partcl: r646 | coke++ | trunk/config/PARROT_VERSION:
16:44 dalek partcl: NotFound++ # fewer segfaults at this revision.
16:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=646
16:46 darbelo I can just leak the memory, singletons are immortal anyway. But I'd like to confirm that it's a bug on parrot and not my code.
16:46 Coke (P*&@#$(*&@#$(*@#&$(*@#$&(@#*$&@#
16:47 NotFound I don't know if destruction of singletons has been planed or even thinked about.
16:47 Coke (unfudge test a. run test in harness. test now segfaults.)
16:47 Coke This is reaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa​aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaally frustrating.
16:47 Coke perhaps I will now get to write my snarky blog post after all, despite NotFound. =-)
16:48 NotFound Coke: you can write it anyway
16:48 darbelo s/destruction o //
16:49 darbelo 'There can only be one of this' != 'make it immortal'
16:50 darbelo Highlander references notwithstanding :)
16:51 yath hm. docs say i should run mk_language_shell.pl in languages/, but there is no languages/. is compilers/ the successor?
16:52 darbelo yath: nope. Languages have left the nest. They live outside of the parrot tree now.
16:52 NotFound You can just mkdir ir for testing
16:52 yath darbelo: hm. and where would i get started (as in: in which directory) to do some fiddling with parrot?
16:52 yath err, PCT
16:52 yath ah ok
16:53 yath $ ../../parrot test.pbc
16:53 yath >
16:53 yath \o/
16:53 yath thanks :)
16:53 darbelo Anywhere you like, actually. I think create_language.pltakes an argument for the directory it should put stuff into.
16:53 NotFound Coke: What test is failing now?
16:53 Coke sadly, we have, what, 2 different ways to create a language shell?
16:54 Coke NotFound: -appendComp.test, -compExpr-old.test
16:54 Coke 2/12
16:54 purl 0.166666666666667
16:54 darbelo Coke: Yup, and neither one did exactly what I wanted last time I tried them :)
16:55 Coke so that's already lost 17% of the gains you just made, just by running the full harness instead of just an unfudging run.
16:55 darbelo But what I wanted was fairly odd too. So I guess it's ok.
16:55 Coke (possible those are lost due to recent changes in parrto from my last run and your commit.)
16:56 Coke (just by running) and I just started that spec test run, many more chances for regressions.
16:57 yath hm, where would i get a pir.vim from?
16:57 jrtayloriv joined #parrot
16:57 yath ah, got ir
16:57 yath it.
16:57 darbelo editor/ in the parrot tree
16:57 yath yep :)
17:03 NotFound Coke: Some easy to try segfault?
17:07 treed .
17:09 Coke notfound: ./tclsh t_tcl/appendComp.test
17:09 Coke (segfaults after 3rd test.)
17:09 Coke ... unless you run it in gdb, apparently. :P
17:11 NotFound Coke: doesn't segfault for me now, in a non optimized build.
17:16 Coke NotFound: try with --gc-debug
17:16 nopaste "coke" at 65.91.151.195 pasted "backtrace for notfound." (23 lines) at http://nopaste.snit.ch/17718
17:17 ruoso joined #parrot
17:27 Coke 9 new failures so far...
17:43 jrtayloriv I want to convert the tests in t/pmc/filehandle.t to use test_more.pir instead of Perl, but a lot of the tests are using the "create_tempfile()" sub from Parrot::Test::Util to create a tempfile before running the pir_output_is tests. Is there any way to get around using Perl here?
17:53 Coke NotFound: net loss of one test file after the update.
17:54 jrtayloriv Is there any reason that I can't just use -- tempfile = open 'tempfile', 'w' -- instead?
17:56 NotFound jrtayloriv: because a file with a fixed name is no good por people doing paralel tests
17:56 AndyA joined #parrot
17:58 Coke we probably need a File::Temp in parrot.
17:59 whiteknight_ joined #parrot
18:00 Coke jrtayloriv: so, skip that one.
18:03 jrtayloriv NotFound, thanks -- Coke, will do ;)
18:05 Coke jrtayloriv: https://trac.parrot.org/parrot/ticket/955
18:08 dalek TT #955 created by coke++: need ability to create tempfile from PIR
18:10 duk3leto coke++, i likes temp files
18:10 duk3leto is the current PID available from Parrot?
18:12 duk3leto jrtayloriv: making test_more.pir better is going to be necessary to convert many tests
18:13 NotFound BTW conveting to pir tests that have known problems not fully solved is not a good idea, and even worse doing it without testing in several different platforms.
18:16 Coke how can one converting tests know which ones have known problems?
18:17 NotFound Good question
18:17 purl Yeah, it is. I'm stumped.
18:17 Coke anything SKIPPED is dangerous.
18:18 NotFound Yeah, and converting to pir just to be forced to skip it is the worse of the ideas.
18:19 davidfetter joined #parrot
18:19 NotFound I mean, converting a todo that segfaults, for example.
18:19 Coke I'd be happy if todos/skips were left in foo-old.t
18:20 Coke I don't think it's a moral imperitive, but it's not worth expending extra effort on, sure.
18:36 joeri joined #parrot
18:39 szabgab joined #parrot
18:49 jrtayloriv As far as implementing create_tempfile() in PIR, File::Temp uses File::Spec::tmpdir() to check for the correct tmp directory ... ultimately, if tmpdir() doesn't find a tmp dir it is supposed to use, it just defaults to cwd -- is there any reason why the tempfiles for the tests should not be created in the test directory?
18:49 NotFound jrtayloriv: because they are temporary files
18:52 jrtayloriv NotFound, What would be the problem with having the temporary files in the test directory? Why is that a Bad Thing?
18:53 NotFound jrtayloriv: mainly, because people don't want that lots of files of unknown purpose appear in his work directories for unkown reasons.
18:55 jrtayloriv Doh ... that was dumb ... it's just because the files wouldn't get cleaned up if the test died. Sorry for the time waste.
18:56 pmichaud (create_language.pl)  -- I need to update that with the latest improvements from Rakudo's configuration
18:57 cotto anyone want to try a windows patch on pluggable_runcore?
19:00 Coke can we kill one or the other of those scripts?
19:01 cotto +1
19:01 purl 1
19:01 cotto +kick purl
19:01 Coke if we don't have a ticket, someone should make one.
19:02 Coke even if it doesn't decide which one to pick.
19:03 Coke ->
19:03 NotFound Coke: "There's more than one way to do it" ;)
19:08 particle cotto: i can try the patch
19:09 nopaste "cotto" at 74.61.2.46 pasted "runcores patch for win32" (17 lines) at http://nopaste.snit.ch/17719
19:10 cotto although it'd be nice to know first why those printf lines yesterday weren't printfing.
19:20 cotto That patch should work, but it'll also be vulnerable to noise from context switches.
19:21 nopaste "cotto" at 74.61.2.46 pasted "alternate runcores patch for win32 using GetProcessTimes" (27 lines) at http://nopaste.snit.ch/17720
19:23 cotto mj41, ping
19:38 dalek parrot: r40842 | NotFound++ | trunk/src/pmc/undef.pmc:
19:38 dalek parrot: [pmc] fix set_pmc vtable in Undef PMC
19:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40842/
19:45 particle cotto: neither patch changes anything, and i'm still not seeing the fprintf output
19:45 particle neither patch changes the 0 in second column, i didn't look closely for anything else
19:47 cotto That's not sane.
19:48 particle sadly, no :(
19:48 cotto Does src/platform.c have the right Parrot_hires_get_time function?
19:49 particle oh give me a break!
19:50 particle i need to reconfigure after i change this. duh.
19:50 cotto yeah
19:50 cotto that'd help
19:50 particle i'm just gonna modify src/platform.c
19:50 cotto fine by me
19:50 particle it takes too damned long to reconfig/compile
19:52 mokurai joined #parrot
19:52 particle cotto: i'm seeing a lot of <<<<<1>>>>> now
19:52 particle so the command is succeeding
19:52 mokurai left #parrot
19:53 particle but the times are still 0
19:54 cotto That shouldn't be the case for any program that takes more than 100ns.
19:55 particle your second patch doesn't change anything
19:57 particle the first patch works!
19:58 cotto the one with QueryPerformanceCounter?
19:58 particle ayep
19:58 nopaste "particle" at 76.121.106.245 pasted "hanoi.pir profiling output" (1301 lines) at http://nopaste.snit.ch/17721
19:58 cotto That's a lot better than nothing, but I really want to know what's not working about GetProcessTimes.
19:59 cotto Thanks!
19:59 particle ship it!
19:59 cotto I'll commit that and figure out what's wrong with GetProcessTimes when I have a windows box to play with.
20:00 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40842 - Ubuntu 9.04 amd64 (g++)
20:04 AndyA joined #parrot
20:07 mikehh rakudo (7666e92) builds on parrot r40842, make test / make spectest (up to r28100) PASS - Ubuntu 9.04 amd64 (g++)
20:08 Coke NotFound: is r40842 going to rock my wold?
20:08 chromatic joined #parrot
20:08 Coke ... world?
20:09 Coke wold: The yellow dye obtained from dyer's rocket.
20:09 NotFound Coke: don't know what to says, seems to change from build to build
20:09 chromatic msg whiteknight How encapsulated is the current GC?  If I wanted to fork the current M&S and use the linked list idea (I figured out the missing part today), how much work is it?  I also need to change the Arena structs slightly.
20:09 purl Message for whiteknight stored.
20:10 mokurai joined #parrot
20:10 chromatic NotFound, sudo echo 0 > /proc/sys/kernel/randomize_va_space ?
20:11 NotFound Uh, forgot to play with that,
20:11 AndyA joined #parrot
20:14 Coke NotFound: it sure does. :|
20:14 Coke chromatic: my segfaults are killing me. any help greatly appreciated. =-)
20:14 Coke NotFound++ # all his work so far today.
20:15 Coke bah. using git-svn, is there an easy way to get .parrot_current_rev to update after 'git svn rebase' ?
20:15 Coke (ATM I have to do a full rebuild or handedit the thing.)
20:16 Coke NotFound++ #good measure
20:16 PerlJam git svn info | awk '/Revision:/ { print $2 }' > .parrot_current_rev    # ?
20:17 PerlJam Coke: that was for you in case it wasn't obvious :)
20:17 Coke PerlJam: ... easier to edit it by hand. =-)
20:17 Coke (actually, easier (but slower) to just run my "rebase and re-intsall for tcl" script. =-)
20:18 mikehh partcl r647 builds on parrot r40842 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (g++)
20:18 Coke PerlJam++
20:19 PerlJam Coke: I wonder if there's a way to trigger scripts to be executed after "git svn rebase"  Seems like that would be a good thing for svn:ignore properties at the very least.
20:20 Coke PerlJam: that would be spiffy.
20:20 NotFound Mmmmm... looks like r40842 breaks a rakudo spectest
20:20 cotto Now I can finally go back to not caring about windows.
20:20 Coke with it got a failure in 'make test' that went away when i ran the test by hand.
20:21 mikehh NotFound: which - I just PASSed them all
20:21 chromatic Coke, PerlJam, I have a script to reconfigure Parrot and rewrite config_lib.pasm whether I use svk or git.
20:21 PerlJam chromatic++
20:21 dalek parrot: r40843 | cotto++ | branches/pluggable_runcore/config/​gen/platform/win32/hires_timer.c:
20:21 dalek parrot: [profiling] Switch to QueryPerformanceCounter for high-resolution timing info on win32.
20:21 dalek parrot: GetProcessTimes would be ideal because it won't record time spent by other processes, but it's goofy and this isn't.
20:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40843/
20:22 PerlJam I guess an ordinary post-receive hook would probably be able to do it.
20:23 nopaste "chromatic" at 72.87.39.97 pasted "Reconfigure Parrot" (1 line) at http://nopaste.snit.ch/17722
20:23 duk3leto chromatic: welcome back
20:23 purl Your dreams were your ticket out.
20:23 NotFound mikehh: S12-attributes.clone
20:23 Coke *snrk*
20:23 nopaste "chromatic" at 72.87.39.97 pasted "Rewrite config_lib.pasm" (19 lines) at http://nopaste.snit.ch/17723
20:24 NotFound Mmmm... maybe the test pass, even if segfaults at exit
20:25 nopaste "coke" at 65.91.151.195 pasted "this is the second segfault bt with recent parrot in Parrot_String_mark" (23 lines) at http://nopaste.snit.ch/17724
20:25 mikehh NotFound: passes for me and ./perl6 t/spec/S12-attributes/clone.t passes all 12 tests
20:26 dalek partcl: r647 | coke++ | wiki/SpecTestStatus.wiki:
20:26 dalek partcl: More spectest churn.
20:26 dalek partcl: Previously passing tests segfaulting after update. (cancels out all the wins
20:26 dalek partcl: from the previous unfudge round.)
20:26 Coke that backtrace was from head of parrot, partcl, optimized, against tcl.pbc t_tcl/if-old.test
20:26 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=647
20:26 chromatic You can add debugging symbols to an optimized build.
20:27 Coke what's the magic Configure.pl option for that?
20:27 Coke --CCFLAGS=-G ?
20:28 Coke --ccflags=-G, I mean.
20:28 mikehh hey dalek is really slow I picked that partcl r647 with svn up 20+ minutes ago
20:29 PerlJam mikehh: it probably depends on how often the RSS feed is updated.
20:29 mikehh I thought it was every 5 minutes or so - maybe not for partcl
20:30 Coke chromatic: huh. says write in the gcc manual "GCC allows you to use -g with -O" nifty.
20:31 Coke "who knew"
20:32 duk3leto Coke: -g increases the size of the binary by adding debug symbols, which is orthogonal to what -O does. That is how I understand it, anyway
20:34 nopaste "coke" at 65.91.151.195 pasted "now, with debug" (64 lines) at http://nopaste.snit.ch/17725
20:34 whoppix joined #parrot
20:35 Coke (gdb) p str_val
20:35 Coke $3 = <value optimized out>
20:36 Coke I have to head out soon; anything I can dump from this gdb session that would help someone debug it?
20:38 Coke rant: all these macros make it hard to debug. :|
20:39 Coke laters.
20:39 particle ~~
20:42 dalek parrot: r40844 | cotto++ | branches/pluggable_runcore/config/gen/platform (3 files):
20:42 dalek parrot: [profiling] pick a more descriptive name for a high-resolution timer function
20:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40844/
20:43 mikehh cardinal - builds on parrot r40842 - make test - 3 failures - 593 tests were run, from 98 files, 511 tests passed, 0 of which were unexpected, 82 tests failed, 82 of which were expected
20:44 NotFound Can a String be Special?
20:44 NotFound Ah, no, is a String PMC
20:44 mikehh cardinal -  There were 3 files that completely failed to compile: gen_08-class.pir, gen_alias.pir,gen_freeze.pir
20:45 dalek parrot: r40845 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
20:45 dalek parrot: [profiling] remove some unused or unnecessary variables
20:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40845/
20:46 mikehh cardinal - all 3 failed with get_pmc_keyed() not implemented in class 'String' - Ubuntu 9.04 amd64 (g++)
20:50 cotto karma g
20:50 purl g has karma of 595
20:52 mikehh ok what else can I test lua doesn't build for me
20:53 dalek parrot: r40846 | NotFound++ | trunk (2 files):
20:53 dalek parrot: [cage] add some checks to C stack gc related code
20:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40846/
20:54 mikehh ok I'll test that :-}
20:54 NotFound lua doesn't build with g++, last time I checked
20:57 darbelo mikehh: I have something for you to test on decnum-dynpmcs
20:58 mikehh doesnt build with gcc either or on i386 for me
20:58 mikehh darbello - ok just rebuilding
20:58 nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Leak memory, don't segfault." (13 lines) at http://nopaste.snit.ch/17726
21:00 darbelo mikehh: http://nopaste.snit.ch/17726
21:03 mikehh got it - will try in about 10 minutes or so
21:11 treed Did get_pmc_keyed get removed from String recently?
21:12 treed bacek_at_work: I'm probably looking at you.
21:21 chromatic http://www.tcl.tk/doc/scripting.html
21:22 Whiteknight joined #parrot
21:25 mikehh darbello: looks good so far
21:25 darbelo mikehh: tests are segfault-free?
21:26 Whiteknight hello #parrot
21:26 mikehh darbello: not all Failed 1/17 test programs. 0/14629 subtests failed. - t/remaindernear.t .. All 121 subtests passed
21:27 treed Whiteknight: Do you know if get_pmc_keyed was removed from String?
21:27 darbelo That's ok, remaindernear.t was my control sample :)
21:28 darbelo mikehh: are you on i386 or on amd64 ?
21:28 mokurai joined #parrot
21:28 mikehh darbelo: the rest pass - Ubuntu 9.04 amd64 (gcc)
21:29 Whiteknight treed: was get_pmc_keyed ever implemented in String?
21:29 Whiteknight chromatic: ping
21:29 chromatic pong
21:30 treed Whiteknight: It used to be.
21:30 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40846 - Ubuntu 9.04 amd64 (gcc)
21:30 treed cardinal's been using it for ages
21:30 Whiteknight chromatic: the PObj part of the GC is relatively well encapsulated, yes
21:30 treed I'd bisect, but I'm on Windows right now, and therefore away from my dev environment.
21:30 Whiteknight there is a problem in the Buffer allocator though, it expects to be able to walk the STRING pool linearly
21:30 Whiteknight treed: what would get_pmc_keyed even do on a String?
21:31 chromatic Is that to compact buffer pools?
21:31 darbelo Whiteknight: is there anything in particular about singleton dynpmcs that could cause segfaults if they heve their active_destroy flag set?
21:31 Whiteknight yeah, it walks the STRING pool linearly to find used buffers and compacts them
21:31 mokurai joined #parrot
21:31 Whiteknight darbelo: nothing that I am aware of, but I'm hardly an expert on the dynpmc loading mechanism
21:32 Whiteknight darbelo: I take that to mean you are seeing problems when a dynpmc gets collected?
21:32 Whiteknight chromatic: so what is this "missing piece" that you figured out? I'm very interested to hear about that
21:33 treed Whiteknight: Return a character at a given index?
21:33 darbelo Whiteknight: It segfaults in Parrot_pmc_destroy() where it should call the destroy vtable.
21:33 chromatic Whiteknight, I could never figure out how to find all garbage PObjs without sweeping the pools.
21:34 treed There's a get_string_keyed
21:34 treed Maybe get_pmc_keyed used to auto-cast?
21:34 treed I swear it used to work.
21:34 chromatic The secret is to add another linked list, maybe_garbage.  Every time you allocate a new PObj (free list or from the pool), stick it on that linked list.
21:34 Whiteknight treed: that doesn't make sense, why would get_pmc_keyed be expected to return a character? It's defined to return a PMC
21:35 treed Maybe it returns a String PMC with a length of 1?
21:35 chromatic Then when you run a normal GC (not a full sweep), stick everything you mark on the live list.
21:35 treed StringIterator uses get_pmc_keyed, IIRC
21:35 chromatic Everything remaining in the maybe_garbage list is unused, and you can stick it on the free list with one pointer swap.
21:35 Whiteknight chromatic: the maybe_garbage list would need to be doubly-linked if you're going to be randomly accessing it and pulling things out of the middle
21:36 treed Last time I got this error message while building:
21:36 treed Last time I got this error message while building: 12:59 <purl> bacek_at_work [Fri Aug  7 04:18:34 2009] said: I'll fix parrot today-tomorrow so StringIterator.shift_pmc will work again.
21:36 chromatic True.
21:36 Whiteknight unless you "swept" it from the root, moving items with the live flag to the alive list, and everything ese to the free list
21:37 chromatic I want to avoid sweeps.
21:37 Whiteknight I always figured sweeps were the least expensive part
21:37 chromatic Not really.
21:37 Whiteknight never benchmarked of course, but that's what it logically seems like it should be
21:38 chromatic About half of our GC time is sweeping.
21:39 Whiteknight you're not really talking about avoiding sweeps so much as you are talking about being more selective about what objects we sweep
21:39 Whiteknight so don't sweep over objects that are not allocated
21:39 beta joined #parrot
21:41 chromatic Right.
21:41 chromatic Not only does that save CPU cycles, but it has a chance of avoiding expensive cache games.
21:41 Whiteknight it's a good heuristic anyway, I bet there are some savings to be had if (1) a large portion of our PObjs at any given time are free and (2) we can make this cache-friendly
21:42 chromatic (1) is almost undoubtedly true for most workloads.
21:42 chromatic We also avoid a lot of add_to_free_list calls this way.
21:42 Whiteknight and we could improve (1) by tuning the GC, using the Lazy allocator, and increasing our initial allocations
21:43 chromatic I did the latter.
21:43 Whiteknight is it in trunk already?
21:43 Whiteknight (i never had a good opportunity to test it)
21:45 Whiteknight Adding two pointers to every PObj (I assume as part of a header) is going to have a noticable impact on our memory footprint
21:46 chromatic It's not in trunk.
21:47 chromatic We do need a better approach than storing two pointers.
21:47 Whiteknight we do have the _next_for_GC field that can reasonably be remoed
21:47 Whiteknight removed*
21:48 chromatic Sweeping is about 50% more expensive than marking, but part of that is managing fixed-sized memory through malloc/free.
21:48 Whiteknight what is being managed with malloc/free during the sweep anymore?
21:48 Whiteknight And I know the STRING compacting stuff is expensive, that has to play a big part
21:48 chromatic PMC attributes.
21:51 Whiteknight that pointer is only available when the PMC is not aliv
21:53 chromatic http://en.wikipedia.org/wiki/XOR_linked_list
21:54 chromatic Alternately, we don't store the linked list structures in the headers themselves (probably a good idea for cache friendliness) and store them in the Pools/Arenas instead.
21:55 chromatic Getting rid of _next_for_GC gets PMCs down to 24 bytes apiece (32 bit).
21:55 chromatic Moving _synchronize into _metadata gets us to 20 bytes.
21:57 NotFound chromatic: a problem is to locate all points that poke into pmc internal, like I'm learning these days.
21:57 chromatic _next_for_GC bothers me, because I've never understood it.
21:57 chromatic PMC_sync is fairly well encapsulated.
21:57 NotFound For example, the copy opcode poke into next_for_gc for no aparet reason
21:58 chromatic That's probably because it's a free pointer.
22:00 mikehh rakudo (7666e92) builds on parrot r40846, make test / make spectest (up to r28100) PASS - Ubuntu 9.04 amd64 (gcc)
22:00 chromatic Let's try to moveof PMC_
22:01 chromatic Let's try to move PMC_sync into PMC_metadata.  That'll give us 14.29% more PMCs for free.
22:01 chromatic Lazy allocation means they're free, anyway.
22:03 Whiteknight _next_for_GC is a premature optimization, trying to create a way to mark PMCs with priority
22:03 Whiteknight removing it from the GC would be trivial
22:03 Whiteknight however, that space is also used in src/freeze.c for an unrelated purpose, and I don't know anything about that
22:04 chromatic Yeah.  That's what always trips me up.
22:04 * Whiteknight would love to travel to the jungle of src/freeze.c with a machete and do some real damage there
22:05 Whiteknight that whole goddamn system is a liability
22:05 cotto Do it!  Kill it with fire.
22:10 jrtayloriv Is there no way to open a file with the O_TEMPORARY flag in PIR?
22:19 Zak joined #parrot
22:24 Whiteknight jrtayloriv: not that I know of, no
22:29 jrtayloriv Is there a reason why it shouldn't be added, or is it just that nobody has had the time to do it yet?
22:29 jrtayloriv it == "ability to do so"
22:31 dalek TT #956 created by darbelo++: [gc] Singleton PMCs with the active_destroy flag set cause segfaults when ...
22:39 Limbic_Region joined #parrot
22:41 rg joined #parrot
22:44 Whiteknight jrtayloriv: no reason why not, I don't think. Probably need to ask allison about it. Probably just waiting for people with tuits
22:47 Whiteknight that's quite the interesting ticket, darbelo
22:47 Whiteknight quite a head-scratcher
22:48 chromatic Shouldn't be:     pmc->vtable      = (VTABLE  *)0xdeadbeef;
22:48 chromatic First time through, the vtable turns into hamburger.S
22:49 darbelo Whiteknight: Tell me about it. I've been looking at all of the surrounding code for two days and can't find anything even remotely suspicious.
22:49 chromatic Second time through, dereferencing hamburger causes segfaults.
22:50 Whiteknight what do you mean hamburger?
22:50 chromatic 0xdeadbeef
22:50 darbelo chromatic: The (pmc)->vtable pointer is quite valid a the point the segfault happens.
22:51 darbelo (pmc)->vtable->destroy could be a suspect. But I can't see anyone tampering with that value anywhere.
22:51 chromatic What's (pmc)->vtable->destroy?
22:52 darbelo 0x211a31170
22:55 darbelo for a bit more context:
22:55 darbelo delprop = 0x202f87e60 <Parrot_default_delprop>, destroy = 0x211a31170,
22:56 chromatic Are there any Parrot_Segfaulty_* functions in p *pmc->vtable?
22:56 chromatic Oh, this is during global destruction.
22:56 chromatic Hm.
22:56 chromatic Conjecture: the dynpmc library is already unloaded at this point, so the dlclose for the shared library handle has already happened.
22:57 mokurai joined #parrot
22:57 chromatic The pointer is still valid, but the OS has already unmapped that area of memory.
22:57 darbelo chromatic: Yes. Singletons live in the constant pool. They are immortal.
22:57 chromatic Okay.
22:58 chromatic The PMC has outlived its C functions loaded from the shared library.
22:58 darbelo chromatic: Non-singletons die quietly :)
22:58 darbelo chromatic: Oh. That make sense.
22:58 chromatic Just another order of destruction problem, this time in the constant PMC pool.
23:00 darbelo chromatic: What prevents singletons from moving out of the constant pool? (probaly after a deprecation notice)
23:01 chromatic The only way I can think of to make them singletons right now without them being in the constant pool is to add a check to the GC sweep not to reap them.
23:02 chromatic That *may* be the right approach, but when the constant PMC pool goes away for good, we may still have this problem.
23:03 darbelo Why not treat them as regular PMCs? "Nobody needs you, bub. Have a nice death."
23:03 chromatic Because we can't reap them during GC sweep, otherwise they're not singletons.
23:04 darbelo I don't see why 'Only one ever created' == 'Can't kill it'.
23:04 chromatic You create one.  It lives for a while.
23:04 chromatic You can never create another one.
23:05 chromatic What happens when that first one you created is unreachable from the root set?
23:05 chromatic Now you have none and you are sad.
23:05 dalek rakudo: 7666e92 | pmichaud++ |  (6 files):
23:05 dalek rakudo: Move infix:<%>, infix:<div>, and infix:<mod> to the setting.
23:05 dalek rakudo: However, we don't actually implement infix:<div> or infix:<mod> yet,
23:05 dalek rakudo: so add dummy versions of those to NYI.pm for now so people know
23:05 dalek rakudo: what's going on.
23:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​666e92876576ce0dc9b1f5b8a5f035e78a80e81
23:05 darbelo "You can never create another one." is not true in current parrot.
23:07 darbelo I've always read singleton as "Only one at any given time." Which is different, to me, from "always the same one"
23:08 darbelo And if parrot singletons are defined as "always the same one" (A reasonable thing too). Then I need a new kind of PMC for waht I want to do.
23:09 Whiteknight chromatic: so you think the Library PMC is being collected earlier in the sweep, unloading the library, and taking all the funcitons with it?
23:14 * Whiteknight has no good idea about how we're going to implement strict order-of-destruction in a non-hackish way that doesn't eat up a shitload of memory/performance
23:14 chromatic Whiteknight, I'm certain of it.
23:15 cotto Andy, whatever happened to that automatic makefile dependency generation you were working on?
23:15 Whiteknight I'm not sure that makes sense to me. Items in the constant pool never get collected, so they should always be laid out in the order they were allocated in, and soruning a sweep backwards through the pool should always do things in the right order
23:16 Whiteknight oh shoot, temporary_pmcs are allocated out of the constant pool, aren't they?
23:20 Zak joined #parrot
23:20 darbelo cotto: That reminds me, I had a "make -j" build failure a few days back in the pluggable_runcore branch. You might have to check your makefile deps.
23:21 cotto darbelo, thank.  I'll see if I can break anything.
23:22 cotto I usually use -j, but it's very possible I missed something.
23:25 MoC joined #parrot
23:26 cotto darbelo, if you get the build failure again, please nopaste the relevant bits of the error message.
23:35 nopaste "darbelo" at 200.49.154.172 pasted "Build failure for cotto++." (50 lines) at http://nopaste.snit.ch/17727
23:39 darbelo cotto: does your make have a -dp option?
23:39 cotto darbelo, can you reproduce it in trunk?  It doesn't look like something runcore-specific.
23:39 cotto lemme check'
23:40 cotto -dp spits out excessively verbose debugging information
23:40 darbelo Hmm on BSD it's "Help finding concurrency issues for parallel make by adding some randomization."
23:41 darbelo But maybe it's one of those "Randomize everything" things the OpenBSD developers like to do. :)
23:51 nopaste "darbelo" at 200.49.154.172 pasted "Another -j failure, this one on trunk." (77 lines) at http://nopaste.snit.ch/17729
23:53 * darbelo keeps breakin' stuff all over the place.
23:53 cotto It seems to be having trouble with the generated file lib//Parrot/OpLib/core.pm
23:55 darbelo I had to "$ make realclean && perl Configure.pl  && make -dp -j9" twice before I finally broke it.
23:58 darbelo I could be an issue of inter-Makefile dependencies.
23:58 cotto I'm not sure what to do about that.  It looks like Ops2c/Utils.pm is getting a partially written version of that file.

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

Parrot | source cross referenced