dfGUI v1.0 for Windows Released (with Source)

Hi everyone,

I have finally released v1.0 of dfGUI with all the features that have been requested. You can get it in the usual spot:
http://gilchrist.ca/jeff/dfGUI/

The source code is also now available from the web site too if anyone is interested.

v1.0 (June 5, 2002):
- Program is stable enough for a 1.0 release. Source code for dfGUI is now available on dfGUI web site.
- Added ability to run dfGUI from any directory and monitor a client on a remote machine (using network UNC paths). dfGUI will save last DF client being monitored in INI file. If you want to run hidden you must put runh.exe in your dfGUI directory.

Enjoy,
Jeff.

Wonderful. =)

Great work. :)

thanks again, Jeff... :)

Hey Jeff,
Thanks for this little jewel. I was wondering if you had read this thread and if you had given any thought to implementing a timed stop restart feature. Maybe with a date and time input. It could make updates to the win client nearly effortless.

You mean like if the next update was supposed to be at say just pulling out of the air, Tuesday at noon EST, you could get the client to stop around there to upload the current structures and then restart so it would hopefully upgrade to the new client?

I'm not sure if it would be able to do both, upload the structures at the last minute and then do an upgrade since the server is usually down for a little while the changeover happens.

What would people prefer, being able to upload their structures at the last second or forcing it to restart when they think the new client will be online so it will do an auto-update faster than it might normally?

I guess the feature would be implemented the same it would just depend on the time you picked to force the upload/restart?

Jeff.

I LIKE the idea of being able to set the upload interval myself! :p I think I've read in one thread or another that this is a planned enhancement somewhere down the road...

From the updates I've watched, I don't believe you're going to have a seamless update the way Weber talks about it in the thread Chris mentions. However, if I've got a box that only uploads every 6 hours due to the length of the protein, it's going to lose an average of 3 hours' work on the update. But clever me, running dfGUI, sets it to upload every hour and the average wasted processing time on update drops to 30 minutes!

Of course, if you set it to upload too often, (a) you're going to incur the Wrath of Howard :sleepy: for exercising his server and (b) you're also going to process more slowly overall, 'cause stopping, uploading, and restarting ain't exactly instantaneous. And of course, it won't work with running as a service...

I think its a great idea...

set it to upload at a user defined preset interval - say every hour... also with a toggle to turn the autoupload off after the update is completed... maybe even allow users to set an active date/time range for the feature, like start hourly uploads at Tuesday morning at 10am and stop hourly uploads at Tueaday afternoon at 3pm...

this would really minimize the "lost" work due to the update to whatever you process in an hour, instead of the full 3000 structures...

And since my last post, KWSN-M2KGuy posted in that other thread:

Quote:

---

If you wait until the official letter shows up from Howard that the next client is available, I have been able to connect immediately after the notice and get the farm up and running again.

In winblows, you use to remotely start the client:
netsvc /start ComputerName "Distributed Folding Project Service"

To stop the service:
netsvc /stop ComputerName "Distributed Folding Project Service"

To install the new distribution files, unzip and place them in some folder somewhere, lets call it "c:\SourceDir". Be sure to put your handle.txt and proxy.cfg files in that folder. Then run the following commands to push the files out:
delete \\ComputerName\ShareName\DFFolderName\*.*
copy c:\SourceDir\*.* \\ComputerName\ShareName\DFFolderName

Follow that with the startup commands and you are good to go.

---

...which should take care of the service aspect. :)

Sound like a great feature except for one thing: the server.

Howard sets the update interval to a given number (3000 structures for the current protein) to help keep the number of connections to the server down (this has happened with an previous small protein).

This feature would override that, so I think Howard should be asked before implementing such a feature.

Ahhh, but Howard sets the same number for all boxen, regardless of speed, OS, usage, etc., etc. It's quite acceptable to me for my gutsy machines to upload every 3 hours. It's not so neat for my older iron that takes up to 7 hours.

What we're talking about is changing the upload trigger from units completed to time spent.

We can already do this with cron in *nix or task scheduler in Windoze. We're just debating making it easier for the masses. As I said before, uploading too often is self-defeating because of the time it takes away from crunching.

I agree that it is something that is already done and can currently be done.

However, making it 'easier for the masses' is a serious issue. I had contemplated requesting this feature as well, but had not yet because I couldn't think of an elegant solution. I think that Howard should probably be contacted, though I imagine he is busy at the moment. Probably a bit late to implement anything for this change-over anyways.

My stance on this is that if some idiot wants to upload every 3 structures and hammer the server, then he ought to atleast have to have enough technical knowledge to script up something that enable such behavior in the first place. Of course, this pretty much ensures that no one will upload every 3 structures, because someone with sufficient technical knowledge and patience to script something of this sort isn't likely to be so impatient and irresponsible that they do something like that.

However, setting that the upload interval (in terms of time) to something along the lines of a couple hours should be feasible. Perhaps set it to the shortest known structure SET completion time, i.e. how fast can the fastest computer running DF complete 3,000 structures and then upload them naturally?

Allowing the user to define the upload interval would also help to avoid lost work due to crashes/outages since the program apparently only checkpoints after each structure set is completed, which can vary from several hours to a day (I don't know how long this P1 200 takes for 3k structures but I know it is a LONG time).

LOL! :jester:

I know what you mean there! I fired up my oldest machine last week to pull some of my assembler code off it onto my current development box. The old box is a p1 133. It booted so slowly I thought some critical part had died. Turns out, I had just forgotten how slow it ran. And this was the pride of my collection just a couple of years ago!

Ah well. Maybe our plea for "timed uploads" will be heard. Sure would make this whole business a lot more predictable and maybe prevent some ranting, such as has occurred lately. AND, if Howard & company do it, then they can set some reasonable limits on it, like say, minimum one hour between uploads or some such.

I will allow a user-adjustable upload interval once our new more robust back-end is in place (coming soon...). As long as I force a reasonable minimum of, say, 500 structures, the servers should handle it fine after this change. Until then, I am the puppet master - mwu-ha-ha-ha-ha :scared:

And you ARE a fierce one, Bwana! :notworthy :notworthy :notworthy

I was just going to say that I was talking with Howard and it seemed best not to add such a feature to dfGUI for the time being because there were some possible interesting changes coming with the new back-end but I see the puppet-master has already spoken. ;)

Jeff.