dfGUI v3.0 for Win available (For Phase II)

With Phase II of DF supposed to be starting tomorrow (Tuesday), I am releasing v3.0 of dfGUI wich has a new look and interface. This version will only work with Phase II of the DF project (it also works with the Phase II beta client so you can try it out now if you have a copy).

You can get it in the regular location:
http://gilchrist.ca/jeff/dfGUI/

v3.0 (Jun. 16, 2003)
- NOTE: This version will only work with the new Phase II of Distributed Folding and will not work with the Phase 1 client.

- Changed look of dfGUI adding tabs to simplify the user interface

- Removed obsolete switches that are no longer in Phase II.

- "Save Config" now gives you a confirmation window letting you know if the .ini file was saved properly or not.

- GUI now displays information about generations.

- GUI has 3 bar graph displays for the current structure laxness level. If a protein gets stuck 3 times it will increase the laxness level for that generation and this value will be shown in the 3 graphs. If the graph reads 0% that means it has not relaxed any of the parameters.

- Due to the way generations work, the benchmark data will get reset when a new generation begins.

- Removed structures per second and minute since the new beta works more slowly these values no longer make sense.

- # generations is configurable in Config window.

- Added display to keep track of best energy seen since you started the GUI and shows which generation # it was found in.

- Added display to indicate time it took to complete the previous generation and average generation time.

- Benchmark output to file info now shows current generation.

- Best energy so far now shows which generation # it was found in.

- Added Tab to display history of best energy seen for each generation (this data is saved to dfGUI.gen to survive the GUI being closed).

- Added Tab to graph the best energy vs generation to see a visual representation of how your DF client is doing. The maximum number of points graphed per page is also configurable.

MD5 Sum:
31fa52fa913f0c7199f72c4f08835997 dfGUIv30.zip
93ddef515b0ed26fd92219430672ca1a dfGUIv30src.zip

If you have any problems please let me know.

Jeff.

Screen Shots:

You can find more screenshots here.

thank you

:notworthy :notworthy :notworthy

And as always DfGui Rules!

:cheers:

You are the absolute BEST Jeff!

-Sid

PS: What is '# generations'?

Thanks for all the nice comments everyone.

Quote:

---

Originally posted by Insidious
PS: What is '# generations'?

---

If you haven't seen the beta version of the client, it now works in generations. During the beta there was 250 generations but that could change so I made that value configurable in the GUI so people could modify it themselves instead of having to download a new version of the GUI.

Jeff.

Thanks DP,

I'm half-way home...

The next questions would be.... how will I determine what to set it to.

What happens if I accidentally set it incorrectly?

Sid

Quote:

---

Originally posted by Insidious
The next questions would be.... how will I determine what to set it to.

What happens if I accidentally set it incorrectly?

---

Then your gen percentage and gen % bar graphs will be off. Whoop-de-doo. ;)

Unless something else changed in 3.0 that depends more on that (maybe I should just keep my mouth shut, Jeff? :p).

There will be a Linux version of 3.0, too... umm, sometime. I haven't had a lot of time lately to do stuff like this, but hopefully I will in the coming week(s). With any kind of luck... I'll post back when it's ready, in any case.

Quote:

---

Originally posted by Insidious
The next questions would be.... how will I determine what to set it to.

What happens if I accidentally set it incorrectly?

---

If you look at the docs when the Phase II client is released, I'm sure Howard will mention somewhere how many generations it will be.

As bwkaz said, if you set it incorrectly it just means that your generation bar graph and percentage will be off since the GUI won't know the total # of generations to expect.

Jeff.

Thanks folks

Quote:

---

Originally posted by bwkaz

There will be a Linux version of 3.0, too... umm, sometime. I haven't had a lot of time lately to do stuff like this, but hopefully I will in the coming week(s). With any kind of luck... I'll post back when it's ready, in any case.

---

Yay! to dfGUI for Windows...double Yay! for the Linux version :p

