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.
japhb Infinoid, OK, where is that committed? I don't see it in github.com/Infinoid/dalek-plugins/t...les/local/ 00:00
shorten japhb's url is at xrl.us/bfrh7j
Infinoid I didn't commit it anywhere 00:01
japhb Infinoid, Oh, the thing you pasted looked like a commit diff ... 00:02
Infinoid oh. /me =~ s/commit/push/
nopaste "kid51" at 70.107.16.27 pasted "pcc_reapply: make corevm on Darwin/PPC: 2 build errors" (2 lines) at nopaste.snit.ch/18303
japhb would you mind pushing? I think I might have some hack left in me today ... 00:03
00:04 TiMBuS joined
japhb applies several dozen dB of sonic energy to the task of increasing the hack 00:05
Infinoid pushed to devel branch. 00:07
japhb Would you prefer I fork or add me to your repo as a committer?
dalek rrot: r41812 | mikehh++ | branches/pcc_reapply/t/pmc/multidispatch.t:
remove TODO from passing test in t/pmc/multidispatch.t
 00:08
Infinoid I don't mind giving out commit bits. I just have to look up how
japhb github ID same as here ( japhb )
allison Tene: if I'm getting 26 failures on the branch with the fill_returns_from_c_args patch, does that mean I'm causing the failures, or have you not committed your final fix yet? 00:10
Infinoid japhb: you're added 00:11
japhb Infinoid, thanks!
Infinoid msg darbelo you've got a commit bit on the dalek-plugins repo. your plugin and test are in the "devel" branch 00:12
purl Message for darbelo stored.
Tene allison: I didn't say that all of 'make coretest' passed, I said that I could successfully run 'make test'
allison Tene: okay, I'll assume I'm not causing those failures (or at least not a substantial number of them) and go ahead and commit 00:13
Tene allison: I also get 26 failures on coretest
allison Tene: excellent 00:14
Tene allison: smolder.plusthree.com/app/public_pr...ails/28844 is the smolder report for a full 'make test'
shorten Tene's url is at xrl.us/bfrid2
allison It is really nice to be able to run 'make test'
Tene we only have 91 failed in all of 'make test'
mikehh I think I am only getting 22
Tene mikeh: yes, I commented earlier that I'm seeing failures that you aren't. I'm curious about which they are.
allison Tene: I'm getting 86 test failures on 'make test' (Mac OSX) 00:17
mikehh pcc_reapply - smolder_coretest #28846 at r41811 - 6,544 ok, 22 failed, 100 todo, 162 skipped and 0 unexpectedly succeeded
Tene allison: I have a total of 10,667 tests. you? 00:18
allison Tene: urg, just overwrote that window with a diff 00:19
Tene What windows?
purl windows is, like, one hell of an event
Tene Ah.
Well, we'll get there.
mikehh running make smoke now 00:20
Tene mikehh: looks like the difference comes from t/pmc/threads.t 00:21
You pass more of those than I do.
mikehh I am running with --optimize (plus otherr stuff)
pcc_reapply - make smoke #28848 at r41811 - 10,625 ok, 82 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 00:27
dalek rrot: r41813 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Change 'Parrot_pcc_fill_returns_from_c_args' to use the shared

