Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:45 dalek rakudo/optimizer: fa826a0 | jnthn++ | src/binder/multidispatch.c:
00:45 dalek rakudo/optimizer: Greatly weaken the 'could never work' analysis - the initial version was wrong. Add a note about how we probably can catch a bunch of obvious cases.
00:45 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/fa826a0657
00:45 dalek rakudo/optimizer: 055835c | jnthn++ | src/ (2 files):
00:46 dalek rakudo/optimizer: Start to do the compile time multi-dispatch analysis. At the moment, we don't actually use the 'I identified the candidate' result, but there's a stub for doing so. We do complain about dispatches that are identified as impossible though, with the result that a bunch of spectests that checked things like '&end requires an argument' now fail to compile.
00:46 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/055835c7e5
00:56 woosley joined #parrot
01:12 davidfetter_ joined #parrot
01:20 jkitazawa joined #parrot
01:39 cotto dukeleto, ping
02:01 cottoo joined #parrot
02:09 jeffreykegler joined #parrot
02:11 jeffreykegler left #parrot
02:31 alvis joined #parrot
03:24 rfw joined #parrot
03:52 cotto seen dukeleto
03:52 aloha dukeleto was last seen in #perl6 2 days ago joining the channel.
06:21 nbrown joined #parrot
06:53 dalek rakudo/nom: ca5f34b | Coke++ | t/spectest.data:
06:53 dalek rakudo/nom: run fudged test!
06:53 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ca5f34b16b
07:14 mj41 joined #parrot
07:34 SHODAN joined #parrot
07:40 aloha joined #parrot
08:03 lucian joined #parrot
08:18 contingencyplan joined #parrot
09:31 dalek rakudo/nom: c5fc397 | moritz++ | src/core/Buf.pm:
09:31 dalek rakudo/nom: [Buf] <=> should really be cmp, TimToady++
09:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c5fc397216
09:43 dod joined #parrot
09:44 bacek_at_work joined #parrot
09:52 lucian joined #parrot
09:58 woosley left #parrot
10:08 particle1 joined #parrot
10:15 arnsholt joined #parrot
11:09 woosley joined #parrot
11:13 arnsholt joined #parrot
11:20 dalek parrot/mls/pct_exceptionhandlers: ddab786 | mls++ | compilers/pct/src/PAST/Node.pir:
11:20 dalek parrot/mls/pct_exceptionhandlers: move handle_types/handle_types_except from PAST::Control to PAST::Node
11:20 dalek parrot/mls/pct_exceptionhandlers:
11:20 dalek parrot/mls/pct_exceptionhandlers: This is done for two reasons:
11:20 dalek parrot/mls/pct_exceptionhandlers: - allow 'try' pirtype node to generate specialized exception handlers
11:20 dalek parrot/mls/pct_exceptionhandlers: - allow to have PAST::Stmts nodes as block handlers
11:20 dalek parrot/mls/pct_exceptionhandlers: review: https://github.com/parrot/parrot/commit/ddab786a93
11:20 dalek parrot/mls/pct_exceptionhandlers: a44e056 | mls++ | compilers/pct/src/PAST/Compiler.pir:
11:20 dalek parrot/mls/pct_exceptionhandlers: refactor exception handler setup into a push_exception_handler function, change pirop=try nodes to use it
11:20 dalek parrot/mls/pct_exceptionhandlers: review: https://github.com/parrot/parrot/commit/a44e056274
11:20 dalek parrot/mls/pct_exceptionhandlers: 03a775d | mls++ | compilers/pct/src/PAST/Compiler.pir:
11:20 dalek parrot/mls/pct_exceptionhandlers: change pirop=try to work more like pirop=if regarding the return value
11:20 dalek parrot/mls/pct_exceptionhandlers:
11:20 dalek parrot/mls/pct_exceptionhandlers: The old code return an unspecific value if an exception was caught.
11:20 dalek parrot/mls/pct_exceptionhandlers: review: https://github.com/parrot/parrot/commit/03a775d339
11:32 preflex_ joined #parrot
11:35 plobsing joined #parrot
11:36 Psyche^ joined #parrot
11:49 lucian joined #parrot
12:00 bluescreen joined #parrot
12:10 whiteknight joined #parrot
12:10 whiteknight good morning, #parrot
12:11 nine good morngin whiteknight
12:13 Felipe good morning
12:22 atrodo =~
12:23 dalek rakudo/nom: bfc3a42 | moritz++ | src/core/Rat.pm:
12:23 dalek rakudo/nom: BUILD should be a submethod
12:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bfc3a42f5b
12:23 dalek rakudo/nom: 00c8180 | moritz++ | src/core/Buf.pm:
12:23 dalek rakudo/nom: fix Buf thinko; fixes .[] indexing into Buf
12:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/00c8180c58
12:30 lucian joined #parrot
12:34 whiteknight hello nine, Felipe, atrodo. How are you all doing today?
12:39 nine whiteknight: looking forward to start fixing tests, now that green_threads builds :)
12:39 whiteknight oh, it builds? What was the problem?
12:39 nine whiteknight: I have no idea :)
12:40 nine whiteknight: did the only thing I could do: ignore the problem and continue with merging the current master including kill_threads. After that the error disappeared.
12:40 whiteknight works for me
12:51 plobsing joined #parrot
12:56 dalek rakudo/nom: 530c04f | moritz++ | t/spectest.data:
12:56 dalek rakudo/nom: run new S06-signature/unpack-object.t
12:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/530c04fec3
13:10 alvis joined #parrot
13:23 dalek rakudo/nom: 1108715 | moritz++ | t/spectest.data:
13:23 dalek rakudo/nom: run new test type-object.t
13:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1108715d8d
13:26 arnsholt joined #parrot
13:51 PacoLinux_ joined #parrot
13:53 dalek rakudo/nom: 6551282 | moritz++ | src/core/Mu.pm:
13:53 dalek rakudo/nom: in .* dispatch, do not turn all method calls into calls on the type object
13:53 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6551282fa5
14:14 dalek rakudo/nom: fce1d9b | moritz++ | t/spectest.data:
14:14 dalek rakudo/nom: run calling_sets.t
14:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fce1d9bfb6
14:37 slavorgn joined #parrot
14:38 dalek rakudo/nom: ef6536f | moritz++ | t/spectest.data:
14:38 dalek rakudo/nom: run S06-multi/proto.t
14:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ef6536f7d8
14:58 mls seen tene
14:58 aloha tene was last seen in #perl6 20 hours 16 mins ago saying "MAIN vs LOAD or something".
15:19 alester joined #parrot
16:18 dalek rakudo/nom: 16cb2b6 | moritz++ | src/core/Parameter.pm:
16:18 dalek rakudo/nom: return Perl 6 strings from Parameter.named_names, japhb_++
16:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/16cb2b6e09
16:42 mls anybody here that has time to look at the mls/pct_exceptionhandlers branch?
16:44 whiteknight mls: in a little bit. What does the branch do?
16:45 mls it generalizes exception handling in PCT a bit
16:45 mls it's just three commits to look at
16:49 whiteknight okay. I'll take a look at it in a bit
16:49 mls thanks!
16:57 PacoLinux joined #parrot
17:06 dmalcolm joined #parrot
17:11 mls whiteknight: I've to leave now, so take your time. talk to you tomorrow...
17:11 whiteknight okay, thanks
17:11 mls afk -> home
17:21 nbrown joined #parrot
17:34 dodathome joined #parrot
17:45 fperrad joined #parrot
17:49 nine whiteknight: did anyone do any benchmarks before and after kill_threads? Would be interesting if removing the locking calls improved things
17:53 whiteknight nine: locking has been removed for months. Maybe years
17:53 whiteknight Most of the functionality of threading has been removed over time. What was left before kill_threads was a hollow shell
17:54 whiteknight the performance impacts are negligible. One or two API calls on startup, a few API calls on certain thread-related PMC methods, etc
17:54 nine ah ok
17:55 jeffreykegler joined #parrot
17:55 whiteknight yeah, so when I say I removed threads, I really mean I stopped pretending that we used to have them
17:57 whiteknight according to the old deprecation policy, we had to continue pretending for several months, so people could update other imaginary software to stop pretending to use it
17:58 benabik joined #parrot
17:59 benabik o/
17:59 nine sounds horribly efficient ;)
18:00 whiteknight what I would like to do is have a system that doesn't require active imagination to use
18:02 benabik I like to imagine we have a more sensible lexical system.  I'll get around to that someday.
18:03 whiteknight it has gotten much better with the addition of native types recently
18:03 whiteknight it has much more ground to cover
18:04 benabik Scopes need to not be linked 1:1 to subs.  We need a hint based lookup ($I0 = get_lex_hint 'foo' ; $P0 = get_lex $I0) to avoid string comparisons...
18:04 benabik Those are my primary concerns ATM.
18:04 whiteknight scopes aren't linked 1:1 to subs in the case of tailcalls
18:04 whiteknight of course, the scope gets very well recycled
18:04 benabik I want a nested scope inside a sub.
18:05 whiteknight I'm not sure I understand that
18:05 benabik int x; while (x) { int y; } should not require a sub for inside the while loop.
18:06 whiteknight benabik: that's a design decision of NQP. Winxed doesn't do it that way
18:06 whiteknight so it's not a fundamental limitation of parrot
18:06 benabik How do you remove y from the lexpad at the end of the loop?
18:06 whiteknight it's not in the lexpad in the first place
18:06 benabik Assuming x and y are lexical.
18:07 whiteknight they just get mapped to different registers in the current lexpad
18:07 whiteknight the compiler makes sure we don't try to access variables in the wrong places. Compile time checks instead of runtime checks
18:07 benabik Yes, but y should not be accessible outside the loop.  So it would have to be removed.
18:07 whiteknight no, the compiler just doesn't emit code that can access it
18:08 benabik And if it was int x; { int x; }, we need to shadow and restore x.
18:08 whiteknight no, the two of them get mapped to different registers
18:08 whiteknight and it's a bad idea to shadow anyway
18:08 whiteknight C# disallows that, and I think that's a fantastic idea
18:08 benabik *sigh*
18:09 benabik It's not invalid.  It's defiantly not invalid for all HLLs we might want to run.
18:09 benabik And not removing it from the lexpad means it might happen to get accessed by closures or other strange lookups.
18:09 whiteknight only if that closure has code emitted to look it up
18:09 whiteknight if you emit code to access storage that is out of bounds, you get the results
18:09 benabik Arbitrary code written in possibly other languages?
18:10 benabik What if I do   { my $*BLOCK; } func(); in NQP and $*BLOCK is looked up in func?
18:10 whiteknight so you're saying that the other HLLs would do absolutely zero analysis about the lifespan of variables, and will emit any sorts of random code in all sorts of weird situations, and Parrot should somehow work around that in an intellegent way?
18:10 benabik NQP currently has to create a new sub because of that case and I don't think it makes sense to make it has to.
18:11 whiteknight I don't think NQP has to. I think that was a design decision
18:11 whiteknight I think you could make an NQP compiler which didn't do that
18:11 benabik Because it stores all its variables in our lexpads.
18:11 benabik And you can't do that with our lexpads.
18:11 benabik (AFAICT)
18:11 whiteknight right, but the code to access those variables has to be generated, and doesn't have to be
18:11 benabik Nested scopes are _commmon_ and should be easy.
18:12 whiteknight right. In winxed they are easy
18:12 benabik Because winxed doesn't use lexicals by default.
18:12 whiteknight NQP has made certain decisions, and those decisions don't need to be copied by other languages
18:13 benabik We have these lovely lexical lookup ops that _can't_ match all language semantics.
18:13 sorear you're calling our lexical lookup ops "lovely"??!?
18:13 benabik Being able to create a inner lexpad shouldn't be difficult and would allow people to do these things.
18:13 benabik sorear: In concept.
18:14 whiteknight benabik: sure, that's a solution, and something like it will probably be necessary to cover edge cases in some languages
18:14 whiteknight but in the vast majority of code examples, that functionality won't be necessary or even preferred
18:14 benabik whiteknight: It would help NQP/Rakudo today, I think.
18:14 benabik It would simplify code gen.
18:15 whiteknight sure, but even a rudimentary optimizer could simplify further
18:15 benabik Nested lexical scopes _require_ nested subs today.  I just want to change that.
18:15 whiteknight if you don't shadow variable names, you don't even need a second lexpad
18:15 benabik whiteknight: So HLLs can't shadow variables unless scope == sub?  :-P
18:16 benabik (Why is it that I end up in arguments whenever I mention lexicals?)
18:16 whiteknight right now, no. But again, you could cut out a hell of a lot of subs if you recognize that the subs don't contain shadowed variable names
18:16 whiteknight I'm saying that your proposal works fine, but I don't think it's the best improvement we could make
18:17 whiteknight an optimizer that recognizes when certain scopes can be inlined would likely be much better for most code
18:17 benabik Optimizers are all well and good, but requiring them isn't.
18:17 whiteknight what we're talking about here is an optimization, making existing code run faster
18:17 benabik I just want the lexical lookups to match the concept of lexical scopes.
18:18 benabik So HLL sub == sub, HLL scope = lexpad.
18:18 whiteknight yes, I'm saying that's a fine and good idea
18:18 benabik I'm not talking optimization, I'm talking conceptual matching.
18:19 whiteknight I don't suspect breaking the Sub implementation up from the LexPad would be too time intensive
18:20 whiteknight and adding in two new ops to push/pop lexpads wouldn't be too hard. Getting them to play nicely through exception handlers etc might be
18:20 whiteknight throwing an exception would need to unwind the lexpad stack, etc
18:20 benabik If current lexpad is attached to continuation, not really.
18:21 benabik And I'd like to do that and a hint system where Lexpads cache lookups and can provide integer indexes for speed.
18:21 whiteknight adding integer hinting would probably be very easy to do, and would likely have a nice optimization effect
18:23 whiteknight actually, that might be a little bit tricky, because you would need a map somewhere to show which scope the lexical was in, and what register number from that scope
18:24 whiteknight you could break up a 32-bit integer so the first 16 bits would be the scope number, the next 14 would be the register number, and the last two would be the register set
18:25 benabik I'd probably try to make it pointer based or something.  index into a pointed to register set.  *handwaves*
18:25 whiteknight then when you're looking up the value, loop up X scopes, find register set Z, and store value in slot Y, no questions asked
18:25 benabik whiteknight: That's the general idea.  Exact data in cache is whatever it needs to be.
18:25 whiteknight benabik: sure, that works too, so long as sizeof(INTVAL) == sizeof(opcode_t*)
18:26 whiteknight If we go that route, we need to start making that relationship more formal
18:26 benabik No, I'd keep a cache of looked up things.  Lexpad has an array of things looked up.
18:26 benabik I dislike accepting integers that mean funny things from users.
18:26 mj41 joined #parrot
18:27 whiteknight there's a difference between code entered by joe-schmoe user and a well-tested code generator
18:28 benabik Yes, well...
18:28 benabik Assembly tends to get hand-written somewhere.  :-D
18:29 benabik I also dislike packing things into magic numbers unless I have to.
18:34 jeffreykegler joined #parrot
18:42 zby_home joined #parrot
19:03 contingencyplan joined #parrot
19:07 whiteknight I've hand-written assembly before. Very very few bits of it and in very very few occasions. Trust me, we don't need to make a system that expects users will be writing anything in assembly
19:08 whiteknight most users will revolt if it's even occasionally necessary
19:10 jeffreykegler joined #parrot
19:46 bluescreen joined #parrot
20:03 ambs joined #parrot
20:04 perlite joined #parrot
20:15 soh_cah_toa joined #parrot
21:08 soh_cah_toa_ joined #parrot
21:23 dalek rakudo/nom: 570bc95 | jnthn++ | src/core/Routine.pm:
21:23 dalek rakudo/nom: Make Routine.candidates_matching work on only routines as well as multis for japhb++.
21:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/570bc9510e
21:41 dalek rakudo/nom: 870306b | jnthn++ | src/Perl6/Actions.pm:
21:41 dalek rakudo/nom: Don't create a thunk that does a smart match for literal value constraints; the binder simply calls .ACCEPTS anyway, so we can just use the literal. Faster, and introspects better.
21:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/870306bf70
21:41 dalek rakudo/nom: 3e8911a | jnthn++ | src/core/Parameter.pm:
21:41 dalek rakudo/nom: Implement Parameter.constraints; fix NPMCA in Parameter.named_names.
21:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3e8911a020
21:59 bluescreen joined #parrot
21:59 cotto_work PHP's testing culture makes me sad.
21:59 benabik … PHP's testing culture?
21:59 cotto_work It's just what you'd expect.
22:00 cotto_work except that it exists
22:00 tadzik they go full hardcore
22:00 tadzik as in "THE FAIL CANNOT STOP ME FROM RELEASE"
22:02 dalek rakudo/optimizer: d34c4e3 | jnthn++ | src/pmc/mdthunk.pmc:
22:02 dalek rakudo/optimizer: Set flag to make sure that inlined protos don't end up with us re-running type checks.
22:02 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/d34c4e38f7
22:21 not_gerd joined #parrot
22:21 not_gerd hello, #parrot
22:22 benabik o/ NotFound
22:22 benabik o/ not_gerd, too.  :-/
22:33 not_gerd on a Parrot with 32-bit integers, do you need to go through FFI for 64-bit arithmetics?
22:33 benabik Haven't tried it myself, but I'd imagine so.
22:34 cotto_work hio not_gerd
22:34 not_gerd hello, cotto_work
22:35 benabik Because the I registers will be 32b wide, and we don't support anything like $I0, $I1 = add $I2, $I3, $I4, $I5.  I suppose we could extend the Integer PMC to support it, but blah.
22:35 cotto_work That's out of scope for a generic Integer class.
22:35 benabik Yeah.
22:36 benabik sized_int dynpmcs…  Byte, Int16, Int64, etc etc etc
22:36 benabik But that's no less obnoxious than FFI, I think.
22:37 cotto_work not_gerd: Do I understand correctly that the big value proposition of M0+/- fast translation to something low-level?
22:42 not_gerd cotto_work: the general idea is that there should be an intermediate representation of higher level than any target instruction sets and a low-level representation for interpretation
22:43 dalek parrot: 4388681 | soh_cah_toa++ | tools/dev/pbc_to_exe.pir:
22:43 dalek parrot: In pbc_to_exe, casted 'bytecode_size' argument to Parrot_api_load_bytecode_bytes() as a Parrot_Int since that's what it expects.
22:43 dalek parrot: review: https://github.com/parrot/parrot/commit/4388681fae
22:44 cotto_work not_gerd: would the translation between m0+ and m0- require a register allocator?
22:46 not_gerd cotto_work: not the way I've implemented it
22:46 cotto_work Interesting.  How does that work?
22:46 not_gerd m0+ registers reside in memory, and m0- just loads/stores the values
22:46 cotto_work Won't that be expensive?
22:46 not_gerd a JIT should probably have to do its own allocation
22:53 not_gerd cotto_work: on x86, you need to round-trip to memory anyway because there just aren't enough general-purpose registers available, especially if you use 64bit integers...
22:55 not_gerd m0- as the lowest common denominator can't really do any better than that
22:56 not_gerd what you can do during the tranlation m0+ -> m0- are peephole optimizations, eg keep immediately re-used values around instead of reloading from meory
22:57 cotto_work that's true
22:59 not_gerd perhaps relevant: that's what the m0- interpreter (or at least the implemented part) looks like on x86 on the refactor branch: https://gist.github.com/1243575
23:00 not_gerd there are 8 m0- registers, and there's already some spilling
23:00 whiteknight joined #parrot
23:00 soh_cah_toa looks like i missed something. what's m0+ and m0-?
23:00 not_gerd however, it's far better than what the master branch generates
23:00 cotto_work soh_cah_toa: http://gerdr.github.com/on​-parrot/rethinking-m0.html
23:01 not_gerd soh_cah_toa: and https://github.com/gerdr/m0-pm
23:01 soh_cah_toa interesting...
23:02 not_gerd soh_cah_toa: there's a lot of handwaving in that article, and what I'm actually implementing is slightly different from that
23:02 soh_cah_toa ok
23:03 soh_cah_toa i like this :)
23:03 dalek parrot/whiteknight/gc_precise: fc619a6 | Whiteknight++ | / (4 files):
23:03 dalek parrot/whiteknight/gc_precise: Add in the naive basics of GC anchoring for precise GC
23:03 dalek parrot/whiteknight/gc_precise: review: https://github.com/parrot/parrot/commit/fc619a6a10
23:03 dalek parrot/whiteknight/gc_precise: a2f669b | Whiteknight++ | / (2 files):
23:04 dalek parrot/whiteknight/gc_precise: Add in a header flag for whether we turn on the precise GC or not.
23:04 dalek parrot/whiteknight/gc_precise: review: https://github.com/parrot/parrot/commit/a2f669bbd9
23:04 dalek parrot/whiteknight/gc_precise: 117bd2e | Whiteknight++ | / (3 files):
23:04 dalek parrot/whiteknight/gc_precise: Add in support for anchoring strings. Parrot builds and runs fine in GC_USE_PRECISE modes 0 and 1
23:04 dalek parrot/whiteknight/gc_precise: review: https://github.com/parrot/parrot/commit/117bd2e68b
23:04 dalek parrot/whiteknight/gc_precise: add0f24 | Whiteknight++ | / (2 files):
23:04 dalek parrot/whiteknight/gc_precise: In GC_USE_PRECISE==1, print out some debug messages in trace_system_areas when we find an unanchored PMC or STRING.  We can use that output to help narrow down occurances.
23:04 dalek parrot/whiteknight/gc_precise: review: https://github.com/parrot/parrot/commit/add0f24149
23:04 whiteknight msg plobsing checkout the whiteknight/gc_precise branch. I need to redo the macros because I am not happy with them, but it's a start
23:04 aloha OK. I'll deliver the message.
23:05 not_gerd soh_cah_toa: some more comments on m0+/-: https://github.com/gerdr/on-parrot/commit/9940dce7
23:05 soh_cah_toa ok
23:06 * sorear wonders how a generational imprecise GC is even possible
23:07 whiteknight sorear: stackwalking
23:07 whiteknight basically differentiated by how we find the root set. Either we know where the pointers are, or we don't know
23:08 whiteknight right now we don't know, so we have src/gc/system.c.
23:08 dalek rakudo/optimizer: f910191 | jnthn++ | / (3 files):
23:08 dalek rakudo/optimizer: Infrastructure to support calling a multi candidate determined at compile time, and not repeating arg type checks.
23:08 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/f910191dcc
23:08 dalek rakudo/optimizer: 031a827 | jnthn++ | src/ops/perl6.ops:
23:08 dalek rakudo/optimizer: Write barriers.
23:08 whiteknight and to keep that file sane, we need plenty of garlic and holy water
23:08 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/031a827d19
23:08 dalek rakudo/optimizer: f9d86d1 | jnthn++ | src/Perl6/ (2 files):
23:08 dalek rakudo/optimizer: First cut of just calling straight to a multi candidate picked at compile, and skipping any bind-time type checks (since we know they aren't needed). Note that it finds barely anything at compile time yet, probably since we hardly have any type information in the tree.
23:08 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/f9d86d1adb
23:16 jeffreykegler joined #parrot
23:29 dalek nqp: b9715f1 | jnthn++ | src/PAST/SixModelPASTExtensions.pir:
23:29 dalek nqp: Enable us to set :type(...) on any PAST node, not just PAST::Var.
23:29 dalek nqp: review: https://github.com/perl6/nqp/commit/b9715f103d
23:30 dalek rakudo/optimizer: ad5f98c | jnthn++ | src/Perl6/SymbolTable.pm:
23:30 dalek rakudo/optimizer: Flag various literals as being able to dispatch as native types (which calls back to their boxed forms); spots a few more things. S06-multi/lexical-multis.t falls victim to a 'could never work' detected at compile time.
23:30 dalek rakudo/optimizer: review: https://github.com/rakudo/rakudo/commit/ad5f98c4f1
23:41 dalek parrot/whiteknight/gc_precise: 4e40dc3 | Whiteknight++ | / (2 files):
23:41 dalek parrot/whiteknight/gc_precise: Add in a new macro which I think looks prettier. Several fixes. Convert two functions in namespace.c to use the new system, even if they aren't good, representative functions to have converted.
23:41 dalek parrot/whiteknight/gc_precise: review: https://github.com/parrot/parrot/commit/4e40dc36f5
23:41 p6eval joined #parrot

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

Parrot | source cross referenced