Purify Output

I just ran purify against the current Parrot CVS as of today at 10 AM PDT. Here are the results: jwilmes@jwilmes-sun:/apps/users/jwilmes/devel/parrot$ ./test_prog test.pbc Purify instrumented test_prog (pid 2187 at Wed Sep 12 10:05:34 2001) * Purify 5.2 Solaris 2 (32-bit), Copyright

another purify run

FYI.. There are a few interesting things in here which look like they may be real errors. (i'd ignore the PLKs for now) --Josh perl assemble.pl t/test.pasm t/test.pbc ./test_prog t/test.pbc t/test.out Purify instrumented test_prog (pid 17982 at Thu Sep 13 02:08:41 2001) * Purify

Re: another purify run

-0700, Josh Wilmes wrote: There are a few interesting things in here which look like they may be real errors. (i'd ignore the PLKs for now) Thanks for doing this, but to be honest, I expect our memory allocation to be all to hell because we have no freeing and no garbage collection

Automated Purify Run

This time i've filtered out all the memory leak related data so all that shows up are legitimate errors. (hopefully) I have set up a cheesy script to update the following URL with the current output of purify on the current CVS test_prog (test,test2,test3,euclid) every hour.

Re: Automated Purify Run

every day. Can we get it to run every hour? Perhaps even on demand? I think I have fixed all of the memory access errors but one. -Original Message- From: Josh Wilmes To: [EMAIL PROTECTED] Sent: 9/15/2001 5:16 PM Subject: Automated Purify Run This time i've filtered out all

Re: Automated Purify Run

: The hourly should be fine...can you do me one other favor and run the following c snippet through Purify: int main() { char* c = (char*)malloc(0); printf( %.*s\n, 0, c ); return 0; } -Original Message- From: Josh Wilmes To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 9

Re: parrot-nightly

At 1:30 on 09/18/2001 BST, Simon Cozens [EMAIL PROTECTED] wrote: On Mon, Sep 17, 2001 at 10:38:35AM -0500, Jonathan Scott Duff wrote: Parrot/Opcode.pm only uses Digest::MD5 for fingerprinting the opcode file which could be done without Digest::MD5 IMHO. For instance, using unpack() to

Re: Name lengths in C code

At 13:16 on 09/21/2001 EDT, Uri Guttman [EMAIL PROTECTED] wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote: The names are unique in the first 31 chars. Are we OK, or do I need to mangle the names? I could mangle them by

Re: Strings db

We could use the bsd gettext though, couldn't we? --Josh At 12:49 on 09/24/2001 PDT, Wizard [EMAIL PROTECTED] wrote: Michael Maraist wrote: But wouldn't that make parrot GPL'd? Yes, Yes it would. (cup o' coffee and a sux donut, please.) Never mind. I'll take a look at the docs and look

[Patch] fix docs in Parrot::Opcode

Here's a fixed version of that patch I sent a while back: Index: Parrot/Opcode.pm === RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v retrieving revision 1.7 diff -u -r1.7 Opcode.pm --- Parrot/Opcode.pm2001/09/20 14:39:17

[Patch] A bit of linting

(either casting to void or doing something with them) - cast IVs to (unsigned int) when printfing them with %x. - remove unused variables (only in one function) - return a value in some places where there was a void return but the function had a return type. --Josh -- Josh

coding standards PDD?

What's the state of the coding standards? This is the last draft of it i've noticed in the archives: http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html Is this going to become a PDD or at least move into the doc directory for parrot? --Josh -- Josh Wilmes ([EMAIL

size_t?

, though. It'd feel a little less silly if i was only casting in one direction. Is there a reason not to convert the memory subsystem to use size_t for all its length parameters? --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

[Patch] Lint, take two.

Here's a replacement for my previous patch. This one includes the following: Makefile target for lint (runs lclint with some very permissive settings) Fixes some ignored return values A few minor casts. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org Index

Re: Revamping the build system

It seems to me that we should look at cons before writing Yet Another Perl Build System. (i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ --Josh At 12:18 on 10/11/2001 PDT, Robert Spier [EMAIL PROTECTED] wrote: | I'm OK

Re: Alt. means of communication

If anyone is interested in a non-IRC discussion system, there's something I use called lily. Its main feature for this sort of thing is that it does server-side logging of discussions and allows you to detach and review what you've missed. If anyone is interested, the URL to sign up is

[Patch] Check for nonempty string before printing

)string_length(s),(char *) s-bufstart); + } } -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: [Patch] Just some -Wall cleanups

