Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
Austin_Hastings Anyone know whether or not it's possible to use function pointers/references/call-via-scalar-string in NQP? If so, how? 00:36
pmichaud Austin_Hastings: It's not directly possible at the moment, but it's something we could easily add. 01:39
Austin_Hastings Pmichaud: Thanks, but I'm just finishing the elsif chain... :(
02:28 whoppix joined 02:35 janus joined 03:48 Austin_Hastings left 04:03 Theory joined 04:22 Andy joined 06:08 flh joined 06:23 iblechbot joined 06:28 cotto joined
dalek TT #808 created by flh++: VIM syntax file: fix parsing of quoted ".end" 06:56
07:03 Zak joined 07:19 szabgab joined
mikehh All tests PASS (pre/post config, smolder, fulltest) at r39872 - Ubuntu 9.04 amd64 08:02
09:05 barney joined 10:08 janus joined 10:09 preflex joined 10:31 bacek joined 10:45 masak joined
dalek rrot: r39873 | fperrad++ | trunk/include/parrot/thr_windows.h:
[build] MinGW gcc 4.4.0

which defines struct timespec with a guard named HAVE_STRUCT_TIMESPEC. So, rename the guard in thr_windows.h		 11:00
11:00 flh joined
12:22 iblechbot joined
dalek TT #771 closed by bacek++: [bug] Duplicate identifier in Test;More.is_deeply 12:23
rrot: r39874 | bacek++ | trunk/runtime/parrot/library/Test/More.pir:
[cage] Rename duplicated C<left> and C<right> variables in Test/More.pir
12:28 kid51 joined 12:38 MoC joined 13:01 Whiteknight joined 13:02 skids joined
flh ping kid51? 13:07
purl I can't find kid51? in the DNS.
flh kid51, did you run "make vim-install" in editor/ after applying the patch? 13:08
kid51 No, I did not. 13:09
flh vim uses the ~/.vim/syntax/pir.vim file, which is only updated by "make vim-install" 13:10
kid51 Okay, I was unaware of that.
dalek rrot: r39875 | jkeenan++ | trunk/editor/pir_vim.in:
Enable Vim to correctly handle quoted string ".end" in subroutines. Cf. trac.parrot.org/parrot/ticket/808; applying patch submitted by flh++.
 13:16
TT #808 closed by jkeenan++: VIM syntax file: fix parsing of quoted ".end" 13:20
13:34 bacek joined
PacoLinux NotFound: en el tercer parrafo de docs/book/draft/ch06_nqp.pod hay un error - NQP represets almost - <-- represents :: lo puedes cambiar ? 13:35
13:36 riffraff joined
PacoLinux wrong channel :) 13:36
MoC question: does building parrot trunk rev. 39873 or greater work on linux? 13:43
13:44 Theory_ joined
kid51 MoC: works for me 13:44
MoC hrm... because I thought that Linux explicitly uses _STRUCT_TIMESPEC to avoid redefinition... 13:45
and rev. 39873 changed it to HAVE_, but if it still works, nevermind
dalek rrot: r39876 | jkeenan++ | trunk/docs/book/draft/ch06_nqp.pod:
Correct spelling error noted by PacoLinux.
 13:47
kid51 MoC: While it has not affected my subsequent builds on Linux, you should feel free to post a question about that on list to fperrad (who is rarely on #parrot). 13:49
MoC: Since the commit message mentions MinGW, I suspect this change was for Win32 users' benefit. 13:50
But I don't know what other side effects it might have.
MoC yep, I already planned to do that, in case of possible future errors
13:50 ruoso joined
kid51 PacoLinux: Lo cambi�. 13:50
PacoLinux kid51: gracias :) 13:51
MoC "MoC: Since the commit message mentions MinGW, I suspect this change was for Win32 users' benefit." <-- yep. Before that commit I had to edit pthread.h itself. 13:52
kid51 MoC: Am now running Smolder test. Will report any problems related to 39873. 13:53
dalek rrot: r39877 | fperrad++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc]

but PARROT_DYNEXT_EXPORT
13:58 Whiteknight joined
MoC kid51: Nevermind about that change breaking something on a non-windows OS. I overlooked that he only changed thr_windows.h, which appears to be only included on windows hosts. I will however still write a mail to the list, since I think that the issue is with pthread.h, because other software also uses _STRUCT_TIMESPEC instead of HAVE_* 13:59
kid51 MoC: good analysis; please post 14:05
... post to list
... or create TT, if appropriate 14:06
MoC I suppose a post to the mailing list is sufficient
dalek rrot: r39878 | fperrad++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc] improve layout
 14:07
