Camelia, the Perl 6 bug

IRC log for #parrot, 2009-12-16

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 dalek TT #1371 created by carlin++: failed assertion 'PObj_is_PMC_TEST(obj)' doing IO from Rakudo
00:01 Tene anyone available for some git questions?
00:01 tetragon joined #parrot
00:02 japhb Tene, what's the question?
00:02 Tene japhb: possible to store acls in git?
00:03 japhb You mean, ACLs for the files?
00:03 Tene yes
00:03 Tene setfacl/getfacl
00:04 Tene My google-fu is failing me here.
00:04 japhb I don't know offhand, but there are a couple projects that have to do something similar, because they version secured trees.
00:04 japhb Give me a sec, lemme find some
00:07 japhb Tene, try taking a look at etckeeper
00:07 Zak joined #parrot
00:07 japhb http://kitenet.net/~joey/code/etckeeper/
00:07 Tene japhb: thanks
00:07 japhb That may also be a decent jump-off point for googling
00:18 lucian joined #parrot
00:24 eiro_ left #parrot
00:27 dukeleto Tene: did I here git question?
00:27 Tene dukeleto: the answer seems to be "git doesn't do that"
00:27 Tene storing file or directory acls
00:28 dukeleto Tene: aren't those OS-specific?
00:28 Tene kinda depends on how you look at it.
00:35 plobsing_ joined #parrot
00:39 dukeleto Tene: what depends? for example, do Linux ACLs work on freebsd?
00:39 dukeleto Tene: where are ACLs stored? in the filesystem?
00:39 dukeleto Tene: if the data is not in the file, it is not really git's problem
00:39 Tene acls are stored in extended attributes.
00:39 dukeleto Tene: it is a similar situation with svn:properties. they are outside the data of the file, so git-svn can allow you to read them, but there is no way to write to them from git
00:40 Tene So, same place as the permissions and ownership, approximately.
00:40 dukeleto Tene: where are extended attributes stored?
00:40 dukeleto Tene: i see, well them maybe git can get access to them
00:40 Tene Huh.  I thought that git didn't track ownership of files.
00:41 dukeleto Tene: if you ask the git mailing list about it, they might just actually implement it.
00:41 dukeleto Tene: git tracks the permissions. what do you mean about ownership? the user/group of a file? I don't think it stores that. maybe I am wrong
00:41 purl but it feels so right
00:41 dukeleto purl++
00:41 Tene Yes, user/group.
00:48 darbelo purl msg plobsing I think I found the root cause of your failure after I removed the packfile. Passing a NULL assumes that the data is in platform-native format. If you pass it a packfile it inspects the header to determine the actual format.
00:48 purl Message for plobsing stored.
00:50 darbelo purl msg plobsing We should probably revert it, as I can't think of a clean way to work around it.
00:50 purl Message for plobsing stored.
00:56 abqar joined #parrot
01:18 diakopter what's a dynamic pmc?
01:19 cotto_work diakopter, it's a PMC that's compiled into a shared library and loaded at runtime
01:19 cotto_work there are some in src/dynpmc
01:19 diakopter ok
01:20 diakopter must it be written to disk before it's loaded?
01:20 diakopter er
01:20 cotto_work I suppose it could be compiled into Parrot, which istr was the plan with the RTEMS port.
01:20 dalek tracwiki: v9 | cotto++ | CottoTasklist
01:20 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Co​ttoTasklist?version=9&action=diff
01:20 dalek tracwiki: v1 | cotto++ | TestingProfiling
01:20 dalek tracwiki: create a page to document the difficulties in testing the profiling runcore
01:20 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Test​ingProfiling?version=1&action=diff
01:22 diakopter is it compiled to C and then sent through gcc?  or to machine code?
01:22 diakopter (or pasm?)
01:22 cotto_work machine code
01:22 purl machine code is, like, a script for the CPU to follow
01:22 cotto_work the eventual plan is to have all PMCs and ops be written in Lorito, but that's a ways off.
01:23 diakopter what's Lorito? another assembly language?
01:23 cotto_work Lorito?
01:23 purl i think Lorito is "little parrot" in spanish or examples/embed/lorito.c
01:23 cotto_work L1?
01:23 purl well, L1 is a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550 or http://rt.perl.org/rt3/Ticket/D​isplay.html?id=39313#txn-471982 or magical unicorns and flying puppies.
01:23 cotto_work that one
01:24 purl hmmm... that one is fairly new
01:24 cotto_work (L1 is the old name)
01:24 Coke pbc?
01:24 purl well, pbc is an acronym for the parrot bytecode format
01:24 Coke pbc is also Pay By Computer
01:24 purl okay, Coke.
01:25 diakopter purl, purl is dead.
01:25 purl ...but purl is <reply> ♬ beat on the bot // beat on the bot // beat on the bot with a baseball bat// oh yeah ♬ or pretty stupid, aren't you or an annoying girl or a non-intuitive answering machine or just the most convenient random number generator or a maroon or triddle's favorite information slut...
01:25 diakopter no, purl is dead.
01:25 diakopter purl, no, purl is dead
01:25 purl okay, diakopter.
01:25 cotto_work purl, purl?
01:25 purl hmmm... i am dead
01:25 cbarrett joined #parrot
01:26 diakopter is someone working on a spec for L1/Lorito?
01:27 cotto_work diakopter, nope.  atm we're focusing on solidifying the foundation for Rakudo *, but I think it'll become a higher priority shortly after that.
01:27 diakopter or is it TAWP SCEEKRIT still.  oh.
01:27 cotto_work chromatic said that it'd be at a similar level to libjit
01:28 diakopter hm
01:28 Zak joined #parrot
01:28 * plobsing_ likes that idea... about as far as I can throw it
01:28 diakopter it must be a heavy idea..
01:29 plobsing_ nope, I'm just really bad at sports
01:29 cotto_work The idea is that once we can compile HLL code down to Lorito, we can write parts of Parrot in any HLL that compiles to Lorito.
01:29 cotto_work (well, one idea among several)
01:30 diakopter oh
01:30 diakopter Lorito would be the MSIL equivalent then, I guess
01:31 cotto_work That sounds about right.
01:31 cotto_work It'd be painful to write, but the majority of Lorito code would be generated anyway.
01:32 cotto_work (Lorito would sit below PIR, so existing PIR could would continue to run, oblivious to lower-level changes.)
01:36 cbarrett Why have two levels of abstraction? PIR and then another intermediate representation. Seems duplicative.
01:36 cbarrett (Not being aggressive, just curious)
01:38 bacek_at_work cbarrett, PIR is kinda macro assembler. A lot of syntax sugar, etc
01:38 cotto_work cbarrett, Lorito would be in there so we can avoid the expensive boundary between Parrot (PIR) and C calling conventions.
01:38 bacek_at_work Lorito is low-level ops. Think "RISC"
01:38 cotto_work hi bacek_at_work
01:38 bacek_at_work hi cotto_work :)
01:39 cbarrett So the idea is that you port Lorito to architeture X and then everything else rests on top of that
01:39 cbarrett which means Lorito will look pretty different from PIR
01:39 cbarrett (If so, that makes sense)
01:40 cotto_work cbarrett, kinda.  The idea is to make it easy to have multiple backends for Lorito (e.g. libjit, LLVM, straight C, a runloop, etc)
01:40 diakopter 3-operand?
01:41 cbarrett Right. Perhaps architecture was the wrong word.
01:41 cbarrett We're on the same page, I think.
01:41 cotto_work I think so.
01:41 cotto_work Hopefully it's the right one.
01:41 cotto_work diakopter, I suspect that's how it'll end up.
01:43 cbarrett cotto_work: If you think of Parrot as a PIR compiler, it makes (more) sense that Parrot would have an IR internally.
01:43 JimmyZ joined #parrot
01:43 diakopter my [limited] understanding of LLVM is that it's particularly good at optimizing HLL concepts/structures, like contexts, recursions, and closures...
01:45 cotto_work My understanding of LLVM is �.
01:45 diakopter so, I don't know how much gain could be had from emitting LLIR that was already essentially single-assignment
01:46 cbarrett diakopter: LLVM makes it easy to express those optimizations, I think. Particular the tools it gives you for building stuff in SSA form are neat.
01:47 cbarrett s/I think/as I understand it/
01:47 diakopter right, but if the Lorito language can't express those notions, they'll be compiled away already by the time it gets to LLVM..
01:48 diakopter will pointer arithmetic and jump to address by value be expressible in Lorito?
01:49 cbarrett diakopter: Yes, that's correct.
01:52 Coke japhb: you've been picked up.
01:52 cbarrett diakopter: Although it occurs to me that SSA form is not really an optimization, it's just a form that is easy to optimize.
01:53 cbarrett So emitting SSA'd code would simply allow LLVM's optimizer to do all the hard work.
01:53 cbarrett I don't really know how tightly coupled to LLVM you guys want to be.
01:55 cotto_work cbarrett, not very.  We don't want to be limited to the platforms supported by LLVM.
01:56 cbarrett Fair.
02:12 japhb Coke, excellent, thank you!
02:13 Coke japhb++ # np.
02:32 * Coke sighs.
02:33 kid51 joined #parrot
02:33 Tene Coke: looking at control shit now
02:33 Tene where are my headphones...
02:37 darbelo joined #parrot
02:45 Tene Coke: I can't reproduce it in nqp...
02:45 nopaste "tene" at 24.10.252.130 pasted "This outputs 42, as it should, Coke. Can you confirm?" (8 lines) at http://nopaste.snit.ch/19100
02:46 Tene now, rakudo does fail on it...
02:46 Coke parrot-nqp or parrot_nqp?
02:46 Tene ./nqp in the nqp-rx repo
02:47 Tene do you want me to check with one of those?
02:47 dukeleto 'ello
02:47 Coke ; I'm not using that. I'm using parrot. =-)
02:47 Coke I'll check in nqp-rx. moment.
02:47 Tene isn't that the nqp that parrot ships with these days?
02:47 Tene parrot-nqp gives the same result
02:47 Tene I don't have a parrot_nqp
02:48 Coke hurm.
02:48 Coke failed for me when I sent you the email. checking my example...
02:48 Tene Coke: that fails with *rakudo* thought
02:48 Tene though
02:49 Coke I originally had the problem in nqp, though.
02:50 Coke yah, I cannot duplicate it in nqp.
02:53 darbelo plobsing_: ping
02:53 Tene I feel weird patching rakudo master. >.>
02:53 Tene although it looks like ng gets it wrong too?  huh?
02:54 plobsing_ darbelo: pong
02:55 cotto Rakudo has bugs.  Ask masak.
02:55 darbelo I sent purl-msgs to your un-underscored alter ego. Did you see those?
02:55 plobsing_ some.
02:56 plobsing_ I am currently testing a revert of 43056,43057
02:56 Coke Tene: sorry about the confusion on my bug report.
02:57 Tene Coke: that's fine.  No problem.  Do you want rakudo fixed in master, or is just ng okay for you?
02:58 darbelo plobsing_: Cool. I'm on amd64 now, so I was about to try to reproduce the failures.
02:58 plobsing_ darbelo: However, I don't think this is a x-platform issue. When it has the pf, it reads as LE 8 (native)
02:58 plobsing_ I think the problem is in being lazy in the reading.
02:58 plobsing_ without the pf
02:59 darbelo It could be that too. I only looked inside PF_fetch_number()
02:59 plobsing_ In the grand scheme though, thaw should really take a PF as an argument to be able to thaw PMCs in non-native-encoded PBCs
02:59 Coke Tene: just ng is fine.
03:00 plobsing_ darbelo: IIRC, thats the only one that doesn't cause an error when passed null
03:00 * darbelo chuckles.
03:00 darbelo Figures.
03:03 darbelo I'm actually wondering if we should move to a Packfile PMC instead of a PackFile struct. There'll be a performace hit, since we'll be hoping the PIR/C barrier often, but it would give increased PIR-level functionality.
03:05 plobsing_ I breifly looked at that. I didn't see how to do low-level IO through the PMC version.
03:06 darbelo I think we could manage a RawPackfileSegment in the same way we now manage the buffer.
03:06 Tene purl: msg pmichaud should PAST::Op(:pasttype('try')) maybe have named arguments for exception types to handle? or do we just say "use .handlers() for that"?
03:06 purl Message for pmichaud stored.
03:07 Tene Coke: committed.  now looking at loops.
03:08 darbelo Granted, that's two extra GC-ables per frozen PMC, but I don't think it's a frequent enough operation to be worth worying about.
03:09 plobsing_ darbelo: if this code becomes useful, we might use it for other object graph traversals. that might increase the frequency
03:12 kid51 I will soon be applying this patch from JimmyZ:  http://trac.parrot.org/parrot/at​tachment/ticket/886/tt_886.patch
03:12 kid51 Any objections?
03:13 Coke I'd like one of the C developers to +1 that.
03:13 Coke +0 from me. =-)
03:13 cotto give me a few minutes
03:14 * JimmyZ couldn't find a scanner here. :)
03:14 kid51 There is also an associated patch in that ticket for Win32:  http://trac.parrot.org/parrot/attachme​nt/ticket/886/edited.tt_886_win.patch
03:14 cotto kid51, does it cause any new warnings or test failures, and what did you test it on?
03:14 kid51 I am currently running 'make test' on Linux/i386.  Results in a few.
03:14 darbelo kid51: The consting looks good, but I would use mem_allocate_n_typed.
03:15 Tene Coke: you'll like this... s/last/zomglol/ in your loop
03:15 Tene since you don't have ()s after it, it's not trying to *call* it, it's just doing a "get_hll_global" and then doing nothing with it.
03:16 Coke should you need ()'s for last?
03:16 Tene I don't know...
03:16 dalek parrot: r43079 | plobsing++ | branches/pmc_freeze_cleanup (2 files):
03:16 dalek parrot: Revert of r43056 and r43057. Apparently the Packfile is used for something after all.
03:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43079/
03:17 kid51 'make':  No difference in output with tt_886.patch applied on top of r43078 from 'make' output at r43056.
03:18 kid51 'make test':  PASS:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/30946
03:18 cotto I'd second darbelo's recommendation.  Other than that, +1 from me.
03:19 kid51 darbelo:  If you want to work on it, please discuss with Jimmy and post to ticket.  I'll hold off applying until this is resolved.
03:19 nopaste "tene" at 24.10.252.130 pasted "This works, fwiw" (16 lines) at http://nopaste.snit.ch/19101
03:19 kid51 cotto:  ditto, please post in TT.  thanks.
03:19 Tene Coke: check the paste for something that works.
03:20 cotto It's a pretty trivial change.  I can adjust and apply.
03:21 darbelo kid51: It's a cosmetic issue, it ends up #defined to what he wrote anyways. I give it +1.
03:24 Coke Tene: ok. I can construct something like that that fails, since that's pretty much what "break" is, and break doesn't work.
03:24 Tene purl: msg pmichaud Coke is wondering about next/last/redo in NQP... should nqp recognize those names in its grammar and generate PIR to build and throw the exceptions, or do we leave it up to nqp users to write their own last() functions, like http://nopaste.snit.ch/19101 (note: this requires you to call last(); instead of just last;)
03:24 purl Message for pmichaud stored.
03:24 Coke if you grab the latest partcl and try:
03:25 Tene building...
03:25 Coke partcl-nqp, that is;
03:25 Tene yes
03:25 Coke ./partcl t/cmd_break.t - you can see the mis.
03:25 Coke *miss
03:29 Tene do you have some kind of global error handler in compiled code?  you're calling back into the compiler here...
03:30 Tene looks like no
03:32 * darbelo sees INTVAL last_type
03:32 darbelo Do we really have to care if the previous PMC was of the same type here?
03:32 plobsing_ darbelo: its compression. not sure if it is good or not.
03:33 dalek TT #1367 closed by jkeenan++: [patch]changed codestring.pmc to use GET_ATTR syntax and consting
03:33 * kid51 must sleep
03:33 purl $kid51->sleep(8 * 3600);
03:34 darbelo plobsing_: Exactly. All of this code is full of small optimizations that I'm not sure are really still valid.
03:34 plobsing_ darbelo: if you have an array of the same type, you'd save N-1 INTVALs in the PBC
03:35 plobsing_ probably also true of hashes
03:35 plobsing_ with elements of only one type
03:36 darbelo I don't see too many of those around here.
03:37 plobsing_ Yeah, seems uncommon. I would remove, but it would change PBC
03:37 plobsing_ is changine PBC backwards incompatible change?
03:37 Tene Coke: adding a CONTROL block to your for builtin shows that the exception isn't making it through your eval stuff.
03:37 nopaste "tene" at 24.10.252.130 pasted "CONTROL for log patch for Coke++" (13 lines) at http://nopaste.snit.ch/19102
03:38 darbelo plobsing_: Not really. We just bump PBC_COMPAT and move on.
03:40 Coke Tene: odd; eval() doesn't have a try {}.
03:40 cbarrett joined #parrot
03:41 Coke looks like it ends with &sub(), which should throw the exception, yes?
03:41 Coke s/throw/pass through/
03:41 Tene yes
03:42 Coke wier.d
03:42 nopaste "tene" at 24.10.252.130 pasted "as it does here" (19 lines) at http://nopaste.snit.ch/19103
03:43 plobsing_ darbelo: wait, hold on a second. its type in the PMC type sense. In that sense all Objects are of the same type.
03:43 plobsing_ so an array of Object PMCs gets more efficient. that seems like it might come up quite a bit.
03:47 darbelo I thought it was getting set to vtable->base_type;
03:48 darbelo That's different for every PMC.
03:49 dalek parrot: r43080 | cotto++ | trunk (7 files):
03:49 dalek parrot: [misc] consting and various cleanups as part of TT #886, courtesy of JimmyZ++
03:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43080/
03:49 dalek parrot: r43081 | plobsing++ | branches/pmc_freeze_cleanup (3 files):
03:49 dalek parrot: Add {push,shift}_pmc ops to visit_info.
03:49 dalek parrot: these forward to visit_pmc_now for now.
03:49 dalek parrot: src/hash.c is an example use of this.
03:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43081/
03:50 plobsing_ darbelo: in general yes, but if the pmc passes PObj_is_object_TEST(), it gets set to enum_class_Object
03:51 plobsing_ so all objects are considered to be of the same type
03:52 darbelo That would be PMCs defined in PIR IIRC.
03:53 plobsing_ anyways, there's only one way to know for sure... rip it out and compare before and after.
03:53 darbelo That could have an impact in big arrays.
03:54 darbelo Yah, I'm looking for an example that execises this so I can callgrind it.
03:55 darbelo But this isn't heavily exercised code AFAICT.
03:56 patspam joined #parrot
03:58 theory joined #parrot
04:04 cbarrett left #parrot
04:13 Tene any other parrot or rakudo requests before I sign off for the night?
04:14 darbelo Ohh, config_lib.pasm looks like a very good test case for this.
04:16 darbelo A short run, and all it does is place a bunch of strings in a hash which is the frozen.
04:16 plobsing_ Strings or string PMCs?
04:17 japhb Tene, still here?
04:17 JimmyZ Tene: rakudo: my ($a, $b) = $b, $a doesn't work in ng.
04:17 darbelo It's all string literals in the source. I don't know if the Hash PMC autoboxes.
04:18 japhb Tene, if you're also doing NQP-rx, fat arrow => at least for function arguments would be nice.  ;-)
04:18 plobsing_ I think by default a hash's contents are assumed to be PMC
04:18 plobsing_ you have to ask for different behaviour
04:18 Tene yes.  working on Getopt::Obj now.
04:19 JimmyZ Tene:  ($a, $b) = ($b, $a) if ($b > $a);
04:19 Tene oh right, forgot about that, japhb.
04:21 japhb np!
04:21 darbelo "By default Hash uses string keys and PMC values."
04:21 dalek parrot: r43082 | japhb++ | trunk/compilers/data_json (2 files):
04:21 dalek parrot: [data_json] Working but possibly suboptimal fix for TT #1326
04:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43082/
04:22 dalek TT #1326 closed by japhb++: crow.pir is broken
04:23 plobsing_ side note, config_lib.pasm is a good place to use a Hash[String=>String]. Would probably save space, and definitely save gcables.
04:23 Tene okay, we just had a release, so I'm just going to commit this Getopt::Obj change, and everything in the parrot repo that's using it.  c thinks it counts as a bugfix, so no deprecation notice required.
04:27 darbelo Tene++
04:30 darbelo plobsing_: Well, on tha particular run callgrind's instruction coun reports a difference of 0.48%
04:32 plobsing_ darbelo: I don't think that's the metric that matters. What's the difference in sizes of fpmc produced? Thats what's being optimized for.
04:34 Tene japhb: gimme a quick test for fatarrow.
04:35 darbelo plobsing_: True, but I wanted to see if the performace changed at all. I'm measuring space next.
04:36 Tene japhb: my tests seem to work... I'll commit it if you add a test for it to the nqp-rx repo
04:36 Tene japhb: committed.
04:36 dalek nqp-rx: 7c9ba0a | tene++ | src/NQP/ (2 files):
04:36 dalek nqp-rx: "Fat Arrow" named parameter passing syntax for japhb++
04:36 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​c9ba0a6615c9955dc808dcd36a7d7043aabc369
04:37 japhb .oO( Don't know if I even have an nqp-rx commitbit )
04:38 diakopter japhb: any of several folks can add you through the ircbot ui
04:38 dalek parrot: r43083 | tene++ | trunk (11 files):
04:38 dalek parrot: Fix Getopt::Obj to use a keyed namespace
04:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43083/
04:38 darbelo 32432 - 30160
04:38 purl 2272
04:38 darbelo as measured by "du -b"
04:38 diakopter not Tene though :)
04:40 darbelo I'm not sure I care for that space saving, really.
04:42 plobsing_ If it matters that much, it can always be redone
04:43 JimmyZ otto: ping
04:43 JimmyZ cotto: ping
04:45 cotto JimmyZ, pong
04:45 JimmyZ Could anyone tell me where is the function defined?  http://trac.parrot.org/parrot/brow​ser/trunk/src/pmc/class.pmc#L1773
04:46 cotto Without looking, I'd guess that it's invalid code that gets silently dropped on the floor by pmc2c.
04:46 cotto I'll check.
04:46 JimmyZ cotto: Does it call STATICSELF.remove_method ?
04:47 cotto JimmyZ, yes.  I was wrong in my guess.
04:47 cotto I'd never seen that VTABLE function before.
04:48 cotto It's the same as any other VTABLE function call.
04:48 JimmyZ cotto: I am trying to change them to use static function instead of pmc->vtable->foo().
04:50 cotto That will work within a single file but I intentionally removed that functionality a while ago to reduce the number of symbols that libparrot needed to expose.
04:50 cotto (at chromatic++'s recommendation)
04:50 JimmyZ cotto: STATICSELF.remove_method is works well in pmc now.
04:51 JimmyZ cotto: s/is//
04:51 JimmyZ cotto: Does it not recommend?
04:52 cotto I don't know either way/
04:52 cotto s?/??
04:53 cotto I'd submit a tt about it.
04:53 JimmyZ cotto: I think use static function within a single file always be recommendatory
04:53 cotto My only concern would be subclasses of Class, but I don't know if that would make sense.
04:54 dalek parrot: r43084 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
04:54 dalek parrot: headerizer + codingstd updates
04:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43084/
04:54 JimmyZ cotto: yep
04:55 cotto It's nice to see our sanity injection framework (a.k.a. plobsing) at work.
04:55 cotto plobsing++
04:55 Tene any other requests before I'm done for the night?
04:56 cotto make Parrot faster than the jvm
04:56 darbelo Yeah, now I can look at this file without my eyes bleeding. plobsing++ indeed.
04:56 JimmyZ cotto: My only concen would be reducing the useful codes from parrot and unifying the codes.
04:56 JimmyZ cotto: ;)
04:56 JimmyZ cotto: s/useful/unuseful/ :)
04:57 cotto ok.  Dead code elimination is a good goal.
04:57 cotto It's nice not to have to take a little extra time to figure out that a bit of code is useless.
04:58 JimmyZ cotto: i.e. when it can use STATICSELF.foo(), I shouldn't let it use SELF.foo() or VTABLE_foo().
04:58 JimmyZ cotto: that is abount unifying.
04:58 cotto Sure.  That'll save us some pointer dereferences.
05:00 JimmyZ cotto: 'there is more than one way to do it' is perl's cultural. I don't think parrot has the same. haha
05:01 cotto Parrot doesn't need that.  That's an HLL philosophy.
05:01 cotto (which Perl 6 takes to dazzling and terrifying new heights, btw)
05:02 JimmyZ cotto: yep, so I'm reducing it in parrot.
05:02 Tene Okay, goodnight all.
05:02 cotto night Tene
05:02 JimmyZ Tene: good night.
05:02 cotto don't let the Parrot bugs bite
05:04 cotto maybe when you wake up there will be fewer of them
05:04 cotto or more
05:06 JimmyZ Is there a way to catch them?
05:07 dukeleto japhb++ # fixing crow.pir
05:07 japhb dukeleto, and now I already have my TT fix for the week.  ;-)
05:12 JimmyZ cotto: If I'm wrong, please warn me. thanks.
05:19 cotto pbc_dump makes me happy
05:21 darbelo cotto: How so?
05:21 cotto It makes it easier to figure out the packfile format
05:22 darbelo Wish I had known that two days ago.
05:22 cotto there's also pbc_disassemble
05:23 cotto darbelo, now you know
05:26 dalek parrot: r43085 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
05:27 dalek parrot: Remove the last_type member from the visit_info structure.
05:27 dalek parrot: This sligtly increases the size of 'frozen' agregates with many PMCs of the same type.
05:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43085/
05:28 JimmyZ hmm. SELF.foo() and STATICSELF.foo() is different, changing them maybe make test failed.
05:29 cotto yup
05:31 JimmyZ when it's only within METHOD and using PIR args flags(i.e. :optional), it's defferent.
05:32 JimmyZ Is it right?
05:33 pmichaud ...I'm a little surprised that r43083  (changing the Getopt namespace)  doesn't require a deprecation notice.
05:33 JimmyZ any other difference?
05:40 Coke pmichaud: ... it should.
05:40 Coke if it's a change and not an addition, that's going to break anyone using it.
05:40 darbelo pmichaud, Coke: http://irclog.perlgeek.de/p​arrot/2009-12-15#i_1841499
05:41 pmichaud yes, I read the backlog.  I'm still surprised.
05:41 Coke opening a itcket.
05:42 darbelo Oh, ok. FWIW we can still go with NotFound's idea of having duplicates.
05:43 dalek parrot: r43086 | darbelo++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
05:43 dalek parrot: Add _NULLOK() to an ARGIN macro and add a cast to pacify the compiler.
05:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43086/
05:43 pmichaud well, I expect nqp-rx and HLL::Compiler to totally not use Getopt::Obj anyway, so it's not a big deal to me.  I'm just surprised by it.
05:45 pmichaud afk # sleep time
05:46 Coke tt#1372
05:47 abqar joined #parrot
06:00 dalek TT #1372 created by coke++: r43083 breaks support
06:18 Tene pmichaud: according to chromatic it doesn't count because it's a bug.
06:18 Tene oh, yes, you read the backlog.
06:19 Tene pmichaud: PCT::HLLCompiler used it, fwiw
06:32 chromatic joined #parrot
06:55 particle1 left #parrot
07:08 bacek joined #parrot
07:10 dukeleto time to hack on tapir
07:14 dukeleto is http://trac.parrot.org/parrot/ticket/1372 about JSON vs data_json ? the TT is ambiguous
07:15 cotto clock?
07:15 purl cotto: LAX: Tue 11:15pm PST / CHI: Wed 1:15am CST / NYC: Wed 2:15am EST / LON: Wed 7:15am GMT / BER: Wed 8:15am CET / IND: Wed 12:45pm IST / TOK: Wed 4:15pm JST / SYD: Wed 6:15pm EST /
07:26 cotto are we there yet?
07:26 purl almost, it's just around the corner
07:26 cotto which corner?
07:26 purl which corner is that?
07:26 dukeleto who's on first?
07:26 purl okay, dukeleto.
07:29 JimmyZ where is purl?
07:29 purl i am probably dead
07:29 JimmyZ purl, are you dead?
07:29 purl jimmyz: i haven't a clue
07:30 JimmyZ purl?
07:30 purl yes, JimmyZ?
07:32 cotto purl, are you dead? is <reply>braaaaaiiiiiiinnnnnssssss
07:32 purl OK, cotto.
07:32 cotto are you dead?
07:32 purl braaaaaiiiiiiinnnnnssssss
07:34 dukeleto purl, what do you want for dinner?
07:34 purl dukeleto: bugger all, i dunno
07:34 dukeleto purl, you want brains for dinner
07:34 purl dukeleto: excuse me?
07:35 dukeleto purl, what is for dinner? is <reply>BRAAAAAAIIIIIIIIINNNNNNSSSS with a side of fava beans and a nice chianti
07:35 purl i don't know, dukeleto
07:36 dukeleto purl: i hate you
07:36 purl dukeleto: sorry...
07:36 * cotto kicks purl with an old botsnack
07:37 cotto night, bot abusers ;)
07:39 dukeleto botsmack
07:39 * purl shoots up... ahhh
07:41 dukeleto maybe this should be our new logo: http://www.bordom.net/view/30684/Honey_di​d_you_remember_the_parrot_?source=twitter
07:51 dukeleto japhb: is there something in plumage that can tell me if a binary exists in the current PATH? i remember something like that
08:02 bacek joined #parrot
08:02 bacek o hai
08:02 dukeleto bacek: howdy
08:02 bacek aloha dukeleto
08:03 * dukeleto is hacking on using distutils.pbc in Tapir
08:06 JimmyZ joined #parrot
08:10 dalek parrot: r43087 | bacek++ | branches/context_unify3/src (2 files):
08:10 dalek parrot: Remove setting of caller_ctx from Sub.invoke and op get_params.
08:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43087/
08:17 dukeleto hmmmmm, looks like distutils does not have a "pbc_merge" step
08:18 dukeleto msg fperrad does distutils have a pbc_merge step? should it? or should i define custom distutils step?
08:18 purl Message for fperrad stored.
08:25 iblechbot joined #parrot
08:33 * chromatic always likes seeing bacek delete code.
08:33 bacek chromatic, I hate code. Best program consists of zero lines of code and DTRT.
08:33 dukeleto bacek++
08:34 bacek btw, I just fixed "no such attribute" problem
08:35 chromatic That should reclaim a lot of tests.
08:35 bacek r43089
08:35 bacek Indeed.
08:35 chromatic r43088 looks a lot like something I mentioned....
08:36 chromatic I *think* there are a couple of places where we can't tell the difference between "I have a context" and "I have a call sig" where we used to be able to do so.
08:36 bacek chromatic, I suspect problem is in pushing initial context. But I didn't investigate it
08:37 chromatic That could very well be.
08:37 mikehh joined #parrot
08:37 bacek sigh... exceptions are badly broken...
08:37 dalek tapir: de92d4e | dukeleto++ | setup.pir:
08:37 dalek tapir: Start porting Tapir to use distutils instead of a Makefile
08:37 dalek tapir: review: http://github.com/leto/tapir/commit/de​92d4e40ccd08c2239ea82ac1c0ab7d26eed967
08:37 fperrad joined #parrot
08:37 dukeleto fperrad: hola!
08:38 dukeleto fperrad: i think i need a pbc_merge step in distutils
08:38 dukeleto fperrad: i have added a basic setup.pir to Tapir, but I need to merge some PBC's
08:40 bacek chromatic, hmm... "no such attribute" replaced with "Null PMC access in get_pmc()"...
08:41 fperrad dukeleto, I'll do it
08:42 chromatic I saw that in a few places, especially PGE.
08:42 dukeleto fperrad++ # you rock
08:42 dalek parrot: r43088 | bacek++ | branches/context_unify3/src/pmc/continuation.pmc:
08:42 dalek parrot: Band-aid wrongly created Continuation.
08:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43088/
08:42 dalek parrot: r43089 | bacek++ | branches/context_unify3/src/ops/object.ops:
08:42 dalek parrot: Merge CallSignature for tailcallmethod(cc).
08:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43089/
08:43 dalek tapir: 0ada11d | dukeleto++ | TODO:
08:43 dalek tapir: Update TODO
08:43 dalek tapir: review: http://github.com/leto/tapir/commit/0a​da11d6613858bc709bf13ae4f0d200593fe181
08:52 bacek chromatic, real problem is in lexicals.
08:52 chromatic How so?
08:52 bacek chromatic, I was wrong, sorry
08:52 bacek Parrot_mmd_sort_manhattan_by_sig_pmc
08:52 bacek Yay! Even easier.
08:52 bacek MustiSub wasn't updated
08:52 chromatic Excellent.
08:52 chromatic That'll reclaim a lot of PIR-only tests.
08:53 bacek dcommiting now
08:54 bacek done
08:55 bacek Time for exceptions.
08:56 chromatic You're a madman.
08:59 dalek parrot: r43090 | bacek++ | branches/context_unify3/src/pmc/multisub.pmc:
08:59 dalek parrot: Update MultiSub.invoke.
08:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43090/
08:59 dalek parrot: r43091 | bacek++ | branches/context_unify3/t/pmc/callcontext.t:
08:59 dalek parrot: Update CallContext test to use CallContext, not CallSignature
08:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43091/
09:04 moritz 'make coretest' seems to hang in context_unify3 somewhere
09:04 chromatic I saw that.
09:05 moritz but parallel testing is very ill suited for finding out which test hangs :/
09:05 chromatic We should review all uses of ->current_sig.
09:05 chromatic Let it go for about a minute (parallel tests take ~28 seconds for me), then killall parrot and see what prints.
09:05 chromatic It looked like t/op/calling.t or something for me.
09:06 JimmyZ chromatic: how to change http://trac.parrot.org/parrot/brow​ser/trunk/src/pmc/class.pmc#L1209 to use SET_ATTR syntax? it blocked me.
09:06 moritz t/op/exceptions_23.pir
09:06 moritz htop++
09:06 chromatic Looking now, JimmyZ.
09:07 JimmyZ chromatic: Thanks.
09:08 moritz the old-23 too
09:08 chromatic SETATTR_Object__class(interp, object, SELF);
09:08 chromatic You need 'include "pmc/pmc_object.h";' as well.
09:08 chromatic You can find the attribute macros in that file: include/pmc/pmc_object.h.
09:09 JimmyZ chromatic: src\oo.c:498: failed assertion 'classobj'
09:10 JimmyZ chromatic: it does like PObj_is_object_TEST(pmc) in SETATTR_Object_attr marco.
09:10 JimmyZ chromatic: s/does/doesn't/
09:10 chromatic That part should be fine, but it's probably the VTABLE_set_attr_str() part that hurts.
09:12 chromatic If that's the case, we can't do it many other ways... or any.
09:13 JimmyZ chromatic: How can I fix it?
09:14 chromatic You'll have to leave it for now.
09:14 chromatic It's not ideal.
09:14 JimmyZ chromatic: ok, thanks.
09:16 chromatic One option is to change Object.init_pmc() to take the class instantiating it.
09:16 chromatic That'd be cleaner, but I'd like to ask allison for her thoughts about such a change.
09:17 bacek moritz, I'm working on exceptions atm.
09:18 bacek Will fix soon (I hope)
09:20 moritz bacek: I'm not meaning to press you on, just wanted to tell about my experience
09:21 bacek moritz, no worries.
09:22 JimmyZ chromatic: actully, I always plan a better way than GET_ATTR syntax.
09:27 bacek chromatic, "BIG DEAL" - lexicals are bloody broken. Because we are not creating new CallContext in tailcalls anymore
09:28 bacek and Sub/LexPad/CallContext mixture doesn't work anymore
09:43 fperrad with Parrot-1.9.0 & mingw, cannot build Rakudo (master)
09:44 fperrad perl6_ops.o:perl6_ops.c:(.text+0x5d2d): undefined reference to `GETATTR_CallSignature_results'
10:40 payload joined #parrot
10:42 lucian joined #parrot
11:05 mikehh joined #parrot
11:09 dalek parrot: r43092 | fperrad++ | trunk/tools/util/pgegrep:
11:09 dalek parrot: Fix Getopt::Obj to use a keyed namespace
11:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43092/
11:35 mikehh cotto: I am getting a g++ build error related to r43080 as follows:
11:36 mikehh config/gen/platform/generic/exec.c: In function ‘INTVAL Parrot_Run_OS_Command_Argv(parrot_interp_t*, PMC*)’:
11:36 mikehh config/gen/platform/generic/exec.c:109: error: cannot convert ‘char***’ to ‘char**’ in initialization
11:37 mikehh I also get the following in the gcc build:
11:37 mikehh src/ops/core_ops_switch.c: In function ‘Parrot_DynOp_core_switch_1_9_0’:
11:37 mikehh src/ops/core_ops_switch.c:14014: warning: dereferencing type-punned pointer will break strict-aliasing rules
11:38 mikehh sorry wrong paste
11:38 mikehh config/gen/platform/generic/exec.c: In function ‘Parrot_Run_OS_Command_Argv’:
11:38 mikehh config/gen/platform/generic/exec.c:109: warning: initialization from incompatible pointer type
11:41 bacek joined #parrot
11:53 mikehh pre/post-config, smoke (#30954) PASS - fulltest FAIL at at r43092 - Ubuntu 9.10 i386 (gcc with --optimize)
11:53 mikehh t/examples/pir.t - Failed test:  2 in examples_tests
11:58 mikehh I think this is relatedf to the problem I outlined above - why it won't build with g++
11:58 mikehh got to go out for a bit - bbl
12:05 dalek parrot: r43093 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
12:05 dalek parrot: [distutils] add the key 'pbc_pbc' in order to support pbc_merge
12:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43093/
12:09 dalek tapir: e345edf | fperrad++ | t/harness.pir:
12:09 dalek tapir: Fix Getopt::Obj to use a keyed namespace
12:09 dalek tapir: review: http://github.com/leto/tapir/commit/e3​45edf3701da3906989445ab65e22b0698115ab
12:09 dalek tapir: c7b4f83 | fperrad++ | setup.pir:
12:09 dalek tapir: now distutils support pbc_merge
12:09 dalek tapir: review: http://github.com/leto/tapir/commit/c7​b4f836e83e3d63ad2307a8f2fd4c513ed9b78b
12:22 ruoso joined #parrot
12:34 nopaste "bacek" at 122.110.90.61 pasted "make coretest status on context_unify3 branch" (50 lines) at http://nopaste.snit.ch/19105
12:36 bacek At least it doesn't hang anymore
12:38 dalek parrot: r43094 | bacek++ | branches/context_unify3 (5 files):
12:38 dalek parrot: Made tailcall to push new CallContext instead of reusing old one. Apparently we need new CallContext to store LexPad information and other bits
12:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43094/
12:38 dalek parrot: r43095 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
12:38 dalek parrot: [distutils] escape JSON strings
12:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43095/
12:39 whiteknight joined #parrot
12:51 moritz do we know how good the parrot GC is? does it miss objects sometimes?
12:51 whiteknight it's possible that it's missing something if somebody has made major PMC changes recently
12:51 whiteknight why do you ask?
12:51 moritz just idle curiosity
12:52 moritz with the background of where to look if rakudo increases in memory
12:53 whiteknight Parrot's GC is generally very conservative. It has more false positives than false negatives
12:54 payload joined #parrot
13:06 nopaste "bacek" at 122.110.90.61 pasted "And more updates on context_unify3 branch coretest" (26 lines) at http://nopaste.snit.ch/19106
13:06 payload joined #parrot
13:06 bacek ok, I'm done for today...
13:06 bacek or even yesterday.
13:11 dalek parrot: r43096 | bacek++ | branches/context_unify3/src/ops/core.ops:
13:11 dalek parrot: Create CallObject for tailcall if it wasn't created early.
13:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43096/
13:11 dalek parrot: r43097 | bacek++ | branches/context_unify3/src/pmc/sub.pmc:
13:11 dalek parrot: Resurrect old core to setting caller_ctx in Sub.invoke.
13:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43097/
13:11 dalek parrot: r43098 | bacek++ | branches/context_unify3/tools/dev/mk_native_pbc:
13:11 dalek parrot: mk_native_pbc actually depends on make "corevm" target, not "all"
13:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43098/
13:11 dalek parrot: r43099 | bacek++ | branches/context_unify3/t/native_pbc (4 files):
13:11 dalek parrot: Rebuild native PBC.
13:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43099/
13:16 patspam joined #parrot
13:19 JimmyZ joined #parrot
13:20 bacek msg chromatic http://smolder.plusthree.com/app/pu​blic_projects/report_details/30968 - corotines are broken.
13:20 purl Message for chromatic stored.
13:21 bacek msg chromatic but it looks much better now.
13:21 purl Message for chromatic stored.
13:21 whiteknight bacek++
13:21 bacek whiteknight, not yet... make all still failing
13:21 whiteknight whatever, progress is progress
13:25 bacek anyway, $bedtime
13:25 bacek Good night, everybody
13:37 JimmyZ_ joined #parrot
13:45 fperrad whiteknight, I've seen a setup.pir in PLA, but not in matrixy
13:45 whiteknight fperrad: I may not have pushed it. I've been playing with it locally
13:47 fperrad does it work as expected ?
13:47 whiteknight yes. I have some local tweaks to make, but otherwise it's very good
13:49 plobsing1 joined #parrot
14:12 Coke dalek?
14:12 purl i guess dalek is #parrot's spammy little rss bot or (see: dalek plugins)
14:16 patspam joined #parrot
14:16 mikehh joined #parrot
14:16 dalek parrot: r43100 | coke++ | trunk/docs/project (2 files):
14:17 dalek parrot: Reflect community decision regarding 3-month supported cycle.
14:17 dalek parrot: Explicitly note the 'experimental' tag from Deprecated.pod
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43100/
14:17 dalek parrot: r43101 | coke++ | trunk/docs/project/support_policy.pod:
14:17 dalek parrot: One more historical note to avoid confusion.
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43101/
14:17 dalek parrot: r43102 | whiteknight++ | branches/context_unify3 (3 files):
14:17 dalek parrot: remove t/pmc/context.t. We no longer have a Context PMC so tests for creatingo one are bad. Fold tests into t/pmc/callcontext.t, though some are commented out for now
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43102/
14:17 dalek parrot: r43103 | whiteknight++ | branches/context_unify3/t/pmc/callcontext.t:
14:17 dalek parrot: uncomment the inspect tests. These should work in CallContext just like they did in Context (or functionality should exist in some way).
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43103/
14:24 payload joined #parrot
14:34 dalek parrot: r43104 | whiteknight++ | branches/context_unify3/t/pmc/callcontext.t:
14:34 dalek parrot: fix t/pmc/callcontext.t Context attributes are accessed by the getattribute opcode now, not named hash lookup. Hash lookup is for named arguments.
14:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43104/
14:34 dalek parrot: r43105 | fperrad++ | trunk (7 files):
14:34 dalek parrot: [befunge] update infrastructure with setup.pir (distutils)
14:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43105/
14:34 JimmyZ joined #parrot
14:34 dalek parrot: r43106 | whiteknight++ | branches/context_unify3/t/pmc/parrotinterpreter.t:
14:34 dalek parrot: ParrotInterpreter[context] returns an object of type CallContext
14:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43106/
15:22 dalek parrot: r43107 | fperrad++ | trunk (8 files):
15:22 dalek parrot: [abc] update infrastructure with setup.pir (distutils)
15:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43107/
15:29 jsut_ joined #parrot
15:36 bluescreen joined #parrot
15:37 Psyche^ joined #parrot
15:38 dalek parrot: r43108 | fperrad++ | trunk (8 files):
15:38 dalek parrot: [squaak] update infrastructure with setup.pir (distutils)
15:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43108/
16:06 bluescreen joined #parrot
16:13 payload joined #parrot
16:16 whiteknight purl msg bacek context_unify3: several files fail (debuginfo.t, file.t) because PDB_backtrace isn't printing out the "current instr.:" line, expected by pir_error_output_like. This fails because ctx->current_sub is Null there for some reason.
16:16 purl Message for bacek stored.
16:16 ruoso joined #parrot
16:21 * Coke whines.
16:23 Coke msg dukeleto does tapir support --exec ?
16:23 purl Message for dukeleto stored.
16:24 whiteknight Coke: I believe it does
16:24 whiteknight never tried it, but I saw it in the source code
16:26 moritz without it tapir would be pretty useless for HLL testing
16:27 Coke msg dukeleto nevermind, it does; looks like we could use tapir to test partcl then, if it were installable.
16:27 purl Message for dukeleto stored.
16:27 moritz pmichaud: is there a good reason why building nqp-rx in parrot depends on PGE?
16:27 Coke (works now if I copy in all the tapir bits into the partcl-nqp build dir)
16:27 darbelo joined #parrot
16:27 Coke moritz: I would not trust the makefile dependencies further than I could throw them. =-)
16:28 moritz that's why I'm asking
16:28 * Coke ponders working on his makefile sanity project.
16:33 moritz sanity++
16:35 dalek partcl-nqp: 3d9f9ff | coke++ | src/Partcl/commands/main.pm:
16:35 dalek partcl-nqp: make p6.vim happier
16:35 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/3d9f9ff8795f9e231aec4de2b15912b21647b2b3
16:36 Coke moritz++ # making irc logs searchable.
16:37 japhb dukeleto, (from last night): You need find_program() in src/lib/Util.nqp
16:39 pmichaud moritz: just forgot to remove that dependency
16:40 darbelo mikehh: ping
16:42 dalek parrot: r43109 | whiteknight++ | branches/context_unify3 (3 files):
16:42 dalek parrot: t/op/cc_params.t was looking for CallSignature, which doesn't exit. Replace references with CallContext and things work normally
16:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43109/
16:44 dukeleto japhb: thanks! japhb++
16:45 dukeleto Coke: yes, Tapir suppports --exec, right now
16:46 dukeleto Coke: Tapir is now semi-installable. a fakecutable can be generated
16:46 darbelo purl: msg mikehh Does r43110 fix the c++ issues tou were seeing?
16:46 purl Message for mikehh stored.
16:46 cotto mikehh, is your build still broken?  I tried realclean and the build was still ok.
16:47 darbelo cotto: I think he's building with g++, that means a mis-cast breaks the build.
16:48 darbelo we had one '*' too many in a mem_allocate_n_typed() call.
16:48 cotto ok.  I see how that happened.
16:49 darbelo I *think* it's fixed by r43110, nut my g++ is too ancient to build parrot.
16:50 nopaste "coke" at 65.91.151.194 pasted "pmichaud - stupid question time" (28 lines) at http://nopaste.snit.ch/19107
16:50 Coke dukeleto: the fakeceutable is not standalone.
16:51 dukeleto Coke: tapir currently uses a Makefile, but as soon as fperrad has pbc_merge support in setup.pir, it will switch over to that
16:51 Coke (it requires the lib dir.)
16:51 Coke I have no problem with requiring make. =-)
16:51 dukeleto Coke: i think i forgot to make the PBC's installable
16:51 dukeleto Coke: if you don't care about 3 files, just copying t/harness.pir and lib/Tapir/*.pir into your project should work
16:52 dukeleto Coke: and then invoke it as parrot t/harness.pir t/*.t
16:52 darbelo dukeleto: Have you considered getting Tapir imported into parrot?
16:53 whiteknight in general, I think it's better to keep it external
16:53 dukeleto darbelo: yes. it will probably happen this month. it will be an external like nqp-rx and live in ext/
16:53 darbelo dukeleto++ # Exactly what I had in mind.
16:53 dukeleto darbelo: it needs a few more rough edges polished, but is very close
16:53 nopaste "coke" at 65.91.151.194 pasted "pmichaud - two more examples" (8 lines) at http://nopaste.snit.ch/19108
16:54 cotto what are the g++ flags for Configure.pl?
16:54 dukeleto Tapir will also be installable via plumage soon, as well
16:54 whiteknight --cc="g++" --c++="g++" --link="g++" --ld="g++"
16:54 whiteknight At least, I think that will work
16:55 fperrad dukeleto, the support of pbc_merge is already committed in parrot & tapir
16:55 whiteknight --cxx="g++"
16:56 Coke tene; oh.
16:57 Coke Tene: I'm using CONTROL_ERROR; I probably expect that to be NOT a control-style, at least from NQP's standpoint.
16:58 fperrad japhb, Plumage is broken with the HEAD of parrot, see r43083 for fix example
16:58 japhb fperrad, I'm a little groggy
16:58 japhb what's going on now?
16:59 dalek parrot: r43110 | darbelo++ | trunk/config/gen/platform/generic/exec.c:
16:59 dalek parrot: Correct the allocation size an type for **argv.
16:59 dalek parrot: mem_allocate_n_typed already multiplies by the size and adds the extra * for us.
16:59 dalek parrot: This should fix the c++ build as well.
16:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43110/
16:59 cotto darbelo, thanks
16:59 dukeleto fperrad: wow!
17:00 japhb Sheesh, almost 30 revs since I went to bed?  Yikes
17:01 dukeleto fperrad++ # pbc_merge in distutils and Tapir. you rock!
17:01 fperrad japhb, see TT #1372
17:01 nopaste joined #parrot
17:01 whiteknight fperrad does rock
17:02 japhb definitely
17:02 japhb OK, read ticket.
17:03 japhb Now ... has a decision been made?  Are we rolling back 43083 or not?
17:04 pmichaud ...who gets to make that call?
17:05 japhb I have no idea.  We need some sort of ruling on whether Getopt::Obj was under protection
17:05 pmichaud I'm sure it technically was.  Any application or language that uses Getopt::Obj (and there are several) would be relying on its 1.4 behavior.
17:05 theory joined #parrot
17:06 pmichaud clearly it's one of the parrot libraries.
17:06 japhb Personally, I don't care, I just want to get back to working, so I need to know if I need to change my code or not.  ;-)
17:07 japhb It would be somewhat annoying that Plumage would cease to work with 1.9 so soon after release, but ... :-/
17:07 pmichaud japhb: that's normal.
17:07 pmichaud japhb: it's common for changes to occur shortly after release
17:08 japhb Yeah, I'm beginning to feel your pain, rather than just empathize with it
17:08 pmichaud or, put another way, what is in parrot HEAD is no longer 1.9
17:08 pmichaud 1.9 is what was released
17:08 pmichaud so, if you're asking if plumage works with 1.9, the answer is "yes"
17:09 Coke anything in library/ is covered, yes.
17:09 japhb pmichaud, no, I meant, "if we don't roll back, then Plumage will change to support HEAD, and thus plumage HEAD will not work with 1.9 anymore, only parrot HEAD"
17:09 Coke japhb: welcome to the club! =)
17:09 pmichaud oh, yeah.  Rakudo has exactly this problem, which is why we have PARROT_REVISION
17:09 japhb Coke, yup
17:09 pmichaud because it's never sufficient for us to say "1.9 or later"
17:09 japhb nodnod
17:10 japhb speaking of which ...
17:10 purl i think speaking of which ... is anyone working on dbdi?
17:10 japhb purl, forget speaking of which ...
17:10 purl japhb, I didn't have anything matching speaking of which
17:10 japhb purl, forget (speaking of which ...)
17:10 purl japhb, I didn't have anything matching (speaking of which ...)
17:10 japhb sigh
17:10 japhb Anyway,
17:10 Coke no, speaking of which ... is <reply>
17:10 purl okay, Coke.
17:10 particle i forgot to mention over the weekend or during parrotsketch... we might try to be coverity-defect-free by 2.0.  is it worth the effort?
17:11 Coke particle: I don't think so, no.
17:11 Coke that falls under "nice to have" for me.
17:11 pmichaud particle: if it didn't steal away from other tasks, perhaps
17:11 PerlJam particle: isn't that a transient thing anyway?
17:12 japhb At some point the HLLs will need to do something to make sure they all support the same parrot at the same time, like support revision ranges or something.  Because otherwise when Plumage tries to depsolve between all the HLLs to find a safe Parrot revision, it's going to come up with nada.
17:12 particle PerlJam: no, there are levels of coverity analysis, if we go defect-free, we advance to the next level of scan
17:12 PerlJam Or do you mean, be defect free for the release?
17:12 pmichaud in the realm of  "parrot runs faster"  versus  "coverity-defect-free",  it's no contest.
17:12 particle defect-free for the 2.0 release
17:12 dalek partcl-nqp: 4c8feef | coke++ | src/Partcl/commands/main.pm:
17:12 dalek partcl-nqp: Don't use a CONTROL type for [error]
17:12 particle pmichaud: correctness before speed
17:12 dalek partcl-nqp: This should avoid issues with using NQP's try {}.
17:12 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/4c8feef214ddc39a94cd186fcad662ca48f76e8f
17:12 dalek partcl-nqp: 6f81dc9 | coke++ |  (5 files):
17:12 dalek partcl-nqp: Allow expr's == to fallback to string comparision.
17:12 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/6f81dc9ed113f550da724a4a3a09754142619211
17:12 Coke japhb: ha. good luck. =-)
17:12 tewk_ particle, who is the coverity admin, can I get an id and passwd.
17:13 particle tewk_: i wish i knew, i've tried several times to get id/passwd, and just ended up borrowing whiteknight
17:13 Coke particle: if the HLLs are not triggering the code that coverity is testing, you're right, it's no contest.
17:13 pmichaud particle: that's a slightly different form of "correctness".  Or, put another way, glacial slowness is a form of bug.
17:13 tewk_ particle, I used to have one in the svn.perl.org days but I don't know what it was.
17:13 particle what the heck is wrong with static analysis?
17:14 particle anyway, there are only a few defects
17:14 particle i think we can achieve the next level, which would put us on par with perl and ruby
17:14 pmichaud japhb: (HLLs will have to support the same Parrot at the same time)   I think you're putting the responsibility in the wrong place.
17:14 japhb Coke: well, here's some ideas: 1. supported revision ranges, 2. tag or branch the HLL revision in a computer-identifiable way that works with a given Parrot release (so that Parrot releases can be safe sync points)
17:14 particle it says something good about the stability of the vm to achieve defect-free coverity scans
17:15 pmichaud particle: to me (as HLL developer), it means that we're targeting the wrong form of stability.
17:15 particle you'd rather be fast and have segfaults?
17:15 japhb (By 2., I mean "have the tag or branch name follow a pattern or formula that I can program into Plumage")
17:16 PerlJam japhb: and have that introspectable via parrot_config (if it's not already)
17:16 pmichaud particle: most of the effort that has gone into parrot over the past six months has been refactoring existing code to make it more stable.  meanwhile, little has been done to improve live for hll developers.  to me, that's the wrong priority at this time.
17:16 particle i remember when i replaced my 386/33 with a 486/66 how excited i was that i could crash windows 4x faster
17:16 pmichaud *life
17:16 pmichaud I'm not saying that segfaults are desirable, but at the same time, other critical parrot needs are going unaddressed.
17:16 Coke particle: we already have segfaults. being coverity clean in the past hasn't helped here.
17:16 particle pmichaud: i agree, but i don't think it's much effort to go defect-free, and it's a marketing win
17:17 Coke particle: then have fun. =-)
17:17 particle coke: we've never been coverity-clean
17:17 Coke ok. "addressing coverity in the past hasn't helped."
17:17 pmichaud particle: as I said, "if it doesn't steal away from other tasks, perhaps"
17:17 particle pmichaud: yes, i'm suggesting that might be the case.
17:17 pmichaud I'm not saying don't do it, I'm saying don't do it if it causes our ROADMAP items to suffer.
17:17 pmichaud I'm saying it's not at all a priority for Rakudo*, also.
17:17 particle otherwise, i agree, life for hll devs takes precedence
17:18 tewk_ fixing/reading coverity reports makes people better C / vm hackers.
17:18 pmichaud it's also been my strong experience that people going in and cleaning up parrot code have also made it slower, as well as broken our deprecation policy.  All of that makes things harder for hll devs too.
17:18 * Coke points to: http://trac.parrot.org/parrot/report/16
17:18 fperrad pmichaud, with Parrot-1.9.0, cannot build Rakudo (master)
17:18 fperrad perl6_ops.o:perl6_ops.c:(.text+0x5d2d): undefined reference to `GETATTR_CallSignature_results'
17:19 pmichaud fperrad: you probably need to do some realcleans somewhere
17:19 pmichaud fperrad: I tested it just a couple of hours ago and it worked for me
17:20 japhb Before these get lost:
17:20 fperrad pmichaud, I use fresh checkout when I work with a released Parrot
17:20 pmichaud ...fresh checkout of.... ?
17:21 japhb 1. It sounds like the Getopt::Obj change needs to be rolled back.  Can someone raise their hand to do that?
17:21 fperrad pmichaud, I want said checkout in new empty directory (not an update)
17:22 japhb 2. HLL developers: Would you be averse to tagging or branching a known good rev of *your* repository each month that works with the latest Parrot release?  (Kindof reversing the PARROT_REVISION semantics.)
17:22 pmichaud japhb: Yes.
17:22 japhb pmichaud, better suggestions then?
17:22 pmichaud japhb: I am adamantly opposed to limiting my development to the latest Parrot release.
17:23 japhb pmichaud, no, no, just giving some way for Plumage to find *a* rev (other than HEAD) that works with the latest parrot rev.
17:23 pmichaud japhb: I'll put it another way.  Given that new changes land shortly after a parrot release, I'm opposed to waiting four weeks to even begin to think about making use of those changes.
17:23 payload joined #parrot
17:23 pmichaud japhb: oh.  we already do this in Rakudo.
17:23 pmichaud each release is tagged
17:23 japhb Otherwise I have no way to say "User just upgraded to 1.9, now I have to update all the HLLs and modules.  But which revs do I use?"
17:24 japhb pmichaud, and your release is known to work with the latest monthly from Parrot, right.
17:24 pmichaud at any rate, parrot's general philosophy is not to impose too many requirements on hll devs
17:25 pmichaud I'm not sure I want to be maintaining a map of "Parrot revision x.y.z corresponds to tag a-b-c" in my repo, though.
17:26 japhb As long as your tag is obvious, plumage can just compute it, no map.  "WORKS_WITH_PARROT_1_9_0"
17:26 pmichaud I don't want to be responding to bug reports from someone who just downloaded Parrot 1.5.0, got the corresponding version of Rakudo, and finds bugs.
17:27 japhb OK, that's a fair point.
17:27 * japhb is looking for better ideas ... because the problem is a real one, and there needs to be *some* sort of solution
17:27 pmichaud the solution is likely for Parrot to actually stabilize for HLL devs.
17:27 pmichaud but I don't know that this will happen anytime soon.
17:28 japhb If we want Parrot to move along a little faster, I can't imagine Parrot getting stable in the way you're wanting for a year or two
17:28 whiteknight pmichaud: users reporting bugs against unsupported platforms or against old releases is a fact of the universe
17:28 whiteknight plumage or any other kind of package management solution isn't going to prevent that
17:29 pmichaud whiteknight: yes, but the approach that japhb is describing gets the streams backwards (more)
17:30 pmichaud it would be like the linux kernel trying to keep track of all of the libraries, modules, and applications built on top of it
17:30 japhb ???
17:30 japhb That analogy doesn't make sense.
17:30 japhb I'm not asking Parrot to do anything
17:31 moritz it's more like apt/dpkg, which only intalls linux, libc and user level apps if the version numbers are compatible
17:31 japhb I'm just asking for some way to not hose the user when they change Parrot version
17:31 japhb moritz, right
17:31 whiteknight Parrot is the base. We have parrot, then we search for a suitable Rakudo version from that
17:31 pmichaud who is the "we" doing the searching?
17:32 japhb In the apt case, there are several thousand DDs whose job is to figure out which revs match up.  We don't have that kind of scale
17:32 whiteknight we the users
17:32 pmichaud that's a non-answer
17:32 pmichaud what do you mean by "users" here?
17:32 whiteknight end-users
17:32 pmichaud you want the end-users to be installing parrot and figuring out which version of each hll to install?
17:32 whiteknight I have a linux kernel on my machine, and my packager finds packages that work with it
17:33 pmichaud okay, so it's not "end user" then, it's "packager" that is doing the searching
17:33 whiteknight i don't download libc and then try to find a compatible kernel
17:33 pmichaud the end user doesn't search
17:33 pmichaud the end user asks the packager to do the search
17:33 japhb OK, pmichaud, let's turn it around.  User has Parrot 1.8 and a bunch of modules and HLLs installed.  They upgrade to Parrot 1.9.  What revisions of each module and HLL should Plumage upgrade to?  How does Plumage figure that out?
17:34 japhb (I can figure out the algorithm for the depsolving.  It's getting the data to *feed* the depsolver that I don't have.)
17:34 pmichaud why would someone upgrade to 1.9?  that seems backwards to me.
17:34 japhb From 1.8?
17:34 japhb OK, 2.0 to 2.1
17:34 purl 41
17:34 pmichaud no, you're missing my point.
17:34 Coke pmichaud: let's say they upgrade tcl, which requires a new parrot, which then impacts everything else.
17:34 japhb seriously, purl, that's what you're bringing to the table?
17:35 japhb What coke said
17:35 pmichaud Coke: yes, your scenario makes much more sense to me.
17:35 japhb Now that we have the story, how can we get to a solution?
17:36 moritz in Debian, Rakudo would depend on an exact parrot version
17:36 pmichaud seems to me that plumage has to have a map for "parrot-revision-to-hll"
17:36 moritz no wait
17:36 pmichaud er, parrot-revision-to-hll-version
17:36 moritz rakudo would be a virtual package
17:36 moritz and rakudo-2009-10, rakudo-2009-11 etc provide 'rakudo'
17:37 moritz adn each of those depends on a particular version of parrot
17:37 japhb moritz, it can't be an exact revision unless all the HLLs and modules can *agree* on one.  In Debian, usually rakudo would depend on a >= rev or a rev range
17:37 Coke japhb: and you are not going to get that with parrot as it exists today.
17:37 japhb or that, I suppose, though I haven't seen that very often
17:37 pmichaud japhb: which gets back to my point that parrot isn't stable enough for rakudo to depend on a >= rev
17:37 Coke the best you can get today is a one-one.
17:37 Coke er, 1:1
17:37 moritz japhb: rakudo depends on exactly one parrot version
17:37 * japhb is having a bad morning
17:38 pmichaud japhb: it just doesn't happen.  It doesn't even happen for a range of more than one parrot.
17:38 Coke japhb: it'll get better by about 3.6 =-)
17:38 moritz japhb: likewise firefox usually depends on an exact version of xulrunner
17:38 PerlJam Coke++ I was just about to type something like that
17:38 moritz s/firefox/iceweasel/
17:38 Coke you may find the answer to the question is "if you upgrade tcl, you will break rakudo; sorry."
17:38 moritz so when xulrunner gets a security update, iceweasel gets an update too, just to keep compatibility
17:38 japhb OK listen, this is why I started the entire discussion by saying "I need to be able to figure out sync revisions of parrot, one revision that all of the HLLs and modules have at least one *findable* revision matching that sync revision of parrot"
17:39 Coke japhb: that's not a guarantee, either.
17:39 PerlJam Coke: hopefully though, the answer is "you get two versions of parrot so that both rakudo and tcl continue to run"
17:39 Coke I may not have a release that matches 2.0
17:39 Coke s/I/partcl/
17:39 japhb nod
17:39 pmichaud there's nothing that says that hll developers have to follow parrot's release cycle
17:39 Coke I mean, sure, we can give you the mappings that exist, but it's is at best going to be 1:1
17:40 Coke pmichaud: I think for the purposes of 'finding a version to work with for plumage', we can assume that.
17:40 Coke I don't think plumage wants to be involved with individual svn revisions.
17:40 pmichaud Coke: fair enough.  I have no idea what the situation is for, say, pynie though.
17:40 moritz I don't even know if pynie has releases
17:40 pmichaud Coke: I'm saying that some hlls might not have monthly releases
17:40 Coke I would say if you can't pin to a release, plumage doesn't figure this out for you.
17:40 Coke pmichaud: sure, partcl doesn't.
17:41 Coke (I might bother if there was an easy way for people to install them via plumage, though._)
17:41 japhb pmichaud, they don't have to have a release.  They just have to tag a rev in their repository to mark it safe.
17:41 pmichaud japhb: let's consider APL, then
17:41 pmichaud what release of Parrot is known to work with APL?
17:41 * japhb blinks
17:41 pmichaud what tags would you expect to see in the APL repo?
17:42 Coke pmichaud: I don't think it's fair to make him ask the first question. you or I would have to answer that. =-)
17:42 pmichaud Coke: can you answer it?
17:42 pmichaud (I can't)
17:42 Coke not without researching.
17:42 pmichaud right.
17:42 Coke it /is/ answerable, though.
17:42 japhb Again, it's not "what release of Parrot works with APL" it's "What release of APL works with a given Parrot release"?
17:42 pmichaud japhb: that's my point
17:42 japhb And the APL developers have to know that
17:43 pmichaud japhb: and I'm saying that we don't.  :)
17:43 japhb Ah-ha!
17:43 PerlJam sounds insane.
17:43 pmichaud so, Parrot 1.9.0 just came out
17:43 pmichaud you're wanting us to somehow know that APL works with 1.9.0
17:44 pmichaud but at the moment we don't really care if APL works with 1.9.0 -- suppose we're targeting 1.4.0 -- the last supported release
17:44 japhb I think I see where this is going
17:44 pmichaud we can't tell you "xyz version of APL works with 1.9.0", because there may not be such a beast
17:44 PerlJam pmichaud: so the answer to japhb's question is "none"
17:44 Coke pmichaud: so presumably if we had any data we'd have rHEAD(APL) works on 1.4.0(parrot)
17:44 Coke and that's it. and that's fine.
17:44 japhb 'BBQ I hate the deprecation system having gone in so early
17:45 Coke we don't have to answer the question for every single version of parrot (though someone could.)
17:45 pmichaud Coke: right.  But japhb seems to be wanting us to have tags in the apl repo that do answer that for every version of parrot
17:45 japhb Coke, exactly
17:45 Coke pmichaud: no, I think you're over-reading.
17:45 pmichaud fair enough
17:45 Coke japhb: ?
17:46 japhb pmichaud, no, I'm wanting "any the HLL knows", so we can feed the depsolver with some info.  Right now, it has *none*.
17:46 pmichaud japhb: then why does this information need to live in the hll repos?
17:46 japhb I'd be fine with saying "You can only install a new partcl if you uninstall APL or accept that it is likely broken"
17:47 pmichaud japhb: look, I'm open to maintaining such a mapping for rakudo -- just let me know what you want it to look like.  I'd prefer it *not* to be tags in my repo, though.
17:47 japhb pmichaud, That was my initial *idea* of how to store that information.  I was asking for better ideas.  :0-(
17:47 japhb er
17:47 japhb :-)
17:47 pmichaud I don't want parrot dictating how my repo needs to be structured.
17:47 pmichaud (or plumage)
17:47 japhb It really was just an idea.
17:48 japhb Sometimes I think we get too hung up on the problems with a particular suggestion, rather than searching for other bits of the solution space.
17:48 davidfetter joined #parrot
17:48 diakopter pmichaud: whatever package manager someone uses (themselves or some software) will need to know (through reading it on a rakudo download webpage, or programmatically in some dependencies manifest) which max backend version will work with that release
17:49 diakopter (I'm not being pedantic; just stating the obvious)
17:49 pmichaud diakopter: I don't disagree with any of what you just wrote.
17:49 NotFound Did we have a deprecation policy? Then why someone has broke Getopt without a notice?
17:49 Coke NotFound: because chromatic said it was ok.
17:49 Coke <shrug> was a mistake, it's getting fixed.
17:49 pmichaud actually, chromatic said it was okay for SDL
17:49 Andy joined #parrot
17:50 NotFound Given that SDL doesn't work, no surprise.
17:50 Coke pmichaud: I read it as asking about getopt in the scroll. I could have misread. Anyway, it's a mistake and someone will fix it. =-)
17:50 darbelo japhb: Wait, you intend plumage to be able to update parrot?
17:50 pmichaud I read chromatic's response as being about the ::'s in SDL libraries.  I can also see how it could be read to apply to Getopt as well.
17:50 japhb darbelo, yes.  It will have to be able to, for the reason that Coke pointed out:
17:51 japhb If the user wants to upgrade partcl, that rev of partcl may need a new parrot.
17:51 NotFound I'm fine with the change and can fix Winxed in a moment, but I excpect some sort of formal announcement before doing that.
17:52 Coke don't fix it, it needs to be rolled back. =-)
17:52 darbelo You mean my ports tree can upgrade my base system when I tell it to update firefox? Scary.
17:52 Coke NotFound: yes. it was a mistake.
17:52 japhb You know, the unspoken "other possibility" is for parrot to support being installed a bunch of times on the same system, with different revisions, without stomping on each other.
17:52 whiteknight but if you want to interoperate with plumage or any other project, you need to agree on an interface
17:52 Coke japhb: that should absolutely be a possibility.
17:52 Coke otherwise the answer will often be {NULL SET}
17:53 pmichaud in Rakudo's case, it may end up being a necessity, even just for Perl 6.
17:53 japhb Coke, yeah, I was hoping to avoid having {NULL SET} be *always* the answer.
17:53 japhb :-(
17:53 Coke well then, make sure we can have N different versions installed. =-)
17:53 japhb Yeah, I'll get right on that.
17:53 japhb What's the emoticon for rolling eyes?
17:53 Coke then plumage can say after a year, "hey, you're  not using 1.0. Want me to remove it to free up some space?"
17:54 mikehh pre/post-config, make corevm/makecoretest, smoke (#30972) PASS - fulltest FAIL at at r43110 - Ubuntu 9.10 i386 (g++ with --optimize)
17:54 mikehh t/examples/pir.t - Failed test:  2 in examples_tests
17:54 mikehh all other test5s PASS
17:54 darbelo japhb: If we bundle plumage into parrot, people install parrot X.X (which includes plumage Y.Y) and that plumage only install stuff that works on parrot X.X
17:54 NotFound No one wants to free up space these days, on the contrary, people like excuses to but bigger disks systems X-)
17:54 Coke darbelo: ... ok, if you install plumage, how does that work?
17:55 NotFound s/but/buy
17:55 pmichaud afk, lunch
17:55 mikehh darbello: yes to the build - I am not sure if it effects the failing test
17:55 japhb darbelo, And here comes the rub: When someone says "plumage upgrade partcl" ... what happens?  Does it install a new parrot, and then exec the plumage owned by that parrot?
17:57 darbelo japhb: It looks in it's (posibly remote) metadata store for a partcl that can work with that parrot.
17:57 japhb darbelo, right ... and how did we get that compatibility information into the metadata store in the first place?
17:58 darbelo Each plumage release can have a different metadata store, I can have six parrots installed inparallel, each with it's own lumage, each with it's own metadata store, each with the lates partcl known to work for that parrot rev installed.
17:58 pmichaud bah
17:59 pmichaud the metadata store can be somewhere that plumage knows where to look
17:59 pmichaud (and that single metadata store have sufficient information for all versions of plumage)
17:59 japhb darbelo, right, fine, the question is: where does that metadata COME FROM?  Where does the information about compatibility come from?  CAN THAT BE AUTOMATED IN ANY WAY?  IF so, how?
18:00 japhb Sorry for shouting.  I'm just getting frustrated.
18:00 Coke the metadata has to be vetted by a human at this point.
18:00 japhb Coke, right, I agree.  Who.
18:01 darbelo japhb: I don't think you can automate it. You can recruit volunteers to keep it up-to date.
18:01 Coke "someone who cares"
18:01 japhb Chicken and egg.
18:01 purl So the chicken's looking really pissy, and the egg's sitting up in bed next to her smoking a cigarette. The chicken snarls, "Well, I guess that solves THAT question."
18:01 darbelo That's how all package managers work nowadays.
18:01 Coke nice, purl.
18:01 purl I'm smooth like that
18:01 Coke nice, purl.
18:01 purl I'm smooth like that
18:02 Coke japhb: do you want a sign up sheet? =-)
18:02 Coke I mean, I'll probably be the one to update the information for partcl.
18:02 japhb darbelo, we're trying to essentially bootstrap a new package manager into this space.  But no one will use it if its unreliable, but it will be unreliable if the HLLs and module authors don't do the vetting (at least at first), and they won't go through the effort if no one is using it.
18:03 darbelo japhb: If the very HLL author can't tell what parrot releases he supports, how could plumage even guess at that?
18:03 Coke darbelo: you're agreeing with him. =-)
18:03 PerlJam darbelo: I think you can automate it with some sort of smoker-server geared towards collecting the appropriate meta-data.   The trick is just getting everyone to register with the smoke-server and having some convention for them to follow and ... etc.  :)
18:03 japhb Coke, thank you.  :-)
18:04 darbelo Coke: Sorta, he thinks he can solve it.
18:04 darbelo ;)
18:04 pmichaud darbelo: as an HLL author, I can very quickly say what parrot releases I do support.  I can't say anything about parrot releases that may have occurred that I don't support.
18:04 Coke pmichaud: that's all we need.
18:04 japhb pmichaud, I'll take what I can get, and I mean that quite seriously.
18:04 pmichaud or, put another way,  I can say which parrot releases I support.  I cannot say anything about parrot releases I don't support.
18:04 Coke pmichaud: no one expects you to.
18:04 japhb Fair enough
18:04 NotFound I suppose the HLL author can check that his HLL work witth the parrot version he uses X-)
18:05 japhb NotFound, true!
18:05 pmichaud japhb: right, I'm not arguing that point at the moment
18:05 pmichaud japhb: all I need is an idea of what information you need, and where you want it to be located
18:05 pmichaud tagging in the repo doesn't work for me
18:06 pmichaud (unless you can somehow use the tags I already have)
18:06 pmichaud we already put parrot revision information in our repo, in the build/PARROT_REVISION file
18:06 pmichaud released versions of Rakudo contain the corresponding release number of Parrot in that file
18:06 pmichaud (note "release number" not "revision number")
18:07 Coke so someone could backfill a bit of information there.
18:07 darbelo pmichaud: could you possibly extend that file to be a *list* of acceptable revs/releases?
18:07 pmichaud darbelo: no.  There's not a list.
18:07 Zak joined #parrot
18:07 japhb darbelo, probably not.  Because only one release is ever a match at a time.
18:07 pmichaud darbelo: at any given point in time, I can only guarantee a single revision of parrot.
18:07 darbelo pmichaud: A one element list is perfectly acceptable ;)
18:08 japhb "at most one", I guess
18:08 pmichaud (note "revision" not "release")
18:08 PerlJam pmichaud: released versions of rakudo should contain *both* the release number and the revision number
18:08 PerlJam (in build/PARROT_REVISION)
18:09 japhb OK, so: pmichaud, it sounds like if I want that information, your suggestion is to skim the history of the PARROT_REVISION file, look for all the points at which it changes, and import that information into the Plumage metadata to get my map
18:09 darbelo PerlJam: A parrot release might not map to a particular trunk rev.
18:09 japhb (I'm not saying that's good or bad, I'm trying to paraphrase)
18:09 pmichaud PerlJam: they do contain that information, yes.
18:10 Coke japhb: I would instead grab the info from his releases.
18:10 japhb Coke, how do I determine what a release is?
18:10 PerlJam japhb: there's a tarball for each one :)
18:10 japhb (programmatically)
18:10 pmichaud japhb: that's going to be hll-specific, yes?
18:11 pmichaud the mechanism one hll uses for a release may be very different from the one that other hlls use
18:11 pmichaud same for modules
18:11 Coke japhb: his github repo has tags, I assume most of those are from a release.
18:11 Coke (I'd grab all the ones #'d 200X-XX)
18:11 japhb pmichaud, yes, I was pointing out to Coke that I had no idea how to do some common rule for "this is a release" across all HLLs.
18:11 Coke japhb: you can't.
18:11 pmichaud japhb: you can't.
18:11 japhb I know.
18:11 Coke since this is a one time grab, I wouldn't worry about it.
18:12 pmichaud japhb: you can propose a protocol by which hlls can make it easier for this information to be made available to plumage
18:12 Coke http://github.com/rakudo/rakudo/b​lob/2009-11/build/PARROT_REVISION gets you the last one.
18:12 japhb I did propose such a protocol.  You said no.  So I'm asking for better ideas.
18:12 Coke (then you can keep bumping back the date.)
18:12 PerlJam maybe a small tool that updates build/PARROT_REVISION and the plumage metadata store.
18:12 Coke japhb: it's a one off.
18:13 japhb Coke, it's not.  It has to happen all through the future.
18:13 pmichaud japhb:  I can't really offer better ideas because I don't know plumage's other constraints
18:13 PerlJam (build/PARROT_REVISION seems like a good (enough) convention to me)
18:13 Coke japhb: the HLL dev is going to have to vet this answer.
18:13 jan joined #parrot
18:13 Coke so pulling it magically across 100 different projects when they're all going to do it differently anyway is not, IMO worth the time.
18:13 japhb Could all of you agree to use something like build/PARROT_REVISION?
18:13 pmichaud but also, keep in mind that this is one of those areas where plumage's goals diverge slightly from hll's goals (more)
18:13 japhb Then I can just look at that.
18:14 Coke I wouldn't rely on that.
18:14 pmichaud plumage's goal at the moment seems to be to make it easy to install languages and modules *for Parrot*
18:14 Coke posit:
18:14 Coke I declare that my january release works with 2.0
18:14 PerlJam or even "If you include a file called PARROT_REVISION *somewhere*  (not necessarily build), your project can be installable/etc with plumage"
18:14 Coke 2.3 comes out. it /happens/ to work with my release from january.
18:14 pmichaud but the bulk of my users aren't at all interested in Parrot or its requirements.  They just want to run Perl 6.
18:14 Coke I'm not going to re-release my january release to declare support for parrot 2.3
18:14 pmichaud ideally, they want to download rakudo, run some build commands, and start writing Perl 6 code
18:15 NotFound Or using
18:15 japhb Coke, that's a completely valid point.
18:16 pmichaud (that's the point I was making earlier about APL, fwiw)
18:16 Coke so you /could/ use it for an initial cut, but I don't think it's worth writing the code to do that, when someone is going to have to bless it anyway.
18:16 japhb pmichaud, my apologies for not understanding that earlier
18:16 Coke (even if that someone is a buildfarm.)
18:17 japhb Coke: does that leave us with the idea of some monster smoke test matrix, and look for the local minima?  'Cause that sounds painful.
18:18 nopaste "coke" at 193.200.132.135 pasted "pmichaud: any idea why this causes t/cmd_incr.t and time.t to fail? (or have better suggestions on cleaning up the impl?" (41 lines) at http://nopaste.snit.ch/19110
18:18 Coke japhb: it is painful. which is why I suggest not bothering trying to automate this.
18:18 pmichaud I think the overall point I'm trying to make is that Parrot has not yet reached a level of stability whereby .... what Coke said.
18:19 Coke let the HLL do the first approximation, and users can say "hey, this works with <later version>, btw."
18:19 pmichaud it's going to require people who care to manually keep things up to date
18:19 pmichaud make it easy for them to do so
18:19 japhb I guess I'm stuck with a problem:  The HLLs, if pmichaud is any indication, really don't care to make this easy for Plumage.  Which means it will be hard (in the sense of either a LOT of code, or humans (me) doing it by hand).  That's ... somewhat suboptimal for me.
18:19 PerlJam Coke, pmichaud: or he could establish a convention and encourage people to use it *now* so that the meta-info is easier to gather later   :)
18:19 pmichaud I care to make it easy for Plumage, if doing so doesn't make it hard on me
18:19 Coke japhb: you can automate the data collection, just not the data /vetting/
18:19 Coke so give the HLLs a way to submit data to you.
18:20 NotFound We can increase our stability level just by not deprecating things before providing working alternatives.
18:20 pmichaud I don't want to offload Plumage's difficulties onto myself :)
18:20 Coke s/HLLs/interested parties/
18:20 pmichaud NotFound: No, because working alternatives still requires updating the hlls and libraries.
18:20 pmichaud and those may happen on a different time scale
18:21 PerlJam Coke: that's why I mentioned a small tool to update build/PARROT_REVISION *and the plumage metadata store*  earlier  :)
18:21 NotFound pmichaud: yes, but providing it allows an interval of compatibility.
18:21 japhb pmichaud, I'm not trying to offload stuff that is "hard" for Plumage.  I'm trying to offload stuff that is impossible for Plumage to do without me becoming essentially a metadata manager for the rest of my days.
18:21 NotFound Is better than having an empty interval.
18:21 PerlJam japhb: not for the rest of your days .... just until you can find some chump^Wvolunteer to take over for you  :)
18:21 Coke japhb: this metadata needs to live in plumage, somewhere.
18:21 pmichaud NotFound: agreed fully.
18:22 Coke alongside the metadata you already keep.
18:22 Coke just like, e.g. the macport information about parrot lives in the macport repo, not parrot.
18:22 Coke (yes, I know we have a copy, but it's just a copy, and only for our convenience.)
18:23 pmichaud japhb: my comment was not intended to say that plumage is trying to push its problems into the hll devs laps
18:23 Coke so, here's a thought: create a new repo that just tracks the metadata.
18:23 pmichaud (new repo)  that's what I also was implying earlier
18:23 Coke then you don't have to update it, but the repo can be the clearinghouse.
18:23 PerlJam Coke++ pmichaud++  excellent idea.
18:24 Coke you can even git out commit bits to hll authors.
18:24 Coke *give
18:24 pmichaud 17:59 <pmichaud> the metadata store can be somewhere that plumage knows where to look
18:24 NotFound Coke: macport repo? Not in the Apple store? ;)
18:24 * Coke cries because he's gong to have to go to the apple store to resurrect 3 dead macs. :|
18:24 PerlJam Maybe proto should do the same (that might make it easier for proto to be replaced with something better too)
18:24 pmichaud proto already does the same -- it just uses its own repo as the metadata store
18:24 pmichaud (but commits are freely given)
18:24 japhb Wait ... so y'all would update your project's Plumage metadata if it just was in a separate repo?
18:25 PerlJam pmichaud: right, I'm saying divorce the two
18:25 japhb Or you're expecting the community would?
18:25 pmichaud japhb: I'm saying I'll update my projects Plumage metadata if it's not a significant cost to do so.
18:25 pmichaud and if I don't do it, someone else likely will.
18:25 Coke yah.
18:25 payload joined #parrot
18:25 pmichaud there are a few places I don't want the metadata to live   (new tags in my repo)
18:26 pmichaud beyond that, if it's easy for me to keep the metadata up-to-date somehow, then I'll do it
18:26 Coke pmichaud: I snuck in a nopaste to you, btw.
18:26 japhb OK, wow.  If I'd known that was the blocker, I would have made the "metadata out of plumage repo" a high priority task rather than a low-priority one, a long time ago.
18:26 pmichaud if it's hard for me to keep metadata up to date, I won't do it  (standard open source applies here)
18:26 bubaflub joined #parrot
18:27 pmichaud i.e., the value derived from keeping the metadata up to date has to be greater than the cost of doing so
18:27 pmichaud Coke: I saw the nopaste... I don't have a quick answer
18:27 NotFound We can create a 'Best metadata of the year' contest X-)
18:27 Coke it's just a slightly expanded version of yours.
18:28 pmichaud Coke: I'm thinking that perhaps we should not inline this just yet.
18:28 pmichaud it's.... messy.
18:28 pmichaud so perhaps take the speed hit for now of a separate dispatch function until we get a few more things worked out.
18:29 Coke pmichaud: fair enough.
18:29 japhb pmichaud, what could Plumage do for you that would make it a net win to help plumage?
18:30 pmichaud japhb: I need to know what metadata to provide.  I need to know where to provide it.
18:30 moritz if plumage brings rakudo users, it's a net win :-)
18:30 japhb moritz, :-)
18:30 pmichaud At the moment it's easiest if that metadata can live somewhere that Rakudo release managers can easily update it.
18:30 japhb pmichaud, OK, fair enough.
18:31 pmichaud this probably means it would be nice if it could live somewhere in the rakudo repo
18:31 pmichaud I don't have a problem with that, depending on where that "somewhere" ends up being
18:31 Zak joined #parrot
18:31 pmichaud (in the rakudo repo being nice because then the release managers don't have to get separate commits to plumage's metadata repository)
18:31 japhb pmichaud, the convention other projects have used is in plumage/metadata.json or plumage/projectname.json in their repo
18:32 pmichaud hmmm, I'm not so sure I like that name, though.
18:32 pmichaud I need to provide a lot of metadata for projects other than plumage as well, can't we have a standard for that?
18:32 pmichaud similar to parrot's  ports/ directory, iirc?
18:33 pmichaud i.e., I don't know that I want a plumage/   debian/   ubuntu/   redhat/     etc.   in my top-level repo dir
18:34 pmichaud Coke: need me to write up a version of the dispatch function to start with?
18:34 pmichaud (It'll have to be after lunch, though)
18:36 japhb pmichaud, it was intended to match 'debian/control' and similar
18:37 pmichaud right... I'm just not a fan of having my root repo cluttered with directories that are really in support of other projects
18:37 pmichaud s/root repo/repo root dir/
18:37 pmichaud i.e., the directories that are important to me are "build/",  "src/", and "docs/"
18:40 Coke pmichaud: that would be spiffy.
18:40 pmichaud japhb: I'd also be okay with rakudo having a separate repo just to maintain metadata for plumage and other projects :)
18:41 Coke (dir) build/ seems vaguely abusable for this.
18:41 Coke (for plumage in specific)
18:41 pmichaud build/ is what Rakudo uses now -- see build/rakudo.spec  in the rakudo repo (for building RPMs)
18:41 pmichaud I'm fine with build/plumage.json    or build/plumage/...
18:42 pmichaud even better, the create_language.pl tool could automatically populate a plumage metadata file :)
18:42 pmichaud (and provide the make targets for performing releases and keep that file up-to-date)
18:44 pmichaud anyway, lunchtime here -- bbl
18:46 dukeleto 'ello
18:46 * dukeleto is amazed at how the Parrot Roadmap google doc has exponentially grown since I last looked
18:47 Coke Parrot Roadmap?
18:47 japhb joined #parrot
18:47 Tene_ joined #parrot
18:47 dngor_ joined #parrot
18:47 leto_ joined #parrot
18:47 athomaso1 joined #parrot
18:47 bubaflub joined #parrot
18:47 theory joined #parrot
18:47 darbelo joined #parrot
18:47 bluescreen joined #parrot
18:47 jsut_ joined #parrot
18:47 rhr joined #parrot
18:47 diakopter joined #parrot
18:47 cotto_work joined #parrot
18:47 PacoLinux joined #parrot
18:47 wayland__ joined #parrot
18:47 silug joined #parrot
18:47 tewk_ joined #parrot
18:47 bacek_at_work joined #parrot
18:47 dcolish joined #parrot
18:47 ingy joined #parrot
18:47 zostay joined #parrot
18:47 purl joined #parrot
18:47 spinclad joined #parrot
18:47 szabgab joined #parrot
18:47 particle joined #parrot
18:47 TimToady joined #parrot
18:47 workbench joined #parrot
18:47 Ryan52 joined #parrot
18:47 jjore joined #parrot
18:47 cxreg joined #parrot
18:47 estrabd_ joined #parrot
18:47 frodwith_ joined #parrot
18:47 treed joined #parrot
18:47 sjn joined #parrot
18:47 Maddingue joined #parrot
18:47 baest joined #parrot
18:48 darbelo Netsplit--
18:48 s1n joined #parrot
18:48 jhelwig joined #parrot
18:49 japhb Well, I couldn't respond to pmichaud earlier, but:
18:50 darbelo Ok, we're back on the irclog.
18:50 japhb Plumage doesn't care where you keep the metadata in your repo.  It needs to be told *once* where that file will be, and then from then on when you fetch/update it will reload the metadata from the fetched copy.
18:50 dukeleto roadmap?
18:50 purl somebody said roadmap was https://trac.parrot.org/parrot/wiki/ParrotRoadmap
18:51 japhb (Or rather, that's the behavior it will have later this week or so -- it was always the plan, just needed to be done after the refactors)
18:51 Coke roadmap google doc is https://spreadsheets.google.com/a/co​leda.com/ccc?key=0Ahm1zTZwW0VHdFVPSW​1BemVEZU82RkFrZDZ5cTdtYXc&amp;hl=en
18:51 dukeleto purl, roadmap is also http://spreadsheets.google.com/ccc?key=0Ahm1zTZ​wW0VHdFVPSW1BemVEZU82RkFrZDZ5cTdtYXc&amp;hl=en
18:51 purl okay, dukeleto.
18:51 Coke forget roadmap google doc
18:51 purl Coke: I forgot roadmap google doc
18:52 dukeleto purl, forget roadmap
18:52 purl dukeleto: I forgot roadmap
18:52 dukeleto purl, roadmap is http://icanhaz.com/parrotroadmap or https://trac.parrot.org/parrot/wiki/ParrotRoadmap
18:52 purl OK, dukeleto.
18:53 Topic for #parrotis now Parrot 1.9.0 "Blue-fronted Amazon" released! | http://parrot.org | Roadmap: http://icanhaz.com/parrotroadmap | Latest modified TT's: http://icanhaz.com/parrotbugs
19:01 confound joined #parrot
19:03 payload joined #parrot
19:08 dalek hq9plus: 5407b5e | bernhard++ | .gitignore:
19:08 dalek hq9plus: Makefile is no longer generated.
19:08 dalek hq9plus: review: http://github.com/bschmalhofer/hq9plus/comm​it/5407b5e1378a0ca7b6e6619d3722d95fb5981847
19:09 dalek parrot: r43111 | tene++ | trunk/compilers/pct/src/PAST/Compiler.pir:
19:09 dalek parrot: Small fix to remove CONTROL_ERROR from the CONTROL handled types.  This API needs more-significant work, but this is enough for now.
19:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43111/
19:22 chromatic joined #parrot
19:22 Andy joined #parrot
19:22 davidfetter joined #parrot
19:22 patspam joined #parrot
19:22 cotto joined #parrot
19:22 KatrinaTheLamia joined #parrot
19:22 Khisanth joined #parrot
19:22 Infinoid joined #parrot
19:22 DrForr_ joined #parrot
19:26 dukeleto yay for netsplits!
19:26 Coke pmichaud: I just avoided a pain point of mine by elminating the gen/ directory for partcl-nqp; hopefully this won't introduce pain for you.
19:27 dukeleto Coke: is that like reverse code acupuncture?
19:28 dalek partcl-nqp: 3286c67 | coke++ | build/Makefile.in:
19:28 dalek partcl-nqp: strip out unused items.
19:28 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/3286c67fc827ad51c91fbce959fe36a4233e31dd
19:28 dalek partcl-nqp: 3a031e8 | coke++ |  (4 files):
19:28 dalek partcl-nqp: switch from putting generated PIR in gen/ to using a SUFFIX rule.
19:28 dalek partcl-nqp: * reduces pain when adding new files to the build (much simplified Makefile)
19:28 dalek partcl-nqp: * the .pir files aren't being installed, they're being .included
19:28 dalek partcl-nqp: * puts generated PIR near the NQP that generated it. (con for some)
19:28 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/3a031e8cffdb50fa923dcff93ad5a01de57ba632
19:30 Khisanth joined #parrot
19:30 davidfetter joined #parrot
19:30 chromatic joined #parrot
19:30 cotto joined #parrot
19:30 patspam joined #parrot
19:30 KatrinaTheLamia joined #parrot
19:31 payload joined #parrot
19:31 * Coke ponders what <nibbler> and <termish> are for in partcl-nqp's ARE grammar.
19:32 Zak joined #parrot
19:37 dalek parrot-plumage: b68c463 | darbelo++ | src/plumage.nqp:
19:37 dalek parrot-plumage: Change the dprecated ['parrot';'Getopt::Obj'] to ['parrot';'Getopt';'Obj'] notation for Getopt.
19:37 purl dalek: that doesn't look right
19:37 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/b68c4637a1c790b3b51cca7e5d239a59f2588ccf
19:37 PerlJam Coke: How would you write it without them?  :)
19:40 japhb darbelo, I thought we agreed earlier that the Getopt::Obj change was going to rolled back?
19:40 japhb Or was that reversed again during one of the netsplits?
19:41 darbelo japhb: really? I missed that.
19:41 japhb Lots of people complained.
19:41 japhb I'm guessing no one actually did the rollback yet, though
19:42 dalek parrot: r43112 | fperrad++ | trunk (4 files):
19:42 dalek parrot: [distutils] now, works in a build tree
19:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43112/
19:42 darbelo I think I saw something about keeping both names and depreacting the old one yesterday when it was first brought up.
19:42 dalek parrot-plumage: 60794cc | darbelo++ | metadata/hq9plus.json:
19:42 dalek parrot-plumage: Add metadata file for hq9plus.
19:42 dalek parrot-plumage: fperrad++; distutils++;
19:42 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/60794cc24b523fdb26f301a2efc8c84577670ea7
19:43 japhb Oy, Vey.
19:43 darbelo Which is the sane startegy if you ask me. You anounce that 'X' won't be available tomorrow, and provide the alternative today.
19:43 japhb Well, if you've got Plumage working again, great.  We can always fix plumage again if the rollback happens
19:44 japhb darbelo, the problem was that it wasn't "both" now, it was just changed.
19:45 Infinoid joined #parrot
19:45 japhb left #parrot
19:45 japhb joined #parrot
19:45 Coke PerlJam: I can't write it /with/ them, so it's not entirely a fair question. =-)
19:46 Coke yes. that change must be rolled back.
19:46 Coke adding a copy that's the new would be very nice.
19:50 zak_ joined #parrot
19:54 * pmichaud returns
19:59 lucian joined #parrot
19:59 iblechbot joined #parrot
20:01 ruoso joined #parrot
20:07 payload joined #parrot
20:07 pmichaud phone
20:09 patspam1 joined #parrot
20:09 bacek joined #parrot
20:17 Coke pmichaud: ENOPHONE today.
20:17 Coke (for me. will catch you next week.)
20:32 whiteknight joined #parrot
20:47 bacek Good morning
20:47 bacek whiteknight++ # fixing context_unify3
20:48 dukeleto bacek: good moroning
20:49 * bacek wonder when purl changed name to dukeleto
20:51 Tene_ I'll go roll back the getopt change and put in a non-breaking version... someday.
20:52 dukeleto bacek: purl wishes she could be as cool as me
20:53 darbelo Tene_: Can't we just put a copy of the old file under a different name and .inlude it from the new one?
20:53 whiteknight bacek: I needed to do more, but I had a few spare moments
20:54 bacek whiteknight, your comment about interp->sub was very helpful. Now I know where to look.
20:56 Tene_ darbelo: dunno.  I feel kind of stupid having two copies in the repo.  The fix I'd like to see is copying the two namespaces into their old names and the old classes being made from the :load sub, I guess.
20:57 dalek rakudo/master: 98b3f18 | chromatic++ | build/PARROT_REVISION:
20:57 dalek rakudo/master: Updated PARROT_REVISION for Parrot release 1.9.0.
20:57 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/9​8b3f18a3ab8846b5701a6c57892dd0129fb0673
20:57 Tene_ I guess that would work, though.
20:57 Coke doesn't have to be high tech. just needs to last through the 2.0 release.
20:58 Coke (after which it can be immediately ripped out.
20:59 dalek parrot-plumage: e516d05 | japhb++ | metadata/xml.json:
20:59 dalek parrot-plumage: [METADATA] Update xml.json; fperrad++
20:59 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/e516d05ad5cbea4b488d5e7d1e40506e3a62cc24
20:59 dalek parrot-plumage: 01f22a5 | japhb++ | README:
20:59 dalek parrot-plumage: [META] Bring OVERVIEW section in README more in line with current status of Plumage
20:59 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/01f22a57499bbfc9b5ec2c87da0489daaaba214e
21:03 dalek parrot: r43113 | tene++ | trunk (11 files):
21:03 dalek parrot: Revert "Fix Getopt::Obj to use a keyed namespace"
21:03 dalek parrot: This reverts commit fbef5a32530d780b0c1bace0542f9b3209b44adb.
21:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43113/
21:05 Coke tene++
21:05 chromatic I thought commit numbers always started with r!
21:06 Tene_ ack, I forgot to remove the "this reverts commit ..." line.
21:06 moritz that has is a bit useless when there's no canonical git repo
21:06 Tene_ sorry.
21:06 moritz s/has/hash/
21:07 chromatic Just teasing.
21:09 japhb darbelo, care to do the honors to Plumage again?  :-)
21:10 Coke pmichaud: chaud++
21:10 Coke er...
21:10 Coke pmichaud++
21:14 darbelo japhb: Ok, I'm on it...
21:15 japhb darbelo, thanks!
21:22 joeri joined #parrot
21:26 bacek yay!
21:26 darbelo bacek++
21:26 bacek "make all" works on branch
21:26 chromatic PGE builds?
21:27 darbelo dammit I forgot to push to Gitorious.
21:27 bacek chromatic, yes
21:27 darbelo japhb: Ok. pushed.
21:27 chromatic Now comes the fun part.
21:27 bacek chromatic, running test now
21:27 japhb darbelo, thank you, rebuilding world
21:29 bacek ho-ho-ho
21:29 nopaste "bacek" at 122.110.75.223 pasted "test summary on context_ubify3 branch" (16 lines) at http://nopaste.snit.ch/19115
21:30 dalek winxed: r268 | julian.notfound++ | trunk/winxedst0.cpp:
21:30 dalek winxed: quick fix for non-pmc attributes
21:30 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=268
21:30 patspam joined #parrot
21:31 bacek http://smolder.plusthree.com/app/pu​blic_projects/report_details/30976 same on smolder
21:31 dalek parrot-plumage: e4cae47 | darbelo++ | src/plumage.nqp:
21:31 dalek parrot-plumage: Change ['parrot';'Getopt';'Obj'] back to ['parrot';'Getopt::Obj'] notation for Getopt.
21:31 purl dalek: that doesn't look right
21:31 dalek parrot-plumage: The parrot change got reverted.
21:31 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/e4cae47d47f5f3ba382c344358216eb90b166a58
21:32 bacek 12,109 ok, 6 failed, 274 todo, 622 skipped and 0 unexpectedly succeeded
21:32 bacek On this positive note I'm departing to $dayjob
21:32 chromatic Only six failures.  That's very reasonable.
21:35 bacek joined #parrot
21:36 mikehh joined #parrot
21:36 dalek parrot: r43114 | bacek++ | branches/context_unify3/src/call/context.c:
21:36 dalek parrot: Put workaround into init_context to avoid reinitilising Coro context.
21:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43114/
21:36 dalek parrot: r43115 | bacek++ | branches/context_unify3/src/pmc/coroutine.pmc:
21:36 dalek parrot: Fix Coro invoke to pop freshly pushed Context
21:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43115/
21:37 dalek rakudo/master: 26251f5 | chromatic++ | docs/announce/2009-12:
21:37 dalek rakudo/master: Added initial release announcement, with obvious places for additions.
21:37 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/2​6251f5b87f96acc4b8620eb2a54430ad5a6d4f3
21:49 dalek rakudo/master: 34895f9 | moritz++ | docs/announce/2009-12:
21:49 dalek rakudo/master: [docs] deprecation notcies for release: Object -> Mu, undef is gone
21:49 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/3​4895f968121fb50eaee6cc72d953b7476ab3962
22:15 dalek parrot-plumage: 424be23 | darbelo++ | src/Makefile.in:
22:15 dalek parrot-plumage: [MAKEFILE] Make 'test' dpepend on 'all' so make doesn't start testing before everything gets built.
22:15 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/424be238ddeddbdf1d7e335a1251dea90b61302b
22:17 japhb *chuckle*
22:17 japhb Things you don't notice if you don't parallel make.
22:18 dukeleto japhb: :)
22:19 * japhb suddenly remembers ... now that Tene has implemented =>, we can do setup.nqp!
22:19 Tene_ Yes!  The one patch i wrote last night that didn't break anything!
22:20 darbelo japhb: I wasn't doing a parallel make, it's a "Thing you don't notice if you don't use GNU make." ;)
22:20 japhb Tene, sorry I haven't gotten tests in for you.  I've been swamped.
22:20 Tene japhb: don't worry about it.
22:22 dalek winxed: r269 | julian.notfound++ | trunk/winxedst1.winxed:
22:22 dalek winxed: operator '.' for method calls and related fixes in stage 1
22:23 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=269
22:23 dalek winxed: r270 | julian.notfound++ | trunk/Makefile:
22:23 dalek winxed: more passing tests in stage 1
22:23 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=270
22:34 dalek rakudo/master: 036536a | jnthn++ | src/ops/perl6.ops:
22:34 dalek rakudo/master: Chase a Parrot change that broke our junction auto-threading code.
22:34 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/0​36536a74f9787060b9b36a50ebc797023f60fda
22:34 dalek rakudo/master: c4b4110 | chromatic++ | t/spectest.data:
22:34 dalek rakudo/master: Skipped a few tests which don't pass with Parrot 1.9.0; will revert after the
22:34 dalek rakudo/master: release.
22:34 purl NO! it will ESCAPE and leave behind a bloddy trail of QA
22:34 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/c​4b4110210108fff9ce1080eb1e92f805870ac8c
22:34 dalek rakudo/master: 73c4a80 | chromatic++ | docs/announce/2009-12:
22:34 dalek rakudo/master: Merge branch 'master' of git@github.com:rakudo/rakudo
22:34 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/7​3c4a808e275173b5d99e42155679330c0a37431
22:36 nopaste joined #parrot
22:50 joeri left #parrot
22:51 nopaste joined #parrot
22:56 dalek winxed: r271 | julian.notfound++ | trunk/ (2 files):
22:56 dalek winxed: member var creation and some related fixes in stage 1
22:56 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=271
22:59 dukeleto i would greatly appreciate feedback on this blog post that I co-wrote with Brian Wisti: http://coolnamehere.com/geekery​/parrot/learn/08-test-more.html
22:59 dukeleto it is a Test::More tutorial for Parrot
23:01 chromatic reads fine to me, dukeleto
23:04 japhb darbelo, plumage seems back to life, thank you
23:04 dukeleto chromatic: awesome
23:05 NotFound dukeleto++
23:08 dalek rakudo/master: 1d44f48 | chromatic++ | src/ops/perl6.ops:
23:08 dalek rakudo/master: [ops] Fixed a C++ compilation warning with an appropriate typedef.
23:08 dalek rakudo/master: review: http://github.com/rakudo/rakudo/commit/1​d44f48bd3722738b968bad816aabaa718025c75
23:10 TonyC joined #parrot
23:12 cotto_work joined #parrot
23:13 payload joined #parrot
23:27 diakopter left #parrot
23:28 kid51 joined #parrot
23:36 hercynium joined #parrot

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

Parrot | source cross referenced