If/when you do release Linux dfGUI could you supply the exceutable (a la dfGUI for Beta 4)

Once again - many :cheers: to dfGUI :jester:

IGNORE THIS POST!
It seems the client itself IS actually stopping on it's own when run in service mode.

Dammit! :swear:

-----------------------------------------

Hey Jeff, having a problem with it on the new client.

I have a service install (2 cpu's) and it keeps switching and saying "client appears to be stopped" when it is still actually running.

I hit start client and it comes right back up.

Thanks for dfgui btw! Great little app :cheers:

Not sure if this is problem due to it being the first run or dfGUI is not picking up gen 1 (or 5 or 6 :p) properly but:





looks odd to me :crazy:

/edit - changing Progress Update to 1 seems to get round the problem...

pfb, that was a problem I logged with Howard during the beta but he wasn't able to reproduce it. For me, if I didn't select update after 1 protein, it often never updated the progress.txt file properly when starting from generation 0.

As soon as the client finished the first generation, dfgui posted the following error message:
'11.267' is not a floating point value.

It keeps in printing that error message once every 10 seconds (I have set it to refresh every 10 secons). The number changes according the number stated in the filelist.txt file, but the text in the error message is the same.

Whats wrong? :(

Quote:

---

Originally posted by mighty
As soon as the client finished the first generation, dfgui posted the following error message:
'11.267' is not a floating point value.

---

Hmmmm. Can you e-mail me your dfGUI.gen file?

Jeff.

Quote:

---

Originally posted by Digital Parasite
Hmmmm. Can you e-mail me your dfGUI.gen file?

Jeff.

---

I have solved the problem in the meantime.

It seems that if you use , for decimal separator (as we do in Denmark) it gives the error. Under "Control Panel->International" I changed the decimal separator to . and it works.

Any way you can check for that in some future version?

I love this new version by the way. Keep up the excellent work.

Quote:

---

Originally posted by mighty
It seems that if you use , for decimal separator (as we do in Denmark) it gives the error. Under "Control Panel->International" I changed the decimal separator to . and it works.

Any way you can check for that in some future version?

---

Oh wow, I never would have expected that. I never realized that changing your OS decimal seperator would affect underlying math routines. I figured it would just modify how Windows displays values to the user.

I just tried changing the settings myself and see what is going on but I don't think there is anything that I can do. Somehow windows manages to change how floating point values are handled inside code that is already compiled. There are floating point values used inside the dfGUI code which uses periods (ie: 3.34) so it seems that it will not run on any machine that has their decimal seperator changed.

I don't have any experience with writing code for international versions of Windows but I wonder how other people handle this problem since many programs use floating point values? Or is this just a strange artifact of the Borland C++ compiler that is not affected with something like MS Visual C++?

Jeff.

I had the same problem but changing the decimal solved it for me also.
mine stopped at 15.544 now its running fine again :cool:

I didn't look at the progress.txt file so can't help you with that.
But I can tell you I'm running Win XP.

I reset one of my systems back to the old setting and got a error (the same) back right away.

In the dfGUI.gen file are no "," only "."

When I use the foldit.bat file the program runs normal

Quote:

---

Does having your decimal seperator settings set to ',' causes the DF client to write a comma to the file?

---

No, it writes a "."

Hope it helps you.

Jeff,

Great GUI... Love the new INFO, Graphs and All.

It did give me pause when it would not just look at the distribfold sub-directory and show me progress at first (I installed dfGui in its own sub-directory). It complained that foldit.bat was not valid or available (or something like that) and indicated that DF folding was not running.

However, when I "Q"ed the foldit task manually and then started it via dfGui, everything came up as it should.

I've always run my DF clients as straight DOS tasks. I see lots of compaints when it is run as a service, so I avoid it.

Thanks Again Jeff..

Ned

Quote:

---

Originally posted by pfb
If/when you do release Linux dfGUI could you supply the exceutable (a la dfGUI for Beta 4)

---

When I do release a new version, it'll use autoconf and automake (this means it will have the "./configure, make, make install" installation process just like almost every other package in existence for Linux). Is that good enough, or do you still want a precompiled executable?

I can do it, it's just that I'm almost POSITIVE that it won't work on a lot of other systems (my machine is running glibc 2.2 or 2.3, depending on which partition I boot to, and if you aren't running whatever version I compile against, it may not work). I suppose I could compile it twice, but then the space gets a little much... Whatever. Let me know. :)

