On Fri, Mar 17, 2006 at 06:40:32PM -0800, Allison Randal wrote:
> On Mar 6, 2006, at 4:06, Nicholas Clark wrote:
>
> >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> >
> > =head2 Network I/O Opcodes
> >
> >
> >Functionality wise, the following are missing:
> >
> > shutdown
>
>
On Mar 6, 2006, at 4:06, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=head2 Network I/O Opcodes
Functionality wise, the following are missing:
shutdown
Added.
getpeername/getsockname
getsockopt/setsockopt
These seem rare, and intimatel
On Mar 3, 2006, at 15:54, Joshua Isom wrote:
Concerning all the byte/character issues, all the string opcodes
except bytelength work with characters. But the io subsystem
currently only deals with bytes. I know there is the speed issue
for things like reading with dealing with utf8, but
On Mar 11, 2006, at 2:07, Nicholas Clark wrote:
I feel more comfortable with the idea of IO being methods on PMCs
than raw
OPs.
They are methods on I/O objects internally. (Just as most opcodes on
PMCs actually call vtable methods.) So, the question isn't as
significant as it appears. I
On Sun, Mar 05, 2006 at 07:11:59PM +, Nicholas Clark wrote:
> =item *
>
> C retrieves information about a file on the filesystem. It takes a
> string filename or an integer argument of a UNIX file descriptor, and an
> integer flag for the type of information requested. It returns an
On Mon, Mar 06, 2006 at 03:31:17PM -0800, Allison Randal wrote:
> On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
> > * C returns a string representing a socket address
> > [Nicholas] "I don't think that this is appropriate. It's IPv4
> >specific."
> >
> >A more general SocketAddr PMC seems
On Mon, Mar 06, 2006 at 01:08:55PM +0100, Leopold Toetsch wrote:
>* opcode vs function / method
>
>open P0, "data.txt", ">"
>print P0, "sample data\n"
>
> Using opcodes for all the IO has some disadvantages:
> a) namespace pollution: all opcodes are reserved words in
On Mar 8, 2006, at 22:55, Jonathan Worthington wrote:
The described mapping doesn't have any PBC portability issues AFAIK.
If 'L' is mapping to 'I' or not is chosen at runtime.
Wouldn't the required re-writing blow away the wins we get through
mmap'ing in bytecode files?
There isn't any re
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Yup, and I really, really don't like the idea of making our bytecode
format non-portable. Part of the point of having a VM is portability,
right?
The described mapping doesn't have any PBC portability issues AFAIK. If
'L' is mapping to 'I' or not
On Mar 7, 2006, at 23:44, Jonathan Worthington wrote:
The register mapping rules would be something like:
- Lx occupies registers I(2x, 2x+1) - this is compile time,
that is 'L1' prevents 'I2' and 'I3' from being assigned by the
register allocator
- the runtime mapping isn't portable due t
On Mar 7, 2006, at 23:44, Jonathan Worthington wrote:
- if you write PASM, overlapping Ix/Ly may cause warnings or errors,
but could be used in a non-portable way, if you know what you are
doing on a specific platform.
You still didn't address my question with these points, though.
mul L
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Depending on the arch (32 vs 64 bits) one of these opcodes is
suboptimal. With a new "L" (Long) register type the functionality could
be handled transparently:
$L0 = pio.'tell'()
Yes, but as you add more register types you get a combinatorial b
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 7 Mar 2006 00:11:13 +0100
On Mar 6, 2006, at 23:16, Jonathan Worthington wrote:
> "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
>> $I0 = pio.'print'("sample data\n") # return sucess (>=0) or
>> failure (<0)
>> pio.
On Mar 7, 2006, at 0:31, Allison Randal wrote:
pio = socket(".AF_UNIX", ...)
It seems like a more general problem than that. Like, you want a way
of flagging a constant when you define it as to whether it should be
substituted when compiling to bytecode or substituted when
interpreting t
On Mar 5, 2006, at 13:52, Joshua Isom wrote:
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't
work
yet), would suffice and is generated at compile time. Parsing .h
On Mar 7, 2006, at 0:31, Allison Randal wrote:
It's overkill to require people to write:
P0 = getstdout
P0.'print'(S1)
Yep. The more that printing to stdout is heavily used in the test
suite. OTOH opcode vs method is merely a matter of what the assembler
is creating. That is: there are 2 n
On Mar 6, 2006, at 5:31 PM, Allison Randal wrote:
On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes
On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
Some remarks re the pdd and discussion so far.
o "write" ... [Is this redundant?]
"write" isn't needed. It is there, as some time ago, "print" was't
able to write strings with "\0"s inside.
Now marked in the PDD as deprecated.
(To make
On Mar 6, 2006, at 23:16, Jonathan Worthington wrote:
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
$I0 = pio.'print'("sample data\n") # return sucess (>=0) or
failure (<0)
pio.'print'("sample data\n") # throw exception on failure
Could perhaps get fun for compilers though
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overrida
On Mar 5, 2006, at 15:35, chromatic wrote:
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
[It's worth considering making all the network I/O opcodes use a
consistent way of marking errors. At the moment, all return an
On Mar 6, 2006, at 6:08 AM, Leopold Toetsch wrote:
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overridable, that is you can't provide your own
'print' opcode for e.g. debugging
c) all such IO opcodes ha
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=head2 Network I/O Opcodes
Functionality wise, the following are missing:
shutdown
getpeername/getsockname
getsockopt/setsockopt
I'd view shutdown as most important, as I believe that there are some
protocols you can't i
On Mar 3, 2006, at 20:27, Allison Randal wrote:
We're going to try something a little different. With Chip's blessing
I've written a very early draft of the PDD for I/O (not numbered yet).
The attached PDD isn't a completed document with Chip's seal of
approval, it's a seed for discussion.
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
> On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> [It's worth considering making all the network I/O opcodes use a
> consistent way of marking errors. At the moment, all return an integer
> status code except for C, C, a
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't work
yet), would suffice and is generated at compile time. Parsing .h
files
This way does the numeric values of
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
>
> On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
>
> >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> >
> >Should the network opcodes even be loaded as standard? C et al
> >aren't
> >actually that useful on Perl
On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
Should the network opcodes even be loaded as standard? C et al
aren't
actually that useful on Perl 5 without all the constants in the Socket
module,
so in practical terms a redes
On Mar 5, 2006, at 20:11, Nicholas Clark wrote:
C flags the stream as operating in line-buffer mode (see
C below). Lines are truncated at 64K.
Is there a fundamental need for a hard hard limit?
There used to be a hard limit until about a year ago. This is of course
gone now.
leo
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
[It's worth considering making all the network I/O opcodes use a
consistent way of marking errors. At the moment, all return an integer
status code except for C, C, and C.]
IIRC the Linux kernel uses negative values as return c
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=item *
C retrieves a single line from a stream into a string. Calling
C flags the stream as operating in line-buffer mode (see
C below). Lines are truncated at 64K.
Is there a fundamental need for a hard hard limit?
On Sun, Mar 05, 2006 at 18:34:26 +, Nicholas Clark wrote:
> On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
>
> > I don't think it's really been addressed, at least not recently, but
> > what about IPv6? By the time perl6 becomes commonplace and used
> > often(and thus, parrot)
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> What I need from you all is comments. What's missing? What's
> inaccurate? What's accurate for the current state of Parrot, but is
> something you always intended to write out later? What thoughts have
> you had on how the I/O
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
> I don't think it's really been addressed, at least not recently, but
> what about IPv6? By the time perl6 becomes commonplace and used
> often(and thus, parrot), IPv6 will be common enough that problems could
> occur. Currently it
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
> How do you verify that a print succeeded? Currently there's no way to
> know. Throwing an exception if a global flag is set would suffice and
I assumed that the lack of documentation of any return code meant that it
would return as
With respect to async IO (regretfully I get to see a lot of this at
$job):
Each operation can be async, or sync, with a similar API. There
should be enough hooks to be able to wait on a specific operation
happenning on a stream, any operation on a stream, any operation on
a group of streams, and a
How do you verify that a print succeeded? Currently there's no way to
know. Throwing an exception if a global flag is set would suffice and
wouldn't require constantly pushing exception handlers in case the
program doesn't care enough (e.g. the run it and delete it variety).
Plus using excep
37 matches
Mail list logo
