* [9fans] mk time-check/slice issue @ 2013-12-18 22:01 Blake McBride 2013-12-18 22:08 ` Matthew Veety 2013-12-18 22:16 ` erik quanstrom 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-18 22:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:01 [9fans] mk time-check/slice issue Blake McBride @ 2013-12-18 22:08 ` Matthew Veety 2013-12-18 22:42 ` Blake McBride 2013-12-18 22:16 ` erik quanstrom 1 sibling, 1 reply; 50+ messages in thread From: Matthew Veety @ 2013-12-18 22:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:08 ` Matthew Veety @ 2013-12-18 22:42 ` Blake McBride 0 siblings, 0 replies; 50+ messages in thread From: Blake McBride @ 2013-12-18 22:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:01 [9fans] mk time-check/slice issue Blake McBride 2013-12-18 22:08 ` Matthew Veety @ 2013-12-18 22:16 ` erik quanstrom 2013-12-18 22:46 ` Blake McBride 1 sibling, 1 reply; 50+ messages in thread From: erik quanstrom @ 2013-12-18 22:16 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:16 ` erik quanstrom @ 2013-12-18 22:46 ` Blake McBride 2013-12-19 5:40 ` erik quanstrom 2013-12-19 10:01 ` Richard Miller 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-18 22:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:46 ` Blake McBride @ 2013-12-19 5:40 ` erik quanstrom 2013-12-19 6:07 ` Bakul Shah 2013-12-19 14:52 ` Blake McBride 2013-12-19 10:01 ` Richard Miller 1 sibling, 2 replies; 50+ messages in thread From: erik quanstrom @ 2013-12-19 5:40 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 5:40 ` erik quanstrom @ 2013-12-19 6:07 ` Bakul Shah 2013-12-19 10:59 ` Charles Forsyth 2013-12-19 14:52 ` Blake McBride 1 sibling, 1 reply; 50+ messages in thread From: Bakul Shah @ 2013-12-19 6:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 6:07 ` Bakul Shah @ 2013-12-19 10:59 ` Charles Forsyth 2013-12-19 14:21 ` Oleksandr Iakovliev 0 siblings, 1 reply; 50+ messages in thread From: Charles Forsyth @ 2013-12-19 10:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 10:59 ` Charles Forsyth @ 2013-12-19 14:21 ` Oleksandr Iakovliev 2013-12-19 14:58 ` erik quanstrom 0 siblings, 1 reply; 50+ messages in thread From: Oleksandr Iakovliev @ 2013-12-19 14:21 UTC (permalink / raw) To: 9fans [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 14:21 ` Oleksandr Iakovliev @ 2013-12-19 14:58 ` erik quanstrom 0 siblings, 0 replies; 50+ messages in thread From: erik quanstrom @ 2013-12-19 14:58 UTC (permalink / raw) To: yshurik, 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 5:40 ` erik quanstrom 2013-12-19 6:07 ` Bakul Shah @ 2013-12-19 14:52 ` Blake McBride 2013-12-19 14:55 ` erik quanstrom 2013-12-19 17:07 ` a 1 sibling, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 14:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 14:52 ` Blake McBride @ 2013-12-19 14:55 ` erik quanstrom 2013-12-19 15:58 ` Blake McBride 2013-12-19 17:07 ` a 1 sibling, 1 reply; 50+ messages in thread From: erik quanstrom @ 2013-12-19 14:55 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 14:55 ` erik quanstrom @ 2013-12-19 15:58 ` Blake McBride 2013-12-19 16:30 ` Tristan 2013-12-19 17:59 ` Steffen Daode Nurpmeso 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 15:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 15:58 ` Blake McBride @ 2013-12-19 16:30 ` Tristan 2013-12-19 16:37 ` Blake McBride 2013-12-19 17:59 ` Steffen Daode Nurpmeso 1 sibling, 1 reply; 50+ messages in thread From: Tristan @ 2013-12-19 16:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 16:30 ` Tristan @ 2013-12-19 16:37 ` Blake McBride 2013-12-19 16:40 ` Jacob Todd 2013-12-19 17:24 ` Tristan 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 16:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 16:37 ` Blake McBride @ 2013-12-19 16:40 ` Jacob Todd 2013-12-19 17:05 ` Blake McBride 2013-12-19 17:24 ` Tristan 1 sibling, 1 reply; 50+ messages in thread From: Jacob Todd @ 2013-12-19 16:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 16:40 ` Jacob Todd @ 2013-12-19 17:05 ` Blake McBride 0 siblings, 0 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 17:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 16:37 ` Blake McBride 2013-12-19 16:40 ` Jacob Todd @ 2013-12-19 17:24 ` Tristan 2013-12-19 18:30 ` Blake McBride 1 sibling, 1 reply; 50+ messages in thread From: Tristan @ 2013-12-19 17:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 17:24 ` Tristan @ 2013-12-19 18:30 ` Blake McBride 0 siblings, 0 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 18:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 15:58 ` Blake McBride 2013-12-19 16:30 ` Tristan @ 2013-12-19 17:59 ` Steffen Daode Nurpmeso 1 sibling, 0 replies; 50+ messages in thread From: Steffen Daode Nurpmeso @ 2013-12-19 17:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 14:52 ` Blake McBride 2013-12-19 14:55 ` erik quanstrom @ 2013-12-19 17:07 ` a 2013-12-19 18:40 ` Blake McBride 1 sibling, 1 reply; 50+ messages in thread From: a @ 2013-12-19 17:07 UTC (permalink / raw) To: 9fans // 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 17:07 ` a @ 2013-12-19 18:40 ` Blake McBride 2013-12-19 18:58 ` Kurt H Maier ` (6 more replies) 0 siblings, 7 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 18:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride @ 2013-12-19 18:58 ` Kurt H Maier 2013-12-19 19:06 ` Matthew Veety ` (5 subsequent siblings) 6 siblings, 0 replies; 50+ messages in thread From: Kurt H Maier @ 2013-12-19 18:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride 2013-12-19 18:58 ` Kurt H Maier @ 2013-12-19 19:06 ` Matthew Veety 2013-12-19 19:07 ` Kurt H Maier ` (4 subsequent siblings) 6 siblings, 0 replies; 50+ messages in thread From: Matthew Veety @ 2013-12-19 19:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride 2013-12-19 18:58 ` Kurt H Maier 2013-12-19 19:06 ` Matthew Veety @ 2013-12-19 19:07 ` Kurt H Maier 2013-12-19 19:20 ` Blake McBride 2013-12-19 19:09 ` a ` (3 subsequent siblings) 6 siblings, 1 reply; 50+ messages in thread From: Kurt H Maier @ 2013-12-19 19:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:07 ` Kurt H Maier @ 2013-12-19 19:20 ` Blake McBride 2013-12-19 19:27 ` Kurt H Maier 2013-12-19 19:35 ` a 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 19:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:20 ` Blake McBride @ 2013-12-19 19:27 ` Kurt H Maier 2013-12-19 19:42 ` Blake McBride 2013-12-19 19:35 ` a 1 sibling, 1 reply; 50+ messages in thread From: Kurt H Maier @ 2013-12-19 19:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:27 ` Kurt H Maier @ 2013-12-19 19:42 ` Blake McBride 2013-12-19 20:02 ` Kurt H Maier 0 siblings, 1 reply; 50+ messages in thread From: Blake McBride @ 2013-12-19 19:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:42 ` Blake McBride @ 2013-12-19 20:02 ` Kurt H Maier 2013-12-19 20:18 ` erik quanstrom 0 siblings, 1 reply; 50+ messages in thread From: Kurt H Maier @ 2013-12-19 20:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 20:02 ` Kurt H Maier @ 2013-12-19 20:18 ` erik quanstrom 2013-12-19 20:23 ` Kurt H Maier 0 siblings, 1 reply; 50+ messages in thread From: erik quanstrom @ 2013-12-19 20:18 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 20:18 ` erik quanstrom @ 2013-12-19 20:23 ` Kurt H Maier 0 siblings, 0 replies; 50+ messages in thread From: Kurt H Maier @ 2013-12-19 20:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:20 ` Blake McBride 2013-12-19 19:27 ` Kurt H Maier @ 2013-12-19 19:35 ` a 1 sibling, 0 replies; 50+ messages in thread From: a @ 2013-12-19 19:35 UTC (permalink / raw) To: 9fans // 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride ` (2 preceding siblings ...) 2013-12-19 19:07 ` Kurt H Maier @ 2013-12-19 19:09 ` a 2013-12-27 10:16 ` dexen deVries 2013-12-19 19:09 ` erik quanstrom ` (2 subsequent siblings) 6 siblings, 1 reply; 50+ messages in thread From: a @ 2013-12-19 19:09 UTC (permalink / raw) To: 9fans // 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:09 ` a @ 2013-12-27 10:16 ` dexen deVries 0 siblings, 0 replies; 50+ messages in thread From: dexen deVries @ 2013-12-27 10:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 [[[↓][→]]] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride ` (3 preceding siblings ...) 2013-12-19 19:09 ` a @ 2013-12-19 19:09 ` erik quanstrom 2013-12-19 19:29 ` Blake McBride 2013-12-19 19:12 ` Skip Tavakkolian 2013-12-19 19:26 ` sl 6 siblings, 1 reply; 50+ messages in thread From: erik quanstrom @ 2013-12-19 19:09 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:09 ` erik quanstrom @ 2013-12-19 19:29 ` Blake McBride 2013-12-19 19:39 ` Gabriel Diaz 2013-12-19 20:15 ` Richard Miller 0 siblings, 2 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 19:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:29 ` Blake McBride @ 2013-12-19 19:39 ` Gabriel Diaz 2013-12-19 20:15 ` Richard Miller 1 sibling, 0 replies; 50+ messages in thread From: Gabriel Diaz @ 2013-12-19 19:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:29 ` Blake McBride 2013-12-19 19:39 ` Gabriel Diaz @ 2013-12-19 20:15 ` Richard Miller 2013-12-19 20:28 ` Blake McBride 1 sibling, 1 reply; 50+ messages in thread From: Richard Miller @ 2013-12-19 20:15 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 20:15 ` Richard Miller @ 2013-12-19 20:28 ` Blake McBride 2013-12-19 20:45 ` Richard Miller 0 siblings, 1 reply; 50+ messages in thread From: Blake McBride @ 2013-12-19 20:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 20:28 ` Blake McBride @ 2013-12-19 20:45 ` Richard Miller 2013-12-20 15:23 ` Aram Hăvărneanu 0 siblings, 1 reply; 50+ messages in thread From: Richard Miller @ 2013-12-19 20:45 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 20:45 ` Richard Miller @ 2013-12-20 15:23 ` Aram Hăvărneanu 0 siblings, 0 replies; 50+ messages in thread From: Aram Hăvărneanu @ 2013-12-20 15:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride ` (4 preceding siblings ...) 2013-12-19 19:09 ` erik quanstrom @ 2013-12-19 19:12 ` Skip Tavakkolian 2013-12-19 19:22 ` Blake McBride 2013-12-19 19:26 ` sl 6 siblings, 1 reply; 50+ messages in thread From: Skip Tavakkolian @ 2013-12-19 19:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:12 ` Skip Tavakkolian @ 2013-12-19 19:22 ` Blake McBride 2013-12-19 19:43 ` Rudolf Sykora 0 siblings, 1 reply; 50+ messages in thread From: Blake McBride @ 2013-12-19 19:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:22 ` Blake McBride @ 2013-12-19 19:43 ` Rudolf Sykora 2013-12-19 19:58 ` Blake McBride 0 siblings, 1 reply; 50+ messages in thread From: Rudolf Sykora @ 2013-12-19 19:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 19:43 ` Rudolf Sykora @ 2013-12-19 19:58 ` Blake McBride 0 siblings, 0 replies; 50+ messages in thread From: Blake McBride @ 2013-12-19 19:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 18:40 ` Blake McBride ` (5 preceding siblings ...) 2013-12-19 19:12 ` Skip Tavakkolian @ 2013-12-19 19:26 ` sl 6 siblings, 0 replies; 50+ messages in thread From: sl @ 2013-12-19 19:26 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 22:46 ` Blake McBride 2013-12-19 5:40 ` erik quanstrom @ 2013-12-19 10:01 ` Richard Miller 2013-12-19 15:01 ` erik quanstrom 1 sibling, 1 reply; 50+ messages in thread From: Richard Miller @ 2013-12-19 10:01 UTC (permalink / raw) To: 9fans > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-19 10:01 ` Richard Miller @ 2013-12-19 15:01 ` erik quanstrom 0 siblings, 0 replies; 50+ messages in thread From: erik quanstrom @ 2013-12-19 15:01 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <CAC0DbM5safEHO_MFpBazvvH6CcGQXGTow-Fe7fkqkP6GrU1Xzw@mail.gmail.com>]
[parent not found: <CAC0DbM7S-xZvOSDwB6KoWH2X8ny_57F9mBE7gaB_BuWR5RSJiw@mail.gmail.com>]
* Re: [9fans] mk time-check/slice issue [not found] ` <CAC0DbM7S-xZvOSDwB6KoWH2X8ny_57F9mBE7gaB_BuWR5RSJiw@mail.gmail.com> @ 2013-12-18 23:09 ` Jason Catena 2013-12-19 5:47 ` erik quanstrom 0 siblings, 1 reply; 50+ messages in thread From: Jason Catena @ 2013-12-18 23:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [9fans] mk time-check/slice issue 2013-12-18 23:09 ` Jason Catena @ 2013-12-19 5:47 ` erik quanstrom 0 siblings, 0 replies; 50+ messages in thread From: erik quanstrom @ 2013-12-19 5:47 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2013-12-27 10:16 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-18 22:01 [9fans] mk time-check/slice issue Blake McBride 2013-12-18 22:08 ` Matthew Veety 2013-12-18 22:42 ` Blake McBride 2013-12-18 22:16 ` erik quanstrom 2013-12-18 22:46 ` Blake McBride 2013-12-19 5:40 ` erik quanstrom 2013-12-19 6:07 ` Bakul Shah 2013-12-19 10:59 ` Charles Forsyth 2013-12-19 14:21 ` Oleksandr Iakovliev 2013-12-19 14:58 ` erik quanstrom 2013-12-19 14:52 ` Blake McBride 2013-12-19 14:55 ` erik quanstrom 2013-12-19 15:58 ` Blake McBride 2013-12-19 16:30 ` Tristan 2013-12-19 16:37 ` Blake McBride 2013-12-19 16:40 ` Jacob Todd 2013-12-19 17:05 ` Blake McBride 2013-12-19 17:24 ` Tristan 2013-12-19 18:30 ` Blake McBride 2013-12-19 17:59 ` Steffen Daode Nurpmeso 2013-12-19 17:07 ` a 2013-12-19 18:40 ` Blake McBride 2013-12-19 18:58 ` Kurt H Maier 2013-12-19 19:06 ` Matthew Veety 2013-12-19 19:07 ` Kurt H Maier 2013-12-19 19:20 ` Blake McBride 2013-12-19 19:27 ` Kurt H Maier 2013-12-19 19:42 ` Blake McBride 2013-12-19 20:02 ` Kurt H Maier 2013-12-19 20:18 ` erik quanstrom 2013-12-19 20:23 ` Kurt H Maier 2013-12-19 19:35 ` a 2013-12-19 19:09 ` a 2013-12-27 10:16 ` dexen deVries 2013-12-19 19:09 ` erik quanstrom 2013-12-19 19:29 ` Blake McBride 2013-12-19 19:39 ` Gabriel Diaz 2013-12-19 20:15 ` Richard Miller 2013-12-19 20:28 ` Blake McBride 2013-12-19 20:45 ` Richard Miller 2013-12-20 15:23 ` Aram Hăvărneanu 2013-12-19 19:12 ` Skip Tavakkolian 2013-12-19 19:22 ` Blake McBride 2013-12-19 19:43 ` Rudolf Sykora 2013-12-19 19:58 ` Blake McBride 2013-12-19 19:26 ` sl 2013-12-19 10:01 ` Richard Miller 2013-12-19 15:01 ` erik quanstrom [not found] <CAC0DbM5safEHO_MFpBazvvH6CcGQXGTow-Fe7fkqkP6GrU1Xzw@mail.gmail.com> [not found] ` <CAC0DbM7S-xZvOSDwB6KoWH2X8ny_57F9mBE7gaB_BuWR5RSJiw@mail.gmail.com> 2013-12-18 23:09 ` Jason Catena 2013-12-19 5:47 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).