RE: [PATCH] ParrotPointer.pmc

Ack, forgot these. (Below my sig.) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 . hawt sysadmin chx0rs This is sad. I know of *a* hawt sysamin chx0r. I know more than a few. obra: There are two? Are you sure it's not the same one? --- ..\..\parrot-cvs\parrot\global_setu

[PATCH] PIO - more stuff

Changes: -Minor layer cleanups -Win32 layer added (mostly stubs for now) but will be using the Win32 API and company rather than the unix-ish fake ones. -stdin/stdout/stderr Win32 specific code added. Rather than use 0,1,2, Microsoft says use GetStdHandle(), etc. so that stuff is the

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: /

[PATCH] ParrotPointer.pmc

The attached patch adds a PMC class that just contains a pointer. (Yes, this is based on the Handle stuff I submitted a week or so ago.) You generally don't create these in the bytecode, but C functions will create them and stuff them for you. Get operations do what you expect; the string repre

RE: catching warnings

Or possibly a universal catch, with the $@.warning and $@.die or something, so that you can check it. Ilya > -Original Message- > From: David Whipp [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 08, 2002 7:25 PM > To: Perl6-Language (E-mail) > Subject: catching warnings > > > Per

catching warnings

Perl6 is going to introduce a non-resumable throw/catch mechanism to replace die/$@. (I assume that die will be synonymous with throw, for compatibility.) But what about warnings? I frequently find myself wanting to "catch" warnings (e.g. to add extra context around a library's "use of undefined

Re: Problem with key.c?

Simon Glover wrote: > > In amongst all the unused parameter warnings, gcc throws up these two for > key.c: > > key.c: In function `key_element_value_s': > key.c:275: warning: passing arg 2 of `find_bucket' from incompatible >pointer type > > key.c: In function `key_set_element_value

Re: [PATCH] unused variables

On Mon, Jan 07, 2002 at 07:32:43PM -0800, Steve Fink wrote: > would appeal more to other compilers. My only complaints with > 'if (0 || a) {}' are (1) I can easily see it getting optimized away > and complaining anyway on a later gcc version or different compiler, I was under the impression that

Re: [PATCH] Keep comments in sync with the code...

On Tue, Jan 08, 2002 at 12:20:59PM -0800, Hong Zhang wrote: > > By the way, we should not have global variable names like "index" > at the first place. All globals should look something like "GIndex". Valid point. Sadly in this case there's not much we can do, as I think that gcc was warning a

Re: Complex Class

At 03:40 PM 1/8/2002 -0800, Boris Tschirschwitz wrote: >Hi. > >I suppose that it is not possible to use non build-in PMC's, yet. >Therefore I have implemented the GNU Scientific library complex number >type as a build-in class, just for myself. >Since there is no complex type so far I wonder if th

Complex Class

Hi. I suppose that it is not possible to use non build-in PMC's, yet. Therefore I have implemented the GNU Scientific library complex number type as a build-in class, just for myself. Since there is no complex type so far I wonder if there is interest in having as much basic functionality as sens

RE: Some random design notes

At 01:47 PM 1/8/2002 -0800, Brent Dax wrote: >Dan Sugalski: ># This is just a collection of random notes I put together while serving ># jury duty. There's not much coherence here, but better to get it down ># than not. > >"Is this case worthy of the death penalty?" >"Hmm? Yeah, sure, whatever."

[PATCH] 2 warnings in key.c

These are both warnings regarding using a STRING * to refer to a BUCKET *. "key.c", line 275: warning: argument #2 is incompatible with prototype: prototype: pointer to struct _bucket {struct _key_pair {..} pair, pointer to struct {..} key, pointer to struct _bucket {..} next} : "key.c"

RE: Some random design notes

Dan Sugalski: # This is just a collection of random notes I put together while serving # jury duty. There's not much coherence here, but better to get it down # than not. "Is this case worthy of the death penalty?" "Hmm? Yeah, sure, whatever." :^) # Global namespaces need to be multilevel the w

Some random design notes

This is just a collection of random notes I put together while serving jury duty. There's not much coherence here, but better to get it down than not. --- Global namespaces need to be multilevel the way lexical spaces are. Ruby and Python both require this. (Well, it's not required but i

RE: [PATCH] Keep comments in sync with the code...

By the way, we should not have global variable names like "index" at the first place. All globals should look something like "GIndex". Hong > -Original Message- > From: Simon Glover [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 08, 2002 9:56 AM > To: [EMAIL PROTECTED] > Subject:

Re: [PATCH] Keep comments in sync with the code... [APPLIED]

At 05:55 PM 1/8/2002 +, Simon Glover wrote: > We changed from index to idx in the code, but not in the comments. Applied, thanks. Dan --"it's like this"--- Dan Sugalski even

Problem with key.c?

In amongst all the unused parameter warnings, gcc throws up these two for key.c: key.c: In function `key_element_value_s': key.c:275: warning: passing arg 2 of `find_bucket' from incompatible pointer type key.c: In function `key_set_element_value_s': key.c:339: warning: assignment

[PATCH] Keep comments in sync with the code...

We changed from index to idx in the code, but not in the comments. Simon --- key.c.old Tue Jan 8 08:00:00 2002 +++ key.c Tue Jan 8 17:52:36 2002 @@ -217,7 +217,7 @@ /*=for api key key_element_type -return the type of element of KEY +return the type of element of KEY =cut

[PATCH] Fix io.c warning

Enclosed patch fixes this warning: io/io.c: In function `PIO_copy_stack': io/io.c:277: warning: declaration of `new_stack' shadows global declaration Simon --- io.c.oldTue Jan 8 17:40:19 2002 +++ io.cTue Jan 8 17:41:49 2002 @@ -274,11 +274,11 @@ * IO object. Later we wil

Re: [PATCH] .ops files use in/out/inout arg use qualifiers [APPLIED]

At 04:22 AM 1/8/2002 -0500, [EMAIL PROTECTED] wrote: >All -- > >I've modified Parrot/OpsFile.pm to expect opfunc declarations to >take the form: > > inline op set(out INT, in INT) { > >or >: > inline op inc(inout INT) { ... > >(you get the idea). Applied, thanks.

Re: Possible error in key_hash [APPLIED]

At 05:47 PM 1/8/2002 +0200, Peter Gibbs wrote: >Jeff > >If I understand the STRING struct correctly, buflen is the physical >allocation of the buffer, and bufused is the number of bytes actually used >by the string; therefore the latter would be correct for key_hash? Applied, thanks.

Re: [PATCH] .ops files use in/out/inout arg use qualifiers

Jason -- Thanks for taking the time to look at this and comment on it. > Actually you need to clarify what the semantics of an 'out' parameter are for S > and P registers. 'out' should indicate whether the value of the register (ie. > the value of the pointer) may change. > > For example, in :

Possible error in key_hash

Jeff If I understand the STRING struct correctly, buflen is the physical allocation of the buffer, and bufused is the number of bytes actually used by the string; therefore the latter would be correct for key_hash? Peter Gibbs EmKel Systems Index: key.c =

Re: [PATCH] .ops files use in/out/inout arg use qualifiers

Actually you need to clarify what the semantics of an 'out' parameter are for S and P registers. 'out' should indicate whether the value of the register (ie. the value of the pointer) may change. For example, in : inline op set(PMC, NUM) { $1->vtable->set_number_native(interpreter, $1, $2);

[PATCH] .ops files use in/out/inout arg use qualifiers

All -- I've modified Parrot/OpsFile.pm to expect opfunc declarations to take the form: inline op set(out INT, in INT) { or : inline op inc(inout INT) { ... (you get the idea). This is a big patch because most of core.ops is affected. I've made the vtable.ops generation code compatib

Re: [patch] Reading bytecode stream from stdin

On Tue, Jan 08, 2002 at 03:06:32AM +, Alex Gough wrote: > The patch below adds the ability to say: > ../test_parrot -f - < foo.pbc > (Yes, an interactive bytecode interpreter, just what you've been > waiting for) Yes, I have, thank you. Do you want to apply it? -- As the saying goes, if you