half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
Set by moderator on 6 October 2009.
00:00 quek joined 00:06 Zak joined
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.
darbelo chromatic: did you --buildframes=0 ? 00:17
00:17 quek left
chromatic Oh, no. Hang on. 00:17
00:18 quek joined
dalek rrot: r41779 | bacek++ | trunk/src/pmc/sub.pmc:
[cage] Don't use C strings in Sub.get_regs_used.
 00:18
rrot: r41780 | bacek++ | trunk/src/runcore/profiling.c:
[cage] Reduce scope for C string in runcore_profile_init.
cotto_work on which platforms is buildframes=0 necessary? 00:22
non-x86/x64?
darbelo non-darwin x86
the frame builder only knows about x86 and braks on darwin. 00:23
s/braks/breaks/
chromatic Much better.
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.
cotto_work oic
dalek rrot: r41781 | chromatic++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fixed compiler warnings in fill_results() -- especially switching *over*
 00:28
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.
Maybe 3.10 or newer.
cotto_work thanks 00:30
there it is.
00:31 payload joined
cotto_work I don't like how more recent versions of Test::Harness omit the total number of failed tests. 00:34
00:34 bacek joined
cotto_work It appears there's still an old Parrot release in CPAN: search.cpan.org/~mdiep/parrot-0.4.11/ 00:37
darbelo s/old/ancient/ 00:38
cotto_work easy typo. the letters are right next to each other. 00:39
darbelo :)
It has ** UNAUTHORIZED RELEASE ** in big, bold, red letters. 00:42
He has better marketing than us...
mikehh pcc_reapply - make spectest_smolder #28774 at r41781 - Ubuntu 9.04 amd64 00:44
6,436 ok, 67 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded
chromatic Did r41781 clear up your warnings, mikehh? 00:45
mikehh chromatic: yes - the last run was g++ - and as I am on amd64 don't need buildframes=0 00:46
using the same config options as I use in trunk 00:47
chromatic Did it change the test count at all?
mikehh +6 tests
dalek rrot: r41782 | darbelo++ | trunk/config/gen/crypto/digest_pmc.in:
Kill several unnecessary strstart uses with one stone.
kudo: 1b83557 | moritz++ | t/spectest.data:
we pass t/spec/S06-signature/introspection.t, jnthn++
shorten dalek's url is at xrl.us/bfrd3s
mikehh 25 of the test failures are in t/oo/composition.t which drops out in test 21 - I think it segfaults 00:50
Parse errors: Bad plan. You planned 45 tests but ran 20 00:51
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?
I'll look at it immediately, if so. 00:53
chromatic t/pmc/sub_37.pir
Tene on it. 00:54
mikehh ok 20 - class has a method
Null PMC access in elements()
current instr.: 'conflict_resolution_by_exclusion' pc 815 (t/oo/composition.t:204)
called from Sub 'main' pc 83 (t/oo/composition.t:29)
Tene chromatic: what is :postcomp ? 00:55
darbelo post-compilation?
chromatic Run this sub after compiling the whole file.
Tene Ah, not required to make it fail.
mikehh the other problem test for me id t/op/calling.t
t/op/calling.t (Wstat: 4864 Tests: 95 Failed: 19)
Tene if it's :immediate and :postcomp, it just runs twice.
mikehh Failed tests: 35, 47, 52-55, 57-59, 61, 72, 74, 81-82
84, 88-89, 93, 95 00:56
chromatic It *should* run twice, yes.
It doesn't, because the :immediate run doesn't return PMCNULL.
Tene Right, okay.
chromatic Although....
Want a forehead slapper? 00:57
cotto_work prepare for facepalm... 00:58
chromatic The problem's in run_sub(). src/packfile.c:670.
I'll give you a moment to think about it.
Tene I don't understand any of the packfile stuff. 00:59
chromatic That's irrelevant.
mikehh PMC *retval;
chromatic Uninitialized value. 01:00
Pointer to that value passed into PCC.
If PCC doesn't set the pointed-to value....
Tene Ah, nice.
chromatic ... which it doesn't....
dalek rrot: r41783 | chromatic++ | branches/pcc_reapply/src/packfile.c:
[pcc] Initialized the PMC return value in run_sub() to PMCNULL explicitly.

sub doesn't have a return value, the return value will be PMCNULL, not whatever random junk is on the stack that is almost assuredly not a -- and is definitely not the -- valid PMC.
Tene fill_returns_from_c_args needs to be updated to use fill_results 01:04
I don't know how to test the c_args versions, though
01:07 kid51 joined
dalek rrot: r41784 | jkeenan++ | branches/detect_llvm (2 files):
Refactor more code into _handle_component_version_output() and _cleanup_llvm_files(). Add tests to improve coverage.
 01:15
mikehh pcc_reapply - make spectest_smolder #28778 at r41783 - Ubuntu 9.04 amd64
bbiab 01:16
01:20 rhr joined 01:26 MoC joined 01:34 darbelo left
dalek rrot: r41785 | jkeenan++ | branches/detect_llvm (2 files):
Refactor code into _handle_native_assembly_output() and add tests.
 01:41
