app_info.xml question

Message boards : Questions and problems : app_info.xml question
Message board moderation

To post messages, you must log in.

AuthorMessage
kevin6912

Send message
Joined: 13 Dec 08
Posts: 6
United States
Message 23733 - Posted: 16 Mar 2009, 14:40:47 UTC

Should my client_state.xml have a copy of every <app_version> tag listed in the app_info.xml?

ID: 23733 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15482
Netherlands
Message 23734 - Posted: 16 Mar 2009, 15:33:55 UTC - in response to Message 23733.  
Last modified: 16 Mar 2009, 15:34:20 UTC

If the question is if you should add them yourself, then no.
If it was to ask if it's correct that the state file has them, then yes that's correct. It will add these automatically.
ID: 23734 · Report as offensive
kevin6912

Send message
Joined: 13 Dec 08
Posts: 6
United States
Message 23739 - Posted: 16 Mar 2009, 17:46:41 UTC - in response to Message 23734.  

Thanks. Jord

Few more questions:

If I defined three versions in the app_info.xml I was expecting the same three versions in my client_state.xml. Even if the client_state.xml did not have that version before. That is not what I am seeing.

How does boinc decide what to drop from my app_info.xml when merging it into my client_state.xml?

Example:
I have version 602, 603, and 608 <app_version> defined in app_info.xml. I am only getting 608 <app_version> in the client_state.xml.

Regards,
Kevin
ID: 23739 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15482
Netherlands
Message 23740 - Posted: 16 Mar 2009, 19:02:53 UTC - in response to Message 23739.  

As far as I know, it'll only show the tags for the applications that have work.
ID: 23740 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5082
United Kingdom
Message 23741 - Posted: 16 Mar 2009, 21:14:13 UTC - in response to Message 23739.  

Thanks. Jord

Few more questions:

If I defined three versions in the app_info.xml I was expecting the same three versions in my client_state.xml. Even if the client_state.xml did not have that version before. That is not what I am seeing.

How does boinc decide what to drop from my app_info.xml when merging it into my client_state.xml?

Example:
I have version 602, 603, and 608 <app_version> defined in app_info.xml. I am only getting 608 <app_version> in the client_state.xml.

Regards,
Kevin

Those sound like SETI numbers.

In all BOINCs up to v6.4.7, the version numbers refer to the application - in this case, I'm guessing 'setiathome_enhanced'. So, even if the version sections actually refer to different programs (say, a CPU program and a CUDA program), BOINC thinks they're all talking about the same thing, assumes they're functionally equivalent, and the only one you want is the newest, latest and greatest, right? So in your example case, it'll hang on to 608, but throw away 602 and 603 as soon as it thinks you've finished with them - which, as Jord says, will be when you've finished the last work for them. And since it will never fetch any new work for older versions, that'll be quite soon.

BOINC v6.6.14/15, on the other hand, considers both the application and the plan class - e.g. CUDA. So you can have a version 603 without a plan class, and a version 608 with plan class CUDA, it will keep/use both versions. But the downside is you have to include much more detail in the app_info file if you want it to work with v6.6.15: if you can do that (there's an example posted on the SETI boards), then v6.6.15 is worth upgrading to.
ID: 23741 · Report as offensive
kevin6912

Send message
Joined: 13 Dec 08
Posts: 6
United States
Message 23745 - Posted: 16 Mar 2009, 23:29:05 UTC - in response to Message 23741.  

Thank you,

Jord and Richard

That explains it. I did look over the wiki. I don't recall the detail about Boinc removing old app versions.
I would have preferred Boinc did not remove the older versions. But that is what I am left with. My VBScript program I was working on will have to wait or I upgrade to the Boinc 6.6.15 beta. I prefer getting all the information on changes to client_state.xml from the client_state.xml.

I am running 6.6.15 on one of my PC. It seems stable. It also has the information I need in the client_state.xml file.

Kevin
ID: 23745 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5082
United Kingdom
Message 23747 - Posted: 16 Mar 2009, 23:48:30 UTC - in response to Message 23745.  

Thank you,

Jord and Richard

That explains it. I did look over the wiki. I don't recall the detail about Boinc removing old app versions.
I would have preferred Boinc did not remove the older versions. But that is what I am left with. My VBScript program I was working on will have to wait or I upgrade to the Boinc 6.6.15 beta. I prefer getting all the information on changes to client_state.xml from the client_state.xml.

I am running 6.6.15 on one of my PC. It seems stable. It also has the information I need in the client_state.xml file.

Kevin

Ah, so that's what you're trying to do.

There's a way of fooling it. If you add a <file_ref> entry in the latest, current app_version (608 in your case), with the file name of the old (603) application - though not as main_program, obviously - that will keep the application file from being deleted from disk.

Don't worry about client_state. I'm pretty sure that if BOINC finds a 603 reference in a workunit/result as it starts up, and there's a matching 603 entry in app_info and the necessary file on disk, it'll sort itself out without complaint.

If you're writing the script I think you're writing (and somebody else writing the same script has already consulted me about this), then for BOINC v6.6.15 you also need to remove the plan_class line from the result block. Otherwise the task errors on restart.
ID: 23747 · Report as offensive

Message boards : Questions and problems : app_info.xml question

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.