> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Most of what gets flag-checked now will probably do this, yes.
>> And why waste the GC data. I suspect that most variables will not be shared.
DS> Doesn't matter whether they're shared. Mark & sweep, generational, and
DS> refcount garb
At 03:29 AM 8/4/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > Your extended way's cool too--RFC it and we can do that as well.
>
>I've been wanting to. It would be nice (at least for me) for you to
>start suggesting more RFC "assignments" like this. Community is not
>the same as "no ownership"
At 11:40 AM 8/5/00 +, Nick Ing-Simmons wrote:
>Damian Conway <[EMAIL PROTECTED]> writes:
> > > It definitely is, since formats do things that can't be done in
> modules.
> >
> >Such as???
>
>Quite.
>
>Even in perl5 an XS module can do _anything at all_.
It can't access data the lexer's alr
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 to all threads. Perl
> will never know it's done with the Lisp structure, neither Perl nor
At 10:02 PM 8/5/00 -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.
>
>Likewise for D
At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
>Why waste space on flags? The vtbl should handle that.
Because some flags are universal, and if they're not, this field gets tossed.
>There are a limited
>number of valid combinations, the vtbl could alter the behavior and
>trading space for speed,
At 06:24 PM 8/5/00 -0400, Ken Fox wrote:
>Nick Ing-Simmons wrote:
> > I am tempted to turn that round - have the vtable pointer in the SV *,
> > and the type code (if we need it) in the vtable - that saves a deref on
> > dispatch - where we need speed - and still allows type code access for
> > me
I was thinking of RFC'ing tri-state logic. Would it be worthwhile to
make it seperate or to extend your RFC?
I'd like to be able to mimic what the rules for nulls are in databases.
(I only know sybase's rules, so there may be differences between vendors.
Could somone that is aware of the ANSI sta
Why waste space on flags? The vtbl should handle that. There are a limited
number of valid combinations, the vtbl could alter the behavior and
trading space for speed, no need to check flags. Alter the vtbl instead.
(Perhaps a simple state machine.)
And why waste the GC data. I suspect that most
John Tobey wrote:
>
> My quickie summary seems to be inaccurate. The lcc thing is not an
> implementation, it's a C-- code generator (why??).
The "lcc thing" is a C to C-- translator that serves two purposes: to
demonstrate how one might employ C-- as a back-end, and to provide an
abundant sourc
On Sat, Aug 05, 2000 at 07:25:41PM -0700, Russ Allbery wrote:
> > =head1 TITLE
>
> > Use features of portable, free compilers and libraries
>
> [...]
>
> > =head1 ABSTRACT
>
> > There is no sane reason why *nix vendors continue to push proprietary
> > compilers and system libraries on their cu
> =head1 TITLE
> Use features of portable, free compilers and libraries
[...]
> =head1 ABSTRACT
> There is no sane reason why *nix vendors continue to push proprietary
> compilers and system libraries on their customers when better, free
> replacements could be had for little effort. Eventual
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Use features of portable, free compilers and libraries
=head1 VERSION
Maintainer: John Tobey <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 46
=head1 ABST
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
Mailing List: [EMAIL PROTEC
Bennett Todd <[EMAIL PROTECTED]> writes:
> If perl6 were to want to try and rise to the level of jwz's design
> aesthetics, I'd say we oughta save ourselves a lot of work and abandon
> it now. jwz (thanks for xemacs and netscape) is solidly in the "no
> program can be gigantic enough, or slow eno
Nick Ing-Simmons wrote:
> I am tempted to turn that round - have the vtable pointer in the SV *,
> and the type code (if we need it) in the vtable - that saves a deref on
> dispatch - where we need speed - and still allows type code access for
> meta ops.
I was thinking about the case where someo
2000-08-02-19:43:57 Simon Cozens:
> Ref counting isn't garbage collection.
Ref counting is fine garbage collection.
> http://www.jwz.org/doc/gc.html
If perl6 were to want to try and rise to the level of jwz's design
aesthetics, I'd say we oughta save ourselves a lot of work and
abandon it now.
On 5 Aug 2000, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://tmtowtdi.perl.org/rfc/
>
> =head1 TITLE
>
> Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars
>
> Either include (if there is a bigint library with the appropriate
> fea
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECT
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Standardise Handling Of Abnormal Numbers Like Infinities And NaNs
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Hmm, somehow this slipped through the cracks as I was changing list
subscription addresses. Oh, well.
Below are my quickie, off-the-cuff reactions to Dan's RFC #35v1.
Recipe cum grano salis.
>The base variable structure looks like:
>
>struct {
> IV GC_data;
> void *variable_data;
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mailing List: perl6-language, [EMAIL PROTECTED]
Number: 42
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Module Scope Control
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 40
=head1 ABSTRACT
Modules
Dan Sugalski writes:
:my $foo :integer;
I expect that would be
my int $foo;
If PI ends up being a "managed" Perl6, you might see things like this though:
my int $foo : bits(16);
Larry
Ken Fox writes:
: Dan Sugalski wrote:
: > > there is a nice paper "The Structure and Performance
: > > of Interpreters" by Romer, Lee, et al. that compares Java, Perl and Tcl.
: >
: > URL?
:
: Google had a bunch of references when I searched on "structure performance
: interpreters", but none of
At 09:45 AM 8/5/00 -0700, Nathan Wiger wrote:
> > Probably not with tie, but with function calls in general, sure. We can do
> > some flow control analysis on the subs and propagate it outwards so we
> > might know, for example, that:
> >
> >sub foo {
> > my (@vars) = @_;
> > return
At 12:51 PM 8/5/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > but it's really not SVs that eat up all the space, it's arrays and hashes.
>
>And closures! If curried functions get added (and they're just sugar for
>closures) we're going to have to optimize them a *lot* more than Perl 5.
What,
At 01:03 PM 8/5/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > and it will require
> > jumping through a lot of hoops because of perl's profligate use of dynamic
> > polymorphing. If it's needed, well, we'll do it, but I'd rather put the
> > effort elsewhere to start.
>
>
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
At 06:04 PM 8/5/00 +0200, H.Merijn Brand wrote:
>In the roadmap, there's lot of actions and shamelines as spoken of in the
>camel herders association meeting. What was also talked about there, was an
>early release of perl6 to the active CPAN authors, so they would be able to
>try and implement th
Dan Sugalski wrote:
> but it's really not SVs that eat up all the space, it's arrays and hashes.
And closures! If curried functions get added (and they're just sugar for
closures) we're going to have to optimize them a *lot* more than Perl 5.
> Three classes, which is why the three lines here. I
> Probably not with tie, but with function calls in general, sure. We can do
> some flow control analysis on the subs and propagate it outwards so we
> might know, for example, that:
>
>sub foo {
> my (@vars) = @_;
> return scalar @vars;
>}
>
> doesn't change its args or any gl
At 11:16 AM 8/5/00 +, Nick Ing-Simmons wrote:
>Benjamin Stuhl <[EMAIL PROTECTED]> writes:
> >It has also led to the perl5 internals being, to put it
> >bluntly, a horrible mess.
>
>Agreed - but that is due to grafting it in late - and possibly
>trying to be too clever intuiting whether existin
At 02:45 PM 8/5/00 +, Nick Ing-Simmons wrote:
>We currently (perl5) have the "token" being:
>
>struct sv {
> void* sv_any; /* pointer to something */
> U32 sv_refcnt; /* how many references to us */
> U32 sv_flags; /* what we are */
>};
>
>3
At 08:12 AM 8/5/00 -0400, John Tobey wrote:
>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)
At 10:58 AM 8/5/00 +, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >For foreign objects, I'm not sure why you're forcing a two level
> >dispatch. Why not let the foreign code register dispatches directly
> >in the scalar's vtbl? If we did it that way, a foreign object
> >is j
At 12:07 PM 8/5/00 +, Nick Ing-Simmons wrote:
>Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >=head1 IMPLEMENTATION
> >
> >The base variable structure looks like:
> >
> >struct {
> > IV GC_data;
> > void *variable_data;
> > IV flags;
> > void *vtable;
> > void
In the roadmap, there's lot of actions and shamelines as spoken of in the
camel herders association meeting. What was also talked about there, was an
early release of perl6 to the active CPAN authors, so they would be able to
try and implement the new language for their modules.
I cannot find thi
>
> Er - Tk has (compile time generated) tables of functions.
> You can call into Tk (from C) by getting address of function table from
> perl variable and then doing (*table->func)(x,y,z).
>
> Is this relevant to what was being discussed?
Yes: what was being discussed that this problem is fai
John Tobey <[EMAIL PROTECTED]> writes:
>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) really i
Perhaps string promotion a la SV promotion?
You could have each string carry around an extra byte or two of
overhead, and encode ASCII vs UTF8 (vs UTF32 vs FOO).
Line disciplines would set the appropriate flag, and any string
handling function could read the flag if it needed to differentiate
by
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) really isn't, if we keep the
> >> two-level variabl
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-compliant) complete. Others in progress.
My quickie
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, Joshua. Quickie summary. Implementations: one[1] semi-free
> >(non-DFSG
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>
>This is similar to the structure used in perl 5, with one major
>difference. Rather than having all the intellegence needed to use a
>variable separate from that variable, this RFC embeds that information
>into the variable itself. This allows for
Tim Jenness <[EMAIL PROTECTED]> writes:
>On Fri, 4 Aug 2000, Tuomas Lukka wrote:
>
>> > Both of these are language related. Is ther really nothing in the
>> > internals that we need to make pdl better?
>>
>> One important thing that I don't have time to write an RFC for: allow XS
>> to make dynam
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) really isn't, if we keep the
>> two-level variable structure that we have now. The 'main' SV structure
Damian Conway <[EMAIL PROTECTED]> writes:
> > It definitely is, since formats do things that can't be done in modules.
>
>Such as???
Quite.
Even in perl5 an XS module can do _anything at all_.
--
Nick Ing-Simmons
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:17 PM 8/4/00 +0500, Tom Scola wrote:
>> >[I think this belongs on the language list, FWIW, Cc'd there]
>> >
>> >I like this, but I'd like to see this, inter-thread queues, and events
>>all
>> >use the same communication method. Overload filehandles t
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>> No, that's the beauty of utf8: the C datatype is still
>> char* and as long
>> as you stick to 7-bits ASCII you won't know the
>> difference. wchar_t
>> comes from a totally different school of thought, where
>> all your strings
>> are instantly incomp
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>--- 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
John Tobey <[EMAIL PROTECTED]> writes:
>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 specif
Ken Fox <[EMAIL PROTECTED]> writes:
>I'd like to see *minimal* overhead for simple scalars -- if we
>could cram immediates (like small integers and booleans) directly
>into the "SV *" that seems like a big win.
Agreed.
>
>For foreign objects, I'm not sure why you're forcing a two level
>dispatch
On Sat, 5 Aug 2000 [EMAIL PROTECTED] wrote:
> Tim Jenness wrote:
> >
> > On Fri, 4 Aug 2000, Tuomas Lukka wrote:
> >
> > > > Both of these are language related. Is ther really nothing in the
> > > > internals that we need to make pdl better?
> > >
> > > One important thing that I don't have tim
54 matches
Mail list logo
