ge in
some applications.
Instead of a linked list, how about using a dynamic array?
https://en.wikipedia.org/wiki/Dynamic_array
This would give you constant-time lookups, amortized constant time
insertions and deletions, and better data locality and cache behavior.
What do you think?
Mark
On 28/06/17 08:38, Mark Morgan Lloyd wrote:
This looks like the snapshot from january. There's the 2017 release
from may on
http://www.debian.org/ports/hurd/hurd-cd
Page fault trap, either shortly after selecting the mirror or shortly
after tasksel (with nothing non-standard sel
Initially bounced at GNU servers, re-sent.
On 27/06/17 14:23, Samuel Thibault wrote:
> Mark Morgan Lloyd, on mar. 27 juin 2017 08:06:59 +, wrote:
>> The CD image I was using was
>>
>> $ cksum *iso
>> 4089521537 678834176 cd
On 27/06/17 14:23, Samuel Thibault wrote:
Mark Morgan Lloyd, on mar. 27 juin 2017 08:06:59 +, wrote:
The CD image I was using was
$ cksum *iso
4089521537 678834176 cd-1.iso
$ sha1sum *iso
9239135037b664a08d355e2f7ece69bfa7576f07 cd-1.iso
This looks like the snapshot from january
, or should I be
reverting to the somewhat older image described at
https://www.gnu.org/software/hurd/index.html ?
CC not necessary, I'm subscribed.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
;) is basically SMP with SSI, but that a
sysplex has multiple OS instances with jobs moved around as required.
It's perhaps interesting that Moshe Bar, who was originally responsible
for MOSIX, is occasionally seen hanging out in IBM mainframe mailing lists.
CC not necessary, I&#x
ility situation? Way back I worked on a
microkernel in '386 protected mode that used segmentation heavily, am I
correct in assuming that that sort of thing is completely deprecated in
the interest of portability?
When I were a lad we used logic analysers to debug our code...
--
Mark Morgan Ll
gdb locally on there.
But it'd be difficult to have access to all the advanced features a
native GNU/Hurd GDB offers.
Mark
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
do business with you.
Mark
Server Dept
[EMAIL PROTECTED]
***
No.Thank: [EMAIL PROTECTED]@gnu.org
Title: jyh petalid
Внимание!
С 8 по 25 октября проводится акция «Оплачиваете за
два уровня единовременно – третий изучаете
бесплатно!»
N Y L C
Вот несколько причин, по
которым Вы будете рады выбрать NYLC:
1.Обуч.аю.щие прог.раммы
–ES..L(En.g.lish as a sec.ond lang.uage)
2.Ми.ни гру.ппы,
wer specific questions is less so. Clearly you don't want them to
spend their time writing doc instead of writing code but a little doc is
a wonderful thing.
Thanks
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Offer valid untill 12 July, FREE everyone 490$,
who had quest four matching digits, for old and new customers.
This action from our company.
We could send you checks, e-gold, wire transfer.
More info here:
http://www.aberbid.com/
___
Bug-hurd mailing l
Please be aware that the Mach LDT code still contains serious bugs.
Setting the segment registers to something else than thier defaults is
very likely to crash the kernel. I've tried to hunt down the bug, but
didn't succeed.
Mark
__
From: Roland McGrath <[EMAIL PROTECTED]>
Date: Thu, 25 Oct 2001 02:31:19 -0400 (EDT)
> (gdb) attach 743
> Attaching to program `/usr/bin/tail', pid 743
> ^C^C
Hmm. That might be gdb trying to talk to the signal thread.
Definitely.
But there is no excuse for C-c not worki
couple days but I was interested if knew where I could get one
earlier?
I removed the link to my OSF MiG package from my homepage a while ago,
but you can still find it at:
http://www.science.uva.nl/~kettenis/osfmk
Enjoy,
Mark
___
Bug-hurd m
The link for the remote debugging boot option (oskit-boot.txt)
under Booting OSKit-Mach is broken. I would propose the following
patch to correct this link to a live location:
--- oskit-mach.texi.origTue Oct 9 11:15:14 2001
+++ oskit-mach.texi Tue Oct 9 11:16:08 2001
@@ -344,7 +34
Could it be a compiler optimization issue, where the empty loop is
simply optimized away, and therefore never executed??
(I have seen stranger things come out of optimized code)
On Wed, 26 Sep 2001 19:20:22 +0200, Marcus Brinkmann wrote:
>On Wed, Sep 26, 2001 at 05:15:32PM +0200, Piotr Kr
he
application to manage stack overflow along with stack allocation
and management in this case.
Changebars in the draft indicate that this is a recent addition. See
http://www.opengroup.org/austin on how to get the current POSIX draft.
Mark
___
is* a bug in GCC. Please report it to the GCC folks. See
http://gcc.gnu.org/bugs.html for more information on reporting bugs in
GCC.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Date: Fri, 29 Jun 2001 15:49:01 -0500
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Hi,
io/fts.c has a MAXPATHLEN issue.
The Debian glibc build of 2.2.3-6 (CVS 6-9-2001) fails because
of that.
I don't see any problems with the current CVS version. Yes, it uses
MAXPATHLEN, but on
From: [EMAIL PROTECTED] (Thomas Bushnell, BSG)
Date: 29 Jun 2001 10:55:51 -0700
Mark Kettenis <[EMAIL PROTECTED]> writes:
> The way the ext2fs and ufs file system calculate the number of
> available blocks can yield a negative number. Since fsblkcont_t is an
>
Hey Marcus, it works really great. No real problems thus far. Even
ftpfs seems to work reasonably well.
Thanks!
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
The way the ext2fs and ufs file system calculate the number of
available blocks can yield a negative number. Since fsblkcont_t is an
unsigned type this causes some interesting output from df, when your
filesystem is clogging up.
Roland, OK to check thus in?
Mark
Index: ext2fs/ChangeLog
from
Date: Sun, 27 May 2001 18:36:52 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
On Thu, May 24, 2001 at 05:17:08PM +0200, Mark Kettenis wrote:
> I can't reproduce Marcus' problems with a freshly checked out glibc.
> Everything appears to work fine for me.
I can't reproduce Marcus' problems with a freshly checked out glibc.
Everything appears to work fine for me.
Oh, and invoking ld.so on a statically linked executable isn't
supposed to work I think. Produces a segmentation fault on Linux and
Solaris, so I think the current Hurd hebaviour is quite
he argument/environment vector munging that we do at
various stages. And those things are done differently if a program is
started directly by Mach or serverboot or via the exec server.
The dates Marcus mentions make the following change a bit suspect:
2001-03-24 Mark Kettenis <[EMAIL PROTECTED
r to attract the attention of the release manager.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
dl_addr() it looks at
_dl_argv[0], which points somewhere in the deallocated stack which
results in your SIGBUS.
Unfortunately, I'm not sure how to fix this yet.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
might get lost. Entering them into the Debian BTS
should be enough to avoid that. And now we also have savannah.gnu.org
(the GNU sourceforge site) where you can enter bug reports for the
Hurd.
Whatever you do, please let us know about these problems and patches,
no m
such that this wouldn't work.
At that time Roland suggested that we'd simply add the necessary *64
functions to libc (emulating them with the 32-bit interfaces), but I
only did those that were necessary to support libio. I'll have a go
at it now.
Mark
__
From: Farid Hajji <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2000 13:03:39 +0100
Hi,
cross-compiling glibc (new cvs snapshot) breaks with the following
error message (while making $(GLIBC_BUILDDIR)/elf/dl-sysdep.os):
I already fixed this :-).
us what is going wrong.
Mark, can you commit this or a patch with a similar effect?
Thanks Marcus, I checked it in.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
ust finds the wrong libc so that's
the wrong way to check.
Indeed. ldd is useless in cross-compiling situations, since it is
invoking the Linux ld.so on a Hurd binary.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailma
Enabling the
timeouts isn't too difficult, but when I did so somewhere in the past,
I encountered some bugs. One of them an off-by-one problem that
terminated the last thread listening for requests. Sorry, I don't
have the details right now. Could look them up
ing should work fine :-).
By the way, I don't thing V_GETPARMS is supported by oskit-mach.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
nfigure tests"), and the code is correct in any way.[1]
I have no problem with that. We should not claim to conform to things we
don'te rally conform to.
FYI, I checked in the following change:
2000-09-18 Mark Kettenis <[EMAIL PROTECTED]>
* sysdeps/mach/hurd/bits
's progress :-). Don't hesitate to ask any
questions. Make sure you provide parallel implementations for the
things in sysdeps/mach/hurd/i386. dl-machine.h is particularly
relevant to the dynamic linker.
Mark
gram
interpreter, but it also is a shared library.
Anyway, either something went wrong with your build (nm and objdump
might be handy to find out what's wrong), or your cross compiler is
screwed somehow (passing -v to gcc can be of assistence here).
Mark
so). It
looks as if the build process is using the old ld.so instead of the
new one.
Mark
Date: Sun, 30 Jul 2000 17:31:11 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
On Sat, Jul 29, 2000 at 07:05:27PM +0200, Mark Kettenis wrote:
> You'll probably need to provide alternatives for more (all) of the
> functions in oskit-0.97.2505/dev/x86/synch.c
he previous pageouts have not yet completed when a
new one arrives). Some time ago Thomas made some changes to the
paging code in the kernel with the idea to avoid this scenario, but
apparently it doesn't help enough in your case.
Mark
You'll probably need to provide alternatives for more (all) of the
functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach
synch.c.
Mark
Date: Sat, 29 Jul 2000 00:03:06 -0700 (PDT)
From: Paul Eggert <[EMAIL PROTECTED]>
From: Mark Kettenis <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2000 01:22:03 +0200
Date: Sat, 29 Jul 2000 00:27:09 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]
bug in fileutils?
No, it's a bug in autoconf. We don't advertise that we support large
files on the Hurd. If we did, we would set one of more of the
following macros to 1 in :
_LFS_LARGEFILE
_LFS64_LARGEFILE
_LFS64_ASYNCHRONOUS_IO
_LFS64_STDIO
I think autoconf should at least check for _LFS_LARGEFILE.
Mark
n autoconf. We don't advertise that we support large
files on the Hurd. If we did, we would set one of more of the
following macros to 1 in :
_LFS_LARGEFILE
_LFS64_LARGEFILE
_LFS64_ASYNCHRONOUS_IO
_LFS64_STDIO
I think autoconf should at least check for _LFS_LARGEFILE.
Mark
proc server. It was losing point
rights when sending signals to a program. You could use GDB on the
proc server to see if you can spot any cases where the number of port
references is obviously wrong. The `set noninvasive on' and `info
port' commands might be useful.
Mark
his way, but backtraces should work fine, and you can print
variables (and watch them change underneath you).
Mark
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: 14 Jul 2000 23:23:31 +0300
Mark Kettenis <[EMAIL PROTECTED]> writes:
>Date: Thu, 13 Jul 2000 19:27:55 -0400
>From: Olivier Galibert <[EMAIL PROTECTED]>
>
>settrans -c
.
Anyway, I agree with Marcus that it's useful to have this feature, and
it's probably how Thomas designed it.
Mark
oncrete questions, don't hesitate to ask. I'd love
to see the Hurd running alongside with Mac OS X :-).
Mark
Date: Fri, 19 May 2000 19:03:38 -0400 (EDT)
From: Roland McGrath <[EMAIL PROTECTED]>
Yeah, on later thought I liked your idea fine.
Here's a patch. OK to check this in?
2000-05-20 Mark Kettenis <[EMAIL PROTECTED]>
* configure.in: Add check for li
HO the simplest and most robust way to solve the problem.
Mark
y real hacking or even much code-reading these
days (it will be probably at least several more weeks before I can), and I
don't recall the full details of all this off hand. I don't think there
should be a problem like this, but I don't have enough information on hand
but I don't have enough information on hand
right now to be of much more help. Mark understands the details too and
might be able to help before I can.
I'll look into it the coming week.
Mark
at the argument above
doesn't have to apply. That's probably why the manual mentions those
restrictions.
However, for the Hurd servers themselves, it is not too bad to make
some additional assumptions about implementation details if that is
convenient or improves performance.
Mark
Date: Tue, 9 May 2000 22:55:21 +0500 (GMT-5)
From: Sergey Izvoztchikov <[EMAIL PROTECTED]>
On Wed, 10 May 2000, Mark Kettenis wrote:
> Indeed. I don't really have experience with CORBA, but I don't think
> the issues in this thread are relevant
hat
retroactively change the rules (like added new reserved words) are
just not worth supporting.
Mark
Just don't expect any
of the core Hurd developers to take part in it. That might be a good
reason to take it off the bug-hurd mailing list.
Mark
really, but maybe you could get some idea's from looking at Linux
or one of the BSD's.
Mark
g_post_request.
Check mach_msg return value for sanity assert.
(send_signal): Make MESSAGE auto instead of static, use new type name.
This problem tracked down by Mark Kettenis <[EMAIL PROTECTED]>.
Mark
Date: Sat, 26 Feb 2000 03:22:21 -0500
From: Roland McGrath <[EMAIL PROTECTED]>
That looks fine, though you should match `*-*-gnu*' for the configuration.
Mark Kettenis is in charge of gdb for hurd and will take care of getting
the fix put into gdb.
It is probably ea
61 matches
Mail list logo
