On Tue, Oct 03, 2000 at 03:42:49PM +0100, Graham Barr wrote:
> On Mon, Oct 02, 2000 at 12:58:37PM -0700, Damien Neil wrote:
> > What? I don't think people should be writing either XML or HTML
> > as the source documentation format. I said that, quite clearly.
>
> T
On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote:
> Single quotes don't interpolate \' and \\
I rather like the Python triple-quote mechanism used for this
purpose:
$foo = """Things like ', ", and \ have no special meaning in here.""";
Of course, this doesn't help if you wa
On Fri, Sep 29, 2000 at 07:24:38PM -0400, Dan Sugalski wrote:
> > $foo = """Things like ', ", and \ have no special meaning in here.""";
>
> Argh! *NO*! That way lies madness, or at least DCL's quoting mania. My
> record, in a command procedure that wrote other command procedures that
> submi
On Sun, Oct 01, 2000 at 03:39:51PM -0400, Adam Turoff wrote:
> I think POD's list handling is full of warts, but what follows
> is much better than HTML/DocBook itemized lists:
For me, they're about the same.
Actually, I'd rather read an XHTML/HTML itemized list than a POD one;
they both look ug
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, Perl
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", w
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 04:17:21PM -0500, Dan Sugalski wrote:
> The issue isn't support, it's efficiency. Since we're not worrying about
> loss of precision (as we will be upconverting as needed) the next issue is
> speed, and that's where we want things to be in a platform convenient size.
I t
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
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 m
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> In the other way around, what matters to the design of the file i/o
> subsystem is exactly the same thing: whether it will or won't be using
> blocking syscalls. I believe after the decision of whether we will or not
> allow b
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
On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> Yes it can tell, actually--we do have the full bytecode to the sub
> available to us, along with whatever metainfo we choose to remember
> generally about the sub. Whether we use the info is a separate matter, of
> course.
What ab
[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
On Wed, Feb 14, 2001 at 05:43:31PM -0300, Branden wrote:
> 4. Why should we bother destroying an object before GC does it?
>
> To free system resources, like open files or database connections. Probably
> the average program won't do it never, but programs that must open several
> files sequentia
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens wrote:
> > Using object lifetime to control state is almost never a good idea,
> > even if you have deterministic finalization.
>
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy,
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> I think you just said all about why we shouldn't bother giving objects
> deterministic finalization, and I agree with you. If we explicitly want to
> free resources (files, database connections), then we explicitly call close.
> Otherwise,
On Wed, Feb 21, 2001 at 12:25:10AM +, Alan Burlison wrote:
> Shame it only works with the Sun compilers.
See also Boehm's garbage collector, which is rather more portable:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
"The collector uses a mark-sweep algorithm. It provides incremental
On Sat, Mar 03, 2001 at 07:57:54PM +0100, Paolo Molaro wrote:
> All the function names shall begin with the C prefix. The only exception
> is function names that may be used only in the perl core: these names shall
> begin with the C<_perl_> prefix. This will make it possible to export only
> the
On Sat, Mar 10, 2001 at 12:29:43AM +0100, Paolo Molaro wrote:
> My understanding is that symbols with double underscore or underscore
> followed by an uppercase letter are reserved, while _something
> symbols are ok if they are not exported and that is actually
> what we are doing. I prefer _perl
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
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
On Fri, Mar 23, 2001 at 12:38:04PM -0500, Dan Sugalski wrote:
>while () {
> $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 Mon, Mar 26, 2001 at 06:16:00PM +, [EMAIL PROTECTED] wrote:
> Damien Neil <[EMAIL PROTECTED]> writes:
> >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 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
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 t
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 perso
On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type. The fact
> that it's become the industry standard for method call syntax is also
> a point in its fav
On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
> Yes, I know ~ is the bitwise negation operator. Have you EVER used it?
Today, in fact:
fcntl($fh, F_SETFL, $flags & ~O_NONBLOCK) or die "fcntl: $!";
- Damien
On Thu, Apr 26, 2001 at 04:46:48PM -0700, Larry Wall wrote:
> And I'm tired of hearing the argument that Perl programmers can't get
> used to a different operator for concatenation. I know better--after
> all, Perl is probably what got them used to . in the first place. If
> you can teach dogs t
On Tue, Jun 05, 2001 at 11:14:29PM +0100, Michael G Schwern wrote:
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> I'm probably using the wrong terms.
>
> This definately can't work if $obj is of a class which is strongly
> typed.
You would do that in Java by using reflection.
On Mon, Jun 11, 2001 at 01:14:37PM -0700, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> > I don't think canonicalization should do this. (I really hope not) This
> > isn't really a canonicalization matter--words written with one character
> > set aren't (AFAIK) the same as words
On Mon, Jun 11, 2001 at 05:03:26PM -0400, Dan Sugalski wrote:
> I don't think just /i should do that, as it seems rather extreme. (If you
> took that argument, it would seem to follow that KATAKANA LETTER A matches
> LATIN CAPITAL A, and I don't think we want to go there) The actual
> perl-leve
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
> func
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 a
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 K
On Mon, Jul 02, 2001 at 12:59:51PM -0700, David Whipp wrote:
> Its not quite the same thing, but Java does have the concept of
> anonymous classes (it names them 'inner' classes): Is Perl6 going
> to have a similar concept?
Inner classes and anonymous classes are actually different in Java.
(Anon
On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote:
> As the pendulum swings in the other direction you get mind-bogglingly
> silly things like finalize which I just learned of today.
What's so silly about finalize? It's pretty much identical to Perl's
DESTROY. (Except that Java'
On Tue, Aug 28, 2001 at 05:23:46PM -0700, David Whipp wrote:
> The only good justification I've heard for "final" is as a directive
> for optimization. If you declare a variable to be of a final type, then
> the compiler (JIT, or whatever) can resolve method dispatch at
> compile-time. If it is no
On Tue, Aug 28, 2001 at 09:07:03PM -0400, Sam Tregar wrote:
> Well, there's the Perl 5 reference counting solution. In normal cases
> DESTROY is called as soon as it can be. Of course we're all anxious to
> get into the leaky GC boat with Java and C# because we've heard it's
> faster. I wonder
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 be
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 conf
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
> d
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...
>
> I
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 par
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 identif
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 ai
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
On Mon, Nov 11, 2002 at 11:47:01PM +0100, Angel Faus wrote:
> Does anyone have any experience with SDF?
I played with it for some in-house documentation a couple years ago.
I'm afraid I wasn't very impressed with it; I found it very difficult
to customize the output to what I wanted, and the synt
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote:
> Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0
> will benefit most users. Do not invoke legacy. [1]
Answer 1: Ignoring legacy, it won't.
Answer 2: Because C uses 0-based indexes, Parrot is written in C
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
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 b
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 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 01:10:24PM +0200, Jos Visser wrote:
> Lots of Java programs simulate AIO by using threads. Almost all Java IO
> mechanisms are blocking and this means that doing interesting work while
> the IO is in progress requires some mechanism that involves a separate
> thread with a c
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 ma
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 wh
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 loc
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 Wed, Jan 14, 2004 at 10:28:25PM -0800, Jeff Clites wrote:
> You might be right, but that's not exactly how I read it, because later
> it says, "A use action (by a thread) transfers the contents of the
> thread's working copy of a variable to the thread's execution engine.
> This action is per
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 th
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 s
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 lo
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
On Thu, Sep 20, 2001 at 04:25:45PM -0400, Dan Sugalski wrote:
> At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
> > Could you explain again why you don't want char* anywhere, and prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __
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
> > ag
On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> Where all word values are as big as the word size says they are.
What should the byteloader do when it encounters data in a word that
cannot fit in a native word?
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
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 Thu, Sep 20, 2001 at 04:24:19PM -0400, Dan Sugalski wrote:
> At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
> >Another approach would be to include a means of defining information
> >that must be included by the file implementing the ops. For example:
>
> I like that
On Fri, Sep 14, 2001 at 10:20:00AM +0100, Simon Cozens wrote:
> On Thu, Sep 13, 2001 at 08:54:40PM -0700, Damien Neil wrote:
> > Here's an updated version of my original patch, to account for recent
> > changes in CVS. As before, this includes opcode-munging to let Parro
On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
For clarification: do you
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 ca
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 t
The attached file contains tests for all Parrot integer ops.
- Damien
#! perl -w
use Parrot::Test tests => 26;
output_is(<
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: /home/perlcv
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
--- parrot.orig/Parrot/Opcod
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 segfaul
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 Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> >For clarification: do you mean async I/O, or non-blocking I/O?
>
> Async. When the interpreter issues a read, for example, it won't assume the
> read completes immediately.
That sounds like what I would call non-blocking I/O. Asy
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 eit
On Tue, Sep 11, 2001 at 12:06:52AM -0700, Damien Neil wrote:
> 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 &quo
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
...and here are tests for the number ops.
- Damien
#! perl -w
use Parrot::Test tests => 23;
output_is(<
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
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 abou
On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
> >final and private are completely different concepts as I understand
> >them.
>
> I wouldn't say "completely different". They are both used for "enforcement"
> of similar means, but you are correct, they are different.
I view "final
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 w
On Wednesday, May 1, 2002, at 02:27 PM, Aaron Sherman wrote:
> unless my $fh = $x.open {
> die "Cannot open $x: $!";
> } else while $fh.getline -> $_ {
> print;
> } else {
> die "No lines to read in $x";
> }
I think you need a bet
On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote:
> Why is it silly? Hashes and arrays are *conceptually* very similar (even
> if they are extremely different implementation-wise). One of them has
> implicit key, the other has an explicit key. They both provide some sort
> of o
On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote:
> I like the idea of adding the context-aware operators, but I don't
> think I'd use them as often as I use "the number of things in the
> array". I think most Perl programmers would be in the same camp.
> Unless you can show a co
On Tue, Aug 15, 2000 at 11:15:03PM -0700, Peter Scott wrote:
> No, || is half-consistent at the moment: the left hand side is forced into
> scalar context but the result context propagates down the right hand
> side. I challenge anyone to come up with a rationalization for this that
> does not
On Wed, Aug 16, 2000 at 05:34:51PM -0400, Karl Glazebrook wrote:
> > You appear to arguing that expressions in function argument lists should
> > not be evaluated in a list context. Is this really what you mean?
>
> I guess I do. I guess I just hate contexts!
Context is a fundemental part of Pe
On Wed, Aug 16, 2000 at 09:04:00PM +0200, Kai Henningsen wrote:
> And context dependency is bad for people.
Actually, people deal very well with context dependency.
"Have you paid Bill?"
"Have you paid that bill?"
"It looks like a duck's bill."
"The President vetoed the bill."
> A rose
On Wed, Aug 16, 2000 at 05:36:25PM -0400, Karl Glazebrook wrote:
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)
Why, then, don't you just use Python?
I'm not being sarcastic. Python is a very good language. It h
1 - 100 of 116 matches
Mail list logo
