Re: [PASM] problem opening / reading file

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote: >At 11:13 PM -0400 8/12/02, Clinton A. Pierce wrote: >>At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote: >> >>>I looked at parrot_assembly.pod and saw: >>>open px, sy >>>Open the file Y on filehandle X >>>read px, py, pz

Re: Autovivi

On Mon, 5 Aug 2002, Dan Sugalski wrote: > At 1:30 PM +1000 8/6/02, Damian Conway wrote: > >Luke Palmer asked: > > > >>Does: > >> > >> print %foo{bar}{baz}; > >> > >>still create %foo{bar} as a hashref if it doesn't exist? > > > >It is my very strong hope that it will not. > > Unless Larry de

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Hash should support integer lookup. PerlHash doesn't have to, and may > throw an exception. I don't follow the logic behind this... Making it work for one but not another is tricky - either get

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Arrays don't have to support lookup by string keys. They also can > throw an exception. How about numeric keys? Presumably they can also throw an exception as it doesn't make much sense to acce

Re: Keyed access to PerlArray/PerlHash

At 5:50 PM +0100 8/13/02, Tom Hughes wrote: >In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> Arrays don't have to support lookup by string keys. They also can >> throw an exception. > >How about numeric keys? Presumably they can also th

Re: Keyed access to PerlArray/PerlHash

At 5:49 PM +0100 8/13/02, Tom Hughes wrote: >In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> Hash should support integer lookup. PerlHash doesn't have to, and may >> throw an exception. > >I don't follow the logic behind this... Making

[PASM] PerlArray.length issue a warning

Hi, it's me again with my questions on pasm... I just downloaded the latest version of Parrot (it's currently 17:00 GMT). $ ./parrot -v [...] This is parrot version 0.0.7-devel built for i386-linux [...] $ cat test.pasm new P0, .PerlArray set P0[10], "foo" set I0, P0.length print I0 print "\n" $

[PATCH] core.ops and pod

One should begin with slight updates.. :) So this patch is just about pod in core.ops (unbalanced =over / =back, and a missing blank line). Btw, how do you prefer me to send patch (as if I were able to send more patches... anyway...): plain text inside the mail or attached (such as this one)?

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Nobody's doing a get_integer on key PMCs--we're peeking directly. > (Integer lookup can also be done via the keyed_int method of the > vtable) At the moment it is using get_integer as I decided

RE: [PASM] problem opening / reading file

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote: >Anyone up to throwing a list of outstanding > problems with the I/O system together? From: Clinton A. Pierce [mailto:[EMAIL PROTECTED]] >I'd volunteer, except that I'm used to grunging > around at the assembler level of I/O (INT 21h!) > or with C'

Re: Keyed access to PerlArray/PerlHash

On Tue, 13 Aug 2002, Tom Hughes wrote: > In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > Nobody's doing a get_integer on key PMCs--we're peeking directly. > > (Integer lookup can also be done via the keyed_int method of the > > vtable)

Re: [PASM] PerlArray.length issue a warning

Jerome Quelin wrote: >Hi, it's me again with my questions on pasm... > >I just downloaded the latest version of Parrot (it's currently 17:00 GMT). >$ ./parrot -v >[...] >This is parrot version 0.0.7-devel built for i386-linux >[...] >$ cat test.pasm >new P0, .PerlArray >set P0[10], "foo" >set I

Re: Autovivi

On Tue, 13 Aug 2002, Deven T. Corzine wrote: : However, will the "func($x{1}{2}{3})" case cause an implementation problem? This is why the new function type signatures will assume that parameters are constant. If you want a modifiable parameter, you have to say "is rw". Then it's considered an

Re: Autovivi

From: Larry Wall [EMAIL PROTECTED] > Of course, there are issues here if the code modifies those > variables, since the issue of whether a variable is rw is > really distinct from whether it represents a pass by value > or reference. Slapping a "constant" on it is a bald-faced > attempt to get th

Re: Autovivi

On Tue, 13 Aug 2002, [EMAIL PROTECTED] wrote: : From: Larry Wall [EMAIL PROTECTED] : > Of course, there are issues here if the code modifies those : > variables, since the issue of whether a variable is rw is : > really distinct from whether it represents a pass by value : > or reference. Slappin

Re: Autovivi

On Tue, 13 Aug 2002, Larry Wall wrote: > On Tue, 13 Aug 2002, Deven T. Corzine wrote: > : However, will the "func($x{1}{2}{3})" case cause an implementation problem? > > This is why the new function type signatures will assume that > parameters are constant. If you want a modifiable parameter,

The Perl5->Perl6 Convertor

