Hello,
Svante Signell, on Sat 10 Dec 2016 20:52:20 +0100, wrote:
> On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote:
> > On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote:
> >
> > > OK! Then maybe the sbrk() feature should be flagged as not
> > > available in order
> > > not to
On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote:
> On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote:
>
> > OK! Then maybe the sbrk() feature should be flagged as not
> > available in order
> > not to fool configure and the compiler. In fact FreeBSD/arm64 did
> > exactly that,
On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote:
> I've read it, thanks! I think emacs is in a similar situation as Hurd with
> respect to the still missing mlockall/munlockall functions.
Except we're not fighting to keep the status quo. We will adapt and
implement these dependencie
On Thu, 2016-12-08 at 14:47 +0100, Richard Braun wrote:
> On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote:
> > Since a long time emacs FTBFS due to unknown reasons. The latest version
> > building was Debian 24.5+1-5, from 28 Nov 2015.
>
> As already mentioned, the real issue is in
On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote:
> Since a long time emacs FTBFS due to unknown reasons. The latest version
> building was Debian 24.5+1-5, from 28 Nov 2015.
As already mentioned, the real issue is in Emacs. See the relevant
LWN article [1] for details.
> Even befor
Hello bug-hurd ML,
Since a long time emacs FTBFS due to unknown reasons. The latest version
building was Debian 24.5+1-5, from 28 Nov 2015.
Even before successful builds were by pure luck. One suspicious issue is that
emacs use sbrk() for memory allocation, right? Notably sbrk() is not fool-proof
This is just a reminder, if someone accidently purged their inbox, so
unless someone speaks up, I'll take over gnumach-1-branch tomorrow,
apply some old patches, and apply any new patches that people send.
The same rules as for ams-branch will apply (anyone with commit access
is free to do what th
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Thomas, we can aruge all we want, for days and years. But the fact is
> that the only way to prove that you design actually works is to
> implement it. I can't disprove that it won't work, since that is
> theoretically impossible.
I'm not trying
Thomas, we can aruge all we want, for days and years. But the fact is
that the only way to prove that you design actually works is to
implement it. I can't disprove that it won't work, since that is
theoretically impossible.
___
Bug-hurd mailing list
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Just try solving the "where do I popup a dialog?" problem first, you'd
> have to write some kind of a windowing system and then force all
> programs to use it.
Not at all. The user context would provide a "ask the user a
question" call. The files
Alfred M. Szmidt wrote:
Just try solving the "where do I popup a dialog?" problem first, you'd
have to write some kind of a windowing system and then force all
programs to use it.
Translators need "just" to support several user-interaction systems. As
fallback, all translators must support consol
> I was surprised to see that you talk about code -- we are talking
> about change in Hurd design now.
He's just trying to provoke me in a good way to writing some code.
:)
I wish that I was infact doing just that, but what you suggest is just
not doable...
Just try solving the "wher
Ognyan Kulev <[EMAIL PROTECTED]> writes:
> I was surprised to see that you talk about code -- we are talking
> about change in Hurd design now.
He's just trying to provoke me in a good way to writing some code. :)
And if my advisor hears about it, she'll skin him alive. I'm supposed
to be wri
I was surprised to see that you talk about code -- we are talking
about change in Hurd design now.
One can talk all about designs, but they don't matter if they cannot
be implemented, or shown to be able to even work out.
___
Bug-hurd mailing lis
Alfred M. Szmidt wrote:
The reason that filesystems do not have user context is because I
was not sufficiently far-sighted at the time to realize the full
flexibility of the translator concept I had created.
No, it is because they can't have "user context", but feel free to
disprove me wit
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> It all sounds like a Lisp Machine... And even though I enjoyed your
> little story, it has zlich todo with filesystems and user
> interactions.
Sure it does. It's about why a filesystem needs to be able to prompt
the user, and why RPC should be p
Please, don't lecture me about the Hurd being perfect; it's not.
Trust me, I won't lecture you about that, but I might lecture your
about how unperfect it is.
A friend at the AI lab once gave the following dream as an example
of a well-functioning system:
It all sounds like a Lisp Machi
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> First, the question of installing packages and user interaction is
> probably one of the simpler questions to answer. User interaction at
> installation time is horrible from just any point of view -
> interface-wise, administration wise, etc.
No a
At 20 Mar 2005 14:35:15 -0800,
Thomas Bushnell BSG wrote:
> Thread moved over to bug-hurd since it's about design and not Debian
> GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg
> installation translator (one where you copy a .deb into a directory to
> install it into the system) canno
Ben Asselstine <[EMAIL PROTECTED]> writes:
> Let's take the simple example of a symlink translator noticing that
> the file it points to has gone away.
>
> A user would register for interaction with the symlink translator, to
> give it permission to bug you when it wanted to. Is this act of
> reg
On 20 Mar 2005 14:35:15 -0800, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> The reason that filesystems do not have user context is because I was
> not sufficiently far-sighted at the time to realize the full
> flexibility of the translator concept I had created. Now that we know
> more abo
Thread moved over to bug-hurd since it's about design and not Debian
GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg
installation translator (one where you copy a .deb into a directory to
install it into the system) cannot be easily written, because Debian
package installation scripts
22 matches
Mail list logo