kid51 Confirmed by successful Smolder test smolder.plusthree.com/app/public_pr...ails/24479 14:10
MoC Ok. Mail sent. 14:26
Whiteknight thinks he might have solved the GC heisenbug 15:00
or, at least one part of it
davidfetter but only if the isotope has decayed?
15:01 Andy joined
kid51 GC heisenbug => Unfreed memory disappears if you look at it, but then immediately reappears. 15:03
Infinoid Whiteknight++ 15:05
Whiteknight commit coming now, you're going to like this one Infinoid
a real bear to track down 15:06
Infinoid I've put in some work adding valgrind annotations but it didn't really catch much. Glad to see someone else has been making more progress :)
I'd like to add some padding between PMC structures within the arenas, and stagger reallocation so that (for instance) if PMC is 48 bytes in a 64-byte structure, the first time it's allocated at offset 0, the next time at offset 8, the next time at offset 16, and throw up some red zones to catch old pointers 15:07
48 bytes of structure in a 64-byte zone, I mean 15:08
Whiteknight that's not a bad idea
Infinoid But I have a question.
dalek rrot: r39879 | whiteknight++ | trunk/src/oo.c:
[gc] fix one gc heisenbug, although apparently this isn't the only one. When cloning an object, we get into situations where we mark the object before it's ATTRs struct is initialized. This causes whatever garbage was in that allocated memory to be passed to the GC for marking, and hilarity ensues. Zero out the struct here to ensure we have NULL values in the struct and then Parrot_Object_mark won't try to mark the NULL pointers
Whiteknight a little wasteful, so we should be able to turn that feature off
what's your question?
Infinoid Of all the fields of the PMC structure, are the first ones most likely to be accessed, or the last ones?
That will determine whether we should precess forward or backward
Whiteknight let me look at it again
Infinoid There's too much smoke and mirrors in the pobj/pmc structure definition, I'm still not really sure how they are built 15:09
I was wanting to look again, it's just an idea that occurred to me in the shower
Whiteknight flags, vtable, and pmc_ext are the most frequently used, I think
I don't think data is used at all
or, maybe it is and I never noticed
15:10 hudnix_ joined
jonathan Whiteknight++ # nice work! 15:10
Infinoid Whiteknight++ indeed
So I haven't made a lot of progress with valgrind, though its memcheck.h API does give us some interesting possibilities 15:11
I can explicitly tell it that all the fields in the PMC structure are "undefined" when it's pulled from the free list, for example
and I can make them unreachable when it's put back on the free list 15:12
The problem is, when it's reallocated, that doesn't help much, hence the offset allocation idea
hmm. I can also put an implicit read barrier into the PMC_* macros to check whether the PMC was reallocated with a different offset 15:15
... or, on x86-64 at least, we can build a serial number or some kind of cookie into the highest bits of the pointer value itself
assuming nothing accesses them without going through those macros... 15:16
Whiteknight nopaste? 15:21
purl nopaste is, like, at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
nopaste "Whiteknight" at 69.248.162.161 pasted "new segfault, happens in P6Invocation" (45 lines) at nopaste.snit.ch/17110 15:22
Whiteknight jonathan: take a look at that backtrace please
I'll dig into it now, but you probably know the code better then I do
jonathan Whiteknight: Ah, that's new-ish code, that hasn't had a bug found in it yet. It's probably about time. ;-) 15:25
oh, it crashes inside the multi dispatcher.
Interesting.
Whiteknight the pos_args parameter has ->vtable == 0xdeadbeef
so it's been prematurely collected at some point 15:26
jonathan Ah
This works with -G?
Whiteknight it's that same incantation that bacek sent me
jonathan I can tell you for sure that pos_args only ever exists on the stack.
Whiteknight I don't know if -G fixes it
here's the command I used: gdb --args ../../parrot -R gcdebug --gc-debug ./perl6.pbc t/spec/S04-statements/do.rakudo 15:27
so it might disappear with -G, or even if we omit --gc-debug
jonathan Aye, but it still shouldn't be getting collected.
Whiteknight true
jonathan PMC *pos_args, *named_args; 15:28
get_args(interp, &pos_args, &named_args);
get_args should be setting those.
pmichaud re: r39879 (Whiteknight++) --- shouldn't mem_allocate_typed zero out the pointers and fields by default?
jonathan I did extensively refactor that code recently, let me sanity check.
Whiteknight pmichaud: I don't know what it *should* do, but I can tell you what it isn't doing 15:29
jonathan pmichaud: That's mem_allocate_zeroed_typed IIRC.
Or similar.
purl rumour has it similar is happening in Rakudo
pmichaud then perhaps we should be calling mem_allocate_zeroed_typed
Whiteknight does that function even exist?
pmichaud I'm wondering when it would be appropriate to call mem_allocate_typed
Infinoid yes, it exists
Whiteknight I don't see it in src/gc/alloc_memory.c 15:30
Infinoid memory.h:#define mem_allocate_zeroed_typed(type) (type *)mem_sys_allocate_zeroed(sizeof (type))
jonathan Whiteknight: In get_args it does
PMC * const arg_list = pmc_new(interp, enum_class_ResizablePMCArray);
PMC * const arg_hash = pmc_new(interp, enum_class_Hash);
And later
*pos_args = arg_list;
*named_args = arg_hash;
Where pos_args and named_args are pointes to PMC pointers.
(e.g. to set them in the caller)
So I'm pretty sure they're always on the stack. 15:31
pmichaud ...what keeps them from being gc'ed?
jonathan Anyway, the relevant code is all inside perl6multisub.pmc
Not p6invocation.pmc
pmichaud: The GC walks the stack. In theory.
Whiteknight ah nevermind, it's defined in a #define
pmichaud it walks the C stack?
jonathan Right.
Whiteknight pmichaud: yes
pmichaud interesting. 15:32
Whiteknight you can see the (horrible) code for it in src/gc/system.c
I would like nothing more then to kill it in a fire, but it's there
jonathan Well, we kinda need to walk it, or we miss things.
pmichaud right, makes sense.
jonathan But somehow we're missing pos_args here, it seems. :-/ 15:33
That or some other bug.
pmichaud it's not on the c stack.
Whiteknight jonathan: where is that code you mentioned?
perl6multisub.pmc?
jonathan src/pmc/perl6multisub.pmc
pmichaud well, I guess it must be, but it's not an argument.
jonathan pmichaud: Huh?
pmichaud: OK, but it's a local.
pmichaud right. 15:34
jonathan Those must be pushed on the stack at some point, right?
pmichaud yes, I think so.
jonathan Also
Whiteknight jonathan: pos_args here is a PMC**, the GC can't track those
jonathan At the point we crash, it has been passed as an argument to do_dispatch.
Whiteknight: OK, but notice that
a) Inside get_args it's on the stack as a direct PMC * 15:35
Whiteknight jonathan: yes, but the PMC is getting collected before the call to do_dispatch
jonathan Ah.
Looking at what else gets allocated 15:36
I see
PMC * const arg_hash = pmc_new(interp, enum_class_Hash);
The PMC right after it.
oh, if we're boxing, potentially various others too in fact.
Whiteknight: Maybe set a breakpoint at the end of get_args and see if we're collected at that point? 15:37
Whiteknight doing that right now...
pmichaud here's a thought: 15:40
nm
Whiteknight okay, I put in a bunch of asserts, building now 15:44
pmichaud where is "get_all_candidates_with_cur_args" called?
jonathan from p6invocation iirc
yes 15:45
line 76
All part of the fun interplay betwene the dispatchers. :-)
pmichaud ah, I see.
The *.pmc code doesn't appear to be following the parrot coding style -- that was throwing me a bit
jonathan In what way? 15:46
Though it's out of the Parrot repo, so it doesn't have to.
It's not deliberately different though.
pmichaud in Parrot I'm used to seeing 15:47
PMC *
get_all_candidates_with_cur_args(...)
instead of
Whiteknight what do the two different dispatchers do?
pmichaud PMC *get_all_candidates_with_cur_args
jonathan One does method dispatch, the other does multi dispatch.
pmichaud: Ah, OK. 15:48
Whiteknight ./perl6multisub.pmc:825: failed assertion 'pos_args->vtable != 0xdeadbeef'
pmichaud also, the p6invocation.pmc makes an extern reference to get_all_candidates.... but doesn't explicitly label it "extern" (and I missed the semi at the end)
so it looked to me like it was re-defining the function somehow.
jonathan Ah, it wants extern?
pmichaud (when I read it from a grep)
Whiteknight I added the same assertion at the start of find_many_candidates_with_arg_list, and that one passed 15:49
and the assertion directly before do_dispatch fails
so somewhere inside find_many_candidates_with_arg_list, pos_args is getting collected
jonathan Which is very odd given 15:50
PMC *pos_args
is int he parameter list
And therefore surely on the stack?
pmichaud I was wondering if "return find_many_candidates_with_arg_list(...)" was being optimized somehow such that *pos_args isn't on the stack.
i.e., if gcc thinks it's a tailcall
Whiteknight I would hope so, unless the compiler did some creepy optimization magic 15:51
jonathan That'd be some really creepy magic.
Whiteknight that's why I dislike stackwalking GC stuff, because stackwalking + optimizing c compiler = horrible
pmichaud Whiteknight: what happens if you split the return statement into two statements? 15:52
(ooc)
Whiteknight no idea, I'm running another test right now 15:53
jonathan Whiteknight: I know that
if (cache)
results = Parrot_mmd_cache_lookup_by_values(interp, cache, "", pos_args);
Certainly allocates a STRING.
Whiteknight (and these tests are painfully slow with the --gc-debug flag)
jonathan Also, if we run it, sort_candidates will allocate an absolute LOAD of stuff.
Whiteknight okay, pos_args is collected during this call:
candidates = sort_candidates(interp, unsorted, &proto);
jonathan So there's easily scope for allocation.
Ah
Whiteknight directly before, it's alive, directly after it's been collected 15:54
jonathan I'm just curious why it's not on the stack and anchored. :-/
But yes, sort_candidates will allocate PMCs for certain.
Whiteknight who knows? stack gremlins?
pmichaud I'd like to eliminate the (potential) tailcall and see what happens.
jonathan Worth a try for sure.
pmichaud (I agree it's a very long shot.) 15:55
jonathan Whiteknight: One tidbit though this still is no more clue to me: we do run PIR code during the course of sort_candidates. 15:56
Whiteknight that is interesting 15:57
Ahah! I think that might be the aswer
answer
jonathan We don't by any chance modify the stack top pointer?
Whiteknight when we recurse into a new runloop, I think we set a new lo_val_ptr on the stack, and don't mark anything on the stack above that 15:58
pmichaud I bet we do.
Whiteknight so anything that's not anchored when we recurse runloops falls off the face of the earth
jonathan oh arse
pmichaud that sounds like a serious problem.
jonathan That'd do it
That'd completely do it.
pmichaud given Parrot's design, I'm not sure that we can ever be certain that everything is anchored prior to recursing into a new runloop 15:59
jonathan No, me either. 16:00
Whiteknight we can tell parrot not to change the stacktop pointer when it recurses though
jonathan Aye.
I'm curious why we're setting it at that point.
Whiteknight because that sounds like stupid behavior, in hindsight
pmichaud doesn't that just translate to "don't change the stacktop pointer"?
jonathan I suspect it was a case of
Whiteknight I have to double-check that we are re-setting it, but I think we are
jonathan "we need to do it at some point"
And at one time, it was an OK place to do it 16:01
Like, when we didn't call back into PIR.
pmichaud well, it was likely OK.... right
jonathan From C.
This could easily explain various segfaults.
Whiteknight HA! I shut off the GC sweep at that point, pos_args is no longer getting prematurely swept, and now it segfaults later in the test 16:02
jonathan bwah
nopaste "Whiteknight" at 69.248.162.161 pasted "new segfault, backtrace for jonathan++ and pmichaud++" (48 lines) at nopaste.snit.ch/17111 16:03
16:03 flh joined
Whiteknight is reminded of GSOC: fix one segfault and a new one just appears later 16:03
pmichaud well, "shut off GC sweep" sounds like "workaround" and not "fix" to me 16:04
jonathan Oh, it's surely the same issue.
mmd_cache_key_from_values
That values pointer is also pos_args
pmichaud we can't keep shutting off the GC every time we might recurse
jonathan do_dispatch may also call into PIR
So almost certainly it's the same issue with recursion into PIR, and fixing that will clear this up. 16:05
pmichaud in particular, I don't think we can expect .pmc writers to know every possible situation in which they might recurse
jonathan aye
Well, Whiteknight++ maybe was just trying it to ensure it was that issue rather than proposing it as a fix.
pmichaud yes. 16:06
Whiteknight yeah, I was just proving that was the source of the issues. Looking for a more permanent solution now
pmichaud what's the purpose of lo_val_ptr ?
jonathan To make sure we don't walk too far down the stack 16:07
pmichaud I can't even find "lo_val_ptr" (with ack) 16:08
Andy Hey, you know what I'd like to get rid of?
functions that take NULL PMCs that I assume are doing it only as a safety check 16:09
pmichaud ah, it's "lo_var_ptr" 16:12
Whiteknight lo_var_ptr
yes, sorry
okay, so I think I was mistaken. I don't think the stacktop is being changed on runloop recursions 16:16
pmichaud I agree.
if it is, I can't find it. 16:17
Whiteknight ditto
but that doesn't change the fact that a PMC that is only anchored on the stack is disappearing after a recursion into a new runloop 16:19
whether it's the recursion that causes the problem or not is yet to be determined
pmichaud exactly.
So I suspect something is wrong with the algorithm for finding PMCs on the stack 16:21
either the algorithm itself, or where it's being told to search 16:22
jonathan It couldn't be at all anything to do with longjmp-ish stuff?
pmichaud I'd think that's another possibility.
that what we think is a "stack" isn't really complete because of longjmp 16:23
Whiteknight that might be possible I suppose 16:24
pmichaud I'm not familiar enough with longjmp to say, though.
Whiteknight but I have a problem thinking that we're longjmping to a point on the stack above where pos_args is being used
pmichaud we might not be (more)
Whiteknight based on what little I know about how exception handling works
pmichaud we could be longjumping to a point on the stack below wehre pos_args is being used 16:25
and for that reason the stack trace isn't getting to pos_args
jonathan I don't know enough about lngjmp stuff either.
pmichaud (I might have my above/below backwards, sorry if that's the case)
16:29 amuck joined
Whiteknight pmichaud: I think you might have been on to something with the longjmp stuff. testing now 16:32
nope, false alarm 16:40
this is a tricky nut to crack 16:41
dalek rrot: r39880 | fperrad++ | trunk (2 files):
[codingstd] put config_h.in under control
 16:44
Andy seen mauke
purl mauke was last seen on #perl 15 hours, 45 minutes and 3 seconds ago, saying: source: www.datapacrat.com/Art/Fiction/STORIES/SMALL.TXT
skids Huh. I never thought about the implications of "stackless" stuff WRT debuggers. 16:50
Whiteknight stupid gdb question: how do I set a breakpoint on a function only if the parameter is a particular value? 16:53
Whiteknight has to go dig out his gdb reference book
pos_args is definitely being collected inside Parrot_run_meth_fromc_args 17:02
the gc_debug runcore is collecting it
and the lo_var_ptr is the same in both places 17:04
17:19 AndyA joined
Whiteknight AHA! I think I've got it! 17:25
runops_gc_debug core calls Parrot_gc_mark_and_sweep(interp, 0); 17:26
jonathan What's the 0?
The problem?
purl In 1972 a crack commando unit was sent to prison for a crime thry didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them, maybe you can hire... the A Team.
jonathan Yeah let's get the A Team to debug our GC! 17:27
Whiteknight notice that it doesnt call it with GC_TRACE_FULL, which would trace the stack
so the gc_debug runcore is not tracing the stack, so anything that's stack-only will get killed when we recurse into this runcore 17:28
so the gc_debug core creates new bugs that we wouldn't see otherwise
17:29 dukeleto joined
Whiteknight changing to the normal slow core, and the test completes without problem 17:29
even passes
Tene oh man, that's hilarious. :D 17:31
jonathan Damm! 17:34
pmichaud so..... 17:37
you're saying that the other fix you did seems to have resolved the problem?
(or at least moved it somewhere else?) 17:38
17:39 skids joined 17:45 bobke joined
Whiteknight spectest fails a lot fewer tests now 18:14
not zero though
18:19 davef joined 18:21 davef left
pmichaud well, there are some failing tests that aren't -G related 18:29
afk, errands
Whiteknight that's a good sign, right? that the tests aren't -G related? 18:31
jonathan Yes. 18:33
18:33 david joined 18:34 david left
dalek rrot: r39881 | whiteknight++ | trunk/src (2 files):
[gc] use mem_allocate_zeroed_typed instead of mem_allocate_typed + memset. Suggested to me by ... everybody who saw my r39879. fperrad++, pmichaud++, Infinoid++
 18:37
Whiteknight Well, I'm going to do my best W. and declare "mission accomplished"
nopaste "mikehh" at 90.209.206.211 pasted "codetest failure from make fulltest at r39880 (PATCH follows)" (32 lines) at nopaste.snit.ch/17113 18:40
mikehh codetest fails at r39880 - all others PASS - Ubuntu 9.04 amd64 - PATCH done - PASSes
dalek rrot: r39882 | whiteknight++ | trunk/src/runcore/cores.c:
[gc] The gc_debug core doesn't trace the system stack between dispatches. This causes a problem when we recurse into a new runcore while there are PObjs in the previous runcore that are only located on the stack and not anchored anywhere else in the memory graph. Change this to run a GC_TRACE_FULL trace, to make sure we cover the stack. Sure it's slower, but we don't use gc_debug because of the blinding speed
nopaste "mikehh" at 90.209.206.211 pasted "PATCH for codetest failure at r39880" (13 lines) at nopaste.snit.ch/17114
ttbot whiteknight: Parrot trunk/ r39881 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/45723.txt 18:41
Whiteknight wtf? what is ttbot?
mikehh: I think I already fixed that in r39881 18:42
mikehh++ though
18:43 jan joined
ttbot whiteknight: Parrot trunk/ r39882 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/45738.txt 18:44
mikehh Whiteknight: yes you removed the problem "sizeof" 18:45
Whiteknight ok 18:46
dalek rrot: r39883 | whiteknight++ | trunk/include/parrot/pmc.h:
[gc] make headerizer to fix problems with gc_unregister_pmc which were introduced for some systems in r39881
Whiteknight EAT THAT TTBOT! 18:47
skids heheh. ttbot: "the compiler that stalks your ass" 18:54
Whiteknight who runs ttbot? 18:56
ttbot?
purl: you're worthless
purl Whiteknight: huh?
Whiteknight just the response I would expect from a worthless bot
mikehh All tests PASS (pre/post config, smolder, fulltest) at r39883 - Ubuntu 9.04 amd64 19:11
Infinoid what's a ttbot? 19:27
mberends my xchat says it's TapTinder bot, at the Brno University of Technology 19:33
mikehh more rakudo tests passing (4/5 real fails) t/spec/S04-declarations/constant.rakudo exits after 7 out of 20 with Null PMC access in type() 19:37
19:44 PacoLinux joined 19:45 Theory joined 20:29 Austin joined 20:32 david joined 21:03 bacek joined 21:10 klapperl left
bacek goo morning #parrot 21:10
good of course
Austin oodgay orningmay, acekbay
bacek Austin: :) 21:11
mikehh not yet 1 hour + to go, but hi anyway
bacek Hooray! Whiteknight++ 21:14
Austin ?? 21:17
bacek Austin: GC fix. 21:18
Austin ?? 21:20
Ignore that last ?? 21:21
I hit uparrow by mistake.
Tene Hi Austin. :) 21:38
Austin Hello, Tene. 21:39
dalek rrot: r39884 | bacek++ | failed to fetch changeset:
Bring brach up-to-date with trunk.
 21:41
