From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> <257c46.301443fc.D01R.mx@tumtum.plumbweb.net> Date: Thu, 19 Dec 2013 11:05:08 -0600 Message-ID: From: Blake McBride To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1135fb34ef835a04ede629c8 Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a11d1f5a-ead8-11e9-9d60-3106f5b1d025 --001a1135fb34ef835a04ede629c8 Content-Type: text/plain; charset=ISO-8859-1 Yea, got that. I just thought it made sense for a wider audience. On Thu, Dec 19, 2013 at 10:40 AM, Jacob Todd wrote: > No one is stopping you from changing it in your installation. > On Dec 19, 2013 11:38 AM, "Blake McBride" 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 >> >> > --001a1135fb34ef835a04ede629c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yea, got that. =A0I 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 c= hanging it in your installation.

On Dec 19, 2013 11:38 AM, "Blake McBride&qu= ot; <blake@mcbri= de.name> wrote:
On T= hu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote:
> I for one favor practical usefulness over theoretical correctness= . =A0An
> environment variable option would trivially satisfy both = groups. It could
> operate as-is so nothing pre-existing would be affected.<= br>
how long does it take you to run mk, and th= en realise you didn't Put your
last set of changes?

i once changed mk on my local machine to act as y= ou suggest, and then
took far too long trying to figure out why the program's b= ehavior didn't
reflect the code. more time than i s= aved from waiting on mk? who knows?<= br>

If the situation you describe can happen t= hen it definitely shouldn't be changed. =A0Could you please provide me = with a scenario (sequence of events) that would be a problem if mk=A0was changed? =A0I can't think of one.

Thanks.

Blake
=A0

--001a1135fb34ef835a04ede629c8--