accessor functions, since args and returns don't pass pointers like params and results.
purl well, results is @results seems to work but no result => displayed I see the links but not the results...
mikehh need to take a break for a bit - bbl 00:28
Coke skips review.
mikehh actually the smoke was at r41812 - although it reports 41811 - I thought I had reconfigured 00:31
bbl 00:32
allison Tene: I'm 86/10526 00:37
So, I guess some of your failures are skipped tests on Mac OS X 00:38
Tene could be.
I'm trying to debug the big pct failure right now. 00:39
looks like a bad plan... should work on other stuff first. NQP isn't working at all. 00:41
allison Tene: t/compilers/pct/complete_workflow.t? 00:49
Tene: it's 2am here, off for some sleep, will dive in again tomorrow 00:51
Tene Goodnight, allison 00:52
allison Tene: curiously, the t/pmc/coroutine.t failure survived complete refactors of the argument and return handling code 00:53
Tene: must be unrelated to either
Tene that failure was already there?
Hmm... need to figure out what to work on next. 00:54
allison Tene: yes, it's been the same failure for a long time
Tene: which is curious with all the changes we've made
Tene: g'night
Tene: (especially odd since I thought the problem there was that we weren't handling the :optional flag on returns) 00:56
bacek We still don't handle :opt_flags on returns 00:58
Tene we *should*... I just tested it like an hour ago. 00:59
bacek: can you provide me with a test case that doesn't work?
bacek Tene: coroutine_8.pir
Tene :P
bacek When we have single optional value while(1) loop exits too early. 01:00
Tene Huh. 01:03
kid51 pcc_reapply branch: make coretest: Darwin/PPC: I get 24 failures. 01:04
smolder.plusthree.com/app/public_pr...ails/28845
shorten kid51's url is at xrl.us/bfrijq
Tene kid51: we can run 'make test' in pcc_reapply now.
kid51 Tene: Does that indicate I should run 'make' rather than 'make corevm'? 01:06
Tene kid51: yes.
bacek: Huh. You're right. 01:07
kid51 Do you have any idea when we will no longer need to configure with --buildframes=0 on x86?
bacek Tene: of course :)
Tene kid51: when someone gets around to either ripping out or fixing the remnants of oldjit.
might want to try to con WK into it. 01:08
That is to say, I don't feel confident that I could fix it, so I'd only look at it as a last resort. WK has talked about JIT a lot and has some history with ASM, and iirc he has fixed the oldjit at least once in the past. 01:16
chromatic Mostly it's just updating some calls to get and set parameters. 01:33
Whiteknight eh? 01:46
who is conning me into what?
nevermind, /me backscrolls 01:48
and now it's time for bed, later
Tene Whiteknight: update the frame builder inthe pcc branch. 01:49
Whiteknight right, I'll get on that
Tene Whiteknight: tat is, that's what you're being conned into.
Whiteknight gotcha
goodnight
Tene 'night
argh NQP is failing in a very weird way... 01:55
claiming that some class doesn't have a 'returns' method. 01:56
japhb Infinoid, pushed to devel branch of dalek-plugins; all gitorious.t tests now pass. 02:00
Tene pmichaud: ping 02:02
Infinoid nice, I didn't know about m//g before
japhb Infinoid, :-) 02:03
So ... trade you code for a parrot-plumage feed? ;-) 02:04
Infinoid Sure, it's worth trying out 02:05
02:09 nopaste joined 02:13 dalek joined
Infinoid (from dalek's log) parrot-plumagelog gitorious ATOM parser autoloaded. gitorious.org/parrot-plumage.atom 02:14
japhb OK, I'll try a trivial commit
02:14 bacek joined
Infinoid seen masak 02:17
purl masak was last seen on #parrot 1 days, 14 hours, 20 minutes and 14 seconds ago, saying: good post-lunch coma, whiteknight. [Oct 9 11:49:06 2009]
02:25 JimmyZ joined
japhb dalek? 02:27
purl somebody said dalek was #parrot's spammy little rss bot or (see: dalek plugins)
japhb Infinoid, any way to tell dalek to check feeds immediately? 02:28
Infinoid if it were going to generate output, it already would have 02:29
japhb damn
Infinoid I've got outside-of-bot debug tools that tell me the plugin should be working, but debugging things in dalek itself is kind of a pain
rrot-plumage: 21cfa3b | japhb++ | :
[BUILD] Makefile.in: NQP_PBC is dead, long live PARROT_NQP
 02:30
shorten Infinoid's url is at xrl.us/bfriwb
Infinoid oh! unlike github, gitorious will let us shorten that hash to 21cfa3b
japhb There's a commented-out warn() that can be changed to print to the log file, that would show the bot's thinking ... though if the output above was from you running it manually, I'm not sure what's wrong. :-( 02:32
Infinoid, you mean we can shorten the review link that we send to the channel? 02:33
Infinoid yes
That output was from me preemptively setting $self->{not_first_time} in gitoriousparser.pm and running test.pl on it 02:34
test.pl is a crocky sort of dalek-emulator.
(and it's in the repo in modules/local/ if you're curious just how crocky) 02:35
02:35 janus joined
japhb :-) 02:35
Need dinner now. I pushed another commit just to see if dalek notices this one. 02:52
dalek rrot-plumage: 305f5b5 | japhb++ | :
[META] Update README to reflect requiring parrot_nqp
 02:56
shorten dalek's url is at xrl.us/bfrizc 02:57
03:05 coke joined
coke seen pmichaud ? 03:06
purl pmichaud was last seen on #parrot 1 days, 8 hours, 56 minutes and 32 seconds ago, saying: NQP doesn't have closures? It should. If it doesn't, it will. [Oct 9 18:01:09 2009]
Coke seen dukeleto? 03:07
purl dukeleto was last seen on #parrot 1 days, 3 hours, 43 minutes and 3 seconds ago, saying: allison: ok, will include a test for it then [Oct 9 23:15:46 2009]
Coke seen infinoid?
purl infinoid was last seen on #parrot 31 minutes and 50 seconds ago, saying: (and it's in the repo in modules/local/ if you're curious just how crocky)
Coke Infinoid: ping.
Tene oh! This is going to be horrible to track down!
in trunk, an nqp compiler method gets a PAST::Val object, while in the pcc branch, it gets a NQP::Grammar object 03:08
This is horrible! I'm not looking forward to tracking this down at all!
Exclamation marks!
Infinoid Coke: hi 03:09
Coke Infinoid: can you add github.com/partcl/partcl to the commit trackr? 03:10
bacek Tene: I can say you why it's failing. Key PMC isn't properly handled in branch. So NQP fetching wrong value. 03:11
Tene bacek: magical coding robot indeed... I think I remember seeing some failing key tests? 03:12
bacek Tene: yeap.
Infinoid Coke: Sure. I'm surprised it isn't already there; I had to rework my test suite due to the repo move (and due to the link being on the Languages page) 03:13
Coke Infinoid: partcl's in there elsewhere. 03:14
I'm moving the repo.
Infinoid basically, if the link on Languages is right, I shouldn't have to do anything manually
Coke Infinoid: aha.
I'll change that. 03:15
Infinoid it's already there
however, since I don't see any output from github partcl in the channel log, I'll figure out what went wrong
Coke Infinoid: nothing. 03:17
purl i guess nothing is open or closed or nothing
Coke I was trying to be proactive, is all, and I see dukeleto beat me to it.
sorry I didn't follow through before checking.
s/checking/asking/ whoops 03:18
anyone here familiar with how rakudo/rakudo is setup? 03:19
Tene wtf@ t/pmc/object-meths_22.pir 03:29
dalek kudo: 7ec926f | (Kyle Hasselbacher)++ | t/spectest.data:
[spectest.data] fix filename typo
 03:32
shorten dalek's url is at xrl.us/bfri35
Tene wtf keys 03:34
purl keys is Wakeman.
Tene no, keys is wtf
purl okay, Tene.
bacek Tene: yum, Keys :). Problem in $I1 = $P1[$S0] 03:36
[$S0] is Key PMC with reference to STRING register. 03:37
and trying to use it in fill_params lead to dark land on undefined behaviour.
Tene ;_; 03:38
bacek What you have to do is move clone_key_arg calls from fill_params to build_sig_object. 03:39
And uncomment early return in clone_key_arg
Tene first step 0: understand clone_key_arg
bacek And check in which Context this functions called. Because you probably don't need to save/restore registers 03:40
Tene: ignore it. I'll fix it few minutes 03:42
Tene Thank you, bacek. I was feeling lost. 03:45
bacek Tene: how much expected failures in coretest? 03:46
Tene I think it was, like, 24 or 26 or soething.
there's some number that vary by platform.
between 20 and 30
bacek ok 03:47
Tene Yeah, I got 26 and mikey got 22 03:48
mikeh
bacek mikehh :) 03:59
Tene: fixed. At least object-meth.t passed 04:00
Tene bacek++
commited yet?
yes 04:01
bacek r41815
Tene nqp still fails. :( 04:02
Tene rebuilds, just in case.
bacek Just because there is still 12 failing tests in calling.t 04:03
04:03 mberends joined
dalek rrot: r41814 | bacek++ | branches/pcc_reapply/src/call/args.c:
[cage] Pass proper variable into exception
 04:03
rrot: r41815 | bacek++ | branches/pcc_reapply/src/call/args.c:
Fix passing Keys.
Tene nqp still gets the wrong class. 04:06
I'll look through the rest of calling.t 04:07
several issues from tailcalls.
Still don't know how we're going to catch the "no params" and "no returns" cases. 04:09
dalek rrot: r41816 | bacek++ | branches/pcc_reapply/src/call/args.c:
Fix passing constant strings as named returns.
 04:23
Tene allison: Wait, no, PARROT_ERRORS_PARAM_COUNT_FLAG can't be on by default in trunk... because that .pir file fails when i explicitly turn that flag on with errorson in trunk 05:02
allison: this is demonstrated in t/op/calling_83.pir
Oh, um, I think that commit was maybe bad. 05:04
dalek rrot: r41817 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fail when building a sig for a duplicate named parameter
 05:05
rrot: r41818 | tene++ | branches/pcc_reapply/src/call/args.c:
Revert "[pcc] Fail when building a sig for a duplicate named parameter"
Tene okay, named returns are definitely broken. 05:14
bacek_at_work Tene, not only them :)
dalek rrot: r41819 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fail when building a sig for a duplicate named parameter and don't crash.
 05:18
