pool doesn't need to use tailq. simpleq is good enough. list
operations are now using 50% fewer pointers, and therefore must be
twice as fast. zoom! well, it does reduce memory of elements some,
which is always nice.
entirely mechanical change, except only in pool_destroy does it
matter. i don't e
On Thursday 21 March 2013 7:47:34 am Brad Smith wrote:
> On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
> > On 2013/03/21 12:32, Taylan Ulrich B. wrote:
> > > Stuart Henderson writes:
> > >
> > > > As I said, "perhaps the uthread workarounds that we used to have
> > > > in the
On Thu, Mar 21, 2013 at 06:59:44PM -0500, Vladimir Támara Patiño wrote:
> Regarding the situtation with other languages, in
> /usr/src/share/locale/ctype/Makefile I find the following languages
> with countries pointing all of them to the same cmap definitions:
> * de_AT, de_CH and de_DE
Taking th
use %u for unsigned (ino_t).
Index: fsdb.c
===
RCS file: /cvs/src/sbin/fsdb/fsdb.c,v
retrieving revision 1.23
diff -u -p -r1.23 fsdb.c
--- fsdb.c 27 Oct 2009 23:59:33 - 1.23
+++ fsdb.c 22 Mar 2013 01:49:27 -
@@
On Thu, Mar 21, 2013 at 04:13:35PM +, Christian Weisgerber wrote:
> Lawrence Teo wrote:
>
> > The checksum flags listed in the mbuf(9) man page do not match the ones
> > in mbuf.h. In addition, the m_pkthdr.csum variable name should be
> > m_pkthdr.csum_flags.
> >
> > The following diff fix
Some ports in snapshot that include .po or .mo catalogs
different to es_ES are (just listing few without repetition):
davical es_AR es_MX es_VE
gnomebaker es_CO, es_CR
poedit es_PR
zarafa es_CA
The following packages have other localization files practically for
every spanish speaking countr
On 2013/03/21 21:54, Miod Vallat wrote:
> > - www/chromium - OSError: [Errno 8] Exec format error
>
> Please make the binary available to me offlist, as well as its linking
> command (or build log, whatever suits you).
Well this is very strange because if I run the program which generates
the err
On 2013/03/21 21:54, Miod Vallat wrote:
> > - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
>
> Hmm, that's odd. `environ' is a common and not declared as static or
> with any visibility attribute. Can you share the exact linking command
> which has triggered this error?
Build lo
> Date: Thu, 21 Mar 2013 21:54:02 +
> From: Miod Vallat
>
> > - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
>
> Hmm, that's odd. `environ' is a common and not declared as static or
> with any visibility attribute. Can you share the exact linking command
> which has trigger
> - local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
Hmm, that's odd. `environ' is a common and not declared as static or
with any visibility attribute. Can you share the exact linking command
which has triggered this error?
> - Error: suffix or operands invalid for `mov'
>
> these
So it seems the bulk of additional amd64 failures are looking like this:
/usr/bin/ld: MethodJIT.o: relocation R_X86_64_PC32 against
`JaegerTrampolineReturn' can not be used when making a shared object;
recompile with -fPIC
On 2013/03/21 10:52, Stuart Henderson wrote:
> i386 package build is sti
On Thu, Mar 21, 2013 at 11:03, Taylan Ulrich B. wrote:
> I'm a GNU Guile 2.0 user, whose latest versions require latest
> versions of the Boehm garbage collector. This uses the functions
> pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
> don't exist in rthreads.
Right. Ear
patch to change 1 to FD_CLOEXEC. previous diff was OK'd by millert, but
here is an updated version.
Index: bin/systrace/openbsd-syscalls.c
===
RCS file: /cvs/src/bin/systrace/openbsd-syscalls.c,v
retrieving revision 1.41
diff -u -p -
patch to just call open() with O_CLOEXEC
Index: lib/libutil/check_expire.c
===
RCS file: /cvs/src/lib/libutil/check_expire.c,v
retrieving revision 1.8
diff -u -p -r1.8 check_expire.c
--- lib/libutil/check_expire.c 20 Apr 2004 23:21:2
All AMD64 systems should be Y2K compliant, so we can kill this code from
clock.c on this arch.
The i386 version currently only functions if the first boot after
Jan 1, 2000 is actually in the year 2000. Obviously now that we are in
2013, it's much more useful to allow the user to map
1900-1969 ->
On Thu, Mar 21, 2013 at 06:00:09AM +, Miod Vallat wrote:
> > > Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan
> > > Code Translation Table'
> >
> > Yes, but that document just lists the codes that Windows translates to
> > internally when a USB keyboard is in use. I hav
On Thu, Mar 21, 2013 at 06:05:11AM +, Miod Vallat wrote:
> > Excellent. Try setting the default, though:
> >
> > # wsconsctl keyboard.repeat.deln.default=350
> > keyboard.repeat.deln.default -> 200
> >
> > In fact, if you check, whenever a user changes the normal value, the
> > default value
It seems there's an ITE 8728 chip on my motherboard, and, it's
showing some sensible information! :-)
ok?
it0 at isa0 port 0x2e/2: IT8728F rev 1, EC port 0x228
hw.sensors.it0.temp0=37.00 degC
hw.sensors.it0.temp1=34.00 degC
hw.sensors.it0.temp2=27.00 degC
hw.sensors.it0.fan0=2020 RPM
hw.sensors.
Lawrence Teo wrote:
> The checksum flags listed in the mbuf(9) man page do not match the ones
> in mbuf.h. In addition, the m_pkthdr.csum variable name should be
> m_pkthdr.csum_flags.
>
> The following diff fixes both issues.
>
> OK?
Okay, but while you're there, could you remove the "/IPv4"
On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
> On 2013/03/21 12:32, Taylan Ulrich B. wrote:
> > Stuart Henderson writes:
> >
> > > As I said, "perhaps the uthread workarounds that we used to have
> > > in the port got committed upstream and now need to be reverted?"
> > >
> >
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
> Stuart Henderson writes:
>
> > As I said, "perhaps the uthread workarounds that we used to have
> > in the port got committed upstream and now need to be reverted?"
> >
> > i.e. _used_ to have, before the change to rthreads.
>
> Oh sorry, I und
Stuart Henderson writes:
> As I said, "perhaps the uthread workarounds that we used to have
> in the port got committed upstream and now need to be reverted?"
>
> i.e. _used_ to have, before the change to rthreads.
Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem
equi
On 2013/03/21 11:51, Taylan Ulrich B. wrote:
> Stuart Henderson writes:
>
> > the current boehm-gc port works with rthreads, best way forward is
> > probably to update that to a newer version, maintaining the patches that
> > we have.
> >
> > perhaps the uthread workarounds that we used to have i
i386 package build is still running, but there are a few common
failure modes I've picked up (and at least ffmpeg and gstreamer
will have knocked out big chunks of the tree) so I think I'll
send this out now.
Mostly binutils-related but there may be other failures mixed in
(this is the first full
Stuart Henderson writes:
> the current boehm-gc port works with rthreads, best way forward is
> probably to update that to a newer version, maintaining the patches that
> we have.
>
> perhaps the uthread workarounds that we used to have in the port got
> committed upstream and now need to be reve
On 2013/03/21 11:03, Taylan Ulrich B. wrote:
> I'm a GNU Guile 2.0 user, whose latest versions require latest
> versions of the Boehm garbage collector. This uses the functions
> pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
> don't exist in rthreads.
the current boehm-gc
I'm a GNU Guile 2.0 user, whose latest versions require latest
versions of the Boehm garbage collector. This uses the functions
pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
don't exist in rthreads.
I've read that rthreads are just processes, albeit with a special flag
se
kern malloc rolls its own linked list code. for the sake of clarity
and to make future changes easier, i'd like to make it a simpleq.
it would be very nice if this could be tested on a few different kinds
of machines. it's not supposed to actually change anything, but that's
what testing is to ver
28 matches
Mail list logo
