Camelia, the Perl 6 bug

IRC log for #parrot, 2010-02-13

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 chromatic So much for easy questions.
00:00 darbelo That would expand to "((s)->flags) & PObj_constant_FLAG" right?
00:01 chromatic yes
00:01 chromatic s is probably not a valid pointer there.
00:01 shamu left #parrot
00:01 Austin Fwiw, the problem changes if I rearrange some code, which is why I'm guessing it's a wild pointer someplace.
00:01 darbelo s=0x29 in the bt
00:01 chromatic Maybe stronger than "probably" then.
00:01 Austin But it's time to go, so I'll bang my head on this later.
00:01 chromatic The String PMC may not be a String PMC.
00:11 darbelo It may not be a String PMC, but it's for sure calling String's get_string() VTABLE.
00:16 sri joined #parrot
00:46 ash_ joined #parrot
00:48 ash_ joined #parrot
00:50 mikehh joined #parrot
01:07 patspam joined #parrot
01:09 dalek parrot-plumage: fe89202 | leto++ | t/03-util.t:
01:09 dalek parrot-plumage: Add some basic tests for hash()
01:09 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/fe89202077fe42c8caf34e3ea16d502652958216
01:19 Whiteknight joined #parrot
01:19 cotto_work hi Whiteknight
01:20 Whiteknight 'ello 'ello
01:20 cotto_work it is merging time
01:20 cotto_work ?
01:29 Whiteknight I have to run to the store to buy eggs
01:29 Whiteknight then...MERGERIN' TIME
01:30 Whiteknight mikehh++ on the fix, by the way
01:31 cotto_work looks like that branch takes 400B off the _vtable struct on x64.
01:35 chromatic Nice.
01:36 Coke I am probably going to miss my merge window.
01:36 dukeleto Coke: merging what?
01:36 purl i guess merging is slow
01:37 Coke rm_cflags
01:37 chromatic http://matt.might.net/articles/writing-an-interpre​ter-substitution-denotational-big-step-small-step/
01:39 mikehh rm_cflags branch:
01:39 plobsing @cbind  <Ctrl>f      = scroll vertical 95%
01:39 plobsing @cbind  <Ctrl>u      = scroll vertical -95%
01:39 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32173), fulltest) at r43920 - Ubuntu 9.10 amd64 (g++ with --optimize)
01:39 ruoso joined #parrot
01:40 plobsing oops, unintentional paste. sorry
01:42 cotto_work startup is also moderately faster in vtable_massacre, with 6% less time being spent initializing PMCs
01:42 purl okay, cotto_work.
01:43 cotto_work startup?
01:43 purl i guess startup is taking over 45 seconds... or moderately faster in vtable_massacre, with 6% less time being spent initializing PMCs
01:43 dukeleto cotto_work: how are you measuring that?
01:43 cotto_work I'll leave that. Maybe someday I too can confuse people talking about startup.
01:43 cotto_work callgrind
01:43 purl i think callgrind is a very intresting profiling tool for linux with details at http://kcachegrind.sourcef​orge.net/cgi-bin/show.cgi
01:44 cotto_work it's a lovely tool
01:45 cotto_work looking at total cycles, it's ~1.50M in Parrot_initialize_core_pmcs branch and ~2.55M in trunk.
01:48 Whiteknight ...back!
01:48 cotto_work wb
01:49 dukeleto i have tried many times to get kcachegrind to work on os x, but no dice. i should just put it on my dusty linux laptop
01:49 cotto_work I <3 kcachegrind.
01:51 Whiteknight I need to learn kcachegrind better
01:52 cotto_work It helps to have a large monitor.
01:54 mikehh chromatic: as I understand the article parrot is a small-step interpreter, right?
01:55 chromatic Sounds right.
01:55 dukeleto chromatic: is that similar to the difference between braod and narrow compilers?
01:56 dukeleto s/braod/broad/
01:59 chromatic I don't know that.
02:01 nbrown joined #parrot
02:02 Whiteknight who is looking at one of those OpenVMS accounts?
02:06 Whiteknight INCOMING
02:06 purl duck!
02:13 Whiteknight ...and vtable_massacre has landed. now to close some tickets!
02:14 dukeleto Whiteknight: coleda was looking into the openvms acct
02:18 Whiteknight I would be interested in hacking there, if hacking were needed
02:19 chromatic Ugh.
02:20 chromatic Anyone who wants something to do so badly that making Parrot work on a platform where we're likely to have no users and which gives us no benefit for other platforms, please look at the list of HLL bugs and development priorities for 2.3 first.
02:21 dalek parrot: r43921 | whiteknight++ | failed to fetch changeset:
02:21 dalek parrot: merge vtable_massacre branch
02:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43921/
02:37 dukeleto chromatic: i tend to agree.
02:38 chromatic I know volunteer labor and people work on what they want to, but I can't see how a VMS port has value right now.
02:54 Whiteknight depends how much effort the port is
02:54 Whiteknight it may slap together
02:56 chromatic It won't; I have code that runs on VMS.
02:56 chromatic Forget everything you think you know about processes and filesystems.
02:56 purl chromatic, I didn't have anything matching everything you think you know about processes and filesystems
02:57 cotto and here I was, thinking it was just another commercial unix
02:58 chromatic There's a POSIX-compatible layer, but it's not that widespread and not that POSIX.
02:58 chromatic Windows is easier to port to.
03:01 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32175), fulltest) at r43921 - Ubuntu 9.10 amd64 (g++ with --optimize)
03:19 Whiteknight dukeleto: what if I want to go apeshit reimplementing unicode?
03:29 mikehh Whiteknight: you really want to re-invent the wheel :-}
03:29 chromatic In that case, we all owe Mrs. Whiteknight an apology for the beating you'll receive.
03:31 chromatic src/main.c:417: warning: cast from function call of type ‘long unsigned int’ to non-matching type ‘enum <anonymous>’
03:31 chromatic Oh C, your attempts to have a working type system are so sad and cute at the same time.
03:36 mikehh chromatic: had to put that cast in to get it to build on g++
03:37 chromatic Yeah, I know why we need it.  It's just... poor C.
03:37 mikehh I get the warning on gcc build
03:37 chromatic Not "that's awful code" but "aww, isn't C CUTE?"
03:41 janus joined #parrot
03:43 mikehh be interesting to see where Pike, Thompson et al go with Go :-}
03:56 * Whiteknight decides to start a C-on-Parrot compiler called "CUTE"
03:57 Whiteknight I would like to get the op_pmcs branch merged in tomorrow probably and have those PMCs marked as experimental
03:57 Whiteknight shouldn't affect the build at all, but does bump PBC_COMPAT
04:04 kid51 joined #parrot
04:04 kid51 trunk: r 43921: Linux/i386:  PASS make test; make buildtools_tests; make codetest
04:04 Whiteknight but I have to go in to work tomorrow morning because management is bad at things like "planning" and "deadlines"
04:05 Whiteknight and "resource management"
04:06 * kid51 reads scrollback
04:07 kid51 At PPW a couple of years ago, Schwern remarked:  "I like to work on VMS from time to time.  It's like visiting another planet."
04:08 Whiteknight I've never used VMS. it might be a fun learning experience
04:09 Whiteknight anyway, I need sleep if I have to wake up and work tomorrow
04:09 Whiteknight later
04:09 kid51 There's one guy who comes to Perl Seminar NY from time to time,
04:09 kid51 ... trained as a physicist, but who has worked as a programmer for many decades
04:10 kid51 ... who swears "I've never lost a file on VMS"
04:10 kid51 And, of course, Dan was a VMS expert in his youth.
04:18 kid51 Tried to view dukeleto's slides on Google Docs at same time as I was building Parrot on my Mac.
04:18 kid51 result:  eternally spinning kaleidoscopic ball
04:19 kid51 one of the rare times I had to cut the juice entirely, then start from cold
04:21 Util My first quarter of CompSci was Pascal on Vax VMS. I ended up doing Tiger work (authorized attempted break-ins) via DCL, and became proficient, but have not touched VMS in the last 20 years.
04:23 Util I have heard VMS called the anti-unix. I agree with the sentiment.
04:23 * kid51 had to google for DCL
04:24 Util Digital Control Language? Halfway between mainframe JCL and unix shell scripts
04:25 kid51 DCL?
04:25 purl DCL is, like, digital control language, the VMS shell or a project tracking system. see http://dcl.sourceforge.net/index.php
04:25 kid51 purl, DCL is also http://www.nationmaster.com/encyc​lopedia/DIGITAL-Command-Language
04:25 purl okay, kid51.
04:32 nopaste "kid51" at 71.246.114.173 pasted "t/pmc/bigint.t FAILed due to bad plan on darwin/ppc -- but at same rev it passed on linux/i386" (59 lines) at http://nopaste.snit.ch/19585
04:33 kid51 I thought that I changed the plan on that test from 34 to 45 when it was still in branch.
04:33 kid51 But it appears that someone (whiteknight?) changed it back ...
04:33 kid51 perhaps for good reason ...
04:34 kid51 but I can't tell because this is one of those files on which 'svn blame' does not work ...
04:34 kid51 due to long-ago corruption when we went from CVS to SVN.
04:35 kid51 too tired to ponder this more now
04:35 kid51 starting make fulltest and going to bed
04:35 * kid51 must sleep
04:35 purl $kid51->sleep(8 * 3600);
04:40 mikehh joined #parrot
05:11 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32178), fulltest) at r43921 - Ubuntu 9.10 i386 (g++ with --optimize)
05:12 * mikehh enough - must sleep
05:30 patspam joined #parrot
06:08 kurahaupo joined #parrot
06:10 kurahaupo joined #parrot
06:47 iblechbot joined #parrot
06:56 TiMBuS joined #parrot
07:20 dalek parrot: r43922 | bacek++ | branches/boehm_gc_2/t/op/string_mem.t:
07:21 dalek parrot: Disable string_mem.t on non-MS GC.
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43922/
07:21 dalek parrot: r43923 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
07:21 dalek parrot: Add commented-out finalizers. Apparently they are making parrot 3x times slower
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43923/
07:21 dalek parrot: r43924 | bacek++ | branches/boehm_gc_2/t/op/gc.t:
07:21 dalek parrot: Skip county tests for non-MS GC.
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43924/
07:21 dalek parrot: r43925 | bacek++ | branches/boehm_gc_2/src/gc/gc_private.h:
07:21 dalek parrot: Put void* gc_private into GC_Subsystem
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43925/
07:21 dalek parrot: r43926 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
07:21 dalek parrot: Use typed allocating of PMC ans STRING.
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43926/
07:21 dalek parrot: r43927 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
07:21 dalek parrot: Use alloc/copy in reallocate_string instead of GC_REALLOC. This behavior
07:21 dalek parrot: suits Parrot's strings implementation better.
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43927/
07:21 dalek parrot: r43928 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
07:21 dalek parrot: Collect memory in gc_boehm_mark_and_sweep
07:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43928/
07:34 shockwave joined #parrot
07:36 shockwave I'm in the code generation part of my compiler design. This process involves generating code Parrot code for each construct in my language. So i generate the Parrot code, and manually check it, of course. However, and this is my question, has anyone devise a way to automate part of this process? To make sure the generated code works as intended?
07:37 shockwave I know there may not be a clear answer to this, or none at all. What I'm looking for is for the machine to help me do what I'm manually doing; to make sure the generated code does what is supposed to.
07:37 shockwave Thanks.
07:45 bacek shockwave, check nqp-rx test suite. It can probably help
07:48 shockwave @bacek, I will. Thanks.
08:14 shockwave In order to define a class, newclass must be used? Just having the namespace with the class name is not enough, right?
08:16 cotto correct
08:18 shockwave Thanks, @cotto
08:21 bacek cotto, are you just woke up or going to sleep?
08:24 shockwave Let's say that I'm defining a class in file A, to be used in file B. Ideally, file B would just load file A and then instantiate the class. How can this be done if newclass needs to be used to tell parrot that a class exist?
08:25 shockwave Can one of the vtable methods help here?
08:25 bacek shockwave, can you use .include?
08:25 shockwave sure.
08:25 shockwave maybe load_bytecode, as well.
08:26 cotto bacek, I'm up.  It'll be a while before my brain winds down so I can go to sleep.
08:26 cotto it's 0030 here.
08:26 cotto ~
08:26 dalek parrot: r43929 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
08:26 dalek parrot: Alias interp->gc_sys to reduce noice.
08:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43929/
08:26 dalek parrot: r43930 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
08:26 dalek parrot: Decypher Boehm GC bitmap creation
08:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43930/
08:26 bacek cotto, sound good :)
08:26 shockwave @bacek, is .include the answer?
08:27 cotto shockwave, once you run new_class, you can do new ['your';'class';'here'] and it'll dtrt
08:27 bacek shockwave, .include erm.. include other pir file.
08:27 shockwave Right. But the issue is that I would like the 'newclass' to automagically be ran by the file that defines the class.
08:28 shockwave Not in the file that is using the class.
08:28 shockwave Am I making sense?
08:29 bacek shockwave, you can use something like ".sub 'init' :anon :immediate  :load" with newclass in it
08:29 bacek to create your classes
08:30 shockwave @bacek, Sweet. That what I was looking for. Thanks.
08:30 bacek This sub will run automatically during compilation
08:30 cotto bacek, are there any prereqs for building the boehm branch?
08:30 bacek cotto, apt-get install libgc1-dev
08:33 shockwave One more question for you guys. Should the .HLL directive be placed in all the generated files, or only on the main one that includes the other files?
08:34 cotto looks like it's libgc-dev on my box
08:34 cotto let's see if this works
08:35 bacek shockwave, it doesn't harm to put .HLL in all files
08:35 shockwave OK
08:39 cotto looks like the boehm branch is slightly slower at parsing tools/dev/pprof2cg.nqp, but it seems to be within 10%.
08:40 cotto It looks like it's to the point where it'll be better than the default for some workloads.
08:40 cotto bacek++
08:42 bacek cotto, do you have svn checkout? Can you kill old boehm branch? It's useless now
08:43 cotto np
08:44 cotto you mean boehm_gc?
08:44 bacek indeed
08:45 cotto baleeted
08:46 cotto anyone know why vtable_massacre is still around?
08:46 cotto It was merged earlier today.
08:46 cotto well, yesterday
08:46 purl it has been said that yesterday is seemingly so far away
08:48 cotto seen darbelo
08:48 purl darbelo was last seen on #parrot 8 hours, 36 minutes and 33 seconds ago, saying: It may not be a String PMC, but it's for sure calling String's get_string() VTABLE.
08:59 dalek parrot: r43931 | cotto++ | branches/boehm_gc:
08:59 dalek parrot: deleting now-unused branch
08:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43931/
09:02 fperrad joined #parrot
09:11 cotto bacek, ooc are you thinking about implementing the sweepless gc on the wiki once boehm_gc_2 is merge-worthy?
09:11 bacek cotto, may be.
09:30 fperrad_ joined #parrot
09:30 bacek cotto, are you still alive?
09:31 cotto should the inf gc be expected to segfault in the branch?
09:31 cotto yup
09:31 bacek cotto, can you check TT#1402?
09:31 cotto ./parrot -g inf parrot-nqp.pbc --target=pir tools/dev/pprof2cg.nqp >/dev/null
09:31 cotto 'splode
09:31 cotto sure
09:31 dalek parrot: r43932 | bacek++ | trunk (5 files):
09:31 bacek We basically need few functions exposed via interp->gc_sys
09:31 dalek parrot: Remove unused CallContext.current_results. It should give small performace improvements due less allocations
09:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43932/
09:31 dalek parrot: r43933 | bacek++ | trunk/src/main.c:
09:31 dalek parrot: Replace Parrot_ex_throw with fprintf(stderr) in CLI parsing. Part of TT#1436.
09:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43933/
09:32 cotto bacek, +1 to merge those functions.
09:33 cotto actually, your moving CLI parsing out of imcc may enable me to close a bug
09:34 cotto (unrelated but helpful to me)
09:48 dalek parrot: r43934 | cotto++ | trunk/src/interp/inter_create.c:
09:48 dalek parrot: [interp] reorder initialization code a bit to minimize apparent dependencies between PMC initialization passes
09:48 dalek parrot: no functional changes
09:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43934/
09:49 cotto It worked!
09:49 purl What do you mean it worked? Did it run to completion? Did it bomb out early? Did it finish the job early? Did it tell your girlfriend "let's just be friends"? Be specific!
09:51 cotto msg Coke r43935 adds --hash-seed to parrot.  Next time you think you have an ordering-dependent bug, you can use that to verify.
09:51 purl Message for coke stored.
09:57 kurahaupo joined #parrot
10:02 dalek TT #1383 closed by cotto++: [PATCH] add a cli option to set Parrot's hash seed
10:04 dalek parrot: r43935 | cotto++ | trunk/src (2 files):
10:04 dalek parrot: [string] add --hash-seed and -H to explicitly set the seed used for hashing
10:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43935/
10:05 shockwave joined #parrot
10:08 shockwave @bacek mentioned this:  shockwave, you can use something like ".sub 'init' :anon :immediate  :load" with newclass in it
10:09 shockwave This works well. But, I noticed that if I have to '.include' directives with the same file, the 'init' method gets run twice.
10:09 shockwave I have two '.include'...^^^
10:09 shockwave something like:
10:09 shockwave .include 'foo.pir'
10:10 shockwave .include 'foo.pir'
10:10 shockwave The anon gets ran twice. Is there a way to limit it to only running once, in order to register the class with Parrot using 'newclass'?
10:20 chromatic Don't include it twice.
10:20 chromatic I know that sounds facile, but .include is a textual inclusion at that point in the source code.
10:21 Austin joined #parrot
10:21 shockwave @chromatic, right now, all the inclussions are on one file. My only concern would be if in the future (like, tomorrow), the inclussions needed to be in all generated files. That could cause problems.
10:22 shockwave I was just curious if there was a work-around for this.
10:23 chromatic Use load_bytecode instead, if you can't avoid multiple inclusion.
10:23 shockwave @chromatic, Ok. Thanks.
11:00 shockwave this short code:
11:00 shockwave .sub main
11:00 shockwave say 'from PROOF file'
11:00 shockwave .end
11:00 shockwave error:imcc:syntax error, unexpected $end ('�')
11:00 shockwave in file 'TestXXX.pir' line 1
11:00 shockwave Gives me that error^^^^
11:01 shockwave I don't understand what's going on.
11:05 shockwave Does anyone have an idea why errors would be issued when running the hello world example, like the first code here: http://docs.parrot.org/parrot/l​atest/html/docs/intro.pod.html
11:10 chromatic No idea.
11:10 chromatic Works for me.
11:10 shockwave Something's fucked up on my machine. This is weird.
11:11 kjeldahl joined #parrot
11:11 nbrown joined #parrot
11:14 shockwave These are the exact contents of the file:
11:14 shockwave .sub main
11:14 shockwave say "Hello world!"
11:14 shockwave .end
11:14 shockwave Weird.
11:15 chromatic Any strange newlines?  Whitespace?
11:16 shockwave I setup vim to write Unix, Windows, and Mac new lines.
11:16 shockwave But nothing.
11:16 purl i heard nothing was shared - this is why things work
11:18 shockwave I created another file, and saved it brand new from vim.
11:18 shockwave It worked.
11:18 purl What do you mean it worked? Did it run to completion? Did it bomb out early? Did it finish the job early? Did it tell your girlfriend "let's just be friends"? Be specific!
11:19 shockwave Oh you know what, Since I'm running on windows, and, originally, the previous file was created from Windows Powershell, it may have added some bogus Unicode byte mark. Maybe.
11:20 chromatic That's the only other thing that comes to mind.
11:20 shockwave Anyhow, Thanks for the help, @chromatic
11:21 chromatic You're welcome.
11:42 dalek parrot: r43936 | chromatic++ | branches/boehm_gc_2 (2 files):
11:42 dalek parrot: [GC] Allow build to link and run on systems without Boehm GC installed.
11:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43936/
11:45 chromatic Ugh, Boehm GC and Valgrind are NOT friends.  Callgrind goes boom.
11:55 Austin_away Yow. Walking off the end of a sub is way better than doing a 'return'.
11:55 Austin_away (In nqp)
12:01 Austin_away Here's a nopaste that didn't seem to make it: http://nopaste.snit.ch/19586
12:06 joeri joined #parrot
13:05 Austin Pmichaud: What is the nqp  pir:: syntax for the delete_p_k opcode - delete $P0[$P1] ?
13:47 shockwave In order to assign null to a PMC one has to: $P0 = new 'Null'  ?
13:47 shockwave Or is there a null opcode
13:48 Austin There is a null opcode.
13:48 Austin "null $P0"
13:48 shockwave How about for this form: $P0 = null ?
13:48 shockwave I'll try it.
13:49 shockwave Thanks
13:49 Austin seems to work
13:50 nopaste "Austin" at 68.37.46.53 pasted "Does ' = null' work?" (9 lines) at http://nopaste.snit.ch/19588
13:51 shockwave Sweet.
13:51 Austin Out of curiousity, why are you trying to nullify something?
13:51 Austin Isn't that what undef is for?
13:51 shockwave It's for creating variables, which in my language are null.
13:52 Austin Okay. What language is that?
13:52 purl I'm not sure... but it doesn't sound like any kind of English I know.
13:52 shockwave My own custom DSL.
13:53 Austin Cool.
13:53 Austin (Cooler if it isn't lisp.)
13:54 shockwave I agree with that.
13:54 Austin :)
13:54 Austin About the last eleventy-six people doing HLLs were doing lisp variants. There ought to be a special page on the wiki
13:54 Austin "How to lisp in parrot"
13:56 mikehh thsquaaak
13:56 Austin lol
13:56 Austin mikehh++
13:56 Austin That's dethpicable!
13:57 mikehh :-}
14:06 Austin Man, I hate it when I'm like "Whoa, I'm totally going to rewrite this gnarly code!" and I wind up with the same gnarly code.
14:15 Austin What do you call a sub or method that returns multiple values?
14:26 TiMBuS joined #parrot
14:27 mikehh t/run/options.t is failing at r43936 - Ubuntu 9.10 i386 (gcc/g++ with --optimize)
14:28 shockwave Austin, I don't think it has a special name.
14:28 Austin Google was not my friend.
14:28 Austin I named them "tuple_sub" and "tuple_method" respectively.
14:29 shockwave Sounds good enough.
14:29 mikehh also it is failing in make coretest and that shouldn't be in make coretest
14:30 mikehh also fails in make test
14:56 Austin I can has parse error?
14:58 dalek TT #1440 created by Austin_Hastings++: parrot-nqp does not parse { in string correctly
15:01 Austin Not a bug, but a heretofore unused feature.
15:08 Austin Okay, why is P6object::__dump getting called when dumping a Sub?
15:14 dalek TT #1440 closed by Austin_Hastings++: parrot-nqp does not parse { in string correctly
15:33 pmichaud Austin: we don't have a syntax for that.
15:33 pmichaud (delete_p_k opcode, that is)
15:33 Austin The delete_p_k?
15:33 Austin Okay.
15:34 Austin I'll leave that in PIR
15:34 pmichaud dealing with the _k syntaxes is a real pain.
15:34 Austin :)
15:34 pmichaud 11:54 <Austin_away> Yow. Walking off the end of a sub is way better than doing a 'return'.
15:34 pmichaud yes.  'return' is very expensive.
15:35 Austin A lot of things just got converted from return ...; to ...;
15:35 pmichaud I think using 'return' in the fib.nqp benchmark makes it about 2.5x slower
15:37 pmichaud user0m10.370s   # fall-through
15:37 pmichaud user0m23.790s  # using 'return'
15:38 Austin !!
15:38 Austin Puts pressure on developers to code 'fat' methods.
15:38 Austin Use less infrastructure.
15:40 Psyche^ joined #parrot
15:41 whiteknight joined #parrot
15:48 whiteknight purl msg bacek the boehm numbers are looking fantastic!
15:48 purl Message for bacek stored.
15:53 mikehh joined #parrot
15:55 dalek kakapo: ae5b8fe | austin++ | src/Pmc/ (3 files):
15:55 dalek kakapo: Changed some Opcode:: names
15:55 dalek kakapo: Added __dump method for Sub.nqp
15:55 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
15:55 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/ae5b8fefd2a695d1d9fa9a90b06b0d902e868fb0
16:02 Austin Woot. Kakapo P6objects now dump correctly.
16:03 dalek TT #1441 created by jkeenan++: t/run/options.t: new failures in 14 tests
16:03 dalek TT #1442 created by Austin_Hastings++: Sub PMC should support getattribute
16:07 iblechbot joined #parrot
16:14 whiteknight t/run/options.t is failing 14 tests for me this morning
16:14 whiteknight wasn't seeing those failures last night after the vtable_massacre branch merged
16:15 whiteknight Ah, nevermind. I didn't see TT #1441
16:15 whiteknight TT #1442 +1.
16:15 whiteknight Austin: ping
16:16 Austin Whiteknight: ?
16:16 whiteknight Austin: can we get a list of what getattribute values you want from Sub?
16:16 whiteknight I could put together a prototype
16:16 theory joined #parrot
16:18 jsut_ joined #parrot
16:19 * whiteknight hates BigInt and BigNum, would love to see them exorcised from the repo and moved to external projects
16:19 * whiteknight would like to see several things exorcised in such a way
16:19 nopaste "Austin" at 68.37.46.53 pasted "Sub attributes" (33 lines) at http://nopaste.snit.ch/19596
16:20 dalek parrot: r43937 | whiteknight++ | trunk/t (2 files):
16:20 dalek parrot: fix skip numbers in t/pmc/bigint.t and t/op/arithmetics_pmc.t. Patch from Andy++
16:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43937/
16:21 Austin Whiteknight: The 'Sub' class makes a bunch of promises. I think that the individual objects need to be able to keep 'em.
16:21 whiteknight Austin: so getattributes could just call VTABLE_inspect, build that hash, and return the keyed value from it?\
16:21 whiteknight sounds easy enough for a prototype
16:21 Austin I think the problem lies in building the hash.
16:22 Austin My goal here is to have a consistent introspection mechanism.
16:22 whiteknight how so? you're building it in the example
16:22 whiteknight or are you saying that it's needlessly wasteful?
16:22 Austin I'm not building the hash of Sub data, I'm getting a hash full of promises from class Sub.
16:23 Austin The PMC would have to actually get that data, and I understand that some of it may be hard to get.
16:23 Austin (I don't *know* it's hard to get, but I acknowledge the possibility)
16:25 whiteknight so that hash in your example contains all the keys, but no values?
16:26 Austin Right. I think each key foo maps to another hash, that has "name => 'foo'" in it,
16:26 Austin It's pretty lame.
16:26 whiteknight that is pretty lame
16:27 Austin %attributes<foo> := Hash.new( :name('foo') );
16:27 Austin I added my nopaste to the ticket
16:28 whiteknight extend your example to say($_ + " " + %attrs[$_])
16:28 whiteknight I want to see what you are actually getting
16:28 Austin bide
16:30 whiteknight Sub.inspect calls Sub.inspect_str to get the values, but it doesn't look to me like inspect_str does anything like what we want
16:31 whiteknight maybe it does, just in a roundabout way
16:31 nopaste "Austin" at 68.37.46.53 pasted "More details" (63 lines) at http://nopaste.snit.ch/19597
16:32 Austin It's teh suxx0rs.
16:36 whiteknight Well, looking at the code I don't think that should be the case
16:36 whiteknight it should be returning at least a few integer values
16:36 Austin I don't think it does getattribute at all. It supports inspect.
16:37 whiteknight actually, no, it's not calling Sub.inspect at all
16:37 Austin Frankly, I'm not sure why we seem to have two different systems for getting instance data: inspect and getattribute.
16:37 whiteknight because Sub.inspect should be returning a different hash with different values
16:37 Austin :)
16:37 whiteknight see src/pmc/sub.pmc:760
16:38 whiteknight So what the hell is "my &sub := Foo::foo" returning?
16:38 whiteknight because it sure as hell isn't a Sub PMC
16:38 Austin It's a sub.
16:39 whiteknight Austin: can you dump the PIR output of the NQP compiler for me and nopaste it?
16:39 * whiteknight is at work and having a hard time doing any development
16:40 nopaste "Austin" at 68.37.46.53 pasted "test.pir" (72 lines) at http://nopaste.snit.ch/19598
16:40 Austin look for the .annotate line 6
16:41 whiteknight okay, right
16:42 whiteknight Sub is a built-in type and doesn't have a Class PMC associated with it. it does have a PMCProxy, which we might be returning
16:42 whiteknight so the behavior you're looking at is in PMCProxy, not Class
16:42 whiteknight and I'm not sure if we can make PMCProxy smart enough to fix it
16:43 whiteknight check what "my $type = pir::typeof__sp($class)" is, I suspect it will be PMCProxy
16:44 whiteknight in which case, we probably need to call "my %attrs = pir::inspect__pp(&sub)" to get the info you want
16:44 whiteknight but, we should also fix Sub.getattributes to return more good data
16:45 Austin $class is a PMCProxy, &sub is a Sub
16:45 Austin (per typeof)
16:45 Austin The trouble is in Sub.pmc, not in the proxy.
16:45 Austin The proxy is saying "here are the attributes that class.pmc told me to tell you about."
16:46 Austin But Sub says "I don't support getattribute."
16:46 whiteknight ah, ok. so PMCProxy is calling getattribute internally?
16:46 Austin No.
16:46 Austin There's no Proxy involved
16:46 whiteknight ...so...why do we need getattribute?
16:46 whiteknight I
16:46 whiteknight 'm not following
16:47 Austin The type of &sub, per typeof__sp(), is 'Sub'.
16:47 Austin Not 'PMCProxy'
16:47 whiteknight okay. So from your code example it doesn't look like you are calling getattributes on &sub at all
16:48 plobsing whiteknight, Austin: this appears to me to be a result of auto_attrs, which sets vtable->attribute_defs, which PMCProxy reads
16:48 nopaste "Austin" at 68.37.46.53 pasted "typeof" (28 lines) at http://nopaste.snit.ch/19599
16:48 Austin Right!
16:49 Austin I'm not calling getattribute because I know better. :)
16:49 whiteknight okay, so I was looking for the problem in your example, but that's not where it is. I see now
16:50 whiteknight so you want Sub.getattribute to return values for that list of strings that the PMCProxy.inspect is returning?
16:50 * whiteknight sincerely wonders why the hell we need both inspect_str and getattribute
16:51 nopaste "Austin" at 68.37.46.53 pasted "error" (38 lines) at http://nopaste.snit.ch/19600
16:51 Austin Right. The inspect in question is "attributes".
16:52 Austin Which suggests to me that "these are valid attributes"
16:54 Austin I can see where you might not want certain information to be an attribute, especially since "attributes" are what objects routinely store into. But if there is an "attributes" tag in the inspect tree, then those should be attributes.
16:55 Austin (Ditto for the "methods", "roles", etc. tags.)
16:58 whiteknight I really would like to find out what the intended differences are between getattribute and inspect_str
16:59 whiteknight because I dont think there is any rule that getattribute needs to correspond directly to the list of defined ATTRs
16:59 Austin I think that inspect is a general-purpose introspection mechanism. While attributes are things that objects have.
16:59 whiteknight that may be the original intention, but in practice getattribute is often used to return things that aren't necessary defined ATTRs
17:00 Austin I'd agree that there's no required correspondence, *until and unless* you tell me, via .inspect('attributes'), that "here is a list of attributes."
17:00 whiteknight that may be the case. inspect should return the list of strings (maybe a hash of complete string+values) that getattribute responds to
17:01 whiteknight but that still doesn't leave much room for inspect_str to avoid the axe
17:01 Austin Well, inspect('attributes') should.
17:03 whiteknight purl msg allison we're trying to figure out the differences between inspect_str and getattribute, and whether inspect_str is redundant. Can you shed some light?
17:03 purl Message for allison stored.
17:04 mikehh getting a codetest faiulure - assert args with - include/parrot/context.h: Parrot_pcc_set_results_func but the function and assert only seems to exist in context.h
17:04 mikehh in the headerizer section
17:05 Austin Hey, when's 2.1 going out
17:05 whiteknight tuesday, I believe
17:05 Austin Well, maybe some of these segfaults will go away.
17:05 * darbelo materializes
17:05 whiteknight segfaults?
17:05 purl No whammies!
17:06 darbelo 2.1 is going out on tuesday. But my mail announcing it didn't reach the list.
17:06 Austin Yeah, it's blowing up left and right.
17:06 mikehh what about the middle?
17:06 tetragon joined #parrot
17:06 Austin mikehh: The middle is where I get some kind of progress made.
17:07 whiteknight Austin: I haven
17:07 whiteknight 't seen too many segfault reports recently
17:07 Austin I guess that depends on how you define "too many".
17:07 mikehh tried to run make headerizer but it failed on me - can't find HEADERIZER HFILE directive in 'compilers/pirc/src/pircompiler.c' at tools/build/headerizer.pl line 521.
17:07 whiteknight I can't recall any
17:07 Austin I'm just running everything two or three times.
17:08 Austin To get past the segfaults.
17:08 whiteknight Austin: nopaste me an example that esplodes
17:08 Austin Hahahahahaha!
17:08 purl LOLCON 6 reached.
17:11 Austin If I had a nopasteable example, I'd submit a patch.
17:13 whiteknight oi, nevermind. I'm seeing failures in PLA now
17:15 whiteknight well, looks like we have some debuggerin to do tonight
17:15 Austin :)
17:15 whiteknight which is not nearly as much like English buggering as it sounds
17:16 Austin Stop now, dude.
17:16 Austin There's no way you're going to sound any better.
17:17 whiteknight usually i get into a hole where I can't possibly sound any worse
17:17 Austin Perhaps you should run for elected office.
17:17 dalek kakapo: 2d03d94 | austin++ | src/Classes/P6 (2 files):
17:17 dalek kakapo: Changed attribute code to use '$!foo' instead of just '!foo' so that intended-type will show in dump.
17:17 dalek kakapo: Added __dump method to P6object.nqp, to dump attribute-based objects.
17:17 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
17:17 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/2d03d943455c5ebab8f65e30bb66480357447e6c
17:17 dalek kakapo: 4fd0e18 | austin++ |  (14 files):
17:17 dalek kakapo: Slamming code to try to show segfaults.
17:18 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
17:18 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/4fd0e183768da6c3c40cbc83a635c94237127eb7
17:19 Austin Well, all that work for a "die" op
17:26 dalek parrot: r43938 | fperrad++ | trunk/src/ops/math.ops:
17:26 dalek parrot: the opcode pow must honor HLL types
17:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43938/
17:29 dalek lua: cdc873f | fperrad++ | dynext/pmc/lua (3 files):
17:29 dalek lua: vtable pow & i_pow are gone, since the merge of branch vtable_massacre
17:29 dalek lua: (see http://trac.parrot.org/parrot/changeset/43921).
17:29 dalek lua: currently, we lost the support of metamethod __pow.
17:29 dalek lua: review: http://github.com/fperrad/lua/commit/cd​c873fdf109035c82a6d8e61f7173c3d57301a4
17:40 dukeleto 'ello
17:41 whiteknight heya duke
17:42 dukeleto whiteknight: how goes it? what are you up to now that vtable_massacre has merged?
17:42 whiteknight dukeleto: Austin has clued me into the fact that we've got some instability issues. Parrot-linear-algebra fails all tests apparently
17:43 whiteknight so once I get home it's debugging time
17:43 dukeleto whiteknight: on trunk and 2.0.0 ?
17:43 whiteknight on trunk. Everything built and tested fine that I'm aware of for 2.0
17:44 dukeleto Austin: have you looked at Util.nqp in plumage? it might have some useful stuff for kakapo
17:44 dukeleto whiteknight: did vtable_massacre cause the breakage?
17:44 Austin duke: I haven't looked recently, but I already know there's a bunch of stuff I'd like to steal in there.
17:45 dukeleto Austin: it is even tested, to boot! although i think some bugs may still lurk
17:45 Austin :)
17:45 whiteknight dukeleto: I'm not sure. need to test
17:46 whiteknight I'm still at work, so when  I get home I'll check things out more
17:47 dukeleto Austin: http://gitorious.org/parrot-plumage/parr​ot-plumage/blobs/master/src/lib/Util.nqp
17:47 whiteknight Austin: any insight into when these errors started happening?
17:47 dukeleto Austin: tests are here: http://gitorious.org/parrot-plumage/pa​rrot-plumage/blobs/master/t/03-util.t
17:48 Austin whiteknight: Not usefully. I'm catching up on back taxes from before the new year, so it could have been anytime from 1.7
17:48 dukeleto Austin: git bisect is your friend
17:49 whiteknight well, PLA was working fine about a week ago when I last tested it
17:49 Austin Actually, dukeleto, I've got very little opportunity to git bisect, since part of paying my taxes is adopting the new nqp-rx.
17:49 Austin That's killing me, since it's a bunch of syntax changes, and I've got a pretty large code base.
17:49 whiteknight I've got to pay the nqp-rx tax in Matrixy soon
17:50 whiteknight I'm thinking that might be the opportunity for me to do the big dispatch refactor I have planned
17:51 dukeleto Austin: gotcha
17:58 whiteknight Okay, I'm heading home now. Should be at the debugging station within 2 hours.
17:59 whiteknight later
18:13 chromatic joined #parrot
18:14 dukeleto chromatic: ahoy
18:14 chromatic morning
18:14 Austin Yay! Another nqp problem.
18:41 Austin Whoa.
18:41 Austin I think I just made 'progress'.
18:41 darbelo Austin++
18:42 Austin I think I just made 'progress'.
18:43 Austin Whoops. Wrong window.
18:43 shockwave --Austin
18:50 Austin Well, so much for that.
19:02 nopaste "Austin" at 68.37.46.53 pasted "Class creation quandary" (15 lines) at http://nopaste.snit.ch/19602
19:02 Austin Why does this keep happening to me?
19:28 Coke chromatic: my openvms testing wsa going to amount to "hey, look that, it <does|doesn't> work!"
19:32 chromatic Sure.  Like I said, I think the amount of work beyond that will be non-trivial.
19:44 Austin Any idea why a class woud appear non-existent to the oo code, but be accessible otherwise?
19:51 shockwave Is the current Parrot PIR compiler an optimizing compiler?
19:53 darbelo Not as such.
19:54 chromatic Hm, the naive GC-per-MB patch (a couple of lines of changes) runs fib.pir 12.894% faster.
19:55 darbelo Nice.
19:55 chromatic Let me verify that number; I want to isolate the changes.
19:56 darbelo Any percentage above 2 is nice.
19:56 chromatic 12.855%
19:56 purl 0.12855
19:56 chromatic Still worth doing.
19:57 darbelo Indeed.
19:58 chromatic Let me review the KCachegrind visualizations.
19:58 darbelo That reminds me...
19:58 darbelo You once mentioned that we might benefit from setting the 'special' flag when we attach metadata to PMCs in order to reduce branching in the gc code. Is that still worth investigating?
19:59 Austin What's the gc-per-mb patch do?
19:59 chromatic Austin, run the GC only after we've allocated a megabyte of memory, not whenever we run out of free objects.
19:59 Austin Ahh
20:08 chromatic Huge difference in number of GC runs.
20:13 chromatic 3.895% improvement in an NQP benchmark.
20:13 chromatic This all depends on the ratio of easily recyclable GCables to live GCables.
20:14 darbelo I wonder if NQP-generated code holds on to GCables we could recycle.
20:15 chromatic Possibly.
20:15 chromatic How do you feel about a 4 - 13% performance improvement this close to a release?
20:15 darbelo I'm all for it.
20:16 chromatic Incoming.
20:16 purl duck!
20:23 Whiteknight joined #parrot
20:25 nbrown joined #parrot
20:26 chromatic dukeleto, benchmarks before and after r43939 will be informative.
20:27 Whiteknight what happened at r43939?
20:27 darbelo The world changed.
20:27 * darbelo pokes dalek with a stick.
20:27 chromatic I closed one world and opened the nexT.
20:27 Whiteknight ah, I see. chromatic's magic GC magic
20:28 chromatic We have *less* code in the GC with that tiny patch.
20:28 dalek parrot: r43939 | chromatic++ | trunk/src/gc (3 files):
20:28 dalek parrot: [GC] Changed the mark/sweep GC so that it runs a GC only if it's allocated a
20:28 dalek parrot: megabyte or more of GCables since the last GC run.  This allows dead GCables to
20:28 dalek parrot: stick around for longer, but reduces the amount of time marking and sweeping
20:28 dalek parrot: live GCables.  Note that we may have to reduce the tunable for the maximum size
20:28 dalek parrot: of a GCable pool.
20:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43939/
20:28 dalek parrot: r43940 | chromatic++ | trunk/src/gc (2 files):
20:28 dalek parrot: [GC] Tidied some code and fixed some typos.  No functional changes.
20:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43940/
20:29 Whiteknight I'm seeing failures in t/pmc/hash.t now
20:29 Whiteknight and t/run/options.t
20:29 purl t/run/options.t is failing 14 tests for me this morning
20:29 chromatic I had the latter before.
20:30 chromatic I'm not sure how the GC tuning would affect the former.
20:30 darbelo same here with the options.
20:30 bacek good morning
20:30 purl What's so good about it?
20:30 bacek options.t is my fault. I'll fix it soon.
20:32 darbelo --bacek++ # decrement for breaking, increment for fixing.
20:33 darbelo Damm is decnum-dynpmcs full of FAIL today.
20:33 Whiteknight PLA is building on this computer now. I need to check it on an x86 machine now
20:40 Whiteknight yay! I think VirtualBox fixed my Xorg bug! I should be able to run Fedora12 again
20:41 dalek parrot-data-structures: 49a435d | Whiteknight++ | t/pmc/ (3 files):
20:41 dalek parrot-data-structures: fix test plans. All tests pass
20:41 dalek parrot-data-structures: review: http://github.com/Whiteknight/parrot-data-structur​es/commit/49a435dcddeff601a4ee90e0d7672a6e463a1249
20:43 darbelo Whiteknight: ping
20:45 Whiteknight darbelo: pong
20:45 darbelo Say, how did the vtable massacre affect PIR's "z = x ** y" pow syntax?
20:46 darbelo Should that still be valid?
20:46 chromatic It should be, yes.
20:47 Whiteknight should be
20:47 darbelo From what I see here, it's still is. But doesn't dtrt for decnum-dynpmcs, which I expected.
20:47 darbelo Just wanted to check.
20:47 Whiteknight darbelo: right, calls VTABLE_get_number, calls pow() in libc, then VTABLE_set_number_native for result PMC
20:50 chromatic bacek, looks like -R is broken.
20:51 bacek chromatic, tt#1441
20:51 darbelo Whiteknight: Yeah, I kinda guessed that when the pow() tests started failing horribly.
20:51 chromatic That's the one.
20:52 Whiteknight darbelo: probably best to convert pow() to a METHOD
20:52 darbelo Just did that.
20:53 darbelo But I was curious about the ** syntax staying.
20:54 darbelo I was expecting an altogether different kind of FAIL.
20:55 Whiteknight yeah, the ** syntax just gets translated to the pow opcode
20:55 Whiteknight so that still works because the opcode still exists
20:56 darbelo I'm guessing you'll go after the opcode on the next cycle, eh?
20:56 chromatic Ah, there's the fix.
20:57 Whiteknight darbelo: the opcode is, I believe, intended to become a dynop along with several other math ops
20:57 dalek decnum-dynpmcs: r196 | darbelo++ | trunk/ (2 files):
20:57 dalek decnum-dynpmcs: After the VTABLE massacre, pow() is no longer a VTABLE, rather than lose the
20:57 Whiteknight so it will still exist, and may eventually get smarter, but will be a dynop
20:57 dalek decnum-dynpmcs: functionality, expose it via a METHOD.
20:57 dalek decnum-dynpmcs: review: http://code.google.com/p/decnu​m-dynpmcs/source/detail?r=196
20:57 chromatic bacek, fix coming in a moment.
21:01 dalek parrot: r43941 | chromatic++ | trunk/src/main.c:
21:01 dalek parrot: [parrot] Added missing curly brackets to "No runcore found, bailing out!" case
21:01 dalek parrot: when processing command-line arguments.  This fixes TT #1441.
21:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43941/
21:01 dalek parrot: r43942 | chromatic++ | trunk/t/run/options.t:
21:01 dalek parrot: [t] Added diagnostic output to display failed command when testing command-line
21:01 dalek parrot: arguments in t/run/options.t.
21:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43942/
21:02 chromatic All tests pass for me again on trunk.
21:03 dalek TT #1441 closed by chromatic++: t/run/options.t: new failures in 14 tests
21:05 Whiteknight okay, pla passes all tests on x86 again too
21:05 Whiteknight no idea why it failed earlier, must have been a fluke
21:09 chromatic If you don't trust me to delete code from the GC now... GOSH!
21:34 dalek parrot: r43943 | mikehh++ | trunk/include/parrot/context.h:
21:34 dalek parrot: remove lines that headerizer keeps even though function has been removed
21:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43943/
21:34 Whiteknight what needs to get done prior to the release? Just test reports?
21:34 Whiteknight any serious bugs need a look?
21:36 AndyA joined #parrot
21:39 chromatic Anything reported in the last few weeks, I'm sure.
21:42 hercynium joined #parrot
21:47 mikehh t/pmc/hash.t is failing (Segmentation fault) - Parse errors: Bad plan.  You planned 168 tests but ran 79. - r43942 - Ubuntu 9.10 amd64 (gcc with --optimize)
21:47 Whiteknight urg
21:51 chromatic mikehh, can you bisect?
21:53 mikehh chromatic: I will in a minute
21:55 chromatic Thanks.  A backtrace will be informative too.
22:05 mikehh chromatic: passes at r43938 - fails at r43940 - trying r43939
22:07 chromatic That's not a good sign.
22:10 mikehh fails at r43939
22:11 mikehh how do you get a backtrace again? - I've done it it before but I cat't recall how
22:13 chromatic Run it within gdb, let it segfault, then do bt.
22:14 mikehh hmnn - sure I did something else, but anyway
22:33 mikehh chromatic: it don't seg fault under gdb or ./parrot -v
22:33 chromatic Does it segfault under prove?
22:34 chromatic or perl t/harness t/pmc/hash.t ?
22:34 chromatic If the latter, there's an extra command line argument in there.
22:41 Whiteknight I'm seeing the hash.t failure here too, under --optimize
22:41 mikehh chromatic: yes for both and ./parrot t/pmc/hash.t
22:43 mikehh it fails with both gcc and g++ (with --optimize) havcen't tried without yet
22:43 mikehh haven't
22:45 nopaste "Whiteknight" at 68.46.29.192 pasted "t/pmc/hash.t segfault backtrace" (20 lines) at http://nopaste.snit.ch/19607
22:46 Whiteknight for that, I ran gdb --args ./parrot t/pmc/hash.pmc
22:46 Whiteknight no other args
22:49 Whiteknight ImageIO->buffer is null for some reason
22:49 Whiteknight I don't know enough about the PMC to tell if that's an acceptable condition
22:51 Whiteknight do Buffer* objects need to be marked for FC?
22:51 Whiteknight GC?
22:51 purl GC is the boehm conservative garbage collector at http://reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com or branches/gsoc_pdd09 or a travesty against god
22:54 chromatic Looks like it can be NULL.
22:55 nopaste "chromatic" at 173.50.130.127 pasted "mikehh, Whiteknight try this patch" (16 lines) at http://nopaste.snit.ch/19608
22:55 Whiteknight I wonder why an error doesn't appear in non-optimized version
22:56 chromatic Address space randomization.
22:58 Whiteknight I'm already building with a variation on that patch
22:58 Whiteknight ...and works
22:59 Whiteknight committed
23:06 payload joined #parrot
23:10 lucian joined #parrot
23:12 mikehh ok - looks good
23:12 dalek parrot: r43944 | whiteknight++ | trunk/src/pmc/imageio.pmc:
23:12 dalek parrot: fix ImageIO.mark() to not try to mark a NULL buffer. Patch inspired by chromatic++, mikehh++
23:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43944/
23:28 dalek parrot: r43945 | whiteknight++ | trunk/src/pmc/imageio.pmc:
23:28 dalek parrot: add a const modifier like I should have originally
23:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43945/
23:29 hercynium joined #parrot
23:31 dalek TT #1443 created by jonathan++: Segfauts possibly caused by pool compaction bug
23:33 dukeletoz joined #parrot
23:35 dukeletoz 'ello
23:35 Whiteknight hello
23:42 chromatic dukeletoz, benchmarks before and after r43939 will be informative.
23:42 chromatic Whiteknight, can you poke at TT #1443?
23:44 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32187), fulltest) at r43944 - Ubuntu 9.10 i386 (g++)
23:45 dalek parrot: r43946 | whiteknight++ | trunk/src/pmc/imageio.pmc:
23:45 dalek parrot: fix indenting in ImageIO to be like all other .pmc files
23:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43946/
23:46 dukeletoz chromatic: i will try to make that happen
23:46 chromatic Thanks.
23:46 chromatic I expect between a 4 and 13% performance improvement.
23:47 dukeletoz chromatic: ok. are there any specific benchmarks, or just the usuals, like oofib and friends?
23:49 chromatic The usuals.
23:51 dalek tracwiki: v2 | chromatic++ | GCSizeTuning
23:51 dalek tracwiki: Implemented.
23:51 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GC​SizeTuning?version=2&amp;action=diff
23:53 payload joined #parrot

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

Parrot | source cross referenced