Quote:

---

Originally posted by Nofinger
No, it writes a "."

---

Jeff, it sounds to me like this is the problem.

The original error was "<number with a .> isn't a valid floating point value", and in that locale, it isn't (floating-point values need to have commas in them in that locale).

To anyone having this problem -- if you set your locale's separator to a comma, then edit the dfGUI config (or .gen) file yourself to make them commas, does it at least work for a short time?

The DF client probably needs to be changed to write commas in its log file, too, so this won't work for very long, but if dfGUI will at least read its config file, then that'll at least give a bit of direction.

Quote:

---

Originally posted by bwkaz
Jeff, it sounds to me like this is the problem.

The original error was "<number with a .> isn't a valid floating point value", and in that locale, it isn't (floating-point values need to have commas in them in that locale).

To anyone having this problem -- if you set your locale's separator to a comma, then edit the dfGUI config (or .gen) file yourself to make them commas, does it at least work for a short time?

The DF client probably needs to be changed to write commas in its log file, too, so this won't work for very long, but if dfGUI will at least read its config file, then that'll at least give a bit of direction.

---

No, that is not the problem. By default, dfGUI fills up unknown generations with a single period '.' I just decided to use that character but could have picked anything. That has nothing to do with floating point values. It reads the data in as text and only tries to use the value if it is not a single . character.

It doesn't matter if you can change the log files to be commas because internally in the source code there are things like b = c / 2.5; and that is where it will also generate errors. That is the part where I don't think I can do anything about it.

Jeff.

Quote:

---

Originally posted by bwkaz
When I do release a new version, it'll use autoconf and automake (this means it will have the "./configure, make, make install" installation process just like almost every other package in existence for Linux). Is that good enough, or do you still want a precompiled executable?

I can do it, it's just that I'm almost POSITIVE that it won't work on a lot of other systems (my machine is running glibc 2.2 or 2.3, depending on which partition I boot to, and if you aren't running whatever version I compile against, it may not work). I suppose I could compile it twice, but then the space gets a little much... Whatever. Let me know. :)

---

Could the pre-compiled executable be offered as a separate download? When I downloaded dfGUI 2.1 it would never compile but the executable offered with the beta dfGUI worked flawlessly...:looney:

Quote:

---

Originally posted by Digital Parasite
pfb, that was a problem I logged with Howard during the beta but he wasn't able to reproduce it. For me, if I didn't select update after 1 protein, it often never updated the progress.txt file properly when starting from generation 0.

---

I've seen that problem on 2 boxen today!

For windows, it seems that just opening the file in notepad a time or three releases it and it starts to update. Nothing to do with dfGui, the progress.txt just doesn't update the best "gen" sometimes.

For Linux, it took a restart.

It's almost as if the file didn't get closed properly somewhere or somehow. Then opening and closing seems to set things right again.

Quote:

---

Originally posted by Digital Parasite
I don't have any experience with writing code for international versions of Windows but I wonder how other people handle this problem since many programs use floating point values? Or is this just a strange artifact of the Borland C++ compiler that is not affected with something like MS Visual C++?

---

No, Jeff. This is a problem that - so far - appears to occur exclusively with your dfGUI. Would be a desaster if it wasn't like that. Many people from our team encountered that problem. The most strange thing for me was that after stopping dfGUI and restarting, the error message appeared and dfGUI did not even open anymore (in all other cases I came across the error message comes up and after that I could still continue to use the monitor). So, as sad as it is - under these conditions I cannot use your monitor anymore (since - for other reasons - it is not acceptable to change the country settings in the OS).