bacek_at_work Tene, you have to check flag before throwing exception 05:24
Tene bacek_at_work: there's something weird there... that flag is on by default in the branch, but off by default in trunk... but allison thinks that it's on by default in trunk? but I don't think it is? I don't quite know what's going on there. 05:26
bacek_at_work Tene, bacek@illusion:~/src/parrot$ grep -2 'by default' docs/pdds/pdd03_calling_conventions.pod 05:30
If too many or too few values are provided for the given target registers,
Parrot by default will throw an exception for C<get_params>, but not for
C<get_results>. This error behavior can be controlled via the C<errorson> and
C<errorsoff> opcodes using C<PARROT_ERRORS_PARAM_COUNT_FLAG> for C<get_params>
chromatic The parameter check warning? It's off by default in trunk.
Tene That's what I thought.
chromatic I enabled it once and deep hurting.
Tene well, it's enabled by default in the branch, and needs to be turned off. 05:32
treed I know there's a git command that will do a super-duper clean of the working directory. 05:35
That is, deleting everything that's not there because of git.
But I can't remember the command.
git clean -f seems to work partially
I guess rake clobber takes care of the rest.
bacek_at_work treed, git reset --hard HEAD 05:37
Tene that won't delete non-tracked files. 05:38
treed Is Coding Red on planet parrot yet? 05:39
Okay, so. 05:41
Method 'iterator' not found for invocant of class 'String'
Did that get removed or something?
Because these tests used to pass.
Tene a string iterator? what would that do? 05:42
as well, I'd be surprised if there was an iterator method on the string pmc.
treed There's certainly nothing in my code calling it anyway.
ack iterator only shows one file where I'm calling iterator as a method 05:43
And it's on cardinal;Range, which defines it in the same file.
That error message is at the end of a long chain of current instr.: 'parrot;POST;Compiler;pir_children' pc 9676 (src/POST/Compiler.pir:77) and things like it
(or rather, the start, but the end temporally) 05:44
but, anyway, I'd expect a string iterator to iterate over the characters in the string, for one 05:45
This came up (or something like it), once before
and got fixed
Tene even then, you wouldn't get it by calling the 'iterator' method on a string. 05:46
you would use the 'iter' opcode.
treed Sure.
And nowhere in cardinal is anything explicitly calling that method on a string.
Tene so if you're calling the iterator method on a string, it's not related to that.
treed There are only two instances of calling an iterator method on anything in cardinal, and they're both a Range calling its own method 05:47
There is some code where cardinal;String calls iter self 05:48
There's a lot of iter all over the source.
gist.github.com/207475 05:49
that's the full error output
I get that from any of three test files.
Something's failing in the compilation step.
mikehh pcc_reapply - make smoke #28858 at r41819 - 10,629 ok, 78 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 05:50
treed Also, there have been some speedups in Parrot execution in the last month or so.
The precompiled cardinal test suite now only takes 20 seconds to run. 05:51
Used to be 28-30
compilation still takes about as long, though
although that 20 seconds number may be off slightly because of the three files not actually being executed
But I doubt those three make that big of a difference.
12:03 < mikehh> the culprit -> parrot: r40788 | jonathan++ | trunk/compilers/pct/src/PAST/Compiler.pir 05:54
That's where mikehh previously tracked down the start of this test failure.
I note that this file *does* call a method 'iterator' in some cases. 05:55
iter = node.'iterator'() 05:56
nopaste "mikehh" at 86.178.198.194 pasted "test summary report for pcc_reapply branch at r41819" (38 lines) at nopaste.snit.ch/18306
treed Can you even use iter as a variable name?
mikehh note that 48 of the failures are from t/compilers/pct/complete_workflow.t 05:57
Tene Yes, although I'll look at you funny.
mikehh: yes, as I noted earlier, NQP doesn't actually work. 05:58
treed tene: That's in Parrot.
So don't look at me funny.
Tene treed: I'll have to find some other more-complimentary way of looking at you, then. ;) 05:59
treed Line 410 of compilers/pct/src/PAST/Compiler.pir is where that 'iterator' method call is
Heh. I didn't realize you swung that way.
I wish the vim syntax highlighting for PIR was more reliable. 06:00
Sometimes when I'm scrolling around it seems to lose track of what shit is and color it all the same
Tene ^L
but, yeah
treed Seems to have to do with perldoc
dalek rrot: r41820 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Handle named returns more properly.
treed Could post_children be expecting something other than a String? 06:01
Return the POST representation of evaluating all of C<node>'s
children in sequence.
Seems likely, given that description.
But somehow it's getting a string, but only in very rare cases. 06:02
actually, the backtrace says that it's in pir_children, not post_children 06:03
but that's not even in that file
Oh, I was looking at the wrong file.
>_>
so, line 77 06:04
Tene Okay, I fixed named returns, but NQP is still schizophrenic. I don't want to step through every sub in the NQP compiler.
treed Hm. 06:07
Seems like pir_children would have to be handing itself a string. 06:08
Which would require that one of the children be a string.
Can I even effect what happens at that level in POST?
(I being cardinal)
mikehh pcc_reapply - make smoke #28862 at r41820 - 10,630 ok, 77 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 07:15
note that 46 of the failures are from an early exit in t/compilers/pct/complete_workflow.t - Parse errors: Bad plan. You planned 54 tests but ran 8 07:16
Failed tests: 7-8 then exit 07:18
nopaste "allison" at 77.98.130.30 pasted "Demo code for Tene, chromatic, bacek demonstrating that parameter count errors is *on* be default in trunk" (9 lines) at nopaste.snit.ch/18307 07:23
allison Tene: I thought PARROT_ERRORS_PARAM_COUNT_FLAG was off by default in trun too, but running code examples shows otherwise 07:24
07:25 fperrad joined
allison Tene: running t/op/calling_83.pir in trunk, after deleting the explicit 'errorson', still gives me an error about "duplicate named argument - 'a' not expected" 07:41
Tene Hmm.
Okay.
allison What's strange about the branch is it's *not* giving an error about the duplicate parameter 07:42
Tene allison: it does now.
allison Even with an explicit errorson
Tene but it's not guarded with the errors flag
allison Tene: okay, will try rebuilding again
Tene allison: named returns work in the branch now, but not named flattened returns. 07:43
allison Tene: will have to check trunk, but I think the duplicate arg shouldn't be guarded by the errors flag
Tene nods. 07:44
allison Tene: named flattened returns are where you stuck in the exception "named flattened returns don't work yet"?
Tene Yes.
Well...
if you try it, it fails even earlier.
allison Tene: so, they just don't have an implementation yet
ah, okay, logic error somewhere 07:45
Tene allison: search for "named returns must have a value"
that's what gets thrown if you try.
allison: I'm currently stumped by NQP's weird behavior... it ends up getting an object of the wrong class somewhere, which seems like a very bizarre failure mode. I haven't felt up to tracking it back through NQP by hand to see where it gets confused. 07:46
allison Tene: I just ran 'svn up' and 'make' and t/op/calling_83.pir still doesn't give me a 'duplicate argument" error
Tene: or any error at all
Tene allison: that's because I commented out that section at the end of fill_params, which seems to have been the wrong thing to do. I don't have any idea why I thought it was right. 07:48
dalek rrot: r41821 | mikehh++ | branches/pcc_reapply/src/call/args.c:
fix codetest failures - unused assert macros, line length and space before parenthesis
allison Tene: because uncommenting it makes the PGE build fail 07:49
Tene ah
allison Tene: (I just tried it)
Tene: but, that means we've go a surface error case
Tene does PGE do an errorsoff? chromatic says that error checking is off in trunk, and that everything died horribly when he tried turning it on.
allison Tene: (that is, a surface fix *looks* like the right one, but isn't)
Tene: yes, that's what I thought too
Tene: I was horribly surprised when I ran code examples on trunk and found that it was errorson by default 07:50
Tene: I don't know when it changed
Tene: maybe PGE is setting errors off somewhere? 07:51
and the branch isn't picking that up properly?
Tene no, it doesn't use errorsoff.
I bet pmichaud would know.
allison Tene: yes 07:53
Tene: maybe it's an error in the code to count how many named args have been used? 07:56
Tene: like, a named arg is used somewhere but not counted?
Tene No, the part that was failing in PGE had one named param, and was called with zero named args.
allison Tene: oh, then the error message is backwards... hmmm... 07:57
Tene: was the one param marked optional?
oh, or was it called with enough positional args to fill the named param?
Tene one positional arg and one positional param. 07:58
lemme check, though. I really don't trust my memory.
oh, yes, I misremembered. 08:00
It's *extra* named params passed to a sub that *doesn't* have a named param. 08:01
nopaste "tene" at 24.10.252.130 pasted "like this" (8 lines) at nopaste.snit.ch/18308
Tene *that* example runs in trunk and fails in the branch.
even with all error flags turned on 08:03
allison Tene: okay, missing params bad, extra params fine (at the moment) 08:04
Tene Right.
allison Tene: so we'll need to temporarily mock that behaviour in the branch 08:05
mikehh pcc_reapply - make smoke #28864 at r41821 - 10,630 ok, 77 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded
allison Tene: technically, I'd call that a bug in trunk, but it's apparently a bug someone was relying on 08:07
Tene Yes.
mikehh of the 77 listed failures 52 are not run (well 50 the 2 tests exit) - t/compilers/pct/complete_workflow.t - Parse errors: Bad plan. You planned 54 tests but ran 8 08:10
and t/library/coroutine.t - Parse errors: Bad plan. You planned 6 tests but ran 2
Tene Yes, pct's workflow test can't run because NQP doesn't work at all. 08:11
not sure about coroutine... 08:12
it has to do with optional returns
mikehh Yes I noticed - nqp_test failed completely when I ran make test before commiting r41821
it doesn't run with make smoke
anyway codetest passes at the moment 08:16
need to take the dog out - bbiab
allison Tene: okay, but how is that different from t/op/calling_83.pir? 08:17
trunk complains "too many named arguments"
Tene allison: you're going to love this. 08:18
allison: it behaves differently in the case of zero named params.
nopaste "tene" at 24.10.252.130 pasted "this fails in trunk for allison++" (9 lines) at nopaste.snit.ch/18309
Tene so, definitely a bug.
allison Tene: okay, that's really a bug :)
Tene but one that PGE seems to be relying on. 08:19
allison Tene: I'm inclined to say we fix PGE
Tene nodnod
or we just put the branc off until pm finishes his PGE replacement. ;)
allison either it adds a named param, or stops passing that extra named arg 08:20
Tene: nooooooooooooo! :)
Tene: do you have the info still lying around on where you found the mismatched call and sub in PGE? 08:22
Tene: I'll add a :optional param to the sub
nopaste "tene" at 24.10.252.130 pasted "There's a reason I have my terminal scrollback set at the maximum it will let me" (7 lines) at nopaste.snit.ch/18310 08:23
mikehh alison: I use konsole which allows me to set unlimited scrollback 08:28
mind you at the moment it is using 493.5MiB Virtual Memory and 60.8 MiB resident memory 08:31
Tene use the ram if you have it. 08:33
mikehh Tene: it is - none of the Virtual Memory is on storage media 08:34
allison mikehh: I'm on my Mac at the moment, the Linux laptop died
mikehh: (the replacement is being shipped as we speak) 08:35
mikehh Actually - I have a graphics card I want to install which will reclaim another 512MB - giving me 8GB to play with 08:45
the on-board graphics on the Asus M4A78 Pro is ok for what I need but my son just got a new one and his old one is still very good 08:48
allison Tene: blech, it's not just one sub in PGE, it's dozens 08:49
Tene: basically, any rule that's called may be called with a named "actions" arg
Tene yeah
allison Tene: but, only some of them actually accept a named "actions" param
Tene: I'm adding in a more limited version of your error quieting, that only does it if there were no named parameters handled 08:50
Tene nodnod 08:51
I pretty much know what's going on in PGE, and I'm not too concerned about it. We can deal with it.
The NQP issue is proving a lot more frustrating to understand.
After I wake up tomorrow, I'm going to ave to just walk thgough the entire thing. 08:52
08:55 allison joined
allison Curious, my Mac just rebooted itself 08:55
allison thinks this isn't her month for hardware
treed Mine's been crashing a lot lately. 08:56
Actually, my work laptop too.
Something about the screensaver was making it freeze.
08:57 bacek joined
allison I'm just hoping my Mac lasts until my new Linux laptop arrives, don't know what I'd do without a computer... 08:57
Tene does perl run on your cellphone? 08:58
;)
allison Tene: :)
09:13 jrtayloriv joined
dalek TT #1103 created by allison++: [CAGE] Optional named parameters must be explicit 09:15
rrot: r41822 | allison++ | trunk/DEPRECATED.pod:
[pcc] Add a deprecation notice for optional named parameters that aren't
 09:26
