Thanks for all the comments. I started this thing as a goof, but I can
already see that it will serve dual purposes. Presenting information
in such a form can lead people to further insights and questions.
Deborah Pickett's comments in this thread are an example. (For some
real inspiring
Uri Guttman wrote:
are you going to predict any new operators based on missing boxes as
mendeleev did? :)
Funny you should ask! It is clear that there is a missing list
concatenate operator, and that its spelling should be ~~. Alas, that
is already taken by smart match. On the other hand,
# New Ticket Created by Midnight
# Please include the string: [perl #29917]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29917
Under windows (I didn't try on unix), yy_init is not reinitialised after
yyparse
# New Ticket Created by Will Coleda
# Please include the string: [perl #29924]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29924
Escaping quotes doesn't seem to work:
bash-2.05a$ cat quoting.imc
.sub main
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
I think next step would need to review Cygwin math
lib sources and trace
into the library. Nasty.
Parrot isn't using GMP right? I am not sure where to
go look for the math lib sources other than the math
header /usr/include/math.h ???
Is your
1) Async vs sync
Currently the ParrotIOLayerAPI [1] has distinct entries for Open, Read,
Write with _Async appended. These are of course all unimplemented. Dan's
draft [2] has additionally async variants of seek and tell [3].
I'm thinking of a separate IO layer (above the default OS layer(s))
Midnight [EMAIL PROTECTED] wrote:
Under windows (I didn't try on unix), yy_init is not reinitialised after
yyparse call. It is not possible to compile parrot assembler two times
in the same process because the static variable yy_init in imclexer.c is
set to 0 after the first parsing.
$ grep
I didn't get much comments for my proposal WRT IO changes. So I'll
sumarize my next planned steps:
* use Parrot_stat_info_intval(..., STAT_FILESIZE) in
embed.c:Parrot_readbc() to obtain the PBC file size [1]
* convert all IO Read layer functions to return a STRING* [2]
* toss PIO_read()
William Coleda [EMAIL PROTECTED] wrote:
I've been trying to wrap my head around freezing and objects. My
current understanding is that:
o parrotclass extends delegate
o delegate's freeze vtable entry is Parrot_delegate_freeze
o Parrot_delegate_freeze should delegate the freeze vtable
# New Ticket Created by Will Coleda
# Please include the string: [perl #29927]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29927
Dumper is currently unable to dump the 'Array' type that's used by the 'foldup'
At 1:15 PM +0200 5/28/04, Leopold Toetsch wrote:
1) Async vs sync
Currently the ParrotIOLayerAPI [1] has distinct entries for Open,
Read, Write with _Async appended. These are of course all
unimplemented. Dan's draft [2] has additionally async variants of
seek and tell [3].
I'm thinking of a
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT [3] the AIO docs in info libc indicate that after issueing an
LT aio_read or aio_write, the file position is undefined, because these
LT functions might execute in any order. The async tell or seek seems
LT really to be needed, if one
# New Ticket Created by Joshua Gatcomb
# Please include the string: [perl #29936]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29936
---
osname= cygwin
osvers= 1.5.9(0.11242)
arch= cygwin-64int
cc= gcc
Dan Sugalski [EMAIL PROTECTED] wrote:
Why don't we wait a bit? I should be done with the second draft of
the events/IO spec today, and we can go from there.
That's alway an option ;) But, if you did read on, there was a bit more
to think about. Not directly event/IO related.
And: fixing the
Uri Guttman [EMAIL PROTECTED] wrote:
this is another reason to drop seek/tell as separate ops and just add a
seek offset as an arg to the i/o ops. tell is useless in the aio
world. the user code needs to manage its own seek location and pass it
into each call.
Well, yes that's true. OTOH we
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT Uri Guttman [EMAIL PROTECTED] wrote:
this is another reason to drop seek/tell as separate ops and just add a
seek offset as an arg to the i/o ops. tell is useless in the aio
world. the user code needs to manage its own seek location
At 4:21 PM -0400 5/28/04, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT Uri Guttman [EMAIL PROTECTED] wrote:
this is another reason to drop seek/tell as separate ops and just add a
seek offset as an arg to the i/o ops. tell is useless in the aio
world. the user
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 4:21 PM -0400 5/28/04, Uri Guttman wrote:
i am not against having a sync api but as dan said it should be a
wrapper around the async stuff. but as we agree (and dan hasn't acked
yet) the aio ops need a seek arg and the seek/tell ops
Not to beat a dead horse, but
I've updated the Periodic table with almost all the changes that people
here sent me, as well as reading a few more threads and references.
This will be the last update for some time. I'll be uploading a
version to cafepress so people can get posters,
-Original Message-
From: Mark Lentczner [mailto:[EMAIL PROTECTED]
Sent: Friday, May 28, 2004 7:18 PM
To: [EMAIL PROTECTED]
Subject: Re: Periodic Table of the Operators
Not to beat a dead horse, but
I've updated the Periodic table with almost all the changes that people
# New Ticket Created by Will Coleda
# Please include the string: [perl #29938]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29938
bash-2.05a$ cat escape.imc
.sub _main @MAIN
load_bytecode
21 matches
Mail list logo
