Tim Jenness <[EMAIL PROTECTED]> writes:
> On 14 Aug 2000, Russ Allbery wrote:
>> Day resolution is insufficient for most purposes in all the Perl
>> scripts I've worked on. I practically never need sub-second precision;
>> I almost always need precision better than one day.
> MJD allows fractio
On 14 Aug 2000, Russ Allbery wrote:
> Day resolution is insufficient for most purposes in all the Perl scripts
> I've worked on. I practically never need sub-second precision; I almost
> always need precision better than one day.
>
MJD allows fractional days (otherwise it would of course be us
> Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
1904 (if it matters).
Damian
> i think you are mistaken. TIL means to me Threaded In Line code. the
> term threaded code had a meaning way before execution threads. it is a
> very simple way to generate executable machine code and some compilers
> used it. all the work was done in subroutines (as in perl) but the
> generated
> Is Perl currently using different epochs on different platforms? If so, I
Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
reason IIRC.
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> Anyway, it doesn't matter; it's a lot more widely used than any other
>> epoch, and epochs are completely arbitrary anyway. What's wrong with
>> it?
> I think the "What's wrong with it?" part is the wrong approach to this
> discussion.
That's exactly
> Anyway, it doesn't matter; it's a lot more widely used than any other
> epoch, and epochs are completely arbitrary anyway. What's wrong with it?
I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX
(thank hea
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Just in case I'm not the only one here who doesn't know what TIL
DLN> means:
DLN> http://www.cs.cornell.edu/home/jgm/tilt.html
i think you are mistaken. TIL means to me Threaded In Line code. the
term threaded code had a meanin
Tim Jenness <[EMAIL PROTECTED]> writes:
> Of course, "seconds since 1970" is only obvious to unix systems
> programmers.
I disagree; I don't think that's been true for a while. It's certainly
familiar, if not obvious, to *any* Unix programmer (not just systems
programmers), as it's what time()
On Mon, 14 Aug 2000, David L. Nicol wrote:
>
> Just in case I'm not the only one here who doesn't know what TIL means:
Ummm, no. Threaded Interpreted Language. Different TLA. :)
Dan
On 14 Aug 2000, Russ Allbery wrote:
> Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> > The idea would be twofold:
>
> >1. time() would still return UNIX epoch time. However, it
> > would not be in core, and would not be the primary
> > timekeeping method. It would be in Time::Loca
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> How much of the current base of target ports are you willing to
DS> give up in the first cut for fast? The TIL suggestion, amongst
DS> others, has the potential to speed things up rather a lot, but it
DS> has the disadvantage of r
Just in case I'm not the only one here who doesn't know what TIL means:
http://www.cs.cornell.edu/home/jgm/tilt.html
On Mon, Aug 14, 2000 at 10:03:11PM -0500, Jarkko Hietaniemi wrote:
> > What did Jarkko mean by this:
> >
> > > (strict ANSI compiler was very unhappy with the vtables
> > > in the code)
> >
> > Does this mean that Perl Vtable is going to throw portability?
>
> Huh? That was the Storable ext
> What did Jarkko mean by this:
>
> > (strict ANSI compiler was very unhappy with the vtables
> > in the code)
>
> Does this mean that Perl Vtable is going to throw portability?
Huh? That was the Storable extension and how it declared its (static)
vtables, very little to do with perl6 code,
On Mon, Aug 14, 2000 at 10:44:33PM -0400, Dan Sugalski wrote:
> > (I'm not really following Perl 6, but Unicode is obviously something
> > I have a concern about. Please *do* CC me replies, just this once.)
> > This is why we should:
> > i) Make the choice of internal encoding (UTF-8/UTF-16
Nathan Wiger <[EMAIL PROTECTED]> writes:
> The idea would be twofold:
>1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility (along with localtime
On Tue, 15 Aug 2000, Simon Cozens wrote:
> (I'm not really following Perl 6, but Unicode is obviously something
> I have a concern about. Please *do* CC me replies, just this once.)
>
> On Sat, Aug 05, 2000 at 11:16:46AM +, Nick Ing-Simmons wrote:
> > Agreed - but that is due to grafting it
On Mon, 14 Aug 2000, Nathan Wiger wrote:
>1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility (along with localtime and gmtime).
>
>2. mjdate(
(I'm not really following Perl 6, but Unicode is obviously something
I have a concern about. Please *do* CC me replies, just this once.)
On Sat, Aug 05, 2000 at 11:16:46AM +, Nick Ing-Simmons wrote:
> Agreed - but that is due to grafting it in late - and possibly
> trying to be too clever in
On 14 Aug 2000, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> How much of the current base of target ports are you willing to give up in
> DS> the first cut for fast? The TIL suggestion, amongst others, has the
> DS> potential to speed things up rather a l
On Mon, 14 Aug 2000, Larry Wall wrote:
> Dan Sugalski writes:
> : On Mon, 14 Aug 2000, Larry Wall wrote:
> :
> : > Dan Sugalski writes:
> : > : The big problem here is the large number of operators that need to
> : > : be supported in every vtable. On the other hand, it means we whittle
> : > :
> > I'm not sure anyone does that much in the way of time/date work that it'd
> > make a difference. Besides, we're talking internal here--time() may still
> > return Unix epoch seconds for compatibility reasons.
>
> Blah! I saw the prosal for an mjdate() routine and thought it was at
> the lang
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> How much of the current base of target ports are you willing to give up in
DS> the first cut for fast? The TIL suggestion, amongst others, has the
DS> potential to speed things up rather a lot, but it has the disadvantage of
DS> requiring
On 14 Aug 2000, Chaim Frenkel wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> No, they're only stored once per statement, as far as I recall. This
> LW> is a great way to handle all sorts of lexically scoped things, provided
> LW> they don't require finer specificity than
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Be careful what you ask for from us language designers. If you're not
LW> careful, we'll take away your low-level primitives and give you something
LW> like Ada's rendezvous model.
Okay, give. You obviously think it is bad. (I don't know
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> No, they're only stored once per statement, as far as I recall. This
LW> is a great way to handle all sorts of lexically scoped things, provided
LW> they don't require finer specificity than a statement. Each new
LW> statement just rams a
Dan Sugalski writes:
: On Mon, 14 Aug 2000, Larry Wall wrote:
:
: > Dan Sugalski writes:
: > : The big problem here is the large number of operators that need to
: > : be supported in every vtable. On the other hand, it means we whittle
: > : ourselves down to only one operator opcode. ;-)
: >
:
On Mon, 14 Aug 2000, Larry Wall wrote:
> Dan Sugalski writes:
> : The big problem here is the large number of operators that need to
> : be supported in every vtable. On the other hand, it means we whittle
> : ourselves down to only one operator opcode. ;-)
>
> I don't care if the program is hal
Dan Sugalski writes:
: The big problem here is the large number of operators that need to
: be supported in every vtable. On the other hand, it means we whittle
: ourselves down to only one operator opcode. ;-)
I don't care if the program is half vtables, as long as it runs fast.
Larry
On Mon, 14 Aug 2000, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : >It's not clear to me whether the intrinsic types should have a different
> : >solution to this than the extrinsic types.
> :
> : _This_ thread is about using vtables for intrinsic types. If we cannot
> : make them work there
Dan Sugalski writes:
: A language issue. Being able to require multiple locks upon entering a sub,
: along with timeouts and retries and such, would be very nice, and something
: for the language people. (Which probably means some of us over there, since
: I don't know that we have that much th
Dan Sugalski writes:
: That's what I was thinking about, and it also makes the ops smaller.
Er, I don't think so, if you're talking about what I think you're talking
about.
: (We got a warning flag field in every op as of 5.6.0, IIRC)
No, they're only stored once per statement, as far as I reca
I'm not of a mind to write up an RFC, because I'm not yet sure what I'm
suggesting, so requesting comments would be spurious at best.
Having put a lot of time in recently on an XS-implemented tied hash class,
I've noted that the standard hashtable iterator support (at least for tied
hashes) has n
Nick Ing-Simmons wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
> >Sure, but we may have to warp our ideas of what a vtable is to encompass
> >the notion of a vtable that is the cross-product of two vtables.
>
> That wouldn't be a 'vector' table but a 'matrix' table ! only 1/2 ;-)
Yep. Multime
Nick Ing-Simmons writes:
: Larry Wall <[EMAIL PROTECTED]> writes:
: >Nick Ing-Simmons writes:
: >: >It's not clear to me whether the intrinsic types should have a different
: >: >solution to this than the extrinsic types.
: >:
: >: _This_ thread is about using vtables for intrinsic types. If we c
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >It's not clear to me whether the intrinsic types should have a different
>: >solution to this than the extrinsic types.
>:
>: _This_ thread is about using vtables for intrinsic types. If we cannot
>: make them work there then t
Nick Ing-Simmons writes:
: >It's not clear to me whether the intrinsic types should have a different
: >solution to this than the extrinsic types.
:
: _This_ thread is about using vtables for intrinsic types. If we cannot
: make them work there then the proposed innermost SV * replacment is flaw
Larry Wall <[EMAIL PROTECTED]> writes:
>
>I was talking about utf8 strings having a completely different vtable
>than a utf16 or a utf32 string. The statement in question seems to be
>incompatible with that, but I'm not here to argue about that.
>
>What I'd like to figure out about these vtables
Chaim Frenkel writes:
: > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
:
: LW> : =item vtable
: LW> :
: LW> : The vtable field holds a pointer to the vtable for a variable. Each
: LW> : variable type has its own vtable, holding pointers to functions for
: LW> : the variable. Vtables are sh
40 matches
Mail list logo