bacek purl: TapTinder? 21:46
purl TapTinder is back, tt.perl6.cz/ .. need port watchdog to linux ... some test hang in r26917
bacek purl: ttbot is TapTinder bot. Owned by rj41
purl OK, bacek.
Austin is grinding testcases for PCT 21:55
Bleargh 21:56
22:09 dduncan joined 22:10 dduncan left 22:34 rg joined
Austin Double-bleargh. Undef != null. 22:58
msg pmichaud Patrick, when a class (e.g., PCT::Node) uses P6object to extend Capture, printing an object of the class reports "Capture[0xb74b34a8]" instead of the name of the newly derived class. Is this a bug? 23:03
purl Message for pmichaud stored.
Austin msg pmichaud Patrick, when a class (e.g., PCT::Node) uses P6object to extend Capture, printing an object of the class reports "Capture[0xb74b34a8]" instead of the name of the newly derived class. Is this a bug? 23:04
purl Message for pmichaud stored.
Austin Man, I have to watch that alt-tab+up+enter. sigh
Sorry, patrick.
23:15 Limbic_Region joined
pmichaud Austin: if it's a bug, it's not completely a bug in PCT 23:16
it's true also for any class (P6object or not) that extends built-in PMC types 23:17
for example, try it with Hash
nopaste "pmichaud" at 72.181.176.220 pasted "subclasses of PIR classes don't always stringify to subclass name (for Austin)" (11 lines) at nopaste.snit.ch/17116 23:18
dalek rrot: r39885 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Don't use MULTIs in Hash... It was way too optimistic.
 23:30

Powered by Cro and the Raku® Programming Language.

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

Thank you!