Camelia, the Perl 6 bug

IRC log for #parrot, 2008-10-21

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:12 pantherse particle, looks like mk_language_shell.sh produces code that doesn't error out on make test anymore. However, it appears that make test on parrot root now spits out an error
00:13 dmknopp joined #parrot
00:13 nopaste "pantherse" at 69.233.246.105 pasted "make test on parrot root dir output" (561 lines) at http://nopaste.snit.ch/14341
00:14 pantherse before the 32061 revision I didn't get an actual error code from gmake, thought I'd let you know
00:17 chromatic pantherse, those are non-functional tests that we're not going to run by default any more.
00:18 chromatic Don't worry about them; all of the functional tests of things that matter passed.
00:18 pantherse ok, just making sure. I figured it's okay per the last few messages.
00:19 chromatic We had a long discussion about this earlier today, actually.
00:20 chromatic I've corrected the appropriate files and am re-running the test before I commit a fix.
00:25 grim_fandango__ joined #parrot
00:26 dalek r32062 | chromatic++ | trunk:
00:26 dalek : [lib] Fixed SVN properties on new file Parrot::Test::Util.
00:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32062
00:35 chromatic make testj works on x86-32/Linux
00:39 chromatic make testC has some segfaults.
00:44 chromatic The testC problems look like the same weird context problems we have with Parrot -> NCI -> Parrot control flow in the slow core.
00:47 chromatic make testf works on x86-32/Linux
00:47 chromatic make testg works on x86-32/Linux
00:48 chromatic make testj works on x86-32/Linux
00:50 chromatic make testr has the same failure as last month on x86-32/Linux
00:51 chromatic make testS has plenty of problems
00:52 chromatic It looks like testC and testS have the same types of problems.
00:53 Whiteknight I didn't even know we had all those make targets!
00:54 rdice joined #parrot
00:55 chromatic They run through make fulltest.
01:04 chromatic examples/benchmarks/overload.pir has deprecated add_multi syntax.
01:04 Whiteknight don't open a ticket, we're so close to 600!
01:07 chromatic I'll just fix it in place.
01:08 dalek r32063 | chromatic++ | trunk:
01:08 dalek : [examples] Replaced deprecated add_multi op with :multi declaration on multisub.
01:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32063
01:09 particle thanks for cleaning up my commit detritus, chromatic
01:09 chromatic You'd do the same for me.
01:09 particle and i have. :)
01:09 * particle looks at svn log for the past month
01:10 particle just under 1k revs
01:11 particle ok, <900
01:11 particle i've got to get these five tests passing
01:11 particle and i'd love to apply some patches from p6c
01:12 particle e.g. the doc patch from ovid
01:12 particle # compiler_6.obj : error LNK2001: unresolved external symbol _PMCNULL
01:12 chromatic Whiteknight, there's a segfault in examples/benchmarks/oofib.pir.  Want to stab it?
01:15 Whiteknight can't tonight, but if it's still here tomorrow I can
01:16 Whiteknight oh shoot, I need to update NEWS with some of the stuff I've been doing
01:16 * Whiteknight goes to look at the SVN logs now
01:16 particle svn log -r 31199:HEAD | gvim -
01:17 Whiteknight svn log -r 31199:HEAD | medit -
01:17 Whiteknight I never got into the swing of vim or it's kin
01:17 particle i never got away from it
01:18 Whiteknight back when I was first learning it, I left my computer on for 4 days because I couldn't figure out how to exit it
01:18 particle it's an editor with line noise commands... perfect for this perl programmer.
02:33 chromatic src/multidispatch.c is broken with regard to CPointer
02:34 chromatic It's setting CPointer to stack locations, which isn't going to work.
02:34 Infinoid is that related to the issues I'm seeing?
02:35 chromatic Looks like it.
02:35 chromatic Add this at line 170 in src/pmc/cpointer.pmc
02:35 chromatic fprintf( stderr, "Set %p pointer to %p\n", pmc, value );
02:35 chromatic then ./parrot examples/benchmarks/oofib.pir
02:36 chromatic Set 0x80db55c pointer to 0xbfc3cec0
02:36 chromatic Set 0x80db2bc pointer to 0xbfc3cec0
02:36 chromatic Set 0x80db0a8 pointer to 0xbfc3cec0
02:36 chromatic Set 0x80dae5c pointer to 0xbfc3cec0
02:38 chromatic 0xbfc3cec0 is way outside of any PMC pool... and it looks like stack storage, though I haven't checked the process map to be absolutely sure.
02:38 Infinoid it sure does
02:38 * Infinoid updates to r32063
02:38 chromatic I'm not sure the varargs unpacking code is correct in Parrot_mmd_add_function, even.
02:39 chromatic But that's a matter of taking one * off of STRING ** and PMC **.
02:41 ab5tract joined #parrot
02:42 chromatic That means CPointer's set_pointer has to dereference value pointers and merely copy pointers.
02:44 Infinoid ah.  now that ccache isn't trying to go over an nfsmount over a slow VPN, things are actually building at a reasonable pace.  (oops)
02:48 chromatic No reason we couldn't combine all of those operations in to set_FOO_keyed_str, where the key is the STRING type.
02:48 Infinoid infinoid@chirp parrot-trunk % ./parrot examples/benchmarks/oofib.pir
02:48 Infinoid Set 0x994150 pointer to 0x7fff4ec3a5b8
02:48 Infinoid Set 0x993d60 pointer to 0x7fff4ec3a5b8
02:48 Infinoid [snip a bunch of pages]
02:49 Infinoid Set 0xa1c190 pointer to 0x7fff4ec3a5b8
02:49 Infinoid Set 0xa1be10 pointer to 0x7fff4ec3a5c8
02:49 Infinoid zsh: segmentation fault  ./parrot examples/benchmarks/oofib.pir
02:49 chromatic 0x7fff... definitely looks like stack space.
02:50 Infinoid yep, confirmed by /proc/[pid]/maps
02:50 Infinoid I'm seriously considering turning off this stack randomization stuff gentoo does.  The numbers aren't consistent between runs, which make this kind of thing harder.
03:24 apeiron joined #parrot
03:31 Zaba joined #parrot
03:38 apeiron joined #parrot
03:40 allison joined #parrot
03:42 apeiron joined #parrot
03:43 chromatic Infinoid, look at Parrot_mmd_multi_dispatch_from_c_args though.
03:43 chromatic With a signature like PP->I, the INTVAL is a pointer to an INTVAL.
03:44 chromatic See cmp in src/pmc/default.pmc for example.
03:47 chromatic In that case, the pointer *can* be to a stack location, because it's to a prior call.
03:48 Infinoid hmm
03:48 Infinoid that sounds dangerous
03:48 chromatic Parrot_mmd_multi_dispatch_from_c_args(interp,
03:48 chromatic "cmp", "PP->I", SELF, value, &retval);
03:48 chromatic It's an out parameter.
03:50 Infinoid so what's to stop that spot on the stack from being overwritten?
03:51 Infinoid shouldn't it be copied to some more stable location when wrapping a PMC around it?
03:52 chromatic In theory, the PMC shouldn't outlast that call frame.
03:52 Infinoid an "out parameter" is a return value, right?
03:52 chromatic yes.
03:53 chromatic Because the MMD function doesn't know the arity of the function being called, you pass in pointers to locations where it will store the return values.
03:53 Infinoid so you allocate something on the stack and return it, thereby "freeing" your section of the stack... then the caller goes and calls something else that uses a lot of stack... crunch?
03:53 chromatic INTVAL retval;
03:53 chromatic /* Don't multidispatch if you've got two pointers to the same PMC. They
03:53 chromatic * are equal. */
03:53 chromatic if (SELF == value)
03:53 chromatic return 0;
03:53 chromatic Parrot_mmd_multi_dispatch_from_c_args(interp,
03:53 chromatic "cmp", "PP->I", SELF, value, &retval);
03:53 chromatic return retval;
03:54 chromatic retval's a stack variable, so &retval is a pointer to a stack location, but return retval is fine because it returns a value, not a pointer.
03:54 Infinoid ok, that makes sense.  sorry, I thought we were talking about pointers to pointers
03:55 chromatic Me too, but we're not here.
03:57 Ademan joined #parrot
04:02 Infinoid what's a "PPP->P" signature?  I'm not sure how to read that.
04:02 Infinoid takes 3 PMC arguments, returns 1 PMC?
04:03 chromatic Yes.
04:03 Infinoid cool.
04:05 chromatic allison, how does a CallSignature set return values through a CPointer PMC?
04:10 chromatic Anyway Infinoid, that's why our backtraces were showing that BigInt and FixedIntegerArray and such were changing the value of the pointed-to value.
04:14 Infinoid ok, that makes sense
04:14 Infinoid unfortunately, I think the memory containing this pointer got freed somewhere.
04:17 chromatic We probably need to invalidate the CPointer PMC after we've finished manipulating its results.
04:27 tetragon joined #parrot
04:28 nopaste "chromatic" at 69.64.234.10 pasted "Invalid CPointer After Setting Its Return Values" (49 lines) at http://nopaste.snit.ch/14342
04:28 chromatic Infinoid, try that.  It fixes things for me.
04:31 dalek r32064 | chromatic++ | trunk:
04:31 dalek : [t] Fixed benchmark output results from floating point precision patch.
04:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32064
04:31 Infinoid t/op/bitwise....ok
04:32 Infinoid examples/benchmarks/oofib.pir runs to completion, too
04:32 chromatic That's definitely an improvement.
04:33 Infinoid absolutely.  going through a "make test" now
04:37 * ab5tract is making smoke
04:39 Infinoid All tests successful.
04:39 Infinoid chromatic++
04:40 donaldh joined #parrot
04:40 chromatic Committing now.
04:40 Infinoid out of curiosity, what's the s/results/returns/ part about?
04:42 chromatic See set_attr_str in the CallSignature PMC.
04:42 chromatic Future-proofing.
04:46 dalek r32065 | chromatic++ | trunk:
04:46 dalek : [src] Made return-to-C parameter handling invalidate any CPointer PMC used to
04:46 dalek : store out parameter pointers.  Without this, any GC which somehow marks a used
04:46 dalek : CPointer PMC may attempt to mark a location on the C stack as if it were a
04:46 dalek : pointer.  That should frighten you.  See RT #59880 for an example of the
04:46 dalek : consequences.
04:46 dalek : If CPointer PMCs get re-used, this may be a problem, but if you re-use a
04:46 dalek : CPointer PMC, you're probably going to abuse your C stack in a very bad way
04:46 dalek : anyway, and I may not help you, so don't do that.
04:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32065
04:47 chromatic Hm, perhaps I should eat.
04:48 Infinoid oh hey, good idea.
05:08 * ab5tract is making smoke again
05:08 ab5tract good shit yall ;)
05:32 dalek r32066 | moritz++ | trunk:
05:32 dalek : [rakudo] Update README with instructions on how to run individual tests.
05:32 dalek : Patch courtesy by Ovid++. Closes [perl #60016].
05:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32066
05:39 TimToady joined #parrot
05:40 diakopter joined #parrot
05:59 Infinoid chromatic: I've closed #59880, thanks again.
05:59 Infinoid z &
06:05 rajit joined #parrot
06:10 uniejo joined #parrot
06:26 allison chromatic: still around?
06:38 allison chromatic: ah, looks like you've got it sorted, and no longer need the answer to the earlier question
06:40 allison chromatic: giving the CPointer an empty signature, clever
06:43 Patterner joined #parrot
06:56 chromatic It might not even be worth marking anything in CPointer.
07:07 allison chromatic:possibly not, though if GC did run in the middle of a call, then it's useful to know that a string or PMC return value isn't going to be collected before the call completes
07:08 spinclad joined #parrot
07:08 allison (in theory, it will be marked by the calling context, but can't necessarily guarantee that)
07:09 * allison sleeps, early to airport tomorrow
07:16 bacek joined #parrot
07:30 cosimo joined #parrot
07:34 tetragon joined #parrot
07:56 iblechbot joined #parrot
08:16 bacek evening
08:17 bacek moritz: around?
08:19 bacek msg moritz There is 'sprintf' and 'chomp' is Str.pir in "todo" section. Looks like they already implemented
08:19 purl Message for moritz stored.
08:29 tomyan joined #parrot
08:49 TiMBuS joined #parrot
09:02 dalek r32067 | fperrad++ | trunk:
09:02 dalek : [install]
09:02 dalek : - remove Perl modules dependencies
09:02 dalek : - this script must be shipped (see RT #58852)
09:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32067
09:04 Zaba joined #parrot
09:12 Debolaz joined #parrot
09:49 kj joined #parrot
11:06 Bzek joined #parrot
11:18 Bzek joined #parrot
11:22 gaz joined #parrot
11:28 ruoso joined #parrot
11:33 masak joined #parrot
11:42 nopaste joined #parrot
12:00 TonyC joined #parrot
12:03 Lorn joined #parrot
12:29 moritz I won't be there for #ps today, but I have nothing interesting to report anyway
12:44 davidfetter joined #parrot
12:59 * ruoso wonders if anyone is aware of  http://www.perlfoundation.org/pe​rl6/index.cgi?distributionformat
13:00 masak is it release day today?
13:03 gryphon joined #parrot
13:04 Infinoid I think so, yes
13:09 donaldh joined #parrot
13:15 xiaoyafeng joined #parrot
13:16 Infinoid infinoid@tweet ~/parrot $ ./parrot examples/library/pcre.pir asdf as
13:16 Infinoid asdf =~ /as/
13:16 Infinoid 1 match(es):
13:16 Infinoid Segmentation fault
13:16 purl (Core dumped)
13:16 jhorwitz joined #parrot
13:17 nopaste "Infinoid" at 75.28.74.251 pasted "backtrace (bufstart pointer is null)" (34 lines) at http://nopaste.snit.ch/14346
13:18 Infinoid NotFound: I think that's the same error you were seeing.
13:20 Infinoid ./parrot -G runs fine, of course.
13:25 Wknight8111 joined #parrot
13:34 particle masak: yes, i release today
13:36 Wknight8111 particle++
13:37 particle moritz++ for applying ovid's patch before me
13:37 Wknight8111 the karma fairy sprinkles liberally!
13:37 particle :)
13:37 particle i *really* hate releasing parrot with known segfaults
13:41 Wknight8111 There are known segfaults? Which ones?
13:42 Wknight8111 and have you started the release process yet? Is it too late to update NEWS and stuff?
13:42 jhorwitz Wknight8111: i submitted #60030 last night.  chromatic and i worked on it before, but i was able to get a nice test case this time.
13:44 jhorwitz you're local, so if you fix, you could collect your beer in person.  ;-)
13:44 PerlJam particle: just remember that perl 5 AFAIK can still be made to segfault.
13:44 Wknight8111 great, now I have to take a look at it
13:44 PerlJam (I haven't played with 5.10 much, so they may have fixed most of the segfaults)
13:44 particle Wknight8111: please update news, i haven't started the release yet
13:45 particle will probably be a few hours, as i'm getting paid for work atm :)
13:45 Wknight8111 yeah, me too :)
13:45 * jhorwitz has a sudden guilt trip and gets to work...
13:46 dalek r32068 | Whiteknight++ | trunk:
13:46 dalek : [NEWS] Update NEWS with an IMCC change I made this week.
13:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32068
14:02 barney joined #parrot
14:09 pmichaud particle:  what's the release eta?
14:11 Wknight8111 he said it's going to be a few hours
14:11 Wknight8111 I'm more interested in what the release version and release name is going to be!
14:12 Wknight8111 and I really should be taking good notes if I'm going to have to do this in december
14:12 DietCoke Wknight8111: the notes are already taken. docs/project/rel*
14:12 DietCoke feel free to do a dry run to practice. =-)
14:13 Wknight8111 trust me, I've already done one or two on my machine
14:13 Wknight8111 I thought about scheduling the day off work too, but I don't have any vacation time left and I need the money too bad
14:15 DietCoke money++
14:15 pmichaud I'm not in favor of a release that regresses, though.
14:18 DietCoke which regressions are you referring to?
14:18 pmichaud the inplace math ops
14:18 DietCoke I didn't realize we had any failing tests on that.
14:18 DietCoke (I've pretty much given up on this release for tcl, though, so haven't been following much else.)
14:18 pmichaud #59788, but apparently there are more.
14:20 particle pmichaud: yeah, i want that fixed
14:21 particle i may hold over until tomorrow for it, if we see a solution in sight
14:21 DietCoke I added it as a dep on the release ticket.
14:21 particle Wknight8111: the release number is 0.8.0
14:21 particle i haven't even put two minutes thought into a name
14:21 DietCoke I didn't realize it was a showstopper.
14:22 pmichaud inplace might not be a showstopper, but we keep finding more fundamental failures in Parrot so I'm curious how many more are left.
14:23 DietCoke are we adding failing tests for these failures?
14:24 DietCoke (not that we'd have noticed them given that smolder's been dying for about a week)
14:24 pmichaud yes.  #59788 has tests.
14:24 pmichaud #59630, too.
14:25 grim_fandango joined #parrot
14:29 Wknight8111 8.0? nice!
14:29 Wknight8111 or, 0.8.0
14:45 DietCoke 0.8.0
14:45 DietCoke note that 0.9 is NOT the last point release, a source of much confusion.
14:45 PerlJam People won't be confused any more when 0.10.0 comes out :)
14:46 DietCoke perhaps we should just jump to that. =-)
14:50 silug joined #parrot
15:16 dalek r32069 | pmichaud++ | trunk:
15:16 dalek : [rakudo]:  per #parrot, remove 'codetest' from 'make test' target
15:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32069
15:18 Wknight8111 What's the criteria to updating to 0.x.0 or 0.x.y? How do we decide whether it's a major or minor point release?
15:19 pmichaud addition of a major milestone feature causes a major point release
15:19 Infinoid isn't it a milestone thing?
15:19 pmichaud in this case, mmd
15:19 Infinoid cool.
15:19 particle Wknight8111: http://www.perlfoundation.org/pa​rrot/index.cgi?release_planning
15:19 particle things are a little out of order there, but we keep adjusting
15:20 particle pmichaud: are you ready to call ast 'complete'? can't remember if that milestone has been paid
15:20 particle actually, are compiler tools complete, too?
15:21 pmichaud milestone for ast implementation is paid
15:21 particle where complete is >>80%
15:21 pmichaud but not for ast documentation (still needs to be done)
15:21 pmichaud oh, maybe I have that backwards
15:21 pmichaud I think we've already done   ast impl and doc, but only compiler tools impl
15:22 particle that sounds right to me
15:22 pmichaud (i.e., we're still missing compiler tools doc)
15:22 pmichaud adding that to my hiveminder list....
15:22 particle unless you count kj++'s tutorial
15:24 Wknight8111 hiveminder! I started using hiveminder about a week ago, and I love it!
15:24 Wknight8111 it's turning my entire life around
15:24 Infinoid wow.  with a glowing review like that, how can I not check it out
15:24 pmichaud what's really nice is being able to manipulate my hiveminder lists from irssi  :-)
15:25 Wknight8111 I haven't watched more then 15 minutes of TV since I got organized with hiveminder. Having a todo list right there in my face is amazingly motivating
15:25 pmichaud since I already have irssi open anyway, it's nice to just be able to type "/todo add compiler tools documentation [perl]"  and have it go onto my list.
15:25 particle hiveminder++
15:25 particle wish it would work on my phone, att--
15:26 particle so, should i pop the release number to 0.9.0 based on ast completion?
15:26 pmichaud no
15:27 pmichaud i'd still only go to 0.8, even if there are multiple milestones achieved.
15:27 Wknight8111 What all milestones have been acheived this month?
15:28 Wknight8111 I know we did the MMD stuff, what else?
15:28 particle ok, i'm renumbering the release plan now
15:28 dalek jerry.gay+openid@gmail.com | Release Planning:
15:28 dalek link: http://www.perlfoundation.org/pa​rrot/index.cgi?release_planning
15:28 particle mmd/concurrency
15:29 Wknight8111 I can't wait till we can finally get that GC milestone tackled!
15:29 Wknight8111 until that problem gets resolved, my sanity is going to be tenuous at best
15:30 Wknight8111 especially with daily hiveminder emails about it in my inbox!
15:30 particle currently, gc is scheduled for release 0.13 :)
15:31 particle Wknight8111: take a week off the reminder emails for your sanity
15:31 particle just postpone it, you're not going to work on it anyway
15:31 Wknight8111 ...that sounds like a challenge!
15:31 DietCoke particle: works fine on my at&t phone. =-)
15:31 dalek r32070 | pmichaud++ | trunk:
15:31 dalek : [rakudo]: Fix test output in 06-op-inplace.t (RT #60016)
15:31 dalek : * Patch courtesy Ovid++ (publiustemp-perl6internals2@yahoo.com)
15:31 Wknight8111 but no, you're probably right. I won't have time to work on it for a while
15:31 dalek : * Now correctly reports failures as failures instead of misnumbered tests
15:31 dalek : * Still some failing tests due to inplace errors (RT #59788 ?)
15:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32070
15:31 dalek r32071 | pmichaud++ | trunk:
15:31 dalek : [rakudo]:  Correct infix:<**=> operation for new 'pow' opcode (RT #60016)
15:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32071
15:33 particle pmichaud: r32071 is purely a workaround, correct?
15:34 jan joined #parrot
15:36 dalek jerry.gay+openid@gmail.com | Release Planning:
15:36 dalek link: http://www.perlfoundation.org/pa​rrot/index.cgi?release_planning
15:38 pmichaud no.
15:38 pmichaud it's not a workaround.
15:42 particle so, do the rest of the inplace ops need to change?
15:42 pmichaud I don't know yet
15:42 pmichaud the difference for **= is that parrot doesn't have an inplace pow opcode
15:42 pmichaud thus the code was doing   pow a, a, b
15:43 pmichaud which used to compute a**b and then store the result back in a
15:43 pmichaud but now the pow opcode code something different
15:43 pmichaud namely, it computes a**b in a new PMC and then sets the a register to point to the new PMC, leaving the original PMC untouched (i.e., it now acts like n_pow)
15:47 particle ah
15:47 dalek r32072 | pmichaud++ | trunk:
15:47 dalek : [rakudo]:  Fix some tests in 06-op-inplace.t .
15:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32072
15:48 particle that seems wrong on the parrot side
15:48 particle seems to me there should be inplace pow
15:49 pmichaud eh, it's not likely going to matter anyway, at least for Rakudo.
15:49 pmichaud I suspect most or all of the inplace operations are going to end up not using the inplace opcodes anyway
15:49 pmichaud unless we really think we get a significant optimization from it.
15:50 pmichaud in Rakudo,  a op= b   is likely to be implemented as a meta operator, directly becoming  a = a op b
15:50 pmichaud at least for most values of "op"
15:54 pmichaud we're agreed that t/02-test-pm/  should disappear, yes?
15:54 particle sure, rip it out
15:54 Theory joined #parrot
15:55 pmichaud done in r32073.
15:56 dalek r32073 | pmichaud++ | trunk:
15:56 dalek : [rakudo]:  Remove obsolete t/02-test-pm/ .
15:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32073
15:56 DietCoke particle: is "cd languages/pheme && make test" a showstopper for you to release?
15:56 particle what's pheme?!?! ;)
15:57 particle the failures are the same in pheme as for tcl, right?
15:57 particle pmichaud: you need to delete the testtest target in perl6 makefile
15:58 DietCoke particle: they're related. I can't say more than that with certainty
16:00 pmichaud particle:  I thought I already did that.
16:01 pmichaud (r32069)
16:01 particle ah, sorry i missed that one
16:01 particle ok, i have <30m to write an important work document, so i'm going incognito
16:01 particle i'll read scrollback
16:05 pmichaud np -- I have errands to run, then I need to head back to the hospital
16:05 pmichaud I _may_ miss #ps today
16:05 pmichaud if so, I'll post-contribute my report
16:06 pmichaud (oh, for those who are wondering -- paula's having minor surgery today so I'm shuttling her to/from the hospital)
16:07 nopaste "barney" at 84.154.51.71 pasted "Has IMCC been changed WRT macros?" (36 lines) at http://nopaste.snit.ch/14347
16:28 sjansen joined #parrot
16:34 DietCoke barney: odd. (I'd update the label and locals to use the macro versions of same, but even with that, I can't get that last line to compile
16:49 NotFound joined #parrot
16:49 NotFound Hi
16:49 DietCoke NotFound: ho
16:49 barney Coke: I think it's the macro constants .STAT_xxxx    The order of evaluation might have changed
16:50 NotFound Let's go
16:50 * DietCoke is found by his high school reunion committee.
16:50 * DietCoke hopes his easy-to-remember email address helped.
17:00 dalek r32074 | bernhard++ | trunk:
17:00 dalek : [Pipp] workaround for funny macro expansion weirdness
17:00 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32074
17:06 Infinoid All tests successful on 4 out of 5 of my linux boxes... that's a lot better than last week
17:06 particle pmichaud: let me know if you want to get spectest_regression.csv updates in before release
17:07 Infinoid my only remaining failure is the pcre test in t/examples/library.t, and I'm not sure what's different about that box.
17:17 Theory joined #parrot
17:19 DietCoke pcre version?
17:21 tewk joined #parrot
17:22 Infinoid 7.7
17:22 chromatic joined #parrot
17:22 Infinoid hmm.  the GC is barfing because we're allocating a buffer with a null pointer, and then trying to dereference it later during a compact_pool run
17:23 Infinoid #2  0xb7b57e46 in string_make_direct (interp=0x8050040, buffer=0x0, len=500, encoding=0x8070d88, charset=0x8072328, flags=0) at src/string.c:725
17:23 Infinoid buffer=0 is wrong, right?
17:24 Infinoid oh, nevermind.  the pointer is set and then nulled later by libpcre, that was nice of them.
17:24 Infinoid Old value = (void *) 0xb72a5904
17:25 Infinoid New value = (void *) 0x0
17:25 Infinoid 0xb78db59e in pcre_compile2 () from /usr/lib/libpcre.so.0
17:26 NotFound NULL buffer and non zero length?
17:27 Infinoid yep
17:27 Infinoid pointer=0 length=0x500
17:28 Wknight8111 urg
17:28 NotFound Smells bad to me, even if valid.
17:28 Infinoid I really doubt it's valid.
17:28 Wknight8111 tell libpcre that I hate it
17:28 Infinoid even if it didn't crash, it would leak memory
17:28 NotFound Infinoid: if (buffer) { ... } else {s->strlen = s->bufused = 0;}
17:29 NotFound Is ignored.
17:30 DietCoke http://smolder.plusthree.com/app/public_p​rojects/report_details/6469#first_failure ... that's looking pretty tragic for a near-release check.
17:30 * DietCoke fires up a run on his OS X box.
17:31 Infinoid parrot's testsuite passes fine for me on 4 out of 5 boxes
17:31 Infinoid this crash is the only thing preventing the 5th from passing
17:31 particle dietcoke: looks like it's a link problem, which is what's causing 5 test failures for me with t/src/ with msvc
17:32 NotFound Infinoid: from where is that call to string_make_direct?
17:34 chromatic It'd be nice to bisect that link problem down to one specific patch.
17:34 particle yes, it would.
17:36 Tene I don't have net access here, so no #ps for me.
17:36 * particle checks out r31199 as a starting point
17:36 Infinoid NotFound: one moment, nopasting
17:36 barney LDTA 2009 in York, http://ldta.info/, might be an interesting conference
17:36 particle tene: any time to update pynie/cardinal news before release?
17:37 nopaste "Infinoid" at 96.238.213.50 pasted "gdb log" (98 lines) at http://nopaste.snit.ch/14348
17:37 Infinoid NotFound: see the first and second backtraces.  but I don't think that's the problem... it seems to have been allocated correctly
17:37 Infinoid the issue is, the pointer was unset later
17:38 particle Infinoid: when you say testsuite, do you mean fulltest or test?
17:38 Tene particle: I'll be back online around 5:00 EST.
17:38 particle tene: you may make the cut, then. thanks
17:38 Infinoid I just mean test
17:38 Infinoid once that passes, I can fulltest too :)
17:38 Tene I'm on my phone right now.  I don't think there are any svn clients for PalmOS.  :)
17:39 Tene (I certainly hope not!)
17:39 particle i don't need a proper patch, bullet points will do
17:39 allison joined #parrot
17:39 particle however, you may need svn log to jog your memory, i know
17:39 particle hey allison, travelling today?
17:40 allison yup, flying to sfo
17:40 Tene Oh, sure.  I'll /query
17:40 particle from?
17:40 allison portland
17:40 purl portland is at http://www.perl.org/oscon/2003/portland/altis.html or (: oscon, pdx people)
17:40 particle an, no worries
17:41 Infinoid NotFound: I created #60042 so I won't forget about the issue.
17:43 particle allison: anything special i should worry about wrt release?
17:44 pmichaud particle: yes, I'd like to get spectest_regression.csv updates in today, but it may be 3-4 hours before I can do that
17:44 NotFound Infinoid: looks like the buffer is allocated, but length and bufused are set to zero.
17:44 pmichaud it's not worth holding the release for, if that's the only thing holding the release
17:44 allison particle: looks like we've had a fantastic effort at cleaning up smolder failures
17:44 particle pmichaud: i *must* be *done* with release by 5p seattle time
17:45 pmichaud that's 7p CDT -- hrm
17:45 Infinoid NotFound: yes, the values are set correctly later on in Parrot_allocate_string()
17:45 particle pmichaud: your changes can go in last, since they're not code
17:45 particle allison: yes, and hopefully squashing a few more before release
17:45 pmichaud particle: if I don't have it done by 3:30p PDT, it's not likely to happen.
17:45 Infinoid wonder if there's a way of telling libpcre to not null our pointer.  or maybe we can just give it a bounce pointer and fixup the case afterwards
17:45 NotFound Infinoid: the setting to zero happens *after* calling Parrot_allocate_string
17:45 Infinoid NotFound: ... by libpcre
17:47 dalek r32075 | particle++ | trunk:
17:47 dalek : [RELEASE] updates for Cardinal and numbered release as 0.8.0
17:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32075
17:47 NotFound Infinoid: if libpcre manipulate string internal details, is not strange that if fails in bizarre ways.
17:48 DietCoke particle: http://smolder.plusthree.com/app/p​ublic_projects/report_details/6473 looks good, anyway.
17:48 Infinoid it is unsetting our pointer, it must think its a string literal or something (otherwise memory will leak)
17:48 DietCoke (osx intel)
17:48 particle boy, i wish those urls were friendlier
17:49 DietCoke shorten that
17:49 purl That URL is at http://xrl.us/oumq7 [smolder.plusthree.com]
17:49 Infinoid nice.
17:50 Infinoid NotFound: we've made an NCI call out to a library that unset the pointer we gave it, which screwed up our internals.  sounds like something NCI should handle
17:50 * DietCoke <B extjs.
17:50 particle friendly as in, parrot/darwin-gcc-x86_64/ or whatever
17:50 DietCoke particle: there's a tag could, I think.
17:51 particle and i'd love the test summary info at the top
17:51 DietCoke smolder?
17:51 purl smolder is http://sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or http://smolder.plusthree.com/app​/public_projects/smoke_reports/8
17:51 NotFound Infinoid: you must not treat a buffer under control of the string subsystem as an arbitrary pointer.
17:52 DietCoke the smolder guy (mike?) has been very responsive when we ask for features.
17:52 Infinoid agreed.  I think maybe we should create a bounce pointer and then give *that* to libpcre
17:52 DietCoke bounce pointer?
17:53 Infinoid we're giving it a pointer to a pointer, but that value is important to use for GC reasons
17:53 tewk Infinoid: you can tell NCI to transform a STRING to a char*,  i think a 't' in the signature doesn that.
17:53 Infinoid so I want to copy it and then give libpcre the copy
17:53 Infinoid so it can unset it without breaking us
17:53 Infinoid s/use/us/
17:53 tewk s/doesn/does
17:54 * jhorwitz finds string GC maddening
17:54 * Infinoid finds NCI confusing
17:55 Infinoid its being called by pcf_p_tiB3P(), if that tells you anything about the signature it's using.
17:57 tewk the B in the signature may not be right, it may need to be a t, file:line?
17:58 Infinoid typedef void * (*func_t)(char *, int, void **, int *, PMC *);
17:58 DietCoke better you get confused now than someone else at 1.0. or something.
17:58 Infinoid yeah, I don't think the char* is the problem, I think its the void**
17:58 Infinoid that's pcre_compile's char**errptr argument
17:59 Infinoid tewk: http://nopaste.snit.ch/14348
17:59 Infinoid second backtrace.
18:00 tewk Infinoid: where is the pir its trying to execute?
18:00 Infinoid oh.  its something called from examples/library/pcre.pir, one moment
18:01 Infinoid runtime/parrot/library/pcre.pir:89
18:02 Infinoid that NCI function is called by examples/library/pcre.pir line 56.
18:04 jhorwitz that doesn't look right for the signature
18:05 Infinoid its a pointer to a char* which libpcre uses to give you an error string if something breaks
18:05 Infinoid but instead, we're passing a pointer to a string as an input, and libpcre is mangling it and breaking GC.
18:06 particle joined #parrot
18:07 Infinoid it is odd that this only breaks on one machine and not others
18:07 allison Infinoid: mmm, yeah, passing a pointer to a STRING in place of a pointer to a char * will certainly break things
18:07 tewk Yeah its a char* OUT type variable, I'm trying to see how to handle that.  B used to be the way to do that but I don't know now.
18:08 jhorwitz i *never* got B to work
18:08 tewk B reached into the guts of buffers.
18:08 jhorwitz tried to use it in mod_parrot years ago and i gave up
18:08 tewk I think it worked before calling conventions got redone.
18:09 allison we haven't changed the NCI calling conventions
18:09 Infinoid allison: well, we're giving it a pointer to the char* pointed to by the STRING... but its an output, not an input
18:09 Infinoid when libpcre sets it to NULL, its really setting the STRING's pointer to NULL, which breaks gc later on.
18:10 Infinoid (I think.)
18:10 allison yeah, that's giving a little too much access to STRING internals
18:10 tewk looking at tools/build/nativecall.pl:97
18:11 Zaba what does parrot use pcre for?
18:11 tewk 16172 paultcochrane         #     b => "Buffer *final_destination =
18:11 Infinoid well, the NCI example, for starters
18:11 * jhorwitz fails at "Failed to load libpcre" even with libpcre installed.  hrm.
18:11 particle pcre is optional
18:11 particle used as an example of linking an external library to parrot
18:11 NotFound The library linking is another issue that needs some discussion.
18:12 particle yes, i'm trying to find where it bork
18:12 tewk svn blame 16172 paultcochrane
18:12 tewk I'm guessing it hasn't worked since pre  16172
18:13 Infinoid have we just gotten lucky and libpcre didn't try to overwrite the error pointer in most cases?
18:13 chromatic That sounds likely.
18:13 Infinoid lucky me
18:14 tewk Infinoid: It shouldn't be to hard to fix.
18:14 NotFound With code like that, minimal changes in garbage collection can break.
18:15 Infinoid tewk: great, I'm pretty clueless but I'm open to suggestion
18:15 tewk give me a minute
18:15 particle r31199 failed (t/src linking), trying r30000
18:18 NotFound "if compilation of a  pattern fails, pcre_compile() returns NULL, and sets the variable pointed to by errptr to point to a textual error message. This is a static string that is part of the library. You must not try to free it."
18:18 chromatic We need to set the external flag on the STRING then somehow.
18:18 Infinoid in my case, it's just trying to write NULL to errptr, which has disasterous consequences
18:19 jhorwitz couldn't you pin it beforehand?
18:21 tewk "B" is the right answer, B is just broken.
18:21 * jhorwitz touches nose
18:22 Infinoid tewk: ok.  I posted that nopaste as RT #60042, but it's pretty terse, I can add your analysis to it
18:23 tewk I'm working on fixing it right now, assign #60042 to me
18:23 Infinoid great, thanks
18:24 chromatic #ps in 7
18:26 allison my flight leaves 20 minutes after #ps starts, so I'll miss question time. does anyone have any questions for me?
18:27 chromatic Why is there air?
18:27 allison So you can speak.
18:28 Ivatar joined #parrot
18:29 particle allison: if you have any suggestions for a release name, let me know
18:29 chromatic "A Golden Field of Radioactive Parrots"
18:29 kj currently it seems 'broken wings' would do, but that's kindof bad for publicity :-P
18:30 allison particle: There's the ever useful "Index of Parrot Species" http://www.avianweb.com/parrotspecies.htm
18:30 NotFound kj: 'Broken arrow' can be even worse X-)
18:30 allison have we used "Antipodes Island" yet? :)
18:31 NotFound Anti-pod?
18:31 chromatic #ps time
18:31 Infinoid NotFound: its just like pod, but it contains disinformation
18:32 NotFound Infinoid: I think we have several of that kind
18:33 chromatic allison, any ideas on how to unbreak Pheme?
18:34 allison chromatic: I suspect the problem is that PGE's output tree changed
18:35 allison chromatic: I know the problem is that Pheme's TGE rules are returning null nodes, which shouldn't happen
18:35 johbar joined #parrot
18:36 chromatic Cannot find the attribute 'application' (PAST;Op) that you asked for.
18:36 allison chromatic: okay, so PAST attributes have changed
18:37 allison chromatic: are you using PCT PAST or custom PAST?
18:37 chromatic PCT PAST.
18:37 chromatic transform application (PAST::Op) :language('PIR') { ... }
18:37 allison chromatic: so it's very possible that it changed out from under you
18:38 chromatic lib/ASTGrammar.pir:157:.sub '_PAST::Op_application' :method
18:39 chromatic I don't know how TGE creates the subs for the attribute grammars.
18:39 * DietCoke drinks a coffee.
18:40 DietCoke I think that's an OK sub name; just need to key off the types properly in the dispatch() calls.
18:41 DietCoke -think-. (never did get tcl working)
18:41 DietCoke Tene: allison will not be here for questions, so ask over here now.
18:42 allison chromatic: okay, I'll take a look on the plane
18:42 DietCoke de plane?
18:43 allison en plane
18:43 chromatic en passant
18:43 DietCoke check.
18:45 Tene parrot;Foo;Bar and perl6;Foo;Bar are both created as class Foo;Bar.  There's an RT ticket somewhere.
18:45 Tene I'll make mail later.
18:46 masak joined #parrot
18:47 Wknight8111 $real_job can be such a bother sometimes, like when it distracts me from #ps!
18:47 jhorwitz $real_job--
18:47 particle yeah. $real_job--. who's hiring?
18:48 Tene Or takes me to Georgia, with no wifi.
18:48 jhorwitz oh the horror!
18:48 Wknight8111 particle, I could probably get you a job here as a low-level hardware assembly guy
18:48 Wknight8111 ...not that you would want that
18:48 jhorwitz yes particle, get back over here.
18:48 particle i haven't used a soldering gun in a few months...
18:49 Wknight8111 good, we don't even have guns here, just shitty radioshack irons
18:49 particle i *didn't* get a job in pittsburgh today
18:49 jhorwitz Wknight8111: you and i require a beer one happy hour in the near future.
18:49 particle ...better than a one beer happy hour...
18:50 jhorwitz well, it all starts with one....
18:51 Wknight8111 why, did I do something good?
18:51 jhorwitz i didn't say i was buying...  ;-)
18:51 Wknight8111 haha! nice
18:52 Wknight8111 I'm around in November if you want to get together and drink and hack
18:52 jhorwitz we're 15 minutes away.  the rules state that beer must be had.
18:53 Wknight8111 Agreed
18:53 jhorwitz november it is then
18:53 masak I have a question about point 1 of bacek's comment in http://rt.perl.org/rt3/Tic​ket/Display.html?id=57652 -- what does it mean, more exactly?
18:54 masak because I think I can do points 2 and 3 quite easily, so I'm wondering if point 1 is easy too.
18:54 jsut|work there are 2 companies i know of looking hard for perl people in toronto.
18:55 particle jsut|work: feel free to send me the details, i'll see if they're open to part-time telecommuters
18:56 particle particle?
18:56 purl The most abundant particle in the universe is the moron. or spin 1/2, charge 2/3 or jerry gay or a boson. or a bozon. or a bogon or one bad mobo. or full of lies
18:56 particle particle is also mailto:jerry.gay@gmail.com
18:56 purl okay, particle.
18:57 pmichaud masak: bacek's patch is modifying PCT to allow a 'control' attribute
18:58 masak oh! didn't see the attached patch till now
18:58 * masak investigates
19:00 Infinoid chromatic: you're welcome.
19:00 particle has the 'loop' refactor been done yet?
19:02 chromatic welcome?
19:02 purl Heh, not likely around here you won't be.
19:02 particle carrie fisher was born today in 1956
19:05 chromatic mmm cinnamon rolls
19:05 jhorwitz LOL
19:06 cotto joined #parrot
19:06 DietCoke I'm only using TGE because PCT can't do everything I need. I think.
19:06 Tene particle: no
19:06 DietCoke I wouldn't complain if someone ported parrot away from TGE if the plan is to ditch TGE.
19:06 particle the plan is not to ditch tge
19:06 DietCoke s/ported parrot/ported partcl/
19:07 pmichaud DietCoke: even if PCT doesn't do what you need it to, NQP might.
19:07 pmichaud the "replacement" for TGE is really NQP, not PCT
19:07 particle except see my "really ugly" comment about tree walking with nqp
19:08 pmichaud I saw the comment but didn't understand
19:08 particle see the patch i emailed you
19:08 Wknight8111 purl, the plan?
19:08 purl well, the plan is to get you onto something, aevil.
19:08 DietCoke basically, I don't have a preference, is what I'm saying.
19:08 particle for $?BLOCK[0][1] { ...
19:09 pmichaud oops, I have to run now
19:09 pmichaud time to head home again :-)
19:09 particle ~~
19:09 chromatic That man seems born to run.
19:10 DietCoke baby?
19:10 purl Baby me and you'll be peeing through a catheter!
19:10 masak purl, you're obscene, grotesque and obnoxious.
19:10 purl masak: sorry...
19:11 jhorwitz purl requires an anger management module
19:11 purl jhorwitz: excuse me?
19:12 cotto Great Tit would be a good release name (http://en.wikipedia.org/wiki/Great_Tit)
19:12 chromatic That *is* a nice name for 8
19:12 cotto although not technically a parrot
19:13 Wknight8111 and not technically unobscene
19:13 masak does it have to be?
19:13 cotto there are some nice Tits on that page
19:13 * jhorwitz covers purl's ears
19:13 Wknight8111 no, we can be as obscene as we want. Everybody knows there are no women on the internet :)
19:13 cotto masak, I don't think "reverse sublimation" is a parrot either.
19:13 masak jhorwitz: way, way too late
19:14 jhorwitz :)
19:14 masak cotto: did I say it was? :)
19:14 chromatic It might be nice to pick something that's not even tangentially sexist though.
19:14 masak yes.
19:14 * masak is slowly coming around to 'Octarine'
19:14 chromatic Though I do admit "Caulked Snack" was Cockney slang.
19:15 masak octarine's a nice color
19:17 Wknight8111 okay, I have to split. I have another meeting today on another IRC server.
19:17 Wknight8111 later
19:17 Wknight8111 left #parrot
19:18 masak has there already been a Parrot release named 'Cockatoo'?
19:20 cotto hmmm.  it seems like Parrot's Wikipedia page should have a list of previous releases.
19:21 masak I know some page on the web does
19:22 cotto http://www.parrotcode.org/docs/parrothist.html
19:23 masak hm, says here #57332 depends on merging of the pdd25cx branch. that branch is merged now. maybe something I could look into?
19:27 NotFound Some objection to "typedef struct Parrot_Context Parrot_Contex;" and get rid of parrot_context_t ?
19:28 NotFound (The lack of t in the second is a typo)
19:28 chromatic Don't care either way.
19:29 NotFound This will solve the current headerizer breakage and help prevent others.
19:29 particle if it breaks my release, i will break you. :)
19:29 chromatic Solving the headerizer breakage gets +1
19:29 particle indeed
19:29 Infinoid thought there already was a Parrot_Context typedef
19:30 NotFound particle: you must found me ;)
19:30 NotFound Infinoid: easily solvable
19:30 Infinoid oh, I see
19:30 Infinoid consolidation++
19:31 chromatic jhorwitz, your string segfault example in RT #60030 doesn't segfault for me.
19:31 particle even with --gc-debug?
19:32 jhorwitz i had the same issue on 64-bit
19:32 jhorwitz however, the "say" after the collect would print nothing or garbage
19:32 chromatic With --gc-debug, the last say prints nothing.
19:33 jhorwitz which is obviously not the right thing to print
19:33 chromatic True.
19:33 particle infinoid: can you check svn log -r 20750
19:34 particle t/src/compiler.t fails to link for me, with missing exported symbol PMCNULL
19:34 NotFound chromatic: same results for me
19:34 particle in 20750, you reverted my changes since thy broke darwin
19:34 particle but i'm not sure there's a fix for msvc again later
19:34 NotFound Why PMCNULL must be exported?
19:35 chromatic 'Foo::Bar' is a constant string though, stored in the bytecode.
19:35 particle NotFound: actually, i think linking needs to be fixed, not pmcnull exported
19:36 NotFound From the outside, there is a function to be used to check pmc nullness instead of the macro.
19:36 particle PMC_is_null is tha function
19:36 jhorwitz chromatic: i believe the string becomes "unconstanted" after substr cuz of COW.
19:36 jhorwitz in the parlance of our times
19:36 particle ok, i'm hungry. sorry for the misdirection.
19:37 particle uncontantinople
19:37 chromatic I have an idea then.
19:37 particle unconstantinople
19:37 particle where are all these darned bugs coming from!?! we need less code.
19:38 jhorwitz NotFound: the embed/extend API needs PMCNULL
19:38 chromatic From New Bugsterdam.
19:39 NotFound jhorwitz: why?
19:39 jhorwitz so i can assign a NULL PMC to things
19:39 jhorwitz example...
19:39 jhorwitz from mod_parrot: Parrot_PMC_set_pmc_intkey(interp, handler, 0, PMCNULL);
19:39 jhorwitz sets foo[0] to an null PMC.
19:39 NotFound jhorwitz: we can solve that with a function that returns a null pmc.
19:40 jhorwitz that would work too
19:40 particle NotFound: please update NEWS with any pirric &| examples info you want added
19:40 nopaste "chromatic" at 69.64.234.10 pasted "jhorwitz: Fix for in place substr with constant source string segfault" (14 lines) at http://nopaste.snit.ch/14349
19:40 jhorwitz oooooh, tasty tasty patch
19:41 NotFound particle: sorry, I completely forgot it.
19:41 particle np, you have time
19:41 chromatic Add another doit('Foo::Bar') call after the first, and you see that the source string isn't modified.
19:41 * jhorwitz tries it on his 2 platforms....
19:43 Infinoid particle: can do
19:45 * jhorwitz needs to svn up...
19:47 Infinoid particle: I take it r20767 didn't help?
19:48 jhorwitz chromatic: can you explain why that works in 50 words or less?
19:49 particle parrot had a cow, man.
19:49 * jhorwitz rolls eyes
19:49 purl You rolled a 11, jhorwitz
19:50 chromatic A string is a container.
19:50 Infinoid regarding r20750, declaring a local (uninitialized) PMCNULL variable may hide linker problems, but I'd prefer to actually solve them
19:50 chromatic When you free a string, you free its contents.
19:50 chromatic A constant string is a constant container.
19:51 chromatic Passing a constant string and modifying it in place reuses the container.
19:51 particle Infinoid: yes, you're correct with that approach
19:51 chromatic Making the string COW reuses the contents until they change, and modifies the container.
19:51 chromatic Freeing the modified string during GC frees only any copied contents.
19:52 chromatic Looks like ~60 words.  Sorry.
19:52 * jhorwitz segfaults
19:52 purl No whammies!
19:52 peepsalot joined #parrot
19:53 jhorwitz ah, looks like it works!  chromatic++
19:53 DietCoke segfaults works?
19:53 Infinoid the 50 word buffer overflowed
19:54 jhorwitz indeed
19:54 DietCoke ah.
19:54 jhorwitz subtle
19:55 chromatic This is probably a pattern we need to repeat in our code -- either always COW when we modify constants in place in ops, or COW constant strings passed as function arguments.
19:55 chromatic The latter seems like a more complete change.
19:55 chromatic ... but this one fixes a release semi-blocker, so commit it goes.
19:55 jhorwitz ...and there was much rejoicing.
19:58 chromatic Nice test case too.
19:59 jhorwitz 3 weeks in the making.  ;-)
19:59 chromatic Two line patch.
20:00 chromatic How nicely things work with simple PIR test cases!
20:00 dalek r32076 | chromatic++ | trunk:
20:00 dalek : [ops] Added a COW when attempting to modify a constant string with inplace
20:00 dalek : substr when passed as a parameter to a function.  This avoids strange GC
20:00 dalek : segfaults.  See RT #60030, reported by Jeff Horwitz.
20:00 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32076
20:01 chromatic Three more tickets to go until we hit 650.
20:03 DietCoke 60020 should be pretty easy.
20:08 DietCoke (also, there are about 5 tickets relating to Storable version.)
20:08 chromatic Like r32069?
20:08 chromatic Or was that just the Parrot side?
20:09 chromatic Just the Rakudo side.
20:10 DietCoke his was just rakudo
20:11 chromatic Testing my patch now.
20:14 Zaba_ joined #parrot
20:16 dalek r32077 | chromatic++ | trunk:
20:16 dalek : [lib] Removed coding standards tests from default test target (RT #60020).
20:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32077
20:18 dalek r32078 | julianalbo++ | trunk:
20:18 dalek : put pirric in NEWS
20:18 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32078
20:25 NotFound If we want to upset a lot of people, we can call this release: 'GOTO parrot' X-)
20:26 cotto I'm sure pirric will upset enough people as-is.
20:30 particle i just might have to call the release "Macaw-Palin"
20:31 NotFound What about 'Crisis? What Crisis?'
20:32 cotto "Parrot for President"
20:32 chromatic What should say_p output when given PMCNULL?
20:33 chromatic Stringy Undef?
20:33 DietCoke BOOM?
20:33 purl i think BOOM is the battery exploding.
20:33 Infinoid perl6 say(undef) prints "\n" I think
20:34 NotFound Warning! Big commit!
20:34 Infinoid Danger Will Robinson
20:34 purl use POE!  ohh... DANGER!
20:36 dalek r32079 | julianalbo++ | trunk:
20:36 dalek : typedef struct Parrot_Context Parrot_Context, replace parrot_context_t usages with Parrot_Context and update headerizing
20:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32079
20:37 pmichaud (say_p null)  seems like it ought to throw the same exception that most other opcodes give when doing something with a null PMC
20:38 chromatic I'm thinking the fix in typeof is more useful.
20:38 allison joined #parrot
20:38 particle how was the flight, alison?
20:38 particle allison, even
20:38 dalek r32080 | particle++ | trunk:
20:38 dalek : [RELEASE] NEWS updates
20:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32080
20:39 allison particle: mercifully brief
20:39 particle ok, i have zero tuits to fix that link problem, so i'm skipping those tests
20:39 allison I fixed the pheme problem too
20:39 allison it was a separator problem
20:40 allison PAST nodes now report their type as "PAST;Op" instead of "PAST::Op"
20:40 chromatic The Great Divorce
20:40 purl it has been said that the great divorce is good too :) CS Lewis is wonderful
20:40 pmichaud that's just what  typeof_s_p  returns :-)
20:42 nopaste "chromatic" at 69.64.234.10 pasted "Make typeof_p_p return Undef instead of PMCNULL (RT #59532)" (16 lines) at http://nopaste.snit.ch/14351
20:43 pmichaud chromatic: is that because   typeof_p_p  returns PMCNULL if run on a PMCNULL argument?
20:43 dalek r32081 | allison++ | trunk:
20:43 dalek : [CAGE] TGE now accepts classname strings that use either ';' or '::' as the separator.
20:43 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32081
20:44 pmichaud or is there some argument to typeof that is returning PMCNULL as its class?
20:44 chromatic typeof_p_p returns PMCNULL when run on a namespace with no associated class.
20:44 pmichaud ....shouldn't it be returning NameSpace ?
20:44 allison typeof just calls VTABLE_name
20:44 dalek r32082 | allison++ | trunk:
20:44 dalek : [CAGE] Update Pheme to use ';' separators for PAST node names (since that's
20:44 dalek : what the PAST classes use).
20:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32082
20:45 chromatic typeof_p_p just calls VTABLE_get_class
20:45 allison so, every PMC gets to decide how it'll report its string name
20:45 pmichaud $P0 = get_namespace ['Foo'];   $P1 = typeof $P0;   # I expect to get the NameSpace PMCProxy
20:45 pmichaud allison: we're talking about typeof_p_p, not typeof_s_p
20:45 allison I should say typeof_s_p
20:45 allison yes
20:45 chromatic $P0 = get_namespace
20:45 chromatic $P1 = typeof $P0
20:45 chromatic say $P1
20:45 chromatic *crash*
20:46 pmichaud I think that $P1 should end up being the NameSpace PMCProxy in that case
20:46 pmichaud having it return Undef is ... wrong.
20:46 allison is this an unrelated conversation I wandered into, or is it related to the Pheme problem?
20:47 pmichaud allison:  unrelated to pheme
20:47 allison ok
20:47 dalek r32083 | particle++ | trunk:
20:47 dalek : [t] skip tests which fail to link with msvc -- fix these after release!
20:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32083
20:47 chromatic RT #59532
20:47 pmichaud I'm referring to chromatic's nopaste
20:47 pmichaud it's causing typeof_p_p to return Undef instead of PMCNULL
20:47 pmichaud I see two issues there.
20:48 pmichaud First, say_p  on PMCNULL shouldn't cause "boom" -- it should throw a "Null PMC exception" like most other operations
20:48 chromatic I'm comfortable with that.
20:48 allison oh, yeah, we've been changing all those Undef returns to PMCNULL wherever possible
20:48 pmichaud secondly, typeof $P0 should always return something that is class-like.
20:48 pmichaud (unless overridden, of course.)
20:48 allison pmichaud: yes, Null PMC exception is right
20:49 particle i hate fulltest
20:49 Theory joined #parrot
20:49 NotFound A guideline on some doc about returning PMCNULL, NULL, or Undef will be helpful.
20:49 chromatic I'll put the Null PMC exception in place there and close the segfault ticket.
20:50 zostay joined #parrot
20:50 DietCoke I don't think anything "user facing" in parrot should be returning NULL.
20:50 pmichaud NotFound:  the basic guideline I use is:   PMCNULL == "doesn't exist",   Undef == "exists but isn't defined"
20:50 pmichaud DietCoke: hash['no_such'key']   returns PMCNULL
20:51 DietCoke PMCNULL != NULL
20:51 pmichaud I agree there, then.
20:51 pmichaud sorry, I misread.
20:51 DietCoke I don't think anything "user facing" in parrot should be returning C's NULL.
20:51 pmichaud I agree.
20:51 NotFound DietCoke: mainly, no function whose result is assigned to register must never return NULL.
20:51 allison no, Undef is Perl 6
20:51 purl okay, allison.
20:52 allison PMCNULL is Parrot
20:52 pmichaud Perl 6 has no Undef
20:52 allison returning Undef as an 'error' value is Perl 6 semantics
20:52 DietCoke should we at some point commit a run of 'make headerizer' ?
20:52 allison Parrot has an Undef, but it's only provided as a utility to various HLLs
20:52 pmichaud Perl 6 returns Failure as an error
20:53 pmichaud Perl 6 doesn't have an C<Undef> class.
20:53 NotFound DietCoke: I've done it right now
20:53 allison ah, so now we have legacy useless code
20:53 pmichaud oh, it gets used
20:53 DietCoke ah, so you have.
20:53 pmichaud PCT makes use of Parrot's Undef type because it can't rely on having a Perl 6 runtime.
20:53 allison okay, in the old days, Parrot returned Undef because Perl 6 wanted it
20:53 pmichaud So yes, Undef then becomes perl-like semantics
20:54 NotFound So we must deprecate the Undef pmc?
20:54 allison fair enough
20:54 allison NotFound: no
20:54 pmichaud PCT and PGE depend on Undef
20:54 pmichaud I just want to be clear (because it's a common point of confusion) that Perl 6 itself doesn't have a "Undef" type
20:54 allison NotFound: we're just changing core types like Array and Hash to return PMCNULL instead of Undef
20:54 allison (have changed many)
20:55 pmichaud We still need some sort of PMC in Parrot to represent undefined values
20:55 allison but, Undef is provided for HLLs
20:55 allison and for tools
20:55 allison though, if Perl 6 has abandoned the name "Undef", maybe we should use a more generic name for the Parrot type
20:55 allison because that name came straight from the old Perl 6 specs
20:55 TimToady the most generic undefined type in Perl 6 is "Object"
20:56 pmichaud "Undef" works well for me in Parrot
20:56 allison well, the relevant type here would be "Failure"
20:56 allison but, we don't really want that
20:56 chromatic "Teenager"
20:56 chromatic Full of potential, but practically useless.
20:57 allison pmichaud: It likely wouldn't make much difference to you if it was called "Undefined" instead, though
20:57 pmichaud allison: correct, other than it's yet-another-name to have to remember.
20:57 allison pmichaud: or "Empty", or whatever
20:58 pmichaud at least "Undef" roughly correspond's to Perl 5's  "undef"
20:58 chromatic "CPD"?
20:58 DietCoke allison: is that PAST::Op -> Past;Op change only if you're using some default PAST object?
20:58 allison pmichaud: yeah, but we're supporting legacy specs that never saw the light of day, seems like a silly burden to put on future language implementors
20:58 NotFound Maybe we can just use the Default pmc.
20:58 pmichaud but you're right, it doesn't make much difference to me
20:59 pmichaud DietCoke: when ['PAST::Op'] changed to ['PAST';'Op'], the way that Parrot reports the typename for PAST::Op objects changed from "PAST::Op" to "PAST;Op"
20:59 allison DietCoke: it's basically whatever the output of 'typeof' is on the node you're transforming
20:59 allison DietCoke: so you can quickly check if you need to use "PAST;Op" or "PAST::Op"
21:00 allison NotFound: Default might work, though currently it's "abstract" never instantiated
21:01 dalek r32084 | chromatic++ | trunk:
21:01 dalek : [ops] Added PMCNULL exception to say_p op to avoid segfaults when trying to
21:01 dalek : stringify PMCNULL (RT #59532, reported by I Sop).
21:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32084
21:01 allison NotFound: the scalar PMC might also work
21:01 particle1 joined #parrot
21:02 allison NotFound: but "Undefined" is more immediately obvious than "Scalar"
21:02 * DietCoke rants about "Null pmc access in invoke()" with lack of stacktrace.
21:02 chromatic Pheme confirmed to work as of r32084.
21:02 NotFound Yes, for code and error messages a descriptive name is better.
21:03 allison NotFound: Also possible is creating an "Error" type, which could also contain an error message (explaining the reason for the Null return value), and allowing easy promotion to an actual exception in certain contexts or pragmas
21:03 NotFound DietCoke: if you want a stack trace, add an exception handler with hcf inside.
21:04 DietCoke a -parrot- stack trace.
21:04 allison uncaught fatal exceptions should spit out a stack trace
21:04 NotFound We have an opcode for that, if I remember well.
21:04 DietCoke unfortunately, this is a rethrow'n one.
21:05 DietCoke (If it's where I think it is. which of course, i don't know at the moment.)
21:06 pmichaud chromatic: did you happen to catch my addition to RT #59778?  I'm thinking that ticket should move to the parrot queue because it's not really a rakudo issue.
21:07 chromatic pmichaud, I saw that.  You may be right.  It could be that longjmp confuses gdb terribly.
21:07 pmichaud okay, just wanted to make sure you saw it.  No rush for a fix from here.  :-)
21:08 chromatic It might also be the resumable exception problem as well.
21:08 chromatic 42 new + 609 open = 651
21:08 pmichaud yes, I know moving it to the queue would work in the wrong direction.  Maybe I need to close a parrot ticket before I move it :-P
21:08 NotFound allison: sounds good, like Undef except that throws an exception with a descriptive message instead of "Null pmc access" in any usage other than check for defined
21:08 nopaste "Coke" at 72.228.52.192 pasted "shouldn't rethrow show the full stacktrace here?" (18 lines) at http://nopaste.snit.ch/14352
21:09 particle1 allison: tene's question from earlier was about class registration
21:09 particle perl6;Foo;Bar and python;Foo;Bar both register as Foo;Bar
21:09 DietCoke that is showing that the error occurred at the rethrow, making that just a throw.
21:09 allison yes, that is a bug in the current registry code
21:09 pmichaud tene's question is essentially RT #43419.
21:10 allison it's one of the reasons we started ripping out the current registry
21:10 allison ah, yeah, I looked at that ticket before, should have left a note
21:11 pmichaud it's also a big reason why Rakudo does things like "Perl6Object", "Perl6Array", "Perl6Scalar", etc. -- because the non-Perl6 names are already taken by the class registry for 'parrot'.
21:11 allison which is silly, since that's the whole reason for having HLL namespaces
21:11 pmichaud correct.  it's also one of the reasons why I hadn't been pushing hard to get .HLL to work in Rakudo
21:12 pmichaud (we now have lots of languages using PCT, though, and so we need .HLL to work so we can avoid global symbol name conflicts for things like "infix:+"
21:12 particle yep
21:13 * Infinoid does another run of make tests
21:13 NotFound There is a note in oo.c:fail_if_type_exists that says: "The global type registry will go away eventually"
21:14 allison yes, that's the intention
21:14 allison but, it's longer away than expected
21:14 pmichaud (I don't know, I expect it to be a very long ways away.  You're saying it's longer than that?  ;-)
21:14 allison the quick fix (and probably also the right fix as long as we have the type registry), is to prefix all registered types with their HLL namespace
21:14 NotFound Many, many moons ;)
21:15 pmichaud OOC, would the quick fix also end up affecting   typeof_s_p ?
21:15 allison well, the plan was to rip it out in the OO branch
21:15 allison pmichaud: no, the type registry is all through a separate interface
21:15 allison would have no effect on what's reported by typeof
21:16 pmichaud allison: okay, I'm a bit confused there, but no problem.   Would    $P0 = get_class "Integer"   then need to become   $P0 = get_class "parrot;Integer"   ?
21:16 allison no
21:16 allison the registry is a hash internal to Parrot
21:16 allison it only keeps an association of class name to type id
21:17 allison get_class searches the namespace, not the registry
21:17 pmichaud ...it does?
21:17 allison yup
21:17 pmichaud hrm.
21:18 allison so maybe there's another problem here, and that is code that's searching from the HLL root namespace, instead of the true root namespace?
21:18 allison or vice versa
21:18 nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches wrong namespace?" (10 lines) at http://nopaste.snit.ch/14353
21:18 allison but, for the "already registered" problem, it's just the registry
21:19 allison pmichaud: you would expect that to say "Perl6Integer" instead?
21:20 pmichaud I would expect it to say "class Integer not found" or return PMCNULL
21:20 allison why?
21:20 pmichaud because there is no "Integer" class defined in the perl6 HLL namespace
21:20 pmichaud i.e., there's no "Integer" namespace in the perl6 HLL
21:21 allison okay, so you want no access to core parrot types when operating within an HLL
21:21 allison that does make sense
21:21 pmichaud no, I'm simply questioning whether get_class actually searches namespaces
21:21 allison though it's likely to seriously disrupt some code
21:21 pmichaud I think it currently looks things up in the registery
21:21 pmichaud I'm not advocating for or against a position yet -- simply seeking to understand what is currently implemented
21:22 nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches registry? -- another example" (23 lines) at http://nopaste.snit.ch/14354
21:23 allison the get_class opcode calls 'Parrot_oo_get_class_str', which searches the namespace
21:23 pmichaud I don't quite understand why get_class 'Integer' works then.
21:24 DietCoke perhaps it's a fallback?
21:24 DietCoke (the result of a...)
21:24 TiMBuS joined #parrot
21:24 allison It has a default fall-back to create a PMCProxy by type number, if nothing is found in the namespace
21:24 allison that does use the registry
21:24 pmichaud okay, that explains it then.
21:24 pmichaud I knew the registry had to be in use *somewhere*
21:25 * DietCoke throws his rethrow question to the list.
21:25 DietCoke Hopefully I'll be able to get tcl working with the tge updates post release. There's no status information about partcl in the repo anymore, so nothing to update pre-release.
21:26 pmichaud again, I'm not advocating for a particular design -- I'll just be curious to know what the final answer will be.  (I suspect the answer belongs in RT #43419.)
21:27 pmichaud also, I think it's more than just "create a PMCProxy by type number", because it works even for non-PMCProxy things
21:27 pmichaud (nopaste coming up)
21:28 nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches registry -- example #3 for non-PMCProxy" (23 lines) at http://nopaste.snit.ch/14355
21:29 pmichaud or it's creating a PMCProxy for the non-PMC type
21:30 allison that's just searching the namespace
21:30 allison you mean 'MyFoo'?
21:30 pmichaud yes
21:30 pmichaud in example #3 it's searching the wrong namespace, then.
21:30 pmichaud because   the get_class is being run from the 'parrot' namespace, while 'MyFoo' is in the 'perl6' namespace.
21:31 pmichaud what's really happening is that it's not finding ['parrot';'MyFoo'], so it's falling back to the type registry.
21:31 allison would have to look at 'Parrot_get_namespace_keyed_str' to see if it's falling back
21:31 allison but, if it is falling back to the registry there, it's a bug
21:32 pmichaud I'm reasonably sertain that ['parrot';'MyFoo'] doesn't exist.
21:32 pmichaud *certain
21:32 allison a big bug, but easy to fix
21:32 allison I suspect it's a bug that a lot of code is relying on too
21:32 pmichaud probably not so much
21:32 pmichaud there hasn't been a lot of HLL usage yet, for precisely this reason.
21:32 pmichaud afaik only Tcl is making heavy use of .HLL as yet
21:33 allison yeah, it is fundamentally broken
21:33 pmichaud and as I said, I've been holding off on using .HLL in hopes that this would somehow get fixed
21:33 allison well, the registry naming is easy to fix
21:33 pmichaud (because I didn't want to be introducing a lot of broken code.)
21:33 pmichaud (or, a lot of code that would break when we tried to fix it.)
21:34 pmichaud fortunately most tools making use of P6object won't be affected, because they use protoobjects for their class manipulations and not stringified names.
21:34 allison (the latter is likely, unfortunately)
21:34 pmichaud we pretty much avoid making use of class string names in PCT
21:34 allison using class objects is always preferred to using string names or type numbers
21:34 pmichaud time for dinner here -- bbiah
21:35 particle time for make fulltest
21:35 mberends joined #parrot
21:35 particle ...which has failures...
21:36 Whiteknight joined #parrot
21:36 particle Whiteknight: update news with any you might have, especially regarding the book/docs
21:38 allison could we smolder 'make fulltest' too?
21:38 particle i don't know... it's multiple harnesses
21:40 Whiteknight Okay, let me look at it now
21:40 Infinoid make testC fails a bunch of stuff for me
21:41 Infinoid on both 32-bit and 64-bit linux
21:44 Whiteknight done
21:46 * allison off to pick up rental car
21:49 dalek r32085 | Whiteknight++ | trunk:
21:49 dalek : [NEWS] Update NEWS with some information about what's changed in /docs/books
21:49 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32085
22:00 GeJ q
22:01 GeJ my mistake
22:01 GeJ Good morning all.
22:01 Infinoid hi GeJ
22:01 GeJ Anyone familiar with stam_start, stm_wait and friends?
22:04 GeJ Heya Infinoid
22:04 purl Infinoid is Mark Glines <mailto:mark@glines.org>
22:04 GeJ thanks hun'
22:06 Infinoid I'm not familar with them, sorry
22:12 particle PLATFORMS updates anybody?
22:16 GeJ could it be possible to SKIP t/stm/basic_mt_4.pir?
22:17 cognominal joined #parrot
22:17 dalek r32086 | pmichaud++ | trunk:
22:17 dalek : [rakudo]: spectest-progress.csv update: 204 files, 4407 passing, 13 failing
22:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32086
22:17 dalek r32087 | pmichaud++ | trunk:
22:17 dalek : [NEWS]:  rakudo, pct, pge updates
22:17 particle yes, but it would be best if it could be narrowed down to platform/arch
22:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32087
22:17 GeJ it's already skipped on darwin, and it is know to hang on cygwin (#59790), freebsd (self) and --I suspect-- randomly on linux as well ( http://buildbot.eigenstate.net:8040/fc6​-x86_64-trunk/builds/241/step-shell_3/0 )
22:20 pmichaud particle:  I think I'm done with my NEWS and spectest-progress.csv updates.
22:20 particle thanks
22:21 pmichaud I'm a little concerned about the 13 failing spectests in rakudo, though -- looking to see if those were just a timing issue or if they're still present.
22:21 particle pmichaud: i haven't done any language testing yet
22:21 pmichaud (timing issue == failing at 00:00 CDT but fixed shortly thereafter)
22:21 particle i wonder if #59788 can be fixed quickly, like **=
22:22 pmichaud that's a parrot bug
22:22 particle ah :(
22:22 pmichaud it has to do with the mmd merge, I think.
22:22 particle yep
22:22 Limbic_Region joined #parrot
22:23 Infinoid GeJ: heh, hung here on linux on the second try.
22:25 GeJ Infinoid: It hangs on my freebsd box every time.
22:25 GeJ I tried to look at it, but
22:25 GeJ 1) my C-fu is close to nil
22:25 GeJ 2) I got lost trying to understand the code
22:26 GeJ 3) When I wanted to come here for tuits, people were already busy with some bugfixing, so I hesitated to interupt.
22:26 Infinoid its a thread race
22:26 GeJ I believe so.
22:27 Infinoid is there a ticket open for it?  if not, opening one would be a good idea
22:27 Infinoid in the meantime, skipping the test seems appropriate to me
22:27 GeJ there is one for cygwin
22:27 GeJ #59790
22:27 GeJ I think it appeared with mmd merge.
22:28 particle Infinoid: can you mark it skipped?
22:28 Infinoid will do
22:28 Infinoid GeJ: thanks.  can you can add a followup to that with your own test results?
22:29 Infinoid and I'll add a note about the skip, and gdb output
22:29 GeJ Infinoid: sure, will do.
22:31 Infinoid heh, we aren't testing threads much.
22:31 Infinoid after my change:
22:31 Infinoid 1..4
22:31 Infinoid ok 1 - wait (simple)
22:31 Infinoid ok 2 # skip Intermittent failures on all platforms
22:31 Infinoid ok 3 # skip Intermittent failures on all platforms
22:31 Infinoid ok 4 # skip Intermittent failures on several platforms
22:34 GeJ yup
22:34 Infinoid particle: done, r32088
22:34 dalek r32088 | infinoid++ | trunk:
22:34 dalek : [t] Skip t/stm/basic_mt.t test #4 for now;
22:34 dalek : it hangs on several platforms (cygwin, darwin, freebsd, and linux).
22:34 dalek : This issue is tracked as RT #59790.
22:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32088
22:36 particle thanks. unfortunately, this release is going out very dirty.
22:36 particle i can't stop smokers from reporting failures, there's just too many
22:36 pmichaud I think I found the 13 failing tests -- they may be due to a misconfig on my machine.
22:37 pmichaud I'm regenerating spectest-progress.csv (at least the latest entry) now
22:37 Infinoid its ok, X.Y.0 releases have never been known for their stability :)
22:38 dalek Krishna Sethuraman | Parrot Development on Windows:
22:38 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?parrot_development_on_windows
22:38 allison joined #parrot
22:41 particle oh, gimme a break! t/pharness/01-default_tests.t fails due to removing codetest
22:42 Infinoid I've taken ownership of #59790 for now.  compared to the memory management nightmares I've been flailing helplessly against for the last week, a thread race seems pretty trivial
22:43 bacek_ joined #parrot
22:44 Infinoid (famous last words, probably.)
22:47 GeJ :-D
22:47 GeJ I'll be available for any patch-testing if required
22:47 GeJ now, if I could only find my bitcard credentials...
22:48 Infinoid so many sites, so little time
22:49 * chromatic wishes the repository browser actually worked
22:50 * GeJ svn-sync every 2 hours and feeds a local trac setup.
22:50 DietCoke (smolder multiple harness) just smolder each one with a different tag.
22:51 dalek r32089 | particle++ | trunk:
22:51 dalek : [t] skip config tests i don't have time to understand how to modify properly before release of 0.8.0
22:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32089
22:51 GeJ works fine, except when commits use the #\d+ notation that trac interprets as local tickets.
22:53 Infinoid like my last one did?
22:53 pmichaud gotta run -- bbl
22:53 dalek r32090 | pmichaud++ | trunk:
22:53 dalek : [rakudo]:  spectest-progress.csv correction: 204 files, 4413 passing, 0 failing
22:53 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32090
22:54 DietCoke seen kid51?
22:54 purl kid51 was last seen on #parrot 3 days, 5 hours, 46 minutes and 48 seconds ago, saying: The smolder report at r31992 was from me, and I know that I did not have Perl 6 build at the time that smolder report was run ('cause kid51 doesn't work like that!)  [Oct 18 17:07:37 2008]
23:10 dalek r32091 | particle++ | trunk:
23:10 dalek : [RELEASE] updated release info
23:10 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32091
23:11 dalek r32092 | particle++ | RELEASE_0_8_0:
23:11 dalek : tagged release 0.8.0
23:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32092
23:13 chromatic joined #parrot
23:15 particle ok, it's on cpan. now i need a name....
23:16 Infinoid Smoking Crater
23:17 daxelrod joined #parrot
23:18 chromatic Sheesh, I just fixed the make testC failures.
23:18 chromatic Or at least worked around them.
23:18 Infinoid actually, Octarine sounded pretty good
23:19 particle i found a name
23:20 Whiteknight ???
23:21 chromatic Did you already upload it?
23:21 particle yes, i did
23:22 particle i need to be done soon, seattle.pm beckons
23:22 chromatic Let's hope no one wants to play with CGP then with the release version!
23:22 particle i'll buy you a hot beverage if we get any unsolicited error reports for CGP this month
23:24 chromatic Seems a safe bet.
23:24 chromatic I'm not sure we can fix the code without the calling conventions branch merging anyway.
23:26 DietCoke how can you upload a version before deciding on the name?
23:26 dalek r32093 | particle++ | trunk:
23:26 dalek : [RELEASE] are we there yet? almost.
23:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32093
23:37 particle i run into this every time... how do i fix perms on Parrot::Test::C99AST?
23:38 particle pause perms
23:38 GeJ All tests successful, 15 tests and 610 subtests skipped.
23:39 GeJ Thanks everyone.
23:39 chromatic Is it an unauthorized release?
23:39 chromatic Generally the previous uploader has to disclaim ownership of all of those first-come/first-served modules.
23:39 dalek r32094 | chromatic++ | trunk:
23:39 dalek : [src] Temporarily disabled CGP when re-entering runops due to MMD calls.  See
23:39 dalek : RT #60048.
23:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32094
23:40 particle ok, that's pmic
23:40 particle pmichaud: Parrot::Test::C99AST needs pause fixing
23:40 particle then i can request reindex

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

Parrot | source cross referenced