We might want to have a member/method by which we can tell what type of
variable we're dealing with, so that a function can be passed an arbitrary
XV, and treat it differently if it's an SV, AV, and so on.
For SVs, we might want to have a method to determine what form of
representation the int
Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| But the big problem is that there's a lot of stuff that's based off of
| time() right now, like stat(), lstat(), etc, etc. When you think of the
| cascading effects of changing Perl's timekeeping it gets really,
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
> If the internal timekeeping were changed, one thing that's apparent from
> the discussions is that there would *have* to be a core way of providing
> exactly what time() does currently or lots of stuff would break really
> badly. Some
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
>
> But the big problem is that there's a lot of stuff that's based off of
> time() right now, like stat(), lstat(), etc, etc. When you think of the
> cascading effects of changing Perl's timekeeping it gets really, really
> sticky.
I
"Stephen P. Potter" wrote:
>
> Why do we have to worry about changing time()? There's a real parallel
> between sleep() and alarm(), so we would want to do both if we did either,
> but time() really has no relation to them.
>
> Or, should we just implement usleep() and (for lack of a better nam
On Tue, Jan 30, 2001 at 05:49:43PM -0200, Branden wrote:
>
> Well, then I propose the same of RFC 48: deprecate time() and create another
> name to refer to the number of seconds since (an epoch) with decimals for
> fractions of seconds. Maybe it could be called now() or timestamp(). Then
> time
Lightning flashed, thunder crashed and Jarkko Hietaniemi <[EMAIL PROTECTED]> whispered
:
| I guess it's part of the can of sub-second worms: if we do sleep(),
| people will ask why don't we do time() and alarm(), too. sleep() and
| alarm() we could get away with more easily, but changing time() t
On Tue, 30 Jan 2001, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> >
> > As I said the problem isn't the p52p6 doing that kind of transformation.
> > The problem is someone familiar with perl5 writing code in perl6:
> >
> > if (my $fh = open(">/tmp/$$".time())) {
> >
> > and later
Jarkko Hietaniemi wrote:
> As I said the problem isn't the p52p6 doing that kind of transformation.
> The problem is someone familiar with perl5 writing code in perl6:
>
> if (my $fh = open(">/tmp/$$".time())) {
>
> and later something crashing and burning because some other place expects
> to fin
Jarkko Hietaniemi wrote:
>
> As I said the problem isn't the p52p6 doing that kind of transformation.
> The problem is someone familiar with perl5 writing code in perl6:
>
> if (my $fh = open(">/tmp/$$".time())) {
>
> and later something crashing and burning because some other place exp
On Tue, Jan 30, 2001 at 02:09:32PM -0200, Branden wrote:
> Jarkko Hietaniemi wrote:
> > I guess it's part of the can of sub-second worms: if we do sleep(),
> > people will ask why don't we do time() and alarm(), too. sleep() and
> > alarm() we could get away with more easily, but changing time()
We seem to have gotten away from the subject at hand (what jwz, who doesn't
like to use Perl, doesn't like about Java, and how those Java deficiencies
will make Perl more likeable to others who don't like to use Perl, either) to
peripheral, unimportant, non-topical things... like Perl 6 develop
David Mitchell wrote:
> Sorry, I misunderstood you. I think in fact we agree! What I was
> advocating was that Perl should automatically make accesses to
> individual shared variables safe, so 2 threads executing
> 1: $shared = 10; 2: $shared = 20;
>
> wont guarantee whether $shared ends up as 1
On Tue, Jan 30, 2001 at 10:49:56AM -0500, Dan Sugalski wrote:
> At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
> >On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
> > > Is there any really good reason why sleep() doesn't work for
> > > microseconds? I mean, if I can do th
Jarkko Hietaniemi wrote:
> I guess it's part of the can of sub-second worms: if we do sleep(),
> people will ask why don't we do time() and alarm(), too. sleep() and
> alarm() we could get away with more easily, but changing time() to do
> subsecond granularity would be A Bad Thing for backward c
"Branden" <[EMAIL PROTECTED]> wrote:
> The thing with mandatory locks per variable, is that as long as you only
> want to access _that_ variable, it's ok, but if you want to make several
> uses of several variables and want to do it all at once, you've got a
> problem.
[ big snip ]
Sorry, I misu
David Mitchell wrote:
> I let the Perl developers do all
> the hard locking code behind the scenes, and I don't have to worry my
pretty
> little head about it.
> Now, there may be practical reasons why it isnt possible for perl to do
> this for me automatically (reasons, anyone?), but it's a nice
At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
>On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
> > Is there any really good reason why sleep() doesn't work for
> > microseconds? I mean, if I can do this:
> >
> > sub sleep {
> > my($time) = shift;
> >
On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
> Is there any really good reason why sleep() doesn't work for
> microseconds? I mean, if I can do this:
>
> sub sleep {
> my($time) = shift;
> if( /^[+-]?\d+$/ ) {
> sleep($time);
> }
>
"Branden" <[EMAIL PROTECTED]> wrote:
> Well, mandatory locking is something we should definetly NOT have in Perl6.
> Most of perl's code today is not threaded, and I believe much of it will
> continue to be this way. The pseudo-fork thread behaviour that is being
> proposed also makes this ok. Eve
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
select(undef, undef, undef, $time);
}
}
Why can
Hi,
I know the process ended some time ago, but I got an email from Peter
Schattner who was using the sample code that Piers and I wrote for the
RFC and had a suggested improvement. Piers rewrote the sample
implementation and I tweaked it a tiny bit and so I thought I ought to
submit it... The co
22 matches
Mail list logo
