www.parrot.org/ | Parrot 1.4.0 "Mundo Cani" Released! | For 1.5: Remove Deprecated Features | Planet Parrot planet.parrotcode.org/
Set by moderator on 4 August 2009.
00:10 Khisanth joined 00:11 Khisanth joined
dalek cnum-dynpmcs: r146 | darbelo++ | /:
Replace����/trunk/t/subtract.t

   More test file cleanup, t/subtract.t this time. Same as before, mostly:
  - Removed all add.t test failures caused by library bugs
  - Removed tests that depended on not rounding at assignment time.
  - Removed tests involving invalid input.		 00:21
cotto I'm disappointed in decNumber. I'd really expect the library to pass all its own tests. 00:25
(no reflection on darbelo, of course)
darbelo cotto: Well, if you have the patience to read, say 2716 lines of tests you can spot in the comments that a few of them are to be skipped. 00:33
It's not like they didn't warn us :)
Also, the decTest suite assumes that whatever values it puts before the "->" remain untouched, while our conversion process rounds them during the assignment. 00:35
Most of the add/subtract failures happened for that reason. I would expect them to pass if we didn't force our input to match our operating context. 00:36
cotto ok. I still wonder how a reference implementation would do, but that gives me a little more confidence. 00:39
reference implementation of the test suite, that is
darbelo Having spent most of the day looking at the test suite, I can pretty much gurantee that you wouldn't be able to get 100% success without skipping over some tests. 00:44
Here's one example line 1450 of power.decTest : "-- Invalid operations due to restrictions" 00:49
cotto Is there any indication in the docs (i.e. not in comments in the tests themselves) that some tests are expected to fail? 00:52
darbelo cotto: I can't recall the docs mentioning the test suite at all. 00:53
Even better, if you go to the 'decNumber homepage' (speleotrove.com/decimal/decnumber.html) you don't have any links to the test suite either. 00:55
cotto There's a moderate amount of documentation on the test cases, but it doesn't mention either coverage or expected % pass.
00:55 kid51 joined
darbelo The actual test suite is offered by the "General Decimal Arithmetic" page (speleotrove.com/decimal/) not decNumber. 00:57
00:58 patspam joined
darbelo I suspect that it's meant as a spec-test for whoever decides to implement a decimal arithmetic package. 01:00
But if I'm disappointed with decNumber, it's for different reasons. It puts waaaaay too much effort into trying to be a 'decimal FPU'. 01:02
01:03 Eevee joined
darbelo There are a few moments where I though I was working with a *hardware* implementation. It's handling of zeros, for example, is completely baffling if you look at it from a software standpoint. 01:04
But enough ranting from me. Let's commit some stuff 01:18
Whiteknight darbelo++ 01:19
purl seen Austin?
purl Austin was last seen on #parrot 2 days, 8 hours, 48 minutes and 21 seconds ago, saying: Try "find_charset" instead of "find_encoding" maybe? [Aug 6 16:25:02 2009]
darbelo (Shut up and hack!)++ 01:21
dalek cnum-dynpmcs: r147 | darbelo++ | /:
Replace����/trunk/t/divide.t

   Cleanup time for t/divide.t. Pretty much the same as the others.
01:22 braceta joined
darbelo All tests successful. 01:43
purl ship that sucker
darbelo Files=7, Tests=4763, 59 wallclock secs (51.70 cusr + 0.59 csys = 52.29 CPU)
dalek cnum-dynpmcs: r148 | darbelo++ | /:
Replace����/trunk/t/multiply.t

   Test file cleanup, this time for t/multiply.t, you know how it goes. Same as
before except now all test PASS.		 01:46
darbelo As of r148, all DecNum test PASS. That puts testing DecInt, writing DecRat and testing DecRat as the only outstatnding schedule items. 01:47
dalek ose: r91 | Austin++ | trunk/library/close/Compiler/Dumper.pir:
Removed accidental .pir file
rrot: r40458 | allison++ | branches/pcc_arg_unify/tools/build/nativecall.pl:
[pcc] Rework NCI function generator to use new argument passing style.
 01:52
