From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tristan <9p-st@imu.li> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com><34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net><71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net><257c46.301443fc.D01R.mx@tumtum.plumbweb.net> Message-Id: <257c46.39bba3e5.HL59.mx@tumtum.plumbweb.net> Date: Thu, 19 Dec 2013 12:24:44 -0500 User-Agent: mx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a1ff1bc6-ead8-11e9-9d60-3106f5b1d025 > > 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 did= n't > > reflect the code. more time than i saved from waiting on mk? who know= s? > If the situation you describe can happen then it definitely shouldn't b= e > changed. Could you please provide me with a scenario (sequence of even= ts) > 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 --=20 All original matter is hereby placed immediately under the public domain.