bacek allison: why we need deprecation notice for buggy behaviour? 09:27
allison bacek: because it was part of the interface
bacek allison: so every single bug (or undefined behaviour) requires deprecation cycle? 09:28
allison it's one of those edge cases where the behavior wasn't defined by the spec, so the implementation is the spec
bacek: no
bacek allison: where is the crossing line? 09:29
allison I'm sure there are hundreds of little bugs with the old implementation we're cleaning up without realizing it
but if it's big enough that it causes a major external system to fail horribly (in a way that's non-trivial to fix), then it's a deprecation item
and, we certainly won't always catch all of those 09:30
but we'll try
bacek It's specced btw. 09:31
If too many or too few values are provided for the given target registers,
Parrot by default will throw an exception for C<get_params>
so, it's better to fix bug in PGE now instead of putting more hacks... 09:32
allison bacek: the problem is, there's no way to be sure we caught all of them 09:33
bacek "all of bugs" or "all of usage"?
allison bacek: I fixed the ones that allowed PGE to compile, but ran across a huge number more in the PGE tests
"all the cases in PGE that need an explicit optional named parameter added to the sub" 09:34
because it's one point invoking a dynamically looked up sub object
bacek Are all this calls in single place? 09:36
allison I can't guarantee that
and even if we got PGE to pass all the tests, we still wouldn't know if we'd caught all of them
bacek yes 09:37
but proper behaviour is specced.
allison (there are times when dynamic dispatch is a pain)
yes, it's true, but the practicality of the deprecation policy is that we don't rip the carpet out from under our users 09:38
even if it was our mistake that allowed them to wander down the path in the first place
bacek I think that all our 6 users can adjust their code to be in-line with spec. 09:40
allison that's what we used to say 09:41
and the pain it causes is the reason we have deprecation cycles
dalek rrot: r41823 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Turn on named parameter count checking again, with a smaller restriction
 09:42
