Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 quek joined #parrot
00:06 Zak joined #parrot
00:16 allison Tene: it's after 1am here, so I'm wrapping up. The logic is in place, I'll work on debugging the last bits tomorrow (unless you beat me to it)
00:16 chromatic I get lots more than 70 failures.
00:17 darbelo chromatic: did you --buildframes=0 ?
00:17 quek left #parrot
00:17 chromatic Oh, no.  Hang on.
00:18 quek joined #parrot
00:18 dalek parrot: r41779 | bacek++ | trunk/src/pmc/sub.pmc:
00:18 dalek parrot: [cage] Don't use C strings in Sub.get_regs_used.
00:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41779/
00:18 dalek parrot: r41780 | bacek++ | trunk/src/runcore/profiling.c:
00:18 dalek parrot: [cage] Reduce scope for C string in runcore_profile_init.
00:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41780/
00:22 cotto_work on which platforms is buildframes=0 necessary?
00:22 cotto_work non-x86/x64?
00:22 darbelo non-darwin x86
00:23 darbelo the frame builder only knows about x86 and braks on darwin.
00:23 darbelo s/braks/breaks/
00:23 chromatic Much better.
00:26 chromatic Let's see if this fixes any tests.
00:26 Tene cotto_work: buildframes=0 is only needed on platforms that would normally try to use the remnants of the jit to build frames.
00:26 cotto_work oic
00:28 dalek parrot: r41781 | chromatic++ | branches/pcc_reapply/src/call/args.c:
00:28 dalek parrot: [pcc] Fixed compiler warnings in fill_results() -- especially switching *over*
00:28 dalek parrot: the setting of a variable used to determine from where to pull results.
00:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41781/
00:29 cotto_work what's needed to make make test run tests in parallel?  I've set TEST_JOBS=9 and am passing -j to make
00:29 chromatic That should do it, if you have a Test::Harness 3.14 or newer.
00:29 chromatic Maybe 3.10 or newer.
00:30 cotto_work thanks
00:30 cotto_work there it is.
00:31 payload joined #parrot
00:34 cotto_work I don't like how more recent versions of Test::Harness omit the total number of failed tests.
00:34 bacek joined #parrot
00:37 cotto_work It appears there's still an old Parrot release in CPAN: http://search.cpan.org/~mdiep/parrot-0.4.11/
00:38 darbelo s/old/ancient/
00:39 cotto_work easy typo.  the letters are right next to each other.
00:39 darbelo :)
00:42 darbelo It has ** UNAUTHORIZED RELEASE ** in big, bold, red letters.
00:42 darbelo He has better marketing than us...
00:44 mikehh pcc_reapply - make spectest_smolder #28774 at r41781 - Ubuntu 9.04 amd64
00:44 mikehh 6,436 ok, 67 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded
00:45 chromatic Did r41781 clear up your warnings, mikehh?
00:46 mikehh chromatic: yes - the last run was g++ - and as I am on amd64 don't need buildframes=0
00:47 mikehh using the same config options as I use in trunk
00:47 chromatic Did it change the test count at all?
00:47 mikehh +6 tests
00:47 dalek parrot: r41782 | darbelo++ | trunk/config/gen/crypto/digest_pmc.in:
00:47 dalek parrot: Kill several unnecessary strstart uses with one stone.
00:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41782/
00:47 dalek rakudo: 1b83557 | moritz++ | t/spectest.data:
00:47 dalek rakudo: we pass t/spec/S06-signature/introspection.t, jnthn++
00:47 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​b835575694653a394944ae24fec731f7e286e1c
00:47 shorten dalek's url is at http://xrl.us/bfrd3s
00:50 mikehh 25 of the test failures are in t/oo/composition.t which drops out in test 21 - I think it segfaults
00:51 mikehh Parse errors: Bad plan.  You planned 45 tests but ran 20
00:52 chromatic Tene, allison, some of the t/pmc/sub.t failures are in :immediate subs that don't return anything.  If they return something, they get replaced with the cached value.  Something's not returning PMCNULL in those cases appropriately.
00:52 Tene chromatic: can you write a minimal test case?
00:53 Tene I'll look at it immediately, if so.
00:53 chromatic t/pmc/sub_37.pir
00:54 Tene on it.
00:54 mikehh ok 20 - class has a method
00:54 mikehh Null PMC access in elements()
00:54 mikehh current instr.: 'conflict_resolution_by_exclusion' pc 815 (t/oo/composition.t:204)
00:54 mikehh called from Sub 'main' pc 83 (t/oo/composition.t:29)
00:55 Tene chromatic: what is :postcomp ?
00:55 darbelo post-compilation?
00:55 chromatic Run this sub after compiling the whole file.
00:55 Tene Ah, not required to make it fail.
00:55 mikehh the other problem test for me id t/op/calling.t
00:55 mikehh t/op/calling.t                     (Wstat: 4864 Tests: 95 Failed: 19)
00:55 Tene if it's :immediate and :postcomp, it just runs twice.
00:55 mikehh Failed tests:  35, 47, 52-55, 57-59, 61, 72, 74, 81-82
00:56 mikehh 84, 88-89, 93, 95
00:56 chromatic It *should* run twice, yes.
00:56 chromatic It doesn't, because the :immediate run doesn't return PMCNULL.
00:56 Tene Right, okay.
00:56 chromatic Although....
00:57 chromatic Want a forehead slapper?
00:58 cotto_work prepare for facepalm...
00:58 chromatic The problem's in run_sub().  src/packfile.c:670.
00:58 chromatic I'll give you a moment to think about it.
00:59 Tene I don't understand any of the packfile stuff.
00:59 chromatic That's irrelevant.
00:59 mikehh PMC              *retval;
01:00 chromatic Uninitialized value.
01:00 chromatic Pointer to that value passed into PCC.
01:00 chromatic If PCC doesn't set the pointed-to value....
01:00 Tene Ah, nice.
01:00 chromatic ... which it doesn't....
01:00 dalek parrot: r41783 | chromatic++ | branches/pcc_reapply/src/packfile.c:
01:00 dalek parrot: [pcc] Initialized the PMC return value in run_sub() to PMCNULL explicitly.
01:00 dalek parrot: This way, when PCC doesn't set a return value in those cases where the invoked
01:00 dalek parrot: sub doesn't have a return value, the return value will be PMCNULL, not whatever
01:00 dalek parrot: random junk is on the stack that is almost assuredly not a -- and is definitely
01:00 dalek parrot: not the -- valid PMC.
01:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41783/
01:04 Tene fill_returns_from_c_args needs to be updated to use fill_results
01:04 Tene I don't know how to test the c_args versions, though
01:07 kid51 joined #parrot
01:15 dalek parrot: r41784 | jkeenan++ | branches/detect_llvm (2 files):
01:15 dalek parrot: Refactor more code into _handle_component_version_output() and _cleanup_llvm_files().  Add tests to improve coverage.
01:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41784/
01:15 mikehh pcc_reapply - make spectest_smolder #28778 at r41783 - Ubuntu 9.04 amd64
01:16 mikehh bbiab
01:20 rhr joined #parrot
01:26 MoC joined #parrot
01:34 darbelo left #parrot
01:41 dalek parrot: r41785 | jkeenan++ | branches/detect_llvm (2 files):
01:41 dalek parrot: Refactor code into _handle_native_assembly_output() and add tests.
01:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41785/
01:50 chromatic I wonder if t/oo/composition.t fails because NCI hasn't converted yet.
01:56 bacek Yay. As I expected. pcc_reapply much nice, cleaner and _slower_ on op-op invocations.
01:56 bacek micer
01:56 bacek nicer
01:57 nopaste "bacek" at 114.73.170.127 pasted "callgrind result for simple call." (49 lines) at http://nopaste.snit.ch/18285
01:58 bacek and it's almost "unfixable" by design.
02:07 bacek (9730587 - 9208895)/9208895
02:07 purl 0.0566508793943247
02:14 nopaste "bacek" at 114.73.170.127 pasted "Side-by-side pcc_reapply vs trunk of examples/benchmark/fib.pir" (37 lines) at http://nopaste.snit.ch/18288
02:15 bacek purl: 12,849,174,523/5,024,202,920
02:15 purl bacek: excuse me?
02:15 TiMBuS joined #parrot
02:15 bacek purl: 12849174523 / 5024202920
02:15 purl 2.55745532726214
02:15 bacek 2.5 times slower on fib.pir
02:15 bacek chromatic: good luck with making pcc faster :-/. http://nopaste.snit.ch/18288
02:16 chromatic 2.5 times slower?
02:16 bacek chromatic: yes. I can explain why.
02:18 chromatic Go ahead.
02:18 bacek on trunk passing args do direct copying from caller Context to callee Context without creating lots of GC objects.
02:18 bacek for op-op invokation
02:19 chromatic The CPointer PMC, for example?
02:19 bacek on pcc_reapply for every single call CallSignature created, arguments copied to it, then copied from it to callee Context
02:19 bacek yes, CPointer
02:19 purl CPointer is very simple and could certainly have more features added (rather than making another PMC that does mostly the same things)
02:20 bacek and because VTABLE calls can't be inlined by compiler it adds even more overhead.
02:21 chromatic 52.26% of the fib benchmark is beneath Parrot_set_args_pc.
02:21 bacek chromatic: in trunk?
02:21 chromatic Almost all of that is under Parrot_pcc_build_sig_object_from_op.
02:21 chromatic On the branch.
02:24 chromatic If we cached those signature objects... we know them at compile time.
02:24 bacek looks about all right. trunk doesn't require to build such complex structure.
02:24 bacek CallSignatures can't be constant
02:24 chromatic Then we're doing something very, very wrong with a register-based VM.
02:25 bacek build_sig_object fill CallSignature with real values.
02:25 bacek chromatic: indeed
02:27 quek left #parrot
02:28 quek joined #parrot
02:28 quek left #parrot
02:29 bacek anyway, from my pov, trunk's code is much better than branch. At least it faster.
02:30 chromatic Trunk's code is a huge, unmaintainable mess.
02:30 chromatic Every time I try to do something with it, I wind up confused and upset.
02:30 bacek Because there is a lot of useless functions.
02:31 chromatic Not just that.
02:31 purl not just that is it
02:31 chromatic There are several different ways to do the same thing, each slightly different.
02:31 bacek "a lot of useless functions"
02:31 bacek we can just unify them without changing whole param passing algorithm.
02:33 bacek purl: 1177-808
02:33 purl 369
02:33 bacek 369 lines of code in fill_params in branch. Small, nice and comprehensible function.
02:33 chromatic Remember though that trunk doesn't do everything that Rakudo needs, for example.
02:34 bacek for example?
02:34 chromatic I don't know the specific details, but something about named parameter passing was very wrong.
02:35 bacek It's still wrong.
02:35 chromatic It's a work in progress.
02:35 JimmyZ joined #parrot
02:36 janus joined #parrot
02:36 bacek And after converting contexts to PMC I added introspection function for getting raw signatures. So they are accessible from PIR for manual processing
02:36 bacek already.
02:36 chromatic I don't think Rakudo wants to get into that business though.
02:37 bacek And Rakudo will have to implement manual processing anyway. To support "sub foo($a where { $_ == 42 })"
02:37 bacek or handle named args with same name
02:38 bacek anyway, rl time.
02:38 chromatic We'll have to unify CallSignature and context at some point.
02:39 bacek I doubt that we need "CallSignature".
02:39 chromatic Yeah.
02:41 bacek set_args can just store pointer to raw signature in Context for "extended handling"
02:41 bacek ah. It's already in Interp.
02:42 chromatic We already know signatures for all PIR invocations anyway, and they're by far the most common calls.
02:42 bacek we can just expose current_args from Interp.
02:42 bacek "CallSignature" isn't signature only.
02:43 bacek It carries values
02:43 chromatic That part I don't understand.
02:43 chromatic For PIR <-> PIR invocations, that doesn't make sense to me.
02:43 bacek CallSignature extend capture. build_sig_object copies values inside
02:44 bacek chromatic: I started with it. That's why branch 2.5 times slower
02:44 bacek "Unification for the win"
02:44 chromatic Sure, but we also can't fall into the Parrot 2002 - 2006 trap of speed uber alles.
02:47 bacek "Parrot 2.0 business ready. You just have to buy few Crays"
02:48 chromatic Remember that the branch isn't finished and no one's done any optimization, though.
02:48 bacek It's not about code optimisation... It's slow by design.
02:48 chromatic If we avoid the copy in the standard PIR <-> PIR case, it doesn't have to be slow.
02:49 dalek parrot: r41786 | jkeenan++ | branches/detect_llvm (2 files):
02:49 dalek parrot: Refactor code into _examine_llvm_gcc_version().  Add corresponding tests.
02:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41786/
02:49 bacek yeap. But it's unified.
02:49 bacek anyway, I really have to go.
02:49 bacek See you soon
02:49 chromatic au bientot
02:56 joeri left #parrot
03:16 plobsing joined #parrot
03:18 rhr joined #parrot
03:18 dalek parrot: r41787 | jkeenan++ | branches/detect_llvm/config/auto/llvm.pm:
03:18 dalek parrot: Correct misleading error message.
03:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41787/
03:22 TiMBuS joined #parrot
04:42 jrtaylor joined #parrot
05:12 kyle_l5l joined #parrot
05:14 jrtaylor joined #parrot
05:49 fperrad joined #parrot
06:03 dalek parrot: r41788 | fperrad++ | trunk/tools/install/smoke_languages.pl:
06:03 dalek parrot: [languages] in installed tree, try to find an executable "parrot-lang".
06:03 dalek parrot: If not exist, use "parrot lang.pbc".
06:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41788/
06:43 mikehh pre/post-config, smoke (#28791) PASS, fulltest FAIL at r48788 - Ubuntu 9.04 amd64
06:43 mikehh fulltest (testf, testg and testS) (same tests FAIL, same results)
06:43 mikehh t/compilers/imcc/syn/macro.t - Failed tests:  2-4
06:43 mikehh t/compilers/imcc/syn/regressions.t - Failed test:  7
06:43 patspam joined #parrot
06:43 mikehh bahy that's r41788
06:45 chromatic allison, Tene: Parrot_call_sub_ret_* is broken when calling MultiSubs.  You can't dereference them to switch the constant table in the current context until you've dispatched to them to figure out the appropriate sub.
06:46 allison chromatic: checking to see if Parrot_call_sub_ret_* have been updated yet...
06:46 chromatic They have; there are notes in there.  I think the constant switching code is new.
06:47 allison chromatic: yeah, they are using call signatures, taking a look to see when the constant switching was added
06:48 allison chromatic; (because that should be done inside the sub's invoke, which would delay it until after multisub dispatch
06:48 chromatic Exactly.
06:49 chromatic With that change in place, t/src/extend.t #16 still fails, but it looks like it fails inside CallSignature processing, which is a much better place to fail at the moment.
06:50 allison chromatic: it was r41654
06:51 allison chromatic: but no explanation of why other than "reclaiming failing tests"
06:51 allison chromatic: so it could have been a cosmetic fix for a deeper problem
06:51 chromatic It's definitely not correct.
06:51 allison chromatic: (that often happens in branch debugging, a quick fix is actually the wrong fix)
06:51 chromatic I wonder, though.
06:52 chromatic When handling incoming arguments, does anything need to access PBC constants of the invokee?
06:52 allison chromatic: are you failing additional tests when you revert the change?
06:52 allison chromatic: bacek put in some code that did
06:52 allison chromatic: but I need to remove it
06:52 chromatic I can't get an accurate count of failing tests.  Test::Harness stopped summarizing failures for some reason I do not understand.
06:53 allison chromatic: it has to do with cloning key args
06:53 allison chromatic: oh, cotto was complaining about that, said it was related to the version of Test::Harness
06:54 allison chromatic: the current code is cloning the weird register based keys on the param side, when it should do it on the arg side
06:54 allison chromatic: (and may I say that register based keys are a filthy hack and a premature optimization)
06:55 chromatic Wouldn't surprise me.  All of PCC seems overcomplex to me.
06:55 allison chromatic: there is absolutely no reason to store the key value as an integer index to a register number
06:55 allison chromatic: no, this is old code
06:56 allison chromatic: which part seems complex? the function pointers or the duplication?
06:56 allison chromatic: we're kind of half-way between the two at the moment, and I'm not sure which is the lesser of two evils
06:57 chromatic I don't mean the current implementation; I understand it's a work in progress.
06:57 allison chromatic: aye totally agreed on the old code
06:57 allison chromatic: the new code is more complex than I'd like it to be
06:58 chromatic It seems like it does a lot of work even for the simple case of a caller passing positionals to a callee expecting positionals.
07:00 allison chromatic: if that was all we had, the code would be pretty simple
07:01 chromatic Sure, I understand that.
07:01 allison chromatic: the complexity comes with checking for all the weird options
07:01 allison chromatic: I think we can simplify the maintenance by breaking down the common repeated behaviors into a few smaller functions
07:02 chromatic Maintenance isn't my primary concern here.
07:02 allison chromatic: so someone can read over the top level in a  few lines
07:02 allison chromatic: ah, but it is, in the sense that it will help us evaluate execution complexity too
07:03 chromatic Here's the thing though.
07:03 allison chromatic: the version just before this one was a finite state machine on a fixed integer array
07:03 allison it only checked flags and performed some action based on those flags
07:04 allison this one is more complex, but basically the same idea
07:04 allison so, a lot of the code never runs
07:04 chromatic The amount of code isn't my primary concern.
07:04 chromatic It's moving lots of data around, trying to decide whether to run code.
07:04 allison i.e. you only get the cost of a slurpy if you use a slurpy
07:05 allison yes, the new version of the code moves a lot more data
07:05 chromatic You still have to pay the cost of deciding if you use a slurpy.  That's the part that worries me.
07:05 allison it had to, to exactly duplicate the semantics of the old calling conventions
07:05 allison deciding if you use a slurpy is still a straight integer check
07:06 allison (more to the point, a bit on an integer check)
07:06 chromatic ... after you've paid the cost of building a CallSignature and moving register values around.
07:06 allison yup
07:07 chromatic Going from PIR with positionals to PIR with positionals, we don't need any of that.
07:08 allison chromatic: aye, it does increase execution cost in some cases, to vastly reduce it in others
07:08 chromatic Where does it vastly reduce it?
07:08 allison chromatic: once we have the code passing all tests, I'd like to run some benchmarks
07:08 allison chromatic: it vastly reduces it in the general pcc case
07:08 chromatic Not by the fib.pir benchmark.  That's 2.5 times slower on branch versus trunk.
07:09 allison chromatic: good to know
07:09 allison chromatic: what features does it use?
07:09 chromatic PIR <-> PIR with positionals
07:10 allison okay, I would expect it to be somewhat slower there
07:10 chromatic I shouldn't even pluralize positional.  It passes an int and returns an int.
07:10 allison though, not that much slower
07:11 allison the advantage of the old system for straight PIR-to-PIR calls is that it did a straight register copy between the two
07:11 allison (the speed advantage)
07:11 chromatic There shouldn't even be a register copy, I think.
07:12 allison chromatic: there has to be, since the two use different register sets
07:12 chromatic Unless you mean 1) create a context 2) fill in registers in that context
07:12 allison yes, 1) create sub's context 2) copy arg registers from caller context to param registers of sub's context
07:13 allison but that very simplicity was exactly what was killing us in every other type of call
07:13 chromatic I don't think it had to, if we were clever about it.
07:13 allison because it meant every thing else had to pretend to be a register-to-register transfer
07:14 chromatic Take slurpy, for example.
07:14 chromatic Caller passes 10 PMCs.
07:14 chromatic Callee takes two as params and the rest as slurpy.
07:14 chromatic For the sake of argument, imagine the calling conventions are P1, P2, ... P10.
07:15 chromatic Callee says "Oh, slurpy at P3."  It creates its own slurpy PMC, gobbling P3.  It inserts that slurpy into P3, noting that it also accesses P4 - P10, and sets the counter for number of PMC registers used in passing parameters to note that it's consumed the rest.
07:16 allison what counter?
07:16 purl counter is some dumb thing having to do with the web, cause for immediate kicking.
07:16 chromatic Presumably some integer register keeps track of the number of PMC registers used.
07:17 allison right, but my question is where is it stored?
07:17 chromatic What is "it" in this context?
07:17 allison the note for how many registers were used
07:17 allison the most obvious would be "it just lives inside the param allocation function"
07:18 chromatic In an integer register.
07:18 allison but, the information is needed outside the function
07:18 chromatic Why is it needed outside the function?
07:18 allison chromatic: then how do you determine what register it was stored in
07:19 allison chromatic: what I'm getting at is that we need a record of the call state
07:19 allison the old system had a call state struct
07:19 allison the new system has call signature objects
07:19 allison but, no matter what we do, we can't get around the fact that we need some way of storing call state information
07:20 allison what was stored where and how, and how to retrieve it on the other side
07:20 chromatic Why does anything outside of the invoked function need to know what register that function maps any parameter to?
07:21 allison there's two sides to every call
07:21 allison and they have to communicate
07:21 chromatic That's what calling conventions are for, sure.
07:21 allison right
07:22 allison but there's more information than simply dumping a bunch of registers from one side to another
07:22 chromatic Why?
07:22 allison (different types of registers for one)
07:22 chromatic I'm not playing devil's advocate here.
07:22 allison I know
07:22 allison every problem has a certain fundamental level of complexity
07:22 allison I'm trying to explain what that is here
07:23 chromatic Why is it not the callee's side to manipulate what it gets into what it wants?
07:23 iblechbot joined #parrot
07:23 allison you can move the complexity around, but you can't just make it disappear
07:23 chromatic You can make some of it disappear.
07:23 allison chromatic: you can put all the complexity on the callee's side
07:24 allison chromatic: but it makes for much worse code, and doesn't actually reduce the overall complexity
07:24 chromatic That sounds like a generalization.
07:24 chromatic How does it make the code worse?
07:24 allison I'm starting with the generalization
07:25 dalek parrot: r41789 | mikehh++ | trunk/config/gen/crypto/digest_pmc.in:
07:25 dalek parrot: fix commit r48782 for g++ build
07:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41789/
07:25 allison foundational complexity:...
07:25 allison there's a certain amount of work that has to be done to deal with caller side options
07:25 allison like :flat to munge incoming arguments
07:25 chromatic Okay, let's talk about :flat.
07:26 allison or where the arguments came from (registers, constants, C varargs, etc)
07:26 chromatic I want to pass three PMCs to a function.
07:26 allison chromatic: let me finish
07:26 allison there is also a certain amount of work that needs to be done to deal with callee side options
07:26 allison like :slurpy
07:27 allison and where the parameters are going to (registers, C varargs, etc)
07:27 allison it is perfectly possible to have the code for handling the caller side options on the callee side
07:28 allison but, it vastly increases the complexity of that code (I'm talking mainenance) without actually reducing the execution time (since the same total work is being done)
07:28 allison chromatic: okay, go ahead with :flat
07:28 chromatic I want to pass three PMCs to a function.
07:29 chromatic The first and third are scalar PMCs.  The second is an aggregate containing three PMCs.
07:29 chromatic The first PMC goes into P1.  The items of the second go into P2, P3, and P4.  The third goes into P5.
07:29 chromatic This is all caller side.
07:29 chromatic The callee sees that it has five PMC parameters in registers P1 through P5.
07:30 chromatic Does that increase complexity anywhere?
07:30 allison caller side the items would be in P1, P2, P3, not P1-5
07:30 chromatic Well it shouldn't.
07:31 allison chromatic: but it is, because that's how they're passed in
07:31 chromatic If the caller has the second PMC marked as :flat?
07:31 allison what you get on the caller side is exactly what was passed in
07:31 allison something, somewhere has to flatten it out
07:31 allison and, it has to have a place to store what was flattened out
07:32 chromatic I say that's the responsibility of the caller side and the storage location is in registers in the context created for the call.
07:32 allison so, yes, what the callee sees is P1-5, not p1-3
07:32 allison that's the mistake the earlier code made
07:33 chromatic Why is that a mistake?
07:33 allison let me be clear
07:33 allison we can merge call signatures and contexts
07:34 allison possibly even return continuations
07:34 chromatic I think we have to do the former.  I'm all for that.
07:34 allison that is, I kind of agree with you
07:35 allison but the old way isn't the right way to get there
07:35 chromatic I agree with that too.
07:36 allison okay, in the mean time, I would like to look for ways to speed up CallSignatures for the simple cases
07:36 chromatic If you're telling me that 1) the old code was unmaintainable as-is 2) this current step is a simplification for maintenance 3) our deprecation policy holds us to making bigger simplifications until January 4) it's more important to get this work in progress merged at a stable point than to get it perfect, I agree completely.
07:36 allison especially, I'm curious if most of that 2.5 times slow down is in the returns, rather than the calls
07:37 chromatic It's both.
07:37 allison chromatic: useful to know
07:37 allison and, yes, that is what I'm saying
07:37 allison not perfect, a step in the right direction
07:37 chromatic Mostly it's everything called from the set_args PC op.
07:37 allison have you been able to run more complex profile examples yet?
07:37 chromatic Not yet.
07:38 allison chromatic: ah, that's building the call signature
07:38 allison chromatic: that could be vastly simplified
07:38 chromatic Parrot_pcc_build_sig_object_from_op is the expensive part.
07:38 allison chromatic: yes, that doesn't surprise me
07:38 allison chromatic: it's creating quite a few PMCs there too
07:38 chromatic That's mostly it, yes.
07:39 allison how hard do you think it would be to create a typed array?
07:39 allison that is, it can store a pmc or string pointer, or directly store an integer or float value
07:39 allison in each array slot?
07:40 chromatic It's 12:39 am, so I'm not quite following.
07:40 allison one of the big costs now is that every signature value has to be cast as a PMC
07:40 allison so it can be stored in a ResizablePMCArray
07:41 chromatic If you had a ResizableSTUFFArray that kept track of types, that wouldn't be necessary?
07:41 allison if we had a typed array, values could be stored directly (no PMC created)
07:41 allison yes, we have a signature, so we know what type each element should be
07:41 chromatic That's easy.
07:41 allison and, we're storing them with, for example set_integer, get_integer_native, etc
07:41 chromatic Just make a ResizableSTUFFArray which stores a union.
07:42 allison chromatic: a union for each value?
07:42 chromatic I guess it wouldn't have to store a union.  It could store a pointer.
07:42 chromatic A union wouldn't hurt anything though.  Might be safer too.
07:42 allison a blob of memory large enough to hold anything from a pointer to a float
07:42 chromatic That's a union, yep.
07:42 allison yes
07:43 allison okay, so that's step one on reducing PMCs created
07:43 chromatic We can even make it safe.
07:43 allison step two is to hold the array/hash data directly within the CallSignature, rather than having it hold array and hash PMCs
07:44 chromatic Right, that's a huge savings right there.
07:44 allison that cuts down two more pmc allocations
07:44 chromatic You cut down PMC allocations here by two thirds and you're onto something.
07:44 allison the third is eliminating the CPointers for returns (switching over to the same typed array as calls)
07:44 particle left #parrot
07:45 chromatic For 392,835 calls in this benchmark, we allocate ~2,750,000 PMCs and 392,840 STRINGs.
07:45 allison so, we're left with a single PMC for each call
07:45 chromatic Sorry, ~1,180,000 STRINGs.
07:45 allison we could make it a struct instead of a PMC, like the old system did
07:45 chromatic GC pressure is the biggest problem right now.
07:46 allison but, I'm more inclined to merge it with Context, and reduce PMC's that way
07:46 chromatic That seems better long term.
07:46 chromatic Capture's push_integer is about a third of runtime.
07:47 allison that makes sense, as the fib example was all integer arguments, yes?
07:47 chromatic CallSignature inherits that one, right?
07:47 chromatic Yes.
07:47 allison yes, it inherits that one
07:47 allison so, the typed array maybe the first obvious optimization
07:48 * allison adding notes to the CallingConventions wiki
07:48 chromatic Improving storage within CallSignature seems like a bigger improvement to me.
07:49 allison chromatic: well, I'd do both at the same time
07:49 allison that is, implement the typed storage within CallSignature, rather than as a separate PMC
07:49 chromatic Oh, right.
07:50 chromatic That makes sense.
07:50 chromatic My only remaining concern is that it's risky to do these things with tests failing on the branch.
07:50 allison chromatic: that's why I haven't started them yet
07:50 allison chromatic: it's too hard to know the source of failing tests
07:51 allison chromatic: but, someone could work on CallSignature independently
07:51 chromatic I'd hate to merge the branch without these optimizations, though.
07:51 allison chromatic: that is, take the tests dukeleto has implemented for CallSignature, and use that to prove functional equivalence
07:52 chromatic How good are the tests?
07:52 allison and also to demonstrate the speed enhancements
07:52 allison chromatic: a lot better than they were
07:53 allison chromatic: though, there are likely untested cases
07:53 chromatic I'm sure there are.
07:53 allison still, it's enough to do the work
07:53 chromatic I suppose someone can work on this in a local branch, push it to GH or somewhere as useful, and merge in when it looks reasonable.
07:53 allison yup
07:53 allison honestly, they could work on it in a branch of trunk, that just updates CallSignature and the CallSignature tests
07:54 allison it's a strictly isolated part of the system
07:54 allison it has to provide the same interface to work, but how it works internally is open
07:55 chromatic Provided we can get the improved CallSignature tests in a different branch, that seems easiest to me.
07:55 allison yup, copy over t/pmc/callsignature.t
07:56 allison I can create the branch now if anyone's interested in working on it
07:57 chromatic By "anyone" you mean "Hey, you with loads of experience writing and maintaining PMCs and with an understanding of how GC works and mad profiling skills"?
07:58 cotto good reading between the lines
07:58 allison an ideal candidate, but I also don't know how much schedule time you have over the weekend
07:58 allison and, it would have to be this weekend, since our merge deadline for 1.7 is next Tuesday
07:59 * cotto unlurks briefly
07:59 allison (unless we decide optimizations are important enough to delay the merge)
07:59 allison (which I'm willing to accept)
07:59 chromatic I admit a certain sympathy in that direction.
08:00 chromatic Even though we only support 1.7 for a month, a 2.5x slowdown for common-case function calls is a bitter pill.
08:00 allison I'd still say "merge the week after 1.7"
08:00 chromatic s/week/minute/
08:00 cotto How likely is it that the branch will be ready to merge before the deadline without those optimizations?
08:00 chromatic There's the big unknown.
08:00 allison cotto: pretty likely
08:01 allison we're down to 73 failing tests
08:01 chromatic 67
08:01 allison last weekend we killed 800+ failing tests
08:01 * chromatic haz a magic power
08:01 allison chromatic++
08:01 chromatic It was a facepalm for cotto.
08:01 cotto does this magic power involve getting a good summary from recent versions of Test::Harness?
08:02 chromatic I said "magic", not "godlike".
08:08 chromatic If you update the wiki and get the groundwork in place with dukeleto or whomever, I'll poke at it between battling my blackberries, allison.
08:09 einstein joined #parrot
08:09 allison chromatic: by groundwork you mean "create the branch"?
08:09 chromatic create/cause to be created/merge over tests/whichever
08:09 chromatic I'm saving my brainpower for important things like not losing a toe to the hedge clippers.
08:10 allison chromatic: yup, can do, within the hour
08:11 allison (so it's available whenever you want a break from the evil blackberries)
08:11 chromatic I want that break now, but I want doesn't always gets.
08:13 allison and those blackberries'll take to extremes
08:14 chromatic That's rare; _Safe as Milk_ was hard to find when *I* bought a copy in the '90s.
08:16 allison I still haven't managed to find a copy, but I remember it anyway
08:17 mikehh msg bacek - with r41780 in src/runcore/profiling.c line 130 - runcore->profile_fd = fopen(profile_filename, "w"); - profile_filename is unitialised
08:17 purl Message for bacek stored.
08:17 JimmyZ joined #parrot
08:17 chromatic Get the 12 song version if you can.
08:18 chromatic It has the song that's about a car that everyone thinks is about a woman and they look at him weird for it.
08:18 allison ooh, I remember that one
08:19 allison I actually liked it
08:20 * allison is currently signing away rights for a company to use my name, voice, likeness, and biographical information in promoting their product
08:20 * allison feels vaguely dirty
08:21 allison okay, it's OSCON, so not as bad as it sounds, but still
08:21 chromatic Could be worse; could be like the Head First girl with the embarrassing female itch.
08:21 allison ah, the wonders of stock photos
08:22 allison I wonder if that model has died her hair and started wearing glasses or something
08:22 allison but then, I suppose models don't move in the same circles as technical book readers
08:23 chromatic You'd be surprised.
08:23 treed Didn't OSCON just happen?
08:23 allison maybe she hooked up with a Java geek who think's it's totally cool she's on the cover of his book
08:23 chromatic I can't walk past Abercrombie and Fitch here without seeing particle's shiny visage.
08:23 allison treed: yes, this is the contract for next year
08:23 treed Ah.
08:23 treed Yeah, I just missed being in the area this year.
08:24 * treed recently moved to Mountain View.
08:24 allison particle's secret life as a model?
08:24 treed Would have liked to come.
08:24 treed Haha. Awesome.
08:24 allison treed: ah, Mountain View is a good place
08:24 * treed tried running rubyspec.
08:24 treed on cardinal, that is
08:24 treed No output!
08:24 treed Clearly that means we're at 100% and nothing remains to be done.
08:24 cotto clearly
08:24 * treed dusts his hands off and goes to do something else.
08:25 chromatic I have a spare hedge trimmer.
08:25 treed Actually, there is output.
08:25 cotto on to the next big thing
08:25 treed [1:23] [inara:/Users/treed/code/rubyspec]% mspec -t ../cardinal/cardinal
08:25 treed This compiler is built with the Parrot Compiler Toolkit, parrot revision 40987.
08:25 treed But that's it.
08:25 chromatic Just tell them to stop monkeypatching.
08:26 chromatic Must be something in their local Kernel::
08:26 treed Or just that Cardinal really sucks. :-P
08:26 allison treed: I'm at about the same place on Pynie
08:26 treed I wonder if they have a list of the minimal stuff an implementation must support.
08:26 allison treed: the hard thing is, these test suites assume a full working interpreter
08:27 treed Well, rubyspec specifically says that it tries to be minimal in the basic support it requires.
08:27 allison treed: with Pynie I have to break their test suite down into smaller bootstrapping tests
08:27 treed It specifically mentioned that something was hard to implement in Rubinius and was specifically avoided.
08:27 allison treed: so I can get there in stages, and know I'm passing features along the way
08:27 * treed nods.
08:27 treed Cardinal has its own test suite.
08:27 allison does Rubinius have a bootstrapping test suite you can use?
08:27 chromatic If you do something similar, treed, you might talk to Rubinius and see about donating bootstrapping tests.
08:28 treed Mostly, from my point of view, for regression testing. But we have some tests that were never passing.
08:28 treed similar in what fashion?
08:28 chromatic Extracting bootstrapping tests.
08:28 treed I mean, we have tests for basic functionality.
08:28 treed using a very very simple module
08:28 treed And outputting TAP.
08:30 mikehh chromatic: I think I first heard that album in about 1972 in Johannesburg in SA - is that the one with "squid eating dough in a polyethelene bag etc."
08:30 allison aye, Rubinius probably would be interested in TAP output
08:31 treed It's possible that Rubinius has some tests besides using rubyspec.
08:31 * treed checks
08:31 allison treed: I converted Pynie's tests to Subunit output, which does the same thing as TAP, but is Python-based
08:31 * treed nods.
08:31 allison s/would/wouldn't/
08:31 treed I wrote a TAP harness into our Rakefile.
08:31 allison treed: nice!
08:32 treed Could probably be abstracted out into a proper module.
08:32 treed It's pretty basic, and has been specifically adapted to the way I write tests.
08:32 chromatic Way before my time, mikehh.  The album I'm thinking of is from the heady days of 1996, when I was ceasing to be a professional musician.
08:32 treed That is, I have specific shit that happens with TODO and SKIP
08:32 treed And if you have one of those and the comment doesn't mention an issue number, the rakefile will bitch at you.
08:33 treed This is to ensure that everything that is marked todo and skip is known and on the radar.
08:33 treed Instead of sitting in a file somewhere.
08:33 chromatic A powerful aegis.  So to speak.
08:33 mikehh mind you that might have been Trout Mask Replica
08:36 treed https://trac.parrot.org/parrot/ticket/977​https://trac.parrot.org/parrot/ticket/977
08:36 shorten treed's url is at http://xrl.us/bfrffv
08:36 treed dammit
08:36 treed https://trac.parrot.org/parrot/ticket/977
08:37 treed That one.
08:37 purl that one is probably silly to.  It's an impl detail, right?
08:37 treed It can be closed, but I don't have the ability to close it.
08:38 cotto treed, done
08:38 dalek TT #977 closed by cotto++: parrot_config returns with an error about "Invalid Charset"
08:38 treed Thanks.
08:38 treed Yeah, rubinius also has unit tests of their own.
08:39 treed maybe I can try those out
08:39 treed Honestly, it's not like I don't know what needs fixing, though.
08:39 treed Mostly I ran rubyspec out of curiosity.
08:40 treed I was trying to implement Ruby's actual object model, and ran into some problem I couldn't figure out, and that derailed me.
08:40 treed Then I got busy with the job offer and moving.
08:40 treed Still moving, actually.
08:40 cotto treed, good pun
08:40 treed But things are calmer now.
08:40 treed Heh.
08:41 allison treed: btw, are you at google?
08:41 treed IMVU
08:41 treed Which is in Palo Alto.
08:41 allison (mountain view)
08:41 treed I just live in Mountain View.
08:41 allison ah, makes sense
08:41 treed PA is much more expensive.
08:41 allison Palo Alto is spendy
08:41 allison yes
08:41 allison and Mountain View is right next door
08:41 treed The Facebook effect, as my coworkers call it.
08:41 allison :)
08:42 treed Turns out that facebook gives employees a stipend of $650 OSLT to live within a mile of the facebook offices.
08:42 treed So, all the rents are inflated by $650 in that area.
08:42 treed Facebook used to be in the building right next to us.
08:43 treed Looking forward to spending time at the Hacker Dojo now that I'm here.
08:43 quek joined #parrot
08:43 treed A place I can go hang out and hack on shit is pretty sweet.
08:43 treed And maybe I can recruit some more folks.
08:43 treed As I member I could give presentations and such.
08:44 allison treed: yeah, it's a very cool idea
08:45 treed A bunch of my co-workers were involved with that stuff and the SHDVs before it.
08:45 treed I knew a bunch of them from way back.
08:45 treed And used to get really envious of the SHDH parties.
08:45 allison the best jobs are the ones with those kinds of connections
08:46 allison it's so much better than wandering into a new office cold
08:46 * treed nods.
08:46 treed Lots of really smart people at IMVU. I'm really enjoying the job so far.
08:46 treed Other than the fact that much of my job depends on me coding in Perl5. >_>
08:46 treed Ops guys use Perl, Engineering uses Python/C++.
08:46 treed no love for ruby
08:47 allison interesting combination
08:47 treed It's just about who was there to write stuff in the beginning.
08:47 treed because so much of the early stuff was in those languages, the related stuff stayed with those languages.
08:48 treed One guy was ops for the first couple years, and he's really into Perl.
08:48 allison yeah, and then the subsequent hires follow along the same lines, because they have to maintain the existing code
08:48 treed Although not enthusiastic about Perl6, sadly.
08:48 treed Yeah.
08:48 treed One of the engineers was trying to get me to subvert ops and start writing stuff in Python.
08:48 treed Because they have to interface with our stuff.
08:48 treed And hate having to interface python to perl.
08:49 treed Usually happens by scraping the output of perl scripts.
08:49 allison a lot of Perl 6 is overkill for ops folks. Will be good to get some books out on the simple subset of Perl 6 that basic perl 5 users actually need)
08:49 treed Management doesn't want to spend the effort maintaining APIs in both languages.
08:49 treed Honestly, I'd be enthused to not have to mess around with references.
08:49 allison yeah
08:50 treed I spent a whole afternoon banging my head into a wall trying to embed arrays in hashes in hashes.
08:50 allison :)
08:50 treed Tene finally explained it to me the next morning when I'd calmed down and was able to understand his words.
08:50 treed And it makes sense, historically.
08:50 treed But it's still ass.
08:51 treed My boss looked at me funny for putting arrays in hashes in hashes.
08:51 treed But it really was the most sensical representation of the data.
08:51 treed there are hosts which have many interfaces which each have two data rates
08:51 treed makes sense to me
08:51 treed I could have made classes for it, but I'm still far from understanding Perl OO.
08:52 treed Hm.
08:52 treed cardinal's rake smolder takes longer than it did last time I ran it
08:52 treed almost 11 minutes now
08:53 treed I'd be more enthusiastic about converting ops to python if python wasn't so comparatively verbose when doing text munging.
08:53 treed Which is a lot of what we do.
08:53 treed So perl6 would be really nice.
08:54 allison aye, I've noticed the string handling differences between python and perl
08:55 treed Well, mostly it's the
08:55 treed my_re = re.compile('blahblahblah')
08:55 treed my_re.match(str)
08:55 treed oh, and you have to save the match object
08:55 treed rather than just str =~ /blahblahblah/
08:56 treed Really, I just want the syntactic sugar.
08:57 * treed heads to bed.
08:57 * purl follows treed
08:58 treed okay, purl, but I'm just going to sleep
08:58 allison I think that small low-level distinction explains a lot of why perl is popular for ops work (strings), and python for scientific work (numbers)
08:58 allison treed: g'night
08:58 treed night!
09:00 mikehh trunk - pre/post-config, smoke (#28795) PASS, fulltest FAIL at r41789 (see TT #1102) - Ubuntu 9.04 amd64
09:04 mikehh hey you bunch - no new commits to test for a couple of hours :-}
09:09 allison mikehh: I'll get cracking :)
09:09 allison (after I create chromatic's branch)
09:48 bacek joined #parrot
09:52 mikehh rakudo (1b83557) builds on parrot r41789 make test / make spectest_smolder (up to 28713 -> #28801) PASS - Ubuntu 9.04 amd64
10:03 payload joined #parrot
10:05 mikehh holy ... rakudo spectest_smolder reports tests as 35,121 ok, 0 failed, 520 todo, 6,851 skipped and 0 unexpectedly succeeded
10:10 darbelo joined #parrot
10:14 * darbelo thinks IMAGE_IO needs to become a PMC, like, yesterday.
10:21 * darbelo wonders if that can be done without deprecating anything.
10:36 dalek parrot: r41790 | allison++ | branches/pcc_optimize_sig:
10:36 dalek parrot: Creating branch for refactoring calling conventions, to work on trimming down the creation/initialization time and memory footprint of the CallSignature PMC.
10:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41790/
10:38 moritz is that the successor of the pcc_reapply branch? or an entirely different beast?
10:40 darbelo moritz: Both?
10:40 purl hmmm... Both is country *and* western or salt and MSG
10:42 moritz purl: forget both
10:42 purl moritz: I forgot both
10:48 einstein i found a bug in the capture.pmc mark function, it does something which is just imposible
10:48 einstein i uses it's own attributes instead of the array
10:48 darbelo einstein: If it's imposible, how can it do it?
10:48 darbelo ;)
10:48 allison einstein: could you explain a bit more?
10:50 darbelo einstein: you mean the PARROT_CAPTURE(SELF)->data_size ?
10:51 einstein yes the PARROT_CAPTURE(SELF) would be index [2] of the data array
10:51 einstein yes the PARROT_CAPTURE(SELF)->data_size would be index [2] of the data array
10:52 joeri joined #parrot
10:53 darbelo data_size is an ATTR, it's pre-allocated allong with the two PMC pointers. (Capture uses auto_attrs)
10:54 einstein &(PMC_data_type(SELF, PMC **)[2]) == &(PARROT_CAPTURE(SELF)->datasize), that is the problem
10:55 dalek parrot: r41791 | allison++ | branches/pcc_optimize_sig (2 files):
10:56 dalek parrot: [pcc] Copying over CallSignature PMC and tests for independent development.
10:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41791/
10:56 einstein PMC ** const data = PMC_data_typed(SELF, PMC **); should be something like PARROT_CAPTURE(SELF)->array
10:58 darbelo PARROT_CAPTURE(SELF)->array is a (PMC *) not (PMC **)
10:59 dalek parrot: r41792 | allison++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
10:59 dalek parrot: [pcc] A bit of internal renaming on the CallSignature (they're not "returns"
10:59 dalek parrot: they're "results"), while preserving the external interface.
10:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41792/
10:59 darbelo What you want is  &(PARROT_CAPTURE(SELF)->array)
11:00 allison einstein: ah, you're talking about trunk, not branch
11:00 einstein yes it is the main trunk yes
11:00 darbelo Which, coincidentally is the same as PARROT_CAPTURE(SELF)
11:01 darbelo or PMC_data(SELF)
11:01 purl PMC_data(SELF) is a void *
11:02 darbelo Which, as purl pointed out, is the wrong type.
11:02 allison einstein: that has been fixed on the branch
11:02 allison einstein: see https://trac.parrot.org/parrot/changeset/416​28/branches/pcc_reapply/src/pmc/capture.pmc
11:02 shorten allison's url is at http://xrl.us/bfrfor
11:03 einstein oh ok then i will do update, it is little week ago i did a update
11:04 allison einstein: well, it hasn't been merged into trunk yet
11:04 einstein ah ok
11:04 allison einstein: but it will be in a week or two
11:05 einstein ok that is good to know, thanks for the information
11:06 allison einstein: good catch, by the way. that was a non-trivial error
11:08 einstein yes I know, thanks for your help
11:09 masak joined #parrot
11:29 bacek joined #parrot
11:33 dalek TT #1100 reopened by bacek++: t/src/extend.t:  failing in trunk
11:37 dalek parrot: r41793 | bacek++ | trunk/src/call/context.c:
11:37 dalek parrot: [cage] Initialise Context.current_sub in init_context.
11:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41793/
11:55 mokurai left #parrot
12:22 jsut_ joined #parrot
12:23 JimmyZ joined #parrot
12:51 mikehh pcc_reapply - make spectest_smolder #28808 at r41793 - Ubuntu 9.04 amd64
12:52 mikehh trunk - pre/post-config, smoke (#28809) PASS, fulltest FAIL at r41793 (see TT #1102) - Ubuntu 9.04 amd64
13:00 quek left #parrot
13:01 kid51 joined #parrot
13:06 JimmyZ joined #parrot
13:13 dalek TT #1100 closed by jkeenan++: t/src/extend.t:  failing in trunk
13:23 ruoso joined #parrot
13:24 * darbelo lapses into a coma.
13:29 * kid51 reads scrollback to see what possibly could have induced darbelo's coma
13:39 workbench joined #parrot
13:39 * darbelo recovers from the coma.
13:39 darbelo lack of exitment.
13:42 plobsing joined #parrot
13:47 JimmyZ .\miniparrot.exe config_lib.pasm > runtime\parrot\include\config.fpmc
13:47 JimmyZ Malformed string
13:47 JimmyZ make: *** [runtime\parrot\include\config.fpmc] Error 1
14:16 Psyche^ joined #parrot
14:16 dalek parrot: r41794 | jkeenan++ | branches/detect_llvm (2 files):
14:16 dalek parrot: Refactor four instances of handling verbose output.
14:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41794/
14:26 theory joined #parrot
14:29 dalek rakudo: bd7966f | jonathan++ | src/ (15 files):
14:29 dalek rakudo: Start to store the default value as a closure inside the signature object. Also stub in space for sub-signatures - we don't support them just yet, but it'll be ready for when we do. Also fix a typo that caused constraints introspection to be broken.
14:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​d7966f695b87d1ae9c192908045fbead1ee64f6
14:29 shorten dalek's url is at http://xrl.us/bfrf5h
14:35 dalek rakudo: 4cdac8a | moritz++ | perl6.pir:
14:35 dalek rakudo: make backtraces a bit less noisy
14:35 dalek rakudo: Hopefully marking line numbers with the word "line" makes their purpose more
14:35 dalek rakudo: obvious.
14:35 purl i guess obvious is redirect to where you want to be
14:35 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​cdac8a020c0e98b53ed5f4dcee019adb8a80c15
14:35 shorten dalek's url is at http://xrl.us/bfrf6a
14:46 dalek rakudo: 925fd06 | jonathan++ | src/ (2 files):
14:46 dalek rakudo: Tweak to .constraints to pass another spectest.
14:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​25fd06b2cf044a604b7aafbc99469eb4d28f4ef
14:46 shorten dalek's url is at http://xrl.us/bfrf7o
15:27 dalek parrot: r41795 | jkeenan++ | branches/detect_llvm/t/steps/auto/llvm-01.t:
15:27 dalek parrot: Test previously unexercised branches.
15:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41795/
15:29 Tene ... Huh.
15:29 Tene I go to start working on pcc stuff, and then I fall asleep for 13 hours.
15:29 Tene So, um... good morning, all.
15:30 kid51 Good morning, tene
15:30 kid51 So far, not much sign of a hackathon here today yet
15:37 dalek rakudo: 3208e7b | jonathan++ | src/parser/actions.pm:
15:37 dalek rakudo: {%h} constructs a Hash, not a closure
15:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​208e7b7fe7f8034f662b0025b942d2214b8203b
15:37 shorten dalek's url is at http://xrl.us/bfrgct
15:38 einstein joined #parrot
15:41 jonathan 13 hours...that's...quite some sleep...
15:45 tetragon joined #parrot
15:47 jonathan Eww. I'm seeing some lovely segfault/assertion failure in Parrot.
15:48 jonathan context.pmc line 66 - Parrot_gc_mark_PMC_alive(INTERP, ctx->current_sub);
15:48 jonathan Seems sometimes this pointer is junk.
15:48 jonathan So trying to mark it explodes.
15:48 jonathan I actually get it at startup of Rakudo under the debugger...though not under the debugger it doesn't seem to happen.
15:49 jonathan Others are hitting it occasionally.
15:51 jonathan In init_context it appears we don't set the ->current_sub pointer.
15:56 jonathan And hey, that clears up the segfault. Whee.
16:02 dalek parrot: r41796 | jonathan++ | trunk/src/call/context.c:
16:02 dalek parrot: [core] Be sure we don't leave ctx->current_sub uninitialized. While it *usually* will be init'd shortly after context creation, there's no promise of that, and this uninitialized pointer was being hit and followed during a GC run, causing an assertion failure and/or segfault.
16:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41796/
16:10 Tene okay, os how can I get a count of failing tests?
16:11 dalek rakudo: 27d9f14 | jonathan++ | build/PARROT_REVISION:
16:11 dalek rakudo: Bump PARROT_REVISION to get a fix I just put in for a segfault.
16:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​7d9f14b0e0ffb9aa1898ea32dc27961e955c953
16:11 shorten dalek's url is at http://xrl.us/bfrggx
16:12 dalek parrot: r41797 | tene++ | branches/pcc_reapply/src/call/args.c:
16:12 dalek parrot: [pcc] Check returns count properly.
16:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41797/
16:13 rhr joined #parrot
16:19 Tene okay, :flat returns don't work.
16:22 Tene fixing...
16:22 purl rumour has it fixing is good, definitely
16:23 Tene LIES.
16:26 kyle_l5l joined #parrot
16:27 Tene Hmm.  Not sure where to do this correctly.
16:28 Tene allison's pseudocode doesn't mention :flat returns anywhere... maybe she wanted them processed elsewhere?
16:29 dalek tracwiki: v26 | tene++ | CallingConventionsOverview
16:29 dalek tracwiki: fix a minor typo
16:29 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=26&amp;action=diff
16:29 shorten dalek's url is at http://xrl.us/bfrgi9
16:32 msmatsko joined #parrot
16:35 Tene Ahh, they're handled in the sig building.
16:41 dalek nqp-rx: a0788f8 | pmichaud++ | src/Regex/Cursor-builtins.pir:
16:41 dalek nqp-rx: Add some builtin subrules to Cursor.
16:41 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​0788f8a7eaac5a14f3c63a231eb0a17da93b17d
16:41 shorten dalek's url is at http://xrl.us/bfrgmb
16:41 dalek nqp-rx: 86f5d68 | pmichaud++ |  (8 files):
16:41 dalek nqp-rx: Add lexical $�.
16:41 dalek nqp-rx: Add subrule matching -- non-capturing and non-backtracking as yet.
16:41 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​6f5d68869a4f607c8dcf7d4fb4191ee46d5ea6b
16:41 shorten dalek's url is at http://xrl.us/bfrgmd
16:43 Tene oh, nm, that's for results, not returns... ><
16:47 payload joined #parrot
17:06 einstein joined #parrot
17:24 Tene okay, the general algorithm I'm going to use is to add a return_subindex INTVAL and then check for :flat every time we fill a result from a PMC, and if so, pull the return_subindex item out of the return and increment that instead of return_index.
17:24 Tene that doesn't seem *too* bad.
17:49 * Tene jfdi
18:02 allison Tene: sounds reasonable
18:03 mberends joined #parrot
18:04 Patterner joined #parrot
18:05 Tene allison: thanks.
18:30 dalek tracwiki: v3 | darbelo++ | ItsABughunt
18:30 dalek tracwiki: https://trac.parrot.org/parrot/wiki/I​tsABughunt?version=3&amp;action=diff
18:30 shorten dalek's url is at http://xrl.us/bfrg22
18:33 chromatic joined #parrot
18:46 * chromatic had dreams of fixing the CallSignature PMC.
18:46 * chromatic also had dreams of joining a non-evil law firm and working for a long time before anyone discovered he's not actually a licensed attorney.
18:46 chromatic Thus you're not getting your CallSignature PMC in the next couple of hours.
18:57 allison chromatic: no worries, I'm just getting down to parrot work for today myself
19:02 nopaste "tene" at 24.10.252.130 pasted "allison++: review this patch?" (84 lines) at http://nopaste.snit.ch/18294
19:05 nopaste "tene" at 24.10.252.130 pasted "The same, but with a type check" (87 lines) at http://nopaste.snit.ch/18295
19:06 * allison reviewing second one
19:06 Tene Oops, the second one violates C90
19:07 nopaste "tene" at 24.10.252.130 pasted "The same, but doesn't violate C90w" (88 lines) at http://nopaste.snit.ch/18296
19:07 Tene ... argh
19:07 Tene It helps to *test* patches before pasting them.
19:08 Tene just a variable name problem.  s/aggregate/return_item/
19:08 Tene I'm not proud of return_index--, but it seemed better than adding guards to every other return_index++
19:10 allison Tene: where's the logic that pulls subsequent elements from the array? Oh, I see, you're holding it in place with the return_index-- until it's done with the flattening
19:11 Tene Yeah.  Exactly.
19:11 allison Tene: you know, it works, and it's code that'll last 3 months, so I'm cool with it
19:11 allison Tene: looks good in general
19:11 Tene Okay, great.
19:11 Tene It fails t/compilers/imcc/syn/tail_4.pir though... checking why.
19:12 allison Tene: I'm getting 76 failures with the new return code turned on now, is it time to switch it over to being the default?
19:12 Tene Ah, slurpy results don't use it yet.
19:12 Tene allison: I don't have any objections.
19:13 allison Tene: okay, I'll work the magic on Parrot_pcc_fill_returns_from_op
19:13 Tene Great.
19:13 allison Tene: (and then see about Parrot_pcc_fill_returns_from_c_args)
19:14 allison Tene: those shouldn't interfere with the lines you're working on
19:14 Tene No, they shouldn't.
19:19 Tene pushing...
19:19 purl it has been said that pushing is the answer
19:19 Tene purl: shoving?
19:19 purl shoving is the answer or
19:19 treed pushing and shoving and pushing and shoving me
19:20 Tene no, shoving is the answer to the terrible secret of space!
19:20 purl okay, Tene.
19:20 dalek parrot: r41798 | tene++ | branches/pcc_reapply/src/call/args.c:
19:20 dalek parrot: [pcc] The first step in handling :flat returns.
19:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41798/
19:26 einstein joined #parrot
19:28 mokurai joined #parrot
19:30 ash_ joined #parrot
19:32 Tene more fixes!
19:33 dalek parrot: r41799 | tene++ | branches/pcc_reapply/src/call/args.c:
19:33 dalek parrot: [pcc] Add a termination condition to the slurpy-result-filling loop.
19:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41799/
19:36 nopaste "tene" at 24.10.252.130 pasted "my test failures" (42 lines) at http://nopaste.snit.ch/18297
19:39 darbelo left #parrot
19:41 bacek joined #parrot
19:42 Tene 75 failed for me
19:43 Tene Hmm.  Smolder is nice.
19:43 dalek parrot: r41800 | allison++ | branches/pcc_reapply/src/call/args.c:
19:43 dalek parrot: [pcc] Turn on new return handling code for everyone.
19:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41800/
19:52 Tene reclaimed 6 tests by fixing a test regex.
19:53 dalek parrot: r41801 | tene++ | branches/pcc_reapply/t/op/cc_params.t:
19:53 dalek parrot: [pcc] Update a regex in t/op/cc_params.t
19:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41801/
19:56 Tene 2two more
19:56 dalek parrot: r41802 | tene++ | branches/pcc_reapply/t/op/cc_state.t:
19:56 dalek parrot: [pcc] Another test regex fix
19:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41802/
19:56 mikehh pcc_reapply - make spectest_smolder #28825 at r41800 - Ubuntu 9.04 amd64
20:02 Tene smolder server is down?
20:04 Tene back up now, it seems.
20:05 mikehh trunk - pre/post-config, smoke (#28824) PASS,fulltest FAIL at r41800 (see TT #1102) - Ubuntu 9.04 amd64
20:09 dalek lua: 10c0499 | fperrad++ | src/ (2 files):
20:09 dalek lua: implement trigo hyper
20:09 dalek lua: review: http://github.com/fperrad/lua/commit/10​c04995ffeae1ef824f7aeabb3a1510d668ca1a
20:09 Tene 67 failed at 41802
20:09 shorten dalek's url is at http://xrl.us/bfrhft
20:14 dalek lua: 9b5ce12 | fperrad++ | t/lua-TestMore:
20:14 dalek lua: update submodule lua-TestMore
20:14 dalek lua: review: http://github.com/fperrad/lua/commit/9b​5ce128cf118d68107c646a4f3a7a2a479c347c
20:14 shorten dalek's url is at http://xrl.us/bfrhf9
20:20 mikehh pcc_reapply - the biggest problem tests are t/op/calling.t - Failed 19/95 subtests, t/pmc/exporter.t - Failed 7/12 subtests, t/pmc/threads.t - Failed 5/14 subtests
20:21 mikehh and t/oo/composition.t which exits in subtest 21 out of 45
20:24 mikehh I get 6,441 ok, 62 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded at r41802 - #28829
20:32 mikehh Tene - I am using my normal config options (the same as I use in trunk) on perl Configure.pl - you might want to re-config and realclean
20:34 Tene mikehh: thanks, I'll do that.
20:34 Tene working on composition.t right now.
20:34 Tene I think I know what the problem is.
20:38 mikehh I've got a codetest line length error I forgot to commit about 13 or so hours ago in src/call/args.c
20:39 mikehh of course it has changed a bit since then
20:40 mikehh I was working in a different dir
20:45 Tene okay, yes, got composition.t's failure reduced to minimal pir
20:49 bacek Good morning
20:49 mikehh_ joined #parrot
20:50 Tene fixed composition.t
20:50 Tene committing.
20:50 Tene 25 more test passes
20:50 allison Tene++
20:51 Tene r41803
20:53 dalek parrot: r41803 | tene++ | branches/pcc_reapply/src/call/args.c:
20:53 dalek parrot: [pcc] Fix a copy/paste error in fill_params for named pmc params.
20:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41803/
20:53 dalek parrot: r41804 | bacek++ | trunk/src/runcore/profiling.c:
20:53 dalek parrot: Revert "[cage] Reduce scope for C string in runcore_profile_init."
20:53 dalek parrot: mikehh++ for noticing, bacek-- for to be careless.
20:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41804/
20:53 Tene when trying a full 'make', we get an error when compiling TGE due to mmd not being updated to deal with 'n' for 'named' in sigs
20:54 Tene i don't know what to do with it... don't understand mmd at all.
20:55 Tene in src/multidispatch.c +716
20:56 Tene down to 32 failed.
21:02 allison mmd should ignore named args
21:03 allison (they don't participate in multiple dispatch, only positional args are signiicant
21:03 allison f
21:03 allison )
21:04 rhr joined #parrot
21:05 Tene allison: so if it gets an 'n', it should drop the previous item from the type tuple it's building?
21:05 bacek Tene: just ignore 'n'
21:06 bacek it's flag for previous argument
21:06 Tene bacek: it says that the previous argument is named, and allison just said that mmd should ignore named args.
21:06 allison Tene: if it gets an 'S', it should check if the next item is an 'n' and stop building if it is
21:06 Tene OK.
21:06 allison (preventing, rather than undoing)
21:07 allison Tene: similarly for Pf
21:07 allison (though it may already be doing that)
21:07 Tene What is 'f'?
21:07 purl 'f' is bottom lip and top teeth
21:07 allison :flat
21:09 nopaste "tene" at 24.10.252.130 pasted "like this? for allison++" (27 lines) at http://nopaste.snit.ch/18299
21:09 Tene Well, I'll just try it.  No coretests fail because of it, afaict...
21:10 allison Tene: wrap the 'S' case in braces (so the INTVAL is declared inside a block)
21:10 bacek :flat should update signature similar to "dissect_aggregate_arg"
21:10 Tene Yeah, I got that.  It didn't compile otherwise. :)
21:10 allison Tene: then do the same for the 'P' case
21:11 mikehh joined #parrot
21:11 Tene allison: Pf you mean?  and are you disagreeing with bacek here?
21:11 allison bacek: mmd is different, dynamically flattened args don't count for mmd
21:11 bacek allison: ah, ok
21:11 bacek but... why?
21:11 allison Tene: Sn and Pf, yes
21:12 dalek parrot: r41805 | mikehh++ | branches/pcc_reapply/src/call/args.c:
21:12 dalek parrot: fix a bunch of line length errors in src/call/args.c
21:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41805/
21:14 allison bacek: hrmph...
21:14 purl i guess hrmph is the key word to ambiguosity
21:15 allison bacek: there was a reason, but it's pretty late here, and I'm not entirely alert
21:15 Tene allison: want me to add an XXX comment complaining about "Why?"?
21:15 allison Tene: you can skip Pf for now
21:15 allison Tene: I'll come back to it
21:16 Tene allison: well, the code as it is would just throw an exception on 'f'
21:16 allison Tene: (fix the failures, don't worry about the extras)
21:16 Tene I'll make it skip for now, to comply with old behavior.
21:17 allison Tene: 'f' will either be ignored, or it will be stripped out of the signature string before it reaches mmd
21:17 allison Tene: ("ignored" as in, that item not counted for MMD)
21:17 Tene so should I terminate sig processing on seeing 'f' or no?
21:18 allison Tene: either way, it shouldn't be getting stray 'f's
21:18 allison Tene: yes, do
21:18 allison Tene: because flats should be processed before MMD if they're going to be
21:19 allison Tene: MMD can't handle unprocessed flats, so just ignores them
21:19 * allison recovering previous logic
21:21 Tene committed.  this doesn't affect any coretests.
21:21 kid51 joined #parrot
21:21 allison Tene: yes, figure it probably wouldn't
21:21 nopaste "tene" at 24.10.252.130 pasted "if anyone wants to add a test for it, here you go" (18 lines) at http://nopaste.snit.ch/18300
21:22 dalek parrot: r41806 | tene++ | branches/pcc_reapply/src/multidispatch.c:
21:22 dalek parrot: [pcc] Stop build mmd type tuples on named and flat parameters
21:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41806/
21:24 Tene several of the op/calling.t failures are anti-failures.  We're not failing when we should be.
21:29 mikehh pcc_reapply - smolder_coretest #28835 at r41805 - 6,539 ok, 27 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded
21:35 dalek parrot: r41807 | tene++ | branches/pcc_reapply/t/op/calling.t:
21:35 dalek parrot: [pcc] Update three more error message text tests
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41807/
21:36 dalek nqp-rx: b0e696b | pmichaud++ | src/Regex/Cursor.pir:
21:36 dalek nqp-rx: Remove some obsolete methods from Cursor.
21:36 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/b​0e696bf7dfded473872b13aade629fcb36b54c2
21:36 dalek nqp-rx: 5ecd319 | pmichaud++ | src/Regex/Cursor.pir:
21:36 shorten dalek's url is at http://xrl.us/bfrhqx
21:36 dalek nqp-rx: Partial change of match stack to a cursor stack, update bstack handling.
21:36 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​ecd31941c3d6483f4751108d1b51b67704ceed7
21:36 shorten dalek's url is at http://xrl.us/bfrhqz
21:36 dalek nqp-rx: 7b01e97 | pmichaud++ | src/Regex/Cursor.pir:
21:36 dalek nqp-rx: Manage cstack on mark_fail.
21:36 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​b01e976627a08108493df3f0f96d5fc3f30d4f6
21:36 shorten dalek's url is at http://xrl.us/bfrhq3
21:44 mikehh pcc_reapply - smolder_coretest #28838 at r41807 - 6,542 ok, 24 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded
21:45 Tene allison: still awake?
21:48 dalek parrot: r41808 | tene++ | branches/pcc_reapply/src/call/args.c:
21:48 dalek parrot: [pcc] Get flags for optional results from the right sig
21:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41808/
21:49 * chromatic idly wonders if subclasses of CallSignature would make the default case fast and let us replace runtime conditionals with compile-time polymorphism.
21:56 Whiteknight joined #parrot
21:57 Tene hi whiteknight
21:58 Whiteknight hello Tene!
21:58 Whiteknight how's the hackathon going?
21:58 Tene s'okay.  a lot closer.
21:58 Tene fill_results is the default now
21:59 Tene last I heard, allison was working on making fill_returns_from_c_args use fill_results.
21:59 Tene I think she might be sleeping, though.
21:59 Tene we're down to 20-something failures in coretest.
21:59 Whiteknight ~20 failures! Awesome
21:59 Tene these last failures I'm running into, I don't know what to do with at all.
22:00 Tene optional results aren't getting their opt_flag set when the sub doesn't return at all
22:00 Tene tailcalling into an NCI doesn't work.
22:02 Tene is anyone using the result_info opcode at all?
22:03 Tene ah, optional results... I bet I can fix those.
22:04 Tene oh, I already did.
22:07 jonathan Tene: I can't remember seeing it used in Rakudo, I can't speak for the rest of the toolchain though.
22:07 Tene The only things using it in the parrot repo are the tests
22:08 jonathan Just searched all the Rakudo source tree and didn't find any mentions of it.
22:08 allison Tene: yes, working on fill_returns_from_c_args
22:08 allison Tene: (not sleeping yet)
22:09 jonathan Tene: Though I guess unless it was already deprecated, it can't go away.
22:09 allison Tene: I found some other bits while I was reviewing the code, though
22:09 Tene another failure: if the sub doesn't have any .params, where can we check for excess args?
22:10 Tene Similar to the one I wa slooking at earlier... if the sub doesn't have any .return(), where can we check for excess results or set :opt_flags for results?
22:10 jonathan Tene: I think that is a bug in current Parrot.
22:10 jonathan Tene: (the first one, that is)
22:11 nopaste "allison" at 77.98.130.30 pasted "Fixes for pcc_reapply that I can't commit at the moment because I'm working on another chunk in the same file, for Tene++" (21 lines) at http://nopaste.snit.ch/18301
22:11 jonathan Tene: So if you ain't checking that, then you've not improved things, but it won't be a regression.
22:13 jsut joined #parrot
22:13 allison Tene: I finished updating fill_returns_from_c_args a while ago, but I'm getting a segfault in miniparrot config_lib.pasm, so haven't checked it in yet
22:13 allison Tene: I've tracked the problem as far as the :flat handling code in fill_results
22:13 Tene Huh.
22:14 dalek parrot: r41809 | tene++ | branches/pcc_reapply/src/call/args.c:
22:14 dalek parrot: [pcc] two fixes from allison++
22:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41809/
22:15 allison Tene: specifically, this line is returning an invalid address (not NULL, or PMCNULL, just illegal)
22:15 allison 1573                         PMC *return_item = (constant) ? accessor->pmc_constant(interp, return_info, return_     index)
22:16 allison 1574                                                     : *accessor->pmc(interp, return_info, return_index);
22:16 allison (pardon the strange IRC wrapping)
22:16 bacek joined #parrot
22:16 Tene Fascinating.
22:19 allison hmmm... pmc_from_varargs returns PMC**
22:20 bacek allison: we need 4 other _from_varargs functions for fill_returns
22:21 bacek allison: scratch it.
22:21 bacek my mistake
22:21 allison bacek: we're only using the functions to access the elements passed in from varargs (the same as fill_params)
22:21 allison yeah
22:22 allison bacek: I mean, it would be possible to use functions for both fetching and setting, but we're not at the moment
22:23 bacek allison: we have to review all calls to fill_params_from_c then. Currently params/returns passed slightly inconsistently.
22:24 allison bacek: the function pass them is just a list of varargs, the same for both
22:24 allison to pass
22:25 bacek allison: PCCMETHOD creates different calls for fill_returns and fill_results. Like Parrot_pcc_fill_params_from_c_args(interp, _call_object, "Pi",
22:25 bacek &pmc);
22:25 bacek and     Parrot_pcc_fill_returns_from_c_args(interp, _call_object, "P",
22:25 bacek ret)
22:25 allison why is pmc_from_vararg fetching a PMC**?
22:25 allison in the existing code it was fetching a PMC*
22:25 bacek because it's passed as PMC**
22:26 bacek (in fill_params)
22:27 allison the parameters are passed as PMC** so they can be set with the arg value?
22:27 allison bacek: then, yes, we do need another set of pointers for fill_results
22:27 allison because they're passed as PMC*
22:28 bacek we can adjust PCCMETHOD.pm to pass args and returns consistently
22:28 allison bacek: on the plus side, the same set of function pointers will be used for build_sig_object_from_varargs
22:28 bacek I don't see reasons why they inconsistent.
22:28 allison bacek: args and returns are passed the same
22:29 allison bacek: it's params and returns that are different
22:29 allison (because returns are args, not params)
22:29 allison (results are params)
22:29 bacek yeah
22:32 allison bacek: so, I'll rename the existing functions to X_param_from_c_args, and add X_arg_from_c_args for the new ones
22:32 bacek allison: what about just passing params and returns consistently?
22:33 allison bacek: no, they're doing different things
22:33 allison bacek: an arg/return just passes a simple value
22:33 bacek yes, but we can always pass pointers
22:33 allison bacek: a param/result passes a pointer to a value
22:34 allison bacek: that's pushing unnecessary complexity on the user and on the code, just to avoid a set of function pointers
22:34 bacek ok
22:35 bacek Anyway, those functions are bad. I don't like  them at all.
22:35 allison bacek: what, the function pointers?
22:35 Tene he means fill_params and fill_results
22:35 bacek no, this particular set of functions
22:35 bacek foo_from_bar
22:37 allison bacek: at least most of the behavior is abstracted into the common fill_params and fill_results now
22:37 allison bacek: the distinction is limited to a prelude
22:37 allison bacek: and a different signature (one takes a vararg list)
22:38 bacek We just need pair of classes with shift_foo for fetching param/returns and push_foo to set arg/results
22:38 bacek then we can avoid copying staff into CallSignature.
22:39 Wolong joined #parrot
22:39 bacek build_sig_object will just set this fetchers/fillers.
22:40 Tene allison: what error needs to be thrown fro: 'foo'('abc', 'def'=>1, 'ghi', 'jkl'=>1) ?
22:41 allison bacek: we're working on stripping the PMCs constructed during a call down to just the CallSignature, don't want to add more
22:41 mikehh trunk - pre/post-config, smoke (#28839) PASS,fulltest FAIL at r41808 (see TT #1102) - Ubuntu 9.04 amd64
22:41 Tene Could it be "too many positional args", or does it need to be "named args must follow all positional args"?
22:41 allison Tene: that's "named args must follow all positional args"
22:41 bacek allison: we will avoid creating CPointers at all
22:41 allison bacek: we'll do that anyway, once we unify the two
22:42 chromatic allison, did you put your task notes somewhere?
22:43 allison chromatic: it's open in my browser, not submitted yet, give me a sec and they'll be on https://trac.parrot.org/parrot/​wiki/CallingConventionsTasklist
22:43 shorten allison's url is at http://xrl.us/bfqjf4
22:44 chromatic No rush here, I just wanted to see it before you vanished into unconsciousness like I did.
22:44 allison Tene: even if it is too many positional returns (which it may be), that's an error that can be turned off
22:44 Tene allison: you mean positional args?
22:44 allison Tene: mixing named and positional returns is always an error
22:45 allison Tene: both (returns are args)
22:45 Tene allison: could I throw the error in build_sig instead of fill_params?
22:45 allison Tene: yes
22:45 allison Tene: build_sig is the primary arg processor
22:47 Tene ah, nm, got it.
22:52 Wolong joined #parrot
22:57 allison bacek: ah, the annoyance with separate arg versions of the getter functions is it means we need them for 'from_op' too
22:57 allison bacek: (because we want to be able to call both without modification)
22:57 bacek allison: indeed.
22:59 allison bacek: I'll leave them with a consistent signature for now so that's not necessary
23:07 Tene I'm apparently failing some tests that mikeh isn't?
23:08 allison Tene: what are the platform differences?
23:08 allison chromatic: oh, forgot to submit again, doing it now
23:09 Tene Not sure.  I see a result from him earlier failing only 24 tests, but I'm failing 26 after this commit, which *fixes* 4 tests for me.
23:09 dalek parrot: r41810 | tene++ | branches/pcc_reapply (2 files):
23:09 dalek parrot: [pcc] Fail correctly when positional args are passed to slurpy named params
23:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41810/
23:19 Tene allison: awake to explain some error checking to me?
23:25 Tene allison: I'm running into a problem where it looks like PARROT_ERRORS_PARAM_COUNT_FLAG is on by default in the branch but off by default in trunk.
23:26 nopaste "tene" at 24.10.252.130 pasted "This works in trunk and fails on the branch, unless you uncomment" (11 lines) at http://nopaste.snit.ch/18302
23:27 Tene If I set err_check to 0 inside the conditional testing that value, then it passes.
23:29 jrtayloriv joined #parrot
23:32 allison chromatic: CallSignature refactor notes added in https://trac.parrot.org/parrot/​wiki/CallingConventionsTasklist
23:32 shorten allison's url is at http://xrl.us/bfqjf4
23:32 allison Tene: yes?
23:32 allison Tene: I wondered about that, but I checked and it's on by default in trunk too
23:33 Tene allison: so why does that snippet of PIr pass in trunk but fail on branch?  are extra named args not considered to fall under that?
23:33 allison Tene: that's possible
23:33 Tene PGE extensively relies on extra named args not being failures.
23:33 allison Tene: then for now they must not be failures in the branch
23:34 allison Tene: we can just comment out that code and put in a deprecation notice
23:34 mikehh pcc_reapply - smolder_coretest #28842 at r41810 - 6,545 ok, 21 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded
23:34 Tene so should I change the trailing "if (err_check)" branch in fill_params to if(0) oslt?  or just delete it?
23:34 dalek tracwiki: v12 | allison++ | CallingConventionsTasklist
23:34 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=12&amp;action=diff
23:34 shorten dalek's url is at http://xrl.us/bfrh34
23:35 allison Tene: keep the code, but comment it out
23:35 allison Tene: (not a recommended usual practice, but in this case the right one)
23:35 Tene argh embedded comments... can I #if 0 ?
23:35 allison Tene: it should have a TT ticket
23:35 allison Tene: yes, #if 0 is okay
23:36 allison Tene: or #ifdef SOME_SENSIBLE_NAME
23:36 Tene it also needs some tests, theoretically.
23:36 allison Tene: write them as todo tests for how it should work
23:37 Tene allison: after this pending commit, it looks like everything compiles correctly, I think...
23:38 Tene 'make' just succeeded for me.  I want to realclean and reconfigure just to test, but it looks like we can switch to 'make test'
23:41 Tene It compiled... running 'make smolder_test' right now.
23:42 dalek parrot: r41811 | tene++ | branches/pcc_reapply/src/call/args.c:
23:42 dalek parrot: [pcc] Don't fail on extra named args
23:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41811/
23:44 allison Tene: excellent!
23:44 * purl zwooshes
23:46 kid51 Hmm.  Even when I configure on Linux/i386 with --buildframes=0, I still get 4 more failures than mikehh:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28843
23:46 shorten kid51's url is at http://xrl.us/bfrh5f
23:47 jonathan Looks like good progress. Tene++, allison++
23:48 japhb Infinoid, what's the status of the gitorious parser for dalek?
23:50 Infinoid it needs some help in the bits where it finds the actual commit messages amid the html and (joy of joys) escaped html of its atom feed
23:51 Infinoid with that done, and (optionally) a bit more scraping to get the changed paths for the end of the first line, it would be done
23:53 japhb Anyone still hacking on it, or is it stalled?
23:55 Infinoid darbelo started it, I took that and hacked a little (the output of that is http://nopaste.snit.ch/18273)
23:55 Infinoid he may have hacked more, I don't know.
23:57 patspam joined #parrot

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

Parrot | source cross referenced