cotto darbelo, nice. That's especially good since the last two are stretch goals iirc. 01:55
allison++ 01:56
Whiteknight allison++ indeed. I am so anxious for this pcc work to land 01:58
dalek rrot: r40459 | allison++ | branches/pcc_arg_unify/lib/Parrot/Pmc2c/PCCMETHOD.pm:
[pcc] Updating PCCMETHOD generation to reduce unnecessary fiddling with contexts.
rrot: r40460 | allison++ | branches/pcc_arg_unify/src/pmc (2 files):
[pcc] Update method calls in Class and Object PMCs to use new C call
 02:08
purl i heard interface was more or less well defined for robots - but other agents could refer to the resource with different keys.
cotto < purl-- > 02:09
darbelo cotto: Sort of, they were part of the "What I want to get done" list. I made a best-guess hope-everything-works-out schedule and never revised it when stuff started not-entirely-working-out. 02:19
dalek rrot: r40461 | allison++ | branches/pcc_arg_unify/src (7 files):
[pcc] Updates for new C sub and method calling interface in core subsystems.
 02:22
darbelo Say, is pcc_arg_unify the new pcc_rewiring? 02:28
Whiteknight yeah, I think so
or, it's a more modest first step
goodnight 02:29
darbelo goodnight 02:30
02:35 janus joined 02:37 braceta left
dalek rrot: r40462 | dukeleto++ | trunk/t/tools/parrot_debugger.t:
[debugger] Add tests for the run command
 02:41
02:43 dukeleto joined
dukeleto hola 02:43
purl bonjour, dukeleto.
darbelo dukeleto++ # Good work on the debugger. 02:45
dukeleto darbelo: danke
dalek cnum-dynpmcs: r149 | darbelo++ | trunk/t/data/ (16 files):
Remove decTest files for library functionality we don't expose or use.
dukeleto darbelo: now you can assign to most registers, which should be helpful with debugging 02:46
darbelo If you keep improving it like that people might even start debugging stuff with it!
02:57 MinorToken joined
dukeleto darbelo: that is the plan 03:01
darbelo But... If they do that... They'll find bugs! And fix them! 03:03
cotto oh noes!
dukeleto i have found lots of bugs that I can't even properly test yet, but it is fun
03:04 mokurai joined
dalek rrot: r40463 | allison++ | branches/pcc_arg_unify/src/library.c:
[pcc] Only include the build directory in the search path conditionally.
 03:08
03:11 bacek joined
dalek cnum-dynpmcs: r150 | darbelo++ | trunk/t/data/ (4 files):
Delete some more files we don't need.
 03:16
03:20 donaldh joined, eternaleye joined 03:25 cotto joined
dalek cnum-dynpmcs: r151 | darbelo++ | trunk/t/divideint.t:
New test file for integer division, it adds no new failures.
 03:25
cnum-dynpmcs: r152 | darbelo++ | trunk/src/pmc/decnum.pmc:
Taking a closer look at how parrot handles % on floats, it looks like
 03:40
cnum-dynpmcs: r153 | darbelo++ | trunk/src/pmc/decnum.pmc:
Opps, missed a VTABLE on the last commit.
 03:45
03:52 TiMBuS joined
dalek cnum-dynpmcs: r154 | darbelo++ | trunk/src/pmc/decint.pmc:
Replace all uses of PARROT_DECNUM() with PARROT_DECINT() for the DecInt PMC.
 03:55
cnum-dynpmcs: r155 | darbelo++ | trunk/src/pmc/decint.pmc:
Adjust DecInt's modulus* VTABLEs to mimic the behavior of % on integers.
 04:00
cnum-dynpmcs: r156 | darbelo++ | trunk/t/data/ (21 files):
Remove another batch of unused decTest files.
 04:20
cnum-dynpmcs: r157 | darbelo++ | trunk/ (3 files):
Add a new test file for the the modulus vtable. This gets us 422 more tests with
 04:40
cnum-dynpmcs: r158 | darbelo++ | trunk/t/remaindernear.t:
Add our first DecInt test file. 121 tests (0 failures) for the DecInt modulus
 05:00
