Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 18 May 2010.
00:07 contingencyplan joined 00:10 mikehh_ joined
dalek rrot: r47118 | jonathan++ | trunk/src/ops (2 files):
[core] Another step towards better annotation output; this does the same for method calls as the previous patch did for other invocations.
 00:13
plobsing how do backtraces handle TCO? 00:21
00:23 jnthn joined
jnthn plobsing: TCO? 00:23
purl i guess TCO is total cost of ownership
plobsing TCO is also tail call optimization
purl okay, plobsing.
00:23 whiteknight joined
jnthn plobsing: There is no frame. ;-) 00:24
00:24 gbacon joined
jnthn plobsing: The context is done, so we've no way to know we tailcalled when we get to produce the backtrace. 00:24
*gone
plobsing I guess there is no good way to handle that one. Might be a tad bit confusing for debugging though. 00:25
jnthn plobsing: Given how many problems we have producing decent backtraces today, if we get to the point where that's our biggest problem, I'll be happy. :-)
Last few patches have made things a *lot* better though. 00:26
One more nasty issue and then I can probably consider the data good enough to enable the Rakudo backtrace printer.
Hmm...does Parrot_cx_find_handler_local do any unwinding or does it just go looking? 00:28
oh whee, it does all sorts. :-) 00:29
dalek rrot: r47119 | jonathan++ | trunk/src (2 files):
[core] A little cleanup now we have GC-able contexts.
jnthn <- rusty Parrot guts skillz 00:31
davidfetter oh hai 00:34
GeJ plobsing: ping
Good morning everyone. 00:35
plobsing GeJ: pong
GeJ plobsing: I saw that you recently touched t/op/arithmetics_pmc.t to accomodate with the merge of ops_massacre. 00:36
You decreased the test count from 44 to 40.
plobsing yes. I moved the pow test to t/dynoplibs 00:37
GeJ However Its looks like I'm running 42 tests.
plobsing I didn't delete tests if that is your concern
weird
GeJ no gmp here. 00:38
plobsing oic. I need to decrement the skip count for non-GMP
GeJ maybe that changes the tests count?
plobsing fixed in r47120. 00:40
or should be. can you test it?
GeJ thanks.
yup, give me a couple of minutes. 00:41
plobsing: make test PASS. Thank you. 00:45
bbiab 00:46
&
dalek rrot: r47120 | plobsing++ | trunk/t (2 files):
adjust appropriate skips for non-GMP users
00:49 hercynium joined, joeri joined
jnthn GAH! 00:52
Pro debugging tip: never skip reading a line of code just because you think it's doing something too obvious go get wrong. 00:53
*to
dalek rrot: r47121 | jonathan++ | trunk/src/pmc/exception.pmc:
[core] Rather than just getting the thrower context, we should actually then use it to try and obtain a backtrace, not just toss it in favor of (probably the handler's) context.
 01:02
rrot: r47122 | jonathan++ | trunk/src/exceptions.c:
[core] Exceptions thrown from ops also need to stash the thrower inside the Exception object so we can produce the backtrace.
rrot: r47123 | plobsing++ | trunk (2 files):
make opsc op_func_table output slightly prettier
jnthn OK, I think I've patched enough to actually have useful backtraces. 01:03
This very possibly makes the PIR backtraces a bit more informative too.
plobsing 2 options for fixing dynops in PBC: 01:11
1) scan code at compile time and add a fixup for every dynop instance 01:12
2) scan code at runtime and modify dynop instances
note that scanning code may be expensive as you have to ask each opcode what size it is 01:13
but many fixups will be bloaty
advice welcome 01:15
jnthn plobsing: What's the Actual Problem that you're looking to fix? 01:16
The fact that different PBCs may have assigned different numbers to dynops? 01:17
plobsing yes. and a loading parrot has no way of knowing this.
jnthn Does it know what dynop libs the PBC uses? 01:18
plobsing in an indirect way, yes
the interpreter state gets frozen into the pbc and merged with the current interpreter on load
I intend to make the dynop dependancies explicit
jnthn How about - and I'm *rusty* on Parrot guts - something like: 01:19
A PBC lists the dynoplibs it uses and the numeric range it gave to each
plobsing yes. this is what I intend to do about the explicit mapping.
jnthn OK
So today when you call code in another bytecode segment...
...you have to "switch" to that seg.
Could you associate with each bytecode segment a number -> op function pointer lookup table? 01:20
plobsing umm... not really. loading *appends* to the current segment. it is all kinds of ugly and wrong.
jnthn Oh.
Er, yeah.
whiteknight what the hell does interp->class_hash contain?
jnthn That sounds...awful.
plobsing in fact, parrot *can't* handle multiple segments.
GC doesn't mark constants for anything but the current segment 01:21
jnthn Heh. Even though all the stuff is there to switch to another segment when you call a sub?
Oh.
Do I want to ask why?
plobsing because multiple segments is the *right* way to do it.
just not the way we do it now
jnthn Yeah, it's what I'd have expected too.
Then you don't have to modify a load of stuff 01:22
Each seg can have its own mapping to the actual dynop functions.
Heck, a JITter can then even use the table to write the calls faster. Or a pre-deref core. Or whatever.
plobsing that would be nice. very nice. but a lot of work. 01:23
jnthn Fixing things to enable multiple segs would be? 01:24
Or the other fancy stuff I mentioned?
plobsing fixing things to enable multiple segs and then making enough things use multiple segments to make breaking it non-trivial 01:25
At some time in the past, I suspect multiple segments worked
jnthn I'm sure they did.
I'm not sure why things ended up going in the appending direction.
plobsing but then someone broke it and the tests didn't whine because everything was using one segment
jnthn I suspect it got broken long, long ago. 01:26
plobsing pushes segments issue to tasklist 01:27
jnthn whiteknight: clash_hash maps names to type IDs 01:29
whiteknight: $P0 = new 'ResizablePMCArray' # probably uses class_hash to map the name to the PMC ID 01:30
whiteknight: I have no idea wtf it's a namespace and not a hash.
whiteknight jnthn: yeah, that's the question I'm running into right now. Why the hell is it a namespace? 01:31
but, I think I'm understnading better how it is used now
jnthn whiteknight: Well, does making hash break anything?
er, making *it* a hash... :-)
Maybe the person who wrote it was making hash. ;)
whiteknight jnthn: I'm sure it does. It's called often with the get_pointer_keyed VTABLE, which I don't know if Hash implements in the same way
whatever, I'll consider changing it later 01:32
jnthn ugh
I thought the whole thing was meant to go away anyway.
plobsing can you make it a Hash of Integers? That would reduce memory usage *and* help GC.
sorear plobsing: The first time I read our handling of dynops, here's how I understood it working; it might be sufficient:
1. Dynops aren't real ops, but live in separate tables, one per dynop lib 01:33
2. Dynop libs have dynamically assigned numbers; each PBC has a fixup table for the constant pool
jnthn btw, with today's Parrot fixes, I can now get Rakudo start to spit out stuff like in gist.github.com/418686
sorear 3. When a dynop is assembled, it generates the _wrapper coreop, passing a constant table index (which gets fixed up) for the lib, a number for the op itself, and the op's args
jnthn Other HLL devs may be interested to do similar. :-) 01:34
plobsing sorear: so you're for using fixups in stead of scan on read?
jnthn plobsing: Anything that involves changing the bytecode in memory before running it is *very* bad. 01:35
That's the main thing to avoid.
plobsing jnthn: we already do that with fixups
jnthn ...
Wow.
sorear fixups need to exist, but they should be localized to a small area 01:36
plobsing also Parrot *mostly* works without multiple segments. I consider it to be a lower priority
sorear think about the PIC and GOT
that's the model we want to follow
(actually just the GOT; PIC isn't needed)
jnthn Guess all the "we can mmap bytecode files" stuff is kinda not happening then.
sorear jnthn: if all the fixups are on a single 4k page, no harm
plobsing doesn't the G in GOT stand for *global*?
sorear plobsing: yes 01:37
jnthn sorear: Troo.
plobsing so how does that keep the fixups local?
sorear plobsing: each module has its own GOT
it would be more correct to call it Intermodule Offset Table
they're "global" in the sense that they refer to external things
the offsets are what's global, not the table 01:38
plobsing jnthn: how does modifying bytecode after loading preclude mmapping?
jnthn plobsing: mmap lets one copy of a file be held in memory and shared between all running instances.
sorear plobsing: the whole point of using mmap is that it's lazy. If you mmap a 5MB bytecode file, the I/O doesn't occur until subs are called
jnthn Also that.
But the other thing is, imagine a CGI situation where people are running 20 instances of Perl 6 simultaneously. 01:39
sorear but if we're making 1 fixup on each of 1250 4kb pages, we force the whole thing to be loaded
plobsing I see. So it's that we want read-only bytecode.
jnthn Our bytecode file is, say, 6 megs.
sorear plobsing: this is also why we use native-endian bytecode
jnthn Having one copy of that in RAM rather than having to make 120 MB worth of copies of it is kinda preferable. :-)
sorear in a perfect world, the kernel would have a callback for "I just paged in some data at XYZ address; please byteswap or otherwise fix up the in-memory version" 01:40
but neither POSIX nor Linux has that
plobsing mmapping bytecode would be nice, but there are more pressing issues.
if you can figure out how to eliminate the fixup table, and get multiple segments working, it would likely be smooth sailing from there 01:41
sorear Is our fixup table a table of fixups or a table that is fixed up? 01:42
plobsing those are all things I'd like to do, but I only have so much time. Also single-instance parrot performance is still shitty, so I'll fix that before fixing multiple-instance performance 01:43
nopaste "GeJ" at 192.168.1.3 pasted "[PATCH] Partially fix `make codetest`" (71 lines) at nopaste.snit.ch/20732
plobsing I'll try and keep the fail in one place and use fixups then. 01:45
so to answer my initial RFC, option (2)
sorear: fixup table is table of bytecode fixups 01:46
mostly label and sub fixups ATM
I mean option (1). /me can't count apparently. 01:47
sorear plobsing: ah
the ELF global offset table is a data object at a known (PC relative) address which contains pointers to global functions and variables used in the module 01:48
all external references from the module indirect through the GOT 01:49
this means that, if a module imports 1000 functions, only a single 4kb page of pointers needs to be touched during dynamic linking
dalek kudo: b066578 | jonathan++ | (3 files):
First cut of a backtrace printer. With recent Parrot improvements, it actually

