Re: [9fans] mk time-check/slice issue

Re: [9fans] mk time-check/slice issue

[Jason Catena]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

In part to substitute issues with time with issues with checksums, I am
writing a build tool for Inferno loosely inspired by djb's redo.  I think
it deals nicely with some of the problems of make/mk tools: it handles
multiple outputs, treats shell variables as /env files for dependencies,
and uses the Inferno shell calling small programs, instead of a
domain-specific shell-like language in a build description file.

https://github.com/catenate/credo

[-- Attachment #2: Type: text/html, Size: 550 bytes --]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> In part to substitute issues with time with issues with checksums, I am
> writing a build tool for Inferno loosely inspired by djb's redo.  I think
> it deals nicely with some of the problems of make/mk tools: it handles
> multiple outputs, treats shell variables as /env files for dependencies,
> and uses the Inferno shell calling small programs, instead of a
> domain-specific shell-like language in a build description file.
>
> https://github.com/catenate/credo

imho, mk could be greatly improved if it had a rule flag that would allow it
to compile many c files with a single compiler invocation.

- erik

[9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

Greetings,

I apologize for beating the heck out of the group.  I admit that some of my
questions are premature.  I appreciate everyones help.

I have a better handle on what is going on, and with that knowledge, I was
able to restructure the mkfile to work correctly in parallel.  I am
encountering a new problem, however.

Mk (and make) look at file times to determine what needs to be built.
 Cool.  When I type "mk" my app builds just fine.  The problem is that if I
type "mk" again, it (at least) partially builds again.  If I keep doing
this, eventually it says my target is up-to-date.

What I think is going on is that this little test app builds so fast that
the file write times look like they are the same time.  For example if I
build main.c and then do:

    ls -lrt

I should see them listed in this order:

    main.c
    main.8
    main

but sometimes I see them like this:


    main.c
    main
    main.8

I think this is caused because the time slice is too short and the system
can't tell the build times apart.  Even though main clearly came after main.8
the system sees them as the same time.  Of course this can cause mk to
dothe link again unnecessarily if
mk is called again.  This is what is happening to me.  Each time I mk it
builds less.

Perhaps this is a problem with 9port under VMware.  Perhaps, in certain
environments, the time slices are too big.

Any experience or thoughts on the matter are greatly appreciated.


Blake

[-- Attachment #2: Type: text/html, Size: 3863 bytes --]

Re: [9fans] mk time-check/slice issue

[Matthew Veety]

> On Dec 18, 2013, at 17:01, Blake McBride <blake@mcbride.name> wrote:
> 
> I apologize for beating the heck out of the group.  I admit that some of my questions are premature.  I appreciate everyones help.
> 

Don't worry about asking questions ever, man. It's good to see, seeing people willing to ask questions is rare nowadays and shows that you have true sack.

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Thanks for the encouragement.  I'll move into other areas soon.  I'll try
to do as much research as possible before posting.


On Wed, Dec 18, 2013 at 4:08 PM, Matthew Veety <mveety@gmail.com> wrote:

>
>
> > On Dec 18, 2013, at 17:01, Blake McBride <blake@mcbride.name> wrote:
> >
> > I apologize for beating the heck out of the group.  I admit that some of
> my questions are premature.  I appreciate everyones help.
> >
>
> Don't worry about asking questions ever, man. It's good to see, seeing
> people willing to ask questions is rare nowadays and shows that you have
> true sack.
>

[-- Attachment #2: Type: text/html, Size: 999 bytes --]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> I think this is caused because the time slice is too short and the system
> can't tell the build times apart.  Even though main clearly came after main.8
> the system sees them as the same time.  Of course this can cause mk to
> dothe link again unnecessarily if
> mk is called again.  This is what is happening to me.  Each time I mk it
> builds less.
>
> Perhaps this is a problem with 9port under VMware.  Perhaps, in certain
> environments, the time slices are too big.
>
> Any experience or thoughts on the matter are greatly appreciated.

you are correct.  this is all about time resolution.  plan 9
times are recorded in 1s resolution, and unless you have a very slow
processor, or a very big program, building & linking a program can take
less than 1s.

- erik

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On Wed, Dec 18, 2013 at 4:16 PM, erik quanstrom <quanstro@labs.coraid.com>wrote:

> > I think this is caused because the time slice is too short and the system
> > can't tell the build times apart.  Even though main clearly came after
> main.8
> > the system sees them as the same time.  Of course this can cause mk to
> > dothe link again unnecessarily if
> > mk is called again.  This is what is happening to me.  Each time I mk it
> > builds less.
> >
> > Perhaps this is a problem with 9port under VMware.  Perhaps, in certain
> > environments, the time slices are too big.
> >
> > Any experience or thoughts on the matter are greatly appreciated.
>
> you are correct.  this is all about time resolution.  plan 9
> times are recorded in 1s resolution, and unless you have a very slow
> processor, or a very big program, building & linking a program can take
> less than 1s.
>
> - erik
>
>
So, I think you are saying, that for pieces in a mkfile that take less than
1s to build it is possible for them to be build again, unnecessarily, when
mk is run again.  This is normal and just the way it is.  Is that correct?

Thanks!

[-- Attachment #2: Type: text/html, Size: 3546 bytes --]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> So, I think you are saying, that for pieces in a mkfile that take less than
> 1s to build it is possible for them to be build again, unnecessarily, when
> mk is run again.  This is normal and just the way it is.  Is that correct?

to be more explicit.  if a is built from b and mtime(a) <= mtime(b), then
mk could fail to rebuild a when it needs to.  for correctness, mk must use <=
not <.

in some cases, it is possible that this will never converge and adding a
sleep 1 to the rule helps things converge.  certainly if the point is to save
time, then one need not bother.  on the other hand, if the point is to
make mk precise, that goal can be accomplished with a little effort.

- erik

Re: [9fans] mk time-check/slice issue

[Bakul Shah]

On Thu, 19 Dec 2013 00:40:52 EST erik quanstrom <quanstro@quanstro.net> wrote:
>                                                     if the point is to
> make mk precise, that goal can be accomplished with a little effort.

I suppose making atime, mtime of type struct timespec would
break too much including 9p?

Re: [9fans] mk time-check/slice issue

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

On 19 December 2013 06:07, Bakul Shah <bakul@bitblocks.com> wrote:

> I suppose making atime, mtime of type struct timespec would
> break too much including 9p?
>

It's unfortunate that the times in the protocol have low resolution.
I think ix does better.

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

Re: [9fans] mk time-check/slice issue

[Oleksandr Iakovliev]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

On 12/19/2013 11:59 AM, Charles Forsyth wrote:
>
> On 19 December 2013 06:07, Bakul Shah <bakul@bitblocks.com
> <mailto:bakul@bitblocks.com>> wrote:
>
>     I suppose making atime, mtime of type struct timespec would
>     break too much including 9p?
>
>
> It's unfortunate that the times in the protocol have low resolution.
> I think ix does better.

Is it time for for 9p2014?

[-- Attachment #2: Type: text/html, Size: 1363 bytes --]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> On 12/19/2013 11:59 AM, Charles Forsyth wrote:
> >
> > On 19 December 2013 06:07, Bakul Shah <bakul@bitblocks.com
> > <mailto:bakul@bitblocks.com>> wrote:
> >
> >     I suppose making atime, mtime of type struct timespec would
> >     break too much including 9p?
> >
> >
> > It's unfortunate that the times in the protocol have low resolution.
> > I think ix does better.
>
> Is it time for for 9p2014?

there are ways a file server could address this without changing the protocol.
for example, if the fs returned directory entries in oldest-first order, files
could be ordered without reference to the time.

(not that this is a good idea.)

- erik

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

On Wed, Dec 18, 2013 at 11:40 PM, erik quanstrom <quanstro@quanstro.net>wrote:
>
>
> to be more explicit.  if a is built from b and mtime(a) <= mtime(b), then
> mk could fail to rebuild a when it needs to.  for correctness, mk must
> use <=
> not <.
>

I was thinking about the problem and actually, at least in all
circumstances I can think of, changing that one operation from <= to <
would fix the problem.  If the times are on the same second, I would never
have had time to change it.  This would fix the problem.  Perhaps this
functionality can be controlled by an environment variable like NPROC.

I think this is important as follows.  If you are working on a project,
edit some files, and then perform a mk, if files you haven't changed get
built, I for one would constantly question myself, about whether or not I
changed that file.  It would make things confusing.  Also, and perhaps more
importantly, it may occur that a very long build is dependant on a very
short preceding build.  So, the unnecessary rebuild of the fast process can
unnecessarily trigger the very long process.  This really needs addressing
for that reason especially IMO.

Thanks.

Blake

[-- Attachment #2: Type: text/html, Size: 2888 bytes --]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> I was thinking about the problem and actually, at least in all
> circumstances I can think of, changing that one operation from <= to <
> would fix the problem.  If the times are on the same second, I would never
> have had time to change it.  This would fix the problem.  Perhaps this
> functionality can be controlled by an environment variable like NPROC.

i thought this idea might come up.  i think the reason not to do this
is a very fundamental principle: correctness.  never give up on correctness.

- erik

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I was thinking about the problem and actually, at least in all
> > circumstances I can think of, changing that one operation from <= to <
> > would fix the problem.  If the times are on the same second, I would
> never
> > have had time to change it.  This would fix the problem.  Perhaps this
> > functionality can be controlled by an environment variable like NPROC.
>
> i thought this idea might come up.  i think the reason not to do this
> is a very fundamental principle: correctness.  never give up on
> correctness.
>
>
I for one favor practical usefulness over theoretical correctness.  An
environment variable option would trivially satisfy both groups. It could
operate as-is so nothing pre-existing would be affected.

Blake

[-- Attachment #2: Type: text/html, Size: 2141 bytes --]

Re: [9fans] mk time-check/slice issue

[Tristan]

> I for one favor practical usefulness over theoretical correctness.  An
> environment variable option would trivially satisfy both groups. It could
> operate as-is so nothing pre-existing would be affected.

how long does it take you to run mk, and then realise you didn't Put your
last set of changes?

i once changed mk on my local machine to act as you suggest, and then
took far too long trying to figure out why the program's behavior didn't
reflect the code. more time than i saved from waiting on mk? who knows?

theoretical incorrectness has a way of becoming practical...

tristan

-- 
All original matter is hereby placed immediately under the public domain.

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Thu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote:

> > I for one favor practical usefulness over theoretical correctness.  An
> > environment variable option would trivially satisfy both groups. It
> could
> > operate as-is so nothing pre-existing would be affected.
>
> how long does it take you to run mk, and then realise you didn't Put your
> last set of changes?
>
> i once changed mk on my local machine to act as you suggest, and then
> took far too long trying to figure out why the program's behavior didn't
> reflect the code. more time than i saved from waiting on mk? who knows?
>

If the situation you describe can happen then it definitely shouldn't be
changed.  Could you please provide me with a scenario (sequence of events)
that would be a problem if mk was changed?  I can't think of one.

Thanks.

Blake

[-- Attachment #2: Type: text/html, Size: 2634 bytes --]

Re: [9fans] mk time-check/slice issue

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

No one is stopping you from changing it in your installation.
On Dec 19, 2013 11:38 AM, "Blake McBride" <blake@mcbride.name> wrote:

> On Thu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote:
>
>> > I for one favor practical usefulness over theoretical correctness.  An
>> > environment variable option would trivially satisfy both groups. It
>> could
>> > operate as-is so nothing pre-existing would be affected.
>>
>> how long does it take you to run mk, and then realise you didn't Put your
>> last set of changes?
>>
>> i once changed mk on my local machine to act as you suggest, and then
>> took far too long trying to figure out why the program's behavior didn't
>> reflect the code. more time than i saved from waiting on mk? who knows?
>>
>
> If the situation you describe can happen then it definitely shouldn't be
> changed.  Could you please provide me with a scenario (sequence of events)
> that would be a problem if mk was changed?  I can't think of one.
>
> Thanks.
>
> Blake
>
>

[-- Attachment #2: Type: text/html, Size: 1874 bytes --]

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Yea, got that.  I just thought it made sense for a wider audience.


On Thu, Dec 19, 2013 at 10:40 AM, Jacob Todd <jaketodd422@gmail.com> wrote:

> No one is stopping you from changing it in your installation.
> On Dec 19, 2013 11:38 AM, "Blake McBride" <blake@mcbride.name> wrote:
>
>> On Thu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote:
>>
>>> > I for one favor practical usefulness over theoretical correctness.  An
>>> > environment variable option would trivially satisfy both groups. It
>>> could
>>> > operate as-is so nothing pre-existing would be affected.
>>>
>>> how long does it take you to run mk, and then realise you didn't Put
>>> your
>>> last set of changes?
>>>
>>> i once changed mk on my local machine to act as you suggest, and then
>>> took far too long trying to figure out why the program's behavior didn't
>>> reflect the code. more time than i saved from waiting on mk? who knows?
>>>
>>
>> If the situation you describe can happen then it definitely shouldn't be
>> changed.  Could you please provide me with a scenario (sequence of events)
>> that would be a problem if mk was changed?  I can't think of one.
>>
>> Thanks.
>>
>> Blake
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2386 bytes --]

Re: [9fans] mk time-check/slice issue

[Tristan]

> > how long does it take you to run mk, and then realise you didn't Put your
> > last set of changes?

> > i once changed mk on my local machine to act as you suggest, and then
> > took far too long trying to figure out why the program's behavior didn't
> > reflect the code. more time than i saved from waiting on mk? who knows?

> If the situation you describe can happen then it definitely shouldn't be
> changed.  Could you please provide me with a scenario (sequence of events)
> that would be a problem if mk was changed?  I can't think of one.

i thought i just described one in acme:

change stuff
middle click Put
change more stuff
middle click mk
middle click Put (within the same second of a file's compile)
middle click mk (don't notice that the file wasn't recompiled)

tristan

-- 
All original matter is hereby placed immediately under the public domain.

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On Thu, Dec 19, 2013 at 11:24 AM, Tristan <9p-st@imu.li> wrote:

> > > how long does it take you to run mk, and then realise you didn't Put
> your
> > > last set of changes?
>
> > > i once changed mk on my local machine to act as you suggest, and then
> > > took far too long trying to figure out why the program's behavior
> didn't
> > > reflect the code. more time than i saved from waiting on mk? whoknows?
>
> > If the situation you describe can happen then it definitely shouldn't be
> > changed.  Could you please provide me with a scenario (sequence of
> events)
> > that would be a problem if mk was changed?  I can't think of one.
>
> i thought i just described one in acme:
>
> change stuff
> middle click Put
> change more stuff
> middle click mk


I assume at least one second would transpire here.


>
> middle click Put (within the same second of a file's compile)
> middle click mk (don't notice that the file wasn't recompiled)
>

Would work correctly assuming the above.


>
> tristan
>
> --
> All original matter is hereby placed immediately under the public domain.
>
>

[-- Attachment #2: Type: text/html, Size: 4081 bytes --]

Re: [9fans] mk time-check/slice issue

[Steffen Daode Nurpmeso]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Blake McBride <blake@mcbride.name> wrote:
 |On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom <quanstro@\
 |quanstro.net>wrote:
 |
 |>> I was thinking about the problem and actually, at least in all
 |>> circumstances I can think of, changing that one operation from <= to <
 |>> would fix the problem.  If the times are on the same second, I would
 |>
 |> i thought this idea might come up.  i think the reason not to do this
 |> is a very fundamental principle: correctness.  never give up on
 |> correctness.
 |>
 |I for one favor practical usefulness over theoretical correctness.  An

I think on FAT filesystems even giving up correctness won't help
you with it's two second resolution.

--steffen

[-- Attachment #2: Original message content --]
[-- Type: message/rfc822, Size: 8434 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 839 bytes --]

On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I was thinking about the problem and actually, at least in all
> > circumstances I can think of, changing that one operation from <= to <
> > would fix the problem.  If the times are on the same second, I would
> never
> > have had time to change it.  This would fix the problem.  Perhaps this
> > functionality can be controlled by an environment variable like NPROC.
>
> i thought this idea might come up.  i think the reason not to do this
> is a very fundamental principle: correctness.  never give up on
> correctness.
>
>
I for one favor practical usefulness over theoretical correctness.  An
environment variable option would trivially satisfy both groups. It could
operate as-is so nothing pre-existing would be affected.

Blake

[-- Attachment #2.1.2: Type: text/html, Size: 2141 bytes --]

Re: [9fans] mk time-check/slice issue

[a]

// If you are working on a project, edit some files, and then
// perform a mk, if files you haven't changed get built, I for
// one would constantly question myself, about whether or
// not I changed that file.  It would make things confusing.

It's confusing because it doesn't match your expectations,
but that's just as much because you're misunderstanding
the intent of the tool. mk is not a tool for checking for
changes, it is a tool for ensuring things are up to date. It
just isn't designed to provide what you're looking for. That
isn't to say that what you're looking for is unreasonable,
but mk is not the tool to provide it.

As an aside, I'd suggest learning to simply not worry about
it. Internalize the fact that mk will sometimes rebuild things
that don't strictly need it, but will ensure that things are up
to date, and you'll have an easier time of it.

// I for one favor practical usefulness over theoretical
// correctness.

You have not demonstrated anything that significantly
impacts mk's practical usefullness. The fact that mk will, in
some cases, rebuild things which don't need it doesn't
significantly impact its utility for its intended purpose.

In Plan 9, the heirarchy of values is different from other
systems. Correctness (theoretical or otherwise) and
elegance come above utility. That's not to say there are
no tradeoffs in the system, but if you're going to give up
even a little bit of correctness or elegance (environment
variables?!?), you'd best be prepared to demonstrate a
rather substantial utility gain. Given how much use this
community has gotten out of mk over the past ~27
years, I think it's safe to say we're not sold.

Anthony

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

On Thu, Dec 19, 2013 at 11:07 AM, <a@9srv.net> wrote:

> // If you are working on a project, edit some files, and then
> // perform a mk, if files you haven't changed get built, I for
> // one would constantly question myself, about whether or
> // not I changed that file.  It would make things confusing.
>
> It's confusing because it doesn't match your expectations,
> but that's just as much because you're misunderstanding
> the intent of the tool. mk is not a tool for checking for
> changes, it is a tool for ensuring things are up to date. It
> just isn't designed to provide what you're looking for. That
> isn't to say that what you're looking for is unreasonable,
> but mk is not the tool to provide it.
>
> As an aside, I'd suggest learning to simply not worry about
> it. Internalize the fact that mk will sometimes rebuild things
> that don't strictly need it, but will ensure that things are up
> to date, and you'll have an easier time of it.
>
> // I for one favor practical usefulness over theoretical
> // correctness.
>
> You have not demonstrated anything that significantly
> impacts mk's practical usefullness. The fact that mk will, in
> some cases, rebuild things which don't need it doesn't
> significantly impact its utility for its intended purpose.
>
> In Plan 9, the heirarchy of values is different from other
> systems. Correctness (theoretical or otherwise) and
> elegance come above utility. That's not to say there are
> no tradeoffs in the system, but if you're going to give up
> even a little bit of correctness or elegance (environment
> variables?!?), you'd best be prepared to demonstrate a
> rather substantial utility gain. Given how much use this
> community has gotten out of mk over the past ~27
> years, I think it's safe to say we're not sold.
>
> Anthony
>
>
>
What I am beginning to understand from comments like this is that there is
a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
is correct, period.  No mater what exceptions, special cases, or good new
ideas occur, they are wrong and we will find some way of rationalizing
"club Plan-9".  Anyone can join "club Plan-9" if you buy into that
assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
port to new hardware.  Messing with the premise of "club Plan-9" is
significantly frowned upon and attacked.

Just a newbie's (with 35 years experience) perception.

Blake

[-- Attachment #2: Type: text/html, Size: 6204 bytes --]

Re: [9fans] mk time-check/slice issue

[Kurt H Maier]

Quoting Blake McBride <blake@mcbride.name>:

> What I am beginning to understand from comments like this is that there is
> a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
> is correct, period.  No mater what exceptions, special cases, or good new
> ideas occur, they are wrong and we will find some way of rationalizing
> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
> assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
> port to new hardware.  Messing with the premise of "club Plan-9" is
> significantly frowned upon and attacked.
>
> Just a newbie's (with 35 years experience) perception.


eagerly awaiting your discoveries regarding wetness of water

Re: [9fans] mk time-check/slice issue

[Matthew Veety]

You should learn the system before wanting to make changes to it. You're wanting to change how zen is practiced without knowing much zen.

Re: [9fans] mk time-check/slice issue

[Kurt H Maier]

Quoting Blake McBride <blake@mcbride.name>:

> What I am beginning to understand from comments like this is that there is
> a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
> is correct, period.  No mater what exceptions, special cases, or good new
> ideas occur, they are wrong and we will find some way of rationalizing
> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
> assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
> port to new hardware.  Messing with the premise of "club Plan-9" is
> significantly frowned upon and attacked.
>
> Just a newbie's (with 35 years experience) perception.

What I am beginning to understand from comments like this is that there is
a "club entitlement."  Everything ever done by the members of "club
entitlement"
is correct, period.  No matter what preconceptions, bad habits, or horrible
misfeatures exist, they are correct and we will find some way of implementing
"club entitlement."  Anyone can join "club entitlement" if you assume you
cannot be wrong.  The main purpose of operating systems (with no
exceptions) is to
port gnu software.  Messing with the premise of "club entitlement" is
significantly whined about on tumblr.

Just a newbie's (with six hundred years experience) perception.

khm

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Thu, Dec 19, 2013 at 1:07 PM, Kurt H Maier <khm@sciops.net> wrote:

> Quoting Blake McBride <blake@mcbride.name>:
>
>  What I am beginning to understand from comments like this is that there is
>> a "club Plan-9".  Everything ever done by the originators of "club
>> Plan-9"
>> is correct, period.  No mater what exceptions, special cases, or good new
>> ideas occur, they are wrong and we will find some way of rationalizing
>> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
>> assumption.  The main purpose of Plan-9 forks (with some exceptions) is
>> to
>> port to new hardware.  Messing with the premise of "club Plan-9" is
>> significantly frowned upon and attacked.
>>
>> Just a newbie's (with 35 years experience) perception.
>>
>
> What I am beginning to understand from comments like this is that there is
> a "club entitlement."  Everything ever done by the members of "club
> entitlement"
> is correct, period.  No matter what preconceptions, bad habits, or
> horrible
> misfeatures exist, they are correct and we will find some way of
> implementing
> "club entitlement."  Anyone can join "club entitlement" if you assume you
> cannot be wrong.  The main purpose of operating systems (with no
> exceptions) is to
> port gnu software.  Messing with the premise of "club entitlement" is
> significantly whined about on tumblr.
>
> Just a newbie's (with six hundred years experience) perception.
>
>
Given the number of times I have been enlightened by this group and shown
to be clearly wrong, I suppose I am not a member of "club entitlement".
 When I make a query, I am looking for examples of why it is done the way
it is.  I have provided examples of why the way it works is a problem.
 Members of "club Plan-9" insist that that is just the way it works, as
opposed to here is a counterexample why the way it works is better.  There
is a difference between valid arguments and club allegiance.

Blake

[-- Attachment #2: Type: text/html, Size: 4241 bytes --]

Re: [9fans] mk time-check/slice issue

[Kurt H Maier]

Quoting Blake McBride <blake@mcbride.name>:

> There is a difference between valid arguments and club allegiance.

You have not demonstrated a necessity for anyone subscribed to this
list to give a particular shit about which of the two are at play here.

We don't owe you anything, including a defense of plan 9.

Patches welcome.

khm

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

On Thu, Dec 19, 2013 at 1:27 PM, Kurt H Maier <khm@sciops.net> wrote:

> Quoting Blake McBride <blake@mcbride.name>:
>
>  There is a difference between valid arguments and club allegiance.
>>
>
> You have not demonstrated a necessity for anyone subscribed to this
> list to give a particular shit about which of the two are at play here.
>


It would take a long email to properly answer that question involving human
motivation.  I think I'll spare myself the time writing it, and the group
with that information.




>
> We don't owe you anything, including a defense of plan 9.
>

Agreed.  You also don't owe your grocer, your tailor, or your gas station
attendant anything either.  There is personal gain we all get by shared
contribution.


> Patches welcome.


I would be much more interested in producing and providing patches if I
wasn't in such fear of upsetting the Plan-9 philosophy.  (That is if
improvements were sufficient.)

I am very, very happy to understand technical reason why things are the way
they are.  I am also humble enough to know that there is a hell of a lot I
can learn from all of you and Plan-9.  Hitting roadblocks with "that's the
way it works and should work" gives me nothing (yes, the nothing you owe
me).




>
>
> khm
>
>
>

[-- Attachment #2: Type: text/html, Size: 2687 bytes --]

Re: [9fans] mk time-check/slice issue

[Kurt H Maier]

Quoting Blake McBride <blake@mcbride.name>:

> Agreed.  You also don't owe your grocer, your tailor, or your gas station
> attendant anything either.  There is personal gain we all get by shared
> contribution.

I've selected grocers, tailors, and gas station attendants based on
technical merit.  How am I to value your input?

> I would be much more interested in producing and providing patches if I
> wasn't in such fear of upsetting the Plan-9 philosophy.  (That is if
> improvements were sufficient.)

Your total lack of effort in understanding Plan 9 philosophy deftly
removes any interest I may have had in your programming output.  Your
fear is your own problem.

> I am very, very happy to understand technical reason why things are the way
> they are.  I am also humble enough to know that there is a hell of a lot I
> can learn from all of you and Plan-9.  Hitting roadblocks with "that's the
> way it works and should work" gives me nothing (yes, the nothing you owe
> me).

Your humility expresses itself in strange ways, particularly when you arrive
in a cloud of smoke, not having read even the most immediately relevant
documentation, to tell us that mk is broken because it does not work like
make.

You won't do it, but I recommend reading the entire post history of 9fans.
You will see yourself in several posts throughout the years, as well as
techincal discussions you would find illuminating.  A large part of the
reticence you're running into here is the fact that all of this has been
discussed to death, frequently to very little profit.

khm

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> > I would be much more interested in producing and providing patches if I
> > wasn't in such fear of upsetting the Plan-9 philosophy.  (That is if
> > improvements were sufficient.)
>
> Your total lack of effort in understanding Plan 9 philosophy deftly
> removes any interest I may have had in your programming output.  Your
> fear is your own problem.

i think this is unfair.  argument is a way to understand a problem.

- erik

Re: [9fans] mk time-check/slice issue

[Kurt H Maier]

Quoting erik quanstrom <quanstro@labs.coraid.com>:

>> > I would be much more interested in producing and providing patches if I
>> > wasn't in such fear of upsetting the Plan-9 philosophy.  (That is if
>> > improvements were sufficient.)
>>
>> Your total lack of effort in understanding Plan 9 philosophy deftly
>> removes any interest I may have had in your programming output.  Your
>> fear is your own problem.
>
> i think this is unfair.  argument is a way to understand a problem.
>
> - erik

I disagree, and thereby achieve understanding.

khm

Re: [9fans] mk time-check/slice issue

[a]

//  I have provided examples of why the way it works is a problem.
// Members of "club Plan-9" insist that that is just the way it works, as
// opposed to here is a counterexample why the way it works is better.

No, we don't. You keep hearing that, but nobody's saying it.

mk does what it does because it is a more conservative behavior.
Yes, things sometimes get needlessly rebuilt. We recognize that, and
agree it's not ideal. We are concerned that your suggested change
would introduce more problems than it solves. This has all been
stated repeatedly, and has nothing to do with "it's just the way it
works". The closest we've come to that is asserting that there is *a
reason* it is that way, and that you seem not to have taken the time
to understand what it is. You've been reluctant to accept that idea.

Further, while I don't think it's been stated explicitly, the idea of "just
change the behavior of the out-of-date check based on an
environment variable" is counter to the general Plan 9 philosophy.
Again, not because "that's the way it is", but because it makes the
tool less predictable and introduces a whole other class of extrnal
dependency. This is something Plan 9 intentionally avoids.

Anthony

Re: [9fans] mk time-check/slice issue

[a]

// What I am beginning to understand from comments like
// this is that there is a "club Plan-9".  Everything ever done
// by the originators of "club Plan-9" is correct, period.  No
// mater what exceptions, special cases, or good new ideas
// occur, they are wrong and we will find some way of
// rationalizing "club Plan-9".

No, that's not what's going on, and I'm sorry if you've felt
attacked. The issue is not that "different==bad" or that what
Ken, Rob, & co. have done is infallible. It's just that it seems
as though you have not taken the time to understand the
reasons behind things being the way they are.

There is a reason (or set of reasons) we're using Plan 9, as
opposed to doing everything on Linux or whatnot. The
system is designed with a different set of principles in mind.

My "~27 years" comment was not intended to start a years-
of-experience pissing match (although arguably I should
have anticipated it). My point is rather that the tool's been
around for quite some time in productive use, and has
undergone changes over that time. It would be wiser to take
some time to understand why it is the way it is before
concluding that it's been broken for all that time. No, we
don't assume that it's correct, either, but it does shift the
burden of proof a bit.

Also, it's "Plan 9" or "plan9"; never "Plan-9".

Anthony

Re: [9fans] mk time-check/slice issue

[dexen deVries]

On Thursday 19 of December 2013 14:09:05 a@9srv.net wrote:
> 
> There is a reason (or set of reasons) we're using Plan 9, as
> opposed to doing everything on Linux or whatnot. The
> system is designed with a different set of principles in mind.


as a resident contrarian, let me say:

there is a reason i prefer using p9p (mk, rc, acme) when working on linux -- 
rather than just linux (or GNU Make, Bash, emacs/vi), with all the assorted 
bells and whistles.


call it zen, call it time saver,
i debug my projects, not the meta-projects.
commit.


-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

> What I am beginning to understand from comments like this is that there is
> a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
> is correct, period.  No mater what exceptions, special cases, or good new
> ideas occur, they are wrong and we will find some way of rationalizing
> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
> assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
> port to new hardware.  Messing with the premise of "club Plan-9" is
> significantly frowned upon and attacked.
>
> Just a newbie's (with 35 years experience) perception.

first things first.  breaking mk is not a good idea.  to see that things could
break with < rather than <= one only needs to consider a dependency that might
be modified more than once during a build.  for example fu.h that is modified
for a debug version built along a non-debug version.

perhaps there is some truth to this.  certainly plan 9 is not perfect.  and
certainly there are things you will improve.  but on the other hand, many
of us have quite a bit of experience, too.

- erik

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom <quanstro@labs.coraid.com>wrote:

> > What I am beginning to understand from comments like this is that there
> is
> > a "club Plan-9".  Everything ever done by the originators of "club
> Plan-9"
> > is correct, period.  No mater what exceptions, special cases, or good
> new
> > ideas occur, they are wrong and we will find some way of rationalizing
> > "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
> > assumption.  The main purpose of Plan-9 forks (with some exceptions) is
> to
> > port to new hardware.  Messing with the premise of "club Plan-9" is
> > significantly frowned upon and attacked.
> >
> > Just a newbie's (with 35 years experience) perception.
>
> first things first.  breaking mk is not a good idea.  to see that things
> could
> break with < rather than <= one only needs to consider a dependency that
> might
> be modified more than once during a build.  for example fu.h that is
> modified
> for a debug version built along a non-debug version.
>
> perhaps there is some truth to this.  certainly plan 9 is not perfect.
> and
> certainly there are things you will improve.  but on the other hand, many
> of us have quite a bit of experience, too.
>


Thanks for the input. I see your point but would argue (in the most
friendly way) that the case you point out would be extremely rare, while
the reverse case is very common.  Adding sleep to the rarer case makes more
sense to me.  Again, I propose an option to mk that, IMO, would have wide
value.

Yes, I realize I can change my version of mk.  In that case, I could do as
I please.  I was hoping to either learn from the experience (perhaps there
is a good reason to have mk make the same stuff repeatedly), or be able to
contribute.

Thanks.

Blake

[-- Attachment #2: Type: text/html, Size: 5075 bytes --]

Re: [9fans] mk time-check/slice issue

[Gabriel Diaz]

off topic - for your own amusement, you can search in the mail list archives (http://9fans.net/archive/)  DP9IK and SP9SSS

gabi


On Thursday, December 19, 2013 8:30 PM, Blake McBride <blake@mcbride.name> wrote:

On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom <quanstro@labs.coraid.com> wrote:

> What I am beginning to understand from comments like this is that there is
>> a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
>> is correct, period.  No mater what exceptions, special cases, or good new
>> ideas occur, they are wrong and we will find some way of rationalizing
>> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
>> assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
>> port to new hardware.  Messing with the premise of "club Plan-9" is
>> significantly frowned upon and attacked.
>>
>> Just a newbie's (with 35 years experience) perception.
>
>first things first.  breaking mk is not a good idea.  to see that things could
>break with < rather than <= one only needs to consider a dependency that might
>be modified more than once during a build.  for example fu.h that is modified
>for a debug version built along a non-debug version.
>
>perhaps there is some truth to this.  certainly plan 9 is not perfect.  and
>certainly there are things you will improve.  but on the other hand, many
>of us have quite a bit of experience, too.
>


Thanks for the input. I see your point but would argue (in the most friendly way) that the case you point out would be extremely rare, while the reverse case is very common.  Adding sleep to the rarer case makes more sense to me.  Again, I propose an option to mk that, IMO, would have wide value.

Yes, I realize I can change my version of mk.  In that case, I could do as I please.  I was hoping to either learn from the experience (perhaps there is a good reason to have mk make the same stuff repeatedly), or be able to contribute.  

Thanks.

Blake

Re: [9fans] mk time-check/slice issue

[Richard Miller]

> I see your point but would argue (in the most
> friendly way) that the case you point out would be extremely rare, while
> the reverse case is very common.

"Correctness" (in the context of software engineering) doesn't mean
doing the right thing in all but the rarest cases; it means doing the
right thing in every case.  Multiprocessor race conditions are
extremely rare, but that doesn't absolve us from putting locks around
critical sections in the kernel to guarantee that "rare" becomes
"never".

Remember mk is not just used to compile stuff.  It's a "general tool
for describing and maintaining dependencies between files or
programs".  If there are cases (even extremely rare ones) when mk can
finish without establishing all the described dependencies, it's
broken.  Given the simple low-resolution time stamps currenly
supported by the Plan 9 file protocol, ensuring that files are updated
correctly may come at a cost of doing some redundant work.

Think a bit further outside the box than a single-user computer being
used to compile programs.  Suppose for example there's a cron script
which uses mk to update indices for the lookman(1) command, or to
update hash files for ndb(8).  What if someone (maybe in another
timezone!) happens to be editing a man page or ndb file when the cron
job activates.  Oops, race condition.  Extremely rare like most race
conditions, but I for one am happy that mk is robust enough do the
right thing when the rare occurrence occurs.

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

On Thu, Dec 19, 2013 at 2:15 PM, Richard Miller <9fans@hamnavoe.com> wrote:

> > I see your point but would argue (in the most
> > friendly way) that the case you point out would be extremely rare, while
> > the reverse case is very common.
>
> "Correctness" (in the context of software engineering) doesn't mean
> doing the right thing in all but the rarest cases; it means doing the
> right thing in every case.  Multiprocessor race conditions are
> extremely rare, but that doesn't absolve us from putting locks around
> critical sections in the kernel to guarantee that "rare" becomes
> "never".
>
> Remember mk is not just used to compile stuff.  It's a "general tool
> for describing and maintaining dependencies between files or
> programs".  If there are cases (even extremely rare ones) when mk can
> finish without establishing all the described dependencies, it's
> broken.  Given the simple low-resolution time stamps currenly
> supported by the Plan 9 file protocol, ensuring that files are updated
> correctly may come at a cost of doing some redundant work.
>
> Think a bit further outside the box than a single-user computer being
> used to compile programs.  Suppose for example there's a cron script
> which uses mk to update indices for the lookman(1) command, or to
> update hash files for ndb(8).  What if someone (maybe in another
> timezone!) happens to be editing a man page or ndb file when the cron
> job activates.  Oops, race condition.  Extremely rare like most race
> conditions, but I for one am happy that mk is robust enough do the
> right thing when the rare occurrence occurs.
>

I see your point, and agree.  I suppose I have been arguing for an _option_
that would assist one person working in one tree at a time - a common but
not utterly common situation.  Also, see my earlier point about fast, prior
dependencies unnecessarily triggering very time consuming dependencies.
 Having been envolved with projects that take 4 hours to build, this could
be very significant.  Again, the _option_ would help a great deal.

Thanks.

Blake

[-- Attachment #2: Type: text/html, Size: 5660 bytes --]

Re: [9fans] mk time-check/slice issue

[Richard Miller]

> Having been envolved with projects that take 4 hours to build

Don't worry, that will never happen in Plan 9.  One of the more
delightful consequences of putting simplicity first.

Re: [9fans] mk time-check/slice issue

[Aram Hăvărneanu]

The "problem" discussed here is caused by low-resolution timestamps. The
solution is to to increase the resolution of the timestamps, not to add
hacks to the mk tool. Adding hacks and special casings inside tools is
one of the main reasons why Unix is so clumsy and hard to use. Look at how
networking was added to BSD. A quick hack to the kernel that expanded the
API surface and required writing new programs. On Plan 9 we know better.

Increasing timestamp resolution comes at a cost. It is a problem too
minor to be addressed on its own. If there's ever a revamp of the
protocols for some other, more fundamental reason, perhaps it is worth
addressing. Perhaps not. See IX. Making lasting changes too early is
also a mistake Unix made.

I'd also like to note that if low-resolution timestamps became observable
in mk, the thing you are building compiles so quickly that it's unlikey
to cause any wasted human time. Avoiding solving problems that exist only
as academic exercises to keep complexity down is also one good trait of
Plan 9.

-- 
Aram Hăvărneanu

Re: [9fans] mk time-check/slice issue

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]

You can change anything you want on your system; but don't try to ram it
down others' throats unless you can prove that you're approach is (a)
correct (b) meets the collective sense elegance.  Reasoned disagreement is
not an attack.



On Thu, Dec 19, 2013 at 10:40 AM, Blake McBride <blake@mcbride.name> wrote:

>
> On Thu, Dec 19, 2013 at 11:07 AM, <a@9srv.net> wrote:
>
>> // If you are working on a project, edit some files, and then
>> // perform a mk, if files you haven't changed get built, I for
>> // one would constantly question myself, about whether or
>> // not I changed that file.  It would make things confusing.
>>
>> It's confusing because it doesn't match your expectations,
>> but that's just as much because you're misunderstanding
>> the intent of the tool. mk is not a tool for checking for
>> changes, it is a tool for ensuring things are up to date. It
>> just isn't designed to provide what you're looking for. That
>> isn't to say that what you're looking for is unreasonable,
>> but mk is not the tool to provide it.
>>
>> As an aside, I'd suggest learning to simply not worry about
>> it. Internalize the fact that mk will sometimes rebuild things
>> that don't strictly need it, but will ensure that things are up
>> to date, and you'll have an easier time of it.
>>
>> // I for one favor practical usefulness over theoretical
>> // correctness.
>>
>> You have not demonstrated anything that significantly
>> impacts mk's practical usefullness. The fact that mk will, in
>> some cases, rebuild things which don't need it doesn't
>> significantly impact its utility for its intended purpose.
>>
>> In Plan 9, the heirarchy of values is different from other
>> systems. Correctness (theoretical or otherwise) and
>> elegance come above utility. That's not to say there are
>> no tradeoffs in the system, but if you're going to give up
>> even a little bit of correctness or elegance (environment
>> variables?!?), you'd best be prepared to demonstrate a
>> rather substantial utility gain. Given how much use this
>> community has gotten out of mk over the past ~27
>> years, I think it's safe to say we're not sold.
>>
>> Anthony
>>
>>
>>
> What I am beginning to understand from comments like this is that there is
> a "club Plan-9".  Everything ever done by the originators of "club Plan-9"
> is correct, period.  No mater what exceptions, special cases, or good new
> ideas occur, they are wrong and we will find some way of rationalizing
> "club Plan-9".  Anyone can join "club Plan-9" if you buy into that
> assumption.  The main purpose of Plan-9 forks (with some exceptions) is to
> port to new hardware.  Messing with the premise of "club Plan-9" is
> significantly frowned upon and attacked.
>
> Just a newbie's (with 35 years experience) perception.
>
> Blake
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4312 bytes --]

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Thu, Dec 19, 2013 at 1:12 PM, Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> You can change anything you want on your system; but don't try to ram it
> down others' throats unless you can prove that you're approach is (a)
> correct (b) meets the collective sense elegance.  Reasoned disagreement is
> not an attack.
>

Agreed.  I enjoy reasoned debate.  I don't enjoy being told the reason is
because "that's the way we do it".  That is not reasoned debate.  It is
club support.

[-- Attachment #2: Type: text/html, Size: 979 bytes --]

Re: [9fans] mk time-check/slice issue

[Rudolf Sykora]

Hello,

On 19 December 2013 20:22, Blake McBride <blake@mcbride.name> wrote:
> Agreed.  I enjoy reasoned debate.  I don't enjoy being told the reason is
> because "that's the way we do it".  That is not reasoned debate.  It is club
> support.

I believe, from reading this mailing list for some time, you must be ready
to find many stupid reasonings. But opposite is, fortunately, also true: there
are people here who can help.

Second, you bumped into something which is not 100% to your liking, but on
the other hand is "simple" and works. The simplicity is, in my
opinion, what has always
counted for people seriously-involved in plan9 and is one of the main
advantages of the plan9 programs.

Third, it would be, from my experience, an error to expect that there are no
errors/flaws in the plan9 programs. When I started to play with plan9,
I thought:
it is simple, there are no errors. But in reality, whatever I tried,
it did not quite
work. So, my advice is to be ready to find such problems nearly all the time.
And since many people who created the programs are gone by now, there is
often little effort to correct these, even if there are true bugs.

That's what I think.

Ruda

Re: [9fans] mk time-check/slice issue

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Thu, Dec 19, 2013 at 1:43 PM, Rudolf Sykora <rudolf.sykora@gmail.com>wrote:

> Hello,
>
> On 19 December 2013 20:22, Blake McBride <blake@mcbride.name> wrote:
> > Agreed.  I enjoy reasoned debate.  I don't enjoy being told the reason is
> > because "that's the way we do it".  That is not reasoned debate.  It is
> club
> > support.
>
> I believe, from reading this mailing list for some time, you must be ready
> to find many stupid reasonings. But opposite is, fortunately, also true:
> there
> are people here who can help.
>
> Second, you bumped into something which is not 100% to your liking, but on
> the other hand is "simple" and works. The simplicity is, in my
> opinion, what has always
> counted for people seriously-involved in plan9 and is one of the main
> advantages of the plan9 programs.
>
> Third, it would be, from my experience, an error to expect that there are
> no
> errors/flaws in the plan9 programs. When I started to play with plan9,
> I thought:
> it is simple, there are no errors. But in reality, whatever I tried,
> it did not quite
> work. So, my advice is to be ready to find such problems nearly all the
> time.
> And since many people who created the programs are gone by now, there is
> often little effort to correct these, even if there are true bugs.
>
> That's what I think.
>
> Ruda
>
>

Thanks for your thoughtful input!

Unfortunately, I have started and continue to provoke a most unhelpful line
of discussion.  Know that it was (poorly) done with good intention
merely to draw a distinction between technical reasons and "that's the way
we do it" attitudes.

Blake

[-- Attachment #2: Type: text/html, Size: 3703 bytes --]

Re: [9fans] mk time-check/slice issue

[sl]

> Just a newbie's (with 35 years experience) perception.

It sounds like you're saying that you came on the scene around
the time UNIX diverged from sanity and devolved into madness.

sl

Re: [9fans] mk time-check/slice issue

[Richard Miller]

> So, I think you are saying, that for pieces in a mkfile that take less than
> 1s to build it is possible for them to be build again, unnecessarily, when
> mk is run again.  This is normal and just the way it is.  Is that correct?

Correct except for "just the way it is".  There is a principle
involved which is so pervasive to Plan 9 that we often forget to make
it explicit.  To quote Ken Thompson: "Throughout, simplicity has been
substituted for efficiency.  Complex algorithms are used only if their
complexity can be localized."  He was writing in 1978 about UNIX, but
Plan 9 follows firmly in this tradition.  (Linux not so much.)

Using the existing file time stamps costs some efficiency, when
targets are built more often than necessary.  The question is, how
significant is this cost compared to the complexity of adding higher
time resolution?  Note that it's not necessary to run mk repeatedly
until it converges -- the algorithm is conservative in the sense that
it will not build less than required.

So, how many seconds is the unnecessary building of targets actually
costing?

Re: [9fans] mk time-check/slice issue

[erik quanstrom]

On Thu Dec 19 05:02:50 EST 2013, 9fans@hamnavoe.com wrote:
> > So, I think you are saying, that for pieces in a mkfile that take less than
> > 1s to build it is possible for them to be build again, unnecessarily, when
> > mk is run again.  This is normal and just the way it is.  Is that correct?
>
> Correct except for "just the way it is".  There is a principle
> involved which is so pervasive to Plan 9 that we often forget to make
> it explicit.  To quote Ken Thompson: "Throughout, simplicity has been
> substituted for efficiency.  Complex algorithms are used only if their
> complexity can be localized."  He was writing in 1978 about UNIX, but
> Plan 9 follows firmly in this tradition.  (Linux not so much.)
>
> Using the existing file time stamps costs some efficiency, when
> targets are built more often than necessary.  The question is, how
> significant is this cost compared to the complexity of adding higher
> time resolution?  Note that it's not necessary to run mk repeatedly
> until it converges -- the algorithm is conservative in the sense that
> it will not build less than required.
>
> So, how many seconds is the unnecessary building of targets actually
> costing?

+1.  i just love to hear this approach expressed better than i can.
sorry for my redundant post.

- erik