Parrot 1.8.0 Zygodactyly released | Online Parrot Roadmap Meeting: Sunday 13 December, 20:30 UTC on #parrotsketch
Set by moderator on 13 December 2009.
00:00 bacek joined
dalek rtcl-nqp: 3dbbb2b | coke++ | src/class/tcllist.pir:
remove unused methods copied over from partcl
 00:06
pmichaud Tene: src/HLL/Compiler.pm 00:07
also a new pdd31 draft
Tene: I just added these Friday and yesterday.
(to complete my grant)
Tene: comments, patches welcomed 00:08
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
but I'm also wanting to use this as a chance to re-think some of our compiler interfaces, such as the staging interface
and to hopefully bring in some generic getopts-style processing
00:11 Zak joined
Coke pmichaud: hey, do you have than unknown patch lying about? 00:24
pmichaud Coke: oh yeah, I didn't commit it. Hmmm.
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.
nopaste "pmichaud" at 66.25.4.52 pasted "unknown patch for Coke++" (27 lines) at nopaste.snit.ch/19071
japhb pmichaud, got a couple to talk about the Perl 6 installer space? (Or should I take this to #perl6?) 00:26
00:26 payload joined
pmichaud japhb: alas, I have to take care of family's dinner here (because we ran a bit long) 00:27
japhb: but I'll be most happy to reserve time to talk about it with you
japhb pmichaud, OK. But please do ping me at some point, because I'd like to ... yes, thank you
pmichaud tonight might be tricky; is there a specific time tomorrow that would be good?
japhb thinks
pmichaud or do you just want me to catch you online?
I'll be around quite a bit over the next few days 00:28
japhb yes, that would probably be best
ok, great
Tene, still around?
pmichaud okay, we'll do that. if it looks like I've forgotten about it, ping/bump me
japhb Ok, great, thank you.
pmichaud I'd very much like to discuss it with you, it will likely turn into a blog article
japhb nodnod
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)
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
nopaste "coke" at 193.200.132.135 pasted "for pmichaud" (41 lines) at 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, abqar joined 01:02 colomon_ joined
Whiteknight excellent planning meeting today 01:07
everybody++
go team!
Infinoid Whiteknight: Ok. I can give you the Pipe primitives pretty easily, and leave the FileHandle.open refactor as a separate task 01:13
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
dalek rrot: r43029 | plobsing++ | trunk/include/parrot/pmc_freeze.h:
remove unused mark_ptr element from visit_info
 01:38
01:40 JimmyZ joined
plobsing can someone explain why we need TT#1305? 02:05
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.
Ryan52 the next parrot release is in 2 days, right? and then the one after it is "stable", right?
plobsing I am feeling the constant urge to kill it with fire 02:07
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
plobsing my first goal is usable from pir
i think the others fall out from there
Whiteknight yeah, definitely 02:10
plobsing So I can rip them out ASAP if I've got a reasonable replacement? 02:11
thats what I really want to know 02:12
Whiteknight make a branch, but yeah 02:14
dalek rrot: r43030 | plobsing++ | branches/pmc_freeze_cleanup:
create branch for freeze/thaw/visit subsystem refactoring
 02:43
