Re: cvs commit: parrot/io io.c io_buf.c
Melvin Smith [EMAIL PROTECTED] writes: Did you consider using the method interface in ParrotIO? That ought to be even extensible with user code. Yes, I'm trying to get back up to speed on everything. The method interface is a new feature that I need to look at. I've written a first cut on the method interface in parrotio.pmc. The system is fairly simple: At class_init time the methods are registred in a hash and the find_method function looks up this hash and returns a invoke-able PMC (a NCI). See t/pmc/io.t for example. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: cvs commit: parrot/io io.c io_buf.c
Melvin Smith [EMAIL PROTECTED] wrote: I personally don't like to add an opcode for every special case because most of them are very rarely used, but as usual its up for discussion. Did you consider using the method interface in ParrotIO? That ought to be even extensible with user code. -Melvin leo
Re: cvs commit: parrot/io io.c io_buf.c
At 09:59 AM 10/11/2003 +0200, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: I personally don't like to add an opcode for every special case because most of them are very rarely used, but as usual its up for discussion. Did you consider using the method interface in ParrotIO? That ought to be even extensible with user code. Yes, I'm trying to get back up to speed on everything. The method interface is a new feature that I need to look at. -Melvin
Re: cvs commit: parrot/io io.c io_buf.c
Which ones? The PIOCTL ones are, for a lack of current
interface, a way for interfacing to the lower level IO
system through a catchall opcode. It can be anything from
setting terminal modes, buffering, separator characters, the
list goes on.
Although we probably want to make separate ops for
common things like setting blocking mode, async/sync, etc. there are
usually a lot of little operations or queries that you might want
to do on an IO system that might not warrant a separate op for each.
I personally don't like to add an opcode for every special case
because most of them are very rarely used, but as usual its
up for discussion.
-Melvin
At 04:46 PM 10/10/2003 +0100, Nicholas Clark wrote:
On Fri, Oct 10, 2003 at 02:43:10AM -, Melvin Smith wrote:
+else if(arg == PIOCTL_BLKBUF) {
+ PIO_setbuf(interpreter, pmc, PIO_UNBOUND);
+ return 0;
+}
+else return -3;
case PIOCTL_CMDGETBUFSIZE:
if(b) return b-size;
else return -6;
What are all these magic numbers about?
Nicholas Clark
Re: cvs commit: parrot/io io.c io_buf.c
On Fri, Oct 10, 2003 at 05:55:11PM -0400, Melvin Smith wrote:
Which ones? The PIOCTL ones are, for a lack of current
interface, a way for interfacing to the lower level IO
system through a catchall opcode. It can be anything from
setting terminal modes, buffering, separator characters, the
list goes on.
Sorry. Wasn't clear. The PIOCTL macros are (to me) the correct way of doing
something.
-6 and -3 are magic numbers. They have no context as to what they might be.
At 04:46 PM 10/10/2003 +0100, Nicholas Clark wrote:
On Fri, Oct 10, 2003 at 02:43:10AM -, Melvin Smith wrote:
+else if(arg == PIOCTL_BLKBUF) {
+ PIO_setbuf(interpreter, pmc, PIO_UNBOUND);
+ return 0;
+}
+else return -3;
case PIOCTL_CMDGETBUFSIZE:
if(b) return b-size;
else return -6;
What are all these magic numbers about?
Nicholas Clark
Nicholas Clark
Re: cvs commit: parrot/io io.c io_buf.c
At 11:23 PM 10/10/2003 +0100, Nicholas Clark wrote: On Fri, Oct 10, 2003 at 05:55:11PM -0400, Melvin Smith wrote: Which ones? The PIOCTL ones are, for a lack of current interface, a way for interfacing to the lower level IO system through a catchall opcode. It can be anything from setting terminal modes, buffering, separator characters, the list goes on. Sorry. Wasn't clear. The PIOCTL macros are (to me) the correct way of doing something. -6 and -3 are magic numbers. They have no context as to what they might be. Eep, I misread it, you were clear. That was just debugging I left in. Have we defined the standard way for error reporting in Parrot. At one time we had talked of having an errno for each interpreter? Maybe now is the time to standardize it. -Melvin
Re: cvs commit: parrot/io io.c
Readded the pio_(stdin|stdout|stderr) to make builds work again.
I moved stdin/stdout/stderr to be interp local so you can
use: interpreter-piodata-table[PIO_STDIN_FILENO], etc. now.
Those global pointers should go away because they are null
now anyway.
-Melvin
Revision ChangesPath
1.11 +5 -5 parrot/jit.c
Index: jit.c
===
RCS file: /home/perlcvs/parrot/jit.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -w -r1.10 -r1.11
--- jit.c 20 Jan 2002 20:52:21 - 1.10
+++ jit.c 28 Jan 2002 14:16:59 - 1.11
@@ -1,7 +1,7 @@
/*
** jit.c
**
-** $Id: jit.c,v 1.10 2002/01/20 20:52:21 grunblatt Exp $
+** $Id: jit.c,v 1.11 2002/01/28 14:16:59 grunblatt Exp $
*/
#include parrot/parrot.h
@@ -33,7 +33,7 @@
INTVAL *address,ivalue,size,i,k;
INTVAL *op_address, prev_address, bytecode_position;
#ifdef ALPHA
-char *interpreter_registers = ((char
*)interpreter-int_reg-registers[0]) + 0x7fff;
+char *interpreter_registers = ((char
*)interpreter-int_reg.registers[0]) + 0x7fff;
INTVAL high,low;
#endif
@@ -107,7 +107,7 @@
v = op_assembly[*pc].intval_register_address;
for (i = 0; i v.amount; i++)
{
-address =
interpreter-int_reg-registers[pc[v.info[i].number]];
+address =
interpreter-int_reg.registers[pc[v.info[i].number]];
#ifdef ALPHA
address = (INTVAL*)(((char *)address) -
interpreter_registers);
#endif
@@ -117,7 +117,7 @@
v = op_assembly[*pc].floatval_register_address;
for (i = 0; i v.amount; i++)
{
-address = (INTVAL
*)interpreter-num_reg-registers[pc[v.info[i].number]];
+address = (INTVAL
*)interpreter-num_reg.registers[pc[v.info[i].number]];
#ifdef ALPHA
address = (INTVAL*)(((char *)address) -
interpreter_registers);
#endif
@@ -129,7 +129,7 @@
v = op_assembly[*pc].string_register_address;
for (i = 0; i v.amount; i++)
{
-address = (INTVAL
*)interpreter-string_reg-registers[pc[v.info[i].number]];
+address = (INTVAL
*)interpreter-string_reg.registers[pc[v.info[i].number]];
#ifdef ALPHA
address = (INTVAL*)(((char *)address) -
interpreter_registers);
#endif
1.12 +6 -1 parrot/io/io.c
Index: io.c
===
RCS file: /home/perlcvs/parrot/io/io.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -w -r1.11 -r1.12
--- io.c 28 Jan 2002 04:27:17 - 1.11
+++ io.c 28 Jan 2002 14:17:05 - 1.12
@@ -1,7 +1,7 @@
/* io.c
* Copyright: (When this is determined...it will go here)
* CVS Info
- * $Id: io.c,v 1.11 2002/01/28 04:27:17 mrjoltcola Exp $
+ * $Id: io.c,v 1.12 2002/01/28 14:17:05 grunblatt Exp $
* Overview:
* This is the Parrot IO subsystem API. Generic IO stuff
* goes here, each specific layer goes in its own file...
@@ -29,6 +29,11 @@
/*
ParrotIOLayer * pio_default_stack;
*/
+
+/* The standard streams */
+ParrotIO * pio_stdin;
+ParrotIO * pio_stdout;
+ParrotIO * pio_stderr;
PIOOFF_Tpiooffsetzero;
