half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 6 October 2009.
00:05 kid51 joined 00:23 quek joined
dalek TT #1104 created by jkeenan++: Correct erroneous reference in docs to Number PMC 00:27
TT #952 closed by jkeenan++: pcc_arg_unify branch fails tests. 00:56
01:10 quek left, rhr joined 01:17 rhr joined 02:35 janus joined 02:53 rhr joined
dalek rrot: r41829 | mikehh++ | branches/pcc_reapply/src/extend.c:
codetest fix - space between C keyword and open parenthesis
 03:14
03:17 rhr joined
cotto make test in pcc_reapply keeps getting stuck on t/op/gc.t 03:23
s/test/coretest/ 03:24
dalek rrot: r41830 | mikehh++ | branches/pcc_reapply/t/src/extend.t:
remove TODO on passing test (passes on amd64 and i386)
 03:27
03:29 ash_ joined
mikehh cotto: what platform? 03:29
cotto ubuntu x86 03:30
mikehh odd - I just ran some tests there and they seemed to be ok - but I am back on amd64 at the moment 03:32
cotto meh. I'm sure it'll get fixed. It's not like I'm not running the most common platform ever.
bacek_at_work buildframes=0 ftw
cotto let's see if that helps 03:34
all better with that change
clock? 03:35
purl cotto: LAX: Sun 8:35pm PDT / CHI: Sun 10:35pm CDT / NYC: Sun 11:35pm EDT / LON: Mon 4:35am BST / BER: Mon 5:35am CEST / IND: Mon 9:05am IST / TOK: Mon 12:35pm JST / SYD: Mon 2:35pm EST /
mikehh cotto: yes - I forgot to mention that - I ran make -j test TEST_JOBS=5 with that config option on Ubuntu 9.04 i386
I am using my normal build options om amd64 03:36
on
cotto It's nice to see only 15 failing tests on that branch. 03:37
It'll be even nicer to see 0.
mikehh see smolder #28908 (kid51 on i386) and #28910 (mikehh on amd64) that is the normal make smoke 03:39
need to take a break now - will be back later with some tests on Ubuntu 9.10 beta 03:46
04:15 payload joined 04:29 masak joined
Tene Looks like the next item to address in pcc branch is te commented block in src/pmc/continuation.pmc +248 04:34
chromatic t/op/calling.t #47 is a .tailcall problem. 05:15
Tailcall into NCI, that is.
05:20 bacek_at_work joined
chromatic Tailcall into NCI should work once Continuation's invoke() works correctly, by my reading of NCI. 05:20
Tene Yes. 05:27
05:28 JimmyZ joined
chromatic t/op/calling.t #58 looks the most promising. 05:32
The old PCC stored where the continuation's caller wanted its results; should the new PCC store the CallSignature? 05:37
05:40 TiMBuS joined
dukeleto 'ello 05:41
06:02 uniejo joined 06:05 kurahaupo joined 06:08 jrtayloriv joined
dalek rrot-plumage: 4053ee7 | leto++ | :
[t] Make sanity.t use Glue.pbc instead of Glue.pir
 06:13
shorten dalek's url is at xrl.us/bfrxuf
japhb Infinoid, dukeleto, it looks like parrot-plumage needs to know about remapping leto/dukeleto for karma. Is that just a matter of fixing Parrot's CREDITS? 06:17
dukeleto japhb: i am not sure 06:49
07:07 fperrad joined 07:36 quek joined
chromatic wishes CallSignature had better tests on the pcc_optimize_sig branch. 07:36
dukeleto chromatic: should I add the new tests from pcc_reapply to pcc_optimize_sig ? 07:46
chromatic How many tests are there? The file on the pcc_optimize_sig branch has 7. 07:47
dukeleto i will check 07:50
07:56 bacek joined
dukeleto msg chromatic they have exactly the same callsignature tests. what kinds of tests do you need? 07:58
purl Message for chromatic stored.
dukeleto we have some tests failing in trunk on Scientific Linux: smolder.plusthree.com/app/public_pr...ails/28916 08:09
shorten dukeleto's url is at xrl.us/bfryba
bacek dukeleto: looks like conflict with installed parrot 08:15
dukeleto bacek: i hate that 08:21
bacek dukeleto: was I right?
dukeleto bacek: sounds probable, but I am hitting the sack. will check it out tomorrow 08:22
bacek dukeleto: ok
dukeleto bacek: happy hacking
dalek rrot: r41831 | dukeleto++ | branches/pcc_reapply/t/pmc/callsignature.t:
[t] Fix a bug in some of the CallSignature tests
 08:27