02:46 kid51 joined
kid51 plobsing: darbelo was looking closely at src/pmc_freeze.c yesterday. See chart in trac.parrot.org/parrot/wiki/PreDece...eHackathon 02:47
moderator Parrot 1.8.0 Zygodactyly released | Parrot 1.9.0 to be released Tues 15 Dec 02:49
Coke (*&$#. 03:06
this generated PIR is SO verbose.
Makes it very difficult to track down problems when my NQP doesn't work.
03:12 jsut_ joined
Coke pmichaud, Tene: NQP and rakudo seem to be catching a return inside a try. That should be let through, shouldn't it? 03:27
04:13 bacek joined 05:31 darbelo joined
darbelo plobsing: ping 05:32
plobsing pong
darbelo I see you created a branch for cleaning up the yakhole^W^W freeze/thaw, is there anyway I can help there? 05:33
plobsing there's so much concentrated evil there. where to begin... 05:34
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
plobsing I saw the ticket you made.
why does it need to live?
doesn't it all fall under "internal datastructures"?
darbelo The deprecation policy says we can't chance 'user facing interfaces' without previous notice in DEPRECATED.pod 05:36
05:36 mikehh joined
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.
plobsing I see. 05:38
darbelo let me get you an example.
code.google.com/p/decnum-dynpmcs/so...ext.pmc#95 05:39
Sorry, visit_info, not image_io
plobsing example is good. 05:40
I want to change both. 05:41
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
dalek rrot: r43031 | plobsing++ | branches/pmc_freeze_cleanup (24 files):
Merge image_io and visit_info.

of this subsystem deals with (and what should become a PMC). Add get_integer vtable interface to replace visit_info.what.		 05:43
chromatic #define visit_info PMC 05:44
plobsing thats the eventual goal
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.
darbelo plobsing: I do like that ;)
But, "struct PackFile *pf" can die now. It's 'unused' out of the function that creates it. 05:46
chromatic: Really? Ok. 05:47
chromatic Just a thought.
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.
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
darbelo++ 05:50
chromatic Punt later.
particle gets back to gin&tonic-making & 05:51
Coke wonders if timtowdi.org is gone.
darbelo plobsing: Looks like green light to me. Start poring fire! 05:54
plobsing woot! full steam ahead! 05:55
darbelo I've checked out the branch and I'm removing the packfile member from the structure. 05:56
plobsing darbelo++ 05:57
darbelo I removed it from the structure and reduced it's scope to the one function that uses it. 05:59
But I'm not sure why we're using it there at all. 06:00
I'm seriously wondering what's the point of copying that header to the string. 06:03
plobsing In theory, it should give us portability accross platforms. 06:04
I doubt that actually happens though 06:05
darbelo Looking at the way we store INTVALs there. We can't be portable.
Hm. I'm looking at this wrong. 06:07
We should ditch the STRING and create a PackFile.
That format is supposed to be portable, and we are already using the PF_* functions for storing stuff. 06:08
plobsing yes, that would be best. It makes TT #1359 a lot easier. 06:09
darbelo Reading ticket.. 06:10
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.
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:13
Coke has an nqp question... 06:15
. o O (man is this frustrating.) 06:29
darbelo Not unexpected, but PackFile code is damm ugly in places. 06:30
Also, we store things in platform-specific fromats and then convert them when reading. 06:35
That looks backwards to me. 06:36
plobsing how so? 06:37
darbelo The on-disk format changes from machine to machine. It stored in 'platform-native' format. 06:38
plobsing the common case is fast - if the writer and the reader are the same machine, no conversion occurs IIRC 06:39
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?
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.
validation tools need to be dumb, so that there is no way to get them wrong. 06:43
plobsing good point.
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.
purl Message for pmichaud stored.
bacek_at_work darbelo, 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 ''
purl Message for pmichaud stored.
bacek_at_work darbelo, I'm pushing for changing PBC format for quite long time already...
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)
purl Message for pmichaud stored.
chromatic I don't know if that truly works, or if we have to perform fixups on the PBC after loading.
bacek_at_work chromatic, and load annotations, etc, etc, etc. 06:50
darbelo I'm pretty sure we don't actually do that.
chromatic Perform fixups or mmap? 06:51
darbelo mmap()
chromatic I know we don't.
Dan wanted to for a very long time. 06:52
darbelo We should decide wether to do that or go with TT#451, then. 06:54
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:55
That way we don't block portable PBC on future optimizations which may not take place until ... THE FUTURE. 06:56
darbelo True, but I'm going off target here. I'm supposed to make 2003's "THE FUTURE" happen for pmc_freeze. 06:57
chromatic I have a bias for platform-independent formats here. 06:58
dalek rrot: r43032 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc (2 files):
change all external accesses to visit_info.what to use get_integer

