[perl #29938] [PATCH] Data::Escape String - backslash

# New Ticket Created by Will Coleda # Please include the string: [perl #29938] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=29938 > bash-2.05a$ cat escape.imc .sub _main @MAIN load_bytecode "library/Data/Escape.imc

FW: Periodic Table of the Operators

> -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 p

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 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, tee-shir

Re: Q: IO layers

> "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

Re: Q: IO layers

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 >

Re: Q: IO layers

> "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 ow

Re: Q: IO layers

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. OTO

Re: Q: IO layers

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 th

[perl #29936] JIT debugging on Cygwin not working

# New Ticket Created by Joshua Gatcomb # Please include the string: [perl #29936] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=29936 > --- osname= cygwin osvers= 1.5.9(0.11242) arch= cygwin-64int cc= gcc 3.3.1 (c

Re: Q: IO layers

> "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 nee

Re: Q: IO layers

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 se

[perl #29927] [PATCH] Dumper can't dump 'Array'

# New Ticket Created by Will Coleda # Please include the string: [perl #29927] # in the subject line of all future correspondence about this issue. # 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' opcode

Re: Freeze, objects, crash, boom.

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 vtabl

PIO_read, PIO_reads

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() interfac

Re: [perl #29917] bug on yy_init

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. $

Q: IO layers

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)) th

Re: JIT problem on Cygwin revisited

--- 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 ??? > >

[perl #29924] [PATCH] Data::Escape->String quoting problem.

# New Ticket Created by Will Coleda # Please include the string: [perl #29924] # in the subject line of all future correspondence about this issue. # 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 @MAIN

[perl #29917] bug on yy_init

# New Ticket Created by "Midnight" # Please include the string: [perl #29917] # in the subject line of all future correspondence about this issue. # 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 call.