Parrot 1.6.0 "half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 12 October 2009.
Whiteknight dukeleto: intention has nothing to do with it. We don't care why it's abandoned, we only care that it is 00:00
jonathan And one of those "we'll regret it later" things.
darbelo dukeleto: and then we put it back on the list. historical++
Whiteknight we can mark it as un-abandoned when it picks up again
dukeleto Whiteknight: touche
chromatic My optimization principle: if we really have a register machine and not a half-assed stack machine, why can't we take advantage of what register machines do best: not copying lots of memory around for every call or return.
Whiteknight jonathan: it removes an unnecessary extra step 00:01
jonathan I'm not saying "omg no never ever do it", but my initial feeling is "huh, that doesn't fit into my mindset of how Parrot works at all"
dukeleto chromatic: that sounds like a good principle
Whiteknight instead of putting args into a CallSignature and then moving args from there into the Context, we can put the args directly into the Context where they need to be
and we can avoid creating unnecessary PMCs
dukeleto Whiteknight: i think projects that require parrot pre-1.0 is a decent working definition of 'abandoned' 00:02
Whiteknight only if the project is not being worked on 00:03
it's not inconceivable that a project is intentionally targetting an older "stable" Parrot
jonathan It may be worth looking into or exploring. It just worries me somehow. Maybe another time, when it's not 2am, I'll be able to come up with good reasons why.
dukeleto Whiteknight: yes, with that caveat as well. i was assuming "hasn't been worked on and requires parrot pre-1.0" 00:04
Whiteknight ok
chromatic I don't see the "separation of concerns" arguments. 00:05
If anything, I think we have too much separation of concerns.
We have the arguments passed stored in one place and information about which arguments we're passing stored in another place.
Whiteknight we certainly won't rush into anything, but unification of some key aspects of the calling hotpath is a necessity eventually
darbelo dukeleto: my andidates from the list are BASIC, c99, eclectus, forth, lisp, Pirate, PJS, regex, scheme
Whiteknight there are plans to merge RetContinuation into Context first though
jonathan chromatic: I thought the CallSignature was meant to hold all details of what was being passed. 00:06
chromatic It is. 00:07
japhb Man, I wish I had enough spare tuits to do a Parrot port of my Perl 5 Forth ...
chromatic The problem is that it doesn't actually contain the storage of what gets passed.
jonathan chromatic: Are you conflating the arguments being passed with their final destination after being bound against a signature? 00:08
I thought a CallSignature directly contained pointers to the PMCs being passed...
chromatic It does.
purl stays quiet
chromatic It contains pointers to *register* locations.
jonathan Erm.
It doesn't contain the actual PMCs? 00:09
chromatic For incoming parameters, it does.
We copy them out of contexts into CallSigs to copy into contexts.
jonathan No, we copy *pointers to them* into...
dukeleto darbelo: are you proposing deleting those langs or just marking them as 'abandoned' on the wiki
chromatic For return parameters, we create pointers to the destination registers, store that in the CallSig, and then fill in those pointers. 00:10
jonathan chromatic: OK, but that's more out of allison's feeling that we must not break PASM compatibility rather than our actual ability to deal with that.
And something we can change within a deprecation cycle, iiuc.
darbelo dukeleto: Moving them into another page (or another table on the same page), so that we can more easily look at the active languages. 00:11
jonathan Or am I missing something?
chromatic I think we can all agree that the current design copies too many things and moves too much memory around.
jonathan (That is, we only create pointers to the destination registers because at the moment set_results comes first.)
chromatic I may be the only one saying that variable-sized register sets was a mistake. 00:12
jonathan Maybe. :-)
I guess what I'm kinda curious about is why CallSignature contains pointers to the actual PMCs - which obviously change per call - rather than register numbers. 00:13
chromatic Ideally, to invoke a sub, we create a continuation, fill in that continuation's registers with the arguments, and invoke the sub.
jonathan Which don't.
And then have the PMC have a positional interface that fetches them.
chromatic The sub rearranges its parameters as it sees fit.
Okay, but here's my question about that. 00:14
jonathan But guts can deal with going straight for the registers and copying to toher registers.
darbelo dukeleto: If somebody ask me "What languages can I run on parrot" I'd like to point them at that page.
chromatic Why do we need to have a PMC-based interface to get/set registers?
jonathan Of course, then your dealings with flattening thingies get fun.
dukeleto darbelo: ok, that sounds good. perhaps just make another table below the current one with abandoned langs?
darbelo dukeleto: Works for me. So nice of you to volunteer! 00:15
jonathan chromatic: I can only guess, because it's felt that is the best way to have and pass around a way of describing the argumetns to a call independent of how the call was made.
darbelo was joking.
jonathan chromatic: And providing a common way to access them.
chromatic I think the problem is this.
darbelo I'll do it as soon as I find out what the heck is wrong with this bloody makefile. 00:16
jonathan chromatic: I'm not entirely sure having that interface available is a bad thing.
chromatic We need to be able to describe the signature at the caller point and the callee point.
Occasionally (MMD) we need to find compatible signatures and convert between them.
The current code appears to want to perform that comparison before invoking a callee. 00:17
jonathan No, not occasionally. Every single Perl 6 operator invocation is MMD.
chromatic Not every PIR call a Rakudo program makes uses MMD.
Not every PIR call an arbitrary program running on Parrot uses MMD.
jonathan Of course, but a substantial number of them are.
chromatic If I'm restating the "our get/set params opcodes appear in the wrong order in bytecode until January" argument, then that's fine. 00:18
jonathan chromatic: Well, I think that we can feel how we want on that, but a decision is made on it.
chromatic Sure, we have a deprecation policy and I think that's reasonable. 00:19
jonathan Sure, I'm just saying it's not really an argument worth having. 00:20
chromatic Of how to redesign the system for efficiency?
I'm not arguing against the deprecation policy.
jonathan Ah, I meant arguging about the get/set params opcode ordering. :-) 00:21
How to be efficeint is of interest. :-)
chromatic That's my concern: efficiency.
jonathan What I'm trying to say is that, as far as I understand it, the pointers-to-registers-for-returns thing is a short-term thing to avoid breaking deprecation policy, that's all. 00:22
chromatic Sure, that's fine.
jonathan So that particular concern has a timeframe for being dealt with.
chromatic I think I can get rid of that.
jonathan We can perhaps even get rid of it now, if we define a new "get_returns" op that IMCC starts emitting for sugared calls. 00:23
chromatic I think the unification of CallSig and Context is important, ultimately though.
Sugared how?
jonathan x = 'foo'(y, z)
Can we compile that to whichever ops we want without breaking depercation policy? 00:24
So long as folks writing PASM can also write the alternate ordering through January?
chromatic It's a change to IMCC, which is doable.
Probably doable.
jonathan I'm not sure how feasible maintaining two approaches is.
You'd know far better than I. 00:25
chromatic I don't know if the PASM/PIR approaches are different in terms of code.
jonathan Sure, but supporting set_returns called before the call creating a CallSignature with pointers that then set registers, and get_returns bidning against a returning call signature instead (so we make both work for a while...) 00:26
pmichaud (MMD) one of the impedance mismatches between what Parrot provides and what Perl 6 / Rakudo needs is the fact that nearly all of Rakudo's operations are MMD based
so most of parrot's claimed gains for doing things with registers and opcodes disappears in the need to be able to do mmd dispatch
chromatic I don't necessarily see how. 00:27
00:28 mikehh joined
jonathan chromatic: $a + $b in Rakudo compiles down to 'infix:+'($a, $b) 00:28
Well, the registers containing $a and $b
chromatic We have to find the appropriate candidate and may have to convert some registers through boxing/unboxing.
jonathan Right. 00:29
chromatic Is there anything else that penalizes registers?
pmichaud sure. But if people are expecting $a + $b in Perl 6 to compile down to an 'add' opcode in Parrot, it's not happening.
jonathan But note that we find the appropriate candidate and *then* invoke it.
Actually the thing is that the add opcode in Parrot probably then may well go and do a second multi-dispatch. 00:30
chromatic I agree with both, but I'm not sure what implications I'm supposed to see here.
nopaste "Whiteknight" at 69.249.176.251 pasted "general approach for fixing tailcalls" (101 lines) at nopaste.snit.ch/18352
jonathan Even though Rakudo already knows it has two Ints.
pmichaud I'm not necessarily making a point, just bringing up another observation.
Many of the things that we think of as promoting efficiency (e.g., int registers) end up being terribly inefficient for rakudo. 00:31
for example, consider $a + 1
we can compile this down to
'infix:+'($a, 1)
or
$P0 = box 1
'infix:+'($a, $P0)
it turns out the latter is more efficient. 00:32
chromatic It shouldn't be, but I agree.
pmichaud especially if $a + 1 is in a loop, and we move the constant generation out of the loop.
so the claimed advantage of integer constants and integer registers kinda disappears.
s/claimed/widely believed/
so, one of the things that PAST will be getting is the ability to have constants created as soon as a sub is entered instead of at the point where they're used. 00:33
(thus moving constant generation out of loops) 00:34
jonathan The only way we can really ever emit "add $I0, $I1, $I2" style stuff is when we (a) determinted from type inference or annotations that everything is an int, (b) know we've no operator overloads that may have effect on this have been made and (c) know that we don't have any lookups of the lexicals by name so we were able to promote them to registers.
pmichaud anyway, I don't have a strong point to make here, other than the observation that the naive expectations about calling efficiency seem to not apply
jonathan That's quite a lot of analysis.
pmichaud ....and that the integers don't become bigints. 00:35
chromatic I'm not making any claims about the advantage of primitive registers over PMC registers.
jonathan pmichaud: no, that's one thing we *don't* have to worry about here. :-)
pmichaud: lowercase int is spec'd as "CPU register int"
For Int, though, yes, for sure that's also an issue.
Whiteknight the types of the registers don't matter, what matters is reducing the number of copies betweehn them 00:36
pmichaud anyway, I'll depart now (dinner). Sorry if I derailed a conversation.
chromatic Exactly. If managing *all* kinds of registers is inefficient, it doesn't matter if you use primitives or PMCs.
pmichaud I guess I just wanted to confirm jonathan's comment that MMD is far more common than "occasional", at least for Rakudo. 00:37
chromatic Okay, but if managing *all* kinds of registers is inefficient, it doesn't matter if you use MMD or not.
Whiteknight so instead of copying args from the CallSignature to the Context, we dump them into a unified PMC and simply update the mapping for params 00:38
00:39 mikehh joined
chromatic It's not quite that simple. I think we also have to perform some conversions in place when there's no exact MMD match. 00:39
Whiteknight This is true, but we can do the conversions en passant
jonathan Anyway, it's laaate here. I need sleep.
Whiteknight goodnight jonathan
chromatic Yeah, I think en passant callee-side conversions make more sense.
Whiteknight exactly 00:40
chromatic The MultiSub invoke is even a convenient place to do so.
Or a special get_params op for multis... or something.
Whiteknight when doing MMD, we only really need to compare tuples anyway. Once we find the proper signature, we can do ops conversions lazily 00:41
chromatic Right.
Whiteknight purl msg allison can you take a look at nopaste.snit.ch/18352 ? It doesn't work, but something like this should solve some of our tailcall problems, I think 00:42
purl Message for allison stored.
Whiteknight The only thing I worry about is Rakudo 00:43
their behavior of passing control to the next multi variant means they need to store a raw form of passed args
chromatic They do have their own PMCs for this though. 00:44
Whiteknight this is true 00:45
some of the Perl6 semantics are so complex and involved, it's hard to really support them at any level
especially if we want to offer equal support to any other languages
not that it's a bad thing, the p6 spec is rediculously ambitious 00:46
00:47 rhr joined
Austin WhiteKnight: That's why perl6 programs will always have filenames ending in .pl6 00:47
Or plvi 00:48
dalek rrot-plumage: 7726562 | leto++ | :
[t] Add some tests for path_exists()
shorten dalek's url is at xrl.us/bfsm42
Whiteknight Austin: and why all Perl6 programs are at least O(n^4)
Austin :)
(It's funnier if you've ever worked in PL/I, natch...)
Whiteknight the first "Killer App" written in P6 will be skynet
00:48 integral joined
Whiteknight and it will actually kill 00:48
I've seen PL/I, never had the misfortune of programming in it 00:49
Austin It was fine to program in. Very smooth. But the compiler required N**2 passes, where N was the number of tokens in the input. :(
00:50 kid51 joined
Austin Turns out that most programs could eventually be rendered down into like 6 or 7 opcodes. Those mainframe guys had opcodes for everything. 00:50
Whiteknight a tradition that Parrot tries to continue 00:51
Austin "Ohhhh! You want to normalize by using the 1970-adjusted price of grain futures in *brazil*? Why didn't you say so in the first place. You need to put 'E9 4B' right there, in front of that call."
Whiteknight well, price of grain futures in brazil is a standard metric in computer science 00:53
so that's fortuitous
chromatic It's a Hamilton number, right? 00:54
Austin What's a Hamilton number? 00:58
err.
What *is* a Hamilton number?
dalek cnum-dynpmcs: r188 | darbelo++ | trunk/ (8 files):
Convert our build to single-makefile, all build products now go into
Austin Grr. 01:00
I'm never sure if I love the fact that NQP always returns the last expression evaluated as a result of a block, or if I hate the fact that NQP always returns the last expression evaluated as the result of a block.
Whiteknight yeah, that's a perl-ism that I never liked 01:02
I've run into problems before in C with lousy old compilers where a statement would put a value in EAX, and the caller wouldn't preserve EAX because the function call was supposed to return a void 01:03
Austin Apropos of nothing, I bought these "window sealing kits" at a store this spring, and today I got a little cold in my office (I still haven't turned on the heat) so I figured that I'd try sealing my office window, to see if it made a difference.
(My office is a 3rd bedroom, and the window in question is a "slider".)
Whiteknight let me tell you how great it is to debug THOSE kinds of errors
Austin Boy, oh boy, did it make a difference. In the 40 or so minutes I fought with the plastic sealer, the temperature went up by 7 degrees Fahrenheit. 01:04
Whiteknight Austin: once you got it onto the window, did it work? 01:05
Austin I haven't even done the "heat-shrink" thing yet. Mostly because I don't have a hair dryer.
chromatic Why don't you have a ... oh, right.
dukeleto darbelo: what is the difference between 'abandoned' and 'retired' ? (defined at the bottom of the wiki page) 01:08
msg japhb should I attempt to load src/plumage.pbc to test individual functions or should things get moved into Glue.pir? i am thinking specifically about find_program() 01:11
purl Message for japhb stored.
cotto_work chromatic++ for taking pizza out of someone else's fridge 01:28
chromatic Turns out I had pizza in my own fridge too. I was surprised. 01:29
dalek TT #1102 reopened by jkeenan++: test failures with t/compilers/imcc/syn/macro.t and regressions.t in fast, ...
Whiteknight what's more surprising is that they ended up being the same fridge because GE didn't lexically scope them
chromatic I hope my cupcakes are still present. 01:30
If I get a vote, can we set TT #1102 on fire? 01:33
cotto_work goes off to add a new "on fire" ticket resolution. 01:35
or maybe it should be a status.
Austin Why this animus towards TT? 01:36
japhb dukeleto: Hmmm. Why don't we create a src/lib/Util.nqp, and compile it down to pbc during make? Then utility functions written in NQP can be moved there. The long term goal is to move the model and controller parts of plumage.nqp out to one or more libraries, so we can change UIs at easily, or do programmatic inspection. 01:43
dukeleto japhb: and make it easier to test ;) 01:46
chromatic: what does a burning ticket mean?
japhb dukeleto, yes, that had crossed my mind. ;-) 01:48
kid51 unpacks a box that just arrived and finds ... Parrot Developer's Guide: PIR 01:50
dukeleto japhb: i am on that now 01:51
kid51: can you take a pic? where do I order one?
kid51 amazon 01:52
01:53 JimmyZ joined
kid51 is startled to see he gets a mention in the "Parrot team" section of the endpaper 01:54
01:54 rhr joined
solarion interesting 01:54
dukeleto kid51: how many pages? 02:02
02:02 dalek joined
dukeleto kid51: 118 02:02
dukeleto has to learn to scroll down
kid51 v + 113 = 118
Granted, I could have read it online ... 02:03
... but that's just so 21st century!
dukeleto kid51: does anybody know which svn rev the printed book roughly corresponds to? 02:04
kid51 Somebody does ...
dukeleto kid51: or in other words, how old is the dead tree version?
kid51 ... but I'm not that body
well, whiteknight and allison are the lead authors, so I presume they know. 02:05
And they probably posted on channel at the point the book went to press.
And then there's this Shane Warden guy who was the editor. I'll bet he'll know. 02:06
dukeleto japhb: nqp --target=pbc -o src/lib/Util.pbc src/lib/Util.nqp
"pbc" => PMC 'Eval' { ... }
japhb: how do I turn .nqp into .pbc ?
02:06 abqar joined
dukeleto japhb: also, i have nqp aliased to parrot_nqp 02:06
Austin parrot_nqp
purl rumour has it parrot_nqp is just the name of the fakecutable binary
dukeleto purl: that might actually be useful 02:07
purl dukeleto: what?
dukeleto purl, be useful is i try my best
purl ...but be useful is <action>whirrs and clicks in the background....
dukeleto purl, be useful is also i try my best
purl okay, dukeleto.
dukeleto purl: be useful
purl whirrs and clicks in the background. or i try dukeleto's best
dukeleto facepalms
kid51 purl, good bot 02:08
purl thanks kid51 :)
Austin or 2 /usr/local/bin/parrot /usr/local/lib/parrot/1.6.0-devel/languages/nqp/nqp.pir --target=pir --output=foo.pbc foo.nqp
For some value of /usr/local 02:09
chromatic The book roughly corresponds to 1.6. 02:10
PIR hasn't changed much since then though. 02:11
Austin There's a good question: Is pcc_reapply coming in 1.7?
chromatic No. 02:12
Austin <whew>!
Taxes won't be too bad this month, then.
02:22 rhr joined
japhb dukeleto, see Makefile.in. 02:33
It's a multistage process
And current parrot 'install-dev' (and maybe 'install', I dunno) creates a parrot_nqp fakecutable and installs it, so no need for an alias anymore. ;-)
Basically, do the same thing as plumage.nqp, but stop before you create the fakecutable. 02:34
japhb disappears again to do the weekly trash/recycling/yard waste run
02:35 petdance joined, janus joined
dukeleto msg japhb i alias nqp=parrot_nqp, just 'cause I am lazy :) 02:44
purl Message for japhb stored.
dukeleto japhb: i see the multi-staged-ness now. i should have it working soon... 02:45
one could write a treatise on effective laziness based on my .bashrc alone 02:49
Tene dukeleto: I alias n=parrot-nqp, p=parrot, r=perl6 02:53
r{pir,past,parse}='perl6 --target=foo' 02:54
lots more
cdp='cd ~/src/parrot/' 02:55
nopaste "dukeleto" at 69.64.235.54 pasted "can you tell that I work in deep directory hierarchies at $work?" (8 lines) at nopaste.snit.ch/18353 02:57
dukeleto Tene: do you have yours under version control?
Tene: github.com/leto/Util/tree/master/config 02:58
japhb dukeleto, an early "advanced shell" for DOS and Windows magically converted N+1 dots to "go up N levels". So you could 'cd .....' 02:59
dukeleto Tene: i like the target aliases, i should add those
japhb: that sounds like a create feature
japhb: perhaps the zsh folks will do something like that
chromatic I like pushd/popd. 03:00
japhb alias dirv='dirs -v' # The way it should have been, dammit
chromatic, extra points if you do 'pushd -0' on a regular basis. :-) 03:01
Austin Speaking of shell programming, some guy on reddit (!) just posted a "high precision status bar" for bash. 03:02
Apparently reddit is now the cool place to show off your warez.
Unicode U+2580..F is your friend, provided you have the right fonts. 03:03
dukeleto Austin: i avoid reddit and digg like swine flu
Austin :)
Swine flu is the new celebrity fashion disease, dukeleto. Aren't you keeping up on TMZ?
japhb Austin, url? 03:04
Austin www.reddit.com/r/programming/commen...r_in_bash/
shorten Austin's url is at xrl.us/bfqec4
Austin Or did you mean? : www.tmz.com/2009/09/24/swine-flu-al...hollywood/ 03:06
shorten Austin's url is at xrl.us/bfsnsx
japhb OMG MY EYEZ
Austin japhb: One of the shells, probably bash, has or had a "CDPATH" variable, where you could put alternative places to cd. Maybe you should just set CDPATH = ".:..:../..:../../..:" ...etc 03:08
dalek rrot-plumage: 144bc0d | leto++ | :
[util] Refactor utility functions of plumage.nqp into src/lib/Util.nqp
 03:09
