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
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::
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
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
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
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
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_
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-
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
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;
# 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
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
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
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, 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.
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
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:
> >
> > >
> >
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
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
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 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
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]>
# 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
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 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, David Lloyd wrote:
> This patch removes the const-ness of those STRINGs that are modified.
Applied, thanks.
> 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 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
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, 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
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:
> 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 :)
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 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
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 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
I'm sort of side-tracking from the trend of discussions, but I was just
thinking that I always found it annoying how you had to double backslashes
in single-quoted strings. I like the bash's behavior with regard to this
much better... I mean, the whole idea behind single-quoted strings is tha
On 5/20/02 8:04 PM, "Luke Palmer" <[EMAIL PROTECTED]>
claimed:
> 'You think I' _ q{'} _ 'm knit-picking!'
Ugh. If you really don't like back-slashing single quotes, do this:
q{You think I'm knit-picking!};
I would agree that in a q{} context, it is silly that a double-backslash
prints a single
Luke Palmer writes:
: I'm sort of side-tracking from the trend of discussions, but I was just
: thinking that I always found it annoying how you had to double backslashes
: in single-quoted strings. I like the bash's behavior with regard to this
: much better... I mean, the whole idea behind s
> : Would something like these DWIM?
> :
> : # match pat1 _ pat2 and capture pat2 match:
> : / pat1 { ($foo) = / pat2 / } /
>
> Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo)
Me writes:
: > : Would something like these DWIM?
: > :
: > : # match pat1 _ pat2 and capture pat2 match:
: > : / pat1 { ($foo) = / pat2 / } /
: >
: > Yes
:
: So a match in a closure starts where the outer match
: was. Simple enough.
:
: Will:
:
: # match pat1 _ pat2 _ pat3 and ca
42 matches
Mail list logo
