Parrot 1.8.0 Zygodactyly released | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 17 November 2009.
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.
I suspect it is.
it probably should be.
i.e., things that don't follow parrot's deprecation policy perhaps don't belong in the repo. 00:01
darbelo Won't that reintroduce the 'devel freeze' problems that made you take nqp-rx out of the repo? 00:02
00:02 tetragon joined
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
darbelo Whiteknight: Oops. I'm on it.
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
m trying to fix it, I just don't know how
chromatic I'd rather put specific exceptions in place for experimental code or code we expect to change somewhat. 00:06
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
japhb: i will be starting the parrot -> git train the minute that 2.0 comes out.
japhb dukeleto, NO ARGUMENT THERE. 00:08
darbelo Whiteknight: pushed it.
pmichaud darbelo: I expect that by the time we reach 2.0, nqp(rx) will be fairly stable.
Whiteknight w00t
darbelo++
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".
pmichaud japhb: I plan to write that tool for Rakudo, at least.
darbelo pmichaud: Glad to hear it. 00:10
japhb pmichaud, I'll be needing it in Plumage, no question. :-)
dukeleto japhb: pmichaud has a good idea for ordering
Whiteknight darbelo: it looks like it's still using /languages/nqp/nqp.pbc
darbelo Whiteknight: really? where? 00:11
Whiteknight do a make test
pmichaud the nqp tests indeed use nqp.pbc
Whiteknight the commandline there involves nqp.pbc
pmichaud they're testing the old nqp
(same as 1.4)
Whiteknight make test in parrot-linear-algebra
darbelo Oh, yeah, I know where it is. Let me fix that. 00:12
Whiteknight ok
dalek rrot-linear-algebra: c0d2c85 | darbelo++ | t/ (5 files):
s/parrot_nqp/parrot-nqp/ in the test files and harness.
 00:14
Whiteknight the harness itself is still run with nqp.pbc 00:15
check out config/Makefile.in:19
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.
Whiteknight okay. Teach me how to update the harness 00:16
I'm really trying to get a feel for what the differences are between old and new nqp
darbelo Whiteknight: learning that myself ;)
Whiteknight ah, okay 00:17
00:17 Limbic_Region joined
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
darbelo "Unable to parse blockoid, couldn't find final '}' at line 62" 00:19
Never seen that before.
Limbic_Region Whiteknight - thanks - hoping to build a EventLog message dll tonight 00:20
Limbic_Region bites the bullet
Whiteknight sorry 00:21
darbelo: yeah, that's the problem I'm seeing
weird
japhb Whiteknight or darbelo: paste or link the source? I might be able to eyeball it.
Whiteknight github.com/Whiteknight/parrot-linea.../t/harness 00:22
nopaste "darbelo" at 190.192.220.13 pasted "source of test harness for haphb" (85 lines) at nopaste.snit.ch/18745
japhb looking 00:23
Whiteknight w00t 00:24
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
1. collapse lines 40..42 to just 'for $output -> $line {'
2. unparen your if conditions 00:27
3. make sure all binary ops have spaces on both sides, and comma has space on the right
But like I said, there was nothing truly obviously wrong to me there.
Also, you no longer need to go through ~ contortions; double quoted strings interpolate variables and closures now. 00:29
so line 69 can be 'say("passed $curr_test tests");' 00:30
00:30 davidfetter joined
japhb And line 79 can be 'say("FAILED $total_failed / { $total_passed + $total_failed }");' 00:30
Whiteknight it doesn't like the elsif{} block 00:31
I take that out, it works fine
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
try dropping the elsif to the line after the closing } fot the if block
Whiteknight I pushed a fix 00:36
dalek rrot-linear-algebra: 6a03f61 | Whiteknight++ | src/pmc/complexmatrix2d.pmc:
silence a warning about casting the result of a function call
 00:37