come, but commit early, commit often and all that. :-)		 01:53
kudo: 339d0b9 | jonathan++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get latest Parrot with various backtrace production
01:57 tcurtis joined
sorear also, \\o/ JONATHAN RETURNS 02:00
02:05 Andy joined
dalek rrot: r47124 | plobsing++ | trunk (4 files):
partial codetest fixes submitted by GeJ++

  $ prove t/distro/file_metadata.t 2>&1 1>/dev/null | perl -nle '/#\\s*(svn ps.*)$/ and print($1) and system($1)'		 02:08
kudo: 8b3bb0b | jonathan++ | src/Perl6/BacktracePrinter.pm:
Include fully qualified names of routines in the backtrace, plus better handling
 02:22
tracwiki: v2 | plobsing++ | PlobsingTaskList 02:27
tracwiki: trac.parrot.org/parrot/wiki/Plobsin...ction=diff
02:30 eternaleye joined
dalek rrot: r47125 | plobsing++ | trunk (6 files):
eliminate unused fixup type 'label'
 02:41
03:01 janus joined
dalek rrot: r47126 | plobsing++ | trunk/t/native_pbc (4 files):
mk_native_pbc
 03:15
plobsing I broke PBC_COMPAT twice in one week. Let's see if I can make it a hattrick ;-) 03:19
dalek kudo: 6e39fe1 | jonathan++ | src/Perl6/Compiler.pir:
Little tweak so things in the core setting get shown in the backtrace with a
 03:21
kudo: 34542f7 | jonathan++ | src/Perl6/Actions.pm:
Emit file annotation so backtraces have file names.
GeJ plobsing: even at r47126, I seem to have problems with packfile tests. 03:52
"PackFile_unpack: This Parrot cannot read bytecode files with version 6.19." 03:55
plobsing yes. someone seems to have added *other* PBCs that don't get updated when I run mk_native_pbc. 03:56
(whoever did that)--
03:56 patspam joined
plobsing I am in the process of updating them 03:56
sorear wonders how hard it would be to add a "write little endian 32-bit PBC" function to Parrot
GeJ Great. Sorry for the repeated annoyances. 03:57
sorear we already have code to massage PBC integers...we run it when loading non-native PBC
plobsing sorear: probably very. we have *many* places that simply do '*cursor++ = x;' for writing PBC
plobsing is more interested in if we could make opcode_t smaller than native pointer size 03:58
then I could make 16-bit PBC for epic compression levels
GeJ: pointing out failures I introduced is *usefull*. no need to appologize. 04:00
04:05 Andy joined
dalek rrot: r47127 | plobsing++ | trunk/t/native_pbc (3 files):
mk_packfile_pbc
 04:21
