[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > I'd *really* want to see a flag to mmap that means "If the file
> > shrinks, just map in some zero pages instead. Don't ever SEGFAULT me
> > about it".
>
> You could just set up a preemptor to catch these type of faults. This
> is what the file s
> I'd *really* want to see a flag to mmap that means "If the file
> shrinks, just map in some zero pages instead. Don't ever SEGFAULT me
> about it".
You could just set up a preemptor to catch these type of faults. This
is what the file system's do. Take a look at .
___
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> This is a bit related to changing the size of the file, which we probably
> should never do if the client mmap's it.
I'd *really* want to see a flag to mmap that means "If the file
shrinks, just map in some zero pages instead. Don't ever SEGFAULT me
At Wed, 5 Jun 2002 05:38:38 -0400 (EDT),
Roland McGrath wrote:
> I was (and am still sort of) unclear on UTF-32 vs UCS-4.
Their formats are identical but their semantics is different, because
UCS-4 is defined in ISO/IEC 10646, while UTF-32 is defined in Unicode
Standard.
Basically ISO/IEC 10646
On Wed, Jun 05, 2002 at 05:38:38AM -0400, Roland McGrath wrote:
> > Or from UCS-4 to the internal format of the console client, whatever it is.
> > Rolands hint for UTF-32LE etc was very helpful.
>
> I was (and am still sort of) unclear on UTF-32 vs UCS-4. There is also
> UCS4-LE and UCS-4BE, wh
On Wed, Jun 05, 2002 at 10:03:27AM +0200, Niels Möller wrote:
> > It just seems like the interface is wrongheaded if it winds up doing byte
> > order conversions back and forth on the same machine.
>
> I suspect that the conversions are actually not between UCS-4 little
> endian and UCS-4 big end
> Mmh, I thought it would work over sockets, and would involve some sort of
> communication protocol over that. After all, you can do multi-attach etc.
> But I never looked into it, so I really don't know.
I'm just guessing too. But I think its socket communications are just
"here attach to thi
> Or from UCS-4 to the internal format of the console client, whatever it is.
> Rolands hint for UTF-32LE etc was very helpful.
I was (and am still sort of) unclear on UTF-32 vs UCS-4. There is also
UCS4-LE and UCS-4BE, which is all but identical to the internal form (all
the converter does is c
On Tue, Jun 04, 2002 at 11:55:35PM -0400, Roland McGrath wrote:
> > It actually makes for a runnable program that does something visibly useful.
>
> That's fantastic! (And well beyond the norm for new Hurd features. ;-)
That's just because I have a running Hurd system to go along with :)
> It
Roland McGrath <[EMAIL PROTECTED]> writes:
> It just seems like the interface is wrongheaded if it winds up doing byte
> order conversions back and forth on the same machine.
I suspect that the conversions are actually not between UCS-4 little
endian and UCS-4 big endian, but between UCS-4 (some
> It actually makes for a runnable program that does something visibly useful.
That's fantastic! (And well beyond the norm for new Hurd features. ;-)
> 2. The whole display interface issue, including asynchronous notifications.
> I have some ideas for this obviously. Maybe the first versions
Hi,
I checked in my new console server code. It is buggy like hell, but it has
one big advantage over the older code: It actually makes for a runnable
program that does something visibly useful.
I hope that this allows for a more incremental and hopefully more
collaborative console server. Ev
12 matches
Mail list logo
