Camelia, the Perl 6 bug

IRC log for #parrot, 2010-09-11

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 kid51 is now known as kid51_at_dinner
00:09 sorear just skip_all nt/exit
00:11 NotFound I just deleted alll and forked again
00:25 dalek TT #1781 created by plobsing++: examples/benchmarks/freeze.pasm broken in r48918
00:25 dalek TT #1781: http://trac.parrot.org/parrot/ticket/1781
00:26 eternaleye_ is now known as eternaleye
00:39 tcurtis joined #parrot
00:47 davidfetter left #parrot
00:54 kid51_at_dinner is now known as kid51
00:59 dalek TT #1782 created by NotFound++: C++ build broken in r48923
00:59 dalek TT #1782: http://trac.parrot.org/parrot/ticket/1782
01:07 tcurtis Hello, folks.
01:09 whiteknight hello tcurtis
01:22 tcurtis How's PLA coming, whiteknight?
01:22 whiteknight tcurtis: very well, thanks. I'm putting together some online documentation for it now. I'm planning a release to follow 2.8
01:25 kid51 whiteknight: How much linear algebra would someone need to know to appreciate/use PLA?
01:25 whiteknight kid51
01:25 whiteknight : not much, really. Basically it only provides some matrix types now. Bsically 2-D arrays
01:25 whiteknight it does support some of the mathematical operations on matrices too, but those aren't really necessary to use
01:25 * kid51 once studied linear algebra.  Nixon was president.
01:26 whiteknight :)
01:28 whiteknight the ComplexMatrix2D PMC type is an extremely efficient storage solution for Complex values
01:28 whiteknight ...if that's something anybody cares about
01:28 NotFound I suppose it can be useful for doing 3-D oprations for graphics.
01:29 kid51 I ask because I've been thinking ...
01:29 kid51 ... (which is always dangerous) ...
01:30 kid51 ... that in the first half of 2011, it would nice to be able to have a "road show" of projects built on Parrot ...
01:30 tcurtis whiteknight: http://whiteknight.github.​com/parrot-linear-algebra/ is excessively wide on my screen (I have to scroll right to read some of the text and to see the sidebar). On the PMC documentation pages, I have the opposite problem.
01:30 whiteknight japhb, I think, was talking about using the matrix type as a screen buffer for graphics
01:30 kid51 ... both the ones people expect (i.e., Rakudo) and the ones they don't expect (such as PLA)
01:30 dalek parrot: r48925 | jkeenan++ | trunk (4 files):
01:30 dalek parrot: Applying patch submitted by ash++ in �http://trac.parrot.org/parrot/ticket/1774, plus additional tests for case of new configuration option '--without-readline'.
01:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48925/
01:30 whiteknight tcurtis: that's weird. I don't specify any screen widths, I don't think
01:31 kid51 hmm, you can tell that's a whiteknight page:  white type on black background
01:32 kid51 not good on kid51's eyes
01:32 NotFound kid51: I'm doing a Gtk wrapper via Gtk2 perl5 module via blizkost that will be good for presentations for people that only appreciate things with GUI.
01:32 whiteknight kid51: I'm no artist. I rarely use color, and I stick with what I know
01:32 whiteknight :)
01:32 kid51 But I don't have problem tcurtis reports
01:32 dalek TT #1774 closed by jkeenan++: Adding without-readline support
01:32 dalek TT #1774: http://trac.parrot.org/parrot/ticket/1774
01:33 whiteknight kid51: If you can suggest to me a better color scheme, I'll consider changing it
01:34 NotFound whiteknight: you can add some men at work signs, to give it a full good old geocities fashion ;)
01:34 hercynium left #parrot
01:35 whiteknight again, not an artist
01:36 NotFound Talking about art, we still lack a scalable version of the parrot logo.
01:39 ash_ left #parrot
01:40 whiteknight well, on that front: is the current parrot logo something we want to keep and use, or do we want a different one?
01:41 whiteknight if we don't have a scalable version of it, we'll need to recreate it in a scalable format. Getting it right could be a huge pain in the butt
01:41 NotFound If someone provides a better one, I suppose we can switch.
01:42 whiteknight That's not really a serious proposal, I'm just musing out loud
01:42 kid51 whiteknight: When you get a chance, can you comment on http://trac.parrot.org/parrot/ticket/1450 ?
01:43 kid51 msg Coke Can you comment on http://trac.parrot.org/parrot/ticket/1450 ? Thanks.
01:43 purl Message for coke stored.
01:43 aloha OK. I'll deliver the message.
01:43 whiteknight kid51: sure. I'll do it now
01:45 whiteknight I'm fine with closing the ticket
01:45 kid51 msg allison When you get a chance, can you comment on http://trac.parrot.org/parrot/ticket/905 ?  Thanks.
01:45 purl Message for allison stored.
01:45 aloha OK. I'll deliver the message.
01:45 kid51 whiteknight: ok, but presumably coke has something to say before we close it
01:45 plobsing C++ build has been broken for a while. why don't we have ttbot++ complaining at us?
01:45 whiteknight I'm sure. My vote is cast, anybody else can have their say too
01:47 NotFound plobsing: usually I am ttbot++, but these days I've been buliding with C for blizkost compatibility.
01:49 plobsing I'm trying to fix TT #1782, but there have been a number of changes that each broke C++ build independantly. fun.
01:49 NotFound plobsing: I can take care of them.
01:50 NotFound (not today)
01:50 plobsing I really don't know how to fix "src/packout.c:280:30: error: cast from ‘void*’ to ‘int’ loses precision
01:50 plobsing it's an explicit cast. why can't C++ shut up and deal?
01:52 NotFound Error? No warning?
01:52 plobsing yeah. error. no idea why.
01:53 NotFound I'm too sleepy to look at it right now, sorry.
01:54 plobsing It's cool. I'm lukcy, I'll be able to figure it out somehow.
01:54 plobsing lucky even
01:54 NotFound We have some macros for convoluted casts.
01:55 shockwave joined #parrot
01:55 shockwave Hi.
01:56 shockwave I'm having some trouble compiling a file to PBC.
01:56 kid51 Uh-oh:  Starting to get things like this in 'make test' on Darwin/PPC:  src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
01:57 kid51 I was not getting that yesterday at this time.
01:57 shockwave Up until now, I've running my compiler's output by simple doing: ./parrot -I someDir someDir/file.to_run.foo -- Which runs fine.
01:57 shockwave However, when I try to create a pbc, by adding the -o output_name, only a blank file is created.
01:57 shockwave I must be overlooking some silly detail.
02:00 plobsing kid51: that's likely related to TT #1781
02:01 plobsing shockwave: what is the exact command you run that generates a blank PBC file? are there any diagnostic messages printed?
02:02 shockwave @plobsing: I copied the parrot exec/lib to the output directory, so that I don't have to use the -I flag. But still, no luck. Here's the command:
02:02 shockwave ./parrot -o tmp.rune TestOutput.s_stream_2_xml_2.proof
02:02 shockwave No diagnostics
02:03 shockwave if I remove the -o tmp.rune from the command, the file is ran fine.
02:03 plobsing hmmm... parrot still uses file extension to determine filetype in a number of places. try changing the name to tmp.pbc.
02:04 * cotto is afk for most of the evening
02:05 shockwave @plobsing: thanks. That wrote a non-empty file.
02:05 shockwave If I may ask you another question.
02:06 shockwave Now, when I run that pbc file, I get a Null PMC error.
02:06 dalek TT #1783 created by jkeenan++: t/compilers/pge/p5regex/p5rx.t and t/compilers/pge/perl6regex/01-regex.t: ...
02:06 dalek TT #1783: http://trac.parrot.org/parrot/ticket/1783
02:06 shockwave Do all the .include'ed files get baked into the PBC, or not?
02:06 plobsing null pmc error... progress :-D
02:06 shockwave Yep :)
02:07 shockwave To tell you the truth, when I saw that blank file get created a few times, my heart skipped a few beats.
02:07 plobsing yes, all included files are baked into the PBC.
02:07 shockwave Compared to that, errors are much better :)
02:08 plobsing I'd suggest filling a ticket (if one doesn't already exist) about alternate file extensions.
02:08 shockwave That's weird, then.
02:09 shockwave @plobsing: If you want, I can do it. But, I don't really need it. And, in fact, I did mean to use the .pbc extension. I'm saving that .rune extension for something else. I just had it in mind, and kept writing it.
02:10 shockwave That null pointer error, otoh... that's something.
02:14 shockwave Some of the file my compiler generates have different file extensions, such as .proof, .init, and .main -- I hope that's not the case
02:15 shockwave They get read fine, like I said, when just running them with ./parrot ...
02:16 plobsing really? I thought parrot would assume them to be pbc files by defalt.
02:16 plobsing s/defalt/default/
02:16 shockwave The only reason I'm doing that is to match them up with their correct .pir counterparts.
02:17 shockwave I'll test naming them all with the .pir extension.
02:18 kid51 left #parrot
02:20 whiteknight left #parrot
02:22 sjn joined #parrot
02:22 tcurtis shockwave: ooc, is your compiler available anywhere online?
02:23 shockwave tcurtis: Unfortunately no.
02:23 shockwave Darn, that issue is not name related :(
02:23 shockwave I manually edited the files, and renamed them with the .pir extension.
02:24 kid51 joined #parrot
02:26 plobsing shockwave: if I've understood correctly, you are compiling up a number of files using a bunch of includes. could you try compiling smaller sets of files or even individual files in an attempt to pinpoint the problem?
02:27 patspam joined #parrot
02:27 patspam left #parrot
02:28 ttbot Parrot trunk/ r48925 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/389770.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
02:28 plobsing yay! ttbot lives!
02:28 shockwave @plobsing: Sure. But, I'm gonna have to do this tomorrow. I can't keep my eyes open anymore. (I get up at 5am).
02:28 shockwave I'm sure I'll be back asking for more help.
02:29 shockwave Thanks for getting me this far.
02:29 shockwave bye
02:29 shockwave left #parrot
02:35 janus left #parrot
02:35 ash_ joined #parrot
02:41 alin left #parrot
02:41 ash_ left #parrot
02:44 kid51 left #parrot
02:48 janus joined #parrot
03:25 sjn left #parrot
03:36 sjn joined #parrot
04:24 luben left #parrot
05:32 gaurav joined #parrot
05:44 gaurav left #parrot
05:57 dalek parrot: r48926 | plobsing++ | trunk (7 files):
05:57 dalek parrot: fix C++ build
05:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48926/
06:31 dalek parrot: r48927 | chromatic++ | trunk/src/gc/system.c:
06:31 dalek parrot: [GC] Fixed unoptimized builds in stack tracing.
06:31 dalek parrot: The STRING marking function has an assert for STRINGness that Buffers which get
06:31 dalek parrot: marked don't need.  This whole system is a mess of false and foolish premature
06:31 dalek parrot: isomorphism, but we can live with this for now (unless someone beats me to
06:31 dalek parrot: cleaning up this approach before we replace this part of the GC).
06:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48927/
06:35 dalek TT #1782 closed by plobsing++: C++ build broken in r48923
06:35 dalek TT #1782: http://trac.parrot.org/parrot/ticket/1782
06:47 dalek parrot: r48928 | chromatic++ | trunk/src/pmc/nci.pmc:
06:47 dalek parrot: [PMC] Fixed GC bug in NCI's mark().
06:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48928/
07:38 tcurtis left #parrot
07:59 tadzik joined #parrot
08:06 cosimo left #parrot
08:32 mikehh t/op/integer.t and t/pmc/bigint.t FAIL in make corevm/make coretest - error:imcc:loadlib directive could not find library `sys_ops'
08:32 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48928 - Ubuntu 10.04 i386 (g++ with --optimize)
08:38 tadzik left #parrot
08:45 barney joined #parrot
09:00 cosimo joined #parrot
09:12 mikehh left #parrot
09:27 dalek roast: defbf3b | moritz++ | S0 (2 files):
09:27 dalek roast: random rakudo unfudges
09:27 dalek roast: review: http://github.com/perl6/roast/commit/de​fbf3b9f486427f6d3346a33692a003bf73ec45
09:28 moritz whoever configured dalek, roast should report o #perl6, not #parrot
09:28 moritz *to
09:34 dalek roast: 3d90aad | moritz++ | S03- (2 files):
09:34 dalek roast: fix two tests that used non-matching series endpoints
09:34 dalek roast: review: http://github.com/perl6/roast/commit/3d​90aad19b68ddef2b448ff78cb5867710609663
09:40 dalek roast: c3f4ab2 | moritz++ | S32-list/grep.t:
09:40 dalek roast: fix another series misuse
09:40 dalek roast: review: http://github.com/perl6/roast/commit/c3​f4ab287471981b6f2c5f0bc808a95769f1f81f
09:52 dalek roast: 2832230 | moritz++ | S03-operators/series- (2 files):
09:52 dalek roast: [series] fudge fixes
09:52 dalek roast: review: http://github.com/perl6/roast/commit/28​3223009b36df9cff99bf2208dd292f76c0d7c1
09:58 whiteknight joined #parrot
10:03 barney left #parrot
10:07 mikehh joined #parrot
10:08 contingencyplan joined #parrot
10:12 fperrad joined #parrot
10:12 baest left #parrot
10:12 whiteknight good morning, #parrot
10:18 dalek roast: d3868b4 | moritz++ | S04-statements/given.t:
10:18 dalek roast: [given.t] unfudge test using .so
10:18 dalek roast: review: http://github.com/perl6/roast/commit/d3​868b4e7684b49d7d0c6705d9c00e4c38f18189
10:22 tadzik joined #parrot
10:44 slavorg left #parrot
10:51 slavorg joined #parrot
10:58 dalek parrot: r48929 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
10:58 dalek parrot: fix a typo with the 3.0 release date. Add dates of releases through 3.6
10:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48929/
11:13 allison msg kid51 commented on TT #905
11:13 purl Message for kid51 stored.
11:13 aloha OK. I'll deliver the message.
11:13 allison left #parrot
11:31 dalek parrot: r48930 | NotFound++ | trunk/t/pmc/packfile.t:
11:31 dalek parrot: add some more Packfile PMC tests
11:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48930/
11:45 atrodo left #parrot
11:53 dalek TT #1784 created by whiteknight++: distutils fails sdist and bdist if zlib is not installed
11:53 dalek TT #1784: http://trac.parrot.org/parrot/ticket/1784
11:58 tadzik new parrot fails with LDFLAGS=--as-needed, is that known?
11:58 tadzik (fails to build)
12:04 whiteknight fperrad: ping
12:10 whiteknight how do I go about making a .deb file for my project using distutils?
12:31 sjn_ joined #parrot
12:33 sjn_ left #parrot
12:41 dalek winxed: r627 | NotFound++ | trunk/winxedst1.winxed:
12:41 dalek winxed: minor refactors
12:41 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=627
12:47 aloha left #parrot
12:48 bacek left #parrot
12:59 kid51 joined #parrot
13:03 kid51 Just got this build failure on Darwin/PPC at r48930:  <src/glut_nci_thunks.nci
13:03 kid51 src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
13:03 kid51 make: *** [src/glut_nci_thunks.c] Error 134
13:03 kid51 Re-building to confirm.
13:18 Patterner left #parrot
13:18 kid51 Well, I got 'make' to complete.  But am still getting same test failures reported in TT #1783 yesterday.
13:28 Psyche^ joined #parrot
13:28 Psyche^ is now known as Patterner
13:46 plobsing kid51: can you get a backtrace of the failing assertion? (I tried, but I can't get it to fail on linux/x86_64)
13:46 fperrad pong whiteknight
13:46 whiteknight fperrad: how do I make a .deb using distutils?
13:47 whiteknight I can see some stuff in the code, but I can't quite figure out all the steps to make the package
13:47 kid51 plobsing: I don't know how to do that
13:48 plobsing kid51: do you have gdb? if you run the failing parrot program (gdb --args ./parrot etc.pbc), it will halt at the failing assertion. then run bt to print a backtrace.
13:50 whiteknight fperrad: if I do "setup.nqp control" it looks like I get all the .deb metadata. Is that what I'm supposed to do or is there a different step I should run?
13:50 fperrad whiteknight, distutils doesn't make .deb, like it makes a RPM or SRPM,
13:50 fperrad but the command :
13:50 fperrad $ setup.pir control
13:51 fperrad creates some useful files in port/debian
13:51 dalek TT #1781 closed by plobsing++: examples/benchmarks/freeze.pasm broken in r48918
13:51 dalek TT #1781: http://trac.parrot.org/parrot/ticket/1781
13:51 tadzik left #parrot
13:51 whiteknight yeah, okay. so after that I can use some external tools to make the .deb?
13:51 fperrad the next step is read : http://www.debian.org/doc/maint-guide/
13:55 kid51 plobsing:  I typed: gdb --args ./parrot t/compilers/pge/p5regex/p5rx.t
13:55 kid51 When the gdb prompt appeared, I typed: run t/compilers/pge/p5regex/p5rx.t
13:55 kid51 All the tests ran and I got this result:  Program exited normally.
13:55 whiteknight fperrad: yeah, I've been reading that. Thanks.
13:56 plobsing well there's your fix... just run parrot through gdb all the time ;-)
13:57 kid51 Got same result with: run t/compilers/pge/perl6regex/01-regex.t
14:01 plobsing do the same files fail when run with just ./parrot ? if not maybe the harness is using some flags.
14:04 kid51 plobsing:  Running: ./parrot t/compilers/pge/p5regex/p5rx.t t/compilers/pge/perl6regex/01-regex.t ...
14:04 kid51 ... the first test fails at the same point (after completing 233), with this:
14:04 kid51 src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
14:04 kid51 Abort trap
14:05 kid51 And, earlier, I got the same result running the 2nd test just by itself in the same way
14:06 plobsing can you try (under gdb and not) the --gc-debug flag?
14:07 kid51 perl t/harness --gc-debug  t/compilers/pge/p5regex/p5rx.t  .... ends with:
14:07 kid51 t/compilers/pge/p5regex/p5rx.t .. 209/960 src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
14:07 kid51 t/compilers/pge/p5regex/p5rx.t .. Failed 727/960 subtests
14:07 kid51 (less 8 skipped subtests: 225 okay)
14:09 kid51 Again invoking 'gdb' as before, only calling: run --gc-debug t/compilers/pge/p5regex/p5rx.t, I get same result, i.e., all tests complete and I conclude with: Program exited normally.
14:10 dalek roast: fd2903a | moritz++ | S03-operators/series-nonnumeric.t:
14:10 dalek roast: fix another old-school series test
14:10 dalek roast: review: http://github.com/perl6/roast/commit/fd​2903a6546a8d48538736075f75b6783e4ce39b
14:11 dalek rakudo: 62e168d | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo:  Starting to implement new series spec
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​2e168d68b94711f97786536efce8efe5fa54c3f
14:11 dalek rakudo: 953705a | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: There is no more need to check of the wrong side
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​53705acda85f522cd95b9edfcdce0708c1fe7d9
14:11 dalek rakudo: 6483439 | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: Simplify the limit-reached code since geometric series don't require use of abs() anymore
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​4834397cc2ea627f0008b63b581585ce7eccff1
14:11 dalek rakudo: c6e6807 | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: Simplify the code, we don't need the type of the series anymore
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​6e680795dc5e86acab7d44babb7380f280e3f62
14:11 dalek rakudo: 9f204b1 | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: 1..* ... 5 and @fib ... 8 (where @fib is infinite lazy) now work
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​f204b19b027564fb3580e124c2b4d15111abd9c
14:11 dalek rakudo: 927c28c | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: Simplify limit check and when in doubt next is .succ
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​27c28c2bf0aa8f14cb37257a881e2e4425cd013
14:11 dalek rakudo: 09f36de | patrickas++ | src/core/operators.pm:
14:11 dalek rakudo: .succ instead of src/core/operators.pm.succ
14:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​9f36decf7acad2a1e909b9b358f43b69749d8e5
14:12 dalek rakudo: 23cffdb | moritz++ | src/core/operators.pm:
14:12 dalek rakudo: Merge remote branch 'patrickas/series-new-spec'
14:12 dalek rakudo:
14:12 dalek rakudo: This implements the new series spec, and at the same time significantly
14:12 dalek rakudo: simplifies the code.
14:12 dalek rakudo:
14:12 dalek rakudo: To quote http://github.com/rakudo/rakudo/pull/4 :
14:12 dalek rakudo:
14:12 dalek rakudo: * No more special cases for geometric series switching sign
14:12 dalek rakudo: * No more special case 'limit is on the wrong side'
14:12 dalek rakudo: * Literal limit must smart match exactly
14:12 dalek rakudo: * Code on the rhs returns true to indicate limit has been reached.
14:12 dalek rakudo: * Code on the rhs cannot have arity > 1
14:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​3cffdb244a62d79e975534dd387151748d491b6
14:15 plobsing kid51: well, that's pretty much the end of my bag of tricks. I really don't see what gdb could be doing to modify the program execution so that it doesn't fail.
14:15 kid51 ISTR that we've encountered this paradoxical situation before
14:16 NotFound Is Darwin, it adapts to survive.
14:16 kid51 I am now bisecting
14:17 dalek roast: 9560604 | moritz++ | S03- (10 files):
14:17 dalek roast: move series test to new S03-series/ directory
14:17 dalek roast: review: http://github.com/perl6/roast/commit/95​6060417bae6504fc8510cc16c12d1f3fbe7c70
14:17 dalek roast: e118651 | moritz++ | S03-series/misc.t:
14:17 dalek roast: [series] comma before series is caught at compile time, so change test to eval_dies_ok
14:17 dalek roast: review: http://github.com/perl6/roast/commit/e1​186511a529b89a9bf309c2f453cc5903fef190
14:17 dalek rakudo: fb4feba | moritz++ | t/spectest.data:
14:17 dalek rakudo: track test file rename
14:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​b4feba08f8994651b44b2d5d896df7d9417c502
14:20 kid51 i.e., a situation in which a test file fails via 'prove' or 'perl t/harness' but succeeds when run thru 'gdb'.
14:35 dalek parrot: r48931 | NotFound++ | trunk/src/pmc_freeze.c:
14:35 dalek parrot: check PMCNULL instead of NULL and improve the Exception thrown in Parrot_visit_loop_visit
14:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48931/
14:36 dalek roast: 4e24c6c | moritz++ | S03-series/ (4 files):
14:36 dalek roast: lots of series unfudges for rakudo
14:36 dalek roast: review: http://github.com/perl6/roast/commit/4e​24c6c591aa566cef10e12a1db0a50cdca5439b
14:41 dalek rakudo: a93dcb6 | moritz++ | / (2 files):
14:41 dalek rakudo: [docs] update ChangeLog
14:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​93dcb688d612f4a972ad676183f9ac07f1d266f
14:42 cognominal left #parrot
14:42 cognominal joined #parrot
14:42 dalek roast: 1beb062 | moritz++ | S03-series/nonnumeric.t:
14:42 dalek roast: [series] oops, unfudged too much in previous commit; adding back a fudge marker now
14:42 dalek roast: review: http://github.com/perl6/roast/commit/1b​eb062b884dc6238dd4474ac5b0417cf39400b9
14:46 kid51 r48918 is the source of the problem in TT #1783: http://trac.parrot.org/par​rot/ticket/1783#comment:4
14:49 ash_ joined #parrot
15:03 patspam joined #parrot
15:04 davidfetter joined #parrot
15:04 kid51 left #parrot
15:08 whiteknight left #parrot
15:19 tcurtis joined #parrot
15:21 dalek nqp-rx: 184e828 | moritz++ | src/Regex/P6Regex/Grammar.pm:
15:21 dalek nqp-rx: catch p5 gneral quantifiers
15:21 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​84e828e137ae5813a895f39a63c547204fd9a5e
15:26 NotFound The next commit is funny
15:33 * cotto sighs
15:33 ruoso joined #parrot
15:42 dalek parrot: r48932 | NotFound++ | trunk (3 files):
15:42 dalek parrot: add a check for duplicated VTABLE functions in PMCs and remove two duplicates found while tesing it
15:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48932/
15:42 dalek parrot: r48933 | nwellnhof++ | trunk/src/ops (2 files):
15:42 dalek parrot: Fix find_codepoint opcode without ICU
15:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48933/
15:43 patspam left #parrot
15:48 mikehh left #parrot
15:49 dalek TT #1758 closed by plobsing++: Segfault caused by new dynop mapping code
15:49 dalek TT #1758: http://trac.parrot.org/parrot/ticket/1758
15:56 kid51 joined #parrot
15:58 dalek parrot: r48934 | NotFound++ | trunk/t/pmc/packfile.t:
15:58 dalek parrot: fix test for Packfile set_integer_keyed_str with invalid key
15:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48934/
16:11 nopaste "plobsing" at 192.168.1.3 pasted "TT #1783 debug patch" (13 lines) at http://nopaste.snit.ch/23297
16:12 plobsing kid51: http://nopaste.snit.ch/23297 will turn the failed assertion into an infinite loop. you then can use gdb to attach to the already started program (using the 'attach <PID>' command) and obtain a backtrace.
16:27 tadzik joined #parrot
16:29 kid51 plobsing:  When I apply that patch, then call 'make', 'make' is hanging at Linked: parrot_nci_thunk_gen ./parrot_nci_thunk_gen --loader-name=Parrot_glut_nci_loader --loader-name=Parrot_glut_nci_loader --loader-storage-class=PARROT_DYNEXT_EXPORT --output=src/glut_nci_thunks.c <src/glut_nci_thunks.nci
16:31 pmichaud there's an argument to be made that r48932 requires a deprecation cycle.
16:31 plobsing then it is working. the assertion failed. get the PID of the hung parrot process and attach.
16:34 sjn left #parrot
16:37 NotFound pmichaud: What is the reason?
16:37 purl rumour has it the reason is that the company isn't VC funded. VC funded companies tend to spend money like water or that you didn't patch it yet or that you didn't patch it yet or that you didn't patch it yet
16:38 pmichaud NotFound: because there could be users that rely on that particular bug, and now their code doesn't work.
16:38 kid51 plobsing:  gdb ./parrot_nci_thunk_gen 11663
16:38 kid51 leads to
16:38 purl somebody said leads to was a type of verb.
16:38 kid51 0x0207e7c0 in Parrot_gc_mark_PMC_alive_fun (interp=0x600c30, obj=0x1065de0) at src/gc/api.c:169
16:38 kid51 169             while (!PObj_is_PMC_TEST(obj));
16:39 plobsing yes. that's the line of the failing assertion. running 'bt' should get you a backtrace now.
16:39 NotFound pmichaud: I profoundly dislike the idea of supporting stupidity.
16:39 NotFound Including our won.
16:39 pmichaud that's part of what a deprecation policy is for, though.
16:40 NotFound If something is obviously wrong, it should be fixed.
16:40 pmichaud I didn't say "don't fix it", I said "don't break our users' code"
16:40 nopaste "kid51" at 192.168.1.3 pasted "'bt' after applying plobsing's diagnostic patch to api.c" (31 lines) at http://nopaste.snit.ch/23298
16:40 NotFound pmichaud: What user code? Code affected by that thing disappears.
16:41 pmichaud Rakudo doesn't build because of that patch.
16:41 kid51 plobsing:  is that what you were looking for?
16:41 NotFound pmichaud: It has duplicated VTABLE functions on its PMCs?
16:42 pmichaud There's one yes.  I agree it's a mistake (and I'm fixing it now)
16:42 pmichaud But the point of the deprecation policy is so that user code doesn't get surprised by these sorts of changes.
16:42 plobsing kid51: yes, that backtrace should help tremendously. I'm not all that familiar with gc (and trying to stay that way), so I'll defer to chromatic for the fix.
16:42 pmichaud (which we did.)
16:43 NotFound pmichaud: I don't expect anyone to be negatively impacted by better error detection.
16:43 pmichaud NotFound: then you were wrong.
16:43 pmichaud the better approach is to issue a warning until the deprecation point, and fail after that.
16:44 pmichaud anyway, it's not serious enough for me to argue heavily for.  I'm simply pointing out that it violates the deprecation policy.
16:45 NotFound pmichaud: I don't buy that. If someone wants to do the deprecation cycle, fine, but I'm not going to do it.
16:45 pmichaud Fair enough.
16:46 pmichaud I'm not saying we absolutely have to make this fix.  But as one of the active users of Parrot I think I also have a responsibility to let Parrot devs know when they've done something that breaks our code.
16:46 pmichaud If you'd prefer that I shut up about it, then I will.
16:47 NotFound Sorry if I'm being rude, but I'm tired of seeing lots of breaks without complaints, and complains for absolutely minor points.
16:47 pmichaud breaks without complaints?
16:48 NotFound Changes that break lot of things. Like the dynop debacle, for example.
16:48 pmichaud I did complain about that.
16:48 NotFound But it passed
16:49 pmichaud So, you would prefer I just shut up and not report these things?
16:49 tcurtis And resulted in some changes to our deprecation policy.
16:50 NotFound I'm not sure about what I prefer.
16:51 pmichaud sometimes when we discover that something breaks the deprecation policy, we decide to go with the lesser evil of causing some pain for downstream users rather than trying to strictly follow the policy, and to me that's okay.  But we should at least acknowledge when it occurs. (more)
16:52 pmichaud and this includes letting our downstream users know that a fundamental change was made outside of the policy.
16:52 kid51 plobsing++ for diagnostic assistance; let's hope c. can figure this out
16:53 pmichaud but simply saying "sorry, we don't support stupidity"  doesn't seem to me to be very supportive.
16:53 NotFound In a extreme case, someone can argue that fixing a segfault breaks the deprecation policy, because some code may be expecting that the segfault happens.
16:53 pmichaud so, you're saying we should be free to ignore the policy in extreme cases, and we should be able to ignore it in non-extreme cases.
16:54 NotFound I just don't think that the purpose of the deprecation policy is to keep errors.
16:55 pmichaud it's there to keep errors that downstream projects may be inadvertently relying upon.
16:55 kid51 Patrick, may I ask a question ...
16:55 pmichaud kid51: sure
16:55 kid51 Does Rakudo (or any other downstream project) have some idea of which bugs it is *advertently* relying on?
16:55 pmichaud it's there to give downstream users the opportunity to adjust to things rather than "surprise!  Your project no longer builds!"
16:55 NotFound pmichaud: I completely fail to imagine how someone mey be relying on having two chunks of source code and one being ignored.
16:56 kid51 (I haven't been involved in any downstream projects, so I don't have the user's perspective.)
16:56 pmichaud NotFound: because pmc2c now dies where previously it succeeded.
16:56 pmichaud NotFound: in other words, when I type "make" for Rakudo, it no longer gets to a running perl 6 executable.
16:56 pmichaud it now stops with an error
16:57 NotFound Because there is an error.
16:57 pmichaud an error that previously wasn't one.
16:57 pmichaud it may have been poor coding style, but it wasn't a fatal error.
16:58 pmichaud kid51: sometimes we do know that we're relying on certain bugs, yes.
16:58 pmichaud when that happens, I try (but often fail) to add a test for the buggy behavior so that someone else knows we're relying on it
16:59 tcurtis Speaking of deprecation, was the charset/encoding distinction at all user-facing?
16:59 pmichaud tcurtis: very.
16:59 pmichaud at least at the opcode level it certainly is.
17:00 pmichaud at the PMC level I suspect it could be user-facing as well, especially for users that create their own String PMC types (such as Rakudo does)
17:00 pmichaud kid51: but many times it's hard to know if a given feature is in fact a bug or "working as designed"
17:01 NotFound In fact is hard to know is it was designed.
17:01 NotFound s/is/if
17:01 pmichaud NotFound: agreed.
17:03 pmichaud in the case of the segfault example, we've already declared that "Parrot should never segfault", so any user that relies on a segfault is in fact relying on an explicitly deprecated feature.
17:03 tcurtis Did the charset_massacre merge affect the user-visible behavior of strings?
17:03 NotFound Good point ;)
17:03 kid51 IIRC, our next *supported* release is Sept 21.
17:04 pmichaud kid51: Oct 21
17:04 kid51 k
17:04 pmichaud Jan, Apr, Jul, Oct
17:04 NotFound I'm having this failure during the build with --optimize=-O3
17:04 NotFound builtins_gen.pir compilers/pge/PGE/builtins.pg
17:04 NotFound NULL current PMC at 0 in visit_loop_todo_list - thaw
17:04 NotFound current instr.: 'parrot;PGE;Perl6Grammar;Compiler;__onload' pc 24 (runtime/parrot/library/PGE/Perl6Grammar.pir:75)
17:04 kid51 CAn we put in a deprecation notice today such that it will take effect after Oct 19 ... and revert the commit, changing die to warn?
17:05 pmichaud kid51: that would be the normal procedure, yes.
17:05 pmichaud in rakudo's case it won't matter in about 10 minutes, as I'm fixing the rakudo bug (at least the one we've found)
17:05 NotFound The error message comes from r48931, previously it was a NULL PMC accessed.
17:07 pmichaud NotFound: line 75 is load_bytecode 'PGE.pbc'
17:07 kid51 NotFound:  I think we could live until Oct 19 with a deprecation notice, and a revert of r48932, and a change from 'die' to 'warn' at line 74 of lib/Parrot/Pmc2c/PMC.pm
17:07 pmichaud so it does sound like a thaw issue
17:07 NotFound kid51: As I said, I don't oppose to do it, but I'm not going to do it myself.
17:08 kid51 Then I'll do it.
17:08 NotFound Fine
17:12 jnthn plobsing: I just blogged something roadmap-ish. http://6guts.wordpress.com/2010/09/11/a​-roadmap-for-6model-and-nqp-rx-changes/
17:12 jnthn as I mentioned I would last night.
17:12 jnthn :-)
17:19 pmichaud kid51++
17:25 plobsing jnthn++ # roadmap
17:25 jnthn :-)
17:25 * jnthn afk for noms
17:28 chromatic joined #parrot
17:29 dalek TT #1785 created by jkeenan++: src/pmc/oplib.pmc, src/pmc/resizeablestringarr.pmc: Deprecate duplicated ...
17:29 dalek TT #1785: http://trac.parrot.org/parrot/ticket/1785
17:33 chromatic Testing a fix for TT #1783.
17:33 pmichaud kid51++ # because one karma wasn't enough
17:34 chromatic The warning is my preference for now as well.
17:35 sjn joined #parrot
17:36 sjn left #parrot
17:37 dalek rakudo: 085920f | pmichaud++ | src/pmc/perl6multisub.pmc:
17:37 dalek rakudo: Remove extra (unused) VTABLE get_pmc_keyed_int from perl6multisub.  Discovered by NotFound++ (Parrot r48932) and masak++.
17:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​85920ffaabb521b63a7b0c02767fe84720c0e71
17:38 nwellnhof joined #parrot
17:38 sjn joined #parrot
17:38 hudnix left #parrot
17:39 hudnix joined #parrot
17:39 plobsing NotFound: I can't reproduce your --optimize=-O3 error. what compiler/system are you on?
17:39 NotFound plobsing: amd64 debian gcc 4.3.2
17:41 patspam1 joined #parrot
17:41 patspam1 left #parrot
17:41 nwellnhof chromatic: TT #1783 might be caused by something on the stack that looks like a PMC pointer, but isn't.
17:42 chromatic Yeah, I found what should be an easy fix.
17:44 nopaste "nwellnhof" at 192.168.1.3 pasted "--- a/src/gc/system.c +++ b/sr" (12 lines) at http://nopaste.snit.ch/23299
17:44 nwellnhof Something like that?
17:45 chromatic That was my first thought, but I found something better.
17:46 dalek TT #1786 created by jkeenan++: Trac: 'Milestone' drop-down needs to display 2.10 and 2.11
17:46 dalek TT #1786: http://trac.parrot.org/parrot/ticket/1786
17:49 chromatic kid51, can you test r48936?
17:55 dalek parrot: r48935 | jkeenan++ | trunk (4 files):
17:55 dalek parrot: TT #1785: partially revert r48932 to conform to deprecation policy.
17:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48935/
17:55 dalek parrot: r48936 | chromatic++ | trunk/src/gc/system.c:
17:55 dalek parrot: [GC] Made is_pmc_ptr() much more accurate.
17:55 dalek parrot: This should fix TT #1783.
17:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48936/
17:56 kid51 chromatic in progress
17:59 nwellnhof chromatic: i'm not sure your patch is safe. it can access random memory between pmc_min and pmc_max which might be unmapped.
18:00 chromatic Is the check better after contained_in_pool?
18:00 nwellnhof yes, that should be safe.
18:04 kid51 chromatic: Got:  make: *** [compilers/opsc/gen/Ops/Emitter.pir] Segmentation fault
18:04 luben joined #parrot
18:07 kid51 left #parrot
18:08 patspam joined #parrot
18:09 dalek winxed: r628 | NotFound++ | trunk/winxedst1.winxed:
18:09 dalek winxed: fix a mistake in keyed base classes
18:09 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=628
18:14 dalek winxed: r629 | NotFound++ | trunk/ (3 files):
18:14 dalek winxed: Error for no program specified in installable driver
18:14 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=629
18:28 jhelwig left #parrot
18:29 dalek parrot: r48937 | chromatic++ | trunk/src/gc/system.c:
18:29 dalek parrot: [GC] Inverted the condition of r48936 for safety.
18:29 dalek parrot: nwellnhof argued (correctly) that *reading* the flag of something which might
18:29 dalek parrot: not be a PMC could read unmapped memory.  Kablammo.
18:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48937/
18:52 M_o_C joined #parrot
18:52 plobsing NotFound: it appears this is another victim of -finline-functions.
18:53 NotFound plobsing: some function in particular?
18:54 plobsing not sure yet, but I can get it to fail with -O2 -finline-functions but not with only -O2
18:54 plobsing I'm not certain, but I suspect our stack-scanning code.
18:55 nwellnhof plobsing: is this with gcc 4.3?
18:55 NotFound I tend to suspect of wrong const casts or lack of NULLOK somewhere
18:56 plobsing nwellnhof: yes.
18:57 plobsing NotFound: how could either of those cause only inlined versions to fail?
18:57 NotFound plobsing: inlining combined with others optimizations may delete checks for NULL
18:58 nwellnhof i have the suspicion that gcc 4.3 with -finline-functions also inlines functions with __attribute__((noinline)).
18:58 NotFound And const assumptions can make use values on register rather than re-reading memory.
18:59 NotFound When the const qualifiers ara lies... Boom
19:01 plobsing the thing is, that PMC hasn't been alive long. it gets created at src/pmc/imageio.pmc:769 and the failure occurs in the first loop iteration of Parrot_visit_loop_visit called on the next line.
19:02 plobsing it doesn't appear to be put into any const containers
19:08 dalek winxed: r630 | NotFound++ | trunk/winxedst0.cpp:
19:08 dalek winxed: start reworking of base class specifiers in stage 0
19:08 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=630
19:09 NotFound WTF is the private1 flag in imageio?
19:10 plobsing whether or not we have an external packfile constant table to work from.
19:11 plobsing we use this knowledge to avoid generating extra PBC headers and also to leverage the existing string constants when available
19:11 plobsing I would have given it a better name, but I couldn't get the pre-processor to expand things in the correct order.
19:18 NotFound Where is the todo attribute initialized?
19:20 plobsing ImageIO.init
19:20 NotFound Empty
19:20 NotFound Where is populated?
19:21 plobsing ImageIO.shift_pmc
19:21 NotFound unused = STATICSELF.shift_pmc(); ?
19:21 plobsing yes. that is used to populate the first entry in the todo list
19:22 plobsing the first being the actual object that will be evenutally returned (ImageIO.get_pmc)
19:22 NotFound What if the first object is a PMCNULL?
19:24 plobsing it cannot be NULL. the null PMC is treated separately. also it is not null in this case (otherwise it would fail elsewhere)
19:27 M_o_C left #parrot
19:30 nwellnhof left #parrot
19:32 NotFound Unfortunately pbc_dump fails the same way.
19:35 fperrad left #parrot
19:35 nopaste "plobsing" at 192.168.1.3 pasted "PGE.pbc dump" (10005 lines) at http://nopaste.snit.ch/23300
19:35 NotFound I don't see anything wrong in a packfile.winxed dump
19:36 plobsing the packfile is fine. I can read it and manipulate it with my previously installed parrot tools.
19:37 NotFound For me it fails at loading Perl6Grammar.pir
19:38 NotFound I can compile it to pbc, and looks fine, but executing the pbc gives the failure.
19:40 Paul_the_Greek joined #parrot
19:41 Paul_the_Greek Good afternoon [here in Massachusetts], folks.
19:43 NotFound At least the pbc_dump backtrace is shorter
19:49 plobsing NotFound: first discrepancy I found - failing case reads a type of 4(UnManagedStruct) for the first PMC, as opposed to 8 (ParrotInterpreter) for the non-failing case
19:54 pjcj left #parrot
19:57 NotFound plobsing: the failure is while thawing the first item inside that, it isn't?
19:57 plobsing yes. and the first PMC constant of any PBC file is a ParrotInterpreter.
19:58 dalek rakudo: 8669d77 | Util++ | build/PARROT_REVISION:
19:58 dalek rakudo: Bump PARROT_REVISION to include nwellnhof++ fix for non-ICU Parrots. Fixes RT#77778 part 2.
19:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​669d77a310a4675db8734e33969ac31db5977cd
20:06 plobsing NotFound: it appears the ImageIO is being fed a buffer that is 8 bytes offset from where it should be
20:10 NotFound plobsing: I'm not sure if it's really reading the constant segment
20:11 plobsing It is. If I use image->strstart[8] as the array base in the failing case, it matches up with image->strstart[0] in the non-failing case
20:12 plobsing I'm currently focused on PF_fetch_buf, which appears to be where the trouble is.
20:12 NotFound Nice, we just need to look for an 8 that fails when being inlined X-)
20:13 plobsing I suspect an opcde_t* isn't being incremented properly.
20:14 NotFound Yes, bytecode and fixups gets unpacked without problem.
20:17 AzureSto_ joined #parrot
20:20 AzureStone left #parrot
20:25 dalek parrot: r48938 | chromatic++ | trunk/src/string (2 files):
20:25 dalek parrot: [string] Optimized Parrot_str_substr().
20:25 dalek parrot: If the substring has no offset and the same length as the source, return the
20:25 dalek parrot: source directly.  (Hooray for immutable STRINGs!)  This optimizes Rakudo
20:25 dalek parrot: slightly by allocating fewer STRING headers.
20:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48938/
20:26 tadzik1 joined #parrot
20:27 ash_ left #parrot
20:28 tadzik left #parrot
20:28 plobsing NotFound: I'm testing a fix. Turns out gcc was breaking pointer aliasing.
20:31 NotFound plobsing: where?
20:31 plobsing in PF_fetch_opcode
20:31 plobsing stream wasn't being updated
20:31 plobsing at least when called from PF_fetch_buf
20:33 Paul_the_Greek left #parrot
20:36 tadzik1 left #parrot
20:38 nopaste "chromatic" at 192.168.1.3 pasted "Now that trunk works, can I get some review on this patch?" (53 lines) at http://nopaste.snit.ch/23301
20:38 plobsing NotFound: should be fixed at r48934
20:42 NotFound plobsing: it buils with --optimize='-O2 -finline-functions' Testing now with -O3
20:42 dalek parrot: r48939 | plobsing++ | trunk/src/packfile/pf_items.c:
20:42 dalek parrot: tidy up PF_fetch_opcode.
20:42 dalek parrot: also, for some reason gcc 4.3 now updates stream appropriately. fixes gcc 4.3 -O3 build.
20:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48939/
20:42 dalek parrot: r48940 | plobsing++ | trunk/src/pmc_freeze.c:
20:42 dalek parrot: eliminate unused variable
20:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48940/
20:46 NotFound -O3 build and pass tests. plobsing++
20:47 plobsing chromatic: patch seems to be missing a mark and sweep run that could free up more memory before compact
20:48 plobsing also the "worthwhile" test for compacting is gone, so the comment is a bit misleading
20:49 chromatic We could yank the compact there too.
20:49 NotFound chromatic: patch pass tests in amd64 -O3
20:50 plobsing benchmarks or gtfo
20:50 chromatic Suggestions for a STRING-heavy benchmark?
20:51 chromatic I wrote this patch in response to pmichaud's mail sometime last week about Parrot's GC.
20:51 sorear micro or macro?
20:51 NotFound I'm going to install int and build winxed. Not a good benchmark but can give some idea.
20:52 patspam left #parrot
20:55 nwellnhof joined #parrot
20:56 NotFound No noticeable difference
20:56 chromatic It'll have to be something NQP-rx based, I'm sure.
20:58 nwellnhof chromatic: what's the purpose of the patch? if we skip a GC run there, we will simply run the GC at the next header allocation.
20:59 chromatic It's to decouple allocating new fixed-sized pools from GC runs.
21:00 chromatic It's much more likely to get into a situation where we've exhausted one fixed-size pool without making any GCables GCable than it is to fill up a GCable pool without making any GCables GCable.
21:09 nwellnhof the timing of GC runs now depends on a global condition. it is checked in two places: allocation of a memory block for fixed size headers and allocation of a memory block for variable sized buffers.
21:10 nwellnhof if remove the check in one of these places, the GC will be run as soon as we reach the other place.
21:10 dalek winxed: r631 | NotFound++ | trunk/winxedst1.winxed:
21:10 dalek winxed: fix mistake with trans_ops commited when refactored lib loading
21:10 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=631
21:12 chromatic Enough other things allocate from pools we don't need to mark/sweep that I'm not sure running a full mark/sweep on exhaustion is useful.
21:16 nwellnhof exhaustion of a pool doesn't really trigger a GC run. it's just a good place to check for the global condition.
21:17 nwellnhof we have to change that condition if we want to make a difference.
21:17 nwellnhof taking freed memory into account, for example.
21:18 chromatic It's not even exhaustion of a pool, just not enough space in a pool for an allocation.
21:24 pjcj joined #parrot
21:25 nwellnhof but that doesn't trigger a GC unconditionally. it's only the place where we check whether to run a GC. we could put that check in as many places as we want. it wouldn't make a difference.
21:31 plobsing nwellnhof: so if we're running the GC too much, then it is because this condition is too often true?
21:33 nwellnhof plobsing: yes
21:33 nwellnhof but the condition is easily tunable to avoid GC runs at the expense of memory.
21:34 plobsing why don't we make the threshold higher then? or make it configurable such that rakudo could 'gcadvise .GONNA_ALLOCATE_A_LOT'
21:35 nwellnhof making it configurable is a good idea, IMO
21:39 chromatic Not everything that allocates a lot of memory from here is visible to Rakudo.
21:40 plobsing such as?
21:40 purl hmmm... such as is done with isgt vs islt now
21:40 plobsing purl, forget such as
21:40 purl plobsing: I forgot such as
21:40 chromatic Resizing storage of hashes and arrays.
21:43 plobsing resizing an individual array or hash isn't really visible. but rakudo knows that at startup it is going to be populating a lot of such objects.
21:47 dalek blizkost: 489e3c7 | NotFound++ | src/pmc/bkmarshal.c:
21:47 dalek blizkost: Fix mistake caused by my previous commits, not sure why
21:47 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​489e3c767dce4481e51de4047f779e9ba6871ab3
21:51 kid51 joined #parrot
21:55 plobsing hmmm... reviewing pmichaud's email, that's not really the problem. rakudo simply has a lot of objects and it is expensive to trace through them all.
21:56 pmichaud I looked at it further, a bit later.
21:56 pmichaud That program resulted in 1700 mark and sweep runs
21:56 pmichaud inside of the call to .'readall'()
21:57 plobsing we fixed that part thought, didn't we?
21:57 chromatic This patch gave me a 20% performance improvement ont hat benchmark though.
21:58 pmichaud plobsing: 'readall' was fixed, yes.  That doesn't fix the generic problem that lots of string concats result in a huge number of GC marks.
21:58 pmichaud I can come up with a straightforward Perl 6 program that exhibits the same behavior.
21:59 pmichaud sub join($sep, *@list) {   my $s = '';  for @list { $s = $s ~ $_ };  $s };   ....
21:59 pmichaud oops, and I need a $sep in there.  Anyway, you get the point.
22:00 pmichaud sub join($sep, *@list) { my $s = shift @list; while @list { $s = $s ~ $sep ~ shift @list }; $s }
22:01 plobsing understood. so the problem is that GC is triggered to frequently by this common but pathological case?
22:01 plobsing not that GC costs too much to run?
22:01 pmichaud plobsing: I think it's both.
22:01 pmichaud GC costs too much to run, and this case ran it too often.
22:02 pmichaud simply loading static code shouldn't increase our GC load as much as it did.
22:02 pmichaud let me put it a different way.
22:02 pmichaud when perl6.pbc isn't loaded, we have 1740 mark runs.
22:02 pmichaud when perl6.pbc is loaded, we have a few more mark runs, *and* those runs take a heck of a lot longer.
22:03 pmichaud enough to make the difference between 2 seconds and 22 seconds.
22:03 pmichaud and perl6.pbc is static.
22:03 pmichaud (it's static from the perspective of "it's not doing anything other than sitting in memory")
22:03 plobsing I think we could squeeze some GC performance out of inlining common mark vtables. good candidates: Sub, FixedIntegerArray, Key, etc
22:04 pmichaud I think the order-of-magnitude win is to find some way to avoid "mark the world".
22:04 chromatic That's minor optimization though.
22:04 chromatic Mark/sweep the world is just too expensive.
22:04 pmichaud put another way, those optimizations would have likely made zero difference to my example.
22:04 chromatic Look at it this way: if we *know* we've thawed all Sub attributes from PBC, why do we ever need to mark them?
22:05 chromatic Those Sub attributes should never change, if we've designed Sub correctly.
22:05 pmichaud ...sub attributes aren't static?
22:05 plobsing they aren't
22:05 pmichaud they do change, unfortunately.
22:05 pmichaud (my remark was in answer to chromatic's question... we mark them because they aren't static)
22:05 plobsing multidispatch, autoclose, various other "features"
22:05 chromatic They should be static.
22:05 dalek parrot: r48941 | NotFound++ | trunk/src (4 files):
22:05 dalek parrot: replace several usages of Parrot_str_new_noinit(interp, 0) with CONST_STRING(interp, "")
22:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48941/
22:06 pmichaud chromatic: probably they should be, but several pieces of parrot's design depend on them not being static.
22:06 chromatic Sure, and we need to fix that too.
22:06 chromatic The solution to "GC takes too long!" is "Don't mark/sweep things that never change." and "Mark/sweep only what may have changed."
22:07 ash_ joined #parrot
22:07 plobsing avoiding marking the world is hard. we could make the world smaller though. I doubt most Perl 6 programs actually make use of all of the facilities rakudo provides. If these could be lazily loaded somehow...
22:07 dalek rakudo: 9734b29 | chromatic++ | src/pmc/objectref_pmc.template:
22:07 dalek rakudo: [PMC] Made ObjectRef's mark() more accurate.
22:07 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​734b29faf0778d3593469b888ad79f1b38afdf9
22:07 pmichaud plobsing: that's actually pretty hard to do (more)
22:08 pmichaud most of Perl 6's features are built in terms of other Perl 6 features
22:09 pmichaud I suppose some of them could be autoloaded.  But I suspect it doesn't decrease the core working set by a significant amount.
22:09 kid51 left #parrot
22:09 pmichaud (I could be wrong about that; but that's my guess based on the code I've seen.)
22:10 plobsing every single method, block, hash access, namespace lookup, etc adds more gcables
22:10 plobsing I imagine those add up quite quickly
22:11 plobsing oh, I forgot function and method calls
22:11 pmichaud from a design perspective, the existence of lots of gcables shouldn't be causing huge performance penalties, though.
22:11 pmichaud if it does, that's a design flaw.
22:12 pmichaud We want programs running on Parrot to be able to handle millions of elements, if not more.
22:12 plobsing It sounds as if we really want a generational gc
22:12 chromatic We do.
22:13 * pmichaud changes his 'm' to a 'b'.
22:13 dafrito joined #parrot
22:13 jnthn We can avoid making the world every startup by making it once at compile time and serializing it. But that doesn't mean it won't be in memory.
22:14 pmichaud jnthn: did you mean s/making/marking/  ooc?
22:14 jnthn making
22:14 pmichaud we're talking about "marking"
22:14 pmichaud (gc)
22:14 jnthn My point being that without switching to a generational scheme, even doing less work at startup to construct all of those objects isn't going to mean there's any less to mark.
22:15 pmichaud I think plobsing's point was that by loading less of core Perl 6, there would be less to mark.
22:15 pmichaud i.e., make some parts of the core dynamically loadable
22:15 pmichaud instead of all-in-one-pbc as we do now.
22:15 jnthn That's less than trivial.
22:16 jnthn If we can find a way to mmap PMCs into memory then we could get it for free out of demand paging by the OS though. :-)
22:16 pmichaud :-)
22:22 pmichaud http://gist.github.com/575618   # a simple experiment
22:22 pmichaud 99,000 PMCs is not, in the overall scheme of things, a lot of PMCs
22:23 pmichaud (IMO)
22:24 kid51 joined #parrot
22:24 NotFound Someone know what is it? CONST { IMCC_INFO(interp)->is_def = 1; } INTC var_or_i '=' any_string
22:25 NotFound Declaring a .const pmc by number?
22:27 pmichaud maybe declaring a const int?
22:27 pmichaud e.g.,   .const int somevalue = 4
22:28 M_o_C joined #parrot
22:28 NotFound const int type_enum = atoi(type);  switch (type_enum) case enum_class_Sub: ....
22:29 pmichaud or is it the case of
22:29 NotFound Looks like a PMC by number. Isn't that deprecated since long time ago?
22:29 pmichaud .const 'Sub' xyz = 'somesub'
22:29 pmichaud ?
22:29 pmichaud oh yes, it may indeed be the deprecated form
22:29 pmichaud .const Sub xyz = 'somesub'   # iirc
22:30 NotFound No, that isin the next branch: | CONST { IMCC_INFO(interp)->is_def = 1; } STRINGC var_or_i '=' any_string
22:30 pmichaud aha
22:30 NotFound There is a unused static function in imc.y used only by this.
22:30 pmichaud old PGE (parrot 0.4.10) has             .const .Sub corou = '%0_corou'
22:31 pmichaud so I'm guessing it's the one that handled the .Sub
22:31 NotFound Unused -> uncovered
22:33 pmichaud looks like PGE switched to the   .const 'Sub' form in 0.8.1
22:33 NotFound Time to kill, then?
22:33 chromatic Do it.
22:33 pmichaud I'd try killing it and see what happens.
22:33 pmichaud I suspect it's just a fossil.
22:34 NotFound The way to see what happens is to commit it.
22:34 pmichaud if pge/pct survive the change, then I can't imagine anything in rakudo or other HLLs will be affected.
22:35 pmichaud 0.8.1 was like... a very long time ago.  :)
22:35 NotFound pmichaud: if coverage report says is uncovered, sure pge/pct can survive... or our test suite is a lot worse than I can imagine.
22:35 pmichaud good point.
22:35 pmichaud anyway, +1 to kill :)
22:38 hudnix left #parrot
22:46 nwellnhof left #parrot
22:52 luben chromatic, is it time to merge hash-inlined branch?
22:53 chromatic I'm all for it.
22:54 luben by the way, make headerizer spits 2 warnings in compilers/imcc/parser_util.c (try_find_op)
22:54 NotFound luben: I'v seen it, going to fix in a while
22:54 kid51 is now known as kid51_at_dinner
22:55 luben ok, I'll wait for the fix in headerizer and the I'll merge the branch into trunc
22:56 dalek parrot: r48942 | NotFound++ | trunk/compilers/imcc (3 files):
22:56 dalek parrot: delete fossil support for the long time ago deprecated form of declaring const PMC in PIR
22:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48942/
22:58 davidfetter left #parrot
23:04 NotFound luben: done, r48943
23:05 luben :) thanks. goint to resolve conflicts now, test and merge
23:05 dalek TT #1783 closed by jkeenan++: t/compilers/pge/p5regex/p5rx.t and t/compilers/pge/perl6regex/01-regex.t: ...
23:05 dalek TT #1783: http://trac.parrot.org/parrot/ticket/1783
23:07 NotFound The better way to improve coverage is to delete unused code :)
23:10 luben Why does Bison generated parsers are checked in the repository?
23:11 NotFound luben: we don't want to require flex/bison install to build parrot.
23:12 luben aha, yes... but requires a lot of hand-work on generated code in branch merges
23:12 dalek parrot: r48943 | NotFound++ | trunk/compilers/imcc (2 files):
23:12 dalek parrot: add can return null decorator to the try_find_op imcc function and make it static
23:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48943/
23:13 plobsing luben: I tend to just regenerate those files when they have a merge conflict.
23:13 NotFound luben: just ignore it, and rebuild after the mergr
23:14 chromatic Same with headerizing.
23:14 luben aha, yes... nice to know
23:14 dafrito left #parrot
23:26 M_o_C left #parrot
23:27 NotFound The function Parrot_pcc_do_run_ops is never used in the repo. Its pod says "Used in tailcall for updating RetContinuation". Can we consider it covered by the deprecation and deletion of RetContinuation ad kill it?
23:37 patspam joined #parrot
23:41 jnthn Anyone know if the PMC compiler can handle an ATTR that is a function pointer?
23:43 tcurtis jnthn: are you porting your new metamodel back to Parrot?
23:43 jnthn "back"? :-)
23:43 jnthn But yes, to :-)
23:44 jnthn tcurtis: I blogged a roadmap earlier.
23:44 jnthn tcurtis: Figured I'd make the first little steps. :-)
23:45 plobsing jnthn: probably not a straight function pointer declaration, but a typedef'd thingy should probably work.
23:45 luben hash_inline_func merged :)
23:45 jnthn plobsing: OK
23:46 dalek parrot: r48944 | luben++ | trunk (11 files):
23:46 dalek parrot: Merge hash_inlined_func branch
23:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48944/
23:46 dalek parrot: r48945 | luben++ | trunk (2 files):
23:46 dalek parrot: headerizer run
23:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48945/
23:46 NotFound But you need to typedef it in a place the generated header can see
23:46 jnthn ah, hm
23:46 jnthn Maybe I'm safer just declaring the struct I want and sorting stuff out manually.
23:47 plobsing and, last I tried, I couldn't tell pmc2c to put things in the header
23:47 jnthn Probably want it to be a PMC.
23:47 jnthn (reprs)
23:47 plobsing note that nci.pmc skirts the whole issue by using void*
23:48 jnthn heh
23:48 hudnix joined #parrot
23:48 jnthn oh hmm...GET_ATTR and SET_ATTR also always do "have we been subclassed" checks...
23:48 jnthn Er, subclassed at PIR level
23:49 jnthn Don't really want that.
23:49 plobsing you can avoid that by getting the attributes struct and doing element lookup directly.
23:49 jnthn Yeah
23:49 ttbot Parrot trunk/ r48944 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/390546.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
23:49 particle left #parrot
23:49 jnthn Well, thing is, almost all the usage of the stuff in the struct will be by stuff outside the PMC anyway
23:49 jnthn The PMC isn't much more than a "holder"
23:50 * jnthn is still working out how to map everything to C / Parrot.
23:50 particle joined #parrot
23:51 jnthn I guess if you squint a struct full of function pointers is a tiny bit like an interface. :-)
23:52 NotFound My god! It's full of function pointers!
23:54 jnthn I accidentally the whole struct.
23:55 cotto In C, we call those "objects". ;)
23:57 jnthn C-ing is believing...

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

Parrot | source cross referenced