chromatic I wonder if t/oo/composition.t fails because NCI hasn't converted yet. 01:50
bacek Yay. As I expected. pcc_reapply much nice, cleaner and _slower_ on op-op invocations. 01:56
micer
nicer
nopaste "bacek" at 114.73.170.127 pasted "callgrind result for simple call." (49 lines) at nopaste.snit.ch/18285 01:57
bacek and it's almost "unfixable" by design. 01:58
(9730587 - 9208895)/9208895 02:07
purl 0.0566508793943247
nopaste "bacek" at 114.73.170.127 pasted "Side-by-side pcc_reapply vs trunk of examples/benchmark/fib.pir" (37 lines) at nopaste.snit.ch/18288 02:14
bacek purl: 12,849,174,523/5,024,202,920 02:15
purl bacek: excuse me?
02:15 TiMBuS joined
bacek purl: 12849174523 / 5024202920 02:15
purl 2.55745532726214
bacek 2.5 times slower on fib.pir
chromatic: good luck with making pcc faster :-/. nopaste.snit.ch/18288
chromatic 2.5 times slower? 02:16
bacek chromatic: yes. I can explain why.
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.
for op-op invokation
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
yes, CPointer
purl CPointer is very simple and could certainly have more features added (rather than making another PMC that does mostly the same things)
bacek and because VTABLE calls can't be inlined by compiler it adds even more overhead. 02:20
chromatic 52.26% of the fib benchmark is beneath Parrot_set_args_pc. 02:21
bacek chromatic: in trunk?
chromatic Almost all of that is under Parrot_pcc_build_sig_object_from_op.
On the branch.
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.
CallSignatures can't be constant
chromatic Then we're doing something very, very wrong with a register-based VM.
bacek build_sig_object fill CallSignature with real values. 02:25
chromatic: indeed
02:27 quek left 02:28 quek joined, quek left
bacek anyway, from my pov, trunk's code is much better than branch. At least it faster. 02:29
chromatic Trunk's code is a huge, unmaintainable mess. 02:30
Every time I try to do something with it, I wind up confused and upset.
bacek Because there is a lot of useless functions.
chromatic Not just that. 02:31
purl not just that is it
chromatic There are several different ways to do the same thing, each slightly different.
bacek "a lot of useless functions"
we can just unify them without changing whole param passing algorithm.
purl: 1177-808 02:33
purl 369
bacek 369 lines of code in fill_params in branch. Small, nice and comprehensible function.
chromatic Remember though that trunk doesn't do everything that Rakudo needs, for example.
bacek for example? 02:34
chromatic I don't know the specific details, but something about named parameter passing was very wrong.
bacek It's still wrong. 02:35
chromatic It's a work in progress.
02:35 JimmyZ joined 02:36 janus joined
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
already.
chromatic I don't think Rakudo wants to get into that business though.
bacek And Rakudo will have to implement manual processing anyway. To support "sub foo($a where { $_ == 42 })" 02:37
or handle named args with same name
anyway, rl time. 02:38
chromatic We'll have to unify CallSignature and context at some point.
bacek I doubt that we need "CallSignature". 02:39
chromatic Yeah.
bacek set_args can just store pointer to raw signature in Context for "extended handling" 02:41
ah. It's already in Interp.
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.
"CallSignature" isn't signature only.
It carries values 02:43
chromatic That part I don't understand.
For PIR <-> PIR invocations, that doesn't make sense to me.
bacek CallSignature extend capture. build_sig_object copies values inside
chromatic: I started with it. That's why branch 2.5 times slower 02:44
"Unification for the win"
chromatic Sure, but we also can't fall into the Parrot 2002 - 2006 trap of speed uber alles.
bacek "Parrot 2.0 business ready. You just have to buy few Crays" 02:47
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.
chromatic If we avoid the copy in the standard PIR <-> PIR case, it doesn't have to be slow.
dalek rrot: r41786 | jkeenan++ | branches/detect_llvm (2 files):
Refactor code into _examine_llvm_gcc_version(). Add corresponding tests.
 02:49
bacek yeap. But it's unified.
anyway, I really have to go.
See you soon
chromatic au bientot
02:56 joeri left 03:16 plobsing joined 03:18 rhr joined
dalek rrot: r41787 | jkeenan++ | branches/detect_llvm/config/auto/llvm.pm:
Correct misleading error message.
 03:18
03:22 TiMBuS joined 04:42 jrtaylor joined 05:12 kyle_l5l joined 05:14 jrtaylor joined 05:49 fperrad joined
dalek rrot: r41788 | fperrad++ | trunk/tools/install/smoke_languages.pl:
[languages] in installed tree, try to find an executable "parrot-lang".
 06:03