darbelo And now that's done I'm going to sleep. I don't trust myself to keep commiting changes after 2 am.
05:03 HG` joined
cotto good idea there 05:12
05:23 Andy joined 05:25 bacek joined 05:37 mokurai joined 07:20 donaldh joined
cotto If anyone knows Smalltalk, now's your time to shine. 07:52
dalek tracwiki: v1 | cotto++ | LoritoPrimitives 07:53
tracwiki: initial version; needs help from someone who knows Smalltalk
tracwiki: trac.parrot.org/parrot/wiki/Lorito...ction=diff
cotto Not coincidentally, it's my time to sleep.
08:01 mikehh_ joined 08:40 mokurai left
payload is their a known way to print the line number of the hll in a Parrot_ex_throw_from_c_args ? 08:45
or make Parrot_ex_thow_from_c_args allways print the/a line number 08:47
09:22 masak joined
payload :-/ trac.parrot.org/parrot/changeset/38073 09:27
09:36 bacek joined
dalek tracwiki: v22 | kjs++ | PIRCDevelopment 09:44
tracwiki: more heredoc explanation
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
tracwiki: v23 | kjs++ | PIRCDevelopment 09:54
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
tracwiki: v24 | kjs++ | PIRCDevelopment 10:14
tracwiki: include and pod parsing
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
10:16 kj joined
dalek tracwiki: v25 | kjs++ | PIRCDevelopment 10:24
tracwiki: multi heredoc
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
tracwiki: v26 | kjs++ | PIRCDevelopment 10:34
tracwiki: finish discussion heredoc parser.
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
tracwiki: v27 | kjs++ | PIRCDevelopment 10:47
tracwiki: add AST node types
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
10:56 MoC joined 11:10 bacek joined 11:17 kid51 joined 11:20 donaldh joined 11:29 kj joined 11:31 Hunger joined 12:02 bacek joined
dalek tracwiki: v28 | kjs++ | PIRCDevelopment 12:14
tracwiki: more on reg allc
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff 12:15
12:18 Whiteknight joined
Whiteknight good morning #parrot 12:21
kj morning Whiteknight 12:25
Whiteknight hello kj 12:26
kj Whiteknight: the big PIRC documentation project has started :-)
Whiteknight I saw that. Very nice!
kj thanks :-) 12:27
dalek tracwiki: v29 | kjs++ | PIRCDevelopment 12:28
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
12:37 Whiteknight joined
dalek tracwiki: v30 | kjs++ | PIRCDevelopment 12:38
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
12:54 einstein joined
dalek trixy: r195 | wknight8111++ | trunk/src/builtins/loadlibrary.pir:
Remove a reference to dumper, since something has changed in parrot about the
 12:56
mikehh I meant to post this a couple of hours ago All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40463 - Ubuntu 9.04 amd64 13:08
dalek trixy: r196 | wknight8111++ | trunk/t/008-path.t:
Fix a test involving paths that's failing because our string literal path is

in parrot. Will dig into this later		 13:10
13:19 kj joined
dalek trixy: r197 | wknight8111++ | trunk/src/parser/grammar.pg:
quick hack to get files working if they start with whitespace. Whitespace

ticket#20		 13:20
Whiteknight feels good to work on matrixy, development on that has been stagnant for a few months now 13:29
dalek trixy: r198 | wknight8111++ | trunk/t/ (5 files):
add a test to the dispatch tests to catch regressions on r197
 13:30
Whiteknight Infinoid: ping 13:31
kjs: ping
kj hi Whiteknight 13:32
Whiteknight hello kj 13:33
kj you lookin for me?
Whiteknight no, kjs 13:36
kj kj=kjs
Whiteknight oh shit, I'm getting names mixed up in my head
sorry 13:37
kj np
Whiteknight Austin? 13:53
purl i heard Austin was nice. or a city in Texas.
Whiteknight Austin_Hastings?
purl i guess Austin_Hastings is asking for method.
Whiteknight that's not helpful
dalek kudo: 5c4b1b8 | dakkar++ | (2 files):
Fix splice

Signed-off-by: Moritz Lenz <moritz@faui2k3.org>		 14:00
14:20 Austin joined
mikehh rakudo (5c4b1b8) builds on parrot r40463 make test/make spectest (up to 27922) PASS - Ubuntu 9.04 amd64 14:20
Austin WhiteKnight: hi 14:21
purl hola, Austin.
Whiteknight hello Austin 14:24
Austin If the wife is away, shouldn't you be headed for a strip club, or sports bar, or something? 14:25
"Delilah's! Now with free wi-fi!"
Whiteknight if said gentleman's club had free wi-fi, no cover charge, no drink minimum, and offered no distractions to my coding, I would go 14:27
Austin Sure. But *that* kind of gentlemen's club died out in the 19th century.
Whiteknight yeah and back then the wi-fi wasn't even worth the trip
Austin "There's old Whitworth. He's a bit of a strange chappy. Sits by himself smoking stogies and hacking parrot all day. Never says a word to anyone." 14:28
Whiteknight well, that is what they say
Austin :(
No wi-fi, just pay a kid to run a message for you. 14:29
Write your code in long hand, with a pen. The way God intended.
Whiteknight yeah, those were the days 14:31
Austin So what are you working on today? 14:32
14:35 jan joined
Whiteknight I dont know. Nothing right now 14:37
I was doing some Matrixy hacking earlier, and I have some GC stuff still up in the air that I could tackle
Tene wants to work on a select()/poll() interface too, and I really want to finish up the pipe stuff with Infinoid 14:38
Austin What's new in GC-ville?
Woo. I love it when I get a whole bunch of code in a row to start working. 14:44
Whiteknight chromatic had an idea for a lazy allocator that might be able to shave a few percent off startup time 14:45
14:45 Psyche^ joined
Whiteknight and NotFound has been doing some stuff with PMC allocation that should give us some good improvements, at least in terms of decreased code complexity 14:46
actually, NotFound: ping
Austin What is the current state of the "GC problem"? Is it too slow, or just too much of an interruption? 14:48
Whiteknight too slow, we're basically just using a simplistic algorithm 14:49
Austin Okay. 14:50
Whiteknight although we do have more people looking at it now, so that's a big plus
14:50 tetragon joined
Austin Okay. 14:51
Why is the simplistic algorithm a problem? 14:52
Coke skips review. 14:53
simplistic could cause slow collections, or insufficient collections...
Whiteknight the simplistic algorithm (mark&sweep) is just algorithmically inefficient
Austin Hmm. I don't get that.
Coke you don't experience it or you don't understand? 14:54
Whiteknight it's like the difference between a bubble sort and a quick sort. Both sort an array, but one is faster then the other
Austin I don't understand it.
I certainly don't understand the sort analogy. 14:55
dalek tracwiki: v2 | cotto++ | LoritoPrimitives
tracwiki: add a field for an example Smalltalk snippet
tracwiki: trac.parrot.org/parrot/wiki/Lorito...ction=diff
Austin Maybe it's the edge cases.
Coke Are you basing this on looking at the existing code? 14:56
(austin)
Austin Nope.
Coke ok.
Austin Just thinking about GC in an environment where we know what all the objects are.
Coke but we don't, necessarily. there's discovery.
Austin Why is there discovery?
Coke because there's objects on the c stack? 14:57
Austin Didn't you write them down when you allocated them?
And how do you discover objects on the C stack?
Coke <shrug> I'm not your GC guy. but the fact that you don't get that there can be a bad algorithm for a given problem seems to be a blocker. 14:58
Austin I get that there can be a bad algorithm. But Andrew, and a whole bunch of other smart people, have spent a bunch of time on this.
Coke HA.
ahem.
Austin So I don't get that we could still be *using* a bad algorithm.
Coke Austin: that's pretty much how parrot has been developed. 14:59
Austin How's that?
Coke ;"here's a placeholder that will barely get the job done." "ok, onto the next thing."
Austin Hmm.
Coke We have been going back and fixing a lot of the placeholders.
Austin Okay. 15:00
Whiteknight Austin: the biggest problem is that for a long time Parrot was very dependent on the bad algorithm because there wasn't any encapsulation
Austin (On a side note, I've made a vow *not* to look at the internals. That way lies non-productivity.) 15:01
Whiteknight we have better encapsulation now, but we're still finding problems where the old bad design hasn't been completely contained and organizd
Austin Whiteknight: Okay.
Coke: How does a parrot object get put on the C stack?
Is there a "parrot-handle", or just a pointer to the object?
Coke Austin: I have no idea.
Austin Ah.
Whiteknight: do you know? 15:02
Whiteknight PMC * p = pmc_new(...) 15:03
It's not where the PMC is stored, those are always in the pools. It's where the PMC reference is stored 15:04
the GC follows references
Austin Right.
Whiteknight So there are two options: either the PMC is referenced from another PMC, or it's referenced from a C variable on the C stack
Austin Hmm.
Do we care about that? 15:05
Whiteknight Yes, because we need to find all references to avoid prematurely collecting PMCs
Austin How does GC get triggered?
Whiteknight usually it gets triggered internally to pmc_new, when it attempts to allocate but has no free buffers available 15:06
Austin Okay.
Whiteknight so if I do "PMC * a = pmc_new(...); PMC * b = pmc_new(...);" There is a chance that a won't be "anchored", and can be lost if the second call to pmc_new triggers a GC run 15:07
Austin I'm wondering just how many PMCs can be on the stack, since the stack should be (some constant stuff, which we can write down), plus whatever is needed to execute one opcode.
Whiteknight ...unless we sweep the C stack and find it
Right, it's never much stuff, but it's also not zero stuff
luckily because of the way that Parrot dispatches opcodes, the stack is rarely very deep, so sweeping it is quick 15:08
Austin So that's a fairly low-cost operation, then?
Whiteknight yes
Austin Okay. Then the list of every allocated object is really-cheap-but-not-quite-free.
Whiteknight depends what you mean by that 15:09
Austin Does the mark process tell pmcs to recursively mark, or just one level?
Whiteknight it's a recursive mark 15:10
Austin I mean if pmc_new is the allocator for all pmcs, then all the pmc references are known (cause you allocated them) except the ones on teh c stack, which are cheap to get. 15:11
Whiteknight yes
but in reality, we don't need that list
Austin So where do the all the mips go during gc? 15:12
Whiteknight GC is two stages: Mark, then sweep.
Austin Sure.
Whiteknight For sweep, GC starts at the root set (interpreter, registers, C stack) and follows references, marking objects alive.
er, mark
Austin You mean "For mark" right? 15:13
Whiteknight yes
for sweep, GC traverses the pools finding all items that aren't marked and freeing them
The inefficiencies come from the huge numbers of PMCs
Austin Which one takes longer? 15:14
Whiteknight for both stages we end up moving huge amounts of memory into the CPU cache, and marking/sweeping objects that are never going to die
I don't know, but I assume mark takes longer
never benchmarked it
Austin Do you know which objects will never die?
Whiteknight some, like constant objects don't die. But there are others that almost never die, and we don't detect those 15:15
so things that live for a long time are still marked every single time the GC runs, when heuristically we can say that they don't need to be marked as often 15:16
15:16 JimmyZ joined
Austin Detecting != knowing. 15:17
It sounds to me like you need a benchmark program.
How many pmc's are there, really?
I've heard someone, maybe you, talking about the large numbers of pmcs created at startup. Is that still true?
15:20 donaldh joined 15:21 tetragon_ joined 15:22 kid51 joined
moritz that sounds like something chromatic would say ;-) 15:23
Whiteknight chromatic probably knows that information, I don't 15:24
15:24 dalek joined
Austin Is there a cheap way to find out if a pmc 'can' do a certain vtable op? 15:27
Whiteknight what do you mean? 15:29
technically, pmcs "can" do all VTABLEs, but many of them just fall back to Default
Austin Right.
I was thinking about how to experiment with different GCs. And it seems like you'd want to be able to add a new vtable method, "experimental_GC_some-function". But then you'd need to know which Pmc's didn't implement it. 15:30
Whiteknight yeah, I don't know 15:31
Austin I guess it would be vtable[index] != default.vtable[index]. Still pretty good.
Whiteknight in C, yes. But I don't know how you would do that in PIR 15:32
Austin I was planning on doing it in C.
:)
A PIR garbage collector seems to be inviting trouble..
moritz because it has to collect itself? ;-) 15:33
Austin That wouldn't be a problem if we had semaphores.
moritz doesn't have metaphores either 15:34
16:09 mberends joined
dalek kudo: 212b145 | masak++ | src/setting/Temporal.pm:
[Temporal.pm] fixed formula in epoch

changed the names of a few local variables to make parameter passing prettier.		 16:39
kudo: 5517d80 | moritz++ | src/ (2 files):
implement infix:<!%>
 16:44
kudo: 75d2b7d | moritz++ | src/setting/Any-list.pm:
simplify List.kv
kudo: 7d06fad | dakkar++ | src/ (2 files):
moved kv to setting
NotFound Whiteknight: pong 16:56
Whiteknight NotFound: you doing any work on the auto_attrs branch todaY?
NotFound Whiteknight: nothing after r40449 16:57
Whiteknight Okay, I'm building it now to test it out 16:58
NotFound Whiteknight: ok
Whiteknight anything you're blocking on, or just need to convert all PMCs over to use the new stuff?
NotFound Whiteknight: not all, but there are some problems with non auto inheriting from auto. I plan to add a report to the ticket tomorrow. 17:08
Whiteknight ok
17:13 Khisanth joined 17:14 chromatic joined 17:24 mikehh_ joined 17:40 mokurai joined 18:01 mberends joined
dalek rrot: r40464 | allison++ | trunk/docs/book/pir (2 files):
[pirbook] Typo fixes from Nuno Carvalho.
 18:17
rrot: r40465 | allison++ | branches/pcc_arg_unify/config/gen/config_pm/config_lib_pasm.in:
[pcc] Use idiomatic Parrot, PMCNULL instead of 'Undef'.
 18:50
18:59 einstein joined 19:00 payload joined 19:04 dukeleto joined 19:11 MikHel joined 19:18 Whiteknight joined 19:20 donaldh joined 19:23 rdice joined
moritz pmichaud: PGE's STATUS document seems outdate, it mentions \\c and \\C as TODO 19:51
pmichaud: same with composed char classes 19:52
19:53 iblechbot joined
pmichaud moritz: very likely, yes. 19:55
feel free to submit patch or update it :)
moritz ok
I know, nobody reads docs anyway...
dalek rrot: r40466 | moritz++ | trunk/compilers/pge/STATUS:
[PGE] update STATUS
 20:00
20:11 whoppix joined
dalek rrot: r40467 | moritz++ | trunk/compilers/pge/PGE/OPTable.pir:
[PGE] fix outdated sub name in POD
 20:14
20:23 chromatic joined
dalek kudo: 61f269d | pmichaud++ | docs/ROADMAP:
First ROADMAP update for Rakudo Star.
 20:34
20:34 joeri joined 20:43 smash joined
smash hello everyone 20:43
20:45 joeri left 20:46 Tene joined
GeJ Good morning everyone 21:00
japhb OK, big parrot module ecosystem proposal draft outline sent to parrot-dev.
*phew*
that ... took a while 21:01
21:06 bacek joined 21:32 darbelo joined 21:34 mberends joined 21:35 dukeleto joined
dalek kudo: 7dd4463 | pmichaud++ | src/parser/ (2 files):
(STD tracking) <...> and <<...>> are now circumfix: instead of quote:
 22:12
22:23 tetragon joined
dalek rrot: r40468 | jkeenan++ | trunk/examples/config (2 files):
Add directories to hold examples of file-based configuration.
 22:35
kudo: f489207 | pmichaud++ | build/gen_whatever_pir.pl:
Add Whatever forms of some prefix operators.
 22:36
22:36 kid51 joined
dalek rrot: r40469 | jkeenan++ | trunk (1 files):
Move files as per trac.parrot.org/parrot/ticket/908.
 22:38
22:39 rg joined
dalek kudo: bf5ed94 | (Martin Berends)++ | src/builtins/eval.pir:
Also pass the 'ver' pmc as a named parameter to sub 'require', for

on Rakudo builds prior to the Lisbon Walkathon, it triggered a GC bug during t/01-sanity/07-isa.t but it does not do that now.		 22:41
kudo: e690c9f | (Martin Berends)++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
22:42 payload joined 23:20 donaldh joined
dalek rrot: r40470 | jkeenan++ | trunk (3 files):
Revise Configure.pl POD and other docs to reflect file movement.
 23:25
kudo: 4786eb8 | pmichaud++ | src/ (2 files):
Move .end() from builtins (PIR) into setting (P6).
 23:28
kudo: 39cc848 | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
rrot: r40471 | jkeenan++ | trunk/xconf/samples:
Remove directory no longer needed.
 23:31
rrot: r40472 | jkeenan++ | trunk/xconf:
Remove directory no longer needed.
TT #908 closed by jkeenan++: [CAGE] Relocate xconf/ examples to examples/ directory 23:34
23:40 Psyche^ joined 23:47 tetragon_ joined 23:48 patspam joined
treed Is there a good primer on AST/PAST besides the Parrot docs? 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!