shorten dalek's url is at xrl.us/bfsns5
03:16 davidfetter joined 03:37 plobsing joined 04:07 abqar_ joined 04:22 mikehh joined 04:30 mikehh joined
dalek TT #1114 created by mgrimes++: [patch] Converted some tests from perl to pir 05:02
05:07 kyle_l5l joined 05:37 desertm4x joined 05:47 uniejo joined 05:58 he_ joined
dalek cnum-dynpmcs: r189 | darbelo++ | trunk/Configure.pir:
Give Configure.pir a --help option and make it verbose to let the user know
 06:03
06:23 theory joined
chromatic msg whiteknight factor-language.blogspot.com/2009/1...ctors.html 06:27
purl Message for whiteknight stored.
shorten chromatic's url is at xrl.us/bfsocv
JimmyZ whiteknight? 06:34
purl whiteknight is mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
kyle_l5l is there a way to see what a program in PIR looks like after being compiled to pasm? 06:36
chromatic ./parrot fun.pir -o fun.pasm 06:37
06:40 UltraDM joined
kyle_l5l does set_args take any arguments? (I'm not seeing any in the pasm) 06:40
chromatic It has a constant PMC stored in the bytecode representing the signature. I believe it's a FixedIntegerArray. 06:41
06:50 iblechbot joined 06:54 fperrad joined
kyle_l5l but it does look like set_args takes some arguments. yeah, parrot's pasm output leaves out all arguments for set_args, get_results, etc (and thus the pasm output can't be run) 06:59
chromatic There are a couple of notes in IMCC that it doesn't dump all of PIR appropriately. 07:00
The pbc_dump utility may be more useful.
kyle_l5l alright 07:01
07:24 donaldh joined 07:40 mikehh joined 07:48 GeJ joined 07:50 masak joined 07:55 bacek joined
bacek o hai 07:55
07:56 mikehh_ joined 08:01 mikehh joined
dalek rrot: r41885 | fperrad++ | trunk/tools/install/smoke.pl:
[install] since r41417 , NQP is installed as an executable parrot_nqp
 08:09
