Parrot 0.8.1 "Tio Richie" Released! | www.parrot.org/
Set by moderator on 22 November 2008.
jonathan chromatic: Cache invalidation ci'd. 00:02
all tests still passing here
dalek r33122 | jonathan++ | mmdcache: 00:03
: [rakudo] Cache invalidation when a Perl6MultiSub gets a new candidate.
diff: www.parrotvm.org/svn/parrot/revision?rev=33122
chromatic Running the tests now. 00:04
So far so good. 00:07
00:08 Theory joined
jonathan crosses his fingers...then uncrosses them again as it makes typing hard 00:10
00:10 AndyA joined
chromatic Looks good. I'll merge back unless you holler. 00:12
jonathan hollers "merge" 00:13
chromatic Working on that now. 00:15
00:22 nopaste joined, japhb joined
dalek r33123 | chromatic++ | trunk: 00:33
: [mmdcache] Merged the mmdcache branch into trunk for r30003 to r33122.
diff: www.parrotvm.org/svn/parrot/revision?rev=33123
r33124 | chromatic++ | mmdcache:
: Removed the mmdcache branch from the repository (merged in r33123).
diff: www.parrotvm.org/svn/parrot/revision?rev=33124
r33125 | chromatic++ | trunk: 00:36
: [docs] Fixed some typos and added some minor enhancements to the branching
: guide.
diff: www.parrotvm.org/svn/parrot/revision?rev=33125
jonathan chromatic++ 00:40
chromatic: Had you got some other performance tweaks in there besides the MMD cache too?
00:45 Limbic_Region joined 00:57 apeiron joined 01:01 kid51 joined
Infinoid kid51++ # ticket mongering 01:05
kid51 What can I say? It goes well with a Sunday afternoon beer. 01:06
Performed at www.drinkgoodstuff.com 01:08
jonathan mmm 01:10
jonathan has beer too
kid51 Infinoid: And speaking of RTs .... rt.perl.org/rt3/Ticket/Display.html?id=51718 01:14
jonathan Infinoid: I'm planning to dig into the bytecode stuff again soon.
chromatic jonathan, just a couple. 01:15
01:16 sjn joined
jonathan chromatic: Nice. :-) 01:16
chromatic Did you notice a difference?
jonathan A little, but it's always a tad subjective... :-)
When you're hoping for one. 01:17
Feel free to enhance and tweak the caching code. I'm not at all attached to it, I just wanted something that was quick enough to do and would give some benefit.
01:17 japhb joined
chromatic It's not too bad now. 01:17
jonathan Now we're got an interface, should be easy to enhance it on the inside.
Sure, I think we can squeeze a little more out of it.
But maybe not so much. 01:18
I don't like that we allocate a STRING* per entry.
They are GC-able.
chromatic I really do think moving the MMD vtable entries to PCC subs and getting them out of the vtable will help.
jonathan You mean dispatching in the op right to the MMD rather than going through the VTABLE only to have it do the same? 01:19
kid51 cognominal ping 01:21
chromatic More than that, having the generated MMD code manage arguments PCC-style rather than C style.
Hmm, there's a memory leak if you run ./parrot on a non-existent file. 01:22
kid51 Infinoid: here's another unresolved RT: rt.perl.org/rt3/Ticket/Display.html?id=50212 01:23
jonathan chromatic: Ah, so we don't have to marshall back to C again?
chromatic Exactly.
jonathan That may be a win, yeah.
chromatic I experimented yesterday with rewriting some of the vtable entries in primes.2 in PIR as :multi subs, and it's substantially faster. 01:24
jonathan Worth trying.
Wow!
I guess the C/PIR boundry is a tad costly...
chromatic Hugely.
jonathan In that case, certainly worth trying.
chromatic Right now I need to pack up and leave though. 'night all. 01:25
jonathan night
chromatic Oh, and good work closing tickets, kid51. Much appreciated.
01:27 Andy joined
dalek r33126 | jkeenan++ | trunk: 01:43
: Specify correct number of tests in plan.
diff: www.parrotvm.org/svn/parrot/revision?rev=33126
01:44 jimmy joined 01:45 Hadi joined, Hadi left 02:14 tetragon joined 02:31 tetragon joined
dalek r33127 | jkeenan++ | trunk: 03:03
: In configuration tests, substitute a simple 'use' for 'use_ok'.
diff: www.parrotvm.org/svn/parrot/revision?rev=33127
GeJ otitis(es?) suck! 03:14
dalek r33128 | allison++ | pdd22io_part2: 03:39
: [pdd22io] Use one-call version of 'readall' instead of pre-opening the
: filehandle. Faster because we can stat the file size and read in the
: whole thing at once.
diff: www.parrotvm.org/svn/parrot/revision?rev=33128
03:49 apeiron joined 03:54 Theory joined 04:16 Andy joined
jimmy coke? 04:17
purl i guess coke is mailto:will@coleda.com
jimmy ok
05:52 chromatic joined
dalek r33129 | allison++ | trunk: 05:52
: [cage] Add a deprecation notice for the 'open' opcode mode strings.
diff: www.parrotvm.org/svn/parrot/revision?rev=33129
r33130 | allison++ | pdd22io_part2: 05:55
: [pdd22io] Add in old mode-string parsing for backward-compatibility (to be
: removed after deprecation cycle).
diff: www.parrotvm.org/svn/parrot/revision?rev=33130
chromatic There are reasons why math uses‭ ‬f(x‭)‬ and‭ ‬f(x,y‭)‬ rather than‭ ‬x.f‭()‬,‭ ‬x.f(y‭)‬,‭ ‬and‭ ‬(x*y‭)‬.f‭()‬ --‭ ‬the latter is an attempt to express the idea of a‭ "‬truly object-oriented method‭" ‬of two arguments and to avoid the inherent asymmetry of‭ ‬x.f(y‭)‬. 05:59
(Bjarne Stroustrup
) 06:00
dalek r33131 | pmichaud++ | trunk: 06:29
: [core]: Fix up context leaks introduced in r33010.
diff: www.parrotvm.org/svn/parrot/revision?rev=33131 06:30
r33132 | allison++ | pdd22io_part2: 06:36
: [pdd22io] Add 'eof' method to FileHandle PMC.
diff: www.parrotvm.org/svn/parrot/revision?rev=33132
r33133 | allison++ | pdd22io_part2: 06:48
: [pdd22io] The 'rw' filehandle mode is truncating rather than appending unless
: 'rwa' is specified.
diff: www.parrotvm.org/svn/parrot/revision?rev=33133
07:10 uniejo joined 07:34 Hadi joined 07:36 apeiron joined 07:48 elmex joined 07:52 ff-wonko joined 08:00 Hadi left 08:19 alvar joined 08:41 iblechbot joined 09:03 chromatic joined 09:25 bacek joined 09:59 tomyan joined, tomyan1 joined 10:24 AndyA joined 10:26 kj joined 10:31 NotFound joined 10:34 contingencyplan joined 11:09 tomyan1 left
dalek r33134 | fperrad++ | trunk: 11:16
: [HQ9Plus] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33134
11:18 gmansi joined 11:31 Lorn joined 11:47 gmansi joined 12:01 gaz joined 12:19 skv joined 12:20 Maddingue joined
dalek r33135 | fperrad++ | trunk: 12:45
: [bf] change PASM registers to PIR registers
diff: www.parrotvm.org/svn/parrot/revision?rev=33135
12:48 pis joined
pis hello 12:48
purl que tal, pis.
jonathan purl claims another victim! 12:51
purl jonathan: what?
szbalint botsnack 12:52
purl thanks szbalint :)
cotto I didn't know that .jp was a Spanish-speaking tld. 12:56
szbalint hello 12:57
jonathan knowing purl, "que tal" will be swearing in Japanese, or something...
;-) 12:58
szbalint hello purl
hmz no trigger
sjn wonders what the {*} feature masak writes about is 13:02
can anyone help me with that? :) 13:04
pmichaud haven't read masak's writing yet
but I suspect the {*} is the 'actions' trigger
when encountered in a regex it calls a method in another object 13:05
sjn suspects he is too much of a perl6 newbie to understand what that means 13:08
m/(mymethod)/{*}/; # runs mymethod() ?
pmichaud regex foo { 'hello' {*} } 13:09
the {*} will call a method named 'foo' after matching the word 'hello'
sjn ooh
pmichaud it make it easy to write "after matching this pattern, trigger this method" types of things 13:10
sjn a sneaky non-intuitive opaque way to do event parsers :)
pmichaud well, a lot of times we want to do parsing without actions. {*} is a convenient way to do that. 13:12
sjn nifty feature, but definitely one of those "OMGWTF" things for everyone who isn't aware of this
pmichaud one could embed the action directly in the rule, but then you're always bound to the action.
if no actions are supplied (or if a 'foo' method doesn't exist), then {*} is the same as { * }
which basically means "do nothing" (or "do whatever")
sjn * is legal syntax? 13:13
what's the difference between ... and * ?
(sorry about the naĩve questions :-( ) 13:14
pmichaud "..." is yadda yadda yadda -- it means "I haven't defined this yet". It throws a warning if executed.
"*" is the "whatever term" -- it's used to mean "whatever" in various contexts. 13:15
e.g., 1..*
sjn so what effect would a "sub foo { * };" make? 13:16
would it return something useful?
pmichaud probably not. :-)
sjn would it make a warning like ... ?
pmichaud probably not.
I suppose it could return a Whatever object, but I don't know if that would then work the same as in other contexts. Probably would (but I'm not awake enough to know for sure yet.) 13:17
afk for a bit (getting kids off to school)
sjn suspects using {*} in a regex defaulting to { * } is one of those "silent bug" situations, where knowing this one feature means a _lot_ when debugging 13:19
sjn wonders if returning a plain "whatever" from a block should trigger a warning of some sort 13:21
13:26 tetragon joined
sjn "Warning: whatever operator used in void context. Did you mean, like, whatever?" 13:27
Coke woof. recent changes in parrot have killed tcl spec tests. 13:30
"2008-11-19 12:51",159,"v0.8.1",57,4001,2341,1059,601,12550
+"2008-11-23 22:59",172,"r33128",46,1822,1158,476,188,11353
(to be fair, I should run that tests again with the older version of tcl.)
2341 - 1158 ? 13:31
2341 - 1158
purl 1183
jonathan Coke: In terms of speed, or in terms of them now failing? 13:32
Coke failing. I was completing 57 files and passing 2341 tests; with recent changes, I am completing 46 files and passing only 1158 tests. 13:36
jonathan bisect, I guess 13:37
Coke running one of the individual tests now just to see what the failure mode is.
jonathan: que tal == idiomatic "what's up?" I don't -think- it's dirty. 13:44
jonathan: ayup: Parrot VM: PANIC: Out of mem!
C file src/gc/memory.c, line 137
kj Coke: you're using any PASM registers in partcl? 13:45
jonathan Coke: I know what it means in Spanish - I was saying that it may mean something offensive in Japanese. ;-)
Coke OH!
my bad. =-)
jonathan lived in Spain for 6 months, he at least learned that
Coke kj: I don't think so. But I wouldn't expect usage of them to manifest as a PANIC out of memory. 13:46
jonathan kj: Even if he is, that error message is a odd way to fail...
Coke jonathan: crap. I can't use the old version of tcl with the current version of parrot. (deprecated things removed.) 13:47
jonathan Arses. 13:48
Coke: A backtrace of where we crash like that would be good.
Coke jonathan: I presume it's very similar to the backtrace I posted this weekend. 13:49
(which was a panic in another test file.)
which looked very much like the infinite exception loops p6 was tripping over.
kj Coke,jonathan: you're right. Just wanted to make sure :-)
jonathan Ah, ouch. 13:51
Coke running latest tcl against v0.8.1 to see if it works or goes boom. Then I can try to bisect. 13:56
did pmichaud's exception changes ever hit trunk? 13:57
pmichaud ...exception changes?
Coke where I might have to change PIR code in the handlers?
pmichaud I think they all got changed already. 13:58
Coke post 0.8.1 ?
pmichaud pre 0.8.1, actually.
Coke I'm pretty sure you didn't change tcl, though. =-)
pmichaud tcl wasn't in the repo. :-)
Coke ok. if it was pre 0.8.1, then it's probably not that.
pmichaud I fixed all of the push_eh/pop_eh pairs that I found, but afaik we haven't enabled the core change in parrot that necessitated the change in the others. 13:59
Coke yah. it's just insanely hard for me to catch all the ways in which I am borked unless I run a daily tcl spectest. (which takes > 3 hours)
(and since it takes > 3 hours, i can't expect someone doing core dev to do it.)
14:01 grim_fandango joined
Coke ah, 32824 works, 33128 runs OOM. 14:03
(with partcl r172 in both cases.) 14:04
pmichaud (r33128) I blame pmichaud. 14:05
the changes I made in 33010 that caused some serious context leaks, fixed in 33131. 14:06
Coke well, there's about 158 commits in there; we'll see. =-)
pmichaud so if you got OOM, I'd suspect that.
Coke ah. so i should svn up first. ok. moment.
everything rebuilt, testing at 33135... 14:11
pmichaud++ 14:19
thanks, that saved me several hours of bisecting. =-)
PerlJam good morning #parrot 14:22
Coke loves the smell of GC in the morning.
14:23 PacoLinux joined
Coke . o O (not really) 14:23
14:26 dalek joined
Coke when GC runs, does it put as many PMCs as possible on the free list, or the minimum? 14:30
(testing a previously failing memory hog to see if it's improved: currently up to a parrot with 1.6G)
wondering what is keeping hold of what PMCs here. 14:31
ooh, 2.11G 14:35
once a .Sub is put in a .namespace, is it ever freed? 14:36
pmichaud it's like any other gc-able element, I would guess. It gets freed when there aren't any references to it any longer. 14:37
Coke (and, a related question, are anon Subs ever reclaimed? I would expect so, yes?)
also, is there any easy way to get the GC system to tell me what it's hanging on to?
pmichaud most of the subs I deal with tend to be part of their surrounding Eval PMC.
including anonymous ones. So, the anonymous ones stick around as well. 14:38
(at least until the entire Eval PMC is dropped.)
seems like it ought to be possible to get the GC mark function to provide some information about what it's traversing. 14:39
Coke there's no reason for partcl to be consuming this much memory. :|
I mean, I'm sure something is hanging on to a reference somewhere, but... ah, there. hit about 2.4G before exploding on my desktop. 14:40
Coke fires up valgrind. 14:41
valgrind?
purl valgrind is not only astonishingly clever, but also has a beautifully written manual. or developer.kde.org/~sewardj/ or an open-source memory debugger or see also cachegrind or kcachegrind or No Silver Bullet or a time saver or mostly working on FreeBSD or not working on windows
Coke valgrind parrot?
ah, wait, I already did a valgrind run and, as i recall, no one saw anything useful. 14:42
jonathan That certainly sounds like something is leaking...or references are being kept. 14:43
Coke I wonder if a run against something that actually completed would be more useful.
Infinoid purl, valgrind parrot is valgrind --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test 14:44
14:45 jimmy joined
Infinoid purl is ignoring me. 14:45
Coke src/pmc.c:476: warning: no previous prototype for 'pmc_free' 14:46
anyone with memory-fu; feather's /tmp/coke_leak has the results of a [puts hi] in tcl. 14:55
summary:
==24939== definitely lost: 163,112 bytes in 2,364 blocks.^M
==24939== indirectly lost: 125,331 bytes in 1,228 blocks.^M
==24939== possibly lost: 104 bytes in 1 blocks.^M
==24939== still reachable: 77,284 bytes in 7 blocks.^M
so that seems pretty lossy.
15:01 PacoLinux joined, masak joined
Coke I'm seeing a ton of these: 15:02
==24939== Use of uninitialised value of size 4
==24939== at 0x4211702: Parrot_dod_trace_children (dod.c:436)
15:02 Andy joined
Coke looks like it's because PMC* next; is never initialized; init'ing to PMCNULL and running make test so see if anything breaks. 15:06
Coke stresses that hINACP. =-)
15:06 skv_ joined
masak Coke: you just play one on TV? 15:06
15:07 skv__ joined
PerlJam Coke: Isn't line 436 where it is initialized? 15:07
Or does it only count when initialization happens at declaration? 15:08
(that would seem odd)
Coke t/pmc/bigint.t is failing the new pasm register stricture. 15:09
PerlJam: an excellent question. I have no idea why valgrind is complaining about that. 15:10
kj: ping
pmichaud Coke: I know it takes forever to do, but I'd be curious if the memory leak also occurs in r33009 (i.e., before my 33010 patch)
kj Coke: pong 15:11
bigint.t failing eh? moritz reported success yesterday
PerlJam If I were guessing, I'd say that some bit of current that PMC_next_for_GC() is using isn't initialized (also guessing that valgrind isn't smart enough to introspect #defines)
Coke pmichaud: checking. 15:16
PerlJam: am I wrong to expect macros to be all caps? 15:17
PerlJam Coke: probably. PMC_next_for_GC is a #define in include/parrot/pobj.h 15:18
Coke ok. that expands to (pmc)->pmc_ext->_next_for_GC
PerlJam ack++ :-) 15:19
Infinoid we have lots of mixed-case macros, e.g. PObj_is_PMC_TEST()
Andy PerlJam: Great! Now help me get tarball searching on it!
Coke PerlJam: ok. now that I know what that one macro expands to, I have... no idea how to fix it. =-) 15:20
Coke is tempted to just add it to the bottom of the valgrind supressions with a note that anything after this point might be fixable. 15:21
PerlJam Coke: me either. But I'd be looking for where ever the pmc_ext structure is created to make sure that _next_for_GC is initialized to NULL or something.
Coke supposes it would be easier to turn off that kind of valgrind warning for now. =-) 15:22
PerlJam Andy: sure ... first you tell the person running ack to untar the file in /tmp and re-run ack on that. :>
Andy: But I suppose you want to use Archive::Tar or something 15:23
Andy Yeah, see, that's sort of a suboptimal solution.
Coke pmichaud: Revision: 33009 15:26
still has the memory explosion.
pmichaud okay, that makes me feel better. 15:27
thanks for checking it.
kj Coke: you looking for me? 15:28
dalek r33136 | pmichaud++ | trunk: 15:29
: [core]: Improve a context refcount diagnostic just a bit.
diff: www.parrotvm.org/svn/parrot/revision?rev=33136
PerlJam pm: how goes the lex stuff? 15:30
dalek r33137 | pmichaud++ | lex5:
: One last branch for final development/testing of lexicals support.
diff: www.parrotvm.org/svn/parrot/revision?rev=33137
PerlJam oh, heh.
If I'd've waited a few seconds ...
Coke pmichaud: still some context-related leaks in trunk, it seems. 15:31
nopaste "coke" at 72.228.52.192 pasted "sample of context leaks?" (44 lines) at nopaste.snit.ch/14697 15:34
pmichaud Coke: yes, there were context leaks even before r33009 though. 15:36
r33009 wasn't intended to change the number of context leaks, just improve our ability to do something about them. 15:37
s/r33009/r33010/
Coke ok. they seem to be the largest single source of leaked memory in parrot right now. What can I do to help make them go away?
pmichaud we need to figure out what isn't calling Parrot_free_context() at the right time.
namespace_54.pir exposes a leak, and is short. 15:38
15:38 PacoLinux joined
Coke if i have a trace from valgrind that shows information about the leak, is that helpful? 15:39
nopaste "pmichaud" at 72.181.176.220 pasted "leaks in namespace_54.pir (r33009)" (127 lines) at nopaste.snit.ch/14698
Coke (for example, the partial one postedin nopaste?)
pmichaud valgrind's information tells us where the leaked memory was created
so whatever creates it ought to be cleaning it up at some point.
Coke since contexts are using refcounting, shouldn't that really narrow down the search area? 15:40
15:40 jhorwitz joined
pmichaud yes. 15:40
although I suspect part of the problem is in pccinvoke 15:41
Coke which test file is that from?
pmc/namespace.t?
pmichaud prove t/pmc/namespace.t
then grab t/pmc/namespace_54.pir
ooops. 15:42
Looks like the context leak in namespace_54.pir was fixed sometime between r33009 and head. :-)
Coke ? it's still leaking. 15:43
r33135
pmichaud okay, let me check.
maybe fixed in r33136? 15:44
that really shouldn't have changed anything, though.
Coke fixed between 33135 and 33137 15:45
... and 37 was in a branch.
so yah. retesting tcl...
pmichaud that's weird. 15:46
oh, wait.
yes, r33135 would've had a leak, now fixed in r33136.
Coke "puts hi" in tcl goes from: 15:47
==7590== definitely lost: 163,112 bytes in 2,364 blocks.
to: 15:48
==11437== definitely lost: 19,656 bytes in 1,002 blocks.
pmichaud ahhh, much better.
what leaks are left?
Coke biggest leaks remaining are in dyops. 15:49
"dynops"
pmichaud if there are any Parrot_free_context alls in the dynops, the ",0)" probably needs to be changed to a ",1)"
nopaste "coke" at 193.200.132.135 pasted "leaks in tcl's [puts hi]" (3618 lines) at nopaste.snit.ch/14699 15:50
Coke I am also disconcerted that the test program -fails- when run via valgrind, but one thing at a time. =-) 15:51
purl okay, Coke.
Coke ah, still some context failures in there.
15:51 hercynium joined
Coke OOOH. if you do a search in chrome, it highlights the match points in the scrollbar. 15:52
chrome++
Infinoid stuff on the context-reuse list usually show up as leaks. it would be really nice if we could somehow tell valgrind that Parrot_free_context() is a form of free(). 15:54
pmichaud actually, it doesn't show up as leaks.
the context-reuse list will get freed if --leak-test is added to Parrot's command line.
Infinoid oh, cool.
Coke vgp? 15:55
vgp is valgrind --suppressions=/home/coke/sandbox/parrot/tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test $@
(from chromatic's valgrind test)
Infinoid vgp? 15:56
purl ignored me too...
purl Infinoid: what?
Coke vgp?
purl thinks that's a karma line.
purl Coke: huh?
pmichaud purl, vgp is valgrind --suppressions=tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test $@ 15:57
purl--
purl pmichaud: i'm not following you...
Infinoid karma valgrind
purl valgrind has karma of 20
Coke vgp? 15:58
purl well, vgp is valgrind --suppressions=/home/coke/sandbox/parrot/tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test $@
Coke (you have to escape the -- as -\\-)
pmichaud maybe change suppressions so that it doesn't have the /home/coke... in it ?
just tools/dev/parrot.supp ought to be sufficient.
Infinoid Coke++ 15:59
Coke vgp?
purl hmmm... vgp is valgrind --suppressions=tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test $@
Coke purl, scooby snack.
purl Rank roo, Coke!
Coke (I just added some local modifications to the .supp file to ignore the uninitialized warnings) 16:02
should I open a ticket pointing to that nopaste for tcl's [puts hi] ? 16:03
16:03 alvar joined
pmichaud maybe for leaks in general. I suspect that context leaks will be resolves when we re-do contexts as PMCs anyway. 16:05
although it may be worthwhile to keep searching them out a bit.
16:06 Hadi joined, Hadi left
Coke Since partcl is definitely experience memory pressure, every bit helps, I suspect. 16:08
(opening trac ticket.)
pmichaud do we have trac-to-email yet?
Coke iunno 16:09
pmichaud not a reason not to post the ticket -- was just curious.
Coke slowly waits for the attachment to be posted... 16:13
16:14 skv__ joined 16:17 Theory joined
Coke gives up and just posts a link. 16:19
16:20 sjansen joined
Coke sees if patrick's recent fixes to trunk allow him to reclaim any more tcl files. 16:23
s/files/spec tests/
particle pmichaud: trac updates forwarded to a mailing list? yes, parrot-tickets@lists.parrot.org 16:29
16:31 Hadi1 joined 16:37 tomyan1 joined 16:38 tomyan2 joined, tomyan1 joined 16:39 rdice joined
Coke pmichaud: I seem to be hemmorraging memory at a slightly less prodigious rate. 16:39
dalek r33138 | pmichaud++ | lex5: 16:43
: Merge in latest versions of lexical code, for testing before trunk merge.
diff: www.parrotvm.org/svn/parrot/revision?rev=33138
jonathan afk for a while 16:44
pmichaud jonathan: subtypes is failing for me in the lex5 branch -- any ideas? 16:46
16:48 Hadi1 left
Andy The Parrot 1.0 is getting much traffic on reddit. www.reddit.com/submit?url=http%3A%2...March+2009 16:51
and chromatic++ for some of the least frantic anti-FUD I've seen in a while.
particle is there a way to view that without getting an account? 16:52
jhorwitz www.reddit.com/r/programming/commen...arch_2009/ 16:55
pmichaud does it require an account to read?
I remember reading it w/o logging in at one point.
particle jhorwitz++
pmichaud yes, jhorwitz++
jhorwitz above link is for the comments -- the article is direct from perlbuzz 16:56
Andy that's one set of comments.
the other set is www.reddit.com/r/perl/comments/7ej5...arch_2009/
jhorwitz andy++ :) 16:58
dalek r33139 | tewk++ | trunk: 17:00
: [SQLite3] remove dependency on C
diff: www.parrotvm.org/svn/parrot/revision?rev=33139
particle tewk: does this mean we can use sqlite from rakudo now? 17:05
tewk I just patched up the incomplete implementation. We need to add more functions, but it works from PIR 17:07
Basically I removed the need for c code.
particle seems the makefile needs changing
tewk Someone needs to add a bunch of functions, maybe I'll revive NCIGEN tonight and see if I can spit them all out. 17:08
Coke one of the top google hits for parrot 1.0 is a WOW site.
tewk I know I can parse, sqlite3.h so it will be a good exercise to make sure the generated pir bindings are right.
lathos was working on it, I had some changes that were sitting in my wc, so I checked them in. 17:09
Coke where is interp freed? 17:13
got it. 17:15
17:15 tomyan1 left
particle is it in Parrot_really_destroy? 17:15
Coke ayup. 17:17
but I soon realized my C is not up to this task atm.
particle what task?
purl task is a single atomic action for a client
Coke trac.parrot.org/parrot/ticket/5 17:19
kj Coke: you were looking for me?
Coke kj: regarding the t/pmc/bigint.t failure.
pmichaud manifest failing in trunk.
kj is it failing for you?
Coke it did earlier today. 17:20
kj (I don't have a bigint lib installed; can't check)
moritz reported success yesterday
Coke do you have an account on feather/
kj i don't think so
pmichaud r33139 breaks build.
Coke why do we have "if 0 ... endif" code checked in? seems evil.
"src/interpreter.c" line # 1175 17:21
pmichaud Coke: there's quite a few of those.
Coke should they all be ripped out?
pmichaud they're quick ways to enable/disable various bits of debugging code.
at this point I would not expect to be ripping them out. Perhaps as we near 1.0. 17:22
particle yes, that's a good cleanup item. we need a tracking ticket
kj Coke: is bigint.t passing now? 17:23
Coke nop
Revision: 33137
t/pmc/bigint (Wstat: 256 Tests: 44 Failed: 1) 17:24
particle pmichaud: fixed trunk in r33140
pmichaud particle++ # thanks
kj Coke: what's the error message?
purl it has been said that the error message is in op.c
Coke # error:imcc:'$N10' is not a valid register name in pasm mode
# in macro '.fp_eq' line 15
kj ah
i know
dalek r33140 | particle++ | trunk:
: fix tewk--'s manifest-o
diff: www.parrotvm.org/svn/parrot/revision?rev=33140
particle hrm... so you can't use pasm macros in pir anymore? 17:25
kj particle: basically... you can't use PASM registers anymore in macros if you expand them in PIR code
particle seems that error is pir-macro-in-pasm, which should fail
kj I added a fp_eq_pasm variant using PASM registers 17:26
particle is there a pir2pasm compiler that can be used instead of making copies?
Coke since a macro isn't pasm or PIR but just a snippet of text, I think barfing at compile time (after macro expansion) is still the right thing to do. 17:27
kj well a solution would be to use .local nums
ehm
Coke particle: (pir2pasm) that hasn't worked in aeons, has it?
particle yes, .macro_local
pmichaud src/pmc.c:477: warning: no previous prototype for ‘pmc_free’
kj no, that wouldn't work
pmichaud seems like a fixable warning.
Coke pmichaud: I tried pasting that in here earlier today and no one noticed. =-)
kj particle: well, .macro_local is still mapped to a .local in the end
Coke I'm guessing we need a ticket. =-)
kj particle: it's a bit unfortunate yes... long term I would think I can fix it. Short term, it's the choice what's more important: allowing PASM macros in PIR, or allow PASM regs in PIR mode. 17:30
dalek r33141 | kjs++ | trunk: 17:31
: [t] change expansion of .fp_eq into .fp_eq_pasm, as PASM registers in PIR mode are no longer allowed.
diff: www.parrotvm.org/svn/parrot/revision?rev=33141
kj Coke: r33141 should fix it for you (bigint.t)
Coke kj++ 17:32
kj kj-- # for breaking so much :-(
particle pmichaud: are tge failures expected in lex5 atm? 17:33
Coke kj: having just broken a ton of things before 0.8.2, i think you're fine. =-)
kj I thought that macros were not part of PASM anyway... apparently they are. 17:34
Coke will hold off reporting more leakages, he supposes, until the ones in trac 5 are fixed. 17:35
looks like quite a few leaks from imc_compile_unit 17:37
pmichaud particle: no, they are not expected.
Coke seen chromatic? 17:38
purl chromatic was last seen on #parrot 11 hours, 37 minutes and 44 seconds ago, saying: )
nopaste "particle" at 98.232.28.49 pasted "tge failures in lex5" (102 lines) at nopaste.snit.ch/14701
dalek r33142 | pmichaud++ | lex5: 17:41
: Properly handle freeing of outer_ctx, and don't mark dead contexts.
diff: www.parrotvm.org/svn/parrot/revision?rev=33142
pmichaud particle: the failures are happening in an 'onload' sub? That's... odd. 17:42
particle unquestionably.
pmichaud I wonder if it's the load_bytecode bug.
particle what bug is that? i lost track of parrot before the weekend, so i'm way behind (judging by the amount of irc traffic) 17:43
pmichaud load_bytecode depends on using a freed context. 17:44
I didn't port that fix from lex4 into lex5, but I can try that.
particle c:\\Users\\particle\\dev\\parrot\\lex>parrot -t 1 t\\compilers\\tge\\basic_1.pir
0 load_bytecode "TGE.pbc"
ayep.
pmichaud okay, just a sec. 17:45
17:46 chromatic joined
particle kj: do you know if the bytecode loader is sufficiently decoupled from imcc that we can build a parrot without imcc that can run bytecode? 17:47
kj I know that somewhere parrot calls into IMCC
particle wants a "parrot runtime environment"
kj it has to , because load_bytecode "foo.pir" needs to use IMCC to compile
pmichaud particle: is that useful yet for dynamic languages?
Coke not for tcl. 17:48
pmichaud i mean, eval() goes out the window without imcc.
Coke (I invoke imcc several thousand times.)
particle right, no eval.
does rakudo use eval today?
kj preferably it could be a function pointer, so that it's easy to switch to a different pir compiler
pmichaud it uses "use"
kj *...it could be /through/ a function pointer...
pmichaud yes, the thing being used could be precompiled into bytecode also. 17:49
particle merge_pbc
chromatic "(I invoke imcc several thousand times.)"
pmichaud but you can see the diminished returns of a parrot w/o a pir compiler.
particle yes, i understand that 17:50
17:50 alvar joined
particle but if we're to run in embedded systems, we need tradeoffs 17:50
pmichaud it would be great if imcc could become a dynamic library.
(or more precisely, imcc's replacement)
particle gimme a small parrot runtime, and a merged pbc file i can run on my treo/sony ereader/bug
pmichaud I'd like to put "dynamic load" as a prereq for pirc, actually. 17:51
dalek r33143 | kjs++ | trunk: 17:52
: [pirc] Allow PIRC to parse and expand macros in PASM mode. This is too easy... I need a challenge! Oh wait, I've got a few already. Nevermind.
diff: www.parrotvm.org/svn/parrot/revision?rev=33143
pmichaud particle: maybe r33144 fixes tge for you? 17:56
kj pmichaud: what's "dynamic load"?
pmichaud kj: load imcc or pirc only when they're first needed or requested 17:57
kj ah ok
pmichaud kj: as opposed to having them built-in as part of parrot.
kj basically it's a dll then
pmichaud yes.
dalek r33144 | pmichaud++ | lex5:
: Clean up context handling around load_bytecode.
diff: www.parrotvm.org/svn/parrot/revision?rev=33144
kj that shouldn't be too hard I think.
pmichaud thinks of a cool optimizatio for PGE matching against utf-8 strings. 18:02
*optimization
Coke pmichaud: only failures for me in lex5 is t/pmc/bigint.t (osx/86) 18:03
Revision: 33142
pmichaud Coke: noted, thanks.
I'm a little surprised bigint.t fails there -- I wouldn't think that what I'm doing affects that in anyway. 18:04
*any way.
kj isn't that fixed by 33144?
Coke pmichaud: it's probably the holdover failure that was only recently fixed on trunk.
pmichaud could be.
Coke (yup)
chromatic: you're back!
I have some lovely memory leaks for you!
18:06 Theory joined
Coke chromatic: trac.parrot.org/parrot/ticket/5 18:07
chromatic Hm, the dynop leak is big. I'll work on that one first. 18:09
Coke chromatic++ 18:10
dalek r33145 | kjs++ | trunk: 18:12
: [pirc] allow .macro_const in PASM mode; some cleanups
diff: www.parrotvm.org/svn/parrot/revision?rev=33145
r33146 | julianalbo++ | trunk: 18:20
: make pmc_free static and update headerizing of pmc.c
diff: www.parrotvm.org/svn/parrot/revision?rev=33146
moritz kj: there was some misunderstanding, I fear. I reported success with a fix that also broke other test files, which is why I didn't commit it
particle 0.1124*2000 18:21
purl 224.8
kj moritz: ooh. I see.
ehm, I updated bigint.t, to use fp_eq_pasm
instead of fp_eq
was that your fix as well?
NotFound CTX_LEAK_DEBUG_FULL and CTX_DEBUG_LEAK_FULL are different or is a typo?
pmichaud typo 18:22
moritz kj: I didn't get that far
pmichaud CTX_LEAK_DEBUG_FULL is correct.
NotFound Ok, fixing.
kj moritz: ok, that's fine. I did that already (just wondering whether *that* caused other tests to fail)
moritz: thanks for letting me know
dalek r33147 | julianalbo++ | trunk: 18:24
: fix CTX_DEBUG_LEAK_FULL/CTX_LEAK_DEBUG_FULL typo
diff: www.parrotvm.org/svn/parrot/revision?rev=33147
18:29 gaz joined
dalek r33148 | kjs++ | trunk: 18:33
: [pirc] give a better error message when using PASM registers in PIR code. I0 = 1, with I0 undeclared, will report a useful message.
diff: www.parrotvm.org/svn/parrot/revision?rev=33148
particle pmichaud: still get same failures with branch head. trying realclean now 18:34
18:35 skv__ joined
particle kj: are pasm register names outlawed in pir for named vars? they should be. 18:36
.local pmc I0 # eek!
18:36 skv___ joined
kj well, no, I didn't want to disallow them. Just implementing a warning if you're runnign with warnings on 18:37
I mean, if we're allowing .local int int
then why should .local int I0 be disallowed?
particle if if then then goto goto 18:38
kj yeah... I know :-) 18:39
that's 1 if too much btw
NotFound if if=then then goto goto
particle oh, wait, i had a typo there?!?!! how was i supposed to know? :P 18:40
kj ha ha
NotFound This way works on ZX-Spectrum Basic. 18:41
kj well, I think the decision was to have as few reserved words as possible
it took quite some effort to implement that! :-P
18:48 purl joined
Coke if I wish to 'smoke' perl 5.8.9RC1 - is there some way to report how 'make test' went? 18:49
chromatic I think there's a 'make ok' target. 18:51
dalek r33149 | pmichaud++ | lex5: 18:52
: Only mark the current continuation as live once, not once per context.
: Try mark_context without following the outer_ctx chain.
diff: www.parrotvm.org/svn/parrot/revision?rev=33149
Coke amazing how much faster this runs on my osx/86 box than perl4 did on xenix. =-)
NotFound Hasn't SCO claimed property of Perl? 18:53
18:54 skv___ joined
Coke not sfaik. 18:54
(my days of building perl on xenix are LONG ago)
jonathan returns 18:57
NotFound Don't tell SCO you did, just in case ;)
pmichaud jonathan: t/spec/S02-builtin_data_types/subtypes.t is failing for me in lex5... any clues? 18:58
(I haven't looked that closely yet...just curious if you could think of anything offhand)
jonathan It's only failing in lex5?
pmichaud yes.
jonathan And you just changed lexical and context related things?
pmichaud it appears to be working in trunk.
afaik, that's all I changed.
jonathan OK
pmichaud I'll get a full spectest failure list here in a few minutes. 18:59
jonathan Nothing off hand, but if I see how it's failing I might think of something.
It's only an anonymous subclass, if those are br0ke I'd expect to see much failure elsewhere. 19:00
pmichaud last time I checked I was getting some other class-related failures, too.
jonathan Ah, OK 19:01
The bunch are likely related.
pmichaud t/spec/S12-class/open.t
t/spec/S12-enums/basic.t
dalek r33150 | kjs++ | trunk: 19:02
: [pirc] give a warning when using PASM regs as PIR identifiers. only when running with -W warnings on option.
diff: www.parrotvm.org/svn/parrot/revision?rev=33150
jonathan Hmm...harder to see a pattern in those two...
Checking out the branch now
tewk jhorwitz: ping what mod_parrot signature would you most like to work without C stubs, the char** one, where is it in mod_parrot? 19:04
purl I can't find what in the DNS.
dalek r33151 | julianalbo++ | trunk:
: fix several pitfalls that fooled heeaderizer and update headerizing
diff: www.parrotvm.org/svn/parrot/revision?rev=33151
jhorwitz tewk: char ** is the only troublesome one. it's used as an out arg. 19:05
tewk OUT only right, not an IO/OUT
who free it? 19:06
jhorwitz i'm not using it cuz it was broken
oh wait, you mean the actual apache function....
tewk so do you need to free it later? 19:07
jhorwitz i *think* it's managed by an APR pool in apache, so apache will deal with it. i create a parrot string from it.
yep -- apache allocates the memory from a pool for it 19:08
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo spectest failures in lex5 branch (r33149)" (12 lines) at nopaste.snit.ch/14702 19:09
jhorwitz so we wouldn't need to free it
tewk I think we could probably change src/pmc/pointer.pmc to return a string and just use pointer with the V signature.
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo spectest failures in lex5 branch (r33149) #2 -- annotated" (12 lines) at nopaste.snit.ch/14703
jhorwitz tewk: V is an OUT char **? 19:10
tewk jhorwitz: so you create a Pointer pmc, pass it in to the function with the "V" signature and then call S0 = P0.
jhorwitz i see
tewk V is a void ** but you have to pass in a Pointer PMC. if we change the get_string call on Pointer it should just work. 19:11
jhorwitz ah
makes sense
so in theory that should also work for P1=P0 where P1 is a Perl6Str?
tewk Pointer is a PMC that kinda represents the & of operation in C calling semantics. 19:12
jhorwitz or maybe i need that S0=P0 in between....
ok, in any case, sounds like that should do the trick 19:13
tewk We use it for opaque pointer but it really should work for any OUT params.
s/pointer/pointers/
I'll continue looking into it and probably patch it tonight.
NotFound I think we need a sort of unmanaged pointer pmc with the ability to set a free function for his content. 19:14
tewk yep, I'll go look at all the uses of pointer and then either make unmanaged pointer or modify pointer itself. 19:15
jhorwitz when you're done it's trivial to try it out in mod_parrot
NotFound Well, maybe "unmanaged" is not an adequete name in that case. 19:16
tewk see CPointer.pmc 19:17
jonathan pmichaud: That test dies...early.
pmichaud which one?
tewk CPointer isn't quite right either, but I'll write one that works 19:18
jonathan subtypes.t
looking at why now
It actually fails inside parrot;P6protoobject;ACCEPTS 19:20
pmichaud ...maybe it's eval related?
most of these failures seem related to eval.
jonathan pmichaud: Here's probably a good clue. 19:21
> multi sub my_abs (Num where { $^n >= 0 } $n){ $n }
'' isn't the :outer of '_block47'
GeJ Good morning everyone
jonathan pmichaud: In fact, I can reduce it 19:22
sub ($n where { 1 }) { 1 }
pmichaud: That isn't even using the new subtype stuff in fact...I didn't convert anonymous ones to do so yet, becuase there's a parameter refactoring due anyway.
pmichaud: So it just generates a block (Parrot .sub) for the { 1 } and then invokes it as part of the type check. 19:23
particle kj: pasm is human-readable bytecode
pmichaud jonathan: okay, I'll check there.
jonathan pmichaud: Looks to be something to do with outers...
particle: bytecode is readable to with a hex editor ;-)
jonathan speaks from painful experience
particle you signed up for that pain! :P 19:24
jonathan Masochism's a good thing, right?
particle imcc shouldn't do register allocation for pasm, unless it also does it for bytecode 19:25
yes, and i enjoy your masochistic tendencies
kj particle: well, ISTR that if you do print P1 in imcc, it'll emit print P0
dalek r33152 | kjs++ | trunk:
: [pirc] now for all identifiers that resemble PASM names, give a message saying they're not allowed in PIR mode. This also resulted in a nice refactoring.
diff: www.parrotvm.org/svn/parrot/revision?rev=33152
kj but just want to get this clear now, so I can DTRT 19:26
particle kj: yes, understood
purl Roger Roger.
NotFound I have a suggestion: make --maintainer option always run codetest
pmichaud jonathan: where does that block get attached...? 19:28
kj particle: but I was wrong. IMCC DTRT as well.
particle i thought imcc did not do any register allocation. are you saying that is correct? 19:29
19:29 rob joined
jonathan pmichaud: signature 19:30
(as in the action method)
kj I just assembled + disassemlbed 'print P10', and it stays P10, so no allocation in PASM mode. And that's right I think
jonathan Oh, hmm
We generate the block once, but push it in two places (the same block), but we get two blocks generated from the one PAST node.
particle pmichaud: realclean and maybe your patch fixed tge in lex5 for me
pmichaud particle: excellent, thanks!
particle now just failing eval.t
pmichaud jonathan: pushing block in two places is a bad thing.
particle: eval.t in parrot 'make test', or ...? 19:31
jonathan It appears that now it indeed is.
particle likely due to temp files overwriting each other
t/pmc/eval.t 1 256 17 1 10
kj temp files: I think there was an email on that on the list recently
jonathan pmichaud: Thus the plan was to stick it once in the signature object and pull it from there.
particle it fails in trunk, too
chromatic I fixed t/pmc/io.t, t/pmc/eval.t, and t/io/filehandle.t with regard to temp files. 19:32
pmichaud jonathan: well, the real question is... what's the scope of the where block?
particle chromatic: i get a permission denied in test 10, checking source now...
jonathan It can see things that were bound so far in the signature
pmichaud so, it's gotta appear in the sub block itself.
jonathan But if the where block has an outer of the signature generator sub, and that in turn has an outer that is the sub itself, it would all Just Work. 19:33
chromatic particle, Windows has a weird idea about not unlinking files you have open.
pmichaud ....yes, but eventually I'm hoping that the signature generator sub becomes not a part of the inner scope.
jonathan Of course, we can be much neater about this when .const 'Sub' $P0 = 'foo' works for subid
particle yep, figured it was something like that, c
jonathan Yes, we can do that. We'll make the where block then have an outer of the correct sub. 19:34
And then look it up from its subid in the one generator sub.
pmichaud okay, I get the picture now.
jonathan But we can't have that yet.
pmichaud what changed is that lex5 is stricter about making sure that we close from the outer block.
jonathan Aha.
OK, so options are... 19:35
pmichaud the mainline _claimed_ to be checking for such things, but the check was broken such that it allowed closing from, well, anywhere.
19:35 Hadi joined, Hadi left
pmichaud I'm going to have capture_lex and newclosure silently fail if we attempt to close form the wrong place for now. 19:35
since that's what trunk was doing.
jonathan a) Refactor it now to let the signature only hold the block and pull it out of there, b) stop putting the block as a check inside the sub, or c) stop putting it in the signature 19:36
b breaks single dispatch type checks, c breaks multi...
pmichaud it'll then autoclose upon execution, which is what was happening before.
jonathan Or that to work around it.
pmichaud we can clean it all up when subid works.
jonathan Sure. Probably worth holding off on the whole cleanup until we have that.
pmichaud agreed.
let's see if this works. Thanks for finding that -- it would've taken me... well, forever. 19:37
jonathan I've got some other stuff to clear up to make sure we don't run type checks twice in multis, but we'll tackle that i the refactor too.
Welcome. :-) 19:38
Thanks for fixing lexicals. :-)
particle wonders why nobody tried to fix the lexical handling before...
pmichaud nobody wanted to deal with it, I think. 19:39
particle but you make it look so *easy*
:P
pmichaud huh. After working on it basically non-stop for how many days now...?
particle 14?
purl hmmm... 14 is ALRM
particle damned straight, purl 19:40
purl particle: huh?
jonathan pmichaud: Yeah, I know the feeling...I tried to escape the bytecode PDD implementation too. ;-)
jonathan will make the branch for annotations stuff soon
pmichaud: Any preference on when I Rakudo day this week?
I'm going to be generally around anyway, doing multi dispatch stuff and starting on bytecode annotations stuff. 19:41
pmichaud Thanksgiving is Thu+Fri of this week -- we'll have company here. I'll undoubtedly be hacking some those days, but with frequent distractions.
Thu is probably not good, actually.
so either Tue, Wed, or Fri.
I sincerely doubt we'll go out and do any shopping on Black Friday (which might not be so black this year :-) 19:42
chromatic You all complain about having to escape things. Anyone want IMCC and GC?
jonathan chromatic: Well, we all know you so love them... 19:43
In a loving hate kinda way. ;-)
pmichaud: OK, Wednesday it is. 19:44
Black Friday?
purl it has been said that Black Friday is acmoore's favorite, though.
jonathan looks it up and understands 19:45
It basically sounds like the worst day to shop in the year. 19:46
Coke typically very deep discounts on some items.
pmichaud now subtypes.t give me a segfua[A[B[B[A segfault.
trying something different 19:47
jonathan Maybe your error check was correct. ;-)
pmichaud I'll go ahead and let it capture the outer we call from, instead of the sub's immediate outer.
(which is what the previous version did)
jonathan Seriously, break the single-dispatch if you want. 19:48
I hope the refactor won't be so far away.
pmichaud I'll try it this way for a bit -- sounds simpler.
jonathan ok
pmichaud we _will_ have the issue though that the closure that gets stored in the signature can't be determined at compile time. 19:49
or that something will have to happen to get it to the right place. perhaps we need to mark it as an immediate block instead of a declaration.
actually, immediate block sounds more correct. 19:50
we have to do the capture_lex at the point when the sub is entered, and the signature has to use *that* version of the captured sub. We can't clone it beforehand (which is what newclosure does.) 19:51
because the clone that would be taken at startup time would capture the lexicals in place at compile time, as opposed to the ones from the sub invocation.
jonathan Ah, yes.
Ouch indeed.
dalek r33153 | kjs++ | trunk: 19:52
: [pirc] Don't do any PASM allocation in PASM mode, but do allow optimization. If you ask for it, you can get it.
diff: www.parrotvm.org/svn/parrot/revision?rev=33153
pmichaud okay, neither of my two workarounds worked.
we have to fix it so that it doesn't appear twice in the tree. 19:53
jonathan OK 19:55
Comment out the one that doesn't put it in the signature object for now. It'll give some fail though.
But at least the one in the signature object is the one we want. 19:56
I'll do a partial refactor on Wed or maybe tomorrow to fix those up.
pmichaud ...thinking.
I don't know where that is, exactly. 19:57
dalek r33154 | kjs++ | trunk: 19:59
: [NEWS] Add PIRC news. + add :lexid->:subid to deprecated section (just as PARROT_{API->EXPORT}).
diff: www.parrotvm.org/svn/parrot/revision?rev=33154
Coke offers chromatic a scooby snack. 20:00
chromatic I'd rather have an assistant. 20:01
jonathan pmichaud: Line 1191 - if you comment that out it'll surpress it
(And all other parameter type checks on single dispatch...)
pmichaud ...that will break a lot of tests. 20:02
(the ones that do typechecking)
jonathan Those that rely on type checks failing yes.
pmichaud you're saying we should regress those for now?
jonathan How soon do you expect to merge the branch?
pmichaud I was hoping today.
this is the last blocker.
jonathan Regress them today, I'll fix them in the next couple. 20:03
OK, put antoher way
pmichaud is there a way to just regress the where clauses but leave the type checks?
jonathan *if* commenting out *just* that line fixes it
Trouble is, I did this whole re-use thing...fail! ;-)
Oh, maybe there's an easy way 20:04
jonathan looks again
pmichaud maybe moving the block to an 'immediate' one will help -- I'll try that. 20:05
jonathan pmichaud: I can put some code in to avoid emitting them for now, but it's not just commenting out a line. 20:06
pmichaud I'll go with your best judgement on this one... whatever it is. 20:07
dalek r33155 | julianalbo++ | trunk:
: add prototype for imcc set_filename and fix coding standards
diff: www.parrotvm.org/svn/parrot/revision?rev=33155
jonathan pmichaud: That code is up for a refactor anyway, and I had it on the list to review as part of the multi stuff because I need to not emit the checks when we have a multi. 20:08
So I was going to be in there shortly to do that.
(Don't need the checks as the multi dispatcher has already done 'em)
pmichaud so, you think just remove parameter type checks for now?
let's see if that does it.
jonathan How much did commenting out that one line break?
pmichaud didn't try that one yet.. just a sec 20:09
jonathan OK, I can try it here
Or do you have other local changes/
pmichaud no other local changes that should make a difference
(the only other local change I have is the capture_lex workaround, but this should work without it)
dalek r33156 | kjs++ | trunk: 20:10
: [pirc] add a comment to clarify PASM register allocation (or rather, non-allocation).
diff: www.parrotvm.org/svn/parrot/revision?rev=33156
pmichaud ultimately this is going to be fairly interesting, because we can't invoke the where closures until *after* the sub has set up its lexical invocation environment.
i.e., we can't do the checks until we've invoked the sub. 20:11
jonathan pmichaud: You know, you've just made me realize something horrible in the multi-dispathcer too. 20:12
Yes. Shit.
jonathan ponders
pmichaud either that, or we create a "fake sub" that simply does the checks for us.
jonathan Or we just create a fake lex-env. ;-)
Ouch though. That's not nice at all.
I've got away with it so far since the conditions only referred to the things they were passed 20:13
And not things in an outer scope, which of course doesn't exist...
pmichaud ...doesn't exist?
wouldn't the outer scope be the sub itself, as well as its outer scope?
jonathan Because we're still in the scope of the caller, not the scope of a potential callee.
pmichaud the parameters are definitely in the scope of the callee 20:14
jonathan Yes, I know
But in the multi-dispatcher we haven't invoked a callee yet.
pmichaud ...maybe a wrapper?
jonathan So we haven't bound the signature.
Maybe, but it'll be a different wrapper per sub.
Hmm. 20:15
pmichaud right.
jonathan thinks I need to think a good bit on this one
pmichaud and we only need the wrapper on subs that involve where closures.
jonathan True.
pmichaud actually
jonathan I'm not sure I like it as a solution though.
pmichaud we only need the wrapper on subs that involve where closures that use variables from an outer scope.
jonathan Right. And statically in many cases we'll be able to prove that it ain't so. 20:16
pmichaud correct.
jonathan Of course, as soon as it does an eval inside there we've no hope.
pmichaud heh.
jonathan But in cases where people are being sane, yes...
Ouch. Can't believe I didn't think of that. 20:17
Anyway, it's solvable in some way. 20:18
Wrapper sub or otherwise. 20:19
Hmmm. Commetning out that line makes no difference to the subtypes test. 20:24
pmichaud no difference as in "still segfaults" or "still fails tests"? 20:25
I would expect it to fail tests.
jonathan Still fails that subtypes test the same way 20:26
20:27 PacoLinux joined
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo spectest failures in lex5 branch #3" (12 lines) at nopaste.snit.ch/14704 20:28
pmichaud the enums test stopped failing
jonathan Ouch. 20:29
pmichaud but yes, we still have some failures here.
jonathan Commenting out that line shouldn't have made a difference to the enums tests - or was that another fix you did?
pmichaud that may be my other fix causing that.
jonathan I suspect so.
pmichaud i.e., relaxing the restriction on outer.
jonathan These test results were with the line I mentioned commented out or with it still in?
pmichaud commented out. 20:30
20:30 ruoso joined
jonathan OK 20:30
Hmm
pmichaud so I think there must be something else going on here also.
it must be an issue with eval. 20:31
no, perhaps not. 20:32
hmmm.
oh, it looks like whatever _follows_ an eval has trouble. 20:34
...maybe 20:35
20:35 masak joined
nopaste "jonathan" at 85.216.157.73 pasted "MyFAIL - with the line commented out, without your other patch" (13 lines) at nopaste.snit.ch/14706 20:36
20:36 davidfetter joined
pmichaud looks to me like a context is being reclaimed too soon. 20:39
nopaste "pmichaud" at 72.181.176.220 pasted "eval causes segfault" (53 lines) at nopaste.snit.ch/14707 20:45
pmichaud moving the block containing the eval causes the segfault to move.
so, perhaps it's a problem with the 'lexpad' introspection. 20:47
...or the exception handler. 20:50
I bet the handler reclaims the context. 20:51
20:59 Hadi joined 21:00 Hadi left
jonathan pmichaud: It segv's here too. 21:04
pmichaud yes, I think we have an early context reclaim somewhere. 21:05
I'm tracing it through gdb now.
jonathan OK. Well, just to confirm it's not your locally applied patch.
pmichaud I suspect something is a RetContinuation that needs to be a Continuation.
Coke all of them! =-) 21:11
pmichaud hmmm, when running from pir it occurs much earlier. 21:14
jonathan Coke: The way to test that theory, is to delete all of the methods in the RetContinuation PMC ;-) 21:15
21:18 chromatic joined
dalek r33157 | allison++ | pdd22io_part2: 21:19
: [pdd22io] Add a 'puts' method to FileHandle for backward compatibility.
diff: www.parrotvm.org/svn/parrot/revision?rev=33157
21:20 gmansi joined
Coke wonders if he scared chromatic away! 21:21
pmichaud yes, it's almost certainly that a context/lexpad is being reclaimed early. Running with -G causes it to work fine.
chromatic No, my network is misbehaving. 21:22
21:24 cxreg joined
cxreg hey, does S19 actually exist yet, and if so, where can I read it? 21:24
pmichaud it's being drafted (no, it doesn't exist in a file yet) 21:25
cxreg ok thanks
particle is coming by in an hour or so and I'd hoped to peruse his throughts 21:26
thoughts too
PerlJam throughts sounds vagues vulgar
s/vagues/vaguely/
particle cxreg: it only exists on a private google doc atm 21:28
*in a
PerlJam What is S19 supposed to be? Is that the command line stuff?
cxreg particle: ok thanks. wasn't sure if you were online now or not. josh was looking for it somewheres 21:29
PerlJam: yep
Coke S19? 21:30
S19 is the command line stuff
21:36 jsut|work joined
Coke 588+41 21:37
purl 629
Coke msg allison: do you have a meta ticket for IO stuff? (There's a bunch of old IO tickets.) 21:46
purl Message for allison stored.
allison Coke, nope, no meta ticket atm
more of a meta wiki page 21:47
oh, but still in the old wiki
Coke which old wiki? we have 3 altogether now, right? =-)
(trac, parrot.org, and perl.org)
allison I'll migrate that over, then people can add the tickets to that
parrot.org
purl i heard parrot.org was drupal?
allison which is rapidly being removed 21:48
or, the wiki part moved to trac
Coke it is? ok.
Coke has trouble keeping up with such goings on.
allison well, we have been moving quickly :) 21:49
drupal just didn't work as a wiki
and, seems better to move off it quickly than to keep struggling with it
PerlJam good deal (drupal sucks in a variety of ways)
allison it's great for the website, though
the "wiki" section of drupal has now been renamed to "User Contributed docs" 21:50
PerlJam notices that no one has taken the baton for "marketing mojo"
allison so, we still have a part of the website that's editable by anyone
PerlJam: that'll be me
it's not actually marketing, it's explaining the vision for 1.0 21:51
chromatic allison, don't dissuade volunteers with goatees!
allison (well, that is marketing in a way)
Coke 's ears ring. 21:53
PerlJam Answer the phone! ;)
allison chromatic: all goateed volunteers gladly welcomed :)
Coke pmichaud: as long as you're looking at contexts, can you peek at RT # 45695 ? 21:55
allison; still a bunch of mmd tickets.
pmichaud coke: reject it. from_ctx is needed. 21:56
Coke allison: when searching for io tickets, include 'parrotio'.
pmichaud at present, it's the only way for a continuation to know its current context.
(i.e., the context in which it was made.) 21:57
allison Coke: agreed with pmichaud, reject RT #45695
pmichaud it's also sometimes the only thing that keeps a context alive (e.g., as in a continuation). 21:58
allison Coke: the I/O tasklist wiki page is trac.parrot.org/parrot/wiki/IOTasklist, ticket links can be added there (maybe just a link for a search that catches all the I/O related tickets? 21:59
Coke wonders why RT #45965 never got applied.
pmichaud ...because there were questions about how contexts would be collected if it was applied.
and those questions were valid (and correct)
the original poster assumed that contexts were part of the normal mark-and-sweep GC, which they are not. 22:00
allison pmichaud: different ticket (two digits reversed)
pmichaud oh.
heh :-)
allison Coke: I think it mostly has been applied at this point
Coke: if not, then it should be
Coke it applied cleanly still, retesting. 22:01
allison Coke: I think it falls into the "somebody else's problem" category
Coke will apply if so.
moritz pmichaud: how's the lex branch coming along?
pmichaud everything works except for a few minor issues in spectests. 22:02
well, seemingly minor. But coke's pointing me to #45695 might explain the problems I'm seeing.
so, I'm trying a solution based on that.
Coke be sure to give the guy credit if his patch inspired something. =-) 22:04
pmichaud ...doesn't seem to have helped in this case.
Coke ah well
as part of the RT cleanup, I'm going to go through and close tickets reporting bugs on non-core platforms that are more than a big revision back. 22:05
pmichaud +1 22:06
purl 1
22:06 clunker3 joined
Coke folks can re-open them on the new system. (We really need someone with access to help port.) 22:06
allison Coke: sensible
purl i guess sensible is usually inappropriate, yes :)
Coke (and when they re-open the ticket, we can grab them then. =-)
(i'm looking at you, jarrko!) 22:07
er, jarkko?
Coke wonders why "vtablecache" is a pmc.
jonathan never quite figured out what that PMC was 22:08
chromatic Nothing uses it, as far as I know.
allison delete it, delete it! 22:09
allison has lately gotten into a mode of deleting unused code 22:10
pmichaud I have a lot of deletions to make also :-)
Coke if someone opens a ticket, I can rip it out. (otherwise I will forget)
dalek r33158 | coke++ | trunk: 22:11
: vtable slot names shouldn't have leading double underscore (RT #45965)
diff: www.parrotvm.org/svn/parrot/revision?rev=33158
Coke 41+586
purl 627
nopaste "pmichaud" at 72.181.176.220 pasted "my list of tickets that are likely "ripe" for closing" (16 lines) at nopaste.snit.ch/14708
22:12 Whiteknight joined
allison Coke: will open a trac ticket 22:12
jonathan [TODO] Produce Single PBC from Multiple PIR Files with -o 22:14
You can nearly do that with pbc_merge ;-)
pmichaud yes, I figure we should go ahead and reject that todo.
jonathan Aye.
pmichaud the other way to do it is with .include "file1.pbc", "file2.pbc", etc., as PGE and Rakudo frequently do. 22:15
s/pbc/pir/g
jonathan Yes.
chromatic #39856?
Coke pmichaud: which reminds me:
I think it was perl6 that didn't do .includes, but instead cut and pasted the contents of N files into a .PIR file, making it very difficult to find the original source.
pmichaud Coke: yes. 22:16
Coke (I think that's been copied around a few languages/, actually.)
Any reason not to just have it be .include'd ?
pmichaud the number of files is quite long.
and I didn't want to be generating perl6.pir itself.
Coke <shrug> it's a generated file.
pmichaud oh, you mean have the generated file be a list of includes?
Coke yes.
pmichaud sure, that would work.
didn't think of that.
Coke then when you have a syntax error you can actually find the original source. =-) 22:17
pmichaud perfect. I'll make it so.
Coke danke.
pmichaud ...now I think I'm ending up with circular chains in the mark_context algorithm. :-(
Coke -> 22:20
22:20 donaldh joined
jonathan pmichaud: I managed to introduce such a thing once. :-( 22:20
pmichaud I think one of the paths might not be necessary, so trying that now. 22:21
jonathan pmichaud: IIRC, it was something to do with when the outer and caller were the same.
22:21 tak joined
pmichaud jonathan: I was explicitly testing for that case :-) 22:21
jonathan OK
pmichaud but I think it's not necessary to follow the caller chain.
jonathan I seem to remember having to explicityly check that one too.
pmichaud because the continuations keep those alive.
jonathan ah, yes 22:22
pmichaud (at least they should. Or if they don't, then they can be made to do so)
so far everything seems to work without marking caller. It also seems faster.
That actually makes sense to me -- because if we're marking caller_ctx, then mark becomes an O(n^2) operation.
PerlJam faster++ 22:23
pmichaud (if a context marks all of its callers, and continations mark all of their contexts, then the contexts near the top get marked one for each (child) continuation)
(plus they in turn go back and mark all of their dependencies... etc. etc.) 22:24
jonathan Ouch!!
pmichaud all parrot tests succeed after turning off caller marking. 22:25
....AND subtypes.t passes! woo hoo!
jonathan Oh, awesome!
pmichaud++
pmichaud working +1. faster +1. working + faster == ?? 22:26
jonathan pmichaud: With the thingy commented out or not?
pmichaud not commented out.
jonathan Rock on.
purl The rock is now on.
jonathan moshes
pmichaud I'm using the version of actions.pm that is in trunk (with one or two minor lexical-related changes)
doh! test failure in nqp, though. :-|
at least nqp is a lot easier to troubleshoot than perl6 :-) 22:27
jonathan Rakudo passes and NQP fails? That's...impressively odd.
pmichaud rakudo has a lot more :outer contexts that would tend to keep things alive.
NQP doesn't.
PerlJam If it's part of nqp that rakudo doesn't use, then we don't need it ;)
pmichaud t/02-if-else.t
I think we need it. 22:28
still, I'm comfortable I can get it from here.
NQP is very easy to troubleshoot -- it produces nice concise PIR.
tewk tests++
jonathan I'm going to start doing some stuff on bytecode annotations, etc.
First step will be getting some stuff stuck into PDDs, like the PIR PDD. 22:29
Should I do that in a branch, so we merge the PDD updates with the code changes?
Or?
jonathan doesn't mind either way
pmichaud docs can go in trunk, I think.
maybe stick something in draft/ 22:30
allison jonathan: shouldn't bytecode annotations go in the bytecode PDD?
and, yes, doc changes are best in trunk
jonathan allison: There is the .annotate syntax, which I think belongs in the PIR PDD.
pmichaud I don't think doc updates need bran.... what allison said :-)
jonathan pmichaud: Well, I'd have done code updates in the branch too. ;-)
pmichaud branches are primarily for things that break tests and code.
jonathan OK
allison jonathan: ah, yes, the parts used from PIR should go in the PIR PDD
jonathan allison: Aye. We should also decide on an interface for the Exception PMC so you can get a hash of the active annotations at the point the error occured too. 22:31
pmichaud arrrrrrrrrrgh
once again, -t1 hides the bug I'm trying to locate.
allison jonathan: that's the 'payload', any additional data for the exception goes in there 22:32
jonathan: and each exception type is free to use the 'payload' in it's own unique way
jonathan allison: I think this kinda cross-cuts all exception types though.
pmichaud I agree. 22:33
jonathan I don't see how the type of exception matters, in getting where it was thrown from.
pmichaud we're basically looking for "where did the exception occur?"
jonathan votes for a method on the exception PMC
allison are you talking about bytecode errors? no, I guess not
jonathan Then we only lookup/get this data if it's needed.
allison: No, I'm talking about getting the current set of annotations, like HLL line number and file, at the point an exception occurs. 22:34
allison are you thinking of annotations on the particular line of PIR where the exception was thrown?
(particular line of bytecode)
jonathan The annotations that were in effect at the point where the exception was thrown.
The point in the bytecode, yes.
You'd get a Hash back of the annotations set at that point. 22:35
allison ok, make it an "annotations" method
jonathan OK, great. 22:36
allison it takes an optional string parameter to look up a specific annotation
(like, "hll_line", etc)
jonathan Fajn.
This should be mentioned in the Exceptions PDD too, right?
allison yes, add it to the interface description for the Exception PMC 22:37
jonathan OK.
jonathan updates stuff
pmichaud only one rakudo spectest fails: t/spec/S04-statements/for_with_on 0 11 ?? ?? % ??
jonathan That looks like a segfaulty kinda fail.
pmichaud yes.
all of the subset/subtypes tests passed this time. 22:38
jonathan w00t
That means I don't have to go fix the sig stuff to quickly.
*so
pmichaud and for_with_only_one_item passes when run from the command line.
so that looks like a harness error.
so I just need to figure out the nqp failure and I think we're good. 22:39
actually, I need to commit what I have so far.
jonathan Heh. In the Exceptions PDD, the section under "=head2 Resuming after Exceptions" shows how to throw an exception - but not how to resume it! 22:40
(In the code sample) 22:41
allison jonathan: sounds like a good fix to make
dalek r33159 | pmichaud++ | lex5:
: Report the subname of whatever we're referencing for easier tracing.
diff: www.parrotvm.org/svn/parrot/revision?rev=33159
22:42 Limbic_Region joined
jonathan allison: I don't personally know what the fix is... 22:43
pmichaud jonathan: grab the 'resume' element out of the exception, invoke it. 22:44
dalek r33160 | pmichaud++ | lex5:
: (1) Don't carp about capture_lex from non-outer scope.
: (2) Don't mark caller - we'll let the continuations do that.
diff: www.parrotvm.org/svn/parrot/revision?rev=33160
r33161 | pmichaud++ | lex5:
: Continuations now mark their from context.
diff: www.parrotvm.org/svn/parrot/revision?rev=33161
22:44 tak joined
Tene I thought I fixed that one... 22:46
22:50 particle1 joined, particle1 left
dalek r33162 | jonathan++ | trunk: 22:50
: [pdd] Add details of how to get bytecode annotations from Exception PMC.
diff: www.parrotvm.org/svn/parrot/revision?rev=33162
Tene jonathan: Ah, I must have reverted it when cleaning up after a mistake and not re-written it. 22:51
dalek r33163 | jonathan++ | trunk:
: [pdd] Correction to previous commit; name is just an optional parameter to annotations, for consistency with e.g. inspect method.
diff: www.parrotvm.org/svn/parrot/revision?rev=33163
jonathan Tene: Can I leave it with you to pop it back in? 22:53
Tene Doing tha tnow.
jonathan Since you probably have better text than I'd write. 22:54
Tene Thanks.
In exception['resume'], what is that called? It's stored in the resume... attribute? element? what? 22:56
stored under the 'resume' key?
Infinoid field?
purl field is what the ivory tower is right in the middle of.
Tene field is okay.
EH filters aren't discussed in the pdd either, are they? 22:57
Infinoid especially when they have ivory towers.
Tene Nope. That's a problem.
dalek r33164 | tene++ | trunk: 23:00
: Add missing documentation about resuming from exceptions.
: jonathan++ for reporting this.
diff: www.parrotvm.org/svn/parrot/revision?rev=33164
23:14 jan joined
allison Tene: called the 'resume' attribute, the key access to attributes is just a convenience 23:16
dalek r33165 | tene++ | trunk: 23:18
: Fix wording. allison++
diff: www.parrotvm.org/svn/parrot/revision?rev=33165
pmichaud ... I have a question. 23:19
this looks bizarre to me.
(nopaste coming up) 23:20
nopaste "pmichaud" at 72.181.176.220 pasted "...how does this work? (src/pmc/sub.pmc)" (14 lines) at nopaste.snit.ch/14709 23:21
pmichaud oh, never mind, I see it.
the get_params opcode also handles tailcalls. 23:22
allison pmichaud: yes. there should be a better interface for that, but it works for now 23:23
pmichaud indeed, it does.
dalek r33166 | jonathan++ | trunk: 23:24
: [pdd] Document .annotate and .file and update .line directives in the PIR PDD.
diff: www.parrotvm.org/svn/parrot/revision?rev=33166
23:25 gmansi joined
pmichaud okay, with the current lex5 branch (r33166), all tests are passing in parrot, abc, punie, pheme, APL, pge, tge, and rakudo (including spectests) 23:26
I have one failure in lolcode, which I can tell is due to a lolcode bug and not the lexicals changes. 23:27
jonathan pmichaud++
pmichaud I have one failure in nqp, which runs fine when the -G flag is present.
two questions:
jonathan pmichaud: Want a Win32 test?
pmichaud (1) can others test on their systems?
jonathan yes ;-)
pmichaud (2) what else needs to be fixed before I can merge to trunk?
tewk -G would tend to show GC errors not hide them. 23:28
pmichaud -G hides them.
-G turns off GC.
jonathan Aye.
tewk never mind I was thinging of the gc run core.
jonathan :-)
pmichaud oh, I could try gcdebug, yes.
jonathan That may help work out why we're getting the error.
pmichaud The problem in nqp is something to do with argument processing. 23:29
tewk yeah, run it with the gc run core
afk ~15min
pmichaud (also, all of the lexicals-related tickets in rakudo's RT queue work properly.) 23:30
I get a totally different error with --runcore=gcdebug than I do without. Weird. 23:32
nopaste "Infinoid" at 96.238.213.50 pasted "pmichaud: fix a couple of warnings in src/gc/register.c" (22 lines) at nopaste.snit.ch/14710
Infinoid I also get some warnings from src/pmc.c:pmc_free(), due to the lack of a prototype in pmc.h. headerizer can't deal with it because that function has no POD 23:33
but these are things that can be easily cleaned up post-merge, I think 23:35
pmichaud that warning is in trunk, also. 23:36
Infinoid ooh, # error:imcc:'$N10' is not a valid register name in pasm mode. that's probably not lex5-specific
pmichaud correct, it's not.
dalek r33167 | pmichaud++ | lex5: 23:37
: Some code cleanups from Infinoid++ .
diff: www.parrotvm.org/svn/parrot/revision?rev=33167
Infinoid infinoid@chirp perl6 % ../../parrot perl6.pbc t/00-parrot/07-op-string.t 23:39
zsh: segmentation fault ../../parrot perl6.pbc t/00-parrot/07-op-string.t
allison pmichaud: excellent news on the lex branch! platform/language testing should be all that's needed before a merge
Infinoid the rest of rakudo "make test" passed
jonathan Infinoid: How does that one do under -G for you? 23:40
pmichaud: make test for Parrot clean on Win32
nopaste "Infinoid" at 96.238.213.50 pasted "rakudo segfault backtrace (vtable = 0xdeadbeef)" (255 lines) at nopaste.snit.ch/14711 23:42
Infinoid let me check, I'm pretty sure it'll look good
I'm guessing this pmc got GC'd out from under it.
passes fine with -G.
Infinoid tries spectest_regression 23:43
pmichaud (backtrace) that's the same function that gives me the (same) error in nqp. 23:44
nopaste "pmichaud" at 72.181.176.220 pasted "backtrace from minimized nqp 02-if-else.t test" (96 lines) at nopaste.snit.ch/14712 23:46
Infinoid p_arg->vtable == 0xdeadbeef makes it seem very likely to be a GC issue 23:47
pmichaud yes, I agree.
that's what I was noticing as well.
Infinoid should I expect to see a bunch of "Use of uninitialized value" outputs during spectest_regression?
jonathan Yes
Infinoid great, no worries then.
that part's working :)
pmichaud I think I'm going to turn those off for a while, or make them flag selectable. 23:48
probably re-enable them after we have list assignment and basic slicing working.
Infinoid lots of failures in lua which also exist in trunk 23:49
pmichaud lua is guaranteed to fail -- it relies on the Closure PMC (which is gone in the lex5 branch) 23:50
I'm not sure I can fix that one.
jonathan was about to point out a fail, when he realized that he still had a line commented out in actions.pm...
allison pmichaud: will lua work if we change it to subclass Sub instead? (since Subs now have all the behavior of Closures) 23:52
chromatic I would think so.
pmichaud well, it's also overriding some behaviors, so we'd have to tease out what it's overriding from what it replaces.
I haven't looked closely at it. 23:53
23:54 particle1 joined
allison pmichaud: was the removal of Closure listed in the deprecations for the last release? If not, we can just keep it for now, and remove it after the next release 23:54
nopaste "Infinoid" at 96.238.213.50 pasted "a few spectest_regression failures on linux/x86-64" (28 lines) at nopaste.snit.ch/14713 23:55
pmichaud it was listed in the deprecations, yes. 23:56
I made sure to get it in there for precisely this reason. :-)
Infinoid: none of those spectest failures are expected, so we probably need to look at those. 23:57
I'm guessing a caller context is being lost somewhere in GC.
having to do with parameter passing to subs. 23:58
allison pmichaud: alright, then that counts as fair warning
Infinoid can I do PARROT_TEST_ARGS=-G or somesuch?
jonathan pmichaud: I get a new fail in t\\spec\\S06-multi\\type-based.rakudo
chromatic Infinoid, should work.
allison chromatic: if you have a moment, it's worth looking into fixing Lua up quickly by changing it over to Sub
chromatic I'll look into it, but it won't be for a few hours.
pmichaud I may be able to take a look also a bit later. 23:59
jonathan pmichaud: Oh, but it runs fine from the command line.
pmichaud: So test harness issue.
pmichaud jonathan: right. +1 there.
allison chromatic:/pmichaud it's mainly just to minimize frustration for language developers, keep them moving smoothly
pmichaud although I'd like to see Lua running in trunk before trying to get it to run in the branch.

Powered by Cro and the Raku® Programming Language.

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

Thank you!