local label, and runops is
a block of code that uses goto instead of function pointer calls. It
could be kept clean (by Perl 5 standards) using techniques similar to
embed.pl's.
--
John Tobey, late nite hacker <[EMAIL P
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I propose that all internal and external functions be implemented in
> > header files and declared inline. The external runtime API will be
> > generated by compiling non-inline wra
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Hear, hear! This is exactly what I
time to optimize and this is not it.
>
> We're doing a rewrite, aren't we?
Umm, well, not necessarily. Not if what I'm doing becomes what we're
doing. See http://joel.editthispage.com/stories/storyReader$47 on the
evils of total rewrite
I'm thinking of a rewrite in the sense that (by my impression) BSD was
a rewrite of Unix. Refactoring, shifting stuff around until it's easy
to get a handle on things, and replace it all a little at a time. So,
yes, these problems
OK, this is the last I'll say on it before laying *myself* to rest.
:-)
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2000 at 02:31:15AM -0400, Sam Tregar wrote:
> > Note that we don't have to take that "chance," but I don't think we should
> > turn it down lightly. I suppose a reaso
> [Reply redirected to perl6-internals, as requested by Dan Sugalski]
>
> At 13:20 -0500 2000-07-31, Garrett Goebel wrote:
> >- Pickle looks like a better XS. But I don't know much about it
>
> What Pickle would that be? Python has something with the right name,
Gah!! That shows my ignorance
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:58 AM 8/1/00 -0500, Garrett Goebel wrote:
> >From: John Tobey [mailto:[EMAIL PROTECTED]]
> > >
> > > Since this issue mainly affects Windows users (I assume),
> >
> >Actually I've run across a coupl
BLA; }
foo() { i_foo(); }
versus
foo() { BLA; BLA; BLA; }
? I am not talking about forcing inlined functions down anyone's
throat. Non-inline functions have their place in reducing code size
and easing debugging. I just want an i_foo for every foo that callers
will have the option of us
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> >Is foo() compiled any differently in
> >
> > inline i_foo() { BLA; BLA; BLA; }
> > foo() { i_foo(); }
> >
> >versus
> >
> > foo() { BLA
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Is foo() compiled any differently in
> >
> >inline i_foo() { BLA; BLA; BLA; }
> >foo() { i_foo(); }
> >
> >versus
> >
> >foo() {
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I'm thinking of a rewrite in the sense that (by my impression) BSD was
> > a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> > to get a handle on
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:55 PM 8/1/00 -0400, John Tobey wrote:
> >Well, I am going to assume you are wrong and the above two foo()
> >implementations will produce exactly the same code.
>
> Your assumption is incorrect for good compilers. (Whethe
and works out to 256 bytes, that's 16 fetches
> on the main bus. That costs 112 cycles. On the other hand, if your
Dan, you are completely missing my point. Okay, fine, non-inline may
be a performance win in some cases. Inline may be a win in others. I
am not proposing we mandate inlin
Alan Burlison <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
>
> > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> >from PerlInterpreter and SV everywhere in place
> >of these types
AL);
> SPAGAIN;
> if (count >= 1) {
> answer = SvIV(POPs));
> }
>
> You _want_ to keep that???
Off to the side, out of sight of new code, yes.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Brent Fulgham <[EMAIL PROTECTED]> wrote:
> > Alan Burlison wrote:
> >
> > John Tobey wrote:
> >
> > > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> > >from PerlInterpreter and SV
> > everywher
???
>
> I want to print it out, take it out to the parking lot, drive a stake
> through it, light it on fire, bury the ashes print side down into a silver
> box inside an iron box under a crossroad sprinkled with garlic powder
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> But is usually much easier add entropy - so start with its the same
> function - call it, and let compiler decide which ones to expand.
You'll get no argument on that point. Please stop suggesting that I
want to take the power of decision away from
However I don't see how the proposal would aid
> the migration - after all what he is writing will be neither perl5 nor
> perl6.
I am not "writing". I am "transforming".
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> >Dan, you are completely missing my point. Okay, fine, non-inline may
> >be a performance win in some cases. Inline may be a win in others. I
> >am not proposing we mandate
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:34 PM 8/1/00 -0400, John Tobey wrote:
> >Okay. For starters, assume that every inline function is called in
> >exactly one place in the translation unit that defines its non-inline
> >counterpart. That one place be
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Bad assumption. How often is av_fill called?
Only once in av_fill.c (generated by allfuncs.pl). In most other
places, it's called as i_av_fill().
--
John Tobey, late nite hacker <
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >> But is usually much easier add entropy - so start with its the same
> >> function - call it, and let compiler deci
[EMAIL PROTECTED] wrote:
> John Tobey wrote:
>
> > > Why is he bothering? A year to produce a prototype doesn't seem like a
> > > useful way to expend effort on something that isn't actually perl6.
> >
> > It is actually perl6 if/when it's f
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > The people here are rightly skeptical about the effectiveness of using
> > the 5.6 code base as a starting point for v6, but I have a pretty
> > clear vision of how to do it, and I a
Tim Bunce <[EMAIL PROTECTED]> wrote:
> There may be scope for having two levels of API. One high level clean
> simple etc and the other a lower-level more performance oriented API.
> The former could be implemented in terms of the latter.
This is essentially what I meant by:
inline i_foo() {
Tim Bunce <[EMAIL PROTECTED]> wrote:
> So please, follow Chips wise lead, don't call your work Perl 6.
It's called Pickle.
"Andy Wardley" <[EMAIL PROTECTED]> wrote:
> Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful
> kinda way), but there's nothing to stop you from wrapping it
(Ideas, yes, but code, no)
In my case, any code that I write and mention here will carry a
license that permits its being nicked for any official perl release.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
[EMAIL PROTECTED] wrote:
> Graham Barr wrote:
>
> > Well I think it is worth an RFC (not that I have time to write one just now)
> > If only to suggest some sample implementations. Do other languages do it ?
> > If so how ?
>
> Ok, Ok, I'll do a RFC then... :-)
>
> Actually the only thing aff
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Bad assumption. How often is av_fill called?
> >
> >Only once in av_fill.c (generated by allfuncs.pl). I
s Brent points out, is
free to ignore our hint under normal optimization flags.
Moving from a first-guess (C) to an optimal (C) (where we make
reasonable hints all the time, no doubt with the aid of some Configure
tests or machine-dependent conditionals) can be an ongoing pursuit.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
id a very good job. My only big
> >worry for perl6 is that, without great care, we'll loose that
> >performance edge in the name of a 'clean API'.
Please everyone accept that we will provide *both* a source *and* a
binary API, so ideally the choice between total chasti
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> That sounds like a pre-judgement that inline form is prefered ;-)
> >> But actually most places (I looked when doing TIEARAY) perl itself calls
> >> nether i
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> I don't think so - it is a question which way we code the source:
> >>
> >> A. Use 'inline' every where and trust compiler not to do what we told i
On Linux: /proc/self/exe
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
dlink /proc/self/exe
/bin/readlink
$ perl -le 'print readlink "/proc/self/exe"'
/home/usr/local/bin/perlmacs
> And it's a nonportable answer
> that cannot be reproduced everywhere that Perl runs.
Touche. I believe Windows&#x
Can I safely assume that we will be counting references for garbage
collection?
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:38 PM 8/2/00 -0400, John Tobey wrote:
> >Can I safely assume that we will be counting references for garbage
> >collection?
>
> No.
>
> In fact, you can safely assume that GC will be handled by some non-refcount
> 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,
> int *num_args_out, perl_arg_stack *return_values);
>
>
&
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > A scalar is made an object via a call into the perl library. The
> > > scalar is marked as an object and stuck into a package. Attached to
> > > the scalar is a pointer
s, is there any more concrete info on
the C# IL than what's in the article? I'd like to know what would be
involved in supporting it.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
#x27;m only halfway through the C-- paper, and I'm wondering:
What is the status of implmentations? Why not implement it as
extensions to existing C compilers?
Thanks
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> A few more clicks and I found:
>
> http://www.cminusminus.org/
Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free
(non-DFSG-compliant) complete. Others in progress.
Why not specify as a C extension: I'm still looking for that.
Kevin Scott <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> >
> > Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free
> > (non-DFSG-compliant) complete. Others in progress.
> >
> > Why not specify as a C extension: I'm still loo
s--that way you can get a generic
> perl magic cookie pointer and find out what the heck the thing really is.
Making it a data member of the vtable sacrifices extensibility. I
started doing Perlmacs that way until I realized this.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
forcement departments understand each other perhaps even
better than did Hitler and Stalin. Some of the world's best coders
are in there, and the rest of us are out here. :-)
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
me.
Oh, cool. I misunderstood you.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Garrett Goebel <[EMAIL PROTECTED]> wrote:
> With Bruno Haible's permission, I'm reposting a portion of our
> correspondence. The gist of which is that he'd be willing to make ffcall
> available for use with Perl under the LGPL.
Great. I suggest that this topic be moved to the library list (or is
utines could be demand-loaded so as
not to affect programs that don't use them.
This is something like how the Windows 32 API works, I believe, where
FooBarBlahBlahBlah is a macro defined as either FooBarBlahBlahBlahA
(for
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:11 PM 8/2/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > > > A scalar is made an object via a call into the perl
> > &
Tom Christiansen <[EMAIL PROTECTED]> wrote:
> Does that mean that we're tossing out all other less onerous licensing
> schemata, like Artistic or BSD, and that consequently Perl is now
> guaranteed to be infested by the infinitely divisive political
> problems and pernicious peculations of rms and
I think we are trying to accommodate any of several GC systems to be
selected amongst in future.
Ken Fox <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> > Picture this. A Lisp (or Java, ...) structure holds a Perl
> > interpreter. A Perl variable holds a reference
Ken Fox <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> > I think we are trying to accommodate any of several GC systems to be
> > selected amongst in future.
>
> Then the Perl API needs to allow for the GC to move objects. If that
> can't happen, the majority
Ask, can we please have the following list:
Name: perl6-internals-gc
Chairs: John Tobey <[EMAIL PROTECTED]>
Ken Fox <[EMAIL PROTECTED]>
Deadline: Conterminous with perl6-internals (currently 13
October 2000)
Mission:Det
Oops, I guess this should be contingent on Dan Sugalski's approval.
-John
John Tobey <[EMAIL PROTECTED]> wrote:
> Ask, can we please have the following list:
>
> Name: perl6-internals-gc
> Chairs: John Tobey <[EMAIL PROTECTED]>
>
debates out of the more general internals list, since a lot of
people love discussing GC at great length, and I don't expect that
debate to have much relevance to the rest of the internals.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Yup, and I realized one of my big problems to GCs that move memory
> (references that are pointers and such) really isn't, if we keep the
> two-level variable structure that we have now. The 'main' SV structure
> won't move, while the guts that the equi
OK. Ask, cancel that request. Sorry.
-John
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 02:45 PM 8/4/00 -0400, John Tobey wrote:
> >I guess, more than establishing a working group, I'm hoping to siphon
> >GC debates out of the more general internals list, sin
rather than every darned time) make install, however, should
> be the only thing that messes with these files.
How tough would this be?
# perl -MPerl::Mover -e 'copyperl "/home/me/local"'
Perl/Mover.pm does whatever's needed regarding binedits, relinking,
and w
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> >> A few more clicks and I found:
> >>
> >> http://www.cminusminus.org/
> >
> >Thanks, Jo
John Tobey <[EMAIL PROTECTED]> wrote:
> Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> > A few more clicks and I found:
> >
> > http://www.cminusminus.org/
>
> Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free
> (non-DFSG-com
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Yup, and I realized one of my big problems to GCs that move memory
> >> (references that are pointers and such)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> That's going to complicate a lot of things, and it will mean perl will end
> up doing all sorts of temp SV creation when these 'mini SVs' get passed to
> subs. Plus it complicates life a lot for people writing the guts. (Which
> would be us. :)
The pro
or other such things. If 0, the scalar is assumed to be
>unshared and no synchronization is done.
Interpreter ownership: Stuff that exists "by value" does not need an
owner. Stuff that lives in an a
I'm sending this to perl6-internals and BCC'ing it to perl6-rfc.
Maybe that is a good compromise.
-John
=head1 TITLE
Use features of portable, free compilers and libraries
=head1 VERSION
Maintainer: John Tobey <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mail
Your have a powerful argument for supporting argument standards and
avoiding use of features that are ill-conceived or differently
specified by a standard. I will add these points to the document.
However, I believe I still have a strong case for encouraging adoption
of the good features of GNU
On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski wrote:
> John Tobey wrote:
> > Picture this. A Lisp (or Java, ...) structure holds a Perl
> > interpreter. A Perl variable holds a reference to the Lisp structure.
> > Structure and interpreter become inaccessible
;room. And as needed the vtbl can be promoted to a duality version
> >that maintains both.
>
> I agree with this, though I'm pretty sure most scalars end up with
> multiple types. I'm up for either way, though--
re's nothing left to unlock
when you're done. Hmm, how do we politely tell the guy waiting for
the lock we destroyed to have better luck next time... Maybe don't
free the memory until we lock the arena page.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
On Sun, Aug 06, 2000 at 08:40:51AM -0400, John Tobey wrote:
> Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > >> If the sync data is in the SV, I believe there is a race
> > >> condition between the destruction and grabbing a lock.
> >
> > DS> Nope.
On Sun, Aug 06, 2000 at 08:33:52AM -0400, John Tobey wrote:
> If the stuff lives in an arena, have one mutex-init lock per page of
> the arena. I imagine every arena page will be aligned on 4k or so and
> will have a structure at the beginning containing the interpreter
> pointer an
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:33 AM 8/6/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> > > >Why waste space on flags? The vtbl should handle that.
> >
all the locking code once a variable's been
> explicitly shared (and therefore has a valid threading vtable as well as
> presumably a valid sync structure)
That sounds like a good idea to me.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
Hi guys,
I'm in the middle of writing an RFC regarding Perl's use of the C
stack. If any of you has the time, please take a look at what I've
written below and send me any comments or corrections. I haven't got
to the implementation section yet, but it will involve smallish,
fixed-size stack fr
data-tracking mechanism aside from
security. If the keyword 'untaint' had to appear, it would be easier
to find security issues than when m/(.*)/ is used.
Uh-oh, now we're getting back into perl6-language territory...
a
traightforwardly
implemented with GCC using a smallish machine-specific header.
I'll bet a non-optimizing version could be produced with no asm - just
use volatile for variables and goto for jumps. Accessing the stack
pointer and inserting span data might require asm.
Best
-John
On Sat, Aug 05, 2000 at 10:02:23PM -0500, Jarkko Hietaniemi wrote:
> On Sat, Aug 05, 2000 at 07:25:41PM -0700, Russ Allbery wrote:
> > libraries and tools are better than the vendor counterparts; Sun's
> > compilers and linkers are considerably better than GNU's for SPARC C code,
> > for example.
78 matches
Mail list logo
