On Mon, 20 May 2002, Jason Gloudon wrote:
>
> The buflen of a new header was not always set to 0, which would cause SIGSEGVs
> when parrot_reallocate tries to copy a non-zero length buffer with a bufstart
> of NULL. This would happen when buffers get recycled.
>
> I don't know if new_pmc_header
The buflen of a new header was not always set to 0, which would cause SIGSEGVs
when parrot_reallocate tries to copy a non-zero length buffer with a bufstart
of NULL. This would happen when buffers get recycled.
I don't know if new_pmc_header has the same problem, but it also does not
initialize
On Fri, May 17, Nicholas Clark wrote:
> On Thu, May 16, 2002 at 08:37:32PM -0400, Dan Sugalski wrote:
> > Pssst. Brent. Don't tell anyone, but ~0 *is* -1... :)
>
> $ perl -le 'print ~0'
> 4294967295
> $ perl -le 'print -1'
> -1
>
> What language were we talking about? :-)
$ perl -e 'printf "%d
On Mon, 20 May 2002, Daniel Grunblatt wrote:
>
> On Mon, 20 May 2002, David M. Lloyd wrote:
>
> > What about subroutines? Are bsr & jsr the way it's gonna be or is there
> > a rework in the works?
>
> docs/pdds/pdd03_calling_conventions.pod :)
OK, I've looked it over but it doesn't say "Subrout
On Mon, 20 May 2002, David M. Lloyd wrote:
> What about subroutines? Are bsr & jsr the way it's gonna be or is there
> a rework in the works?
docs/pdds/pdd03_calling_conventions.pod :)
Steve Fink wrote:
> Is there some way to make the default be that things will not get
> moved around, and allow routines to volunteer to have their guts
> scrambled if they know how to handle it?
A few random thoughts re buffers that don't wander around on their own:
Create a new memory pool for
On Mon, 20 May 2002, David M. Lloyd wrote:
> Has anyone given any thought to this problem yet?
>
> Will we be able to do this or do we need a special vtable whose entries
> automatically do a callback to Parrot?
For that matter, what about calling C functions from Parrot? Loading PMCs
dynamical
On Sun, May 19, 2002 at 10:43:20PM -0400, Mike Lambert wrote:
> I started to look into the GC crashes with the perlhash tests. I'm not
> sure I found the exact problem, but I found a bunch of dangerous things
> that were being done, and could possibly cause the GC problems.
>
> restore_invariants
On Mon, 20 May 2002, Jason Gloudon wrote:
>
> The disassembler isn't happy at the moment, this patch appears to fix
> the problem it has with the bytecode header.
>
Applied, thanks.
Ok, this is now obsolete. I was too slow, I guess. :-) The following
patch (1) is no longer needed because Peter's new version has already
been committed, and (2) fails to pass a stacks.t test. But in case we
want to keep the neonate counters, here's an updated version of
Peter's original neonate
> At 12:06 AM -0400 5/19/02, Mike Lambert wrote:
> >Is there a plan to make a freed method for when pmc header gets put
back
> >onto the free list? (This would require we call this method on all
pmc's
> >before moving anything to the freelist, in case of dependancies between
> >pmcs and buffers)
>
On 20 May 2002, David Lloyd wrote:
> This patch removes the const-ness of those STRINGs that are modified.
Applied, thanks.
# New Ticket Created by David Lloyd
# Please include the string: [netlabs #605]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=605 >
I get:
cc -mt -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I./inc
On 20 May 2002, Peter Gibbs wrote:
> # New Ticket Created by "Peter Gibbs"
> # Please include the string: [netlabs #602]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=602 >
>
>
> Attached patch to core.ops implements
# New Ticket Created by "Peter Gibbs"
# Please include the string: [netlabs #602]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=602 >
Attached patch to core.ops implements neonate protection for the 'pack'
opcode. The
Has anyone given any thought to this problem yet?
Will we be able to do this or do we need a special vtable whose entries
automatically do a callback to Parrot?
- D
<[EMAIL PROTECTED]>
At 12:06 AM -0400 5/19/02, Mike Lambert wrote:
>Is there a plan to make a freed method for when pmc header gets put back
>onto the free list? (This would require we call this method on all pmc's
>before moving anything to the freelist, in case of dependancies between
>pmcs and buffers)
Nope. I do
On Mon, 2002-05-20 at 17:47, Dan Sugalski wrote:
> At 5:25 PM +0100 5/20/02, Alberto Manuel Brandão Simões wrote:
> >Directory Parrot on root cvs parrot tree was deleted by hand, or why
> >can't I update it?
>
> You're looking at the Parrot directory within parrot itself, right?
> It was removed
At 5:25 PM +0100 5/20/02, Alberto Manuel Brandão Simões wrote:
>Directory Parrot on root cvs parrot tree was deleted by hand, or why
>can't I update it?
You're looking at the Parrot directory within parrot itself, right?
It was removed ages ago, and its contents moved into lib/. It was
conflictin
Still, this problem is unsolved:
set I0,10
set S0,"#"
REDO: pack S1,1,S0
dec I0
print I0
print "\n"
if I0,REDO
end
Will core dump, because in :
inline op pack(inout STR, in INT, in STR) {
STRING *t,*s = $3;
UINTVAL len = (UINTVAL)$2;
char buf[3];
if
Try this:
cvs -d ":pserver:[EMAIL PROTECTED]:/home/perlcvs" get parrot
Daniel Grunblatt.
On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
> On Mon, 2002-05-20 at 17:58, Daniel Grunblatt wrote:
> > On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
> >
> > >
> >
On Mon, 2002-05-20 at 17:58, Daniel Grunblatt wrote:
> On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
>
> >
> > Directory Parrot on root cvs parrot tree was deleted by hand, or why
> > can't I update it?
>
> It works fine for me.
Anonymous CVS, of course
cvs server: cannot o
On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
>
> Directory Parrot on root cvs parrot tree was deleted by hand, or why
> can't I update it?
It works fine for me.
Directory Parrot on root cvs parrot tree was deleted by hand, or why
can't I update it?
Thanks
Alberto
--
Alberto Manuel B. Simoes
Departamento de Informática - Universidade do Minho
http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
On 20 May 2002, Peter Gibbs wrote:
> # New Ticket Created by "Peter Gibbs"
> # Please include the string: [netlabs #601]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=601 >
>
>
> Attached is a simplified version of a
The disassembler isn't happy at the moment, this patch appears to fix
the problem it has with the bytecode header.
Index: lib/Parrot/PackFile.pm
===
RCS file: /home/perlcvs/parrot/lib/Parrot/PackFile.pm,v
retrieving revision 1.15
d
# New Ticket Created by "Peter Gibbs"
# Please include the string: [netlabs #601]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=601 >
Attached is a simplified version of a previous patch to allow buffers to
avoid colle
Aldo Calpini wrote:
> and now for timings: [...]
em... forgot to include the platform details:
OS: Windows 2000 Advanced Server + Cygwin 1.3.10
CPU: AMD K7 550MHz
RAM: 256 MB
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
hi there,
the Examples page on www.parrotcode.org states this about subroutines:
The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch
and do not have to be preserved by the callee.
this seems to be false for *recursive* subroutines. this is my PASM
code fibo.pasm (it calcu
There are, at least native size issues, maybe not alignment issues; but
thats why I left that fixme warning in packfile to remind us to go back and
fix floats.
At least the fetch routines do it per-byte so they don't care.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-
On Sun, 19 May 2002, Mike Lambert wrote:
> > This patch removes a bunch of warnings that have accumulated with MSVC
> > recently.
Thanks. I'm down to 934 warnings now :-).
Index: packfile.c
-self->number = PackFile_fetch_nv(pf, (unsigned char *)cursor);
+self->number = PackFile_fetch_
Folks,
Yesterday I checked in the new JIT from Jason Gloudon.
Now it does NOT depend on an external assembler and disassembler
but instead uses some macros.
All tests succesful.
The size of the executable have been reduced by ~700K.
It should work on most x8
At 6:09 PM +0100 5/19/02, Nicholas Clark wrote:
>On Sat, May 18, 2002 at 07:33:53PM -0400, Dan Sugalski wrote:
>> At 7:25 PM -0400 5/18/02, Melvin Smith wrote:
>> >Yeh I know that word is yucky and from Java land, but in this case,
>> >I think that
>> >"system" PMCs should take liberties for o
I've been trying to catch up with parrot again (darn it, babies take
more time than I thought :) and I've come up with a question... how do
you do "other" things to PMCs that aren't normal ops? In particular, I
was wondering about shift/unshift, push/pop on the PerlArray PMC. Am I
missing somethi
On Sun, May 19, 2002 at 06:01:56PM +0100, Nicholas Clark wrote:
>
> Seriously though - is it possible to automate testing how many ops don't
> have tests? That way we could have a test that looked for untested ops, and
> failed if any weren't tested.
> I guess it couldn't easily be very sophistic
Jeffrey Goff (via RT) wrote:
> I've just patched lib/Parrot/Makefile.PL to check for a Win32 platform,
> and if so, use .obj for the default object extension. However I did it
> simply by checking $^O for 'Win'. This is probably not as portable as it
> could be, but a quick look through ExtUtils::
I submitted a patch to implement the initial parts of Dan's method some time
ago, which has never been applied. (Although Dan recently agreed that it
needed to be done, and I will be updating it shortly in line with changes to
the memory management system) However, thinking about it some more, the
37 matches
Mail list logo
