Re: [9fans] newwindow() vs. acme, potentially others.

Re: [9fans] newwindow() vs. acme, potentially others.

[rob pike, esq.]

Russ backed out my libventi change, because that directory is
in transition.

I grepped for newwindow and found one other instance, in page.
that's on sources now too.

May I ask why you were building everything, something I should
have done myself?  (Thanks!)

-rob

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

> May I ask why you were building everything, something I should
> have done myself?  (Thanks!)

No particular reason other than that I was bored and had made some
local changes that I wanted to make sure still compiled after the
various updates I saw come down on Friday.

Oh, but speaking of rebuilding everything....  Is there a reason ``mk
release'' in /sys/src doesn't do a ``mk nuke'' instead of a ``mk
clean'' at the end?  It leaves behind various library droppings in,
e.g., /sys/src/cmd/cc.  Also, is there a reason ``noweb'' isn't in the
``BUGGERED'' line in /sys/src/cmd/mkfile?

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

Actually, I'm an idiot.  I can answer my own question about mk nuke
versus mk clean; mk nuke removes $LIB, which is usually set to
/$objtype/lib/libwhatever.a.  That'd be bad.  At anyrate, maybe it'd be
good to change the clean target to remove *.a[$OS] in addition to the
usual things.  There're three or four different places where libraries
aren't cleaned.

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[Russ Cox]

i'm confused.  tell me which file doesn't exist?

i have all of them, but maybe i missed some
when building the package:

g% du -a /sys/src/cmd/noweb |grep mkfile
1	/sys/src/cmd/noweb/awk/mkfile
1	/sys/src/cmd/noweb/c/mkfile
1	/sys/src/cmd/noweb/mkfile
1	/sys/src/cmd/noweb/rc/mkfile
1	/sys/src/cmd/noweb/tex/mkfile
g%

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

Huh.  I'll have to go look again (tomorrow, I suppose), but I didn't
see noweb/mkfile.  Err, rather, mk didn't.  Maybe I'm mistaken.  I'll
check tomorrow and get back to you...are the mkfiles on the iso on
sources?

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

> Huh.  I'll have to go look again (tomorrow, I suppose), but I didn't
> see noweb/mkfile.  Err, rather, mk didn't.  Maybe I'm mistaken.  I'll
> check tomorrow and get back to you...are the mkfiles on the iso on
> sources?

*sigh*.  The combination of not looking closely enough at the problem,
and not having my laptop with  me last night contributed to me saying
this drivel.  Okay, I'm not going to beat myself up too much, though.
There is a problem with the mkfile in noweb/rc: it doesn't understand
now to nuke itself.  I suppose adding a ``nuke:V:       clean'' to it
would fix the problem.

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[Russ Cox]

> ``BUGGERED'' line in /sys/src/cmd/mkfile?

noweb isn't BUGGERED because it's not in the
distribution.  you must have installed it separately.
anyhow, what's buggered about it?  looks to me like
it builds fine.  BUGGERED usually means it doesn't
build cleanly on all platforms (like perl and mosml
only work on the x86, for example).

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

> > ``BUGGERED'' line in /sys/src/cmd/mkfile?
>
> noweb isn't BUGGERED because it's not in the
> distribution.  you must have installed it separately.
> anyhow, what's buggered about it?  looks to me like
> it builds fine.  BUGGERED usually means it doesn't
> build cleanly on all platforms (like perl and mosml
> only work on the x86, for example).

It's buggered because there's no mkfile for it; which messes up mk's in
/sys/src/cmd.  I did install it seperately, but asked because I thought
the precedence had been set by the inclusion of perl and mosml, neither
of which are in the distribtion, in NOTSYS and BUGGERED (or wherever
they live; I'm afraid I'm not in front of my terminal at the moment).

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[rob pike, esq.]

Both were caused by a huge sweep I made the other day
through the mkfiles, trying to make a consistent set
of update rules.  I pushed out the library mkfiles
before realizing there was no reason to.  Libstdio
had a glitch; the problem with libventi was that I
pushed only the mkfile and not the entire directory.
I believe both should be fixed on sources now.

-rob

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

Cool.  Thanks.

	- Dan C.

Re: [9fans] newwindow() vs. acme, potentially others.

[Russ Cox]

Rob fixed this yesterday.  Update from sources.

Re: [9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

Okay.  btw- I last did a pull from sources at about 7pm yesterday.  Did
he (or anyone else) also fix the problems with the mkfiles in
/sys/src/libstdio and /sys/src/libventi?  In the case of the former,
OFILES has an entry for ``.$O'' (no stem), and for the latter, a
non-existent pack.c threw it off when trying to build pack.$O.

	- Dan C.

[9fans] newwindow() vs. acme, potentially others.

[Dan Cross]

Rebuilding acme failed for me today due to a protocol mismatch with
newwindow(), which is new.  I was literally running out the door at the
time, and couldn't stop to dig deeper, but I'm guessing that acme has a
``newwindow()'' function it uses internally that conflicts with the new
function Rob added to libdraw.  I suppose the best solution is to
rename one or the other.  I could imagine other commands having similar
problems.

	- Dan C.