»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: , or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by wolfe.freenode.net on 30 October 2009.
pmichaud and then we make that lexical 00:00
we know at compile time if the thing is multi or not
jnthn Oh, of course.
And thanks to contextucals, we even know it in routine_def
pmichaud exactly
jnthn OK, maybe it's not so bad. 00:01
I may try and do those tomorrow.
pmichaud 03-op-logic.t passes 00:02
jnthn Just pushed some fixes for default param values and named params.
pmichaud merged.
(testing) 00:03
jnthn Until we get to types, I think that (other than some fixes) will do us for sigs for a little while.
pmichaud pushed.
we may be at types very soon.
jnthn That's fine. 00:04
pmichaud I'm guessing we will.
jnthn They'll be easy to put back into the signature binder too.
Juerd enjoys reading your conversation.
jnthn heh, bonus
t\01-sanity\01-tap.t ............... ok
pmichaud heh 00:05
I haven't even attempted the 01-sanity tests
jnthn oh well, at least you know the first one passes
Oh gee
pmichaud I'm still working on the 00-parrots
jnthn One of the sanity tests does type captures. :-)
diakopter hm, maybe I broke dalek :)
pmichaud does Test.pm need them? 00:06
jnthn lol no
pmichaud then we don't need it in sanity
jnthn I'm not even sure they they're tested in there.
pmichaud I think that someone might've contributed a patch that tested it, and I applied it just because I didn't want to reject it
jnthn
.oO( hey cool, we run the sanity tests in 6s )
 00:07
