Re: [9fans] mk time-check/slice issue
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
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
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
On 19 December 2013 06:07, Bakul Shah ba...@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.
Re: [9fans] mk time-check/slice issue
On 12/19/2013 11:59 AM, Charles Forsyth wrote: On 19 December 2013 06:07, Bakul Shah ba...@bitblocks.com mailto:ba...@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?
Re: [9fans] mk time-check/slice issue
On Wed, Dec 18, 2013 at 11:40 PM, erik quanstrom quans...@quanstro.netwrote: 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
Re: [9fans] mk time-check/slice issue
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
On 12/19/2013 11:59 AM, Charles Forsyth wrote: On 19 December 2013 06:07, Bakul Shah ba...@bitblocks.com mailto:ba...@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
On Thu Dec 19 05:02:50 EST 2013, 9f...@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
Re: [9fans] mk time-check/slice issue
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
On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@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
Re: [9fans] mk time-check/slice issue
No one is stopping you from changing it in your installation. On Dec 19, 2013 11:38 AM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@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
Re: [9fans] mk time-check/slice issue
Yea, got that. I just thought it made sense for a wider audience. On Thu, Dec 19, 2013 at 10:40 AM, Jacob Todd jaketodd...@gmail.com wrote: No one is stopping you from changing it in your installation. On Dec 19, 2013 11:38 AM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@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
Re: [9fans] mk time-check/slice issue
// 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
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 bl...@mcbride.name wrote: |On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom quanstro@\ |quanstro.netwrote: | | 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 ---BeginMessage--- On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom quans...@quanstro.netwrote: 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 ---End Message---
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 11:24 AM, Tristan 9p...@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.
Re: [9fans] mk time-check/slice issue
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
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@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
Quoting Blake McBride bl...@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
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
// 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
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
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 bl...@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
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:07 PM, Kurt H Maier k...@sciops.net wrote: Quoting Blake McBride bl...@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
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:12 PM, Skip Tavakkolian skip.tavakkol...@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.
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@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
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
Hello, On 19 December 2013 20:22, Blake McBride bl...@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
On Thu, Dec 19, 2013 at 1:43 PM, Rudolf Sykora rudolf.syk...@gmail.comwrote: Hello, On 19 December 2013 20:22, Blake McBride bl...@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
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom quans...@labs.coraid.comwrote: 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
// 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
On Thu, Dec 19, 2013 at 1:27 PM, Kurt H Maier k...@sciops.net wrote: Quoting Blake McBride bl...@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
Re: [9fans] mk time-check/slice issue
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 bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom quans...@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
Quoting Blake McBride bl...@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
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
Quoting erik quanstrom quans...@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
On Thu, Dec 19, 2013 at 2:15 PM, Richard Miller 9f...@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
Re: [9fans] mk time-check/slice issue
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.
[9fans] mk time-check/slice issue
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
Re: [9fans] mk time-check/slice issue
On Dec 18, 2013, at 17:01, Blake McBride bl...@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
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
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 mve...@gmail.com wrote: On Dec 18, 2013, at 17:01, Blake McBride bl...@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
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
Re: [9fans] mk time-check/slice issue
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
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
Re: [9fans] mk time-check/slice issue
On Thu, 19 Dec 2013 00:40:52 EST erik quanstrom quans...@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?