09:49 mokurai left 10:36 masak joined 10:55 fperrad_ joined 10:58 quek joined
bacek fperrad: ping 11:13
msg fperrad can you confirm that TT#1093 still failing on win32? 11:14
purl Message for fperrad stored.
11:18 joeri joined
mikehh pcc_reapply - make smoke #28871 at r41823 - 10,630 ok, 10,631 ok, 76 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 11:23
11:26 kid51 joined 11:32 Whiteknight joined 11:33 ruoso joined
dalek kudo: 0a5ec87 | (Solomon Foster)++ | t/spectest.data:
Turn on S06-operator-overloading/workout.t.
 11:36
shorten dalek's url is at xrl.us/bfrjxm
mikehh did make fulltest on pcc_reapply - most of the runcore tests look the same except TestS which has a few more errors - will analyse later 11:40
11:54 jrtayloriv joined 11:57 JimmyZ joined
dalek kudo: e5562c9 | util++ | build/Makefile.in:
RT#69684 Fixed parallel build by adding dependency.
 12:04
shorten dalek's url is at xrl.us/bfrjzd
kid51 Util ping 12:05
12:16 edgar joined
JimmyZ å¦‚ęžœęƒ³äŗ†č§£ parrot ļ¼ŒåÆ仄去那äøŖ频道ļ¼Œå¦å¤–ļ¼ŒchatzillaåÆ仄ꉓ钩ļ¼Œā€œOpen this Channel at startupā€ 12:17
sorry, wrong channel
kid51 msg Whiteknight Have you had a chance to take a look at trac.parrot.org/parrot/ticket/1067 ? Is this a GC-related problem? 12:31
purl Message for whiteknight stored.
kid51 msg Coke Any comment on trac.parrot.org/parrot/ticket/1068#comment:3 ? Thanks. 12:35
purl Message for coke stored.
12:36 edgar joined 12:40 iblechbot joined
JimmyZ edgar: ;) 12:45
edgar en ? 12:49
purl i heard en was the pronoun for "of them"?
edgar what JimmyZ?
purl JimmyZ are you watching this?
JimmyZ hello?
purl Raise your hand in the back if you can't hear me.
edgar reboot my computer just now 12:51
13:19 edgar left
fperrad ping bacek_at_work 13:20
purl I can't find bacek_at_work in the DNS.
13:20 quek left
fperrad msg bacek I confirm TT#1093 still failing on win32 (today seen with r41820) 13:23
purl Message for bacek stored.
13:38 preflex joined
Whiteknight kid51: I'll look at it now 14:01
14:14 Psyche^ joined 14:15 whoppix joined 14:31 tetragon joined 14:34 payload joined 14:51 theory joined 14:52 davidfetter joined 14:55 jan joined 15:01 msmatsko joined
Util kid51: pong 16:02
kid51 Util: Earlier I was looking for some git advice, but I eventually figured it out myself and then got a response on another channel. 16:22
mikehh kid51: ref TT #1061 - is that in the autoprops branch 16:23
dalek rrot: r41824 | allison++ | branches/pcc_reapply/src/ops/core.ops:
[pcc] Change the 'result_info' op to get signature information for new calls.
 16:25
