Camelia, the Perl 6 bug

IRC log for #parrot, 2009-12-14

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 bacek joined #parrot
00:06 dalek partcl-nqp: 3dbbb2b | coke++ | src/class/tcllist.pir:
00:06 dalek partcl-nqp: remove unused methods copied over from partcl
00:06 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/3dbbb2bd54bebb871ae93f310b5211e7a8737906
00:07 pmichaud Tene: src/HLL/Compiler.pm
00:07 pmichaud also a new pdd31 draft
00:07 pmichaud Tene: I just added these Friday and yesterday.
00:07 pmichaud (to complete my grant)
00:08 pmichaud Tene: comments, patches welcomed
00:09 pmichaud Tene: in general, I'd like to get HLL::Compiler as a standalone class and remove its dependency on PCT::Compiler (and have more of it written in NQP instead of PIR)
00:09 pmichaud but I'm also wanting to use this as a chance to re-think some of our compiler interfaces, such as the staging interface
00:09 pmichaud and to hopefully bring in some generic getopts-style processing
00:11 Zak joined #parrot
00:24 Coke pmichaud: hey, do you have than unknown patch lying about?
00:24 pmichaud Coke: oh yeah, I didn't commit it.  Hmmm.
00:25 pmichaud I have it as a diff right now.  I'm not entirely happy with it but perhaps you can work with it a bit
00:25 Coke yes, please.
00:25 nopaste "pmichaud" at 66.25.4.52 pasted "unknown patch for Coke++" (27 lines) at http://nopaste.snit.ch/19071
00:26 japhb pmichaud, got a couple to talk about the Perl 6 installer space?  (Or should I take this to #perl6?)
00:26 payload joined #parrot
00:27 pmichaud japhb: alas, I have to take care of family's dinner here (because we ran a bit long)
00:27 pmichaud japhb: but I'll be most happy to reserve time to talk about it with you
00:27 japhb pmichaud, OK.  But please do ping me at some point, because I'd like to ... yes, thank you
00:27 pmichaud tonight might be tricky; is there a specific time tomorrow that would be good?
00:27 * japhb thinks
00:27 pmichaud or do you just want me to catch you online?
00:28 pmichaud I'll be around quite a bit over the next few days
00:28 japhb yes, that would probably be best
00:28 japhb ok, great
00:28 japhb Tene, still around?
00:28 pmichaud okay, we'll do that.  if it looks like I've forgotten about it, ping/bump me
00:28 japhb Ok, great, thank you.
00:28 pmichaud I'd very much like to discuss it with you, it will likely turn into a blog article
00:28 japhb nodnod
00:29 Tene japhb: I'm here, kind of.  This weekend has kind of exploded.
00:29 pmichaud (so I can publish my views on the topic a bit more widely)
00:29 japhb :-)
00:29 japhb Tene, just wanted to ping you on fat arrow syntax for NQP-rx, but not important enough to prevent you from jumping behind some shelter v. the explosion
00:32 payload joined #parrot
00:45 nopaste "coke" at 193.200.132.135 pasted "for pmichaud" (41 lines) at http://nopaste.snit.ch/19072
00:45 Coke pmichaud: that version deals with a missing unknown, with an invoke with no args... but causes 'make test' to fail.
01:00 Whiteknight joined #parrot
01:00 abqar joined #parrot
01:02 colomon_ joined #parrot
01:07 Whiteknight excellent planning meeting today
01:07 Whiteknight everybody++
01:07 Whiteknight go team!
01:13 Infinoid Whiteknight: Ok.  I can give you the Pipe primitives pretty easily, and leave the FileHandle.open refactor as a separate task
01:14 Infinoid I'll send you a patch once I've had a chance to get my head back into parrot
01:14 Whiteknight awesome
01:19 colomon___ joined #parrot
01:38 dalek parrot: r43029 | plobsing++ | trunk/include/parrot/pmc_freeze.h:
01:38 dalek parrot: remove unused mark_ptr element from visit_info
01:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43029/
01:40 JimmyZ joined #parrot
02:05 plobsing can someone explain why we need TT#1305?
02:06 * Whiteknight looks
02:06 Coke Without knowing what the replacement PMC looks like, no; but in general, you can interact with a pmc from PIR, you can't with a c struct.
02:06 Ryan52 the next parrot release is in 2 days, right? and then the one after it is "stable", right?
02:07 plobsing I am feeling the constant urge to kill it with fire
02:08 plobsing and AFAICT image_io and visit_info fall under "internal datastructures" as being explicitly not supported
02:08 Whiteknight plobsing: make them GCable, make them usable from PIR, overridable, ec
02:08 plobsing my first goal is usable from pir
02:08 plobsing i think the others fall out from there
02:10 Whiteknight yeah, definitely
02:11 plobsing So I can rip them out ASAP if I've got a reasonable replacement?
02:12 plobsing thats what I really want to know
02:14 Whiteknight make a branch, but yeah
02:43 dalek parrot: r43030 | plobsing++ | branches/pmc_freeze_cleanup:
02:43 dalek parrot: create branch for freeze/thaw/visit subsystem refactoring
02:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43030/
02:46 kid51 joined #parrot
02:47 kid51 plobsing: darbelo was looking closely at src/pmc_freeze.c yesterday.  See chart in http://trac.parrot.org/parrot/w​iki/PreDecemberReleaseHackathon
02:49 Topic for #parrotis now Parrot 1.8.0 Zygodactyly released | Parrot 1.9.0 to be released Tues 15 Dec
03:06 Coke (*&$#.
03:06 Coke this generated PIR is SO verbose.
03:06 Coke Makes it very difficult to track down problems when my NQP doesn't work.
03:12 jsut_ joined #parrot
03:27 Coke pmichaud, Tene: NQP and rakudo seem to be catching a return inside a try. That should be let through, shouldn't it?
04:13 bacek joined #parrot
05:31 darbelo joined #parrot
05:32 darbelo plobsing: ping
05:32 plobsing pong
05:33 darbelo I see you created a branch for cleaning up the yakhole^W^W freeze/thaw, is there anyway I can help there?
05:34 plobsing there's so much concentrated evil there. where to begin...
05:35 plobsing what I'm hoping to do is move all access to visit_info and image_io into vtables so that they can easily be made into PMCs
05:35 darbelo Yeah, there's that. And some of the evil needs to live 'till 2.0
05:35 plobsing I saw the ticket you made.
05:35 plobsing why does it need to live?
05:35 plobsing doesn't it all fall under "internal datastructures"?
05:36 darbelo The deprecation policy says we can't chance 'user facing interfaces' without previous notice in DEPRECATED.pod
05:36 mikehh joined #parrot
05:37 plobsing how is this user facing? you can't get a handle to any of this stuff using PARROT_API functions I don't think.
05:37 darbelo Right now all PMCs written in c get passed a image_io struct, if we make it a PMC users have to change their function signatures.
05:38 plobsing I see.
05:38 darbelo let me get you an example.
05:39 darbelo http://code.google.com/p/decnum-dynpmcs/sour​ce/browse/trunk/src/pmc/decnumcontext.pmc#95
05:39 darbelo Sorry, visit_info, not image_io
05:40 plobsing example is good.
05:41 plobsing I want to change both.
05:42 darbelo So, we can make changes to the structure, but not eliminate it.
05:42 plobsing you're not going to like my next commit to that branch then
05:43 dalek parrot: r43031 | plobsing++ | branches/pmc_freeze_cleanup (24 files):
05:43 dalek parrot: Merge image_io and visit_info.
05:43 dalek parrot: This moves the vtable functionality into visit_info, which is what everything outside
05:43 dalek parrot: of this subsystem deals with (and what should become a PMC).
05:43 dalek parrot: Add get_integer vtable interface to replace visit_info.what.
05:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43031/
05:44 chromatic #define visit_info PMC
05:44 plobsing thats the eventual goal
05:45 chromatic Who says you can't now?
05:45 plobsing the problem is the current API requires struct member access. apparently we have consumers of this API.
05:45 darbelo plobsing: I do like that ;)
05:46 darbelo But, "struct PackFile *pf" can die now. It's 'unused' out of the function that creates it.
05:47 darbelo chromatic: Really? Ok.
05:47 chromatic Just a thought.
05:48 plobsing for the record, I would like nothing more than to do that right now.
05:48 chromatic We could ask HLL developers if they've overridden those entries.
05:49 darbelo Thinking about it some more, I don't see why we can't go ahead in the branch and punt the "can we dod that?" argument until it's ready to merge.
05:49 particle you could ask hll devs to test their hll on your branch
05:50 particle darbelo++
05:50 chromatic Punt later.
05:51 * particle gets back to gin&tonic-making &
05:51 * Coke wonders if timtowdi.org is gone.
05:54 darbelo plobsing: Looks like green light to me. Start poring fire!
05:55 plobsing woot! full steam ahead!
05:56 darbelo I've checked out the branch and I'm removing the packfile member from the structure.
05:57 plobsing darbelo++
05:59 darbelo I removed it from the structure and reduced it's scope to the one function that uses it.
06:00 darbelo But I'm not sure why we're using it there at all.
06:03 darbelo I'm seriously wondering what's the point of copying that header to the string.
06:04 plobsing In theory, it should give us portability accross platforms.
06:05 plobsing I doubt that actually happens though
06:05 darbelo Looking at the way we store INTVALs there. We can't be portable.
06:07 darbelo Hm. I'm looking at this wrong.
06:07 darbelo We should ditch the STRING and create a PackFile.
06:08 darbelo That format is supposed to be portable, and we are already using the PF_* functions for storing stuff.
06:09 plobsing yes, that would be best. It makes TT #1359 a lot easier.
06:10 darbelo Reading ticket..
06:11 darbelo Nice plan there. plobsing++
06:11 plobsing Its a nice plan. I'm not sure I'll be able to implement. But I can dream.
06:13 darbelo But, freezing stuff from PIR uses STRINGS, so we should provide a way to 'stringify' the PF if we want to keep a compatible interface.
06:15 * Coke has an nqp question...
06:29 Coke . o O (man is this frustrating.)
06:30 darbelo Not unexpected, but PackFile code is damm ugly in places.
06:35 darbelo Also, we store things in platform-specific fromats and then convert them when reading.
06:36 darbelo That looks backwards to me.
06:37 plobsing how so?
06:38 darbelo The on-disk format changes from machine to machine. It stored in 'platform-native' format.
06:39 plobsing the common case is fast - if the writer and the reader are the same machine, no conversion occurs IIRC
06:41 darbelo Yes. But we can't test the validity of PF created in another arch without knowing all N*N platform to platform conversions.
06:41 plobsing that isn't already handled somehow?
06:42 plobsing anyone know why thawing a ParrotInterpreter should cause all subsequent PMCs to be thawed as constants?
06:42 darbelo Tha means that validation tools grow in complexity (and bug-prone-ity) or rely on the very code they are supposed to be testing.
06:43 darbelo validation tools need to be dumb, so that there is no way to get them wrong.
06:43 plobsing good point.
06:44 darbelo And I'd bet this is a io-bound code path. We aren't gaining *that* much speed.
06:44 Coke msg pmichaud: I have been making changes to partcl's integer rule for about an hour now trying to get it to access negative numbers. I finally replaced it with a rule that only took ints consisting of 7s. "32" still parses as an int. I suspect that I am always getting the parent grammar's integer rule.
06:44 purl Message for pmichaud stored.
06:48 bacek_at_work darbelo, http://trac.parrot.org/parrot/ticket/451
06:48 Coke msg pmichaud if I change the rule name to "tcl_integer" (in the grammar, the actions, and in src/TclString.pm's "getInteger()", I get Method 'tcl_integer' not found for invocant of class ''
06:48 purl Message for pmichaud stored.
06:48 bacek_at_work darbelo, I'm pushing for changing PBC format for quite long time already...
06:49 chromatic Reminder: if we use a platform-native format, we can (in theory) mmap in the PBC.
06:49 Coke msg pmichaud (this in support of TODO item #1)
06:49 purl Message for pmichaud stored.
06:49 chromatic I don't know if that truly works, or if we have to perform fixups on the PBC after loading.
06:50 bacek_at_work chromatic, and load annotations, etc, etc, etc.
06:50 darbelo I'm pretty sure we don't actually do that.
06:51 chromatic Perform fixups or mmap?
06:51 darbelo mmap()
06:51 chromatic I know we don't.
06:52 chromatic Dan wanted to for a very long time.
06:54 darbelo We should decide wether to do that or go with TT#451, then.
06:55 chromatic I can make the argument we should consider a PBC optimizer which would allow faster loading with better shared memory performance... but default to portable PBC.
06:56 chromatic That way we don't block portable PBC on future optimizations which may not take place until ... THE FUTURE.
06:57 darbelo True, but I'm going off target here. I'm supposed to make 2003's "THE FUTURE" happen for pmc_freeze.
06:58 chromatic I have a bias for platform-independent formats here.
07:04 dalek parrot: r43032 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc (2 files):
07:04 dalek parrot: change all external accesses to visit_info.what to use get_integer
07:04 purl dalek: that doesn't look right
07:04 dalek parrot: also, eliminate ParrotInterpreter setting visit_info.what because ...
07:04 dalek parrot: well ... I'm not quite sure what it does, but it seems very, very wrong.
07:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43032/
07:07 plobsing on that note, time for sleep.
07:07 darbelo plobsing: The one thing I've learned about this code is that if often looks very, very wrong.
07:07 chromatic Often because it is.
07:07 darbelo And it mostly is very, very wrong too.
07:08 darbelo So, you're probably right about that change ;)
07:09 masak joined #parrot
07:20 colomon_ joined #parrot
07:48 cotto joined #parrot
07:53 TiMBuS joined #parrot
08:03 colomon left #parrot
08:05 iblechbot joined #parrot
08:25 mikehh chromatic: did you get a chance to look at TT #1368?
08:27 fperrad joined #parrot
08:28 chromatic Can you revert the relevant parts of r42924 on HEAD and reproduce?
08:32 mikehh I'll give it a go after I take my grandsons to school - in an hour or so
08:34 mikehh I looked at r42924 and couldn't see anything that would cause the problem - I will play around with it
08:38 fperrad_ joined #parrot
08:49 wayland__ joined #parrot
09:20 bacek joined #parrot
10:13 mikehh chromatic: looks like it didn't like the change at line 54 and 74 - I reverted that and everything passes with gcc with --optimize and g++ with --optimize - AL:L tests PASS in both (inc fulltest)
10:14 mikehh commited at r43033
10:21 chromatic +    PMC    * const _class = Parrot_pcc_get_HLL(interp, CURRENT_CONTEXT(interp))
10:21 chromatic +                          ? Parrot_oo_get_class_str(interp, name)
10:21 chromatic +                          : PMCNULL;
10:21 chromatic ?
10:21 dalek parrot: r43033 | mikehh++ | trunk/src/ops/pmc.ops:
10:21 dalek parrot: partial reversion of r42924 in src/ops/pmc.ops to fix TT #1368
10:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43033/
10:23 chromatic For debugging fun, can you print the integer returned from Parrot_pcc_get_HLL()?
10:24 bacek joined #parrot
10:33 mikehh chromatic: yes - I running tests on everything else now
10:33 chromatic Thanks.
10:33 chromatic I'll backlog.  I have an idea; I'd hate to lose that performance improvement.
10:36 mikehh chromatic: I'll have a look in more detail after the release tomorrow - it only failed generally with gcc with --optimize (not testr) and g++ in testr on amd64
10:49 Zak joined #parrot
10:52 tewk_ T
11:26 TiMBuS joined #parrot
11:36 nopaste "Infinoid" at 173.75.243.182 pasted "More unhandled opengl header types" (46 lines) at http://nopaste.snit.ch/19073
11:38 Infinoid msg japhb It looks like they've added more types to my opengl headers yet again.  Would you mind taking a look at http://nopaste.snit.ch/19073 ?
11:38 purl Message for japhb stored.
11:43 dalek parrot: r43034 | gerd++ | trunk/NEWS:
11:43 dalek parrot: NEWS file update for version 1.9.0
11:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43034/
12:04 Infinoid NotFound: In r40354, you added a clause to runtime/parrot/library/pcre.pir to make it search for libpcre.so.3 if it failed to find libpcre.so.  That's awesome, but where did you get that filename from?
12:04 Infinoid On my gentoo box, libpcre-8.0.0 is installed as /lib64/libpcre.so.0.0.1 (symlinked as libpcre.so.0).  So I think the libpcre.so.3 must be from some other distro.
12:05 Infinoid If I add a similar clause for libpcre.so.0, I can effectively fix TT #578.  But I'm curious how brittle (or at least, distro-specific) this naming scheme is
12:06 Infinoid (not really a fix for TT #578, more of a workaround, but it gets the test passing for me)
12:12 bacek joined #parrot
12:40 bacek ~~
12:49 dalek parrot: r43037 | bacek++ | branches/context_unify3/src/call/args.c:
12:49 dalek parrot: Update merge_signature_for_tailcall.
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43037/
12:49 dalek parrot: r43038 | bacek++ | branches/context_unify3/src/sub.c:
12:49 dalek parrot: Put temporary workaround for context cycles.
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43038/
12:49 dalek parrot: r43039 | bacek++ | branches/context_unify3/src/ops/core.ops:
12:49 bacek *incoming*
12:49 dalek parrot: Fix op tailcall to merge proper signatures.
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43039/
12:49 dalek parrot: r43040 | bacek++ | branches/context_unify3/tools/build/nativecall.pl:
12:49 dalek parrot: Fix NCI builder to use CallContext directly
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43040/
12:49 dalek parrot: r43041 | bacek++ | branches/context_unify3/src (2 files):
12:49 dalek parrot: Pop context in NCI.invoke, not invoke_from_sigobject
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43041/
12:49 dalek parrot: r43042 | bacek++ | branches/context_unify3 (2 files):
12:49 dalek parrot: Factor out prepare_call function
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43042/
12:49 dalek parrot: r43043 | bacek++ | branches/context_unify3/src/ops/core.ops:
12:49 dalek parrot: Use pcc_prepare_call instead copy-pasted code.
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43043/
12:49 dalek parrot: r43044 | bacek++ | branches/context_unify3/src/ops/object.ops:
12:49 dalek parrot: Update callmethod(cc) to properly use CallContext.
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43044/
12:49 dalek parrot: r43045 | bacek++ | branches/context_unify3/src/pmc/continuation.pmc:
12:49 dalek parrot: Update passing results in Continuation.invoke
12:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43045/
12:49 dalek parrot: r43046 | bacek++ | branches/context_unify3/src/pmc/sub.pmc:
12:50 dalek parrot: Resurrect Sub.invoke's set of parent context to grand-parent.
12:50 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43046/
12:54 whiteknight joined #parrot
12:55 bacek msg chromatic context_unify3 failing only 2 tests in t/op/calling.t. Many other tests are failing with diagnostic "No such attribute 'expect'" in 'parrot;Test;Builder;ActivePlan;header'
12:55 purl Message for chromatic stored.
12:56 bacek msg chromatic I'm done for today (and probably rest of the week... :-/ )
12:56 purl Message for chromatic stored.
12:56 bacek G'Night everyone
12:56 naypalm night!
13:00 pjcj joined #parrot
13:06 payload joined #parrot
13:06 bacek erm...
13:06 bacek It's tomorrow now. So I probably reading some numbers wrong...
13:07 bacek But context_unfiy3 branch is 88% faster on examples/benchmarks/fib.pir comparing to trunk...
13:09 bacek anyway, $bedtime
13:09 pmichaud good morning, #parrot
13:20 whiteknight good morning pmichaud
13:21 whiteknight holy shit, 88%?
13:21 * whiteknight has to check out a copy ASAP
13:28 lucian joined #parrot
13:33 plobsing joined #parrot
13:33 Coke pmichaud: hio!
13:34 Coke bacek_at_work: context_unify3 fails to build for m.e
13:34 Coke msg bacek context_unify3 fails to build for me; dies during PGE.
13:34 purl Message for bacek stored.
13:41 payload joined #parrot
13:43 Coke pmichaud: you're up early.
13:43 Coke (oh wait, that's only one hour difference.
13:45 Coke pmichaud: got a second?
13:49 nopaste "coke" at 193.200.132.135 pasted "This new <integer> rule seems to be ignored." (54 lines) at http://nopaste.snit.ch/19074
13:52 Coke (with this patch, you can use incr to force the int conversion: {set a 3; incr a 33}
13:54 riffraff joined #parrot
13:55 JimmyZ joined #parrot
13:56 Coke if I can figure out why this isn't being used, I have a prayer of getting the sign bit working.
13:58 * Coke has a developer who just dumps his work into a branch with the log message "saving work"
13:58 * Coke sighs.
13:58 * Coke remembers he started a partcl-nqp blog post and never finished.
14:07 JimmyZ 88% faster?
14:08 moritz too good to be true :-)
14:09 JimmyZ Is it really true?
14:09 moritz JimmyZ: there's just one way to find out
14:11 JimmyZ moritz: I am waiting.
14:11 moritz JimmyZ: that's not what I meant :-)
14:13 moritz just try it out
14:16 particle should the parrot release manager guide be updated to include a step for updating external components like nqp-rx?
14:16 JimmyZ moritz: waiting for benchmark from some guys'
14:18 moritz particle: isn't that the job of the upstream maintainers?
14:19 moritz the numbers fluctuate here... in trunk parrot takes about 0.9s for fib.pir, in the branch 0.8s
14:19 JimmyZ particle: nqp-x has its own release cycles
14:19 particle i mean including the latest external resources in the parrot repo
14:19 moritz (both with --optimize)
14:19 particle if nqp-rx has a release before parrot, we should have the latest if possible
14:20 moritz let's just highlight pmichaud, maybe he has something to say about it
14:20 particle it's not the upstream maintainer's job to include his latest distro in our downstream source
14:20 JimmyZ 0.8/0.9
14:20 purl 0.888888888888889
14:21 JimmyZ 0.1/0.9
14:21 purl 0.111111111111111
14:21 JimmyZ not 88%, it's 11%
14:22 naypalm didn't realize --optimize made such a difference, 2.2s down to 0.8s
14:22 JimmyZ which is 2.2s?
14:22 naypalm both trunk, one without optimize
14:23 JimmyZ naypalm: branch is more faster, then
14:25 iblechbot joined #parrot
14:26 JimmyZ msg kid51 Could you take a look at TT #886?
14:26 purl Message for kid51 stored.
14:35 pmichaud back again
14:36 pmichaud I tend to keep nqp-rx updated in parrot trunk; I still need to see about getting regular release cycles for nqp-rx
14:37 fperrad pmichaud have you seen my last message ?
14:37 pmichaud fperrad: I'm still catching up on backlogs and the like
14:37 particle so is it too early to let the responsibility for including latest nqp-rx in parrot repo before release fall on the parrot release manager?
14:37 pmichaud I think I'd do it after tomorrow's release
14:38 particle ok
14:42 pmichaud Coke:  +token term:sym<integer> { 7+ }   # not the integer rule
14:43 pmichaud the integer rule is     token integer { 7+ }
14:43 pmichaud (and there isn't one in Tcl's grammar because it's being inherited from HLL::Grammar
14:43 pmichaud the term:sym<integer> rule is the one that parses an integer inside of expressions (i.e., as terms)
14:57 bluescreen joined #parrot
15:02 Andy joined #parrot
15:03 NotFound There are mentions of 'stage 1' and 'stage 0' compilers in NEWS. Someone mixed Winxed commit messages into parrot?
15:04 PacoLinux joined #parrot
15:07 davidfetter joined #parrot
15:14 bubaflub joined #parrot
15:17 JimmyZ joined #parrot
15:24 particle NotFound: probably nqp-rx, not winxed
15:25 NotFound particle: 'parser example' looks winxed.
15:25 particle well, anyway, it's gone.
15:31 bluescreen joined #parrot
15:32 particle does the libjit framebuilder work with current parrot? who knows this?
15:34 dalek parrot: r43047 | NotFound++ | trunk/runtime/parrot/library/pcre.pir:
15:34 dalek parrot: check for libpcre.so.0, TT #578
15:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43047/
15:34 dalek parrot: r43048 | particle++ | trunk/NEWS:
15:34 dalek parrot: [RELEASE] updates to NEWS language, dropping low-level items
15:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43048/
15:37 mikehh joined #parrot
15:39 Psyche^ joined #parrot
15:43 payload joined #parrot
15:50 jan joined #parrot
16:01 darbelo joined #parrot
16:14 jsut joined #parrot
16:21 particle plumage is in a separate repo, and not shipped with parrot, correct? why so much NEWS about it?
16:22 darbelo There was a plan to bundle it with parrot, like we do for nqp-rx. IIRC.
16:23 dalek parrot: r43049 | darbelo++ | trunk/src/library.c:
16:23 dalek parrot: Revert this change, _bufstart can differ from strstart here.
16:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43049/
16:23 darbelo But I don't think we're doing that yet.
16:23 japhb *pop* (groggily)
16:23 particle ok, so that news probably gets ripped out
16:23 particle hey there japhb
16:23 japhb What's going on now?
16:24 particle i'm reviewing NEWS for tomorrow's release
16:24 particle there's 6 or 8 lines about plumage
16:24 particle which isn't shipped with parrot
16:24 particle i don't think those items belong in parrot's NEWS file
16:24 japhb Ah.  I didn't put it there.  I'm checking to see what someone said
16:24 darbelo NotFound mentioned items from winxed (his HLL) going into NEWS, so it could be that someone based them on the dalek reports without proper filtering.
16:25 japhb Yeah, not a single line of that Plumage stuff should be there
16:25 particle ok, ripped out, committing now.
16:25 japhb Those are commit messages (out of an odd selection of commits, too)
16:26 particle r43050
16:27 japhb Thanks particle
16:35 payload joined #parrot
16:39 dalek parrot: r43050 | particle++ | trunk/NEWS:
16:39 dalek parrot: [RELEASE] more NEWS updates: removing unrelated plumage news, more lipstick
16:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43050/
16:39 dalek parrot: r43051 | particle++ | trunk/NEWS:
16:39 dalek parrot: [RELEASE] add disambiguating comma to NEWS item
16:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43051/
16:45 Coke pmichaud: ... thank you.
16:49 PerlJam joined #parrot
16:54 Coke pmichaud: hurm. so, how do I make an integer rule outside of a term create an int constant?
16:54 payload joined #parrot
16:55 Coke Past::Val() using a value of +$/ ?
16:57 Coke (nope, that's a capture...)
17:01 Coke hurm. I seem to be able to say {make 88} and have that work.
17:02 darbelo_ joined #parrot
17:05 Coke aha. SYN05 ftw. make +$/.Str;
17:17 Coke WHEE.
17:23 nopaste "coke" at 193.200.132.135 pasted "pmichaud: getting closer; this seems to work interactively, but global vars aren't getting incr'd properly now." (76 lines) at http://nopaste.snit.ch/19075
17:36 Coke got it.
17:50 Coke pmichaud: is HLL::Action's string_to_int from nqp-rx available in my actions?
17:53 Coke sigh. I will endeavor to keep ratcheting the time limit of questions up a bit so I find the answer before I ask here. =-)
17:56 PacoLinux joined #parrot
18:05 Coke I do wonder how I am introducing issues that change the return value of ./partcl
18:13 nopaste "coke" at 193.200.132.135 pasted "pmichaud: nearly there; for some reason this changes the exit value of ./partcl, though." (92 lines) at http://nopaste.snit.ch/19076
18:22 japhb pmichaud, ping
18:25 cotto_work joined #parrot
18:25 joeri joined #parrot
18:25 japhb Infinoid, ping
18:26 dukeleto 'ello
18:26 japhb Morning, dukeleto!
18:26 dukeleto japhb: how goes it? I missed the sunday meeting
18:26 japhb Pretty good.  The Sunday meeting was very good.
18:27 cotto_work afaict we're on a 3-month deprecation cycle now
18:27 japhb Felt like we all agreed on most things, and have plans for the rest ... none of which will get in the way of supporting Rakudo *, which is our big goal for the next 4-6 months.
18:28 * Coke wonders if return() is guaranteed to autobox to an int of 0.
18:28 japhb cotto_work, indeed ... though I don't know if the person who had the action item to update the docs has done so yet.
18:29 dalek winxed: r259 | julian.notfound++ | trunk/winxedst1.winxed:
18:29 dalek winxed: array initializers in stage 1
18:29 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=259
18:31 Coke apparently not. bother.
18:38 tewk_ plobsing?
18:38 purl hmmm... plobsing is part of our sanity injection framework
18:38 tewk_ purl thats not helpful
18:38 purl tewk_: sorry...
18:38 tewk_ email?
18:38 purl i guess email is for old people
18:39 joeri joined #parrot
18:39 darbelo_ plobsing is also probably canadian
18:39 purl okay, darbelo_.
18:39 darbelo_ tewk_: did dthat help ?
18:39 darbelo_ ;)
18:41 Coke pmichaud++
18:41 Coke PerlJam: I did task #1.
18:42 darbelo purl: plobsing is also plobsing@gmail.com
18:42 purl okay, darbelo.
18:42 darbelo tewk_: How about now? :)
18:43 tewk_ plobsing?
18:43 purl rumour has it plobsing is part of our sanity injection framework or probably canadian or mailto:plobsing@gmail.com
18:44 tewk_ I checked out CREDITS, but now purl is smarter too.
18:44 Infinoid japhb: pong
18:44 darbelo She has more facts, not really sure she's smarter.
18:45 dalek partcl-nqp: d5e5a68 | coke++ |  (6 files):
18:45 dalek partcl-nqp: Remove emacs boilerplate inherited from parrot
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/d5e5a682e555e97fd86a876bcfaa9131a79d4f68
18:45 dalek partcl-nqp: a5e894d | coke++ | src/Partcl.pir:
18:45 dalek partcl-nqp: command_line does not return something that is usable as an exit value.
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/a5e894d2a2d4ed33de096e4899f67418bc3ef7aa
18:45 dalek partcl-nqp: 71f0678 | coke++ | src/Partcl/commands/main.pm:
18:45 dalek partcl-nqp: force [incr] args to be ints (both the var and the value)
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/71f06784664dfb7acb11e96d9255981176d52c01
18:45 dalek partcl-nqp: d1a1ed9 | coke++ | src/ (3 files):
18:45 dalek partcl-nqp: Add some tcl-specific integer parsing and make it available outside expr.
18:45 dalek partcl-nqp: handle oct/hex/dec...
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/d1a1ed95b439e67a6c10b2565a8b60e1ae5eafc7
18:45 dalek partcl-nqp: f14e892 | coke++ | TODO:
18:45 dalek partcl-nqp: completed.
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/f14e8929ef40b529ba19e753b8c89bafe2eea899
18:45 dalek partcl-nqp: 06a6c07 | coke++ | build/Makefile.in:
18:45 dalek partcl-nqp: this test now passes.
18:45 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/06a6c079fab0b6abc85f25a6acf681ec7165cfa1
18:46 japhb Infinoid, Can you email me a tarball of your /usr/include/GL , so I can hack on your OpenGL configure problem?
18:47 Infinoid japhb: Gladly.  Sent.
18:47 japhb thx
18:48 Infinoid It's probably full of crazy gentoo breakage
18:48 Infinoid japhb++
18:51 Infinoid japhb: Hmm.  Looks like that had some symlinks into /usr/lib64.  I'll send an updated tarball that includes the link targets
18:51 japhb Infinoid, OK, thank you
18:52 japhb .oO( Why would anything in /usr/include have symlinks into /usr/lib* ...? )
18:53 Infinoid Gentoo likes to be able to switch opengl implementations on the fly.  Though it's not really "on the fly" if you have to recompile the app too, so I dunno.
18:53 japhb nodnod
18:53 * Infinoid did warn about crazy gentoo breakage :)
18:54 japhb True ...
19:04 japhb Oddly, the original tarball didn't arrive, but the new one has.  Looking at it now
19:19 japhb Infinoid, try r43052
19:22 dalek parrot: r43052 | japhb++ | trunk/config/gen/opengl.pm:
19:22 dalek parrot: [OpenGL] New typemaps; handle FGUNUSED properly
19:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43052/
19:34 Coke ... now I have a failure when running 'make test' that doesn't show when running with ./partcl foo.t
19:34 Coke odd.
19:35 Coke WOOF. rebuild. now the error shows with ./partcl but not make test.
19:37 whiteknight joined #parrot
19:39 Coke ah. LTM and hash randomization. fun.
19:39 whiteknight LTM?
19:39 purl it has been said that LTM is longest token matching
19:39 Coke (well, lack of LTM)
19:39 whiteknight ah, right
19:39 Coke I had a token of 0
19:39 Coke and it was occasionally hitting that instead of the octal rule for 00000012345
19:40 chromatic joined #parrot
19:41 theory joined #parrot
19:42 moritz so the integer rule shouldn't match leading 0, and delegate that to octal (for now)
19:44 Coke i just put 0 in as an alternation on <decimal> instead of having a separate <zed>
19:49 Coke incoming.
19:49 purl duck!
19:52 dalek partcl-nqp: c1106c9 | coke++ |  (4 files):
19:52 dalek partcl-nqp: booleans rules for [expr]; use in TclString. make '0' not conflict with octals.
19:53 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/c1106c9fbc4ac628a30e9524339d085a09cc94a8
20:01 riffraff joined #parrot
20:17 Infinoid japhb++: gen::opengl -         Generating OpenGL bindings.........................done.
20:19 Infinoid NotFound++: t/library/pcre.t ............................ ok
20:20 NotFound Infinoid: good
20:22 * Coke bounces!
20:24 lucian joined #parrot
20:27 Coke pmichaud: ping.
20:28 japhb Infinoid, yay!  Glad to hear it.
20:31 * Coke wonders how to get a .panic to include the string that caused the panic to match.
20:31 Coke [ $<err>=(\S+) <.panic: "list element in braces followed by $<err> instead of space"> ]?
20:31 Coke (the $<err> tehre does not interpolate)
20:37 darbelo tewk_: Good patches. I was about to do something similar last night, but Generating an actual PackFile instead of a string.
20:37 tewk_ darbelo, but you want a string?
20:38 darbelo tewk_: Well, not really. That string, well buffer, has a packfile header in it an a bunch of packfile-formatted data in it.
20:39 darbelo Might as well be honest about it and use a real packfile ;)
20:39 darbelo We do however have to keep returning a string for backwards compatibility.
20:40 darbelo But now that PackFiles are PMCs, there's not much of a point to storing this in string IMO.
20:40 tewk_ darbelo, but it doesn't have segments, maybe it should.
20:40 whiteknight we could be returning the PMCs instead of the strings within a deprecation cycle
20:42 tewk_ PackFiles of course have a toString right?
20:43 darbelo tewk_: PackFile PMCs do, it returns a string in a format similar to what freeze/thaw returns now.
20:45 tewk_ Sounds like the obvious right thing to do
20:47 whiteknight (do the right thing)++
20:49 darbelo That reminds me. I have a question: Should I be able to store INTVALs in a PackfileConstantTable PMC?
20:51 whiteknight can you not?
20:51 whiteknight I dont know a lot about those packfile PMCs yet
20:51 tewk_ darbelo, When you serialize something you have to tag it, Boxing primitive types aka tagging.
20:51 GeJ Good morning everyone
20:51 whiteknight good morning GeJ
20:53 GeJ Heya whiteknight. How are things going?
20:53 darbelo tewk_: Ah, boxing. I had missed that.
20:53 darbelo I guess it's PackfileRawSegment and manual storing, then.
20:53 whiteknight GeJ: Things are going well, thanks for asking. How are you?
21:00 GeJ I'm experiencing Murphy's Law at its best. So, things could be better.
21:15 riffraff joined #parrot
21:20 darbelo JoeSatriani1986
21:20 darbelo ww
21:30 dalek tapir: 426747b | dukeleto++ |  (2 files):
21:30 dalek tapir: Add a target to a hopefully temporarily Makefile for generating a pbc
21:30 dalek tapir: review: http://github.com/leto/tapir/commit/42​6747bda7ca1329e753e4e8c113e25843f05daf
21:34 bacek joined #parrot
21:35 bacek Good morning
21:36 japhb o/
21:36 darbelo \o
21:36 bacek I was wrong yesterday. It's only 15% improvements in context_unfiy3 branch...
21:37 darbelo 88% sounded too good to be true.
21:37 darbelo But 15% is still good.
21:37 cotto_work yes
21:41 NotFound darbelo++
21:41 darbelo Thanks, but what did I do?
21:42 NotFound Stimulate ;)
21:42 NotFound bacek++
21:42 darbelo ok ;)
21:42 bacek :)
21:45 bacek Coke, "make" doesn't work in context_unify3. "make corevm" does.
21:48 chromatic We can probably get more than 15% out of there.
21:49 bacek chromatic, "make it, make it right, make it fast". I'm still on step 2.
21:49 darbelo And it's already faster? bacek++
21:53 chromatic Sure, I'm not complaining.  I think it opens the door for other optimizations.
21:53 Coke bacek: ok.
21:53 chromatic I can imagine eking out another 10%.
21:53 * Coke wonders if he scared away pmichaud. =-)
21:54 bacek chromatic, yeah. We'll see.
21:56 dalek winxed: r260 | julian.notfound++ | trunk/winxedst1.winxed:
21:56 dalek winxed: hash initializer in stage 1
21:56 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=260
22:05 darbelo chromatic: ping
22:06 dalek parrot: r43053 | darbelo++ | trunk/DEPRECATED.pod:
22:06 dalek parrot: Correct and clarify the freeze/thaw deprecation notice.
22:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43053/
22:06 dalek parrot: r43054 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
22:06 dalek parrot: Aplly two cleanup patches by tewk++.
22:06 dalek parrot: This reduces poking into STRING internals and replaces the image STRING* with a Buffer.
22:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43054/
22:09 cotto_work Hmmm.  Is it going to cause pain to have pmc_freeze_cleanup and context_unify3 active at the same time?
22:10 chromatic I don't think so, no.
22:10 darbelo I doubt it, there's little potential for conflicts file-wise
22:10 Whiteknight joined #parrot
22:11 darbelo chromatic: You wanted to give ->bufused a macro, like bufstart and the other buffer fields, right?
22:12 chromatic I have that in a local git branch, but I don't want to do that before the release.
22:14 darbelo Cool, I waws going to suggest you put an example on the wiki and tell people to do it over time.
22:16 dalek winxed: r261 | julian.notfound++ | trunk/ (2 files):
22:16 dalek winxed: & and | operators in stage 1
22:16 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=261
22:23 chromatic Is there a Trac page for our 2.0 - 2.3 development priorities, or notes from the discussion yesterday?
22:23 darbelo Not yet, AFAIK.
22:24 cotto_work RecentChanges say no
22:26 patspam joined #parrot
22:30 dalek winxed: r262 | julian.notfound++ | trunk/t/intarray.t:
22:30 dalek winxed: fix a redeclared variable in a test
22:30 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=262
22:37 Zak joined #parrot
22:38 japhb pmichaud, ping
22:40 the_irrational_one joined #parrot
22:41 pmichaud japhb: pong
22:41 japhb Up for installer talk?
22:42 pmichaud I may get interrupted a fair bit
22:43 japhb Did you want to do it here or #perl6, or ...?
22:43 japhb And interrupted is fine by me
22:45 dalek winxed: r263 | julian.notfound++ | trunk/winxedst1.winxed:
22:45 dalek winxed: throw statement in stage 1
22:45 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=263
22:46 pmichaud either here or #perl6 is fine.  here might make more sense to begin with -- we can move to #perl6 if needed
22:46 davidfetter joined #parrot
22:46 bacek joined #parrot
22:47 japhb pmichaud, OK then.
22:48 japhb pmichaud, so what did you have in mind to talk about?
22:48 pmichaud my comments yesterday probably came across slightly more strongly than I intended; I was typing fast :)
22:48 japhb nodnod
22:48 japhb Understtod.
22:49 pmichaud that said, I'm not sure where plumage is likely to fit in the Perl 6 constellation
22:49 japhb pmichaud, OK, where do you see the Perl 6 module space going?
22:49 pmichaud since plumage currently appears to have a very strong Parrot affiliation, I'm not sure how that will work for a more general "Perl 6" installer
22:49 pmichaud but ultimately I think the answer for module installers is that it won't be decided from the top, but from the bottom
22:50 japhb Meaning someone will just create something different, and the Perl 6 people will wander off and use it?
22:50 pmichaud i.e., until there's a very complete working installer, it's unlikely that any will be annointed as "official"
22:50 japhb I can understand that
22:50 pmichaud and I have trouble thinking of "official" with respect to anything Perl 6
22:51 pmichaud i.e., people ask which compiler is the "official" compiler -- there isn't one
22:51 japhb Of course.
22:51 purl Indubitably.
22:51 pmichaud so if we say "which installer is the 'official' Perl 6 installer"..... the question itself doesn't quite work
22:51 japhb Mu.
22:51 pmichaud that's all I was really intending to say yesterday
22:52 japhb I guess I was concerned that there was active desire *not* to use Plumage, even if it was the bee's knees by the time Rakudo * came out.
22:52 pmichaud that concern was very reasonable, given my poorly quick-phrase
22:52 pmichaud *poorly worded
22:53 pmichaud clearly if it is the bee's knees by Rakudo*, we'll adopt it
22:53 pmichaud and I'd be very happy for that
22:53 japhb It sounds like the biggest concerns about it right now are: 1) It's not finished.  2) It's got strongish Parrot ties.
22:53 japhb OK, good to hear.
22:53 pmichaud those aren't even really "concerns" (more)
22:54 pmichaud we know that Rakudo* is going to have strongish ties to Parrot, it's okay for us to have an installer with strongish ties to Parrot as well
22:54 pmichaud what we have to be careful of is claiming that it's the official Perl 6 installer (interruption)
22:54 japhb nod
22:54 japhb Right, gotcha.
22:55 dalek parrot: r43055 | pmichaud++ | trunk/NEWS:
22:55 dalek parrot: [NEWS]:  nqp-rx, HLL::Compiler, and PDD31 updates
22:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43055/
22:55 dalek parrot: r43056 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
22:55 dalek parrot: Reduce packfile scope to the one place we need to use it.
22:55 dalek parrot: The PF_store_*() functions can explicitly handle a NULL argument for freeze/thaw.
22:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43056/
22:57 pmichaud (back)
22:58 japhb listening
22:58 pmichaud anyway, from a larger perspective, my feeling is that dealing with module installation issues is going to be a particularly thorny/challenging problem
22:58 japhb yes, quite
22:58 pmichaud I figure there will be quite a few false starts, and that's probably okay
22:59 japhb nod
23:00 japhb Is there a belief among any of the Perl 6 community that there either can or should be a "one Perl 6 installer" that runs on all implementations?
23:00 * moritz doesn't believe that, for now
23:00 pmichaud I'm sure there is such a belief, but I tend to want to dispell that notion
23:01 japhb moritz, *chuckle*
23:01 japhb OK
23:01 pmichaud I think there should be a Perl 6 installer that runs on all implementations.  But to say that there's "only one" is the part I disagree with.
23:01 pmichaud just like I think we shouldn't say there's "only one" Perl 6 compiler
23:02 pmichaud in general I think we should be talking about common specifications and targeted implementations
23:02 pmichaud so, for module sharing, we come up with some common specifications, but there can be many implementations
23:02 japhb The thing I'm thinking of is that examples all over the place start to use instructions for one particular installer, like cpan shell in the Perl 5 world, and that just becomes *assumed*
23:03 japhb I would certainly invite anyone interested in the space to come help the effort of working on the metadata spec, the rules and assumptions around it, any common APIs, etc.
23:04 japhb I'm trying to continually refactor Plumage in a way that it can be the first implementation of such a standard introspection and manipulation API.
23:04 pmichaud japhb: and an excellent job of it, too.  I'm extremely pleased that it's primarily written in NQP
23:04 pmichaud speaking of which, I owe plumage some NQP tuits
23:04 pmichaud I should be able to get to those today/tomorrow :)
23:05 * japhb brightens up ... oooh tuits!
23:05 japhb thanks in advance
23:05 pmichaud well, I finally got my hague grant finished, so that's no longer weighing me down as much
23:05 pmichaud opens up the space to work on a few other things a bit :)
23:05 japhb I've been putting effort into converting Glue.pir routines into Util.nqp.  Unfortunately, that's on a local branch, so you can't see it yet.
23:06 japhb I bet.
23:06 Zak joined #parrot
23:06 japhb Once I've got that as converted as I can, we should try to move the parts of Util.nqp that make sense into NQP::Util in the NQP-rx repo, as we'd discussed before.
23:07 japhb (I'm positive I'll have questions for you while I work)
23:07 japhb So.
23:07 pmichaud sounds good to me.  I'm still thinking a bit about how that ends up being structured :)
23:07 japhb Back to the main topic.
23:08 japhb So ... how do you suggest I engage the Perl 6 people into working with me on this grand installer API project?
23:09 japhb I literally can't keep up with #perl6 backlogs (I don't even try any more), so that's right out.
23:09 japhb And stopping by every so often doesn't seem to get any traction.
23:09 japhb A couple people recognize the Plumage name now, that's about it.
23:09 pmichaud well, mainly people need to see progress, documentation, and how they can start using it
23:10 pmichaud if plumage's goal is to replace proto, then seeing examples of how one can use plumage today to do proto-like things would be a start
23:10 japhb Yesterday in the big #ps meeting it was suggested to start blogging on blogs.perl.org, with a feed into Planet Parrot.  Are either of those places watched by Perl 6 folks?
23:10 pmichaud yes
23:10 japhb pmichaud, Ah, that's a good idea
23:11 * japhb watches more hours of free time twinkle out of existence
23:11 japhb :-)
23:11 pmichaud I suspect one of the bigger stumbling blocks to participation may be plumage's requirement for a parrot cla
23:12 pmichaud but your biggest source of contributors will likely come from people who are writing Perl 6 modules and want to distribute them or make others aware of the modules' existence
23:12 japhb That was a requirement from Allison, IIRC, to make it easier to bring in Plumage to Parrot.  But if plumage goes the ext/ route like nqp-rx, is that still an issue?
23:12 pmichaud (and applications, perhaps)
23:13 * japhb 's understanding of copyright law is "just enough to be dangerous to self and others"
23:13 pmichaud I don't know how plumage's licensing would work out... and I'm not really the one to make that decision
23:13 japhb Well, how does the licensing and copyright work with nqp-rx?
23:14 pmichaud well, nqp-rx is currently held by the Perl Foundation, and whatever other contributors may be there
23:14 pmichaud it's released under the AL2
23:14 pmichaud Parrot then chooses to release a version of nqp-rx as part of its distribution
23:15 japhb ... as is Parrot and Plumage, so the license itself is not an issue.
23:15 japhb Do nqp-rx contributors have to do a Perl Foundation CLA?
23:15 pmichaud not currently, although Rakudo contributors do
23:16 japhb Hmmm.  Is there anyone who contributes to nqp-rx who is not also a Rakudo contributor?
23:16 pmichaud there is an awful lot of details to be worked out in making the distinction between copyrights on individual components and copyrights on distributions (from a TPF and PaFo perspective)
23:17 japhb Is work progressing on that, or is it tabled for now?
23:17 moritz japhb: there's a commit by Coke++, don't think he's a Rakudo committer
23:17 pmichaud oh, Coke++ is certainly a rakudo committer
23:17 japhb It almost feels like TPF and PaFo need some sort of cross-license agreement in place, so we can stop worrying about who is CLA'd to whom.
23:18 pmichaud that's not the licensing that I'm thinking of
23:19 pmichaud it's not cross-licensing between tpf and pafo, it's the "Rakudo * wants to distribute a module written by Betty Author, who hasn't signed a CLA"
23:19 pmichaud somehow I don't think we want our distributions (with batteries) to be limited to those modules for which we have CLAs.  Maybe that's possible, but that doesn't seem like the right model to me.
23:19 japhb (a CLA to either one, I assume you mean)
23:19 pmichaud right
23:20 pmichaud it would be like Debian or Ubuntu or RedHat having to get license agreements from every contributor to every project included in the distribution.
23:20 japhb Part of the whole original "we have a real ecosystem" plan is that we could separate the core, copyright one team, from everything above it, copyright who knows
23:20 japhb right, understood
23:21 pmichaud so, Rakudo (the compiler) requires a CLA, while Rakudo * (the distribution) may not require a CLA for all of its components
23:21 japhb So then it's just a matter of formalizing when Parrot or Rakudo core is being talked about, and when it's the Parrot or Rakudo Distribution
23:21 japhb nodnod
23:22 Tene So Rakudo * is a distribution of Rakudo, in chromatic's sense of Perl 5 Distributions.
23:22 pmichaud Yes.
23:22 pmichaud In the sense of Strawberry Perl, and the like, also.
23:23 Tene That does suggest that there will be versions of *
23:23 pmichaud there will.
23:23 Tene Okay.  I think I like it.
23:23 pmichaud I'm also expecting Rakudo * to have its own release cycle
23:23 pmichaud and likely its own release managers
23:23 japhb OK, so maybe Plumage is just in the Parrot Distro, not Parrot itself, so we can drop the CLA requirement.
23:23 pmichaud the compiler will continue with a monthly release cycle
23:23 pmichaud the distribution will probably go with a quarterly release cycle to begin wtih
23:24 pmichaud (although we might do monthly at first, if there appears to be a rapid convergence or development needed)
23:25 pmichaud but my vision is that distributions take place on a slightly longer time cycle, since they have more stability requirements.  The compiler continues to press forward on its own timescale, without being dragged down by stability issues.
23:25 japhb sounds good
23:25 pmichaud each distribution release would choose whatever compiler release is most appropriate for that release
23:26 pmichaud also, unlike Perl 5's traditional model, I think we have to start separating the "compiler manager" role from the "distribution manager" role
23:27 Tene Ooo, I like that too.
23:27 japhb yes, and I think chromatic has suggested that for the future of Perl 5 as well.
23:27 pmichaud watching Perl 5's issues over the summer has been particularly instructive
23:28 pmichaud and yes, I'd very much like to see P5 head in that direction, although they have a lot of inertia to overcome
23:28 pmichaud (which just means it's hard, not that P5 won't do it :-)
23:29 pmichaud when we switched Parrot from the p5-like pumpking role to the release-manger process we have today, there was a fair bit of pain and initial effort involved, iirc.  (particle++ chromatic++ others++)  Doing the same for something as big and mature as P5 seems... like a lot of work.
23:29 pmichaud *manager
23:29 japhb Still, they did manage to switch to monthly releases, so hope springs eternal
23:29 japhb :-)
23:29 pmichaud right
23:30 pmichaud and the fact that Parrot did so (with great success) has I think helped many of the p5 leaders see the value and possibility of doing so with p5
23:30 japhb nodnod
23:30 japhb So ... back on the CLA thing for a minute, I'd love to toss that requirement, but I don't know who to discuss that with.
23:31 japhb Who can give me an answer I can rely on?
23:31 darbelo japhb: allison, chromatic, particle, people on the PaFo board.
23:32 pmichaud well, the main thing is determining where plumage is going to fit in the perl 6 / rakudo / parrot ecosystem
23:32 japhb darbelo, pmichaud is on the PaFo board. ;-)
23:32 japhb pmichaud, ah, and here we come full circle
23:32 pmichaud and then decide what licensing arrangements are best for the components involved
23:32 pmichaud I don't see any issue with requiring cla's for plumage to begin with, and then eventually relaxing that requirement if we see that it's a blocker
23:34 japhb I've got the typical hacker mentality: I want my code to be of the most use to the most people possible.  But I've been finding myself rather frustrated that I can't get enough help to build momentum as fast as I like (there's some, and I'm happy about that, but mental integration says that I need to get more contributors to get where I want to by by Rakudo *)
23:34 japhb So if the CLA is a blocker to contributors, that's a pain point for me.
23:34 pmichaud from here, it doesn't seem to me like it's (yet) your primary blocker
23:34 japhb OK, that's good to hear
23:35 pmichaud I'd suggest going with my earlier item -- get some people actually using plumage
23:35 pmichaud that will help drive its requirements a lot better
23:36 pmichaud that's been our experience in Rakudo, at least -- the thing that brings the most hackers to the table is them trying to use Rakudo for something else :)
23:36 japhb A few people are, and people like fperrad++ have been very helpful in that area.  But mostly they are Parrot people, very few Perl 6 people.
23:36 * chromatic likes when people reuse his metaphors and descriptions
23:38 japhb I wonder if I need to start doing the thing fperrad was doing for his distutils stuff ... just finding every Parrot project he could, doing the conversion work for them, and sending them a patch.  That's a lot of effort, but it has seemed to work for him ....
23:38 * japhb trying to find best places to spend tuits for maximum effect.
23:38 pmichaud yes
23:39 pmichaud also perhaps interview masak for his experience and ideas (I suspect you've already done this, though?)
23:39 japhb I have tried, but with mixed success.  He seems very distracted of late.
23:39 japhb And a couple of times he just passed off to mberends, who never responded.  :/
23:39 pmichaud we're all pretty busy :)
23:40 japhb I'm sure!
23:40 moritz japhb: I've never seen a signal like "plumage is very close to distribute Perl 6 modules" or something along these lins
23:40 moritz *lines
23:40 moritz japhb: if I had, I might be much more interested
23:40 japhb Oh wow.  Serious miscommunication then.
23:41 japhb Huh.
23:41 * japhb momentarily flummoxed
23:41 moritz so, what can plumage do to help distributing Perl 6 modules?
23:42 japhb It's like proto, but more powerful.
23:42 moritz so it can track dependencies, download modules for me...
23:42 japhb (Along a number of axes)
23:42 japhb yup
23:42 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30922), fulltest) at r43056 - Ubuntu 9.10 amd64 (gcc with --optimize)
23:42 kid51 joined #parrot
23:42 moritz japhb: then it's really a communication problem
23:42 dalek winxed: r264 | julian.notfound++ | trunk/winxedst1.winxed:
23:42 dalek winxed: handle new arguments in stage 1
23:42 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=264
23:43 moritz japhb: if I were you, I'd send a mail to perl6-users, announcing plumage support for Perl 6 modules
23:43 darbelo moritz: It completely automates the fetch-build-test-install cycle, with dep-handling for every step.
23:43 moritz japhb: include the sample input/output for downloading a Perl 6 modules
23:44 moritz *module
23:44 moritz and call for testers, users, whatever
23:44 japhb The only thing that kept me from presenting it as a fait accompli to the #perl6 crowd is that I wanted to have all of the info on proto projects imported into the Plumage metadata repo; and it turned out that wasn't doable at the time because too many projects assumed non-install-based proto -- since the installed-modules branch had not lanfded
23:44 moritz have you imported proto's project.list or so?
23:44 moritz ok
23:45 moritz japhb: asked differently - if I wanted plumage support for my json module, what do I have to do?
23:45 japhb But maybe given the above I just need to include patches for everyone that make their project work when installed
23:45 japhb Write a Plumage metadata file (in JSON) for it.  Send me that file.  You're done./
23:46 moritz where is the metadata file format documented?
23:46 japhb If it turns out that your module has a build step not yet supported by Plumage, I will add it.
23:46 pmichaud (making announcement/fait accompli)  the major thing I'd want to achieve is to get a good handle on managing expectations (more)
23:47 moritz japhb: the only thing that JSON needs is "copy all *.pm below lib/ to ~/.perl6/lib"
23:47 pmichaud there will be any number of pepole who will say "it doesn't solve xyz problem", "this isn't what we expected", "it's inadequate for our needs", etc.  That's true for Perl 6 as well.  The thing to do is to say "we're getting the pieces to work that we can, and explicitly postponing some of the hard issues to later"
23:48 japhb moritz,  http://trac.parrot.org/parrot/wiki​/ModuleEcosystem#MetadataProposal was the original, it is now a bit out of date (people are using the existing metadata files as examples, or using setup.pir to produce one automatically for them), so in #ps I was asked to update that.  It's on my short list.
23:48 pmichaud the main difference between plumage and proto in this regard is (I think) that proto explicitly planned its obsolesence, while plumage seems to want to have a longer lifespan :)
23:48 japhb pmichaud, understood.  I'll mark it at the top of my list to manage the expectations.  ;-)
23:48 japhb ... all in caps no less
23:49 Tene The big question, re plumage / HLL, is about compat with existing HLL library systems.
23:49 dalek tracwiki: v16 | jkeenan++ | AllHackathons
23:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki/All​Hackathons?version=16&amp;action=diff
23:49 dalek tracwiki: v136 | jkeenan++ | WikiStart
23:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=136&amp;action=diff
23:50 moritz japhb: will take a look at it tomorrow (nearly 1am here). If I don't get back to you soon, feel free to bother me again
23:50 japhb moritz, OK, will do
23:50 cotto_work clock?
23:50 purl cotto_work: LAX: Mon 3:50pm PST / CHI: Mon 5:50pm CST / NYC: Mon 6:50pm EST / LON: Mon 11:50pm GMT / BER: Tue 12:50am CET / IND: Tue 5:20am IST / TOK: Tue 8:50am JST / SYD: Tue 10:50am EST /
23:50 kid51 make fulltest:  PASS on Linux/i386 at r43027
23:50 japhb Tene, meaning, working with LuaRocks, RubyGems, et al.?
23:51 Tene Yeah.  If we want to work with existing HLLs, should we really be trying to co-opt that?  Maybe HLL implementations should provide some information to plumage about their "native packaging tool"?
23:52 japhb Plumage is able to drive other systems.
23:52 japhb It already can handle driving a Perl 5 style Makefile.PL system, fperrad's parrot distutils system, etc.
23:52 japhb It's easy to add new external systems.
23:52 Tene Right, right, I remember now.
23:53 Tene Thanks for indulging me. :)
23:54 japhb What it currently *can't* do (but I am considering adding over time) is query the other-HLL tools to gather data (such as dependency resolution info) to make it easier to write Plumage metadata that Just Works.
23:54 Zak joined #parrot
23:54 Tene Should that go into plumage, or should that go into the HLL implementation, as part of the inter-hll api?
23:55 japhb Tene, that's a good question.
23:55 Tene that is, pynie supports plumage, not the other way around.
23:56 Tene that would be my preference, I expect.
23:56 japhb fperrad is pushing hard on turning the simplistic dependency solver in Plumage into a real, industrial strength dep solver.  Which kindof implies being able *somehow* to get foreign dep info.  But whether plumage ships that code, or the HLLs do, is not really critical to me right now.
23:56 * Tene nods.
23:58 japhb Anyone else have thoughts on Plumage and related items?
23:59 Tene Yes, it looks like we should be able to get that information through the cross-HLL API.
23:59 Tene I'll add research into that into my thoroughly-neglected TODO
23:59 japhb heh
23:59 kid51 Is there anything equivalent to Devel::Cover in NQP yet?

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

Parrot | source cross referenced