Michael.

Hello,

I post from France, so I have exactly the same issues (under XP and NT) as Michael H.W. Weber, as we also use here the comma and not the dot as a decimal separator. And I also can't change my national settings to "English" without numerous and unpredictable side-effects on other applications.

As an immediate workaround, perhaps you could give a link to download V2.2beta4 that I have successfully tested during the beta test, on the same environnments.

Furthermore, I'm not a developer myself, but I'm pretty sure other members are professionals who have experience in multinational development, and may help you solve this issue.

With all my hopes...
:notworthy

Same here :bang:

I'm now using PK's DCMonitor, which is also great, but it is intended to check several clients and give basic info about them, whereas dfGUI is for a single client and provides a lot more info.

/me hopes Jeff will be able to fix this somehow :notworthy

Quote:

---

Originally posted by gleyeny
As an immediate workaround, perhaps you could give a link to download V2.2beta4 that I have successfully tested during the beta test, on the same environnments.

---

So the 2.2beta4 version worked fine for you...

Ok, well I will put up the 2.2beta for now until I figure out what is going on. Everyone can download it here:
http://gilchrist.ca/jeff/dfGUI/dfGUIv22beta.zip

Jeff.

OK, I'm trying to figure out if when you have your decimal seperator set to ',' if programs that normally use decimals will write those to the output file.

Can a few people who are still running with theirs set to a comma ',' please e-mail me their progress.txt file (or post it here).

It seems that initially dfGUI works fine, but only starts giving you these errors of you shut down the GUI and restart it again?

Jeff.

the client autoupdated and I updated dfGUI to ver. 3 and not too long thereafter, I went to bed. When I got up, dfGUI had shutdown and I got that error when I tried to start it again :(

I'll try a clean install and send you the info you request :)

As far as I understand, this is the problem:
the DF client saves a line

Quote:

---

Best Energy so far: 9.329

---

in the progress.txt.
Your dfGUI parses this line with

Quote:

---

inProgressFile [...] >> bestenergy;

---

where bestenergy is a double.
The >> operator for some reasons uses the locale settings on the machine, and therefore needs a ',' on german systems; there is no ',', and the dfGUI throws an exception.

So, why don't you parse the value as char[], split it at the '.' and transform it to double:

Code:

---

#include <math.h>
[...]
    char temp[20] = {"bad"};
[...]   
    inProgressFile >> progtext >> progtext2 >> structcomplete
                    >> progtext3 >> currentgeneration
                    >> structremain >> progtext4 >> progtext5 >> progtext6
                    >> generationsbuffered >> progtext7 >> progtext8
                    >> progtext9 >> progtext10 >> progtext11 >> progtext12
                    >> temp;
    // close file
    inProgressFile.close();
   
[...]
    char *pos;
    pos = strtok(temp, ".");
    char *in = pos;  // in = integer part before the .
    pos = strtok(NULL, ".");
    char *fr = pos;  // fr = fractional part after the .
    bestenergy = atof(in) + atof(fr)* (1.0 / pow(10, strlen(fr)));  // here: bestenergy = 9.0 + 329.0 * 1/1000 = 9.329
[...]

---

:elephant:


EDIT: I don't have Borland C++ Builder 6 and couldn't test it, but it should work.
Hope my English is good enough, /me is a german guy ;)

Quote:

---

Originally posted by Digital Parasite
OK, I'm trying to figure out if when you have your decimal seperator set to ',' if programs that normally use decimals will write those to the output file.

Can a few people who are still running with theirs set to a comma ',' please e-mail me their progress.txt file (or post it here).

It seems that initially dfGUI works fine, but only starts giving you these errors of you shut down the GUI and restart it again?

Jeff.

---

