The first new astropulse results are appearing.

We only have an x86_64 application ready. Josh will be compiling other linux and solaris in the next few days. Maybe even MacOS. No graphics yet. That's mostly my fault.

Eric

Yay :-)

I'll try to make a FreeBSD port this weekend, with a big beta-disclaimer...

---

The first new astropulse results are appearing.

We only have an x86_64 application ready. Josh will be compiling other linux and solaris in the next few days. Maybe even MacOS. No graphics yet. That's mostly my fault.

Eric

Yay :-)

I'll try to make a FreeBSD port this weekend, with a big beta-disclaimer...

Just a sanity check: the most recent source archives live at
http://setiathome.berkeley.edu/ap_source/nightly/ , right?

(these are from 2005/11/03)

---

Just a sanity check: the most recent source archives live at
http://setiathome.berkeley.edu/ap_source/nightly/ , right?

(these are from 2005/11/03)

Rather old. If you want to stay with the actual development check what you have with the browseable CVS-server.
The tagging of files on that server should be changed to a more clear way of naming (now: all tags/default branch, start, MAIN, HEAD, astropulse).

---

_\|/_
U r s

Just a sanity check: the most recent source archives live at
http://setiathome.berkeley.edu/ap_source/nightly/ , right?

Good question. I'll need to restart the daemon that creates the tar files.

Eric

---

Just a sanity check: the most recent source archives live at
http://setiathome.berkeley.edu/ap_source/nightly/ , right?

Good question. I'll need to restart the daemon that creates the tar files.

Eric

Thought so, because the directory itself is newer than the archives within it. Could you also include the few server-/db-schema and seti files which it uses, so that the archive is self-contained?

---

http://setiathome.berkeley.edu/donation_history.php

:-)

http://setiathome.berkeley.edu/donation_history.php

:-)

That's one helluva big donation from an individual or organisation, Byron!

Might get a few weeeks' pay for the Berkeley crew out of that! (Wouldn't it be nice if they could paid by the hour?)

---

http://setiathome.berkeley.edu/donation_history.php

:-)

That's one helluva big donation from an individual or organisation, Byron!

Might get a few weeeks' pay for the Berkeley crew out of that! (Wouldn't it be nice if they could paid by the hour?)

is it just me or do the links on the listed page show up in a different language.

---

Just added this host (Linux/x86 app).

I hope it generates usefull results.

;-)

---

Just saw these messages:

do 08 feb 2007 20:55:50 CET|SETI@home Beta Test|You used the wrong URL for this project
do 08 feb 2007 20:55:50 CET|SETI@home Beta Test|The correct URL is http://setiweb.ssl.berkeley.edu/beta/
do 08 feb 2007 20:55:50 CET|SETI@home Beta Test|Using the wrong URL can cause problems in some cases.
do 08 feb 2007 20:55:50 CET|SETI@home Beta Test|When convenient, detach this project, then reattach to http://setiweb.ssl.berkeley.edu/beta/

Will do so as soon as results are reported.

;-)

---

This one ran into an error...

<error_code>-131</error_code>

(from local messages)
"File size: 27220986.000000 bytes. Limit: 655360.000000 bytes"

;-)

---

This one ran into an error...

-131

(from local messages)
"File size: 27220986.000000 bytes. Limit: 655360.000000 bytes"

;-)

Sorry about that. We might have the thresholds set too low. A new client release should be coming at some point in the near future.

Eric

---

Eric, just curious, do you have a guesstimate on when we might
see the astropulse app for the Mac OSX PPC? Thanks.

---

Eric, just curious, do you have a guesstimate on when we might
see the astropulse app for the Mac OSX PPC? Thanks.

If and when Eric replies to you query, don't forget to apply Hofstadter's law. LOL

Andy

This one ran into an error...

<error_code>-131</error_code>

(from local messages)
"File size: 27220986.000000 bytes. Limit: 655360.000000 bytes"

;-)

Sorry about that. We might have the thresholds set too low. A new client release should be coming at some point in the near future.

Eric

No harm done... I wasn't counting on an app that worked flawless.

I'm sure things will improve... ;-)

---

Hi!

I sincerely hope that somebody thought of not-so-modern Linux distributions (such as RedHat 7.x) that don't come with glibc 2.3 ... I really wouldn't like to see many of such failures. It's quite easily to cure by linking apps statically ...

---

Metod ...

The first new astropulse results are appearing.

