On Wed, 14 Aug 2002, David M. Lloyd wrote:
> > The problem was that the math vtable methods were giving up if the
> > other side of the operator wasn't an int or a num. So the current
> > version of PerlArray would make $x undef. I'm not sure getting the
> > o
On Fri, 12 Jul 2002, Sean O'Rourke wrote:
> # New Ticket Created by "Sean O'Rourke"
> # Please include the string: [netlabs #801]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=801 >
>
>
> This patch makes the followin
I can comment on a bit of this at least :)
On Wed, 24 Jul 2002, Melvin Smith wrote:
> It is not clear to me yet that there needs to be a 1-to-1 correlation
> from PMC's to upper level "classes".
There won't be. In general, there well be far fewer PMC classes than
upper-level classes.
Also, as
On Mon, 22 Jul 2002, Dan Sugalski wrote:
> At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
> >Dan, can we create this new vtable method? returning an integer (long
> >integer)... with name hashValue, or asHash.. or something else.
>
> Yep. Call it id and have it return an INTVAL.
On Sat, 13 Jul 2002, Tom Hughes wrote:
> Of course... The attached patch should handle that I think...
This patch is breaking several Solaris 32-bit tests. The following
assembly (from t/pmc/perlarray1.pbc):
new P0,.PerlArray
set P0,0
set I0,P0
print I0
On Tue, 16 Jul 2002, John Porter wrote:
>
> David M. Lloyd wrote:
> > John Porter wrote:
> > > The MM dispatch problem is pretty much solidly in
> > > the realm of pmc inheritance,
> >
> > There _is_ no pmc inheritance right now.
> > There's
On Mon, 15 Jul 2002, John Porter wrote:
> "David M. Lloyd" wrote:
> > Do we really want *two* inheritance trees per object
> > in Perl 6? One language-level and one PMC-level?
>
> Well, parrot != perl6, so I don't see a problem.
Ugh.
> The MM dispatch
On Wed, 10 Jul 2002, Dan Sugalski wrote:
> >What bothers me is this: the programmer needs to be able to predict
> >what the machine is going to do with the code she gives it.
> >And predicting how the machine is going to resolve the multimethod
> >call could be, in any but trivial cases, far too
On Mon, 15 Jul 2002, Ashley Winters wrote:
> PDD02: Common vtable format for all variables
> Nice.
I should be able to answer some of these.
> Question: Why is the key param for keyed_int vtable functions a pointer?
> Considering I have to implement all those functions to add a PMC...
> seems o
On Fri, 12 Jul 2002, John Porter wrote:
>
> > >Which IRC network, which channel?
> >
> > I use irc.pobox.com, you can also try irc.rhizomatic.net
> > Channel is #parrot
>
> Problem I have with irc (besides the fact that I don't, can't and won't
> use it) is that all the good stuff that flows by i
On Fri, 5 Jul 2002, Josh Wilmes wrote:
> At 8:55 on 07/05/2002 CDT, "David M. Lloyd" <[EMAIL PROTECTED]> wrote:
>
> > It got removed because it wasn't in the spec... Dan directed that we
> > replace it with a version of init that accepts a PMC argument
>
On Wed, 3 Jul 2002, Melvin Smith wrote:
> At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
> >I know there was some talk about this extra "address" parameter recently,
> >but i'm not sure what the upshot of it is. Right now, tcc is complaining
> >loudly because the init functions for parrotsub and
Well, there's now a _keyed_int form for every _keyed vtable method.
PDD02 has a summary of how these new methods work.
Also, I've added push/pop/shift/unshift vtable methods. There are no ops
that use these yet.
So if anyone wants to a make a (first?) contribution, the following needs
to be do
On Mon, 10 Jun 2002, Jeff wrote:
> Tests are now failing because of the removal of the 'inc_n_ic' opcode. I
> find this interesting for several reasons. One, the tests probably
> should have been removed. Two, once the 'inc' operator has two
> parameters, it is no longer 'increment' in my mind. I
On Fri, 7 Jun 2002, Brent Dax wrote:
> David M. Lloyd:
> # On Fri, 7 Jun 2002, Brent Dax wrote:
> #
> # > Er, what patch?
> #
> # It was attached because it is 214K. I could resend with it
> # inline if nobody minds the large message body.
>
> I don't think a
On Fri, 7 Jun 2002, Brent Dax wrote:
> Er, what patch?
It was attached because it is 214K. I could resend with it inline if
nobody minds the large message body.
- D
<[EMAIL PROTECTED]>
Nearly two years ago, a great debate was begun on this mailing list about
when to inline code and when not to, as well as the actual merits of
inlining in the first place. I will attempt to summarize here, becuase
this debate was never concluded and we now are at a point where some
things are inl
On Fri, 31 May 2002, Melvin Smith wrote:
>
> The common way is to define our own INLINE definition and have Configure
> check for it, define it null if needed, and conditionally include it
> into a file as extern if so.
>
> Sounds like a job for. BrentDax++!
Also some compilers (like SUN Wor
On Wed, 29 May 2002, Hong Zhang wrote:
> > > I used to be at Sun. I knew those warnings too. If we use longjmp
> > > carefully, we can make it. In the worst case, write our own version.
> >
> > ..Or we could use setcontext/getcontext, could we not?
>
> The setcontext/getcontext will be much worse
On Wed, 29 May 2002, Hong Zhang wrote:
> > Actually I'd been given dire warnings from some of the Solaris folks.
> > "Don't use setjmp with threads!"
> >
> > I've since gotten details, and it's "Don't use setjmp with threads
> > and do Stupid Things."
>
> I used to be at Sun. I knew those warning
On Wed, 29 May 2002, Jerome Vouillon wrote:
> On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
> > Dan may have been referring to the fact that on some key platforms
> > (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
> > use inside
On Tue, 28 May 2002, Hong Zhang wrote:
> > Important given: We can *not* use setjmp/longjmp. Period. Not an
> > option--not safe with threads. At this point, having considered the
> > alternatives, I wish it were otherwise but it's not. Too bad for us.
>
> I think this statement is not very accur
On Sun, 26 May 2002, Steve Fink wrote:
> I implemented it that way once in my private tree. But I ended up
> replacing it with a couple of PerlArrays.
>
> I am now of the opinion that there's currently nothing for a regex PMC
> to do. At compile-time, you know what sort of beast you're matching
>
May I be the first to say that the new Configure system *rocks*?
No more digging through the source code to find that config option...
- D
<[EMAIL PROTECTED]>
On Wed, 22 May 2002, Steve Fink wrote:
> Which brings me to my question: is there some way of getting
> machine-readable output from tinderbox? I'd really like to alias my cvs
> commit to something that automatically monitors the tinderbox for the
> next hour and a half so it screams at me when I
Are the REGEX structure and the match vtable methods officially dead? The
POD inside of rx.ops does not mention them at all, and right now REGEX is
typedef'd to void and no-one uses the 'match' method for anything.
Since regular expressions will most likely be implemented as Parrot
bytecode, wou
On Mon, 20 May 2002, Daniel Grunblatt wrote:
>
> On Mon, 20 May 2002, David M. Lloyd wrote:
>
> > What about subroutines? Are bsr & jsr the way it's gonna be or is there
> > a rework in the works?
>
> docs/pdds/pdd03_calling_conventions.pod :)
OK, I&
On Mon, 20 May 2002, David M. Lloyd wrote:
> Has anyone given any thought to this problem yet?
>
> Will we be able to do this or do we need a special vtable whose entries
> automatically do a callback to Parrot?
For that matter, what about calling C functions from Parrot?
Has anyone given any thought to this problem yet?
Will we be able to do this or do we need a special vtable whose entries
automatically do a callback to Parrot?
- D
<[EMAIL PROTECTED]>
Is CVS access for Parrot still invitation-only? If not, I would like to
request CVS access. I have posted mildly useful patches (mostly warning
fixes really) in the past; I don't think any have ever been rejected.
The CVS page at dev.perl.org/cvs implies that a maintainer (probably Dan I
guess)
On Thu, 21 Mar 2002, Melvin Smith wrote:
> Ahhh, those simpler days
>
> Hmm you have just given me an evil idea...
I must have had the same idea in the same instant. :-)
- D
<[EMAIL PROTECTED]>
I forgot to mention there's a patch enclosed. If it doesn't survive
formatting, take it out of my previous message.
On Tue, 19 Mar 2002, David M. Lloyd wrote:
> My Tinderbox client for 32-bit Solaris + 64-bit ints is entering an
> infinite loop with this message:
>
> >
My Tinderbox client for 32-bit Solaris + 64-bit ints is entering an
infinite loop with this message:
> Determining C data type sizes by compiling and running a small C program
> (this could take a while):
>
> Building ./test.c from test_c.in...
>
> Hmm, I see your chosen INTVAL isn't the same s
This fixes a compile error under Solaris: "a cast does not yield an
lvalue". I think this is something that GCC allows that others don't.
It's not entirely clear to me why 'rflags' was a UINTVAL to begin with.
It doesn't look like this code is really in use anyway. But in any case,
casting an l
On Fri, 15 Mar 2002, 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 like the "use less qw(me
This silly bug has been driving me mad, so I'm posting this very simple
patch despite the fact that I should really be working instead. (Guess I
got sick of seeing all three Solaris targets on fire :-)
Index: io_unix.c
===
RCS file:
On Sat, 12 Jan 2002, Dan Sugalski wrote:
> At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
> >I have a design question here. Why did we take the approach of having a
> >match method on every single vtable, instead of having a vtable for
> >regular expressions, and ha
On Sat, 12 Jan 2002, Dan Sugalski wrote:
> At 10:23 AM 1/12/2002 -0600, David M. Lloyd wrote:
> >On Sat, 12 Jan 2002, Dan Sugalski wrote:
> >
> > > At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
> > > >I have a design question here. Why did we take t
Subject says it all...
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.77
diff -a -u -r1.77 Configure.pl
--- Configure.pl9 Jan 2002 17:24:11 - 1.77
+++ Configure.pl
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl 5)?
>From a Perl (6) perspective, it makes more sense to me:
# This:
$a =~ /$regex/;
# wo
On Fri, 11 Jan 2002, Jonathan Leffler wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> >[...] I'd like to propose a convention [...] By example:
> >
> >struct somename_t { ... };
> >typedef struct somename_t { ... }* Somename;
> >
> >The non-typedef'd name of a struct type ends in _t.
>
> Is
This patch fixes a warning and also changes an 'int' to an 'INTVAL'. All
tests should pass on Solaris.
Index: rx.ops
===
RCS file: /home/perlcvs/parrot/rx.ops,v
retrieving revision 1.4
diff -a -u -r1.4 rx.ops
--- rx.ops 11 Jan
Just out of curiosity, is the regex compiler going to be written in Parrot
or C?
- D
<[EMAIL PROTECTED]>
Try #2, my first was lost in the mail or something.
Index: rx.ops
===
RCS file: /home/perlcvs/parrot/rx.ops,v
retrieving revision 1.4
diff -a -u -r1.4 rx.ops
--- rx.ops 11 Jan 2002 05:34:00 - 1.4
+++ rx.ops 11 Jan
On Thu, 10 Jan 2002, David M. Lloyd wrote:
> The problem is that when you save an int constant on the stack in a
> mixed 32/64-bit system, the int type is 8 bytes but the pointer points
> to four bytes of int constant and four bytes of... something else. So
> it has to be copied out
I'm removing this more common configuration because of the increased time
it takes to build Parrot these days. If someone else wants to pick it up,
cool, but until then I'm figuring that if the other two (mixed 32/64-bit
and pure 64-bit) work, 32-bit probably does too.
- D
<[EMAIL PROTECTED]>
This patch will clash with Steve Fink's stacks patch, but you get the
idea.
Also, there's gonna be a small speed hit that I don't know how to get
around. The problem is that when you save an int constant on the stack in
a mixed 32/64-bit system, the int type is 8 bytes but the pointer points
to
Just as the subject says.
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.72
diff -u -r1.72 core.ops
--- core.ops9 Jan 2002 17:24:11 - 1.72
+++ core.ops10 Jan 2002 21:47:29 -
On Thu, 10 Jan 2002, Steve Fink wrote:
> The naming of things is getting a bit messy. I'd like to propose a
> convention that I use in my work. It's compatible with the last draft
> of PDD 7 that I could find:
> http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
I agree, we sho
This patch fixes parrotpointer.pmc, which tries to return 0 from a void
function.
Index: classes/parrotpointer.pmc
===
RCS file: /home/perlcvs/parrot/classes/parrotpointer.pmc,v
retrieving revision 1.1
diff -u -r1.1 parrotpointer.pmc
On Wed, 9 Jan 2002, Dan Sugalski wrote:
> At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote:
> >Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
> >probably
> >it got lost in the shuffle.
>
> Weird. It's in my local MANIFEST from the patch, and CVS is convinced
> that it's up to
Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies
becuase the file isn't there...
- D
<[EMAIL PROTECTED]>
This patch adds macros to the config.h file for INTVAL and NUMVAL printf
formats; I called them INTVAL_FMT and NUMVAL_FMT, although if those names
are not appropriate I won't sweat it.
The detection mechanism is not that fancy. It just reads what you have
in $c{iv} and $c{nv} and hopefully recog
These are both warnings regarding using a STRING * to refer to a BUCKET *.
"key.c", line 275: warning: argument #2 is incompatible with prototype:
prototype: pointer to struct _bucket {struct _key_pair {..} pair, pointer to
struct {..} key, pointer to struct _bucket {..} next} : "key.c"
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
No such file: classes/perlhash.pmc
On Fri, 4 Jan 2002, Bryan C. Warnock wrote:
> On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
> >
> > So that you can use constants that are up to sizeof(opcode_t) bytes, but
> > after that you're on your own. That raises a question, though: Do we
> >
I'm getting warnings on this bit of core.ops when compiling with 64-bit
ints:
op write(i|ic, i|ic) {
INTVAL * i = &($2); /* */
write($1, i, sizeof(INTVAL));
goto NEXT();
}
I'm getting a warning that stems from the fact that sizeof(INTVAL) = 8 and
sizeof(opcode_t) = 4, so the poi
On Fri, 4 Jan 2002, Jason Diamond wrote:
> > Okay, the problem is in the compiletestc in Configure.pl. Unfortunately
> I'm
> > not sure what's proper for this. If you could, take a look at hints/vms.pl
> > for how to override the default compiletestc sub and add an override to
> > hints/mswin32.p
> > Also, the UL[L] should probably be on the inside of the ():
> >
> > stacklow => '(~0xfffULL)',
>
> I still don't see this one is safer than my proposal.
>
>~((uintptr_t) 0xfff);
Well, if you ever want to specify a constant longer than 0x7fff, you'd
better put a 'u', 'ul' or 'u
On Thu, 3 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
> >
> > Maybe we should be using the Configure output to determine what postfix to
> > use, based on the size of ints, longs, long longs, etc., and pointers,
> >
On Thu, 3 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
>
> > Maybe we should be using the Configure output to determine what postfix to
> > use, based on the size of ints, longs, long longs, etc., and pointers,
> > ra
On Thu, 3 Jan 2002, Jarkko Hietaniemi wrote:
> Please find attached a typescript log from a freshly rsynced parrot in
> tru64.
>
> Failed Test Status Wstat Total Fail Failed List of Failed
> -
> t/op/basic.t
On Thu, 3 Jan 2002, Bryan C. Warnock wrote:
> On Thursday 03 January 2002 12:33 am, Bryan C. Warnock wrote:
> > Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every
> > test failure I checked was centered around an inaccesable address coming
> > out of STACK_CHUNK_BASE(*top) [li
Here's how things build on Solaris now:
32-bit: Perfect, beautiful, couldn't be better.
32-bit with 64-bit ints: OK, but many PMC tests fail, don't know why yet.
64-bit: Horrid. About 25% of tests are crashing, don't know why yet.
The 32-bit with 64-bit ints problems should be duplicatable on a
Silences this warning.
Index: chartypes/unicode.c
===
RCS file: /home/perlcvs/parrot/chartypes/unicode.c,v
retrieving revision 1.4
diff -u -r1.4 unicode.c
--- chartypes/unicode.c 31 Dec 2001 20:00:37 - 1.4
+++ chartypes/unic
Silence this warning.
Index: io/io_os.c
===
RCS file: /home/perlcvs/parrot/io/io_os.c,v
retrieving revision 1.2
diff -u -r1.2 io_os.c
--- io/io_os.c 2 Jan 2002 04:10:50 - 1.2
+++ io/io_os.c 2 Jan 2002 16:30:52 -
@@ -1
This patch fixes a pointer deref problem if sizeof(INTVAL) >
sizeof(opcode_t).
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.67
diff -u -r1.67 core.ops
--- core.ops2 Jan 2002 00:55:03 -
The incorrect assumption here is that you are building Parrot with the
same compiler and architecture (read: integer and pointer sizes) that Perl
was built with. Specifically, it allows my perl (64-bit ints but
otherwise 32-bit) to build a full 64-bit Parrot under Solaris. Maybe it
helps other m
Is it 'incorrect' to build Parrot with ints that are bigger than opcodes?
My 'some 64-bitness' build is generating warnings and failing tests
because of the pointer mismatch (long * vs long long *) between INTVAL and
opcode_t.
Also, just out of curiosity, why is it INTVAL and opcode_t, rather tha
When I look at the tinderbox screen, there's green, orange, yellow, and
red. What to the colors mean? There's no key.
You know, it's kind of fun to watch. There should be like an auto-refresh
every 5 minutes or something. :-)
- D
<[EMAIL PROTECTED]>
On Mon, 31 Dec 2001, Dan Sugalski wrote:
> > > Could you throw the system into tinderbox? It'll give us logs of the
> > > zillions of errors or so...
> >
> >I am working on it right now. I will set up two: one that uses sparcv9
> >(fully 64-bit) and one that is 32-bit with 64-bit ints.
>
> Cool,
On Mon, 31 Dec 2001, Dan Sugalski wrote:
> At 04:43 PM 12/31/2001 -0600, David M. Lloyd wrote:
> >Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
>
> Heh, yep, I was fishing for p5p folks that might have machines they
> could enlist if it didn't t
Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
- D
<[EMAIL PROTECTED]>
-- Forwarded message --
Date: Mon, 31 Dec 2001 16:41:43 -0600 (CST)
From: David M. Lloyd <[EMAIL PROTECTED]>
To: Dan Sugalski <[EMAIL PROTECTED]>
Cc: [EMAIL
Will there be a way to 'freeze' an interpreter so that its state can be
serialized to storage? If so, how would this work with PMCs? Some
special vtable method?
This was discussed several months ago when high-level language compilation
was being discussed, but nothing definite ever came of it.
On Thu, 13 Dec 2001, Dan Sugalski wrote:
> I'm not sure we'll ultimately go this way, but I've added the following ops
> to the core:
>
> setline
> setpackage
> setfile
> getline
> getpackage
> getfile
>
> so compiler output can note the file, package, and line that code i
On Wed, 5 Dec 2001, Dan Sugalski wrote:
> The Zork interpreter might be stack based, thinking about it, but it was
> hardly geared for speed, so I don't know that it'd count if it was.
FWIW, there are many MUDs and MUCKs out there (multiplayer text-based
role-playing gmaes for those not in the k
On Mon, 3 Dec 2001, Dan Sugalski wrote:
> I'm getting tempted to have some sort of multi-level ENV thing that, for
> most single-interpreter cases, collapses down to a plain getenv/putenv.
On a related topic, I have a friend/coworker who's an avid developer of
PHP, and we routinely get into, sha
On Sat, 24 Nov 2001, Bryan C.Warnock wrote:
> On a side note, do we want to be positive-oriented or
> negative-oriented? (Do we want to succeed as fast as possible, or fail
> as fast as possible? I'm thinking fail, since you're probably more
> likely to do that.) If you weight each kind of rege
On Tue, 16 Oct 2001, Dan Sugalski wrote:
> An interpreter can get access to a shared PMC in another interpreter
> only at interpreter clone time, or if explicitly passed in via an (as
> yet undetermined) handoff method.
One thing I'd really like to be able to do in Parrot/Perl 6 is to be able
t
On Tue, 16 Oct 2001, Dan Sugalski wrote:
> Parrot's going with the "one thread per interpreter" model of
> threading.
Yay!
> PMCs will be shareable, but only when explicitly marked as shared. Passing
> an unshared PMC to another interpreter's a fatal error. PMCs *can* be
> cloned when an interp
On Fri, 28 Sep 2001, Benjamin Stuhl wrote:
> 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 com
On Fri, 28 Sep 2001, Alan Burlison wrote:
> Arthur Bergman wrote:
>
> > longjmp in a controlled fashion isn't thread-safe? Or longjmping while
> > holding mutexs and out from asynchronous handlers is not thread-safe?
>
> Arthur It *may* be possible to use longjmp in threaded programs in a
> restr
On Mon, 24 Sep 2001, Uri Guttman wrote:
> >> then what about a win/win? we could make the event checking style a
> >> compile time option.
>
> DS> Odds are you'll get per-op event checking if you enable debugging,
> DS> since the debugging oploop will really be a generic "check event
>
I'm just curious, is there a plan for how closures will work in Parrot? I
think that closures are one of the coolest Perl 5 features around (despite
their memory leak issues :-), and I'd hate to see them go away.
- D
<[EMAIL PROTECTED]>
On Sat, 22 Sep 2001, Ken Fox wrote:
> I've been thinking about the possibility of building a higher-level
> VM. The current VM is very close to a traditional CPU. What if we did
> something non-traditional that made implementing higher-level
> lexically scoped languages easier?
> I'm proposing:
Not to harp on this subject, but there is still no official place where a
casual developer like myself can find a current listing of PDDs aside from
the perl6-internals mail list archive. http://dev.perl.org/perl6 has not
been updated in a long time... and that's the place that I would expect
peo
On Mon, 10 Sep 2001, Simon Cozens wrote:
> On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski 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-what
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> > > You've pretty much got it. The flag-checking will be hardwired, but
> > > there's no reason that the function called can't be user-defined.
> > > Being able to install an arbitrary number of user-defined inter-opcode
> > > (and inter-statement) functi
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
>
> >It would be nice to be able to tell the interpreter to call a user-defined
> >C function between opcodes. This could make it easier to implement
> >debuggers, profilers, etc
Here's a feature suggestion for Perl 6.
It would be nice to be able to tell the interpreter to call a user-defined
C function between opcodes. This could make it easier to implement
debuggers, profilers, etc. as well as providing a method of safely using
asynchronous callbacks that certain C lib
90 matches
Mail list logo
