> 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
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
> 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
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.
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
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)
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.
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
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
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
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
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
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
> "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 {
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
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
> 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
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,
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
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
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
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
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)
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'
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
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)?
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"
$
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
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
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
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
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
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
33 matches
Mail list logo