Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Chaim Frenkel <[EMAIL PROTECTED]> wrote:
>
> > I'd like to be able to mimic what the rules for nulls are in databases.
>
> > NULL == NULL : false
>
> Always true surely?
NULL to a database means unknown not undefined or uniti
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Chaim Frenkel <[EMAIL PROTECTED]> wrote:
>
> > 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
On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote:
>>Even in perl5 an XS module can do _anything at all_.
>
>It can't access data the lexer's already tossed out. That's where the
>current format format (so to speak) runs you into trouble.
Only if you insist on the identical syntax as it ha
In message <[EMAIL PROTECTED]>
Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> GNU CPP supports
> varargs macros, so why not ship GNU CPP with perl? There is no GPL
> issue if it is only used in the build.
C99 supports them as well, so you're likely to see other compilers
start to su
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> 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 standard chime in.)
Are
At 09:11 PM 8/6/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >The rest is also there to optimize the common case. (Though I do think it's
> >overkill in many circumstances if all variables share the same base
> >structure--arrays don't really need an integer po
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>The rest is also there to optimize the common case. (Though I do think it's
>overkill in many circumstances if all variables share the same base
>structure--arrays don't really need an integer portion, neither do hashes)
So you re-use the space for A
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>And why carry around IV/NV and ptr? Make it into a union, to allow room.
_my_ original "ramblings" posting did.
I kept the triple to pad the thing to 8 words.
Partly as devil's advocate against the "squeeze it all into one word" camp ;-)
Essentially
At 08:51 PM 8/6/00 +, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >
> >This got me thinking about whether it's necessary to define exactly what
> >an SV struct is. The following seems over-specified:
> >
> >
> >Dan's struct that includes thread sync stuff is also over-specif
At 08:35 PM 8/6/00 +, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >(And if
> >we say something like "this is fast" people will ignore all the warnings.)
>
>As one of the worst offenders I certainly will ;-)
Works for me. :) People have always had the capability to fundament
Ken Fox <[EMAIL PROTECTED]> writes:
>
>This got me thinking about whether it's necessary to define exactly what
>an SV struct is. The following seems over-specified:
>
>
>Dan's struct that includes thread sync stuff is also over-specified.
>
>I think the only thing we have to standardize on is the
Ken Fox <[EMAIL PROTECTED]> writes:
>
>When we document this, can we move the low level interfaces out of the
>pod directory? It would be a shame to have people accidentally start using
>the internal interfaces just because they're well documented. ;)
If they are well documented then the risks t
Bryan C . Warnock <[EMAIL PROTECTED]> writes:
>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
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
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > ``Abundant macros, inline functions, and API functions will be
> > used wherever possible so as to allow fundamental changes to the
> > internal representation.''
>
> That belongs in a different RFC, the one roughing out the embedding,
> ex
At 10:13 AM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > >IMHO it would be a lot easier to read the
> > >code if we clearly differentiated between what's now called SV and the
> > >collection of xpv*'s.
> >
> > I agree. That's why I yanked in the PMC designation. :-)
>
>PMC isn't any easi
At 10:30 AM 8/6/00 -0400, John Tobey wrote:
>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.
>
John Tobey wrote:
> Sorry, I fail to see why. To upgrade or destroy an object:
>
> 1. lock the object
> 2. lock the source arena
> 3. lock the destination arena
> 4. move bits
> 5. unlock the destination arena
> 6. unlock the source arena
> 7. unlock the object
Arena
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.
> > >
> > > Because some flags are universal, and if t
Dan Sugalski wrote:
> >IMHO it would be a lot easier to read the
> >code if we clearly differentiated between what's now called SV and the
> >collection of xpv*'s.
>
> I agree. That's why I yanked in the PMC designation. :-)
PMC isn't any easier than SV.
I think we should call it a binding. Bin
At 07:54 AM 8/6/00 -0400, John Tobey wrote:
>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 int
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.
> >
> > Because some flags are universal, and if they're not, this field
> > gets tossed.
>
>Flags tha
At 08:40 AM 8/6/00 -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. If the variable is shared, the lock will need to be taken
> > DS> to
At 07:13 AM 8/6/00 -0400, John Tobey wrote:
>However, I believe I still have a strong case for encouraging adoption
>of the good features of GNU CC and Libc as new standards and getting
>vendors to contribute their optimizations. No one I know really wants
>to maintain portability code such as Co
John Tobey wrote:
> Use features of portable, free compilers and libraries
As special optimization cases identified by Configure? Sure.
I don't want to hurt portability though and I sure don't want
to be unfriendly to vendors. IMHO this RFC is not in the spirit
of the Artistic license.
- Ken
Chaim Frenkel wrote:
> > "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, gene
John Tobey writes:
> I am furthermore *not* suggesting dropping support for non-Unix or
> non-GCC platforms. I am merely saying that that is not where our
> focus should be.
Is there some problem with the current perl5 treatment of gcc that
you're trying to address? If not, then I don't see the
Dan Sugalski wrote:
> I agree with this, though I'm pretty sure most scalars end up with multiple
> types. I'm up for either way, though--I think some test code is in order
> once things get a bit more hammered out. (I'd like to get some sample
> variable code put together in a few weeks, once the
John Tobey wrote:
> But if we anticipate possibly implementing mark-and-sweep
We're definitely going to have some sort of traversing collector. It
might only augment the ref count collector. The ref count might be 5
bits at the bottom of flags and we can do this:
enum gc_flags { sticky = 16 };
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 and stuff like t
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. If the variable is shared, the lock will need to b
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. If the variable is shared, the lock will need to be taken
> DS> to destroy it. If it's not shared it's not an issue.
>
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.
>
> Because some flags are universal, and if they're not, this field
> gets tossed.
Flags that vary only when the vptr varies could go in a field of
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 to all threads. Perl
>
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
John Tobey <[EMAIL PROTECTED]> writes:
> I am furthermore *not* suggesting dropping support for non-Unix or
> non-GCC platforms. I am merely saying that that is not where our focus
> should be.
I think our focus should be on portable, standards-compliant code that
will run on any platform that
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.
37 matches
Mail list logo