well ... I'm not quite sure what it does, but it seems very, very wrong.		 07:04
purl dalek: that doesn't look right
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.
chromatic Often because it is.
darbelo And it mostly is very, very wrong too.
So, you're probably right about that change ;) 07:08
07:09 masak joined 07:20 colomon_ joined 07:48 cotto joined 07:53 TiMBuS joined 08:03 colomon left 08:05 iblechbot joined
mikehh chromatic: did you get a chance to look at TT #1368? 08:25
08:27 fperrad joined
chromatic Can you revert the relevant parts of r42924 on HEAD and reproduce? 08:28
mikehh I'll give it a go after I take my grandsons to school - in an hour or so 08:32
I looked at r42924 and couldn't see anything that would cause the problem - I will play around with it 08:34
08:38 fperrad_ joined 08:49 wayland__ joined 09:20 bacek joined
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:13
commited at r43033 10:14
chromatic + PMC * const _class = Parrot_pcc_get_HLL(interp, CURRENT_CONTEXT(interp)) 10:21
+ ? Parrot_oo_get_class_str(interp, name)
+ : PMCNULL;
?
dalek rrot: r43033 | mikehh++ | trunk/src/ops/pmc.ops:
partial reversion of r42924 in src/ops/pmc.ops to fix TT #1368
chromatic For debugging fun, can you print the integer returned from Parrot_pcc_get_HLL()? 10:23
10:24 bacek joined
mikehh chromatic: yes - I running tests on everything else now 10:33
chromatic Thanks.
I'll backlog. I have an idea; I'd hate to lose that performance improvement.
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:36
10:49 Zak joined
tewk_ T 10:52
11:26 TiMBuS joined
nopaste "Infinoid" at 173.75.243.182 pasted "More unhandled opengl header types" (46 lines) at nopaste.snit.ch/19073 11:36
Infinoid msg japhb It looks like they've added more types to my opengl headers yet again. Would you mind taking a look at nopaste.snit.ch/19073 ? 11:38
purl Message for japhb stored.
dalek rrot: r43034 | gerd++ | trunk/NEWS:
NEWS file update for version 1.9.0
 11:43
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
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.
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:05
(not really a fix for TT #578, more of a workaround, but it gets the test passing for me) 12:06
12:12 bacek joined
bacek ~~ 12:40
dalek rrot: r43037 | bacek++ | branches/context_unify3/src/call/args.c:
Update merge_signature_for_tailcall.
 12:49
rrot: r43038 | bacek++ | branches/context_unify3/src/sub.c:
Put temporary workaround for context cycles.
rrot: r43039 | bacek++ | branches/context_unify3/src/ops/core.ops:
Fix op tailcall to merge proper signatures.
bacek *incoming*
rrot: r43040 | bacek++ | branches/context_unify3/tools/build/nativecall.pl:
Fix NCI builder to use CallContext directly
rrot: r43041 | bacek++ | branches/context_unify3/src (2 files):
Pop context in NCI.invoke, not invoke_from_sigobject
rrot: r43042 | bacek++ | branches/context_unify3 (2 files):
Factor out prepare_call function
rrot: r43043 | bacek++ | branches/context_unify3/src/ops/core.ops:
Use pcc_prepare_call instead copy-pasted code.
rrot: r43044 | bacek++ | branches/context_unify3/src/ops/object.ops:
Update callmethod(cc) to properly use CallContext.
rrot: r43045 | bacek++ | branches/context_unify3/src/pmc/continuation.pmc:
Update passing results in Continuation.invoke
rrot: r43046 | bacek++ | branches/context_unify3/src/pmc/sub.pmc:
Resurrect Sub.invoke's set of parent context to grand-parent.
12:54 whiteknight joined
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.
bacek msg chromatic I'm done for today (and probably rest of the week... :-/ ) 12:56
purl Message for chromatic stored.
bacek G'Night everyone
naypalm night!
13:00 pjcj joined 13:06 payload joined
bacek erm... 13:06
It's tomorrow now. So I probably reading some numbers wrong...
But context_unfiy3 branch is 88% faster on examples/benchmarks/fib.pir comparing to trunk... 13:07
anyway, $bedtime 13:09
pmichaud good morning, #parrot
whiteknight good morning pmichaud 13:20
holy shit, 88%? 13:21
whiteknight has to check out a copy ASAP
13:28 lucian joined 13:33 plobsing joined
Coke pmichaud: hio! 13:33
bacek_at_work: context_unify3 fails to build for m.e 13:34
msg bacek context_unify3 fails to build for me; dies during PGE.
purl Message for bacek stored.
13:41 payload joined
Coke pmichaud: you're up early. 13:43
(oh wait, that's only one hour difference.
pmichaud: got a second? 13:45
nopaste "coke" at 193.200.132.135 pasted "This new <integer> rule seems to be ignored." (54 lines) at nopaste.snit.ch/19074 13:49
Coke (with this patch, you can use incr to force the int conversion: {set a 3; incr a 33} 13:52
13:54 riffraff joined 13:55 JimmyZ joined
Coke if I can figure out why this isn't being used, I have a prayer of getting the sign bit working. 13:56
Coke has a developer who just dumps his work into a branch with the log message "saving work" 13:58
Coke sighs.
Coke remembers he started a partcl-nqp blog post and never finished.
JimmyZ 88% faster? 14:07
moritz too good to be true :-) 14:08
JimmyZ Is it really true? 14:09
moritz JimmyZ: there's just one way to find out
JimmyZ moritz: I am waiting. 14:11
moritz JimmyZ: that's not what I meant :-)
just try it out 14:13
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'
moritz particle: isn't that the job of the upstream maintainers? 14:18
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
particle i mean including the latest external resources in the parrot repo
moritz (both with --optimize)
particle if nqp-rx has a release before parrot, we should have the latest if possible
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
JimmyZ 0.8/0.9
purl 0.888888888888889
JimmyZ 0.1/0.9 14:21
purl 0.111111111111111
JimmyZ not 88%, it's 11%
naypalm didn't realize --optimize made such a difference, 2.2s down to 0.8s 14:22
JimmyZ which is 2.2s?
naypalm both trunk, one without optimize
JimmyZ naypalm: branch is more faster, then 14:23
14:25 iblechbot joined
JimmyZ msg kid51 Could you take a look at TT #886? 14:26
purl Message for kid51 stored.
pmichaud back again 14:35
I tend to keep nqp-rx updated in parrot trunk; I still need to see about getting regular release cycles for nqp-rx 14:36
fperrad pmichaud have you seen my last message ? 14:37
pmichaud fperrad: I'm still catching up on backlogs and the like
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?
pmichaud I think I'd do it after tomorrow's release
particle ok 14:38
pmichaud Coke: +token term:sym<integer> { 7+ } # not the integer rule 14:42
the integer rule is token integer { 7+ } 14:43
(and there isn't one in Tcl's grammar because it's being inherited from HLL::Grammar
the term:sym<integer> rule is the one that parses an integer inside of expressions (i.e., as terms)
14:57 bluescreen joined 15:02 Andy joined
NotFound There are mentions of 'stage 1' and 'stage 0' compilers in NEWS. Someone mixed Winxed commit messages into parrot? 15:03
15:04 PacoLinux joined 15:07 davidfetter joined 15:14 bubaflub joined 15:17 JimmyZ joined
particle NotFound: probably nqp-rx, not winxed 15:24
NotFound particle: 'parser example' looks winxed. 15:25
particle well, anyway, it's gone.
15:31 bluescreen joined
particle does the libjit framebuilder work with current parrot? who knows this? 15:32
dalek rrot: r43047 | NotFound++ | trunk/runtime/parrot/library/pcre.pir:
check for libpcre.so.0, TT #578
 15:34
rrot: r43048 | particle++ | trunk/NEWS:
[RELEASE] updates to NEWS language, dropping low-level items
15:37 mikehh joined 15:39 Psyche^ joined 15:43 payload joined 15:50 jan joined 16:01 darbelo joined 16:14 jsut joined
particle plumage is in a separate repo, and not shipped with parrot, correct? why so much NEWS about it? 16:21
darbelo There was a plan to bundle it with parrot, like we do for nqp-rx. IIRC. 16:22
dalek rrot: r43049 | darbelo++ | trunk/src/library.c:
Revert this change, _bufstart can differ from strstart here.
 16:23
darbelo But I don't think we're doing that yet.
japhb *pop* (groggily)
particle ok, so that news probably gets ripped out
hey there japhb
japhb What's going on now?
particle i'm reviewing NEWS for tomorrow's release 16:24
there's 6 or 8 lines about plumage
which isn't shipped with parrot
i don't think those items belong in parrot's NEWS file
japhb Ah. I didn't put it there. I'm checking to see what someone said
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.
japhb Yeah, not a single line of that Plumage stuff should be there 16:25
particle ok, ripped out, committing now.
japhb Those are commit messages (out of an odd selection of commits, too)
particle r43050 16:26
japhb Thanks particle 16:27
16:35 payload joined
dalek rrot: r43050 | particle++ | trunk/NEWS:
[RELEASE] more NEWS updates: removing unrelated plumage news, more lipstick
 16:39
rrot: r43051 | particle++ | trunk/NEWS:
[RELEASE] add disambiguating comma to NEWS item
Coke pmichaud: ... thank you. 16:45
16:49 PerlJam joined
Coke pmichaud: hurm. so, how do I make an integer rule outside of a term create an int constant? 16:54
16:54 payload joined
Coke Past::Val() using a value of +$/ ? 16:55
(nope, that's a capture...) 16:57
hurm. I seem to be able to say {make 88} and have that work. 17:01
17:02 darbelo_ joined
Coke aha. SYN05 ftw. make +$/.Str; 17:05
WHEE. 17:17
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 nopaste.snit.ch/19075 17:23
Coke got it. 17:36
pmichaud: is HLL::Action's string_to_int from nqp-rx available in my actions? 17:50
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:53
17:56 PacoLinux joined
Coke I do wonder how I am introducing issues that change the return value of ./partcl 18:05
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 nopaste.snit.ch/19076 18:13
japhb pmichaud, ping 18:22
18:25 cotto_work joined, joeri joined
japhb Infinoid, ping 18:25
dukeleto 'ello 18:26
japhb Morning, dukeleto!
dukeleto japhb: how goes it? I missed the sunday meeting
japhb Pretty good. The Sunday meeting was very good.
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.
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.
dalek nxed: r259 | julian.notfound++ | trunk/winxedst1.winxed:
array initializers in stage 1
 18:29
Coke apparently not. bother. 18:31
tewk_ plobsing? 18:38
purl hmmm... plobsing is part of our sanity injection framework
tewk_ purl thats not helpful
purl tewk_: sorry...
tewk_ email?
purl i guess email is for old people
18:39 joeri joined
darbelo_ plobsing is also probably canadian 18:39
purl okay, darbelo_.
darbelo_ tewk_: did dthat help ?
;)
Coke pmichaud++ 18:41
PerlJam: I did task #1.
darbelo purl: plobsing is also plobsing@gmail.com 18:42
purl okay, darbelo.
darbelo tewk_: How about now? :)
tewk_ plobsing? 18:43
purl rumour has it plobsing is part of our sanity injection framework or probably canadian or mailto:plobsing@gmail.com
tewk_ I checked out CREDITS, but now purl is smarter too. 18:44
Infinoid japhb: pong
darbelo She has more facts, not really sure she's smarter.
dalek rtcl-nqp: d5e5a68 | coke++ | (6 files):
Remove emacs boilerplate inherited from parrot
 18:45
rtcl-nqp: a5e894d | coke++ | src/Partcl.pir:
command_line does not return something that is usable as an exit value.
rtcl-nqp: 71f0678 | coke++ | src/Partcl/commands/main.pm:
force [incr] args to be ints (both the var and the value)
rtcl-nqp: d1a1ed9 | coke++ | src/ (3 files):
Add some tcl-specific integer parsing and make it available outside expr.
rtcl-nqp: f14e892 | coke++ | TODO:
completed.
rtcl-nqp: 06a6c07 | coke++ | build/Makefile.in:
this test now passes.
japhb Infinoid, Can you email me a tarball of your /usr/include/GL , so I can hack on your OpenGL configure problem? 18:46
Infinoid japhb: Gladly. Sent. 18:47
japhb thx
Infinoid It's probably full of crazy gentoo breakage 18:48
japhb++
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
.oO( Why would anything in /usr/include have symlinks into /usr/lib* ...? )
 18:52
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
Infinoid did warn about crazy gentoo breakage :)
japhb True ... 18:54
Oddly, the original tarball didn't arrive, but the new one has. Looking at it now 19:04
Infinoid, try r43052 19:19
dalek rrot: r43052 | japhb++ | trunk/config/gen/opengl.pm:
[OpenGL] New typemaps; handle FGUNUSED properly
 19:22
Coke ... now I have a failure when running 'make test' that doesn't show when running with ./partcl foo.t 19:34
odd.
WOOF. rebuild. now the error shows with ./partcl but not make test. 19:35
19:37 whiteknight joined
Coke ah. LTM and hash randomization. fun. 19:39
whiteknight LTM?
purl it has been said that LTM is longest token matching
Coke (well, lack of LTM)
whiteknight ah, right
Coke I had a token of 0
and it was occasionally hitting that instead of the octal rule for 00000012345
19:40 chromatic joined 19:41 theory joined
moritz so the integer rule shouldn't match leading 0, and delegate that to octal (for now) 19:42
Coke i just put 0 in as an alternation on <decimal> instead of having a separate <zed> 19:44
incoming. 19:49
purl duck!
dalek rtcl-nqp: c1106c9 | coke++ | (4 files):
booleans rules for [expr]; use in TclString. make '0' not conflict with octals.
 19:52
20:01 riffraff joined
Infinoid japhb++: gen::opengl - Generating OpenGL bindings.........................done. 20:17
NotFound++: t/library/pcre.t ............................ ok 20:19
NotFound Infinoid: good 20:20
Coke bounces! 20:22
20:24 lucian joined
Coke pmichaud: ping. 20:27
japhb Infinoid, yay! Glad to hear it. 20:28
Coke wonders how to get a .panic to include the string that caused the panic to match. 20:31
[ $<err>=(\\S+) <.panic: "list element in braces followed by $<err> instead of space"> ]?
(the $<err> tehre does not interpolate)
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?
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:38
Might as well be honest about it and use a real packfile ;) 20:39
We do however have to keep returning a string for backwards compatibility.
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.
whiteknight we could be returning the PMCs instead of the strings within a deprecation cycle
tewk_ PackFiles of course have a toString right? 20:42
darbelo tewk_: PackFile PMCs do, it returns a string in a format similar to what freeze/thaw returns now. 20:43
tewk_ Sounds like the obvious right thing to do 20:45
whiteknight (do the right thing)++ 20:47
darbelo That reminds me. I have a question: Should I be able to store INTVALs in a PackfileConstantTable PMC? 20:49
whiteknight can you not? 20:51
I dont know a lot about those packfile PMCs yet
tewk_ darbelo, When you serialize something you have to tag it, Boxing primitive types aka tagging.
GeJ Good morning everyone
whiteknight good morning GeJ
GeJ Heya whiteknight. How are things going? 20:53
darbelo tewk_: Ah, boxing. I had missed that.
I guess it's PackfileRawSegment and manual storing, then.
whiteknight GeJ: Things are going well, thanks for asking. How are you?
GeJ I'm experiencing Murphy's Law at its best. So, things could be better. 21:00
21:15 riffraff joined
darbelo JoeSatriani1986 21:20
ww
dalek pir: 426747b | dukeleto++ | (2 files):
Add a target to a hopefully temporarily Makefile for generating a pbc
 21:30
