On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote:
So a native int could be 8 bits big? I think that's allowed according to
ANSI.
ANSI/ISO C states:
char = short = int = long
char = 8 bits
short = 16 bits
int = 16 bits
long = 32 bits
C99 adds "long long", which is
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
I don't recall the bit sizes to be in ANSI C. Which paragraph is that
in?
You need to deduce the bit sizes, as the standard doesn't speak in
terms of bits. I don't have a copy of C89 available, but section
5.2.4.2.1 defines the
On Wed, Dec 27, 2000 at 02:51:57PM -0500, Hildo Biersma wrote:
This seems likely, but we must take care not to take these assumptions
too far. For example, (and this is not realted to this discussion),
pointers may well be smaller than integers (MVS defines 32-bit ints and
31-bit pointers)
On Wed, Dec 27, 2000 at 05:17:33PM -0500, Dan Sugalski wrote:
The part I'm waffling on (and should ultimately punt to Larry) is what to
do with lazy data, and what exactly counts as lazy data anyway. For
example, tied variables certainly aren't passive data, but should they be
evaluated if
On Wed, Dec 27, 2000 at 09:27:05PM -0500, Dan Sugalski wrote:
While we can evaluate the list lazily, that doesn't mean that's what the
language guarantees. Right now it's perfectly OK to do:
$foo = ($bar, $baz, $xyzzy);
and if $bar and $baz are tied, that'll execute their FETCH
On Wed, Feb 14, 2001 at 11:26:00AM -0500, Dan Sugalski wrote:
At 11:03 AM 2/14/2001 -0500, Buddha Buck wrote:
[Truly profound amount of snippage]
I'm sure this idea has flaws. But it's an idea. Tell me what I'm missing.
You've pretty much summed up the current plan.
I have a strong
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
package NuclearReactor::CoolingRod;
sub new {
Reactor-decrease_core_temperature();
bless {}, shift
}
sub DESTROY {
Reactor-increase_core_temperature();
}
A better
On Fri, Mar 23, 2001 at 12:38:04PM -0500, Dan Sugalski wrote:
while (IN) {
$count++ if /bar/;
print OUT $_;
}
I would find it surprising for this to have different output
than input. Other people's milage may vary.
In general, however, I think I would prefer to be
On Fri, Mar 23, 2001 at 06:16:58PM -0500, Dan Sugalski wrote:
At 11:09 PM 3/23/2001 +, Simon Cozens wrote:
For instance, chr() will produce Unicode codepoints. But you can pretend that
they're ASCII codepoints, it's only the EBCDIC folk that'll get hurt. I hope
and suspect there'll be an
On Fri, Mar 23, 2001 at 06:31:13PM -0500, Dan Sugalski wrote:
Err, perhaps I'm being dumb here - but surely $foo and $bar arent
typed strings, they're just numbers (or strings which match /^\d+$/) ???
D'oh! Too much blood in my caffeine stream. Yeah, I was thinking of ord.
chr will emit a
On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
So the results of ord are dependent on a global setting for "current
character set" or some such, not on the encoding of the string that
is passed to it?
Nope, ord is
On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
If ord is dependent on the encoding of the string it gets, as Dan
was saying, than ord($e) is 0x81,
It it could still be 0x81 (from ebcdic) with the encoding carried
along with the _number_ if we thought that worth the
On Tue, Mar 27, 2001 at 12:38:23PM -0500, Dan Sugalski wrote:
I'm afraid this isn't what I'd normally think of--ord to me returns the
integer value of the first code point in the string. That does mean that A
is different for ASCII and EBCDIC, but that's just One Of Those Things.
My
On Tue, Jun 12, 2001 at 06:12:35PM -0400, Dan Sugalski wrote:
At the moment I'm leaning towards the functions doing their own decoding,
as it seems likely to be faster. (Though we'd be duplicating the decoding
logic everywhere, and bigger's reasonably bad) Possibly mandating shadow
On Tue, Jun 12, 2001 at 06:44:02PM -0400, Dan Sugalski wrote:
While that's true, KATAKANA LETTER A and HIRAGANA LETTER A are also
referring to distinct things. (Though arguably not as distinct as either
with LATIN CAPITAL A) If we do one, why not the other? I'm perfectly happy
with an
On Wed, Jun 13, 2001 at 01:22:32AM +0100, Simon Cozens wrote:
I'd say it was about as useful as providing a regexp option to translate
the search term into French and try that instead.[1] Handy, possibly.
Essential? No. Something that should be part of the core? I'll leave
that for you to
On Wed, Jun 13, 2001 at 02:15:16AM +0100, Simon Cozens wrote:
Or we could keep it out of core. It's up to you, really.
No, it isn't. It's up to Larry, or to whoever gets the regex
pumpkin.
I'm withdrawing from this discussion: My intent was to clarify
exactly why someone might want to treat
On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
Parrot fails to work in very obscure ways on FreeBSD. After some
poking around, I tracked the problem to the end op--this appears
to conflict with something inside libc. Renaming
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with Parrot_op_. I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
Oops--that breaks
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote:
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote:
This patch seems to work on the FreeBSD box I have access to. Now to
figure out what's causing all those 'use of uninitialized value at
assembler.pl line 81' messages...
It's the
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
I'm thinking of writing something to generate a Parrot::Opcode.pm
module, so code doesn't need to parse opcode_table and interp_guts.h.
Sound reasonable?
Yes, please do. I knew we needed one the second time I needed to parse
The following patch moves all parsing of opcode_table into a
Parrot::Opcode module. It also removes all parsing of interp_guts.h.
This patch incorporates my earlier patches to prefix all C opcode
functions with Perl_op_.
As best I can tell, everything works the same with the patch as it
did
On Thu, Sep 13, 2001 at 08:25:46AM +0100, Simon Cozens wrote:
On Thu, Sep 13, 2001 at 12:29:18AM -0700, Damien Neil wrote:
CVS changes over the past couple of days mean this patch will no
longer cleanly apply. I'd be happy to update it to patch cleanly
against the current CVS code
On Thu, Sep 13, 2001 at 08:44:44AM +0100, Simon Cozens wrote:
Aiiee. Yes, I appreciate what you're saying, but the other lessons
from Perl 5 is that if you want to do that, you end up with either
lots of unweildy code, or a nasty macro renaming. Which is it
gonna be?
I don't really like the
On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote:
If we are going to keep on doing fancy stuff with pointer arithmetic (eg
the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
integer type which is guaranteed to be the same width as a pointer, so
we can
On Thu, Sep 13, 2001 at 06:41:00PM -0400, Dan Sugalski wrote:
At 01:42 PM 9/13/2001 -0700, Benjamin Stuhl wrote:
Could we please get in the habit of adding a -c or a -u to
our CVS diffs, just as we would with normal patches?
Yes, please!
All diffs posted to the list should be either -c
Here's an updated version of my original patch, to account for recent
changes in CVS. As before, this includes opcode-munging to let Parrot
run on FreeBSD.
- Damien
diff -u --new-file -r parrot.orig/Parrot/Opcode.pm parrot/Parrot/Opcode.pm
---
On Fri, Sep 14, 2001 at 11:31:20AM -0500, Gibbs Tanton - tgibbs wrote:
The patch assumes that your source code directory is named parrot. This may
have been an invalid assumption, but it is going to be hard to do this patch
unless we agree on the name of the source directory.
That may be
On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
of a dictionary likely to be a significant problem?
Please elaborate.
IFF stores a linear series of chunks. Each chunk has a header containing
the
On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
It will be hard to use one format for both native and portable.
Not one format, but a set of closely related formats with well-defined
transformations between them.
After thinking about implementing this for a bit, I'm
On Sat, Sep 15, 2001 at 01:15:57AM -0700, Brent Dax wrote:
As for the 5.6 thing...I think we're supposed to support 5.005 and
above. Can you tell what Parrot::Opcode needs it for? (And if it's for
'our', I'm going to punch someone... :^) )
Er...I think it IS for our, actually. : I'm so
On Sat, Sep 15, 2001 at 01:52:26AM -0700, Brent Dax wrote:
use vars qw(%opcode $fingerprint);#or strict will throw a tantrum
Not necessary--the patch changes those variables to lexicals.
There wasn't any strong reason for them to be package vars.
- Damien
The attached file contains tests for all Parrot integer ops.
- Damien
#! perl -w
use Parrot::Test tests = 26;
output_is(CODE, OUTPUT, set_i_ic);
# XXX: Need a test for writing outside the set of available
# registers. Parrot doesn't check for this at
On Tue, Sep 18, 2001 at 03:55:23PM -0400, Dan Sugalski wrote:
Anyone care to take a shot at it? Having an extra overridable column in
the opcode_table file (so we know which opcodes are overridable, and thus
can't be in the switch) would be a good thing while you were at it...
I will do
Proposed: Parrot should never crash due to malformed bytecode. When
choosing between execution speed and bytecode safety, safety should
always win. Careful op design and possibly a validation pass before
execution will hopefully keep the speed penalty to a minimum.
Yes, no?
On Tue, Sep 18, 2001 at 10:40:30PM +0100, Simon Cozens wrote:
On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote:
Proposed: Parrot should never crash due to malformed bytecode.
Haven't we done this argument? :)
Sort of, while talking about other things. I wanted to drag it out
...and here are tests for the number ops.
- Damien
#! perl -w
use Parrot::Test tests = 23;
output_is(CODE, OUTPUT, set_n_nc);
set N0, 1.0
set N1, 4.0
set N2, 16.0
set N3, 64.0
set N4, 256.0
set N5,
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote:
I think that especting 4294967295 == -1 because they have the same
bit pattern ( on two's complement 32 bit machines ) is wrong
I was wondering how long it would take for someone to notice that. :
If anyone feels like defining a
On Tue, Sep 18, 2001 at 06:12:48PM -0500, Gibbs Tanton - tgibbs wrote:
All the tests are great! But, could everyone please remember to put an
end at the end of each assembly test...cygwin doesn't like it if you
don't. I think I've patched all the ones up to this point.
Oops. Sorry about
On Tue, Sep 18, 2001 at 07:52:06PM -0400, Dan Sugalski wrote:
More to the point, it needs typing exactly twice--once in the .ops file
that defines the opcode function body, and once in opcode_table. The
assembler, of course, uses the smaller name.
Three times: And once to name the test
On Wed, Sep 19, 2001 at 01:40:31PM -0400, Pat Eyler wrote:
I realize that the $count inside the if block shown masks the $count
declared outside the while loop, but (to me) this would be easier to
understand if the inner $count where changed to $numParams -- it is more
obvious on casual
Oops; that'll teach me to submit things before a cvs update. The
generate.pl I just sent is out-of-date with regards to CVS. Attached
is an updated version.
(I haven't seen my prior mail go through yet; I'm guessing this is
the list being slow, but it might be a problem with my local mail
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
Damien, is there any way we could get a similar fix for number.t? That
would make us at 100% on Tru64.
(Apologies if this shows up twice; something appears to be screwy with
my mail system.)
I'm currently getting
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're
On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
Just a reminder--function names shouldn't exceed 31 characters. The C
standard doesn't guarantee anything past that...
You think that's bad? You aren't guaranteed more than six characters,
case-insensitive for external
test_main.c still seems to contain a call to _read(), rather than
read(). This breaks compilation under Tru64 for me; the attached
patch removes the _.
- Damien
Index: test_main.c
===
RCS file:
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay.
make: *** [test] Error 2
Damien, is there any way we could get a similar fix for number.t? That
would make us at 100% on Tru64.
I'm currently
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're
Are there any issues holding up 0.0.2 that I (or others) could work
on? Failing that, what areas of Parrot are most in need of immediate
work?
I'm interested in looking at the bytecode loader, if nobody else
has intentions there. In particular, I'd like to see if we can
get empirical data to
On Tue, Sep 25, 2001 at 07:29:01PM -0700, Wizard wrote:
Actually, the thing that I didn't like was using an actual string as the
message_id. I would have expected something more in the way of:
char *err = get_text_string( THREAD_EXCEPTION_117, \
THREAD
On Tue, Sep 25, 2001 at 07:36:31PM -0400, Gregor N. Purdy wrote:
I'm currently working on some assigned taskes for the bytecode stuff
for 0.0.2. I need to get it to the point where we can stash NVs in
the const_table. I've already got the interpreter using packfile.[hc]
for its work (I posted
On Wed, Sep 26, 2001 at 12:38:28AM +0100, Simon Cozens wrote:
But then I'm one of those weird critters who doesn't understand what all the
complaining over XS is about. :) I'd be happy to do the XS coding if it came
down to it.
I'll take a look at making the assembler and disassembler use the
On Wednesday, April 24, 2002, at 04:04 PM, Robert Spier wrote:
One of the keys of the system Jeff has implemented is that it's 100%
real perl code and real perl objects, not a language parsed with
perl. This means you can do nifty things and write perl code to
modify things in a natural way.
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
The last four are reserved by various C and C++ standards.
I always hear this, but in real life it is never much of a problem.
Especially
with a namespace like [Parrot]
It is a good idea to avoid using the reserved identifier
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
1) Async support. The IO system needs to be asynchronous and re-entrant
at the core, whether by threads or by use of the platform's async support.
Other things like callbacks assume other features of Parrot to be finished,
like
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
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 Thu, Jul 17, 2003 at 12:58:12PM -0400, Dan Sugalski wrote:
The first is done in the case of readw or writew, for example. The
second for event-driven programs that set up callbacks and park
themselves forever in one big ProcessEvent call. (Tk programs come to
mind) The third is to be
On Fri, Jul 18, 2003 at 11:29:27AM -0400, Dan Sugalski wrote:
Nope, that won't work. A lot of what's done is really main thread
with interrupts and that doesn't map well to doing all signal
handling in separate threads. You really do want to pause the main
program to handle the events that
On Fri, Jul 18, 2003 at 05:42:10PM -0400, Benjamin Goldberg wrote:
AIO is unpopular because it's not widely/portably supported, whereas
non-blocking event-loop IO is, (one generally does have either select or
poll), as is blocking threaded IO (even if the thread starting stuff may
need to be
On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:
and event loop i/o doesn't usually support async file i/o. many people
conflate the two. event i/o handles sockets, pipes and such but none
support files. the issue is that the async file i/o api is so different
(or non-existant) on
On Sun, Jul 20, 2003 at 11:59:00AM -0400, Dan Sugalski wrote:
We're supporting interrupts at the interpreter level because we must.
It doesn't matter much whether we like them, or we think they're a
good idea, the languages we target require them to be there. Perl 5,
Perl 6, Python, and
On Tue, Jul 22, 2003 at 11:41:25PM -0400, Dan Sugalski wrote:
First, to get it out of the way, I don't have to convince you of
anything. You have to convince me. For better or worse I'm
responsible for the design and its ultimately my decision. If you
don't want async IO, it's time to make
On Sun, Jan 04, 2004 at 12:17:33PM -0800, Jeff Clites wrote:
What are these standard techniques? The JVM spec does seem to guarantee
that even in the absence of proper locking by user code, things won't
go completely haywire, but I can't figure out how this is possible
without actual
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and pointers seems to rely on the architecture but is of course
reasonable.
You
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
variable access, because it even doesn't provide such atomic access.
You're missing the point of the
On Wed, Jan 21, 2004 at 01:14:46PM -0500, Dan Sugalski wrote:
... seems to indicate that even whole ops like add P,P,P are atomic.
Yep. They have to be, because they need to guarantee the integrity of
the pmc structures and the data hanging off them (which includes
buffer and string stuff)
On Fri, Jan 23, 2004 at 10:07:25AM -0500, Dan Sugalski wrote:
A single global lock, like python and ruby use, kill any hope of
SMP-ability.
Assume, for the sake of argument, that locking almost every PMC
every time a thread touches it causes Parrot to run four times
slower. Assume also that
On Wed, Jan 28, 2004 at 12:53:09PM -0500, Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are not synchronized; access
involves no locks at all. Multiple threads
On Jun 14, 2004, at 1:54 PM, Dan Sugalski wrote:
Parrot provides code points for all graphemes, even for those
character sets/encodings which don't inherently do so. Most sets that
have variable-length encodings use an escape sequence scheme--the
value of the first byte in a character determines
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
int perl6_parse(PerlInterp *interp,
void *source,
int flags,
void *extra_pointer);
Count me in with the people who prefer:
int perl6_parse(PerlInterp *interp, PerlIO
72 matches
Mail list logo