08:28 quek left, quek joined 08:29 quek left
dalek rrot: r41832 | dukeleto++ | branches/pcc_reapply/t/pmc/callsignature.t:
[t] Add test for get_pmc in CallSignature and improve instantiation test
 08:47
08:47 jrtayloriv joined
dalek rrot: r41833 | bacek++ | trunk/src/call/context.c:
[cage] Remove duplicated Context.current_sub initialisation.
 09:09
09:46 slavorgn joined 10:04 donaldh joined 10:29 mokurai left
Infinoid japhb: Yep. 10:36
japhb: but, uh... it actually worked? When I left it, it seemed non-functional 10:38
11:16 payload joined 11:35 kid51 joined 12:09 whiteknight joined
whiteknight good morning Parrot 12:11
kid51 good morning whiteknight 12:20
Did you get moved successfully?
whiteknight kid51: yes, Thanks!
I'm very sore, but the work is done 12:21
kid51 off to $job
12:26 JimmyZ joined 12:41 uniejo joined
Coke waves from the correct timezone. 12:45
whiteknight good morning Coke 13:20
13:37 mikehh joined 13:48 payload joined
Coke is it me, or did I used to get a test summary with a number of failed tests. 13:57
whiteknight Coke: Yes! I think I've been missing that too 14:02
Coke I just watned to know how many failing tests were left, and it's gone. 14:05
dalek p-rx: a8a7999 | pmichaud++ | src/ (4 files):
Code to create and capture submatches; Match objects built lazily.
 14:12
p-rx: a0c9610 | pmichaud++ | (8 files):
Refactor subrule matching a bit.

  <alpha> matches underscore.