mikehh should have reported this a few ago but fell asleep 08:11
trunk - pre/post-config, smoke (#29064) PASS, fulltest FAIL at r4184 (see TT #1102) - Ubuntu 9.10 (beta) amd64 08:12
fulltest - testf and testg now PASS but testS still FAILs
t/compilers/imcc/syn/macro.t - Failed tests: 2-4
t/compilers/imcc/syn/regressions.t - Failed test: 7
all other tests in fulltest PASS
that's r41864
08:13 uniejo joined
bacek mikehh: you can fix regexes in failing tests. It's just adding |0 into it. 08:25
mikehh: just after |-1 08:27
mikehh bacek: will have a look in a bit - got to go to get some stuff from Macdonalds - bbiab 08:32
08:43 mokurai left 09:06 AndyA joined 09:25 AndyA joined
dalek rrot: r41886 | mikehh++ | trunk/t/compilers/imcc/syn (2 files):
fix failing tests in testS for macro line numbering
 10:10
mikehh messages 10:16
10:19 petdance joined
mikehh All tests PASS (pre/post-config, smoke (#29075), fulltest) at r41886 - Ubuntu 9.10 (beta) amd64 10:43
10:57 jsut_ joined 11:08 cconstantine joined 11:41 einstein joined 12:02 JimmyZ joined 12:06 whiteknight joined
whiteknight good morning #parrot 12:08
12:10 payload joined
JimmyZ good morning, whiteknight . 12:10
whiteknight hello JimmyZ, how are you today? 12:14
Coke chromatic, kyle_l5l : I thought that foo.pir -o foo.pasm has been broken for like 6 years.
s/broken/not intended to work/
JimmyZ whiteknight: Fine, thanks. I just visited your blog, there are many good articles talking about Parrot. 12:19
whiteknight: That's helpful for newcommer. 12:21
whiteknight thanks! I try to provide lots of information
I feel like it helps people get involved
dalek TT #1102 closed by jkeenan++: test failures with t/compilers/imcc/syn/macro.t and regressions.t in fast, ... 12:22
JimmyZ whiteknight: yes, I think It can be moved to trac.parrot.org or parrot.org for who wants to get involved. BTW, blogspot is forbidden by Chinese Great Firewall. I used proxy. 12:24
whiteknight really? I didn't know it was blocked 12:25
JimmyZ whiteknight: many sites such as facebook, twitter also are blocked by it. 12:26
whiteknight I guess that doesn't surprise me though
dalek TT #1102 reopened by coke++: test failures with t/compilers/imcc/syn/macro.t and regressions.t in fast, ... 12:28
Coke reopens 1102! whee! 12:30
JimmyZ whiteknight: It really take me several months to find a useable proxy to visit your blog. 12:31
12:31 bluescreen joined, desertm4x joined
nopaste "dukeleto" at 69.64.235.54 pasted "fib.pir benchmarked across released versions of parrot, trunk@r41884, pcc_reapply@r41884" (15 lines) at nopaste.snit.ch/18355 12:32
dukeleto msg chromatic nopaste.snit.ch/18355 is a bitter pill to swallow. let me know what I can do to help 12:33
purl Message for chromatic stored.
dukeleto 'ello
whiteknight we know there's a factor of two slowdown in branch 12:34
there are lots of critical path optimizations needed stil
dukeleto whiteknight: yes, but fib.pir has gotten slower since 0.9.0 by a factor of ~2 as well. so when we merge pcc_reapply in, that is a ~4x slowdown in fib.pir since 0.9.0 12:37
whiteknight we've been doing a lot of refactoring on various systems to make them cleaner, but haven't followed with an equal amount of optimizations 12:38
obviously it's something we need to look at across the board
dukeleto whiteknight: that is very understandable. i am interested to see what chromatic has to say about those benchmark numbers. 12:39
whiteknight yeah
we know the context refactors slowed things down
Coke newsflash: parrot is still slow. 12:42
JimmyZ newsflash: parrot will be faster. 12:43
Coke I obviously hold out hope for that or would have left 8 years ago. =-) 12:44
masak even abandoning the project is slow, in other words. :)
Coke I'm going as fast as I can. =-)
masak heh :) 12:45
dukeleto Coke: i wouldn't even go that far. This is the first benchmark that I have found that has gotten consistently slower thoroughout time (although I am sure there are more), for the most part, parrot has started to really fly 12:48
Coke dukeleto: It seems to do fine at hand crafted pir examples vs. perl5 12:49
I have yet to see any compelling HLL timings.
dukeleto Coke: oh yes. parrot kicks perl 5 in benchmarks these days. HLLs are a different story 12:50
Coke yes. and what is the expected usage of parrot? =-)
for me? HLLs.
so, parrot, being used as I expect it is intended to be used, is still slow.
dukeleto Coke: i think we are still in the stage of giving HLLs features, and not quite in the stage of optimizing for HLLs
Coke: yes, for an HLL, parrot is slow 12:51
Coke dukeleto: Agreed on both counts (slow for HLLs, still missing features) 12:52
so, I cringe whenever I see "parrot is fast(er)!". =-) 12:53
(even to run the tcl program 'exit', partcl takes .675s while tcl8.5 takes 0.005s, e.g.) 12:54
JimmyZ :( 12:55
dukeleto Coke: chromatic needs to work on his mitosis. with a half dozen chromatics, i think parrot would get faster at a much faster rate :) 13:04
i am learning a lot about valgrind and cachegrind, so hopefully I become useful in that area soon as well 13:05
13:06 payload joined
whiteknight Once we get the last few failing tests fixed, more people will be able to do more optimization work 13:07
I don't want to focus on optimizations myself until they're fixed, anyway 13:08
JimmyZ promising 13:11
purl promising is, like, a term for developing stuff.. >: [
whiteknight I definitely want to pay more attention to what kinds of optimization ideas chromatic and bacek are coming up with 13:43
dukeleto whiteknight: yes, i am not advocating optimization being done on pcc_reapply until all tests are passing. just want to quantify what the slowdown will be and prepare us all for it 13:49
dalek rrot: r41887 | pmichaud++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[pct]: Use explicit Undef check for parseactions instead of get_bool.
 13:50
whiteknight yeah, it's going to be quite the experience
dukeleto whiteknight: those rakudo guys, they might beat us up :) 13:51
13:51 payload joined
whiteknight fixing the NCI frame builder will cut 30% off startup time I think 13:51
a proper generational GC will give us between 2%-30% depending on workload
Coke has anyone done any profiling against partcl to see what sort of improvements are to be gained there? 13:52
whiteknight I think we can easily get back 20% at least by being smarter in handling contexts
Coke: none that I know of
jonathan plans to run the profiler against Rakudo in the not too distant future. 13:56
And work out what's costing us (besides signature binding, which I'm in the process of dealing with at the moment.)
whiteknight profiling these things will be a very good thing, although I have a good idea about where a lot of slowdowns are
chromatic I'm sure knows better 13:57
jonathan whiteknight: I'm not entirely sure where Rakudo's worst runtime ones are outside of the sig binding. 14:01
So I'll be interested to see the results.
whiteknight Me too. I don't know enough about Rakudo to guess where your bottlenecks are going to be 14:05
I have to suspect startup, parsing, and MMD are going to be huge 14:06
14:09 Psyche^ joined
jonathan whiteknight: Startup isn't great, but in the last week or two it's had 40% shaved off of it. 14:11
whiteknight: MMD is fairly efficient.
whiteknight: Parsing isn't, but there's a fix in the works for that.
If startup could lose another chunk off it, that'd be great though. 14:12
dalek rrot: r41888 | pmichaud++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[pct]: Explicitly allow protoobjects as parseactions in HLLCompiler.
 14:13