GeJ I don't doubt that there is some use in my pointing at errors and or mistakes. However I can't stop thinking that it may make me look like a whining bitch to all of you guys who make the real work (which is definitely not my intent I can assure you). 04:24
cotto GeJ, doing nothing but complaining about valid problems with Parrot still counts as making a valuable contribution. 04:26
GeJ Hah! my point exactly. I'm not so much "complaining" about anything. I'm more in the line of "Hey guys, when I run make codetest, I get this, this and this. Would be nice if someone had a few minutes to fix it." 04:30
Hence my apologies if I sound like always complaining. :)
cotto I consider that to be complaining, but I think I have a less negative connotation attached to the word than you do. 04:31
If it helps, mentally substitute "report
" for "complain" and you won't lose any information.
GeJ Well, my English sucks. I may have translated it to my native language in which "complain" holds a negative connotation. You're lucky I don't apologize for that every couple of lines I type something here. 04:33
cotto Heh. I'll make sure to say "report" more often then.
GeJ Nah, "complain" is fine. :) 04:34
cotto ooc, what's your native language? French?
GeJ yes.
cotto good to know 04:35
I wouldn't have guessed without having Wikipedia to look up New Caledonia's official language
sorear GeJ: complain has a strong negative connotation in Englsih too
GeJ Speaking about foreign languages and translations, Christian Aperghis-Tramoni has written his second series of articles about Parrot. They have been published in France in a F/OSS-oriented magazine. Their policy is to publish the articles online 6 months after the paper version. 04:55
The first series of articles were about PASM. And the second one are about PIR.
The first article of the second series has been put online. 04:56
www.unixgarden.com/index.php/progra...ere-partie (in French)
Not quite sure about licence and rights restrictions, but since they're pretty well witten and cover a lot of topics, they could be a nice addition to the docs. 04:58
I'll try to get some info about this. 05:03
sorear grumbles at the lack of good Anglophone technical writers 05:04
cotto It's good that they have url at the bottom, but I'm not sure why they wouldn't want to make them into actual links. 05:12
Has the author been on #parrot? 05:13
GeJ cotto: my guess, quick copy-and-paste from the paper version.
cotto probably the case
plobsing wow finite 32 registers of each set? how old is that article? 05:14
cotto if they wait 6 months to publish articles online, the interwebs are most like ancillary to the print version
Maybe we'll get another hacker or some bug reports out of the deal. 05:18
GeJ plobsing: yep, that seemed weird to me when I read it. I had the ide that this limitation had been guillotined a long time ago. 05:19
plobsing it also claims our register allocator works
GeJ FYI, in src/exceptions.c on line 213, there are some trailing spaces that if removed make `make fulltest` passes all tests. 05:21
cotto fix't 05:23
sorear ...what 05:25
traling spaces in C code cause bugs?
cotto no. It's just a coding standards test 05:26
GeJ not bugs, but failures in `make codetest`
dalek rrot: r47128 | cotto++ | trunk/src/exceptions.c:
[codingstd] trailing space fix, gej++ for noticing
 05:27