21:34 bacek joined
bacek Good morning 21:35
japhb o/ 21:36
darbelo \\o
bacek I was wrong yesterday. It's only 15% improvements in context_unfiy3 branch...
darbelo 88% sounded too good to be true. 21:37
But 15% is still good.
cotto_work yes
NotFound darbelo++ 21:41
darbelo Thanks, but what did I do?
NotFound Stimulate ;) 21:42
bacek++
darbelo ok ;)
bacek :)
Coke, "make" doesn't work in context_unify3. "make corevm" does. 21:45
chromatic We can probably get more than 15% out of there. 21:48
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++
chromatic Sure, I'm not complaining. I think it opens the door for other optimizations. 21:53
Coke bacek: ok.
chromatic I can imagine eking out another 10%.
Coke wonders if he scared away pmichaud. =-)
bacek chromatic, yeah. We'll see. 21:54
dalek nxed: r260 | julian.notfound++ | trunk/winxedst1.winxed:
hash initializer in stage 1
 21:56
darbelo chromatic: ping 22:05
dalek rrot: r43053 | darbelo++ | trunk/DEPRECATED.pod:
Correct and clarify the freeze/thaw deprecation notice.
 22:06
rrot: r43054 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
Aplly two cleanup patches by tewk++.
cotto_work Hmmm. Is it going to cause pain to have pmc_freeze_cleanup and context_unify3 active at the same time? 22:09
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
darbelo chromatic: You wanted to give ->bufused a macro, like bufstart and the other buffer fields, right? 22:11
chromatic I have that in a local git branch, but I don't want to do that before the release. 22:12
darbelo Cool, I waws going to suggest you put an example on the wiki and tell people to do it over time. 22:14
dalek nxed: r261 | julian.notfound++ | trunk/ (2 files):
& and | operators in stage 1
 22:16
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.
cotto_work RecentChanges say no 22:24
22:26 patspam joined
dalek nxed: r262 | julian.notfound++ | trunk/t/intarray.t:
fix a redeclared variable in a test
 22:30