jonathan We run a bit over 400 or so test files, so saving about 0.4s on startup shaved me 3 minutes off a spectest run.
whiteknight jonathan: yeah, like I said I can only guess where slowdowns might be. 14:18
jonathan whiteknight: Not if you run the profiler. ;-)
whiteknight true,
14:27 JimmyZ joined
Coke git q: I have a bunch of old branches on github for partcl. how do I update them to match work done in origin/master? 14:28
(what is the git-way of doing svn's merge changes from trunk)
which gitk 14:31
whiteknight wouldn't it be something like git pull master? 14:32
Coke or git rebase. 14:35
purl rumour has it git rebase is cool
Coke (or git merge) 14:36
14:42 payload joined
Coke (ok. git checkout --track -b foo origin/foo; git merge master) . modulo a lot of conflicts. 14:43
14:45 pjcj joined
dalek rtcl: 82b7665 | coke++ | docs/spectest_skips:
Update spectests (slightly different results on new testing platform)
 14:45
shorten dalek's url is at xrl.us/bfspmi
14:50 iblechbot joined
Coke if I do a merge from master into a branch, does it do the whole thing as a single commit? 14:56
dukeleto Coke: yes 14:57
Coke did I really want a rebase here?
dukeleto Coke: not sure, backlogging
Coke I have a very old branch; trying to bring it up to date with master.
dukeleto Coke: also, trackking is default now-a-days
14:58 mikehh joined
dukeleto Coke: git checkout -b foo origin/foo make a local branch that tracks the one on github 14:58
Coke: then I think you might want 'git rebase master' ?
Coke: i think
s/make/makes/ 14:59
dukeleto is still getting over being sick and is still making lots of dumb typos
Coke ok. how can I delete my local branch that tracks the origin branch?
(so I can try this over.)
dukeleto Coke: git branch -d foo
Coke: or git branch -D foo if you are sure :) 15:00
Coke: -d only deletes it if it has been merged in. -D will delete any branch, regardless
Coke: i tend to try -d first, then make sure to myself that I don't want it, then do -D
Coke: you can always get it back with git reflog, so it ain't that big a deal 15:01
Coke: does this newer patch look reasonable to you? trac.parrot.org/parrot/ticket/1085 I am testing it now 15:02
Coke dukeleto: is that the tcl patch? 15:03
it's pretty much entirely orthoganol to partcl. No opinion.
so, if I rebase, have conflicts, after I locally edit, do I have to do a 'git add' for for the rebase --continue to work?
dukeleto Coke: yes 15:05
Coke: yes, I know that Tcl is orthoganl to partcl, but I thought you might have more than my 0 tuits in that area. no worries 15:06
Coke: git add is the same as 'svn resolved file' when you are fixing conflicts 15:07
Coke: basically you are telling git to update the index with what the working copy is now
Coke if I do a rebase like this and then push back, what's going to happen? will I get N commit emails showing these commits played on the branch? 15:18
.. if I do a git push, I get "everything up to date". huh? 15:24
also, "not currently on any branch" . huh?
(switch to branch. git push. everything up to date) 15:26
I am very confused. :|
dukeleto Coke: hmm 15:40
Coke: what does git status -a say?
Coke I've moved on. Just did the whole thing again, this time failing on git push; 15:43
$ git push
To git@github.com:partcl/partcl.git
! [rejected] tclint -> tclint (non-fast forward)
error: failed to push some refs to 'git@github.com:partcl/partcl.git'
dukeleto Coke: do a pull first 15:46
Coke dukeleto: AIGH
now all my conflicts are back.
the ones that I have now fixed ... what, 3 times?
=-)
dukeleto Coke: if you don't care about what the remote branch is like write now, you can override it, and do a non-fast forward. do you want to do that? 15:47
s/write/right/ # ug
Coke dukeleto: I have no idea what you mean. 15:48
dukeleto Coke: do a git reset --hard HEAD^ to get rid of the conflicts
Coke at this point, I'm probably just going to destroy the branch and recreate it because git sucks. =-)
dukeleto Coke: let me ask that question in normal-speak
Coke: do you care about the state of the remote branch 'tclint' right now? do you want to rewrite its history? 15:49
Coke dukeleto: that's not entirely normal speak. =-) 15:50
I would /like/ the branch to be rebased against master. I will settle for a merge. I am pondering just deleting the branch and, as allison does with svn, manually reapplying the bits in new commits to master. 15:51
dukeleto Coke: can we stomp on the remote branches face and just recreate it? is anyone else tracking that branch? can we pull the rug out from anyone that was?
Coke dukeleto: you overestimate the # of people looking at partcl. right now it's just me. =-)
cotto_work LLVM videos: llvm.org/devmtg/2009-10/
dukeleto Coke: then doing a git push --force will do what you want 15:52
Coke I do not like the sound of that.
but I have no idea what it means. =-)
dukeleto Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.
'the command' refers to 'git push' 15:53
15:53 theory joined
dukeleto Coke: so obviously, you don't want to use --force willy-nilly, but for this situation, it is fine. it is kind of like deleting the remote branch and recreating it 15:53
Coke: actually, you can do that instead.
Coke: delete the remote branch, and then you won't have to use --force 15:54
Coke dukeleto: at this point, it seems simpler to me to delete and just start over completely.
dukeleto Coke: perhaps. you can always make a diff and apply that to master. perhaps a few hunks will get rejected, but that is the least amount of work right now 15:55
Coke: it could be that you just have lots of actual conflicts between that branch and master.
Coke: git merge-magic-pony is still in development ;) 15:57
Coke from elsewhere: "git-rebase I think has fairly strong warnings against doing it."
true?
purl rumour has it true is not false
Coke darbelo: looks like your install-parrot branch doesn't have any actual commits on it, but does have an svn merge. easier to delete and recreate? 16:00
msg darbelo looks like your install-parrot branch doesn't have any actual commits on it, but does have an svn merge. easier to delete and recreate?
purl Message for darbelo stored.
darbelo Coke: Probably.
Coke msg darbelo added you as a collaborator on partcl/partcl 16:01
purl Message for darbelo stored.
whiteknight purl forget true
purl whiteknight: I forgot true
Coke oh, hai.
whiteknight hi
darbelo hi
purl salut, darbelo.
Coke darbelo: feel free to delete that branch and recreate it. I suspect the remaining branches may suffer a similar fate.
darbelo I'll delete now, recreate later when I actually have some tuits to work on it. 16:02
Coke darbelo: +1 16:04
purl 1
Coke darbelo++
darbelo I get karma for punting stuff?
Coke darbelo++ #questioning authority 16:05
darbelo :)
cotto_work some days you get karma for existing
Coke cotto_work-- # smart-talk. 16:06
karma cotto
purl cotto has karma of 956
Coke karma cotto_work
purl cotto_work has karma of 5
16:11 payload1 joined
Coke -> afk 16:14
whiteknight cotto_work++ # links to LLVM videos 16:16
downloading several now 16:17
cotto_work whiteknight, which ones?
16:17 allison joined
whiteknight Unladen Swallow, the GC efficiency one, the action script one, spacial memory safety, and the ruby one 16:18
those are the ones that I think, reading the descriptions, are most pertinent for Parrot
cotto_work possibly also the "building a backend" one. 16:19
cotto_work is glad to have a fast Internet connection at his disposal for downloading said videos.
whiteknight I saw that. But I figure most of our conversions are going to be PBC -> LLVM, not the other way around
darbelo purl: msg Coke The install-partcl branch is gone. Hope you had a chance to say goodbye :) 16:23
purl Message for coke stored.
whiteknight The Rubinius guy says he's never seen any documentation or examples for using a JIT with a stackless VM 16:29
I didn't expect it to be too difficult to do 16:30
dukeleto Coke: git rebase has many adherents and enemies. the best i can say is 'it depends'. 'Only rebase history no one else has seen or depends on' is my motto 16:36
16:37 cognominal joined 16:41 davidfetter joined 16:51 HG` joined
redbrain hey guys working on having a build bot for us on some sparc64 and mips i'll send a mail to the list when its up we should have an irc bot for it too 17:31
17:31 payload joined
cotto_work redbrain, great! 17:32
redbrain yeah there will be more but just work on 2 machines so far its not quite working yet but i'll fix it when i get some food :P 17:33
anyways i am heading on to get food be back online later :) 17:34
17:34 redbrain left
cotto_work nom 17:34
17:35 allison joined
cotto_work Coke, did you have any hashing library in mind when you added that comment to ItsABughunt? 17:37
Coke any of the ones that I found several years ago when I suggested it and did a google search? =-) 17:38
(no, no one in particular.) 17:39
17:43 AndyA joined
cotto_work what advantages are you thinking of? 17:43
dalek rrot: r41889 | mikehh++ | trunk/t/compilers/imcc/syn (2 files):
revert r41886 and mark failing tests in testS for macro line numbering as TODO
 17:50
17:52 HG` joined
Coke cotto_work: not reinventing the wheel. 18:01
purl not reinventing the wheel is nice too, but smolder is _so_ hard to install, it's insane
darbelo Coke: you'd need an Artistic 2.0 licensed wheel. 18:02
Coke darbelo: only if we include it in core.
s/core/repo/
we can depend on 3rd party libs without much problem.
cotto_work minimizing external dependencies is nice too, since any hll will depend on what parrot depends on 18:03
darbelo Except parrot needs to run on two gazillin platforms that might not have thar lib.
Coke darbelo: see also ICU. 18:04
18:04 rdice joined
cotto_work but that's a really hard wheel to reinvent 18:04
darbelo I can install without ICU. I can't install wothout hashes.
Coke at least 2 HLLs are completely dead without ICU.
pmichaud wonders which 2 those are.
Coke is overselling. 18:05
doesn't rakudo currently require ICU?
darbelo rakudo and which other?
pmichaud for full functionality, yes.
Coke so, overselling.
s/completely dead/not fully functional/ =-)
pmichaud but it isn't "completely dead" w/o it :)
Coke partcl.
darbelo Oh.
pmichaud the test files that rakudo can't pass w/o icu are listed in t/spectest.data with a "# icu" tag. 18:06
Coke anyway, I'm saying someone should /evaluate/ a 3rd party library.
18:06 payload joined
pmichaud (15 test files out of 450, fwiw) 18:07
Coke this is true for a lot of code. (jit, nci, icu, bignums, ....)
pmichaud but yes, the point that Parrot relies on 3rd party non-bundled libraries is completely correct. :) 18:08
Coke yes. I'd rather rely on 3rd party libraries.
pmichaud but then how would we make sure all of the wheels have been properly reinvented? ;-) 18:09
darbelo I mostly agree with Coke here, butI think having some languages not work on, say OpenBSD/vax, is quite different from having the whole vm 'only work where library Foo does'
18:09 cognominal joined
pmichaud I think the number of platforms that we explicitly claim to support is fairly small (more) 18:10
Coke (small) and we don't even really support them.
(OS X 10.4/intel, e.g.)
pmichaud so if there's a library that doesn't run on a platform where we need it, our efforts might be better put towards porting that library than reinventing it whole-cloth. 18:11
Coke pmichaud++ #I've been saying that for years. =-)
PerlJam pmichaud: no,no, let's be like netscape! ;>
pmichaud what, and rewrite the whole thing in Java? ;-) 18:12
darbelo pmichaud: The library might compile, hell even *work*, but parrot "Can't rely on it if nobody packages it." 18:13
pmichaud we can improve that too.
packaging a library is often a lot less effort than writing one from scratch :) 18:14
I'm just sayin', thazzall. :)
18:16 ruoso joined
darbelo For one OS, yes. For *all* OSes parrot has to run in? Half of the supported platforms don't package *parrot*. 18:16
pmichaud see "small" above.
Coke darbelo: define "all oses parrot has to run in" ?
pmichaud I'd even like to see "half of the supported platforms" :-) 18:17
PerlJam parrot has to run in an OS?
:)
darbelo First approximation: The list of OSes I can tag a ticket with.
pmichaud PerlJam: no, I don't think we support EMACS yet. 18:18
True value: The Parrot team is committed to supporting the following combinations as 18:19
"core platforms": Linux (x86), Win32 (x86), OS X (x86 and PPC), Cygwin, Tru64,
OpenVMS (Alpha), FreeBSD (x86).
I count seven.
er, eight.
darbelo Packaged on: Some linux, Win32, macports, and ...
pmichaud I don't think we claim to support every packaging system for each one of those core platforms. 18:20
18:21 joeri joined
darbelo We don't package for Cygwin, Tru64, OpenVMS or FreeBSD 18:21
half.
PerlJam I thought there was a cygwin package 18:22
pmichaud So, your claim is that we should create our own versions of libraries for platforms that we don't even have the manpower to build a package for...? ;-)
darbelo The first page of google results for "parrot cygwin" shows 0.6.4
pmichaud s/manpower/resources/ 18:23
darbelo pmichaud: No. I'm saying we need look again at the whole "running on toasters too" goal.
pmichaud is "running on toasters" (or its approximation) somewhere in our roadmap/timeline ? 18:24
(out of curiosity)
jonathan
.oO( pmichaud, our resident toaster expert :D )
 18:25
