>>> "tl" == "Terry Lambert" wrote:
tl> FWIW: tail-call optimization is when I have a function
tl> that, as it's last thing (perhaps after reordering by
tl> the compiler, as well) calls another function, such
tl> that the return value of the other function is its
tl> return value.
See also:
D
Kenneth D. Merry ([EMAIL PROTECTED]) wrote:
> diff2 output, on the other hand, won't run through patch properly. You
> have to run it through a fixup script to get it right.
p4 diff -u -b branch
That works just fine.
--
Paul Saab
Technical Yahoo
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL
On Mon, Aug 06, 2001 at 21:39:11 -0700, Arun Sharma wrote:
> On 7 Aug 2001 05:07:13 +0200, Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > > At this stage diffs must be pushing close to 1MB (maybe more)
> > > (I don't know as I don't know yet how to get p4 to generate diffs :-)
> >
> > Isn't it jus
On 7 Aug 2001 05:07:13 +0200, Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > At this stage diffs must be pushing close to 1MB (maybe more)
> > (I don't know as I don't know yet how to get p4 to generate diffs :-)
>
> Isn't it just `p4 diff` ?
The diff produced by the above command is not accepted
On Mon, 6 Aug 2001, Julian Elischer wrote:
> I have pushed the thread pointers down through most of the code
> though there are still many many places that assume that there is only one
> thread per process. (no multithreading yet, but getting closer..)
Keep up the good progress :-)
> At this st
I have pushed the thread pointers down through most of the code
though there are still many many places that assume that there is only one
thread per process. (no multithreading yet, but getting closer..)
At this stage diffs must be pushing close to 1MB (maybe more)
(I don't know as I don't know
Mike Smith schrieb:
>
> > > Ok. I'm going to revert to the "safe" read code in a few minutes.
> > >
> > > Can you update and let me know if you're still wildly off? I'm having a
> > > hard time believing that your timer is really running at double pace, but
> > > I guess anything is possible.
On Wed, 01 Aug 2001 10:37:26 MST, Dima Dorfman wrote:
> > I'm in favour of the current behaviour but I _still_ think you should
> > commit my patches that add a "mount /tmp in mfs" option to rc.conf.
>
> I don't know where you got the idea that I thought your rc.conf knob
> was a bad idea.
I'
On 05-Aug-01 Mike Smith wrote:
>> Usually with APM enabled I just press The Fn+F1 key combination
>> to initiate suspend to disk, but this same key sequence doesn't
>> do a thing when under ACPI. Is this supposed to work yet?
>
> Under ACPI, the OS initiates sleep, not the BIOS, so the keyboard
On Mon, Aug 06, 2001 at 12:32:49PM +0100, Mark Murray wrote:
> > For quite a while now (?3-4 months?) one's terminal settings are messed
> > up when rlogin'ing into a FreeBSD from a FreeBSD-current one. It used to
> > be I could rlogin from an 80x24 Xterm, and the terminal settings on the
> > rem
¾È³çÇϼ¼¿ä ÇÁ·£
> For quite a while now (?3-4 months?) one's terminal settings are messed
> up when rlogin'ing into a FreeBSD from a FreeBSD-current one. It used to
> be I could rlogin from an 80x24 Xterm, and the terminal settings on the
> remote box would also be 80x24. Now COLUMNS=80 and ROWS and TERMCAP
> i
> Does anyone know what changed?
> (someone has suggested the change came about when PAM's session model was
> changed)
Following up on my previous message; I've asked re@ for permission
to MFC the fix.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROT
13 matches
Mail list logo