05:39 JimmyZ joined
cotto hola, JimmyZ 05:42
JimmyZ Hi
purl privet, JimmyZ.
tcurtis Is there a way in Perl 6(preferably also in NQP) regexes to be able to add the ability to do something like <foo(bar, baz)>, where foo is a named regex that takes parameters? Not necessarily with that syntax, but with some simple convenient syntax? 05:46
plobsing I'm looking into associating dynops with bytecode segments in stead of interpreters (like jnthn++ and sorear++ advised earlier). 05:47
It would be a clean design but would require deciding between 2 tables of ops (1 for core ops, 1 for currently active dynops)
I'm sure it might cause some controversy
tcurtis I retract my question. Looking at dev.perl.org/perl6/doc/design/apo/A05.html I see that <foo(bar, baz)> is indeed valid. Is that implemented in NQP-rx? 05:50
sorear yes 05:52
we use it extensively
token scope_declarator:sym<our> { <sym> <scoped('our')> } 05:53
eg
from Rakudo
tcurtis Wonderful! 05:56
sorear Are you doing this for tree gramamrs? 06:02
tcurtis Yes. 06:03
sorear Excellent.
tcurtis This is a very simple single optimization(independent optimizations should probably be roles, I'd rather a tree grammar "does FoldArithmetic::Optimization does TailCallElimination::Optimization does BlockLocalExceptionElimination::Optimization" than "is ... is ... is ...") gist.github.com/418828 06:25
thoughts, anyone? 06:29
sorear it looks pretty much exactly like I imagined 06:32
note that NQP doesn't have roles
what you're doing is a rewrite system, not really a parser, though 06:33
"make" is as such slightly wrong
you'd still need a set of classes to build a rewrite engine 06:34
maybe you would want a new regex declarator rewrite{}
rewrite names are used only for documentation; a rewrite engine take a rewrite grammar and calls rules in the right places 06:35
Perl6 'tr' is an example of a rewrite engine for strings
(it's incomparably more powerful than perl5 tr) 06:36
try this: pastie.org/983986 06:39
the Grammar/Actions split arguably has no place in this context; it's optional in Perl6 06:40
tcurtis That is much nicer. Although, I think a Grammar/Actions split might be sensible for larger groups of more complicated optimizations. 06:43
sorear or better yet
pastie.org/983989 06:45
proto regex means to take fold:foo, fold:bar, fold:quux in the current inheritence hierarchy and merge them by conjunction into one super-regex named fold
now, the rewrite engine you're going to use for constant folding is going to look like this 06:46
sub rewrite-past-bottom-up($past, $grammar, $rule) { 06:47
for ($past.children) { $_ = rewrite-past-bottom-up($_, $grammar, $rule); }
while ($past ~~ /<$grammar::$rule>/) { $past = $/.ast } 06:48
$past
}
there will be different rewrite engines for different occassions; top-down ones, ones that work on POST, etc
plobsing tcurtis: you have to be carefull about constant folding PMCs. PMCs are free to do whatever they want when you ask them to add. This is one of the things that makes parrot great (or horrible, flip sides of the same coin really). 06:49
bacek Hello humans 06:50
purl hey, what about me?
bacek purl, good girl :)
purl thanks bacek :)
bacek plobsing, (about your mail) what about store dynops with each segment, have global core ops and create full table of ops per segment during unpack? 06:51
plobsing so option (3)? 06:52
bacek plobsing, e.g. option "5" - copy in Parrot_switch_cs + copy in PackFile_unpack
tcurtis plobsing: noted.
plobsing tcurtis: you might want to maintain a "well behaved" list of PMCs and use available type information (if available) to make inferences on what you actually can fold 06:54
cotto plobsing, could hll mapping mess that up? 06:55
plobsing I would assume that HLLs would be the people specifying what optimizations are legal and/or providing the list of well behaved PMCs 06:56
sorear replies to plobsing
plobsing bacek: the problem with that option is that every PBC bytecode segment gets its own rather large ops table. core ops alone is almost 1K entries. 06:57
cotto There won't be that many different ops tables. That strikes me as something we could be smart about to avoid excessive memory bloat. 06:59
(different wrt contents) 07:00
bacek plobsing, how many bytecode segments do we usually have? What if pbc_merge will properly merge them? 07:01
cotto That's also an important question.
sorear plobsing: reply is now sent.
bacek: 1 07:02
but that's due to change
(right now, pbc load *appends to the current segment*)
plobsing sorear++. bacek, cotto: while I do enjoy the immediate discussion IRC allows, please at least put a summary on the list.
cotto sorear, nice suggestions 07:03
plobsing (trying to keep discussion entirely in one place)
re pbc_merge, appending segments: those actually perform shallow packfile merging (ie: only at the directory level). bytecode segments remain distinct. 07:06
sorear: I don't understand your 3a suggestion. please elaborate 07:14
sorear instead of having 1000 core ops + N*M dynops 07:15
have 0 core ops
IMCC will always act as if the core ops were implicitly loadlib's 07:16
'd
so the user notices no difference
but because all ops are in the dynop table, we can trim them
plobsing I thought you might be getting at that, but given the recent issues with removing core ops, I thought it impossible for someone to suggest that
sorear say the user uses 57 distinct core ops. that's a 228 byte "core op" section
plobsing sorear: that assumes you can load ops with a granularity of a single op 07:17
sorear plobsing: the core ops are only removed if the packfile doesn't use them
plobsing: why couldn't we? PIRC knows what ops are used, it doesn't have to generate dispatch table entries for /all/ of them 07:18
tcurtis Even if you load all of the ops in an oplib, you wouldn't need to keep all of them in every op table. 07:19
plobsing OK, I think I have a grasp on what you're getting at. Now I can form a response on the list with a little more than "I have no idea what you just said".
tcurtis I have an idea which would probably be equivalent or very similar to sorear's 4b. But if so, no harm in describing it more explicitly, eh? And if not, perhaps it's at least worth considering. 07:25
Have a global ops table that holds both core and dynops. Have a separate dynops table for each segment that maps from dynop numbers used in the segment to the index into the global ops table for each segment.
When you execute an op above HIGHEST_CORE_OP_NUMBER, get the dynop table for the current bytecode segment, execute the op found at $global_table[$current_dynop_table[$dynop_number - HIGHEST_CORE_OP_NUMBER - 1]]
plobsing IIUC, that's a pretty close variant of what I suggested in (4) with the exception that you lose thread-locality 07:27
cotto How much of this applies to dynpmcs?
plobsing sorear: what's the difference between the redispatch op of (4a) and the stub ops of (4b)?
sorear there is only 1 or a small number of redispatch ops 07:28
cotto: None. dynpmcs are referenced by name.
plobsing no they aren't
sorear D:
plobsing actually, this has a little to do with dynpmcs, but the problems with their numbering ends after the bytecode is loaded. 07:29
as opposed to dynops, whose mapping remains important throughout runtime
so the redispatch looks like "dynop_redispatch <dynop_num> <dynop_args>", whereas the stub looks like "<magic_stub> <dynop_args>"? 07:31
sorear yes
dynop 1395, <args> vs dynop_1395 <args> 07:32
the former is actually how I misunderstood the dynop code the first time I read it
plobsing anything that requires platform-specific code is likely to fall into disrepair for anything except x86(_64)? linux very quickly 07:35
cotto I got the impression that it'd only be a tiny snippet of assembly. 07:37
sorear it couldn't be the only option 07:39
plobsing case and point: do we actually ever use src/atomic ?
that has platform-specific stuff
sorear (for a start, many of the machines bubaflub is trying to port Parrot to have separated I/D spaces and *cannot* support this)
plobsing: it will be impossible to have sanely working threads without it, so if the GSoC thread guy succeeds, we will 07:40
pthreads, RTEMS threads, and NT threads all offer CPU-independant atomic op APIs 07:41
cotto sorear, did you mean that 4b would be possible with straight C but could be sped up with asm?
plobsing sorear: what modern architectures are pure Harvard?
sorear if we aren't using those, we should
dalek rrot: r47129 | bacek++ | branches/gc_massacre:
Yet another massacre. See wiki GCMassacre for details
sorear plobsing: AIUI, many microcontrollers
cotto: yes 07:42
cotto ok. that's sane
sorear (my favorite is 3a)
plobsing sorear: I think I'm missing something about (3a). see my response on list. 07:44
07:47 fperrad joined
plobsing sorear: I've done some work with microchip and atmel uCs and they provide ways (albeit convoluted) of mixing data with code 07:47
07:47 eternaleye joined
sorear it wouldn't actually be asm written; it would be a small chunk of C that does t = malloc(11); /* pretend I got that from a W&X pool somewhere */ memcpy(t, "\\xA1\\x00\\x00\\x00\\x00\\xFF\\xA0", 11); *(int*)(t+1) = (int)&current_dynop_table; *(int*)(t+7) = (int)(opnum * 4); 07:49
plobsing: Did you send it to me only in error, or is it truly secret and I should reply in kind? 07:53
plobsing lolno. /me fails at mailing lists often
cotto I was wondering about that same question. 07:55
07:55 fperrad_ joined
plobsing it is now forwarded appropriately 07:55
cotto (how does parrot know which op table to dispatch to)
plobsing whichever one is current. each code segment gets one. you can only be executing one code segment in one thread of execution at any one time. 07:56
(see Parrot_switch_to_cs, which is where we'd put the code to support switching between tables) 07:57
sorear plobsing: replied 08:01
plobsing: I was thinking of PIC, so I guess I was wrong. This is without hardware modification? 08:02
plobsing: Anyways, runtime code generation is not portable between CPUs, not portable between OSes (if PROT_EXEC is fully supported), and flat out impossible under maximum-security SELinux 08:03
we'd be fools to not support doing without 08:04
tcurtis Good night, folks. I'll work some more on example code(probably quite similar to your idea, sorear) of possible tree grammar syntax tomorrow and probably post on the list about it. By the way, sorear, you could reduce the memory usage by...nevermind...you already mentioned an essentially equivalent version(mine would have used a sentinel value for the end, but length prefix is slightly better, now that I think about it). 08:06
plobsing one thing about (4a) I dislike: it introduces a variable length op, which are hard to work with 08:07
cotto istr that we already have some 08:08
plobsing and I wish we'd eliminate them
cotto +1, and I'm certainly not saying more are justifiable if there's a better way 08:09
dalek rrot: r47130 | moritz++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[PCT] print backtraces to STDERR by default, not STDOUT
 08:14
moritz oh fun 08:16
plobsing moritz: what?
moritz that commit makes rakudo segfault on producing an error message
plobsing moritz: you can get at stderr without using dynops
getinterp => interp.stdhandle => print
moritz plobsing: will try that, thanks 08:17
plobsing or you could just use "die"
ttbot Parrot trunk/ r47130 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/332232.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
sorear ...why does PCT print backtraces?
that belongs in src/exception.c 08:18
plobsing sorear: it is so you can overload backtraces. so that java on parrot can be just as fun to debug 08:20
dalek rrot: r47131 | bacek++ | branches/gc_massacre (3 files):
Start cutting PMC_Attribute_Pool as Pool_Allocator.
 08:31
rrot: r47132 | bacek++ | branches/gc_massacre/src/gc (2 files):
Cargo-cult PMC_Attributes_Pool as Pool_Allocator
rrot: r47133 | moritz++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[pct] print backtraces to STDERR without using dynops. plobsing++
rrot: r47134 | bacek++ | branches/gc_massacre/src/gc (2 files):
Add .is_owned method to Pool_Allocator
rrot: r47135 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Don't allocate objects smaller than sizeof(void*). Always allocate full 4kb page
lscript: 83982a0 | fperrad++ | setup.pir:
refactor with runtests()
 08:42
rrot: r47136 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add a helper runtests()
 08:48
a: 6f78f52 | fperrad++ | setup.pir:
refactor with runtests (from distutils)
 08:50
08:57 sorear joined 08:59 purl joined
dalek kudo: dd8b9f0 | moritz++ | docs/ChangeLog:
update ChangeLog
 09:07
kudo: 5aba135 | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION yet again to get backtraces printed to STDERR
kudo: 6eec67c | moritz++ | src/core/Seq.pm:
Seq hash coercion
p-rx: d1d1d31 | moritz++ | src/stage0/ (4 files):
update stage0
 09:36
rrot: r47137 | moritz++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp-rx] update bootstrap files to get $/.chars fix for failed matches
 09:38
