--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 'Kay, here's a question to ponder. Should the op dispatch
> loop handle
> argument decoding, or should that be left to the opcode
> functions?
[good analysis of trade-off's snipped]
> At the moment I'm leaning towards the functions doing
> their own
--- Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Benjamin Stuhl <[EMAIL PROTECTED]> writes:
> >I don't see where shadow functions are really necessary
> -
> >after all, no one has ever complained that you can't do
> >
> >pp_chomp(sv); /* or p
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> =head1 Stacks
[snip]
> The stacks are at least:
>
> =over 4
>
> =item Temp stack
>
> for squirreling away the contents of individual registers
>
> =item Register stack
>
> For pushing the entire register file at once. There are
> four sets, one
>
> In summary:
>
>1. I don't like ~ for concat
>
>2. But if it does become concat, then we still
> shouldn't
> change ~'s current unary meaning
>
>
> Thanks for listening.
>
> -Nate
I agree completely. However, this is no longer really a
topic for -internals, it's really a pure
Thus spake the enlightened Uri Guttman <[EMAIL PROTECTED]>:
>
> i am going to make a proposal that we ('we' to be defined
> later) develop
> a new common event loop with two major goals in mind:
>
> 1. the event loop should be fully portable over all
> modern unix OS's
> and the win32 ser
Alright, here's an issue I was musing on after dinner
yesterday: There are huge sets of optimizations that could
be made *if* the user promises not to do certain things.
For instance, who needs a symbol table when the user has
promised not to do any symbolic lookups? (Yes, I know, the
debugger, bu
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
> > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >
> > DS> Ah. I've always wanted to do that with tied
> hashes. Okay, even
> > DS> more reason to pass the data in! (We're going to
> en
I had a thought this morning on funtion/struct/global
prefixes for Parrot. If we really plan to also run
Python/Ruby/whatever on it, it does not look good for the
entire API to be prefixed with "perl_". We really (IMHO)
ought to pick something else so that we don't give people a
convenient target
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, I'm whipping together the "fancy math" section of
> the interpreter
> assembly language. I've got:
>
> sin, cos, tan : Plain ones
> asin, acos, atan : arc-whatevers
> shinh, cosh, tanh : Hyperbolic whatevers
> log2, log10, log
Thus wrote the illustrious Simon Cozens:
[severely trimmed]
> STRING* string_make(void *buffer, IV buflen, IV
> encoding, IV flags, IV type)
> STRING* string_copy(STRING* s)
> void string_destroy(STRING *s)
*cough* Namespace pollution *cough*
These should proably all be prefixed...
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl
> wrote:
> > *cough* Namespace pollution *cough*
> > These should proably all be prefixed...
>
> You're going to have a canary when you see the rest of
>
--- "Bryan C. Warnock" <[EMAIL PROTECTED]> wisely wrote:
> On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
> > And in addition - why are we worrying about namespace
> collision RIGHT NOW?
> > Sure, when Parrot can be embedded, then we should
> ensure that our names
> > aren't going to cl
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl
> wrote:
> > > It's not a prioirty, but it's so much easier to walk
> the
> > > correct path from the start. Since it's all Parrot,
> it'
It seems to me that Parrot should expose a "feature
testing" API. Something on the order of
int [read: boolean] par_has_feature(PAR_STRING *feature);
(yes, I _do_ think that claiming STRING is unnecessary
namespace pollution - sepecially as ANSI compilers, AFAIK,
aren't required to be case-sensi
--- Andy Dougherty <[EMAIL PROTECTED]>
wrote:
> In perl5, we've had occasional header file name conflicts
> over the
> years. One common example is someone putting a file
> named "config.h"
> in /usr/local/include. Other conflicts with "string.h"
> and "memory.h"
> are also conceivable.
>
> I'd
I had to hand-apply the NV patch and some of the casting
patches to get VC++ to shut up and compile, but Parrot
works on Win32 (Win2k, VC++ 6.0SP5). (it takes <1 sec to
count to ten million on my PIII 1Ghz) I'll post the
hacked-up Makefile that I fed through nmake to get it to
work when I get back
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> 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 t
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> > Index: assemble.pl
>
===
> RCS file: /home/perlcvs/parrot/assemble.pl,v
> retrieving revision 1.14
> diff -r1.14 assemble.pl
> 7a8
> > use Getopt::Long;
> 9,12c10,33
> < my $opt_c;
> <
As promised, here's the patch that gets Parrot building out
of the box on Win32. I had to comment out the mmap(), I'll
start working on doing that portably after class.
-- BKS
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, I'm currently working on the stack system for Parrot.
> I've got the
> following issue here.
>
> Assuming there's one general stack to save "stuff" on,
> where stuff is:
Out of curiousity, why only one stack? Perl 5 has at least
four or five tha
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> I've been thinking alot about the bytecode file format
> lately. Its
> going to get really gross really fast when we start
> adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
>
> * All data sizes are
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> Ok, what if we did IFF with these caveats:
> * all chunks must be padded to 4 bytes (instead of IFF's
> 2)
> * no nesting of FORMs
>
> Chunks we'd need are:
>
> Name: 'PINF' - Parrot Information
> Size: 28 bytes + size o
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Gibbs Tanton - tgibbs:
> # ## +#if defined(WIN32)
> # ## +program_code = malloc( file_stat.st_size );
> # ## +#else
> #
> # Also, since more than win32 is not going to have mmap,
> # perhaps you could add
> # a Configure #define for HAS_MMAP or someth
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2001 at 09:33:56AM +0100, Tom Hughes
> wrote:
> > The attached patch adds string_nprintf, the last
> unimplemented
> > function listed in strings.pod as far as I can see.
>
> Thanks; but I think I'm going to wait for the portability
>
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
> Hietaniemi wrote:
> > unaligned access
>
> Bother. It is as I feared.
>
> Dan, we need to do something about this. The choices are:
> put floats into the
> constant section, or ensure instructions a
--- Hong Zhang <[EMAIL PROTECTED]> wrote:
> Just curious, do we need a dedicated zero register and
> sink register?
> The zero register always reads zero, and can not be
> written. The sink
> register can not be read, and write to it can be ignored.
Those, probably not = we have a real nop, and i
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote:
> >I'm just waiting for the thumbs-up from Simon and Dan
> before committing
> >that increment and then moving on to do the changes to
> the format to
> >support more than just strings in const_table.
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
> >Just to make sure that it's making the _right_ sense,
> the
> >fixup section is basically our single level of
> indirection
> >so that we can make the byte
--- Alan Burlison <[EMAIL PROTECTED]> wrote:
> Benjamin Stuhl wrote:
>
> > Let me be more specific: if you're holding a mutex over
> a
> > call back into parrot, it's your own fault. Parrot
> itself
> > knows which functions may croak() and which wo
--- Brent Dax <[EMAIL PROTECTED]> wrote:
>
>
> --Brent Dax
> [EMAIL PROTECTED]
> Configure pumpking for Perl 6
>
> They *will* pay for what they've done.
>
> # -Original Message-
> # From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> # Sent: Wednesday, October 03, 2001 09:51
> # To: Brent
--- "Gregor N. Purdy" <[EMAIL PROTECTED]> wrote:
> Brian --
>
> > > None of these are issues with the approach I've been
> working on /
> > > advocating. I'm hoping we can avoid these altogether.
> > >
> >
> > I think this is a cool concept, but it seems like a lot
> of overhead with
> > the st
Thus did the Illustrious Dan Sugalski <[EMAIL PROTECTED]>
write:
> Croak's going to throw an interpreter exception. There's
> a little bit of
> documentation about the exception handling opcodes in
> docs/parrot_assembly.pod, with more to come soonish.
This is fine at the target language level
--- Hong Zhang <[EMAIL PROTECTED]> wrote:
>
> > > This is fine at the target language level (e.g.
> perl6, python, jako,
> > > whatever), but how do we throw catchable exceptions
> up through six or
> > > eight levels of C code? AFAICS, this is more of why
> perl5 uses the
> > > JMP_BUF stuff - s
--- Alan Burlison <[EMAIL PROTECTED]> wrote:
>
> > > or have entered a mutex,
> >
> > If they're holding a mutex over a function call without
> a
> > _really_ good reason, it's their own fault.
>
> Rubbish. It is common to take out a lock in an outer
> functions and then
> to call several othe
--- Paolo Molaro <[EMAIL PROTECTED]> wrote:
[snip, snip]
> The problem here is to make sure we really need the
> opcode swap
> functionality, it's really something that is going to
> kill
> dispatch performance.
> If a module wants to change the meaning of, eg the +
> operator,
> it can simply req
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, I think it's time to abstract out how the build
> system's handled a
> bit. I'm not sure how much we need, but filling in a
> template makefile's
> not going to cut it, I think.
>
> We've a couple of things we need to do generically:
>
> *) C
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:28 AM 12/5/2001 -0500, Jason Gloudon wrote:
> >Using the aggregate's vtable is another way of getting
> the job done that
> >avoids all the extra reference PMCs. However, references
> will have to be
> >supported.
>
> References are interestin
--- Andy Dougherty <[EMAIL PROTECTED]> wrote:
> One idiom which might work is
>
> cd foo && $(MAKE)
>
> Since lines in makefiles are handed off to the native
> shell, this will
> be dependent upon the user's native shell. I don't know
> any details,
> but I gather the various shells in Wi
--- Melvin Smith <[EMAIL PROTECTED]> wrote:
> Burp, more spam from me...
And there was much rejoicing... (rah! yay!)
> As I see it there are several immediate questions to be
> answered for Parrot
> IO.
> Feel free to answer with Y/N or Maybe.
All of the above?
> 1) Nick Ing-Simmons' Perl IO f
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:03 PM 12/18/2001 -0800, Benjamin Stuhl wrote:
> >--- Melvin Smith <[EMAIL PROTECTED]> wrote:
> > > 3) Perl IO has conditional compilation for using
> stdio.
> > > Dan has said no
> > > STDIO
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs
> wrote:
> > > GC will manage all the memory. Everything managed
> should either be hung
> >
At 04:28 PM 8/2/2002 +0200, Haegl wrote:
>On 2002/08/02 16:11:26 Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> >It does on reading. I forget the eloquent explanation about the how or
> >why, but all references bar the leftmost are vivified. (Even inside
> >defined). In effect, all bar the last ref
At 03:00 PM 1/22/2003 -0500, you wrote:
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are all
meant for movement within a segment of bytecode. They are *not* supposed
to leave a segment. To do so was a
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:11 PM 8/2/00 +0100, Tim Bunce wrote:
> >Thinking about that some more, I can imagine that...
> >
> >a) The 'use' of an 'interface definition' could
> optionally just define
> >stubs that will trigger the 'use' of a module to
> implement it wh
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> actual work. The
> dispatch routine has a function signature like so:
>
> int status = dispatch(void *native_obj, sv
> *perl_scalar, char *method_called,
> int *num_args_in, perl_arg_stack
> *arg_stack,
>
--- Bart Schuller <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 03, 2000 at 08:22:28AM -0700, Benjamin Stuhl
> wrote:
> > One thing: remember, there is a lot of talk about
> having
> > perl6 use Unicode internally, which means that things
> like
> > method na
> The normal problem with this type of structure is that
> the previous
> statement would create 2 array copies, and 3 loops for
> most compilers. In
> perl speak, it might look like:
> $dummy1[$_] = $b[$_]*$c[$_] for (0..$#b-1);
> $dummy2[$_] = $d[$_]+$dummy1[$_] for (0..$#dummy1-1);
> $sum+=$_ f
While I approve of this RFC, there are a few places where
it proposes (unnecessary) new primatives. Most of these
already exist or have planned names (in perl5).
--- Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
[snip]
> =item 2
>
> The Thread module should add a C keyword or
> function that e
--- "Stephen P. Potter" <[EMAIL PROTECTED]> wrote:
> Lightning flashed, thunder crashed and Tom Christiansen
> <[EMAIL PROTECTED]
> m> whispered:
> | Unless that's done completely transparently, you'll
> pretty much screw the
> | pooch as far as "Perl is the Cliff Notes of Unix"
> notion. Not to
> At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
> >Dan Sugalski writes:
> > > One of the current plans is for the parser to have
> access to a list of
> > > functions that trigger autoloading modules.
> >
> >Isn't dynamic loading really slow?
>
> Not particularly, at least not as far as I k
All -
I fail to see the reason for imposing that all
variables
"know" how to perform ops upon themselves. An operation is
separate from the data it operates on. Therefore, I propose
the following vtbl scheme, with two goals:
1. that the minimal vtbl be just that, minimal
2. that it be pos
--- Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > "SWM" == Steven W McDougall <[EMAIL PROTECTED]>
> writes:
>
> SWM> If you actually compile a Perl program, like
>
> SWM> $a = $b
>
> SWM> and then look at the op tree, you won't find the
> symbol "$b", or "b"
> SWM> anywhere in it. The
I have one question about vtbls that I have not been able
to figure out an answer to:
How does using a vtbl get rid of the switch(sv->sv_flags)
with multi-valued scalars running around? That is, how does
one write a vtbl function that can cope with the perl6
equivalent of perl5's
sv_setiv(s
Firstly, by "bytecode" I mean a .pmc and by "optree" I mean
the perl6 VM's internal form that it goes through
executing.
It seems to me that one thing that the perl6 bytecode
implementation _should_ do (in the interests of being light
and fast, as well as meshing well with MT) is be
position-inde
--- Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> >>>>> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>
> BS> 1. Bytecode can just be mmap'ed or read in, no
> playing
> BS> around with relocations on loading or games with RVAs
>
Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> Okay, here's what I'm currently thinking of for standard
> representations of
> integers, numbers, strings, and (possibly) complex data.
> These are not
> necessarily indicative of how the data's stored in
> scalars (or hashes or
>
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
> >Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > > For integers, we have two types, platform native, and
> > > bigint. No guarantees
> &
How is setting one SV from another going to be implemented?
My (admittedly vague) recollection was that it would be
something like
void sv_setsv(SV* dest, SV* src)
{
dest->sv_vtbl->delete(dest); /* clear the old value */
dest->sv_vtbl = src->sv_vtbl;
dest->sv_vtbl->dupfrom(dest, src); /*
58 matches
Mail list logo