> In essence, all Perl 5 functions have a signature of (*@_ is rw). > Perhaps the translator can turn some of those into (*@_). What'd > really be cool is if it could pick up an initial > > my ($a, $b, $c) = @_; Excuse my ignorance here, but I thought the plan for backwards compatibility wit

Re: Autovivi

On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote: > The only accurate way to know if the code modifies the variables is to do > some sort of dataflow analysis, and it can't be 100% accurate even then. > (Suppose a "shift" may or may not happen, depending on the parameters, then

Re: Autovivi

On Tue, 13 Aug 2002, Nicholas Clark wrote: > On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote: > > > The only accurate way to know if the code modifies the variables is to do > > some sort of dataflow analysis, and it can't be 100% accurate even then. > > (Suppose a "shift" ma

Re: Autovivi

> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> Well, perl5 does already manage to avoid auto-vivifying hash keys NC> when they are used as subroutine arguments. It uses magic, rather NC> than dataflow analysis: NC> sub rval { NC> my $a = $_[0]; NC> } NC> sub lval {

Re: Prototypes

On 13 Aug 2002, Piers Cawley wrote: > Melvin Smith <[EMAIL PROTECTED]> writes: > > > At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote: > > >Here's a more interesting question: which parts of Parrot are > > >enshrined, and which are prototypes, ready to be thrown away? For > > >instance, I'd say mu

[PATCH] new op in core.ops

Well, I don't know if this is interesting, but here's a patch that implement: op rand(out NUM) op rand(out NUM, in INT) and does what you can guess. There's also a test file (I don't know wether the tests should go in an existant test file). But, there is a tiny, little problem: I don't c

Re: [PATCH] core.ops and pod

Jerome Quelin wrote: > > Btw, how do you prefer me to send patch (as if I were able to send more > patches... anyway...): plain text inside the mail or attached (such as this > one)? This is a great start, Jerome! A name for the patch might be a nice touch, but it applied just fine. -- Jeff <[EM

Re: [PATCH] new op in core.ops

Jerome Quelin wrote: > --snip-- > But, there is a tiny, little problem: I don't call srand(), and thus get > always the same value. I don't know *where* to call srand(). I don't even > know *if* I should call srand(). > Anyway, here's the patch and be kind since this is my first patch ;) (pod > c

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

In tracing down the next crash bug using GC_DEBUG, I found that the following code in new_stack is unsafe: stack->buffer = new_buffer_header(interpreter); Parrot_allocate(interpreter, stack->buffer, sizeof(Stack_Entry_t) * STACK_CHUNK_DEPTH); A GC can be triggered by

Re: Prototypes

Piers Cawley wrote: > I'd also like to be able to generate parrot code from within parrot > and immediately execute it... Something like that will be needed for eval() anyway, right? -- John Douglas Porter

Re: Prototypes

On Tue, 13 Aug 2002, John Porter wrote: > Piers Cawley wrote: > > I'd also like to be able to generate parrot code from within parrot > > and immediately execute it... > > Something like that will be needed for eval() anyway, right? Yes, like PDB_eval() may be... Daniel Grunblatt.

Re: debugger.pod

On Fri, 2 Aug 2002, Aldo Calpini wrote: > > hello everybody, > > here is my rough draft of the documentation for the > Parrot debugger. please review it (expecially the > boilerplate stuff like TITLE, HISTORY, etc. -- I don't > know if I have properly followed convention) (and if there > is one)

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

This is a patch that clears up all of the GC_DEBUG-revealed bugs, at least on my machine. As I enumerated in my previous email, there are a lot of different ways to fix these sorts of problems, and this just kinda picks one for each problem encountered. This patch includes the stuff done by Jason

Re: [PATCH] hash init (Version 5)

On 12 Aug 2002, Jason Greene wrote: > One more safety check (fixes another crash bug). Hopefully this is the > last patch patch. Applied, thanks. Daniel Grunblatt.

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

> I have also come to the conclusion that tracking down these memory > bugs is way too difficult right now. I tracked the above problem back > from a seg fault, which was resulting from a garbage value in the byte > code stream, which was triggered by adding a PMC to the free list > until I added

Re: Autovivi

Uri Guttman wrote: [ CCs stripped ] > ... what if you passed \$a{llama}{alpaca}? even as a read only param, > you could deref later through the ref in another sub that gets passed it > from this sub. If I understand Dan's proposal () for a change in the KEYed methods correctly, this would wo

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

> Somebody gimme a cookie. /me hands Steve a cookie. > If the rx info object is going away, then obviously those parts of the > patch need not be applied. But in the meantime, it's nice to have a > Parrot that doesn't crash. I agree. My disclaimer about the regex code in my original email was t