Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2009-10-31

Perl 6 | Reference Documentation | Rakudo

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

All times shown according to UTC.

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

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

Perl 6 | Reference Documentation | Rakudo