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 Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
> On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
> > sub do_add3 {
> > my $a = $_[0];
> > sub add3 {
> > $a + 3;
> > }
> > add3();
> > }
>
> What Perl 5 does with that case is just a plain ol
On Sun, Nov 13, 2005 at 11:58:39AM -1000, Joshua Hoblitt wrote:
> I started a thread about this a couple of weeks ago. I really think
> that bison 1.75c should be the minimum requirement.
Note also that bison < 1.24 has licencing issues, in that the generated
output files are GPLed.
--
Art is a
sidered?
> >
> > Certainly. Note that the naming conventions are now being followed by
> > Interp and friends.
>
> Dave Mitchell <[EMAIL PROTECTED]> is listed as the maintainer for that
> PDD. Perhaps he can comment on the proposal?
I'm not currently involved
On Wed, May 04, 2005 at 05:26:25PM +0100, Nicholas Clark wrote:
> On Mon, May 02, 2005 at 08:58:43AM +0200, Leopold Toetsch wrote:
> > Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > > Parrot gives each PMC class 8 private flag bits. I was wondering how to
> > > use
> > > these most efficiently for
On Thu, Apr 28, 2005 at 05:57:10PM +0200, Robin Redeker wrote:
> Just because refcounting is error-prone it doesn't mean that a garbage
> collector is better (and less error-prone).
I'm one of the maintainers of the perl5 core. perl5 is very mature, with
relatively few new features being added, an
On Fri, Jan 14, 2005 at 02:40:43PM -0700, Luke Palmer wrote:
> What I'd most like is to convince Larry to waive the timely destruction
> requirement. However, that doesn't really solve the problem for other
> languages that need timely destruction. Are there any?
Perl 5 springs to mind !!!
--
On Fri, Sep 24, 2004 at 09:30:22AM -0700, Steve Fink wrote:
> But I agree that it is doing a name lookup in the string eval case.
> Although if you try it, you get puzzling results:
>
> perl -le 'sub x {my $foo = 1; return sub { eval q($foo++) } };$x=x();print
> $x->(), $x->(), $x->()'
>
> print
On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote:
> No, you still have the four basic actions. Subparsing is all hidden in
> the lexer.
Hence why the lexer in Perl 5 is 8000 lines long ;-)
--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has
On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
> But for things like -r "file" && open(FH, "file") they are of rather
> dubious value.
Well, I have some scripts that check at the start whether all the
things they going to need are readable/executable/whatever, so that they
can
On Sat, Jan 17, 2004 at 04:58:25PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Dave Mitchell) writes:
> > The perl5 internals are a complete mess. It's like Jenga - to get the
> > perl5 tower taller and do something new you select a block somewhere in
> > the middle
On Fri, Jan 16, 2004 at 09:27:57AM -0500, Dan Sugalski wrote:
> With perl, for example, it's distinctly possible that this:
>
> our $foo; # It's a global
> $foo = 12;
> if ($foo > 10) {
> print $foo;
> }
>
> will require fetching $foo's PMC out of the global namespace three
> times,
On Sat, Jan 03, 2004 at 08:24:06PM -0500, Matt Fowles wrote:
> All~
>
> I have a naive question:
>
> Why must each thread have its own interpreter?
>
>
> I understand that this suggestion will likely be disregarded because of
> the answer to the above question. But here goes anyway...
>
> Wh
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote:
> At 18:20 + 1/3/04, Nigel Sandever wrote:
> > Sharing data between the threads/interpreters is implemented by
> > tieing the two copies of the variables to be shared and each time
> > a STORE is performed in one thread, the s
On Thu, Jan 01, 2004 at 11:21:57AM -0800, Jeff Clites wrote:
> As far as what level needs to implement them, I'd say that parrot has
> to do enough to make it possible for an HLL to expose ithreads-style
> threading. Due to the cross-language nature of parrot, practically
> speaking this probabl
On Tue, Dec 23, 2003 at 11:07:53AM +0100, Elizabeth Mattijsen wrote:
> At 10:37 +0100 12/23/03, Leopold Toetsch wrote:
> >2) the Perl5ish declaration
> >
> > my $var : shared;
> >
> > is basically:
> >
> > $P0 = new SharedPerlUndef;
> >
> > OTOH:
> >
> > share($var);
> >
> > may n
On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> We've got ordered destruction on the big list 'o things to do, and it
> looks like we need to get that done sooner rather than later. So, this is
> a good chance for someone to burn those surplus SAN points and become one
> with the gr
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
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 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 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 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 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 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 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 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 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 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 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 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 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.
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 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
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 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 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 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 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 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 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 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 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
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
> *) 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
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
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 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 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, 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 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 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
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
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
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]> 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
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]> 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
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:
> 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();
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:
> #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
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?
>
> 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 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
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
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
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
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
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
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 '=>'
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
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
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
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
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
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
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:
> 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
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
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
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
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
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[
?
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
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
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/
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?
>
>
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
> 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,
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
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_
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
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
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
> &
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
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 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
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
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
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
1 - 100 of 131 matches
Mail list logo
