Camelia, the Perl 6 bug

IRC log for #parrot, 2009-11-18

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 darbelo pmichaud: Say, has it been decided wether the code in ext/ is subject to the deprecation plicy?
00:00 pmichaud I haven't heard yet one way or the other.
00:00 pmichaud I suspect it is.
00:00 pmichaud it probably should be.
00:01 pmichaud i.e., things that don't follow parrot's deprecation policy perhaps don't belong in the repo.
00:02 darbelo Won't that reintroduce the 'devel freeze' problems that made you take nqp-rx out of the repo?
00:02 tetragon joined #parrot
00:04 darbelo I mean, you can break compat in upstream, that's the point of taking it out of the parrot repo. But then the parrot copy can't be updated and simply gets in the way for 6+ months.
00:04 Whiteknight make test doesn't work in pla either
00:04 darbelo Whiteknight: Oops. I'm on it.
00:05 dukeleto i am not so sure that parrot's deprecation policy applies to ext/, but that is a question for chromatic+allison
00:05 Whiteknight darbelo: I
00:05 Whiteknight m trying to fix it, I just don't know how
00:06 chromatic I'd rather put specific exceptions in place for experimental code or code we expect to change somewhat.
00:07 japhb darbelo, but since upstream is using a sane VCS, it's easier to branch in upstream into blead and parrot-compatible branches, and cherry-pick only compat stuff out of blead.  And when that truly becomes untenable, I suspect we'll be nearing a 6 month boundary anyway, and the branches have a clean merge point.  (Not that this is pmichaud's plan, I'm just saying it's feasible.)
00:07 dukeleto chromatic: i think our deprecation policy needs to be opt-in, not opt-out
00:07 dukeleto japhb: i will be starting the parrot -> git train the minute that 2.0 comes out.
00:08 japhb dukeleto, NO ARGUMENT THERE.
00:08 darbelo Whiteknight: pushed it.
00:08 pmichaud darbelo: I expect that by the time we reach 2.0, nqp(rx) will be fairly stable.
00:08 Whiteknight w00t
00:08 Whiteknight darbelo++
00:09 pmichaud at any rate, as japhb++ points out, having it officially in a separate repo means that we can indeed let nqp progress on its own timeline, but bring changes into parrot on a different timeline
00:09 japhb I ask only one thing:  Whoever leads that charge needs to write (or copy) the tool that allows us to easily determine an ordering for master commits such that HLLs and projects can continue to depend on "X or newer".
00:09 pmichaud japhb: I plan to write that tool for Rakudo, at least.
00:10 darbelo pmichaud: Glad to hear it.
00:10 japhb pmichaud, I'll be needing it in Plumage, no question.  :-)
00:10 dukeleto japhb: pmichaud has a good idea for ordering
00:10 Whiteknight darbelo: it looks like it's still using /languages/nqp/nqp.pbc
00:11 darbelo Whiteknight: really? where?
00:11 Whiteknight do a make test
00:11 pmichaud the nqp tests indeed use nqp.pbc
00:11 Whiteknight the commandline there involves nqp.pbc
00:11 pmichaud they're testing the old nqp
00:11 pmichaud (same as 1.4)
00:11 Whiteknight make test in parrot-linear-algebra
00:12 darbelo Oh, yeah, I know where it is. Let me fix that.
00:12 Whiteknight ok
00:14 dalek parrot-linear-algebra: c0d2c85 | darbelo++ | t/ (5 files):
00:14 dalek parrot-linear-algebra: s/parrot_nqp/parrot-nqp/ in the test files and harness.
00:14 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/c0d2c85ceed25eba0a4eb311bef3ff8619017c52
00:15 Whiteknight the harness itself is still run with nqp.pbc
00:15 Whiteknight check out config/Makefile.in:19
00:15 darbelo Whiteknight: yeah, the old nqp is still referenced in the makefile. But we have to update the harness before it can work with the new nqp.
00:16 Whiteknight okay. Teach me how to update the harness
00:16 Whiteknight I'm really trying to get a feel for what the differences are between old and new nqp
00:16 darbelo Whiteknight: learning that myself ;)
00:17 Whiteknight ah, okay
00:17 Limbic_Region joined #parrot
00:18 Limbic_Region anyone on windows with VS.net, the free SDK or would be willing to send me just mc.exe, rc.exe and link.exe ping
00:18 Whiteknight Limbic_Region: I could tomorro
00:19 darbelo "Unable to parse blockoid, couldn't find final '}' at line 62"
00:19 darbelo Never seen that before.
00:20 Limbic_Region Whiteknight - thanks - hoping to build a EventLog message dll tonight
00:20 * Limbic_Region bites the bullet
00:21 Whiteknight sorry
00:21 Whiteknight darbelo: yeah, that's the problem I'm seeing
00:21 Whiteknight weird
00:21 japhb Whiteknight or darbelo: paste or link the source?  I might be able to eyeball it.
00:22 Whiteknight http://github.com/Whiteknight/parrot-​linear-algebra/blob/master/t/harness
00:22 nopaste "darbelo" at 190.192.220.13 pasted "source of test harness for haphb" (85 lines) at http://nopaste.snit.ch/18745
00:23 japhb looking
00:24 Whiteknight w00t
00:26 japhb I don't see an obvious error, but I do see three immediate things to clean up (any of which may turn out to help):
00:26 japhb 1. collapse lines 40..42 to just 'for $output -> $line {'
00:27 japhb 2. unparen your if conditions
00:27 japhb 3. make sure all binary ops have spaces on both sides, and comma has space on the right
00:27 japhb But like I said, there was nothing truly obviously wrong to me there.
00:29 japhb Also, you no longer need to go through ~ contortions; double quoted strings interpolate variables and closures now.
00:30 japhb so line 69 can be 'say("passed $curr_test tests");'
00:30 davidfetter joined #parrot
00:30 japhb And line 79 can be 'say("FAILED $total_failed / { $total_passed + $total_failed }");'
00:31 Whiteknight it doesn't like the elsif{} block
00:31 Whiteknight I take that out, it works fine
00:32 japhb The one thing I can think of is the uncuddled-elses rule, but I thought that was a whitespace problem, not a } and else on same line problem.
00:32 japhb try dropping the elsif to the line after the closing } fot the if block
00:36 Whiteknight I pushed a fix
00:37 dalek parrot-linear-algebra: 6a03f61 | Whiteknight++ | src/pmc/complexmatrix2d.pmc:
00:37 dalek parrot-linear-algebra: silence a warning about casting the result of a function call
00:37 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/6a03f61ef23f466377100419d1b8d730fd56db17
00:37 dalek parrot-linear-algebra: a2fefcf | Whiteknight++ | :
00:37 dalek parrot-linear-algebra: Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
00:37 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/a2fefcf1e99f5bfab362536db730ec130ac406af
00:37 dalek parrot-linear-algebra: 676227d | Whiteknight++ |  (2 files):
00:37 dalek parrot-linear-algebra: quick hackaround that makes the harness work again
00:37 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/676227dc760535a666515c0b42b6dfe9084bdf54
00:37 dalek parrot-linear-algebra: b58e1a6 | Whiteknight++ | t/10-nummatrix.t:
00:37 dalek parrot-linear-algebra: get the nummatrix.t test working again
00:37 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/b58e1a6e3410000a219e66e1ab4174f581433240
00:39 japhb MUST have a space after keywords before parens, otherwise it could be seen as a function call.
00:40 japhb And it looks like the pastebin was slightly out of sync with the code you were editing, sorry.
00:40 japhb Anyway, elsif( is wrong.  Should be elsif or elsif (
00:44 Limbic_Region left #parrot
00:46 chromatic http://www.cs.princeton.edu/​research/techreps/TR-451-94
00:46 chromatic "Axiomatic Bootstrapping: A Guide for Compiler Hackers"
00:58 cotto party like it's 1994
01:01 abqar joined #parrot
01:20 plobsing hi #parrot
01:21 dalek matrixy: ce63abc | Whiteknight++ | src/ (3 files):
01:21 dalek matrixy: add preliminary cell support
01:21 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/ce63abc2eba2f1463649d80d08668ebde0d692c2
01:21 dalek matrixy: 9951031 | Whiteknight++ |  (2 files):
01:21 dalek matrixy: fix Matrixy so it works with NQP-RX.
01:21 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/99510312aacce7e9c0083ddbd8d74b60c5838b34
01:22 Whiteknight hello plobsing
01:22 plobsing sorry I didn't attend #ps today. life conspired against me.
01:22 plobsing my report would have been pretty boring anyways
01:23 plobsing Whiteknight: have you had a look at the Lorito stuff I put on the wiki?
01:23 Whiteknight briefly
01:25 plobsing thoughts?
01:25 purl i like cheese
01:29 Whiteknight nothing concrete yet. I need to read some of the stuff cotto wrote too
01:29 plobsing yes, that's good stuff.
01:30 plobsing if anything comes of that page, it'll probably be me finally understanding why we'll use ops
01:30 plobsing i'm still not completely convinced
01:30 plobsing but getting there
01:30 purl it has been said that getting there is the problem. or half the fun
01:30 plobsing purl: forget but getting there
01:30 purl plobsing, I didn't have anything matching but getting there
01:30 Whiteknight still have some thinking and deliberating to od
01:31 dalek parrot-linear-algebra: 550b56d | Whiteknight++ |  (2 files):
01:31 dalek parrot-linear-algebra: add a get_string() VTABLE to pmcmatrix2d
01:31 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/550b56dee10014f91675c35d73955b472aaaeb63
01:31 dalek parrot-linear-algebra: 8999282 | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
01:31 dalek parrot-linear-algebra: fix the get_string VTABLE on pmcmatrix2d
01:31 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/8999282ae955f574ae5331363f4f25f5876e8942
01:54 payload joined #parrot
02:36 hercynium joined #parrot
02:36 cconstantine joined #parrot
02:59 dalek tracwiki: v122 | jimmy++ | WikiStart
02:59 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=122&action=diff
03:03 cotto plobsing, take a look at https://trac.parrot.org/parrot/wiki/L1Recap too.  It's a little wordy but the last two sections of it do a good job of articulating the reasons for an opcode-based Lorito.
03:03 cotto Note that L1 is the old name for Lorito.
03:06 plobsing yes, I've read that over several times
03:07 plobsing I still have a few places where I don't see how it could work
03:07 cotto I have a few minutes if you do.
03:07 plobsing for example: we're going to need to interface to C. How can we do this unless Lorito is at least as "rich" in types as C?
03:08 Austin What was 42564 change?
03:08 plobsing currently parrot has 4 fundamental types. C has far more than that
03:08 kid51 joined #parrot
03:08 Austin WIP. Never mind.
03:10 plobsing or is the framebuilder external to Lorito?
03:10 cotto I think we *can* deal with that through ManagedStruct, but a more wieldy interface would be nice.
03:10 cotto (types)
03:11 plobsing so that kind of stuff (ManagedStruct, Call-In FFI, Call-Out FFI, etc) is external to lorito?
03:12 plobsing because that kind of stuff can also benefit from JIT
03:12 cotto *lightbulb*
03:12 cotto I see what you're saying.
03:13 plobsing as another example, ops (almost by definition) don't represent the structure of the program. there is a loss of information
03:14 plobsing eg: if/else,for,while all become goto
03:14 plobsing that information _may_ be usefull to compilers
03:15 plobsing how do these convert more easily to C than something that closely mirrors C?
03:17 cotto I'm not sure how gotos vs. more structured control flow would trip up an optimizer.
03:18 cotto but types are definitely an issue we need to figure out before Lorito can become feasible.
03:20 plobsing I'm not sure of the details, but I have a gut feeling obscuring information from the compiler is not good
03:25 plobsing how will Lorito easier to validate than PBC?
03:26 dalek TT #1306 created by Austin_Hastings++: Various failures on bogus string used as argname (1.7)
03:27 plobsing if it is lower level, won't it be harder?
03:35 plobsing also, does the fact that Lorito will be easier to validate mean it will be valid to transfer Lorito programs between machines?
03:36 janus joined #parrot
03:39 plobsing It would be easier to make improvements to Lorito and the VM if it were entirely internal.
03:39 plobsing and not subject to the deprecation policy
03:41 Austin Yeah, stuff is always easier if you don't care about the users.
03:53 davidfetter joined #parrot
03:59 * kid51 must sleep
03:59 purl $kid51->sleep(8 * 3600);
03:59 Ryan52 pfft, purl, programmers don't get 8 hours of sleep. silly bot.
05:42 cconstantine joined #parrot
05:57 Austin Argh! I'm being shagged by the new version of NQP.
06:14 dalek tracwiki: v123 | Austin_Hastings++ | WikiStart
06:14 dalek tracwiki: Added link to (nyi) Migrating to NQPrx
06:14 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=123&action=diff
06:19 kyle_l5l joined #parrot
06:24 dalek tracwiki: v1 | Austin_Hastings++ | Migrating%20to%20NQPrx
06:24 dalek tracwiki: Created.
06:24 purl hmmm... created is correct
06:24 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=1&action=diff
06:24 dalek tracwiki: v2 | Austin_Hastings++ | Migrating%20to%20NQPrx
06:24 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=2&action=diff
06:24 dalek tracwiki: v3 | Austin_Hastings++ | Migrating%20to%20NQPrx
06:24 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=3&action=diff
06:29 cotto Does anyone recall at which point ICU became a hard dependency?
06:30 Austin Is it one?
06:30 cotto istr so
06:30 Austin I've been seeing "no libiconv" messages for a while on Configure.pl
06:31 Austin I don't recall if I got one this time.
06:31 cotto It looks like that's what Paul Simon is running into on the list.
06:31 Austin parrot-dev?
06:31 purl parrot-dev is mailto:parrot-dev@lists.parrot.org or http://lists.parrot.org/ma​ilman/listinfo/parrot-dev
06:34 cotto yes
06:34 Austin I haven't seen his message yet.
06:35 cotto actually, parrot-users
06:35 Austin Ah.
06:36 Austin Where I should probably live.
06:36 cotto nice to see that getting some traffic so quickly
06:37 mokurai joined #parrot
06:56 szabgab joined #parrot
07:01 uniejo joined #parrot
07:04 theory joined #parrot
07:05 Austin There's already a -nyc splinter list?
07:05 Austin That's remarkably antisocial, even for New Yorkers.
07:06 cotto ?
07:06 Austin Parrot-users-nyc
07:06 Austin http://lists.parrot.org/mailman/listinfo
07:07 cotto sounds nefarious
07:08 Austin You gotta problem wid dat?
07:20 chromatic joined #parrot
07:25 Austin pmichaud--
07:25 cotto feeling the nqp-rx love?
07:25 Austin Found a bug.
07:26 Austin So yeah.
07:26 purl so yeah is there anyone that has any advice on how to get a resultset that contains two joined tables ?\
07:26 cotto a bug?  that's unpossible!
07:26 Austin I scoff at your certitude!
07:26 cotto what's the bug?
07:26 purl the bug is http://www.cbttape.org/funny/bug3.jpg or http://img227.imageshack.us​/img227/2596/featureiu1.jpg
07:26 Austin Stick around, it'll come by in a minute.
07:29 dalek TT #1307 created by Austin_Hastings++: NQP-rx doesn't handle comments correctly?
07:30 Austin Bug is that 7 unless condition { block; } # comment  all on one line doesn't parse, while moving the comment to a separate line does.
07:31 dukeleto 'ello
07:31 Austin hey, leto
07:31 dukeleto what is up with parrot-users-nyc ?
07:31 dukeleto i am from nyc, i can make fun of them
07:32 * dukeleto was born in Brooklyn, not NYC. but close enough
07:32 Austin Keep 'em separated, throw in some raw meat every once in a while.
07:32 dukeleto what is the latest news? does NQP have flying cars yet?
07:32 Austin NQP has flying something.
07:32 Austin It's not cars.
07:33 * dukeleto flies a something
07:33 dukeleto i need to sit down and write a NQP tutorial or something, just for my own sanity
07:33 Austin No you don't.
07:33 purl Oh no I don't
07:33 Austin You need to update the one already on wikibooks.
07:34 cotto dukeleto, good idea.  Put it on the wiki and shame pmichaud into filling it out.
07:34 Austin WhiteKnight will be your friend for life.
07:34 dukeleto Shame Driven Development
07:35 Austin WhiteKnight will be your friend for life.
07:36 Austin stupid pebkac
07:36 cotto WhiteKnight will be your friend for life.
07:36 Austin It's got a catchy rhythm, but you can't really dance to it...
07:36 Austin WhiteKnight will be your friend for life.
07:36 Austin WhiteKnight will be your friend for life.
07:38 dukeleto lulz
07:39 Patterner It needs more cowbell.
07:40 Austin Whiteknight lives not too far from Amish country. I'm sure there's plenty of cowbell.
07:40 Austin cow-something, anyway.
07:40 Patterner cow-orkers?
07:40 purl hmmm... cow-orkers is traditional :)
07:40 cotto cow-burgers?
07:41 Austin Obsolete pod format, please use =begin/=end instead at line 5, near "module\r\nPr"
07:42 dukeleto MOAR COWBELL
07:42 Austin FWIW, I started a NQP -> NQPrx migration page on the wiki
07:42 dukeleto Austin: link?
07:42 purl or "Link is ... like ... this pointy eared goblin that walks around in midi-music land with a letter opener attacking circles and things and wooing princesses but not bannon, you know?" or preaction is Error.
07:42 dalek nqp-rx: da7048b | dukeleto++ | CREDITS:
07:42 dalek nqp-rx: Add myself to CREDITS
07:42 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/d​a7048be43342f068aa4d3c8336ea1667a46c3dd
07:42 Austin https://trac.parrot.org/parro​t/wiki/Migrating%20to%20NQPrx
07:44 dukeleto we really need a doc about how to write a HLL, from scratch, with NQP. i might do that
07:45 Austin Even better, write one about how to write scheme/lisp from scratch.
07:45 Austin There's about eleventy-six guys in here doing that.
07:49 Austin No spaces before ++ and -- postfix
07:51 dalek tracwiki: v4 | Austin_Hastings++ | Migrating%20to%20NQPrx
07:51 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=4&action=diff
07:53 fperrad joined #parrot
07:54 dalek tracwiki: v5 | moritz++ | Migrating%20to%20NQPrx
07:54 dalek tracwiki: spaces around 'else'
07:54 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=5&action=diff
07:55 moritz somehow the numbering of items is broken on that page
07:55 moritz I fear my trac-fu is too weak to fix it
07:55 Austin Probably because I've got those unnumbered paras between.
07:55 Austin Maybe indenting them will fix it.
07:57 Austin Nope. It aligned the paras, but didn't fix the numbers. :(
07:57 moritz maybe just remove the numbers, of make the numbered lines headings instead
07:58 dalek tracwiki: v6 | Austin_Hastings++ | Migrating%20to%20NQPrx
07:58 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=6&action=diff
08:01 Austin That worked. :)
08:01 Austin moritz++
08:01 dalek tracwiki: v7 | Austin_Hastings++ | Migrating%20to%20NQPrx
08:01 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=7&action=diff
08:02 barney joined #parrot
08:02 Austin Ahh, barney.
08:03 Austin The man directly responsible for all my misery.
08:03 cotto You're thinking of the dinosaur.
08:04 Austin No, I'm old enough that I missed the creepysaurus.
08:04 Austin I got to see the good stuff.
08:05 Austin Statler and Waldorf
08:09 pmichaud pmichaud is already shamed into writing a tutorial, it's just a matter of finding time to do it :)
08:09 theory joined #parrot
08:09 pmichaud ah, yes, the comment bug was in rakudo-ng also.  I need to fix that in nqp-rx.
08:10 Austin pmichaud: Is the no-space-before-++/-- a bug, or some kind of p6ism?
08:10 pmichaud p6ism
08:11 moritz Austin: in general disallowed before postfix operators
08:11 moritz to easier disambiguate them from infix operators
08:11 dalek tracwiki: v8 | dukeleto++ | Migrating%20to%20NQPrx
08:11 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=8&action=diff
08:13 Austin That seems like a bit of a stretch. Is anyone seriously considering infix ++ ?
08:13 pmichaud it's not that so much
08:14 pmichaud it helps to disambiguate    "foo.bar"   from  "foo .bar"
08:14 Austin Where 7 foo .bar  is a function call on a local member variable?
08:14 Austin Hmm. No.
08:14 Austin What is .bar in p6?
08:15 pmichaud foo .bar  is the same as   foo $_.bar
08:15 mikehh joined #parrot
08:15 Austin method call, no args?
08:15 pmichaud right
08:15 barney Austin: glad to help
08:15 pmichaud so,   foo.bar is like  (foo).bar
08:15 pmichaud while foo .bar is like  foo($_.bar)
08:15 pmichaud there are other similar situations
08:16 Austin So is any of that going in to nqp?
08:17 Austin I wouldn't mind ()-less calls.
08:17 pmichaud ()-less calls probably won't make it.  We don't have a reliable mechanism to distinguish between bareword terms and function calls
08:17 Austin Other than proto-objects, what's a bareword term?
08:17 pmichaud in (full) Perl 6 we can get away with it because all bareword terms are lexically known at compile-time
08:18 pmichaud constants
08:18 purl constants are good. sure it's a bit unusual :) but they had to
08:18 pmichaud the main ones are constants and protoobjects, yes.
08:18 moritz purl: forget constants
08:18 Austin Constants?
08:18 purl Constants are good. sure it's a bit unusual :) but they had to
08:18 purl moritz: I forgot constants
08:18 iblechbot joined #parrot
08:18 pmichaud constant pi = 3.14159;
08:18 pmichaud (no, nqp doesn't have those (yet?))
08:18 Austin Is that supported now?
08:19 Austin (Because I'd rather have ()-less calls.)
08:19 pmichaud in general it's hard to know if    Foo +3    is supposed to be Foo(+3)  or   &infix:<+>(Foo, 3)
08:19 Austin :)
08:20 Austin It's the latter. Nobody uses prefix+.
08:20 pmichaud okay, Foo -3 then.
08:20 Austin (Except to generate certain expressions.)
08:20 Austin Yeah.
08:20 moritz "nobody wants to build a wall"
08:20 Austin But that's why we've got you, man.
08:20 Austin To do the heavy lifting.
08:21 Austin changing the subject entirely, pmichaud:
08:22 Austin I've got this problem, tt #1306, where I'm calling x.new(:a('albacore'), :b('byzantine')) and garbage is going through.
08:23 Austin I've reworked that to the point that I know that a call to Hash::new(:a('albacore'), etc) generates the bad hash.
08:23 Austin (That's in 1.7)
08:23 dalek nqp-rx: 2bd89cd | dukeleto++ | examples/ (3 files):
08:23 dalek nqp-rx: Add some basic NQP examples
08:23 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​bd89cde579c9e539ade9044462aa031ddc2b7a5
08:23 Austin Looking at the pir, the generated code is pretty direct:  $P123."new"("albacore" :named("a"), etc.)
08:24 Austin But there's this nonsense coming back. You have any idea what could cause that?
08:24 pmichaud we're also seeing odd segfaults and the like in rakudo-ng
08:24 Austin (Essentially, corrupted hash keys in the slurpy named args collector hash).
08:24 pmichaud anyway, I don't know what could be causing it.  You're correct that the generated PIR looks absolutely right.
08:25 Austin I'll see if it recurs in 1.8
08:26 Austin If so, maybe I can sweet-talk somebody with a C debug platform into single-stepping it for me.
08:26 pmichaud dukeleto: note that the while loop example isn't correct
08:26 pmichaud need a space between while and the paren
08:26 Austin Is there a good way to set a C-level breakpoint on a PIR address?
08:26 pmichaud (it might work in current NQP, but some day will not work)
08:27 moritz the parens must go, otherwise it should be parsed as a subroutine call
08:30 cotto Austin, if it's a unique instruction it's not hard.
08:31 cotto on a PIR address it'll be trickier
08:31 Austin cotto: what about a sub?
08:31 pmichaud I often add a fake  "debug 1"  or "noop" instructioninto the PIR, and the breakpoint on Parrot_debug_ic  or Parrot_noop
08:31 pmichaud s/the/then/
08:31 cotto what he said
08:31 Austin That's work.
08:31 chromatic We need a doop op.
08:31 Austin *That'd
08:31 chromatic democratic order of popcodes
08:32 dukeleto pmichaud: the while loop runs for me
08:33 dukeleto pmichaud: it works on master
08:33 pmichaud dukeleto: as I said, it currently works, but someday will fail (because it's invalid Perl 6 syntax)
08:34 Austin Okay, the subs-are-lexical thing. How does that work?
08:34 dukeleto pmichaud: maybe a warning would be good?
08:34 pmichaud Austin: it just means that subs are "my" scoped instead of "our" scoped.
08:35 pmichaud so a sub isn't visible outside of the block in which it's declared (well, except for the imcc "optimization" that causes it to be treated as a direct call when in the same compilation unit)
08:35 moritz see #perl6 for how std warns/complains
08:38 pmichaud TT #1279 is proving to be a real pain for nqp testing.  :-(
08:38 dalek wmlscript: c693665 | fperrad++ |  (3 files):
08:38 dalek wmlscript: replace deprecated Array PMC
08:38 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/c693665c461c1669956e1f4796b9cafa29a94020
08:40 chromatic pmichaud, I can look at it tomorrow or Thursday.
08:40 dalek nqp-rx: 8aa6c0f | pmichaud++ |  (2 files):
08:40 dalek nqp-rx: [nqp]:  Allow comments after statement-terminating close brace (TT #1307).
08:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​aa6c0ffa5c6583de896cb27834e4ffeedb3432e
08:40 dalek nqp-rx: 52b8c42 | moritz++ | examples/loops.nqp:
08:40 JimmyZ joined #parrot
08:40 dalek nqp-rx: [examples] remove parenthesis from while-loop
08:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​2b8c42b968dc3127184d5c4304a73a424811510
08:40 dalek nqp-rx: c719911 | pmichaud++ | :
08:40 dalek nqp-rx: Merge branch 'master' of git@github.com:perl6/nqp-rx
08:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​7199116fbd18e46927b0a9c1f64872295470f09
08:40 pmichaud chromatic: that would be great.  Actually, I suspect the fix is fairly simple -- it's more a question of deprecation policy for me
08:41 Austin pmichaud: Looking at the generated code, it seems like the subs are going into the namespace. Does the :outer attribute make them non-visible?
08:41 pmichaud :anon makes them non-visible.
08:41 chromatic I can't imagine how there'd be a deprecation question about that.
08:41 pmichaud chromatic: I can't either, but sometimes I'm surprised.
08:42 pmichaud Austin: you're correct, :anon appears to be missing.
08:42 Austin Nice. My "Welcome to the parrot-users list" email is considered spam.
08:42 chromatic I'll paint it red and hang a big "This is a Bug Fix" sign on it and we can all be happy.
08:43 pmichaud Austin: so it's ending up in the namespace when it shouldn't.  I'll have to fix that one tomorrow.
08:43 * diakopter giggles
08:43 Austin Too late, pm. It's a deprecation item. My code depends on it.
08:43 pmichaud Too bad, Austin.  We haven't crossed a deprecation boundary :)
08:44 Austin What I think I'm hearing is that in order to be in the namespace, subs have to be "our sub" or "our method", true?
08:44 pmichaud "our sub", yes.
08:44 Austin What about methods?
08:44 pmichaud in order for methods to appear in the namespace we'll probably need to implement "is export"
08:44 pmichaud methods should not appear in the namespace by default
08:45 Austin Funny, while I don't know what that means, I think I might be implementing it.
08:45 Austin Ahh, right.
08:45 pmichaud method xyz() is export { ... }
08:45 Austin Bummer. I was using "method" to save a bunch of opcodes.
08:46 Austin No need to pay for that "$P0 = find_lex '$param1'' when I know 'self' is defined.
08:48 mikehh joined #parrot
08:50 pmichaud need sleep here -- be back in a few hrs
08:52 dalek parrot: r42565 | pmichaud++ | failed to fetch changeset:
08:52 dalek parrot: [nqp]:  Update NQP with latest syntax improvements (e.g., TT #1307).
08:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42565/
08:52 dalek nqp-rx: ef88e99 | pmichaud++ | src/NQP/Grammar.pm:
08:52 dalek nqp-rx: At least generate *some* sort of error for things like while(1) and if(2).
08:52 dalek nqp-rx: We'll improve the error messages in a later commit.
08:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/e​f88e9922fd8197cadbb0a963ef96045c65e7e6d
08:52 dalek nqp-rx: b8722f3 | pmichaud++ | t/nqp/05-comments.t:
08:52 dalek nqp-rx: Update plan.
08:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/b​8722f3af05109cd5dc5db89dd183ee2b65e1564
08:52 dalek nqp-rx: ecce4ce | pmichaud++ | src/stage0/ (3 files):
08:52 dalek nqp-rx: Bootstrap update with latest fixes.
08:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/e​cce4ce0bdd3ce87761ba188228d2881d6ca92d2
08:54 dalek TT #1307 closed by pmichaud++: NQP-rx doesn't handle comments correctly?
08:55 dalek parrot: r42566 | cotto++ | trunk/DEPRECATED.pod:
08:55 dalek parrot: [DEPRECATED] Array PMC is on its way out
08:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42566/
08:59 ttbot Parrot trunk/ r42565 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/147227.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
09:06 ttbot Parrot trunk/ r42566 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/147257.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
09:11 mikehh joined #parrot
09:11 xenoterracide joined #parrot
09:26 sri joined #parrot
09:26 xenoterracide joined #parrot
09:30 dalek tracwiki: v9 | Austin_Hastings++ | Migrating%20to%20NQPrx
09:30 dalek tracwiki: Default parameter initialization
09:30 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrat​ing%20to%20NQPrx?version=9&amp;action=diff
09:39 xenoterracide joined #parrot
09:42 xenoterracide joined #parrot
09:48 xenoterracide joined #parrot
10:15 dalek TT #1308 created by Austin_Hastings++: NQPrx does not vivify globals in all cases
10:17 dalek tracwiki: v10 | Austin_Hastings++ | Migrating%20to%20NQPrx
10:17 dalek tracwiki: Global viv, tt#1308</a>
10:17 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrati​ng%20to%20NQPrx?version=10&amp;action=diff
10:58 theory joined #parrot
11:15 lucian joined #parrot
11:22 cconstantine joined #parrot
11:52 sri_ joined #parrot
12:07 cconstantine joined #parrot
12:10 dalek pynie: r90 | isop44++ | trunk/ (6 files):
12:10 dalek pynie: Add 'type' type as a functor with a nice string representation. Make the 'str'
12:10 dalek pynie: and 'list' classes instances of this functor. (Though str/list instances are not
12:11 dalek pynie: instances of the 'type' objects yet.)
12:11 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=90
12:29 payload joined #parrot
12:37 fperrad joined #parrot
13:09 whiteknight joined #parrot
13:15 tetragon joined #parrot
13:18 bluescreen joined #parrot
13:19 whiteknight good morning #parrot
13:19 Coke austin (spam) messages get caught by a spam filter? I thought allison and I had to manually reject all those. :|
13:19 Coke (if we manually rejected yours please retry. =-)
13:21 Coke parrot-users-nyc: there was a tricket for this from kid51; consider it an experiment.
13:24 bluescreen joined #parrot
13:24 Coke tricket is trac ticket
13:32 payload joined #parrot
13:35 riffraff joined #parrot
13:39 whiteknight yay! We're creating words
13:40 Coke it's tricket to rock on time.
13:41 Coke which is wrong, but I'm hoping this crowd won't notice.
13:42 dalek lua: f30ecdf | fperrad++ |  (4 files):
13:42 dalek lua: replace deprecated PMC Array
13:42 dalek lua: review: http://github.com/fperrad/lua/commit/f3​0ecdfaa6e8a64c25aad1725a1e16b179a627e9
13:45 fperrad joined #parrot
13:47 lucian what kind of gc does parrot have?
13:48 payload joined #parrot
13:48 moritz mark-and-sweep stop-the-world
13:49 whiteknight we're slowly coming up with plans for something better
13:49 lucian moritz: does the cross-language aspect of parrot make other GCs hard?
13:50 Coke I'm pretty sure that the gc makes the gc hard.
13:50 whiteknight lucian: no, diffent HLLs are basically just a syntax layer over PIR, so it's not an issue
13:50 Coke (most languages targetting parrot don't provide explicit memory management, do they?)
13:50 lucian whiteknight: right, ok
13:50 whiteknight we'll, that's not entirely true because there can be C extensions, but it's generally a small problem
13:50 Coke pmichaud: ping.
13:51 Coke (just wondering if there's anything I can do on the whole partcl-ng thing. =-)
13:51 lucian i've seen that in PyPy, their generational and hybrid GCs are MUCH faster than their mark&sweep
13:51 moritz whiteknight and others having been working on cleaning up the GC interface, so that it's easier to write other GCs
13:52 moritz but parrot is generally quite complex (for example because it allows calls from and to C), and that makes the GC non-trivial
13:52 moritz (as far as I understand it; I'm not really a core parrot hacker)
13:52 moritz better GCs are on our wishlist though
13:53 whiteknight the C issue really isn't a problem, it just means we need to do a stackwalk
13:53 whiteknight and we've been doing that forever
13:53 lucian does it use libffi for the C calling?
13:54 whiteknight GC is really quite simple in that there is a relatively small interface that it must satisfy
13:54 whiteknight lucian: no, we don't use libffi
13:54 whiteknight The big problem in GC is finding a good algorithm that can deal with a huge volume of data reliably and quickly
13:55 whiteknight we have a system now that is mostly reliable but not quick
13:55 moritz shouldn't there be enough prior art so that one can just pick one that works well and fast?
13:55 PerlJam "mostly reliable"?  Isn't that an oxymoron?  :)
13:55 whiteknight mostly not :)
13:56 lucian there is quite a bit of prior art. i found the  PyPy GCs easy to read (since they're implemented in Python)
13:56 PerlJam lucian: somehow I don't think PyPy's GC is fast.
13:56 whiteknight yes, there are lots of other gcs ti look at
13:57 lucian PerlJam: it is VERY fast, since it's compiled to C code
13:57 moritz PerlJam: why not?
13:57 lucian PerlJam: well, some of them are, they have several
13:57 whiteknight yeah, I would expect the PyPy collector to be fast
13:57 PerlJam moritz: because python, in general, tends to be slow across the board.
13:57 PerlJam maybe I just haven't paid enough attention to python though
13:58 whiteknight PerlJam: Think about the speed difference between NQP and pure Perl6
13:58 moritz PerlJam: I think they're working on changing that :-)
13:58 lucian preflex: it's actually RPython, which gets compiled to C/.NET/JVM
13:58 whiteknight a Python language subset could be very fast
13:58 PerlJam So ... we need to write a GC in NQP then.  :)
13:58 whiteknight in a GC, you're dealing with huge volumes of data. Execution speed is usually dwarfed by algorithmic complexity
13:59 whiteknight PerlJam: If an NQP collector could reduce algorithmic complexity, it would be an improvement
14:00 lucian is the GC written in C or PIR ?
14:00 whiteknight C
14:00 whiteknight check out the repo, src/gc/*
14:00 lucian whiteknight: ok. what's the status of the JIT?
14:00 whiteknight lucian: in planning
14:00 whiteknight we've got a lot of plans laid, and details to figure out
14:01 lucian whiteknight: oh, alright. i was thinking that jitted PIR could be faster than C
14:01 moritz we had an old i386-only JIT and ripped it out because it was a maintenance burden
14:01 whiteknight a *big
14:01 whiteknight * burden
14:01 lucian whiteknight: for example with python's psyco2 jit, pure python map() is faster than the C version
14:02 lucian and what are the plans for the JIT, if i'm not imposing
14:02 whiteknight lucian: I don't doubt that
14:02 whiteknight we're planning to use LLVM as the JIT engine
14:02 lucian whiteknight: to generate LLVM IR? or to use LLVM's C++ API directly?
14:02 whiteknight We're going to develop a minimalist language, Lorito, that will be trivially easy to convert to LLVM opcodes at compile time
14:03 moritz and then write as many ops as possible in that language
14:03 whiteknight lucian: they have a C API that we're gong to tap into
14:03 lucian wouldn't the extra pass increase jit warmup time a lot?
14:03 whiteknight we're going to compile our ops to LLVM bytecode during compilation. At runtime we'll assemble those op sequences to large functions and pass them to LLVM for JIT
14:04 moritz lucian: there are two problems: JIT-compiling PIR code, and JIT-compiling our built-in ops
14:04 whiteknight so it shouldn't increase warmup time since we'll be doing all the compilation to bytecode at Parrot's build time
14:04 moritz lucian: and only the built-in ops would go through lorito, and do that at the time when you compile parrot
14:04 lucian moritz: couldn't you reimplement those ops in a lower level PIR?
14:04 whiteknight JITing PIR code is just a matter of assembly the JITted ops into larger functions or traces
14:04 lucian and them just have a jit for that
14:05 whiteknight lucian: that's essentially what Lorito will be
14:05 moritz lucian: think of lorito as a lower level PIR, and you're there :-)
14:05 lucian oh, right. sorry :)
14:05 moritz no problem
14:05 lucian so will this be a tracing jit? or just a copy&paste jit?\
14:06 allison lucian: not tracing at first, but there is potential for it later
14:06 mikehh All tests PASS (pre/post-config, smoke (#30013), fulltest) at r42566 - Ubuntu 9.10 amd64 (g++ with --optimize)
14:07 whiteknight allison: agreed. We would be foolish not to use tracing eventually
14:07 whiteknight but to start, we can be a little bit more naive
14:07 lucian from what i've heard and read, it's hard to implement tracing on top of llvm
14:08 lucian because it's hard to patch functions, you usually have to recompile
14:08 whiteknight with proper tracing you wouldn't patch anyway
14:08 allison lucian: aye, LLVM's jit is quite static
14:09 whiteknight a trace will have a series of exit points. If we need to extend an exit point we can compile another trace at that point
14:09 whiteknight a good PIC system would provide a callsite caching mechanism that wouldn't require recompilation anyway
14:10 allison lucian: on the whole, we're going for a pluggable jit system (like our pluggable GC), so we're not tied to LLVM, it's just one possible JIT output
14:10 lucian allison: right
14:11 lucian have you talked to other people that are implementing JITs nowadays?
14:11 whiteknight there has been some talk, I think, yes
14:11 allison yup, talked with the JVM folks, and the LLVM folks, and the unladen swallow folks
14:12 allison and others. always looking for interesting new papers or work if you have some
14:12 Coke allison: used your name in vain in an email to the list.
14:12 lucian i don't think i have the links, there was a very interesting paper on a tracing jit by the PyPy folks
14:12 moritz https://trac.parrot.org/parrot/wiki/JITRewrite btw
14:12 allison ah, yeah, I talked with them at PyCon last year
14:13 allison there's been some interesting work on tracing JIT's for javascript lately
14:13 lucian i think this is it http://codespeak.net/svn/pypy/extradoc/tal​k/icooolps2009/bolz-tracing-jit-final.pdf
14:13 whiteknight JavaScript is really the driving force in the world of Jit right now, I think
14:14 whiteknight when you look at some of the huge speed gains made by the various browser's engines
14:14 allison lucian: excellent, haven't seen that one yet
14:15 lucian allison: since PyPy works by generating VMs with JIT from an interpreter written in RPython, it's a different approach
14:15 lucian they're tracing the interpreter itself, not the app-level code
14:15 allison lucian: we'd be doing something similar, with Lorito->PIR
14:16 lucian allison: yeah, have a chat with them :)
14:16 allison lucian: (ideally at both levels, interpreter and app)
14:16 lucian afaik, they're not jitting app code
14:17 lucian joined #parrot
14:19 allison lucian: jitting PIR code is likely the biggest gain for us, targeting all languages with one implementation
14:19 lucian allison: yes, i'd imagine so
14:22 whiteknight if we can target tight loops, especially if we have good integration with the Iterator PMCs, we would likely get a nice boost
14:23 * Coke adds trac milestones for 2.1-2.5
14:28 whiteknight lucian: you interested in getting involved? We've obviously got some large projects on the horizon and need lots of helping hands :)
14:29 lucian whiteknight: i don't have much free time and i'd like to devote it to improving python
14:29 whiteknight I know exactly what it's like to not have much free time.
14:29 lucian whiteknight: so i am interested in getting involved, but i may not be able to
14:29 whiteknight well, if you see any other interested papers or projects, please send a note our way
14:29 Coke any deprecation tickets that are to removed  "just after 2.0" should be migrated to the 2.1 milestone.
14:29 lucian there are soo many interesting projects i'd like to contribute to
14:30 lucian and then almost as many i'd like to start
14:30 whiteknight lucian: tell me about it!
14:30 purl Let's not and say we did.
14:30 PerlJam lucian: you could work on pynie :)
14:30 PerlJam (that'll "improve python"  :)
14:30 lucian PerlJam: i intend to look into that, actually
14:31 lucian PerlJam: not that i have anything against other languages, but python is what i use most
14:32 Coke lucian: we're pretty understanding of that sort of thing. =-)
14:32 lucian Coke: yeah, when building a multi-language vm it should come with the territory :)
14:33 whiteknight it would be quite interesting if one day Pynie is competitive with other python distributions
14:33 Coke what do people think about making segfaults release blockers?
14:34 whiteknight Coke: depends on the segfault
14:34 Coke (or at least, very high priority to fix before the next release.)
14:34 whiteknight I could write trivial code right now to force segfaults in Parrot, and none of them are going to be fixed any time soon
14:34 PerlJam Coke: I'll note that Perl 5 could still be made to segfault even after release
14:34 Coke ... whee, segfaults good.
14:35 whiteknight Some segfaults should be release blockers, yes. But we can't use that as a blanket
14:35 PerlJam (though I'm not sure there are any known ways to segfault 5.10)
14:35 whiteknight we'd never release again
14:35 PerlJam whiteknight++ indeed
14:36 Coke we currently have /21/ reported segfaults.
14:36 PerlJam whiteknight: If pynie can't be made competitive with other python dists, then in some sense, parrot failed.
14:38 Coke ...20
14:41 dalek TT #1002 closed by coke++: Building PGE dies with segfault when JIT enabled under Fedora 11
14:48 Coke (never release) certainly not with a segfault. =-)
14:48 Coke I'm just looking for a general concensus, not 100% certainty.
14:49 whiteknight Coke: you have a list of tickets involving segfaults?
14:50 Coke whiteknight: trac -> tickets -> search -> summary contains segfault
14:50 Coke or:
14:50 Coke https://trac.parrot.org/parrot/query?status=ass​igned&amp;status=new&amp;status=reopened&amp;su​mmary=~segf&amp;col=id&amp;col=summary&amp;col=​status&amp;col=type&amp;col=priority&amp;col=mi​lestone&amp;col=component&amp;order=priority
14:51 Coke parrot segfaults are https://trac.parrot.org/parrot/query?status=ass​igned&amp;status=new&amp;status=reopened&amp;su​mmary=~segf&amp;col=id&amp;col=summary&amp;col=​status&amp;col=type&amp;col=priority&amp;col=mi​lestone&amp;col=component&amp;order=priority
14:54 whiteknight Coke: Ticket #771, can I get a complete backtrace and the complete PIR output of the example?
14:55 Coke 771?
14:55 Coke 776?
14:55 whiteknight 776
14:55 whiteknight sorry
14:56 Coke what do you mean, PIR output?
14:56 whiteknight the Tcl compiler generates something that is then input into Parrot
14:56 whiteknight I want to see that something
14:56 Coke (tcl doesn't generate a single PIR file to run, heavily relies on the runtime and the PIR compiler.)
14:56 whiteknight I can't do anything with the Tcl source
14:57 Coke then move on to another ticket.
14:57 whiteknight you're saying that there is absolutely positively no way to get access to the PIR code generated by the Tcl compiler?
14:57 Coke no. I'm saying it's not "here's the PIR output".
14:57 whiteknight whatever we call it. I need to see it
14:57 Coke I could run it with -D60 and send you a zip file with several hundred EVAL files.
14:58 Coke ... or you could do it yourself. It's non trivial, so you might as well try to close someone else's segfaults.
14:58 whiteknight Parrot doesn't operate on Tcl natively. If I am going to fix a parrot issue, I need to see the input that Parrot receives
14:58 Coke whiteknight: I understand that small PIR snippets help diagnose the problem.
14:59 whiteknight I didn't ask for a small PIR snippet
14:59 Coke whiteknight: I cannot give you something that you can feed into parrot without tcl.
14:59 Coke at least not without a LOT of work on my part to remove the partcl bits.
14:59 Coke I'm doing that as time permits on these tickets, but it is non trivial.
15:00 whiteknight okay, let me ask a different question: does partcl compile code down to PIR at once, or does it interpret it more interactively?
15:00 Coke the latter.
15:00 whiteknight ok
15:01 whiteknight Is there any way to access the small bit of PIR code that's being executed at the time of the segfault?
15:02 whiteknight no, wait
15:02 whiteknight are you calling the PIR compreg?
15:02 Coke pretty much constantly.
15:02 whiteknight then the complete PIR code being compiled is going to be somewhere in the backtrace
15:02 whiteknight so I need the complete backtrace
15:02 Coke no. it's going to be in several thousand chunks.
15:02 Coke (complete backtrace) that, sure.
15:03 Coke that's easy to generate because I can use tcl as is.
15:03 Coke or would be if I had that particular branch lying about.
15:06 Zak joined #parrot
15:07 Coke that branch no longer compiles against 1.8.0, so this will take some work.
15:08 Coke In the meantime, there are several other current segfaults with full back traces. =-)
15:08 bubaflub joined #parrot
15:08 Coke stealing ticket, leaving todo note.
15:09 Coke (will give it back to you when I have a backtrace)
15:09 masak joined #parrot
15:12 Psyche^ joined #parrot
15:15 whiteknight Coke: okay.
15:16 whiteknight Coke: somewhere in the backtrace there will be an IMCC function call where one of the arguments is the PIR code that's being compiled
15:16 whiteknight if you can get a dump of that particular value it would be a huge help
15:16 john_ joined #parrot
15:17 Coke (adding that note to the ticket would be very helpful. =-)
15:17 whiteknight okay
15:17 john_ Hi. I didn't see Perl 5 listed among the Parrot-hosted languages at http://www.parrot.org/languages . Are there any plans in the works for it to be added?
15:21 nopaste "coke" at 72.228.52.192 pasted "example of compreg usage." (14 lines) at http://nopaste.snit.ch/18748
15:21 whiteknight john_: see blizkost
15:21 whiteknight http://github.com/jnthn/blizkost
15:22 john_ whiteknight: Thank you. Yes, I was just looking there.
15:22 john_ I suppose any solution here is going to be pretty ambitious.
15:22 whiteknight it isn't a Perl5 compiler by itself, it's basically impossible to make a new Compiler for perl5
15:23 whiteknight not "impossible", but yes, ambitous
15:24 john_ Right. It looks to me like Blizkost is going to be a way for you to call out to the locally installed Perl 5 to run your Perl 5 code from inside the code written in Parrot-hosted languages.
15:24 moritz right
15:25 NotFound Some people said the is impossible to write a perl5 version that meets the language specification because there is no specification other than "What perl5 does"
15:27 whiteknight exactly
15:28 john_ Is Perl 5 difficult to implement because of the lack of official spec, or is it because of the ideosyncracies of the language itself?
15:28 whiteknight so we have two options: (1) create our own variant of perl5 which is similar but not the same, or (2) just embed the existing perl5
15:28 whiteknight john_: both
15:28 whiteknight the spec really is "whatever the perl binary does"
15:28 moritz john_: and (3) because XS is really tied to the internals of the perl5 compiler
15:28 whiteknight so it's a moving target that we can't ever faithfully reproduce
15:28 NotFound john_: that differentiation is purely synactic.
15:28 whiteknight moritz: ah, yes
15:29 john_ CE-Perl ("Close Enough Perl")? ;)
15:29 NotFound The lack of official spec is the idiosincracy.
15:31 NotFound john_: the problem is that the set of people that agree with that "enough" can be just the person that wrote it, or the empty set.
15:31 john_ NotFound: Interesting. I'd just figured that it was a matter of laboriously covering all the special cases. I'm not sure I see what the difference is between "having a spec" and "having a working language interpreter that you can just ask".
15:32 NotFound john_: the problem is that the special cases is the full CPAN.
15:32 NotFound Or even the darkpan :D
15:33 john_ I don't think I understand. The full CPAN is simply modules that use the language -- which itself is what supports the special cases of how the language works.
15:33 john_ NotFound: re. "enough", I see what you mean. Getting 80% may be doable, but everyone wants a different 80%.
15:34 NotFound Yeah, that's the main issue.
15:34 john_ NotFound: Oh. And supporting the full CPAN will pretty much require covering all the 80%'s. :)
15:34 pmichaud partcl?
15:34 purl well, partcl is tcl on parrot or http://code.google.com/p/partcl
15:35 NotFound john_: yes, you've seen it.
15:35 Coke whiteknight: thank you for policing those; after my email to the list today, i was going to get back to those this week. =-)
15:36 Coke whiteknight: in your blog, you mentioned/implied that parrot used to be stack based. It just used to have a global stack that we eliminated.
15:36 john_ NotFound: But doesn't Perl 6 contain a lot of "special cases" to cover as well?
15:36 Coke I think it was you, anyway. I had meant to comment on the blog but saw it on my phone while on vacation.
15:36 john_ NotFound: or are there not as many special cases as with Perl 5?
15:36 Coke john_: note that XS is an issue. (not everything is done "in perl")
15:37 NotFound john_: perl6 has an spec, and is  stillevolving. You can follow the spec, and you can propose to fix the spec if you fund pitfalls on it.
15:39 NotFound And there is an "official" statement that says that a thing that follow the spec an pass the test can use the name Perl 6.
15:39 Coke pmichaud: yesssssssssssssssssssssssssssss? =-)
15:39 Coke whiteknight: note that after pmichaud gets done, hopefully we can avoid a lot of the interactive compiling. =-)
15:40 pmichaud Coke: was just looking for the grammar to start playing with a bit
15:40 pmichaud I think I need to read a quick tutorial on tcl
15:40 john_ Coke: Right, right, ... forgot ... moritz mentioned that. I see.
15:42 whiteknight Coke: (Re: stacks) you
15:42 NotFound And last but not least, Camelia is more smiling and friendly that the dusty camel ;)
15:42 whiteknight 're right, it wasn't "stack based"
15:42 whiteknight I should clarify
15:43 Coke pmichaud: http://www.tcl.tk/man/tcl/tutorial/Tcl1.html perhaps?
15:44 Coke http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm is a good summary of how the ``syntax'' works.
15:44 pmichaud Coke: yeah, looks like that's where I ended up
15:44 pmichaud partcl is more of an interpreter than a compiler, yes ?
15:44 Coke yes.
15:44 pmichaud should it remain that way?
15:44 pmichaud (I think "yes")
15:45 Coke we can't compile the whole program in one go, no.
15:45 Coke (since the user might change the definition of a builtin on the way, and we'd have to make the compiler know that, so we'd have to run it, so...)
15:45 john_ Would be great to see a nice write-up or blog post regarding the reasons discussed here why there's currently no Parrot-hosted Perl 5. Thanks for the enlightenment (I think I understand a bit of it. :) ).
15:45 Coke we do need to fix it so that the bits we're interpreting are as small as possible. (like, each command/subcommandD)
15:46 Coke (no parrot based perl 5) see also "ponie"
15:46 Coke I think there's a postmortem on that somewhere.
15:46 NotFound john_: I think blitzkhost has a short explanation.
15:46 Coke (partcl) right now we try to parse the whole file first, and then run each bit. we really need to parse a command at a time, compile it, run it, move on.
15:47 Coke (we actually have a todo test that will start working when we do that.)
15:47 pmichaud Coke: I think the new tools are much more conducive to that
15:47 john_ NotFound: I don't see a docs dir in the blizkost distribution.
15:47 john_ Coke: Where might I find such a post-mortem?
15:48 NotFound john_: maybe it was just a message on the mailing list, not sure.
15:48 john_ Coke: I see punie and pynie, but no ponie.
15:48 Coke john_: that's because it's dead.
15:48 Coke (some 4 or 5 years now.)
15:48 Coke google for ponie parrot
15:49 john_ Coke: http://en.wikipedia.org/wiki/Ponie thanks.
15:49 Coke wow, only 3 years gone. =-)
15:52 * pmichaud wonders how evil it would be to modify the string being parsed during the parse itself.
15:53 pmichaud is that essentially how tcl works -- repeated substring substitutions?
15:53 Coke i confess to not knowing how the real tcl works internally.
15:54 pmichaud well, even theoretically?
15:54 diakopter pmichaud: tee hee;
15:54 Coke we need to keep the original code around for backtraces, introspection, etc., though.
15:54 diakopter it's just like adding more pp steps
15:55 pmichaud so, something like    "puts [expr 3 + 4]"  ends up evaluating the [expr 3 + 4] first (7), then substituting that into the larger string and evaluating it?
15:55 john_ left #parrot
15:56 Coke ... basically, yes.
15:56 Coke I think an argument could be made that it does the parse /first/, and then substitutes it into the first argument, not the entire command-string.
15:57 Coke ... hurm. no, as soon as it gets to the ], it should do that substitution, i think. So yeah, you're essentially correct there.
15:57 pmichaud what about something like  "puts abc[expr 3 + 4]"  ?
15:57 pmichaud is that the same as  "puts abc7" ?
15:57 Coke yup
15:57 pmichaud if the [...] returns a result containing spaces, those get treated as separate words by the "caller"?
15:58 Coke no.
15:58 Coke (pretty sure, checking.)
15:58 Coke % puts abc[string repeat " " 3]bca
15:58 Coke abc   bca
15:58 Coke as opposed to:
15:58 Coke % puts abc   bca
15:58 Coke can not find channel named "abc"
15:59 pmichaud so, a command gets broken up into its words before the substitutions take place?
16:00 pmichaud ah, item [12] in the syntax list says yes
16:00 Coke ... I was just about to point to that, yes.
16:01 Coke =-)
16:01 pmichaud 15:45 <Coke> (since the user might change the definition of a builtin on the way, and we'd have to make the compiler know that, so we'd have to run it, so...)
16:02 pmichaud does the definition of a builtin affect the parsing of the command at all?
16:02 pmichaud or just the execution?
16:02 Coke not parsing, just e... right.
16:02 Coke you can't dynamically change the parser.
16:02 pmichaud okay, excellent.
16:02 Andy_ joined #parrot
16:03 pmichaud so, it's possible to parse an entire tcl program in one go -- we just have to keep the execution units smallish
16:03 Coke you just can't throw errors if there's a parsing error down the road.
16:04 Coke see http://github.com/partcl/partcl​/blob/master/t/cmd_catch.t#L80
16:04 pmichaud okay, noted
16:05 pmichaud how does partcl currently store/process new commands?
16:06 Coke new commands are implemented with [proc] (runtime/commands/proc.pir)
16:07 Coke basically, comile the given tcl into PIR, compile it, shove some metadata into the .Sub, and stick it into the appropriate namespaces.
16:07 Coke s/ces//
16:07 Coke (er, singular NS)
16:07 Coke subs in namespaces have a leading '&', so proc is really in parrot's ['tcl'; '&proc']
16:08 pmichaud okay, so for this we really do want compilation to PIR then
16:09 Coke everything ends up as PIR before we run it. we just might be delaying that compilation until the last minute.
16:09 pmichaud well, it wouldn't have to be that way.  one could store and interpret the ast
16:09 Coke if we had an AST, sure. =-)
16:10 Coke (right now we might be able to save the TGE tree when we were done...)
16:11 pmichaud do you have a preference or leaning on a a "compile to pir" versus "interpret to ast" approach?  (I'm waffling internally on that)
16:11 pmichaud I guess "compile to PIR" is ultimately more interesting/useful.
16:12 Coke I think either way, if someone changes a tcl level proc that our chunk of code contains, we'll need to re-translate it from scratch anyway.
16:12 Coke so in that case, keeping the ast doesn't help us.
16:13 pmichaud well, if the ast simply represents calls to operations but doesn't bind to specific subs, it's not too bad.
16:13 pmichaud basically the ast avoids a re-parse
16:13 Coke so, with the [for] builtin, we can have a spiffy ast; but that ast will change if someone overrides [for], we have to just replace the nice ast with a "call this sub".
16:13 Coke ah, I was expecting the ast to be more clever for builtins.
16:13 pmichaud ah, I see.
16:14 Coke (doesn't have to be for initial conversion, of course. we can start with everything being "call this sub")
16:14 pmichaud I was thinking less clever to begin with, and then start figuring out ways to usefully inline.
16:14 Coke right.
16:14 pmichaud (if we decide that's important :)
16:14 Coke yah, want to see how the initial conversion impacts speed.
16:15 Coke I suspect converting the flow control builtins will give us the biggest bang if there's any bang to be had.
16:18 pmichaud (thinking)
16:19 Coke (another thing protoregexes will help with: dynamically adding math functions to expr's syntax.)
16:19 Coke (doesn't work at all currently.)
16:20 pmichaud yes, protoregexes are a huge help for that.
16:21 pmichaud (reading about upvar and variable scope)
16:21 Coke I do that now by having a handrolled var context stack.
16:22 Coke (moving to parrot's wouldn't help at the moment, I think, because of [uplevel] requirements)
16:22 Coke runtime/variables.pir is rather ugly.
16:22 pmichaud upvar is dynamic scoped, not lexical, yes?
16:23 pmichaud or.... hmmm.
16:23 Coke upvar is based on caller scope, yes.
16:24 pmichaud yeah, parrot's 'lexicals' don't really help much there then, since they're static scoped
16:25 pmichaud since contexts are now PMCs, it becomes a lot easier to inspect the caller stack, though.
16:25 Coke yah. I was going to fake it with a dynlexpad when we converted to using parrot's call"stack"
16:26 Coke but i suspect that runtime/variables.pir can survive the translation to nqprx.
16:26 Coke ... not that i want it to.
16:26 pmichaud So, each tcl subroutine can have a "LEXPAD" (parrot) lexical that is a hash containing the lexpad that contains the dynamic lexicals
16:26 pmichaud then we don't need a parallel context stack
16:26 Coke how would that handle recursion?
16:27 pmichaud each subroutine invocation gets its own "LEXPAD"
16:27 Coke ... where is that stored?
16:27 pmichaud in the context
16:27 Coke k.
16:28 pmichaud invoking a subroutine creates a context containing a LEXPAD entry.  At the beginning of the sub, we initialize LEXPAD to be a Hash
16:28 pmichaud so each subroutine invocation ends up with its own LEXPAD, that we can easily find by following the caller contexts
16:29 pmichaud (intermediate non-tcl contexts won't have LEXPAD, so we just don't include them in the upvar count)
16:29 Coke my approach was going to be to add dynlexpad to the parrot stack as we traversed.
16:29 Coke (and yes, skip levels that didn't have that as we went through.)
16:29 Coke sounds like we're on the same page.
16:29 pmichaud I think this is essentially the same, except we don't need to use the DynLexPad PMC :)
16:30 pmichaud (which doesn't completely work afaik anyway)
16:30 Coke only reason I would prefer that (yes, there's bugs, think I opened a ticket on one of them) is that if they're in the lexpad, someone else might be able to find them from another hll.
16:30 Coke (maybe)
16:30 pmichaud that's a reasonable point
16:30 dalek winxed: r177 | julian.notfound++ | trunk/ (2 files):
16:30 dalek winxed: new operator '%%' (cmod), suggested by PacoLinux++
16:30 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=177
16:30 Coke but "working" is a good first step. =-)
16:30 Coke I'll jump off the hll interop bridge when we get there.
16:32 pmichaud okay, last question for a bit.  Think there would be much value to only generating PIR for proc definitions?
16:32 pmichaud and have all other commands be "immediate evaluation" without going through PIR ?
16:35 Coke I don't understand.
16:35 Coke (more)
16:36 Coke right now, if we invoke /any/ command, we generate PIR to do the invoke, check for args, dispatch to [unknown] if it exists; if that is done in the conversion process (rather than generate PIR to immediately do it), I think that actually works better than it does now, as it gives us the "process each (sub)command as soon as it happens" for free.
16:36 Coke is that what you mean?
16:37 pmichaud I think so.
16:37 Coke then sure.
16:37 Coke =-)
16:37 pmichaud Essentially I'm thinking that the only time we might need to generate PIR is when evaluating a proc command
16:37 pmichaud in which case we're making a stored procedure
16:37 pmichaud the rest of the time, the command could be executed immediately by interpreting the ast (i.e., calling the commands directly without generating PIR to call the commands)
16:37 Coke ok. there are a few other things, like [namespace eval {...}] and [rename], but we can deal with those as we get to them.
16:38 Coke but yah, [proc] is the big one.
16:38 pmichaud it would mean that the compiler essentially has two parts -- one that generates PIR versus one that does "immediate eval"
16:38 pmichaud and proc simply invokes the part that says "generate PIR"
16:38 pmichaud okay, this is all hugely interesting and helpful
16:38 Coke seems reasonable on paper.
16:39 pmichaud so, here's my plan for the moment
16:39 pmichaud first, I need to take a walk to digest these details
16:39 Coke heh.
16:39 Coke step two: ...
16:39 Coke step 3?
16:39 purl step 3 is PROFIT! or "Get your girl to open that box" or http://www.step3profit.com/
16:39 pmichaud then, I think I'll briefly start a new git repo to see what I can do with nqp
16:40 pmichaud mainly parsing the simple commands and running a few simple things
16:40 Coke ok. again, feel free to use a branch off partcl/partcl
16:40 Coke (but if there's too much cruft in there, anywhere is fine.)
16:40 pmichaud will do.  my first attempt has a good chance of being a throwaway
16:41 pmichaud if it's not a throwaway, we can just move my repo to the partcl account on github as a separate repo
16:41 pmichaud or we could do branch, but I suspect this will be a fundamental enough change that the pieces we want will primarily be the test suite
16:41 pmichaud we'll see -- I just need to start something to see how it kind of falls out
16:43 pmichaud what kinds of substitutions are allowed in double-quoted strings?
16:43 pmichaud just $-vars, or [-substitutions also?
16:43 Coke both. (there's a list....)
16:44 pmichaud okay, I see the example with [-substitution now
16:44 pmichaud so, it's like a Perl 6 closure interpolation
16:44 Coke see the list of 12 rules, #4.
16:44 Coke command, variable, backslash.
16:44 pmichaud right
16:44 pmichaud just like Perl 6 :)
16:44 Coke easy peasy.
16:45 Coke (I knew larry was copying jon!)
16:45 pmichaud (and NQP itself, fwiw)
16:45 pmichaud I'm glad I'm doing this *after* having done NQP and Rakudo in the new protoregex world :)
16:46 pmichaud this looks like fun
16:48 pmichaud is the first part of a command a "word" also?
16:48 pmichaud i.e., can one do something like
16:48 pmichaud set foo puts;  $foo abc
16:48 pmichaud looks like "yes"
16:57 redbrain_ anyone else use git-svn for parrot?
16:57 whiteknight redrain_: I tried once, no likey
16:59 bubaflub redbrain_: yes
17:00 bubaflub not very successfully, but yes. i know dukeleto may use it as well
17:03 dalek TT #541 closed by whiteknight++: r37927 segfaults on building lua
17:05 Coke pmichaud: yes.
17:05 redbrain_ yeah its taking like ages to clone lol
17:06 redbrain_ its going to be very painful to move from svn to git i think since there is so much history
17:08 whiteknight somebody had a compressed svn history project for git-svn you could download
17:08 redbrain_ oh cools yeah i have been downloading all afternoon
17:08 redbrain_ lol
17:09 redbrain_ stilll on r18***
17:09 redbrain_ still*
17:11 dukeleto 'ello
17:11 dukeleto redbrain_: we have a git-svn tarball
17:12 dukeleto git-svn?
17:12 purl git-svn is amazingly great or https://trac.parrot.org/pa​rrot/wiki/git-svn-tutorial
17:13 dukeleto trac is painfully slow right now
17:14 dukeleto http://technosorcery.net/system/parrot-git-svn.tbz
17:15 dalek tracwiki: v19 | dukeleto++ | git-svn-tutorial
17:15 dalek tracwiki: https://trac.parrot.org/parrot/wiki/git-​svn-tutorial?version=19&amp;action=diff
17:25 lucian joined #parrot
17:33 iblechbot joined #parrot
17:35 dalek tracwiki: v11 | japhb++ | Migrating%20to%20NQPrx
17:35 dalek tracwiki: Add notes about closure interpolation and whitespace/paren issues
17:35 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrati​ng%20to%20NQPrx?version=11&amp;action=diff
17:35 dalek tracwiki: v12 | japhb++ | Migrating%20to%20NQPrx
17:35 dalek tracwiki: Minor prose improvement
17:35 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Migrati​ng%20to%20NQPrx?version=12&amp;action=diff
17:39 bubaflub so i'm kinda out of the loop on all of this; could someone explain to me what NQP is and why we have it?
17:39 bubaflub beyond NQP = Not Quite Perl
17:40 cotto_work nqp?
17:40 purl nqp is not quite perl (6) or http://svn.perl.org/parrot/trunk/compilers/nqp
17:40 cotto_work That's not terribly useful.
17:41 cotto_work The idea behind nqp is to have a HLL without a significant runtime.  That way we aren't stuck writing PIR directly, but whatever's written in nqp can be compiled to pir without needing any extra supporting code.
17:41 Coke other vms might have chosen scheme or lisp for this. =-)
17:41 cotto_work but not us
17:42 diakopter purl, no, nqp is http://github.com/perl6/nqp-rx
17:42 purl okay, diakopter.
17:42 diakopter nqp?
17:42 purl nqp is http://github.com/perl6/nqp-rx
17:42 Coke botcheck?
17:42 diakopter (the README that appears inline that page is thorough)
17:42 bubaflub ah, righteous.
17:44 diakopter purl, nqp is also (see the README on that <-- url)
17:44 diakopter purl, nqp is also "(see the README on that <-- url)"
17:44 diakopter purl, nqp is also see the README on that <-- url
17:44 diakopter nqp is also see the README on that <-- url
17:44 diakopter sigh
17:44 diakopter purl, die in a grease fire
17:44 purl diakopter: what?
17:44 diakopter exactly.
17:45 cotto_work nqp?
17:45 purl well, nqp is http://github.com/perl6/nqp-rx
17:45 diakopter purl: nqp is also see the README on that <-- url
17:45 cotto_work unbotsnack
17:45 purl thanks cotto_work :)
17:45 cotto_work you're not welcome
17:45 diakopter :)
17:47 bubaflub another random question: what's the motivation for not using a cuddled else
17:48 Coke bubaflub: I think that was chip's preference and no one cared enough to argue.
17:49 bubaflub ok, good enough for me
17:49 Coke (now enshrined in, what, pdd07?)
17:49 bubaflub just wondering
17:49 purl just wondering is the interpreter itself makes any distinction
17:49 Coke no, just wondering is <reply>The answer is no.
17:49 purl okay, Coke.
17:52 whiteknight any standard improves readability so long as it is followed consistently
17:52 whiteknight And arguably we can't always cuddle teh else, so it's better to never do it
17:53 japhb joined #parrot
17:54 cotto_work Plus Klingons know that a true warrior doesn't cuddle his elses...he dead-grips them.
17:54 bubaflub hahaha
17:54 bubaflub yeah, i saw the coding standard and was just wonderin'
17:54 bubaflub i've seen about an even split in code / textbooks between the else style
17:55 whiteknight yeah
17:55 whiteknight Parrot's code is relatively clean and nice-looking because of all the consistently-followed standards
17:55 whiteknight some I disagree with, but whatever
17:56 bubaflub the no extra whitespace at the end of a line got me a few times
17:56 Dex joined #parrot
17:56 whiteknight yeah, that's a standard that I like much more when i have an editor that shows trailing whitespace or even fixes it automatically
17:57 bubaflub yeah, i think i might have a git option somewhere...
17:57 bubaflub now i just run prove -v t/codingstd/* before submitting any patches
17:57 bubaflub on top of the regular tests
17:58 Coke bubaflub: also, "make codetest"
17:58 bubaflub doh!
17:59 cotto_work now you know
17:59 purl And knowing is half the battle.
18:01 whiteknight purl++
18:06 dukeleto bubaflub: hola!
18:06 bubaflub good $localtime, dukeleto
18:06 bubaflub i think it's still morning for ya on the west coast
18:07 dukeleto bubaflub: yep
18:13 dukeleto bubaflub: what are you working on?
18:13 bubaflub left-over Chinese from yesterday
18:13 bubaflub but seriously, not a whole lot at the moment
18:14 Tene whiteknight: ping
18:14 Tene whiteknight: I tried my cross-hll problem again with latest parrot.  it now fails regardless of GC.
18:15 bubaflub dukeleto: got something for me to hack away on?
18:15 whiteknight Tene: okay
18:15 whiteknight Tene: could you provide a step-by-step guide to reproduce it?
18:15 whiteknight I don't have Rakudo or Steme installed at the moment, so I need to do that
18:16 Tene whiteknight: the current instructions on the ticket work.  it fails differently, though.
18:16 whiteknight ok
18:17 nopaste "tene" at 97.117.56.150 pasted "failure for whiteknight++" (22 lines) at http://nopaste.snit.ch/18750
18:17 Tene AFK, teaching.  Will talk again later.
18:19 dukeleto bubaflub: of course!
18:19 dukeleto bubaflub: how masochistic are you feeling?
18:20 mokurai joined #parrot
18:20 bubaflub hmmmm.... particularly today
18:22 chromatic joined #parrot
18:23 Coke why is parrot-tickets trying to post to parrot-dev?
18:23 Coke (e.g. on #744. I have an admin request holding that on parrot-dev)
18:24 Coke aha. please don't have tickets cc the dev list. :|
18:24 dukeleto bubaflub: want to hack on parrot in postgres?
18:24 bubaflub hoo boy sure
18:24 bubaflub i just got my postgres installation fixed last night
18:24 bubaflub just so happens.
18:27 dukeleto bubaflub: which version of postgres?
18:27 bubaflub 8.4.1
18:27 Coke anyone care if I turn off require_explicit_destination for parrot-dev?
18:27 whiteknight what does that do?
18:27 Coke right now it's blocking parrot-tickets from auto-posting to the -dev list when cc'd there.
18:28 Coke forcing me to admin approve every message from trac to parrot-dev
18:28 Coke (normally it block someone from bcc'ing parrot-dev)
18:29 dukeleto Coke: i think that is fine.
18:29 dukeleto Coke: we don't want to bury you in approval emails
18:29 ttbot joined #parrot
18:30 dukeleto bubaflub: you have a commit bit now: http://github.com/leto/plparrot
18:30 dukeleto bubaflub: read HOWTO to get it working
18:30 dukeleto bubaflub: there are tests!
18:30 bubaflub huzzah
18:30 bubaflub clonin' now
18:30 dukeleto bubaflub: we don't have any type of proper config or build stage.
18:31 bubaflub hmmm
18:31 dukeleto bubaflub: we need to be able to detect pg_config and say "Hey, i see you are using Postgres 8.whatever"
18:31 dukeleto bubaflub: we need a proper test harness
18:31 bubaflub are we assuming that'll be in the path?  or should we have that supplied by commandline?
18:32 dukeleto bubaflub: test harness will be nqptap shelling out to psql to run .sql files
18:32 dukeleto bubaflub: just assume that pg_config is in the path
18:32 dukeleto bubaflub: first feature: bail if pg_config cannot be found
18:32 bubaflub ok
18:33 dukeleto bubaflub: you can tweak the Configure.nqp that exists already, or start fresh. whatever works
18:33 bubaflub okey dokey.
18:33 bubaflub i'll see if i can get this setup
18:33 dukeleto bubaflub: some stuff is hardcoded, you will have to change them to your paths :) patches welcom!
18:33 dukeleto welcome, even
18:34 bubaflub ah, cool
18:34 dukeleto bubaflub: feel free to commit to master unless you are really setting things on fire
18:34 bubaflub hahaha
18:34 bubaflub burn this mo down
18:35 dukeleto bubaflub: it is hard to brake something that doesn't quite work. we can use topic branches when there is something to break :)
18:36 dukeleto bubaflub: make sure to read IDEAS as well
18:39 Coke (email) fixed, you can cc the dev list with  impunity.
18:39 Coke (but please have some punity.)
18:40 * dukeleto lost his punity
18:54 Tene whiteknight: That failure doesn't appear to be GC-related, and still fails with GC disabled... so should I open a different ticket?
18:54 Tene ... Oh, I can just change the summary.
18:54 whiteknight yeah, just change it
18:55 joeri joined #parrot
18:59 Tene Updated ticket.
19:02 Tene Oh, huh, steme fails even trying to import from itself, without rakudo.
19:04 lucian is this in any way interesting to you guys? http://doc.cat-v.org/inferno/concurrent_gc/
19:12 dukeleto lucian: hello
19:12 purl hola, dukeleto.
19:14 Tene whiteknight: I found it.
19:15 whiteknight found what?
19:15 Tene whiteknight: .param 4pmc has_hll 4:opt_flag
19:15 Tene whiteknight: that's what was causing the assert fail I was seeing.
19:15 whiteknight oh wow
19:15 whiteknight something like that should really be caught
19:15 Tene IMO, should just be boxed.
19:16 whiteknight in ether case, we need to account for it
19:16 Coke tene: what about .param string foo :opt_floag ?
19:16 Coke s/oa/a/
19:16 NotFound The doc says that :opt_flag must be int.
19:16 Coke WFM.
19:17 whiteknight WFM?
19:17 purl i guess WFM is works for me (for lazy folks)
19:17 Tene WFMT
19:17 chromatic If I had a syntax test for IMCC, I could make that into a syntax error.
19:17 Tene fixing it, I now get a different error elsewhere...
19:18 Coke chromatic: committing shortly.
19:18 dukeleto lucian: can that algorithm be used in a real-time system? we an in the market for a real-time GC
19:19 dukeleto lucian: but if you would like to add a new optional GC to parrot, go for it. we have a pluggable GC
19:19 lucian dukeleto: i don't know really, i didn't read that very carefully
19:19 lucian dukeleto: it does seem incremental, so should be real-timeable
19:19 Coke chromatic: adding a failing test to PIR based code sucks.
19:20 cotto_work The Inferno Mutator is way less awesome than the name implies.
19:20 chromatic pir_error_output_is....
19:20 nopaste "coke" at 72.228.52.192 pasted "shows the error" (9 lines) at http://nopaste.snit.ch/18751
19:20 fperrad joined #parrot
19:20 Coke chromatic: that's a PIR sub?
19:20 Coke (I thought that was perl only)
19:21 chromatic Hm, good point.
19:22 chromatic I thought someone added throws_ok to PIR though.
19:22 dukeleto Coke: use throws_like()
19:22 dukeleto lucian: have you worked on the GC subsystem before?
19:23 Coke dukeleto: and then also make it a todo. PITA, currently.
19:23 Coke Tene: tt #?
19:23 lucian dukeleto: not on anything serious, i'm probably not the right person to do something like this
19:23 Tene Coke: for what?
19:24 Tene lucian: Nobody else is currently working on it, and you're certainly more right than nobody. :)
19:24 lucian Tene: if i find time, i'll give it a shot
19:25 Tene ;)
19:25 Coke the :opt_flag issue?
19:25 dalek rakudo: c00de9d | tene++ | perl6.pir:
19:25 dalek rakudo: Look up %INC in the right namespace when loading libraries for foreign languages
19:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​00de9dd064b620c858c2de3c962629e702ade66
19:25 Coke (or the ticket that spawned it)
19:26 Coke #744 ?
19:27 dukeleto lucian: if you could add any links you find about GC algorithms to the wiki, that would be useful. do we have a wiki page for GC-related stuff?
19:28 Tene Coke: Kinda.  The original problem with #744 has been resolved, but after pcc refactors, my misuse of :opt_flag was revealed, so it then crashed for unrelated reasons.
19:28 Tene Coke: So, not appropriate to track in #744, which I just closed.
19:28 Coke if you open a new ticket, I'll commit this test. =-)
19:28 dalek TT #744 closed by tene++: Assertion Failure with steme and rakudo
19:29 Tene Man, you're as bad about this as my boss is, always harassing me to open tickets... :P
19:29 Coke <- harasser.
19:29 Coke hey, I wrote the test for you!
19:30 dalek parrot: r42567 | fperrad++ | trunk/t/library/mt19937ar.t:
19:30 dalek parrot: [mt19937] convert test in PIR (from �http://github.com/fperrad/parrot-MT19937)
19:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42567/
19:30 Tene Coke: Sorry, AFK lunch right now. ;)
19:30 Coke ok. I'll leave the old ticket number for now and you can fix it. =-)
19:31 Coke chromatic: incoming.
19:31 purl duck!
19:32 Coke quack.
19:33 * Coke wonders when he started using "joe" as a foo/bar/baz.
19:33 dalek parrot: r42568 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
19:33 dalek parrot: [languages] remove t/harness (now use prove)
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42568/
19:33 dalek parrot: r42569 | coke++ | trunk/t/compilers/imcc/syn/regressions.t:
19:33 dalek parrot: Add test for a bug discovered by Tene++
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42569/
19:33 Coke ah, from "joey bag o' donuts", prolly.
19:34 dukeleto Coke: My Cousin Vinny!
19:34 Coke I'm pretty sure we're not related, no.
19:36 * Coke wishes to own that movie.
19:37 ttbot Parrot trunk/ r42567 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/147377.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
19:37 Coke ttbot, that's old.
19:38 Coke (ah. last one from client 8, so that's ok still)
19:38 Coke client #8 is slow!
19:38 Coke chromatic: did you ever export the STRINGNULL?
19:39 Coke (mswin32 seems to not be able to find it at link time.)
19:39 chromatic I did.
19:40 moritz are parrot-ticket mails suddenly fowarded to parrot-dev?
19:40 chromatic Is that failure in parrot_debugger?
19:40 Coke why yes it is.
19:40 moritz I didn't subscribe parrot-tickets, but I suddenly get those trac mails
19:40 Coke moritz: that's because someone cc'd the list.
19:40 Coke (the -dev list)
19:40 moritz Coke: ok, thanks
19:40 Coke if you look at the cc' for that ticket...
19:40 Coke (took me a minute before, too.)
19:41 Coke chromatic: figuring a test in perl is better than no test in pir, I dumped it into the catchall 'regressions' test file.
19:42 chromatic Thanks!
19:44 ttbot Parrot trunk/ r42569 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/147404.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
19:45 Coke chromatic: shouldn't it be PARROT_EXPORT STRING *STRINGNULL;
19:45 Coke ?
19:46 chromatic I'm not sure we want to export something to which other people can assign though.
19:46 chromatic External code should prefer the STRING_is_null() function.
19:46 bubaflub left #parrot
19:47 Coke er, PARROT_DATA
19:47 Coke (PARROT_DATA is used on PMCNULL)
19:48 Coke seems to just do an 'extern "C"' or equivalent when necessary.
19:48 Coke makes sense that would bother msvc
19:51 Austin joined #parrot
19:52 bacek joined #parrot
19:55 Coke (there's a PARROT_DATA on include/parrot/interpreter.h but not src/string/api.c ; could that be the issue?
19:55 Coke ... doesn't look like src/pmc.c has one for PMCNULL. I have no clue. ah well.
20:00 TimToady phone
20:18 hachi joined #parrot
20:20 tetragon joined #parrot
20:25 Coke ... whoops.
20:25 PacoLinux joined #parrot
20:28 nopaste "pmichaud" at 72.181.176.220 pasted "initial playing with tcl" (9 lines) at http://nopaste.snit.ch/18754
20:29 pmichaud Coke: http://github.com/pmichaud/pmtcl  # yes, it's over-simplified at the moment
20:31 Tene pmichaud: is nqp-rx appropriate for other HLLs to migrate to yet?
20:31 dukeleto Tene: yes, the version that is in parrot core, in ext/
20:33 theory joined #parrot
20:38 Coke pmichaud++
20:41 hercynium joined #parrot
20:57 payload joined #parrot
21:10 whiteknight purl msg lucian I've been reading the VCGC paper, it looks very interesting and is something I would like to implement in Parrot some day
21:10 purl Message for lucian stored.
21:11 theory joined #parrot
21:11 whiteknight purl msg dukeleto: the vcgc algorithm does all it's processing in threads with few synchronization points. Should be real-time usable I think
21:11 purl Message for dukeleto stored.
21:12 Coke message in a bottle
21:12 purl Message for in stored.
21:12 Coke </sting>
21:12 whiteknight good job, Coke. Confusing the bot
21:15 Coke 16:12 <+purl> Message for in stored.
21:15 Coke ... well, that's something, anyway. =-)
21:16 cotto_work Won't in be surprised when he logs in and purl presents him with a bottle.
21:17 chromatic He shouldn't be surprised.  purl watches every breath he takes.
21:18 nopaste "pmichaud" at 72.181.176.220 pasted "tcl command substitution in middle of word" (19 lines) at http://nopaste.snit.ch/18756
21:19 Coke pmichaud: I watch eagerly as you re-do the first 4 years of partcl development in a week. =-)
21:19 Coke (oh, hey, I'll get annotations for free. bonus.)
21:19 Coke (that will let me make the backtraces more tcl like)
21:20 nopaste "pmichaud" at 72.181.176.220 pasted "tcl nested command substitutions" (13 lines) at http://nopaste.snit.ch/18757
21:21 mokurai joined #parrot
21:21 Coke I remember having to parse all this crap with handrolled PIR because it predated PGE. =-)
21:21 Coke . o O (uphill both ways)
21:21 pmichaud .oO( in the snow )
21:22 pmichaud .oO( without a jacket )
21:22 Coke I wonder if the original p5 based "compiler" still exists anywhere.
21:22 particle .oO( square wheels )
21:22 NotFound Coke: Internet Archives is watching you.
21:23 pmichaud "You had wheels?!"
21:23 pmichaud "In my day, we had to walk with cement blocks strapped to our feet.  And we liked it!"
21:23 particle can braced word use ~ ?
21:23 particle token braced_word { '{' $<val>=[<-[}]>*] '}' }
21:24 NotFound pmichaud: sounds like programming in Cobol.
21:24 particle could that use '{' ~ '}' or does that require balancing?
21:28 pmichaud I don't think it requires balancing.
21:28 pmichaud I suppose it could use ~; hadn't tried it.
21:29 GeJ Good morning everyone.
21:30 mokurai left #parrot
21:31 lucian purl: msg whitenight yeah, it's one of the few GC strategies i've seen that are real-time capable
21:31 purl Sorry, I've never seen whitenight before.
21:31 lucian purl: msg whiteknight yeah, it's one of the few GC strategies i've seen that are real-time capable
21:31 purl Message for whiteknight stored.
21:31 lucian purl: thank you
21:33 lucian purl: thanks
21:33 lucian purl: botsnack
21:33 purl :)
21:34 hercynium joined #parrot
21:36 tetragon joined #parrot
21:51 nopaste "pmichaud" at 72.181.176.220 pasted "even more tcl fun -- simple variables" (12 lines) at http://nopaste.snit.ch/18758
22:28 dalek lua: a233d99 | fperrad++ |  (2 files):
22:28 dalek lua: remove staging
22:28 dalek lua: review: http://github.com/fperrad/lua/commit/a2​33d996fef7b1f8f4ee58903f844181a9a87317
22:32 nopaste "pmichaud" at 72.181.176.220 pasted "okay, now I'm just showing off a bit. :-)" (7 lines) at http://nopaste.snit.ch/18759
22:41 PerlJam pmichaud: gah!  Wasting time on tcl instead of improving rakudo?  For shame.
22:41 PerlJam ;-)
22:42 PerlJam pmichaud++ for showing off anyway.  :)
22:43 dukeleto 'ello
22:46 dukeleto message purl will this make you go boom?
22:46 purl Message for purl stored.
22:49 Tene pmichaud: persistent lexicals, or are tcl vars not lexical?
22:53 cconstantine joined #parrot
22:58 Whiteknight joined #parrot
23:09 pmichaud Tene: cheating lexicals
23:10 pmichaud right now pmtcl just stores all variables in a shared hash
23:10 pmichaud (so they end up being persistent)
23:11 pmichaud parrot's default lexicals aren't sufficient for tcl anyway
23:16 zak_ joined #parrot
23:17 dalek winxed: r178 | julian.notfound++ | trunk/ (2 files):
23:17 dalek winxed: add '<=' and '>=' operators and refector '<' and '>'
23:17 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=178
23:24 kiwichris joined #parrot
23:27 darbelo joined #parrot
23:29 mikehh All tests PASS (pre/post-config, smoke (#30019), fulltest) at r42559 - Ubuntu 9.10 amd64 (gcc with --optimize)
23:31 dukeleto mikehh++
23:36 Whiteknight dukeleto: does nqpTAP work on old NQP, or NQP-RX?
23:37 dalek winxed: r179 | julian.notfound++ | trunk/examples/parser.winxed:
23:37 dalek winxed: start implementing local int vars in example parser
23:37 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=179
23:37 dukeleto Whiteknight: nqptap is the new nqp-rx
23:37 Whiteknight awesome
23:38 dukeleto Whiteknight: the nqptap repo is just a skeleton right now, but soon it will be functional. IRL has been throwing me some curveballs
23:38 darbelo MSVC--
23:38 dukeleto Whiteknight: the test harness in plumage (which nqptap came from) was converted to nqp-rx a few weeks ago
23:38 Whiteknight dukeleto: same here.
23:39 dalek parrot: r42570 | darbelo++ | trunk/src/parrot_debugger.c:
23:39 dalek parrot: Use function version of STRING_is_null() in the debugger to make MSVC happy.
23:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42570/
23:40 darbelo Okay, that should shut up ttbot for a few hours.
23:42 dalek parrot: r42571 | chromatic++ | trunk/src/string/encoding.c:
23:42 dalek parrot: [string] Initialized the encoding pointer variables, in the hopes that they
23:43 dalek parrot: will no longer contain random memory and cause odd failures before proper
23:43 dalek parrot: initialization.  Hopefully this initialization won't upset picky C++ compilers.
23:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42571/
23:45 dukeleto MSVC--
23:45 dukeleto karma MSVC
23:45 purl msvc has karma of 136
23:45 dukeleto !
23:45 darbelo MSVC--
23:45 darbelo MSVC--
23:45 darbelo MSVC--
23:45 darbelo MSVC--
23:45 chromatic It must have wrapped around from zero.
23:46 dukeleto chromatic: lulz
23:46 cotto_work must be from people referring to the c plus plus compiler
23:46 darbelo c++--
23:46 cotto_work karma msvc++
23:46 purl msvc++ has karma of -1
23:46 dukeleto MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC-- MSVC--
23:47 darbelo karma msvc
23:47 purl msvc has karma of 131
23:47 Austin So what's wrong with msvc?
23:47 dukeleto Austin: the first 2 letters
23:47 cotto_work dukeleto, only one per line ;)
23:47 chromatic The C part of it.
23:47 dukeleto cotto_work: ug
23:47 darbelo <purl-->
23:48 chromatic My laptop has more than 32 kb of memory.  Surely their compiler could add a pass to identify variables declared other than the top of a scope.
23:48 cotto_work I don't think the V is so great either.
23:48 chromatic Yeah, what was with that hybrid kid in the last episode of the original miniseries?  Bizarre ending.
23:49 darbelo Wasn't that the hook for the TV series?
23:49 kid51 joined #parrot
23:50 chromatic I'm not sure.  I tried to put most of the '80s out of my mind.
23:50 japhb Is is just me, or is the current series doing reveals at a rather accelerated pace?  Perhaps they're running on the assumption that 80% of their audience already knows all the reveals, so they're going as fast as the remaining 20% can handle.
23:50 Austin Who has a MSVC build environment set up? And have you written a wiki page detailing all the ingredients?
23:51 Austin japhb: Maybe they're going at the "Wow, we actually got them to sign off on this garbage a second time? Quick, reveal before they figure it out!"
23:51 darbelo Austin: I think jonathan has, he was the last one to fix massive MSVC breakage.
23:52 darbelo japhb: New series?
23:52 purl well, New series is quite good
23:52 Austin darbelo: V.
23:52 japhb darbelo, There's a V on right now.  The alien lead is played by the Companion from Firefly.
23:52 darbelo Austin: Hadn't heard about that.
23:52 chromatic Alan Tudyk is the alien lead?
23:52 japhb LOL
23:53 Austin Darbelo: Don't worry. I'm sure it hasn't become a better idea the second time around.
23:53 Austin (But I'll bet the CGI is great.)
23:53 chromatic Curse their sudden but inevitable betrayal.
23:53 Zak joined #parrot
23:53 darbelo I'll give it a look when it crosses the equator.
23:53 japhb chromatic, actually, he is in there!  But killed in episode 3 or so.
23:54 darbelo Austin: I think the key to a MSVC build was to Configure with ActiveState perl.
23:55 chromatic There are a lot of leaves on the wind outside my office right now.
23:55 japhb Austin, yeah, the CGI is pretty good.  Occasionally you wonder if they hit a budget limit, but at this point, compute time and tools are good enough that most of the time it's pretty unlimited.  I'm pretty sure that a fair number of the sets are 100% CGI.
23:55 Austin darbelo: Win! and here I sit with a hand full of Strawberries..
23:56 darbelo Austin: Those are broken less often. FWIW.
23:56 Austin Everybody and their freaking mother wants to bundle an msys environment...
23:57 Austin Strawberry has mingw, git has msys+bash. No wonder configure is befuddled.
23:57 japhb Austin: everybody and their freaking mother wants market penetration without having to deal with undiluted Windows.
23:57 darbelo Austin: And mixing the strawberrys with MSVC is likely to be poisonous. Do not attempt.
23:58 Austin Yeah. Fabulous.
23:58 japhb (Hell, even in the MS toolset: witness the popularity of MS-created layers upon layers on top of the base API.)
23:58 darbelo My only exposure to windows programming happened years ago. With MFC.
23:58 darbelo I haven't left unix since.
23:58 Austin japhb: It ain't easy being a climax species.
23:58 japhb I learned undiluted raw COM.  I went stark raving sane.
23:59 Tene I did some windows programming back in, like, 2003 I think?  2002?
23:59 Tene I have painful memories, but not detailed memories.

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

Parrot | source cross referenced