Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-12

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:05 kid51 joined #parrot
00:23 quek joined #parrot
00:27 dalek TT #1104 created by jkeenan++: Correct erroneous reference in docs to Number PMC
00:56 dalek TT #952 closed by jkeenan++: pcc_arg_unify branch fails tests.
01:10 quek left #parrot
01:10 rhr joined #parrot
01:17 rhr joined #parrot
02:35 janus joined #parrot
02:53 rhr joined #parrot
03:14 dalek parrot: r41829 | mikehh++ | branches/pcc_reapply/src/extend.c:
03:14 dalek parrot: codetest fix - space between C keyword and open parenthesis
03:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41829/
03:17 rhr joined #parrot
03:23 cotto make test in pcc_reapply keeps getting stuck on t/op/gc.t
03:24 cotto s/test/coretest/
03:27 dalek parrot: r41830 | mikehh++ | branches/pcc_reapply/t/src/extend.t:
03:27 dalek parrot: remove TODO on passing test (passes on amd64 and i386)
03:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41830/
03:29 ash_ joined #parrot
03:29 mikehh cotto: what platform?
03:30 cotto ubuntu x86
03:32 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.
03:32 bacek_at_work buildframes=0 ftw
03:34 cotto let's see if that helps
03:34 cotto all better with that change
03:35 cotto 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 /
03:35 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
03:36 mikehh I am using my normal build options om amd64
03:36 mikehh on
03:37 cotto It's nice to see only 15 failing tests on that branch.
03:37 cotto It'll be even nicer to see 0.
03:39 mikehh see smolder #28908 (kid51 on i386) and #28910 (mikehh on amd64) that is the normal make smoke
03:46 mikehh need to take a break now - will be back later with some tests on Ubuntu 9.10 beta
04:15 payload joined #parrot
04:29 masak joined #parrot
04:34 Tene Looks like the next item to address in pcc branch is te commented block in src/pmc/continuation.pmc +248
05:15 chromatic t/op/calling.t #47 is a .tailcall problem.
05:15 chromatic Tailcall into NCI, that is.
05:20 bacek_at_work joined #parrot
05:20 chromatic Tailcall into NCI should work once Continuation's invoke() works correctly, by my reading of NCI.
05:27 Tene Yes.
05:28 JimmyZ joined #parrot
05:32 chromatic t/op/calling.t #58 looks the most promising.
05:37 chromatic The old PCC stored where the continuation's caller wanted its results; should the new PCC store the CallSignature?
05:40 TiMBuS joined #parrot
05:41 dukeleto 'ello
06:02 uniejo joined #parrot
06:05 kurahaupo joined #parrot
06:08 jrtayloriv joined #parrot
06:13 dalek parrot-plumage: 4053ee7 | leto++ | :
06:13 dalek parrot-plumage: [t] Make sanity.t use Glue.pbc instead of Glue.pir
06:13 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/4053ee7f7411204e64a209333b0724fe9b10cbfc
06:13 shorten dalek's url is at http://xrl.us/bfrxuf
06:17 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:49 dukeleto japhb: i am not sure
07:07 fperrad joined #parrot
07:36 quek joined #parrot
07:36 * chromatic wishes CallSignature had better tests on the pcc_optimize_sig branch.
07:46 dukeleto chromatic: should I add the new tests from pcc_reapply to pcc_optimize_sig ?
07:47 chromatic How many tests are there?  The file on the pcc_optimize_sig branch has 7.
07:50 dukeleto i will check
07:56 bacek joined #parrot
07:58 dukeleto msg chromatic they have exactly the same callsignature tests. what kinds of tests do you need?
07:58 purl Message for chromatic stored.
08:09 dukeleto we have some tests failing in trunk on Scientific Linux: http://smolder.plusthree.com/app/pu​blic_projects/report_details/28916
08:09 shorten dukeleto's url is at http://xrl.us/bfryba
08:15 bacek dukeleto: looks like conflict with installed parrot
08:21 dukeleto bacek: i hate that
08:21 bacek dukeleto: was I right?
08:22 dukeleto bacek: sounds probable, but I am hitting the sack. will check it out tomorrow
08:22 bacek dukeleto: ok
08:22 dukeleto bacek: happy hacking
08:27 dalek parrot: r41831 | dukeleto++ | branches/pcc_reapply/t/pmc/callsignature.t:
08:27 dalek parrot: [t] Fix a bug in some of the CallSignature tests
08:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41831/
08:28 quek left #parrot
08:28 quek joined #parrot
08:29 quek left #parrot
08:47 dalek parrot: r41832 | dukeleto++ | branches/pcc_reapply/t/pmc/callsignature.t:
08:47 dalek parrot: [t] Add test for get_pmc in CallSignature and improve instantiation test
08:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41832/
08:47 jrtayloriv joined #parrot
09:09 dalek parrot: r41833 | bacek++ | trunk/src/call/context.c:
09:09 dalek parrot: [cage] Remove duplicated Context.current_sub initialisation.
09:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41833/
09:46 slavorgn joined #parrot
10:04 donaldh joined #parrot
10:29 mokurai left #parrot
10:36 Infinoid japhb: Yep.
10:38 Infinoid japhb: but, uh... it actually worked?  When I left it, it seemed non-functional
11:16 payload joined #parrot
11:35 kid51 joined #parrot
12:09 whiteknight joined #parrot
12:11 whiteknight good morning Parrot
12:20 kid51 good morning whiteknight
12:20 kid51 Did you get moved successfully?
12:20 whiteknight kid51: yes, Thanks!
12:21 whiteknight I'm very sore, but the work is done
12:21 * kid51 off to $job
12:26 JimmyZ joined #parrot
12:41 uniejo joined #parrot
12:45 * Coke waves from the correct timezone.
13:20 whiteknight good morning Coke
13:37 mikehh joined #parrot
13:48 payload joined #parrot
13:57 Coke is it me, or did I used to get a test summary with a number of failed tests.
14:02 whiteknight Coke: Yes! I think I've been missing that too
14:05 Coke I just watned to know how many failing tests were left, and it's gone.
14:12 dalek nqp-rx: a8a7999 | pmichaud++ | src/ (4 files):
14:12 dalek nqp-rx: Code to create and capture submatches; Match objects built lazily.
14:12 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​8a79998c9def1bae4f54f4d31d92424df2a8925
14:12 dalek nqp-rx: a0c9610 | pmichaud++ |  (8 files):
14:12 shorten dalek's url is at http://xrl.us/bfry6p
14:12 dalek nqp-rx: Refactor subrule matching a bit.
14:12 dalek nqp-rx: Correct Cursor-builtins to use new !cursor_pass method.
14:12 dalek nqp-rx: <alpha> matches underscore.
14:12 dalek nqp-rx: Update specialized dump_str method to check for new Match objects.
14:12 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​0c96100455f3e1a337b5589914bfa5b30d13f88
14:12 shorten dalek's url is at http://xrl.us/bfry6t
14:12 dalek nqp-rx: 7155d02 | pmichaud++ | src/Regex/P6Regex/Actions.pm:
14:12 dalek nqp-rx: Add first (incomplete) version of <+subrule>.
14:12 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​155d023e7910364ca45bc871ce60ee111be0f10
14:12 shorten dalek's url is at http://xrl.us/bfry6x
14:12 dalek nqp-rx: 90293e5 | pmichaud++ |  (2 files):
14:12 dalek nqp-rx: Add some more built-in regexes (char classes, word boundaries, etc.).
14:12 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​0293e5e44d0e7a95911acf05ff9e059b79e7614
14:12 shorten dalek's url is at http://xrl.us/bfry6z
14:13 Psyche^ joined #parrot
14:14 edgar joined #parrot
14:24 Coke anyone with commit bits to rakudo/rakudo on github here?
14:24 * moritz raises hand
14:28 Coke moritz: I would like to have something similar setup for partcl/partcl
14:28 moritz Coke: just register a user partcl on github
14:28 Coke moritz: done. repo is already there.
14:28 Coke (dukeleto++)
14:29 Coke 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 Coke er, push my commits back to partcl/partcl
14:29 moritz when you're logged in as partcl, you can simply fork the project from coke
14:30 moritz and then in your local checkout, edit .git/config
14:30 moritz and change the 'coke' part in the URL to 'partcl'
14:30 purl moritz: that doesn't look right
14:30 moritz git pull
14:30 purl git pull is probably not slow.
14:30 moritz done
14:31 Coke that seems like a lot of work. =-)
14:31 Coke is rakudo's version control workflow documented somewhere?
14:31 moritz that's something you do once
14:32 Coke ... Then I am confused.
14:32 moritz and then you just always push to and pull from the partcl/partcl repo
14:32 * Coke finds http://wiki.github.com/rakudo/ra​kudo/frews-recommended-workflow
14:34 Coke moritz: does http://github.com/partcl/partcl change your instructions at all?
14:34 Coke (there is no coke/partcl yet.)
14:34 moritz Coke: sorry, I was using wrong assumptions
14:34 moritz so
14:35 moritz you log in as partcl, and add coke and the others as committers
14:35 moritz then you log in as coke
14:35 moritz and 'git clone $your_clone_url'
14:35 moritz hack hack hack
14:35 moritz git commit
14:35 moritz git push
14:35 purl git push is much faster than svn ci or svk push
14:38 Coke committer == "repository collaborators" ?
14:40 Coke Permission denied (publickey).
14:40 Coke (on git clone git@github.com:partcl/partcl.git
14:40 Coke oh. s/git@/coke@/ ?
14:41 Coke adding a public key...
14:42 Coke cd .ssh
14:42 Coke ls
14:42 Coke bah
14:43 szbalint you didn't do "cat id_rsa" at least :)
14:48 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:49 Coke bah. still getting permissions errors, even trying to clone coke/partcl as coke.
14:51 Coke (ok, git@ is a literal ...)
14:59 dalek partcl: 65f57fb | coke++ | README:
14:59 dalek partcl: Note new code repository.
14:59 dalek partcl: review: http://github.com/partcl/partcl/commit/6​5f57fba1a9362080ca98031a1d498143a0c5fd2
14:59 shorten dalek's url is at http://xrl.us/bfrzc5
15:02 Coke moritz++
15:03 Coke dukeleto++
15:08 rdice joined #parrot
15:20 * Coke finds the "delete repository" button.
15:20 plobsing joined #parrot
15:21 * Coke waits for step 3. Profit.
15:30 jsut_ joined #parrot
15:32 dalek partcl: 0d695c5 | coke++ | CREDITS:
15:32 dalek partcl: Mention dukeleto in CREDITS
15:32 dalek partcl: review: http://github.com/partcl/partcl/commit/0​d695c527e1cb5e13836dfc9087e044184b50f95
15:33 shorten dalek's url is at http://xrl.us/bfrzh2
16:26 dukeleto 'ello
16:31 whiteknight hello duke
16:32 dukeleto whiteknight: how goes it?
16:32 whiteknight it goes well enough
16:33 whiteknight I'm tired, hungry, sore, angry, and a little ugly. But other then that, doing swell
16:34 whiteknight you?
16:34 purl well, you is very bed in engrish too
16:38 dukeleto whiteknight: still waking up
16:38 purl waking up is probably hard to do or a strange reason to die
16:42 whiteknight yeah, i guess it is a strange reason to di
16:42 whiteknight die
16:56 * 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 #parrot
17:05 dukeleto Coke: mornin'
17:11 Coke cotto_work: anyone can post to the group, first-post moderated.
17:11 Coke dukeleto: hio
17:12 Coke dukeleto++
17:12 Coke so, seems like we're up and running with github.
17:12 Coke didn't really need to do much after your initial setup, just some personal bookkeeping.
17:12 Coke seen mdiep?
17:12 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]
17:12 Coke (that's a long nap.)
17:13 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.
17:13 Coke switched it back, nothing.
17:14 Coke 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
17:15 Coke dukeleto: Any interest in writing code? =-)
17:16 Coke I'm trying to decide if I should bail on googlecode completely.
17:17 dukeleto Coke: what kind of code?
17:17 dukeleto Coke: have you thought about migrating to the github wiki/issue tracker?
17:17 Coke cotto_work: any /member/ can send, not any one.
17:17 Coke fixed.
17:18 Coke cotto++
17:18 Coke dukeleto: 13:16 <@Coke> I'm trying to decide if I should bail on googlecode completely.
17:18 Coke yes.
17:18 Coke not sure, though.
17:20 Coke looks like the googlecode ticketing is a little more full featured.
17:20 Coke but unification is good.
17:22 dukeleto Coke: what code do you need to bail on googlecode?
17:23 Coke dukeleto: (write code) No, I meant actual "writing code for partcl" there. =-)
17:23 Coke part of my "squeeze contributors dry" plan!
17:27 Coke Is there a compelling reason to move the wiki and the issue tracker?
17:27 Coke (aside from "single point of contact" ?)
17:32 dukeleto Coke: not really.
17:33 dukeleto Coke: is there a list of beginner tasks that need doing in partcl?
17:37 Coke dukeleto: no, but I can lob one or two at you.
17:37 Coke er, yes.
17:38 Coke http://code.google.com/p/partcl/issues/list, sort by difficulty!
17:38 Coke (I already did this once!)
17:38 Coke hey, didn't you implement rand/srand in parrot?
17:38 Coke http://code.google.com/p/p​artcl/issues/detail?id=89 might be an easy one to start with.
17:40 dukeleto Coke: i refactored rand/srand into dynops
17:40 dukeleto Coke: checking that out now
17:41 dukeleto Coke: that should be reasonably simple. does tcl have both floating point and integer rand() functions, or what?
17:42 Coke http://www.tcl.tk/man/tcl8.5/TclCmd/mathfunc.htm - rand returns (0,1)
17:42 Coke (and srand takes an int.)
17:42 dukeleto Coke: that makes it easy. all we have to do is call the parrot dynop, no other pre/post processing needed
17:45 Coke dukeleto: I added some notes to the ticket.
17:46 chromatic joined #parrot
17:48 Coke chromatic: hio
17:51 Coke dukeleto++
17:52 chromatic morning/afternoon
17:52 dukeleto chromatic: happy sunny day
17:54 chromatic Maybe where you are.
17:54 chromatic Speaking of CallSignature tests, I need tests for all vtable entries that PCC exercises.
17:54 dukeleto chromatic: it is sunny at the airport. not so in Hillsboro?
17:55 chromatic If PCC pushes I, N, P, S onto the CallSignature array, great.  If it pops/shifts/unshifts them from it, great.
17:55 chromatic dukeleto, it's Novembercast here.
17:55 dukeleto chromatic: i added a callsig test to pcc_reapply last night
17:56 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?
17:56 chromatic The only reason CallSignature extends Capture is to contain an array and a hash.
17:57 chromatic 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.
18:02 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.
18:02 Tene to test the pcc stuff.
18:02 chromatic I don't want to test PCC, I want to test the CallSignature.
18:03 chromatic I'm reimplementing a CallSignature PMC that doesn't inherit from Capture.
18:03 Coke or, test it directly, not indirectly.
18:03 Tene It's just capture + a few thin wrappers around some attributes.
18:03 Coke ?
18:04 bacek joined #parrot
18:05 dukeleto chromatic: can you tell me how to test the uncovered code at http://tapir2.ro.vutbr.cz/cover/cover-results​/41833/c_cover/src-pmc-callsignature-pmc.html ?
18:05 shorten dukeleto's url is at http://xrl.us/bfrz7a
18:05 chromatic I know what it is, but I don't know which parts of Capture it uses.
18:06 chromatic 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:08 Tene fill_{params,results} uses keyed access and elements.  build_sig uses push.
18:09 chromatic How about indexed access?
18:10 Tene Yes.
18:10 Tene I somehow thought that was implied by 'keyed access', but you're right, it's not.
18:11 Tene 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?
18:12 chromatic How about set_FOO_keyed_int?
18:12 Tene Yes, bot.
18:12 Tene both
18:13 chromatic dukeleto, I could use tests for all of those.
18:13 chromatic For each register type.
18:14 Tene I think that 'exists' is used at least once.
18:15 chromatic exists_keyed or exists_keyed_int or both?
18:16 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 Tene So shouldn't all of the capture interface be tested?
18:16 chromatic I don't know the intent of CallSignature.
18:17 chromatic 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.
18:17 Tene Instead of filling params out of it, just pass the whole thing off to userspace.
18:17 chromatic Sure.  I can extend it later if necessary.
18:19 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:20 jonathan Where good = spec'd :-)
18:21 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 Tene I think I'm missing something.
18:21 Tene afk driving to work.
18:21 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.
18:21 Tene Okay.
18:22 Tene I understand now.  Thanks.
18:22 Tene (One option would be to just implement those, and see what fails when you try it. ;) )
18:22 Tene rly afk now
18:22 chromatic Lots!
18:29 joeri joined #parrot
18:38 Coke Is there a standard way to show what revision we're working against in git?
18:38 Coke (git log | head -1 seems like cheating.)
18:38 iblechbot joined #parrot
18:41 dukeleto Coke: git log -1 shows the last commit
18:43 dukeleto Coke: git rev-parse master shows you the sha1 of the master branch
18:43 dukeleto Coke: git rev-parse HEAD gives the sha1 of where ever the current branch tip is
18:45 bacek Good morning
18:45 cotto_work clock?
18:45 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 /
18:46 bacek cotto_work: it is not eve 6AM here...
18:46 cotto_work good morning to you, sleepless bacek
18:46 bacek even
18:46 dukeleto bacek: o hai
18:47 bacek dukeleto: g'day
18:47 Coke dukeleto: so if git rev-parse master NE git rev-parse HEAD, I have local mods?
18:48 dukeleto Coke: it could also mean you are on a different branch
18:49 dukeleto Coke: what are you trying to figure out? git status will tell you if you have local mods
18:50 Coke dukeleto: updating the build/testing scripts so they work with git instead of svn/git-svn
18:50 Coke (I'm not even sure we build straight out of git now.)
18:52 dukeleto Coke: yes, those probably need to be updated
18:53 dukeleto 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:54 Coke dukeleto: yes.
18:54 Coke added a generic ticket to partcl (#115) for this.
18:59 szabgab joined #parrot
19:04 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.
19:06 dukeleto Coke: this should give you enough example/inspiration : http://github.com/leto/math--gsl​/blob/master/bin/smolder_mathgsl
19:06 shorten dukeleto's url is at http://xrl.us/bfr2hc
19:40 szabgab_ joined #parrot
19:45 japhb joined #parrot
19:56 dalek nqp-rx: a1f5fa1 | pmichaud++ | src/ (2 files):
19:56 dalek nqp-rx: Initial code for detecting capture arrays.
19:56 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​1f5fa1864dc69cc97eb87b97a2b2fdf2f6329cd
19:56 shorten dalek's url is at http://xrl.us/bfr2qx
19:56 dalek nqp-rx: 8a90013 | pmichaud++ | src/ (2 files):
19:56 dalek nqp-rx: Fully handle arrayed subcaptures.
19:56 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​a90013d0f81fa6b780eb1ff877e84073263670a
19:56 shorten dalek's url is at http://xrl.us/bfr2qz
20:20 joeri left #parrot
20:21 dalek TT #1105 created by plobsing++: [PATCH] change to a libjit based frame builder
20:23 plobsing joined #parrot
20:32 payload joined #parrot
20:33 Coke plobsing: nifty.
20:34 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.
20:35 Coke I wonder if the fact that we considering using llvm for jit-like things affects that patch.
20:35 chromatic Nope.
20:36 chromatic 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.
20:37 Coke plobsing: minor nit; you add .h's to src/frame_builder.c but don't list those in the root.in
20:37 Coke (that'll break make -j)
20:43 plobsing what?
20:43 plobsing as far as I can tell, I removed included headers
20:43 chromatic They need to be dependencies of the src/frame_builder$(O) rule in the Makefile.
20:43 plobsing ok, fixing.
20:46 plobsing wait, isn't that $(GENERAL_H_FILES) ?
20:47 payload joined #parrot
20:48 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.
20:49 Tene 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:50 Tene 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.
20:51 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.
20:51 Coke s/might have/probably/
20:53 Tene oh, I get them from the from_ctx, of course.
20:55 plobsing nope, you pointed out a fault, in both trunk and my patch.
21:08 Whiteknight joined #parrot
21:09 Tene Oh, this is going to be kinda ugly, I guess.
21:10 Tene Oh, wait, maybe not.
21:10 Whiteknight TT #1105: Awesome
21:11 plobsing still working out a few kinks
21:14 Whiteknight kinks are fine, so long as all the code is mostly written
21:16 plobsing Tene: i've just updated the patch to have frame_builder$(O) only depend on directly included h files
21:17 Tene plobsing: Sorry if I confused you.  I'm talking about something completely different.
21:17 plobsing oops, sorry, that should be Coke
21:24 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 Tene This probably isn't quite right.
21:25 Tene This might be the wrong way to do this.  I have all of the args in a callsignature already.
21:27 Tene I could cheat and save the raw_returns in the callsignature when it's built.
21:27 Tene Let's see if that works...
21:29 Tene Oh, no, I think I'd have to wrap it in a cpointer... ew
21:44 Tene chromatic: I have a very evil continuation returns patch that only works for positional args... Willing to take a look at it?
21:49 dukeleto
21:49 * dukeleto says oops
21:50 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 http://nopaste.snit.ch/18324
21:50 Tene It works, though.  Kind of.  t/op/calling_58.pir passes
21:52 Tene t/op/calling_59.pir uses the same not-actually-correct thing that exceptions use, calling get_results *after* instead of before.
21:53 Tene exception handlers, that is.
21:56 GeJ Good morning everyone
21:56 Tene hi GeJ
21:57 dukeleto GeJ: howdy
22:14 chromatic Tene, I had a feeling we'd have to write code like your patch.
22:15 Tene it might get a little bit better with some changes to the abstraction.
22:16 Tene I'm also not confident that there isn't a better way.
22:17 kid51 joined #parrot
22:19 chromatic If continuations captured more of The Right Thing, it'd be easier.
22:23 Whiteknight urg, I obviously don't know enough about Continuations in Parrot
22:24 Whiteknight Tene: calling .get_results after is what we *should* have, eventually
22:24 Whiteknight but that's going to be a major refactor at some point down the right
22:24 Tene Whiteknight: Yes, that's right.
22:24 Tene Whiteknight: all I meant was that that's currently not supported outside of a special case for exception handlers.
22:24 Whiteknight yeah
22:26 Whiteknight I don't even know how continuations pass arguments. /me needs to look at that
22:27 Whiteknight what all does .get_results do? Does it let you specify an entire argument list?
22:27 Tene Whiteknight: set_args before invoke
22:28 Tene Whiteknight: yes
22:28 Whiteknight so I can do like .get_results($P0 :named('foo'), $P1 :optional, $I0 :opt_flag), etc?
22:28 Tene Yes.
22:28 Whiteknight awesome
22:29 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?
22:29 Tene ($P0 :named('foo), ...) = foo(...)
22:32 Limbic_Region joined #parrot
22:34 Whiteknight kid51: might be, yes. He has a branch on github with it all, so experimentation has been proceeding already
22:34 Whiteknight I suggest we shouldn't merge anything really until after pcc_reapply lands
22:36 Whiteknight 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?
22:39 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:40 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.
22:41 plobsing sorry about the large patch, but I can't think of a way of doing that incrementally
22:42 Topic for #parrotis now Parrot 1.6.0 "half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview
22:42 kid51 No, I agree that it made sense to do it all at once.
22:43 kid51 And I was glad to see that you included t/steps/*.t files, entries in Options.pm, etc.
22:43 mokurai joined #parrot
22:43 kid51 It was a very comprehensive job.
22:47 Whiteknight for pcc_reapply we are going to need to rip out the current framebuilder anyway
22:47 Whiteknight since the changes there don't work with the current one
22:47 Whiteknight so your patch actually gets smaller, because you're going to be adding a new frame builder, not replacing one
22:51 Whiteknight oh boy dinner! That's where I'm a viking!
22:58 cotto_work sounds spammy
22:59 rhr joined #parrot
22:59 Whiteknight actually, I'm the damn thundergod in my kitchen
23:00 patspam joined #parrot
23:01 Tene Man, now I want to go to dinner at WK's.
23:02 Whiteknight Tene: you ever come to town, I'll cook you up a masterpiece
23:02 Tene That just might happen.
23:03 Tene I used to be in PHL all the time for work.
23:03 Whiteknight awesome
23:03 * cotto_work generally stays on the left coast
23:03 Whiteknight anyway, speaking of masterpieces, what's the state of pcc_reapply today?
23:04 moritz the error summary fits on a 80x24 console ;-)
23:04 Tene parrot_config still dies, which is a big blocker for HLLs
23:05 Tene 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
23:05 treed cotto: I may have already asked, but where on the left coast?
23:06 Tene Eh, I'll just commit it, and let people revert it if they object.
23:08 Whiteknight Go Tene!
23:08 Tene Whiteknight: if you could track down some information about the parrot_config failure, that would be great.
23:09 moritz bacek had a workaround for it... let me find the nopaste
23:10 dalek parrot: r41834 | tene++ | branches/pcc_reapply (3 files):
23:10 dalek parrot: [pcc]
23:10 dalek parrot: * Handle positional returns in continuations, kind of.
23:10 dalek parrot: * This is kind of evil; feel free to revert.
23:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41834/
23:10 Whiteknight Tene: what's the failure? How do I recreate it?
23:10 Tene Whiteknight: ./parrot_config --dump
23:10 Tene NPMCA
23:11 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:12 Whiteknight chromatic: I want to rip it out anyway. We can honestly have it replaced by 1.8
23:13 allison Tene: that's actually quite clean
23:14 Tene allison: it's going to require more work if we want to support named returns, though.
23:14 Tene right now, it'll just fial badly if you try to pass nameds to a continuation
23:14 Tene I expect
23:14 allison Tene: that's reasonable
23:14 Tene reasonable for now, at least.  I expect to look at it again after we can switch the order after 2.0
23:15 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.
23:15 allison Tene: yes, this will be slimmed down after the order switch
23:15 Tene So it doesn't work.
23:15 Tene calling_58 works, though.
23:16 allison Tene: okay, I have a partial fix for calling_59 that I haven't put in het
23:16 allison yet
23:16 allison (was away this evening)
23:16 Whiteknight I wonder why t/op/lexicals.t fails
23:16 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.
23:16 Whiteknight the test all looks sane to me and doesn't look like it should be too too affected by PCC work
23:16 Whiteknight chromatic: I don't want to fix it. I want to kill it in a fire
23:17 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
23:17 allison Tene: it calls fill_params, since at that point the logic is identical to fill_params
23:17 allison Tene: okay
23:17 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.
23:18 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:19 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
23:19 Whiteknight jonathan: pure evil
23:19 purl pure evil is http://www.passport.com/Consumer/TermsOfUse.asp or The United Way.
23:20 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.
23:21 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.
23:21 jonathan chromatic: Really half? Ouch!
23:21 chromatic Half.
23:21 jonathan Wow.
23:21 jonathan Sounds like NCI thunks are what needs killing with fire. ;-)
23:22 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.
23:22 Whiteknight we can have a libJIT and an LLVM solution in trunk by 1.8
23:22 cotto_work treed, redmond, WA
23:22 jonathan chromatic: Yes, that's what I meant.
23:22 chromatic Here's my point though.
23:22 treed Ah, that's right.
23:23 chromatic We have to update any extant frame builders for pcc_reapply *anyway*.
23:23 chromatic To my knowledge, no one has done any work on updating any of them yet.
23:23 chromatic We don't know what it takes.
23:23 Whiteknight chromatic: I would rather update the right solution then update the wrong solution
23:23 Whiteknight and a portable frame builder improves our startup time on all platforms
23:24 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 Themeruta joined #parrot
23:25 Whiteknight I'mnot sure what you mean by "no one has done any work on updating any of them yet"
23:25 Whiteknight any of what?
23:25 chromatic How many of the existing or proposed frame builders work on pcc_reapply?
23:26 Whiteknight chromatic: I don't see why any of them wouldn't work
23:26 Whiteknight 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
23:26 chromatic No one has tried, as far as I know.
23:27 chromatic 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
23:27 chromatic I updated it for the Context branch.
23:27 Whiteknight we want people to do it, let them to it right
23:27 Whiteknight chromatic: well you're a better man then I am. I wouldn't do it
23:27 chromatic You're talking about regressing on a very common platform for 1.7 because you don't like how the code looks.
23:28 chromatic 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
23:28 Tene Whiteknight: We want to keep the pcc branch as minimal as possible and get it merged ASAP.
23:28 Whiteknight right, I want that too
23:29 Tene So let's *try* fixing the frame builder.
23:29 Tene If that attempt fails badly, or whatever, then we can address removing it.
23:29 Tene If we remove it, the fallback is that we can only use the precompiled thunks.
23:30 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.
23:30 chromatic Why does the frame builder come out without a working replacement?
23:30 Whiteknight because I hate it and those are my terms
23:31 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
23:31 jonathan That way, it doesn't disrupt those who are using it.
23:31 allison Tene: are you getting a compile error in PGE?
23:31 Whiteknight but that's the price of my tuits on this project
23:31 Tene allison: dunno, lemme check.
23:32 chromatic Okay, that's fair.  If no one can or wants to fix it, it stays disabled.
23:32 Tene allison: yes!  segfault!
23:32 Tene allison: did I cause that?  Feel free to revert my commit.
23:32 allison Tene: okay, wasn't sure if it was me
23:33 allison Tene: just need to wrap the access to 'raw_args' in an "if(!PMC_IS_NULL(from_obj))"
23:33 allison Tene: in Continuation's invoke
23:33 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.
23:33 Whiteknight not a "maybe", it WILL happen
23:33 Whiteknight cause and effect
23:34 allison Tene: oh, also the call to fill_returns_from_continuation
23:34 allison Tene: (I'd commit it, but I have other code in that file)
23:34 chromatic git stash
23:34 purl git stash is probably Stash the changes in a dirty working directory away
23:35 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
23:36 chromatic Probably, but simplicity trumps here.
23:41 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 kurahaupo 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?
23:42 Whiteknight what do you mean "in flight"?
23:42 kurahaupo In the middle of the C function that implements "push", for instance.
23:45 Whiteknight have a patch or something so I can see what you are talking about?
23:47 rhr joined #parrot
23:47 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:48 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 parrot: r41835 | allison++ | branches/pcc_reapply/src/pmc/continuation.pmc:
23:48 dalek parrot: [pcc] Quick fix for continuation call, only do the argument passing when the
23:48 dalek parrot: Continuation was invoked with arguments.
23:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41835/
23:49 kurahaupo So I'm focussed on arrays *other* than arrays-of-PMCs.
23:50 kurahaupo Think: laying down the floats in memory so that my GPU can work on them for me.
23:51 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.
23:52 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?
23:53 Tene the former
23:53 jonathan kurahaupo: I meant threads.
23:53 jonathan Since PMCs never get moved (e.g. by the GC) then multiple references won't be a problem.
23:53 jonathan Not much is doing threading in Parrot yet though.
23:54 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.
23:54 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"?
23:55 kurahaupo Being able to change the vtable would probably be essential to implementing a compacting GC?
23:56 kurahaupo Are we guaranteed that writing one memory word to replace the vtable pointer is threadsafe on all architectures of interest?
23:58 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 jonathan 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.
23:58 jonathan I'm hazy on how that lot works these days - sorry.

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

Parrot | source cross referenced