kid51 mikehh: No: svn.parrot.org/parrot/branches/library_files
... though the diff posted to TT #1061 may suffice. 16:26
mikehh kid51: sorry was looking in the wrong branch - in the right one now 16:27
kid51 tries to remember if he had anything to do with the autoprops branch 16:28
mikehh kid51: was getting verry confuzezed - ha probably need some sleep :-} 16:30
kid51 no, autoprops is Util's branch 16:31
Speaking of branches .... 16:32
... for the Nth time, I wonder if there's anyone on Win32 (or a non-symlinkable filesystem) who could look at the tt509_install_files branch. 16:33
mikehh If I ever get time to properly set up kvm or VirtualBox properly on this box (wireless link) I might even install that as a guest 16:35
Util autoprops is for TT#994 16:38
17:02 chromatic joined 17:17 s1n joined
nopaste "mikehh" at 86.178.198.194 pasted "pcc_reapply branch - Summary of make fulltest failures at r41823" (66 lines) at nopaste.snit.ch/18311 17:37
mikehh pcc_reapply - make smoke #28886 at r41824 - 10,633 ok, 74 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 17:49
two more passing tests
kid51 quite a formidable list of failures there 17:50
mikehh kid51: which one - the fulltest or smoke? - most of the failures come from t/compilers/pct/complete_workflow.t - Parse errors: Bad plan. You planned 54 tests but ran 8. 17:53
kid51 I was looking at the fulltest
mikehh most of the cores have the same failures (one or two differences) 17:54
kid51 Given the number of failures, I doubt we can merge this branch before Oct 20.
mikehh I think I would like to test rakudo, partcl and cardinal at least, maybe some others 17:58
kid51 Well, if you have a generous supply of electrons, please do so :-) 17:59
moritz wouldn't it make sense to wait with that until PGE really works in that branch? (or does it already? it didn't last I looked)
mikehh but I would like to get most of the rest passing before that - and nqp_test which fails completely
jonathan If nqp fails to pass its tests, then I wouldn't hold much hope for Rakudo even compiling, let alone running. 18:00
mikehh jonathan - yes 18:01
Tene yes, it looks better than it is because nqp tests don't run as part of 'make smoke' 18:08
18:09 kasih joined
nopaste "mikehh" at 86.178.198.194 pasted "pcc_reapply branch - nqp_test failures" (14 lines) at nopaste.snit.ch/18312 18:09
18:09 mokurai joined
kasih salam 18:10
dalek rrot: r41825 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Modify the return handling logic, don't throw an exception when we run