mikehh pre/post-config, smoke (#28791) PASS, fulltest FAIL at r48788 - Ubuntu 9.04 amd64 06:43
fulltest (testf, testg and testS) (same tests FAIL, same results)
t/compilers/imcc/syn/macro.t - Failed tests: 2-4
t/compilers/imcc/syn/regressions.t - Failed test: 7
06:43 patspam joined
mikehh bahy that's r41788 06:43
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:45
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.
allison chromatic: yeah, they are using call signatures, taking a look to see when the constant switching was added 06:47
chromatic; (because that should be done inside the sub's invoke, which would delay it until after multisub dispatch 06:48
chromatic Exactly.
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:49
allison chromatic: it was r41654 06:50
chromatic: but no explanation of why other than "reclaiming failing tests" 06:51
chromatic: so it could have been a cosmetic fix for a deeper problem
chromatic It's definitely not correct.
allison chromatic: (that often happens in branch debugging, a quick fix is actually the wrong fix)
chromatic I wonder, though.
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?
chromatic: bacek put in some code that did
chromatic: but I need to remove it
chromatic I can't get an accurate count of failing tests. Test::Harness stopped summarizing failures for some reason I do not understand.
allison chromatic: it has to do with cloning key args 06:53
chromatic: oh, cotto was complaining about that, said it was related to the version of Test::Harness
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
chromatic: (and may I say that register based keys are a filthy hack and a premature optimization)
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
chromatic: no, this is old code
chromatic: which part seems complex? the function pointers or the duplication? 06:56
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
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
chromatic: the new code is more complex than I'd like it to be
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. 06:58
allison chromatic: if that was all we had, the code would be pretty simple 07:00
chromatic Sure, I understand that. 07:01
allison chromatic: the complexity comes with checking for all the weird options
chromatic: I think we can simplify the maintenance by breaking down the common repeated behaviors into a few smaller functions
chromatic Maintenance isn't my primary concern here. 07:02
allison chromatic: so someone can read over the top level in a few lines
chromatic: ah, but it is, in the sense that it will help us evaluate execution complexity too
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
it only checked flags and performed some action based on those flags
this one is more complex, but basically the same idea 07:04
so, a lot of the code never runs
chromatic The amount of code isn't my primary concern.
It's moving lots of data around, trying to decide whether to run code.
allison i.e. you only get the cost of a slurpy if you use a slurpy
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.
allison it had to, to exactly duplicate the semantics of the old calling conventions
deciding if you use a slurpy is still a straight integer check
(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.
allison yup
chromatic Going from PIR with positionals to PIR with positionals, we don't need any of that. 07:07
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?
allison chromatic: once we have the code passing all tests, I'd like to run some benchmarks
chromatic: it vastly reduces it in the general pcc case
chromatic Not by the fib.pir benchmark. That's 2.5 times slower on branch versus trunk.
allison chromatic: good to know 07:09
chromatic: what features does it use?
chromatic PIR <-> PIR with positionals
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.
allison though, not that much slower
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
(the speed advantage)
chromatic There shouldn't even be a register copy, I think.
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
allison yes, 1) create sub's context 2) copy arg registers from caller context to param registers of sub's context
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.
allison because it meant every thing else had to pretend to be a register-to-register transfer
chromatic Take slurpy, for example. 07:14
Caller passes 10 PMCs.
Callee takes two as params and the rest as slurpy.
For the sake of argument, imagine the calling conventions are P1, P2, ... P10.
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:15
allison what counter? 07:16
purl counter is some dumb thing having to do with the web, cause for immediate kicking.
chromatic Presumably some integer register keeps track of the number of PMC registers used.
allison right, but my question is where is it stored? 07:17
chromatic What is "it" in this context?
allison the note for how many registers were used
the most obvious would be "it just lives inside the param allocation function"
chromatic In an integer register. 07:18
allison but, the information is needed outside the function
chromatic Why is it needed outside the function?
allison chromatic: then how do you determine what register it was stored in
chromatic: what I'm getting at is that we need a record of the call state 07:19
the old system had a call state struct
the new system has call signature objects
but, no matter what we do, we can't get around the fact that we need some way of storing call state information
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?
allison there's two sides to every call 07:21
and they have to communicate
chromatic That's what calling conventions are for, sure.
allison right
but there's more information than simply dumping a bunch of registers from one side to another 07:22
chromatic Why?
allison (different types of registers for one)
chromatic I'm not playing devil's advocate here.
allison I know
every problem has a certain fundamental level of complexity
I'm trying to explain what that is here
chromatic Why is it not the callee's side to manipulate what it gets into what it wants? 07:23
07:23 iblechbot joined
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.
allison chromatic: you can put all the complexity on the callee's side
chromatic: but it makes for much worse code, and doesn't actually reduce the overall complexity 07:24
chromatic That sounds like a generalization.
How does it make the code worse?
allison I'm starting with the generalization
dalek rrot: r41789 | mikehh++ | trunk/config/gen/crypto/digest_pmc.in:
fix commit r48782 for g++ build
 07:25
allison foundational complexity:...
there's a certain amount of work that has to be done to deal with caller side options
like :flat to munge incoming arguments
chromatic Okay, let's talk about :flat.
allison or where the arguments came from (registers, constants, C varargs, etc) 07:26
chromatic I want to pass three PMCs to a function.
allison chromatic: let me finish
there is also a certain amount of work that needs to be done to deal with callee side options
like :slurpy
and where the parameters are going to (registers, C varargs, etc) 07:27
it is perfectly possible to have the code for handling the caller side options on the callee side
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
chromatic: okay, go ahead with :flat
chromatic I want to pass three PMCs to a function.
The first and third are scalar PMCs. The second is an aggregate containing three PMCs. 07:29
The first PMC goes into P1. The items of the second go into P2, P3, and P4. The third goes into P5.
This is all caller side.
The callee sees that it has five PMC parameters in registers P1 through P5.
Does that increase complexity anywhere? 07:30
allison caller side the items would be in P1, P2, P3, not P1-5
chromatic Well it shouldn't.
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?
allison what you get on the caller side is exactly what was passed in
something, somewhere has to flatten it out
and, it has to have a place to store what was flattened out
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
that's the mistake the earlier code made
chromatic Why is that a mistake? 07:33
allison let me be clear
we can merge call signatures and contexts
possibly even return continuations 07:34
chromatic I think we have to do the former. I'm all for that.
allison that is, I kind of agree with you
but the old way isn't the right way to get there 07:35
chromatic I agree with that too.
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.
allison especially, I'm curious if most of that 2.5 times slow down is in the returns, rather than the calls
chromatic It's both. 07:37
allison chromatic: useful to know
and, yes, that is what I'm saying
not perfect, a step in the right direction
chromatic Mostly it's everything called from the set_args PC op.
allison have you been able to run more complex profile examples yet?
chromatic Not yet.
allison chromatic: ah, that's building the call signature 07:38
chromatic: that could be vastly simplified
chromatic Parrot_pcc_build_sig_object_from_op is the expensive part.
allison chromatic: yes, that doesn't surprise me
chromatic: it's creating quite a few PMCs there too
chromatic That's mostly it, yes.
allison how hard do you think it would be to create a typed array? 07:39
that is, it can store a pmc or string pointer, or directly store an integer or float value
in each array slot?
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
so it can be stored in a ResizablePMCArray
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)
yes, we have a signature, so we know what type each element should be
chromatic That's easy.
allison and, we're storing them with, for example set_integer, get_integer_native, etc
chromatic Just make a ResizableSTUFFArray which stores a union.
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.
A union wouldn't hurt anything though. Might be safer too.
allison a blob of memory large enough to hold anything from a pointer to a float
chromatic That's a union, yep.
allison yes
okay, so that's step one on reducing PMCs created 07:43
chromatic We can even make it safe.
allison step two is to hold the array/hash data directly within the CallSignature, rather than having it hold array and hash PMCs
chromatic Right, that's a huge savings right there. 07:44
allison that cuts down two more pmc allocations
chromatic You cut down PMC allocations here by two thirds and you're onto something.
allison the third is eliminating the CPointers for returns (switching over to the same typed array as calls)
07:44 particle left
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
chromatic Sorry, ~1,180,000 STRINGs.
allison we could make it a struct instead of a PMC, like the old system did
chromatic GC pressure is the biggest problem right now.
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.
Capture's push_integer is about a third of runtime.
allison that makes sense, as the fib example was all integer arguments, yes? 07:47
chromatic CallSignature inherits that one, right?
Yes.
allison yes, it inherits that one
so, the typed array maybe the first obvious optimization
allison adding notes to the CallingConventions wiki 07:48
chromatic Improving storage within CallSignature seems like a bigger improvement to me.
allison chromatic: well, I'd do both at the same time 07:49
that is, implement the typed storage within CallSignature, rather than as a separate PMC
chromatic Oh, right.
That makes sense. 07:50
My only remaining concern is that it's risky to do these things with tests failing on the branch.
allison chromatic: that's why I haven't started them yet
chromatic: it's too hard to know the source of failing tests
chromatic: but, someone could work on CallSignature independently 07:51
chromatic I'd hate to merge the branch without these optimizations, though.
allison chromatic: that is, take the tests dukeleto has implemented for CallSignature, and use that to prove functional equivalence
chromatic How good are the tests? 07:52
allison and also to demonstrate the speed enhancements
chromatic: a lot better than they were
chromatic: though, there are likely untested cases 07:53
chromatic I'm sure there are.
allison still, it's enough to do the work
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.
allison yup
honestly, they could work on it in a branch of trunk, that just updates CallSignature and the CallSignature tests
it's a strictly isolated part of the system 07:54
it has to provide the same interface to work, but how it works internally is open
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
I can create the branch now if anyone's interested in working on it 07:56
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:57
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
and, it would have to be this weekend, since our merge deadline for 1.7 is next Tuesday
cotto unlurks briefly 07:59
allison (unless we decide optimizations are important enough to delay the merge)
(which I'm willing to accept)
chromatic I admit a certain sympathy in that direction.
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"
chromatic s/week/minute/
cotto How likely is it that the branch will be ready to merge before the deadline without those optimizations?
chromatic There's the big unknown.
allison cotto: pretty likely
we're down to 73 failing tests 08:01
chromatic 67
allison last weekend we killed 800+ failing tests
chromatic haz a magic power
allison chromatic++
chromatic It was a facepalm for cotto.
cotto does this magic power involve getting a good summary from recent versions of Test::Harness?
chromatic I said "magic", not "godlike". 08:02
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:08
08:09 einstein joined
allison chromatic: by groundwork you mean "create the branch"? 08:09
chromatic create/cause to be created/merge over tests/whichever
I'm saving my brainpower for important things like not losing a toe to the hedge clippers.
allison chromatic: yup, can do, within the hour 08:10
(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.
allison and those blackberries'll take to extremes 08:13
chromatic That's rare; _Safe as Milk_ was hard to find when *I* bought a copy in the '90s. 08:14
allison I still haven't managed to find a copy, but I remember it anyway 08:16
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
chromatic Get the 12 song version if you can. 08:17
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
I actually liked it 08:19
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
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.
allison ah, the wonders of stock photos
I wonder if that model has died her hair and started wearing glasses or something 08:22
but then, I suppose models don't move in the same circles as technical book readers
chromatic You'd be surprised. 08:23
treed Didn't OSCON just happen?
allison maybe she hooked up with a Java geek who think's it's totally cool she's on the cover of his book
chromatic I can't walk past Abercrombie and Fitch here without seeing particle's shiny visage.
allison treed: yes, this is the contract for next year
treed Ah.
Yeah, I just missed being in the area this year.
treed recently moved to Mountain View. 08:24
allison particle's secret life as a model?
treed Would have liked to come.
Haha. Awesome.
allison treed: ah, Mountain View is a good place
treed tried running rubyspec.
on cardinal, that is
No output!
Clearly that means we're at 100% and nothing remains to be done.
cotto clearly
treed dusts his hands off and goes to do something else.
chromatic I have a spare hedge trimmer. 08:25
treed Actually, there is output.
cotto on to the next big thing
treed [1:23] [inara:/Users/treed/code/rubyspec]% mspec -t ../cardinal/cardinal
This compiler is built with the Parrot Compiler Toolkit, parrot revision 40987.
But that's it.
chromatic Just tell them to stop monkeypatching.
Must be something in their local Kernel:: 08:26
treed Or just that Cardinal really sucks. :-P
allison treed: I'm at about the same place on Pynie
treed I wonder if they have a list of the minimal stuff an implementation must support.
allison treed: the hard thing is, these test suites assume a full working interpreter
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
treed It specifically mentioned that something was hard to implement in Rubinius and was specifically avoided.
allison treed: so I can get there in stages, and know I'm passing features along the way
treed nods.
Cardinal has its own test suite.
allison does Rubinius have a bootstrapping test suite you can use?
chromatic If you do something similar, treed, you might talk to Rubinius and see about donating bootstrapping tests.
treed Mostly, from my point of view, for regression testing. But we have some tests that were never passing. 08:28
similar in what fashion?
chromatic Extracting bootstrapping tests.
treed I mean, we have tests for basic functionality.
using a very very simple module
And outputting TAP.
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
treed It's possible that Rubinius has some tests besides using rubyspec. 08:31
treed checks
allison treed: I converted Pynie's tests to Subunit output, which does the same thing as TAP, but is Python-based
treed nods.
allison s/would/wouldn't/
treed I wrote a TAP harness into our Rakefile.
allison treed: nice!
treed Could probably be abstracted out into a proper module. 08:32
It's pretty basic, and has been specifically adapted to the way I write tests.
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.
treed That is, I have specific shit that happens with TODO and SKIP
And if you have one of those and the comment doesn't mention an issue number, the rakefile will bitch at you.
This is to ensure that everything that is marked todo and skip is known and on the radar. 08:33
Instead of sitting in a file somewhere.
chromatic A powerful aegis. So to speak.
mikehh mind you that might have been Trout Mask Replica
treed trac.parrot.org/parrot/ticket/977h...ticket/977 08:36
shorten treed's url is at xrl.us/bfrffv
treed dammit
trac.parrot.org/parrot/ticket/977
That one. 08:37
purl that one is probably silly to. It's an impl detail, right?
treed It can be closed, but I don't have the ability to close it.
cotto treed, done 08:38
dalek TT #977 closed by cotto++: parrot_config returns with an error about "Invalid Charset"
treed Thanks.
Yeah, rubinius also has unit tests of their own.
maybe I can try those out 08:39
Honestly, it's not like I don't know what needs fixing, though.
Mostly I ran rubyspec out of curiosity.
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
Then I got busy with the job offer and moving.
Still moving, actually.
cotto treed, good pun
treed But things are calmer now.
Heh.
allison treed: btw, are you at google? 08:41
treed IMVU
Which is in Palo Alto.
allison (mountain view)
treed I just live in Mountain View.
allison ah, makes sense
treed PA is much more expensive.
allison Palo Alto is spendy
yes
and Mountain View is right next door
treed The Facebook effect, as my coworkers call it.
allison :)
treed Turns out that facebook gives employees a stipend of $650 OSLT to live within a mile of the facebook offices. 08:42
So, all the rents are inflated by $650 in that area.
Facebook used to be in the building right next to us.
Looking forward to spending time at the Hacker Dojo now that I'm here. 08:43
08:43 quek joined
treed A place I can go hang out and hack on shit is pretty sweet. 08:43
And maybe I can recruit some more folks.
As I member I could give presentations and such.
allison treed: yeah, it's a very cool idea 08:44
treed A bunch of my co-workers were involved with that stuff and the SHDVs before it. 08:45
I knew a bunch of them from way back.
And used to get really envious of the SHDH parties.
allison the best jobs are the ones with those kinds of connections
it's so much better than wandering into a new office cold 08:46
treed nods.
Lots of really smart people at IMVU. I'm really enjoying the job so far.
Other than the fact that much of my job depends on me coding in Perl5. >_>
Ops guys use Perl, Engineering uses Python/C++.
no love for ruby
allison interesting combination 08:47
treed It's just about who was there to write stuff in the beginning.
because so much of the early stuff was in those languages, the related stuff stayed with those languages.
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
treed Although not enthusiastic about Perl6, sadly.
Yeah.
One of the engineers was trying to get me to subvert ops and start writing stuff in Python.
Because they have to interface with our stuff.
And hate having to interface python to perl.
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)
treed Management doesn't want to spend the effort maintaining APIs in both languages.
Honestly, I'd be enthused to not have to mess around with references.
allison yeah
treed I spent a whole afternoon banging my head into a wall trying to embed arrays in hashes in hashes. 08:50
allison :)
treed Tene finally explained it to me the next morning when I'd calmed down and was able to understand his words.
And it makes sense, historically.
But it's still ass.
My boss looked at me funny for putting arrays in hashes in hashes. 08:51
But it really was the most sensical representation of the data.
there are hosts which have many interfaces which each have two data rates
makes sense to me
I could have made classes for it, but I'm still far from understanding Perl OO.
Hm. 08:52
cardinal's rake smolder takes longer than it did last time I ran it
almost 11 minutes now
I'd be more enthusiastic about converting ops to python if python wasn't so comparatively verbose when doing text munging. 08:53
Which is a lot of what we do.
So perl6 would be really nice.
allison aye, I've noticed the string handling differences between python and perl 08:54
treed Well, mostly it's the 08:55
my_re = re.compile('blahblahblah')
my_re.match(str)
oh, and you have to save the match object
rather than just str =~ /blahblahblah/
Really, I just want the syntactic sugar. 08:56
treed heads to bed. 08:57
purl follows treed
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)
treed: g'night
treed night!
mikehh trunk - pre/post-config, smoke (#28795) PASS, fulltest FAIL at r41789 (see TT #1102) - Ubuntu 9.04 amd64 09:00
hey you bunch - no new commits to test for a couple of hours :-} 09:04
allison mikehh: I'll get cracking :) 09:09
(after I create chromatic's branch)
09:48 bacek joined
mikehh rakudo (1b83557) builds on parrot r41789 make test / make spectest_smolder (up to 28713 -> #28801) PASS - Ubuntu 9.04 amd64 09:52
10:03 payload joined
mikehh holy ... rakudo spectest_smolder reports tests as 35,121 ok, 0 failed, 520 todo, 6,851 skipped and 0 unexpectedly succeeded 10:05
10:10 darbelo joined
darbelo thinks IMAGE_IO needs to become a PMC, like, yesterday. 10:14
darbelo wonders if that can be done without deprecating anything. 10:21
dalek rrot: r41790 | allison++ | branches/pcc_optimize_sig:
Creating branch for refactoring calling conventions, to work on trimming down the creation/initialization time and memory footprint of the CallSignature PMC.
 10:36
moritz is that the successor of the pcc_reapply branch? or an entirely different beast? 10:38
darbelo moritz: Both? 10:40
purl hmmm... Both is country *and* western or salt and MSG
moritz purl: forget both 10:42
purl moritz: I forgot both
einstein i found a bug in the capture.pmc mark function, it does something which is just imposible 10:48
i uses it's own attributes instead of the array
darbelo einstein: If it's imposible, how can it do it?
;)
allison einstein: could you explain a bit more?
darbelo einstein: you mean the PARROT_CAPTURE(SELF)->data_size ? 10:50
einstein yes the PARROT_CAPTURE(SELF) would be index [2] of the data array 10:51
yes the PARROT_CAPTURE(SELF)->data_size would be index [2] of the data array
10:52 joeri joined
darbelo data_size is an ATTR, it's pre-allocated allong with the two PMC pointers. (Capture uses auto_attrs) 10:53
einstein &(PMC_data_type(SELF, PMC **)[2]) == &(PARROT_CAPTURE(SELF)->datasize), that is the problem 10:54
dalek rrot: r41791 | allison++ | branches/pcc_optimize_sig (2 files):
[pcc] Copying over CallSignature PMC and tests for independent development.
 10:55
einstein PMC ** const data = PMC_data_typed(SELF, PMC **); should be something like PARROT_CAPTURE(SELF)->array
darbelo PARROT_CAPTURE(SELF)->array is a (PMC *) not (PMC **) 10:58
dalek rrot: r41792 | allison++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
[pcc] A bit of internal renaming on the CallSignature (they're not "returns"
 10:59
darbelo What you want is &(PARROT_CAPTURE(SELF)->array)
allison einstein: ah, you're talking about trunk, not branch 11:00
einstein yes it is the main trunk yes
darbelo Which, coincidentally is the same as PARROT_CAPTURE(SELF)
or PMC_data(SELF) 11:01
purl PMC_data(SELF) is a void *
darbelo Which, as purl pointed out, is the wrong type. 11:02
allison einstein: that has been fixed on the branch
einstein: see trac.parrot.org/parrot/changeset/4...apture.pmc
shorten allison's url is at xrl.us/bfrfor
einstein oh ok then i will do update, it is little week ago i did a update 11:03
allison einstein: well, it hasn't been merged into trunk yet 11:04
einstein ah ok
allison einstein: but it will be in a week or two
einstein ok that is good to know, thanks for the information 11:05
allison einstein: good catch, by the way. that was a non-trivial error 11:06
einstein yes I know, thanks for your help 11:08
11:09 masak joined 11:29 bacek joined
dalek TT #1100 reopened by bacek++: t/src/extend.t: failing in trunk 11:33
rrot: r41793 | bacek++ | trunk/src/call/context.c:
[cage] Initialise Context.current_sub in init_context.
 11:37
11:55 mokurai left 12:22 jsut_ joined 12:23 JimmyZ joined
mikehh pcc_reapply - make spectest_smolder #28808 at r41793 - Ubuntu 9.04 amd64 12:51
trunk - pre/post-config, smoke (#28809) PASS, fulltest FAIL at r41793 (see TT #1102) - Ubuntu 9.04 amd64 12:52
13:00 quek left 13:01 kid51 joined 13:06 JimmyZ joined
dalek TT #1100 closed by jkeenan++: t/src/extend.t: failing in trunk 13:13
13:23 ruoso joined
darbelo lapses into a coma. 13:24
kid51 reads scrollback to see what possibly could have induced darbelo's coma 13:29
13:39 workbench joined
darbelo recovers from the coma. 13:39
lack of exitment.
13:42 plobsing joined
JimmyZ .\\miniparrot.exe config_lib.pasm > runtime\\parrot\\include\\config.fpmc 13:47
Malformed string
make: *** [runtime\\parrot\\include\\config.fpmc] Error 1
14:16 Psyche^ joined
dalek rrot: r41794 | jkeenan++ | branches/detect_llvm (2 files):
Refactor four instances of handling verbose output.
 14:16
14:26 theory joined
dalek kudo: bd7966f | jonathan++ | src/ (15 files):
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
shorten dalek's url is at xrl.us/bfrf5h
dalek kudo: 4cdac8a | moritz++ | perl6.pir:
make backtraces a bit less noisy

obvious.		 14:35
purl i guess obvious is redirect to where you want to be
shorten dalek's url is at xrl.us/bfrf6a
dalek kudo: 925fd06 | jonathan++ | src/ (2 files):
Tweak to .constraints to pass another spectest.
 14:46
shorten dalek's url is at xrl.us/bfrf7o
dalek rrot: r41795 | jkeenan++ | branches/detect_llvm/t/steps/auto/llvm-01.t:
Test previously unexercised branches.
 15:27
Tene ... Huh. 15:29
I go to start working on pcc stuff, and then I fall asleep for 13 hours.
So, um... good morning, all.
kid51 Good morning, tene 15:30
So far, not much sign of a hackathon here today yet
dalek kudo: 3208e7b | jonathan++ | src/parser/actions.pm:
{%h} constructs a Hash, not a closure
 15:37
shorten dalek's url is at xrl.us/bfrgct
15:38 einstein joined
jonathan 13 hours...that's...quite some sleep... 15:41
15:45 tetragon joined
jonathan Eww. I'm seeing some lovely segfault/assertion failure in Parrot. 15:47
context.pmc line 66 - Parrot_gc_mark_PMC_alive(INTERP, ctx->current_sub); 15:48
Seems sometimes this pointer is junk.
So trying to mark it explodes.
I actually get it at startup of Rakudo under the debugger...though not under the debugger it doesn't seem to happen.
Others are hitting it occasionally. 15:49
In init_context it appears we don't set the ->current_sub pointer. 15:51
And hey, that clears up the segfault. Whee. 15:56
dalek rrot: r41796 | jonathan++ | trunk/src/call/context.c:
[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
Tene okay, os how can I get a count of failing tests? 16:10
dalek kudo: 27d9f14 | jonathan++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get a fix I just put in for a segfault.
 16:11
shorten dalek's url is at xrl.us/bfrggx
dalek rrot: r41797 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Check returns count properly.
 16:12
16:13 rhr joined
Tene okay, :flat returns don't work. 16:19
fixing... 16:22
purl rumour has it fixing is good, definitely
Tene LIES. 16:23
16:26 kyle_l5l joined
Tene Hmm. Not sure where to do this correctly. 16:27
allison's pseudocode doesn't mention :flat returns anywhere... maybe she wanted them processed elsewhere? 16:28
dalek tracwiki: v26 | tene++ | CallingConventionsOverview 16:29
tracwiki: fix a minor typo
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfrgi9
16:32 msmatsko joined
Tene Ahh, they're handled in the sig building. 16:35
dalek p-rx: a0788f8 | pmichaud++ | src/Regex/Cursor-builtins.pir:
Add some builtin subrules to Cursor.
 16:41
shorten dalek's url is at xrl.us/bfrgmb
dalek p-rx: 86f5d68 | pmichaud++ | (8 files):
Add lexical $�.
shorten dalek's url is at xrl.us/bfrgmd
Tene oh, nm, that's for results, not returns... >< 16:43
16:47 payload joined 17:06 einstein joined
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
that doesn't seem *too* bad.
Tene jfdi 17:49
allison Tene: sounds reasonable 18:02
18:03 mberends joined 18:04 Patterner joined
Tene allison: thanks. 18:05
dalek tracwiki: v3 | darbelo++ | ItsABughunt 18:30
tracwiki: trac.parrot.org/parrot/wiki/ItsABu...ction=diff
shorten dalek's url is at xrl.us/bfrg22
18:33 chromatic joined
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.
Thus you're not getting your CallSignature PMC in the next couple of hours.
allison chromatic: no worries, I'm just getting down to parrot work for today myself 18:57
nopaste "tene" at 24.10.252.130 pasted "allison++: review this patch?" (84 lines) at nopaste.snit.ch/18294 19:02
"tene" at 24.10.252.130 pasted "The same, but with a type check" (87 lines) at nopaste.snit.ch/18295 19:05
allison reviewing second one 19:06
Tene Oops, the second one violates C90
nopaste "tene" at 24.10.252.130 pasted "The same, but doesn't violate C90w" (88 lines) at nopaste.snit.ch/18296 19:07
Tene ... argh
It helps to *test* patches before pasting them.
just a variable name problem. s/aggregate/return_item/ 19:08
I'm not proud of return_index--, but it seemed better than adding guards to every other return_index++
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:10
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
Tene: looks good in general
Tene Okay, great.
It fails t/compilers/imcc/syn/tail_4.pir though... checking why.
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.
allison: I don't have any objections.
allison Tene: okay, I'll work the magic on Parrot_pcc_fill_returns_from_op 19:13
Tene Great.
allison Tene: (and then see about Parrot_pcc_fill_returns_from_c_args)
Tene: those shouldn't interfere with the lines you're working on 19:14
Tene No, they shouldn't.
pushing... 19:19
purl it has been said that pushing is the answer
Tene purl: shoving?
purl shoving is the answer or
treed pushing and shoving and pushing and shoving me
Tene no, shoving is the answer to the terrible secret of space! 19:20
purl okay, Tene.
dalek rrot: r41798 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] The first step in handling :flat returns.
19:26 einstein joined 19:28 mokurai joined 19:30 ash_ joined
Tene more fixes! 19:32
dalek rrot: r41799 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Add a termination condition to the slurpy-result-filling loop.
 19:33
nopaste "tene" at 24.10.252.130 pasted "my test failures" (42 lines) at nopaste.snit.ch/18297 19:36
19:39 darbelo left 19:41 bacek joined
Tene 75 failed for me 19:42
Hmm. Smolder is nice. 19:43
dalek rrot: r41800 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Turn on new return handling code for everyone.
Tene reclaimed 6 tests by fixing a test regex. 19:52
dalek rrot: r41801 | tene++ | branches/pcc_reapply/t/op/cc_params.t:
[pcc] Update a regex in t/op/cc_params.t
 19:53
Tene 2two more 19:56
dalek rrot: r41802 | tene++ | branches/pcc_reapply/t/op/cc_state.t:
[pcc] Another test regex fix
mikehh pcc_reapply - make spectest_smolder #28825 at r41800 - Ubuntu 9.04 amd64
Tene smolder server is down? 20:02
back up now, it seems. 20:04
mikehh trunk - pre/post-config, smoke (#28824) PASS,fulltest FAIL at r41800 (see TT #1102) - Ubuntu 9.04 amd64 20:05
dalek a: 10c0499 | fperrad++ | src/ (2 files):
implement trigo hyper
 20:09
Tene 67 failed at 41802
shorten dalek's url is at xrl.us/bfrhft
dalek a: 9b5ce12 | fperrad++ | t/lua-TestMore:
update submodule lua-TestMore
 20:14
shorten dalek's url is at xrl.us/bfrhf9
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:20
and t/oo/composition.t which exits in subtest 21 out of 45 20:21
I get 6,441 ok, 62 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded at r41802 - #28829 20:24
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:32
Tene mikehh: thanks, I'll do that. 20:34
working on composition.t right now.
I think I know what the problem is.
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:38
of course it has changed a bit since then 20:39
I was working in a different dir 20:40
Tene okay, yes, got composition.t's failure reduced to minimal pir 20:45
bacek Good morning 20:49
20:49 mikehh_ joined
Tene fixed composition.t 20:50
committing.
25 more test passes
allison Tene++
Tene r41803 20:51
dalek rrot: r41803 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fix a copy/paste error in fill_params for named pmc params.
 20:53
rrot: r41804 | bacek++ | trunk/src/runcore/profiling.c:
Revert "[cage] Reduce scope for C string in runcore_profile_init."
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
i don't know what to do with it... don't understand mmd at all. 20:54
in src/multidispatch.c +716 20:55
down to 32 failed. 20:56
allison mmd should ignore named args 21:02
(they don't participate in multiple dispatch, only positional args are signiicant 21:03
f
)
21:04 rhr joined
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'
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.
allison Tene: if it gets an 'S', it should check if the next item is an 'n' and stop building if it is
Tene OK.
allison (preventing, rather than undoing)
Tene: similarly for Pf 21:07
(though it may already be doing that)
Tene What is 'f'?
purl 'f' is bottom lip and top teeth
allison :flat
nopaste "tene" at 24.10.252.130 pasted "like this? for allison++" (27 lines) at nopaste.snit.ch/18299 21:09
Tene Well, I'll just try it. No coretests fail because of it, afaict...
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"
Tene Yeah, I got that. It didn't compile otherwise. :)
allison Tene: then do the same for the 'P' case
21:11 mikehh joined
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
bacek allison: ah, ok
but... why?
allison Tene: Sn and Pf, yes
dalek rrot: r41805 | mikehh++ | branches/pcc_reapply/src/call/args.c:
fix a bunch of line length errors in src/call/args.c
 21:12
allison bacek: hrmph... 21:14
purl i guess hrmph is the key word to ambiguosity
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?"?
allison Tene: you can skip Pf for now
Tene: I'll come back to it
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)
Tene I'll make it skip for now, to comply with old behavior.
allison Tene: 'f' will either be ignored, or it will be stripped out of the signature string before it reaches mmd 21:17
Tene: ("ignored" as in, that item not counted for MMD)
Tene so should I terminate sig processing on seeing 'f' or no?
allison Tene: either way, it shouldn't be getting stray 'f's 21:18
Tene: yes, do
Tene: because flats should be processed before MMD if they're going to be
Tene: MMD can't handle unprocessed flats, so just ignores them 21:19
allison recovering previous logic
Tene committed. this doesn't affect any coretests. 21:21
21:21 kid51 joined
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 nopaste.snit.ch/18300
dalek rrot: r41806 | tene++ | branches/pcc_reapply/src/multidispatch.c:
[pcc] Stop build mmd type tuples on named and flat parameters
 21:22
Tene several of the op/calling.t failures are anti-failures. We're not failing when we should be. 21:24
mikehh pcc_reapply - smolder_coretest #28835 at r41805 - 6,539 ok, 27 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded 21:29
dalek rrot: r41807 | tene++ | branches/pcc_reapply/t/op/calling.t:
[pcc] Update three more error message text tests
 21:35
p-rx: b0e696b | pmichaud++ | src/Regex/Cursor.pir:
Remove some obsolete methods from Cursor.
 21:36
p-rx: 5ecd319 | pmichaud++ | src/Regex/Cursor.pir:
Partial change of match stack to a cursor stack, update bstack handling.
shorten dalek's url is at xrl.us/bfrhqx
shorten dalek's url is at xrl.us/bfrhqz
dalek p-rx: 7b01e97 | pmichaud++ | src/Regex/Cursor.pir:
Manage cstack on mark_fail.
shorten dalek's url is at xrl.us/bfrhq3
mikehh pcc_reapply - smolder_coretest #28838 at r41807 - 6,542 ok, 24 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded 21:44
Tene allison: still awake? 21:45
dalek rrot: r41808 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Get flags for optional results from the right sig
 21:48
chromatic idly wonders if subclasses of CallSignature would make the default case fast and let us replace runtime conditionals with compile-time polymorphism. 21:49
21:56 Whiteknight joined
Tene hi whiteknight 21:57
Whiteknight hello Tene! 21:58
how's the hackathon going?
Tene s'okay. a lot closer.
fill_results is the default now
last I heard, allison was working on making fill_returns_from_c_args use fill_results. 21:59
I think she might be sleeping, though.
we're down to 20-something failures in coretest.
Whiteknight ~20 failures! Awesome
Tene these last failures I'm running into, I don't know what to do with at all.
optional results aren't getting their opt_flag set when the sub doesn't return at all 22:00
tailcalling into an NCI doesn't work.
is anyone using the result_info opcode at all? 22:02
ah, optional results... I bet I can fix those. 22:03
oh, I already did. 22:04
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
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
Tene: (not sleeping yet)
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
Tene another failure: if the sub doesn't have any .params, where can we check for excess args?
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.
Tene: (the first one, that is)
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 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
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
Tene: I've tracked the problem as far as the :flat handling code in fill_results
Tene Huh.
dalek rrot: r41809 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] two fixes from allison++
 22:14
allison Tene: specifically, this line is returning an invalid address (not NULL, or PMCNULL, just illegal) 22:15
1573 PMC *return_item = (constant) ? accessor->pmc_constant(interp, return_info, return_ index)
1574 : *accessor->pmc(interp, return_info, return_index); 22:16
(pardon the strange IRC wrapping)
22:16 bacek joined
Tene Fascinating. 22:16
allison hmmm... pmc_from_varargs returns PMC** 22:19
bacek allison: we need 4 other _from_varargs functions for fill_returns 22:20
allison: scratch it. 22:21
my mistake
allison bacek: we're only using the functions to access the elements passed in from varargs (the same as fill_params)
yeah
bacek: I mean, it would be possible to use functions for both fetching and setting, but we're not at the moment 22:22
bacek allison: we have to review all calls to fill_params_from_c then. Currently params/returns passed slightly inconsistently. 22:23
allison bacek: the function pass them is just a list of varargs, the same for both 22:24
to pass
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
&pmc);
and Parrot_pcc_fill_returns_from_c_args(interp, _call_object, "P",
ret)
allison why is pmc_from_vararg fetching a PMC**?
in the existing code it was fetching a PMC*
bacek because it's passed as PMC**
(in fill_params) 22:26
allison the parameters are passed as PMC** so they can be set with the arg value? 22:27
bacek: then, yes, we do need another set of pointers for fill_results
because they're passed as PMC*
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
bacek I don't see reasons why they inconsistent.
allison bacek: args and returns are passed the same
bacek: it's params and returns that are different 22:29
(because returns are args, not params)
(results are params)
bacek yeah
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?
allison bacek: no, they're doing different things 22:33
bacek: an arg/return just passes a simple value
bacek yes, but we can always pass pointers
allison bacek: a param/result passes a pointer to a value
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
Anyway, those functions are bad. I don't like them at all. 22:35
allison bacek: what, the function pointers?
Tene he means fill_params and fill_results
bacek no, this particular set of functions
foo_from_bar
allison bacek: at least most of the behavior is abstracted into the common fill_params and fill_results now 22:37
bacek: the distinction is limited to a prelude
bacek: and a different signature (one takes a vararg list)
bacek We just need pair of classes with shift_foo for fetching param/returns and push_foo to set arg/results 22:38
then we can avoid copying staff into CallSignature.
22:39 Wolong joined
bacek build_sig_object will just set this fetchers/fillers. 22:39
Tene allison: what error needs to be thrown fro: 'foo'('abc', 'def'=>1, 'ghi', 'jkl'=>1) ? 22:40
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
Tene Could it be "too many positional args", or does it need to be "named args must follow all positional args"?
allison Tene: that's "named args must follow all positional args"
bacek allison: we will avoid creating CPointers at all
allison bacek: we'll do that anyway, once we unify the two
chromatic allison, did you put your task notes somewhere? 22:42
allison chromatic: it's open in my browser, not submitted yet, give me a sec and they'll be on trac.parrot.org/parrot/wiki/Callin...nsTasklist 22:43
shorten allison's url is at xrl.us/bfqjf4
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
Tene allison: you mean positional args?
allison Tene: mixing named and positional returns is always an error
Tene: both (returns are args) 22:45
Tene allison: could I throw the error in build_sig instead of fill_params?
allison Tene: yes
Tene: build_sig is the primary arg processor
Tene ah, nm, got it. 22:47
22:52 Wolong joined
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
bacek: (because we want to be able to call both without modification)
bacek allison: indeed.
allison bacek: I'll leave them with a consistent signature for now so that's not necessary 22:59
Tene I'm apparently failing some tests that mikeh isn't? 23:07
allison Tene: what are the platform differences? 23:08
chromatic: oh, forgot to submit again, doing it now
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 rrot: r41810 | tene++ | branches/pcc_reapply (2 files):
[pcc] Fail correctly when positional args are passed to slurpy named params
Tene allison: awake to explain some error checking to me? 23:19
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:25
nopaste "tene" at 24.10.252.130 pasted "This works in trunk and fails on the branch, unless you uncomment" (11 lines) at nopaste.snit.ch/18302 23:26
Tene If I set err_check to 0 inside the conditional testing that value, then it passes. 23:27
23:29 jrtayloriv joined
allison chromatic: CallSignature refactor notes added in trac.parrot.org/parrot/wiki/Callin...nsTasklist 23:32
shorten allison's url is at xrl.us/bfqjf4
allison Tene: yes?
Tene: I wondered about that, but I checked and it's on by default in trunk too
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
Tene PGE extensively relies on extra named args not being failures.
allison Tene: then for now they must not be failures in the branch
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
Tene so should I change the trailing "if (err_check)" branch in fill_params to if(0) oslt? or just delete it?
dalek tracwiki: v12 | allison++ | CallingConventionsTasklist
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfrh34
allison Tene: keep the code, but comment it out 23:35
Tene: (not a recommended usual practice, but in this case the right one)
Tene argh embedded comments... can I #if 0 ?
allison Tene: it should have a TT ticket
Tene: yes, #if 0 is okay
Tene: or #ifdef SOME_SENSIBLE_NAME 23:36
Tene it also needs some tests, theoretically.
allison Tene: write them as todo tests for how it should work
Tene allison: after this pending commit, it looks like everything compiles correctly, I think... 23:37
'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:38
It compiled... running 'make smolder_test' right now. 23:41
dalek rrot: r41811 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Don't fail on extra named args
 23:42
allison Tene: excellent! 23:44
purl zwooshes
kid51 Hmm. Even when I configure on Linux/i386 with --buildframes=0, I still get 4 more failures than mikehh: smolder.plusthree.com/app/public_pr...ails/28843 23:46
shorten kid51's url is at xrl.us/bfrh5f
jonathan Looks like good progress. Tene++, allison++ 23:47
japhb Infinoid, what's the status of the gitorious parser for dalek? 23:48
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:50
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:51
japhb Anyone still hacking on it, or is it stalled? 23:53
Infinoid darbelo started it, I took that and hacked a little (the output of that is nopaste.snit.ch/18273) 23:55
he may have hacked more, I don't know.
23:57 patspam joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!