pmichaud
.oO( for that, I need to put the 'hcf' opcode back into Parrot :-)
darbelo There's noise every now and then about 'running everywhere perl does, and more!'
pmichaud Oh. At PDS 2008 I think we decided to forego that particular goal for the time being. 18:26
I'm not sure it was decided what "the time being" meant, though.
darbelo was not at the PDS :(
whiteknight means "forever"
speaking of PDS, weren't there talks to do a virtual one this year?
I would really like to be able to have a dedicated planning meeting like that 18:27
pmichaud yes, there were. I've heard no further details (but I've also been heads-down on regex stuff)
whiteknight I've been heads-down on pcc stuff, so I'm in the same boat
Coke darbelo: the package on macports is hideously out of date and hasn't worked for some time with trunk.
pmichaud there were talks to have a meeting; whether it's virtual or non-virtual hadn't been decided iirc. But I'm fairly certain it'd be virtual, given resource limits.
whiteknight Coke: what does it take to make a macports package? Is that something that can be automated? 18:28
Coke whiteknight: i CANNOT INSTALL ON THAT PLATFORM.
darbelo I'll trade it for FreeBSD, I just found a port for 1.4 there.
pmichaud I think we'd really want to make sure the next meeting can involve direct participation from people who cannot travel.
Coke so, making the package is irrelevant, since I can't even run "make install"
once make install works, the package is simple. 18:29
whiteknight Okay...so what needs to happen to fix that?
Coke whiteknight: if I knew, I'd fix it. tehre's a ticket open for some time now.
whiteknight is not familiar with the plight of OSX
if I had a Mac, or access to one, I would fix it
pending that, SOL
darbelo whiteknight: We need to get more OSX experts. 18:30
Coke darbelo: ... more?
18:30 mikehh joined
whiteknight starts drafting a blog post about it 18:30
Coke we don't really have any, I think. we have a bunch of developers who do casual development on osx.
darbelo Coke: Yes, a non-negative number of them.
That's more than we have now. 18:31
whiteknight If anybody has an old, spare mac that they'd be willing to send me, I'd fix it all 18:32
Coke darbelo: the english teacher in my head says that you can't say "more" in english if you have none to start with.
18:32 theory joined
Coke whiteknight: no. good luck getting any h/w from apple, either. 18:32
I've given out dev accounts on my home desktop machine in the past to no avail.
whiteknight I have some mac-loving inlaws that I might be able to convince that they need to "upgrade"
:)
darbelo isn't a native english speaker. 18:33
Coke soon it won't matter for me either, as I hear 10.5 JFW.
darbelo: just explaining why I picked on that particular word.
whiteknight JFWing is a major feature
does apple do hardware donations and stuff to open-source groups? 18:35
I hadn't even considered that path
Coke not SFAIK.
ISTR that people on the board have asked. 18:36
and we have an ex-parrot person at apple who I think has also told me no.
whiteknight okay, well I will continue not considering that path
darbelo Coke: That TT needs to go into the roadmap, marked with "BLOCKER" in big angry letters.
Coke (but that may just have been because he had no access.)
pmichaud I wonder if we could get a donation from one of our sponsors (or possibly a new sponsor)
instead of trying to hit apple up directly.
Coke darbelo: yes, well, i can only open so many tickets that don't get responded to. =-)
whiteknight soliciting a donation would be quite hot
whiteknight would love to set up a little build farm with a lot of test machines
Coke we just don't have anyone to work on OS X issues that isn't already swamped on other things. 18:37
pmichaud I suspect sponsors have old(er) machines they'd be willing to part with
and we might be able to solicit a cash donation if we could say "it's going to be used for this specific purpose"
Coke I pretty much just gave up on OS X and am using feather or other donated boxes I have remote access to. 18:38
whiteknight okay, so how do we go about doing that? I'm not in charge of anything, so I don't know what the process would be
Coke: What's the ticket number?
pmichaud another possibility might be to start asking various apple user groups for help 18:39
could grow our developer pool.
darbelo (grow our developer pool)++ 18:40
cotto_work developers developers developers
Coke whiteknight: 910 "macport/installing on OS X"
whiteknight what compiler are you using, gcc? 18:41
for that matter, could you just post your entire config/build log?
Coke whiteknight: no, I'm busy ATM. please post questions on the ticket, I'll get to it when I can. 18:44
(gcc) yes.
it's pretty much the only game in town.
darbelo for now, at least. 18:45
Coke ?
whiteknight I wonder if you could try building with LLVM? I know Apple has been putting some energy into that lately
darbelo apple has been making noises about LLVM for a while.
Coke whiteknight: on 10.4 ? I highly doubt it.
it's been reported (dukeleto?) that parrot installs just fine on 10.5 (10.6 is latest), so I may just be SOL. 18:47
(in that we have no one with the time to make it work on my 2 year old OS.)
darbelo SOL?
purl SOL is Shit Outta Luck. or the sun or s/Shit/Straight/ or snicker out loud
darbelo ah 18:48
mikehh All tests PASS (pre/post-config, smoke (#29100), fulltest) at r41889 - Ubuntu 9.10 (beta) amd64 18:50
cotto_work cool. the unladen swallow presentation mentions parrot 18:51
whiteknight really? I haven't watched that one yet 18:56
I was in the middle of the VMKit one and got distracted 18:57
I really would love to go to this one next year
cotto_work hopefully we'll even have something to talk about by then 18:59
19:01 mikehh joined 19:02 mokurai joined
cotto_work llvm? 19:06
purl llvm is a big huge thing with not much docs, but it works or low-level virtual machine or at www.llvm.org
cotto_work llvm is also not the cure for cancer
purl okay, cotto_work.
19:09 Ron joined
cotto_work possibly useful page describing python's bytecode instructions: www.python.org/doc/2.5.2/lib/bytecodes.html 19:09
19:18 chromatic joined, desertm4x joined
cotto_work chromatic, do the tagged pointers in CallSignature have the potential to mess up gc? 19:19
chromatic I can't imagine how. 19:20
They all get marked appropriately.
If the tagging didn't work, we wouldn't get to the point of asking "Is this a GC bug?"
Crazy thought for getting rid of CPointer: make a ResizablePointerArray. 19:21
cotto_work Ok. I was just wondering if it'd be smart enough to deal with non-aligned addresses.
apparently it is.
whiteknight I like the idea of resizable Pointer Array
especially nice if we limit behavior for what CallSignature needs 19:22
chromatic The pointers should all be aligned; it only tags the storage pointers, not the INSP values themselves.
whiteknight Positional arguments seem to be accessible in order, so we can optimize for ordered access
cotto_work of course, but the gc looks for pointers, doesn't it? 19:23
chromatic If there's a platform that doesn't align pointers so that the bottom three bits are free, I don't know what it is.
We don't have a heap scanner looking for all heap-allocated pointers though.
whiteknight we really don't want a heap scanner either
19:24 mikehh joined
cotto_work ok. I see where my thinking was off. 19:25
chromatic Hm, I wonder if putting const in the appropriate place for the pcc_get_funcs struct will prevent refetching of pointers that won't change.
Could help branch prediction.
dalek p-rx: 4741f3d | pmichaud++ | src/ (2 files):
Remove Regex::P6Regex::Grammar's dependency on PCT::Grammar.
 19:26
shorten dalek's url is at xrl.us/bfsq4u
dalek p-rx: 5d42e76 | pmichaud++ | src/Regex/P6Regex.pir:
Correct compiler class to be Regex::P6Regex::Compiler .
shorten dalek's url is at xrl.us/bfsq4w 19:27
dalek p-rx: 638b1b5 | pmichaud++ | src/ (4 files):
Add naive protoregexes (from PGE cheats) to Regex::Cursor for bootstrapping.
shorten dalek's url is at xrl.us/bfsq4y
whiteknight that VMKit video has very interesting information about a proper precise GC
chromatic Where in fill_returns does it actually set the values in the CPointers? 19:31
Tene 'sec, I'll look 19:32
dukeleto Coke: can anyone else reproduce the error on 10.4 ? 19:34
Tene chromatic: most of the VTABLE_set calls in fill_results are assigning to the cpointers. 19:35
chromatic: look for result_item = 19:36
1590 fetches the cpointer in the positionals loop
chromatic VTABLE_set_pmc(interp, result_item, ...); 19:37
and so forth?
Tene Yes. The general strategy is to fetch the cpointer at the start of the loop, save it in result_item, and then later on, assign to result_item. 19:38
I don't expect any problems with rewriting that into set_*_keyed_int 19:39
whiteknight I also didn't realize that GDB7.0 had better JIT support 19:40
chromatic Let me work up a pointer array then.
cotto_work That was nice to find out.
whiteknight yes, now I really need to get GDB7
I wonder how long until it's included by the Ubuntu packagers
cotto_work too long 19:42
whiteknight true. that means I'll have to do the upgrade manually, which I hate
cotto_work however: blog.vinceliu.com/2009/09/how-to-bu...r-gdb.html
shorten cotto_work's url is at xrl.us/bfsq7v 19:43
whiteknight I'll check that out later
right now, I'm heading home
cotto_work it's pretty simple
assuming you can build it
whiteknight true, and that might be a nightmare
19:44 KatrinaTheLamia joined
cotto_work For me it just required figuring out the dependencies. 19:44
19:54 allison joined 19:58 bluescreen joined 20:04 confound joined
pmichaud is there a way from PIR to disable garbage collection -- i.e., to have the same effect as setting -G on parrot's command line? 20:06
Tene Look at t/op/gc.t as a first step 20:07
well, I'll look.
nothing there 20:08
cotto_work gdb upgrade request for ubuntu as a bug report: bugs.launchpad.net/ubuntu/+source/...bug/446457 20:09
chromatic The sweepoff op.
pmichaud thanks.
...find_method returns an exception if a method isn't found? icky. Perhaps it should return PMCNULL like most of the other "not found" situations? 20:11
20:11 theory joined
chromatic Makes sense to me. 20:13
darbelo nopaste? 20:16
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
jonathan pmichaud: find_method the op, or find_method the vtable? 20:18
20:18 mikehh joined
nopaste "darbelo" at 200.49.154.173 pasted "Sample matrixy run for Whiteknight." (44 lines) at nopaste.snit.ch/18357 20:19
pmichaud find_method the op
jonathan pmichaud: ah, ok
I was gonna say, I'm pretty sure I've not seen a find_method vtable throwing...
pmichaud if find_method the vtable throws exceptions, that'd be Very Bad.
jonathan Yes, tell me about it... 20:20
purl i think it is about the ordering
jonathan purl: I think you are about retarded.
purl ...but purl is <reply> ā™¬ beat on the bot // beat on the bot // beat on the bot with a baseball bat// oh yeah ā™¬ or pretty stupid, aren't you or an annoying girl or a non-intuitive answering machine...
jonathan purl: forget it
purl jonathan: I forgot it
darbelo purl: msg Whiteknight With my last push to github you can configure, build and run matrixy against an installed parrot. see nopaste.snit.ch/18357 20:21
purl Message for whiteknight stored.
darbelo purl: msg Whiteknight It will only work with a recent trunk, as I'm using the parrot_nqp fakecutable in the makefile. I can easisly make it work with earlier parrots too. 20:23
purl Message for whiteknight stored.
cotto_work We don't care about earlier parrots. We only look TO THE FUTURE.
darbelo cotto++ 20:24
Coke dukeleto: I have no idea. I think I am pretty much teh only 10.4/intel person. 20:25
Tene cotto_future++
20:27 davidfetter joined 20:28 einstein joined
darbelo purl msg dukeleto Whiteknight's matrixy now builds and runs with an installed parrot, feel free to test the heck out of it ;) 20:28
purl Message for dukeleto stored.
dukeleto darbelo: shweet! 20:29
darbelo nopaste.snit.ch/18357 is about as far as I've tested it.
dalek p-rx: 4506dba | pmichaud++ | src/Regex/P6Regex.pir:
Add a custom parse method to Regex::P6Regex::Compiler that understands cursors.
 20:47
shorten dalek's url is at xrl.us/bfsrjt
dalek p-rx: c9a4f85 | pmichaud++ | (2 files):
Clean up parse and !reduce methods.
shorten dalek's url is at xrl.us/bfsrjv
darbelo Infinoid: ping
desertm4x darbelo: I've just tested building matrixy and it worked without problems. :-) great job! 20:48
20:50 theory joined
darbelo Those were actually very minor changes, I didn't touch the code at all. 20:50
japhb darbelo: Is it now time for me to get off my butt and write the dependency handling for Plumage?
darbelo japhb: not yet, matrixy builds, but the library it'll depend on doesn't. 20:51
japhb OK.
Any expected time frame for that? 20:52
darbelo Not today?
japhb *chuckle* 20:53
OK, I guess it's not a huge rush then.
japhb goes back to taking a chainsaw to his $day_job source tree
darbelo Whiteknight should be better qualified to answer that than I am.
japhb fair enough
jonathan rakudobug? 20:58
purl i heard rakudobug was mailto:rakudobug@perl.org
dukeleto msg whiteknight i've started using the issue tracker for matrixy: github.com/Whiteknight/matrixy/issues/#issue/1 21:02
purl Message for whiteknight stored.
darbelo dukeleto: (issue 1) maybe I shuld stick to the old-style invocation? 21:07
21:21 theory joined
darbelo msg dukeleto fixed and closed your matrixy issue. It will now work with pre-1.7 parrots. 21:23
purl Message for dukeleto stored.
dukeleto darbelo: damn, you are quick!
darbelo Eh, it was an easy fix. 21:26
dalek p-rx: c381a19 | pmichaud++ | src/Regex/P6Regex/Actions.pm:
Handle quantified aliases like $<var>=(subrule)* .
 21:27
shorten dalek's url is at xrl.us/bfsrqt
dalek p-rx: 3095780 | pmichaud++ | src/Regex/Cursor.pir:
Fix Cursor.parse to return a Match object.
shorten dalek's url is at xrl.us/bfsrqv
dalek p-rx: 7c2e928 | pmichaud++ | build/Makefile.in:
Temporary bootstrap helper target.
shorten dalek's url is at xrl.us/bfsrqz
cotto_work goes home early 21:36
darbelo yay!
dalek rrot: r41890 | pmichaud++ | trunk/compilers/pct/src/PCT/Node.pir:
[pct]: Generalize the types of nodes that PCT::Node.node() understands.
 21:50
21:58 theory joined
dalek rrot: r41891 | pmichaud++ | trunk/compilers/pct/src/PCT/Node.pir:
[pct]: Error in previous commit.
 22:16
22:30 Whiteknight joined
darbelo watches an avalanche of purl-o-grams engulf an unsuspecting Whiteknight 22:31
davidfetter pretty soon he'll be talking backwards 22:32
Whiteknight awesome. loves me some messages 22:33
darbelo++ # you're a rock star
darbelo sdrawkcab gniklat s'taht uoy s'tI on ,mmH :rettefdivad 22:34
dukeleto Whiteknight: yes, he is on the ball today
Whiteknight I would have been in here like an hour ago, but the fire alarm in my apartment building went off and we had to go outside 22:35
darbelo No actual fire?
Tene we can fix that. 22:36
darbelo gets his flamethrower. 22:37
Tene but how will we light the flamethrower? We need a bootstrapping stage...
darbelo pulls his bootstraps. 22:38
Whiteknight no fire
dukeleto FIRE!
darbelo ZOMG! I knew this bootstraps were magical! 22:39
dukeleto what happens to people that yell 'FIRE!' in a crowded IRC channel, when there is no fire?
darbelo They get punished! 22:40
purl: annoy dukeleto!
purl darbelo: excuse me?
darbelo Bah, useless bot.
dukeleto purl, be useful 22:49
purl whirrs and clicks in the background. or i try dukeleto's best
darbelo purl, be useful 22:50
purl whirrs and clicks in the background.
darbelo still not useful, but less confusing.
;) 22:51
dukeleto purl, go play in traffic
purl wanders off to dent some cars.
22:54 cconstantine joined, theory joined
darbelo Whiteknight: ping 22:55
23:06 kid51 joined
kid51 mikehh ping 23:08
dalek tracwiki: v109 | jkeenan++ | WikiStart 23:10
tracwiki: Delete line in hackathon schedule referring to last week's hackathon
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/bfssa9
23:13 cconstantine joined
dalek TT #1061 closed by jkeenan++: Lists of test files duplicated. 23:14
23:25 AndyA joined 23:28 darbelo left 23:29 theory joined
kid51 msg mikehh Re: trac.parrot.org/parrot/ticket/1102 Was your changing the name of this ticket to 'pass' intentional? 23:31
purl Message for mikehh stored.
23:35 AndyA joined 23:36 AndyA joined 23:41 darbelo joined
kid51 Is there any reason why as the *owner* of a TT I would *not* get email notifications of new posts to the ticket? 23:45
I failed to receive notifications to at least one post (plus some attachments) to trac.parrot.org/parrot/ticket/1105? 23:46
23:51 Austin joined
dalek rrot: r41892 | jkeenan++ | branches/auto_libjit (6 files):
Applying to auto_libjit branch two (of three) patches submitted by plobsing in

lacking libjit.)		 23:56
23:57 TiMBuS joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!