pmichaud but if running Test.pm doesn't require a test from 01-sanity, it's a candidate for removal
jnthn Sure.
We test that elsewhere too in the spectests anyways.
One thing on multis...
I was pondering doing the HLL map to Perl6MultiSub. 00:08
Or at least seeing how it works out.
pmichaud feel free to test it. if it's hairy, don't commit, if it's simple, commit away :-)
afk for a second, i haz a honey-do
jnthn We spend a bunch of time at startup in master re-blessing them.
kk
.oO( haz a WHAT?! must be a texas thing... )
diakopter like a honeydew melon, only it's a request from a human-spouse, not a melon 00:09
jnthn oh! 00:10
diakopter "honey, do ____ [please|now|or_else]" 00:11
jnthn lol 00:12
rule honeydo { 'honey, do ' <task>+ [please|now|or_else] } # ;-)
diakopter goes and grabs 10-15kg of food from the company halloween party trays' leftovers, to take home. 00:15
00:17 patspam left
pmichaud sometimes it's more like <task>+! 00:19
rarely is it <task>+?
00:20 wknight8111 joined 00:22 pmurias left, Whiteknight left
pmichaud jnthn: you added a $*PARAMETER contextual? 00:24
jnthn pmichaud: yes 00:25
pmichaud: I wanted it available in e.g. named_param and param_var
pmichaud in general I think I'd prefer not to add variables that don't already exist in STD.pm. But in this case it may just be replacing the @*LEXPAD so we'll go with it for now 00:26
jnthn pmichaud: It's the details of an individual parameter.
pmichaud: We maybe could re-organize it...at the cost of neat code...
But I kinda liked the way this ended up looking. :-)
There's probably a neat way too, mind.
In fact, there surely is. 00:27
pmichaud oh, I think we can do something that is still neat :)
jnthn But anyways...
pmichaud in fact, in NQP there's actually not an action method for <signature>
because the <param_var> is able to add itself directly to the PAST::Block
jnthn Yeah
pmichaud (I know that's not the case here.)
jnthn In Rakudo signatures and blocks got a divorce. :-)
A block is something that has a signature, and can take it and attach it to itself. 00:28
pmichaud I can think of two other possibilities
jnthn As part of what it's made up of.
pmichaud one would be to reserve the [0] node of a block for its signature, the [1] node for initialization, and subsequent nodes for the body
jnthn I really disliked our inter-mingling of the two in what we have in master.
diakopter dalek: you alive?
jnthn I don't really want blocks to have anything to do with sigs though. 00:29
pmichaud so that when we enter a block (via <.newpad>), we set up its signature object then
00:29 Eevee joined, envi^home left
jnthn :(...) (sigterms) don't need a block, and my ($x, $y) doesn't either. 00:29
00:29 dalek left, dalek joined
jnthn It just feels kinda crufty to assume a block and toss it. 00:30
00:30 cdarroch left
pmichaud oh, I'm not in favor of that at all. 00:30
jnthn OK, good. :-)
I'm actually a tad bothered about STD's "fakesignature" rule, fwiw. 00:31
pmichaud part of the purpose of the contextuals (and the various $*LEX objects in STD.pm) is to make a distinction between parse and AST
i.e., so that one can do a parse without having to build the ast
(but still do lexical variable checking)
jnthn Hmm. 00:32
OK, I can buy that.
pmichaud NQP tends to combine the two, because that's easier to do for the simpler languages
Rakudo did the same, because we didn't have contextuals or a good STD.pm to go from
we should think a bit about how we might do the same in the new grammar
that said, I don't have any ideas of anything immediately better than $*PARAMETER so lets go with that. 00:33
jnthn Sure.
pmichaud (but I'll be thinking about it to see if I can come up with a better separation of parse+ast)
(or if I really want to :-)
jnthn I think based on what you've said, in terms of "does this affect our ability to parse", I think this particular case doesn't.
(it just sets up a contextual but it doesn't matter if it goes untouched) 00:34
pmichaud right
O
(wrong keys)
jnthn I'll try and keep this in mind though.
pmichaud I'm just not sure how much of the AST building should bubble up into the grammar.
(i agree it's harmless from a parse perspective)
jnthn Yeah, it's probably something of an anti-pattern.
It just made the actions oh so neat. ;-) 00:35
pmichaud still, I do like the neatness of it.
jnthn I'm glad you agree it's neat. :-)
pmichaud I won't make us take it out until there's something neater.
jnthn OK, wfm. :-)
diakopter I think it's neat you both agree it's neat
pmichaud I'm pretty pleased with the <O(...)> pattern for operator precedence, btw.
It took me a day or two to come up with that one. 00:36
(probably longer than it should've, but eventually I got there :-)
00:36 mtnviewmark left
jnthn It's different from STD, but seems to allow a bit more to be said about the operator too. 00:36
pmichaud it does
jnthn And tbh, I never actually understood STD's use of "-->".
pmichaud and it doesn't try to do the weird "use the return constraint to try to coerce the match object...." stuff 00:37
jnthn Yes, it's certainly a constraint and spec'd as such. Not a coercion.
pmichaud this is more straightforward -- "give the match object an <O> submatch with these values"
so, with the new signature binder in place, I can haz subs ? 00:38
jnthn Yeah, it seems clean, and it fits more nicely with the other compiler tools goals (e.g. wanting to specify a pirop).
Yes, subs work.
methods probably not quite yet.
00:38 orafu joined, ihrd joined
pmichaud (fits nicely w/pirop) there are also a few places where even STD needs to fold in an extra <O> attribute. :-) 00:38
diakopter 's ears perk up at the opp discussion
00:39 ihrd left
pmichaud what kind of subs can I have? I presume it doesn't do type constraints yet? 00:39
jnthn It doesn't. Do you want those?
tbh we don't actually have any types yet really. ;-)
pmichaud If I parsed but threw away the type constraint, would it work?
jnthn Yeah
Feel free to add the parsing rules and nothing behind them. 00:40
pmichaud hmmmm
jnthn If you don't stuff anything into the Parameter object, you'll be fine.
pmichaud I'm thinking I might go ahead and figure out how to parse operator multis
jnthn I didn't really finish filling it out yet.
Oh, awesome.
pmichaud that seems easier than writing cheats for the relational ops
jnthn Well, yes, I was hinting in that direction earlier. :-)
pmichaud (i.e. src/setting/Operators.pm) 00:41
jnthn fwiw, it's a cheat, but if you create a Perl6MultiSub, you can .push onto it.
(verifying that)
pmichaud would it hurt if we temporarily made all subs into multis? ;-)
jnthn pmichaud: Yes, you can. 00:42
pmichaud: Erm.
Well, there's one other thing that just crossed my mind.
pmichaud I guess they still need types to be able to distinguish
jnthn Today we mark things :multi()
Parrot makes it's multi-sub.
We then go through contortions to make that go away and replace it with our own.
Can we not just instantiate Perl6MultiSub and emit code to .push the candidates? 00:43
Heck, if you emit it as push vtable methods its even cheap. :-)
e.g. push multi, cand
pmichaud you're thinking do the .push as a loadinit action? 00:44
jnthn Dunno even about that.
pmichaud or in the case of lexical multis, when the lexical is established?
jnthn Yes, then for lexical multis.
pmichaud oh!
jnthn loadinit for namespace. 00:45
pmichaud I should mention, I'm likely to add a neat new feature to PAST
jnthn But since subs are lexical by defualt now.
The majority of our multis will also be lexical.
Oh?
pmichaud PAST nodes will get a .once attribute
jnthn ...oh?
pmichaud the first time thru, the node is executed as normal, but the result is cached away somewhere
second time threw the code, we load the same result we had previously 00:46
*thru
jnthn !!!
OK, trait app win.
:-)
pmichaud also lexical multis
jnthn Yes, indeed.
diakopter oh; I added that to sprixel's ast engine ........ <trails off>
pmichaud also <a b c d e f g>
we build the list once the first time we encounter it, and keep it as a constant thereafter
jnthn Neat. 00:47
Heh, we're at risk of not performing terribly. ;-)
pmichaud heh
it's a cheap and lazy way of building "constants"
jnthn Yes.
00:47 patspam joined
jnthn Hmm. 00:48
If you make it "per closure" we can use it to implement state vars. ;-)
oh no, maybe now...
pmichaud I might be able to do that, or something like it.
jnthn *not
Hmm, worth a thought.
Well, we've got plenty of state variable tests.
pmichaud having PAST be able to do state vars might also be a Win 00:49
jnthn Yeah.
pmichaud (or state values)
diakopter makes mental notes .oO(oh, I can do that similarly in sprixel)
jnthn It's just getting binding + assignment + closure semantics right
Which took...a little effort... :-)
pmichaud I need to go review the details of state vars and fold it into my mental models
the implementation feels slightly more complex than perhaps it needs to be (if we had better primitives) 00:50
jnthn Yeah, I think we can improve on it.
the thing is
.once per closure and .once ever are different semantics.
pmichaud right
jnthn We'd want one for state vars, if we could base these on top of this anyway.
pmichaud which is why I need to review the state var semantics a bit 00:51
jnthn And the other for constatns and trait app.
pmichaud so I can figure out where they overlap :)
jnthn Right.
The important thing is to keep the state vars attached to the closure.
If you do it as a property then...
pmichaud anyway, I was looking at doing a bunch of "build constants at loadinit" and then said "I really want to be doing that lazily" and came up with .once
jnthn 1) They get lost when you make a new closure, which does the Right Thing. 2) they get GC'd when the closure is no longer referenced too 00:52
pmichaud it may end up being .cache('once') and .cache('state')
(or .cache('global') and .cache('closure'/'block')
jnthn Yeah
pmichaud the only real difference is where the value gets held
jnthn If you start trying to stash the state vars somewhere global, it'll come back and bite you. :-)
yes, you're right. 00:53
diakopter yeah, attached to objs directly helps the gc be more natural...
instead of symbolic links/keys
pmichaud I'll review state vars and see about adding some PAST support for them, along with .once 00:54
(whatever it ends up being called)
jnthn Cool.
pmichaud but yes, having .once or something like it to pre-compute lexical multisubs can be a real win 00:55
jnthn Indeed.
Sounds quite workable.
pmichaud you're right about "trait app win" -- that hadn't occurred to me either :) 00:56
in fact, if we build our traits as a prophash, and then setprophash....
instead of a bunch of setprop ...
we only end up building the property hash once
instead of once-per-execution 00:57
jnthn erm.
trait app is either something done in the compiler for a few of them, and the rest are all multi-dispatches.
If they happen to insert something into the prophash, that's just a detail.
But yes, we should only do those dispatches once.
pmichaud I'm thinking about types on containers and the like 00:58
jnthn Ah.
Yes, in that case, we can.
But you can't assume it's just the prophash.
pmichaud if the prophash is static, they can all share the same prophash
jnthn True.
pmichaud if it's dynamic, we clone a static one and attach it
jnthn But it's the whole container 00:59
Not just the prop-hash.
And while they maybe can share the prophash, they perhaps (well, closure sematnics aside) should not be sharing the same Perl6Array or Perl6Scalar or whatever.
pmichaud well then, we build the whole container with props, .once that, and clone it
jnthn Yup
pmichaud the point being we don't need a separate structure to manage it :-) 01:00
jnthn That'll work.
Yes.
pmichaud and it gets done lazily
jnthn It'll take a little getting right, but yes, it's doable.
pmichaud okay, I need a break for a while. 01:01
need to figure out what I want to do with the relops
there are few enough of them that it may just be easier to cheat
if I run into more operators, though, I'm likely to work on p6-ifying it all
(only five relops aren't already cheats in Rakudo, so implementing those five is easy) 01:02
afk for a bit 01:03
diakopter moritz_: to where'd you run off
jnthn I think moritz_ is away for much of the weekend. 01:05
diakopter oh 01:06
01:22 lichtkind left
jnthn loliblogged: use.perl.org/~JonathanWorthington/journal/39821 01:29
quuxx jnthn blogged "Rakudo Day: Starting to put Rakudo together again": use.perl.org/~JonathanWorthington/j...1?from=rss
01:37 brunov left
jnthn OK, sleep time, night o/ 01:40
01:41 pnate2 joined 01:44 maja left 01:55 pnate joined 02:11 pnate2 left 02:12 tak11 joined
pugs_svn r28963 | pmichaud++ | [misc/pm.txt]: Added Pm-10. 02:12
r28963 | Pm-10: Subs are canonically considered to be stored in symbol
r28963 | tables (lexpads, namespaces) with the & sigil. Is the same
r28963 | true for methods? If we ask a method for its name or otherwise
r28963 | obtain a list of method names from an object, would we expect
r28963 | those names to have a & sigil as well?
r28964 | pmichaud++ | [misc/pm.txt]: Add a comment to Pm-10: 02:17
r28964 | (For HLL interop reasons Pm tends to want methods to not
r28964 | include a & sigil, but it's not a strong tendency.)
02:32 stephenlb left 02:35 charsbar left 02:36 charsbar joined 02:40 justatheory left
dalek p-rx: d35a707 | pmichaud++ | src/ (2 files):
The Regex and HLL libraries were inadvertently loading PGE.pbc (via PCT.pbc).
 02:49
02:58 xinming_ joined 03:02 mberends left
pmichaud std: say(3 and 4); 03:04
p6eval std 28964: OUTPUT«===SORRY!===␤Unable to parse argument list; couldn't find final ')' at /tmp/4uUDRvnlrE line 1:␤------> say(3 ⏏and 4);␤ expecting any of:␤ bracketed infix␤ infix or meta-infix (with precedence tighter than list infix)␤ infix stopper␤
.. standard …
pmichaud std: say([+] 1, 2, 3) 03:06
p6eval std 28964: OUTPUT«ok 00:02 109m␤»
pmichaud std: say(... 1, 2, 3)
p6eval std 28964: OUTPUT«ok 00:02 106m␤»
03:07 rml_ joined 03:11 xinming left 03:27 kst left, dalek left, d4l3k_ joined 03:28 d4l3k_ is now known as dalek, kst joined 03:30 rml_ left 03:37 tak11 left
dalek p-rx: 2e786f4 | pmichaud++ | src/ (2 files):
Include a '&' on operator names by default.
 03:53
diakopter pmichaud: I'm curious where labels/goto fit on rakudo-vNext's feature impl list 03:58
relative to the other big chunks
04:00 wknight8111 left
pmichaud low priority 04:01
I'm not even sure they're on our roadmap for Rakudo Star
04:01 tylerni7 left
pmichaud we *might* do labels for next/redo/last handling 04:01
(likely)
gotos may be way down the list, because of the subroutine entry/exit issues discussed briefly earlier 04:02
04:04 joe__ joined
diakopter oh.. if I may, sounds like it may need its own stack, frame creation, exception handling, etc..... essentially another VM layer 04:09
pmichaud it shouldn't, though.
I just need to pound on Parrot hard enough to get it to provide the features we need :)
diakopter imagines a stone sculptor trying to train a parrot to contort itself into the shape of a sculpture 04:10
"ok, hold that muscle right there; now stop breathing" 04:11
04:29 tylerni7 joined 04:31 fax left 04:34 astrojp left 04:36 joe__ left 04:37 frew joined 04:49 quuxx left 04:52 mepplock joined 04:59 tak11 joined 05:08 meppl left 05:18 patspam left 05:20 patspam joined 05:38 Chillance left 05:54 TiMBuS joined 05:55 mepplock left 06:07 mberends joined 06:32 tak11 left 06:41 envi^home joined 06:46 Schwern left 07:03 agentzh joined 07:11 agentzh left 07:24 agentzh joined 07:41 desertm4x joined 07:56 patspam left 08:00 synth joined
Tene does Perl 6 currently have a spec for pipe(2), select(2), etc? 08:20
mathw IO generally is pretty incompletely specced 08:21
I don't believe those are covered
Tene 'kay, I'll just make shit up.
mathw make shit up, we'll moan about it, even tually someone will just implement it and all will be well
carlin making it up is the best idea given what S32/IO looks like 08:22
Tene I'm more going the "implement something, then require someone else to make spec decisions if they want it different"
mathw that works too
sometimes you need to see something used to figure out if it's good 08:25
although to be honest I'm not sure there is a 'good' interface to select
it's irredeemably low-level
08:38 xenoterracide left, Su-Shee joined
Su-Shee hi all :) 08:38
08:40 xenoterracide joined 08:42 xenoterracide left 08:46 xenoterracide joined 08:53 patspam joined 09:07 xinming_ is now known as xinming
sjohnson hi 09:07
09:17 quuxx joined
carlin needs to make quuxx auto-restart after it segfaults 09:17
09:18 quuxx left 09:21 quuxx joined 09:46 Psyche^ joined 09:59 Patterner left, Psyche^ is now known as Patterner
sjohnson ..perl! 10:02
colomon perl 6! 10:12
sjohnson dances 10:19
colomon started writing a new reel this week, but doesn't think it's good enough to be the "Star of Rakudo". 10:22
sjohnson has faith 10:29
10:33 TiMBuS left
colomon sjohnson: did you follow all the insanity from jnthn++ and pmichaud++ yesterday? 10:41
github.com/rakudo/rakudo/commits/ng 10:44
10:45 Su-Shee left 10:46 xenoterracide left 10:47 agentzh left 10:48 xenoterracide joined 10:51 xenoterracide left 10:53 xenoterracide joined
sjohnson colomon: i didnt follow too much, as i am usually at work trudging through PHP / javascript when some major discussions go on... i will have a look though 10:53
colomon use.perl.org/~JonathanWorthington/j...1?from=rss 10:54
10:55 xenoterracide left
colomon also conveys a lot of it, but falls short on the sheer scale of it all. 10:55
10:57 xenoterracide joined
sjohnson colomon: also, a lot of the stuff they talk about is a bit over my head :) but i will check it out 10:57
colomon and I'm sure they will be back at it as soon as they are awake.
sjohnson: same here, of course. 10:58
sjohnson i would love to know where these guys find the time to apply themselves to pationately towards Perl 6 / Parrot 10:59
I work a fulltime job programming in languages I hate and after that, i'm exhausted
colomon I think they've both got a number of grants to work on rakudo. don't know the details. 11:01
sjohnson that is definitely a noble position, if the grant thing is the case 11:02
well, noble if it isn't the case as well
11:08 astrojp joined 11:25 Su-Shee joined, Su-Shee_ joined 11:26 Su-Shee_ left 11:41 ejs left 11:43 [particle] left
pugs_svn r28965 | payload++ | $_.foo ?\226?\134?\146 .foo # setting and testing the $_ topic, should also test if the feature of $_ is useable. 11:55
11:55 xenoterracide left 11:57 patspam left, xenoterracide joined 11:58 xenoterracide left 12:00 ejs joined, xenoterracide joined
jnthn oh hai 12:02
carlin o/ 12:04
12:04 patspam joined 12:05 pnate2 joined, patspam left
colomon \o 12:10
jnthn: Any notion when the ng branch will be far enough along that mere mortals can play with it? 12:14
(Help out with some of the lighter work to be done on it, etc.)
12:17 pmurias joined
jnthn colomon: It's hard to guess - right now it passes all of 3 sanity tests. ;-) 12:17
We're putting a lot of the more fundemental things back in first.
colomon But I'm fully optimistic it will pass all of the sanity tests by the end of the weekend. Maybe by the end of the day. :)
jnthn Maybe - depends where we focus. 12:18
I mean, we could hack in a bunch of the operators in PIR subs to pass the tests.
But more likely is getting multi-dispatch up and running again. 12:19
And operator parsing.
12:19 pnate left
colomon those both sound great. :) 12:19
12:29 rfordinal joined 12:30 rfordinal left 12:35 astrojp left 12:42 Whiteknight joined 12:56 pnate joined 12:58 pnate2 left 13:00 meteorjay left 13:01 xenoterracide left 13:02 xenoterracide joined 13:03 xenoterracide left 13:05 xenoterracide joined
jnthn lol i givez my lolsql to sql translashun on teh github!! 13:15
github.com/jnthn/lolsql 13:16
www.aaronbassett.com/2009/i-can-haz-lolsql/ # this guy's fault
13:17 astrojp joined
carlin PARSE FAIL! UR DOIN IT RONG 13:19
:(
jnthn carlin: Added link to README. :-) 13:21
(with syntax "guide") 13:22
Ah well, that's my bit of silliness for the day. :-) 13:26
oh btw, if the code is like, really crap, it's 'cus I wrote it in about an hour or so, while watching other people's talks. 13:28
mberends jnthn++: your silliness is another person's parsing tutorial :) 13:29
jnthn mberends: Well, there is that. :-) 13:36
pmurias jnthn: shouldn't lolsql use mismatched quotes like I CAN HAZ 'column" LIEK "VALUE'? 13:41
jnthn pmurias: lol n00b no 13:43
pmurias: spec sez `foo`
www.aaronbassett.com/2009/i-can-haz-lolsql/ ;-)
Though I did figure that literals should be '...' and not `...` 13:45
13:45 pnate2 joined
carlin Ohh... it wants "PLZ MAKES `column` LIEKS 'value'" not `value` 13:49
HAI! I'M IN UR `table` PLZ MAKES `column` LIEKS 'value' KTHNXBYE 13:50
UPDATE table SET column = 'value'
jnthn \o/
carlin is a lolsql pioneer
jnthn carlin: Feel free to get a commit bit and add examples. ;-)
otoh your IRC bot may be a more useful use of tuits ;-) 13:51
carlin Oh yeah ... I was in the process of writing a grammar for RSS when your lolsql distracted me, curse you :-P 13:52
jnthn lol
pmichaud good morning, #perl6 13:57
jnthn morning pmichaud :-)
Get some decent sleep in? :-)
pmichaud yes, I did 13:58
jnthn Same :-)
14:00 fax joined 14:01 pnate left 14:05 xenoterracide left 14:06 xenoterracide joined
jnthn rakudo: say 2 + 3.5; 14:07
p6eval rakudo d154eb: OUTPUT«5.5␤»
14:08 xenoterracide left
jnthn rakudo: for &infix:<+>.candidates { .signature.perl.say } 14:09
p6eval rakudo d154eb: OUTPUT«:(Complex $a, Complex $b)␤:(Complex $a, Any $b)␤:(Any $a, Complex $b)␤:(Rat $a, Rat $b)␤:(Rat $a, Int $b)␤:(Int $a, Rat $b)␤:(Int $a, Int $b)␤:(Any $a, Any $b)␤:(Whatever $a, Any $b)␤:(WhateverCode $a, Any $b)␤:(Any $a, Whatever $b)␤:(Any $a, WhateverCode $b)␤» 14:10
14:10 xp_prg left
jnthn rakudo: say 3/5 + 2.5; 14:11
p6eval rakudo d154eb: OUTPUT«3.1␤»
14:11 xenoterracide joined
jnthn rakudo: say 5/2 + 2.5; 14:11
p6eval rakudo d154eb: OUTPUT«5␤»
pmichaud jnthn: this morning I'm trying to figure out how to do list/array flattening
it has a fundamental impact on all list/array/assignment operations, so it's important to get it right-ish early 14:12
jnthn I agree.
So I guess what I'm curious to knwo is
(1,2,3) # what is this now? 14:13
Parcel?
List?
pmichaud Don't know yet
jnthn aww
pmichaud I haven't gotten a clear answer. It gets back to my earlier question of "how visible are Capture and Parcel?"
I guess it's pretty clear that (1,2,3) must be a Parcel 14:14
but if/when it is bound or assigned, it gets collapsed into a List
jnthn I'd guess more generally, when it's put into some context. 14:15
pmichaud hmmm
that might work
jnthn That was the impression I got from the discussion with TimToady
pmichaud my guess then would be that (1,2,3).WHAT gives back "List" 14:16
assuming that the .WHAT is item context
jnthn Hmm
Well, .WHAT is a macro, so it may be special.
pmichaud true
anyway, a parcel in item context flattens and becomes a List 14:17
jnthn But I guess the interesting question is what (1,2,3).method_call is more generally.
pmichaud I'm pretty sure .method_call imposes item context 14:18
jnthn OK, if we see it that way...
Only thing is that we don't want to have to do a .item on the invocant for every method call. ;-)
pmichaud we'd only have to do it on every parcel invocant 14:19
(3) is not a parcel
$x.foo # $x is not a parcel
jnthn Even if (3) is a parcel, in item context it's just 3.
pmichaud right
jnthn So it's kinda immaterial. :-)
pmichaud but according to current S08, it's &infix:<,> that produces the parcel
jnthn Ah, OK.
In that case then, it ain't a parcel. 14:20
pmichaud I'm thinking we'll need "flattening references" to be able to handle list interpolation
jnthn References that are tagged flattening? 14:21
Hmm. How do we do those, do you think?
pmichaud yes, although "tag" can also mean "type"
jnthn PMC subclass of ObjectRef?
pmichaud yeah
although, perhaps I don't need that
jnthn That could work.
pmichaud the tricky case is something like
jnthn We just need something that \ can whip off.
pmichaud my @a = 1,2,3;
my $a := @a; 14:22
say (@a, $a).elems # 4
say @a := $a # true
er
say @a =:= $a # true
jnthn hmm.
I think =:= would have to deobjectref its arguments...
pmichaud right 14:23
jnthn And my $a := @a; would take off the flattener.
Erm, the flatten-me tag.
Or however we choose to do it.
pmichaud actually, rethinking this a bit
jnthn Question is, what causes that...
pmichaud in my view of binding, my $a := @a actually creates an objectref (scalarref?) from $a to @a 14:24
same as if we passed @a to foo($a)
same as if we passed @a to sub foo($a)
jnthn Ah, OK. 14:25
pmichaud perhaps @a can have the "flatten me" tag, while $a doesn't.
i.e., flattening isn't transitive
jnthn So we care if the outermost thing has the flattning tag?
pmichaud right
that seems to also work in the case of
14:25 pnate2 left
pmichaud my $a := (1,2,3); 14:25
my @a := $a; 14:26
jnthn Heh. We can also write a *very* cheap "is_flattening" dynop for this too.
pmichaud @a would be an objectref that has the flattening tag
lambdabot Maybe you meant: activity activity-full admin all-dicts arr ask . ? @ v
pmichaud I don't mind looking up a property
I don't want to turn all properties into dynops
14:26 pnate2 joined
jnthn $1 = $2->base_type->vtable == flattener_id 14:26
No, but this is something we'll probably have to check a lot.
pmichaud even so
jnthn I don't mind us looking in hashes for things we do now and then. 14:27
pmichaud let's not prematurely optimize, please.
jnthn I don't really want that for things we have to do all the time.
pmichaud I really want to keep the dynop load down.
jnthn Because? 14:28
pmichaud I think we'll regret dynops later.
just a strong feeling I have.
(yes, they're a necessary evil. but I think they'll also bring some complications.)
jnthn Curious, given they've not really been a source of trouble for us so far. 14:29
pmichaud anyway, you're doing a test based on the type of the object, which doesn't work
it can't be a flattening type
it has to be a property on the container
(test based on type of object is what rakudo originally started with)
jnthn OK, so it's not going to be a PMC subclass?
pmichaud no 14:30
I'm thinking it might be a flattening property
jnthn OK, in that case the dynop makes less sense.
OK, in that case yes, we just want it in the metadata hash for now.
(I hadn't made the leap that you didn't want to do this as a container.)
pmichaud (ok) 14:31
jnthn OK, so infix:<,> is going to create a Parcel?
pmichaud one downside would be that every Parcel would end up with the flattening tag
I guess that's not too bad
jnthn TimToady seemed to quite strongly feel that we should have a "do flatten" tag, not a "don't flatten" tag. 14:32
pmichaud right
so that's the premise I'm working from today
14:32 meppl joined
jnthn If it's going to end up costly, we can work out a way to make it cheaper later, I guess. 14:32
pmichaud it might not be too costly
might be able to do something by-fiat --- i.e., flatten if it's a parcel or if it has the flattening tag 14:33
jnthn Well, let's get the semantics in first.
Hmm
pmichaud array lookups also end up with the flattening tag
jnthn I'd rather we didn't start checking for a bunch of different things.
Looking in a hash = cheap. isa = less so. 14:34
pmichaud well, if hash lookups are cheaper, we go with that and just make sure every parcel has the tag :)
jnthn Works for me.
pmichaud (not hard)
jnthn I really don't like the way we end up checking a whole loads of things at the moment.
In !flatten. 14:35
pmichaud well, we'll be able to get rid of a bunch of that soon
jnthn Yes.
pmichaud oh, !flatten becomes much simpler in the new approach
jnthn My most hated of which is that we checked for RPA and had to have an exclusion for multis!
Or somehting like that.
Anyway, sounds like this will be far cleaner. 14:36
So in our Parcel type, we have:
.list - always flattens and makes a List
.item - if it's 1 element, then that one element, otherwise same as .list ?
.Capture - makes our Parcel into a Capture, but we don't need to worry about this yet.
(last one can go on my worries list :-)) 14:37
pmichaud well, let's think about Capture a second
while we're looking at this
14:37 payload left
pmichaud if we need flags for flatten, perhaps we also need flags for 'named argument' 14:37
or 'named value' 14:38
because there's a difference between (1, 2, :a(3)) and (1, 2, 'a'=>3)
jnthn That's an interesting point, and I don't think S08 addresses it enough. 14:39
I mean, the S08 view seems to be that
14:39 pnate joined
jnthn foo(1, 2, :a<3>) 14:39
Conceptually, we start off with a Parcel, (1,2,:a<3>) and then it gets turned into a Capture because it's being used as the arguments to a call.
And it's the capture that has the named parts. 14:40
Of course, we don't *really* do that, because it's slooow.
pmichaud right. but "named part" has to be syntactic
jnthn Right.
Which is easy in the case that we're not *really* producing a parcel.
IIUC too, 14:41
sub foo() { return 1,2,:a<3>; }
my ($a, $b, $c) = foo(); # $c is a Pair
vs
pmichaud I would disagree with that.
jnthn my ($x, $y, :$a) := foo(); # bound as a Signature.
And thus capture-ified.
pmichaud I would think that my ($a, $b, $c) = foo(); should leave $c undef 14:42
jnthn I don't think so.
Because the return payload is a Parcel, not a Capture.
Or at least, that was the way TimToady seemed to be leaning.
pmichaud okay
14:42 kidd joined
pmichaud I'll go with that. 14:42
jnthn And my ($a, $b, $c) puts it in list context, which just makes a List. 14:43
pmichaud yeah, that works for me.
jnthn OK, cool.
pmichaud the tricky part is that if :a<3> is flagged somehow, we really do need a way to remove the flag
jnthn That does beg the question of if return 1, 2, :a<3> and return 1, 2, 'a' => 3 are different though. 14:44
pmichaud they're different if used in a signature bind
jnthn Aye.
That somehow needs to be flagged when making the parcel, but the flag has gotta go when we coerce the Parcel into anything else I guess.
pmichaud anyway, worth keeping in mind when we get to that stage 14:45
bbiab
jnthn ok 14:46
colomon Question from the peanut gallery: Why :a<3> and not :a(3)? 14:47
jnthn colomon: No reason - :a(3) woulda changed nothing.
At least, not in this context.
PerlJam colomon: perhaps $a has a constraint on it that it must be a string :) 14:49
pmichaud colomon: :a<3> is the same as :a('3')
14:49 pnate left
pmichaud colomon: just like <3> is the same as ('3') 14:49
jnthn: okay, so what are the cases in which we flatten ?
colomon pmichaud: I was wondering if that was it. Danke, everyone. 14:50
14:50 pnate joined
jnthn pmichaud: The most obvious one is, when we're put in list context. 14:50
pmichaud: What are the cases besides list context? 14:51
I mean, even in (1,2,@x,3,@y) then is there a case where we need to flatten before we're put into list context?
14:51 pnate2 left
pmichaud I guess my question is, where do we encounter list context ? 14:52
jnthn Meh, and there I was with a smart answer. :-P 14:53
Well, I guess we can try and make a list... :-)
pmichaud well, we get list context with for <something> { ... }
and we get list context inside of square brackets: [ <something> ]
jnthn we get it with list assignment.
pmichaud and we get it with list assignment
jnthn We get it in slurpies.
pmichaud and we get it when binding to slurpies 14:54
jnthn ...there's an echo in here.
:-)
pmichaud ...are there any others?
jnthn thinks
pmichaud I'm thinking it's always "only when bound to slurpies"
jnthn ? 14:55
PerlJam understanding context has always been fundamental to understanding perl. If you guys have trouble finding it, imagine what trouble newbies will have :)
jnthn We'll just tell them to google for it. ;-)
pmichaud list assignment is really &infix:<=>(List $lhs, *@rhs)
jnthn Heh. 14:56
You're thinking we can let slurpies trigger it always? :-)
pmichaud building an array is really &circumfix:<[ ]>(*@values)
for <something> { ... } is really map( { ... }, <something> )
jnthn doesn't cover (1,2,3).foo 14:57
well, (1,2,3).elems
pmichaud a parcel in item context flattens
jnthn Oh, though that's item context anyway.
But yes, it flattens.
pmichaud but yes, that doesn't fit the rule
okay, here's a question you may really like or really hate... :) 14:58
perhaps Parcel isa RPA
jnthn Well at least it stops you wanting Array to be one. ;-) 14:59
pmichaud more to the point, it means that .param pmc args :slurpy is naturally a Parcel
which then flattens
jnthn Flattens to give a list?
Hmm, interesting.
pmichaud yes
jnthn Heck, we could even hll_map RPA to be Parcel, then we don't have to hack methods into RPA... 15:00
pmichaud or perhaps our "Parcel" is really just "RPA"
jnthn (into RPA's namespace)
Hmm
But we want .item, .list and so on?
pmichaud true
jnthn .Capture
pmichaud I do like the hll_map idea
jnthn I'd rather we try and break away from polluting core Parrot namespaces.
I think Parrot is already set up to build the HLL-mapped type for slurpies. 15:01
If it's not, it's a couple of line patch.
pmichaud it was at one time, I'm pretty sure it still is
jnthn I know it was at one time, but said chunk of code also got ripped up and re-done recetnly. :-)
pmichaud I agree with not polluting core namespaces; the primary reason I'm still not doing hll_map is because I measured about a 2x performance penalty
jnthn I'm not sure your test was completely fair. :-) 15:02
pmichaud keep in mind that we double the number of objects created when we hll_map
(unless we create our own PMCs for Int, Num, Str, etc.)
jnthn iirc, you hll_map'd to a high level Object.
pmichaud right
15:02 pnate2 joined
jnthn Well, I was more thinking that we create a PMC subclass of RPA. 15:03
pmichaud wouldn't Parcel be a high level Object?
jnthn We can write our methods in PIR.
We just then avoid shoving them in RPA's namespace.
pmichaud same for Int, Num, and Str ?
...and Hash?
...and Undef? 15:04
jnthn Well, not really in some ways.
Our problem is that a bunch of those may need to become roles...
pmichaud it's Int that caused us the big performance hurt
hll_map Integer to Int instantly increased the number of PMCs we create
jnthn Yes.
In many senses, what we'd really like is role Int { has $!low_level_storage }
Where $!low_level_storage doesn't imply another PMC. 15:05
Unfortunately, unless we want to go write our own Object PMC...
...we're kinda stuck with present situations.
pmichaud anyway, I think we live with the shoving things in parrot namespaces for a little while longer. I totally agree with the overall goal of shaking them loose.
jnthn *situation
OK, I'm fine with that for now. 15:06
It may have just been an easy time to stop with one of them.
pmichaud but yes, subclassing RPA to Parcel seems like no loss
I'd prefer to make it a later optimization, though
jnthn Does this mean that our List and Array are now going have-a?
pmichaud and just get it working for now
jnthn OK, I can go with that. It should be an easy change later.
pmichaud and yes, it means List/Array are likely have-a 15:07
jnthn Excellent.
pmichaud which they were going to be anyway, for laziness
jnthn That means laziness will be....right.
And also it means they can become parametric roles.
pmichaud Indeed.
+1
jnthn And people can stop making Rakudo explode by writing my Array of Int $x;
pmichaud masak will be disappointed.
jnthn Nah 15:08
He'll find other ways.
:-)
pmichaud I have little doubt.
jnthn I think we're a bit off the day where masak++ can't find *some* way to make Rakudo explode, they'll just hopefully get increasingly convoluted. :-)
OK, so given all of these things... 15:09
If Parcel is the thing that cares about all the flattening, wonder if we can then make List and Array live wholly in CORE and not have PIR bits... 15:10
15:10 nihiliad joined
pmichaud I'm thinking we probably don't want to for efficiency reasons 15:10
jnthn OK.
pmichaud specifically list and array assignment
jnthn Yeah, true. 15:11
pmichaud *however*
for the time being I'll list the pir for them as being cheats
jnthn OK.
pmichaud I really like having the src/cheats/ directory
jnthn Same.
Hope we can kill src/parrot/ :-) 15:12
pmichaud it gives a place where we can tell people "maybe you could convert this to P6...?"
jnthn Since pa<tab>argh!
Of course, now it's pe<tab>...
pmichaud right
jnthn Once upon a time, it was p<tab> :-)
Those were the days.
pmichaud Unfortunately, Parrot/Compiler/Signature has ruined my tab completion for Parrot/Compiler.pir :-)
jnthn ;-)
aww 15:13
pmichaud er Perl6
jnthn Is perl6.pir in the root directory eventually going away?
pmichaud I think so.
jnthn and src/parser/ and src/parrot/ ?
15:13 payload joined, Psyche^ joined
pmichaud I like the /Grammar.pm /Actions.pm and /Compiler.{pir|pm} model for languages 15:13
jnthn *nod* 15:14
wfm
pmichaud src/parser will be going away, yes
jnthn OK. I already got rid of signature.pm when I moved it.
pmichaud src/parrot is likely to stick around, although I make turn it into src/cheats/parrots
*parrot
jnthn I like that. :-)
then p<tab> will work again \o/
pmichaud would that fi.... right :-)
15:14 pnate2 left, pnate2 joined
pmichaud okay, src/parrot goes into src/cheats 15:15
jnthn otoh if you're on case-sensitive file system it's P<tab> I guess?
pmichaud yes, but that's not an issue
(at least not for me)
it does beg the question as to whether we might want all of our filenames to be lc
i.e., perl6/compiler.pm instead of Perl6/Compiler.pm
jnthn yes, I was a little surprised when I saw the uppercase ones.
Not in a "that's bad" sense.
pmichaud I was following the parrot/perl 5 naming conventions
but I'm thinking perhaps I don't want to do that 15:16
jnthn Dunno.
pmichaud now would be the time to change it.
15:16 pnate left
jnthn I use a sufficiently advanced OS to see past trivialities like case of file names. ;-) 15:16
pmichaud otoh, I think I prefer load_bytecode 'HLL.pbc' to load_bytecode 'hll.pbc'
jnthn Yeah, same. 15:17
pmichaud and load_bytecode 'Lang/Library.pbc' to load_bytecode 'lang/library.pbc'
which kinda argues for the uppercase
jnthn OK, let's stay uppercase.
pmichaud oh, here's the clincher....
STD.pm is uppercase (so is Cursor.pmc)
jnthn Ah :-) 15:18
There we go then. :-)
pmichaud so we have a vote of sorts from the designer.
jnthn I guess we should pay attention to him once in a while.
pmichaud I've found it sometimes pays off.
jnthn :-) 15:19
I'm putting type constraints back in, btw.
for parameters
pmichaud okay
jnthn So life will be a tad easier when we get to operators.
I may make a first cut of lexical multis, and will assume we can just switch the init to .once or .cache or whatever in the future. 15:20
pmichaud will you follow the model that nqp uses for lexical subs ?
jnthn I want to.
pmichaud okay, good.
jnthn I was thinking something like...
Shove into the .viviself a PAST node that creates a Perl6MultiSub and puts the first candidate into it and stores that 15:21
And stash a reference to that node in .symbol
And then next time around, we just look for that node to be there, and if it is push the next multi into it.
Sound OK?
pmichaud +1
jnthn It's the cleanest I've thought of, if nothing else.
pmichaud very clean 15:22
jnthn Curiously, it means we stop emitting :multi()
I'm not sure what to do with package ones, mind...
Oh, that's another question I had.
pmichaud oh, you may run into a problem if you stop emitting :multi
jnthn I may?
pmichaud yes.
(long explanation coming)
jnthn But if I do emit multi, it's going to...well heck knows...
pmichaud just a sec while I try to figure out how to explain it. I discovered it while writing nqp-rx 15:23
(and you're *not* going to like it)
let's start with this 15:24
suppose I have
my sub foo() { ... }
and later I make a call to foo(). What PIR code do we emit?
currently we emit "foo"()
15:24 Patterner left, Psyche^ is now known as Patterner
jnthn $P0 = find_lex '&foo' 15:24
pmichaud actually, now we emit "&foo"()
jnthn $P0()
pmichaud would you prefer to switch the generation to explicitly do the find_lex instead of find_name ? 15:25
(we may have to)
jnthn Well, go on with what you were saying first..
pmichaud if we emit "&foo"()
jnthn But I think I can guess what might be coming.
pmichaud then IMCC wants to optimize that 15:26
jnthn I thought that opt got ripped out?
pmichaud oh, wait
jnthn "opt"
pmichaud that optimization is ripped out for lexicals now
so yes, no problem.
(it still exists for other things)
jnthn OK, so what was the issue you ran into for nqp-rx and multis, out of interest?
pmichaud I'm not sure now. 15:27
jnthn On "should we emit find_lex" - interesting question. I mean, if we *know* the sub is lexical statically...
pmichaud because I was having the case that calls to "foo"() were working even though they occurred before the lexical variable was initialized
jnthn Yeah
15:27 pnate joined
pmichaud i.e., I would write 15:27
jnthn The trouble with not emitting find_lex is that you can get false positives in the lookup.
pmichaud foo();
my sub foo() { ... } 15:28
and it would work, even though the lexical initializations were taking place in the code sequence order instead of being pushed to the beginning of the block
but now I'm not sure what was going on there
jnthn oh heh, and the slot in the lexpad was NULL, so it decided the symbol didn't exist...
And continued and looked in the namespace instead, I guess.
:-/
pmichaud can't be that
because (1) the sub doesn't go in the namespace 15:29
(2) the imcc optimization is a compile-time optimization
jnthn oh
pmichaud i.e., the actual bytecode generated for "foo"() is different
jnthn That's...odd.
pmichaud depending on whether a lexical exists or not
yeah
jnthn Anyway, should I be expecting issues with what I suggested, or it should be OK? 15:30
Oh, the other question I had. Is .symbol add-y or replace-y?
That is, will it augment the existing hash for the variable, or replace it with the new things I pass?
pmichaud I think it's replace-y
jnthn OK, so if I want to add (not sure if I need this yet anyway though) I'dhave to do like $foo := $block.symbol('$sheep'); $foo<wool> := 'white' 15:31
pmichaud yes.
I'll double-check.
jnthn 'k
Thanks. 15:32
pmichaud btw, last night I put in the code to switch our subs to be '&say' instead of 'say'
but I don't think I committed/pushed yet
I was getting kinda tired, so decided it would be better to wait until I was lucid
but it works out really well
looks like add-y 15:33
yes, it's add-y 15:34
jnthn Aha, great. Thanks. 15:35
hmm
pmichaud so $block.symbol('$sheep', :wool('white')) will replace the <wool> entry for $sheep
but it won't replace all of $sheep
jnthn Right, or add it if it's not already there.
Great.
15:35 desertm4x left
jnthn In token parameter I see this: 15:35
| {} <longname> <.panic("Invalid typename " ~ $<longname>.Str)>
carlin It would very baaad if it did
jnthn carlin: ewe should feel awful about that pun.
15:35 desertm4x joined
jnthn pmichaud: Is that {} just an empty closure? 15:36
pmichaud yes
jnthn pmichaud: some obsure hack?
Or likely leftover?
fossil?
pmichaud not so obscure -- I suspect it's marking the end of the token prefix
jnthn yeah, I did wonder that.
OK, I won't toss it then. :-)
pmichaud don't keep it for now, though
jnthn oh, ok
pmichaud at the moment I'd like use to build our grammar "naturally" without worrying about longest token 15:37
and only put in the token control hacks where we discover we need them
s/hacks/markers/
jnthn ok 15:38
oh, we don't have longname in the grammar yet...
pmichaud there are a number of places where the new grammar diverges from STD.pm (quote parsing is one), and it may be that as a result we need fewer things like {}
feel free to add longname 15:39
jnthn Hmm. At some future point I may be tempted to re-order the grammar rules a bit to more match STD.
15:40 pnate left
jnthn Makes it easier to see what we have and don't have. 15:40
But not now.
15:40 pnate2 left 15:41 pnate joined
pmichaud well, that's another area that I think we might be able to improve on STD -- I'm not certain of the ordering of things in STD 15:42
of course, we probably don't want to create our own ad-hoc ordering to replace STD's, so if we don't have a better scheme, we should just adopt STD 15:43
(STD's ordering)
jnthn Sure
It'd like to be able to more easily see differences, that's all.
pmichaud sure
jnthn But not a big deal yet.
oh grr
pmichaud NQP's grammar was written more to make it understandable by other (HLL designers) than to follow STD 15:44
jnthn I forgot putting typename back in meant I had to put the "is she a type" assertion back in...
pmichaud right
but you can now make it a method :-)
a method in the grammar :-)
jnthn oh yes
True.
What's the proper way to call a method on that? 15:45
STD seems to use $¢
15:49 IllvilJa left 15:54 pnate2 joined 15:55 justatheory joined 15:57 nihiliad left
pmichaud so does NQP 16:00
jnthn pmichaud: OK, cool. 16:01
pmichaud: I just noticed we call what std has as %chaining as %relational at the moment.
But since we refer to it as <EXPR('=m')> either way I guess that's fine. 16:02
pmichaud it's about to be %chaining
(it's %chaining in my local copy, implementing relops)
jnthn ah, great. 16:03
pmichaud %chaining didn't make sense for NQP
jnthn sure
jnthn is still getting his head around all of the new shiny :-)
pmichaud I'm going to clear out most of src/builtins/ (just move it to another dir for now), and end up with src/classes/*.pir in src/builtins 16:04
eventually eliminating src/classes 16:05
i.e., I'm thinking src/builtins/Object.pir, src/builtins/Positional.pir, etc.
jnthn OK.
Given a chunk of what's in there isn't classes anyway...
pmichaud right
src/builtins will be those things we write in PIR that really have to be PIR
(i.e., they aren't "cheats" by necessity) 16:06
jnthn nod
oh, no :dba(...) yet?
pmichaud no :dba(...) yet.
jnthn OK, that's why my grammar additions exploded.
...yes, it was.
Good.
pmichaud I've been commenting them out for now
jnthn oh, that may be a better idea than tossing them out...
jnthn does similar. 16:07
pmichaud I've got to do a few (somewhat big) refactors to get modifiers working properly
16:07 jan_ left
pmichaud so I've been foregoing them for now :-| 16:07
:i :s and :r work, though
jnthn As special cases rather than a more general modifier mechanism?
pmichaud so do :!i :!s and :!r, which PGE didn't have :-)
well, :i/:s/:r tend to be special-casey anyway 16:08
jnthn Ah, OK.
pmichaud because they actually affect the ast
TimToady STD tends to use {} instead of :: because :: ends up requiring backtracking in order to fail backtracking :(
pmichaud TimToady++ # thanks
16:09 pnate left
TimToady and I'm not particularly attached to the current rule ordering 16:09
16:09 pnate joined
pmichaud jnthn: how do you feel about underscores-vs-hyphens in filenames... ? 16:10
jnthn pmichaud: no strong preference, so long as we're consistent.
pmichaud I'm leaning towards making everything hyphens
jnthn That is, mixture = bad.
pmichaud (well, everything that we can)
jnthn wfm.
I've no problem with hyphens.
arnsholt Any OS X wizards in here who know how to force a universal binary to start the i386 branch instead of the x86_64 one? 16:15
pmichaud ...install it on an i386 machine? ;-) 16:16
arnsholt =p
pmichaud (no, I don't know)
arnsholt I figured =)
16:18 NorwayGeek left, NorwayGeek joined, TimToady sets mode: +vvv buubot dalek hugme, TimToady sets mode: +vvvv ilbot2 ilogger2 IRSeekBot lambdabot, TimToady sets mode: +vvvv lisppaste3 p6eval phenny pugs_svn, TimToady sets mode: +v quuxx 16:19 [particle] joined 16:20 literal left, avar left 16:21 pnate2 left 16:22 envi^home left, TimToady sets mode: +oooo buu carlin cognominal colomon, TimToady sets mode: +oooo japhb justatheory Juerd mberends, TimToady sets mode: +oooo PerlJam quietfanatic Su-Shee szabgab, TimToady sets mode: +oo Whiteknight xinming 16:31 lichtkind joined 16:36 pnate left
colomon TimToady: I've been thinking about uniq, for which we have a crude implementation in pir and no specs. 16:38
pugs_svn r28966 | lwall++ | [pm.txt] & in symtabs but no & in .^methods
pmichaud yay!
colomon Looks like the current version of uniq takes a equality comparison function and does a double-loop. 16:39
TimToady a correct impl should declare my %seen{Object} and then %seen{$_}++ 16:40
but rakudo doesn't do Object hashes yet
pmichaud we can approximate it 16:41
TimToady note that Object hashes essentially do === comparison on keys
not eqv
so maybe %seen{$_.WHICH}++ :) 16:42
colomon Interesting. I was figuring the best approach would be to sort the array and then loop on that.
pmichaud sort == bad
sort == expensive
TimToady uniq shouldn't reorder either
pmichaud correct
TimToady just throw away dups
colomon okay, then I guess a hash is probably the only reasonably efficient approach.
TimToady unless you know your list is already ordered 16:43
colomon (see, this is why I shouldn't be writing the spec...)
wait, WHICH? 16:44
16:44 fax left
TimToady returns the identity of an object, which for value types is the value itself 16:44
so it turns out that $a === $b is the same as $a.WHICH eqv $b.WHICH 16:45
colomon Does that imply we can do that %seen{$_.WHICH} now?
pmichaud no
rakudo: say 3.WHICH;
p6eval rakudo d154eb: OUTPUT«3␤»
TimToady rakudo: say [1,2,3].WHICH 16:46
p6eval rakudo d154eb: OUTPUT«47748906480568␤»
pmichaud oh, it might work
at least close enough for now
it'll fail if a list has both 47748906480568 and [1,2,3] :-)
colomon rakudo: say 47748906480568; say 47748906480568.WHAT 16:47
pmichaud (we need a way to distinguish object identity from integers :-)
p6eval rakudo d154eb: OUTPUT«47748906480568␤Int()␤»
colomon rakudo: say 47748906480568 + 0
p6eval rakudo d154eb: OUTPUT«47748906480568␤»
jnthn pmichaud: Yes, but === will never return true if the two things have different types.
TimToady that's an insoluable problem, unless values have an identity that is marked VAL(3) or some such
jnthn pmichaud: === is check types are identical, then check WHICH is identical.
pmichaud jnthn: but hashes currently use string semantics 16:48
colomon but that doesn't help indexing a hash, does it?
pmichaud jnthn: hashes don't use === semantics yet (in Parrot)
TimToady well, if an object address has a unique type
that would work
16:49 lichtkind_ joined
pmichaud jnthn: i.e., if %seen is keyed by $_.WHICH, then the (parrot) hash will still see the keys as equal 16:49
colomon rakudo: say [1,2,3].WHICH.WHAT
TimToady oh, yeah, strings
p6eval rakudo d154eb: OUTPUT«Int()␤»
jnthn pmichaud: ah, I see.
TimToady $_.WHICH.perl would include the type
pmichaud that said, bacek++ has been working on object-keyed hashes for Parrot
colomon could you do $_.WHICH ~ $_.WHAT or something like that? (obviously not terribly efficient)
TimToady but Int() is wrong in any case 16:50
addresses ought to be opaque, to the first approximation
16:50 avar joined
TimToady or you'll have people peeking and poking all over the place :) 16:50
return them in base 13, without the :13 on the front :) 16:51
jnthn pmichaud: Any thoughts on why this won't parse:
method add_my_name($name) { @Perl6::Actions::BLOCK[0].symbol($name, :does_abstraction(1)); 16:52
}
pmichaud NQP doesn't understand @Perl6::Actions::BLOCK yet
jnthn ah
pmichaud it only knows Perl6::Actions::BLOCK
jnthn hmm
pmichaud feel free to update NQP to understand the sigil there, or use Q:PIR
jnthn OK.
will do latter for now.
pmichaud jnthn: note that I've committed a couple of significant refactors recently 16:53
16:53 lichtkind left
pmichaud so you might end up with some merge issues. just a heads-up 16:53
16:53 lichtkind_ is now known as lichtkind
pmichaud (otoh, it might work out just fine :-) 16:53
...and just pushed another set 16:55
jnthn Glancing at the patches, don't see anything I expect to conflict.
oh!
16:55 iblechbot joined, tak11 joined
pmichaud hey, can we get rid of the fixup_cloned_sub stuff, too? 16:55
jnthn erm 16:56
maybe.
We can try.
pmichaud I'll leave it for later.
16:56 quietfanatic left
jnthn I did try and do a few bits to help us kill it. 16:56
colomon really wishes we were getting the ng branch commits from dalek...
s1n pmichaud: are you going to the dallas.p6m hackathon? 17:03
pmichaud s1n: I can't make it today -- kid and family stuff
s1n i think this month is going to be a bust then 17:04
pmichaud probably
it would be a bit difficult to hack on rakudo anyway, since the compiler is all topsy-turvy at the moment
s1n well that's a bummer 17:05
17:06 parduncia joined
s1n i usually look forward to the 2 hours once a month 17:06
pmichaud yeah, sorry about that
s1n not your fault, family is more important
pmichaud since we're in the process of basically redoing all of rakudo's fundamentals, it's a bit of a mess at the moment :)
and yeah, I'm stuck at home watching kids in between soccer and fencing and other activities 17:07
s1n i've mostly only been able to lurk lately anyways
another test this coming week (after 2 quizes in 1 week), getting a bit worn out 17:08
my feed reader has like 500 unread item lol
pmichaud my inbox has 2200 17:11
17:12 Jedai left
jnthn
.oO( The only thing that took longer than implementing Perl 6 was catching up on my email again afterwards )
 17:14