22:37 Zak joined
japhb pmichaud, ping 22:38
22:40 the_irrational_one joined
pmichaud japhb: pong 22:41
japhb Up for installer talk?
pmichaud I may get interrupted a fair bit 22:42
japhb Did you want to do it here or #perl6, or ...? 22:43
And interrupted is fine by me
dalek nxed: r263 | julian.notfound++ | trunk/winxedst1.winxed:
throw statement in stage 1
 22:45
pmichaud either here or #perl6 is fine. here might make more sense to begin with -- we can move to #perl6 if needed 22:46
22:46 davidfetter joined, bacek joined
japhb pmichaud, OK then. 22:47
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 :)
japhb nodnod
Understtod.
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?
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
but ultimately I think the answer for module installers is that it won't be decided from the top, but from the bottom
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"
japhb I can understand that
pmichaud and I have trouble thinking of "official" with respect to anything Perl 6
i.e., people ask which compiler is the "official" compiler -- there isn't one 22:51
japhb Of course.
purl Indubitably.
pmichaud so if we say "which installer is the 'official' Perl 6 installer"..... the question itself doesn't quite work
japhb Mu.
pmichaud that's all I was really intending to say yesterday
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
*poorly worded
clearly if it is the bee's knees by Rakudo*, we'll adopt it 22:53
and I'd be very happy for that
japhb It sounds like the biggest concerns about it right now are: 1) It's not finished. 2) It's got strongish Parrot ties.
OK, good to hear.
pmichaud those aren't even really "concerns" (more)
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
what we have to be careful of is claiming that it's the official Perl 6 installer (interruption)
japhb nod
Right, gotcha.
dalek rrot: r43055 | pmichaud++ | trunk/NEWS:
[NEWS]: nqp-rx, HLL::Compiler, and PDD31 updates
 22:55