rrot: r47138 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Fix rounding up Pool_Allocator_Arena
rrot: r47139 | bacek++ | branches/gc_massacre/src/gc/gc_private.h:
Uncomment GC_Subsystem.gc_private. We'll need it.
rrot: r47140 | bacek++ | branches/gc_massacre (3 files):
Add stub for double-linked lists
rrot: r47141 | bacek++ | branches/gc_massacre/src/gc (2 files):
Implement linked-list. Not tested
 09:55
rrot: r47142 | bacek++ | branches/gc_massacre/src/gc/gc_ms.c:
Add mark_{pmc,string,buffer} stubs into GCMS. Allocate @objects.
10:17 aukjan joined 10:36 whiteknight joined 10:38 TiMBuS joined
whiteknight good morning, #parrot 10:47
10:54 JimmyZ joined
dalek p-rx: 45a6612 | masak++ | src/Regex/P6Regex/Actions.pm:
aligned error message with STD's
 11:13
rrot: r47143 | bacek++ | branches/gc_massacre/src/gc (2 files):
Made Parrot_gc_create_pool_allocator public
 11:17
bacek aloha whiteknight 11:23
whiteknight aloha, bacek
bacek whiteknight, I pleased that my GC pseudo-code is useful :) 11:24
dalek kudo: 5a8bd03 | masak++ | src/core/IO.pm:
[IO.pm] better params name in &note
 11:33
rrot: r47144 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Implement destruction of Pool_Allocator.
 11:34
rrot: r47145 | bacek++ | branches/gc_massacre/src/gc (2 files):
Move guts of mark_FOO_fun into gc_ms.c from api.c
rrot: r47146 | bacek++ | branches/gc_massacre/src/gc/system.c:
Use mark_PMC_alive during tracing of system stack.
rrot: r47147 | bacek++ | branches/gc_massacre/src/gc (3 files):
Remove GC_Subsytem.mark_string_alive. Use mark_pobj_alive instead
kudo: 3d540b8 | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION to get fix for RT #74694
 11:39
whiteknight thinks he's finally figured out how to get a proxy from a namespace 11:43
...maybe not 11:56
12:01 gbacon joined
dalek kudo: ff31b59 | jonathan++ | src/Perl6/Module/Loader.pm:
Set $?FILES in module loader, so we end up with the correct filename annotation
 12:08
