Daniel Dickman wrote:
> > msun library? Ignore the problem? Patch the current implementation?
>
> Patches to correct the current code would be very welcome. (In my case
> especially if it improves numpy test results).
Agree. Don't replace the code.
Replacements are likely to contain other b
> On Jul 1, 2019, at 2:50 AM, Moritz Buhl wrote:
>
> Hi,
>
> while testing arm hardware on OpenBSD I noticed that some floating point
> operations cause failures of other tests.
> In fact the current libm is incorrect according to the ISO C Std Annex
> G. I found this out after porting some F
On Sat, May 04, 2019 at 06:18:27PM +0100, Rafael Neves wrote:
> On Sun, Apr 14, 2019 at 08:05:21PM +0100, Rafael Neves wrote:
> > On Mon, Apr 08, 2019 at 12:35:41AM +0100, Rafael Neves wrote:
> > > Hi tech@,
> > >
> > > When I had to change a HD between machines I figured out that -P option
> > >
This is a modified diff of the previous evaluate multi-argument diff. The
main difference is that all functions are given a number of parameters in
the function map, this number represents how many arguments are required
for the function to work. This extra column indicates to multiarg() how it
On Tue, 09 Jul 2019 18:56:34 +0200, Moritz Buhl wrote:
> while running some NetBSD syscall tests I noticed that listen(2) returns
> the wrong errno when a socket is already connected. man 2 listen already
> mentions EINVAL.
Your patch looks correct and makes our behavior match POSIX (and
our own
Hi,
while running some NetBSD syscall tests I noticed that listen(2) returns
the wrong errno when a socket is already connected. man 2 listen already
mentions EINVAL.
NetBSD bug:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46150
NetBSD patch:
http://cvsweb.netbsd.org/bsdweb.cgi/src/
Klemens Nanni wrote:
> I think sysupgrade should, if at all, use the same semantics as the
> installer. That is, something like `sysugprade -S '-* b*'" to upgrade
> nothing but kernels and base.
>
> Such options offer great potential for users to shoot themselves in the
> foot by doing partial u
Klemens Nanni wrote:
> I think sysupgrade should, if at all, use the same semantics as the
> installer. That is, something like `sysugprade -S '-* b*'" to upgrade
> nothing but kernels and base.
>
> Such options offer great potential for users to shoot themselves in the
> foot by doing partial
I think sysupgrade should, if at all, use the same semantics as the
installer. That is, something like `sysugprade -S '-* b*'" to upgrade
nothing but kernels and base.
Such options offer great potential for users to shoot themselves in the
foot by doing partial upgrades; I am not really sold on
On 09/07/19(Tue) 14:29, Alexandre Ratchov wrote:
> [...]
> Why do you want to differenciate sleeping priorities from running
> priorities?
To be able to simplify the scheduler logic. Sleeping priorities are
something we could question. But by doing this separation it makes
it simpler to get rid
Hello,
Here is a diff to allow selection of packages to install.
My routers do not need X or games to be installed.
$ doas sysupgrade -s -CGMX
SHA256.sig 100%
|***|
2141 00:00
Signature Verified
INSTALL.amd64 10
Ian McWilliam wrote:
> Isn't Unix a trademark of the Open Group? Hence the usage of Unix-like or
> Un*x..
That trademark is UNIX, all caps.
According to [APUEv3]:
"The Open Group owns the UNIX trademark and uses the Single UNIX Specification
to define the interfaces an implementation must suppo
On Mon, Jul 08, 2019 at 06:43:34PM -0300, Martin Pieuchot wrote:
> PUSER has been used since the import of ___thrsleep(2) / librthread.
> This value has been then copied to futex(2). No other tsleep(9) call
> use this value. I'd like to stop using it to be able to differentiate
> sleeping priorit
On Mon, Jul 08, 2019 at 11:56:58PM -0700, Evan Silberman wrote:
> Jason McIntyre wrote:
> > On Tue, Jul 09, 2019 at 07:43:50AM +0200, Otto Moerbeek wrote:
> > > On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
> > >
> > > I don't know our stance on Unix vs Un*x. I'll leave this to
Ian McWilliam wrote:
> Isn't Unix a trademark of the Open Group? Hence the usage of Unix-like or
> Un*x..
Yeah I have no complaint with "Unix-like". I'm happy to learn about the
historical reasons for writing "Un*x". If it's to be suggestive of variants,
that makes a little bit of sense, though i
15 matches
Mail list logo