Oops. Sorry, i'll attach it next time. --Josh At 11:10 on 12/13/2001 EST, Dan Sugalski [EMAIL PROTECTED] wrote: At 11:33 PM 12/12/2001 -0500, Josh Wilmes wrote: Here are a few of the more clear-cut fixes I noticed from -Wall's whinings. Applied, with some hand-patching. (Your mailer

attempts to clean up a few warnings

I'm no sure if i've submitted some of these before, but here goes. Diffs against current cvs: Index: Configure.pl === RCS file: /home/perlcvs/parrot/Configure.pl,v retrieving revision 1.39 diff -u -r1.39 Configure.pl ---

POD cleanups for core.ops

This makes it pass podchecker and look more aesthetically pleasing. Index: core.ops === RCS file: /home/perlcvs/parrot/core.ops,v retrieving revision 1.53 diff -u -r1.53 core.ops --- core.ops20 Dec 2001 01:53:14 - 1.53

[Updated Patch] Core.ops pod, misc cleanups, and gcc -Wall

. Here they are (attached): -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org Index: Configure.pl === RCS file: /home/perlcvs/parrot/Configure.pl,v retrieving revision 1.44 diff -u -r1.44 Configure.pl

Re: recent win32 build errors

At 13:36 on 12/31/2001 GMT, Simon Cozens [EMAIL PROTECTED] wrote: You are, of course, correct. gcc is a lot laxer than many other compilers, so we want to get away with as little as possible. -Wall should be default for gcc. (And please remember that not every compiler supports -Wall, so

[patch] um.

This silences these warnings: test_main.c: In function `main': test_main.c:165: warning: passing arg 6 of `mmap' with different width due to p rototype pdump.c: In function `main': pdump.c:55: warning: passing arg 2 of `mmap' as unsigned due to prototype pdump.c:55: warning: passing arg 6 of

[patch] fake out vtable.h during Configure.pl

I'm fiddling with a compiler called tcc (i'll add it to tinderbox shortly). It was complaining that struct _vtable was not completely defined while building one of the test programs in Configure.pl. It was right- at that point we generate an empty version of vtable.h, so this struct isn't

lcc and tcc added

for such things, it may be interesting to try this out. I'm not too clear on how well it would actually work. Seems interesting in concept though. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

[patch] ignore classes/*.h

Index: classes/.cvsignore === RCS file: /home/perlcvs/parrot/classes/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- classes/.cvsignore 11 Dec 2001 12:03:23 - 1.2 +++ classes/.cvsignore 5 Jan 2002

[patch] fixes so it builds with lcc

With these, it at least compiles. Lots of warnings, and a few test failures. Note that I do not have that much confidence in my lcc installation. It failed some of its own tests. When I have time, i'll reinstall and see if I can figure out what's wrong. Index: classes/perlhash.pmc

lcc blowing up for no good reason

I'll see what I can do as far as upgrading my lcc installation or reporting this as a bug to the lcc people. But for now, here is a workaround for this error, just to get the tinderbox going again: lcc -I./include -DHAS_JIT -o test_main.o -c test_main.c /tmp/lcc62401.s: Assembler messages:

RE: How Powerful Is Parrot? (fwd)

Who is the keeper of the FAQ? This is gold. --Josh --- Forwarded Messages Date:Thu, 24 Jan 2002 12:35:05 -0800 From:Brent Dax [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: How Powerful Is Parrot? [EMAIL PROTECTED]: # I've been watching the Parrot

[Patch] manually disabling jit compilation, testing for cranky jit-unfriendly compilers

. If anyone figures out the proper way to cast these function pointers this may not be necessary. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org Index: Configure.pl === RCS file: /home/perlcvs/parrot

Re: [Patch] A few fixes.

At 8:42 on 02/06/2002 PST, Brent Dax [EMAIL PROTECTED] wrote: Andy Dougherty: # On Wed, 6 Feb 2002, Mattia Barbon wrote: # Probably not: IIRC the standard requires the parts inside # #if 0/#endif to be tokenizable. # # If I recall correctly, some AIX compilers will complain about # such

[updated patch] Re: what libc functions are we using?

I've updated the script to also support scanning the source using the cxref tool. Here's an updated version of the script and patch. The output looks like this: perl lib_deps.pl object exceptions.o global_setup.o interpreter.o parrot.o register.o core_ops.o core_ops_prederef.o memory.o

[Patch] function pointer handling

This patch removes unnecessary function pointer conversions (which have undefined behavior in ANSI C). This gets rid of several warnings encountered with the lcc compiler and isolates our function pointer misbehavior to only the jit code. --Josh Index: core.ops

[Patch] Fix warnings in exceptions.c

Parrot_Interp *interpreter, char *message, char *file, int line); #define PANIC(message)\ do_panic(interpreter, message, __FILE__, __LINE__) -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: [Patch] Fix warnings in exceptions.c [APPLIED]

Oops, my patch introduced some more warnings in other files. Here's a fixed version. Index: exceptions.c === RCS file: /home/perlcvs/parrot/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- exceptions.c

[Patch] More lint-induced fixes

Fixes some bad returns, some unused variables, and some mismatched formats. This should be distinct from my other pending patch, which changes the way function pointers are handled outside of the JIT. --Josh Index: embed.c ===

Re: [Patch] More lint-induced fixes

At 22:02 on 02/15/2002 PST, Brent Dax [EMAIL PROTECTED] wrote: # +++ misc.c 16 Feb 2002 05:36:46 - It's not indenting the nested switch() statements the same as their matched break;s. Hrm. It _should_ be indented OK.. not sure what happened there- can whoever applies the patch make

interesting lint warning in array.pmc

array.pmc: (in function Parrot_Array_move_to) array.pmc:70:18: Stack-allocated storage pmc-data reachable from parameter pmc A stack reference is pointed to by an external reference when the function returns. The stack-allocated storage is destroyed after the call, leaving a dangling

Re: PDDs, guys.

Bravo! PDD 7 (coding standards) is also still MIA, although i understand that it's basically complete. --Josh At 16:18 on 02/17/2002 GMT, Simon Cozens [EMAIL PROTECTED] wrote: I was just starting to think about writing something on the history and evolution of Parrot's design, and came

Re: [PATCH] make core_ops_prederef.c compile with MS c++

Daniel, I've actually got something equivalent for the inline portion of your patch in the patch I just sent to the list. As far as the ssize_t part, yeah, this probably belongs in config.h_in or parrot.h or something. --Josh At 0:30 on 02/18/2002 +0100, Ritz Daniel [EMAIL PROTECTED]

[Corrected Patch] Rollup of my current-outstanding patches

Sorry, I goofed on that last patch- corrected version (including rx.h this time): [josh-002.patch] This patch rolls up all my current outstanding patches. - add makefile target and script to test for external libc dependencies - fix return values in hash and array PMCs (returning 0 in

[Patch] const fix for gcc warnings

[josh-003.patch] This patch adds some missing const's to silence a number of gcc warnings. --Josh Index: include/parrot/warnings.h === RCS file: /home/perlcvs/parrot/include/parrot/warnings.h,v retrieving revision 1.1 diff -u

[Patch] lib_deps.pl

At 8:24 on 02/18/2002 GMT, Simon Cozens [EMAIL PROTECTED] wrote: Josh Wilmes: This patch rolls up all my current outstanding patches. Cool, applied. Although I killed libdeps; I assume you didn't want that in there. (Since there's no patch to the manifest.) Owch. Point taken: [josh-004

[Patch] Yet more warnings-fixes and cleanups

Fixes the following (lcc) warnings: - interpreter.c:470: warning: expression with no effect elided (related to the way warnings flags were defined) - misc.c:352: warning: unreachable code misc.c:483: warning: unreachable code (i introduced these with some overzealous

[Patch] [was Re: Current CVS on Win32 ]

The inline bit of that patch was no longer needed, and the ssize_t thing really shouldn't be needed either. Here's a patch to simplify things: [josh-006.patch] Index: lib/Parrot/OpTrans/CPrederef.pm === RCS file:

Re: [PATCH]Macro bulletproofing

Good stuff! However, regarding the function pointer thing, i've got compilers (tcc and lcc) which disagree with you. Using NULL where a function pointer is expected is considered an error by tcc, and a mandatory warning by lcc. It is my understanding that conversion between data pointers and

cvsclean not really really clean?

]: Initializers are converted as if by assignment. -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: [PATCH] Bowing to necessity (was Re: [PATCH]Macro bulletproofing )

At 6:57 on 02/23/2002 CST, Brian Lee Ray [EMAIL PROTECTED] wrote: However, a null pointer constant, expressed as either 0 or (void*)0 (and the definition of NULL must be one of the above), can be safely compared with or assigned to either a function pointer or a data pointer. Consider the

[Patch] Using indent

This patch adds a script called run_indent.pl which runs the GNU indent program to reformat code to conform to PDD 7. It also patches PDD 7 to reflect what is being done. [josh-011.patch] Index: MANIFEST === RCS file:

Can we go ahead and run indent on our source?

, this will cause headaches and giant diffs (approx 11000 lines) but if not now, when? On the plus side, it cuts down the errors from make check_source by 162.. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: Can we go ahead and run indent on our source?

At 2:22 on 02/24/2002 GMT, Simon Cozens [EMAIL PROTECTED] wrote: If you're prepared to fix the output up manually, feel free to run indent on your local copy, fix it up, and then mail me a diff; or we can get you commit access. Commit access would be the easiest way to get this done, as it's

#defined types

. So, what should be done about the first three? If it's cool to have shortcut names for types like that, may I propose that we make a header file which is for use in-core only and does all those aliases in one place. Then I can parse that for indent's purposes. --Josh -- Josh Wilmes ([EMAIL

[Patch] Fix solaris test failures

); interpreter-pmc_count = 0; -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

[Patch] Fix a warning

-GC_data, 0, sizeof(PMC *) * PMC_HEADERS_PER_ALLOC); new_arena-start_PMC = mem_sys_allocate(sizeof(PMC) * PMC_HEADERS_PER_ALLOC); memset(new_arena-start_PMC, 0, sizeof(PMC) * PMC_HEADERS_PER_ALLOC); new_arena-free = 0; -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

[Patch] Add ending boilerplate

-indentation-style: bsd + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + * + * vim: expandtab shiftwidth=4: + */ -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: [Applied] Re: [Patch] Fix a warning

At 17:41 on 03/02/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote: On Fri, Mar 01, 2002 at 11:28:48PM -0500, Josh Wilmes wrote: Little patch to fix a compiler warning. Thanks, applied. You didn't say which compiler disliked the old version. (I'm curious) lcc, which also totally

[Patch] Fix warning/error in tests.

; { local $/ = undef; - $prog_output = OUTPUT; + $prog_output = OUTPUT . ''; $prog_output =~ s/\cM\cJ/\n/g; } close OUTPUT; -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org

Re: 0.0.4 imminent

We should rename all the PDDs to be consistent. I propose: old name new name title -- pdd0.pod = pdd00_pdd.podPerl Design Documents pdd1.pod = pdd01_overview.pod A high-level

Re: [PATCH] 5.005_03 (was Re: New assembler ready for tasting)

applied. At 16:01 on 03/16/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote: On Fri, Mar 15, 2002 at 06:10:11PM -0500, Simon Glover wrote: With a proper fresh checkout, everything builds OK here, but I've run into another problem: Parrot::Assembler:Utils uses Text::Balanced, but

Re: OpenVMS can't get past configure

I suspect that it's not that VMS can't handle it- it's more likely that VMS does a better job of placing quotas on memory usage than other OSes. There's probably something analogous to ulimit which would fix the issue, but requiring that in order to build parrot isn't really reasonable. If we

Re: [PATCH] Makefile.in 'make clean' should preserve backups

FWIW, I really like having make clean delete *~. But since we have things like make cvsclean, i don't consider it essential. --Josh At 7:19 on 03/18/2002 GMT, Jonathan Stowe [EMAIL PROTECTED] wrote: There may be a very good reason for this that I haven't determined but this keeps catching

Re: [PATCH] 5.005_03 (was Re: New assembler ready for tasting)

At 11:11 on 03/16/2002 EST, Josh Wilmes [EMAIL PROTECTED] wrote: applied. At 16:01 on 03/16/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote: On Fri, Mar 15, 2002 at 06:10:11PM -0500, Simon Glover wrote: With a proper fresh checkout, everything builds OK here, but I've run

test_parrot = parrot

Here are some stragglers: ../.cvsignore:test_parrot ../MANIFEST.SKIP:^test_parrot$ ../docs/intro.pod: % ./test_parrot fib.pbc ../test_main.c:fprintf(stderr, test_parrot: Invalid flag %c used, test_main.c should probably be renamed too. --Josh -- Josh Wilmes ([EMAIL PROTECTED

Re: MSVC Warnings

I've applied the classes/intqueue.pmc patch. The other needs adjustment. FWIW, your change doesn't cure the errors on TCC: string.c, line 51: Error: [ISO 6.3.16.1]: Conversion casts away 'const'-ness. [ISO 6.3.16]: Can't perform this conversion by assignment. string.c, line 55: Error:

Re: Old Warnock's Dilemma for 'make quicktest'

Excellent- applied. --Josh At 18:03 on 03/21/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: Times are: make quicktest, after caching output: 23 seconds make test: 175 seconds make quicktest could screw up if: - you ctrl-c it, or make test (although I haven't had problems with that

Re: [PATCH] Misc PDD 07 nits

Bryan, this is good stuff! One question though- in this section of the patch: - /* file header comments */ - - #if !defined(PARROT_FILENAME_H_GUARD) - #define PARROT_FILENAME_H_GUARD - - /* body of file */ - - #endif /* PARROT_FILENAME_H_GUARD */ +/* file header comments */ +

Re: [PATCH] Misc PDD 07 nits

At 11:34 on 03/22/2002 EST, Bryan C. Warnock [EMAIL PROTECTED] wrote: On Friday 22 March 2002 11:23, Josh Wilmes wrote: This doesn't agree with how we've been doing cpp directive indenting in two ways. I was just fixing various format problems. There's a *lot* in the PDD

[Applied] win32 parrot_dlclose

Good, thanks, applied. --Josh At 23:43 on 03/24/2002 +0100, Ritz Daniel [EMAIL PROTECTED] wrote: parrot_dlclose() uses dlclose() on unix, FreeLibrary() on windoze. dlclose returns 0 on success, FreeLibrary returns 0 on failure...fix included Index: platforms/win32.c

Re: Unicode thoughts...

This is rather concerning to me. As I understand it, one of the goals for parrot was to be able to have a usable subset of it which is totally platform-neutral (pure ANSI C). If we start to depend too much on another library which may not share that goal, we could have trouble with the

Re: [PATCH] tabs-spaces fix

Mike, that doesn't want to apply for me- i suspect that the patch got garbled in the mail. Can you MIME-attach or uuencode it? --Josh At 23:17 on 03/25/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: Below is a fix for the use of tabs in test_main.c and resources.c. Mike Lambert

[Applied] tabs-spaces fix

. Mike Lambert Josh Wilmes wrote: Date: Mon, 25 Mar 2002 23:22:34 -0500 From: Josh Wilmes [EMAIL PROTECTED] To: Michel J Lambert [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] tabs-spaces fix Mike, that doesn't want to apply for me- i suspect that the patch

[Applied] t/pmc/.cvsignore

Thanks, done. At 2:59 on 03/27/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: The introduction make quicktest made this missing .cvsignore more apparent. Mike Lambert

deep tests for stacks.t

I added some tests which push larger numbers of stack frames- this improves our coverage in register.c. However, one of the tests is failing for me. Is this something I did wrong, or did I find a bug? I'm getting weird output for the pushp and popp (deep) test. --Josh Here's the patch:

Re: Warnings Cleanup

I've applied portions of this patch. I omitted the parts which use the byte type, which isn't going to work on all platforms. --Josh At 1:46 on 03/28/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: Attached patch fixes many of the warnings you see on MSVC level 4. The ones listed

[Patch] Fatal errors for invalid chartype/encoding lookups

I forgot to send this patch last night. I was browsing through the code and noticed these return NULLs for what I think are probably really fatal conditions. Here's a patch which switches them to internal_exceptions. Hopefully i'm not missing the point here. --Josh Index: chartype.c

Re: RT is your friend...

Should we be using bugs6 for all patches? --Josh At 15:04 on 03/28/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: When you come across bugs, or there are things that should be implemented but aren't, could folks make entries in the perl 6 bugtracking system so we don't lose track?

[Patch] Add support for tests in C

This should enable writing tests which call parrot C functions directly, which could be useful for increasing coverage to things which aren't easy to call via opcodes. -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org Index: Makefile.in

Re: [Patch] Add support for tests in C

Could you be specific? I was careful to do things identically to Configure.pl (because we lack any common code I can use right now- that's another problem we need to solve) --Josh At 22:03 on 03/28/2002 PST, Brent Dax [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: # This should enable

Re: [Patch] Add support for tests in C

OK- i assumed that target was OK, since it was in the makefile. I'll discuss this with you some more- perhaps this is the time to abstract away some of this building-things stuff. --Josh At 22:23 on 03/28/2002 PST, Brent Dax [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [mailto:[EMAIL

Re: [RETRACTED] get_string on undef

Whatever the answer is, it better end up in a PDD :) --Josh At 2:00 on 03/29/2002 EST, Melvin Smith [EMAIL PROTECTED] wrote: At 10:50 PM 3/28/2002 -0800, Steve Fink wrote: The string_* functions treat NULL and an empty string as equivalent, so this saves time in case we don't actually

Re: [RETRACTED] get_string on undef

At 2:14 on 03/29/2002 EST, Melvin Smith [EMAIL PROTECTED] wrote: Boy a searchable archive would be nifty right about now. Might be time for me to slurp the archive down to a local copy. Try this: http://www.mail-archive.com/perl6-internals@perl.org/ --Josh

[Applied] Bye, Simon.

Applied, with slight tweaking to make sure we keep simon in there :) --Josh At 23:29 on 03/28/2002 EST, Will Coleda [EMAIL PROTECTED] wrote: --B99DD6E33AE5206FD2C4A8AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe this is correct...

Re: [PATCH] stacks.c

It won't go in cleanly any more: patching file stacks.c Hunk #1 FAILED at 108. Hunk #2 FAILED at 153. Hunk #3 succeeded at 227 (offset 46 lines). Hunk #4 succeeded at 243 with fuzz 1 (offset 46 lines). 2 out of 4 hunks FAILED -- saving rejects to file stacks.c.rej If you can submit a patch

[Applied] stacks.c

Applied, all tests passing. --Josh At 20:31 on 03/29/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: It won't go in cleanly any more: How about the below patch? Mike Lambert Index: stacks.c === RCS file:

[Applied] Re: Warnings Cleanup

Good enuff, thanks! Applied. --Josh At 20:36 on 03/29/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote: I've applied portions of this patch. I omitted the parts which use the byte type, which isn't going to work on all platforms. I've changed these to use 'char'. Hopefully that

Re: [preliminary PATCH] Parrot C Compiler Wrapper

I've been thinking along these lines, but I'd decided on a different approach. I think that it's better to keep the magic to a minimum. Rather than relying on extensions, I was thinking about having a different wrapper for each task: - lib.pl: build static library from object files

Re: Unicode thoughts...

Someone said that ICU requires a C++ compiler. That's concerning to me, as is the issue of how we bootstrap our build process. We were planning on a platform-neutral miniparrot, and IMHO that can't include ICU (as i'm sure it's not going to be written in pure ansi C) --Josh At 8:45 on

Re: Misc portability cleanups

You may be interested in the lib_deps target. --Josh At 0:49 on 03/31/2002 EST, Melvin Smith [EMAIL PROTECTED] wrote: I did some browsing of the code for potential problems in compiling for embedded platforms and/or general porting and here are some of the things I found. 1- assert.h and

[Applied] Re: GC Torture Torture Testing

Applied :) As far as a tinderbox-specific target, i'm all for it. I was thinking that it might be better to have it be a perl script, since we could then have it take care of doing the clean and rebuild the makefile appropriately. I can take a stab at it tomorrow, if nobody else does. --Josh

Re: [PATCH] VMS fixups. Configure hints Makefile syntax

Committed, thanks. (makes things ugly, but hopefully we'll be replacing the makefile with something more perlish down the road) --Josh At 16:17 on 04/01/2002 EST, Michael G Schwern [EMAIL PROTECTED] wrote: Ok, here's the necessary fixes to the VMS hints and Makefile.in to get VMS to

Re: cvs commit: parrot core.ops

What is this supposed to do? It breaks the tcc build, and generally looks ungood to me. --Josh At 18:03 on 04/01/2002 GMT, [EMAIL PROTECTED] wrote: cvsuser 02/04/01 10:03:29 Modified:.core.ops Log: Minor optimization Revision ChangesPath 1.115

Added macros for interpreter-flags

--- Forwarded Message Date:02 Apr 2002 06:24:19 + From:[EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: parrot/io io.c io_win32.c cvsuser 02/04/01 22:24:19 Modified:.core.ops embed.c interpreter.c runops_cores.c include/parrot

Re: PDD formatting issues

At 1:19 on 04/02/2002 EST, Jeff [EMAIL PROTECTED] wrote: I ran across the following errors while running pod2html over the PDDs: The errors from podchecker were better about line numbers, but still, this was helpful. [parrot@damogran pdd]$ pod2html pdd00_pdd.pod pdd00_pdd.html

[Applied] round up of warning fixes

Thanks, applied! --Josh At 9:49 on 04/03/2002 +0100, Jonathan Stowe [EMAIL PROTECTED] wrote: This is the residue of the warning fixes I have made and which haven't been applied before I start a new working copy :) Index: chartype.c

[Applied] Yet another MANIFEST patch

Applied this one. No time to look at the others tonight, but i'll pick them up if nobody else does. --Josh At 19:03 on 04/06/2002 EST, Simon Glover [EMAIL PROTECTED] wrote: --- MANIFEST.old Sat Apr 6 13:35:21 2002 +++ MANIFEST Sat Apr 6 13:37:17 2002 @@ -163,6 +163,7 @@

Re: [Applied] Fix up comments in pmc.c

Cool, applied. At 18:21 on 04/11/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote: We no longer pass a PMC pointer into pmc_new, but the comment hasn't been changed to reflect that. Patch below corrects, and also adds an appropriate comment for pmc_new_sized. Simon --- pmc.c.old

[Applied] pasm.el

Marco- i went ahead and added your pasm.el file under parrot/editor/. I'm not familiar enough with the ops to commit your other patch- i'll leave that for someone else. --Josh At 20:21 on 04/14/2002 +0200, Marco Baringer [EMAIL PROTECTED] wrote: ok, please pardon the inconvience but

Re: [Applied] Remove redundant declarations

Applied, thanks. Had to change the chartype.h part a bit, as it didn't want to apply on its own. I am not sure why. Anyway, it's in. Is there a reason not to include -Wredundant_decls in our default warnings flags? --Josh At 22:54 on 04/16/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote:

Re: [APPLIED] Re: First patch to memory allocation routines

At 15:58 on 05/01/2002 PDT, Steve Fink [EMAIL PROTECTED] wrote: I've applied this patch, along with fixing the original resources.c's indentation (re-indenting patches are annoying, but this patch touched enough of resources.c files that it seemed like a golden opportunity.) Here are some

Re: GC, exceptions, and stuff

At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: I think we'll be safe using longjmp as a C-level exception handler. I'm right now trying to figure whether it's a good thing to do or not. (I'd like to unify C and Parrot level exceptions if I can) Just make sure that we

  1   2   >