John Myers ([EMAIL PROTECTED]) scribbled: > A clarification: > I'm not talking about time estimation here. What I'm talking about is > having each provider provide a minimum of two pieces of data: the > number of subtasks it will run, and the number of subtasks which > have been completed.
So more like make saying "I have 33 files to compile, 13 are done"? > On Tuesday 01 February 2005 02:47, Jason Cooper wrote: > > John Myers ([EMAIL PROTECTED]) scribbled: [snip clarification] > > > 2) eprogressd (one for each master task, i.e. if you had an emerge and > > > some > > > other make running at the same time, they would be kept separated). the > > > eprogressd would run in the background and keep track of all the progress > > > data. > > > > Why not a single daemon which spawns a thread for each new program, ala > > sshd (although iirc sshd forks)? > > > I don't think I was clear here: the daemon would be started in the _user's_ > name (including root, if root started it (perhaps it should drop that?)), > once each time the _user_ invokes such a command. i.e. if a user said > emerge -uvD world > emerge would start, and then it would start a progress daemon. Child processes > of emerge would use the same daemon. I don't want to make a system-wide daemon > because most systems' time is not spent with the compiler (or whatever) > running > > Or maybe you understood me and I don't understand you? I understand what you're getting at now, it just took me a second or two. :) [snip gkrellm stuff] [snip 05:30 Cooper being a smartass] > > > Also, progress information does not have to be limited to a percentage > > > (though > > > that is required). The information could contain many things, like > > > compiler > > > command lines, warnings, errors, einfos etc. > > > > This is the line item requirement I would drive a truck through, if I > > were a customer/user. :) > I think i did not properly articulate myself here either: What I meant was > that > in addition to the subtask count and subtask completion count, a client could > send lots of other data, too. > > Or, again, perhaps you understand me, and I do not understand you. Sorry, I spend a lot of time focusing in on customer vagueness and nailing it down. If you don't nail it down, you get 15 great 'ideas' that are 'easy' to add two weeks before the delivery date, and contractually, you would have to do it, if you didn't force them to restrict scope in the beginning. In short, I understood what you were saying, I was just "highlighting an area needing further clarification", albeit colorfully. :) > > > Please let me know what you think. > > > > This idea has been floated many times before, with little success. > Darn. Well, the compile time prediction idea has had little success. > > Not > > to rain on the idea. :) The problem is much more complicated than it > > initially looks. For insight, take a look at the section in > > linuxfromscratch regarding SBUs (static bash units). > > > > http://archive.linuxfromscratch.org/lfs-museum/4.0/LFS-BOOK-4.0-HTML/chapter02/aboutsbus.html > I'm not looking to estimate the time left. I realize that that's impossible. Not impossible. Just that the potential gains are not worth the work involved to implement. With the adoption of the 2.6.x kernels, it's not as critical for most users to know how long something will take. For me personally, I never watch the 'emerge -uDav world' process. I start it on 4 machines, get a cup of coffee, and proceed with normal computer use. It doesn't interfere with user interaction at all, so I don't care if it takes 2 hours or 2.5. Just let me know when it's finished. > > Personally, I would do less planning and more writing, some of the best > > projects started off as a hack to scratch an itch. Keep it simple. A > > lot of the most useful programs out there are very small. It can always > > be rewritten later to include TCP/IP or threads. > Yeah, I just wanted to make sure the idea wasn't stupid. Now that I understand you're not trying to predict compile times, it seems much more feasible. However, I would most likely not use it simply because it doesn't solve a problem I have. Others opinions are certainly valid also. Is it worth pursuing? Well, if it solves a problem _you_ have, go for it. That's all that really matters. If you find it useful, most likely others will too. Cooper. -- gentoo-user@gentoo.org mailing list
