Re: GC design

y aligned ones) As long as the C stack is guaranteed to be contiguous, this should be portable. I'm not sure if that is guaranteed by ANSI C, however. Has this already been considered and explicitly rejected? Thanks, Mike Lambert

Re: Hashtable+GC problems

might point at. Now you have immobile memory that's efficient to allocate, good at avoiding memory fragmentation, and good for you to do with what you please. Once we figure out how hashes are implemented well, we should probably write up some guidelines on when to use what kinds of headers, et.c Thoughts? Mike Lambert

Re: Hashtable+GC problems

others? Thoughts on why we should/shouldn't implement this kind of thing in parrot, below the buffer level? Thanks, Mike Lambert PS: In case you're confused...yes, I was replying to myself. :)

Re: [netlabs #629] [PATCH] Memory manager/garbage collector -majorrevision

uire modification. I think these guidelines make it easy for non-GC-programmers to writ GC-dafe code, since they do not need to be aware of what allocates memory, and what does not. What do people think of this approach? Mike Lambert

Re: [netlabs #629] [PATCH] Memory manager/garbage collector -majorrevision

unction is nenoate, everything we construct into this base pmc should be contiguously neonate, if that makes sense. Granted, it's a little bit expensive to do the tracing, but you shouldn't need to trace too deep at all, and its time is proportional to the size of the nested data structure you

GC Benchmarking Tests

ing to help compare every aspect of our GCs? Real-world programs are too hard to come by. :) Results of the above test suite on my machine comparing my local GC work and the current parrot GC are coming soon... Enjoy! Mike Lambert PS: If you get bouncing emails from me because my email server is down, I

Re: [netlabs #642] GC Bench: Collection Pool Bounds

ough my comments still stand about looking for an adaptive pool sizing system). Thanks for bearing with me on this, Mike Lambert

Re: [netlabs #636] GC Bench: out-of-pool-memory logic

uite efficient. It also makes me realize that a slower rampup here would probably be a better test. I guess it also raises some suspicion about the other test results. Ah well, we need a fix for our GC problems anyway... Mike Lambert PS: I'm currently operating under the assumption that these ki

Re: GC Benchmarking Tests

aren't done, this will demonstrate poor performance due to the old headers not getting marked as unused, and it needing to allocate more memory blocks. I think it is *because* they measure how fast parrot is at copying string that these are good tests. GCs which avoid copying will perform better on these. Mike Lambert

Re: GC Benchmarking Tests

er rampup that should allow for more iterations, while still testing the same thing. Mike Lambert

Re: vtables and multimethod dispatch

the simple ones fine, PMC->PMC conversions are essentially multi-dispatch, and imo, should be treated as such. This might only matter with strong typing, but it might also help with the differently-organized mathematical libraries: assuming no binary operators are written, one only needs to write conversions, to allow them to interoperate, if slowly. Thoughts? Am I taking it too far? Mike Lambert

Finding closure in the continuous forest

sender' on it. I'm not sure how to describe pointers in the forest to the surrounding mountains, however. Rainbows with a pot of gold at the mountainous end? Telescopes on the ground which can be moved and rotated? Mike Lambert

Re: Adding the system stack to the GC

for the OS/platforms which need it differently? resources.c? .c? Maybe in resources.c with each .c calling the generic one in resources.c (since win32, generic, darwin, etc are all likely to share the same logic.) Mike Lambert Dan Sugalski wrote: > Date: Fri, 12 Jul 2002 13:05:54 -0400 > Fr

Re: coders: add doco

rom my vantage point, documentation is bad only if someone attempts to learn a particular area of the code and has trouble because of the lack of, or inadequacy of, the documentation for that task. Have you attempted to learn every aspect of parrot, such that you can verifiably say that all of parrot&#

Re: Adding the system stack to the GC

into valid collectable memory (making it slower), we still have the issue of buflen being set to MAX_INT or something, and killing the system. :| The same caveats apply to pmc headers which happen to have PMC_buffer_ptr_FLAG set. How should we get around this particular problem, or is it spelling the doom of this particular solution? Thanks, Mike Lambert

Re: [perl #814] [PATCH] fix PMC type morphing

and then set the new value. This pattern is currently utilized in the string PMC methods, but not with the number-related methods. So in conconclusion, while I don't have any reservations about your patch, I do have a preference that it be done differently. :) Mike Lambert

Re: [perl #823] [PATCH] put numeric comparisons in the right order

ate between 1^30 and 1^30+1^0, since 30 - 0 > 23. Am I missing something here? Thanks, Mike Lambert

[COMMIT] Major GC Refactoring

changes to get the tests passing on all platforms, again. And then try it with JUST the stackwalking code to avoid neonate problems. Thanks, Mike Lambert

[COMMIT] GC Speedup

0.987 gc_waves_sizeable_headers.pbc 1.000 0.855 Overall: old 1.000 new 0.925 Details of what were done to accomplish this can be found in my email to the cvs-parrot list. It was pretty much 4 or 5 distinct things that each gave a couple percentage points' improvement. Thanks, Mike Lambert

Re: [PATCH] genclass.pl patch

Josef Höök wrote: > I've added an if case in genclass so it will print > "return whoami;" for "name" function so that no one need to grep parrot > source for an hour or two trying to figure out why it segfaults when > registering pmc class in init_world... (

More Keyed Questions

be any overlap at all, so set_keyed_integer could safely be named set_keyed. Can we safely remove "set ", due to the relative inefficiency in constructing dummy PMCs to call it? Wouldn't it be more efficient to split the call into two "set PP*",and "setP*P" calls? Thanks, Mike Lambert

Re: [perl #15317] [PATCH] Recursive keyed lookups for array.pmc

Applied, thanks. If someone wants to mark this ticket as resolved, I'd appreciate it. Mike Lambert Scott Walters wrote: > Date: Mon, 22 Jul 2002 08:49:33 GMT > From: Scott Walters <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Sub

Re: [COMMIT] GC Speedup

know that there are faster solutions to the problem of child collection, but Dan doesn't want to use them due to the problems that occur when we start using exceptions (and longjmp, etc). Perhaps, if the above performance hit is due to trace_system_stack, it might give reason to reconsider the chosen solution? Thanks, Mike Lambert

Re: [patch] win32 io

> * win32 can flush it's file buffers (FlushFileBuffers()) > * SetFilePointer knows about whence, win32 constants (values, not names) are the >same as in linux. Applied, thanks. Mike Lambert

Re: PARROT QUESTIONS: Keyed access: PROPOSAL

ve been addressed, > with the one exception of refactoring code bloat. I feel this is a small change > in implementation, and shouldn't impact design. I hope Dan will (pending time) > consider it, and I'll be happy to hash it out with him on IRC to make sure > both parties understand exactly what is being said and that I don't continue > to miss things ;) Hopefully I've helped to explain some of the things you said you were unsure about. Of course, since I'm not Dan, you might very well hear something completely different when he gets back from TPC. :) Mike Lambert

[PATCH] Reduce array.pmc keyed code

r own get_pmc_keyed ? Thoughts, comments? Mike Lambert

Re: [PATCH] Reduce array.pmc keyed code

> This patch is rather questionable, and thus I did not commit it > directly. However, it illustrates a point I wanted to make. Doh! Hopefully my previous post will make a bit more sense now. :) Mike Lambert Index: arr

Re: [COMMIT] GC Speedup

. Unfortunately, until we have a wide test suite of programs, or start implementing adaptive adjustment of GC parameters, I have a feeling we're just going to travel around in circles. Mike Lambert

Re: [COMMIT] GC Speedup

. To really determine their worth, we need real-world programs, and figure out how often would they be using longjmp, and external code, to determine how often the bookkeeping is wasted. But that brings me back around to the point in my previous email, about the mythical "real world program". :) Mike Lambert

Re: [PATCH] Reduce array.pmc keyed code

he main changes that I see are: - the elimination of the keyed versions for all the mathematical vtable methods - the addition get_keyed_ref method - the addition of mathematical keyed *ops* that use get_keyed_ref to "do their thing" ? - perhaps some method for storing the keyed_ref result

Keyed multiplication

at insights into "the way things (should) work". Of course, the possibility exists that I am completely missing something, and this truly is a simple question. :) Thanks, Mike Lambert

Re: [perl #15724] [BUG] GC bugs

;), but I'm not really sure of any cleaner ways to do it. If you have any suggestions, please feel free to mention them. Anyways, I've committed fixes for both of these issues. Thanks again. Mike Lambert

Re: [perl #15730] [PATCH] Fix typos

> Fixes a few typos and tidies up capitalization in dod.dev > > Simon Applied, thanks. Mike Lambert

Re: [perl #15731] [PATCH] Silence warning

> Patch below kills a couple of warnings that cropped up because > alloc_more_objects was renamed to alloc_objects in the code but > not the headers. Also updates the comments. > > Simon Applied, thanks. Mike Lambert

Re: [perl #15845] [BUG] GC segfault

Applied with some modification, thanks. Mike Lambert Richard Cameron wrote: > Date: Wed, 31 Jul 2002 22:24:55 +0100 > From: Richard Cameron <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [perl #15845] [BUG] GC segfault > > > On

Re: [perl #15948] [PATCH] Configure broken on windows 9x

Applied, thanks. Mr. Nobody wrote: > Date: Fri, 02 Aug 2002 20:57:57 GMT > From: Mr. Nobody <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15948] [PATCH] Configure broken on windows 9x > Resent-Date: 2 Aug 2002 20:57:57 - > Resent-From: [EMAIL PRO

Re: [perl #15949] [PATCH] Silence warning in hash clone

Applied, thanks. Mike Lambert Simon Glover wrote: > Date: Fri, 02 Aug 2002 21:00:19 GMT > From: Simon Glover <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15949] [PATCH] Silence warning in hash clone > Resent-Date: 2

Re: [perl #15951] [BUG] header_allocs_since_last_collect neverupdated

Fixed, thanks. Mike Lambert Simon Glover wrote: > Date: Fri, 02 Aug 2002 21:19:29 GMT > From: Simon Glover <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15951] [BUG] header_allocs_since_last_collect never > updated >

Re: [perl #15952] [PATCH] Minor doc fix in core.ops

Applied, thanks. Mike Lambert Simon Glover wrote: > Date: Fri, 02 Aug 2002 21:39:13 GMT > From: Simon Glover <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15952] [PATCH] Minor doc fix in core.ops > Resent-Date: 2 Aug 2002

Re: [perl #15953] [PATCH] More GC tests

Applied, thanks. Mike Lambert Simon Glover wrote: > Date: Fri, 02 Aug 2002 21:40:51 GMT > From: Simon Glover <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15953] [PATCH] More GC tests > Resent-Date: 2 Aug 2002 21:40:52 -00

Re: [perl #15943] [PATCH] UNICOS/mk vs dynaloading continues

Applied, thanks. Mike Lambert Jarkko Hietaniemi wrote: > Date: Fri, 02 Aug 2002 15:03:21 GMT > From: Jarkko Hietaniemi <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [perl #15943] [PATCH] UNICOS/mk vs dynaloading continues > Resen

Re: [perl #15942] UNICOS/mk new unhappiness: hash.c

, whereas pointers are shallow). Of course, one could argue that the previous one didn't work at all. :) Thoughts? Mike Lambert Sean O'Rourke wrote: > Date: Fri, 2 Aug 2002 08:20:58 -0700 (PDT) > From: Sean O'Rourke <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [

Re: Unifying PMCs and Buffers for GC

ick it on the DOD list so that it can be properly traced later. This then requires that each buffer contain a next_for_GC pointer, so it can be added to the to-do list. Alternately, we can use pool-specific memory to handle the various pointers that are required for DODbut the point remains that this further increases the memory footprint of buffers, and I wanted to verify that it was okay. Comments and/or suggestions, please? Thanks, Mike Lambert

Re: Unifying PMCs and Buffers for GC

Mike Lambert wrote: > One idea, which is most closely in line with the current semantics, is to > add a pool pointer to every header. I've found a few times in the past > where such a pointer would have come in handy. This would allow us to call > the pool's mark() function

Re: Unifying PMCs and Buffers for GC

ies that this buffer contains pointers to other data structures, and should be traced. If this is unset, the buffer doesn't get added onto the free list. Since adding it to the free list requires adjusting next_for_GC, it's already going to reference memory there. Checking the flag would merely prevent traversing the memory again in the 'process' portion. Thanks for the quick reply, Mike Lambert

[COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

other that got lost in the noise of the above issues Anyone more well-versed in these departments than I care to take a look at the potential problems? Just change GC_DEBUG in parrot.h, and you can be on your way. :) Thanks, Mike Lambert

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

n test_main.c, above all possible functions. I think 1 is easiest, but 3 does have the advantage of allowing the user to do GC stuff outside of the parrot execution loop, like allocating global variables (like argv, but app-specific), etc. Of course, it also imposees additional coding overhead on the embedding programmer. Mike Lambert

The Perl5->Perl6 Convertor

sible avenues now, to be discarded as we approach the implementation phase and realize the scope of the project. :) Thanks, Mike Lambert

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

at a few of the early buffer creations do not >return the same buffer (provides early warning of GC mischief) Oooh, nice! :) The rest of the things you listed, which I didn't comment on are, imo, perfectly fine. In conclusion, I don't have any objections to this patch, although it would be nice if "XXX Unification" markers were included in places that needed to be addressed later. Mike Lambert

Re: [INFO] The first pirate parrot takes to the air

, I'd be interested in seeing a patch. I can work on integrating a lot of your non-forbidden code into the current codebase. Thanks for spending the time to generate these numbers...they're a nice eyeopener on what can be done without the current restrictions. Hopefully they'll allow us to reconsider each restriction in the context of the speed of our GC. Mike Lambert

Re: [INFO] The first pirate parrot takes to the air

hile I get a 17% speedup on life, I get a 5% loss on hanoi. Since you only posted life, it's a bit hard to see if the drop on hanoi is just my fault, or the fault of COW in general. (More benchmarks will appear in my soon-to-be-sent COW patch email.) Thanks, Mike Lambert

Stack Walk Speedups?

be able to alleviate this in the long run. Anyone feeling adventuresome and want to attempt to speed this up? It should be an easy introduction to the GC code in general. Just start out in trace_system_stack, and work your way down. Mike Lambert

Re: [perl #16278] [PATCH] Quicker pointer checking for stack walking

Applied, thanks. > Moved the static prototype to dod.c > > Jason

Re: [perl #16219] [PATCH] stack direction probe

Applied, thanks. Mike Lambert > This is a config test for the direction of stack growth that makes > the direction a compile time constant. > > -- > Jason

Re: [perl #16274] [PATCH] Keyed access

? Overall, tho, the patch looks extemely complete. Tracing support, disassemble.pl support, debug.c support, etc. You even reduced macro usage. Rather impressive. :) Thanks, Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

make it drop even further by fixing this memory leak. The fact that both COW's require roughly 3x *more* memory is quite surprising. If you (or anyone else) feels like attempting to figure out where our memory is going, I would greatly appreciate it. I'm stumped over here, and am getting frustrated. (That's why I'm writing this email and going to sleep ;) Thanks, Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

mory due to sharing, it also makes when-to-collect logic break, and break our balance of collection frequency and new-block-size, leading to an apparant memory usage increase. I can't really think of any other cause. Personally, I find that COW logic makes things a bit more complex, and some

Re: [perl #16048] [PATCH] Eliminate alignment warning in packfile.c

s with asserts, and includes parrot.h. Then the main() function could assert on all of the necessary conditions. Configure would compile and run this program to ensure correctness. Thoughts? Anyone want to take a crack at it? Mike Lambert

Re: [perl #15907] [PATCH] Make warnings configurable

> fixed before I was able to submit a patch. Looking at the patch, it seems rather GCC-specific. The checking for "no-X" versus "X" in the warnings flags seems to be rather non-portable to compilers like MSVC. Unfortunately, I don't believe this is easily fixable. Mike Lambert

Re: [perl #16283] parrot dandruff

for their pointer pickiness. Applied, thanks. > On IRIX, though, I get these, where probably NO_STACK_ENTRY_TYPE is > meant instead. Applied as well. Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

create lots of strings of varying lifetimes, so it's unreasonable to expect any better performance on it. So, now that the major objections to the previous patch have been addressed, does anyone have any reasons against this patch going in? Thanks, Mike Lambert Index: core.ops

Re: [perl #16300] [BUG] hash clone hangs

27;s C target. Secondly, can you please turn off strip-trailing-whitespace in your editor? Your patches are reflecting the stripped spaces, which makes it hard to discern intentional changes from accidental ones. Thanks, Mike Lambert

Re: [perl #16308] [PATCH] logical right shift

> This adds logical shift right opcodes. They are essential for bit shifting > negative values without sign extension getting in the way. Applied, thanks. Mike Lambert

Re: [perl #16274] [PATCH] Keyed access

AD wumpus", and watch it die on "Not a string!". It could be that basic is using keys in weird ways, or it could be that the key patch is borked...I haven't looked into it enough to determine the true cause here. Thanks, Mike Lambert

Re: GC generation?

ational count. So in conclusion, generational systems can be done using at most a byte or a short, and it's even possible to do them with nothing at all. So until the need arises, I don't think the generations count would be worth it. Especially since I plan to try and prove the need for a header pool pointer at some point. :) Mike Lambert

Re: [perl #16274] [PATCH] Keyed access

Tom Hughes wrote: > Index: basicvar.pasm > === ... > Index: instructions.pasm > === ... Fixes the bug, and wumpus plays yet again. Applied, thanks. Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

I'd love to see the other ideas you had mentioned in your previous emails that hadn't yet made it to grey, as some of them didn't sound entirely illegal. You said that parroy grey was a fun project to play around with performance numbers, and I'd hate to be the reason you stopped having fun. :) Thanks, Mike Lambert

Re: DOD etc

or things that need to free resources. Other than the above, I'm not sure what other methods could be used to force destruction. And I'm not sure if a decree has been made about what Perl6 will do. Mike Lambert

Re: Possible bug in new string COW code

on there was to only copy as much data as was needed when we uncowify a buffer. I believe changing strlen to bufused is the proper fix, and have committed said change. Thanks, Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

trings, then the second sweep performed would eliminate the wasted memory copy. Not quite as fast in eliminating the memory usage as the above solution, but since we are guaranteed of collections happening throughout the lifetime of any program that does something with strings, I think it's an okay tradeoff. Were there any other reasons for implementing the above linked list technique that I missed? Thanks, Mike Lambert

Re: [perl #16269] [PATCH] COW...Again and Again

> On Wed, Aug 21, 2002 at 04:17:30AM -0400, Mike Lambert wrote: > > Just to complete this thread, I have committed the current version of my > > COW code, as I promised earlier this week. > > Did you try running tests with GC_DEBUG on? I get numerous failures. > Here&#x

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

in32 folk out there want to try this patch and see if it resolves any issues for you? Thanks, Mike Lambert Index: config/gen/makefiles.pl === RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v retrieving revision 1.2 d

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

CVS checkout on win32, and is using cygwin or msvc, they can do: Configure.pl && cd languages\perl6 && make && make test And it should proceed to properly pass all of the compiler tests, aside from 8_5 and 8_6, which are a bug with the perl6 compiler somewhere (verified by sean and leo). Mike Lambert

Re: DOD etc

till a need for determinstic destruction, even in light of the alternative approaches mentioned above? Thanks, Mike Lambert

Re: [perl #16818] [PATCH] Build cleanup

er -shared to work properly. The Makefile was built using cygwin perl (that's why its using cygwin GCC), so perhaps cygwin perl's $Config{lddlflags} is incorrect? Any ideas on how to resolve this? Thanks, Mike Lambert

Re: [perl #16820] [PATCH] Build libparrot.a with ar and ranlib

) > The following patch changes the main makefile to use ar and ranlib, just > as perl5 has successfully done for years. Applied, thanks. Mike Lambert

Re: [perl #16852] [PATCH] Eliminate empty extension

pm, since it hijacks lib/Parrot/Test.pm to get its functionality. I'll probably apply this after the code opens up again, but if someone beats me to it, please be sure to update the affected file above. Thanks, Mike Lambert

Re: [perl #16855] [PATCH] uselessly optimize print()

apply this once Parrot 009 starts up again. Although at some point, we should go 100% in converting the IO in core.ops to use parrot io, or convert the tests/programs over to using io.ops. (Not sure which way we want to go.) Mike Lambert

Re: [perl #16857] [PATCH] minor refactoring in dod.c

llected. I agree with the resources.c patch to fix external, but I'm not sure about this one. Mike Lambert

Re: [perl #16859] [PATCH] Fix BUFFER_external_FLAG for strings

imagine we could either: a) make them act identically, like this patch does b) just have people who want external data to unset selfpoolptr. Thoughts? Mike Lambert

Re: [perl #16874] [BUG] Concatenation failing

ds. I wanted to get a simple interface implemented for using COW, such that it would be easy to understand, and then later optimize it for actual usage scenarios. I imagine that unmake_COW could be extended to take 'pre' and 'post' byte arguments, and would pad the resulting s

Re: Conditional makefile generation (Was Re: [perl #16856] [PATCH]various changes to imcc)

re any fundamental reason why we *cannot* just enter a generated imcparser.c and imcparser.h into CVS and save users the step of building them on these platforms? It's just an additional parrot depenendancy which doesn't need to be there, and may come in handy when trying to build on a lot of the more arcane platforms. Mike Lambert

Re: [BUG] GC collects argv aka P0

lt of unimplemented external-ness, in which case, applying Steve's fixes should make this problem go away. Mike Lambert

Re: [PATCH] in makefile, move libparrot.a from "test" to "all"

hat a static interface doesn't change behavior on us, etc. Currently however, neither a nor b are implemented, and so the t/src/* test have no direct dependancy upon libparrot.a/lib and libparrot.so/dll, and so can probably be removed. If it helps make 0.0.8 build on more platforms, it might b

Re: [perl #16895] [PATCH] core.ops, ops2c.pl

nt them to act. As such, the above argument could be correct or incorrect depending upon exactly how they are defined. :) Mike Lambert

Re: Conditional makefile generation (Was Re: [perl #16856] [PATCH]various changes to imcc)

idea on how to go about fixing the rx ones? They're failing on imc->pasm, with msgs like "NO Op rx_pushmark_ic (rx_pushmark<1>)" Mike Lambert Index: config/gen/makefiles/imcc.in === RCS file: /cvs/public/parrot/co

Re: auto deserialization

example is somewhat contrived, but I still believe it illustrates a problem which *will* arise in practice. Mike Lambert

Current Perl6 on MS Win32 status

k 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ok 10 # ' No idea on where the missing "ok 10" went. If people would like the p6/imcc/pasm/pbc files, I can provide them. Just let me know. Mike Lambert

Re: [perl #16852] [PATCH] Eliminate empty extension

/perl6/P6C/TestCompiler.pm, since > it hijacks lib/Parrot/Test.pm to get its functionality. I'll probably > apply this after the code opens up again, but if someone beats me to it, > please be sure to update the affected file above. Applied, thanks, Mike Lambert

Re: [perl #16855] [PATCH] uselessly optimize print()

e still buggy > > with respect to supporting different encodings. I don't know if > > printf("%s") is any better than fwrite in terms of at least vaguely > > paying attention to your locale or whatever. If so, don't apply it. > > > > (all tests pass) Applied, thanks, Mike Lambert

Re: Current Perl6 on MS Win32 status

type on top of stack! # ' # expected: '678910 # 1112131415 # ' The first was a GPF, the second was just incorrect output. I'm not sure if this is progress or not, but I believe it might adversely affect other platforms. I don't have time to look into the issue now, but I'll try to do so tomorrow. Mike Lambert

Re: Tinderbox "TD-ParkAvenue" not working

ould be removed from the > tinderbox. Yes, I had noticed that. And that struct me as strange, particularly because that machine had worked before, but isn't working now. I'll remove it from the list of machines it connects to. Mike Lambert

Re: [perl #17495] [PATCH] for a faster life

ately, is it possible to allocate this jump table in the system heap (malloc et al), and store only a pointer to it on the stack? Mike Lambert

Re: [INFO] parrot with Lea malloc - 50% faster life

ction is failing.) > I didn't look further into memory usage or such, though top seems to > show ~double the footprint of CVS. I think Dan would disallow such a patch for this reason alone. We're already taking a 2x hit (peak) by using a copying collector. No need to make it worse. :) Mike Lambert

Re: Paren madness (was Re: Regex query)

ple is perfectly fine?) What about: $a = 1,2,3 ($a) = (1,2,3) $a = (1,2,3) ($a) = 1,2,3 Do you still believe those should be identical? They have the same problems mentioned above, and likely other issues as well. Mike Lambert

Re: Of PMCs Buffers and memory management

rs have to be PMC/buffers. Just as we have an make_interpreter to create an interpreter, we can have an unmake_interpreter that destroys the interpreter. I don't think we want interpreters appearing and disapppearing with references...they should be explicitly created and destroyed. But that's a discussion for another thread. My point is that all things don't need to be traced, and some stuff can be handled manually, as long as the perl programmer doesn't see it directly. Hope this helps answer your questions, Mike Lambert

Re: Of PMCs Buffers and memory management

ugh, if nested structures inside the interpreter are all buffers, > destroying them would neatlessly fit into the framework. Yes, it would. But a lot of the interpreters structures have data fields, and those don't work too well as buffer data. They could work as part of a sized buffer header, I s

Re: RFC: library entry name collision

Second: intlist is not the only culprit. ./classes/key.c and ./key.c have a similar problem. Mike Lambert

Re: exegesis 5 question: matching negative, multi-byte strings

(.*) } "a union" => "a " "b" => "b" Am I missing something here? Mike Lambert

Re: Private contracts?

on is not really a problem since one can always add additional checks. However, if the parent's preconditions apply to the child invariably, it would be rather difficult to make your subclass accept a wider variety of input. I'm not proposing a solution, but rather just a problem to keep in mind. Mike Lambert

  1   2   >