kudo: 478ba48 | jonathan++ | src/pmc/p6opaque.pmc:
Correct busted format string to fix bad error message noticed by moritz++.
12:10 JimmyZ joined, smash joined
smash hello everyone 12:10
nopaste "mikehh" at 192.168.1.3 pasted "remaining errors in make corevm/make coeretest at r47147" (71 lines) at nopaste.snit.ch/20739 12:20
mikehh the tests pass in make test
make corevm/make coretest FAILs - see: nopaste.snit.ch/20739 12:23
all other tests PASS (pre/post-config, smoke (#34129), fulltest) at r47147 - Ubuntu 10.04 amd64 (g++)
t/op/annotate-old.t - TODO passed: 1 in testf 12:29
dalek kudo: 1727ca5 | moritz++ | (2 files):
implement Cool.succ and .pred
 12:37
mikehh gotta reboot - bbiab 12:38
12:44 mikehh joined 13:13 snarkyboojum joined
dalek rrot: r47148 | jonathan++ | trunk/src/ops (2 files):
[core] One more tweak for better annotation reporting, from feedback by masak++; this gets us able to identify the correct line number that a failed sub call happened on.
 13:14
13:31 JimmyZ joined 13:41 joeri joined 13:44 elmex joined
mikehh make corevm/make coretest FAILs - see: nopaste.snit.ch/20739 (same failures) 13:50
all other tests PASS (pre/post-config, smoke (#34132), fulltest) at r47147 - Ubuntu 10.04 i386 (g++)
t/op/annotate-old.t - TODO passed: 1 in testf
t/op/exit.t - TODO passed: 6 in testf
in testf the first TODO passes on amd64 but not the second 13:52
cognominal I can't find how to compile pdb :( 14:05
I see stuff in the Makefilethough 14:06
ho, apparently, it is called a longer name... that's why I could not find it. 14:07
but still rough at the edges : ./parrot_debugger 14:11
Segmentation fault
bash-3.2$ ./parrot_debugger --help
stat failed: No such file or directory
purl (Core dumped)
14:13 aukjan joined 14:25 lucian joined 14:37 lucian joined 14:41 seatek joined 14:43 tetragon joined
nopaste "bacek" at 192.168.1.3 pasted "chromatic, it works :)" (12 lines) at nopaste.snit.ch/20742 14:48
bacek msg chromatic nopaste.snit.ch/20742 - first working version of TriColour M&S on gc_massacre branch. 14:49
purl Message for chromatic stored.
nopaste "bacek" at 192.168.1.3 pasted "chromatic, some TriColour stats for t.pir" (10 lines) at nopaste.snit.ch/20743 14:51
14:53 kid51 joined
dalek rrot: r47149 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Copy INF GC to TMS GC as barebone future GC implementation
 14:55
rrot: r47150 | bacek++ | branches/gc_massacre/src/gc/list.h:
Fix list macros.
rrot: r47151 | bacek++ | branches/gc_massacre/src (2 files):
Add TMS into command-line options.
rrot: r47152 | bacek++ | branches/gc_massacre/config/gen/makefiles/root.in:
Build TMS
rrot: r47153 | bacek++ | branches/gc_massacre/src/gc (2 files):
Initial version of TMS
rrot: r47154 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Initialize self.objects in constructor.
rrot: r47155 | bacek++ | branches/gc_massacre/src/gc/api.c:
Actually create TMS when requested
rrot: r47156 | bacek++ | branches/gc_massacre/src/gc (3 files):
Sketch implmenetation of TMS
kid51 got the same errors as mikehh doing make corevm && make coretest
I don't really understand why something that is described as 'core' can fail a test ... and then pass that same test when 'core' is built with 'ancillaries' (terminology used in config/gen/makefiles/root.in). 15:00
Why would the 'ancillaries' fix something that was failing in 'core'? 15:01
Moreover, why would something fail with "error:imcc:syntax error" in 'core' but not fail with syntax error when 'ancillaries' are added to the build? 15:03
bacek kid51, I suspect dynops/ops2c "misunderstanding" 15:04
ops2c depends on NQP/PCT 15:05
which should not be part of corevm.
nopaste "kid51" at 192.168.1.3 pasted "Two make coretest errors as run thru 'prove -v'" (104 lines) at nopaste.snit.ch/20744
kid51 Is that to say that the functionality being tested at the failure points should not be expected to pass at those points? 15:07
... or, given recent changes in trunk, should *no longer* be expected to pass at those points (i.e., prior to nqp-rx)
bacek Testing of functionality dependent on dynops should be moved out of coretest
kid51 Aha, so the tests now are 'prematurely run', in effect? 15:08
bacek E.g. splitting tests into two parts - one for coretest, one for test
kid51, yes.
look at t/op/sprintf.t line 489
kid51 I don't often do 'make corevm && make coretest'
So I don't have past builds and test runs as reference points. 15:09
bacek There is "sysinfo" op which is part of dynops now.
dalek rrot: r47157 | bacek++ | branches/gc_massacre/src/gc/gc_private.h:
Add GC_Sys.is_pmc_ptr.
 15:12
rrot: r47158 | bacek++ | branches/gc_massacre/src/gc/gc_ms.c:
Expose GC.is_pmc_ptr
rrot: r47159 | bacek++ | branches/gc_massacre/src/gc/list.c:
Fix removing items from 'other' list
rrot: r47160 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Fix Pool_Allocator.is_owned slighly by almost copy logic from contained_in_pool
rrot: r47161 | bacek++ | branches/gc_massacre/src/gc/list.c:
Sigh... Fix List.append again
rrot: r47162 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.h:
Rerun headerizer
rrot: r47163 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
First working version of TMS
rrot: r47164 | bacek++ | branches/gc_massacre/src/gc/system.c:
Quick hack to make trace_memory_block work with TMS
kudo: 5fc925c | smashz++ | src/core/IO/Socket/INET.pm:
Fail if can't create socket.
 15:21
kid51 TT created 15:23
dalek rrot: r47165 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Add bits of comments
 15:29
15:31 jan joined
dalek TT #1666 created by jkeenan++: t/op/sprintf.t and t/pmc/sub.t fail during 'make coretest' 15:38
TT #1666: trac.parrot.org/parrot/ticket/1666
kudo: 749fe91 | moritz++ | Test.pm:
[Test.pm] simplify eval_exception

need for nesting try { eval() } anymore.		 15:50
16:09 aukjan joined 16:12 khairul joined
nopaste "mariano" at 192.168.1.3 pasted "Problem in actions.pm with resizablepmc arrays @parrot-2.3.0" (20 lines) at nopaste.snit.ch/20746 16:21
mariano could you please take a look at nopaste, I'm having problems with NQP when shifting unshifting things 16:22
plobsing could you try figuring out if there's anything in the array between the unshift and the shift? 16:26
moritz like say(+$variable)
plobsing btw, shift/unshift is a degenerate case for the performance of RPA. using push/pop will be much faster.
mariano the code i pasted is the actual code 16:28
nothing in the middle
thanks for the tip about the pop/push
moritz rakudo: say ~3.2 16:29
sorry, wrong channel
plobsing yes, I'm asking you to put a debug print there. one of the operations is failing. I want to know which.
mariano says 0 16:31
so i think the push is wrong
I've changed it to push/pop
plobsing maybe this is a bug in autoviv. try initializing @?BLOCK with something 16:38
mariano how? 16:39
plobsing @?BLOCK = ( 'some', 'rubish', 'here' );
or maybe @?BLOCK = Array.new(); 16:41
or however NQP-rx gets at arrays 16:42
kid51 plobsing: If you get a chance, can you take a look at trac.parrot.org/parrot/ticket/1666 ? 16:53
possible fallout from ops massacre
cotto there's been a lot of that lately
dalek kudo: 8081285 | moritz++ | src/core/Match.pm:
make Match.Str return a Perl 6 Str
 16:54
kudo: c227238 | moritz++ | Test.pm:
[Test.pm] return comparsion result from is_deeply
plobsing seriously, what is with our test suite and calculating Pi? There are other irrational numbers people! 17:00
dalek TT #1667 created by jkeenan++: t/op/sprintf2.t: Misleading documentation 17:01
TT #1667: trac.parrot.org/parrot/ticket/1667
cotto We tried Īµ but it was too small. ;) 17:02
dalek rrot: r47166 | fperrad++ | trunk/tools/dev/fetch_languages.pl:
fix Mercurial command
 17:08
rrot: r47167 | plobsing++ | trunk/t/pmc/sub.t:
use something other than Pi for an irrational. avoids the use of dynop atan
mariano plobising: if I do @?BLOCK := (1,2,3); it works, so I guess your theory is correct about the autoviv
cotto phi is a nice number 17:10
plobsing mariano: I don't know enough about nqp to actually fix the bug. Now that we've isolated it, I suggest you file a ticket at trac.parrot.org. 17:14
mariano is there any guidelines for opening bugs? I'm asking cause I know how hateful is to read bugs without enough information 17:15
cotto just make sure there's enough information to reproduce the bug 17:16
mariano alright then, thanks 17:17
pmichaud @?BLOCK should autoviv. 17:18
but perhaps doesn't
16:26 <plobsing> btw, shift/unshift is a degenerate case for the performance of RPA. using push/pop will be much faster. 17:19
we use shift/unshift so that the current block is always in @?BLOCK[0]
speed is generally not an issue here anyway, there aren't that many blocks. 17:20
plobsing oic. I don't know much about PCT, but I do remember the performance bottlenecks we ran into when we changed over from Array to RPA everywhere.
pmichaud ...Array?
plobsing we had a general purpose Array PMC at one point 17:21
it had ... erm ... issues
pmichaud iirc, it wasn't resizable.
plobsing it was. you just had to accept a 1% chance of segfault 17:22
it was a linked-list of chunks. the code implementing that was quite hairy. not helped by the premature optimizations. 17:23
dalek kudo: fe19e82 | masak++ | src/Perl6/BacktracePrinter.pm:
[BacktracePrinter.pm] indented backtrace a bit

error message will be easier to spot.		 17:29
TT #1668 created by bluescreen++: NQP: Problem with arrays when unshifting/pushing 17:34
TT #1668: trac.parrot.org/parrot/ticket/1668
cotto mariano, you should try to reduce your code down to a self-contained test case. 17:38
mariano do you want me to attach that to the TT? 17:39
cotto sure
17:46 lucian joined
mariano doen 17:53
cotto That code seems to work fine. 17:54
It prints 1 17:55
mariano if you run it with parrot-nqp maybe 17:57
cotto how else would you run it/
?
mariano but running with parrot compilers/nqp/nqp.pbc bug.nqp
it was able to reproduce it 17:58
moritz nqp is deprecated
cotto yes
the real nqp lives in github and is copied into ext/nqp-rx on occasion 17:59
moritz and compiled to parrot-nqp
plobsing maybe old-nqp should printerr on startup to warn users
cotto +yes
moritz +1
purl 1
moritz botfail
cotto why is it still around
yes, purl is botfail
not that I don't love confusing newcomers 18:00
plobsing can't remove. deprecation policy and many old languages depend on it. can't ditch nqp without ditching "30 dynamic languages run on parrot" 18:01
mariano cotto: got it.. so my makefile has "compilers/nqp/nqp.pbc" what should I change it for?
plobsing whu? compilers/nqp doesn't exist in current trunk. guess it got axed 18:02
moritz mariano: what version of parrot are you using? 18:07
mariano 2.3.0, but before any speculation i started my project using parrot 1.4
pmichaud nqp was deprecated in 2.3.0 18:08
mariano so i was upgrading parrot and never change the makefile other than the parrot version
pmichaud so it was removed shortly thereafter
(the one in compilers/nqp)
mariano so should I "mk_language_shell" again? 18:09
pmichaud that might work. the language tools have evolved quite a bit over the last six months
mariano thx 18:11
18:19 joeri joined
plobsing coverage? 18:40
purl?
purl yes, plobsing?
plobsing cover?
urg. where are our coverage stats at?
Do I need a deprecation to remove some of the complex and braindead op rewriting rules in IMCC? 18:51
18:57 kid51 joined 19:06 ingy joined
moritz only if it implies semantic change for HLLs 19:25
dalek kudo: dd0e5dd | moritz++ | t/spectest.data:
run test file for line numbers in error messages
 19:44
rrot: r47168 | jkeenan++ | branches/tt1452_configure_debug:
Create branch to work on TT #1452.
 19:54
GeJ Good morning everyone. 20:11
cotto hio GeJ 20:34
arnsholt Does anyone know if NQP-rx can be made to work with a token being possible to interpret as both a term and an operator? 20:35
cotto what are you trying to parse that necessitates that? 20:40
20:42 plobsing joined
arnsholt cotto: Prolog 20:43
In some cases operators are valid literals 20:44
GeJ servus cotto.
arnsholt For example, the draft standard I'm using for reference cites this as a valid example: f(:-, ;, [:-, :-|:-]) 20:45
(Yes, you may now recoil in horror)
cotto all I see is a smiley getting progressively happier 20:46
cotto looks up prolog syntax
arnsholt f(':-', ';', [':-', ':-' | ':-']) is a more readable version 20:47
cotto I'm not sure I agree.
arnsholt [] is a list constructor, and the [ foo | bar ] construct is the same as (cons 'foo 'bar) in Lisp (if you're familiar) 20:48
Yeah, it's not much better
cotto I'll be quiet until I have something other than noise to contribute. 20:49
arnsholt Heh, right. Anyways, :- and ':-' are equivalent (and one of the central operators, incidentally)
So I need to figure out a way to allow the looser operators in certain contexts, but not in others 20:51
cotto I'd wager that pmichaud or some of the #perl6 folks would have enough familiarity with prolog to point you in the right direction. 20:52
arnsholt Probably a good suggestion 20:54
I just try to keep my Prolog project out of #perl6, since it's not strictly the right place =) 20:55
cognominal hi, is need_ext needed anymore in pmcs? I don't see that handled anywhere but they are still there in 1 pmc in parrot and 8 in rakudo 21:00
plobsing take it out and see where it fails tests 21:07
rand > 0.5 and s/where/if/
dalek rrot: r47169 | plobsing++ | trunk/DEPRECATED.pod:
deprecate logical vtables TT #1655
 21:18
cognominal plobsing, compiling, but bet that ATTRS feels the ecological niche previously occupied by the need_ext fossil 21:27
21:32 Patterner joined
dalek rrot: r47170 | jkeenan++ | branches/tt1452_configure_debug (26 files):
Begin to implement Parrot::Configure::debug().
 21:34
bacek Good morning, humans 21:37
mikehh hiho bacek
bacek aloha, mikehh
cotto bacek, the gc_massacre build works fine with tms but 'splodes with the default set to ms 21:38
mikehh bacek: how's your massa-cre branch goin'
cotto it's also funny becuase I'm used to tms standing for transcranial magnetic stimulation, which is completely not a gc 21:39
bacek cotto, I know. Last commit broke ms.
mikehh, pretty well :)
cotto, I'm planning to replace ms with tms and rename it to ms. 21:40
cotto ms is really that useless?
bacek ms is really very naive. 21:42
cotto good for you hacking out tms so quickly 21:45
bacek cotto, I spend about month thinking how to make it :) 21:46
21:46 aloha joined
bacek A-ha! It works :) 21:46
aloha, cotto
cotto is that your bot?
bacek yeap
cotto does it do anything? 21:47
bacek nope :)
cotto and is it running in Parrot?
plobsing it allows autocompletion!
bacek plobsing, it's sole purpose of this bot :)
plobsing aloha++
bacek cotto, hmm. Good idea. Care to migrate POE to parrot? 21:48
cotto aloha, aloha
plobsing is the structure of POE necessary in the presence of full CPS? 21:49
bacek plobsing, not really. But Bot::BasicBot runs on POE. 21:51
22:02 mikehh_ joined
plobsing what non-toy HLLs (beyond rakudo) are in a resonably testable state? I'm looking to make sure some changes I want to make don't affect anything. 22:02
bacek plobsing, lua 22:06
or partcl-nqp afaik
arnsholt And nqp, I suppose? 22:08
plobsing nqp is dead 22:09
nqp-rx ftw
sorear that said, if rakudo works, nqp does 22:10
plobsing parrot lua? 22:11
lua?
damnit purl!
bacek purl, lua? 22:12
purl bacek: no idea
bacek purl, lua is github.com/fperrad/lua
purl OK, bacek.
mikehh opbots, names 22:14
arnsholt plobsing: Er, right. That's what I meant 22:16
I've not really done anything with old nqp, so nqp-rx is just nqp to me =)
sorear plobsing: You should also check out winxed. The author refuses to use PCT, so it's probably a much better test than Yet Another NQP Language 22:17
22:21 mariano joined
dalek rrot: r47171 | bacek++ | branches/gc_massacre/src/gc (2 files):
Rename PoolAllocator.attrib_size to .object_size
 22:24