TimToady my inbox has 9292
17:15 Chillance joined 17:18 literal joined
pugs_svn r28967 | lwall++ | [STD] weed extraneous info to make message LLTA for say(1 and 2) 17:19
jnthn LLTA :-) 17:21
TimToady MTA doesn't quite work... 17:22
A is sort of like infinity
pmichaud jnthn: I'm also about to decimate big portions of Object 17:24
jnthn uh-oh :-) 17:25
pmichaud (I'll leave the dispatch-y and build-y stuff in place though)
jnthn pmichaud: A lot of the dispatchy stuff I'd like to move from there and the parts on guts.pir into some dispatch.pir anyway, so it's not so spread out.
pmichaud that'd be fine with me
what do you need from Object.pir to keep things working? 17:26
(I guess I can find out after I kill stuff off, but ... )
jnthn Well, I guess it was all there for a reason ;-=)
I've forgotten what's in there anyways.
checking
pmichaud I'll just start from an empty Object.pir and see what fails 17:27
that's easy enough
and then pull in the pieces that we need
jnthn bless/build/CREATE should stay, plus default new.
pmichaud but I kinda expect to re-do .list, .hash, etc.
jnthn also clone, defined. 17:28
The rest don't worry about for now.
pmichaud I'm thinking defined should go into the setting
jnthn Leave the dispatch-y bits out too.
17:28 [particle]1 joined
jnthn I'll re-incorporate them later into some dispatch.pir or some such. 17:28
pmichaud okay
jnthn When I put those fancy forms of dispatch back in.
pmichaud I've left a copy of the old Object.pir in src/classes
jnthn Probably not for a few days.
Sure
17:29 parduncia left
jnthn oh heh, we can't parse unsp yet. :-) 17:29
jnthn just comments out parametric types for now anyway.
17:30 [particle] left
jnthn pmichaud: If I want to emit, say, a type name, and I want to know if it's declared lexically, and if not fall back to package, is there a good way to do that in the actions yet? 17:31
I mean, other than walking thorugh @BLOCK...
I guess we'll factor that out somehow to a sub though...
pmichaud there's not a built-in default way
jnthn OK. Do you know how you want this to look?
pmichaud we had a sub to do it in actions.pm
I'd go with that
jnthn OK, you don't want a big change here. Fine.
pmichaud I don't have a huge improvement at the moment. 17:32
jnthn OK.
oh hmm...may need to resurect Perl6::Compiler.parse_name too...
pmichaud it doesn't already have .parse_name ? 17:33
oh, I guess not
that should go into src/cheats
jnthn seems missing in Compiler.pir
?
ohrly?
pmichaud yarly
well.... 17:34
pmichaud thinks
I guess you need it at compile time, so inside of Compiler.pir works
jnthn oh gah, tell me that after I just put it in cheats :-P 17:35
jnthn moves it back again :-)
TimToady STD has such routines as ordinary service methods down at the end 17:36
since symbol-tableness is actually important to parsing
pmichaud jnthn: yeah, it could go into Perl6::Grammar and then we'll just get Perl6::Compiler to forward to it 17:37
that might make even more sense
(NQP is going to want a similar setup)
jnthn ah, so it'll be Perl6::Grammar.parse_name from within the actions? OK.
oh but it's in PIR for now.
pmichaud thus it should go into cheats :-)
jnthn Oh gah, I'll leave it in Compiler now so I can actually get this chunk of stuff committed.
By diff is getting big... 17:38
*my
pmichaud we'll clean it up later, yes :)
avar pmichaud++ jnthn++ # nice blawg posts about rakudo progress
pmichaud even more nice than the blog posts is the progress :)
jnthn pmichaud: I may even clean it up today. :-)
avar pmichaud: heh
jnthn pmichaud: Anyway, I'm about to have type constraints working again. 17:39
as well as a bunch of other sig stuff.
just 'cus it was so little code to do it anyway.
avar Well I read the blogs but I don't use rakudo, so you could blog and not make progress for all I care (at the moment) :)
pmichaud goodie
colomon rakudo: say "This".WHICH
p6eval rakudo d154eb: OUTPUT«This␤»
pmichaud rakudo: say <M I C K E>.WHY 17:40
p6eval rakudo d154eb: OUTPUT«Method 'WHY' not found for invocant of class 'List'␤in Main (file src/gen_setting.pm, line 324)␤»
jnthn oh noes :-P
pmichaud .WHY? We don't know .WHY yet :-)
jnthn sheesh, I thought I'd been busy... 17:42
5 files changed, 223 insertions(+), 41 deletions(-)
plznoconflict plznoconflict...
yay
At this point, I'm going to break and go to the store, *before* it closes and I then end up going to the mcdonalds for dinner... 17:44
TimToady rakudo: say 2.5.WHAT
p6eval rakudo d154eb: OUTPUT«Num()␤»
TimToady hmm, I thought someone already fixed that...oh wait, it was just the .t I saw, I think
jnthn TimToady: It's wrong now? 17:45
TimToady 2.5 is specced to return Rat
jnthn ...oh?
wtf?
why?
I thought 5/2 would create a Rat, sure...
TimToady preserve precision of literals
pmichaud we haven't do anything with constant conversions yet
*done
jnthn ETOOSURPRISING
TimToady not at all 17:46
colomon it's just the flipside of
rakudo: say 5/2
p6eval rakudo d154eb: OUTPUT«2.5␤»
jnthn TimToady: So what if I want a floating point number?
TimToady want it where? in storage, or just as a literal? 17:47
jnthn literal
TimToady 2.5e0 works for that
but generally it shouldn't matter
and certainly, if the optimizer detects that 2.5 can only be used as Num, it can convert at compile time 17:48
alternately, literals cache various interpretations of themselves
jnthn Well, I'd like to think I'm capable of choosing how I want my numbers represented and whether I want to do fixed or flaoting point math...
Just feels odd de-hufmanizing floating point.
TimToady this feature isn't aimed at smart people lik eyou 17:49
it's aimed at people who want to add up a large number of dollars and cents and get an exact amount
jnthn nod 17:50
Makes sense I guess then.
TimToady at people who will ask why 0 ... * + 0.10, 10 doesn't stop exactly on 10
jnthn ;-)
Yeah, fair enough.
Just was a bit "omg" at first sight.
TimToady your job is now to make the feature as transparent as possible :) 17:51
along with it, default Rat is limited to rat64 semantics
so we don't get geometric explosions accidentally
jnthn kk 17:54
pmichaud: Having pulled/merged latest, I get less sanity test WIN than I might have expected...either I screwed something up (likely) or you have uncommitted stuff.
pmichaud: bbi 20 mins or so.
pmichaud jnthn: all of my stuff is committed 17:55
I currently pass 01-* through 04-*, and that's all
colomon \o/ 4 passes. (Or is that 8?)
pmichaud 4.
plus the 01-* pass in 01-sanity 17:56
so 5.
just pulled, let's see what I get
colomon \o/ even better than I thought!
rakudo: say (1..4).WHICH 17:57
p6eval rakudo d154eb: OUTPUT«18940032␤»
colomon That'll do.
17:58 tak__ joined
pmichaud jnthn: after pulling your commits, I get what I expect. I haven't completed lexicals yet, although I'm about to. 17:58
but fixing lexicals also means implementing infix:=, which means implementing STORE and FETCH and ...
and likely Parcel 17:59
sorry, &infix:<=>
(I need to mentally adjust to the new sub names. TimToady++ should be pleased :-) 18:00
colomon rakudo: my $range = 1..4; my @a = $range, $range.WHICH; say @a.elems;
p6eval rakudo d154eb: OUTPUT«5␤»
colomon how do I get that to not flatten out? 18:02
pmichaud you want @a to have a single Range element?
rakudo: my @a = [1..4]; say @a.elems 18:03
p6eval rakudo d154eb: OUTPUT«1␤»
colomon rakudo: my @a = [1..4], 10; say @a.elems;
p6eval rakudo d154eb: OUTPUT«2␤»
colomon Is that use of [ ] legit in the long term?
pmichaud yes 18:04
18:04 Whiteknight left
colomon thank you 18:04
18:07 tak11 left
pugs_svn r28968 | pmurias++ | [re-mildew] refactor AST::*, remove AST::Named,->emit_,->emit 18:12
18:15 am0c joined
pmichaud afk, fetching lunch 18:15
pugs_svn r28969 | colomon++ | [t/spec] Test to make sure we are not using a naive WHICH-hashing uniq. 18:16
18:17 dhaivat joined
dhaivat I was reading dev.perl.org/perl6 18:18
18:18 dhaivat is now known as camlin
camlin and it says that compiling is seperated from parsing and runtime 18:18
so does that mean its going to be two commands? like java? 18:19
javac then java?
18:19 fax joined
mberends camlin: it's optional how each implementation chooses to do it 18:20
camlin what do you mean implementation? isn't there only one perl? 18:21
or is rakudo and others different?
mberends camlin: Perl 6 is the language definition, Rakudo Pugs etc are implementations. Like C has gcc etc. 18:22
camlin oh i see... 18:23
so, there's not going to be just one perl anymore. There's going to be many of them I'll have to choose from 18:24
And, there is a perl written in haskell? How many implementations are there? Too many to count or just a few? 18:25
mberends just a few, Pugs is the Haskell based one. Rakudo is Parrot based. 18:26
18:27 jan_ joined
jnthn back 18:28
camlin Pugs is written in Haskell which is written in C. Wow, I thought I had enough choosing when I chose debian for a linux distro
mberends only the Haskell bootstrap is C based, thereafter it's self hosting.
jnthn back 18:29
camlin: Large parts of Rakudo are written in Perl 6 itself, it's kind of a 2-stage compile. And a lot of the compiler is written in a bootstrapped subset of Perl 6 too. :-) 18:30
18:30 am0c left
camlin what the hell? a perl6 compiler written in perl6? How does that work?! 18:30
jnthn camlin: Rakudo lets you just do perl6 script and it'll compile and run it by default, but it does let you pre-compile too.
camlin: Well, for the "standard library" we compile the core of the compiler, and then we use that to compile the rest and then bundle them into one. 18:31
For the other bits, mostly it's been done through bootstrapping (so there was at one time a throw-away version not in Perl 6).
camlin oh okay. So there is a compiler in the core, then you write the modules in perl6. That makes more sense. I think I like rakudo's design waay more 18:32
Haskell? Who even uses haskell?
jnthn Yes, the more of the compiler we have in Perl 6, the easier it is for people to contribute, I think. :-)
camlin nice. I'm pretty good at C, maybe i'll try my hand at developing.
any docs to help? 18:33
18:34 pnate joined
jnthn camlin: Probably not as many as would be ideal but some - see the docs folder, or github.com/rakudo/rakudo/tree/master/docs/ 18:34
camlin: We're actually in the process of a big refactor at the moment, but the overall sequence of things won't change all that much. 18:35
mberends camlin: newcomers usually begin by installing Rakudo, then try to use it for something. There are quite a few docs at www.perlfoundation.org/perl6 and www.perl6.org and rakudo.org 18:39
18:42 tak__ left
camlin thank you all very much. Perl has a very nice community. 18:46
mberends you're welcome camlin, please join in and make it bigger :-) 18:48
camlin installing git :)
jnthn pmichaud: heh, my fails went away after I pulled and installed the latest nqp :-) 18:58
pmurias camlin: ghc (the haskell compiler used by pugs) is written in haskell 19:05
pmichaud jnthn: excellent 19:07
jnthn pmichaud: We should have type checking back in place now - but hard to know until we have a few more types than Object. ;-) 19:08
pmichaud jnthn: I should have that shortly 19:09
well, depending on distractions. Things are looking a bit crazy around here this afternoon
I definitely like the use of the 'rw' flag instead of 'readonly'
that is already making things much cleaner
jnthn Yes, I can imagine. 19:10
camlin i'll be back 19:13
19:13 camlin left, tak11 joined 19:14 desertm4x left
pmichaud using 'rw' also takes a way a bunch of 'isa' checks 19:14
*away
jnthn Good. We spend far too much time doing those. 19:21
I'm hopeful the flatten flag will take away a bunch more. 19:22
pmichaud it will 19:23
without question
I'm convinced we have the right model this time :)
19:27 dhaivat joined
dhaivat I have question about installing rakudo 19:27
I got the tarball
and extracted it and entered that directory
now, when I do: perl Configure.pl --gen-parrot
it gives me stuff like ===Sorry!===
unable to locate parrot_config 19:28
what should I do?
pmichaud was it able to download parrot ?
it should download parrot (via svn) and then build it
colomon dhaivat: Do you have subversion installed?
dhaivat can't exec svn
mberends dhaivat: you need subversion as well, as pmichaud++ is suggesting
dhaivat OH! i don't have svn
:(
i'll get it
19:32 leedo left
dhaivat (reading parrot docs) Parrot is pretty beast, may allow for easy communication between perl and python and such. Maybe even slow down the holy wars. 19:33
okay, its building parrot 19:34
TimToady <pmichaud> colomon: :a<3> is the same as :a('3') 19:35
actually, with the recent change it now means something more like :a(3 but Str('3')) 19:36
dhaivat wait, rakudo won't replace perl5 will it?
pmichaud TimToady: I haven't caught up to that change yet
TimToady np, just doing attitude adjustment with a 2x4 :) 19:37
pmichaud np
mberends dhaivat: only on your system, if you want it to ;-)
pmichaud otoh, I'll be curious to see how that parses
colomon TimToady: 3 but Str means it's an integer that does the Str role with a string value of '3'?
dhaivat no, but I don't want it to!
can I stop it?!
colomon dhaivat: it won't replace your perl 5 executable
TimToady which doesn't much matter for an Integer, make makes more of a difference with :a<1/2>
dhaivat will it replace the command "perl"?
mberends no, it becomes perl6 19:38
dhaivat okay, that's good .)
:)
TimToady dhaivat: if it does replace perl, it's required to emulate
19:38 dhaivat is now known as camlin
TimToady basically, though, if you meantion '6' anywhere, it doesn't have to assume Perl5 :) 19:38
colomon dhaivat: believe us, we're all using perl 5 as perl too. it's a key component of the rakudo build process. 19:39
camlin I see.
So, in order to build it, you must have perl5. Perl6 just goes on top of perl5?
basically, builds on it right?
pmichaud no
TimToady depends on the implementation
camlin rakudo
colomon camlin: for now it's an entirely separate language.
pmichaud currently rakudo uses Perl 5 as part of its build process, but once running it's independent of perl5 19:40
mberends rakudo would be installed alongside perl5
19:40 TSa joined
camlin I see. It takes a while to build. how large is the code base? 100 mb? 19:41
mberends 306MB here on x86 at the moment, but that includes lots if git logs. 19:42
pmichaud mberends: does that also include parrot ?
mberends pmichaud: yes 19:43
parrot is 145MB of that 19:44
camlin holy 19:46
So, Parrot basically interprets bytecode correct? 19:47
mberends yes
camlin ah. So, if I want to develop perl6, I can safely ignore Parrot most of the time? 19:49
because a 145 MB code base is really, really intimidating. 19:50
The biggest I've ever gone is 500 lines.
pmichaud that number is a bit misleading
145MB likely includes not only parrot, but also its subversion copy
and whatever subversion history happens to be stored in the .svn directories 19:51
and a bunch of compiled libraries, and ...
camlin I see. but still even if its only 100 MB, that's pretty dang big.
okay, I'm off to go trick or treating now :) 19:52
mberends camlin: a parrot tarball would be a more compact option, and as a Perl 6 programmer you never have to look into it.
camlin i see
mberends have a nice trick|treat
camlin I want develop Perl6. Would I still have to mess with Parrot? 19:53
TimToady std: say(3 and 4)
p6eval std 28969: OUTPUT«===SORRY!===␤Unable to parse argument list; couldn't find final ')' at /tmp/SEuR5S4u0B line 1:␤------> say(3 ⏏and 4)␤ expecting an infix operator with precedence tighter than list infix␤FAILED 00:01 106m␤»
s1n camlin: no, see the src/setting directory
camlin in what?
s1n rakudo
camlin okay
colomon Looks like the actual parrot source (counting tests) is 21 megs.
mberends camlin: no, --gen-parrot is all you will see of parrot
camlin ah. That's not so bad.
19:54 camlin left
colomon Minus tests and examples, 14.6 megs 19:54
s1n which is pretty tiny 19:55
pmichaud okay, time to add variable interpolation to nqp/ng
(scalars, at least)
19:56 xp_prg joined
jnthn sheesh you guys said a lot while I nommed dinner :-) 19:56
s1n pmichaud: i was carving pumpkins and didn't make it to the meeting (doubt anyone else did), we were going to get that site up and running, i have a few minutes now
pmichaud I kinda don't, alas. 19:57
I should be able to do it in a day or two
19:58 sifusam joined
s1n that's-a no-good, i have an exam on thursday 19:59
(unless it's this weekend)
pmichaud next weekend is likely better for me 20:00
I have _way_ too much on my plate for the next few days
s1n sounds good 20:01
20:05 nihiliad joined 20:16 NorwayGeek is now known as iGhost
pmichaud 05-var.t passes. 20:18
need a break here... will come back and do either inplace ops or arrays next 20:19
jnthn pmichaud++ 20:20
pmichaud: epic fail 20:42
NMAKE : fatal error U1073: don't know how to make 'src\builtins\assign.pir'
Thing just a forgetting to git add. 20:43
pmichaud looking
correct.
added, merged, pushed. 20:44
jnthn pmichaud: thanks
pmichaud: Just added multi parsing.
pmichaud: But not making them multi just yet.
$*MULTINESS is set though :-) 20:45
pmichaud jnthn: epic fail, after merging I get all failures 20:48
wait, might be a local change
okay, it was a local change 20:50
jnthn
.oO( phew! )
 20:51
