I just want to let you know that there's a refurbished version of the original Eintein@Home graphics application (starsphere) about to be released around next week. It uses SDL in conjuction with Open GL and, more importantly, provides a small but useful framework which encapsulates the following important functionalities:
* Window management
* 3D context management
* Event handling
* BOINC interfacing
* Einstein@Home interfacing
* Self-consistent build script (Linux, Mac OS, Windows/MinGW)
* Full doxygen documentation
I encourage you to have a look at this framework because it should reduce your work significantly and let's you concentrate on the actual "artistic" implementation.
Stay tuned,
Oliver
You the man! I will indeed hold fire and eagerly await. This is terrific. :-)
It is/was my stumbling block, and probably has averted others too.
OpenGL seems to be, dare I say, fairly intuitive ( state machine etc .. ) and seems to require 'only' a modicum of skill to flip around with it. I've got the "OpenGL Programming Guide" 5th Ed by the board that designed it. I've been boring through that and have roughed out a 'solar system plan' with an 'orbiting viewpoint/platform' visualisation of it + elements linking to the current task state. I'll have to be careful not to overchug the graphics engine though .... :-)
[ standard famous last words .... ]
Again thanks.
Cheers, Mike.
( edit ) and I'll go and find out what a doxygen is ...
Finally our new framework for BOINC graphics is ready for release! This should make it much easier to build an own Einstein@home graphics application, as it encapsulates all the communication with BOINC or the science App. It still requires programming the actual graphics, though.
To get it, follow this link to the entry page of the documentation and see the section "Source Code Access".
The new graphics applications built from that framework will honor the new "Graphics settings" you may have noticed in your "Einstein@Home preferences".
The new Arecibo Binary Pulsar search applications were already delivered with this new graphics applications, while the S5R5 "Hierarchical Search" Apps still come with the old graphics you're used to. So consider it the first field test for the new graphics code to build your own graphics binaries and run them with the existing S5R5 workunits.
I have no clue of writing programs for anything dealing with computers. Besides, I don't have an artistic ability. Good luck to everyone that tries and, hopefully, succeeds. As for myself, I think I will wait to see what comes out of this good spirited contest and then choose from what is offered.
I have downloaded gcc-core from sourceforge. The problem may be here ?
I add gcc-core in 3rdparty/mingw/packages/. The build of MinGW is OK.
During the build of libxml2, I had some errors :
3rdparty/libxml2/python/libxml.c -o libxml.o
1)
/usr/include/python2.5/pyport.h:257:24: sys/select.h: No such file or directory
2)
/3rdparty/libxml2/include/libxml/encoding.h:28:19: iconv.h: No such file or directory
The headers files, iconv.h and select.h, are absent in /install/include/ directory.
I think, MinGW can't build libxml2 because he haven't all tools for that.
libxml2 tool need to be patched for MinGW ?
Under linux (./build.sh --linux) the build is OK, I can run the graphic app.
Thanks for trying the framework and spotting this issue! Your're right, the MinGW build is broken right now. This is due to the fact that the MinGW project released new versions of its GCC, Win32 API, binutils and runtime packages - unfortunately they changed the package naming conventions without amending their cross-compile toolset (xscripts). I already notified them about that issue and I'll try to come up with a workaround in the next couple of days.
Update: I pushed a workaround (tested on Debian Lenny) into the framework repository. Please update your sources (via git or download) and try again. This workaround fixes the MinGW issue which was, by the way, not at all related to libxml2. Hopefully the MinGW project will fix their scripts accordingly...
Some notes as I go, which may be of interest to others. Maybe not. :-)
Downloaded the recently posted MingW workaround ( 15/02/09 ).
Using a machine with Suse Linux 11.0 distribution. Closest to Ubuntu apparently, but read on. Found using the build.sh script that I needed to install a couple of things - lacking items in the prerequisite toolchain. Ok, so use the package manager that came with Suse. However :
- 'cvs' wont install in the presence of Subversion. Un-install Subversion then install 'cvs'. Then re-install Subversion! Fine now.
- 'svn' in the script but known as 'subversion' to the shell, hence in '.profile' ( hidden in my home directory ) put :
alias svn='subversion'
- need 'lex' but Suse only has 'flex' ( faster lex ), so install that instead and again in the .profile :
alias lex='flex'
- need 'yacc' but Suse's closest is 'bison' ( ha ha ... ), so whack that in and also :
alias yacc='bison'
Now on Suse 'g++'/'gcc' may not be known as such, or aliased appropriately, so you'd might want ( in .profile again ) :
CC='gcc-4.3'
CXX='gcc-4.3'
export CC # for good measure
export CXX # for good measure
that is version 4.3.1 actually ( use 'g++ -v' on a command line to reveal that ). In the 'build_linux()' function [ line 468 of build.sh ] I see a note re. 'gcc/g++ 4.0.3' - OK to exceed that, or is that exact version preferred?? I look in /usr/bin for the actual executables/links.
With a logout/login cycle to scoop all those up with a profile re-read.
If the build script says 'this may take a while' - it means it!! Clearly downloading, un-compressing, renaming etc. Note all this stuff gets lobbed into (sub) directories that branch from wherever you unzipped the original framework to.
Haven't completed a build yet ( trying 'build.sh --linux' ), still in the 'prepare_generic()' function, as at present seems to be timing out on the repository for 'libxml2' retrieval. Will keep re-trying and get back on that ...
[ And I'm having fun learning about bash scripting! I'll be doing a course in unix/bash/perl/python over the next 3 months, so that's dandy timing. :-) ]
Cheers, Mike.
( edit ) Ok, for 'libxml2' I managed to use ftp on a Windows machine to get 'libxml2-sources-2.6.32.tar.gz', as per line 143, no problem. Then executed lines 142 - 148 ( bar line 143 ) manually to get the unzip/structure in the '3rdparty' subdirectory. Then rem out those lines and retry the build script. Has now gone through start of 'build_linux()' and hence start of 'build_generic()' as we speak ...
SDL, Freetype2, OGLFT and BOINC retrievals no problems. Since 'wget' for the Freetype2 worked OK, but not for 'libxml2' then that suggests a problem at xmlsoft.org .........
( edit ) Oh dear, it's vomited on the SDL build - a blizzard of errors. Here's the relevant section of the log file.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Funny, I'm developing under Suse Linux 11 as well, and I do get svn as an executable , not subversion. I've cvs and svn installed.
The problem I had under Suse 11.0 with the screensaver framework was that I could find no libaudio lib, neither installed nor in the repository. Same for you? I don't think it#s actually used, just needed because of dependencies, and borrowing a libaudio from another minux box fixed it.
Some notes as I go, which may be of interest to others. Maybe not. :-)
- 'cvs' wont install in the presence of Subversion. Un-install Subversion then install 'cvs'. Then re-install Subversion! Fine now.
- 'svn' in the script but known as 'subversion' to the shell, hence in '.profile' ( hidden in my home directory ) put :
alias svn='subversion'
That's strange - even for Suse ;-) Interestingly Bikeman's installation doesn't expose that problem.
Quote:
- need 'lex' but Suse only has 'flex' ( faster lex ), so install that instead and again in the .profile :
alias lex='flex'
- need 'yacc' but Suse's closest is 'bison' ( ha ha ... ), so whack that in and also :
alias yacc='bison'
I intentionally used lex and yacc because they're the original "incarnations" of these tools. Of course they're usually replaced by flex and bison (also true for my system) but the distributions I know all put symlinks to lex and yacc in place (for backwards compatibility).
Quote:
In the 'build_linux()' function [ line 468 of build.sh ] I see a note re. 'gcc/g++ 4.0.3' - OK to exceed that, or is that exact version preferred?? I look in /usr/bin for the actual executables/links.
There is no preferred version as long as you use gcc 4.x. The reference in the build script only states what we use for the official build.
Quote:
If the build script says 'this may take a while' - it means it!! Clearly downloading, un-compressing, renaming etc. Note all this stuff gets lobbed into (sub) directories that branch from wherever you unzipped the original framework to.
Yep, and a "./build.sh --distclean" cleans up everything again.
Quote:
Haven't completed a build yet ( trying 'build.sh --linux' ), still in the 'prepare_generic()' function, as at present seems to be timing out on the repository for 'libxml2' retrieval. Will keep re-trying and get back on that ...
Sad but true. As all of the dependencies are downloaded automatically it may happen that sometimes they're simply not available :-/ But I think that's still better than relying on the user/developer to prep his/her system manually. In my experience sourceforge.net as well as the BOINC repository are the most unreliable sources...
Quote:
[ And I'm having fun learning about bash scripting! I'll be doing a course in unix/bash/perl/python over the next 3 months, so that's dandy timing. :-) ]
Great! Please keep in mind that the build script came into existence to ease my local build process. Therefore there's much potential for improvements that make it more intelligent and robust. Of course I'm happy to accept your contributions (e.g. automake/autoconf) :-)
( edit ) Ok, for 'libxml2' I managed to use ftp on a Windows machine to get 'libxml2-sources-2.6.32.tar.gz', as per line 143, no problem. Then executed lines 142 - 148 ( bar line 143 ) manually to get the unzip/structure in the '3rdparty' subdirectory. Then rem out those lines and retry the build script. Has now gone through start of 'build_linux()' and hence start of 'build_generic()' as we speak ...
SDL, Freetype2, OGLFT and BOINC retrievals no problems. Since 'wget' for the Freetype2 worked OK, but not for 'libxml2' then that suggests a problem at xmlsoft.org .........
That's the "download availability issue" once again. However, it never occurred that often when I built the screensavers the last couple of times...
Quote:
( edit ) Oh dear, it's vomited on the SDL build - a blizzard of errors. Here's the relevant section of the log file.
That's an easy one: your system misses the libdirectfb-dev package (or similar on Suse, look which package contains directfb.h).
I guess I have to revise the list of dependencies in the documentation as SDL requires a couple of development packages I obviously haven't yet mentioned.
RE: Hi Mike, I just want
)
You the man! I will indeed hold fire and eagerly await. This is terrific. :-)
It is/was my stumbling block, and probably has averted others too.
OpenGL seems to be, dare I say, fairly intuitive ( state machine etc .. ) and seems to require 'only' a modicum of skill to flip around with it. I've got the "OpenGL Programming Guide" 5th Ed by the board that designed it. I've been boring through that and have roughed out a 'solar system plan' with an 'orbiting viewpoint/platform' visualisation of it + elements linking to the current task state. I'll have to be careful not to overchug the graphics engine though .... :-)
[ standard famous last words .... ]
Again thanks.
Cheers, Mike.
( edit ) and I'll go and find out what a doxygen is ...
( edit ) Ah. 'Source code documentation generator tool' - nice one.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Finally our new framework for
)
Finally our new framework for BOINC graphics is ready for release! This should make it much easier to build an own Einstein@home graphics application, as it encapsulates all the communication with BOINC or the science App. It still requires programming the actual graphics, though.
To get it, follow this link to the entry page of the documentation and see the section "Source Code Access".
The new graphics applications built from that framework will honor the new "Graphics settings" you may have noticed in your "Einstein@Home preferences".
The new Arecibo Binary Pulsar search applications were already delivered with this new graphics applications, while the S5R5 "Hierarchical Search" Apps still come with the old graphics you're used to. So consider it the first field test for the new graphics code to build your own graphics binaries and run them with the existing S5R5 workunits.
We are happily awaiting your contributions.
BM
BM
I have no clue of writing
)
I have no clue of writing programs for anything dealing with computers. Besides, I don't have an artistic ability. Good luck to everyone that tries and, hopefully, succeeds. As for myself, I think I will wait to see what comes out of this good spirited contest and then choose from what is offered.
Hi I would like to build a
)
Hi
I would like to build a starsphere for windows with MinGw.
There is a dead link for downloading "gcc-core-3.4.5".
I can't access to http://umn.dl.sourceforge.net/sourceforge/mingw/gcc-core-3.4.5-20060117-1-src.tar.gz
I have downloaded gcc-core from sourceforge. The problem may be here ?
I add gcc-core in 3rdparty/mingw/packages/. The build of MinGW is OK.
During the build of libxml2, I had some errors :
3rdparty/libxml2/python/libxml.c -o libxml.o
1)
/usr/include/python2.5/pyport.h:257:24: sys/select.h: No such file or directory
2)
/3rdparty/libxml2/include/libxml/encoding.h:28:19: iconv.h: No such file or directory
The headers files, iconv.h and select.h, are absent in /install/include/ directory.
I think, MinGW can't build libxml2 because he haven't all tools for that.
libxml2 tool need to be patched for MinGW ?
Under linux (./build.sh --linux) the build is OK, I can run the graphic app.
Thank you for your help
Romain
Hi Romain, Thanks for
)
Hi Romain,
Thanks for trying the framework and spotting this issue! Your're right, the MinGW build is broken right now. This is due to the fact that the MinGW project released new versions of its GCC, Win32 API, binutils and runtime packages - unfortunately they changed the package naming conventions without amending their cross-compile toolset (xscripts). I already notified them about that issue and I'll try to come up with a workaround in the next couple of days.
Stay tuned and thanks for your patience,
Oliver
Einstein@Home Project
Update: I pushed a workaround
)
Update: I pushed a workaround (tested on Debian Lenny) into the framework repository. Please update your sources (via git or download) and try again. This workaround fixes the MinGW issue which was, by the way, not at all related to libxml2. Hopefully the MinGW project will fix their scripts accordingly...
Cheers,
Oliver
Einstein@Home Project
Some notes as I go, which may
)
Some notes as I go, which may be of interest to others. Maybe not. :-)
Downloaded the recently posted MingW workaround ( 15/02/09 ).
Using a machine with Suse Linux 11.0 distribution. Closest to Ubuntu apparently, but read on. Found using the build.sh script that I needed to install a couple of things - lacking items in the prerequisite toolchain. Ok, so use the package manager that came with Suse. However :
- 'cvs' wont install in the presence of Subversion. Un-install Subversion then install 'cvs'. Then re-install Subversion! Fine now.
- 'svn' in the script but known as 'subversion' to the shell, hence in '.profile' ( hidden in my home directory ) put :
alias svn='subversion'
- need 'lex' but Suse only has 'flex' ( faster lex ), so install that instead and again in the .profile :
alias lex='flex'
- need 'yacc' but Suse's closest is 'bison' ( ha ha ... ), so whack that in and also :
alias yacc='bison'
Now on Suse 'g++'/'gcc' may not be known as such, or aliased appropriately, so you'd might want ( in .profile again ) :
CC='gcc-4.3'
CXX='gcc-4.3'
export CC # for good measure
export CXX # for good measure
that is version 4.3.1 actually ( use 'g++ -v' on a command line to reveal that ). In the 'build_linux()' function [ line 468 of build.sh ] I see a note re. 'gcc/g++ 4.0.3' - OK to exceed that, or is that exact version preferred?? I look in /usr/bin for the actual executables/links.
With a logout/login cycle to scoop all those up with a profile re-read.
If the build script says 'this may take a while' - it means it!! Clearly downloading, un-compressing, renaming etc. Note all this stuff gets lobbed into (sub) directories that branch from wherever you unzipped the original framework to.
Haven't completed a build yet ( trying 'build.sh --linux' ), still in the 'prepare_generic()' function, as at present seems to be timing out on the repository for 'libxml2' retrieval. Will keep re-trying and get back on that ...
[ And I'm having fun learning about bash scripting! I'll be doing a course in unix/bash/perl/python over the next 3 months, so that's dandy timing. :-) ]
Cheers, Mike.
( edit ) Ok, for 'libxml2' I managed to use ftp on a Windows machine to get 'libxml2-sources-2.6.32.tar.gz', as per line 143, no problem. Then executed lines 142 - 148 ( bar line 143 ) manually to get the unzip/structure in the '3rdparty' subdirectory. Then rem out those lines and retry the build script. Has now gone through start of 'build_linux()' and hence start of 'build_generic()' as we speak ...
SDL, Freetype2, OGLFT and BOINC retrievals no problems. Since 'wget' for the Freetype2 worked OK, but not for 'libxml2' then that suggests a problem at xmlsoft.org .........
( edit ) Oh dear, it's vomited on the SDL build - a blizzard of errors. Here's the relevant section of the log file.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Funny, I'm developing under
)
Funny, I'm developing under Suse Linux 11 as well, and I do get svn as an executable , not subversion. I've cvs and svn installed.
The problem I had under Suse 11.0 with the screensaver framework was that I could find no libaudio lib, neither installed nor in the repository. Same for you? I don't think it#s actually used, just needed because of dependencies, and borrowing a libaudio from another minux box fixed it.
CU
Bikeman
RE: Some notes as I go,
)
That's strange - even for Suse ;-) Interestingly Bikeman's installation doesn't expose that problem.
I intentionally used lex and yacc because they're the original "incarnations" of these tools. Of course they're usually replaced by flex and bison (also true for my system) but the distributions I know all put symlinks to lex and yacc in place (for backwards compatibility).
There is no preferred version as long as you use gcc 4.x. The reference in the build script only states what we use for the official build.
Yep, and a "./build.sh --distclean" cleans up everything again.
Sad but true. As all of the dependencies are downloaded automatically it may happen that sometimes they're simply not available :-/ But I think that's still better than relying on the user/developer to prep his/her system manually. In my experience sourceforge.net as well as the BOINC repository are the most unreliable sources...
Great! Please keep in mind that the build script came into existence to ease my local build process. Therefore there's much potential for improvements that make it more intelligent and robust. Of course I'm happy to accept your contributions (e.g. automake/autoconf) :-)
Cheers,
Oliver
Einstein@Home Project
RE: ( edit ) Ok, for
)
That's the "download availability issue" once again. However, it never occurred that often when I built the screensavers the last couple of times...
That's an easy one: your system misses the libdirectfb-dev package (or similar on Suse, look which package contains directfb.h).
I guess I have to revise the list of dependencies in the documentation as SDL requires a couple of development packages I obviously haven't yet mentioned.
Best,
Oliver
Einstein@Home Project