Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-30

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 particle that's the most general solution, i think.  allow the user to set precisely how each exception will be handled
00:01 particle .'set_errors_as_exception'( $I1, $P2 ) # set these error types to exceptions, handled by this pmc
00:02 particle perhaps, if no pmc is passed, the default is to leave them unhandled, making them fatal unless otherwise handled
00:03 darbelo Wait, the user is passing me the exception to throw or the handler that will catch it?
00:04 particle the exception type, and optionally the handler
00:04 particle ...or exception types
00:04 s1n Whiteknight: i need to speak with you later, but i have to leave now, i'll be back in about 2 hours
00:06 darbelo Oh, I think I get it now. I'll go read the docs.
00:07 Whiteknight s1n: okay, awesome
00:10 Infinoid chromatic: Use helgrind much?
00:14 chromatic Only once, and never figured out what it was telling me.
00:17 particle cycling &
01:10 cotto bacek, ping
01:11 Zak joined #parrot
01:13 dalek tracwiki: v5 | Austin_Hastings++ | PGEBestPractices
01:13 dalek tracwiki: Added some more tid-bits
01:13 dalek tracwiki: https://trac.parrot.org/parrot/wiki/PGE​BestPractices?version=5&action=diff
01:16 dalek tracwiki: v25 | cotto++ | ParrotQuotes
01:16 dalek tracwiki: Whiteknight++ does things wrong, also fix formatting to indicate an afk quote
01:16 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=25&action=diff
01:16 Whiteknight ?
01:18 cotto !
01:19 davidfetter ¡
01:20 Infinoid ¿
01:28 japhb joined #parrot
01:28 Whiteknight yay!
01:28 cotto ?
01:29 dalek tracwiki: v6 | Austin_Hastings++ | PGEBestPractices
01:29 dalek tracwiki: Fixed typos, added leader.
01:30 dalek tracwiki: https://trac.parrot.org/parrot/wiki/PGE​BestPractices?version=6&action=diff
01:30 cotto Austin_Hastings++ #inadvertent pun
01:31 cotto or advertent
01:35 bacek cotto: pong
01:35 cotto bacek, According to your proposal, we'll be implementing core PMCs in nqp or PIR.
01:35 cotto Have you identified any barriers that could keep us from doing this or have you tried to implement something important (say Integer or RPA) in PIR?
01:36 bacek cotto: (NQP or PIR) it doesn't matter. My proposal to drop step with generating C from "new language for PMC"
01:37 bacek however we'll probably have to generate C for "ops"
01:38 bacek (Not necessary of cause)
01:39 bacek If we'll split "ops" into "ops" and "l1ops" where "ops" are in pseudo-C and "l1ops" in "L1"
01:39 cotto So you're saying PMCs will go PIR/nqp/HLL -> PIR -> L1/C, but ops will need to be C until we get L1 working?
01:39 bacek cotto: something like this.
01:39 purl something like this is tempting: http://www.zones.com/cgi-bin/zones/site/pr​oduct/index.html?id=000878057&zone=zbs
01:40 cotto or rather, once we get ops working in L1, we'll have all the tools to write PMCs in nqp/pir and won't need to bother with a separate pmc compiler
01:40 cotto forget something like this
01:40 purl cotto: I forgot something like this
01:41 bacek I didn't quite understand difference between those two approaches.
01:41 cotto just restating
01:41 bacek Ah. Than yes :)
01:42 cotto I still think we'll need to do some more work to be able to make PMCs work from L1, but I think your approach makes sense.
01:43 cotto I don't want to clobber the pmc_pct branch, but it looks like it's worthwhile to start working on ops instead.
01:43 bacek yes, we'll need more work for implementing some L1 ops before we can rewrite PMC into NQP/PIR.
01:43 bacek at least for raw memory access.
01:44 cotto Plus, if we define PMCs at runtime it'll make life easier for HLLs that want to have their own PMCs.
01:44 chromatic There's no reason to clobber that branch.
01:44 chromatic We should do it to get rid of the Perl 5 parser anyway.
01:45 cotto I wonder if there'd be any problems using the GC for all memory allocated from L1.
01:45 bacek We can put it "on hold"
01:45 chromatic I wouldn't think so.
01:45 chromatic Why not bring it to feature parity with pmc2c?
01:45 * bacek imaging shiny world with all memory allocated from GC
01:46 cotto bacek, including memory used by the gc? ;)
01:46 chromatic I built a bootstrapping GC once.
01:46 chromatic Not as hard as you think.
01:46 bacek chromatic: too much effort...
01:46 bacek cotto: of cause!
01:46 cotto bacek, I think the expression you're looking for is "of course"
01:47 * bacek reading ParrotQuote about 4th language :)
01:48 bacek chromatic: "too much effort" was about pmcc/pmc2c parity.
01:48 chromatic I don't see why, but I haven't been working on it.
01:49 cotto I agree with that.  pmc2c isn't great, but it's not so bad that making pmcc work until we can do PMCs in L1 is worthwhile.
01:49 bacek chromatic: there is too many corner cases in pmc2c...
01:49 chromatic That's why it'd be nice to fix them.
01:49 cotto at which point any specific PMC compiler would be obsolete
01:51 chromatic Remember though that pmc2c means that anyone who wants to build dynpmcs needs Perl 5 and all of those libraries installed too.
01:52 cotto only until L1 PMCs work
01:52 chromatic That'll be a while.
01:53 cotto yes, but that's the current state anyway
01:53 chromatic How far is pmc_pct from doing the right thing?
01:53 chromatic With some tweaks to existing PMC syntax anyhow?
01:54 cotto I'd conservatively estimate that it's half way there.
01:54 cotto More than half the coding's been done, but debugging's always tricky.
01:54 chromatic Would another two weeks get it close to merging?
01:55 cotto whose two weeks?
01:55 cotto also, how close?
01:55 chromatic Stable enough to merge, without using it by default.
01:56 cotto hmmm.
01:57 cotto it's not out of the realm of probability
01:58 cotto I'm just not seeing the benefit of putting further effort into it.  What are your thoughts?
01:58 chromatic It's not too far from landing, per a decent estimate.
01:58 chromatic It's a migration path away from pmc2c even in the short term.
01:59 chromatic It's modifiable to do what we need to do for L1 PMCs in the future.
01:59 chromatic I don't see much risk in continuing to work on it.
02:00 cotto My impression was that in the future the pir compiler would be sufficient for building PMCs, obsoleting both pmc2c and pmcc.
02:01 cotto and that since they'll both eventually be obsolete, we might as well just use what we have now
02:01 chromatic I don't assume the PIR compiler will get that sufficient without some work which includes this.
02:03 cotto You may be right, however an updated ops compiler will definitely be needed, whereas pmcc may be needed.
02:04 chromatic We *can* write PMCs in straight PIR, but I'm not sure that's the *best* way to write them.
02:05 cotto When I say "PIR", I mean anything that gets compiled to PIR.
02:05 chromatic Fair enough.
02:06 amuck_ joined #parrot
02:08 cotto btw, with all this talk about making PMCs more dynamic, how feasible do you think it'd be to avoid doing PMC initialization (as in class_init) until the first time pmc_new gets called?
02:08 cotto for a specific PMC type
02:09 chromatic I've thought about that.  You have to init its parents too, but it's not infeasable.
02:09 chromatic That might speed up startup quite a bit.
02:09 cotto just what I was thinking
02:09 chromatic Especially delaying initialization of PMCs with lots of multis.
02:09 cotto one problem is code that depends on enum_class_Foo
02:10 chromatic We probably have to define those constants and do some init anyway, but not the full init.
02:11 cotto I guess there's not a very efficient way to do that without the constants
02:12 chromatic Probably not.
02:15 cotto I wonder how that'd fit in with L1 PMCs.
02:16 snarkyboojum joined #parrot
02:16 chromatic That's an open question.
02:17 chromatic Hopefully we can rearrange our initialization at that point.
02:17 cotto It might be orthogonal.  Either way, it'd help.
02:18 chromatic Our highest priority right now is installation, and then probably the profiler.
02:19 cotto I can buy that.  There's a ton of stuff that could use work, but we do have priorities.
02:23 cotto Starting on an ops compiler would help me learn ops for profiler work.  Maybe that'd be a good thing to start on.
02:23 chromatic Seems reasonable.  I can work on the interface for pluggable runcores.
02:24 cotto sounds like enough of a plan
02:27 s1n i'm getting warnings about trap, is it intended to be experimental and thus not in ops.num?
02:30 dalek parrot: r39831 | petdance++ | trunk/compilers/imcc/pbc.c:
02:30 dalek parrot: Rewrote IMCC_int_from_reg to not be all cut & paste
02:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39831/
02:32 Andy joined #parrot
02:42 janus joined #parrot
02:43 dalek parrot: r39832 | petdance++ | trunk/compilers/imcc/cfg.c:
02:43 dalek parrot: use NULL for pointers, not 0
02:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39832/
02:59 dalek parrot: r39833 | petdance++ | trunk/include/parrot/compiler.h:
02:59 dalek parrot: annotations on the differences between pure and const functions
03:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39833/
03:04 magnachef joined #parrot
03:06 whoppix purl, tell Whiteknight about btw, my offer to make flowcharts and illustrations for the docs is still standing, if someone finds some time to throw a list of things that need illustration the most.
03:06 purl OK, whoppix.
03:09 amuck joined #parrot
03:13 nopaste "tene" at 24.10.252.130 pasted "broken implementation of 'is cached' for pmichaud++ or jnthn++" (52 lines) at http://nopaste.snit.ch/17060
03:21 skids joined #parrot
03:24 s1n is the codetest target for testing coding standards (only)?
03:28 cotto that's codingstd_test
03:28 cotto I think codetest is a little more inclusive
03:34 tetragon joined #parrot
03:36 s1n cotto: i'm looking for cage cleaning things, is codetest the right place?
03:37 Andy or running splint!
03:37 cotto s1n, what Andy said.  We'll occasionally get codingstd failures, but I think you'll have a lot more to do if you play with splint.
03:38 cotto s/get/introduce/
03:38 Andy the bummer is that splint has SO MANY WARNINGS
03:38 Andy and I'm trying to figure out what's what.
03:39 s1n i didn't think splint was maintained anymore
03:40 s1n does it work?
03:40 purl i think does it work is it used? =-)
03:42 Andy yes
03:42 Andy "Maintained" is relative
03:42 Andy build it from source.
03:42 dalek parrot: r39834 | petdance++ | trunk/compilers/imcc/parser_util.c:
03:43 dalek parrot: Splint annotations on string literals
03:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39834/
03:43 dalek parrot: r39835 | petdance++ | trunk (9 files):
03:43 dalek parrot: no longer tries to headerize on imcc.y directly.  Add lots of splint macros to imcc.y
03:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39835/
03:44 ttbot petdance: Parrot trunk/ r39835 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/43484.txt
03:44 Andy huh
03:45 cotto ttbot++
03:45 s1n Andy: do you have docs on how to use splint against parrot to do some cage cleaning?
03:45 Andy no
03:46 jdv79 cotto: get anywhere with your l1 experiments?
03:46 s1n Andy: so where would i start, what would i need to do?
03:46 cotto not terribly far, and I think I've been taking the wrong approach.
03:47 jdv79 the one you outlined in the wiki?
03:47 cotto I think I should be trying as much as possible to use existing nqp syntax to implement PMCs rather than looking for an extension every time there's something tricky.
03:47 cotto yes
03:47 cotto wait, you mean L1Recap?
03:48 Andy I wish I knew the diff between ttbot and me
03:48 jdv79 RewritingPMCsInNQP
03:49 cotto ok.  That's what I was thinking of.
03:50 jdv79 i think i get the general idea.  its the "how do we get there from here" that i guess everyone is wondering about.
03:50 cotto yes, at the nqp level
03:51 jdv79 is there something wrong with doing it with PIR?
03:51 cotto no, it's just that nqp is higher-level and easier to work with
03:52 cotto and can be compiled directly to PIR with existing tools
03:53 jdv79 nqp is tied to p6 though and pir isnt...
03:53 cotto explain "tied"
03:53 cotto it's based on perl6, but it doesn't need Rakudo or anything
03:54 cotto Once "Close" arrives (if it hasn't already), we could just as easily use it.
03:55 cotto but that might be confusing because it looks like C but is very different under the hood.
03:55 jdv79 sounds like PIR is a good fit to me.  basicaly just get rid of the C code.
03:56 cotto Straight PIR makes more sense for ops than for PMCs since the ops will generally be smaller and more self-contained.
03:57 Andy AHA
03:57 Andy For some reason, Makefile can't find my yacc
03:58 jdv79 ok.
03:59 cotto time for some shaving
04:00 Andy well, good, I've goofed up the build.
04:01 Andy are we using actual yacc, or bison?
04:04 snarkyboojum joined #parrot
04:05 chromatic Bison.
04:10 jdv79 asswipe
04:11 jdv79 wrong window - sorry
04:12 Andy chromatic: I was fooled into thinking that I was actually rebuilding files.
04:13 chromatic But you should see the other guy!
04:13 particle1 joined #parrot
04:13 Andy hey, chromatic, I gotta say, thumbs up on the regular posting to the modern perl blog
04:13 dalek parrot: r39836 | petdance++ | trunk (9 files):
04:13 dalek parrot: reverting -r39835
04:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39836/
04:14 cotto laziness?
04:14 purl i heard laziness was a virtue, after all :)
04:14 cotto laziness is also http://bill.wards.net/blosx​om/humor/story/feynman.html
04:14 purl okay, cotto.
04:16 chromatic Thanks, Andy.
04:16 Andy Time & repetition.
04:16 chromatic Fire and motion.
04:20 Andy what's that
04:20 purl somebody said that was about the level that you were asking for
04:20 tetragon joined #parrot
04:21 chromatic That's how you take control of a battlefield.
04:22 chromatic Pin down your opponent and don't get pinned down.
04:23 chromatic "Entropy".  That's my answer to your next question.
04:24 Andy Time & repetition is how habits and/or evolution and/or public perception happens.
04:26 eternaleye joined #parrot
04:30 dalek parrot: r39837 | petdance++ | trunk/compilers/imcc (8 files):
04:30 dalek parrot: adding more splint notations, this time with bison properly running
04:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39837/
04:35 snarkyboojum joined #parrot
04:43 dalek parrot: r39838 | petdance++ | trunk/compilers/imcc (2 files):
04:43 dalek parrot: consting. Removed unused interp from add_pcc_named_return()
04:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39838/
04:54 dalek close: r22 | austin_h...@yahoo.com++ | trunk/ (7 files):
04:54 dalek close: Improved self, builtins, got more of Node.c= working
04:54 dalek close: review: http://code.google.com/p/close/source/detail?r=22
05:00 amuck joined #parrot
05:03 amuck_ joined #parrot
05:14 dalek parrot: r39839 | cotto++ | branches/pmc_pct/compilers/pmcc/src (3 files):
05:14 dalek parrot: [pmcc] Simplify function body parsing to slurp everything into a PAST::Block.
05:14 dalek parrot: The next step is to change the emitter code to apply a bunch of regexes similar to what pmc2c does.
05:14 dalek parrot: NOTE: This may be the last commit to this branch, as a separate pmc compiler may not be necessary.  See http://irclog.perlgeek.de/p​arrot/2009-06-30#i_1275754
05:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39839/
05:14 cotto can someone think of a name for the new ops compiler that looks less like "oops" than "opsc"?
05:15 chromatic lops?
05:20 cotto scalpel - useful for operations
05:22 iblechbot joined #parrot
05:36 leto_ joined #parrot
05:38 bacek cotto: clops
05:38 cotto compiler for L1 ops?
05:39 cotto not bad
05:39 bacek Level One Language
05:40 bacek Ops Mega G...
05:40 bacek Ops Meta G...
05:41 bacek I can't find proper word for G... :-/
05:41 cotto the thesaurus is your friend
05:42 * cotto puts off naming the thing and digs into ops2c
05:45 tetragon joined #parrot
05:46 cotto I was hoping this would be easier than it looks like it's going to be.
05:47 bacek What doesn't kill you...
05:48 cotto leaves me badly injured and possibly scarred for life?
05:49 bacek and without hope to bright shiny future.
05:58 uniejo joined #parrot
06:08 cotto I've had lots of paper cuts that didn't kill me, but I don't feel any stronger.
06:13 jdv79 joined #parrot
06:16 tetragon joined #parrot
06:31 cotto The callgrind spec is hard to read too.  I'm getting the sinking feeling that I might have to do some actual work.
06:31 brbrooks joined #parrot
06:39 tetragon joined #parrot
06:52 leto_ joined #parrot
06:56 cotto chromatic, ping
06:58 chromatic pong
07:11 Zak joined #parrot
07:22 dalek tracwiki: v2 | cotto++ | ProposedParrotsketchProtocol
07:22 dalek tracwiki: Revert preposting recommendation to the original 30m.  We can change it later if needed.
07:22 dalek tracwiki: https://trac.parrot.org/parrot/wiki/ProposedP​arrotsketchProtocol?version=2&action=diff
08:00 burmas joined #parrot
08:03 tetragon joined #parrot
08:10 jdv79 joined #parrot
08:34 snarkyboojum joined #parrot
08:37 viklund joined #parrot
08:49 cognominal joined #parrot
09:26 nopaste "mikehh" at 217.42.128.29 pasted "codetest failures from make fulltest at r39839" (45 lines) at http://nopaste.snit.ch/17063
09:26 mikehh i got a patch - testing now
09:35 nopaste "mikehh" at 217.42.128.29 pasted "PATCH for codetest failures at r38939" (22 lines) at http://nopaste.snit.ch/17064
09:35 mikehh this Patch PASSes make test codetest and fulltest
09:36 mikehh got to go - bbl
09:44 bacek_ joined #parrot
10:31 kid51 joined #parrot
10:34 burmas joined #parrot
10:35 cognominal joined #parrot
10:58 dalek parrot: r39840 | bacek++ | branches/tt761_keys_revamp​/src/dynpmc/rational.pmc:
10:58 dalek parrot: [pmc] Fix handling of C<dest> in Rational dynpmc to be in-line with all
10:58 dalek parrot: other PMCs.
10:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39840/
11:02 dalek parrot: r39841 | jkeenan++ | trunk/compilers/imcc/pbc.c:
11:02 dalek parrot: Applying patch submitted by mikehh to remedy two coding standards failures.
11:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39841/
11:11 dalek rakudo: 78b5ac5 | jnthn++ |  (2 files):
11:11 dalek rakudo: Implement [X] for RT#67064.
11:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​8b5ac5446f790fd86417af2b6b36dcbe536e5dd
11:11 dalek rakudo: 997a1bd | jnthn++ | src/parser/ (2 files):
11:11 dalek rakudo: Get our parsing of type declarators a little more in line with STD.pm and hanlde the case where there is no C<where> clause. Resolves RT#66854.
11:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​97a1bd8d2edee0663e53b4a2c9d8dbadcdf308f
11:24 masak joined #parrot
12:06 bacek_ bah...
12:07 bacek_ msg Whiteknight Does GC check CPU registers?
12:07 purl Message for whiteknight stored.
12:08 skids joined #parrot
12:09 snarkyboojum joined #parrot
12:17 bacek_ kid51: (TT#798) it's libsdl-dev or libsdl1.2-dev
12:18 JC1 joined #parrot
12:21 rhr joined #parrot
12:22 dalek rakudo: fa963c8 | jnthn++ | src/parser/ (2 files):
12:22 dalek rakudo: Support writing of literals inside a signature.
12:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​a963c8e9ac9e52b5b73b4ee49bdb0a9ae8c4ef2
12:22 dalek rakudo: 72ececf | jnthn++ | t/spectest.data:
12:22 dalek rakudo: Add S06-multi/value-based.t to spectest.data.
12:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​2ececf2a67e0462c2a6481e7590440fd654059c
12:27 dalek rakudo: 1317e53 | jnthn++ | src/parser/actions.pm:
12:27 dalek rakudo: If BUILD is declared as a method rather than a submethod, emit a warning. Should handle RT#66120.
12:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​317e537747907874d5b10bd77e51cdefb79be11
12:51 ruoso joined #parrot
13:01 Whiteknight joined #parrot
13:36 dalek TT #800 created by pmichaud++: Parrot assumes command line arguments are ASCII
13:40 dalek rakudo: f484da5 | jnthn++ | src/builtins/globals.pir:
13:40 dalek rakudo: Implement first cut of $*CWD. Patch courtesy of Lyle <webmaster@cosmicperl.com> along with a tweak from me.
13:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​484da5e6c20acadabefb5b5e13e81a2dc4a70cb
13:40 dalek rakudo: 7773f90 | jnthn++ | src/builtins/io.pir:
13:40 dalek rakudo: Implement chdir. Roughly based off a patch from Lyle++ <webmaster@cosmicperl.com>, but with corrections to error handling and the way me update $*CWD to work with relative directory changes.
13:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​773f9079c8a7e7ced1dc241e0afbc116654a730
13:40 dalek rakudo: 466baf6 | jnthn++ | t/spectest.data:
13:40 dalek rakudo: Run chdir and $*CWD spectests.
13:40 MoC joined #parrot
13:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​66baf6820fcd33a2d305871d23d1c06bcf6a931
13:44 pmichaud missing a pop_eh in there.
13:44 pmichaud Also, I would've somewhat expected chdir() in setting instead of PIR
13:45 jonathan eh - we tailcall straight away afterwards, but yeah
13:46 jonathan Yeah, could do it that way too...though we need to instantiate the OS PMC.
13:46 pmichaud I don't mind inline PIR in that case.
13:46 jonathan And it's not a whole load of coe.
13:46 jonathan But mostly, the patch I started in was in PIR.
13:50 maettu joined #parrot
14:05 Andy joined #parrot
14:12 jonathan Man is the Parrot GC heisenbug a pain...
14:14 moritz Whiteknight++ # http://wknight8111.blogspot.com/​2009/06/l1-lets-review-faq.html
14:14 Whiteknight GC heisenbug?
14:14 moritz there's just one minor point: the usage of "algorithmic complexity" is highly misleading in that context
14:14 moritz it usually means the O(n^2) thing
14:14 jonathan Whiteknight: Aye, there's some GC bug in Parrot that is randomly tripping up Rakudo.
14:14 Whiteknight bacek: ping
14:14 moritz but it just buys us constant factors, although we hope they'll be large
14:15 jonathan (Randomly as in, it sometimes causes segfaults, and sometimes wrong answers, and when there's a small change the fail moves.)
14:16 Hunger joined #parrot
14:18 pmichaud Whiteknight: the gc bug started showing up again after the memory leak fixes
14:18 pmichaud which means that somewhere a "leak" was "fixed" that shouldn't have been.
14:19 Whiteknight urg. and I assume from the name "heisenbug" that there's no way to reliably reproduce it?
14:20 szbalint there is, you just have to run parrot long enough =)
14:20 jonathan Whiteknight: There may be a way, but no known way of yet.
14:24 Whiteknight Is there a ticket open for this?
14:25 * Whiteknight wants to get up to speed on the details without having to ask a million stupid questions
14:28 pmichaud there's not a ticket, because it's not reliably reproducible.
14:28 pmichaud as in, it only exists for certain source code programs and certain revisions of rakudo/parrot
14:29 Whiteknight ok
14:30 Whiteknight do we know then that it's even GC-related? most of the fixed memory leaks in recent days haven't involved the GC at all
14:31 moritz all non-determinism is attributed to the GC, by defintion :-)
14:31 pmichaud Whiteknight: sometimes "GC" gets used generically for "problem disappears when parrot's -G flag is used"
14:31 pmichaud and it's not "recent days" -- it's more like "within the past six weeks"
14:33 maettu left #parrot
14:34 dalek rakudo: 2827e45 | jnthn++ | src/pmc/perl6multisub.pmc:
14:34 dalek rakudo: Get Perl6MultiSub to stringify sensibly.
14:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​827e45e8271fbc663f7a09c4bc786a488b079bf
14:34 dalek rakudo: 1e742a7 | jnthn++ | src/builtins/io.pir:
14:34 dalek rakudo: Missing pop_eh spotted by pmichaud++.
14:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​e742a7db5dcc667e79fb3924df38cb1440cb21a
14:34 dalek rakudo: 91bb463 | jnthn++ | src/classes/Multi.pir:
14:34 dalek rakudo: Implement prefix:<~> for MultiSub. This makes sure we stringify Parrot multisubs correctly (it may well we that we can drop this patch if Parrot changes how they stringify).
14:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​1bb463a33e005f5ea8f8684b36b4a02bfcf5cd5
14:34 dalek rakudo: 2ae07bd | jnthn++ | src/setting/IO.pm:
14:34 dalek rakudo: Before handling stuff off to Parrot IO, we should use prefix:~ to stringify it. Causes no spectest issues.
14:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​ae07bd7504f35864f264fe07ff55ccb423beec7
14:37 Whiteknight okay, awesome
14:38 davidfetter joined #parrot
14:45 dalek parrot: r39842 | petdance++ | trunk/compilers/imcc/main.c:
14:45 dalek parrot: use NULL when you mean NULL
14:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39842/
14:45 dalek parrot: r39843 | petdance++ | trunk/compilers/imcc/symreg.c:
14:45 dalek parrot: refactored int_overflows
14:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39843/
14:49 Theory joined #parrot
14:59 bacek_ joined #parrot
15:03 mikehh joined #parrot
15:04 Whiteknight purl msg bacek yes, the GC does check the CPU registers. Check the file src/gc/system.c. It's messy and not well documented, but this is where the magic happens. Let me know if you have any questions about it.
15:04 purl Message for bacek stored.
15:12 kgilmer left #parrot
15:26 * Coke catches up.
15:30 clinton joined #parrot
15:40 chromatic joined #parrot
15:40 Coke chromatic: hey, big guy.
15:40 purl big guy is alot easier to upend on skates
15:41 rdice joined #parrot
15:41 chromatic What's up?
15:41 purl Your face, chromatic. That's what.
15:41 chromatic Also my hair, purl.
15:41 purl chromatic: excuse me?
15:41 dalek rakudo: bcdaaff | pmichaud++ | docs/release_guide.pod:
15:41 dalek rakudo: Update release_guide.pod with more names.
15:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​cdaaff93e76dc30db5b95b24d17b3657d12afa4
15:44 Theory joined #parrot
15:47 dalek rakudo: 7032827 | pmichaud++ | docs/release_guide.pod:
15:47 dalek rakudo: Release #18 is no longer "planned" -- it "happened".  masak++
15:47 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​0328275fbb1b7ac0955e49b541848d398f26f3f
15:48 szbalint haha
15:56 Tene ... looks like cloneflags.pasm isn't getting installed.
15:56 Tene Is this right?
16:04 darbelo joined #parrot
16:06 dalek rakudo: a4978b9 | pmichaud++ | src/ (2 files):
16:06 dalek rakudo: Add infix:<minmax> operator -- resolves RT #66640.
16:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​4978b90b26198e88c76a0761cbe67113d151a4c
16:06 dalek rakudo: c4e546e | jnthn++ | src/parser/ (2 files):
16:06 dalek rakudo: Change the way we detect state variable initialization to be more general. Resolves both RT#67040 and RT#67058.
16:06 purl dalek: that doesn't look right
16:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​4e546e59eb1bc6d456bd60b4ae4947cdf53ccca
16:06 dalek rakudo: 95a2c4f | pmichaud++ | src/builtins/any-str.pir:
16:06 dalek rakudo: Improve error message for "substring not found" (RT #66624).
16:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​5a2c4f850f6f90b78f603a02d1b154c363f099d
16:06 dalek rakudo: 86271a6 | jnthn++ | :
16:06 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
16:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​6271a6c39efc2fe9884bb36c4509f187073d399
16:07 cotto Heh.  I just realized that the 2+ hour YAPC Parrot BOF meeting was described as "short".
16:07 chromatic It was long for a retrospective, but we'd never done a retrospective before (and we don't do them regularly), so it was about as long as I expected.
16:08 Coke I misread that as 24 hour.
16:09 flh joined #parrot
16:09 moritz I've never seen a really short BOF :-)
16:18 cotto I'm not complaining at all.  It was a productive meeting, just not short.
16:21 dalek tracwiki: v26 | coke++ | ParrotQuotes
16:21 dalek tracwiki: I find that dozens work best in the moment.
16:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=26&amp;action=diff
16:31 smash joined #parrot
16:31 smash hello everyone
16:31 everone hello smash
16:36 cotto hi smash
16:40 Psyche^ joined #parrot
16:45 dalek parrot: r39844 | pmichaud++ | trunk/src/string/charset/unicode.c:
16:45 dalek parrot: [strings]:  Fix bug in upcase handling on unicode strings.
16:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39844/
16:50 * jonathan pre-pastes his report.
16:53 jonathan parrotsketch?
16:53 purl i think parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
16:53 jonathan clock?
16:53 purl jonathan: LAX: Tue 9:53am PDT / CHI: Tue 11:53am CDT / NYC: Tue 12:53pm EDT / LON: Tue 5:53pm BST / BER: Tue 6:53pm CEST / IND: Tue 10:23pm IST / TOK: Wed 1:53am JST / SYD: Wed 2:53am EST /
16:53 jonathan Wait, none of them is UTC!
16:53 davidfetter LON is BST, which is usually pretty close to UTC ;)
16:54 jonathan UTC doesn't do daylight savings, though?
16:54 cotto time?
16:54 purl i guess time is 16:49:35 2009 and (did you mean "clock"?) or flowing like a river or the fire in which we burn
16:54 jonathan OK, so is #ps in 35 minutes of 95 minutes?
16:54 jonathan That is, do I eat now or later? ;-)
16:54 cotto 95
16:54 jonathan Food now! :-D
16:55 cotto nom
16:55 davidfetter SELECT now() AT TIME ZONE 'UTC';
16:55 davidfetter timezone
16:55 purl timezone is, like, at http://www.timeanddate.com/worldclock/
16:55 davidfetter ----------------------------
16:55 davidfetter 2009-06-30 16:56:11.301204
16:56 antiphase Has no-one heard of NTP?
16:56 cotto or date -utc
16:56 cotto s/-/--/
16:57 moritz antiphase: even if you have, it might be unwise to mix your database's time with your system time ;-)
17:09 abesapien joined #parrot
17:11 whoppix evening #parrot.
17:12 moritz hei whoppix
17:13 whoppix moritz :) hows rakudo coming along?
17:13 Whiteknight evening whoppix
17:13 moritz whoppix: nicely
17:13 whoppix Whiteknight, hey. You got my message?
17:13 whoppix moritz, cool
17:23 allison joined #parrot
17:24 Whiteknight whoppix: no, no messages
17:25 Whiteknight Coke: I've made a lot of progress on that context_pmc branch, but I still only give it about a 50% chance of success as is
17:25 Whiteknight we may need to go back in as a second step and clean things up first
17:25 whoppix Whiteknight, oh. Well, I was just saying, that my offer to illustrate the docs still stand, if someone finds some time to lump together a list of topics that need illustrating the most.
17:26 whoppix Whiteknight, then I'll read up on the topics myself and make illustrations, which someone more familliar with parrot can proof-read.
17:26 Whiteknight whoppix: oh excellent! I'll make sure we get a list to you!
17:26 whoppix Whiteknight, ok, cool.
17:27 Coke Whiteknight: yes, well, I was hoping we'd clean it up first. =-)
17:28 Whiteknight damn the torpedos, full speed ahead!
17:28 Coke If you want to restart the branch, that's fine.
17:28 Whiteknight plus, I'm getting a much better understanding of where all Contexts are used
17:28 Coke hokay.
17:29 Coke might be good if you slapped a page together with what you think is coming up next.
17:29 smash Coke: sorry, did i miss a relaease ? i have fallen off the face of the earth a couple of times this year
17:32 Coke smash: you mean a release you were scheduled to do? I think so, but we had it covered.
17:32 Coke for penance, you can close a few tickets. =-)
17:32 smash Coke: i'm terrible sorry about that..
17:32 smash fair enough, gimme some links :-P
17:34 Whiteknight moritz: you got clang+llvm to build Parrot? Do tell! Could you write up a recipe on the wiki?
17:36 moritz Whiteknight: there was no black magic involved, and I wrote about it on the list ;-)
17:36 moritz Whiteknight: but if you suggest a nice title I can certainly add a few lines
17:37 Coke smash: my preference is anything on this report marked tcl:
17:38 Coke https://trac.parrot.org/parrot/report/16
17:39 dalek decnum-dynpmcs: r94 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
17:39 dalek decnum-dynpmcs: Changed all of DecNumContext's numeric getters/setters to return/accpet INTVAL
17:39 dalek decnum-dynpmcs: for increased convenience when using the PMCs from PIR.
17:39 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=94
17:39 NotFound "reports by 1800 UTC": "by" means before of after?
17:39 moritz before
17:39 NotFound Ok
17:41 Whiteknight moritz: BuildWithClang seems like a good title
17:41 Whiteknight or BuildWithClangAndLLVM
17:44 brbrooks joined #parrot
17:46 cotto Clang implies LLVM
17:48 moritz aye
17:52 cotto Whiteknight, if all PMC-related memory allocations went through the GC, what other changes would we need to make?
17:52 Whiteknight cotto: what do you mean?
17:52 chromatic malloc/free use GC pools.
17:53 chromatic We could use sized pools (more overhead in managing them, possibly less fragmentation) or just extend the heap and deal with any fragmentation later.
17:55 jhorwitz joined #parrot
17:55 Whiteknight chromatic: we do have sized pools now that are miserably underutilized
17:57 moritz Util: if you need some help on your PPI-based 5->6 translator, feel free to ping me
17:57 moritz (but not this week, I fear)
17:57 Util moritz: thanks!
17:58 cotto ppi?
17:58 purl i think ppi is a perl syntax parser that is good enough to actually use, and is quite capable of handling most non-DamianWare :) or useful for automating perl golfing. or at http://www.perl.com/pub/a/2005/06/09/ppi.html or "100 percent round-trip safe, and it's been stress tested against the 38,000 (non-Acme) modules in CPAN, handling all but 28 of the most broken and bizarre" or impossible or Penis Pushes Inside
17:58 dalek tracwiki: v1 | moritz++ | BuildingWithClang
17:58 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Buil​dingWithClang?version=1&amp;action=diff
18:00 moritz ok, I've added that wiki page. Should I link to it somewhere?
18:01 cogno joined #parrot
18:04 dalek tracwiki: v3 | Util++ | ProposedParrotsketchProtocol
18:04 dalek tracwiki: https://trac.parrot.org/parrot/wiki/ProposedP​arrotsketchProtocol?version=3&amp;action=diff
18:04 amuck_ joined #parrot
18:05 Util purl, PPI is also http://search.cpan.org/dist/PPI/
18:05 purl that is too long, Util
18:08 pmichaud Whiteknight: rather than wait for #ps, I'll ask my current question here:   Why was TT #389 assigned to me?
18:09 Coke ppi?
18:09 purl well, ppi is a perl syntax parser or http://www.perl.com/pub/a/2005/06/09/ppi.html or http://search.cpan.org/dist/PPI/
18:10 Util Coke: much better!
18:10 Whiteknight pmichaud: I dont remember, let me look it up
18:11 Whiteknight you know what? I have no idea. It might have been a goof
18:15 Whiteknight allison: when does the book show up on amazon? :)
18:15 pmichaud #ps in 15
18:15 Whiteknight or, for that matter, when does it appear someplace that I can buy a copy?
18:15 allison Whiteknight: the printers have to finish processing it
18:16 burmas joined #parrot
18:16 Whiteknight okay, and how long does that take? My last experience with a publisher was a print-on-demand thing and I had a book in my hands in 4 days
18:18 Whiteknight darbelo++
18:18 Coke allison: someone should ping monty python and ask for an endorsement. =-)
18:18 allison Whiteknight: that was my experience last time I submitted a print-on-demand title too
18:18 allison Coke: lovely idea :)
18:19 Whiteknight "Wait a minute, this isn't funny at all!" - Monty Python
18:19 moritz darbelo++ # using adverbs in his #ps report ;-)
18:19 moritz dalek: a short line on how much you are on schedule would be nice
18:19 moritz erm, meant darbelo
18:20 Coke allison: which book: draft/ or pir/ ?
18:21 Whiteknight joined #parrot
18:21 allison Coke: pir/
18:22 Coke allison: ""The C<die> opcode throws a
18:22 Coke fatal (that is, uncatchable) exception""
18:22 Coke ORLY?
18:22 purl YA RLY.
18:23 Coke what's the difference between draft/ and pir/ ? is pir just a finalized version?
18:24 amuck_ joined #parrot
18:24 cogno joined #parrot
18:24 allison Coke: draft/ is all the chapters of the original book, pir/ is just the PIR chapter from the original book, broken out into separate chapters
18:25 allison Coke: I'm thinking the next book should be a cleaned up version of the Squaak tutorial
18:25 Coke ok. is that original chapter deleted from draft/ ?
18:25 cotto #ps in 5
18:25 dalek rakudo: aa1a18d | pmichaud++ | docs/spectest-progress.csv:
18:25 dalek rakudo: spectest-progress.csv update: 409 files, 11510 passing, 85 failing
18:26 dalek rakudo: Failure summary:
18:26 dalek rakudo:     S02-builtin_data_types/hash_ref.rakudo 23,24,25,26,28,29,30 - The object is-a 'Hasi'
18:26 dalek rakudo:     S02-builtin_data_types/num.rakudo 32,34,36,38 - The object is-a 'Nun'
18:26 dalek rakudo:     S02-builtin_data_types/range.rakudo 11,15 - got the right array
18:26 dalek rakudo:     S02-literals/quoting-unicode.t 68,69,70 - q-style string with ...
18:26 dalek rakudo:     S02-names_and_variables/fmt.rakudo 5 - fmt() works with @ array
18:26 dalek rakudo:     S02-whitespace_and_comments/comments.rakudo 7,8,9 - embedded comment ...
18:26 dalek rakudo:     S03-operators/cross-metaop.rakudo 4 - smooth cross operator works
18:26 dalek rakudo:     S03-operators/increment.rakudo 3 - magical ++ should not be numified
18:26 dalek rakudo:     S03-operators/increment.rakudo 4 - it isa Str
18:26 dalek rakudo:     S03-operators/range.rakudo 5,6,8,10,12,29,33,48
18:26 dalek rakudo:     S04-statement-modifiers/until.rakudo 4 - post until
18:26 dalek rakudo:     S04-statement-modifiers/while.rakudo 4,5 - post while
18:26 dalek rakudo:     S04-statements/do.rakudo 7,8 - prefixing 'if' statement with 'do' ...
18:26 dalek rakudo:     S05-match/capturing-contexts.rakudo 1,2 - Match object ...
18:26 dalek rakudo:     S05-substitution/match.t aborted 5 test(s)
18:26 dalek rakudo:     S05-transliteration/trans.rakudo 8,9,10,14 -
18:26 dalek rakudo:     S12-attributes/recursive.rakudo 2 - Sanity check, $a is of type A
18:26 dalek rakudo:     S12-class/basic.rakudo 5 - .isa("Foo")
18:26 dalek rakudo:     S12-enums/basic.rakudo 27 - short name of the enum without parenthesis is an enum
18:26 Coke AIGH.
18:26 dalek rakudo:     S32-container/zip.rakudo 11,12 - can mix arrays and ranges for infix:<Z>
18:26 dalek rakudo:     S32-io/IO-Socket-INET.t 2 - echo server and client
18:26 dalek rakudo:     S32-num/int.rakudo 40,42,44,46,48,50,52,54,56,58,60,62 - The object is-a 'Inu'
18:26 dalek rakudo:     S32-num/rand.rakudo aborted 5 test(s)
18:26 dalek rakudo:     S32-scalar/undef.rakudo 37 - The object is-a 'Hasi'
18:26 dalek rakudo:     S32-str/lc.rakudo 8 - lowercasing char-range
18:26 dalek rakudo:     S32-str/words.rakudo aborted 8 test(s)
18:26 dalek rakudo:     integration/99problems-21-to-30.rakudo aborted 5 test(s)
18:26 cotto epic commit message
18:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​a1a18dc1c0942874fa52e595b9f822bf965bcbe
18:27 nopaste "pmichaud" at 72.181.176.220 pasted "rakudo daily test failures, 2009-06-30" (68 lines) at http://nopaste.snit.ch/17066
18:27 moritz notice "The object is-a 'Inu'" and "The object is-a 'Hasi'"
18:27 pmichaud moritz: yes, that's the "strange calls to .succ" that I mentioned.
18:27 pmichaud 'Inu' = 'Int'++
18:27 dalek parrot: r39845 | allison++ | trunk/docs/book/pir (9 files):
18:27 pmichaud 'Hasi' = 'Hash'++
18:27 pmichaud etc.
18:27 dalek parrot: [book] Final cross-reference and page-break fixes.
18:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39845/
18:27 dalek parrot: r39846 | coke++ | trunk/docs/book/pir/ch09_exceptions.pod:
18:27 dalek parrot: fix typo
18:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39846/
18:28 allison Coke: not sure, checking...
18:30 pmichaud #ps in 0
18:31 cogno joined #parrot
18:33 jan joined #parrot
18:36 jonathan Hasigotagcbug?
18:36 chromatic Hope not.
18:37 jonathan Unfortunatley, Parrot has.
18:37 jonathan :-(
18:37 pmichaud the errors in the nopaste seem to occur primarily with the fakecutable.  Running with perl6.pbc doesn't produce the same errors (still checking this)
18:38 moritz pmichaud: which parrot version did you use? with the 1.3.0 release it looks much cleaner here
18:39 NotFound Can someone delete RT #67078?
18:39 cotto NotFound, will do
18:39 pmichaud moritz: the 1.3.0 release.
18:50 athomason joined #parrot
18:53 einstein joined #parrot
18:53 amuck_ joined #parrot
18:57 * Coke at $DAYJOB
19:00 dalek close: r23 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
19:00 dalek close: Created wiki page through web user interface.
19:00 dalek close: review: http://code.google.com/p/close/source/detail?r=23
19:00 dalek close: r24 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
19:00 dalek close: Edited wiki page through web user interface.
19:00 dalek close: review: http://code.google.com/p/close/source/detail?r=24
19:00 dalek close: r25 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
19:00 dalek close: Deleting wiki page WishList.
19:00 dalek close: review: http://code.google.com/p/close/source/detail?r=25
19:04 jevin joined #parrot
19:05 Util pmichaud: I would be very interested in a repeatable test case that fail with fakecutable but succeeds with perl6.pbc.
19:05 chromatic The only real difference between the two is that the fakecutable always enables the --leak-check flag.
19:06 Coke pmichaud++
19:06 Util chromatic: that *should* be the only difference; if another diff is lurking, I will hunt it.
19:06 cotto pmichaue?
19:09 Coke 1072 / 60
19:09 purl 17.8666666666667
19:11 pmichaud util:  Let me see if I can get the instructions together for a repeatable perl6 failure.
19:13 jonathan chromatic: I've seen bugs appear and disappear with very small, unrelated changes. I think just a slightly different memory allocation profile - which the fakeexecutable is *occasionally* enough to give - can do it.
19:14 jonathan chromatic: The *vast* majority perform exactly the same under the fakeexecutable and without it though and it's -G that hides the problem.
19:14 chromatic True, the memory layout will be slightly different.
19:15 jonathan So I'm about certain it's not the fakeexecutable that holds the problem. It just sometimes might make enough of a different in memory layout to make the bug trigger differently.
19:15 jonathan *difference
19:17 Tene joined #parrot
19:18 jdv79 joined #parrot
19:18 Theory joined #parrot
19:21 dalek tracwiki: v76 | whiteknight++ | WikiStart
19:21 dalek tracwiki: creating a section here on the main page to list our current development priorities
19:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=76&amp;action=diff
19:21 dalek tracwiki: v77 | whiteknight++ | WikiStart
19:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=77&amp;action=diff
19:21 dalek tracwiki: v78 | whiteknight++ | WikiStart
19:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=78&amp;action=diff
19:23 flh How would someone describe what the Capture PMC is? Is it just a clever combination of a list and a hash? Why is it called "Capture"?
19:23 pmichaud jonathan: the nopaste I just gave actually demonstrates differences between 'perl6' fakecutable and running the .pbc
19:23 Whiteknight flh: that's actually a very good question. I have no idea what that PMC is for
19:24 Whiteknight flh: I don't think it gets used much, at least not any more
19:24 pmichaud Capture is the base class for all of PGE and PCT.
19:24 pmichaud so I think it gets used a lot.  :-)
19:24 * Whiteknight will just shut up now
19:24 allison pmichaud: Are you using the C Capture now?
19:24 pmichaud flh: Capture is basically a list and a hash, yes.  It represents things that can have both positional and named values.
19:25 moritz flh: it's called "Capture" in Perl 6 because it captures the contents of an argument list
19:25 allison pmichaud: didn't you used to use a PIR Capture Class?
19:25 pmichaud allison: yes, but switched to the Capture PMC once it was available and reliable.
19:25 pmichaud (because the Capture PMC is substantially faster)
19:25 Coke rant: now when a language is marked cross-HLL we'll have no idea WHICH languages it's HLL for. =-)
19:26 Coke meaning we'll have to put it elsewhere. which means we'll have two places to check.
19:26 pmichaud Coke: I think the purpose of "cross-HLL" is to denote issues specifically affecting language interoperability
19:26 pmichaud Coke: it's not intended to simply say "this issue affects multiple languages"
19:26 Coke in which case, that's a component, not a language.
19:27 pmichaud component++
19:27 allison yes, I'm adding the component "hll-interop"
19:27 allison (did someone suggest it as a language?)
19:28 Coke I thought so, based on #ps. could have read it wrong.
19:28 Coke it's still an issue that we can't say that some bug affects both tcl and rakudo.
19:28 Coke easiest way around that is to fix all those bugs. =-)
19:29 Coke Whiteknight: a surprising number of those 300 tickets are still open.
19:29 Coke (for good reason)
19:29 allison Coke: hmm... we could probably create a custom select type
19:29 Whiteknight I think #ps today was very nice and very productive
19:30 Whiteknight maybe needs some practice, but good overall
19:30 pmichaud Coke:  I suspect that TT #760 is no longer a blocker for Tcl.  It's been marked as "rejected", at any rate.
19:30 pmichaud (TT #760 is still appearing in the /16 report)
19:30 NotFound TT #661: there is still something on int blocking perl6, or any other?
19:30 Coke pmichaud: if the ticket is rejected, it shouldn't even be on that report.
19:31 pmichaud NotFound: I was just looking at that.  I think #661 can be marked as resolved, at least from rakudo's perspective.
19:31 pmichaud Coke: Agreed -- so perhaps the report needs fixing.
19:31 Coke will do.
19:31 allison pmichaud: you have a few minutes to talk about install questions?
19:32 NotFound pmichaud: I think you or some other rakudo guy said it was no tested yet on windows, maybe 2 weeks ago. Is this solved?
19:32 iblechbot joined #parrot
19:32 pmichaud NotFound: I think it is solved.  But if it isn't, then we can wait until someone speaks up about it again.
19:33 pmichaud (and they can file a new ticket if that's the case)
19:33 Coke pmichaud: fixed; added status column in report, skipping records == rejected.
19:33 NotFound I'll add a comment on the ticket saying it will be closed in a few days if no one objects, then.
19:33 pmichaud NotFound:  +1
19:33 purl 1
19:34 pmichaud (though I'd be okay with closing it now.)
19:34 Coke NotFound: that is such a common action, i wonder if we should add a status called "closing".
19:34 chromatic Or "closed"?
19:34 Coke (anything in a closing state that's more than N days old is fair game to close.)
19:34 Coke chromatic: but it's not closed.
19:34 nopaste "pmichaud" at 72.181.176.220 pasted "rakudo head running on Parrot trunk, spectest results" (31 lines) at http://nopaste.snit.ch/17068
19:35 Coke I suppose we could just say "closing ticket. Reopen if necessary"
19:35 chromatic Yep.  Reopening is cheap.
19:35 NotFound Coke: I'd like that, if the close will be automated.
19:35 Coke and then leave off the last sentence to be succint.
19:35 Coke er, terse. =-)
19:35 allison Coke: that has the advantage of requiring less work in the default case
19:35 chromatic It's like writing a technical book where each paragraph ends with a sentence telling you what the next paragraph will be about when you get around to reading it, which you'd already be doing if not for the presence of the sentence telling you what you will be reading in a moment.
19:36 chromatic Slightly different from the Star Trek V problem.
19:36 chromatic Sorry, Star Trek: Generations.
19:36 NotFound The I'll close it, following our guru's words about laziness.
19:41 dalek TT #661 closed by NotFound++: [TODO] Capture output of subprocesses
19:44 * Coke wonders if he'll have to post that message with slight updates in another six months.
19:44 japhb Tene: re: the two "General Issues" at the top of https://trac.parrot.org/parr​ot/wiki/HllInteroperability ... Are they 1) already ticketed but you don't know the TT#s, or 2) definitely not ticketed, or 3) may or may not be ticketed?
19:45 pmichaud japhb: The second general issue is probably TT #150
19:46 japhb pmichaud: thanks, looking
19:46 japhb Appears trac is quite slow right now ...
19:47 dalek parrot: r39847 | allison++ | trunk (2 files):
19:47 dalek parrot: [book] Deleting draft chapter now split into a full PIR book.
19:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39847/
19:49 MoC joined #parrot
19:49 Sark joined #parrot
19:49 Tene japhb: I have no idea
19:50 Tene japhb: I have a lot of trouble trying to remember to deal with tickets properly.
19:50 japhb Reading your TT #150, as suggested by pmichaud, I think he's right, that's a match for issue #2
19:50 * japhb goes to edit wiki page
19:50 japhb Crap, have to learn yet another markup language
19:51 nopaste "pmichaud" at 72.181.176.220 pasted "difference between perl6 fakecutable and perl6.pbc (for Util)" (20 lines) at http://nopaste.snit.ch/17070
19:51 pmichaud Util:  See nopaste #17070 (above)
19:51 Tene japhb: Yes, tt150 is right
19:51 abesapien joined #parrot
19:51 smash any wiki page with the install issues mentioned earlier ?
19:51 japhb How do I mark up a TT# on the wiki so that it will be linked?  Just do it like any other HREF?  Or does it recognize special syntax?
19:51 Tene japhb: the other is 777
19:52 PacoLinux joined #parrot
19:52 japhb Tene: thanks
19:52 dalek TT #801 created by flh++: Rewrite capture.t in PIR
19:52 Util pmichaud: thanks; will investigate today.
19:52 Tene japhb: I'll try to work on enumerating and ticketing everything else I can think of tonight.
19:52 pmichaud japhb: I think just  "#150"  is sufficient to generate a link to a ticket.
19:53 japhb Tene: did you create one for the "can't instantiate classes other than the one named in the use statement" problem?  ('use OpenGL::Math:from<parrot>;' doesn't allow 'new OpenGL::Math::Vec4')
19:53 japhb Tene: thanks
19:53 Tene japhb: Your description there isn't exactly right...
19:53 Tene but I have a few clues
19:53 japhb Tene: fair enough
19:54 allison pmichaud: one general philosophical question about install tools
19:54 Tene I'm checking to confirm that #744 hasn't been fixed yet...
19:54 allison right now, our biggest problem is trying to make install tools that ship with parrot and work when they live the build directory and also the install directories
19:55 * smash wavez.
19:55 Tene hi smash
19:55 pmichaud allison:  (short-circuiting where I think you're leading)  I think we should no longer have a notion of "run from the build directory", except to the extent that we create something that looks like an install in the build directory
19:56 pmichaud but I'm guessing you're actually about to ask something else :-)
19:56 allison pmichaud: this is much simpler if language building tools aren't installed with parrot at all, they're just given as "examples" and each language keeps their own customized versions
19:56 dalek tracwiki: v8 | japhb++ | HllInteroperability
19:56 dalek tracwiki: Add Trac Ticket numbers for two existing General Issues
19:56 dalek tracwiki: https://trac.parrot.org/parrot/wiki/HllIn​teroperability?version=8&amp;action=diff
19:57 pmichaud allison: Philosophically I completely agree with that, but there are a few additions
19:57 allison pmichaud: aye, that's also true, to the extent that we can get a build directory to mimic an install
19:57 pmichaud In particular, Parrot should provide tools for compiling dynpmcs and dynops.  We shouldn't expect languages to maintain separate copies of those.
19:57 chromatic I'd like to keep the ability to run HLL code from a Parrot I haven't installed with 'make install' or 'make install-dev', but I don't care if it gets rearranged by 'make' in the Parrot build directory.
19:57 Coke (make hll languages write their own tools); I have concerns with that.
19:58 pmichaud in fact, the tools for compiling dynpmcs and dynops need to follow the deprecation cycle -- they're in effect part of the Parrot API
19:58 allison pmichaud: that is, installing should be no more than copying from one directory to another
19:58 allison Coke: aye, the problem is when you have to fix a bug in the "example" that was the starting point for all the languages
19:58 pmichaud I completely agree that "make install" ought to act more like a copy.  Currently it does a re-build, which means that what we tested with "make test" isn't at all what gets installed.
19:58 allison Coke: it doesn't automatically spread out to all the languages
19:59 allison chromatic: yes, being able to run in the build directory somehow is required for testing
20:00 pmichaud I think we all agree that Parrot's "make" should create something that looks like an uninstalled install
20:00 Coke pmichaud: given that we're linking against two different configs, I'm not sure you can avoid that.
20:00 allison pmichaud: but at the same time, you don't want Parrot to do the processing on your makefiles?
20:00 Coke it already doesn't rebuild individual c files, anyway.
20:00 pmichaud Coke: I'm saying there should be only one real "config"
20:00 Coke pmichaud: ... how?
20:00 allison pmichaud: (that is, I was thinking you were in favor of decoupling the languages from the Parrot scripts)
20:01 pmichaud Coke: but if there can't be only one real config, we should at least make the two configs look as similar as possible
20:01 Coke pmichaud: that's another issue for which there is already a ticket.
20:01 Whiteknight I added a priorities section to the main page of the wiki
20:01 Whiteknight we can list important priorities there
20:01 Coke (see doughera's thoughts on that process)
20:01 pmichaud Coke: i.e., paths to libraries and precompiled things should be the same (modulo the root of the directory)
20:02 allison pmichaud: "make install" shouldn't be building anything. If it is, it's a dependency bug in our makefile
20:02 dalek rakudo: c51b9aa | jnthn++ | src/builtins/guts.pir:
20:02 dalek rakudo: Fix inheritance from Object - it no longer tries to also add Any as a parent also (which explodes when building the C3).
20:02 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​51b9aae43060b58a5f04247c2f85a93a281a40e
20:02 pmichaud Coke: I'm not at all claiming that what I'm suggesting is different from adougherty's stuff.  :-)   Everything I've seen adougherty write I agree with.
20:03 pmichaud allison: iiuc, "make install" recompiles the parrot binary
20:03 pmichaud I could be wrong -- haven't checked recently.
20:03 allison it didn't 4 months ago when I worked on the install process, but could have been introduced since then
20:03 Coke pmichaud: there is a ./parrot and a ./parrot_install, or something to that effect.
20:03 pmichaud Coke: yes, that's that I remember.
20:04 pmichaud We test "./parrot", but then installed "./parrot_install"
20:04 Coke right.
20:04 pmichaud s/installed/install/
20:04 allison mmm... yes, that is true, and should change
20:04 Tene japhb: are we just listing all HLL-related tickets on the HLLinteroperability page?
20:04 Coke the only (theoretical) change is the config.
20:04 pmichaud no, other things change as well.
20:04 Coke Tene: better to just link to the report.
20:04 pmichaud In particular, the paths where the libraries get found.
20:04 Tene Coke: which report?
20:04 purl somebody said which report was the hopkins report? I'm losing track of which is which.
20:04 Coke those paths are in the config.
20:04 Coke Tene: #16
20:04 pmichaud some of them are compiled into the binaries.
20:05 Coke as part of the config, yes?
20:05 japhb Tene: I was thinking "any tickets directly affecting HLL interop that don't affect single-HLL (or pure PIR) code"
20:05 allison pmichaud: yes, but it's the same ones between the two
20:05 pmichaud as hard-coded paths.
20:05 allison pmichaud: that is, Parrot has a set of search paths that include both install and build directories
20:05 Coke japhb, tene: in that case, you can just have a report that returns things assigned to that component.
20:05 allison and both ./parrot and ./parrot_install get the same search paths
20:05 pmichaud allison: that matches what I've seen, yes.  But we should get rid of the "build directory" paths from parrot altogether.
20:06 Coke OBTW: 'make test' failing on feather because, I think, of the pre-installed 1.2.0 parrot.
20:06 japhb Coke: until a few minutes ago, we didn't have that component.  We're still looking for the tickets.  :-)
20:06 allison (there was a change proposed to have different search paths for the two, but it was rejected)
20:06 pmichaud i.e, we just include the install versions of the paths.
20:06 Coke I'm just saying, don't link to them, just tag 'em.
20:06 japhb Coke: can a report be embedded into a wiki page?
20:06 Coke japhb: embed? no clue. link to? sure.
20:06 Coke going to yapc::eu?
20:06 purl it has been said that going to yapc::eu is (: going to YAPC::EU 2009)
20:06 Coke going to yapc::eu 2009?
20:06 purl going to yapc::eu 2009 is ash or BinGOs
20:06 Coke going to yapc::eu 2009 is also maybe coke
20:06 purl okay, Coke.
20:06 allison pmichaud: yes, that's perfectly possible, since the search paths respect the 'prefix' config option
20:06 jonathan going to yapc::eu 2009 is also jnthn
20:06 purl okay, jonathan.
20:07 Coke I just found out I'll be in the UK the week before.
20:07 japhb Coke: I'd prefer if they weren't a link apart.  I'll see what embedding is available.
20:07 pmichaud at any rate, from a hll implementors perspective, it would be far simpler if the relative paths for components (e.g., nqp and perl6grammar) were identical for built and installed versions of Parrot.
20:07 japhb Coke, Tene: In the mean time, I'll change the Component for the tickets we know about.
20:07 japhb Tene: What were your findings on #744?
20:07 Tene japhb: still segfaults
20:07 purl No whammies!
20:07 allison pmichaud: so, all that's actually stored is 'library/' or 'dynext/', and the 'prefix' provides the rest of the path
20:07 Coke pmichaud: that's solved by making the build look like the install.
20:08 pmichaud Coke: that's what I'm advocating, yes.
20:08 Coke so let's make that the priority.
20:08 Tene allison: could parrot_config locate the prefix it's currently running from at runtime?
20:08 Coke then maybe the config stuff will fall out of that.
20:08 pmichaud (afaik, I haven't been advocating anything else.)
20:08 Coke pmichaud: probably not. =-)
20:08 * Whiteknight is heading home
20:08 Coke Whiteknight: no!
20:08 Coke you stay right there.
20:08 Whiteknight !!!
20:08 Coke JK.
20:09 allison there's a tricky bit to making the build look like the install, though, and that is the clash between the parrot runtime directories and the C directories (we have two 'include' directories)
20:09 Whiteknight haha, later
20:09 pmichaud allison:  (decoupling)  Some things like makefile generation should be decoupled from parrot -- i.e., I expect languages to create their own tools for that (from examples that Parrot provides)
20:09 Coke allison: just have our "local install" go into blib
20:09 MoC joined #parrot
20:09 pmichaud that's because hlls and other users may have some heavy customization they need to do with makefiles
20:09 allison pmichaud: but dynpmcs and dynops are makefiles
20:10 Tene I discovered today that cloneflags.pasm isn't installed.  Is this an issue?
20:10 pmichaud I think that dynpmc and dynop generation ought to be tools that Parrot provides
20:10 pmichaud and *not* be pure makefiles
20:10 pmichaud because the generation of dynops and dynpmcs is heavily dependent on configuration information that's not easily managed in makefiles
20:10 jonathan That's what the (now deprecated) tool for them did, IIUC?
20:11 allison pmichaud: they're just a series of generated and compiled files, with dependencies on what should be built first
20:11 brbrooks joined #parrot
20:11 jonathan (e.g. the one that Rakudo still uses...unless that's changed...)
20:11 pmichaud allison: what generates the files?
20:11 allison pmichaud: it seems a bit silly to reinvent makefiles
20:12 pmichaud we don't really need to reinvent makefiles here, though.
20:12 allison pmichaud: it's pretty much exactly like PGE
20:12 pmichaud I don't understand "exactly like PGE"
20:12 allison pmichaud: you call a script to process some syntax
20:12 allison pmichaud: it generates a more general form, which is then compiled
20:12 pmichaud I'm saying that script ought to be one level higher than it is now
20:13 allison the script should generated the C code and compile it?
20:13 allison s/d//
20:13 pmichaud yes.  or the script should generate the makefile
20:13 pmichaud but having the hll implementor manually maintain the makefile is asking for lots of difficulties
20:13 allison I'm in favor of generating the makefiles, perfectly possible
20:13 allison but, then we have some makefiles generated by Parrot and some not
20:14 pmichaud well, that's why I think the tool should just do the compilation oughtright.
20:14 pmichaud *outright
20:14 pmichaud it's not too much of a stretch to think of  pmc2c as becoming   pmc2lib
20:14 pmichaud or something that directly compiles *.pmc files into the library form.
20:14 allison that is what the old tools did, but they kept getting the dependencies wrong, because they were a perl script trying to act as a Makefile
20:15 pmichaud I'd say to fix the old tools then (more)
20:15 pmichaud in particular, I don't see an advantage to breaking up the .c .o .lib dependencies
20:15 allison that's the way makefiles work
20:15 pmichaud but they don't have to
20:15 pmichaud (more)
20:15 allison each file generated is a target, so it can check if it's changed
20:16 pmichaud it's perfectly possible to write a target that goes completely from .pmc to .o
20:16 pmichaud without having to write the intermediate target for .c
20:16 allison yes, but that's a bad makefile, it has to recompile from source every time
20:16 pmichaud isn't that the case anyway?
20:17 allison if the .o file hasn't changed since the last compilation, it doesn't have to recompile it to build the .lib
20:17 pmichaud right, but the dependency for the .o can be the .pmc file, not the .c
20:17 Zak joined #parrot
20:18 allison sure, it can
20:18 pmichaud speaking from an hll perspective at the moment, though, I think I'd rather have a change to a .pmc cause recompilation of all files than to have to worry about managing many individual dependencies myself
20:18 pmichaud especially if/when I have .pmc files that depend on other PMCs, and those have to be linked properly.
20:18 allison so, you'd write your makefiles that way
20:19 pmichaud the issue is that writing those makefiles is very prone to error at the moment.
20:19 allison that's the advantage of leaving languages free to write their own
20:20 allison it's a choice between freedom and the ease of a blackbox
20:20 pmichaud right now compiling ".pmc" files feels like it ought to be a blackbox
20:20 pmichaud I don't see where making it non-blackbox provides any real advantages to hll implementors.
20:21 allison I suspect we'll never write tools that satisfy every language implementor, but I still think it's worth providing tools to make it easy
20:21 pmichaud right.
20:21 allison easy for the default case
20:21 japhb allison: Does it need to be a choice that Parrot makes?  If Parrot provides the blackbox tool, then the HLL can use it ... or not, if they want to Makefile-to-the-metal
20:21 pmichaud so I'd like a tool that makes pmc and ops generation simple
20:21 japhb nod
20:21 allison then I'd go for a makefile generator tool
20:21 pmichaud much like what we have now in the build tree that Rakudo is using
20:22 allison you never have to look at the makefile if you don't want to, it'll just be generated for you
20:22 pmichaud in current Rakudo trunk, it's nice because we just list the *.pmc files in our Makefile and the libraries get compiled automatically
20:22 allison but, it's there if you want to modify it
20:22 pmichaud we don't have to deal with any separate makefiles at all
20:22 allison pmichaud: aye, that's the old tools, but they will never work from an installed parrot
20:23 pmichaud i.e., Parrot (build) provides tools to go directly from .pmc to *.so
20:23 pmichaud can we make tools that would work from an installed parrot?
20:23 allison now
20:23 allison no
20:23 pmichaud why no?
20:23 allison they're a perl script that's template generated using hard-coded build paths
20:23 allison okay, there's one way you could save it
20:23 pmichaud can we make a perl script that doesn't have hard-coded build paths?
20:24 allison do the template generation of the perl script in Rakudo, instead of in Parrot
20:24 allison pmichaud: not in Parrot, no
20:24 pmichaud allison: why not?
20:25 allison clarify: someone could write a script like that, yes, but they wouldn't be using any of the existing code
20:25 pmichaud presumably they would re-use pmc2c.pl and ops2c.pl (the libraries), though, yes?
20:26 allison and, adding more magical, blackbox, unmaintainable perl scripts is really undesirable at this point
20:26 pmichaud let me try this approach
20:26 pmichaud (writing nopaste)
20:27 allison pmichaud: well, no, I mean the original was just calling those scripts
20:27 allison pmichaud: see tools/build/dynpmc.pl
20:27 allison pmichaud: it really was literally a Makefile written in Perl
20:27 allison pmichaud: entirely unnecessary, and buggy as heck
20:28 nopaste "pmichaud" at 72.181.176.220 pasted "ideal makefile entries for dynops and dynpmcs" (5 lines) at http://nopaste.snit.ch/17071
20:29 pmichaud ideally that's what I think what a hll implementer should use to compile dynops and dynpmcs
20:30 allison how is pmc2lib supposed to figure out what the individual pmcs are?
20:30 pmichaud so that if I have a new .pmc file, I just update PMC_SOURCES and then "make"
20:30 pmichaud because the individual pmcs would be given by PMC_SOURCES
20:31 nopaste "NotFound" at 213.96.228.50 pasted "Patch for TT #794: fix and test" (68 lines) at http://nopaste.snit.ch/17072
20:31 NotFound Is that tne intention of the ticket?
20:31 chromatic Looks right to me, NotFound.
20:32 allison pmichaud: what about additional C dependencies?
20:32 pmichaud allison: I haven't run across those yet (more)
20:32 pmichaud I admit that they may occur.  But thus far in Rakudo we haven't run across them nor do we expect to anytime soon.
20:32 jonathan allison: buggy as heck? It's been building Rakudo's dynpmcs for months...
20:32 allison pmichaud: I'm trying to be convinced, I just can't see that pouring the effort into writing pmc2lib is worth it to avoid a simple makefile
20:33 pmichaud allison: I'd agree if the makefile were simple.
20:33 pmichaud The makefile is not simple.
20:33 pmichaud The makefile is quite complex.
20:33 allison jonathan: look back over tickets that tried to change it in any way, it's ossified
20:34 allison pmichaud: aye, but the makefile is also formulaic, it can be generated
20:34 Tene pmichaud: can you show what the makefile needs to look like without pmc2lib?
20:35 pmichaud Tene:  http://code.google.com/p/partcl/source​/browse/trunk/config/makefiles/pmc.in
20:35 Tene Coke++
20:36 chromatic That could be simpler with rules for .pmc .c and .dump files... except that the rules for .c files there might conflict with the rules for .c files elsewhere.
20:36 allison pmichaud: that is, I could give you a similar script to call in the config file "$tools_dir/pmc_makefile" passing it the same list of *.pmc files and the desired directory name
20:36 NotFound Can I commit that right now, or it risk to break something in some HLL?
20:37 pmichaud there's also the issue that some .pmc files depend on others
20:37 pmichaud which the makefile for tcl doesn't seem to illustrate
20:37 allison though, what do we do when some languages are using the Perl .pmc generator while others are using the PCT-based one?
20:38 allison if it's all central, it's harder to make the migration optional
20:38 allison (or gradual)
20:39 pmichaud Rakudo's ins branch attempts to simplify what tcl did a bit:  http://github.com/rakudo/raku​do/blob/ins/build/Makefile.in
20:39 pmichaud (line 365)
20:39 pmichaud (actually, lines 365-372)
20:42 allison pmichaud: that looks good
20:42 pmichaud except I don't like the *.c  (might not be portable)
20:42 pmichaud and it fails on certain platforms, as described by adougherty++
20:43 pmichaud because the LD_OUT macro doesn't expand properly on certain systems
20:43 pmichaud and LIBPARROT doesn't properly handle the #IF(parrot_is_shared) option that tcl is using.
20:44 allison on LD_OUT: aye, that's usually why we end up using the simplest possible Makefile syntax
20:45 pmichaud I'd prefer to be able to create Makefiles that didn't require the special  #IF(...)  preprocessing.
20:46 allison conditionals are useful in makefiles
20:46 allison and, it doesn't really provide good syntax for them internally
20:47 pmichaud right; the code that Parrot's makefile generator uses for handling conditionals feels bletcherous to me, though.
20:47 Tene *obviously* we need a Parrot-hosted 'make' replacement.
20:47 japhb Tene, Coke: How does this look?  https://trac.parrot.org/parr​ot/wiki/HllInteroperability
20:47 pmichaud Tene: I disagree with that.
20:47 Tene pmichaud: Yes, so do I.  I was trolling. :)
20:47 japhb The "General Issues" is an inline query, and the "Known Workarounds" is hand-edited
20:48 allison pmichaud: no arguments here, but does that mean we throw it out or fix it?
20:48 Tene japhb: nice. :)
20:48 chromatic You don't think this whole system is bletcherous?  (more)
20:48 allison pmichaud: another rhetorical question
20:48 allison pmichaud: we need conditional makefiles for Parrot, and they aren't going away
20:48 chromatic We use a Perl 5 system to write and run C code to probe system capabilities, then write a Makefile which calls Perl 5 code to run a C compiler and linker to build Parrot and Parrot extensions.
20:49 pmichaud allison: yes, but you're also saying that every hll needs conditional makefiles.
20:49 dalek tracwiki: v9 | japhb++ | HllInteroperability
20:49 dalek tracwiki: https://trac.parrot.org/parrot/wiki/HllIn​teroperability?version=9&amp;action=diff
20:49 allison pmichaud: so, we will have to fix the processing. That doesn't mean every hll has to use it.
20:49 pmichaud hll's have to do something to be able to handle those conditions, though, yes?
20:49 pmichaud i.e., they might not use conditional make files, but they have to implement their own equivalent mechanism for handling it?
20:50 allison hmmm... well, I'll go so far as saying building C code using Parrot will always require knowing whether parrot is shared or static, yes
20:51 pmichaud it's more than that -- the ops generation requires knowledge of all of the available runcores
20:51 allison that too
20:51 pmichaud which means that when Parrot gets a new runcore, I have to update my Makefile
20:51 allison or, rerun the script that generated the makefile
20:52 allison which should probably be run as part of Configure.pl
20:52 pmichaud and then re-apply any local patches I had made
20:52 Tene allison: pynie isn't even using a makefile... would pynie just have to reimplement everything?
20:52 allison Tene: yup, pynie uses python build infrastructure
20:52 Theory joined #parrot
20:52 Tene So Parrot just wouldn't offer anything here to pynie, with your scheme?
20:52 allison Tene: it'll likely eventually use autoconf
20:53 pmichaud I'll be curious to see pynie make use of dynpmcs and/or dynops :-)
20:53 allison Tene: aye, so you can see why I'm less inclined to favor the "centralized language build infrastructure"
20:54 allison pmichaud: it's just a simple series of calls to scripts and c compilers
20:54 Tene Hmm, okay.
20:54 allison any build system can do it
20:54 pmichaud I'm not at all claiming that parrot should centralize the entire build.  I'm simply saying we should give a slightly higher level of abstraction for dynpmcs and dynops
20:55 allison it just strikes me as a difficult solution to a simple problem
20:55 dalek rakudo: fbc5428 | jnthn++ | src/ (6 files):
20:55 dalek rakudo: Factor out type check error generation to one place and use it consistently. There are improvements we need to do to the reporting, but at least now we need to fix it in one place and the errors will now all consistently contain the type we got and the type we expected.
20:56 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​bc5428f2e6c702202df76d82430df5a32f65fc1
20:56 pmichaud allison:  fair enough (more)
20:56 allison I wouldn't object if someone wants to write it, but there are other places I'd rather see the effort go
20:56 pmichaud I think we're in agreement there (more)
20:56 pmichaud it sounds like you're not unalterably opposed to it, but you're not wanting to dedicate resources to it when there are other priorities
20:57 pmichaud I can't disagree with that
20:57 pmichaud I don't disagree with that
20:57 mikehh allison: make html - Failed to process docs/book/draft/ch03_pir.pod.
20:57 chromatic The sooner we can stop writing ops and PMCs in C, the sooner this problem goes away.
20:57 allison mikehh: thanks, will fix
20:58 pmichaud so while I'd like to see something cleaner, I'm not personally wanting to dedicate a lot of time to it either, which means we should leave things as they are now (even if somewhat more painful for makefile management in hlls) and focus on other priorities.
20:58 allison pmichaud: I guess at this point what I'd say is to think about modularity as you switch Rakudo off the old tools
20:58 allison pmichaud: whatever you develop may get "cannonized"
20:58 allison er, canonized :)
20:58 pmichaud allison: that's exactly how I was thinking.
20:58 pmichaud which is why I didn't like the possibility of canonizing the ugly makefiles.
20:59 pmichaud I also didn't want to complicate the gen_makefile.pl script that Rakudo uses with conditional handling, but it looks as though I will have to do that.
21:00 pmichaud either that or we get Rakudo to use Parrot's gen_makefile.pl script.... but that's just putting a different parrot dependency in place.
21:00 pmichaud (i.e., building Rakudo would still depend on a parrot tool)
21:00 allison yeah, it's a tossup there
21:01 pmichaud so I think the answer to your earlier question is that we have to "fix conditional handling of makefiles"
21:01 allison it's a pretty light tool, but it does use some Perl libraries from Parrot's build system
21:02 pmichaud I was hoping to avoid that, but the only other option is to make it possible to create dynops and dynpmcs w/o conditionals (which doesn't seem likely at this point)
21:02 allison is that something we could get a volunteer working on? or do you have a pretty clear idea how to fix that chunk of code?
21:03 pmichaud ideally I'd want a gen_makefile.pl to not have any dependencies on the Perl libraries in Parrot's build system
21:03 pmichaud or, if we expect hll implementors to be using Parrot's copy of gen_makefile.pl, then we should put it on a deprecation cycle and document its API
21:04 pmichaud we also need to document and explain the pmc2c and ops2c scripts.
21:04 pmichaud (and they need to be on the deprecation cycle as well)
21:04 allison mmm... in that case, I'd just update your gen_makefile.pl
21:05 allison and we can review it as a candidate replacement for the existing gen_makefile.pl
21:05 allison though, the existing one is just a few lines long
21:06 pmichaud okay, so planning (more)
21:06 allison and has the advantage of not duplicating code (even if the code it's not duplicating is kind of ugly, at least it's ugly once instead of ugly twice)
21:06 pmichaud I'm probably not going to want to switch rakudo to using Parrot's gen_makefile.pl, for the modularity issue you mentioned above (and other reasons)
21:06 pmichaud so, I'll look into updating Rakudo's makefile generation (and its tool)
21:07 pmichaud but I'd really like to see that Parrot's build/install layout get cleaned up first
21:07 pmichaud so that we're not having to do a bunch of conditionals along the lines of "if this is an install, do XYZ, otherwise do ABC"
21:08 allison I don't have a list of where all those differences are
21:09 allison but could probably find them pretty quickly trying to build Rakudo off an installed Parrot
21:09 pmichaud I think if we just take the approach of having Parrot's "make" put everything into an install-template
21:09 pmichaud then we'll remove the differences in the first place
21:09 pmichaud at least, we'll remove the bulk of them.
21:10 pmichaud currently the "ins" branch in Rakudo is able to build Rakudo from an installed parrot, but the fakecutable still depends on the build tree being present
21:10 amuck_ joined #parrot
21:10 pmichaud (like Tcl, though, the "ins" branch can only build from an installed parrot -- it's not possible to build Rakudo from a build-copy of parrot)
21:11 Whiteknight joined #parrot
21:12 allison yes, the fakecutables still don't work without the build directory
21:13 allison pmichaud: we're basically looking at something like the DESTDIR option being turned on all the time
21:13 zak_ joined #parrot
21:14 allison or, 'make disttest'
21:17 spinclad 'make build; make DESTDIR=<build> test' v. 'make build; make install; make DESTDIR=<install> test'
21:19 spinclad and at some stage one can check, with strace or such, that all component accesses look to the right DESTDIR.
21:19 abesapien joined #parrot
21:20 pmichaud anyway, as a general item I should probably note that my tuits for parrot core development are likely to be somewhat limited for the next few months.  My Hague grant has been starved for resources while I've been dealing with install/build/packaging/other issues in Rakudo, and I need to get moving on the Hague grant (because without it I have no income at the moment).
21:21 Util pmichaud: [nopaste 17070] Besides changing `git@` to `git://` in the `git clone`, I followed your instructions exactly, on both Darwin and Linux.
21:21 Util All three tests report `ok` in  `./perl6` and `parrot/parrot perl6.pbc` runs of t/01-sanity/07-isa.t, on both systems.
21:21 Util Further info: on Darwin, `make spectest` only fails t/spec/S12-enums/basic (Failed test:  27) and t/spec/S32-num/rand (Parse errors: Bad plan.  You planned 110 tests but ran 106.)
21:21 Util Linux `make spectest` has not completed.
21:21 Util Cannot proceed with investigation :(
21:22 pmichaud Util: what Linux?
21:22 purl Linux is linux is linux by another name. or 80% of the world's top 500 super computers right now and the number one embedded system http://broadcast.oreilly.com/2008/10​/how-linux-supports-more-device.html
21:23 pmichaud (tuits)  I do still expect to be able to complete the hll-interop items, as they directly affect Rakudo, but troubleshooting install/core issues may be more difficult for me to come by.
21:23 Util pmichaud: Mandrakelinux release 10.1 (Community) for i586
21:23 Util Linux version 2.6.8.1-10mdksecure (nplanel@n3.mandrakesoft.com) (gcc version 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)) #1 SMP Wed Sep 8 16:46:40 CEST 2004
21:24 pmichaud util:  okay, I'm on kubuntu 9.04 (i386)
21:24 pmichaud I'll try on 64-bit just to see if I get anything different.
21:24 pmichaud I'm not sure what masak++ is running, but he noticed similar errors today.
21:25 jonathan allison: Are you currently expecting to have some Parrot-y meetup in the day or two after YAPC::EU?
21:25 jonathan allison: Basically it's easy for me to be there on the Thursday, and a little less convenient but possible for me to be there on the Friday.
21:26 jonathan But I need to find/book a flight, so would be good to have an idea.
21:28 pmichaud Util: can you verify the revision of Parrot that you got?   parrot/parrot_config revision
21:29 Util pmichaud: 39846 on both Darwin and Linux
21:29 pmichaud okay.
21:29 pmichaud I'm stumped, then.
21:29 pmichaud let me see if I can duplicate on another platform somewhere.
21:33 pmichaud Util:  on my 64-bit box (using the git://... address) it compiles and runs fine.  Let me try again on my 32-bit box.
21:34 nopaste "mikehh" at 86.150.205.31 pasted "codetest failure from make fulltest at r39847" (29 lines) at http://nopaste.snit.ch/17073
21:35 nopaste "mikehh" at 86.150.205.31 pasted "PATCH for codetest failure at r38947" (17 lines) at http://nopaste.snit.ch/17074
21:35 mikehh codetest passes with the patch
21:36 chromatic +1 on the patch
21:38 Infinoid mikehh: Thanks, applied as r39849
21:38 dalek parrot: r39848 | Infinoid++ | trunk/t/op/integer.t:
21:38 dalek parrot: Apply integer.t_to_pir.patch from flh++ in TT #796.
21:38 dalek parrot: * Convert t/op/integer.t to PIR
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39848/
21:38 dalek parrot: r39849 | Infinoid++ | trunk/docs/book/pir/ch06_subroutines.pod:
21:38 dalek parrot: Apply patch from mikehh++:
21:38 dalek parrot: PATCH for codetest failure at r38947
21:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39849/
21:39 allison jonathan: yes, thursday sounds good
21:39 amuck__ joined #parrot
21:40 allison jonathan: my schedule is pretty flexible, but it's likely that I'll want to get on the road Friday too
21:40 dalek TT #796 closed by Infinoid++: Rewrite globals.t and integer.t in PIR
21:41 jonathan allison: OK, that's helpful to know.
21:41 Whiteknight Infinoid: what do we need to do to get io_cleanups knocked out? I feel like you have a better idea about what needs to be done then I do
21:41 jonathan allison: I'll be around all conference too; I'm sure there'll be some degree of hallway track. :-)
21:41 jonathan I'll probably arrange to head off on Friday too.
21:41 allison pmichaud: yes, that's reasonable. Fortunately I'll have a pile more time for Parrot core starting in late July
21:42 allison jonathan: I may be doing all hallway track at YAPC::EU
21:42 jonathan allison: Sure. I'll probably just take things as they come...
21:42 allison jonathan: hmmm... are they doing hacking rooms again this year? that was very useful
21:42 Whiteknight (more time for Parrot core)++
21:42 Infinoid Whiteknight: Lemme swap that back into my poor little brain
21:43 jonathan allison: They may be, but I dodn't remember reading anything of that.
21:43 Infinoid Whiteknight: (I know the feeling, I haven't found any chunks of time for parrot greater than 5 minutes for the last week or more
21:43 Infinoid Whiteknight: )
21:44 allison jonathan: I guess it entirely depends on the space. Braga had great space for sitting out and hacking, Vienna less so, Copenhagen very little. It's an adventure. :)
21:44 jonathan :-)
21:45 * jonathan is looking forward to it.
21:49 pmichaud Util: now I find I'm unable to duplicate the error I was getting earlier.  I have no clue why.  Earlier I started from a completely fresh checkout as well.
21:50 * Whiteknight would love to make it to YAPC::EU sometime
21:54 pmichaud oh, wait, I might've tested the wrong one.
21:55 Infinoid Whiteknight: Ok.  To get this working, Pipe needs an additional ATTR to store a child process pid.  This should be initialized to -1 or some arbitrarily chosen win32-friendly value.  If the destroy() method detects a sane pid, it should call an OS-specific child process cleanup function
21:55 dalek tracwiki: v79 | whiteknight++ | WikiStart
21:55 dalek tracwiki: Add a link here to a page about installation. This may be the wrong page, somebody please correct me if so
21:55 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=79&amp;action=diff
21:55 Infinoid We don't have a Parrot_waitfor() but we might consider adding one for this
21:56 Infinoid rather, PipeHandle needs these things, not Pipe
21:56 Whiteknight okay, that all sounds reasonable
21:56 Whiteknight I wouldn't know how to write Parrot_waitfor(), would you know how to do that?
21:57 Infinoid yeah.  The relevant code is already there in src/io/unix.c and src/io/win32.c
21:57 Whiteknight oh, okay
21:57 Infinoid It's just terribly FileHandle-specific at the moment
21:57 Whiteknight what about other systems then, is there an equivalent for portable.c?
21:58 Infinoid I don't know.  I think fork() and pipe() are also missing in that case
21:58 Whiteknight ok
21:58 bacek_ joined #parrot
21:59 Infinoid oops.  s/waitfor/waitpid/
21:59 Whiteknight Infinoid: what should the type of this new ATTR be, PIOHANDLE?
21:59 Whiteknight because Win32 doesn't really have much notion of pids
21:59 Infinoid Sure it does, you can see them in the Task Manager if you enable that column
22:00 Infinoid Judging from Parrot_io_close_win32(), it looks like a HANDLE, so if that's what PIOHANDLE wraps, it should work fine
22:00 Infinoid INTVAL procid =  VTABLE_get_integer_keyed_int(interp, filehandle, 0);
22:01 Infinoid HANDLE process = (HANDLE) procid;
22:01 Infinoid WaitForSingleObject(process, INFINITE);
22:01 Infinoid that's beautiful.  HANDLE is a pointer, isn't it?
22:01 Infinoid CloseHandle(process);
22:02 Whiteknight well, let me rephrase that. Win32 has pids, but uses HANDLE to keep track of child processes
22:02 pmichaud Util: Just confirming that I'm unable to duplicate the errors I saw before.  I'll keep an eye out for the problem and let you know if they arise again.
22:02 mikehh smolder don't seem to be talking to me again
22:03 mikehh sorry it just responded
22:03 Infinoid Whiteknight: thanks, win32 confuses me :)
22:03 NotFound CreateProcess returns a handle for the process and other for his main thread. The thread handle is closed during open, for simplicity.
22:16 mikehh pre/post config, smolder, fulltest All PASS at r39849 - Ubuntu 9.04 amd64
22:16 Whiteknight Infinoid: how do we wait in Unix?
22:16 Whiteknight what's the equivalent to WaitForSingleObject?
22:16 Infinoid waitpid()
22:16 purl waitpid() is probably the way to go if you need to just hang around waiting.
22:17 Infinoid Parrot_io_close_unix() has the equivalent to the above code
22:17 Whiteknight do we have any test systems where the portable.c stuff is actually used?
22:18 Infinoid I don't know of any.  I've been wondering that for a while now
22:20 Infinoid If I understand correctly, portable.c is just stdio, but unfortunately, stdio is limited to simple file access, and doesn't try to handle child processes or sockets or pipes or threads, so we still need something OS-specific to handle those things
22:20 NotFound There is the popen call, but if a system has it probably also has fork and pipe.
22:21 Whiteknight okay, I have a commit coming through now that adds a child PIOHANDLE to PipeHandle
22:21 Whiteknight now we just need to find places to set this value (Parrot_io_open?)
22:21 Infinoid hmm, interesting.  the popen() manpage claims to be POSIXful
22:22 Infinoid PipeHandle.new() and overridden by Parrot_io_open_pipe_* I guess
22:23 dalek parrot: r39850 | whiteknight++ | branches/io_cleanups/src (2 files):
22:23 dalek parrot: [io_cleanups] add a child PIOHANDLE to PipeHandle PMC, to keep track of a child process that is attached to the pipe.
22:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39850/
22:24 Whiteknight you want to prototype something for it, or are you going to leave me to fumble around in the dark with it? :)
22:25 Infinoid heh, I've still got the editor window open with fixups for Parrot_io_open_pipe_unix
22:27 Whiteknight does it make sense to ever create just a PipeHandle, or do we always create an entire Pipe?
22:27 NotFound Are you planning to go to Lisbon? If you break my pipe implementation, I don't recommend you go to a place near me }:)
22:27 Infinoid creating a PipeHandle does not make sense, as it won't be connected to anything.
22:27 Infinoid hmm.
22:28 Whiteknight Okay, I'm trying to modify the logic in Parrot_io_open that creates a new FileHandle by default if a PMC is not provided
22:28 Whiteknight I want to create a Pipe instead then if the PIO_F_PIPE flag is specified
22:28 Infinoid I suppose you could optimize this case a little bit by only creating *one* of the PipeHandles yourself, if the other one will just be freed
22:28 Infinoid But in the open() case, the other side of the pipe is just gonna call exec() anyway, so I doubt it's worth the trouble of freeing it properly
22:29 * Whiteknight really needs to read this whole Pipe/PipeHandle implementation a little closer to figure out what is happening
22:29 Infinoid Pipe/PipeHandle are pretty basic, I think the real beef is in the pipe() manpage
22:30 Limbic_Region joined #parrot
22:30 Infinoid You're welcome to harass me if something doesn't make sense, though.  That would mean I haven't written enough documentation :)
22:31 Whiteknight okay, so what happens when I type "$P0 = open 'perl -v' "rp"'?
22:31 Whiteknight what type should $P0 contain, a Pipe or PipeHandle?
22:32 Infinoid $P0 will contain a PipeHandle
22:32 Whiteknight okay, so Parrot_io_open should open and return a PipeHandle?
22:33 Infinoid open() will internally create a Pipe, fork a child, extract the fd from one of the PipeHandles and use Parrot_dup() semi-blindly, hoping it ends up as stdin or stdout (I think that can be done a little more nicely) and exec the child process
22:33 Infinoid the parent process returns the other PipeHandle
22:34 Infinoid uh, all that extract/Parrot_dup stuff happens in the child process prior to calling exec().  My sentence making sk1llZ are full of fail today.
22:35 rg joined #parrot
22:36 Infinoid It's basically the same thing the existing code already does, we're just doing it with PMCs now
22:37 NotFound You can use dup2 instead of dup to make more clear the intention.
22:40 Whiteknight okay, I added basic support to Parrot_io_open for pipes, take a look at this next commit to makes ure it's sane
22:40 dalek parrot: r39851 | whiteknight++ | branches/io_cleanups/src/io/api.c:
22:40 dalek parrot: [io_cleanups] add basic preliminary logic to support for Pipes to Parrot_io_open. Probably doesn't work as-is
22:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39851/
22:43 Infinoid Oh.  Uh...
22:43 Infinoid I've just been hacking Parrot_io_close_unix() to return a PipeHandle directly, I haven't looked at Parrot_io_open() yet
22:43 Infinoid Looks like the flags handling stuff is going to need some help too tho, thanks for pointing that out
22:44 Infinoid uh
22:44 * Infinoid =~ s/Parrot_io_close_unix/Parrot_io_open_pipe_unix/
22:45 Whiteknight the logic in Parrot_io_open is a little lousy as-is, should probably refactor that function a little bit
22:46 Infinoid great.  I've been avoiding it until later because it looked complicated :)
22:46 NotFound Whiteknight: I had the idea of doing that, but left it when you started to talk about refactoring handles.
22:46 Whiteknight hey, don't let me stop you, feel free to jump in!
22:47 NotFound I'll think about that tomorrow, now I go to bed :O
22:48 Whiteknight NO BED! HACK NOW!
22:48 bacek_ Good morning
22:48 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
22:48 NotFound http://www.youtube.com/watch?v=56lF8E1psDU
22:48 Infinoid hai bacek_
22:48 bacek_ o hai, Infinoid
22:49 Infinoid <MCHammer> Stop.  Sammich time!
22:59 Zak joined #parrot
23:04 Whiteknight hey, we just had sammiches too!
23:06 Infinoid Sammiches++
23:06 Whiteknight actually, we've done sammiches two nights in a row now. BLT last night, chicken salad tonight
23:08 * Infinoid gets an ENOMOARSAMMICH and returns to hacking parrot
23:08 chromatic Honeymoon's over?
23:09 Whiteknight no, we've both just been craving sandwiches
23:09 Whiteknight plus we've gotten some really ripe tomatoes, so we put them on everything
23:09 skids joined #parrot
23:12 Infinoid even chicken salad?
23:12 Whiteknight hellz yes. I make the best chicken salad too, and we put all sorts of stuff into it
23:13 Whiteknight tonight we did celery, craisins, and tomato
23:13 Infinoid cool.
23:14 jonathan Mmmm...celery.
23:14 amuck joined #parrot
23:14 * jonathan hadn't been hungry until he just glanced at #parrot
23:14 Infinoid ok.  I just need to do the child process part and then I'll have a patch that probably crashes gloriously
23:15 snarkyboojum joined #parrot
23:16 Infinoid Do you happen to know if the IO PDD mentions anything about open() and pipes mucking with stderr?
23:16 Infinoid This code tries to direct both stdout and stderr to the pipe, which I'm not sure is common behavior.
23:17 Infinoid (I don't see anything, so I'm thinking about ripping it out)
23:25 patspam joined #parrot
23:25 NotFound joined #parrot
23:28 Infinoid My eternal glory is somewhat delayed by the fact that I can't figure out the right path prefix for including a pmc_*.h header
23:29 * Infinoid loves it when he forgets simple stuff like this. :)
23:29 Whiteknight I have no idea
23:29 Whiteknight chromatic: ping
23:30 Infinoid apparently when in src/io/, one must include "../pmc/pmc_foo.h"
23:31 chromatic pong
23:31 Whiteknight chromatic: about how many PMCs get allocated by Parrot on startup? have you seen any numbers like that in your profiling?
23:31 chromatic I can check quickly.
23:31 Whiteknight because it occurs to me that our initial mallocs should provide at least that many initially, so we don't run the GC on startup
23:32 chromatic 1147 to run "Hello, world" from PBC.
23:33 chromatic That's initialized PMCs.
23:33 chromatic 305 constant (a different pool).
23:33 chromatic 290 non-initialized PMCs (does not call VTABLE_init).
23:34 chromatic I don't expect a speedup making the initial arenas larger, though.
23:34 chromatic I'll give you a hint: free list.
23:34 Whiteknight if the initial arena is smaller, we have to do a full GC run first, then allocate a new arena, so I would expect some speedup
23:36 Whiteknight of course, it would be easy enough for me to test that...
23:36 chromatic A better speedup is not dumping everything from a new pool onto the free list first.
23:38 chromatic That means changing the code that grabs a new GCable to check the free list first, then if it's empty do a pointer bump in the fresh arena, and if it reaches the end, do a GC run.
23:40 nopaste "infinoid" at 173.75.243.238 pasted "[PATCH] [HALF-BAKED] This is the kind of thing I had in mind for child pipe creation" (127 lines) at http://nopaste.snit.ch/17076
23:49 Whiteknight chromatic: you're right, that's probably a good speedup too
23:50 Whiteknight that small algorithmic change might make for a great second core in the GC
23:50 Tene Whiteknight: your next big task is AIO, right?
23:51 chromatic Let's make that a second core so we can test it.
23:51 Whiteknight Tene: that's the plan, yes
23:51 Whiteknight chromatic: good idea
23:51 purl Whiteknight: Good Idea: Playing catch with your grandfather. Bad Idea: Playing catch >with< your grandfather.
23:51 Whiteknight I think we have a new hacker who's interested in helping out with GC too
23:52 Whiteknight haha! upping the initial allocation to 2048 PMCs sped up coretest on my system by 2 seconds
23:52 Whiteknight EAT THAT HATERS!
23:53 Infinoid haters?
23:53 purl i think haters is nom nom nom
23:53 chromatic Two seconds in coretest is noise.
23:53 Whiteknight yeah, I know
23:53 chromatic Mine varies anywhere between 40 seconds and 55.
23:57 davidfetter don't hate the parrot. hate the game
23:58 davidfetter player*
23:58 Whiteknight WHO HATES PARROT?!?!

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

Parrot | source cross referenced