Yes. I have EN winXP, but with hungarian regional settings. I changed back to US, and now it is fine.:hifi:

Quote:

---

Originally posted by Gras
[B]As far as I understand, this is the problem:
the DF client saves a line in the progress.txt.
Your dfGUI parses this line withwhere bestenergy is a double.
The >> operator for some reasons uses the locale settings on the machine, and therefore needs a ',' on german systems; there is no ',', and the dfGUI throws an exception.

---

Actually I don't think that is the problem since people are saying that v2.2beta worked fine for them and it used the same >> operator to get the value from the progress.txt file.

It must be something new that I added since then. I will try and track down exactly where it is failing so I can try to solve the problem.

Thanks for taking a look at the source, much appreciated.

Jeff.

Jeff,

Thks for the link to the beta.

To be precise, the problem appears after generation 0 has been uploaded, that is the dfGUI.gen file is, as fas as I understand, updated, dfGUI trying to read (in progress.txt ?) and store (in dfGUI.gen ?) the best energy so far for each generation from 001.

Afterwards, the message "XX.XX is not a valid floating point value" appears each time a refresh is done, either automatically through the timer or manually through the provided "Refresh" button.

If I stop dfGUI (without stopping DF client itself), and try to restart dfGUI, I then get the error message as a starter, and dfGUI doesn't even launch.

If I stop DF client (deleting foldtrajlite.lock), and then launch dfGUI, it starts without error. I start DF client ("Start client" button) and everything runs smoothly ... until the first refresh. Back to the initial issue.

Hope it can help

I found the function that is causing the problem. It is something specific to Borland's compiler.

Borland uses an AnsiString type which makes working with strings very easy. Unfortunately the conversion functions seem to check the locale settings and generate an error if the data doesn't conform.

So for example the following code works just fine, even though I am using a period in the number and my locale is set to use commas:

double testval = 2.453;

But if I use the AnsiString function:

AnsiString FloatValue = "2.453";
double testval = FloatValue.ToDouble();

It will fail on the .ToDouble() call. So I will have to re-write my code so that it doesn't use any AnsiString calls with the floating point value conversions and that should fix the problem.

I'm not sure how quickly I will be able to release a new version so in the mean time as I said above, those people using , in their locale can download and use the v2.2beta posted on the main dfGUI web site for now:
http://gilchrist.ca/jeff/dfGUI/dfGUIv22beta.zip

I'm sorry for the trouble this is causing but I had no idea this kind of error could occur with that code.

Jeff.

Correct, the bug is in FindBestEnergyGen().

Code:

---

AnsiString FloatValue = BestEnergyList[i];
          if (FloatValue.ToDouble() < BestEnergySeen) {...}

---

This conversion throws the exception.

Why do you use AnsiString?
Try

Code:

---

double FloatValue = atof(BestEnergyList[i]);
          if (FloatValue < BestEnergySeen) {...}

---

or the code I posted before.

(Again, not tested in your source code)

Well, the good thing is that you/we now know what causes the error!

Thanks for your quick reaction to this (for many people, *very serious* :bang: ) problem :notworthy :thumbs:

Quote:

---

Originally posted by Gras
Why do you use AnsiString?

Try

Code:

---

double FloatValue = atof(BestEnergyList[i]);
          if (FloatValue < BestEnergySeen) {...}

---

or the code I posted before.

---

I used it because it is easy to use and all the Labels and Text fields in the GUI are AnsiString types.

As you pointed out and I said above, I should be able to get rid of using the AnsiString conversion and I should be fine. I just have to go and change the code now when I have some free time.

Jeff.

All of the locale issues notwithstanding, I absolutely love the new features in version 3.0. :notworthy

Hey Jeff! Me again.

When you have time do you think you could explain the whole "Structure Laxness Levels" thing?

I understand that the percentages increase/decrease based on the number of times the protein gets stuck, but I'm confused as to what exactly the percentages mean and why there are 3 of them.

:smoking:

Thanks!

bunker