Um, I don't think it's right to *always* do the comparison
floating point. Specifically, if both operands are ints,
the comparison should be int.
I thought about this, but all it buys you is a few bits of precision when
your ints and floats are both 64-bit, and slower comparisons all
My suggestion is to add on vtable.tbl comment like
void set_integer_native(INTVAL value) # example: set P0, I0
void set_number_native(FLOATVAL value) # example: set P0, N0
and so on. Of course the content of the comment can be more descritive.
Then, I changed parse_vtable and genclass.pl to
Ok, I cleaned up the file a little bit, and added pod
declarations. Should be finalized or close to it at
least. If anyone likes it, I'll start working on
making a .dev file for some other files, and start
asking questions while I'm at it probably :)
Stephen Rawls
Hi
On my usual place (http://natura.di.uminho.pt/~albie/parrot) I put some
more documentation:
- PerlString examples
- PMC Writting stub (will be, someday, a tutorial for writting PMC's.
Meanwhile, I'm learning how to write them :))
Regards
Alberto
--
Alberto
On Mon, Jul 15, 2002 at 10:17:51PM -0700, John Porter wrote:
Sean O'Rourke wrote:
... all it buys you is a few bits of precision when your ints
and floats are both 64-bit, and slower comparisons all the time.
IMHO it's a wash, so I did it this way.
I would point out that integers have
I have a couple of question regarding using keyed access in assembler.
Lets say we create an Perlarray:
new P0, .PerlArray
set P0,5
Array with size 5.
assembler.pl will call set_p_ic ( ? maybe im wrong here )
But what about setting size on multdimensional PMC's would it also be:
set
On Tue, 16 Jul 2002, Nicholas Clark wrote:
5.8.0 does the full fun and games of integer or floating point comparison:
perl5.8.0-64 -le '$a = ~0; $b = $a ~1; printf %x = %x\n, $a, $b; print $a =
$b; {use integer; print $a = $b}'
= fffe
1
1
IIRC the speed
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like predictive seeks, or
bundling up multiple read/writes, etc. aren't doable with select/poll loops.
And the
Damien Neil wrote:
I'm not familiar with predictive seeks,
can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000 bytes in order, you're probably going to want to read the
next 1000
On Tue, Jul 16, 2002 at 11:35:10AM -0700, John Porter wrote:
Damien Neil wrote:
I'm not familiar with predictive seeks,
can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000
On Tue, 16 Jul 2002, John Porter wrote:
In his P6 Summary for 2002-07-14, in section
Perl 6 grammar, take 5, Piers says:
someone pointed out that [the grammar] had a problem
with code like
{ some_function_returning_a_hash() }
Should it give a closure? Or a hash
Still trying to solve the assembly/PMC vector interface. Accosted Dan on IRC re:
multidimentional indices.
Looking for thoughts on this.
Working under assumptions:
* There is no assembler syntax yet, or atleast not final.
* Hardcoding KEY *'s into the assembly is the only way so far.
*
Scott Walters wrote:
* PMC's be accepted in place of or in addition to KEY *'s
in variants taking multidim subscripts.
In particular, a PMC containing a vector (aka tuple, aka array)
of indices, one per dimension.
As in so many other cases, the array object and the key vector
object should
But what about setting size on multdimensional PMC's
would it also be:
set P0,5,5,5
assembler.pl would try to call
set_p_ic_ic_ic
This will break things when having N dimensions..
I don't see how it could possible be workable
to have all the indices listed out in the
On Mon, 15 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
Do we really want *two* inheritance trees per object
in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
Ugh.
The MM dispatch problem is pretty much solidly in
the realm of pmc
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want.
The point is that this type schema is at the parrot level,
John Porter wrote:
The point is that this type schema is at the parrot level,
and is not the concern of a user-level language like perl
Of course this is not really true; perl scalars, arrays, and
hashes (etc.?) are implemented as PMCs under the hood, so
in that sense they are related by
On Tue, 16 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want. The point is
# New Ticket Created by Tony Payne
# Please include the string: [perl #825]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=825
Conversion from a signed (int,float) to an unsigned int was causing
underflow.
On Tue, Jul 16, 2002 at 07:42:25AM -0700, Sean O'Rourke wrote:
On Tue, 16 Jul 2002, Nicholas Clark wrote:
5.8.0 does the full fun and games of integer or floating point comparison:
perl5.8.0-64 -le '$a = ~0; $b = $a ~1; printf %x = %x\n, $a, $b; print $a
= $b; {use integer; print $a =
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
2) Filters (or IO disciplines) - People have different opinions on what
these
even mean. To me it means a layer that can be pushed onto an IO stack
that may filter or transform the data and/or perform opaque actions, while
David M. Lloyd wrote:
No, the point is that all this talk about type-space mm dispatch
depends on there *being* type space. Since there is currently
no inheritance to speak of then there really is no typespace so
all of this talk is moot,
I agree; but you did express a concern earlier that
Nicholas Clark wrote:
... PerlIO::subfile (treats a section
of a file as if it is a whole file - lets you read direct from a tar
on an uncompressed file stored in a zip file)
Ah -- just like Virtual File Systems (VFS) from Tcl-land.
Good idea!
('COURSE it's a good idea!)
--
At 09:42 AM 7/16/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like predictive seeks, or
bundling up multiple read/writes, etc.
At 05:08 PM 7/15/2002 -0700, Stephen Rawls wrote:
Ok, I cleaned up the file a little bit, and added pod
declarations. Should be finalized or close to it at
least. If anyone likes it, I'll start working on
making a .dev file for some other files, and start
asking questions while I'm at it
Melvin Smith wrote:
I put it temporarily in the root dir, which I know is wrong.
Where should .dev files go, anyway?
Actually, I think that's right.
..dev files live alongside their .c/.h siblings, no?
--
JohnDouglasPorter
__
Do You Yahoo!?
Well, the .h files live elsewhere, but yeah, for now I think .dev files
should live with the .c files. Unless someone has an alternative
suggestion.
I'll update make check_source and pdd07 to reflect this.
--Josh
At 18:14 on 07/16/2002 PDT, John Porter [EMAIL PROTECTED] wrote:
Melvin
Applied.
Applied, thanks!
Applied, Thanks!
Applied, thanks..
Applied, thanks!
OK, I've been playing with Parrot
and reading the mailing list for
a while. (My first post; whee!)
1)
What's with the big mess in
Parrot_readbc? Why not just
start a pbc file with something
like:
#comment
bytecode[7345]:\n
7345 bytes of bytecode
This way you wouldn't have to
worry about where
33 matches
Mail list logo
