> > "K&R" style for indenting control constructs: ie the closing C<}> should
> > line up with the opening C etc.
> >
> > =item *
> >
> > When a conditional spans multiple lines, the opening brace must line up
> > with the "if" or "while", or be at the end-of-line otherwise.
>
> I certainly will
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> I don't like push/pop - they imply a lot of stack limit checking word-by-word
> when it is less overhead for compiler to analyse the needs of whole
basic-block
> check-for/make-space-on the stack _once_ then just address it.
There's no reason why you
> >the op code is stored in network endian order and the interpreter will
> >always build a 16 bit int from the 2 bytes.
>
> Not network. Native. We can put a marker at the beginning of any bytecode
> stream, and provide an endian-swapper. That way we're always running at
> platform optimal enco
Larry Wall <[EMAIL PROTECTED]> wrote:
> It may certainly be valuable to (not) think of it that way, but just
> don't be surprised if the regex folks come along and borrow a lot of
> your opcodes to make things that look like (in C):
>
>while (s < send && isdigit(*s)) s++;
This is the bit th
Simon Cozens <[EMAIL PROTECTED]> opined:
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things:
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, May 23, 2001 at 06:08:52PM +0100, Simon Cozens wrote:
> > ACY's taking a look into this too, so you may want to co-ordinate to avoid
> > clashing. I've also told him what I'd like: something like this:
> >
> > Scalar
> > Strings
> > Ch
mad thought for the day:
I was thinking back to the earlier discusions on opcode dispatch,
and the fact that some people thought that a big switch was as good as,
or possibly faster than a dispatch table. Which led me to think...
should we abandon vtables (ie arrays of fn pointers indexed by op)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
> >should we abandon vtables (ie arrays of fn pointers indexed by op),
> >and just have a single hander function per type which has the op as an arg?
>
> Are you talking vta
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:43 PM 6/19/2001 -0500, David L. Nicol wrote:
> > set $B to copy-on-write mode, so future changes to $B do not
> > affect $A
>
> The one problem with copy-on-write is that, if we implement it in software,
> we end up paying the price to che
Graham Barr <[EMAIL PROTECTED]> wrote:
> Ouch. I have quite often had applications that would use several hundred MB
> now. If I would need double that, then that is going to hurt. I am not
> familiar with copying collector GC, does anyone have a pointer to any
> papers etc.
The basic operation o
Bart Lateur <[EMAIL PROTECTED]> wrote:
> This came up on comp.lang.perl.misc once, and Ilya Z. then wrote, IIRC,
> that there's no reason why the DLL (if I may call it this way) should
> have a name identical to the module name. His example was that on his
> port, for OS/2, he added a (machine gen
Back in the mists of time (May 29th), I solicited comments on my second
draft of the deeply thrilling "Conventions and Guidelines for Perl
Source Code". There were various contributions, but having more interesting
things to do [watching paint dry etc - Ed], I never got round to incorporating
them
Here's the final draft. Please consider it formally submitted; someone
(Dan? Ask? Adam?) needs to assign it a number, please.
Dave.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL PROTECTED]&g
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > =item *
> >
> > Uncuddled elses: ie avoid C<} else {>
>
> Does this mean avoid:
>
> if (...) {
> ...
> } else {
> ...
> }
>
> and instead use:
>
> if (...) {
> ...
> }
> else
> {
> ...
> }
>
> If my interpretation of what it means is cor
I think then we are all agreed that the format is
/* comment */
if (...) {
...
}
/* comment */
else {
...
}
with mandatory {}s.
For completeness, we should also include chained else-ifs; I think the
following is reasonably uncontroversial:
/* comment */
if (...) {
...
}
/* comment
Okay, this really, really *really* the final draft.
can I have a PDD number, please Dan?
The only change since last is the stuff about if/else layout.
Dave M.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EM
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Firstly, a magic number is presented to identify the bytecode file as
> Parrot code.
Hopefully this is followed by a header that has a version number and
lots of useful stuff like flags and offsets and things, just like wot
real object files have :-)
> N
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This also makes scope entry and exit costlier, since you need to make a
> savestack entry and restore, respectively, for each lexical. I don't think
> it'd be a win, even if closures weren't getting in your way.
although to be fair, the current run-time
I'm trying to get my head round the relationship between pad lexicals,
pad tmps, and registers (if any).
The PMC registers are just a way of allowing the the address of a PMC to
be passed to an op, and possibly remembered for soonish reuse, right?
So presumably we still have the equivalent of a
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> > I'm trying to get my head round the relationship between pad lexicals,
> > pad tmps, and registers (if any).
>
> It's exactly the same as the r
whoops, forgot to CC the list
- Begin Forwarded Message -
Date: Thu, 6 Sep 2001 14:32:19 +0100 (BST)
From: Dave Mitchell
Subject: Re: pads and lexicals
To: [EMAIL PROTECTED]
Content-MD5: iVd18ng5xfzBBgJHSPdShg==
Ken Fox <[EMAIL PROTECTED]> wrote:
> Dave
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> > The Perl equivalent $a = $a + $a*$b requires a
> > temporary PMC to store the intermediate result ($a*$b)
>
> Probably a temporary INT or NUM register, in fact
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > of a pad full of tmp targets, each hardcoded as the target for individual
> &
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> Where do they come from? Leave a plate of milk and cookies on your back
> porch and the Temp PMC Gnomes will bring them. :)
Ah, things are starting to make sense!
> ne
Robert Spier <[EMAIL PROTECTED]> wrote
> >>How about something a little more explicit than XXX, like TODO or FIXME?
> > Some syntax-highlighting editors highlight "XXX". Let's use that feature.
>
>
> Which ones? emacs doesn't seem to do it by default.
>
>
> > And how can you get more explici
Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> Erk, we seem to be muddling around in that great grey area between what is
> Parrot and what is Perl.
Yes, which leads me on to think...
(With my "maintainer of the Coding PDD" hat on)
Presumably we have to decide what bits of code have a Parrot_
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Sep 2001, Dan Sugalski wrote:
>
> > > > changing parrot.h to do #include "parrot/config.h" and
> > > > then changing
> > > > Makefile to add -I./include to CCFLAGS.
>
> > One thing to keep in mind is that the directory may not be sufficien
> Assuming there's one general stack to save "stuff" on, where stuff is:
>
> * Scope entries
> * Return addresses for JSRs
> * Saved individual registers
> * Local() calls
Dave's Wild+Whacky+Unworkable Suggestion #42:
If we have one generic stack with all sorts of things on it,
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I'm seriously investigating the possibility of changing IV and NV to something
> more readable.
>
> (But for those of you who are following language-dev, don't tell 'em because
> then they'll think they've won. ;)
Some time ago I sugested that NV was a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Subject: What should and shouldn't get documented?
>
> I see there's a lot of embedded documentation going into the core, and
> that's a good thing. That brings up a question, though--what exactly should
> we document, and where should it be seen?
>
>
I wrote:
> Should we go the full hog and make the /*=for api ... */ bit in the
> src field subsume any info we currently append to embed.pl etc in Perl 5?
s/field/file/
A few comments.
* Is there ever any need to for a PMC type which holds both an int and a
num? In the Perl 5 case we were constrained by code that expected to always
find an int (or a num) in a fixed slot in the SV; with PMCs, all access
to these slots is via methods, so an int-num or num-int conv
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Shouldn't the above be more like:
>
> P1->vtable->vtable_funcs[VTABLE_ADD + P2->vtable->num_type](i, P0, P1, P2);
I'm probably overlooking something here, but why the double indirection?
Shouldn't that just be
P1->vtable.vtable_funcs[
?
ason Gloudon <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote:
> > Alan Burlison <[EMAIL PROTECTED]> wrote:
> > > Dave Mitchell wrote:
> > > > * Is there ever any need to for a PMC type which holds both an in
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >I'm saying that classes can have user-defined flags, to save a
> >dereference. Or at least, I'm saying that until Dan wanders over
> >here and persuades me it's a bad idea. :)
>
> Dan thinks its a very good idea. :) Almost anything that potentially saves
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2001 at 10:58:55AM +0000, Dave Mitchell wrote:
> > Presumably we should have a small, *fixed* number of private bits in
> > the flags word available for use by vtable implementors (ie to stop
> > people getting c
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2001 at 03:29:00PM +0000, Dave Mitchell wrote:
> > I'd prefer the "you have 8 private bits, the rest is Parrot's" approach
> > rather than the "Parrot has 8 bits and the rest is yours for no
Back on Fri, 28 Sep 2001 20:49:42, Josh Wilmes <[EMAIL PROTECTED]> asked:
> What's the state of the coding standards? This is the last draft of it
> i've noticed in the archives:
>
> http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
>
> Is this going to become a PDD or at
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> D'oh! First I find the codings standard doc, then I get it an official PDD
> number if it doesn't have one already. (Then I smack myself with it...)
print "Dan, can I have a PDD number for my coding stds doc?\n" for 1..Inf;
(If you were to give me a PDD
I wrote:
> (If you were to give me a PDD number, I might even get round to finishing
> the doc off ;-)
Okay, I lied
:-)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Ah, the joys of Supreme Executive Power!
Look 'ere - Supreme Executive Power resides in a mandate from the masses,
not some farcical aquatic ceremony... :-)
> We really have three separate but related needs:
>
>*) Shallow register copy. (set) This
Boris Tschirschwitz <[EMAIL PROTECTED]> wrote:
> int *num;
>
> is customary in C, but for some reason C++ people like to write
>
> int* num;
The rationale in C is that the variable is delared in the same way it
is invoked. This has it's own internal logic, but becomes a nightmare for
declaring
Simon Cozens <[EMAIL PROTECTED]> wrote:
> IANDan, but here's the plan as I see it.
>
> 1) Move to using make.pl instead of system's make
> 2) Compile both make.pl and Configure.pl to Parrot bytecode
> 3) Create a miniparrot which builds anywhere and can run the above
>programs
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Subject: Re: Flags to pmc.h. *Important for class creators!*
> Cc: [EMAIL PROTECTED], Jeff G <[EMAIL PROTECTED]>
>
> At 11:23 AM 1/12/2002 -0800, Steve Fink wrote:
> >On Fri, Jan 11, 2002 at 05:43:28PM -0500, Dan Sugalski wrote:
> > > Okay, I've added som
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> There is no string type built out of native eight-bit bytes.
In the good ol'days, one could usefully use regexes on 8-bit binary data,
eg
open G, 'myfile.gif' or die;
read G, $buf, 8192 or die;
if ($buf =~ /^GIF89a\x08\x02/) {
.
where it wa
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > In the good ol'days, one could usefully use regexes on 8-bit binary data,
> > eg
> >
> > open G, 'myfile.gif' or die;
> > read G, $buf, 8192 or die;
> > if ($buf =~ /^GIF89a\x08\x02/) {
> > .
> >
> > where it was clear to everyone that we
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> That was my biggest objection. I like the thought of having a scheme
> pair data type. The interpreter should see it, and it should be
> accessed, as a restricted array, one with only two entries.
Is this then the same datatype as a Perl6 pair (cf '=>'
Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> I count 86 violations of 8.3 in the tree. 8.3-friendly doesn't appear to be
> a concern.
The files themselves don't have to be 8.3; however, they should be unique in
lc( substr($base,0,8) . '.' . substr($suffix,0,3) )
Under that rule, I m
Simon Cozens <[EMAIL PROTECTED]> wrote:
> begin quote from Joe Yates:
> > if (!S_ISREG(file_stat.st_mode)) {
> > As far as I can tell, "S_ISREG" is gcc specific.
>
> My fault, but I'm sure it's POSIX. Oh well, problem, anyway. Anyone got a
> more-portable-than-POSIX way of saying this
I've only had one reply to this so far - anyone else want to
approve or disapprove?
NB - I'm kind of offering to do the patching of paths required if this
move goes ahead, but obviously I can't do the moving on the CVS server
myself.
Dave.
- Begin Forwarded Message -
Da
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > Anyway, here's how I suggest files should be moved around to make
> > a more rational directory hierarchy. This will involve quite a bit
> > of hacking of paths in makefiles, scripts etc; but if we're going
> > to do it at all, then the sooner the bett
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Melvin Smith:
> > I agree with your config/ dir suggestion, but I'm not sure about
> > moving everything else down into perl6/parrot subdirectory,
>
> Me neither. I don't see much point in it.
I'm trying to nip the following in the bud, which is daunting
Simon Cozens wrote:
> Dave Mitchell:
> > I'm trying to nip the following in the bud, which is daunting for someone
> > trying to work out what's what for the first time.
> >
> > ls perl-current/
>
> I see your point, but I don't think 'l
> Are you sitting comfortably?
yes.
>
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so let's write it as
>
> set P1,
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Melvin Smith:
> > I agree with your config/ dir suggestion, but I'm not sure about
> > moving everything else down into perl6/parrot subdirectory,
>
> Me neither. I don't see much point in it.
>
> > 1) Will Perl6 and Parrot distributions be separate?
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> #2 is what you get with normal assignment. $foo = $bar, for example.
> $foo's assign vtable method is called with $bar as a parameter. $foo
> figures out what it should do--if it's a tied variable of some sort
> it should perform its assign action. (Thi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >So in the following:
> >
> >my Complex $c = 3+4i;
> >my $plain = 1.1;
> >$plain = $c;
> >
> >I presume that $plain ends up as type Complex (with value 3+4i)?
>
> Yup.
>
> >If so, how does $plain know how to "morph itself into the RHS's type"?
>
> The g
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, for typed variables. Most variables (i.e. anything you
> declared with a plain "my $foo" or "our @bar") are untyped and can
> change their types as needed.
>
> If you did:
>
> my $foo;
> $foo = Dog.new();
> $foo = FireHydrant.new();
Alex Gough <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2002, Dave Mitchell wrote:
> > > $foo would first be a Dog, then a FireHydrant. When it changed to a
> > > FireHydrant the previous contents would get blown away.
> >
> > Hmmm - how do we distinguish bet
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> There's a flag in the flags field to mark the PMC as a permanent type
> or not. It's insufficient for "Type X or child of X" things, though.
>
> >Or to put it another way, is the type of a PMC determined purely by
> >it's current vtable pointer, and if s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:53 PM + 2/14/02, Dave Mitchell wrote:
> >My outstanding niggle is when a typed variable is undef. I guess we
> >need a generic Perl_Undef_But_Typed vtable type, which behaves mostly
> >like the PerlUndef type, but s
Dan Sugalski <[EMAIL PROTECTED]> wrpote:
> Implementation should be capable of being yanked out and replaced
> with no notice, and things still work. It is, and should be,
> considered ephemeral. It's the least important thing to get right,
> since it can be fixed or completely replaced as we n
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Need discussion on whether C is a good exception for
> this, or whether something else should be used. It's really a compiler
> screw-up, since code which indexes a non-aggregate shouldn't be
> generated.
Except of course references, where the compiler ca
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:10 PM -0800 2/23/02, Brent Dax wrote:
> > typedef struct foo_t * FooPtr;
> > typedef struct foo_t FOO;
>
> Y'know, thinking about this, I don't like this trick. That should be
> FOO, and FOO *.
>
> We either typedef the struct, or the point
Melvin Smith <[EMAIL PROTECTED]> wrote:
> This is my only nitpick with the coding standards.
>
> I never cared for the style of putting return type on a
> separate line above the function declaration header.
>
> I like it just as the prototype.
>
> I vote for non-enforcement of this one.
perso
On Fri, Mar 15, 2002 at 08:50:47PM +, Nicholas Clark wrote:
> On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote:
>
> > >> On Fri, 15 Mar 2002, Tim Bunce wrote:
> > >> > Might be good to also provide "higher level" controls that just
> > >> > provide hints to the GC. Somewhat lik
On Wed, Apr 17, 2002 at 04:34:12PM -0400, Simon Glover wrote:
>
> On Wed, 17 Apr 2002, Brent Dax wrote:
>
> > Dan Sugalski:
> > # Okay, here are the milestones. Each is worth a point release. If we
> > # manage to take them in this order, great. :)
> >
> > Rough dependency tree:
> >
> > Arrays
>
On Wed, Apr 17, 2002 at 04:57:21PM -0400, Dan Sugalski wrote:
> At 9:48 PM +0100 4/17/02, Dave Mitchell wrote:
> >On Wed, Apr 17, 2002 at 04:34:12PM -0400, Simon Glover wrote:
> >> I thought lexicals were going to live in a symbol table now? In which
> >> case,
On Wed, Apr 17, 2002 at 05:43:01PM -0400, Dan Sugalski wrote:
> At 10:16 PM +0100 4/17/02, Dave Mitchell wrote:
> >On Wed, Apr 17, 2002 at 04:57:21PM -0400, Dan Sugalski wrote:
> >> At 9:48 PM +0100 4/17/02, Dave Mitchell wrote:
> >> >On Wed, Apr 17, 2002 at 04:34:
On Wed, May 22, 2002 at 11:52:36AM -0300, Daniel Grunblatt wrote:
> And, please:
>
> 1 - Try to send the patch as an attachment, sometimes it's too difficult
> to apply if you don't.
>
> 2 - 'diff -u' I S Y O U R F R I E N D :)
'diff -up' is even better if your diff supports it!
Dave.
--
N
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
> At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
> >On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> >> Parrot has to handle signals, such as SIGSEGV.
> >
> >That's the one signal I
> *) Expect POSIX's dead-stupid mutexes to magically unlock
Hmmm, are we confident that we can write exception handling and stack
rollback code that will always clean up mutexes?
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jutland, 31st M
Aplogies if this has already been discussed, but I haven't been following
p6i too closely of late (the lure of being allowed to mess with 5.7.3
has been too strong :-)
Anyway, I presume that the Perl6 theading model will be like Perl 5
ithreads - that is to say, each thread has its own interprete
On Tue, Jun 11, 2002 at 11:31:37AM -0400, Dan Sugalski wrote:
> We'll find out with A6 whether we do coroutines and continuations as
> part of the core perl. If not, well, python does the first and ruby
> the second, so it's all good in there.
Does anyone feel like giving a 1 paragraph potted
On Mon, Jun 24, 2002 at 05:21:45PM -0400, David J. Goehrig wrote:
> On Sun, Jun 23, 2002 at 09:50:02PM +0100, Tim Bunce wrote:
> > Much more likely is some kind of wrapper that manages a simple
> > perl5-like run-time environment (stacks, marks, gimme, symboltable
> > etc) plus source-code compati
On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > Of course, another approach is to embed the existing Perl5 interpreter
> > within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs
On Tue, Jun 25, 2002 at 04:45:37PM +0100, Tim Bunce wrote:
> On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote:
> > On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> > > On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > > > Of
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> Nicholas Clark wrote:
> > I was thinking that the metric (x*x + y*y) would be fast to
> > calculate, as that's all we need for ordering.
>
> Point is, it's rather *more* than we need for ordering.
> x + y will suffice.
IIRC, all metr
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote:
>
> Dave Mitchell wrote:
> > IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> > are strongly equivalent, ie they give rise to the *same* ordering.
> > (In the limit as n -> Inf, the metric i
On Sat, Jul 13, 2002 at 03:48:31PM +0100, Nicholas Clark wrote:
> I was working somewhere where the chief technical architect, a very smart
> guy, was far too busy doing stuff to write it down, and also didn't view it
> as a priority as "I don't need to write it down, it's all in my head".
And on
On Wed, Jul 17, 2002 at 01:42:17PM -0700, John Porter wrote:
>
> Andy Dougherty wrote:
> > I think the purpose of the .dev files, as laid out in
> > docs/pdds/pdd07_codinstd.pod, is a reasonable one.
> > Here's an edited excerpt: . . .
>
> (Thanks, Andy.)
>
> Well, given that definition of the
On Wed, Jul 17, 2002 at 11:13:58PM +0100, Nicholas Clark wrote:
> On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
> > One of the reasons I used numerical accuracy as an example was because
> > in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhe
On Fri, Aug 02, 2002 at 11:15:09AM -0600, Jonathan Sillito wrote:
> Could two parallel arrays work? One stores the lexicals (accessed by
> index) and the other stores the names of the lexicals. Then to access a
> lexical by name involves a sequential search through the (probably not
> large) array
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
ie the classic
{ my $fh = IO::File->new(...); }
I know there's been lots of discussion on this over the months,
bu
On Wed, Aug 21, 2002 at 08:25:10PM +0100, I wrote:
> In this Brave New World of DOD and GCC, what guarantees (if any)
s/GCC/GC/
What with PMC, PDD, COW etc, I have TLA on the brain.
:-)
--
Nothing ventured, nothing lost.
On Sun, Aug 25, 2002 at 12:13:36AM -0400, Tanton Gibbs wrote:
> > In my understanding, no. One possible implementation is to set a flag when
> > we create an active_destruction PMC (like IO::File), and perform dod runs
> > at every block close until we don't have any such PMCs left.
>
> I earlier
On Sun, Aug 25, 2002 at 11:16:35AM -0400, Tanton Gibbs wrote:
> > In this case, it is quite likely that many programs will get that flag
> > set. In which case, we'll need to be doing a DOD run at the end of most
> > blocks
>
> I would hope not. The only things which will set this flag are those
On Thu, Sep 05, 2002 at 12:12:52PM +0100, Nicholas Clark wrote:
> On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
> > 4) The *only* tools you will need to build parrot are a C compiler
> > environment and either a make tool or a shell
>
> I believe we may be able to get away withou
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
> How many mmap's can $arch have for one program and for all?
> Could we hit some limits here, if every module loaded gets (and stays)
> mmap()ed.
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linu
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
> On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> > Dan Sugalski wrote:
> >
> > > At 5:32 PM + 1/24/03, Dave Mitchell wrote:
> > >
> > >> I just wrote a quick C program that success
On Sat, Jan 25, 2003 at 10:04:37AM -0500, Jason Gloudon wrote:
> On Thu, Jan 23, 2003 at 08:39:21PM +0000, Dave Mitchell wrote:
>
> > This means that a Perl server that relies on a lot of modules, and which
> > forks for each connection (imagine a Perl-based web server), doesn&#
On Sun, Jan 26, 2003 at 12:40:19AM +, Nicholas Clark wrote:
> On Sat, Jan 25, 2003 at 11:43:40PM +0000, Dave Mitchell wrote:
> > Okay, I just ran a program on a a Solaris machines that mmaps in each
> > of 571 man files 20 times (a total of 11420 mmaps). The process size
> &g
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote:
> The problem's actually _virtual_ memory use/fragmentation, not physical
> memory or swap. Say you map in 10k small files -- that's 640M virtual
> memory, just over a fourth of what's available. Now let's say you're also
> using mmap
On Wed, Feb 19, 2003 at 02:06:55PM +, Peter Haworth wrote:
> Shouldn't we be traversing the inheritance tree once, doing these three
> steps at each node until one works, rather doing each step once for the
> whole tree. MM dispatch probably complicates this, though.
>
> If my derived class ha
On Wed, Aug 29, 2007 at 02:44:13PM +0200, Paul Cochrane wrote:
> I've recently added a test to the coding standards tests which checks
> for a copyright statement, and that the copyright date is up to date.
> After a discussion on #parrot, Coke made the observation that maybe
> the most recent date
On Mon, Aug 11, 2003 at 07:32:00PM -, Rafael Garcia-Suarez wrote:
> Will I really be forced to reimplement the whole subrecursive frobnizer
> for tied magic ?"
Almost certainly, I expect.
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jut
On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> Here comes that ever-reincarnating thread again, sorry.
>
> This is a proposal for an efficient solution to the timely destruction
> problem, which doesn't use refcounting, and fits in to the current
> scheme pretty well.
I don't quit
On Wed, Aug 20, 2003 at 06:40:51PM -0400, Benjamin Goldberg wrote:
> Dave Mitchell wrote:
> >
> > On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> > > Here comes that ever-reincarnating thread again, sorry.
> > >
> > > This is a propos
1 - 100 of 131 matches
Mail list logo
