Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-24

Parrot | source cross referenced

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

All times shown according to UTC.

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

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

Parrot | source cross referenced