parrot.org/ - clean up those smolders for the release!
Set by moderator on 20 October 2008.
bacek I can replace '!keyword_does' with 'r = new "Role"'. Same result... 00:00
or new Class...
bacek found source of truth - t/object-meths.t 00:04
Whiteknight (bacek++).needs(more_karma); bacek++; 00:06
bacek Whiteknight: stop cheating :)
afk #
00:34 davidfetter joined 00:47 bacek joined
Infinoid opbots, trust masak 01:00
clunker3 But I do not trust you Infinoid
slavorg Ok
slavorgn Ok
Infinoid opbots, trust bacek
slavorg Ok
clunker3 But I do not trust you Infinoid
slavorgn Ok
Infinoid (they both seem human.)
dalek r32458 | Whiteknight++ | calling_conventions:
: [calling_conventions] make sure to add the invocant to the front of the call signature. Added an adverb modifier "i" for invocants. Causes segfault.
diff: www.parrotvm.org/svn/parrot/revision?rev=32458
bacek returns to polishing his shiny metal butt :) 01:01
01:10 Theory joined 01:21 kj joined
bacek masak: around? 01:21
01:29 johbar joined 01:43 magnachef joined
dalek r32459 | Whiteknight++ | calling_conventions: 01:50
: [calling_conventions] Fix the new "i" invocant adverb modifier to actually be in the right place
diff: www.parrotvm.org/svn/parrot/revision?rev=32459
01:52 Theory joined 02:13 magnachef__ joined 03:26 silug joined 03:27 Psyche^ joined 04:02 elmex_ joined 04:19 magnachef joined 04:20 dmknopp left 04:22 stockwellb joined 04:23 magnachef__ joined
bacek rakudo: enum Foo<get_string>; 04:26
polyglotbot OUTPUT[A method named 'get_string' already exists in class ''. It may have been supplied by a role.ā¤current instr.: '_block15' pc -339673149 ((unknown file):-1)ā¤called from Sub '_block15' pc 169 (EVAL_11:55)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalpmc' pc 804
..(src/PCT/HLLCompiler.pir:468)ā¤called from Sub 'parrot;PCT;HLLCompiler;compile' pc 4...
bacek rakudo's enums are really bad...
rakudo: enum Foo<pick>; 04:27
polyglotbot RESULT[Null PMC access in find_method()ā¤current instr.: '_block14' pc 25 (EVAL_15:12)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 866 (src/PCT/HLLCompiler.pir:501)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1141 (src/PCT/HLLCompiler.pir:631)ā¤called from Sub
..'parrot;PCT;HLLCompiler;command_line' pc 1320 (src/PCT/HLLCompiler.pir:72...
bacek really really bad...
04:32 MariachiElf joined 04:35 Aisling joined
stockwellb Anyone got a second to answer a Roles inspecting question 04:40
bacek stockwellb: I can try... But I'm not very familiar with Roles 04:42
stockwellb This is a PIR question really. I'm just playing around with Roles and a little introspection. So...
I can inspect a class and get a hash telling me some things about it. To get its roles I have to call the roles method. That method returns an array. Shouldn't I be able to loop through that array and call .inspect() on each one? 04:44
bacek stockwellb: yes 04:45
you can iterate over array of Roles and introspect each of them
stockwellb Good now here's where I'm probably messing up then. I made a little sub to dump a hash to the screen. When I dump the roles inspect hash I get *Null PMC acces in get_string()* 04:47
bacek can you nopaste your code? 04:48
chromatic There's a Data/Dumper.pir you can use with load_bytecode.
stockwellb yes, interesting through my dump_hash sub works with the hash from class.inspect, hold on I'll nopaste in a second or two. 04:49
bacek chromatic: you there! Can you fix #60368 please :)
nopaste "stockwellb" at 70.160.222.145 pasted "inspecting roles" (147 lines) at nopaste.snit.ch/14520 04:50
bacek msg masak #60418 is duplicate of #60368 04:51
purl Message for masak stored.
stockwellb bacek, could you be more specific on the local of Dumper.pir? 04:53
chromatic I'll look into it. 04:54
stockwellb chromatic, my kids are running around the house screamin *Trogdor* they love it!!! 04:55
My second grader won't stop drawing the Burninator. 04:56
dalek r32460 | allison++ | pdd22io: 04:57
: [pdd22io] Converted I/O buffering to new architecture.
diff: www.parrotvm.org/svn/parrot/revision?rev=32460
stockwellb bacek, I found Dumper.pir. I guess I was being lazy. 04:58
bacek stockwellb: :)
stockwellb bacek, did you look at my code? I'm inspecting correctly aren't I? 04:59
bacek, thanks for the dumper clue. Dumper doesn't get hung up on things like types so I see the error in my own sub dump_hash. For my roles, namespace is null and I wasn't taking that into account. At least I understood the Role correctly. Thanks again. 05:10
I was lulled into a little bit of false security as the attributes and methods hash both have a value when you *cast* (not sure if that's the right word for parrot) them to a string. Null on the other hand didn't behave that way. 05:14
05:14 magnachef joined
stockwellb A new day has dawned on the east cost. I'm off to bed. Good night folks! 05:15
05:36 silug joined 05:39 tewk joined 05:48 magnachef__ joined 05:56 magnachef joined 06:19 Theory joined 06:20 cognominal joined 06:26 cognominal joined
dalek r32461 | chromatic++ | trunk: 06:27
: [IMCC] Rearranged members of the IMCC_INFO struct, in preparation for making
: the static IMCC globals part of this struct (see RT #60000).
diff: www.parrotvm.org/svn/parrot/revision?rev=32461
06:38 Jimmy joined 06:44 cognominal joined 06:49 bacek joined
Jimmy hello, guys. I want to implement some function 06:58
to pipp. but need to do some OS judgement. 06:59
can PIR do it ? 07:00
chromatic That depends on what you want to do. 07:02
Jimmy for example, I want to judge OS whether is WIN32 with PIR. 07:03
chromatic That's unlikely. 07:04
However, the OS PMC might help. 07:05
At least, it should be able to.
Or you could look for a Win32-specific environment variable with the Env PMC.
Jimmy thanks, i want to find simple way do do it, some fuctions need to. 07:06
chromatic $P0 = new 'Env' 07:09
$S0 = $P0['%WINDIR%']
if $S0 contains a value, you're likely on Windows.
That's kind of a hack however, but it might work for now.
Jimmy thanks, i just find a way to do it. 07:12
sysinfo S0, 4 07:13
ne S0, "MSWin32", NOTWIN
chromatic I forgot about sysinfo. Nice. 07:14
Jimmy thanks for your suggestion too. 07:16
dalek r32462 | chromatic++ | trunk: 07:24
: [IMCC] Moved IMCC globals from a static struct into the IMCC_INFO struct in the
: interpreter. This helps make IMCC more reentrant (though it doesn't completely
: fix RT #60000 for me).
diff: www.parrotvm.org/svn/parrot/revision?rev=32462
chromatic Whoops. 07:42
dalek r32463 | chromatic++ | trunk: 07:43
: [PMC] Fixed a read of unitialized memory in NCI PMC reported by Valgrind.
: Tidied some of the code while I was at it.
diff: www.parrotvm.org/svn/parrot/revision?rev=32463
r32464 | chromatic++ | trunk: 07:52
: [PMC] Fixed a memory leak in the NCI PMC introduced in r32463. Also fixed a
: bug in cloning NCI PMCs, where the clone received the wrong information about
: the JITtedness of the source PMC.
: Note that JITted NCI functions leak horribly at the moment.
diff: www.parrotvm.org/svn/parrot/revision?rev=32464
chromatic purl, msg tewk JITted NCI functions leak 1024 bytes each. We could stuff a reference count in the first INTVAL bytes and increment/decrement appropriately, returning the next 1020/1016 bytes as the function and freeing them with a special function from the NCI PMC in its destroy(). 07:53
purl Message for tewk stored.
dalek r32465 | chromatic++ | trunk: 08:12
: [src] Made temporary_pmc_free() call the destroy vtable entry on appropriate
: PMCs.
diff: www.parrotvm.org/svn/parrot/revision?rev=32465
08:13 bsb joined
dalek r32466 | chromatic++ | trunk: 08:13
: [PMC] Fixed a potential memory leak when resizing a FixedIntegerArray.
: Added the use of temporary_pmc_new/temporary_pmc_free for a genuine temporary
: PMC. We'll see how this works.
diff: www.parrotvm.org/svn/parrot/revision?rev=32466
08:48 bacek joined 08:58 johbar joined 09:07 iblechbot joined 09:32 davidfetter joined 10:29 rurban joined
jonathan rurban: Comming to the hackathon? 11:12
rurban Dont know yet. My friend is sick, I'll wait a bit 11:13
jonathan Ah, OK.
rurban jonathan: sorry, no. I won't come. 12:24
12:39 bsb left 12:46 gmansi joined 12:48 kj joined 12:49 Whiteknight joined
dalek r32467 | Whiteknight++ | calling_conventions: 12:55
: [calling_conventions] Sanity check: make it compile.
diff: www.parrotvm.org/svn/parrot/revision?rev=32467
jonathan pmichaud: Just mailed you the patch that shows the broken PIR generation (from my Google Mail account since pobox doesn't accept mail from my mail server...) 13:12
15:06 jan joined 15:12 jimmy joined
jimmy hello, i write some pipp function, how can i commit it to svn ? 15:13
jonathan jimmy: Commit bits are only given out after a few good patches; please send a unified diff. 15:15
jimmy how to send it ? 15:16
particle svn.perl.org/parrot/trunk/docs/submissions.pod 15:18
jonathan I'm not sure if the Pipp developers have a place of their own, so just send it...yes, see there.
Whiteknight email to parrotbug@perl.org, I think
pmichaud jonathan: got the email.
jonathan particle: I see www.parrot.org/docs/submissions.html is busted
pmichaud: dobre
pmichaud: uh, good
:-)
jimmy email is parrotbug@parrotcode.org 15:21
thanks
jonathan pmichaud: You can haz 'is also' 15:34
(not for attributes)
pmichaud it's implemented?
jonathan I need to run the spectests to make sure I didn't break anything along the way. 15:35
pmichaud excellent!
purl Smithers, release the hounds!
particle jonathan: is 'is instead' a far cry away from 'is also'?
jonathan But otherwise it seems to be working for methods.
pmichaud 'is instead' => bad.
:-)
jonathan particle: Minor pain.
particle that's what i thought. ok.
jonathan Not sure if remove method is in place.
If it is it ain't so bad.
particle btw i'm not sure 'is also' should work for attributes
the spec doesn't say anything about it that i can find 15:36
jonathan particle: I don't see anything in the spec that says it shouldn't.
pmichaud we had a discussion about 'is also' + attributes at YAPC::EU
jonathan Aye.
particle ah
i missed that :)
pmichaud I think that a "dynamic language" would expect to be able to add attributes to an existing class.
jonathan I think we concluded we'd support it, at some point.
pmichaud Certainly it's possible to do it in P5, so I'd suspect P6 should also.
particle well, that's prototype oo in action
jonathan But I don't plan on doing it especially soon unless there's a pressing need. 15:37
'cus it's...evil.
particle so i assume all instances of the class get the method added in 'is also' in the current implementation?
or is it just new instances?
jonathan particle: All existing ones. 15:38
And new ones of course...
I just did a test to check that.
particle :)
jonathan Running spectest now.
Then will find/write some unit tests for it.
particle jonathan++ 15:39
jonathan hopes pmichaud can spot the bug in the if pblock patch 15:41
pmichaud I may just do the whole refactor to get them all.
jonathan I suspect I've most likely done something stupid.
pmichaud: Even so, I'd be interested to know what I did wrong.
pmichaud checking. 15:42
particle i have seven failing spectests
jonathan I have some fails too. 15:43
particle and three bonus tests
jonathan autoincrement, and the working-then-segfaulting declaration order one.
particle yeah, your code from some days ago created that one 15:44
or exposed it, at least
jonathan autoincrement?
purl autoincrement is something else I'm trying to get them to accept.
jonathan Or declaration order?
pmichaud autoincrement might be from a change I made yesterday
but haven't had a chance to revisit.
particle declaration order
pmichaud I was in a hurry so committed prior to spectest completing
(then had to leave) 15:45
(if pblock) fwiw, I think that in general PAST::Compiler should avoid modifying the PAST structure it's compiling (e.g., thenpast.'blocktype'('declaration') ) 15:46
I know there are a few places in the existing code where we do this, but I'm hoping to get rid of them
jonathan pmichaud: I couldn't think of a better way. :-( 15:50
I wasn't comfortable with it either.
I suspect that's not The Bug though?
pmichaud I suspect not
but the PIR generated by the two code items is really... bizarre.
for some reason the second one becomes an 'unless' instead of an 'if' 15:51
15:51 Andy joined
particle > sub r(*@a) { my $b = (); push @b for @a; return @b.elems; }; say r(1,2,3); 15:52
Scope not found for PAST::Var '@b'
oh, oops
> sub r(*@a) { my @b = (); push @b for @a; return @b.elems; }; say r(1,2,3);
0
that should be 3
pmichaud I don't think slurpies are working.
jonathan no, I think not
particle ok, that's the three failures in for-scope
jonathan ah, damm, I've br0ked lots 15:53
particle hrmm, did i get them working in nqp, but not rakudo?
i thought i did work on slurpies some time ago...
pmichaud we still need to re-do parameter handling in rakudo.
particle what's needs redoing? 15:54
pmichaud major refactors -- last time I looked I felt like the type checking and binding were being handled in the wrong action methods. 15:55
15:55 jhorwitz joined
particle ah, ok 15:55
pmichaud and I think the parameter parts of STD.pm grammar changed last week, so we should revisit that.
particle you're right about that. most trait handling is in the wrong spot, too
for-scope fixed by fudging 15:57
pmichaud jonathan: your patch seems to assume that a 'thenpast' node is always present but that 'elsepast' might be optional 16:02
(both are optional) 16:04
I still don't think that's the issue here
but I do see now how I want to do this :-) 16:11
oh, you changed the rakudo grammar
I suspect the issue is there somewhere
jonathan pmichaud: The PAST looks sane, though. 16:18
Like, what I'd expect.
In both cases.
I changed the action method too, of course.
pmichaud yes
I agree the PAST looks sane in both cases 16:19
the PIR output in the failing one ends up with a line that looks like
($P16)
which makes me suspect that it's missing a $Pxx in front of it
but why it's doing that, I don't know.
anyway, I don't see anything obviously wrong with what you wrote, other than the items mentioned above. 16:20
(thenpast is optional)
I'm going to go ahead and refactor it the way I think it ought to end up 16:21
jonathan pmichaud: Yes, in fact, when you skip the say "ok" it emits "_blockXX"($Pxx)
So it's losing the name of the block somehow.
16:45 rdice joined
pmichaud got it working, now just running spectest. 16:47
jonathan Nice
You worked out what the code-gen bug was? 16:48
Or just did something that didn't expose it?
nopaste "pmichaud" at 76.183.97.54 pasted "if 42 -> $a { ... }" (82 lines) at nopaste.snit.ch/14522
pmichaud I don't know the code-gen bug. I just updated the PAST compiler the way I think it should be done
jonathan OK 16:49
That means there's probably still a bug, but the way you've done it looks more general, so works for me.
if_statement will need updating to use xblock if it's going to match STD.pm
pmichaud yes -- this puts the "pass arguments to block" in the routine that handles all of the blocks instead of handling separately for then/else
yes, I'll do xblock next. 16:50
jonathan You can likely just apply those bits of my patch.
pmichaud I also want to update while/until/etc.
jonathan I copied from STD.pm directly.
pmichaud except I think we should have a method xblock($/) { ... }
instead of doing it in if_statement, while_statement, until_statement, etc.
jonathan Maybe, if there's a clean way to do that.
pmichaud sure, this is what PAST was designed for :-)
16:59 Andy joined
dalek r32468 | pmichaud++ | trunk: 17:06
: [pct]: Allow immediate blocks to take arguments in 'if/unless' nodes.
diff: www.parrotvm.org/svn/parrot/revision?rev=32468
jonathan OK, think I've got the various bits cleaned up for is also - running smoke now. 17:13
gotta go - will ci when I get back, provided all passses 17:25
pmichaud okay, great! 17:27
17:45 Theory joined 17:57 AndyA joined
dalek r32469 | pmichaud++ | trunk: 18:42
: [rakudo]: Add pointy blocks to if/unless statements (partial RT #58008)
diff: www.parrotvm.org/svn/parrot/revision?rev=32469
moritz hi 18:43
dalek r32470 | pmichaud++ | trunk: 18:47
: [pct]: Recognize arity of while/until blocks.
diff: www.parrotvm.org/svn/parrot/revision?rev=32470
r32471 | pmichaud++ | trunk: 18:51
: [rakudo]: Add pointy blocks to while/until statements (RT #58008).
diff: www.parrotvm.org/svn/parrot/revision?rev=32471
jonathan pmichaud: Have got one new spectest fail from the is also patch - don't understand quite where/why it comes from. 19:28
pmichaud: So will hold fire until I can resolve that.
pmichaud jonathan: okay 19:29
jonathan pmichaud: Ah, found it...I re-ordered something I maybe shouldn't. Re-smoking with that fixed. 19:31
19:35 cognominal joined
moritz I see three failus in autoincrement.t. Can somebody confirm that that's a test change, not a regression? 19:38
jonathan pmichaud: OK, the OO tests are clean again now - should be able to commit this. 19:41
It's in. 19:46
bbl
dalek r32472 | jonathan++ | trunk: 19:47
: [rakudo] First cut of 'is also'. Allows methods to be added to classes at runtime.
diff: www.parrotvm.org/svn/parrot/revision?rev=32472
bacek moritz: it's test changed. 19:52
moritz: you can fudge test or apply #59596 :) 19:53
good morning
moritz bacek: in general, if you change tests so that they fail, please fudge them (and open a ticket if there's none) 19:54
a new interpretation of the specs is not a regression. 19:55
pmichaud okay to apply #59596 (if regressions pass)
moritz ok, I'll take a look...
pmichaud I'm in the middle of testing things for pointy blocks or I'd do it myself 19:56
moritz it's fine, I have a few minutes right now
dalek r32473 | moritz++ | trunk: 20:08
: [rakudo] More fiddling with ++/-- aka succ/pred. Closes [perl #59596].
: Patch courtesy by Vasily Chekalkin, bacek++
diff: www.parrotvm.org/svn/parrot/revision?rev=32473
20:09 bacek joined
bacek hates australian internet... 20:10
I missed something?
moritz bacek: I just applied RT #59596 20:11
bacek moritz: o! thanks
moritz ... and closed ticket now. 20:13
which leaves us with only 170 tickets ;)
bacek moritz: good. 20:15
You can close more. Just a sec
moritz closing #60144 right now (masak++) 20:16
bacek moritz: junction3.patch from #60168 20:17
moritz: #60380 20:18
20:19 cognominal joined
moritz uhm, why did I just reject the latter? I wanted to reject some entirely different ticket :( 20:22
now, it's till open... dunno what's wrong...
bacek In Soviet Russia tickets rejects you! 20:23
moritz bacek: re #60380, this seems hardly the correct way... when somebody writes 'class Int is also { method modify_me { ... } }' then that need to be catches as well. Which IMHO means that the check should be done by the container somehow, not in every mutating method 20:24
bacek moritz: containers were under heavy refactoring when I did this patch... 20:25
moritz I know 20:27
dalek r32474 | pmichaud++ | trunk: 20:29
: [rakudo]: refactor xblock handling somewhat
diff: www.parrotvm.org/svn/parrot/revision?rev=32474
cognominal is containers behavior fixed?
pmichaud it's better, but not necessarily fixed. 20:30
cognominal ho, jonathan has written about it in planet parrot 20:31
pmichaud++ jonathan++
bacek found src/pmc/objectref.pmc 20:32
pmichaud eventually the inplace operators go away.
bacek pmichaud: +1
purl 1
pmichaud in bacek's australia, you don't disconnect from the internet -- the internet disconnects from you. :-( 20:39
cognominal the packets have trouble going up from Australia if the pump fails 20:42
20:48 masak joined 21:12 bacek joined
bacek pmichaud: +1 about internet... 21:19
pmichaud: is it reasonable to add method 'ensure_readonly' to ObjectRef and call it in mutating methods? Or it should be standalone function?
pmichaud can't put methods into ObjectRef -- all method calls get forwarded to the referenced object. 21:29
at this point I'm not too interested in solving it until after we move to building primitives in p6
at that point the method signatures will be able to catch things that we aren't catching now. 21:30
(not everything, but some things)
bacek pmichaud: there is already 'readonly' method in ObjectRef... 21:31
pmichaud it's left over, and it only gets called if we use VAR()
bacek sub foo($x) { eval '$x++' }
moritz eval can't access outer scopes yet.
bacek 'yet' :) 21:32
pmichaud in fact, afaict that 'readonly' method in ObjectRef is never used.
bacek sub foo(&s, $x) { &s($x) }
pmichaud: I know. So I can use it in 'ensure_readonly' 21:33
pmichaud except I'm not sure I want to take this approach.
bacek rakudo: sub foo { return }; foo 21:34
polyglotbot RESULT[[]]
pmichaud at this point I want to get signatures fixed first, and possibly methods-in-p6, before I commit to any particular handling of readonly
bacek moritz: you can close #56638
pmichaud: fair enough
pmichaud rakudo: sub foo { return }; say foo.WHAT;
polyglotbot OUTPUT[Listā¤]
pmichaud that looks wrong to me. 21:35
moritz there's another ticket for that, something along the lines of "bare 'return' should yield undef"
which Larry addressed with the new Nil type
so that sub foo { return }; foo ~~ undef; will give true 21:36
pmichaud correct.
21:36 Psyche^ joined
pmichaud so I'm guessing that empty return returns nil 21:36
er, Nil
bacek rakudo: my @a = < 1 2 3 >; say "@a"
polyglotbot OUTPUT[@aā¤]
moritz should I merge these tickets? the discussion in #56638 seems relevant for the othe one.
pmichaud which other ticket? 21:37
moritz I'm looking it up, just a second...
#58770
pmichaud yes, merge them. 21:38
bacek gotta go.
purl EXCUSE ME, I HAVE TO GO WASH MY COMPUTER
bacek purl: you are good girl :)
purl :)
bacek pmichaud: can you review junction3.patch from #60168? 21:39
pmichaud testing for boolean should be $I0 = istrue $P0 21:40
not $I0 = 'prefix:?'($P0)
we don't need special prefix:! and prefix:? for Junction -- the defaults will do just fine. 21:42
I'm generally using '' for all vtable methods
find_global is deprecated.
for istrue, it's not even necessary to do that 21:43
we really don't need separate infix_junction_helper and unary_junction_helper -- instead we should just be using junction_dispatch 21:48
shall I add my comments to the ticket? 21:55
22:19 magnachef joined 22:21 magnachef__ joined 22:29 Theory joined 22:42 davidfetter joined 22:45 szbalint joined 23:06 Andy joined 23:13 d4l3k_ joined, PerlJam joined 23:14 jonathan joined 23:15 wolverian joined
jonathan pmichaud: Will add some tests for 'is also' next week - plan to hack Rakudo on Tuesday. 23:30
23:32 kj joined
pmichaud okay, excellent! 23:33
purl plays air guitar
pmichaud plays air guitar, also
jonathan The patch is...well...
I wish we could do the stuff somehow inside the multi-dispatch of the trait. 23:34
But anyway, it'll work until I can work out better ways to do things. 23:35
pmichaud okay, sounds great.
I'll be playing with it a little tonight or tomorrow
jonathan The new sub I added actually encapsulates some functionality that I think is used elsewhere in actions.pm, so I may refactor some bits involving traits soon to use that.
pmichaud okay, that sounds good 23:36
traits are handled a bit oddly inside of actions.pm
jonathan Yeah, I've got a better handle on traits now than when I wrote various bits of that.
pmichaud I think I'm going to go ahead and refactor junctions a bit, if only to guide others who are working on it 23:37
also, the changes we made today for pointy blocks might be enough to get lexicals "working" in trunk until we can finish the lex branch
the november folks would be very happy about that :-)
jonathan OK. Rightly or wrongly, I've been sorta not paying so much attention to it on the basis that I'd rather spend time in that area doing it properly by re-doing the dispatcher. 23:38
pmichaud that's good enough
I think what I'm going to do will also be a good guidepost for the dispatcher
jonathan Rather than spend time on stop-gap stuff.
OK, great.
The dispatcher is on my list of things I plan to take on if nobody beats me to it. 23:39
pmichaud I'm willing to bet that nobody beats you to it. :-)
jonathan I want to get the multi stuff finished up first, though.
pmichaud the only other person that I can think of that would be in the "race" for dispatcher is myself, and I'm planning to throw that race. :-P
jonathan I think my "big feature" path, if it works for you/others, for the rest of the year and maybe early next year is multis, then dispatcher (which'll sort out junctions, submethods...maybe the next METHOD style things while I'm in that area) and then parametric roles. 23:41
pmichaud that works extremely well for me (and others so far as I know)
23:41 silug joined
pmichaud I'm doing lexicals, then will be back on PGE 23:41
jonathan Excellent. 23:42
I'd be really happy to have protoregexes in before the year is out.
If that's realistic, anyway.
pmichaud oh, I expect that to be the case.
jonathan Nice.
pmichaud fortunately I have no other jobs/tasks at the moment.
jonathan I've fewer than I used to. :-) 23:43
Once parametric roles are done, I think I'll start pondering some bits of S09. Like the typed arrays.
I'd rather get them in and do it in terms of those - how it should be - than hack it into place earlier.
S09 is enormous though. 23:44
pmichaud it is indeed
we'll need captures somewhere before then... but that should wait on the new calling conventions branch
jonathan Yes. 23:45
pmichaud anyway, it sounds like a very good plan.
I'll be eager to see what comes out of the summit
jonathan Yes, me too. 23:46
23:48 mj41_ joined 23:49 baest_ joined 23:50 Themeruta joined 23:51 PerlPilot joined 23:53 _Hunger joined 23:56 wolverian joined, polyglotbot joined 23:57 AndyA joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!