s/line/list/
NIL is what you test against to determin if you have reached
the end of a list. the empty list is just a NIL ( hand wave over all
the car and cdr reality in favor of a simpler albeit not-correct
description of how it works.)
jmb
>
> In message <[EMAIL PROTECTED
On Thu, 27 Jan 2000, Oliver Fromme wrote:
> Warner Losh <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
> > In message <[EMAIL PROTECTED]> "Jonathan M. Bresler"
>writes:
> > : The terminology is very simple. Anyone that can cope with
> > : either vi or emacs can learn:
> > :
> > : NU
Warner Losh <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
> In message <[EMAIL PROTECTED]> "Jonathan M. Bresler" writes:
> :The terminology is very simple. Anyone that can cope with
> : either vi or emacs can learn:
> :
> :NUL: an ascii character (0x00)
> :NIL: a pointer a
In message <[EMAIL PROTECTED]> "Jonathan M. Bresler" writes:
: The terminology is very simple. Anyone that can cope with
: either vi or emacs can learn:
:
: NUL: an ascii character (0x00)
: NIL: a pointer at the end of the line
: NULL pointer: used in C to refer to NIL.
:
>
Matt Dillon wrote:
>
> :> Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary.
> :>
Jonathan Bresler wrote:
> :
> : NIL or nil, is the nil pointer from lisp. lisp is often the
> :first time many people start to understans that data can drive
> :programs. this
:> Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary.
:>
:
: NIL or nil, is the nil pointer from lisp. lisp is often the
:first time many people start to understans that data can drive
:programs. this is a good thing.
:
:jmb
I don't know anybody under the
>
> Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary.
>
NIL or nil, is the nil pointer from lisp. lisp is often the
first time many people start to understans that data can drive
programs. this is a good thing.
jmb
To Unsubscribe: send mail to [EMAIL PRO
On Mon, 24 Jan 2000, Matthew Dillon wrote:
> :
> :The "maximum interval to wait for the selection to complete" isn't
> :really the maximum, but more like the lower bounds of the time to
> :wait for the selection.
> :
> :Dan Eischen
> :[EMAIL PROTECTED]
>
> It's definitely a maximum, because s
:
:The "maximum interval to wait for the selection to complete" isn't
:really the maximum, but more like the lower bounds of the time to
:wait for the selection.
:
:Dan Eischen
:[EMAIL PROTECTED]
It's definitely a maximum, because select() can return much sooner if
one of the I/O events b
On Mon, 24 Jan 2000, Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [000124 12:59] wrote:
> >
> > :The manpage has been updated in -current:
> > :
> > : If timeout is a non-nil pointer, it specifies the maximum interval to
> > : wait for the selection to complete. System
:> :
:> :-Alfred
:>
:> 'nil' ? 'nil' is the designation for an ascii 0, not a pointer.
:> Please use 'null' or 'NULL' -- for example, look at the gettimeofday
:> man page. 'nil' has nothing to do with pointers.
:
:More correctly, 'nul' or 'NUL' are ASCII character 0. 'nil' is a pa
Matthew Dillon wrote:
>
> :The manpage has been updated in -current:
> :
> : If timeout is a non-nil pointer, it specifies the maximum interval to
> : wait for the selection to complete. System activity can lengthen the in-
> : terval by an indeterminate amount.
> :
> : If timeou
Mikhail Teterin wrote:
>
> David Schwartz once wrote:
>
> > The man page is correct and the implementation is correct.
>
> Several people, said the man pages are broken:
>
> [...]
>
> This is becoming ridiculous. Somehow, I get a feeling a bunch of people
> manage to agree with eac
* Matthew Dillon <[EMAIL PROTECTED]> [000124 12:59] wrote:
>
> :The manpage has been updated in -current:
> :
> : If timeout is a non-nil pointer, it specifies the maximum interval to
> : wait for the selection to complete. System activity can lengthen the in-
> : terval by an indete
:The manpage has been updated in -current:
:
: If timeout is a non-nil pointer, it specifies the maximum interval to
: wait for the selection to complete. System activity can lengthen the in-
: terval by an indeterminate amount.
:
: If timeout is a nil pointer, the select blocks
* Mikhail Teterin <[EMAIL PROTECTED]> [000124 12:35] wrote:
> David Schwartz once wrote:
>
> > The man page is correct and the implementation is correct.
>
> Several people, said the man pages are broken:
>
> Bruce Evans on Dec 28:
> > If timeout is a non-nil pointer
> =The man pages say exactly:
> = If timeout is a non-nil pointer, it specifies a maximum interval
> = to wait for the selection to complete.
> =Which doesn't say that it will sleep no more than this. It says that it
> =will wait no longer than this for the selection to complete. It do
David Schwartz once wrote:
> The man page is correct and the implementation is correct.
Several people, said the man pages are broken:
Bruce Evans on Dec 28:
> If timeout is a non-nil pointer, it specifies
> a maximum interval to wait for the selection
In message <01bf669f$94c4ec70$[EMAIL PROTECTED]> "David Schwartz" writes:
: The term "maximum" refers to the fact that she can stop waiting earlier if
: the package arrives. It doesn't mean she can't wait more than 4 hours.
Exactly. She's not letting you down by waiting 5 hours before giving
On Sun, 23 Jan 2000, Warner Losh wrote:
> : This is what I asked for, when I asked for "other specification". Could
> : you provide the chapter/verse number of where POSIX spec contradicts the
> : man pages? It will help me make my case on the TCL forum, since the TCL
> : developers remain un
: This is what I asked for, when I asked for "other specification". Could
: you provide the chapter/verse number of where POSIX spec contradicts the
: man pages? It will help me make my case on the TCL forum, since the TCL
: developers remain under the mistaken assumption, that select() ma
In message <[EMAIL PROTECTED]> Mikhail Teterin writes:
: Where does it guarantee that? Man-pages say, it is guaranteed to sleep
: no MORE then the timeout, not less. Is there some other specification,
: that's different from the man-pages, or are you talking from the
: implementation p
Warner Losh once stated:
=In message <[EMAIL PROTECTED]> Mikhail Teterin writes:
=: Where does it guarantee that? Man-pages say, it is guaranteed to
=: sleep no MORE then the timeout, not less. Is there some other
=: specification, that's different from the man-pages, or are y
Warner Losh once stated:
=In message <[EMAIL PROTECTED]> Mikhail Teterin writes:
=: I understand. And this will also happen in case of a simple printf().
=: What I see, however, with select() is that it _consistently_ takes
=: 9-10 msecs longer then specified to return. On an idle machine.
In message <[EMAIL PROTECTED]> Mikhail Teterin writes:
: I understand. And this will also happen in case of a simple printf().
: What I see, however, with select() is that it _consistently_ takes 9-10
: msecs longer then specified to return. On an idle machine... Someone
: mentioned, that
> I understand. And this will also happen in case of a simple printf().
> What I see, however, with select() is that it _consistently_ takes 9-10
> msecs longer then specified to return. On an idle machine... Someone
> mentioned, that the number of ticks is, actually, rounded up. Perhaps
Dan Nelson once stated:
=In the last episode (Jan 23), Mikhail Teterin said:
=> =FreeBSD is clearly not capable of hard real-time. If I remember
=> =correctly, neither are any of the operating systems from which you
=> =quoted man pages. That makes *all* of those man pages inaccurate.
=>
In the last episode (Jan 23), Mikhail Teterin said:
> =FreeBSD is clearly not capable of hard real-time. If I
> =remember correctly, neither are any of the operating systems from
> =which you quoted man pages. That makes *all* of those man pages
> =inaccurate.
>
> In other words, we found
* Mikhail Teterin <[EMAIL PROTECTED]> [000123 17:51] wrote:
> Jason Evans once stated:
>
> =I thought Bruce was pretty clear when he explained that such upper
> =bounds are not possible unless the operating system can make hard
> =real-time guarantees.
>
> His explanation contradict
Jason Evans once stated:
=I thought Bruce was pretty clear when he explained that such upper
=bounds are not possible unless the operating system can make hard
=real-time guarantees.
His explanation contradicted ALL of the documentation I was able to
find, and he chose not to co
On Sun, Jan 23, 2000 at 11:36:08AM -0500, Mikhail Teterin wrote:
> David Schwartz once stated:
>
> => =FreeBSD:
> => ==> => If timeout is a non-nil pointer, it specifies a maximum
> => ==> => interval to wait for the selection to complete.
>
> = While the pthreads case is clearly a bug,
31 matches
Mail list logo
