On Wed, 2004-05-05 at 22:54, Leopold Toetsch wrote:
> > I'd like to be able to access pixels (an array of Uint32s) directly in
> > some cases.
> > + set P2[ 'i' ], .DATATYPE_PTR
> Why not just define an array of uintvals? The pointer type does nothing
> useful AFAIK.
It's true that the pointer
OK, when I compile this code to PASM, then execute it,
it works just fine (prints "i like peanuts", "hello",
then "goodbye"). But if I call parrot directly on the
IMCC code, it gives me a segmentation fault after
printing "i like peanuts".
.sub looper
print "i like peanuts\n"
shooper()
I was writing a few tests for the P6 parser and ran into a weird problem.
If I have the following in a file in languages/perl6, it works as
expected:
The file contains:
===
use P6C::Parser;
use Perl6grammar;
my $grammar = new Perl6grammar;
print $grammar->sigil('$'),"\n";
print $grammar->
On May 8, 2004, at 10:30 AM, Dan Sugalski wrote:
Do we want to make a distinction between record reads and just plain
"read me X (bytes|codepoints|graphemes)" requests on filehandles and,
if so, do we think it's worth distinguishing between fake records
(line-oriented things) and real records (
At 11:06 PM +0200 5/8/04, Bernhard Schmalhofer wrote:
Hi,
since the last couple of days 'Parrot m4' does strange things when using
a fresh 'parrot'. Internally 'libpcre' is used for regular expression
matching. For a strange reason some strings are not matching any more.
I boiled it down to a test
Hi,
since the last couple of days 'Parrot m4' does strange things when using
a fresh 'parrot'. Internally 'libpcre' is used for regular expression
matching. For a strange reason some strings are not matching any more.
I boiled it down to a test case of 50 lines of PIR. Could somebody take a
look
At 9:04 PM +0200 5/8/04, Ron Blaschke wrote:
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
Another todo list task for the interested. A perl & linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we wan
Leopold Toetsch writes:
> [1] yes I'm thinking of just one frame pointer :) Well, the whole scheme
> makes a stack machine out of Parrot:
>
> I0,...In, In+1Ik, Ik+1...Il
> ^
> |
> frame
> pointer
>
> I0..In are the incoming function arguments
> In+1..Ik are the working registers of the funct
At 3:20 PM -0500 5/5/04, Abhijit A. Mahabal wrote:
This is a patch for one of the ToDo items in languages/perl6/Todo. I have
updated the calling conventions in a bunch of places, but may have missed
some.
Applied, thanks.
BTW, should I keep working on P6C? As A12 has just come out P6C may be
heavi
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #29441]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29441 >
Documentation update, including build instructions for local ICU
installation.
TODO.
On May 8, 2004, at 3:40 AM, Nicholas Clark wrote:
The problem came down to me storing not the PMC pointer, but the 1's
complement
of it in the perl SV.
...
However, I forgot to do the 1's complement on the value passed to the
unregister PMC call
...
(As for all its inherent horrors, perl's refere
Okay, as I work on this, time to weigh in with opinions.
Do we want to make a distinction between record reads and just plain
"read me X (bytes|codepoints|graphemes)" requests on filehandles and,
if so, do we think it's worth distinguishing between fake records
(line-oriented things) and real r
At 12:43 PM +0200 5/8/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I'm up for the mmd-variant version. We just have a one-dimensional
table for PMC/int, PMC/float, and PMC/string functions and have the
ops directly dispatch to it. Seems simpler than stuffing the
functions
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> As Nick seems to be hitting some limits, I've tried this:
> stuff a differing amount of PMCs into an Array and time a DOD run:
> $ parrot -j 10m.pasm
> create 1e+06 PerlInts 2.051168
> DOD sweeps: 21 one is 0.141291
> $ parrot -j 10m.pasm
> create
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
>>> Another todo list task for the interested. A perl & linker thing.
>>>
>>> Right now, through the wonders of the Unix default linking
>>> conventions, every function in parrot gets exported whether we want
>>> them to be or not, and gen
Tor Petterson <[EMAIL PROTECTED]> wrote:
> I am trying to throw and exception from inside a pmc
> so I have this handler
> .sub _handler
>$S1 = P5["_message"]
>if $S1 == "Myexception" goto l1
>rethrow P5
> l1:
>.pcc_begin_return
>.return P5
>.pcc_end_return
> .end
You can'
For reference Dan's blog entry at:
http://www.sidhe.org/~dan/blog/archives/000321.html
I think that the situation has changed again and that we should consider
the original register in the stack scheme.
1) In the presence of MMD and delegate functions, object acessor methods
and OO in general, w
Jens Rieks <[EMAIL PROTECTED]> wrote:
> parrot crashes if any PIR file that is parsed contains:
> .emit
> #
> .eom
Yes.
$ cat imcc/BUGS
BUGS:
...
- the parser doesn't like empty subs:
.sub _foo
.end
inserting a 'noop' helps.
> jens
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm up for the mmd-variant version. We just have a one-dimensional
> table for PMC/int, PMC/float, and PMC/string functions and have the
> ops directly dispatch to it. Seems simpler than stuffing the
> functions into the base MMD table too.
We currently h
I am trying to throw and exception from inside a pmc
so I have this handler
.sub _handler
$S1 = P5["_message"]
if $S1 == "Myexception" goto l1
rethrow P5
l1:
.pcc_begin_return
.return P5
.pcc_end_return
.end
registrered like this
.local Exception_Handler hndl
newsub hndl, .Exceptio
# New Ticket Created by Jens Rieks
# Please include the string: [perl #29440]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29440 >
Hi,
parrot crashes if any PIR file that is parsed contains:
.emit
#
.eom
jens
On Sat, May 08, 2004 at 10:01:56AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> [ half second DODs ]
>
> > 0.07 1266.73 0.86 9459863 0.00 0.13 get_free_object_df
>
> > 0.05 1268.18 0.62 124063316 0.00 0.00 int_compare
>
> Looki
Nicholas Clark <[EMAIL PROTECTED]> wrote:
[ half second DODs ]
> 0.07 1266.73 0.86 9459863 0.00 0.13 get_free_object_df
> 0.05 1268.18 0.62 124063316 0.00 0.00 int_compare
Looking at these 2 lines: You got 9.5 million PMCs. That would be ok,
*if* these actuall
Adam Thomason <[EMAIL PROTECTED]> wrote:
> _main:
> set I1, 0x
> shl I1, I1, 32
> set I2, 0x
> print I2 # prints -1
Old imcc code strikes back. It used atoi() and with 32 bit ints and 64
bit opcodes/INTVALs this is the expected and wrong result.
I've now changed a
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> +void *
> +Parrot_Embed_PMC_get_pointer(Parrot_Interp interp, Parrot_PMC pmc) {
> +if(interp->lo_var_ptr) {
> +return Parrot_PMC_get_pointer(interp, pmc);
> +} else {
> +void *result; /* Doubles up as an indicator of stack top. *
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> *) Lay in a generational garbage collector.
> Good for that degenerated case, probably, but see below.
A generational GC still has to mark the root set and the old
generation's objects. So it wouldn't be of a
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 06, 2004 11:49 PM
> To: Adam Thomason
> Cc: [EMAIL PROTECTED]
> Subject: Re: [perl #29257] Build libnci.so by default
>
>
> Adam Thomason <[EMAIL PROTECTED]> wrote:
>
> > amd64 breaks. Shared l
27 matches
Mail list logo