20:53 payload left
pmichaud Just added Any. 20:53
jnthn Cool 20:54
colomon desperately tries to follow the action on github... d:) 20:56
pmichaud colomon: does github.com/feeds/rakudo/commits/rakudo/ng help ? 20:57
colomon pmichaud: the problem isn't finding the changes, it's understanding them. : 20:58
:
:)
jnthn ...what...I'm supposed to understand these? 20:59
colomon I'm trying to grok Any.pir at the moment. 21:00
pmichaud it just defines a class and a couple of methods
jnthn didn't see that one yet
Ah, just those. 21:01
Nice.
colomon please don't slow down to explain for my sake. it's just fun following along and seeing what is going on, even if I only understand about 20%. 21:02
colomon notices that all the functions just forward to self.HOW, which seems very odd, but actually kind of comprehensible. 21:03
pmichaud normally 'isa' and 'does' are handled by the metaclass object
jnthn std: multi sub { }
p6eval std 28969: OUTPUT«ok 00:01 104m␤» 21:04
pmichaud i.e., $foo.isa(...) is really $foo.HOW.isa(...)
21:04 Schwern joined
jnthn well 21:05
$foo.HOW.isa($foo,...)
:-)
pmichaud jnthn++ # more precise than me
jnthn actually just went to check Any to be sure than pmichaud++ got it right there ;-) 21:06
pmichaud: You know how you were saying earlier about how routine foo got called beforehand even if it was lexical? 21:17
pmichaud: Turns out that we're emitting the .lex "foo", $P13 21:18
But also the sub is emitted as:
.sub "foo" :subid("12_1257023849") :outer("11_1257023849")
Which means it's getting a namespace entry too.
21:23 eternaleye joined 21:28 tak__ joined 21:41 tak11 left
pmichaud jnthn: yes. 21:43
you can set .nsentry('') to prevent that.
$block.nsentry('') 21:44
thing is, we _want_ the sub to have a name
so that if we say(&foo) it comes back with "&foo"
21:44 kidd left
pmichaud but we don't want it to be in the namespace 21:44
21:44 tak__ left
pmichaud so PAST knows that .nsentry('') means "flag it as :anon" 21:45
jnthn pmichaud: ah, ok
pmichaud (which prevents it from going into the namespace)
jnthn Think I'm close with lexical multis.
pmichaud also note that it needs to be "&foo", not "foo"
jnthn Yes, I fixed that already. ;-)
pmichaud okay.
jnthn I'm not sure how we'll do package multis just yet.
pmichaud I'm about to have (real) metaoperators for the inplace ops
jnthn omg
pmichaud I already have it parsing correctly 21:46
jnthn \o/
wow
pmichaud what's more, it'll generate only the metaops we use :)
jnthn Even better.
pmichaud I decided that was actually going to be easier than the gen_metaops approach, at least for the inplace ops.
aren't the package multis still lexical symbols? 21:47
(which is a bug I currently have in my lexical scalars code)
21:47 tak11 joined
pmichaud here's the model I think we end up with for "our" 21:48
essentially, if I say our $x;
the symbol $x itself is still a lexical symbol
what's different is that it's bound to a PMC that is in the package instead of a locally created one 21:49
21:49 tak__ joined
jnthn I always understood it in Perl 5 and a lexically scoped reference to something in the package, fwiw. 21:49
*as a*
pmichaud okay, we'll be doing the same thing here, then. 21:50
jnthn OK, sounds nice.
pmichaud so, package multisub should be the same as lexical one
bind the lexical, push the multisub
the difference being that the Perl6MultiSub is being kept in the namespace instead of locally scopped
jnthn ooh 21:51
OK, that'll be really easy then.
pmichaud right
and my variables code simplifies a bit also
(but I'll get back to it after doing assignop :-)
oh, I can commit what I have now and do the variable stuff 21:52
jnthn ooh, I love the new multis code gen. :-)
pmichaud aren't you glad we started over? ;-) 21:53
jnthn I added a set_candidates method to Perl6MultiSub. :-)
It takes a slurpy parameter.
pmichaud heh
I like that.
jnthn Which of course builds an RPA. Which is exaclty what we store the candidates list as.
So right now adding another candidate looks like:
$symbol<multis>.push($past);
pmichaud oh, sure, that works :-)
WIN.
jnthn Yeah, apart from for some reason not quite working yet. :-/ 21:54
The code it generates looks right
Oh, I didn't set nsentry to empty...wonder if that's it.
pmichaud I wouldn't expect that to be it. The fact that there's a lexical of the same name in scope is supposed to prevent such issues.
(but try it anyway, just in case) 21:55
jnthn oh, it'll be something sillier.
(don't have the signature being generated with the "this parameter is a multi invocant" flag bit)
21:57 tak__ left 22:01 Su-Shee left 22:04 tak11 left
pmichaud yay, "our" variables now have lexical symbols. :-) 22:04
jnthn \o/ 22:05
pmichaud gist.github.com/223273 # lexical symbol bound into package object 22:06
jnthn In other news, 01-sanity/07-simple-multisubs.t passes
pmichaud woo hoo! 22:07
okay, back to the infix_postfix_meta_operator :-)
jnthn pushed 22:09
pmichaud: Hmm...fail? 22:12
pmichaud: With your latest changes I get
Parent isn't a Class.
At startup.
(in bool) 22:15
oh sorry, I think it's my fail 22:17
(out of date makefile)
22:22 TSa left
pmichaud btw, if you haven't guess already, NQP understands :abc and :def<blah> as alternatives to :abc(1) and :def('blah') :-) 22:30
*guessed
(in case you prefer those)
jnthn oh, I didn't know that. 22:31
That'll teach me to reed the grammar probably. :-)
I think I've just won us another of the 00-parrot tests, btw 22:32
pmichaud yay
I think I have assign metaop code generation almost done
jnthn Great. :-)
pmichaud just need to write the builtin to dynamically create the metaop when needed :)
jnthn oh no, it wasn't an 00, it was an 01 22:33
oh well, it's still a win.
t\01-sanity\05-sub.t passes now
btw actually 01 through 05 of t\01-sanity now pass 22:34
pmichaud excellent
I should be able to definitely complete Parcel, List, and Array today
jnthn I love patches that remove more lines than they add. :-) 22:35
Especially when they also pass more tests. :-)
ooh...Parcel, List and Array being in would be excellent.
22:36 synth left
jnthn BTW, I guess we're now just parsing operators off being able to write operators in Perl 6. ;-) 22:38
dukeleto jnthn: those are the best patches
pmichaud jnthn: I'll look at it later tonight also
jnthn Great.
dukeleto pmichaud: ping!
pmichaud dukeleto: pong
dukeleto pmichaud: parrot wants nqp-rx in core like a fish wants to be in water 22:39
pmichaud haven't read email yet today
jnthn Yeah but sometimes a fish is better out of water and in the deep fat frier.
.oO( now everyone is trying to understand the meaningless metaphor )
 22:40