rrot-linear-algebra: a2fefcf | Whiteknight++ | :
Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
rrot-linear-algebra: 676227d | Whiteknight++ | (2 files):
quick hackaround that makes the harness work again
rrot-linear-algebra: b58e1a6 | Whiteknight++ | t/10-nummatrix.t:
get the nummatrix.t test working again
japhb MUST have a space after keywords before parens, otherwise it could be seen as a function call. 00:39
And it looks like the pastebin was slightly out of sync with the code you were editing, sorry. 00:40
Anyway, elsif( is wrong. Should be elsif or elsif (
00:44 Limbic_Region left
chromatic www.cs.princeton.edu/research/techreps/TR-451-94 00:46
"Axiomatic Bootstrapping: A Guide for Compiler Hackers"
cotto party like it's 1994 00:58
01:01 abqar joined
plobsing hi #parrot 01:20
dalek trixy: ce63abc | Whiteknight++ | src/ (3 files):
add preliminary cell support
 01:21
trixy: 9951031 | Whiteknight++ | (2 files):
fix Matrixy so it works with NQP-RX.
Whiteknight hello plobsing 01:22
plobsing sorry I didn't attend #ps today. life conspired against me.
my report would have been pretty boring anyways
Whiteknight: have you had a look at the Lorito stuff I put on the wiki? 01:23
Whiteknight briefly
plobsing thoughts? 01:25
purl i like cheese
Whiteknight nothing concrete yet. I need to read some of the stuff cotto wrote too 01:29
plobsing yes, that's good stuff.
if anything comes of that page, it'll probably be me finally understanding why we'll use ops 01:30
i'm still not completely convinced
but getting there
purl it has been said that getting there is the problem. or half the fun
plobsing purl: forget but getting there
purl plobsing, I didn't have anything matching but getting there
Whiteknight still have some thinking and deliberating to od
dalek rrot-linear-algebra: 550b56d | Whiteknight++ | (2 files):
add a get_string() VTABLE to pmcmatrix2d
 01:31
rrot-linear-algebra: 8999282 | Whiteknight++ | src/pmc/pmcmatrix2d.pmc:
fix the get_string VTABLE on pmcmatrix2d
01:54 payload joined 02:36 hercynium joined, cconstantine joined
dalek tracwiki: v122 | jimmy++ | WikiStart 02:59
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
cotto plobsing, take a look at 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
Note that L1 is the old name for Lorito.
plobsing yes, I've read that over several times 03:06
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.
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?
Austin What was 42564 change? 03:08
plobsing currently parrot has 4 fundamental types. C has far more than that
03:08 kid51 joined
Austin WIP. Never mind. 03:08
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.
(types)
plobsing so that kind of stuff (ManagedStruct, Call-In FFI, Call-Out FFI, etc) is external to lorito? 03:11
because that kind of stuff can also benefit from JIT 03:12
cotto *lightbulb*
I see what you're saying.
plobsing as another example, ops (almost by definition) don't represent the structure of the program. there is a loss of information 03:13
eg: if/else,for,while all become goto 03:14
that information _may_ be usefull to compilers
how do these convert more easily to C than something that closely mirrors C? 03:15
cotto I'm not sure how gotos vs. more structured control flow would trip up an optimizer. 03:17
but types are definitely an issue we need to figure out before Lorito can become feasible. 03:18
plobsing I'm not sure of the details, but I have a gut feeling obscuring information from the compiler is not good 03:20
how will Lorito easier to validate than PBC? 03:25
dalek TT #1306 created by Austin_Hastings++: Various failures on bogus string used as argname (1.7) 03:26
plobsing if it is lower level, won't it be harder? 03:27
also, does the fact that Lorito will be easier to validate mean it will be valid to transfer Lorito programs between machines? 03:35
03:36 janus joined
plobsing It would be easier to make improvements to Lorito and the VM if it were entirely internal. 03:39
and not subject to the deprecation policy
Austin Yeah, stuff is always easier if you don't care about the users. 03:41
03:53 davidfetter joined
kid51 must sleep 03:59
purl $kid51->sleep(8 * 3600);
Ryan52 pfft, purl, programmers don't get 8 hours of sleep. silly bot.
05:42 cconstantine joined
Austin Argh! I'm being shagged by the new version of NQP. 05:57
dalek tracwiki: v123 | Austin_Hastings++ | WikiStart 06:14
tracwiki: Added link to (nyi) Migrating to NQPrx
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
06:19 kyle_l5l joined
dalek tracwiki: v1 | Austin_Hastings++ | Migrating%20to%20NQPrx 06:24
tracwiki: Created.
purl hmmm... created is correct
dalek tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
tracwiki: v2 | Austin_Hastings++ | Migrating%20to%20NQPrx
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
tracwiki: v3 | Austin_Hastings++ | Migrating%20to%20NQPrx
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
cotto Does anyone recall at which point ICU became a hard dependency? 06:29
Austin Is it one? 06:30
cotto istr so
Austin I've been seeing "no libiconv" messages for a while on Configure.pl
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.
Austin parrot-dev?
purl parrot-dev is mailto:parrot-dev@lists.parrot.org or lists.parrot.org/mailman/listinfo/parrot-dev
cotto yes 06:34
Austin I haven't seen his message yet.
cotto actually, parrot-users 06:35
Austin Ah.
Where I should probably live. 06:36
cotto nice to see that getting some traffic so quickly
06:37 mokurai joined 06:56 szabgab joined 07:01 uniejo joined 07:04 theory joined
Austin There's already a -nyc splinter list? 07:05
That's remarkably antisocial, even for New Yorkers.
cotto ? 07:06
Austin Parrot-users-nyc
lists.parrot.org/mailman/listinfo
cotto sounds nefarious 07:07
Austin You gotta problem wid dat? 07:08
07:20 chromatic joined
Austin pmichaud-- 07:25
cotto feeling the nqp-rx love?
Austin Found a bug.
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 ?\\
cotto a bug? that's unpossible!
Austin I scoff at your certitude!
cotto what's the bug?
purl the bug is www.cbttape.org/funny/bug3.jpg or img227.imageshack.us/img227/2596/featureiu1.jpg
Austin Stick around, it'll come by in a minute.
dalek TT #1307 created by Austin_Hastings++: NQP-rx doesn't handle comments correctly? 07:29
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:30
dukeleto 'ello 07:31
Austin hey, leto
dukeleto what is up with parrot-users-nyc ?
i am from nyc, i can make fun of them
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.
dukeleto what is the latest news? does NQP have flying cars yet?
Austin NQP has flying something.
It's not cars.
dukeleto flies a something 07:33
i need to sit down and write a NQP tutorial or something, just for my own sanity
Austin No you don't.
purl Oh no I don't
Austin You need to update the one already on wikibooks.
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.
dukeleto Shame Driven Development
Austin WhiteKnight will be your friend for life. 07:35
stupid pebkac 07:36
cotto WhiteKnight will be your friend for life.
Austin It's got a catchy rhythm, but you can't really dance to it...
WhiteKnight will be your friend for life.
dukeleto lulz 07:38
Patterner It needs more cowbell. 07:39
Austin Whiteknight lives not too far from Amish country. I'm sure there's plenty of cowbell. 07:40
cow-something, anyway.
Patterner cow-orkers?
purl hmmm... cow-orkers is traditional :)
cotto cow-burgers?
Austin Obsolete pod format, please use =begin/=end instead at line 5, near "module\\r\\nPr" 07:41
dukeleto MOAR COWBELL 07:42
Austin FWIW, I started a NQP -> NQPrx migration page on the wiki
dukeleto Austin: link?
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.
dalek p-rx: da7048b | dukeleto++ | CREDITS:
Add myself to CREDITS
Austin trac.parrot.org/parrot/wiki/Migrat...to%20NQPrx
dukeleto we really need a doc about how to write a HLL, from scratch, with NQP. i might do that 07:44
Austin Even better, write one about how to write scheme/lisp from scratch. 07:45
There's about eleventy-six guys in here doing that.
No spaces before ++ and -- postfix 07:49
dalek tracwiki: v4 | Austin_Hastings++ | Migrating%20to%20NQPrx 07:51
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
07:53 fperrad joined
dalek tracwiki: v5 | moritz++ | Migrating%20to%20NQPrx 07:54
tracwiki: spaces around 'else'
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
moritz somehow the numbering of items is broken on that page 07:55
I fear my trac-fu is too weak to fix it
Austin Probably because I've got those unnumbered paras between.
Maybe indenting them will fix it.
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
dalek tracwiki: v6 | Austin_Hastings++ | Migrating%20to%20NQPrx 07:58
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
Austin That worked. :) 08:01
moritz++
dalek tracwiki: v7 | Austin_Hastings++ | Migrating%20to%20NQPrx
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
08:02 barney joined
Austin Ahh, barney. 08:02
The man directly responsible for all my misery. 08:03
cotto You're thinking of the dinosaur.
Austin No, I'm old enough that I missed the creepysaurus. 08:04
I got to see the good stuff.
Statler and Waldorf 08:05
pmichaud pmichaud is already shamed into writing a tutorial, it's just a matter of finding time to do it :) 08:09
08:09 theory joined
pmichaud ah, yes, the comment bug was in rakudo-ng also. I need to fix that in nqp-rx. 08:09
Austin pmichaud: Is the no-space-before-++/-- a bug, or some kind of p6ism? 08:10
pmichaud p6ism
moritz Austin: in general disallowed before postfix operators 08:11
to easier disambiguate them from infix operators
dalek tracwiki: v8 | dukeleto++ | Migrating%20to%20NQPrx
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
Austin That seems like a bit of a stretch. Is anyone seriously considering infix ++ ? 08:13
pmichaud it's not that so much
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?
Hmm. No.
What is .bar in p6?
pmichaud foo .bar is the same as foo $_.bar 08:15
08:15 mikehh joined
Austin method call, no args? 08:15
pmichaud right
barney Austin: glad to help
pmichaud so, foo.bar is like (foo).bar
while foo .bar is like foo($_.bar)
there are other similar situations
Austin So is any of that going in to nqp? 08:16
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
Austin Other than proto-objects, what's a bareword term?
pmichaud in (full) Perl 6 we can get away with it because all bareword terms are lexically known at compile-time
constants 08:18
purl constants are good. sure it's a bit unusual :) but they had to
pmichaud the main ones are constants and protoobjects, yes.
moritz purl: forget constants
Austin Constants?
purl Constants are good. sure it's a bit unusual :) but they had to
moritz: I forgot constants
08:18 iblechbot joined
pmichaud constant pi = 3.14159; 08:18
(no, nqp doesn't have those (yet?))
Austin Is that supported now?
(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)
Austin :)
It's the latter. Nobody uses prefix+. 08:20
pmichaud okay, Foo -3 then.
Austin (Except to generate certain expressions.)
Yeah.
moritz "nobody wants to build a wall"
Austin But that's why we've got you, man.
To do the heavy lifting.
changing the subject entirely, pmichaud: 08:21
I've got this problem, tt #1306, where I'm calling x.new(:a('albacore'), :b('byzantine')) and garbage is going through. 08:22
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
(That's in 1.7)
dalek p-rx: 2bd89cd | dukeleto++ | examples/ (3 files):
Add some basic NQP examples
Austin Looking at the pir, the generated code is pretty direct: $P123."new"("albacore" :named("a"), etc.)
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
Austin (Essentially, corrupted hash keys in the slurpy named args collector hash).
pmichaud anyway, I don't know what could be causing it. You're correct that the generated PIR looks absolutely right.
Austin I'll see if it recurs in 1.8 08:25
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
need a space between while and the paren
Austin Is there a good way to set a C-level breakpoint on a PIR address?
pmichaud (it might work in current NQP, but some day will not work)
moritz the parens must go, otherwise it should be parsed as a subroutine call 08:27
cotto Austin, if it's a unique instruction it's not hard. 08:30
on a PIR address it'll be trickier 08:31
Austin cotto: what about a sub?
pmichaud I often add a fake "debug 1" or "noop" instructioninto the PIR, and the breakpoint on Parrot_debug_ic or Parrot_noop
s/the/then/
cotto what he said
Austin That's work.
chromatic We need a doop op.
Austin *That'd
chromatic democratic order of popcodes
dukeleto pmichaud: the while loop runs for me 08:32
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)
Austin Okay, the subs-are-lexical thing. How does that work? 08:34
dukeleto pmichaud: maybe a warning would be good?
pmichaud Austin: it just means that subs are "my" scoped instead of "our" scoped.
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
pmichaud TT #1279 is proving to be a real pain for nqp testing. :-( 08:38
dalek lscript: c693665 | fperrad++ | (3 files):
replace deprecated Array PMC
chromatic pmichaud, I can look at it tomorrow or Thursday. 08:40
dalek p-rx: 8aa6c0f | pmichaud++ | (2 files):
[nqp]: Allow comments after statement-terminating close brace (TT #1307).
p-rx: 52b8c42 | moritz++ | examples/loops.nqp:
[examples] remove parenthesis from while-loop
08:40 JimmyZ joined
p-rx: c719911 | pmichaud++ | :
Merge branch 'master' of git@github.com:perl6/nqp-rx
pmichaud chromatic: that would be great. Actually, I suspect the fix is fairly simple -- it's more a question of deprecation policy for me
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.
chromatic I can't imagine how there'd be a deprecation question about that.
pmichaud chromatic: I can't either, but sometimes I'm surprised.
Austin: you're correct, :anon appears to be missing. 08:42
Austin Nice. My "Welcome to the parrot-users list" email is considered spam.
chromatic I'll paint it red and hang a big "This is a Bug Fix" sign on it and we can all be happy.
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
Austin Too late, pm. It's a deprecation item. My code depends on it.
pmichaud Too bad, Austin. We haven't crossed a deprecation boundary :)
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.
Austin What about methods?
pmichaud in order for methods to appear in the namespace we'll probably need to implement "is export"
methods should not appear in the namespace by default
Austin Funny, while I don't know what that means, I think I might be implementing it. 08:45
Ahh, right.
pmichaud method xyz() is export { ... }
Austin Bummer. I was using "method" to save a bunch of opcodes.
No need to pay for that "$P0 = find_lex '$param1'' when I know 'self' is defined. 08:46
08:48 mikehh joined
pmichaud need sleep here -- be back in a few hrs 08:50
dalek rrot: r42565 | pmichaud++ | failed to fetch changeset:
[nqp]: Update NQP with latest syntax improvements (e.g., TT #1307).
 08:52
p-rx: ef88e99 | pmichaud++ | src/NQP/Grammar.pm:
At least generate *some* sort of error for things like while(1) and if(2).
p-rx: b8722f3 | pmichaud++ | t/nqp/05-comments.t:
Update plan.
p-rx: ecce4ce | pmichaud++ | src/stage0/ (3 files):
Bootstrap update with latest fixes.
TT #1307 closed by pmichaud++: NQP-rx doesn't handle comments correctly? 08:54
rrot: r42566 | cotto++ | trunk/DEPRECATED.pod:
[DEPRECATED] Array PMC is on its way out
 08:55
ttbot Parrot trunk/ r42565 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/147227.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 08:59
Parrot trunk/ r42566 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/147257.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 09:06
09:11 mikehh joined, xenoterracide joined 09:26 sri joined, xenoterracide joined
dalek tracwiki: v9 | Austin_Hastings++ | Migrating%20to%20NQPrx 09:30
tracwiki: Default parameter initialization
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
09:39 xenoterracide joined 09:42 xenoterracide joined 09:48 xenoterracide joined
dalek TT #1308 created by Austin_Hastings++: NQPrx does not vivify globals in all cases 10:15
tracwiki: v10 | Austin_Hastings++ | Migrating%20to%20NQPrx 10:17
tracwiki: Global viv, tt#1308</a>
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
10:58 theory joined 11:15 lucian joined 11:22 cconstantine joined 11:52 sri_ joined 12:07 cconstantine joined
dalek nie: r90 | isop44++ | trunk/ (6 files):
Add 'type' type as a functor with a nice string representation. Make the 'str'

instances of the 'type' objects yet.)		 12:10
12:29 payload joined 12:37 fperrad joined 13:09 whiteknight joined 13:15 tetragon joined 13:18 bluescreen joined
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. :|
(if we manually rejected yours please retry. =-)
parrot-users-nyc: there was a tricket for this from kid51; consider it an experiment. 13:21
13:24 bluescreen joined
Coke tricket is trac ticket 13:24
13:32 payload joined 13:35 riffraff joined
whiteknight yay! We're creating words 13:39
Coke it's tricket to rock on time. 13:40
which is wrong, but I'm hoping this crowd won't notice. 13:41
dalek a: f30ecdf | fperrad++ | (4 files):
replace deprecated PMC Array
 13:42
13:45 fperrad joined
lucian what kind of gc does parrot have? 13:47
13:48 payload joined
moritz mark-and-sweep stop-the-world 13:48
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?
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
Coke (most languages targetting parrot don't provide explicit memory management, do they?)
lucian whiteknight: right, ok
whiteknight we'll, that's not entirely true because there can be C extensions, but it's generally a small problem
Coke pmichaud: ping.
(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
moritz whiteknight and others having been working on cleaning up the GC interface, so that it's easier to write other GCs
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
(as far as I understand it; I'm not really a core parrot hacker)
better GCs are on our wishlist though
whiteknight the C issue really isn't a problem, it just means we need to do a stackwalk 13:53
and we've been doing that forever
lucian does it use libffi for the C calling?
whiteknight GC is really quite simple in that there is a relatively small interface that it must satisfy 13:54
lucian: no, we don't use libffi
The big problem in GC is finding a good algorithm that can deal with a huge volume of data reliably and quickly
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?
PerlJam "mostly reliable"? Isn't that an oxymoron? :)
whiteknight mostly not :)
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.
whiteknight yes, there are lots of other gcs ti look at
lucian PerlJam: it is VERY fast, since it's compiled to C code 13:57
moritz PerlJam: why not?
lucian PerlJam: well, some of them are, they have several
whiteknight yeah, I would expect the PyPy collector to be fast
PerlJam moritz: because python, in general, tends to be slow across the board.
maybe I just haven't paid enough attention to python though
whiteknight PerlJam: Think about the speed difference between NQP and pure Perl6 13:58
moritz PerlJam: I think they're working on changing that :-)
lucian preflex: it's actually RPython, which gets compiled to C/.NET/JVM
whiteknight a Python language subset could be very fast
PerlJam So ... we need to write a GC in NQP then. :)
whiteknight in a GC, you're dealing with huge volumes of data. Execution speed is usually dwarfed by algorithmic complexity
PerlJam: If an NQP collector could reduce algorithmic complexity, it would be an improvement 13:59
lucian is the GC written in C or PIR ? 14:00
whiteknight C
check out the repo, src/gc/*
lucian whiteknight: ok. what's the status of the JIT?
whiteknight lucian: in planning
we've got a lot of plans laid, and details to figure out
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
whiteknight a *big
* burden
lucian whiteknight: for example with python's psyco2 jit, pure python map() is faster than the C version
and what are the plans for the JIT, if i'm not imposing 14:02
whiteknight lucian: I don't doubt that
we're planning to use LLVM as the JIT engine
lucian whiteknight: to generate LLVM IR? or to use LLVM's C++ API directly?
whiteknight We're going to develop a minimalist language, Lorito, that will be trivially easy to convert to LLVM opcodes at compile time
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
lucian wouldn't the extra pass increase jit warmup time a lot?
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
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
moritz lucian: and only the built-in ops would go through lorito, and do that at the time when you compile parrot
lucian moritz: couldn't you reimplement those ops in a lower level PIR?
whiteknight JITing PIR code is just a matter of assembly the JITted ops into larger functions or traces
lucian and them just have a jit for that
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 :-)
lucian oh, right. sorry :)
moritz no problem
lucian so will this be a tracing jit? or just a copy&paste jit?\\
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)
whiteknight allison: agreed. We would be foolish not to use tracing eventually 14:07
but to start, we can be a little bit more naive
lucian from what i've heard and read, it's hard to implement tracing on top of llvm
because it's hard to patch functions, you usually have to recompile 14:08
whiteknight with proper tracing you wouldn't patch anyway
allison lucian: aye, LLVM's jit is quite static
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
a good PIC system would provide a callsite caching mechanism that wouldn't require recompilation anyway
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
have you talked to other people that are implementing JITs nowadays? 14:11
whiteknight there has been some talk, I think, yes
allison yup, talked with the JVM folks, and the LLVM folks, and the unladen swallow folks
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.
lucian i don't think i have the links, there was a very interesting paper on a tracing jit by the PyPy folks
moritz trac.parrot.org/parrot/wiki/JITRewrite btw
allison ah, yeah, I talked with them at PyCon last year
there's been some interesting work on tracing JIT's for javascript lately 14:13
lucian i think this is it codespeak.net/svn/pypy/extradoc/tal...-final.pdf
whiteknight JavaScript is really the driving force in the world of Jit right now, I think
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
lucian allison: since PyPy works by generating VMs with JIT from an interpreter written in RPython, it's a different approach 14:15
they're tracing the interpreter itself, not the app-level code
allison lucian: we'd be doing something similar, with Lorito->PIR
lucian allison: yeah, have a chat with them :) 14:16
allison lucian: (ideally at both levels, interpreter and app)
lucian afaik, they're not jitting app code
14:17 lucian joined
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
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:22
Coke adds trac milestones for 2.1-2.5 14:23
whiteknight lucian: you interested in getting involved? We've obviously got some large projects on the horizon and need lots of helping hands :) 14:28
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.
lucian whiteknight: so i am interested in getting involved, but i may not be able to
whiteknight well, if you see any other interested papers or projects, please send a note our way
Coke any deprecation tickets that are to removed "just after 2.0" should be migrated to the 2.1 milestone.
lucian there are soo many interesting projects i'd like to contribute to
and then almost as many i'd like to start 14:30
whiteknight lucian: tell me about it!
purl Let's not and say we did.
PerlJam lucian: you could work on pynie :)
(that'll "improve python" :)
lucian PerlJam: i intend to look into that, actually
PerlJam: not that i have anything against other languages, but python is what i use most 14:31
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 :)
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?
whiteknight Coke: depends on the segfault 14:34
Coke (or at least, very high priority to fix before the next release.)
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
PerlJam Coke: I'll note that Perl 5 could still be made to segfault even after release
Coke ... whee, segfaults good.
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)
whiteknight we'd never release again
PerlJam whiteknight++ indeed
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.
Coke ...20 14:38
dalek TT #1002 closed by coke++: Building PGE dies with segfault when JIT enabled under Fedora 11 14:41
Coke (never release) certainly not with a segfault. =-) 14:48
I'm just looking for a general concensus, not 100% certainty.
whiteknight Coke: you have a list of tickets involving segfaults? 14:49
Coke whiteknight: trac -> tickets -> search -> summary contains segfault 14:50
or:
trac.parrot.org/parrot/query?statu...r=priority
parrot segfaults are trac.parrot.org/parrot/query?statu...r=priority 14:51
whiteknight Coke: Ticket #771, can I get a complete backtrace and the complete PIR output of the example? 14:54
Coke 771? 14:55
776?
whiteknight 776
sorry
Coke what do you mean, PIR output? 14:56
whiteknight the Tcl compiler generates something that is then input into Parrot
I want to see that something
Coke (tcl doesn't generate a single PIR file to run, heavily relies on the runtime and the PIR compiler.)
whiteknight I can't do anything with the Tcl source
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?
Coke no. I'm saying it's not "here's the PIR output".
whiteknight whatever we call it. I need to see it
Coke I could run it with -D60 and send you a zip file with several hundred EVAL files.
... 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
Coke whiteknight: I understand that small PIR snippets help diagnose the problem.
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.
at least not without a LOT of work on my part to remove the partcl bits.
I'm doing that as time permits on these tickets, but it is non trivial.
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.
whiteknight ok
Is there any way to access the small bit of PIR code that's being executed at the time of the segfault? 15:01
no, wait 15:02
are you calling the PIR compreg?
Coke pretty much constantly.
whiteknight then the complete PIR code being compiled is going to be somewhere in the backtrace
so I need the complete backtrace
Coke no. it's going to be in several thousand chunks.
(complete backtrace) that, sure.
that's easy to generate because I can use tcl as is. 15:03
or would be if I had that particular branch lying about.
15:06 Zak joined
Coke that branch no longer compiles against 1.8.0, so this will take some work. 15:07
In the meantime, there are several other current segfaults with full back traces. =-) 15:08
15:08 bubaflub joined
Coke stealing ticket, leaving todo note. 15:08
(will give it back to you when I have a backtrace) 15:09
15:09 masak joined 15:12 Psyche^ joined
whiteknight Coke: okay. 15:15
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
if you can get a dump of that particular value it would be a huge help
15:16 john_ joined
Coke (adding that note to the ticket would be very helpful. =-) 15:17
whiteknight okay
john_ Hi. I didn't see Perl 5 listed among the Parrot-hosted languages at www.parrot.org/languages . Are there any plans in the works for it to be added?
nopaste "coke" at 72.228.52.192 pasted "example of compreg usage." (14 lines) at nopaste.snit.ch/18748 15:21
whiteknight john_: see blizkost
github.com/jnthn/blizkost
john_ whiteknight: Thank you. Yes, I was just looking there. 15:22
I suppose any solution here is going to be pretty ambitious.
whiteknight it isn't a Perl5 compiler by itself, it's basically impossible to make a new Compiler for perl5
not "impossible", but yes, ambitous 15:23
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
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:25
whiteknight exactly 15:27
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
john_: both
the spec really is "whatever the perl binary does"
moritz john_: and (3) because XS is really tied to the internals of the perl5 compiler
whiteknight so it's a moving target that we can't ever faithfully reproduce
NotFound john_: that differentiation is purely synactic.
whiteknight moritz: ah, yes
john_ CE-Perl ("Close Enough Perl")? ;) 15:29
NotFound The lack of official spec is the idiosincracy.
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".
NotFound john_: the problem is that the special cases is the full CPAN. 15:32
Or even the darkpan :D
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
NotFound: re. "enough", I see what you mean. Getting 80% may be doable, but everyone wants a different 80%.
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. :)
pmichaud partcl?
purl well, partcl is tcl on parrot or code.google.com/p/partcl
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. =-)
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?
Coke I think it was you, anyway. I had meant to comment on the blog but saw it on my phone while on vacation.
john_ NotFound: or are there not as many special cases as with Perl 5?
Coke john_: note that XS is an issue. (not everything is done "in perl")
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:37
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? =-)
whiteknight: note that after pmichaud gets done, hopefully we can avoid a lot of the interactive compiling. =-)
pmichaud Coke: was just looking for the grammar to start playing with a bit 15:40
I think I need to read a quick tutorial on tcl
john_ Coke: Right, right, ... forgot ... moritz mentioned that. I see.
whiteknight Coke: (Re: stacks) you 15:42
NotFound And last but not least, Camelia is more smiling and friendly that the dusty camel ;)
whiteknight 're right, it wasn't "stack based"
I should clarify
Coke pmichaud: www.tcl.tk/man/tcl/tutorial/Tcl1.html perhaps? 15:43
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
partcl is more of an interpreter than a compiler, yes ?
Coke yes.
pmichaud should it remain that way?
(I think "yes")
Coke we can't compile the whole program in one go, no. 15:45
(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...)
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. :) ).
Coke we do need to fix it so that the bits we're interpreting are as small as possible. (like, each command/subcommandD)
(no parrot based perl 5) see also "ponie" 15:46
I think there's a postmortem on that somewhere.
NotFound john_: I think blitzkhost has a short explanation.
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.
(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
john_ NotFound: I don't see a docs dir in the blizkost distribution.
Coke: Where might I find such a post-mortem?
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.
Coke john_: that's because it's dead.
(some 4 or 5 years now.)
google for ponie parrot
john_ Coke: en.wikipedia.org/wiki/Ponie thanks. 15:49
Coke wow, only 3 years gone. =-)
pmichaud wonders how evil it would be to modify the string being parsed during the parse itself. 15:52
is that essentially how tcl works -- repeated substring substitutions? 15:53
Coke i confess to not knowing how the real tcl works internally.
pmichaud well, even theoretically? 15:54
diakopter pmichaud: tee hee;
Coke we need to keep the original code around for backtraces, introspection, etc., though.
diakopter it's just like adding more pp steps
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
15:55 john_ left
Coke ... basically, yes. 15:56
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.
... 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]" ?
is that the same as "puts abc7" ?
Coke yup
pmichaud if the [...] returns a result containing spaces, those get treated as separate words by the "caller"?
Coke no. 15:58
(pretty sure, checking.)
% puts abc[string repeat " " 3]bca
abc bca
as opposed to:
% puts abc bca
can not find channel named "abc"
pmichaud so, a command gets broken up into its words before the substitutions take place? 15:59
ah, item [12] in the syntax list says yes 16:00
Coke ... I was just about to point to that, yes.
=-) 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...)
does the definition of a builtin affect the parsing of the command at all? 16:02
or just the execution?
Coke not parsing, just e... right.
you can't dynamically change the parser.
pmichaud okay, excellent.
16:02 Andy_ joined
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.
see github.com/partcl/partcl/blob/maste...atch.t#L80 16:04
pmichaud okay, noted
how does partcl currently store/process new commands? 16:05
Coke new commands are implemented with [proc] (runtime/commands/proc.pir) 16:06
basically, comile the given tcl into PIR, compile it, shove some metadata into the .Sub, and stick it into the appropriate namespaces. 16:07
s/ces//
(er, singular NS)
subs in namespaces have a leading '&', so proc is really in parrot's ['tcl'; '&proc']
pmichaud okay, so for this we really do want compilation to PIR then 16:08
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
Coke if we had an AST, sure. =-)
(right now we might be able to save the TGE tree when we were done...) 16:10
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
I guess "compile to PIR" is ultimately more interesting/useful.
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
so in that case, keeping the ast doesn't help us.
pmichaud well, if the ast simply represents calls to operations but doesn't bind to specific subs, it's not too bad. 16:13
basically the ast avoids a re-parse
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".
ah, I was expecting the ast to be more clever for builtins.
pmichaud ah, I see.
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.
Coke right.
pmichaud (if we decide that's important :)
Coke yah, want to see how the initial conversion impacts speed.
I suspect converting the flow control builtins will give us the biggest bang if there's any bang to be had. 16:15
pmichaud (thinking) 16:18
Coke (another thing protoregexes will help with: dynamically adding math functions to expr's syntax.) 16:19
(doesn't work at all currently.)
pmichaud yes, protoregexes are a huge help for that. 16:20
(reading about upvar and variable scope) 16:21
Coke I do that now by having a handrolled var context stack.
(moving to parrot's wouldn't help at the moment, I think, because of [uplevel] requirements) 16:22
runtime/variables.pir is rather ugly.
pmichaud upvar is dynamic scoped, not lexical, yes?
or.... hmmm. 16:23
Coke upvar is based on caller scope, yes.
pmichaud yeah, parrot's 'lexicals' don't really help much there then, since they're static scoped 16:24
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"
but i suspect that runtime/variables.pir can survive the translation to nqprx. 16:26
... not that i want it to.
pmichaud So, each tcl subroutine can have a "LEXPAD" (parrot) lexical that is a hash containing the lexpad that contains the dynamic lexicals
then we don't need a parallel context stack
Coke how would that handle recursion?
pmichaud each subroutine invocation gets its own "LEXPAD" 16:27
Coke ... where is that stored?
pmichaud in the context
Coke k.
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
so each subroutine invocation ends up with its own LEXPAD, that we can easily find by following the caller contexts
(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.
(and yes, skip levels that didn't have that as we went through.)
sounds like we're on the same page.
pmichaud I think this is essentially the same, except we don't need to use the DynLexPad PMC :)
(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.
(maybe)
pmichaud that's a reasonable point
dalek nxed: r177 | julian.notfound++ | trunk/ (2 files):
new operator '%%' (cmod), suggested by PacoLinux++
Coke but "working" is a good first step. =-)
I'll jump off the hll interop bridge when we get there.
pmichaud okay, last question for a bit. Think there would be much value to only generating PIR for proc definitions? 16:32
and have all other commands be "immediate evaluation" without going through PIR ?
Coke I don't understand. 16:35
(more)
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
is that what you mean?
pmichaud I think so. 16:37
Coke then sure.
=-)
pmichaud Essentially I'm thinking that the only time we might need to generate PIR is when evaluating a proc command
in which case we're making a stored procedure
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)
Coke ok. there are a few other things, like [namespace eval {...}] and [rename], but we can deal with those as we get to them.
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"
and proc simply invokes the part that says "generate PIR"
okay, this is all hugely interesting and helpful
Coke seems reasonable on paper.
pmichaud so, here's my plan for the moment 16:39
first, I need to take a walk to digest these details
Coke heh.
step two: ...
step 3?
purl step 3 is PROFIT! or "Get your girl to open that box" or www.step3profit.com/
pmichaud then, I think I'll briefly start a new git repo to see what I can do with nqp
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
(but if there's too much cruft in there, anywhere is fine.)
pmichaud will do. my first attempt has a good chance of being a throwaway
if it's not a throwaway, we can just move my repo to the partcl account on github as a separate repo 16:41
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
we'll see -- I just need to start something to see how it kind of falls out
what kinds of substitutions are allowed in double-quoted strings? 16:43
just $-vars, or [-substitutions also?
Coke both. (there's a list....)
pmichaud okay, I see the example with [-substitution now 16:44
so, it's like a Perl 6 closure interpolation
Coke see the list of 12 rules, #4.
command, variable, backslash.
pmichaud right
just like Perl 6 :)
Coke easy peasy.
(I knew larry was copying jon!) 16:45
pmichaud (and NQP itself, fwiw)
I'm glad I'm doing this *after* having done NQP and Rakudo in the new protoregex world :)
this looks like fun 16:46
is the first part of a command a "word" also? 16:48
i.e., can one do something like
set foo puts; $foo abc
looks like "yes"
redbrain_ anyone else use git-svn for parrot? 16:57
whiteknight redrain_: I tried once, no likey
bubaflub redbrain_: yes 16:59
not very successfully, but yes. i know dukeleto may use it as well 17:00
dalek TT #541 closed by whiteknight++: r37927 segfaults on building lua 17:03
Coke pmichaud: yes. 17:05
redbrain_ yeah its taking like ages to clone lol
its going to be very painful to move from svn to git i think since there is so much history 17:06
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
lol
stilll on r18*** 17:09
still*
dukeleto 'ello 17:11
redbrain_: we have a git-svn tarball
git-svn? 17:12
purl git-svn is amazingly great or trac.parrot.org/parrot/wiki/git-svn-tutorial
dukeleto trac is painfully slow right now 17:13
technosorcery.net/system/parrot-git-svn.tbz 17:14
dalek tracwiki: v19 | dukeleto++ | git-svn-tutorial 17:15
tracwiki: trac.parrot.org/parrot/wiki/git-sv...ction=diff
17:25 lucian joined 17:33 iblechbot joined
dalek tracwiki: v11 | japhb++ | Migrating%20to%20NQPrx 17:35
tracwiki: Add notes about closure interpolation and whitespace/paren issues
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
tracwiki: v12 | japhb++ | Migrating%20to%20NQPrx
tracwiki: Minor prose improvement
tracwiki: trac.parrot.org/parrot/wiki/Migrat...ction=diff
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
beyond NQP = Not Quite Perl
cotto_work nqp? 17:40
purl nqp is not quite perl (6) or svn.perl.org/parrot/trunk/compilers/nqp
cotto_work That's not terribly useful.
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. =-)
cotto_work but not us
diakopter purl, no, nqp is github.com/perl6/nqp-rx 17:42
purl okay, diakopter.
diakopter nqp?
purl nqp is github.com/perl6/nqp-rx
Coke botcheck?
diakopter (the README that appears inline that page is thorough)
bubaflub ah, righteous.
diakopter purl, nqp is also (see the README on that <-- url) 17:44
purl, nqp is also "(see the README on that <-- url)"
purl, nqp is also see the README on that <-- url
nqp is also see the README on that <-- url
sigh
purl, die in a grease fire
purl diakopter: what?
diakopter exactly.
cotto_work nqp? 17:45
purl well, nqp is github.com/perl6/nqp-rx
diakopter purl: nqp is also see the README on that <-- url
cotto_work unbotsnack
purl thanks cotto_work :)
cotto_work you're not welcome
diakopter :)
bubaflub another random question: what's the motivation for not using a cuddled else 17:47
Coke bubaflub: I think that was chip's preference and no one cared enough to argue. 17:48
bubaflub ok, good enough for me 17:49
Coke (now enshrined in, what, pdd07?)
bubaflub just wondering
purl just wondering is the interpreter itself makes any distinction
Coke no, just wondering is <reply>The answer is no.
purl okay, Coke.
whiteknight any standard improves readability so long as it is followed consistently 17:52
And arguably we can't always cuddle teh else, so it's better to never do it
17:53 japhb joined
cotto_work Plus Klingons know that a true warrior doesn't cuddle his elses...he dead-grips them. 17:54
bubaflub hahaha
yeah, i saw the coding standard and was just wonderin'
i've seen about an even split in code / textbooks between the else style
whiteknight yeah 17:55
Parrot's code is relatively clean and nice-looking because of all the consistently-followed standards
some I disagree with, but whatever
bubaflub the no extra whitespace at the end of a line got me a few times 17:56
17:56 Dex joined
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:56
bubaflub yeah, i think i might have a git option somewhere... 17:57
now i just run prove -v t/codingstd/* before submitting any patches
on top of the regular tests
Coke bubaflub: also, "make codetest" 17:58
bubaflub doh!
cotto_work now you know 17:59
purl And knowing is half the battle.
whiteknight purl++ 18:01
dukeleto bubaflub: hola! 18:06
bubaflub good $localtime, dukeleto
i think it's still morning for ya on the west coast
dukeleto bubaflub: yep 18:07
bubaflub: what are you working on? 18:13
bubaflub left-over Chinese from yesterday
but seriously, not a whole lot at the moment
Tene whiteknight: ping 18:14
whiteknight: I tried my cross-hll problem again with latest parrot. it now fails regardless of GC.
bubaflub dukeleto: got something for me to hack away on? 18:15
whiteknight Tene: okay
Tene: could you provide a step-by-step guide to reproduce it?
I don't have Rakudo or Steme installed at the moment, so I need to do that
Tene whiteknight: the current instructions on the ticket work. it fails differently, though. 18:16
whiteknight ok
nopaste "tene" at 97.117.56.150 pasted "failure for whiteknight++" (22 lines) at nopaste.snit.ch/18750 18:17
Tene AFK, teaching. Will talk again later.
dukeleto bubaflub: of course! 18:19
bubaflub: how masochistic are you feeling?
18:20 mokurai joined
bubaflub hmmmm.... particularly today 18:20
18:22 chromatic joined
Coke why is parrot-tickets trying to post to parrot-dev? 18:23
(e.g. on #744. I have an admin request holding that on parrot-dev)
aha. please don't have tickets cc the dev list. :| 18:24
dukeleto bubaflub: want to hack on parrot in postgres?
bubaflub hoo boy sure
i just got my postgres installation fixed last night
just so happens.
dukeleto bubaflub: which version of postgres? 18:27
bubaflub 8.4.1
Coke anyone care if I turn off require_explicit_destination for parrot-dev?
whiteknight what does that do?
Coke right now it's blocking parrot-tickets from auto-posting to the -dev list when cc'd there.
forcing me to admin approve every message from trac to parrot-dev 18:28
(normally it block someone from bcc'ing parrot-dev)
dukeleto Coke: i think that is fine. 18:29
Coke: we don't want to bury you in approval emails
18:29 ttbot joined
dukeleto bubaflub: you have a commit bit now: github.com/leto/plparrot 18:30
bubaflub: read HOWTO to get it working
bubaflub: there are tests!
bubaflub huzzah
clonin' now
dukeleto bubaflub: we don't have any type of proper config or build stage.
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"
bubaflub: we need a proper test harness
bubaflub are we assuming that'll be in the path? or should we have that supplied by commandline?
dukeleto bubaflub: test harness will be nqptap shelling out to psql to run .sql files 18:32
bubaflub: just assume that pg_config is in the path
bubaflub: first feature: bail if pg_config cannot be found
bubaflub ok
dukeleto bubaflub: you can tweak the Configure.nqp that exists already, or start fresh. whatever works 18:33
bubaflub okey dokey.
i'll see if i can get this setup
dukeleto bubaflub: some stuff is hardcoded, you will have to change them to your paths :) patches welcom!
welcome, even
bubaflub ah, cool 18:34
dukeleto bubaflub: feel free to commit to master unless you are really setting things on fire
bubaflub hahaha
burn this mo down
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:35
bubaflub: make sure to read IDEAS as well 18:36
Coke (email) fixed, you can cc the dev list with impunity. 18:39
(but please have some punity.)
dukeleto lost his punity 18:40
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
... Oh, I can just change the summary.
whiteknight yeah, just change it
18:55 joeri joined
Tene Updated ticket. 18:59
Oh, huh, steme fails even trying to import from itself, without rakudo. 19:02
lucian is this in any way interesting to you guys? doc.cat-v.org/inferno/concurrent_gc/ 19:04
dukeleto lucian: hello 19:12
purl hola, dukeleto.
Tene whiteknight: I found it. 19:14
whiteknight found what? 19:15
Tene whiteknight: .param 4pmc has_hll 4:opt_flag
whiteknight: that's what was causing the assert fail I was seeing.
whiteknight oh wow
something like that should really be caught
Tene IMO, should just be boxed.
whiteknight in ether case, we need to account for it 19:16
Coke tene: what about .param string foo :opt_floag ?
s/oa/a/
NotFound The doc says that :opt_flag must be int.
Coke WFM.
whiteknight WFM? 19:17
purl i guess WFM is works for me (for lazy folks)
Tene WFMT
chromatic If I had a syntax test for IMCC, I could make that into a syntax error.
Tene fixing it, I now get a different error elsewhere...
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
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
dukeleto: it does seem incremental, so should be real-timeable
Coke chromatic: adding a failing test to PIR based code sucks.
cotto_work The Inferno Mutator is way less awesome than the name implies. 19:20
chromatic pir_error_output_is....
nopaste "coke" at 72.228.52.192 pasted "shows the error" (9 lines) at nopaste.snit.ch/18751
19:20 fperrad joined
Coke chromatic: that's a PIR sub? 19:20
(I thought that was perl only)
chromatic Hm, good point. 19:21
I thought someone added throws_ok to PIR though. 19:22
dukeleto Coke: use throws_like()
lucian: have you worked on the GC subsystem before?
Coke dukeleto: and then also make it a todo. PITA, currently. 19:23
Tene: tt #?
lucian dukeleto: not on anything serious, i'm probably not the right person to do something like this
Tene Coke: for what?
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
Tene ;) 19:25
Coke the :opt_flag issue?
dalek kudo: c00de9d | tene++ | perl6.pir:
Look up %INC in the right namespace when loading libraries for foreign languages
Coke (or the ticket that spawned it)
#744 ? 19:26
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:27
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
Coke: So, not appropriate to track in #744, which I just closed.
Coke if you open a new ticket, I'll commit this test. =-)
dalek TT #744 closed by tene++: Assertion Failure with steme and rakudo
Tene Man, you're as bad about this as my boss is, always harassing me to open tickets... :P 19:29
Coke <- harasser.
hey, I wrote the test for you!
dalek rrot: r42567 | fperrad++ | trunk/t/library/mt19937ar.t:
[mt19937] convert test in PIR (from �github.com/fperrad/parrot-MT19937)
 19:30
Tene Coke: Sorry, AFK lunch right now. ;)
Coke ok. I'll leave the old ticket number for now and you can fix it. =-)
chromatic: incoming. 19:31
purl duck!
Coke quack. 19:32
Coke wonders when he started using "joe" as a foo/bar/baz. 19:33
dalek rrot: r42568 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[languages] remove t/harness (now use prove)
rrot: r42569 | coke++ | trunk/t/compilers/imcc/syn/regressions.t:
Add test for a bug discovered by Tene++
Coke ah, from "joey bag o' donuts", prolly.
dukeleto Coke: My Cousin Vinny! 19:34
Coke I'm pretty sure we're not related, no.
Coke wishes to own that movie. 19:36
ttbot Parrot trunk/ r42567 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/147377.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 19:37
Coke ttbot, that's old.
(ah. last one from client 8, so that's ok still) 19:38
client #8 is slow!
chromatic: did you ever export the STRINGNULL?
(mswin32 seems to not be able to find it at link time.) 19:39
chromatic I did.
moritz are parrot-ticket mails suddenly fowarded to parrot-dev? 19:40
chromatic Is that failure in parrot_debugger?
Coke why yes it is.
moritz I didn't subscribe parrot-tickets, but I suddenly get those trac mails
Coke moritz: that's because someone cc'd the list.
(the -dev list)
moritz Coke: ok, thanks
Coke if you look at the cc' for that ticket...
(took me a minute before, too.)
chromatic: figuring a test in perl is better than no test in pir, I dumped it into the catchall 'regressions' test file. 19:41
chromatic Thanks! 19:42
ttbot Parrot trunk/ r42569 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/147404.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 19:44
Coke chromatic: shouldn't it be PARROT_EXPORT STRING *STRINGNULL; 19:45
?
chromatic I'm not sure we want to export something to which other people can assign though. 19:46
External code should prefer the STRING_is_null() function.
19:46 bubaflub left
Coke er, PARROT_DATA 19:47
(PARROT_DATA is used on PMCNULL)
seems to just do an 'extern "C"' or equivalent when necessary. 19:48
makes sense that would bother msvc
19:51 Austin joined 19:52 bacek joined
Coke (there's a PARROT_DATA on include/parrot/interpreter.h but not src/string/api.c ; could that be the issue? 19:55
... doesn't look like src/pmc.c has one for PMCNULL. I have no clue. ah well.
TimToady phone 20:00
20:18 hachi joined 20:20 tetragon joined
Coke ... whoops. 20:25
20:25 PacoLinux joined
nopaste "pmichaud" at 72.181.176.220 pasted "initial playing with tcl" (9 lines) at nopaste.snit.ch/18754 20:28
pmichaud Coke: github.com/pmichaud/pmtcl # yes, it's over-simplified at the moment 20:29
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
Coke pmichaud++ 20:38
20:41 hercynium joined 20:57 payload joined
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
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.
Coke message in a bottle 21:12
purl Message for in stored.
Coke </sting>
whiteknight good job, Coke. Confusing the bot
Coke 16:12 <+purl> Message for in stored. 21:15
... well, that's something, anyway. =-)
cotto_work Won't in be surprised when he logs in and purl presents him with a bottle. 21:16
chromatic He shouldn't be surprised. purl watches every breath he takes. 21:17
nopaste "pmichaud" at 72.181.176.220 pasted "tcl command substitution in middle of word" (19 lines) at nopaste.snit.ch/18756 21:18
Coke pmichaud: I watch eagerly as you re-do the first 4 years of partcl development in a week. =-) 21:19
(oh, hey, I'll get annotations for free. bonus.)
(that will let me make the backtraces more tcl like)
nopaste "pmichaud" at 72.181.176.220 pasted "tcl nested command substitutions" (13 lines) at nopaste.snit.ch/18757 21:20
21:21 mokurai joined
Coke I remember having to parse all this crap with handrolled PIR because it predated PGE. =-) 21:21
. o O (uphill both ways)
pmichaud
.oO( in the snow )
.oO( without a jacket )
 21:22
Coke I wonder if the original p5 based "compiler" still exists anywhere.
particle
.oO( square wheels )
NotFound Coke: Internet Archives is watching you.
pmichaud "You had wheels?!" 21:23
"In my day, we had to walk with cement blocks strapped to our feet. And we liked it!"
particle can braced word use ~ ?
token braced_word { '{' $<val>=[<-[}]>*] '}' }
NotFound pmichaud: sounds like programming in Cobol. 21:24
particle could that use '{' ~ '}' or does that require balancing?
pmichaud I don't think it requires balancing. 21:28
I suppose it could use ~; hadn't tried it.
GeJ Good morning everyone. 21:29
21:30 mokurai left
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.
lucian purl: msg whiteknight yeah, it's one of the few GC strategies i've seen that are real-time capable
purl Message for whiteknight stored.
lucian purl: thank you
purl: thanks 21:33
purl: botsnack
purl :)
21:34 hercynium joined 21:36 tetragon joined
nopaste "pmichaud" at 72.181.176.220 pasted "even more tcl fun -- simple variables" (12 lines) at nopaste.snit.ch/18758 21:51
dalek a: a233d99 | fperrad++ | (2 files):
remove staging
 22:28
nopaste "pmichaud" at 72.181.176.220 pasted "okay, now I'm just showing off a bit. :-)" (7 lines) at nopaste.snit.ch/18759 22:32
PerlJam pmichaud: gah! Wasting time on tcl instead of improving rakudo? For shame. 22:41
;-)
pmichaud++ for showing off anyway. :) 22:42
dukeleto 'ello 22:43
message purl will this make you go boom? 22:46
purl Message for purl stored.
Tene pmichaud: persistent lexicals, or are tcl vars not lexical? 22:49
22:53 cconstantine joined 22:58 Whiteknight joined
pmichaud Tene: cheating lexicals 23:09
right now pmtcl just stores all variables in a shared hash 23:10
(so they end up being persistent)
parrot's default lexicals aren't sufficient for tcl anyway 23:11
23:16 zak_ joined
dalek nxed: r178 | julian.notfound++ | trunk/ (2 files):
add '<=' and '>=' operators and refector '<' and '>'
 23:17
23:24 kiwichris joined 23:27 darbelo joined
mikehh All tests PASS (pre/post-config, smoke (#30019), fulltest) at r42559 - Ubuntu 9.10 amd64 (gcc with --optimize) 23:29
dukeleto mikehh++ 23:31
Whiteknight dukeleto: does nqpTAP work on old NQP, or NQP-RX? 23:36
dalek nxed: r179 | julian.notfound++ | trunk/examples/parser.winxed:
start implementing local int vars in example parser
 23:37
dukeleto Whiteknight: nqptap is the new nqp-rx
Whiteknight awesome
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--
dukeleto Whiteknight: the test harness in plumage (which nqptap came from) was converted to nqp-rx a few weeks ago
Whiteknight dukeleto: same here.
dalek rrot: r42570 | darbelo++ | trunk/src/parrot_debugger.c:
Use function version of STRING_is_null() in the debugger to make MSVC happy.
 23:39
darbelo Okay, that should shut up ttbot for a few hours. 23:40
dalek rrot: r42571 | chromatic++ | trunk/src/string/encoding.c:
[string] Initialized the encoding pointer variables, in the hopes that they

initialization. Hopefully this initialization won't upset picky C++ compilers.		 23:42
dukeleto MSVC-- 23:45
karma MSVC
purl msvc has karma of 136
dukeleto !
darbelo MSVC--
chromatic It must have wrapped around from zero.
dukeleto chromatic: lulz 23:46
cotto_work must be from people referring to the c plus plus compiler
darbelo c++--
cotto_work karma msvc++
purl msvc++ has karma of -1
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--
darbelo karma msvc 23:47
purl msvc has karma of 131
Austin So what's wrong with msvc?
dukeleto Austin: the first 2 letters
cotto_work dukeleto, only one per line ;)
chromatic The C part of it.
dukeleto cotto_work: ug
darbelo <purl-->
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.
chromatic Yeah, what was with that hybrid kid in the last episode of the original miniseries? Bizarre ending.
darbelo Wasn't that the hook for the TV series? 23:49
23:49 kid51 joined
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.
Austin Who has a MSVC build environment set up? And have you written a wiki page detailing all the ingredients?
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.
japhb: New series? 23:52
purl well, New series is quite good
Austin darbelo: V.
japhb darbelo, There's a V on right now. The alien lead is played by the Companion from Firefly.
darbelo Austin: Hadn't heard about that.
chromatic Alan Tudyk is the alien lead?
japhb LOL
Austin Darbelo: Don't worry. I'm sure it hasn't become a better idea the second time around. 23:53
(But I'll bet the CGI is great.)
chromatic Curse their sudden but inevitable betrayal.
23:53 Zak joined
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.
darbelo Austin: I think the key to a MSVC build was to Configure with ActiveState perl. 23:54
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.
Austin darbelo: Win! and here I sit with a hand full of Strawberries..
darbelo Austin: Those are broken less often. FWIW. 23:56
Austin Everybody and their freaking mother wants to bundle an msys environment...
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.
darbelo Austin: And mixing the strawberrys with MSVC is likely to be poisonous. Do not attempt.
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.)
darbelo My only exposure to windows programming happened years ago. With MFC.
I haven't left unix since.
Austin japhb: It ain't easy being a climax species.
japhb I learned undiluted raw COM. I went stark raving sane.
Tene I did some windows programming back in, like, 2003 I think? 2002? 23:59
I have painful memories, but not detailed memories.

Powered by Cro and the Raku® Programming Language.

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

Thank you!