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
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?
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.
>
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 t
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
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
commo
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:
>
