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, 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
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 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 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 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
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 fr
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
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 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 d
On Fri, Sep 14, 2001 at 12:16:52PM -0700, Brent Dax wrote:
> make test_prog
Is there any reason not to make test_prog build by default? The
.o files aren't very useful on their own. :>
- Damien
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 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(<
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.
...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 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 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 re
On Wed, Sep 19, 2001 at 11:03:46AM -0400, Dan Sugalski wrote:
> Integer and float ops, *on integer and float registers* do undefined things
> on over/underflow. No guarantees, no promises, no certainty. Price of speed.
Fair enough. Attached is a patch removing the offending overflows.
It also b
On Thu, Sep 20, 2001 at 12:15:37AM -0400, Michael Fischer wrote:
> please see attached process_switch.pl
> notes inside.
I've been working on the same thing. For comparison, I'm attaching
generate.pl, my replacement for build_interp_starter.pl,
process_opfuncs.pl, and make_op_header.pl. (I agre
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
syste
On Wed, Sep 19, 2001 at 10:22:27PM -0700, Dave Storrs wrote:
> I'm working on documenting the opcodes, and I want to make sure that I
> understand the 'RETURN' code properly. I've poked around a little bit to
> see if I coudl figure it out, but I don't want to divert too much. Would
> someone pl
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 segfaul
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 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 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 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 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 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 identifier
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
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 ju
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 EXC
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 pos
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 t
On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote:
> That'd be interesting. Try cobbling up a version of the assembler that does
> big-endian assembly and a loader that reads and byteswaps, and see what you
> get for start-to-finish performance.
I'm going to take a crack at that Real
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 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 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 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 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 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 Wed, Aug 09, 2000 at 03:32:41PM -0400, Chaim Frenkel wrote:
> Each sub has a unique number.
>
> Package A - Has nothing blessed, doesn't need the lookup table
>
> Package B - Has blessed items, lookup table for all subs that are part
> of the package, or in the inheritance tree.
Ar
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 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 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 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 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 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
98 matches
Mail list logo