rrot: r43056 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
Reduce packfile scope to the one place we need to use it.
pmichaud (back) 22:57
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
japhb yes, quite
pmichaud I figure there will be quite a few false starts, and that's probably okay
japhb nod 22:59
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
pmichaud I'm sure there is such a belief, but I tend to want to dispell that notion
japhb moritz, *chuckle* 23:01
OK
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.
just like I think we shouldn't say there's "only one" Perl 6 compiler
in general I think we should be talking about common specifications and targeted implementations 23:02
so, for module sharing, we come up with some common specifications, but there can be many implementations
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*
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:03
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
speaking of which, I owe plumage some NQP tuits
I should be able to get to those today/tomorrow :)
japhb brightens up ... oooh tuits! 23:05
thanks in advance
pmichaud well, I finally got my hague grant finished, so that's no longer weighing me down as much
opens up the space to work on a few other things a bit :)
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.
I bet. 23:06
23:06 Zak joined
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:06
(I'm positive I'll have questions for you while I work) 23:07
So.
pmichaud sounds good to me. I'm still thinking a bit about how that ends up being structured :)
japhb Back to the main topic.
So ... how do you suggest I engage the Perl 6 people into working with me on this grand installer API project? 23:08
I literally can't keep up with #perl6 backlogs (I don't even try any more), so that's right out. 23:09
And stopping by every so often doesn't seem to get any traction.
A couple people recognize the Plumage name now, that's about it.
pmichaud well, mainly people need to see progress, documentation, and how they can start using it
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?
pmichaud yes
japhb pmichaud, Ah, that's a good idea
japhb watches more hours of free time twinkle out of existence 23:11
:-)
pmichaud I suspect one of the bigger stumbling blocks to participation may be plumage's requirement for a parrot cla
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?
pmichaud (and applications, perhaps)
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
japhb Well, how does the licensing and copyright work with nqp-rx?
pmichaud well, nqp-rx is currently held by the Perl Foundation, and whatever other contributors may be there 23:14
it's released under the AL2
Parrot then chooses to release a version of nqp-rx as part of its distribution
japhb ... as is Parrot and Plumage, so the license itself is not an issue. 23:15
Do nqp-rx contributors have to do a Perl Foundation CLA?
pmichaud not currently, although Rakudo contributors do
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)
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
pmichaud oh, Coke++ is certainly a rakudo committer
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.
pmichaud that's not the licensing that I'm thinking of 23:18
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
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.
japhb (a CLA to either one, I assume you mean)
pmichaud right
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
right, understood
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
nodnod
Tene So Rakudo * is a distribution of Rakudo, in chromatic's sense of Perl 5 Distributions. 23:22
pmichaud Yes.
In the sense of Strawberry Perl, and the like, also.
Tene That does suggest that there will be versions of * 23:23
pmichaud there will.
Tene Okay. I think I like it.
pmichaud I'm also expecting Rakudo * to have its own release cycle
and likely its own release managers
japhb OK, so maybe Plumage is just in the Parrot Distro, not Parrot itself, so we can drop the CLA requirement.
pmichaud the compiler will continue with a monthly release cycle
the distribution will probably go with a quarterly release cycle to begin wtih
(although we might do monthly at first, if there appears to be a rapid convergence or development needed) 23:24
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
pmichaud each distribution release would choose whatever compiler release is most appropriate for that release
also, unlike Perl 5's traditional model, I think we have to start separating the "compiler manager" role from the "distribution manager" role 23:26
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.
pmichaud watching Perl 5's issues over the summer has been particularly instructive
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
(which just means it's hard, not that P5 won't do it :-)
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
*manager
japhb Still, they did manage to switch to monthly releases, so hope springs eternal
:-)
pmichaud right
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
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.
Who can give me an answer I can rely on? 23:31
darbelo japhb: allison, chromatic, particle, people on the PaFo board.
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. ;-)
pmichaud, ah, and here we come full circle
pmichaud and then decide what licensing arrangements are best for the components involved
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
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
So if the CLA is a blocker to contributors, that's a pain point for me.
pmichaud from here, it doesn't seem to me like it's (yet) your primary blocker
japhb OK, that's good to hear
pmichaud I'd suggest going with my earlier item -- get some people actually using plumage 23:35
that will help drive its requirements a lot better
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.
chromatic likes when people reuse his metaphors and descriptions
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.
pmichaud yes
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.
And a couple of times he just passed off to mberends, who never responded. :/
pmichaud we're all pretty busy :)
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
*lines
japhb: if I had, I might be much more interested
japhb Oh wow. Serious miscommunication then.
Huh. 23:41
japhb momentarily flummoxed
moritz so, what can plumage do to help distributing Perl 6 modules?
japhb It's like proto, but more powerful. 23:42
moritz so it can track dependencies, download modules for me...
japhb (Along a number of axes)
yup
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
moritz japhb: then it's really a communication problem 23:42
dalek nxed: r264 | julian.notfound++ | trunk/winxedst1.winxed:
handle new arguments in stage 1
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.
moritz japhb: include the sample input/output for downloading a Perl 6 modules
*module 23:44
and call for testers, users, whatever
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
moritz have you imported proto's project.list or so?
ok
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
Write a Plumage metadata file (in JSON) for it. Send me that file. You're done./
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.
pmichaud (making announcement/fait accompli) the major thing I'd want to achieve is to get a good handle on managing expectations (more)
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"
japhb moritz, trac.parrot.org/parrot/wiki/ModuleE...taProposal 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 :)
japhb pmichaud, understood. I'll mark it at the top of my list to manage the expectations. ;-)
... all in caps no less
Tene The big question, re plumage / HLL, is about compat with existing HLL library systems. 23:49
dalek tracwiki: v16 | jkeenan++ | AllHackathons
tracwiki: trac.parrot.org/parrot/wiki/AllHack...ction=diff
tracwiki: v136 | jkeenan++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
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
cotto_work clock?
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 /
kid51 make fulltest: PASS on Linux/i386 at r43027
japhb Tene, meaning, working with LuaRocks, RubyGems, et al.?
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:51
japhb Plumage is able to drive other systems. 23:52
It already can handle driving a Perl 5 style Makefile.PL system, fperrad's parrot distutils system, etc.
It's easy to add new external systems.
Tene Right, right, I remember now.
Thanks for indulging me. :) 23:53
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
23:54 Zak joined
Tene Should that go into plumage, or should that go into the HLL implementation, as part of the inter-hll api? 23:54
japhb Tene, that's a good question. 23:55
Tene that is, pynie supports plumage, not the other way around.
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.
Tene nods.
japhb Anyone else have thoughts on Plumage and related items? 23:58
Tene Yes, it looks like we should be able to get that information through the cross-HLL API. 23:59
I'll add research into that into my thoroughly-neglected TODO
japhb heh
kid51 Is there anything equivalent to Devel::Cover in NQP yet?

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!