results, so unfilled optional results and opt_flag results get taken care of.		 18:13
allison down to 28 failing tests in pcc_reapply 18:14
and that's 'make test' not 'make coretest'
moritz allison++
mikehh excellent - let's check that one :-} 18:15
18:17 bacek joined
moritz and all nqp tests are clean 18:21
time to check rakudo ;-)
parrot_config --dumb dies on the branch 18:24
erm, dump
Null PMC access in get_string()
current instr.: '_main' pc -1 ((unknown file):-1)
which prevents rakudo from configuring 18:25
18:30 rhr joined
mikehh pcc_reapply - make smoke #28889 at r41825 - 10,683 ok, 24 failed, 263 todo, 560 skipped and 0 unexpectedly succeeded 18:33
18:33 szabgab joined
mikehh and nqp_test passes - looking at fulltest now 18:34
nopaste "mikehh" at 86.178.198.194 pasted "pcc_reapply branch - Summary of make fulltest failures at r41825" (66 lines) at nopaste.snit.ch/18313 19:07
allison mikehh: useful, thanks! 19:11
nopaste "bacek" at 114.73.167.154 pasted "hack to allow parrot_config to run for moritz++" (13 lines) at nopaste.snit.ch/18314 19:27
19:29 chromatic joined
bacek sigh... We have to put all old Parrot_run_foo_fromc back. 19:30
Whiteknight why?
bacek Because of deprecation policy? 19:31
Whiteknight so keep them, but rewrite them to use the new PCC system 19:33
but don't let the evil stay
jonathan What's the Good Way to do that now? 19:41
We use those in some of the Rakudo dynpmcs, and while me switching won't allow breaking of deprecation policy, I'd be interested to know what the Better Way is.
chromatic Through Parrot_pcc_invoke_sub_from_c_args, I believe.
Whiteknight Am I only seeing like 15 failed tests? 19:42
jonathan Does that use varargs, or let me build up and pass along a CallSignature instead?
Tene Whiteknight: there are still issues with the jit frame stuff, iirc
chromatic There's a function to invoke from a CallSignature.
dalek kudo: 1305255 | moritz++ | t/spectest.data:
we now pass S12-methods/submethods.t
jonathan chromatic: OK, that's Good To Know.
shorten dalek's url is at xrl.us/bfrmb3
chromatic trac.parrot.org/parrot/wiki/Callin...nsOverview 19:43
jonathan Thanks. 19:45
19:46 joeri left
dalek p-rx: 08a47f4 | pmichaud++ | src/ (3 files):
Create Match objects lazily.
 19:50