rrot: r47172 | bacek++ | branches/gc_massacre/src/gc (2 files):
Always use lazy allocator in PoolAllocator.
rrot: r47173 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Allocate 'constant' PMCs from separate pool
plobsing sorear: winxed is my favorite parrot language. it's the first one I check. 22:27
22:29 mariano joined
plobsing rakudo spec is tl;dnr 22:30
22:31 bluescreen joined
plobsing removing misfeatures from 2003 is fun 22:40
dalek rrot: r47174 | plobsing++ | trunk (5 files):
Eliminate <cmp_op>_(str|num) virtual ops (AKA IMCC op rewrite rules).

are generally a bad idea, and are unused. If these ops are actually desired, they should be added as real ops that DTRT.		 22:41
nopaste "mikehh" at 192.168.1.3 pasted "make corevm/make coretest 1 remaining failure" (20 lines) at nopaste.snit.ch/20754 22:43
plobsing ooh. palendromic commit number!
mikehh: noted. see TT #1666 for discussion. 22:44
mikehh make corevm/make coretest 1 remaining failure - see: nopaste.snit.ch/20754
all other tests PASS (pre/post-config, smoke (#34138), fulltest) at r47170 - Ubuntu 10.04 i386 (gcc with --optimize)
t/op/annotate-old.t - TODO passed: 1 in testf 22:45
t/op/exit.t - TODO passed: 6 in testf
sorear bacek: What does gc_tms do? Just non-incremental tricolor? 22:47
(Why is it called GC Massacre if you're adding GCs?)
bacek sorear, yes. It's described on GCMassacre wiki page
sorear, I'm going to kill Memory_Pools, old GC, and maybe few kittens 22:48
22:48 hercynium joined
mikehh plobsing: there's just the one remaining test failing and I have tested on both i386/amd64 with gcc/g++ with qnd without --optimize 22:48
and
also the with the TODO passes, the first seems to pass on bot amd64 and i386 in testf but the latter only on i386 22:50
both
bacek: as long as you leave the poor puppies alone :-} 22:51
cotto rrot: r47177 | cotto++ | branches/puppy_massacre:
Create a branch to remove all puppies. We only like parrots.
 22:54
bacek LOOOOL 22:55
mikehh cotto: ROFL - should have thought of that :-} 22:56
plobsing ENOPUPPIES
cotto It's a short-lived branch. 22:57
not unlike the puppies
dalek rrot: r47175 | bacek++ | branches/gc_massacre/src/gc (3 files):
Made Memory_Pools optional during gc_mark_root
rrot: r47176 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Remove allocating of Memory_Pools in gc_tms. They are not needed anymore
NotFound Winxed is not a very good test not just because of not using PCT, also because It doesn't have lexicals. 23:02
And don't HLL map. So you can break a lot of important parrot parts without affecting winxed. 23:03
BTW I don't "refuse" to use PCT, I just don't use it. 23:04
sorear What's the difference? 23:05
NotFound Refuse sounds pejorative to me.
sorear ah. 23:06
dalek tracwiki: v59 | bacek++ | ParrotQuotes 23:12
tracwiki: No puppies!
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
23:29 snarkyboojum joined
mikehh bacek: should I regen manifest etc in gc_massacre branch 23:30
bacek_at_work mikehh, not really. It's long way before branch will be ready for codetest fixes. 23:41
mikehh bacek_at_work: 'k just testin' then 23:46
NotFound About whiteknight's 1.000 man-hours estimate to build a compiler on top of Parrot: I wrote most of winxed in two months. 23:51
Calendar months, not work time ;) 23:53
sorear How sophisticated is winxed?
NotFound A lot less than perl ;) 23:54
But is a compiler anyway.
mikehh heading back to amd64 - bbiab 23:55

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!