We only have an x86_64 application ready. Josh will be compiling other linux and solaris in the next few days. Maybe even MacOS. No graphics yet. That's mostly my fault.

Eric

Yay :-)

I'll try to make a FreeBSD port this weekend, with a big beta-disclaimer...

Real-life came in between me and FreeBSD-astropulse, but I'm now doing the standalone run test of it.

So the next question is: What are the error margins for the results ? (IIRC, seti has e < 0.01%)

Question 2: is it possible to run Astropulse without Seti-beta ? (the "astropulse only" thread implies this) [edit] I mean without the seti-beta binary, registration is of course at seti-beta[/edit]

Later,
Rene

---

Hi All!

What about Astropulse for Windows?

---

The first new astropulse results are appearing.

We only have an x86_64 application ready. Josh will be compiling other linux and solaris in the next few days. Maybe even MacOS. No graphics yet. That's mostly my fault.

Eric

Yay :-)

I'll try to make a FreeBSD port this weekend, with a big beta-disclaimer...

Real-life came in between me and FreeBSD-astropulse, but I'm now doing the standalone run test of it.

So the next question is: What are the error margins for the results ? (IIRC, seti has e < 0.01%)

Question 2: is it possible to run Astropulse without Seti-beta ? (the "astropulse only" thread implies this) [edit] I mean without the seti-beta binary, registration is of course at seti-beta[/edit]

Later,
Rene

What should go into the app_info.xml file?

Currently it is:

<app_info>
<app>
<name>astropulse</name>
</app>
<file_info>
<name>ap_4.10_i386-portbld-freebsd</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>410</version_num>
<file_ref>
<file_name>ap_4.10_i386-portbld-freebsd</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

But this results in "no work from project". Changing both instances of "astropulse" to "setiathome_enhanced" gives me seti 5.17 work, changing one instance deletes the astropulse binary.

Thanks,
Rene

---

Rene et al

Yes More than one application can exist in a project directory... That is usually defined in the client_state.xml file.

It has been a while since construction of app_info.xml files was discussed

How do the files get there? (Very simplistic subject to small erros in representation)

The best I can recall (simplistic) when you join a project you have no project application. The scheduler sends in the sched_reply_whatever project the basic information about the project (including url's for the appropriate applications and data).

The Core Client displays the information and checks the client_state.xml.

As the client state is read to see if the necessary application files are present on the computer, and replies I do not any files.

The Project then replies you should have "these files" and sends the specific information which is merged into the client_state.xml.

The Core then sends I "need these files," the scheduler then sends the application and support files. They are checked against the information that was stored in the client_state.xml file.

Next the core would send to the scheduler, I have no work to do (according to preferences)... I request 86400 seconds of work. Then work is downloaded.

After that whenever I send information to the project I tell the project what application I am running. If a new application is required, the scheduler would then tell the Core that these are the new files you need and start the process again.

Every time the BOINC Core is started it checks the files (via client_state.xm) in the project directories for integrity!

The Exception: If you have an app_info.xml files it overrides the change of the application. So if there is fact an upgraded application that is supposed to come to you it will not. If the application reported by you is not acceptable No Work will be sent. If there is an error it will delete the files.

So that all said, I would presume the app_info.xml should look something like this (I am a bit rusty in this)

<app_info>
<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>setiathome_5.17_windows_intelx86.exe</name>
<executable/>
</file_info>
<file_info>
<name>libfftw3f-3-1-1a.dll</name>
<sticky/>
</file_info>
<file_info>
<name>seti517.jpg</name>
<sticky/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>517</version_num>
<file_ref>
<file_name>setiathome_5.17_windows_intelx86.exe</file_name>
<main_program/>
</file_ref>
<app>
<name>astropulse</name>
</app>
<file_info>
<name>ap_4.10_i386-portbld-freebsd</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>410</version_num>
<file_ref>
<file_name>ap_4.10_i386-portbld-freebsd</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

What should go into the app_info.xml file?

Currently it is:

<app_info>
<app>
<name>astropulse</name>
</app>
<file_info>
<name>ap_4.10_i386-portbld-freebsd</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>410</version_num>
<file_ref>
<file_name>ap_4.10_i386-portbld-freebsd</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

But this results in "no work from project". Changing both instances of "astropulse" to "setiathome_enhanced" gives me seti 5.17 work, changing one instance deletes the astropulse binary.

Thanks,
Rene

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project