On 29 Apr, Jake Burkholder wrote:
> Thanks, this should be fixed now. A break; was forgotten in
> some recent proc locking changes.
I will test it after "softdep_update_inodeblock: bwrite: got error
22 while accessing filesystem" is fixed (I made a backup of / after
reading the bugreport and be
> Hi,
>
> -current from yesterday:
> ---snip---
> (45) root@ttyp0 # idprio 31 /bin/sleep 10
> idprio: idprio: Invalid argument
>
> (46) root@ttyp0 # rtprio 31 /bin/sleep 10
> rtprio: rtprio: Invalid argument
> ---snip---
>
> isdnd is also affected (if you use its rtprio keyword in isdnd.rc).
On 2000-Mar-07 05:35:04 +1100, Ian Grigg <[EMAIL PROTECTED]> wrote:
>my $packed = "\0\0\xc0\x7f";
>print STDERR "len: ", length($packed), " bytes: ", unpack("H*", $packed), "\n";
>my $float = unpack("f", $packed);
>print STDERR "float done\n";
>print STDERR "float: $float\n";
Looking at the resul
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
>> Depending on your religion the bug is either in perl itself which
>> should be more careful about NaN and Inf values, or in the perl
>> script you supply which does something which is patently bogus,
>> but nothing which should provoke a FP tra
More on that!
Lads here took this to heart and put the debugger over the code.
Apparently, Linux uses glibc which sets the flags in FPU to ignore
the cmp-NaN fault. Then, I guess, Perl picks it up and turns it into
NaN. OTOH, FreeBSD libraries don't do that, and the FPU causes
the cmp-NaN faul
That is because FreeBSD correctly traps operations on the value NaN.
Depending on your religion the bug is either in perl itself which
should be more careful about NaN and Inf values, or in the perl
script you supply which does something which is patently bogus,
but nothing which should provoke
> after building 4-current (cvsupped yesterday) I'm using OpenSSH now. I'm
> starting my X11 session with ssh-agent and using ssh-add in my
> .xsession. Unfortunally there's no ssh-askpass build in 4-current (and
> ssh-add is build with
> '#define SSH_ASKPASS_DEFAULT "/usr/X11R6/bin/ssh-askpass"')
On Tue, Feb 15, 2000 at 10:59:58AM +0100, Bart Schuller wrote:
>
> On Tue, Feb 15, 2000 at 01:20:28PM +0500, Andrey Kolotev wrote:
> > @c = ("Async32"x4, "Async32"x5, "Async32"x7, "Async32"x10);
> >
> > while (1)
> > {
> > foreach (@c)
> > {
> > $_ =~ s/Async/ Async/;
> >
On Tue, Feb 15, 2000 at 01:20:28PM +0500, Andrey Kolotev wrote:
> @c = ("Async32"x4, "Async32"x5, "Async32"x7, "Async32"x10);
>
> while (1)
> {
> foreach (@c)
> {
> $_ =~ s/Async/ Async/;
> }
> }
You're forever adding spaces and complain of a memory leak?
--
The
On Tue, 25 Jan 2000, Ilya Zakharevich wrote:
> On Tue, Jan 25, 2000 at 02:44:05PM -0500, Chuck Robey wrote:
> > On Mon, 24 Jan 2000, Lars Eggert wrote:
> >
> > > Ilya,
> > >
> > > thanks for the quick response.
> > >
> > > > Signals and Perl do not mix. Please do not use signals if a segfault
On Tue, Jan 25, 2000 at 02:44:05PM -0500, Chuck Robey wrote:
> On Mon, 24 Jan 2000, Lars Eggert wrote:
>
> > Ilya,
> >
> > thanks for the quick response.
> >
> > > Signals and Perl do not mix. Please do not use signals if a segfault
> > > is not a desirable form of output.
> >
> > Never? Afte
On Mon, 24 Jan 2000, Lars Eggert wrote:
> Ilya,
>
> thanks for the quick response.
>
> > Signals and Perl do not mix. Please do not use signals if a segfault
> > is not a desirable form of output.
>
> Never? After reading perlipc I was under the impression that using signals
> was okay if you
On Mon, Jan 24, 2000 at 09:53:27PM -0800, Lars Eggert wrote:
> > Signals and Perl do not mix. Please do not use signals if a segfault
> > is not a desirable form of output.
>
> Never?
Never. Well, I did not try XSUB signal handlers, but if it is a Perl
subroutine, then the harm may be already
Ilya,
thanks for the quick response.
> Signals and Perl do not mix. Please do not use signals if a segfault
> is not a desirable form of output.
Never? After reading perlipc I was under the impression that using signals
was okay if you keep your handlers simple. I may have to use to another fo
Lars Eggert writes:
> Running the following test script causes perl to crash. You may need
> to run the script several times before seeing the problem. (The script
> spawns a child process that does nothing but write to an array. The
> parent signals the child periodically.)
Signals and Perl do n
In message Jeroen Ruigrok/Asmodai writes:
: Why isn't the FreeBSD project using tags like $FreeBSD$ instead of the
: now-used $Id$?
The stuff was added to the tree, but was backed out because our CVS
support, at the time, wasn't up to snuff. I'd love to see this
change, but there are many other
16 matches
Mail list logo