pmichaud dukeleto: I have several reasons for wanting to keep nqp-rx out of the parrot repo 22:41
dukeleto pmichaud: please lay them on me
pmichaud one of them being that parrot's current policy is to drop copyright notices
so, effectively, once it's in the parrot repo, PaFo "owns" it
and since there may come a day when we'll want NQP to target additional backend platforms, I don't want it to be that tied to Parrot 22:42
dukeleto pmichaud: we make everything copyrighted by Parrot Foundation, to protect us against copyright law, yes. The CREDITS file describes contributions on a more fine-grained level
pmichaud the other issue is that I'm not sure I'm authorized to contribute it to PaFo. The work I'm doing is "for hire" by the Perl Foundation. Technically they own the copyrights. 22:43
dukeleto pmichaud: Parrot supports dual licensing with an OSI-approved license, i am pretty sure
pmichaud dukeleto: dual licensing isn't my issue
dukeleto pmichaud: interesting. i suspect other work in Parrot core has been supported by The Perl Foundation
pmichaud dukeleto: in the past that's been true, certainly.
but at the time the bulk of the parrot code was actually owned by the Perl Foundation, and then later transferred to PaFo 22:44
that doesn't mean that all new code should go there
dukeleto pmichaud: assuming there are no legal issues with putting nqp-rx in parrot core, do you have technical issues as well?
pmichaud yes, svn versus git being one
dukeleto pmichaud: also, what if The Perl Foundation and Parrot Founation signed a treaty that says, we all own each others stuff? 22:45
pmichaud also I'm not at all a fan of Parrot's deprecation policy. I don't want to be constrained by it.
dukeleto pmichaud: i am working on git. feel free to use the parrot github mirror, i updated it with a cron job every 2 hours, including all parrot branches 22:46
pmichaud: i understand the deprecation policy reservations. this is why using nqp-rx as a git submodule is the optimal solution.
pmichaud well, if a git submodule, then nqp-rx still lives in its own repo, yes? 22:47
dukeleto pmichaud: would you be opposed to parrot using nqp-rx as a hacked up "git-svn" external?
pmichaud: yes, a git submodule is a way of telling one git repo "hey, use this git repo at this URI for this directory"
pmichaud I already mentioned in my email that I see no problem with Parrot grabbing the nqp-rx sources directly under AL2. I just consider the mainline development to be in the nqp-rx repo, which doesn't fall under Parrot licensing or policy.
dukeleto pmichaud: nqp-rx would be it's own software with a separate deprecation policy and license
pmichaud: i fully understand your reasons of not wanting to be constrained. I support that totally. We don't want to constrain you! 22:48
pmichaud what's the purpose/point of bring in all of the nqp-rx sources, though?
why not just bring the files needed to make nqp-rx available under parrot?
(as I proposed in my email) 22:49
dukeleto pmichaud: we could, at configure-time, all the use of different versions of nqp-rx, if the user/developer wanted that. mostly for devs and testers
s/all/allow/
22:50 synth joined
dukeleto kind of like how rakudo pulls down a parrot checkout... 22:50
pmichaud okay. so you'd still just pull the four files, though?
22:51 pmurias left
pmichaud i.e., to build the libraries and nqp only requires four pir files 22:51
and they're already kept up-to-date in the repo.
dukeleto pmichaud: yep
pmichaud anyway, as I said, I have no problem with parrot grabbing sources from the nqp-rx repository. It's all AL2.
jnthn Wouldn't Parrot instead picking and targetting "releases" of nqp-rx (I know none yet) be a better way forward long term?
pmichaud jnthn: that was my feeling/expectation
jnthn ah, ok :-) 22:52
dukeleto pmichaud: we want to make your life as easy as possible, while getting all the benefits of nqp-rx :)
pmichaud in fact, nqp-rx's release schedule is the second tuesday of each month
precisely so that it'll be released one week before the parrot release :-)
dukeleto jnthn: yes, we should target released versions of nqp-rx. but rakudo should target release versions of parrot as well ;)
pmichaud: that is awesome! good to know
pmichaud dukeleto: the problem with "target release versions of parrot" is that we typically can't live that long with a monthly release
I think the longest we've been able to go on a parrot monthly release is five days 22:53
and that was just once
22:53 fax left
jnthn dukeleto: Rakudo releases *do* target released version of Parrot. 22:53
pmichaud except for that, usually we have to bump PARROT_REVISION within 48 hours of a Rakudo release
dukeleto pmichaud: let us know what we can do to help
jnthn: I stand corrected, they do.
jnthn I'm not sure right now it's a problem as such. 22:54
pmichaud dukeleto: there's not much to be done to help that. The reason Rakudo bumps PARROT_REVISION so quickly is because in order to get some feature to work in Rakudo we need a corresponding feature from Parrot
dukeleto pmichaud: of course. Parrot is delighted that you guys keep upgrading!
pmichaud and if we don't bump the PARROT_REVISION, that means we can't test/use that feature in Rakudo until Parrot's next monthly release, which may be 25-30 days away.
jnthn Aye. Also, Parrot of late lands sizable branches quite often after a release. 22:55
22:55 synth left
dukeleto jnthn: you could say that three more times. 22:55
jnthn It's nice if we can adapt to those well in advance.
22:55 synth joined
pmichaud yes. If we were targeting monthly releases, we'd not be able to take advantage of PCC branch until the November release of Rakudo 22:55
er, actually, December release of Rakudo 22:56
dukeleto jnthn: we actually "merge bomb" trunk hours after the release. Not a pretty sight...
jnthn Yeah, I noticed that.
dukeleto pmichaud: we want to give rakudo devs features and bugfixes as fast as our dep policy allows
jnthn The pccupdate one was an unusually big one though.
pmichaud dukeleto: anyway, if you want to set up Parrot to grab and configure nqp-rx into Parrot, I will cheer loudly.
dukeleto pmichaud: consider it added to my insanely long todo list. 22:57
pmichaud dukeleto: oh, eta then?
dukeleto pmichaud: what is the easiest way to run the parrot test suite with nqp-rx?
22:57 nihiliad left
dukeleto pmichaud: but it got added pretty close to the top ;) 22:57
pmichaud part of the reason I posted my message (and offered to do it) is that Rakudo will want to use nqp-rx soon
...parrot test suite?
you mean to write parrot tests in NQP? 22:58
dukeleto pmichaud: uh, plumage has a test *harness* written in NQP
pmichaud: as well as it's configure system
pmichaud I don't quite understand the question then.
dukeleto pmichaud: and many other parrot add-ons are following this
pmichaud (good, having parrot libraries and addons written in NQP has been my goal :-) 22:59
dukeleto pmichaud: i want to verify that all of our stuff continues to work when using nqp-rx, instead of plain nqp
pmichaud dukeleto: oh. You just need to build nqp-rx and then "make install'
dukeleto pmichaud: it overwrites parrot_nqp ?
pmichaud that will put an NQP-rx.pbc binary in languages/nqp, and it will put a "nqp" binary in the bin/ directory.
"nqp", not "parrot_nqp"
dukeleto ah, so parrot needs to be modified to find nqp instead of parrot_nqp 23:00
that is probably hard-coded up the wazoo
pmichaud well, someone wanting to use the old one would do parrot_nqp, someone wanting to use the new one would use nqp
I'm completely open to changes and suggestions on that front
jnthn I suggest we allow folks to migrate as they wish rather than forcing it on them.
pmichaud I should say that nqp-rx is not entirely a drop-in replacement for parrot_nqp 23:01
dukeleto pmichaud: indeed. i will brood upon that for a bit before replying.
pmichaud there are a few differences
23:01 nihiliad joined
dukeleto pmichaud: i am excited to hear about them 23:01
pmichaud I've been compiling a list
dukeleto sweet!
jnthn OTOH, actions.pm was a good example of how easy the switch can be.
It's not painful. 23:02
pmichaud oh yes, the switch is very simple
well, maybe.
jnthn Or at least, wasn't for what is probably the biggest nqp source file in existence.
pmichaud the change I added today might make it more painful.
jnthn oh?
Which one?
pmichaud scalar variables interpolate in double-quoted strings
jnthn oh lol
Yes!
dukeleto pmichaud: how big is the biggest nqp source file in existence?
pmichaud: interpolation! /me swoons
pmichaud dukeleto: it's undoubtedly Rakudo's action.pm, as jnthn++ said 23:03
dukeleto pmichaud: approx line count?
pmichaud dukeleto: 4K lines ?
dukeleto i was getting really good at typing ~ " foo " ~ ....
pmichaud 3450 lines.
dukeleto pmichaud: plumage currently has 1318 lines of NQP and lots more PIR 23:04
that depends on the NQP working the way it expects
so i feel it is a good test bed to make sure that NQP does not have any horrible regressions or non-backward-compat 23:06
let me clarify that. non-backwards-compatibility that we care about
how soon would rakudo like to see nqp-rx in parrot core? 23:07
pmichaud sorry, wife needed some questions answered 23:24
asap
(rakudo would like nqp-rx in parrot core asap)
dalek p-rx: 1e17347 | pmichaud++ | src/HLL/ (2 files):
Rename <escape> subrule to <quote_escape>.
 23:29
p-rx: dcee671 | pmichaud++ | (3 files):
[nqp]: Add interpolation of scalars into double-quoted strings.
23:31 iblechbot left
pmichaud afk, dinner 23:34
dukeleto pmichaud: duly noted 23:44
msg pmichaud what does one do if we are currently using the .pbc version of NQP? does the .pbc of nqp-rx get installed somewhere? 23:48
msgbot?
jnthn dukeleto: Goes in as NQP-rx.pbc iirc. 23:55
dukeleto just a heads up to rakudo devs: if you follow @parrotvm on twitter or @parrot on identi.ca, you will be notified about branch merges (usually)
jnthn: is that file installed somewhere?
jnthn dukeleto: See github.com/perl6/nqp-rx/blob/master...akefile.in around line 129 for what gets installed. 23:56
dukeleto jnthn: sweet, thanks! that helps a bunch! 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!