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.
On Tuesday 01 February 2005 02:47, Jason Cooper wrote: > John Myers ([EMAIL PROTECTED]) scribbled: > > 1) eprogress progress providers (clients?) (perhaps through some sort of > > libeprogressc). These are programs like emerge, make, gcc, etc. which have > > some sort of goal, and can report on their progress. They would need to be > > patched to provide the system with the progress information. > > I would advise against any development path that required patching many > different projects. There would be a lot of resistance. This also > seems to be passing off the crux of the problem (determining length of > compile time) to the developers of make/gcc/ldd etc. See BUs, below. I almost forgot my (partial) solution to that: For some of the programs (gcc especially), one can write a wrapper which calls GCC and collects its output, possibly supressing it from the console, and passes it up to the framework > > > 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? > > > 3) eprogress viewers which communicate with eprogressd to display a > > representation of the progress data. There could be any number of > > interchangeable viewers, some for console, some for X11. Some may be > > specialized to a particular task (such as a special one for emerges), but > > all > > would use the same protocol to talk to the eprogressd, which would be kept > > generic (there could (should?) be some sort of libeprogressviewer to help > > with this) > > gkrellm? a plugin to gkrellm could be one of the several viewers. I do, however, want to write at least console and full-blown graphical viewers > > > I would suggest that the system should use UNIX domain sockets or TCP/IP > > sockets for the communication, especially TCP/IP for the viewer connection. > > It should not be necessary for the viewer to reside on the same machine as > > the daemon. Nor, for that matter, should it be necessary for individual > > tasks > > to be performed on the same machine. > > Good idea, but there is no need to suggest, it's your project :) I guess you're right... I mostly put it in there to see if it was stupid. > > 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. > > > Please let me know what you think. > > This idea has been floated many times before, with little success. Darn. > 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. > 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. > Good luck! Thanks! I have lots of other ideas too, by the way, but I think I'll focus on this one for now. -- t3h 3l3ctr0n3rd <[EMAIL PROTECTED]> Supermarket Deli Clerk and Student Programmer
pgpbysCNFfsv1.pgp
Description: PGP signature