Update specialized dump_str method to check for new Match objects.
shorten dalek's url is at xrl.us/bfry6p
shorten dalek's url is at xrl.us/bfry6t
dalek p-rx: 7155d02 | pmichaud++ | src/Regex/P6Regex/Actions.pm:
Add first (incomplete) version of <+subrule>.
shorten dalek's url is at xrl.us/bfry6x
dalek p-rx: 90293e5 | pmichaud++ | (2 files):
Add some more built-in regexes (char classes, word boundaries, etc.).
shorten dalek's url is at xrl.us/bfry6z
14:13 Psyche^ joined 14:14 edgar joined
Coke anyone with commit bits to rakudo/rakudo on github here? 14:24
moritz raises hand
Coke moritz: I would like to have something similar setup for partcl/partcl 14:28
moritz Coke: just register a user partcl on github
Coke moritz: done. repo is already there.
(dukeleto++)
but I am still a git newbie. so if I want to work in coke/partcl, and get my commits back, is there a how to guide for this sort of arrangement? 14:29
er, push my commits back to partcl/partcl
moritz when you're logged in as partcl, you can simply fork the project from coke
and then in your local checkout, edit .git/config 14:30
and change the 'coke' part in the URL to 'partcl'
purl moritz: that doesn't look right
moritz git pull
purl git pull is probably not slow.
moritz done
Coke that seems like a lot of work. =-) 14:31
is rakudo's version control workflow documented somewhere?
moritz that's something you do once
Coke ... Then I am confused. 14:32
moritz and then you just always push to and pull from the partcl/partcl repo
Coke finds wiki.github.com/rakudo/rakudo/frews...d-workflow
moritz: does github.com/partcl/partcl change your instructions at all? 14:34
(there is no coke/partcl yet.)
moritz Coke: sorry, I was using wrong assumptions
so
you log in as partcl, and add coke and the others as committers 14:35
then you log in as coke
and 'git clone $your_clone_url'
hack hack hack
git commit
git push
purl git push is much faster than svn ci or svk push
Coke committer == "repository collaborators" ? 14:38
Permission denied (publickey). 14:40
(on git clone git@github.com:partcl/partcl.git
oh. s/git@/coke@/ ?
adding a public key... 14:41
cd .ssh 14:42
ls
bah
szbalint you didn't do "cat id_rsa" at least :) 14:43
Coke ok. I forked partcl/partcl to coke/partcl at some point. if I'm pushing straight to partcl/partcl, I don't need coke/partcl. is there a way to delete it? (I see nothing obvious...) 14:48
bah. still getting permissions errors, even trying to clone coke/partcl as coke. 14:49
(ok, git@ is a literal ...) 14:51
dalek rtcl: 65f57fb | coke++ | README:
Note new code repository.
 14:59
shorten dalek's url is at xrl.us/bfrzc5
Coke moritz++ 15:02
dukeleto++ 15:03
15:08 rdice joined
Coke finds the "delete repository" button. 15:20
15:20 plobsing joined
Coke waits for step 3. Profit. 15:21
15:30 jsut_ joined
dalek rtcl: 0d695c5 | coke++ | CREDITS:
Mention dukeleto in CREDITS
 15:32
shorten dalek's url is at xrl.us/bfrzh2 15:33
dukeleto 'ello 16:26
whiteknight hello duke 16:31
dukeleto whiteknight: how goes it? 16:32
whiteknight it goes well enough
I'm tired, hungry, sore, angry, and a little ugly. But other then that, doing swell 16:33
you? 16:34
purl well, you is very bed in engrish too
dukeleto whiteknight: still waking up 16:38
purl waking up is probably hard to do or a strange reason to die
whiteknight yeah, i guess it is a strange reason to di 16:42
die
Coke tries to setup github to email commit messages to partcl-commits@googlegroups.com and get s... nothing. 16:56
cotto_work Coke, do you have to give github access to the Google group?
16:59 payload1 joined
dukeleto Coke: mornin' 17:05
Coke cotto_work: anyone can post to the group, first-post moderated. 17:11
dukeleto: hio
dukeleto++ 17:12
so, seems like we're up and running with github.
didn't really need to do much after your initial setup, just some personal bookkeeping.
seen mdiep?
purl mdiep was last seen on #parrot 266 days, 8 hours, 46 minutes and 7 seconds ago, saying: err... bed [Jan 19 08:18:08 2009]
Coke (that's a long nap.)
moritz some people do have healthy sleep 17:13
Coke (email) I changed the email address to will@coleda.com, tested, it sent the message.
switched it back, nothing.
cotto_work: actually, you might be right. 17:14
dukeleto Coke: yes, partcl should be mostly setup on github. let me know if there is anything else you need help with
Coke dukeleto: Any interest in writing code? =-) 17:15
I'm trying to decide if I should bail on googlecode completely. 17:16
dukeleto Coke: what kind of code? 17:17
Coke: have you thought about migrating to the github wiki/issue tracker?
Coke cotto_work: any /member/ can send, not any one.
fixed.
cotto++ 17:18
dukeleto: 13:16 <@Coke> I'm trying to decide if I should bail on googlecode completely.
yes.
not sure, though.
looks like the googlecode ticketing is a little more full featured. 17:20
but unification is good.
dukeleto Coke: what code do you need to bail on googlecode? 17:22
Coke dukeleto: (write code) No, I meant actual "writing code for partcl" there. =-) 17:23
part of my "squeeze contributors dry" plan!
Is there a compelling reason to move the wiki and the issue tracker? 17:27
(aside from "single point of contact" ?)
dukeleto Coke: not really. 17:32
Coke: is there a list of beginner tasks that need doing in partcl? 17:33
Coke dukeleto: no, but I can lob one or two at you. 17:37
er, yes.
code.google.com/p/partcl/issues/list, sort by difficulty! 17:38
(I already did this once!)
hey, didn't you implement rand/srand in parrot?
code.google.com/p/partcl/issues/detail?id=89 might be an easy one to start with.
dukeleto Coke: i refactored rand/srand into dynops 17:40
Coke: checking that out now
Coke: that should be reasonably simple. does tcl have both floating point and integer rand() functions, or what? 17:41
Coke www.tcl.tk/man/tcl8.5/TclCmd/mathfunc.htm - rand returns (0,1) 17:42
(and srand takes an int.)
dukeleto Coke: that makes it easy. all we have to do is call the parrot dynop, no other pre/post processing needed
Coke dukeleto: I added some notes to the ticket. 17:45
17:46 chromatic joined
Coke chromatic: hio 17:48
dukeleto++ 17:51
chromatic morning/afternoon 17:52
dukeleto chromatic: happy sunny day
chromatic Maybe where you are. 17:54
Speaking of CallSignature tests, I need tests for all vtable entries that PCC exercises.
dukeleto chromatic: it is sunny at the airport. not so in Hillsboro?
chromatic If PCC pushes I, N, P, S onto the CallSignature array, great. If it pops/shifts/unshifts them from it, great. 17:55
dukeleto, it's Novembercast here.
dukeleto chromatic: i added a callsig test to pcc_reapply last night
chromatic I'm copying behavior from Capture to CallSignature, but I'm not sure we need all of it. 17:56
dukeleto chromatic: can you nopaste an example of code that you want tested?
chromatic The only reason CallSignature extends Capture is to contain an array and a hash.
I don't have a good example; I'd have to read all of pcc to figure out everything that the CallSignature must do. I'm trolling for someone like allison, Tene, bacek, whomever who's worked on it lately to rattle off a list of likely candidates. 17:57
Tene chromatic: the best way to get callsignature tests is to get the :call_sig param and arg attribute working, letting you pass a literal callsignature pmc into and out of a call. 18:02
chromatic I don't follow.
Tene to test the pcc stuff.
chromatic I don't want to test PCC, I want to test the CallSignature.
I'm reimplementing a CallSignature PMC that doesn't inherit from Capture. 18:03
Coke or, test it directly, not indirectly.
Tene It's just capture + a few thin wrappers around some attributes.
Coke ?
18:04 bacek joined
dukeleto chromatic: can you tell me how to test the uncovered code at tapir2.ro.vutbr.cz/cover/cover-resu...e-pmc.html ? 18:05
shorten dukeleto's url is at xrl.us/bfrz7a
chromatic I know what it is, but I don't know which parts of Capture it uses.
If it's *everything*, that's one thing. If it's "only pushing and popping the contents of typed registers", that's another thing. 18:06
Tene fill_{params,results} uses keyed access and elements. build_sig uses push. 18:08
chromatic How about indexed access? 18:09
Tene Yes. 18:10
I somehow thought that was implied by 'keyed access', but you're right, it's not.
I don't mean that to be exhaustive, but that's what I've seen in the parts I've worked on. 18:11
chromatic get_keyed, set_keyed I presume?
How about set_FOO_keyed_int? 18:12
Tene Yes, bot.
both
chromatic dukeleto, I could use tests for all of those. 18:13
For each register type.
Tene I think that 'exists' is used at least once. 18:14
chromatic exists_keyed or exists_keyed_int or both? 18:15
Tene chromatic: the plan is to allow direct access to the callsig if requested, and I thought that we wanted to expose the entire capture interface to users, yes? 18:16
So shouldn't all of the capture interface be tested?
chromatic I don't know the intent of CallSignature.
I can't tell if it extends Capture for expedience or because of some grand plan of exposing a rich interface. 18:17
Tene one of the things rakudo needs it for is to do its own argument handling, by marking a parameter as :call_sig.
Instead of filling params out of it, just pass the whole thing off to userspace.
chromatic Sure. I can extend it later if necessary.
jonathan Basically, beyond that, Rakudo just wants a good, fast way to get the pos args and named args out of there for processing, probably 18:19
Where good = spec'd :-) 18:20
Tene It seems a little weird to me to want to provide some of the positional vtables, but not the rest, or some of the named vtables, but not others. 18:21
I think I'm missing something.
afk driving to work.
chromatic My goal is to get the minimal CallSignature rewrite available as soon as possible, as accurate as possible, to reclaim as much speed as possible by avoiding creating 2 + one for each argument/parameter GCables.
Tene Okay.
I understand now. Thanks. 18:22
(One option would be to just implement those, and see what fails when you try it. ;) )
rly afk now
chromatic Lots!
18:29 joeri joined
Coke Is there a standard way to show what revision we're working against in git? 18:38
(git log | head -1 seems like cheating.)
18:38 iblechbot joined
dukeleto Coke: git log -1 shows the last commit 18:41
Coke: git rev-parse master shows you the sha1 of the master branch 18:43
Coke: git rev-parse HEAD gives the sha1 of where ever the current branch tip is
bacek Good morning 18:45
cotto_work clock?
purl cotto_work: LAX: Mon 11:45am PDT / CHI: Mon 1:45pm CDT / NYC: Mon 2:45pm EDT / LON: Mon 7:45pm BST / BER: Mon 8:45pm CEST / IND: Tue 12:15am IST / TOK: Tue 3:45am JST / SYD: Tue 5:45am EST /
bacek cotto_work: it is not eve 6AM here... 18:46
cotto_work good morning to you, sleepless bacek
bacek even
dukeleto bacek: o hai
bacek dukeleto: g'day 18:47
Coke dukeleto: so if git rev-parse master NE git rev-parse HEAD, I have local mods?
dukeleto Coke: it could also mean you are on a different branch 18:48
Coke: what are you trying to figure out? git status will tell you if you have local mods 18:49
Coke dukeleto: updating the build/testing scripts so they work with git instead of svn/git-svn 18:50
(I'm not even sure we build straight out of git now.)
dukeleto Coke: yes, those probably need to be updated 18:52
Coke: does partcl send smolder reports? if so, we should update it to add sha1's. i have done it before, it ain't hard 18:53
Coke dukeleto: yes. 18:54
added a generic ticket to partcl (#115) for this.
18:59 szabgab joined
dukeleto Coke: i can probably work on partcl+github stuff tomorrow. i have family in town and won't do much hacking today 19:04
Coke roger roger. I will try to fix it up myself in the meantime, time permitting.
dukeleto Coke: this should give you enough example/inspiration : github.com/leto/math--gsl/blob/mast...er_mathgsl 19:06
shorten dukeleto's url is at xrl.us/bfr2hc
19:40 szabgab_ joined 19:45 japhb joined
dalek p-rx: a1f5fa1 | pmichaud++ | src/ (2 files):
Initial code for detecting capture arrays.
 19:56
shorten dalek's url is at xrl.us/bfr2qx
dalek p-rx: 8a90013 | pmichaud++ | src/ (2 files):
Fully handle arrayed subcaptures.
shorten dalek's url is at xrl.us/bfr2qz
20:20 joeri left
dalek TT #1105 created by plobsing++: [PATCH] change to a libjit based frame builder 20:21
20:23 plobsing joined 20:32 payload joined
Coke plobsing: nifty. 20:33
plobsing thanks. 20:34
Coke Evaluating that is beyond my C knowledge, but I know we've had complaints about breakages using our existing buildframes in the pcc_reapply branch.
I wonder if the fact that we considering using llvm for jit-like things affects that patch. 20:35
chromatic Nope.
Any frame builder will have to change with pcc_reapply. 20:36
plobsing yeah, I still use the depracted functions. I'll look into updating these.
Coke plobsing: minor nit; you add .h's to src/frame_builder.c but don't list those in the root.in 20:37
(that'll break make -j)
plobsing what? 20:43
as far as I can tell, I removed included headers
chromatic They need to be dependencies of the src/frame_builder$(O) rule in the Makefile.
plobsing ok, fixing.
wait, isn't that $(GENERAL_H_FILES) ? 20:46
20:47 payload joined
chromatic The more specific we are in our dependencies, the less we have to rebuild. 20:48
Tene okay, making a little bit of progress on continuations.
You don't need to store the callsignature directly in the continuation, you can get it from the to_ctx with Parrot_pcc_get_signature 20:49
I'm trying to figure out where to get the rest of te stuff I need, though. 20:50
chromatic It might not be available yet.
Coke plobsing: if you removed them instead of adding them, my apologies. I might have misread the sense of the patch. 20:51
Tene I need to get the arguments passed to the continuation and feed them into the results instead.
Coke s/might have/probably/
Tene oh, I get them from the from_ctx, of course. 20:53
plobsing nope, you pointed out a fault, in both trunk and my patch. 20:55
21:08 Whiteknight joined
Tene Oh, this is going to be kinda ugly, I guess. 21:09
Oh, wait, maybe not. 21:10
Whiteknight TT #1105: Awesome
plobsing still working out a few kinks 21:11
Whiteknight kinks are fine, so long as all the code is mostly written 21:14
plobsing Tene: i've just updated the patch to have frame_builder$(O) only depend on directly included h files 21:16
Tene plobsing: Sorry if I confused you. I'm talking about something completely different. 21:17
plobsing oops, sorry, that should be Coke
Tene The last thing I need is what's passed as the raw_returns parameter to the pcc functions. In core.ops, this comes from raw_returns=CUR_OPCODE in set_returns and friends. I'm trying to figure out how to get this information from the invoke vtable of continuation.pmc. 21:24
This probably isn't quite right.
This might be the wrong way to do this. I have all of the args in a callsignature already. 21:25
I could cheat and save the raw_returns in the callsignature when it's built. 21:27
Let's see if that works...
Oh, no, I think I'd have to wrap it in a cpointer... ew 21:29
chromatic: I have a very evil continuation returns patch that only works for positional args... Willing to take a look at it? 21:44
dukeleto 21:49
dukeleto says oops
nopaste "tene" at 97.117.62.135 pasted "Probably evil hack to make positional returns work with continuations. Someone else please review this." (282 lines) at nopaste.snit.ch/18324 21:50
Tene It works, though. Kind of. t/op/calling_58.pir passes
t/op/calling_59.pir uses the same not-actually-correct thing that exceptions use, calling get_results *after* instead of before. 21:52
exception handlers, that is. 21:53
GeJ Good morning everyone 21:56
Tene hi GeJ
dukeleto GeJ: howdy 21:57
chromatic Tene, I had a feeling we'd have to write code like your patch. 22:14
Tene it might get a little bit better with some changes to the abstraction. 22:15
I'm also not confident that there isn't a better way. 22:16
22:17 kid51 joined
chromatic If continuations captured more of The Right Thing, it'd be easier. 22:19
Whiteknight urg, I obviously don't know enough about Continuations in Parrot 22:23
Tene: calling .get_results after is what we *should* have, eventually 22:24
but that's going to be a major refactor at some point down the right
Tene Whiteknight: Yes, that's right.
Whiteknight: all I meant was that that's currently not supported outside of a special case for exception handlers.
Whiteknight yeah
I don't even know how continuations pass arguments. /me needs to look at that 22:26
what all does .get_results do? Does it let you specify an entire argument list? 22:27
Tene Whiteknight: set_args before invoke
Whiteknight: yes 22:28
Whiteknight so I can do like .get_results($P0 :named('foo'), $P1 :optional, $I0 :opt_flag), etc?
Tene Yes.
Whiteknight awesome
Tene in PIR, that's: 22:29
kid51 Whiteknight: If we were to create a branch to evaluate plobsing's libjit patch, would that be beneficial?
Tene ($P0 :named('foo), ...) = foo(...)
22:32 Limbic_Region joined
Whiteknight kid51: might be, yes. He has a branch on github with it all, so experimentation has been proceeding already 22:34
I suggest we shouldn't merge anything really until after pcc_reapply lands
the channel topic is...broken 22:36
plobsing if this is only going to be applied after pcc_reapply, should I be patching against that?
kid51 plobsing: I tend to think not. IMHO, pcc_reapply still needs a lot of work. I think you were correct to branch from trunk. 22:39
Tene chromatic: any ideas about the parrot_config failure in pcc_reapply? 22:40
kid51 I thought of an SVN branch because your patch is very large -- 53 pages when printed out -- and I suspect people would like to have it viewable in the repository.
plobsing sorry about the large patch, but I can't think of a way of doing that incrementally 22:41
moderator Parrot 1.6.0 "half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview 22:42
kid51 No, I agree that it made sense to do it all at once. 22:42
And I was glad to see that you included t/steps/*.t files, entries in Options.pm, etc. 22:43
22:43 mokurai joined
kid51 It was a very comprehensive job. 22:43
Whiteknight for pcc_reapply we are going to need to rip out the current framebuilder anyway 22:47
since the changes there don't work with the current one
so your patch actually gets smaller, because you're going to be adding a new frame builder, not replacing one
oh boy dinner! That's where I'm a viking! 22:51
cotto_work sounds spammy 22:58
22:59 rhr joined
Whiteknight actually, I'm the damn thundergod in my kitchen 22:59
23:00 patspam joined
Tene Man, now I want to go to dinner at WK's. 23:01
Whiteknight Tene: you ever come to town, I'll cook you up a masterpiece 23:02
Tene That just might happen.
I used to be in PHL all the time for work. 23:03
Whiteknight awesome
cotto_work generally stays on the left coast
Whiteknight anyway, speaking of masterpieces, what's the state of pcc_reapply today?
moritz the error summary fits on a 80x24 console ;-) 23:04
Tene parrot_config still dies, which is a big blocker for HLLs
I have a fix for continuation return passing, but it's kind of evil. 23:05
Whiteknight i saw that fix, it's not too evil
treed cotto: I may have already asked, but where on the left coast?
Tene Eh, I'll just commit it, and let people revert it if they object. 23:06
Whiteknight Go Tene! 23:08
Tene Whiteknight: if you could track down some information about the parrot_config failure, that would be great.
moritz bacek had a workaround for it... let me find the nopaste 23:09
dalek rrot: r41834 | tene++ | branches/pcc_reapply (3 files):
[pcc]

  * This is kind of evil; feel free to revert.		 23:10
Whiteknight Tene: what's the failure? How do I recreate it?
Tene Whiteknight: ./parrot_config --dump
NPMCA
chromatic We don't need to rip out the current frame builder for pcc_reapply. We need to change it in three or four small places. 23:11
Whiteknight chromatic: I want to rip it out anyway. We can honestly have it replaced by 1.8 23:12
allison Tene: that's actually quite clean 23:13
Tene allison: it's going to require more work if we want to support named returns, though. 23:14
right now, it'll just fial badly if you try to pass nameds to a continuation
I expect
allison Tene: that's reasonable
Tene reasonable for now, at least. I expect to look at it again after we can switch the order after 2.0
allison Tene: does this cover both t/op/calling_59.pir and t/op/calling_58.pir? 23:15
Tene allison: calling_59 relies on the same "get_results after the call" that exception handlers require.
allison Tene: yes, this will be slimmed down after the order switch
Tene So it doesn't work.
calling_58 works, though.
allison Tene: okay, I have a partial fix for calling_59 that I haven't put in het 23:16
yet
(was away this evening)
Whiteknight I wonder why t/op/lexicals.t fails
chromatic Whiteknight, if it's impossible to fix in a couple of hours, that's one thing. Ripping it out now because we believe we can fix it by adding an external dependency by 1.8 is another thing.
Whiteknight the test all looks sane to me and doesn't look like it should be too too affected by PCC work
chromatic: I don't want to fix it. I want to kill it in a fire
Tene allison: it also doesn't fix calling_47 23:17
Whiteknight And we already have a built-in replacement in terms of compiled-in thunks
allison Tene: it calls fill_params, since at that point the logic is identical to fill_params
Tene: okay
chromatic I don't know how to characterize compiled-in thunks any better than a non-scalable, bloated hack that's grown out of hand and still doesn't work properly.
Whiteknight chromatic: I dont know how to characterize the current frame-builder any better then a non-scalable, bloated hack that's grown out of hand and still doesn't work properly 23:18
jonathan If we combine the two, is it twice as bad, or do they cancel each other out? ;-) 23:19
Whiteknight okay, maybe it's not as bloated, but it is definitely more buggy and less complete
jonathan: pure evil
purl pure evil is www.passport.com/Consumer/TermsOfUse.asp or The United Way.
chromatic Definitely not as bloated. 23:20
jonathan I think a frame-builder approach is the right way forward, but I'd not be surprised if the current one is less than awesome too.
chromatic Half of our startup time and half of our PMC cost goes to registering NCI thunks we almost *never* use. 23:21
jonathan OTOH, getting hold of the args should be easier after pcc_reapply.
chromatic: Really half? Ouch!
chromatic Half.
jonathan Wow.
Sounds like NCI thunks are what needs killing with fire. ;-)
Whiteknight chromatic: nobody wants NCI thunks to stay, but I'm saying we can replace the frame builder with speed and gusto 23:22
chromatic Static thunks, yes.
Whiteknight we can have a libJIT and an LLVM solution in trunk by 1.8
cotto_work treed, redmond, WA
jonathan chromatic: Yes, that's what I meant.
chromatic Here's my point though.
treed Ah, that's right.
chromatic We have to update any extant frame builders for pcc_reapply *anyway*. 23:23
To my knowledge, no one has done any work on updating any of them yet.
We don't know what it takes.
Whiteknight chromatic: I would rather update the right solution then update the wrong solution
and a portable frame builder improves our startup time on all platforms
chromatic That means 1) I can't say with certainty "It's trivial to update the extant frame builder" and 2) you can't say with certainty "These will definitely land for 1.8". 23:24
23:24 Themeruta joined
Whiteknight I'mnot sure what you mean by "no one has done any work on updating any of them yet" 23:25
any of what?
chromatic How many of the existing or proposed frame builders work on pcc_reapply?
Whiteknight chromatic: I don't see why any of them wouldn't work 23:26
it's going to be much easier to make them work in any case. NCI functions don't use :optional, :opt_flag, :named. :slurpy, etc
chromatic No one has tried, as far as I know.
We don't know how much work it is. 23:27
Whiteknight chromatic: that's because the current frame builder is shit-ugly and nobody would be caught dead doing it
chromatic I updated it for the Context branch.
Whiteknight we want people to do it, let them to it right
chromatic: well you're a better man then I am. I wouldn't do it
chromatic You're talking about regressing on a very common platform for 1.7 because you don't like how the code looks.
If we're going to regress on a very common platform, I want a better reason. 23:28
Whiteknight so lets pull it out right after 1.7 and have the replacement in for 1.8
Tene Whiteknight: We want to keep the pcc branch as minimal as possible and get it merged ASAP.
Whiteknight right, I want that too
Tene So let's *try* fixing the frame builder. 23:29
If that attempt fails badly, or whatever, then we can address removing it.
If we remove it, the fallback is that we can only use the precompiled thunks.
Whiteknight Okay, I'll strike a bargain: I'll personally fix the frame builder on pcc_reapply, regardless of the time commitment, before the merge. In return, the frame builder comes out on tuesday afternoon 23:30
Tene So first we *try* updating it. Until we try, we really don't know. If we *can* get it updated without too much pain, then we should merge it as is.
chromatic Why does the frame builder come out without a working replacement?
Whiteknight because I hate it and those are my terms
jonathan If replacing it will be so quick after the branch is merged, why not have a short lived branch to replace it? 23:31
Whiteknight you're free to spend your tuits in a different way, if you see fit
jonathan That way, it doesn't disrupt those who are using it.
allison Tene: are you getting a compile error in PGE?
Whiteknight but that's the price of my tuits on this project
Tene allison: dunno, lemme check.
chromatic Okay, that's fair. If no one can or wants to fix it, it stays disabled. 23:32
Tene allison: yes! segfault!
allison: did I cause that? Feel free to revert my commit.
allison Tene: okay, wasn't sure if it was me
Tene: just need to wrap the access to 'raw_args' in an "if(!PMC_IS_NULL(from_obj))" 23:33
Tene: in Continuation's invoke
Whiteknight I'll just reiterate: If the frame builder comes out on Tuesday afternoon, there will be a replacement in by 1.8 with support for both libJIT and LLVM.
not a "maybe", it WILL happen
cause and effect
allison Tene: oh, also the call to fill_returns_from_continuation 23:34
Tene: (I'd commit it, but I have other code in that file)
chromatic git stash
purl git stash is probably Stash the changes in a dirty working directory away
allison Tene: well, it's only one line, I'll delete that and commit the quick fix 23:35
Tene chromatic: you mean git add -p
chromatic Probably, but simplicity trumps here. 23:36
kurahaupo I've been thinking about different array implementations and their trade-offs, which lead me to wonder about changing the implementation mid-flight as it were. 23:41
What are the risks and caveats of pivoting the vtable of a PMC "in flight"? Other than making sure that both object-types have the same sizeof, and that all the new fields are set up sensibly based on the old ones, what else needs to be taken care of?
Whiteknight what do you mean "in flight"? 23:42
kurahaupo In the middle of the C function that implements "push", for instance.
Whiteknight have a patch or something so I can see what you are talking about? 23:45
23:47 rhr joined
jonathan kurahaupo: Main risk I can see is if the PMC was to be shared and there wasn't locks taken to make sure nothing else was in another v-table function... 23:47
kurahaupo This came from reading last month's parrot-dev discussion on auto-converting fixed arrays to resizable ones. But I'm thinking of implementing "SmallArray", where the values are all stored in the PMC, and "LargeArray" where they're stored in a separate chunk of memory. The point is that using arrays as tuples doesn't get penalized by the space overhead for supporting resizing efficiently, so one can implement tensor arithmetic efficiently. 23:48
dalek rrot: r41835 | allison++ | branches/pcc_reapply/src/pmc/continuation.pmc:
[pcc] Quick fix for continuation call, only do the argument passing when the
kurahaupo So I'm focussed on arrays *other* than arrays-of-PMCs. 23:49
Think: laying down the floats in memory so that my GPU can work on them for me. 23:50
Whiteknight converting PMCs from one type to another isn't usually as easy as just switching vtables 23:51
kurahaupo I guessed that might be the case.
Whiteknight you would need to reallocate the ATTRs structure if they are different sizes 23:52
kurahaupo What does "shared" mean in this context? Like threads, or just generally multiple references?
Tene the former 23:53
jonathan kurahaupo: I meant threads.
Since PMCs never get moved (e.g. by the GC) then multiple references won't be a problem.
Not much is doing threading in Parrot yet though.
kurahaupo I would be looking to make the threshhold between "SmallArray" and "LargeArray" be such that the elements of SmallArray were the same size as the ATTR's needed for LargeArray. 23:54
bacek_at_work jonathan, they are not moved for now. I hope we will have compacting GC in future.
kurahaupo Is there a thread-lock primative, or is it a case of replacing the vtable with "everyone else spin while I work on completing this"?
Being able to change the vtable would probably be essential to implementing a compacting GC? 23:55
Are we guaranteed that writing one memory word to replace the vtable pointer is threadsafe on all architectures of interest? 23:56
jonathan kurahaupo: I'm not sure what the Right Way to handle that lot is. I think the share vtable method may actually by default cause a lock to be required for the whole PMC and thus any vtable method called takes it. 23:58
So that'd make such a thing safe I guess. But in that case you'd probably have to make sure you swapped in an updated shared version of the vtable.
I'm hazy on how that lot works these days - sorry.

Powered by Cro and the Raku® Programming Language.

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

Thank you!