shorten dalek's url is at xrl.us/bfrmcu
allison Whiteknight: I have 28, but yes, we're dropping rapidly 20:03
bacek: the Parrot_run_foo_fromc functions are not external functions 20:04
bacek: the Parrot_call_* functions are (which is why we provided backward compatibility functions) 20:06
jonathan: if you want to build up and pass along a CallSignature, use Parrot_pcc_invoke_from_sig_object instead 20:07
jonathan allison: Is a call signature a kind of "one-shot" thing? 20:09
20:09 bacek joined
jonathan allison: Or can you keep hold of it and re-use it for multiple calls? 20:09
allison jonathan: you could reuse it, it's not destroyed 20:10
jonathan: but, you'd have to make sure it's fully reinitialized each time
jonathan "fully reinitialized"?
allison jonathan: as in, no lingering data from the previous call to mess up the next one
bacek "fully reinitialized" is "destroyed old one and created new one". 20:11
allison a fresh PMC for each call is one way to be absolutely sure there's no old data
chromatic I have 17 failing coretests. 20:12
allison but, it's not the only way
jonathan: you would also have to be careful that you're not reusing the PMC while some outstanding call expects to still have it
jonathan: the CallSignature currently lasts through the subroutine, containing both arguments and returns, so it's not safe to reuse one to make one call within another, or for recursive calls 20:14
20:14 kurahaupo joined
kurahaupo gperl 20:16
kurahaupo wonders why IRC doesn't respond to PINE commands :-( *blush*
dalek rrot: r41826 | chromatic++ | branches/pcc_reapply (5 files):
[PCC] Made MultiSub invocation from C slightly less buggy. This doesn't

now.		 20:18
chromatic Sure, I threw a patch over the wall, but I did some nasty debugging to figure it out... so there. 20:19
chromatic eats pancakes
jonathan allison: OK, got it, thanks. :-) 20:21
nopaste "bacek" at 114.73.145.179 pasted "Patch for rakudo to use public API calls instead of internal functions (for johnatan++)" (100 lines) at nopaste.snit.ch/18316 20:27
bacek bah! 20:28
jonathan: nopasted patch was for you, not someone else :)
dalek rrot: r41827 | bacek++ | branches/pcc_reapply/lib/Parrot/Pmc2c/PCCMETHOD.pm:
[cage] Support bare RETURN() in PCCMETHOD.pm
jonathan bacek: aha, thanks...
:-)
I hadn't realized the ones I was calling weren't API. :-) 20:29
bacek me too :) 20:30
allison docs/embed.pod defines the API 20:31
jonathan What, I have to read something?! 20:35
;-)
dalek tracwiki: v13 | mikehh++ | CallingConventionsTasklist 20:40
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfrmjg
allison jonathan: well, it is pretty recent, jhorwitz finished it just before 1.4 20:51
bacek yay. t/src/extend passed. And todoed multisub test too. 21:09
dalek rrot: r41828 | bacek++ | branches/pcc_reapply/src (2 files):
Update return_flags in extend.c:append_result
 21:10
chromatic Nice tag team, bacek. 21:11
bacek chromatic: you can claim this test (and karma) now :) 21:12
chromatic Doing it now. 21:13
purl well, Doing it now. is it paying the bills? :)
bacek rakudo still failing to build...
oookey. 21:17
There is big chunk of code commented out in Continuation.invoke
it should be updated to new pcc.
dalek kudo: d749d9b | jonathan++ | src/pmc/p (2 files):
Apply patch from bacek++ to get us using documented Parrot API functions in place of some non-API ones.
 21:25
shorten dalek's url is at xrl.us/bfrmoz
22:47 TonyC joined 23:09 patspam joined 23:14 davidfetter joined 23:56 rhr 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!