From pjotr.public14 at thebird.nl Sat Aug 1 03:02:19 2009 From: pjotr.public14 at thebird.nl (pjotr.public14 at thebird.nl) Date: Sat, 1 Aug 2009 09:02:19 +0200 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> References: <20090731075810.GA8052@thebird.nl> <20090731075948.GA8974@thebird.nl> <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> Message-ID: <20090801070219.GA22043@thebird.nl> On Fri, Jul 31, 2009 at 11:18:26AM -0400, Xin Shuai wrote: > Hi, I did pull your libsequence branch into my master_conflict branch. > 140-182-128-142:biolib diavy$ git pull pjotrp libsequence > > However something reemerged: > > 12 files changed, 31 insertions(+), 19 deletions(-) > mode change 100644 => 100755 .gitignore > mode change 100644 => 100755 CMakeLists.txt > mode change 100644 => 100755 INSTALL > mode change 100644 => 100755 LICENSE > mode change 100644 => 100755 PROJECTNAME > mode change 100644 => 100755 README > mode change 100644 => 100755 Rakefile > mode change 100644 => 100755 TODO > mode change 100644 => 100755 VERSION > ...... > > I remember the similar situation happened when I commited ( you said I > changed the file permission!) > > Is it normal or abnormal? I really don't hope the same thing occurred! What happened is I cloned your master branch. Next pulled from your master_conflict branch. The master branch contained the old patch - so it got merged in again. I think it advisable you remove the old master branch to avoid confusion - or, better, synchronize the master_conflict branch with your master branch. Something like this can work: -- make a backup first of your tree git checkout master_conflict git branch -D master # delete master git checkout -b master # create new master git push -f github master # overwrite old master github/origin That way the patch goes away forever. I'll clone master_conflict now and merge my changes in again. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 03:46:48 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 09:46:48 +0200 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <20090801070219.GA22043@thebird.nl> References: <20090731075810.GA8052@thebird.nl> <20090731075948.GA8974@thebird.nl> <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> <20090801070219.GA22043@thebird.nl> Message-ID: <20090801074648.GA22853@thebird.nl> On Sat, Aug 01, 2009 at 09:02:19AM +0200, pjotr.public14 at thebird.nl wrote: > -- make a backup first of your tree > git checkout master_conflict > git branch -D master # delete master > git checkout -b master # create new master > git push -f github master # overwrite old master github/origin The last one does not work, my mistake. The way to delete a remote branch is git push github :master next push (the correct branch) to it git push github master OK, new chapter. I am going to show how to revert to an older branch and bring in later patches. I just updated my version of libsequence. I removed the master_conflict branch and checked out your current master_conflict version on github (which does not contain the bad patch): git branch -D master_conflict # remove old local version git checkout --track -b master_conflict origin/master_conflict next I checked the patches I wrote yesterday, and 'cherry-picked' them into your branch: git log master # cherry picking my recent changes git cherry-pick 5d01107bcd839e8a5725ec24f5b813311975b663 (etc.) then I removed my remote github branch and pushed the latest version. git push -f github :master_conflict # deleting remote repo git push -f github master_conflict Now *my* branch is master_conflict version is clean. So I renamed it to libsequence again ;-) git checkout -b libsequence Note that your local branch is probably diluted now with the dirty patches. You need to do something similar to the above starting from my libsequence branch. Create a new branch (assuming my remote is named pjotr): git checkout -b libsequence pjotr/libsequence and cherry-pick *your* latest patches from yesterday. Finally push it to your own tree: git push origin libsequence so I can start pulling from there again. Is this clear? Again, make backups before starting. It is easy to remove some work accidentily. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 04:16:43 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 10:16:43 +0200 Subject: [BioLib-dev] Merging libsequence into main Message-ID: <20090801081643.GA26569@thebird.nl> On Fri, Jul 31, 2009 at 12:01:32PM -0400, Xin Shuai wrote: > Except for the doubt I raised in my last email(I really don't dare to commit > freely this time unless you told me nothing is wrong), I've already updated > the contrib with two submodules: libsequence-1.6.6 and boost. I would have created another remote branch. That way it would have been possible for me to see the differences. Now I am blind to the latest changes. > Regarding to your error, yes, I once met them before. So I modified > a few .hpp , .cc and .tcc files to make them work for swig. That's > way I once asked you if it is OK for me to modify the original > files. > > I attached a txt file which documents all the files I have modified and how. Ah, that is cool. I see you have fixed a number of problems by modifying BOOST and libsequence sources. The only problem is that I don't have them in the tree now. The nice thing is that we actually have both libraries as git repositories in biolib(!). This means we can clone the trees onto our own github accounts, and push the patches. That way we can make visible what works and doesn't work - and share the changes. If you use my latest libsequence branch and run git submodule -i update you will have both repositories locally. Let's start with a change to libsequence: cd contrib/libsequence-1.6.6 git checkout -b xin # important since a git submodule is a virtual branch # hack hack # test git commit Now you have patches. So what next? Two options, clone the libsequence library at http://github.com/pjotrp/libsequence/tree on github and push the patches to your tree. This is nice. I can pull from that tree. Another option is to mail me the patches (as generated by git). The same thing can be done for the BOOST tree. I cloned it from git://gitorious.org/boost/svn.git. Unfortunately it is large and may not fit into your free github account. You'll have to either upgrade github, or I need add you to my github account, or you send me patches. What do you prefer? BTW, fixing upstream libraries - you have to make a call. Really changes should go in we can send upstream to the maintainers. Just commenting out problematic code is not a 'solution'. For isolated cases there are a number of options: 1. Tell SWIG to ignore the code (renames, macros) 2. Create a derived class that is used by SWIG, rather than the parent If it is unavoidable to parse the master file, and SWIG cracks, maybe we can have a copy of that one particular file in the biolib tree, which is compiled, rather than the one in contrib. So problematic.h is found in: ./src/clibs/libsequence/include/problematic.h rather then ./contrib/libsequence/include/problematic.h In other words, fixing the master repositories should be useful to upstream users. Otherwise we need to hack it in biolib itself. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 04:55:47 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 10:55:47 +0200 Subject: [BioLib-dev] Merging biopp into main Message-ID: <20090801085547.GA26863@thebird.nl> Hi Adam, Thanks for moving the SWIG files into src/mappings/swig/python/biopp. >From your BLOG I gather you have a building Bio++ map for Python. That is cool - I would like to merge it into the next release of biolib. We need to get it to build it into biolib automatically with CMake. The first step is to compile the biopp C++ library from source in biolib. I have checked out your branch into a clean tree: git clone git://github.com/adamsmith/biolib.git biolib-biopp cd biolib-biopp/ git checkout --track -b biopp origin/biopp git pull git submodule init git submodule update # fetching biopp into ./contrib/biopp cd ./src/clibs/biopp/src here I should be able to do: cmake . make to build the biopp.so into ../build. I fixed that in earlier days, but you never merged my changes into your tree. So let's start from this point. One of my notes says: == Building the C++ libraries == The control files for building the Bio++ C libraries are in ./src/clibs/biopp/ cd ./src/clibs/biopp/src/ rm CMakeCache.txt ; cmake . ; make should build a shared library in ./src/clibs/biopp/build. This is the library we link against. (Note: As Bio++ has namespaces we can build one single .so file). It is named something like libbiolib_biopp-0.0.5.so, where the version number reflects the biolib repository VERSION. == Continuing... == So I have updated CMakeLists.txt and files.txt in my biopp_fix branch. cd ./src/clibs/biopp/src/ rm CMakeCache.txt ; cmake . ; make shows: STATUS,"FindMap.cmake" PREFIX: /usr/local CMAKE_INSTALL_PREFIX=/usr/local MAP_ROOT=../../../.. MAP_CLIBS_PATH=../../../../src/clibs MAP_PROJECTNAME=biolib MAP_VERSION=0.0.5 -- ClibMacros.cmake CONTRIB_PATH= LIBNAME=biolib_biopp-0.0.5 BUILDDIR=../../../../src/clibs/biopp/build -- Configuring done -- Generating done -- Build files have been written to: /export/users/local/wrk/git/opensource/biolib-biopp/src/clibs/biopp/src Scanning dependencies of target biolib_biopp-0.0.5 [ 6%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/ApplicationTools.cpp.o [ 13%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/AttributesTools.cpp.o [ 20%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/ColorTools.cpp.o (etc) Linking CXX shared library /export/users/local/wrk/git/opensource/biolib-biopp/src/clibs/biopp/build/libbiolib_biopp-0.0.5.so [100%] Built target biolib_biopp-0.0.5 Can you repeat this feat by pulling from my branch. First add my remote repository: git remote add pjotr git://github.com/pjotrp/biolib.git # update branch, probably best to checkout a temporary one git checkout -b biopp_fix git pull pjotr biopp_fix # check changes git log # (or use gitk) # good? back to your development branch git checkout biopp # merge in my change git merge biopp_fix # did it work? Yes. Email and continue hacking... # push to your github account If this is successful - I can see the patch on your github tree - we can go to the next step of integration. Pj. From xshuai at umail.iu.edu Sat Aug 1 12:54:13 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Sat, 1 Aug 2009 12:54:13 -0400 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <20090801081241.GA24447@thebird.nl> References: <20090801081241.GA24447@thebird.nl> Message-ID: <3a7743460908010954j617658cbi5ff50f31b3a0ac3d@mail.gmail.com> Thank you, pjotr, I really learnt a lot about git. Following your instruction, I've already created a new 'master' branch and it looks just as the same as my 'master_conflict' branch. Currently I'm still in the process of updating your libsequence & boost submodule. Later on, I 'll concentrate on fixing modifying the libsequence files. As you mentioned, I plan to put my modified file to: ./src/clibs/libsequence/include/. and leave the /contrib untouched. I think I also have to change the file including path. Is that OK? With regards to the patch, I decided to email them to you.(libsequence-1.6.6 and boost). You mentioned that I can get the patch by git commit Do you mean that I can directly find the patch file in my tree? I also consult the git manual and learned a command to generate the patch: $ git format-patch origin On Sat, Aug 1, 2009 at 4:12 AM, wrote: > On Fri, Jul 31, 2009 at 12:01:32PM -0400, Xin Shuai wrote: > > Except for the doubt I raised in my last email(I really don't dare to > commit > > freely this time unless you told me nothing is wrong), I've already > updated > > the contrib with two submodules: libsequence-1.6.6 and boost. > > I would have created another remote branch. That way it would have > been possible for me to see the differences. Now I am blind to the > latest changes. > > > Regarding to your error, yes, I once met them before. So I modified > > a few .hpp , .cc and .tcc files to make them work for swig. That's > > way I once asked you if it is OK for me to modify the original > > files. > > > > I attached a txt file which documents all the files I have modified and > how. > > Ah, that is cool. I see you have fixed a number of problems by > modifying BOOST and libsequence sources. The only problem is that I > don't have them in the tree now. > > The nice thing is that we actually have both libraries as git > repositories in biolib(!). This means we can clone the trees onto our > own github accounts, and push the patches. That way we can make > visible what works and doesn't work - and share the changes. > > If you use my latest libsequence branch and run > > git submodule -i update > > you will have both repositories locally. Let's start with a change to > libsequence: > > cd contrib/libsequence-1.6.6 > git checkout -b xin # important since a git submodule is a virtual > branch > # hack hack > # test > git commit > > Now you have patches. So what next? Two options, clone the > libsequence library at http://github.com/pjotrp/libsequence/tree on > github and push the patches to your tree. > > This is nice. I can pull from that tree. > > Another option is to mail me the patches (as generated by git). > > The same thing can be done for the BOOST tree. I cloned it from > git://gitorious.org/boost/svn.git. Unfortunately it is > large and may not fit into your free github account. You'll have to > either upgrade github, or I need add you to my github account, or you > send me patches. What do you prefer? > > BTW, fixing upstream libraries - you have to make a call. Really > changes should go in we can send upstream to the maintainers. Just > commenting out problematic code is not a 'solution'. For isolated > cases there are a number of options: > > 1. Tell SWIG to ignore the code (renames, macros) > 2. Create a derived class that is used by SWIG, rather than the > parent > > If it is unavoidable to parse the master file, and SWIG cracks, maybe > we can have a copy of that one particular file in the biolib tree, > which is compiled, rather than the one in contrib. So problematic.h > is found in: > > ./src/clibs/libsequence/include/problematic.h > > rather then > > ./contrib/libsequence/include/problematic.h > > In other words, fixing the master repositories should be useful to > upstream users. Otherwise we need to hack it in biolib itself. > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 10:36:32 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 10:36:32 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090802162823.GA9347@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> Message-ID: <3a7743460908030736x639632aei3af8d6db7b404262@mail.gmail.com> On Sun, Aug 02, 2009 at 10:36:27AM -0400, Xin Shuai wrote: > Hi: I'm still in the process of debugging and testing. I found that , in > addition to Boost++ library, gsl library is also needed. > I tracked the location of gsl library and found it in > /usr/local/lib/libgsl.dylib. Hmmm. How much does it use? I have also the Scilib project, similar to Biolib, which includes the GSL sources. I really dislike linking against shared libraries for critical functionality. Prefer sources, so it is one system and bugs can be tagged against one set of versions. The only exception I am making now are Rlib and zlib. > Generally, any lib that is located in /usr/lib and /usr/local/lib should > be automatically found by CMake. But my program cannot find it. Thus I have > import error when I import libsequence library in Python. I guess the reason > is that CMake only recognize library with .so suffix (Unix) But not library > with .dylib(Mac). Since I met the similar situation at the beginning of > project. Finding is no problem, just takes a bit of hacking. I don't have OSX, that complicates it for me. But we can find solutions if required. > Therefore, I think the solution is to add some hacking to let CMake > recognize .dylib when Linking other library. How do you think of my > thoughts? Can you give me some advice? At this stage I favour including the source tree. Can you check what functions libsequence really uses from the GSL? Pj. -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 10:56:52 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 10:56:52 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803063801.GA13838@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> Message-ID: <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> I've tried to add the related .c source files in gsl library and compile them. However, the difficulty is little beyond my expectation Actually, only four functions are needed for libsequence: gsl_rng_uniform(__r) gsl_ran_flat(__r,a,b) gsl_ran_exponential(__r,mean) gsl_ran_poisson(__r,mean) And they are declared in libsequence-1.6.6/Sequence/RNG/gsl_rng_wrappers.hpp I began by adding source file name in .src/clibs/libsequence-1.6.6/src/files.txt, as well as the files themselves in the same directory. That is the way I do for libsequence. However, as I added more, I found a lot of dependent files needing to be added and complied, in order to *re**ally use the above four* functions in python. I guess more than 30 files. I've tried an afternoon and a night of yesterday and gave up finally. It seems to me a little awkward to manually added files and compile them. So what's your advice? On Mon, Aug 3, 2009 at 2:38 AM, Pjotr Prins wrote: > On Sun, Aug 02, 2009 at 03:11:33PM -0400, Xin Shuai wrote: > > Not very much, only a few functions. So I'm trying to add related source > > files into my tree and complied them together into libsequence library > > That is probably the best option, especially since libsequence is not > actively maintained. > > A list of functions would help though, maybe the functionality is > already in BOOST now, or in Rlib, so we can replace that dependency. > > Pj. > > > On Sun, Aug 2, 2009 at 12:28 PM, Pjotr Prins > wrote: > > > > > On Sun, Aug 02, 2009 at 10:36:27AM -0400, Xin Shuai wrote: > > > > Hi: I'm still in the process of debugging and testing. I found that > , > > > in > > > > addition to Boost++ library, gsl library is also needed. > > > > I tracked the location of gsl library and found it in > > > > /usr/local/lib/libgsl.dylib. > > > > > > Hmmm. How much does it use? I have also the Scilib project, similar > > > to Biolib, which includes the GSL sources. I really dislike linking > > > against shared libraries for critical functionality. Prefer sources, > > > so it is one system and bugs can be tagged against one set of > > > versions. The only exception I am making now are Rlib and zlib. > > > > > > > Generally, any lib that is located in /usr/lib and /usr/local/lib > > > should > > > > be automatically found by CMake. But my program cannot find it. Thus > I > > > have > > > > import error when I import libsequence library in Python. I guess the > > > reason > > > > is that CMake only recognize library with .so suffix (Unix) But not > > > library > > > > with .dylib(Mac). Since I met the similar situation at the beginning > of > > > > project. > > > > > > Finding is no problem, just takes a bit of hacking. I don't have OSX, > > > that complicates it for me. But we can find solutions if required. > > > > > > > Therefore, I think the solution is to add some hacking to let > CMake > > > > recognize .dylib when Linking other library. How do you think of my > > > > thoughts? Can you give me some advice? > > > > > > At this stage I favour including the source tree. Can you check what > > > functions libsequence really uses from the GSL? > > > > > > Pj. > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 3 11:45:37 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 17:45:37 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> Message-ID: <20090803154537.GA31467@thebird.nl> On Mon, Aug 03, 2009 at 10:56:52AM -0400, Xin Shuai wrote: > I've tried to add the related .c source files in gsl library and compile > them. However, the difficulty is little beyond my expectation > Actually, only four functions are needed for libsequence: > > gsl_rng_uniform(__r) > > gsl_ran_flat(__r,a,b) > > gsl_ran_exponential(__r,mean) > > gsl_ran_poisson(__r,mean) Funny. They are all random number generators, which are also in BOOST and Rlib. How about replacing these functions in libsequence with their Boost counterpart? Since we have Boost already. See, for example http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/poisson_dist.html would that be hard? I notice libsequence has a single wrapper Sequence/RNG/gsl_rng_wrappers.hpp, which includes these. The other uses are all example files. How about creating Sequence/RNG/boost_rng_wrappers.hpp which gets included when USE_BOOST is defined? That would be a nice contribution for the libsequence project. If that fails I can pull the GSL source tree into biolib. I have half a mind to do that anyway - it is not so large. All possible ;-) Pj. From pjotr.public14 at thebird.nl Mon Aug 3 12:29:22 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 18:29:22 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803154537.GA31467@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> Message-ID: <20090803162922.GA32533@thebird.nl> Hi Xin, I have applied your patches to the libsequence tree. See http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8. There is one patch changing functionality I hope you know what you are doing: changes: - if (Alignment::IsAlignment(alignment) == true) + // if (Alignment::IsAlignment(alignment) == true) You can pull in this tree into your repository by pulling from my biolib/libsequence branch, and update submodules in biolib: cd biolib git pull pjotr libsequence git submodule update That should do the trick. Check to see whether all patches have gone in. I also modified the files.txt list, so it compiles again. Pj. From xshuai at umail.iu.edu Mon Aug 3 12:34:43 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 12:34:43 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803154537.GA31467@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> Message-ID: <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> I can try the boost version of rng. But I still got a worry about the argument type problem.Those four functions defined are not used directly in libsequence. Instead, they are included in different classes as member function object.( See gsl_rng_wrappers.hpp for detail) . And the instance of these classes will be passed into other functions as argument and those functions are really used directly in libsquence.For example, such a function in libsequnce: std::pair pick2 ( uniform_generator & uni, const int & nsam) the argument &uni is just an object of the following class: class gsl_uniform01 { private: gsl_rng * __r; public: gsl_uniform01( gsl_rng * r ) : __r(r) { } inline double operator()(void) const { return gsl_rng_uniform(__r); } }; Therefore, even if I can write a boost_rng_wrapper.hpp and wrap boost random number generator, I'm afraid it won't be accepted as the current libsequence. I have to rewrite all related functions, like pick2, to make it accept boost rng rather than gsl rng. Correct me if I'm wrong. On Mon, Aug 3, 2009 at 11:45 AM, Pjotr Prins wrote: > On Mon, Aug 03, 2009 at 10:56:52AM -0400, Xin Shuai wrote: > > I've tried to add the related .c source files in gsl library and compile > > them. However, the difficulty is little beyond my expectation > > Actually, only four functions are needed for libsequence: > > > > gsl_rng_uniform(__r) > > > > gsl_ran_flat(__r,a,b) > > > > gsl_ran_exponential(__r,mean) > > > > gsl_ran_poisson(__r,mean) > > Funny. They are all random number generators, which are also in BOOST > and Rlib. How about replacing these functions in libsequence with > their Boost counterpart? Since we have Boost already. See, for example > > > http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/poisson_dist.html > > would that be hard? I notice libsequence has a single wrapper > Sequence/RNG/gsl_rng_wrappers.hpp, which includes these. The other > uses are all example files. > > How about creating Sequence/RNG/boost_rng_wrappers.hpp which gets > included when USE_BOOST is defined? > > That would be a nice contribution for the libsequence project. > > If that fails I can pull the GSL source tree into biolib. I have half > a mind to do that anyway - it is not so large. > > All possible ;-) > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 12:51:25 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 12:51:25 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803162922.GA32533@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <20090803162922.GA32533@thebird.nl> Message-ID: <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> Let me explain the patch for you. I have mentioned beforethat I have problem of instantiate the template function with T = Sequence::Fasta:(But it is supposed to be ) templatebool IsAlignment (const std::vector< T > &data) However, the PolySites template class can be instantiated by Sequence::Fasta and I did do it. The code section I comment out in the patch is just from the PolySites.tcc. So if I don't comment it out, error message will appeared and prevent me from wrapping the whole class. It won't affect unless you input a series of sequence with different length. However, it is still a but and I will try to fix it soon. On Mon, Aug 3, 2009 at 12:29 PM, Pjotr Prins wrote: > Hi Xin, > > I have applied your patches to the libsequence tree. See > > http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8 > . > > There is one patch changing functionality I hope you know what you are > doing: > > changes: - if (Alignment::IsAlignment(alignment) == true) > + // if (Alignment::IsAlignment(alignment) == true) > > You can pull in this tree into your repository by pulling from my > biolib/libsequence branch, and update submodules in biolib: > > cd biolib > git pull pjotr libsequence > git submodule update > > That should do the trick. Check to see whether all patches have gone > in. I also modified the files.txt list, so it compiles again. > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 3 13:00:52 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 19:00:52 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> Message-ID: <20090803170052.GA738@thebird.nl> On Mon, Aug 03, 2009 at 12:34:43PM -0400, Xin Shuai wrote: > I can try the boost version of rng. But I still got a worry about the > argument type problem.Those four functions defined are not used directly in > libsequence. Instead, they are included in different classes as member > function object.( See gsl_rng_wrappers.hpp for detail) . And the instance of > these classes will be passed into other functions as argument and those > functions are really used directly in libsquence.For example, such a > function in libsequnce: OK, I see. I think we just include the GSL sources into biolib. Easiest, and logical as other biolib modules will get access too. In theory the GSL is stable enough to link against it - however, it is small enough just to carry it in. Will do tomorrow. Ignore the problem until I have done that. Pj. From xshuai at umail.iu.edu Mon Aug 3 16:37:22 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 16:37:22 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <20090803162922.GA32533@thebird.nl> <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> Message-ID: <3a7743460908031337k1c1c4910j9783e3ad96fd4698@mail.gmail.com> The problem of instantiation of all template functions in Sequence::Alignment as well as template class Sequence::ClustalW. Actually the solution is quite simple. I forgot to compile one important source file, FastaExplicit.cc, into the libsequence dynamic library, which is provided by libsequence library. This file declares explicit instantiations for type Sequence::Fasta for those function templates as well as class Sequence::ClustalW. So, that related patch can be deleted. However, there's still a problem I don' understand. Sequence::PolySites is a normal class in libsequence but have a template constructor function. But I don't have to first include any "explicit instantiation" declaration, but can directly instantiate it in interface file using Sequence::Fasta type, as well as use it in Python. On Mon, Aug 3, 2009 at 12:51 PM, Xin Shuai wrote: > Let me explain the patch for you. I have mentioned > beforethat I have problem of instantiate the template function with T = > Sequence::Fasta:(But it is supposed to be ) > template bool IsAlignment (const > std::vector< T > &data) > However, the PolySites template class can be instantiated by > Sequence::Fasta and I did do it. The code section I comment out in the patch > is just from the PolySites.tcc. So if I don't comment it out, error message > will appeared and prevent me from wrapping the whole class. It won't affect > unless you input a series of sequence with different length. > > However, it is still a but and I will try to fix it soon. > > On Mon, Aug 3, 2009 at 12:29 PM, Pjotr Prins wrote: > >> Hi Xin, >> >> I have applied your patches to the libsequence tree. See >> >> http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8 >> . >> >> There is one patch changing functionality I hope you know what you are >> doing: >> >> changes: - if (Alignment::IsAlignment(alignment) == true) >> + // if (Alignment::IsAlignment(alignment) == true) >> >> You can pull in this tree into your repository by pulling from my >> biolib/libsequence branch, and update submodules in biolib: >> >> cd biolib >> git pull pjotr libsequence >> git submodule update >> >> That should do the trick. Check to see whether all patches have gone >> in. I also modified the files.txt list, so it compiles again. >> >> Pj. >> > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 18:54:16 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 18:54:16 -0400 Subject: [BioLib-dev] About istream and ostream in script language. In-Reply-To: References: <3a7743460908011445h66976f91w78f52512c13ea500@mail.gmail.com> Message-ID: <3a7743460908031554n283729dfje74cce06ee110ed5@mail.gmail.com> Thank you a lot for your information, Mark, though I cannot totally understand your perl code.It seems that there's NO NEED for the paired read() and print() in libsequence dealing with iostream, to be mapped to Python/Perl script. But I'm not sure about whether BioPython has the similar classes to deal with FASTA streaming. On Sun, Aug 2, 2009 at 1:54 PM, Mark A. Jensen wrote: > Hi David-- > It looks like these classes and methods provide streaming FASTA I/O. In > BioPerl, there is a class called > Bio::SeqIO that will do true FASTA streaming. In a Perl script, it would be > used as follows > > for "read": > > use Bio::SeqIO; > my $io = Bio::SeqIO->new(-format=>'fasta', -file => 'filename.fas'); > while ( my $seq = $io->next_seq ) { > # do stuff with $seq, which is-a Bio::Seq object > } > > for "print": > > use Bio::SeqIO; > use Bio::Seq; > my $io = Bio::SeqIO->new(-format=>'fasta', -file=>'>filename.fas'); > my $seq = Bio::Seq->new( -seq=>'ATACTA', -id=>'seq0' ); > $io->write_seq($seq); > > These require a considerable amount of BioPerl machinery, however. What may > be better is to provide simple "native" Perl functions that accept or return > a two-member hash > > %seq = ( 'id' => 'seq0, 'seq'=>'ATCTGA'); > > or arrays of hashrefs: > > @seqs = ( {'id'=>'seq0', 'seq'=>'ATCTGA'}, {'id'=>'seq1', 'seq'=>'TTCGAT'}, > ... }; > > and use these to read and write very simple fasta. Using the perl "open()" > and "print()" functions will automatically generate streams (via C fopen, > etc, I believe), so no special streaming code would need to be written. > Maybe Chris has other thoughts as well- > cheers, > Mark > > ----- Original Message ----- > *From:* Xin Shuai > *To:* Pjotr Prins ; chris Fields; Mark > A. Jensen > *Sent:* Saturday, August 01, 2009 5:45 PM > *Subject:* About istream and ostream in script language. > > In libsequence, many classes or struct have the similar following paired > member functions: > > std::istream & read(std::istream &s) > > > std::ostream & print(std::ostream &s) const > > I think the above two functions are used to for user > to input/output related data. And I also know there's a > library in swig for Python. But there's no such library in Perl > > I really have no idea of how these two functions can be used in script > language and how to deal with istream/ostream object in script language. > > Thus I'm wondering: Do I need to wrap them into Python/Perl? Or is it > better to manually write similar replacing functions for Python/Perl? > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 09:13:17 2009 From: pjotr.public14 at thebird.nl (pjotr.public14 at thebird.nl) Date: Tue, 4 Aug 2009 15:13:17 +0200 Subject: [BioLib-dev] GSL Message-ID: <20090804131317.GA15379@thebird.nl> Hi Xin, I have updated your contrib/libsequence tree. Also the GSL is now included in biolib (libsequence branch). You should find it in ./contrib/GSL. I also included a CMakeLists.txt file to compile the GSL into a shared library. Two tricks are needed, first GSL compiles a config.h file with global settings. Second it has a strange requirement for include file locations. Both are solved in that CMake file in less src/clibs/gsl/src/CMakeLists.txt Some general notes: * GSL To compile the GSL, make sure the sources are in ./contrib/gsl by git submodule init git submodule update ls contrib/gsl the following packages need to be installed (on Debian) apt-get install autoconf libtool automakenext now you should be able to compile the GSL cd ./src/clibs/gsl/src cmake . make Pj. From xshuai at umail.iu.edu Tue Aug 4 13:29:10 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Tue, 4 Aug 2009 13:29:10 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804131317.GA15379@thebird.nl> References: <20090804131317.GA15379@thebird.nl> Message-ID: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Everything looks fine until the last steps: when I ran: make The following error shows: /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: config.h: No such file or directory /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: gsl_version.h: No such file or directory /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: ?GSL_VERSION? undeclared here (not in a function) It seems that config.h and gsl_version.h cannot be found in my Mac. However, you mentioned that you've already solved them in CMakeLists.txt On Tue, Aug 4, 2009 at 9:13 AM, wrote: > Hi Xin, > > I have updated your contrib/libsequence tree. Also the GSL is now > included in biolib (libsequence branch). You should find it in > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > GSL into a shared library. Two tricks are needed, first GSL compiles > a config.h file with global settings. Second it has a strange > requirement for include file locations. > > Both are solved in that CMake file in > > less src/clibs/gsl/src/CMakeLists.txt > > Some general notes: > > * GSL > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > git submodule init > git submodule update > ls contrib/gsl > > the following packages need to be installed (on Debian) > > apt-get install autoconf libtool automakenext > > now you should be able to compile the GSL > > cd ./src/clibs/gsl/src > cmake . > make > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 13:38:12 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Tue, 4 Aug 2009 19:38:12 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Message-ID: <20090804173812.GA17997@thebird.nl> rm CMakeCache.txt cmake . make should create config.h. The symlink points from ./gsl/config.h. There should also be ./gsl/gsl_version.h - can you see that? Pj. On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > Everything looks fine until the last steps: > when I ran: > make > > The following error shows: > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > config.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > gsl_version.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > ?GSL_VERSION? undeclared here (not in a function) > > It seems that config.h and gsl_version.h cannot be found in my Mac. However, > you mentioned that you've already solved them in CMakeLists.txt > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > Hi Xin, > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > included in biolib (libsequence branch). You should find it in > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > GSL into a shared library. Two tricks are needed, first GSL compiles > > a config.h file with global settings. Second it has a strange > > requirement for include file locations. > > > > Both are solved in that CMake file in > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > Some general notes: > > > > * GSL > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > git submodule init > > git submodule update > > ls contrib/gsl > > > > the following packages need to be installed (on Debian) > > > > apt-get install autoconf libtool automakenext > > > > now you should be able to compile the GSL > > > > cd ./src/clibs/gsl/src > > cmake . > > make > > > > Pj. > > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 14:39:15 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Tue, 4 Aug 2009 20:39:15 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Message-ID: <20090804183915.GA18864@thebird.nl> I think you miss the venerable automake libtool autoconf tools. I just did a fresh install in a new image - if they are missing cmake will give errors. Once installed a fresh config.h will be generated by cmake. With all the tools it should compile. It is nasty, because for the first time we introduce ./configure and friends into biolib. It should be possible to avoid that. The complication is the generation of some include files. You'll need to link against the gsl-5.0.0.so/dylib library. That requires a new reference in the FindSWIG.cmake file. You may ignore that for now and, after a succesful generation of config.h, just compile the ./contrib/gsl/xxx/xxx.c files into your shared library. See if it works. Ideally we use the gsl shared lib. I can fix that later. Note also that the current setup won't work on Windows. As I have introduced symlinks for the include files. Pj. On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > Everything looks fine until the last steps: > when I ran: > make > > The following error shows: > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > config.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > gsl_version.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > ?GSL_VERSION? undeclared here (not in a function) > > It seems that config.h and gsl_version.h cannot be found in my Mac. However, > you mentioned that you've already solved them in CMakeLists.txt > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > Hi Xin, > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > included in biolib (libsequence branch). You should find it in > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > GSL into a shared library. Two tricks are needed, first GSL compiles > > a config.h file with global settings. Second it has a strange > > requirement for include file locations. > > > > Both are solved in that CMake file in > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > Some general notes: > > > > * GSL > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > git submodule init > > git submodule update > > ls contrib/gsl > > > > the following packages need to be installed (on Debian) > > > > apt-get install autoconf libtool automakenext > > > > now you should be able to compile the GSL > > > > cd ./src/clibs/gsl/src > > cmake . > > make > > > > Pj. > > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From xshuai at umail.iu.edu Tue Aug 4 16:42:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Tue, 4 Aug 2009 16:42:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804183915.GA18864@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> Message-ID: <3a7743460908041342s6704276nc1b88739cd8482da@mail.gmail.com> It finally works. But my solution is a little wired. According to your inspiration, I found that there's no configure shell in ./contrib/gsl. And I consulted some document and tried to run autogen.sh in the same directory to generate configure. But when I ran ./autogen.sh The error appeared that libtoolize tool is missing. Thus I thought maybe I haven't installed libtool, though I could found libtool in /usr/bin. I downloaded libtool package and tried to install it. But I failed because of some unknown error. Later on, I found that there's right a libtoolize shell in the libtool package. So I just copy that libtoolize to my /usr/bin. After that, I re-ran autogen.sh in ./contrib/gsl. And then I went into ./src/clibs/gsl/src again and ran cmake . make This time it did work. However, some 'undefined symbol' error came out at last. After checking I found that there's one file gamma_inc.c is forgot to be added to gsl_files.txt. Finally I added that file and the dynamic library is generated in /build On Tue, Aug 4, 2009 at 2:39 PM, Pjotr Prins wrote: > I think you miss the venerable automake libtool autoconf tools. I just did > a > fresh install in a new image - if they are missing cmake will give > errors. Once installed a fresh config.h will be generated by cmake. > With all the tools it should compile. > > It is nasty, because for the first time we introduce ./configure and > friends into biolib. It should be possible to avoid that. The > complication is the generation of some include files. > > You'll need to link against the gsl-5.0.0.so/dylib library. That requires > a > new reference in the FindSWIG.cmake file. You may ignore that for now > and, after a succesful generation of config.h, just compile the > ./contrib/gsl/xxx/xxx.c files into your shared library. See if it > works. > > Ideally we use the gsl shared lib. I can fix that later. > > Note also that the current setup won't work on Windows. As I have > introduced symlinks for the include files. > > Pj. > > On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > > Everything looks fine until the last steps: > > when I ran: > > make > > > > The following error shows: > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > > config.h: No such file or directory > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > > gsl_version.h: No such file or directory > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > > ?GSL_VERSION? undeclared here (not in a function) > > > > It seems that config.h and gsl_version.h cannot be found in my Mac. > However, > > you mentioned that you've already solved them in CMakeLists.txt > > > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > > > Hi Xin, > > > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > > included in biolib (libsequence branch). You should find it in > > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > > GSL into a shared library. Two tricks are needed, first GSL compiles > > > a config.h file with global settings. Second it has a strange > > > requirement for include file locations. > > > > > > Both are solved in that CMake file in > > > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > > > Some general notes: > > > > > > * GSL > > > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > > > git submodule init > > > git submodule update > > > ls contrib/gsl > > > > > > the following packages need to be installed (on Debian) > > > > > > apt-get install autoconf libtool automakenext > > > > > > now you should be able to compile the GSL > > > > > > cd ./src/clibs/gsl/src > > > cmake . > > > make > > > > > > Pj. > > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From hlapp at gmx.net Tue Aug 4 19:32:31 2009 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 4 Aug 2009 19:32:31 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804183915.GA18864@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> Message-ID: <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> Hi Pjotr - many systems come pre-installed with GSL these days. Is it really wise not to just assume it as a system dependency? -hilmar On Aug 4, 2009, at 2:39 PM, Pjotr Prins wrote: > I think you miss the venerable automake libtool autoconf tools. I > just did a > fresh install in a new image - if they are missing cmake will give > errors. Once installed a fresh config.h will be generated by cmake. > With all the tools it should compile. > > It is nasty, because for the first time we introduce ./configure and > friends into biolib. It should be possible to avoid that. The > complication is the generation of some include files. > > You'll need to link against the gsl-5.0.0.so/dylib library. That > requires a > new reference in the FindSWIG.cmake file. You may ignore that for now > and, after a succesful generation of config.h, just compile the > ./contrib/gsl/xxx/xxx.c files into your shared library. See if it > works. > > Ideally we use the gsl shared lib. I can fix that later. > > Note also that the current setup won't work on Windows. As I have > introduced symlinks for the include files. > > Pj. > > On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: >> Everything looks fine until the last steps: >> when I ran: >> make >> >> The following error shows: >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: >> error: >> config.h: No such file or directory >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: >> error: >> gsl_version.h: No such file or directory >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: >> ?GSL_VERSION? undeclared here (not in a function) >> >> It seems that config.h and gsl_version.h cannot be found in my Mac. >> However, >> you mentioned that you've already solved them in CMakeLists.txt >> >> On Tue, Aug 4, 2009 at 9:13 AM, wrote: >> >>> Hi Xin, >>> >>> I have updated your contrib/libsequence tree. Also the GSL is now >>> included in biolib (libsequence branch). You should find it in >>> ./contrib/GSL. I also included a CMakeLists.txt file to compile the >>> GSL into a shared library. Two tricks are needed, first GSL compiles >>> a config.h file with global settings. Second it has a strange >>> requirement for include file locations. >>> >>> Both are solved in that CMake file in >>> >>> less src/clibs/gsl/src/CMakeLists.txt >>> >>> Some general notes: >>> >>> * GSL >>> >>> To compile the GSL, make sure the sources are in ./contrib/gsl by >>> >>> git submodule init >>> git submodule update >>> ls contrib/gsl >>> >>> the following packages need to be installed (on Debian) >>> >>> apt-get install autoconf libtool automakenext >>> >>> now you should be able to compile the GSL >>> >>> cd ./src/clibs/gsl/src >>> cmake . >>> make >>> >>> Pj. >>> >>> >> >> >> -- >> Xin Shuai (David) >> PhD of Complex System in School of Informatics >> Indiana University Bloomington >> 812-606-8019 > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From pjotr.public14 at thebird.nl Wed Aug 5 02:07:47 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 08:07:47 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> Message-ID: <20090805060747.GA21684@thebird.nl> On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: > Hi Pjotr - many systems come pre-installed with GSL these days. Is it > really wise not to just assume it as a system dependency? > > -hilmar That is a call we have to make. There are two problems with these type of dependencies: (1) libraries change (2) on different systems they are in different places The main reason I like to have the source base inside biolib is that when we do a release we have ONE source base. So bugs can be found, without the added complexity of (1). Especially over time this is a great concern. On the Perl mailing list you encountered that this year with the staden_io_lib module - the interface changed. In addition many installations are quite old, so you get an old GSL library, or BOOST, or whatever. With (2) is a particular concern since bio* developers are all over the place: different distros of Linux, OSX, Cygwin, Windows. Having the source tree in biolib kills those birds with one stone. It is possible to use external dynamically linked libraries. We do that for Rlib.so and zlib.so now (note that Biolib does not compile, at this point, on Windows for that very reason). The call is on us. I am not convinced the GSL is stable, Xin had to add a symlink because one file was added in the last months, nor that it is easily found on most systems. And the source base is not that big (BOOST is ten times as big). We are mapping against these libraries - also the GSL. So in it goes, as far as I am concerned. If only for the fact the I only want the latest and greatest :-) With Biolib you will get a stable and modern set of tools to compile against. In addition we use the latest and fastest versions of dependent software. How do you think the bio* developers will like that? Pj. From hlapp at gmx.net Wed Aug 5 10:29:16 2009 From: hlapp at gmx.net (Hilmar Lapp) Date: Wed, 5 Aug 2009 10:29:16 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090805060747.GA21684@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> Message-ID: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> On Aug 5, 2009, at 2:07 AM, Pjotr Prins wrote: > On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: >> Hi Pjotr - many systems come pre-installed with GSL these days. Is it >> really wise not to just assume it as a system dependency? >> >> -hilmar > > That is a call we have to make. There are two problems with these > type of dependencies: > > (1) libraries change > > (2) on different systems they are in different places > > The main reason I like to have the source base inside biolib is that > when we do a release we have ONE source base. So bugs can be found, > without the added complexity of (1). You're really just shifting the complexity of (1) from the system administrator of a user's (or developer's) machine to yourself as the Biolib maintainer (or whoever comes after you). As not infrequently the user doubles as the sysadmin on her machine, this is of course nice for the Biolib user. However, it does create an additional burden, and especially responsibility, for the Biolib maintainers. I'm not convinced that fulfilling that responsibility is one of the best ways Biolib developers and maintainers can spend their time. > Especially over time this is a great concern. On the Perl mailing > list you encountered that this year with the staden_io_lib module - > the interface changed. I know. But it's also a very common situation that we all have to learn how to deal with anyway. Bio::Graphics needs a certain version of GD. Most systems come pre-installed with GD but in a version that's too old, so most people end up having to upgrade their GD, or install a newer version in parallel and then make sure their environment is correct when compiling the GD perl bindings etc. The same is typically true for DBI and the various DBD drivers. There are numerous other examples. > [...] > With (2) is a particular concern since bio* developers are all over > the place: different distros of Linux, OSX, Cygwin, Windows. Having > the source tree in biolib kills those birds with one stone. If there are no problems. As soon as there are (and there are bound to be if the library is under active development) there may be more birds to kill than you have stones (or time) for. > [...] > So in it goes, as far as I am concerned. If only for the fact the I > only want the latest and greatest :-) The other benefit that treating it as an external dependency has is tempering that desire for the bleeding edge. The bleeding edge cuts well, but it's full of blood too. That all being said, having the GSL SWIG-mapped as a first class library in Biolib so that all Bio* projects can take advantage of it would be very cool in its own right. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at illinois.edu Wed Aug 5 11:01:34 2009 From: cjfields at illinois.edu (Chris Fields) Date: Wed, 5 Aug 2009 10:01:34 -0500 Subject: [BioLib-dev] GSL In-Reply-To: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> Message-ID: <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> On Aug 5, 2009, at 9:29 AM, Hilmar Lapp wrote: > > On Aug 5, 2009, at 2:07 AM, Pjotr Prins wrote: > >> On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: >>> Hi Pjotr - many systems come pre-installed with GSL these days. Is >>> it >>> really wise not to just assume it as a system dependency? >>> >>> -hilmar >> >> That is a call we have to make. There are two problems with these >> type of dependencies: >> >> (1) libraries change >> >> (2) on different systems they are in different places >> >> The main reason I like to have the source base inside biolib is that >> when we do a release we have ONE source base. So bugs can be found, >> without the added complexity of (1). > > You're really just shifting the complexity of (1) from the system > administrator of a user's (or developer's) machine to yourself as > the Biolib maintainer (or whoever comes after you). As not > infrequently the user doubles as the sysadmin on her machine, this > is of course nice for the Biolib user. > > However, it does create an additional burden, and especially > responsibility, for the Biolib maintainers. I'm not convinced that > fulfilling that responsibility is one of the best ways Biolib > developers and maintainers can spend their time. I do have to second this. Also, many libraries come with some kind of config check available (what version the lib is, where the headers/ libs are, etc). This wasn't available when bioperl first added io_lib support. Also doesn't help when said code goes largely unmaintained (bioperl- ext is essentially deprecated b/c of bitrot). >> Especially over time this is a great concern. On the Perl mailing >> list you encountered that this year with the staden_io_lib module - >> the interface changed. > > I know. But it's also a very common situation that we all have to > learn how to deal with anyway. Bio::Graphics needs a certain version > of GD. Most systems come pre-installed with GD but in a version > that's too old, so most people end up having to upgrade their GD, or > install a newer version in parallel and then make sure their > environment is correct when compiling the GD perl bindings etc. The > same is typically true for DBI and the various DBD drivers. There > are numerous other examples. The same happens with perl itself. Due to worries about backwards- compat issues they have put off 5.10.1 for over a year now (it was due last summer). After a lot of back-and-forth (and a few resignations) the process is moving forward again, and 5.10.1 is imminent. The overall opinion is if a user wants the latest module updates, and if said module requires 5.10, they will need to upgrade to 5.10. >> [...] >> With (2) is a particular concern since bio* developers are all over >> the place: different distros of Linux, OSX, Cygwin, Windows. Having >> the source tree in biolib kills those birds with one stone. > > If there are no problems. As soon as there are (and there are bound > to be if the library is under active development) there may be more > birds to kill than you have stones (or time) for. > >> [...] >> So in it goes, as far as I am concerned. If only for the fact the I >> only want the latest and greatest :-) > > The other benefit that treating it as an external dependency has is > tempering that desire for the bleeding edge. The bleeding edge cuts > well, but it's full of blood too. If anything the reliance of users on bioperl's bleeding edge code (bioperl-live) has slowed development down to a crawl, and was the impetus for me to push a 1.6 release out ASAP (and the reason we have decided on restructuring bioperl for easier releases). Users who want bleeding edge code should expect bugs, possible API changes, etc. They get kudos for pointing out the bugs, sure, but I start pulling my hair out (what little I have on my head still) when I hear "Bio::Module::Foo in bioperl-live breaks or throws an error in my production code." It doesn't happen often, but enough to be frustrating. > That all being said, having the GSL SWIG-mapped as a first class > library in Biolib so that all Bio* projects can take advantage of it > would be very cool in its own right. > > -hilmar Agreed. chris From pjotr.public14 at thebird.nl Wed Aug 5 12:26:16 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:26:16 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> Message-ID: <20090805162616.GA2301@thebird.nl> On Wed, Aug 05, 2009 at 10:29:16AM -0400, Hilmar Lapp wrote: > However, it does create an additional burden, and especially > responsibility, for the Biolib maintainers. I'm not convinced that > fulfilling that responsibility is one of the best ways Biolib developers > and maintainers can spend their time. Not really. When the build system works, it is OK. Most users get a set of binary libraries. > The other benefit that treating it as an external dependency has is > tempering that desire for the bleeding edge. The bleeding edge cuts > well, but it's full of blood too. Stable installs tend to be older than 1 year. Which is a lot. > That all being said, having the GSL SWIG-mapped as a first class library > in Biolib so that all Bio* projects can take advantage of it would be > very cool in its own right. The GSL has been mapped for Perl and Ruby in ASciLib. I'll import that into biolib soon. There is another aspect. Because we have the sources together it is easier to fix stuff and send upstream. Rather then working around problems. So I think it worth our while. Pj. From pjotr.public14 at thebird.nl Wed Aug 5 12:33:08 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:33:08 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> Message-ID: <20090805163308.GB2301@thebird.nl> On Wed, Aug 05, 2009 at 10:01:34AM -0500, Chris Fields wrote: > The same happens with perl itself. Due to worries about backwards- > compat issues they have put off 5.10.1 for over a year now (it was due > last summer). That is really my point. Because biolib controls all dependencies, and names its own libraries, there are no conflicts with other versions. You can decide to safely run different versions of biolib. When all regression and unit tests succeed we are in business. The GSL is actually the only problematic one, as I have imported the autoconf toolset for it, which is kinda flaky in this setup. But I think we will get rid of that soon enough. For me, it is all about stability and predictability. I have a long history in software deployment. It is one reason I designed the build system like it is now. But I agree that, when libraries are stable enough, it makes sense to move that responsibility to the packagers. There is not a hair on my (sparsely covered) head which would include the sources of zlib. For one. Pj. From pjotr.public14 at thebird.nl Wed Aug 5 12:44:40 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:44:40 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090805163308.GB2301@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> <20090805163308.GB2301@thebird.nl> Message-ID: <20090805164440.GA4584@thebird.nl> On Wed, Aug 05, 2009 at 06:33:08PM +0200, Pjotr Prins wrote: > There is not a hair on my (sparsely covered) head which would include > the sources of zlib. For one. Hmmm. Does it mean anything when hair starts growing out of ones ears? Pj. From pjotr.public14 at thebird.nl Wed Aug 5 13:01:54 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 19:01:54 +0200 Subject: [BioLib-dev] USE_GSL Message-ID: <20090805170154.GA6391@thebird.nl> Hi Xin, Now we have a working libsequence compile we need to link that library. I am going to hand this to you - it is a nice exercise. Basically what you need to do is link libsequence-5.0.0.dylib (or .so in Linux) against the SWIG library you generate, e.g. python/../libsequence.so. That way you import the necessary functions from GSL. I have done something similar for the biolib-core shared library. When you check biolib/tools/cmake-support/modules you can see in FindMapLibraries.cmake that when you define 'USE_CORE' it will locate the shared library and set ${CORE_LIBRARY}. In fact, you have adapted that already for OSX before(!) Here create a section USE_GSL which defines GSL_LIBRARY. This in turn is linked in FindMapSWIG.cmake - in the line SWIG_LINK_LIBRARIES. Where the library gets linked against the SWIG generated libraries. Add ${GSL_LIBRARY} there. When someone defines USE_CORE in their CMakeLists.txt file (e.g. in the Python mapping) the biolib core library gets linked in. So, what you need to do is create a similar facility when someone defines USE_GSL. Which you can do for the libsequence mapping. First fork my cmake-support tree on github to your account. Next checkout the master branch in your biolib tree, etc. Exactly what you did with the libsequence git submodule a few days ago. Pj. From pjotr.public14 at thebird.nl Mon Aug 10 05:01:40 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 11:01:40 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> Message-ID: <20090810090140.GA11161@thebird.nl> Hi Xin, On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > I have already modified related .cmake files and tested it. It looked fine.If > only the problem of my last email is solved, I think I can update the > cmake-support submodule. Good job :-). I can build libsequence and compile Python bindings now. Cool stuff. Now the final step before merging into release_candidate. After updating from my tree: git pull pjotr libsequence git submodule update add a working 'integration' test to the Python module. When you do: cd src/mappings/swig/python/libsequence cmake . make make test you'll see 1/ 1 Testing TestPythonlibsequence ***Failed the output is in Testing/Temporary/LastTest.log. Currently ../test/test_libsequence.py consists of your doctests. They are bound to be elaborate. A biolib integration test merely makes sure the build system did not fail - so it usually has a few simple tests. Rename your current doctest to ../test/doctest_libsequence.py and create a new short test (see test_example.py) that confirms the libraries are linked together and the mapping just works. Same for the Perl module. Once that test passes I'll merge into release_candidate so Mark (and perhaps others) can start testing. Pj. P.S. I had to revert some changes in cmake-support. Not sure why you changed those, but I think this is correct. From xshuai at umail.iu.edu Mon Aug 10 11:20:38 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 11:20:38 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810090140.GA11161@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> Message-ID: <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> Oh, when I pull from your libsequence branch, the file mode change from 644->755 happened again! And it seems far more files than ever changed: mode change 100644 => 100755 .gitignore mode change 100644 => 100755 CMakeLists.txt mode change 100644 => 100755 INSTALL mode change 100644 => 100755 LICENSE mode change 100644 => 100755 PROJECTNAME mode change 100644 => 100755 README mode change 100644 => 100755 Rakefile mode change 100644 => 100755 TODO mode change 100644 => 100755 VERSION mode change 100644 => 100755 contrib/README.txt mode change 100644 => 100755 doc/APIDOCUMENTATION.txt mode change 100644 => 100755 doc/BUILD.txt mode change 100644 => 100755 doc/DEPENDENCIES.txt mode change 100644 => 100755 doc/DEVELOPMENT.txt mode change 100644 => 100755 doc/EXAMPLE.txt mode change 100644 => 100755 doc/GSL.txt mode change 100644 => 100755 doc/LAYOUT.txt mode change 100644 => 100755 doc/NIX.txt mode change 100644 => 100755 doc/OSX.txt mode change 100644 => 100755 doc/PACKAGING.txt mode change 100644 => 100755 doc/PERL.txt mode change 100644 => 100755 doc/PYTHON.txt mode change 100644 => 100755 doc/RELEASE_NOTES.txt mode change 100644 => 100755 doc/REPORTING_BUGS.txt mode change 100644 => 100755 doc/ROADMAP.txt mode change 100644 => 100755 doc/RUBY.txt mode change 100644 => 100755 doc/TESTING.txt mode change 100644 => 100755 doc/TROUBLESHOOTING.txt mode change 100644 => 100755 doc/WINDOWS.txt mode change 100644 => 100755 doc/doxygen/Doxyfile mode change 100644 => 100755 doc/doxygen/mainpage.txt mode change 100644 => 100755 doc/examples/c/CMakeLists.txt ... ... ... To my surprise, the same problem occurred again and again. If I try to modify them one by one like cmake-support, too much should be done this time. On Mon, Aug 10, 2009 at 5:01 AM, Pjotr Prins wrote: > Hi Xin, > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > I have already modified related .cmake files and tested it. It looked > fine.If > > only the problem of my last email is solved, I think I can update the > > cmake-support submodule. > > Good job :-). I can build libsequence and compile Python bindings > now. Cool stuff. Now the final step before merging into > release_candidate. After updating from my tree: > > git pull pjotr libsequence > git submodule update > > add a working 'integration' test to the Python module. When you do: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > the output is in Testing/Temporary/LastTest.log. > > Currently ../test/test_libsequence.py consists of your doctests. They > are bound to be elaborate. A biolib integration test merely makes sure > the build system did not fail - so it usually has a few simple tests. > > Rename your current doctest to ../test/doctest_libsequence.py > > and create a new short test (see test_example.py) that confirms the > libraries are linked together and the mapping just works. Same for > the Perl module. > > Once that test passes I'll merge into release_candidate so Mark (and > perhaps others) can start testing. > > Pj. > > P.S. I had to revert some changes in cmake-support. Not sure why you > changed those, but I think this is correct. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 11:49:04 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 17:49:04 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> Message-ID: <20090810154904.GA18103@thebird.nl> Heh. It is a fine mess :-). I think the problem is we have the patch in one of the branches, and it sneaks back in every time. When you check the log you'll see patch commit 50612d79cf02e767e3b39f6f8c8a13120525c630 Author: diavy Date: Sun Jul 12 01:13:00 2009 -0400 revision form pjotr containing the file mods. Can you provide me a branch without this patch? I'll make sure to work from there. Pj. On Mon, Aug 10, 2009 at 11:20:38AM -0400, Xin Shuai wrote: > Oh, when I pull from your libsequence branch, the file mode change from > 644->755 happened again! And it seems far more files than ever changed: > mode change 100644 => 100755 .gitignore > mode change 100644 => 100755 CMakeLists.txt > mode change 100644 => 100755 INSTALL From pjotr.public14 at thebird.nl Mon Aug 10 12:02:07 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 18:02:07 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090810090140.GA11161@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> Message-ID: <20090810160207.GA18659@thebird.nl> I think your master branch is clean. I'll work from there. Pj. On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > Hi Xin, > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > I have already modified related .cmake files and tested it. It looked fine.If > > only the problem of my last email is solved, I think I can update the > > cmake-support submodule. > > Good job :-). I can build libsequence and compile Python bindings > now. Cool stuff. Now the final step before merging into > release_candidate. After updating from my tree: > > git pull pjotr libsequence > git submodule update > > add a working 'integration' test to the Python module. When you do: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > the output is in Testing/Temporary/LastTest.log. > > Currently ../test/test_libsequence.py consists of your doctests. They > are bound to be elaborate. A biolib integration test merely makes sure > the build system did not fail - so it usually has a few simple tests. > > Rename your current doctest to ../test/doctest_libsequence.py > > and create a new short test (see test_example.py) that confirms the > libraries are linked together and the mapping just works. Same for > the Perl module. > > Once that test passes I'll merge into release_candidate so Mark (and > perhaps others) can start testing. > > Pj. > > P.S. I had to revert some changes in cmake-support. Not sure why you > changed those, but I think this is correct. > > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev From pjotr.public14 at thebird.nl Mon Aug 10 13:06:05 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 19:06:05 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090810160207.GA18659@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> Message-ID: <20090810170605.GA18767@thebird.nl> Hi Xin, This was a bit painful, but arguably my mistake. You can pull from my branch now without problems. You may have to revert your own branch to your github master first: to throw out the reintroduced patch. Note you have later put it new files with the wrong permissions. See the patch: c92151cdc3db8b353534532baee4c70dc5a2583e it includes a number of 755 permissions. When you create a new file on your machine: touch test.me ls -l test.me what are its permissions? It should be 644 or -rw-r--r--. If they are 755 (rwxr-xr-x) you may need to change the umask on your machine: umask 022 See Internet resources on how to manage that. Pj. On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > I think your master branch is clean. I'll work from there. > > Pj. > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > Hi Xin, > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > I have already modified related .cmake files and tested it. It looked fine.If > > > only the problem of my last email is solved, I think I can update the > > > cmake-support submodule. > > > > Good job :-). I can build libsequence and compile Python bindings > > now. Cool stuff. Now the final step before merging into > > release_candidate. After updating from my tree: > > > > git pull pjotr libsequence > > git submodule update > > > > add a working 'integration' test to the Python module. When you do: > > > > cd src/mappings/swig/python/libsequence > > cmake . > > make > > make test > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > the output is in Testing/Temporary/LastTest.log. > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > are bound to be elaborate. A biolib integration test merely makes sure > > the build system did not fail - so it usually has a few simple tests. > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > and create a new short test (see test_example.py) that confirms the > > libraries are linked together and the mapping just works. Same for > > the Perl module. > > > > Once that test passes I'll merge into release_candidate so Mark (and > > perhaps others) can start testing. > > > > Pj. > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > changed those, but I think this is correct. > > > > _______________________________________________ > > BioLib-dev mailing list > > BioLib-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/biolib-dev From xshuai at umail.iu.edu Mon Aug 10 15:33:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 15:33:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810170605.GA18767@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> Message-ID: <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> Hi, Pjotr: I checked my file permission set up in my machine and it is alright. So I don't need to change the unmask. Regarding to the bad commit, I think I forgot to tell you one thing. During the process of modifying the CMake files to include gsl linking, I found you named all the dependent library with a biolib_ prefix: biolib_core, biolib_R. So I renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake setup cannot find the gsl dynamic library. So when I commit, the .gsl/ directory with all its 644 mode files are deleted and a new directory ./biolib_gsl is added. This is not the first time I do this. At the beginning, when I compile the libsequence library, I handle it similarly: I changed the ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake setup cannot find correct path. So is there anything I missed? On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins wrote: > Hi Xin, > > This was a bit painful, but arguably my mistake. You can pull from my > branch now without problems. You may have to revert your own branch > to your github master first: to throw out the reintroduced patch. > > Note you have later put it new files with the wrong permissions. See > the patch: > > c92151cdc3db8b353534532baee4c70dc5a2583e > > it includes a number of 755 permissions. When you create a new file > on your machine: > > touch test.me > ls -l test.me > > what are its permissions? It should be 644 or -rw-r--r--. If they are > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > umask 022 > > See Internet resources on how to manage that. > > Pj. > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > I think your master branch is clean. I'll work from there. > > > > Pj. > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > Hi Xin, > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > I have already modified related .cmake files and tested it. It looked > fine.If > > > > only the problem of my last email is solved, I think I can update the > > > > cmake-support submodule. > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > now. Cool stuff. Now the final step before merging into > > > release_candidate. After updating from my tree: > > > > > > git pull pjotr libsequence > > > git submodule update > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > cd src/mappings/swig/python/libsequence > > > cmake . > > > make > > > make test > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > > are bound to be elaborate. A biolib integration test merely makes sure > > > the build system did not fail - so it usually has a few simple tests. > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > and create a new short test (see test_example.py) that confirms the > > > libraries are linked together and the mapping just works. Same for > > > the Perl module. > > > > > > Once that test passes I'll merge into release_candidate so Mark (and > > > perhaps others) can start testing. > > > > > > Pj. > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > > changed those, but I think this is correct. > > > > > > _______________________________________________ > > > BioLib-dev mailing list > > > BioLib-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 16:09:32 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 22:09:32 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> Message-ID: <20090810200932.GA21413@thebird.nl> All great :-) On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > Hi, Pjotr: I checked my file permission set up in my machine and it is > alright. So I don't need to change the unmask. > > Regarding to the bad commit, > I think I forgot to tell you one thing. During the process of > modifying the CMake files to include gsl linking, I found you named > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. So I > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > directory with all its 644 mode files are deleted and a new directory > ./biolib_gsl is added. > > This is not the first time I do this. At the beginning, when I compile the > libsequence library, I handle it similarly: I changed the > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > setup cannot find correct path. > > So is there anything I missed? > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins wrote: > > > Hi Xin, > > > > This was a bit painful, but arguably my mistake. You can pull from my > > branch now without problems. You may have to revert your own branch > > to your github master first: to throw out the reintroduced patch. > > > > Note you have later put it new files with the wrong permissions. See > > the patch: > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > it includes a number of 755 permissions. When you create a new file > > on your machine: > > > > touch test.me > > ls -l test.me > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > umask 022 > > > > See Internet resources on how to manage that. > > > > Pj. > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > I think your master branch is clean. I'll work from there. > > > > > > Pj. > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > Hi Xin, > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > I have already modified related .cmake files and tested it. It looked > > fine.If > > > > > only the problem of my last email is solved, I think I can update the > > > > > cmake-support submodule. > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > now. Cool stuff. Now the final step before merging into > > > > release_candidate. After updating from my tree: > > > > > > > > git pull pjotr libsequence > > > > git submodule update > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > cd src/mappings/swig/python/libsequence > > > > cmake . > > > > make > > > > make test > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > > > are bound to be elaborate. A biolib integration test merely makes sure > > > > the build system did not fail - so it usually has a few simple tests. > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > libraries are linked together and the mapping just works. Same for > > > > the Perl module. > > > > > > > > Once that test passes I'll merge into release_candidate so Mark (and > > > > perhaps others) can start testing. > > > > > > > > Pj. > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > > > changed those, but I think this is correct. > > > > > > > > _______________________________________________ > > > > BioLib-dev mailing list > > > > BioLib-dev at lists.open-bio.org > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From xshuai at umail.iu.edu Mon Aug 10 16:18:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 16:18:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810200932.GA21413@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> <20090810200932.GA21413@thebird.nl> Message-ID: <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> Then ,do I have to throw out that commit? On Mon, Aug 10, 2009 at 4:09 PM, Pjotr Prins wrote: > All great :-) > > On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > > Hi, Pjotr: I checked my file permission set up in my machine and it is > > alright. So I don't need to change the unmask. > > > > Regarding to the bad commit, > > I think I forgot to tell you one thing. During the process of > > modifying the CMake files to include gsl linking, I found you named > > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. > So I > > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > > directory with all its 644 mode files are deleted and a new directory > > ./biolib_gsl is added. > > > > This is not the first time I do this. At the beginning, when I compile > the > > libsequence library, I handle it similarly: I changed the > > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > > setup cannot find correct path. > > > > So is there anything I missed? > > > > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins >wrote: > > > > > Hi Xin, > > > > > > This was a bit painful, but arguably my mistake. You can pull from my > > > branch now without problems. You may have to revert your own branch > > > to your github master first: to throw out the reintroduced patch. > > > > > > Note you have later put it new files with the wrong permissions. See > > > the patch: > > > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > > > it includes a number of 755 permissions. When you create a new file > > > on your machine: > > > > > > touch test.me > > > ls -l test.me > > > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > > > umask 022 > > > > > > See Internet resources on how to manage that. > > > > > > Pj. > > > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > > I think your master branch is clean. I'll work from there. > > > > > > > > Pj. > > > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > > Hi Xin, > > > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > > I have already modified related .cmake files and tested it. It > looked > > > fine.If > > > > > > only the problem of my last email is solved, I think I can update > the > > > > > > cmake-support submodule. > > > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > > now. Cool stuff. Now the final step before merging into > > > > > release_candidate. After updating from my tree: > > > > > > > > > > git pull pjotr libsequence > > > > > git submodule update > > > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > > > cd src/mappings/swig/python/libsequence > > > > > cmake . > > > > > make > > > > > make test > > > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. > They > > > > > are bound to be elaborate. A biolib integration test merely makes > sure > > > > > the build system did not fail - so it usually has a few simple > tests. > > > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > > libraries are linked together and the mapping just works. Same for > > > > > the Perl module. > > > > > > > > > > Once that test passes I'll merge into release_candidate so Mark > (and > > > > > perhaps others) can start testing. > > > > > > > > > > Pj. > > > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why > you > > > > > changed those, but I think this is correct. > > > > > > > > > > _______________________________________________ > > > > > BioLib-dev mailing list > > > > > BioLib-dev at lists.open-bio.org > > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 16:25:08 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 22:25:08 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> <20090810200932.GA21413@thebird.nl> <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> Message-ID: <20090810202508.GA21501@thebird.nl> The tree looks sane to me - as it is now. The renaming is there biolib_gsl. Your branch on your machine is probably dirty now. But the ones on github are fine. Destroy all the branches with the dirty patch (after making a backup). Pull your github master branch and update from my libsequence branch. Everything should by hunky dory. Pj. On Mon, Aug 10, 2009 at 04:18:51PM -0400, Xin Shuai wrote: > Then ,do I have to throw out that commit? > > On Mon, Aug 10, 2009 at 4:09 PM, Pjotr Prins wrote: > > > All great :-) > > > > On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > > > Hi, Pjotr: I checked my file permission set up in my machine and it is > > > alright. So I don't need to change the unmask. > > > > > > Regarding to the bad commit, > > > I think I forgot to tell you one thing. During the process of > > > modifying the CMake files to include gsl linking, I found you named > > > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. > > So I > > > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > > > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > > > directory with all its 644 mode files are deleted and a new directory > > > ./biolib_gsl is added. > > > > > > This is not the first time I do this. At the beginning, when I compile > > the > > > libsequence library, I handle it similarly: I changed the > > > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > > > setup cannot find correct path. > > > > > > So is there anything I missed? > > > > > > > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins > >wrote: > > > > > > > Hi Xin, > > > > > > > > This was a bit painful, but arguably my mistake. You can pull from my > > > > branch now without problems. You may have to revert your own branch > > > > to your github master first: to throw out the reintroduced patch. > > > > > > > > Note you have later put it new files with the wrong permissions. See > > > > the patch: > > > > > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > > > > > it includes a number of 755 permissions. When you create a new file > > > > on your machine: > > > > > > > > touch test.me > > > > ls -l test.me > > > > > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > > > > > umask 022 > > > > > > > > See Internet resources on how to manage that. > > > > > > > > Pj. > > > > > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > > > I think your master branch is clean. I'll work from there. > > > > > > > > > > Pj. > > > > > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > > > Hi Xin, > > > > > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > > > I have already modified related .cmake files and tested it. It > > looked > > > > fine.If > > > > > > > only the problem of my last email is solved, I think I can update > > the > > > > > > > cmake-support submodule. > > > > > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > > > now. Cool stuff. Now the final step before merging into > > > > > > release_candidate. After updating from my tree: > > > > > > > > > > > > git pull pjotr libsequence > > > > > > git submodule update > > > > > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > > > > > cd src/mappings/swig/python/libsequence > > > > > > cmake . > > > > > > make > > > > > > make test > > > > > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. > > They > > > > > > are bound to be elaborate. A biolib integration test merely makes > > sure > > > > > > the build system did not fail - so it usually has a few simple > > tests. > > > > > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > > > libraries are linked together and the mapping just works. Same for > > > > > > the Perl module. > > > > > > > > > > > > Once that test passes I'll merge into release_candidate so Mark > > (and > > > > > > perhaps others) can start testing. > > > > > > > > > > > > Pj. > > > > > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why > > you > > > > > > changed those, but I think this is correct. > > > > > > > > > > > > _______________________________________________ > > > > > > BioLib-dev mailing list > > > > > > BioLib-dev at lists.open-bio.org > > > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > > > > > > > > > > > -- > > > Xin Shuai (David) > > > PhD of Complex System in School of Informatics > > > Indiana University Bloomington > > > 812-606-8019 > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From pjotr.public14 at thebird.nl Wed Aug 12 03:15:22 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 12 Aug 2009 09:15:22 +0200 Subject: [BioLib-dev] release candidate Message-ID: <20090812071522.GA5274@thebird.nl> Hi Xin, I renamed the test file so it gets found by Cmake. However, the test fails: cd src/mappings/swig/python/libsequence cmake . make make test gives: Command: "/usr/bin/python" "./../test/test_libsequence.py" Directory: /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence "TestPythonlibsequence" start time: Aug 12 08:59 CEST Output: ---------------------------------------------------------- Traceback (most recent call last): File "./../test/test_libsequence.py", line 5, in from biolib.libsequence import * File "biolib/libsequence.py", line 7, in import _libsequence ImportError: /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int This error is caused, most likely, because we build the gsl with inline functions. INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, unsigned l ong int n); The INLINE is used for performance reasons (see http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible outside the shared library itself. However SWIG thinks it is visible, because it is defined in gsl_rng.h) and has created a mapping for it. That is why the test fails. A first good case for an integration test :-) Can you find a way to tell SWIG *not* to create a mapping for this, and similar, declarations? But first you need to ascertain this test fails on your system. If it does not, I suspect your linker finds a different GSL shared library on your system - one that has the INLINE statement switched off. In Linux we can use something like ldd libsequence-swig.so (or similar dylib) to find what libraries it links against. On my system it renders: ldd biolib/_libsequence.so linux-gate.so.1 => (0xb7f42000) libbiolib_libsequence-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/libbiolib_libsequence-0.0.5.so (0xb7acd000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) libbiolib_gsl-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so (0xb7735000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) /lib/ld-linux.so.2 (0xb7f43000) You see it uses libbiolib_gsl-0.0.5.so Pj. From xshuai at umail.iu.edu Wed Aug 12 15:56:34 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Wed, 12 Aug 2009 15:56:34 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090812071522.GA5274@thebird.nl> References: <20090812071522.GA5274@thebird.nl> Message-ID: <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> Hi, Pjotr: I don't have such kind of problem in my machine, but I did revise the rng.c file in gsl library in ./contrib after I first pulled from your libsequence branch and update the submodule. Actually speaking, what I did is restore rng.c file to its original state, since I found that your ./contrib/gsl/rng/rng.c is different from the original one(gsl-1.11 version). I don't know why it is modified in ./contrib/gsl directory (I once mentioned in my email and maybe you didn't notice that). The difference between your ./contrib/gsl/rng/rng.c and the original one is that, the modified file is missing the following part: #ifndef HIDE_INLINE_STATIC unsigned long int gsl_rng_get (const gsl_rng * r) { return (r->type->get) (r->state); } double gsl_rng_uniform (const gsl_rng * r) { return (r->type->get_double) (r->state); } double gsl_rng_uniform_pos (const gsl_rng * r) { double x ; do { x = (r->type->get_double) (r->state) ; } while (x == 0) ; return x ; } /* Note: to avoid integer overflow in (range+1) we work with scale = range/n = (max-min)/n rather than scale=(max-min+1)/n, this reduces efficiency slightly but avoids having to check for the out of range value. Note that range is typically O(2^32) so the addition of 1 is negligible in most usage. */ unsigned long int gsl_rng_uniform_int (const gsl_rng * r, unsigned long int n) { unsigned long int offset = r->type->min; unsigned long int range = r->type->max - offset; unsigned long int scale; unsigned long int k; if (n > range || n == 0) { GSL_ERROR_VAL ("invalid n, either 0 or exceeds maximum value of generator", GSL_EINVAL, 0) ; } scale = range / n; do { k = (((r->type->get) (r->state)) - offset) / scale; } while (k >= n); return k; } #endif So I just added the following part to my./contrib/gsl/rng/rng.c. (The reason I found this problem is that when I import libsequence in Python, gsl_rng_uniform is reported missing. It really took me some time to figure it out) However, when I added that part, which seems related with 'inline' definition. Then I just remove the 'inline.cc' file name from the gsl_file.txt list. And everything looked fine then. Therefore, I guess maybe you modified the original file to avoid inline problem. On Wed, Aug 12, 2009 at 3:15 AM, Pjotr Prins wrote: > Hi Xin, > > I renamed the test file so it gets found by Cmake. > > However, the test fails: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > gives: > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > Directory: > /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > Output: > ---------------------------------------------------------- > Traceback (most recent call last): > File "./../test/test_libsequence.py", line 5, in > from biolib.libsequence import * > File "biolib/libsequence.py", line 7, in > import _libsequence > ImportError: > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > This error is caused, most likely, because we build the gsl with inline > functions. > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, > unsigned l ong int n); > > The INLINE is used for performance reasons (see > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible > outside > the shared library itself. However SWIG thinks it is visible, because it is > defined in gsl_rng.h) and has created a mapping for it. That is why the > test > fails. A first good case for an integration test :-) > > Can you find a way to tell SWIG *not* to create a mapping for this, and > similar, > declarations? > > But first you need to ascertain this test fails on your system. If it does > not, > I suspect your linker finds a different GSL shared library on your system - > one > that has the INLINE statement switched off. In Linux we can use something > like > > ldd libsequence-swig.so (or similar dylib) > > to find what libraries it links against. On my system it renders: > > ldd biolib/_libsequence.so > > linux-gate.so.1 => (0xb7f42000) > libbiolib_libsequence-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/ > libbiolib_libsequence-0.0.5.so (0xb7acd000) > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > libbiolib_gsl-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so (0xb7735000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > /lib/ld-linux.so.2 (0xb7f43000) > > You see it uses libbiolib_gsl-0.0.5.so > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Thu Aug 13 03:05:52 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Thu, 13 Aug 2009 09:05:52 +0200 Subject: [BioLib-dev] release candidate In-Reply-To: <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> References: <20090812071522.GA5274@thebird.nl> <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> Message-ID: <20090813070552.GA12306@thebird.nl> Hi Xin, On Wed, Aug 12, 2009 at 03:56:34PM -0400, Xin Shuai wrote: > Hi, Pjotr: I don't have such kind of problem in my machine, but I did > revise the rng.c file in gsl library in ./contrib after I first pulled from > your libsequence branch and update the submodule. The gsl tree loaded into biolib is from the original repository - so the later version has moved the inline stuff. In fact if you do: cd contrib/gsl git checkout master gitk rng/rng.c You can see patch 85b66997ea8b66cd4b07c283a2ee7823faadc740 by Brian Gough does exactly that. I think we need to track the GSL, don't you? > Actually speaking, what I did is restore rng.c file to its original state, > since I found that your ./contrib/gsl/rng/rng.c is different from the > original one(gsl-1.11 version). I don't know why it is modified in > ./contrib/gsl directory (I once mentioned in my email and maybe you didn't > notice that). The difference between your ./contrib/gsl/rng/rng.c and the > original one is that, the modified file is missing the following part: > > #ifndef HIDE_INLINE_STATIC > > unsigned long int I think the GSL now always uses the INLINE version as all current C compilers support inline. I see one solution or one work around: allow the GSL to function with SWIG by handling INLINE correctly (this should be possible) and the other where we have our own version of rng.c in ./src/clibs/gsl/src/rng.c. The last is a workaround, and, in this case perhaps acceptable. How do you want to handle this? Pj. From xshuai at umail.iu.edu Thu Aug 13 10:57:28 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Thu, 13 Aug 2009 10:57:28 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090813070552.GA12306@thebird.nl> References: <20090812071522.GA5274@thebird.nl> <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> <20090813070552.GA12306@thebird.nl> Message-ID: <3a7743460908130757xe3276eflf4f37db2d8d00d5@mail.gmail.com> Oh....I see, it is the modification from the author.I think at this moment I'll take the work around solution, that is using my version in ./src/clibs/gsl/src/rng.c. Since time is limited I want to concentrate on solving more problems in testing and mapping. Maybe We can find a better solution in the future. On Thu, Aug 13, 2009 at 3:05 AM, Pjotr Prins wrote: > Hi Xin, > > On Wed, Aug 12, 2009 at 03:56:34PM -0400, Xin Shuai wrote: > > Hi, Pjotr: I don't have such kind of problem in my machine, but I did > > revise the rng.c file in gsl library in ./contrib after I first pulled > from > > your libsequence branch and update the submodule. > > The gsl tree loaded into biolib is from the original repository - so > the later version has moved the inline stuff. In fact if you do: > > cd contrib/gsl > git checkout master > gitk rng/rng.c > > You can see patch 85b66997ea8b66cd4b07c283a2ee7823faadc740 by Brian > Gough does exactly that. > > I think we need to track the GSL, don't you? > > > Actually speaking, what I did is restore rng.c file to its original > state, > > since I found that your ./contrib/gsl/rng/rng.c is different from the > > original one(gsl-1.11 version). I don't know why it is modified in > > ./contrib/gsl directory (I once mentioned in my email and maybe you > didn't > > notice that). The difference between your ./contrib/gsl/rng/rng.c and the > > original one is that, the modified file is missing the following part: > > > > #ifndef HIDE_INLINE_STATIC > > > > unsigned long int > > > > I think the GSL now always uses the INLINE version as all current C > compilers support inline. I see one solution or one work around: allow > the GSL to function with SWIG by handling INLINE correctly (this > should be possible) and the other where we have our own version of > rng.c in ./src/clibs/gsl/src/rng.c. The last is a workaround, and, in > this case perhaps acceptable. > > How do you want to handle this? > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Fri Aug 14 02:27:43 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Fri, 14 Aug 2009 08:27:43 +0200 Subject: [BioLib-dev] release candidate In-Reply-To: <20090812071522.GA5274@thebird.nl> References: <20090812071522.GA5274@thebird.nl> Message-ID: <20090814062743.GA22829@thebird.nl> Hi Xin, Everything compiles. Now the final bit - the integration test now expects input from stdin (a FASTA sequence). That should be read from a file instead. I have added src/test/data/fasta/example.fasta to the repository. Pj. On Wed, Aug 12, 2009 at 09:15:22AM +0200, Pjotr Prins wrote: > Hi Xin, > > I renamed the test file so it gets found by Cmake. > > However, the test fails: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > gives: > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > Directory: /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > Output: > ---------------------------------------------------------- > Traceback (most recent call last): > File "./../test/test_libsequence.py", line 5, in > from biolib.libsequence import * > File "biolib/libsequence.py", line 7, in > import _libsequence > ImportError: /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > This error is caused, most likely, because we build the gsl with inline > functions. > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, unsigned l ong int n); > > The INLINE is used for performance reasons (see > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible outside > the shared library itself. However SWIG thinks it is visible, because it is > defined in gsl_rng.h) and has created a mapping for it. That is why the test > fails. A first good case for an integration test :-) > > Can you find a way to tell SWIG *not* to create a mapping for this, and similar, > declarations? > > But first you need to ascertain this test fails on your system. If it does not, > I suspect your linker finds a different GSL shared library on your system - one > that has the INLINE statement switched off. In Linux we can use something like > > ldd libsequence-swig.so (or similar dylib) > > to find what libraries it links against. On my system it renders: > > ldd biolib/_libsequence.so > > linux-gate.so.1 => (0xb7f42000) > libbiolib_libsequence-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/libbiolib_libsequence-0.0.5.so (0xb7acd000) > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > libbiolib_gsl-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so (0xb7735000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > /lib/ld-linux.so.2 (0xb7f43000) > > You see it uses libbiolib_gsl-0.0.5.so > > Pj. > > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev From xshuai at umail.iu.edu Fri Aug 14 12:04:12 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Fri, 14 Aug 2009 12:04:12 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090814062743.GA22829@thebird.nl> References: <20090812071522.GA5274@thebird.nl> <20090814062743.GA22829@thebird.nl> Message-ID: <3a7743460908140904o8841966w765f3f72c2c2b986@mail.gmail.com> OK. I 've already updated that and set the file path in my test_libsequence.py On Fri, Aug 14, 2009 at 2:27 AM, Pjotr Prins wrote: > Hi Xin, > > Everything compiles. Now the final bit - the integration test now > expects input from stdin (a FASTA sequence). That should be read from > a file instead. I have added > > src/test/data/fasta/example.fasta > > to the repository. > > Pj. > > On Wed, Aug 12, 2009 at 09:15:22AM +0200, Pjotr Prins wrote: > > Hi Xin, > > > > I renamed the test file so it gets found by Cmake. > > > > However, the test fails: > > > > cd src/mappings/swig/python/libsequence > > cmake . > > make > > make test > > > > gives: > > > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > > Directory: > /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > > Output: > > ---------------------------------------------------------- > > Traceback (most recent call last): > > File "./../test/test_libsequence.py", line 5, in > > from biolib.libsequence import * > > File "biolib/libsequence.py", line 7, in > > import _libsequence > > ImportError: > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > > > > This error is caused, most likely, because we build the gsl with inline > > functions. > > > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, > unsigned l ong int n); > > > > The INLINE is used for performance reasons (see > > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible > outside > > the shared library itself. However SWIG thinks it is visible, because it > is > > defined in gsl_rng.h) and has created a mapping for it. That is why the > test > > fails. A first good case for an integration test :-) > > > > Can you find a way to tell SWIG *not* to create a mapping for this, and > similar, > > declarations? > > > > But first you need to ascertain this test fails on your system. If it > does not, > > I suspect your linker finds a different GSL shared library on your system > - one > > that has the INLINE statement switched off. In Linux we can use something > like > > > > ldd libsequence-swig.so (or similar dylib) > > > > to find what libraries it links against. On my system it renders: > > > > ldd biolib/_libsequence.so > > > > linux-gate.so.1 => (0xb7f42000) > > libbiolib_libsequence-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/ > libbiolib_libsequence-0.0.5.so (0xb7acd000) > > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > > libbiolib_gsl-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so (0xb7735000) > > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > > /lib/ld-linux.so.2 (0xb7f43000) > > > > You see it uses libbiolib_gsl-0.0.5.so > > > > Pj. > > > > _______________________________________________ > > BioLib-dev mailing list > > BioLib-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Fri Aug 14 12:16:40 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Fri, 14 Aug 2009 12:16:40 -0400 Subject: [BioLib-dev] Focus of my task during last few days. Message-ID: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> Hi, All: Since only a few days left to the project deadline, I 've tried to figured out and solved as many as problems as in the process of mapping and wrapping. However, there're still a few problems left. For some of them I know the reason but don't know to solve it, for others I just don't know the reason at all. Currently I still want to solve those problem if I can. Overall, I think libsequence can be used generally now for Python/Perl. Python unit testing is almost finished, except those problematic classes and functions. Perl unit testing still needs to add. Comparatively, integration testing are quite simple. Thus, in the last few days, I want to know what you expect me to focus: (1) Try to solve the rest of those mapping and testing problems (2) Enrich the integration testing using current usable classes and functions , to include more user case (3) Anything else. Just let me know that I can have an arrangement. -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Fri Aug 14 12:23:59 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Fri, 14 Aug 2009 18:23:59 +0200 Subject: [BioLib-dev] Focus of my task during last few days. In-Reply-To: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> References: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> Message-ID: <20090814162359.GB1128@thebird.nl> I vote for (1) On Fri, Aug 14, 2009 at 12:16:40PM -0400, Xin Shuai wrote: > Hi, All: Since only a few days left to the project deadline, I 've tried to > figured out and solved as many as problems as in the process of mapping and > wrapping. However, there're still a few problems left. For some of them I > know the reason but don't know to solve it, for others I just don't know the > reason at all. Currently I still want to solve those problem if I can. > Overall, I think libsequence can be used generally now for Python/Perl. > Python unit testing is almost finished, except those problematic classes and > functions. Perl unit testing still needs to add. Comparatively, integration > testing are quite simple. > > Thus, in the last few days, I want to know what you expect me to focus: > (1) Try to solve the rest of those mapping and testing problems > (2) Enrich the integration testing using current usable classes and > functions , to include more user case > (3) Anything else. > > Just let me know that I can have an arrangement. > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From cjfields at illinois.edu Fri Aug 14 14:53:00 2009 From: cjfields at illinois.edu (Chris Fields) Date: Fri, 14 Aug 2009 13:53:00 -0500 Subject: [BioLib-dev] Focus of my task during last few days. In-Reply-To: <20090814162359.GB1128@thebird.nl> References: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> <20090814162359.GB1128@thebird.nl> Message-ID: Same here, go for option (1). Testing is important, but as we're in the short term, I think emphasis should be on finishing the implementation first. Once that's in place we can work on tests. chris On Aug 14, 2009, at 11:23 AM, Pjotr Prins wrote: > I vote for (1) > > On Fri, Aug 14, 2009 at 12:16:40PM -0400, Xin Shuai wrote: >> Hi, All: Since only a few days left to the project deadline, I 've >> tried to >> figured out and solved as many as problems as in the process of >> mapping and >> wrapping. However, there're still a few problems left. For some of >> them I >> know the reason but don't know to solve it, for others I just don't >> know the >> reason at all. Currently I still want to solve those problem if I >> can. >> Overall, I think libsequence can be used generally now for Python/ >> Perl. >> Python unit testing is almost finished, except those problematic >> classes and >> functions. Perl unit testing still needs to add. Comparatively, >> integration >> testing are quite simple. >> >> Thus, in the last few days, I want to know what you expect me to >> focus: >> (1) Try to solve the rest of those mapping and testing problems >> (2) Enrich the integration testing using current usable classes and >> functions , to include more user case >> (3) Anything else. >> >> Just let me know that I can have an arrangement. >> >> >> >> >> -- >> Xin Shuai (David) >> PhD of Complex System in School of Informatics >> Indiana University Bloomington >> 812-606-8019 From pjotr.public14 at thebird.nl Sat Aug 1 07:02:19 2009 From: pjotr.public14 at thebird.nl (pjotr.public14 at thebird.nl) Date: Sat, 1 Aug 2009 09:02:19 +0200 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> References: <20090731075810.GA8052@thebird.nl> <20090731075948.GA8974@thebird.nl> <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> Message-ID: <20090801070219.GA22043@thebird.nl> On Fri, Jul 31, 2009 at 11:18:26AM -0400, Xin Shuai wrote: > Hi, I did pull your libsequence branch into my master_conflict branch. > 140-182-128-142:biolib diavy$ git pull pjotrp libsequence > > However something reemerged: > > 12 files changed, 31 insertions(+), 19 deletions(-) > mode change 100644 => 100755 .gitignore > mode change 100644 => 100755 CMakeLists.txt > mode change 100644 => 100755 INSTALL > mode change 100644 => 100755 LICENSE > mode change 100644 => 100755 PROJECTNAME > mode change 100644 => 100755 README > mode change 100644 => 100755 Rakefile > mode change 100644 => 100755 TODO > mode change 100644 => 100755 VERSION > ...... > > I remember the similar situation happened when I commited ( you said I > changed the file permission!) > > Is it normal or abnormal? I really don't hope the same thing occurred! What happened is I cloned your master branch. Next pulled from your master_conflict branch. The master branch contained the old patch - so it got merged in again. I think it advisable you remove the old master branch to avoid confusion - or, better, synchronize the master_conflict branch with your master branch. Something like this can work: -- make a backup first of your tree git checkout master_conflict git branch -D master # delete master git checkout -b master # create new master git push -f github master # overwrite old master github/origin That way the patch goes away forever. I'll clone master_conflict now and merge my changes in again. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 07:46:48 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 09:46:48 +0200 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <20090801070219.GA22043@thebird.nl> References: <20090731075810.GA8052@thebird.nl> <20090731075948.GA8974@thebird.nl> <3a7743460907310818g1b3671a9u6043088af6da37c7@mail.gmail.com> <20090801070219.GA22043@thebird.nl> Message-ID: <20090801074648.GA22853@thebird.nl> On Sat, Aug 01, 2009 at 09:02:19AM +0200, pjotr.public14 at thebird.nl wrote: > -- make a backup first of your tree > git checkout master_conflict > git branch -D master # delete master > git checkout -b master # create new master > git push -f github master # overwrite old master github/origin The last one does not work, my mistake. The way to delete a remote branch is git push github :master next push (the correct branch) to it git push github master OK, new chapter. I am going to show how to revert to an older branch and bring in later patches. I just updated my version of libsequence. I removed the master_conflict branch and checked out your current master_conflict version on github (which does not contain the bad patch): git branch -D master_conflict # remove old local version git checkout --track -b master_conflict origin/master_conflict next I checked the patches I wrote yesterday, and 'cherry-picked' them into your branch: git log master # cherry picking my recent changes git cherry-pick 5d01107bcd839e8a5725ec24f5b813311975b663 (etc.) then I removed my remote github branch and pushed the latest version. git push -f github :master_conflict # deleting remote repo git push -f github master_conflict Now *my* branch is master_conflict version is clean. So I renamed it to libsequence again ;-) git checkout -b libsequence Note that your local branch is probably diluted now with the dirty patches. You need to do something similar to the above starting from my libsequence branch. Create a new branch (assuming my remote is named pjotr): git checkout -b libsequence pjotr/libsequence and cherry-pick *your* latest patches from yesterday. Finally push it to your own tree: git push origin libsequence so I can start pulling from there again. Is this clear? Again, make backups before starting. It is easy to remove some work accidentily. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 08:16:43 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 10:16:43 +0200 Subject: [BioLib-dev] Merging libsequence into main Message-ID: <20090801081643.GA26569@thebird.nl> On Fri, Jul 31, 2009 at 12:01:32PM -0400, Xin Shuai wrote: > Except for the doubt I raised in my last email(I really don't dare to commit > freely this time unless you told me nothing is wrong), I've already updated > the contrib with two submodules: libsequence-1.6.6 and boost. I would have created another remote branch. That way it would have been possible for me to see the differences. Now I am blind to the latest changes. > Regarding to your error, yes, I once met them before. So I modified > a few .hpp , .cc and .tcc files to make them work for swig. That's > way I once asked you if it is OK for me to modify the original > files. > > I attached a txt file which documents all the files I have modified and how. Ah, that is cool. I see you have fixed a number of problems by modifying BOOST and libsequence sources. The only problem is that I don't have them in the tree now. The nice thing is that we actually have both libraries as git repositories in biolib(!). This means we can clone the trees onto our own github accounts, and push the patches. That way we can make visible what works and doesn't work - and share the changes. If you use my latest libsequence branch and run git submodule -i update you will have both repositories locally. Let's start with a change to libsequence: cd contrib/libsequence-1.6.6 git checkout -b xin # important since a git submodule is a virtual branch # hack hack # test git commit Now you have patches. So what next? Two options, clone the libsequence library at http://github.com/pjotrp/libsequence/tree on github and push the patches to your tree. This is nice. I can pull from that tree. Another option is to mail me the patches (as generated by git). The same thing can be done for the BOOST tree. I cloned it from git://gitorious.org/boost/svn.git. Unfortunately it is large and may not fit into your free github account. You'll have to either upgrade github, or I need add you to my github account, or you send me patches. What do you prefer? BTW, fixing upstream libraries - you have to make a call. Really changes should go in we can send upstream to the maintainers. Just commenting out problematic code is not a 'solution'. For isolated cases there are a number of options: 1. Tell SWIG to ignore the code (renames, macros) 2. Create a derived class that is used by SWIG, rather than the parent If it is unavoidable to parse the master file, and SWIG cracks, maybe we can have a copy of that one particular file in the biolib tree, which is compiled, rather than the one in contrib. So problematic.h is found in: ./src/clibs/libsequence/include/problematic.h rather then ./contrib/libsequence/include/problematic.h In other words, fixing the master repositories should be useful to upstream users. Otherwise we need to hack it in biolib itself. Pj. From pjotr.public14 at thebird.nl Sat Aug 1 08:55:47 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Sat, 1 Aug 2009 10:55:47 +0200 Subject: [BioLib-dev] Merging biopp into main Message-ID: <20090801085547.GA26863@thebird.nl> Hi Adam, Thanks for moving the SWIG files into src/mappings/swig/python/biopp. >From your BLOG I gather you have a building Bio++ map for Python. That is cool - I would like to merge it into the next release of biolib. We need to get it to build it into biolib automatically with CMake. The first step is to compile the biopp C++ library from source in biolib. I have checked out your branch into a clean tree: git clone git://github.com/adamsmith/biolib.git biolib-biopp cd biolib-biopp/ git checkout --track -b biopp origin/biopp git pull git submodule init git submodule update # fetching biopp into ./contrib/biopp cd ./src/clibs/biopp/src here I should be able to do: cmake . make to build the biopp.so into ../build. I fixed that in earlier days, but you never merged my changes into your tree. So let's start from this point. One of my notes says: == Building the C++ libraries == The control files for building the Bio++ C libraries are in ./src/clibs/biopp/ cd ./src/clibs/biopp/src/ rm CMakeCache.txt ; cmake . ; make should build a shared library in ./src/clibs/biopp/build. This is the library we link against. (Note: As Bio++ has namespaces we can build one single .so file). It is named something like libbiolib_biopp-0.0.5.so, where the version number reflects the biolib repository VERSION. == Continuing... == So I have updated CMakeLists.txt and files.txt in my biopp_fix branch. cd ./src/clibs/biopp/src/ rm CMakeCache.txt ; cmake . ; make shows: STATUS,"FindMap.cmake" PREFIX: /usr/local CMAKE_INSTALL_PREFIX=/usr/local MAP_ROOT=../../../.. MAP_CLIBS_PATH=../../../../src/clibs MAP_PROJECTNAME=biolib MAP_VERSION=0.0.5 -- ClibMacros.cmake CONTRIB_PATH= LIBNAME=biolib_biopp-0.0.5 BUILDDIR=../../../../src/clibs/biopp/build -- Configuring done -- Generating done -- Build files have been written to: /export/users/local/wrk/git/opensource/biolib-biopp/src/clibs/biopp/src Scanning dependencies of target biolib_biopp-0.0.5 [ 6%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/ApplicationTools.cpp.o [ 13%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/AttributesTools.cpp.o [ 20%] Building CXX object CMakeFiles/biolib_biopp-0.0.5.dir/home/wrk/git/opensource/biolib-biopp/contrib/biopp/utils/Utils/ColorTools.cpp.o (etc) Linking CXX shared library /export/users/local/wrk/git/opensource/biolib-biopp/src/clibs/biopp/build/libbiolib_biopp-0.0.5.so [100%] Built target biolib_biopp-0.0.5 Can you repeat this feat by pulling from my branch. First add my remote repository: git remote add pjotr git://github.com/pjotrp/biolib.git # update branch, probably best to checkout a temporary one git checkout -b biopp_fix git pull pjotr biopp_fix # check changes git log # (or use gitk) # good? back to your development branch git checkout biopp # merge in my change git merge biopp_fix # did it work? Yes. Email and continue hacking... # push to your github account If this is successful - I can see the patch on your github tree - we can go to the next step of integration. Pj. From xshuai at umail.iu.edu Sat Aug 1 16:54:13 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Sat, 1 Aug 2009 12:54:13 -0400 Subject: [BioLib-dev] Merging libsequence into main In-Reply-To: <20090801081241.GA24447@thebird.nl> References: <20090801081241.GA24447@thebird.nl> Message-ID: <3a7743460908010954j617658cbi5ff50f31b3a0ac3d@mail.gmail.com> Thank you, pjotr, I really learnt a lot about git. Following your instruction, I've already created a new 'master' branch and it looks just as the same as my 'master_conflict' branch. Currently I'm still in the process of updating your libsequence & boost submodule. Later on, I 'll concentrate on fixing modifying the libsequence files. As you mentioned, I plan to put my modified file to: ./src/clibs/libsequence/include/. and leave the /contrib untouched. I think I also have to change the file including path. Is that OK? With regards to the patch, I decided to email them to you.(libsequence-1.6.6 and boost). You mentioned that I can get the patch by git commit Do you mean that I can directly find the patch file in my tree? I also consult the git manual and learned a command to generate the patch: $ git format-patch origin On Sat, Aug 1, 2009 at 4:12 AM, wrote: > On Fri, Jul 31, 2009 at 12:01:32PM -0400, Xin Shuai wrote: > > Except for the doubt I raised in my last email(I really don't dare to > commit > > freely this time unless you told me nothing is wrong), I've already > updated > > the contrib with two submodules: libsequence-1.6.6 and boost. > > I would have created another remote branch. That way it would have > been possible for me to see the differences. Now I am blind to the > latest changes. > > > Regarding to your error, yes, I once met them before. So I modified > > a few .hpp , .cc and .tcc files to make them work for swig. That's > > way I once asked you if it is OK for me to modify the original > > files. > > > > I attached a txt file which documents all the files I have modified and > how. > > Ah, that is cool. I see you have fixed a number of problems by > modifying BOOST and libsequence sources. The only problem is that I > don't have them in the tree now. > > The nice thing is that we actually have both libraries as git > repositories in biolib(!). This means we can clone the trees onto our > own github accounts, and push the patches. That way we can make > visible what works and doesn't work - and share the changes. > > If you use my latest libsequence branch and run > > git submodule -i update > > you will have both repositories locally. Let's start with a change to > libsequence: > > cd contrib/libsequence-1.6.6 > git checkout -b xin # important since a git submodule is a virtual > branch > # hack hack > # test > git commit > > Now you have patches. So what next? Two options, clone the > libsequence library at http://github.com/pjotrp/libsequence/tree on > github and push the patches to your tree. > > This is nice. I can pull from that tree. > > Another option is to mail me the patches (as generated by git). > > The same thing can be done for the BOOST tree. I cloned it from > git://gitorious.org/boost/svn.git. Unfortunately it is > large and may not fit into your free github account. You'll have to > either upgrade github, or I need add you to my github account, or you > send me patches. What do you prefer? > > BTW, fixing upstream libraries - you have to make a call. Really > changes should go in we can send upstream to the maintainers. Just > commenting out problematic code is not a 'solution'. For isolated > cases there are a number of options: > > 1. Tell SWIG to ignore the code (renames, macros) > 2. Create a derived class that is used by SWIG, rather than the > parent > > If it is unavoidable to parse the master file, and SWIG cracks, maybe > we can have a copy of that one particular file in the biolib tree, > which is compiled, rather than the one in contrib. So problematic.h > is found in: > > ./src/clibs/libsequence/include/problematic.h > > rather then > > ./contrib/libsequence/include/problematic.h > > In other words, fixing the master repositories should be useful to > upstream users. Otherwise we need to hack it in biolib itself. > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 14:36:32 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 10:36:32 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090802162823.GA9347@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> Message-ID: <3a7743460908030736x639632aei3af8d6db7b404262@mail.gmail.com> On Sun, Aug 02, 2009 at 10:36:27AM -0400, Xin Shuai wrote: > Hi: I'm still in the process of debugging and testing. I found that , in > addition to Boost++ library, gsl library is also needed. > I tracked the location of gsl library and found it in > /usr/local/lib/libgsl.dylib. Hmmm. How much does it use? I have also the Scilib project, similar to Biolib, which includes the GSL sources. I really dislike linking against shared libraries for critical functionality. Prefer sources, so it is one system and bugs can be tagged against one set of versions. The only exception I am making now are Rlib and zlib. > Generally, any lib that is located in /usr/lib and /usr/local/lib should > be automatically found by CMake. But my program cannot find it. Thus I have > import error when I import libsequence library in Python. I guess the reason > is that CMake only recognize library with .so suffix (Unix) But not library > with .dylib(Mac). Since I met the similar situation at the beginning of > project. Finding is no problem, just takes a bit of hacking. I don't have OSX, that complicates it for me. But we can find solutions if required. > Therefore, I think the solution is to add some hacking to let CMake > recognize .dylib when Linking other library. How do you think of my > thoughts? Can you give me some advice? At this stage I favour including the source tree. Can you check what functions libsequence really uses from the GSL? Pj. -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 14:56:52 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 10:56:52 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803063801.GA13838@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> Message-ID: <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> I've tried to add the related .c source files in gsl library and compile them. However, the difficulty is little beyond my expectation Actually, only four functions are needed for libsequence: gsl_rng_uniform(__r) gsl_ran_flat(__r,a,b) gsl_ran_exponential(__r,mean) gsl_ran_poisson(__r,mean) And they are declared in libsequence-1.6.6/Sequence/RNG/gsl_rng_wrappers.hpp I began by adding source file name in .src/clibs/libsequence-1.6.6/src/files.txt, as well as the files themselves in the same directory. That is the way I do for libsequence. However, as I added more, I found a lot of dependent files needing to be added and complied, in order to *re**ally use the above four* functions in python. I guess more than 30 files. I've tried an afternoon and a night of yesterday and gave up finally. It seems to me a little awkward to manually added files and compile them. So what's your advice? On Mon, Aug 3, 2009 at 2:38 AM, Pjotr Prins wrote: > On Sun, Aug 02, 2009 at 03:11:33PM -0400, Xin Shuai wrote: > > Not very much, only a few functions. So I'm trying to add related source > > files into my tree and complied them together into libsequence library > > That is probably the best option, especially since libsequence is not > actively maintained. > > A list of functions would help though, maybe the functionality is > already in BOOST now, or in Rlib, so we can replace that dependency. > > Pj. > > > On Sun, Aug 2, 2009 at 12:28 PM, Pjotr Prins > wrote: > > > > > On Sun, Aug 02, 2009 at 10:36:27AM -0400, Xin Shuai wrote: > > > > Hi: I'm still in the process of debugging and testing. I found that > , > > > in > > > > addition to Boost++ library, gsl library is also needed. > > > > I tracked the location of gsl library and found it in > > > > /usr/local/lib/libgsl.dylib. > > > > > > Hmmm. How much does it use? I have also the Scilib project, similar > > > to Biolib, which includes the GSL sources. I really dislike linking > > > against shared libraries for critical functionality. Prefer sources, > > > so it is one system and bugs can be tagged against one set of > > > versions. The only exception I am making now are Rlib and zlib. > > > > > > > Generally, any lib that is located in /usr/lib and /usr/local/lib > > > should > > > > be automatically found by CMake. But my program cannot find it. Thus > I > > > have > > > > import error when I import libsequence library in Python. I guess the > > > reason > > > > is that CMake only recognize library with .so suffix (Unix) But not > > > library > > > > with .dylib(Mac). Since I met the similar situation at the beginning > of > > > > project. > > > > > > Finding is no problem, just takes a bit of hacking. I don't have OSX, > > > that complicates it for me. But we can find solutions if required. > > > > > > > Therefore, I think the solution is to add some hacking to let > CMake > > > > recognize .dylib when Linking other library. How do you think of my > > > > thoughts? Can you give me some advice? > > > > > > At this stage I favour including the source tree. Can you check what > > > functions libsequence really uses from the GSL? > > > > > > Pj. > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 3 15:45:37 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 17:45:37 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> Message-ID: <20090803154537.GA31467@thebird.nl> On Mon, Aug 03, 2009 at 10:56:52AM -0400, Xin Shuai wrote: > I've tried to add the related .c source files in gsl library and compile > them. However, the difficulty is little beyond my expectation > Actually, only four functions are needed for libsequence: > > gsl_rng_uniform(__r) > > gsl_ran_flat(__r,a,b) > > gsl_ran_exponential(__r,mean) > > gsl_ran_poisson(__r,mean) Funny. They are all random number generators, which are also in BOOST and Rlib. How about replacing these functions in libsequence with their Boost counterpart? Since we have Boost already. See, for example http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/poisson_dist.html would that be hard? I notice libsequence has a single wrapper Sequence/RNG/gsl_rng_wrappers.hpp, which includes these. The other uses are all example files. How about creating Sequence/RNG/boost_rng_wrappers.hpp which gets included when USE_BOOST is defined? That would be a nice contribution for the libsequence project. If that fails I can pull the GSL source tree into biolib. I have half a mind to do that anyway - it is not so large. All possible ;-) Pj. From pjotr.public14 at thebird.nl Mon Aug 3 16:29:22 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 18:29:22 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803154537.GA31467@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> Message-ID: <20090803162922.GA32533@thebird.nl> Hi Xin, I have applied your patches to the libsequence tree. See http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8. There is one patch changing functionality I hope you know what you are doing: changes: - if (Alignment::IsAlignment(alignment) == true) + // if (Alignment::IsAlignment(alignment) == true) You can pull in this tree into your repository by pulling from my biolib/libsequence branch, and update submodules in biolib: cd biolib git pull pjotr libsequence git submodule update That should do the trick. Check to see whether all patches have gone in. I also modified the files.txt list, so it compiles again. Pj. From xshuai at umail.iu.edu Mon Aug 3 16:34:43 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 12:34:43 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803154537.GA31467@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> Message-ID: <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> I can try the boost version of rng. But I still got a worry about the argument type problem.Those four functions defined are not used directly in libsequence. Instead, they are included in different classes as member function object.( See gsl_rng_wrappers.hpp for detail) . And the instance of these classes will be passed into other functions as argument and those functions are really used directly in libsquence.For example, such a function in libsequnce: std::pair pick2 ( uniform_generator & uni, const int & nsam) the argument &uni is just an object of the following class: class gsl_uniform01 { private: gsl_rng * __r; public: gsl_uniform01( gsl_rng * r ) : __r(r) { } inline double operator()(void) const { return gsl_rng_uniform(__r); } }; Therefore, even if I can write a boost_rng_wrapper.hpp and wrap boost random number generator, I'm afraid it won't be accepted as the current libsequence. I have to rewrite all related functions, like pick2, to make it accept boost rng rather than gsl rng. Correct me if I'm wrong. On Mon, Aug 3, 2009 at 11:45 AM, Pjotr Prins wrote: > On Mon, Aug 03, 2009 at 10:56:52AM -0400, Xin Shuai wrote: > > I've tried to add the related .c source files in gsl library and compile > > them. However, the difficulty is little beyond my expectation > > Actually, only four functions are needed for libsequence: > > > > gsl_rng_uniform(__r) > > > > gsl_ran_flat(__r,a,b) > > > > gsl_ran_exponential(__r,mean) > > > > gsl_ran_poisson(__r,mean) > > Funny. They are all random number generators, which are also in BOOST > and Rlib. How about replacing these functions in libsequence with > their Boost counterpart? Since we have Boost already. See, for example > > > http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/dist/dist_ref/dists/poisson_dist.html > > would that be hard? I notice libsequence has a single wrapper > Sequence/RNG/gsl_rng_wrappers.hpp, which includes these. The other > uses are all example files. > > How about creating Sequence/RNG/boost_rng_wrappers.hpp which gets > included when USE_BOOST is defined? > > That would be a nice contribution for the libsequence project. > > If that fails I can pull the GSL source tree into biolib. I have half > a mind to do that anyway - it is not so large. > > All possible ;-) > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 16:51:25 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 12:51:25 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <20090803162922.GA32533@thebird.nl> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <20090803162922.GA32533@thebird.nl> Message-ID: <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> Let me explain the patch for you. I have mentioned beforethat I have problem of instantiate the template function with T = Sequence::Fasta:(But it is supposed to be ) templatebool IsAlignment (const std::vector< T > &data) However, the PolySites template class can be instantiated by Sequence::Fasta and I did do it. The code section I comment out in the patch is just from the PolySites.tcc. So if I don't comment it out, error message will appeared and prevent me from wrapping the whole class. It won't affect unless you input a series of sequence with different length. However, it is still a but and I will try to fix it soon. On Mon, Aug 3, 2009 at 12:29 PM, Pjotr Prins wrote: > Hi Xin, > > I have applied your patches to the libsequence tree. See > > http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8 > . > > There is one patch changing functionality I hope you know what you are > doing: > > changes: - if (Alignment::IsAlignment(alignment) == true) > + // if (Alignment::IsAlignment(alignment) == true) > > You can pull in this tree into your repository by pulling from my > biolib/libsequence branch, and update submodules in biolib: > > cd biolib > git pull pjotr libsequence > git submodule update > > That should do the trick. Check to see whether all patches have gone > in. I also modified the files.txt list, so it compiles again. > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 3 17:00:52 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 3 Aug 2009 19:00:52 +0200 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <3a7743460908030934x44ebed04h7fcc1ae4cb4b070c@mail.gmail.com> Message-ID: <20090803170052.GA738@thebird.nl> On Mon, Aug 03, 2009 at 12:34:43PM -0400, Xin Shuai wrote: > I can try the boost version of rng. But I still got a worry about the > argument type problem.Those four functions defined are not used directly in > libsequence. Instead, they are included in different classes as member > function object.( See gsl_rng_wrappers.hpp for detail) . And the instance of > these classes will be passed into other functions as argument and those > functions are really used directly in libsquence.For example, such a > function in libsequnce: OK, I see. I think we just include the GSL sources into biolib. Easiest, and logical as other biolib modules will get access too. In theory the GSL is stable enough to link against it - however, it is small enough just to carry it in. Will do tomorrow. Ignore the problem until I have done that. Pj. From xshuai at umail.iu.edu Mon Aug 3 20:37:22 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 16:37:22 -0400 Subject: [BioLib-dev] Need to link another library gsl In-Reply-To: <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> References: <3a7743460908020736s323d836br3a26b4a4eade1d86@mail.gmail.com> <20090802162823.GA9347@thebird.nl> <3a7743460908021211v2285ab06r121c157b766e40be@mail.gmail.com> <20090803063801.GA13838@thebird.nl> <3a7743460908030756k61154466j366e51b73deebc75@mail.gmail.com> <20090803154537.GA31467@thebird.nl> <20090803162922.GA32533@thebird.nl> <3a7743460908030951o2471adcbo6d39654ceee4ed45@mail.gmail.com> Message-ID: <3a7743460908031337k1c1c4910j9783e3ad96fd4698@mail.gmail.com> The problem of instantiation of all template functions in Sequence::Alignment as well as template class Sequence::ClustalW. Actually the solution is quite simple. I forgot to compile one important source file, FastaExplicit.cc, into the libsequence dynamic library, which is provided by libsequence library. This file declares explicit instantiations for type Sequence::Fasta for those function templates as well as class Sequence::ClustalW. So, that related patch can be deleted. However, there's still a problem I don' understand. Sequence::PolySites is a normal class in libsequence but have a template constructor function. But I don't have to first include any "explicit instantiation" declaration, but can directly instantiate it in interface file using Sequence::Fasta type, as well as use it in Python. On Mon, Aug 3, 2009 at 12:51 PM, Xin Shuai wrote: > Let me explain the patch for you. I have mentioned > beforethat I have problem of instantiate the template function with T = > Sequence::Fasta:(But it is supposed to be ) > template bool IsAlignment (const > std::vector< T > &data) > However, the PolySites template class can be instantiated by > Sequence::Fasta and I did do it. The code section I comment out in the patch > is just from the PolySites.tcc. So if I don't comment it out, error message > will appeared and prevent me from wrapping the whole class. It won't affect > unless you input a series of sequence with different length. > > However, it is still a but and I will try to fix it soon. > > On Mon, Aug 3, 2009 at 12:29 PM, Pjotr Prins wrote: > >> Hi Xin, >> >> I have applied your patches to the libsequence tree. See >> >> http://github.com/pjotrp/libsequence/commit/d4676e555444f40aadabc9188b6946c868ededf8 >> . >> >> There is one patch changing functionality I hope you know what you are >> doing: >> >> changes: - if (Alignment::IsAlignment(alignment) == true) >> + // if (Alignment::IsAlignment(alignment) == true) >> >> You can pull in this tree into your repository by pulling from my >> biolib/libsequence branch, and update submodules in biolib: >> >> cd biolib >> git pull pjotr libsequence >> git submodule update >> >> That should do the trick. Check to see whether all patches have gone >> in. I also modified the files.txt list, so it compiles again. >> >> Pj. >> > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Mon Aug 3 22:54:16 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 3 Aug 2009 18:54:16 -0400 Subject: [BioLib-dev] About istream and ostream in script language. In-Reply-To: References: <3a7743460908011445h66976f91w78f52512c13ea500@mail.gmail.com> Message-ID: <3a7743460908031554n283729dfje74cce06ee110ed5@mail.gmail.com> Thank you a lot for your information, Mark, though I cannot totally understand your perl code.It seems that there's NO NEED for the paired read() and print() in libsequence dealing with iostream, to be mapped to Python/Perl script. But I'm not sure about whether BioPython has the similar classes to deal with FASTA streaming. On Sun, Aug 2, 2009 at 1:54 PM, Mark A. Jensen wrote: > Hi David-- > It looks like these classes and methods provide streaming FASTA I/O. In > BioPerl, there is a class called > Bio::SeqIO that will do true FASTA streaming. In a Perl script, it would be > used as follows > > for "read": > > use Bio::SeqIO; > my $io = Bio::SeqIO->new(-format=>'fasta', -file => 'filename.fas'); > while ( my $seq = $io->next_seq ) { > # do stuff with $seq, which is-a Bio::Seq object > } > > for "print": > > use Bio::SeqIO; > use Bio::Seq; > my $io = Bio::SeqIO->new(-format=>'fasta', -file=>'>filename.fas'); > my $seq = Bio::Seq->new( -seq=>'ATACTA', -id=>'seq0' ); > $io->write_seq($seq); > > These require a considerable amount of BioPerl machinery, however. What may > be better is to provide simple "native" Perl functions that accept or return > a two-member hash > > %seq = ( 'id' => 'seq0, 'seq'=>'ATCTGA'); > > or arrays of hashrefs: > > @seqs = ( {'id'=>'seq0', 'seq'=>'ATCTGA'}, {'id'=>'seq1', 'seq'=>'TTCGAT'}, > ... }; > > and use these to read and write very simple fasta. Using the perl "open()" > and "print()" functions will automatically generate streams (via C fopen, > etc, I believe), so no special streaming code would need to be written. > Maybe Chris has other thoughts as well- > cheers, > Mark > > ----- Original Message ----- > *From:* Xin Shuai > *To:* Pjotr Prins ; chris Fields; Mark > A. Jensen > *Sent:* Saturday, August 01, 2009 5:45 PM > *Subject:* About istream and ostream in script language. > > In libsequence, many classes or struct have the similar following paired > member functions: > > std::istream & read(std::istream &s) > > > std::ostream & print(std::ostream &s) const > > I think the above two functions are used to for user > to input/output related data. And I also know there's a > library in swig for Python. But there's no such library in Perl > > I really have no idea of how these two functions can be used in script > language and how to deal with istream/ostream object in script language. > > Thus I'm wondering: Do I need to wrap them into Python/Perl? Or is it > better to manually write similar replacing functions for Python/Perl? > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 13:13:17 2009 From: pjotr.public14 at thebird.nl (pjotr.public14 at thebird.nl) Date: Tue, 4 Aug 2009 15:13:17 +0200 Subject: [BioLib-dev] GSL Message-ID: <20090804131317.GA15379@thebird.nl> Hi Xin, I have updated your contrib/libsequence tree. Also the GSL is now included in biolib (libsequence branch). You should find it in ./contrib/GSL. I also included a CMakeLists.txt file to compile the GSL into a shared library. Two tricks are needed, first GSL compiles a config.h file with global settings. Second it has a strange requirement for include file locations. Both are solved in that CMake file in less src/clibs/gsl/src/CMakeLists.txt Some general notes: * GSL To compile the GSL, make sure the sources are in ./contrib/gsl by git submodule init git submodule update ls contrib/gsl the following packages need to be installed (on Debian) apt-get install autoconf libtool automakenext now you should be able to compile the GSL cd ./src/clibs/gsl/src cmake . make Pj. From xshuai at umail.iu.edu Tue Aug 4 17:29:10 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Tue, 4 Aug 2009 13:29:10 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804131317.GA15379@thebird.nl> References: <20090804131317.GA15379@thebird.nl> Message-ID: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Everything looks fine until the last steps: when I ran: make The following error shows: /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: config.h: No such file or directory /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: gsl_version.h: No such file or directory /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: ?GSL_VERSION? undeclared here (not in a function) It seems that config.h and gsl_version.h cannot be found in my Mac. However, you mentioned that you've already solved them in CMakeLists.txt On Tue, Aug 4, 2009 at 9:13 AM, wrote: > Hi Xin, > > I have updated your contrib/libsequence tree. Also the GSL is now > included in biolib (libsequence branch). You should find it in > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > GSL into a shared library. Two tricks are needed, first GSL compiles > a config.h file with global settings. Second it has a strange > requirement for include file locations. > > Both are solved in that CMake file in > > less src/clibs/gsl/src/CMakeLists.txt > > Some general notes: > > * GSL > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > git submodule init > git submodule update > ls contrib/gsl > > the following packages need to be installed (on Debian) > > apt-get install autoconf libtool automakenext > > now you should be able to compile the GSL > > cd ./src/clibs/gsl/src > cmake . > make > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 17:38:12 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Tue, 4 Aug 2009 19:38:12 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Message-ID: <20090804173812.GA17997@thebird.nl> rm CMakeCache.txt cmake . make should create config.h. The symlink points from ./gsl/config.h. There should also be ./gsl/gsl_version.h - can you see that? Pj. On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > Everything looks fine until the last steps: > when I ran: > make > > The following error shows: > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > config.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > gsl_version.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > ?GSL_VERSION? undeclared here (not in a function) > > It seems that config.h and gsl_version.h cannot be found in my Mac. However, > you mentioned that you've already solved them in CMakeLists.txt > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > Hi Xin, > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > included in biolib (libsequence branch). You should find it in > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > GSL into a shared library. Two tricks are needed, first GSL compiles > > a config.h file with global settings. Second it has a strange > > requirement for include file locations. > > > > Both are solved in that CMake file in > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > Some general notes: > > > > * GSL > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > git submodule init > > git submodule update > > ls contrib/gsl > > > > the following packages need to be installed (on Debian) > > > > apt-get install autoconf libtool automakenext > > > > now you should be able to compile the GSL > > > > cd ./src/clibs/gsl/src > > cmake . > > make > > > > Pj. > > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From pjotr.public14 at thebird.nl Tue Aug 4 18:39:15 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Tue, 4 Aug 2009 20:39:15 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> Message-ID: <20090804183915.GA18864@thebird.nl> I think you miss the venerable automake libtool autoconf tools. I just did a fresh install in a new image - if they are missing cmake will give errors. Once installed a fresh config.h will be generated by cmake. With all the tools it should compile. It is nasty, because for the first time we introduce ./configure and friends into biolib. It should be possible to avoid that. The complication is the generation of some include files. You'll need to link against the gsl-5.0.0.so/dylib library. That requires a new reference in the FindSWIG.cmake file. You may ignore that for now and, after a succesful generation of config.h, just compile the ./contrib/gsl/xxx/xxx.c files into your shared library. See if it works. Ideally we use the gsl shared lib. I can fix that later. Note also that the current setup won't work on Windows. As I have introduced symlinks for the include files. Pj. On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > Everything looks fine until the last steps: > when I ran: > make > > The following error shows: > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > config.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > gsl_version.h: No such file or directory > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > ?GSL_VERSION? undeclared here (not in a function) > > It seems that config.h and gsl_version.h cannot be found in my Mac. However, > you mentioned that you've already solved them in CMakeLists.txt > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > Hi Xin, > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > included in biolib (libsequence branch). You should find it in > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > GSL into a shared library. Two tricks are needed, first GSL compiles > > a config.h file with global settings. Second it has a strange > > requirement for include file locations. > > > > Both are solved in that CMake file in > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > Some general notes: > > > > * GSL > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > git submodule init > > git submodule update > > ls contrib/gsl > > > > the following packages need to be installed (on Debian) > > > > apt-get install autoconf libtool automakenext > > > > now you should be able to compile the GSL > > > > cd ./src/clibs/gsl/src > > cmake . > > make > > > > Pj. > > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From xshuai at umail.iu.edu Tue Aug 4 20:42:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Tue, 4 Aug 2009 16:42:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804183915.GA18864@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> Message-ID: <3a7743460908041342s6704276nc1b88739cd8482da@mail.gmail.com> It finally works. But my solution is a little wired. According to your inspiration, I found that there's no configure shell in ./contrib/gsl. And I consulted some document and tried to run autogen.sh in the same directory to generate configure. But when I ran ./autogen.sh The error appeared that libtoolize tool is missing. Thus I thought maybe I haven't installed libtool, though I could found libtool in /usr/bin. I downloaded libtool package and tried to install it. But I failed because of some unknown error. Later on, I found that there's right a libtoolize shell in the libtool package. So I just copy that libtoolize to my /usr/bin. After that, I re-ran autogen.sh in ./contrib/gsl. And then I went into ./src/clibs/gsl/src again and ran cmake . make This time it did work. However, some 'undefined symbol' error came out at last. After checking I found that there's one file gamma_inc.c is forgot to be added to gsl_files.txt. Finally I added that file and the dynamic library is generated in /build On Tue, Aug 4, 2009 at 2:39 PM, Pjotr Prins wrote: > I think you miss the venerable automake libtool autoconf tools. I just did > a > fresh install in a new image - if they are missing cmake will give > errors. Once installed a fresh config.h will be generated by cmake. > With all the tools it should compile. > > It is nasty, because for the first time we introduce ./configure and > friends into biolib. It should be possible to avoid that. The > complication is the generation of some include files. > > You'll need to link against the gsl-5.0.0.so/dylib library. That requires > a > new reference in the FindSWIG.cmake file. You may ignore that for now > and, after a succesful generation of config.h, just compile the > ./contrib/gsl/xxx/xxx.c files into your shared library. See if it > works. > > Ideally we use the gsl shared lib. I can fix that later. > > Note also that the current setup won't work on Windows. As I have > introduced symlinks for the include files. > > Pj. > > On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: > > Everything looks fine until the last steps: > > when I ran: > > make > > > > The following error shows: > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: error: > > config.h: No such file or directory > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: error: > > gsl_version.h: No such file or directory > > /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: > > ?GSL_VERSION? undeclared here (not in a function) > > > > It seems that config.h and gsl_version.h cannot be found in my Mac. > However, > > you mentioned that you've already solved them in CMakeLists.txt > > > > On Tue, Aug 4, 2009 at 9:13 AM, wrote: > > > > > Hi Xin, > > > > > > I have updated your contrib/libsequence tree. Also the GSL is now > > > included in biolib (libsequence branch). You should find it in > > > ./contrib/GSL. I also included a CMakeLists.txt file to compile the > > > GSL into a shared library. Two tricks are needed, first GSL compiles > > > a config.h file with global settings. Second it has a strange > > > requirement for include file locations. > > > > > > Both are solved in that CMake file in > > > > > > less src/clibs/gsl/src/CMakeLists.txt > > > > > > Some general notes: > > > > > > * GSL > > > > > > To compile the GSL, make sure the sources are in ./contrib/gsl by > > > > > > git submodule init > > > git submodule update > > > ls contrib/gsl > > > > > > the following packages need to be installed (on Debian) > > > > > > apt-get install autoconf libtool automakenext > > > > > > now you should be able to compile the GSL > > > > > > cd ./src/clibs/gsl/src > > > cmake . > > > make > > > > > > Pj. > > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From hlapp at gmx.net Tue Aug 4 23:32:31 2009 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 4 Aug 2009 19:32:31 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090804183915.GA18864@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> Message-ID: <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> Hi Pjotr - many systems come pre-installed with GSL these days. Is it really wise not to just assume it as a system dependency? -hilmar On Aug 4, 2009, at 2:39 PM, Pjotr Prins wrote: > I think you miss the venerable automake libtool autoconf tools. I > just did a > fresh install in a new image - if they are missing cmake will give > errors. Once installed a fresh config.h will be generated by cmake. > With all the tools it should compile. > > It is nasty, because for the first time we introduce ./configure and > friends into biolib. It should be possible to avoid that. The > complication is the generation of some include files. > > You'll need to link against the gsl-5.0.0.so/dylib library. That > requires a > new reference in the FindSWIG.cmake file. You may ignore that for now > and, after a succesful generation of config.h, just compile the > ./contrib/gsl/xxx/xxx.c files into your shared library. See if it > works. > > Ideally we use the gsl shared lib. I can fix that later. > > Note also that the current setup won't work on Windows. As I have > introduced symlinks for the include files. > > Pj. > > On Tue, Aug 04, 2009 at 01:29:10PM -0400, Xin Shuai wrote: >> Everything looks fine until the last steps: >> when I ran: >> make >> >> The following error shows: >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:20:20: >> error: >> config.h: No such file or directory >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:21:25: >> error: >> gsl_version.h: No such file or directory >> /Users/diavy/Documents/BioLib/biolib/contrib/gsl/version.c:29: error: >> ?GSL_VERSION? undeclared here (not in a function) >> >> It seems that config.h and gsl_version.h cannot be found in my Mac. >> However, >> you mentioned that you've already solved them in CMakeLists.txt >> >> On Tue, Aug 4, 2009 at 9:13 AM, wrote: >> >>> Hi Xin, >>> >>> I have updated your contrib/libsequence tree. Also the GSL is now >>> included in biolib (libsequence branch). You should find it in >>> ./contrib/GSL. I also included a CMakeLists.txt file to compile the >>> GSL into a shared library. Two tricks are needed, first GSL compiles >>> a config.h file with global settings. Second it has a strange >>> requirement for include file locations. >>> >>> Both are solved in that CMake file in >>> >>> less src/clibs/gsl/src/CMakeLists.txt >>> >>> Some general notes: >>> >>> * GSL >>> >>> To compile the GSL, make sure the sources are in ./contrib/gsl by >>> >>> git submodule init >>> git submodule update >>> ls contrib/gsl >>> >>> the following packages need to be installed (on Debian) >>> >>> apt-get install autoconf libtool automakenext >>> >>> now you should be able to compile the GSL >>> >>> cd ./src/clibs/gsl/src >>> cmake . >>> make >>> >>> Pj. >>> >>> >> >> >> -- >> Xin Shuai (David) >> PhD of Complex System in School of Informatics >> Indiana University Bloomington >> 812-606-8019 > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From pjotr.public14 at thebird.nl Wed Aug 5 06:07:47 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 08:07:47 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> Message-ID: <20090805060747.GA21684@thebird.nl> On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: > Hi Pjotr - many systems come pre-installed with GSL these days. Is it > really wise not to just assume it as a system dependency? > > -hilmar That is a call we have to make. There are two problems with these type of dependencies: (1) libraries change (2) on different systems they are in different places The main reason I like to have the source base inside biolib is that when we do a release we have ONE source base. So bugs can be found, without the added complexity of (1). Especially over time this is a great concern. On the Perl mailing list you encountered that this year with the staden_io_lib module - the interface changed. In addition many installations are quite old, so you get an old GSL library, or BOOST, or whatever. With (2) is a particular concern since bio* developers are all over the place: different distros of Linux, OSX, Cygwin, Windows. Having the source tree in biolib kills those birds with one stone. It is possible to use external dynamically linked libraries. We do that for Rlib.so and zlib.so now (note that Biolib does not compile, at this point, on Windows for that very reason). The call is on us. I am not convinced the GSL is stable, Xin had to add a symlink because one file was added in the last months, nor that it is easily found on most systems. And the source base is not that big (BOOST is ten times as big). We are mapping against these libraries - also the GSL. So in it goes, as far as I am concerned. If only for the fact the I only want the latest and greatest :-) With Biolib you will get a stable and modern set of tools to compile against. In addition we use the latest and fastest versions of dependent software. How do you think the bio* developers will like that? Pj. From hlapp at gmx.net Wed Aug 5 14:29:16 2009 From: hlapp at gmx.net (Hilmar Lapp) Date: Wed, 5 Aug 2009 10:29:16 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090805060747.GA21684@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> Message-ID: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> On Aug 5, 2009, at 2:07 AM, Pjotr Prins wrote: > On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: >> Hi Pjotr - many systems come pre-installed with GSL these days. Is it >> really wise not to just assume it as a system dependency? >> >> -hilmar > > That is a call we have to make. There are two problems with these > type of dependencies: > > (1) libraries change > > (2) on different systems they are in different places > > The main reason I like to have the source base inside biolib is that > when we do a release we have ONE source base. So bugs can be found, > without the added complexity of (1). You're really just shifting the complexity of (1) from the system administrator of a user's (or developer's) machine to yourself as the Biolib maintainer (or whoever comes after you). As not infrequently the user doubles as the sysadmin on her machine, this is of course nice for the Biolib user. However, it does create an additional burden, and especially responsibility, for the Biolib maintainers. I'm not convinced that fulfilling that responsibility is one of the best ways Biolib developers and maintainers can spend their time. > Especially over time this is a great concern. On the Perl mailing > list you encountered that this year with the staden_io_lib module - > the interface changed. I know. But it's also a very common situation that we all have to learn how to deal with anyway. Bio::Graphics needs a certain version of GD. Most systems come pre-installed with GD but in a version that's too old, so most people end up having to upgrade their GD, or install a newer version in parallel and then make sure their environment is correct when compiling the GD perl bindings etc. The same is typically true for DBI and the various DBD drivers. There are numerous other examples. > [...] > With (2) is a particular concern since bio* developers are all over > the place: different distros of Linux, OSX, Cygwin, Windows. Having > the source tree in biolib kills those birds with one stone. If there are no problems. As soon as there are (and there are bound to be if the library is under active development) there may be more birds to kill than you have stones (or time) for. > [...] > So in it goes, as far as I am concerned. If only for the fact the I > only want the latest and greatest :-) The other benefit that treating it as an external dependency has is tempering that desire for the bleeding edge. The bleeding edge cuts well, but it's full of blood too. That all being said, having the GSL SWIG-mapped as a first class library in Biolib so that all Bio* projects can take advantage of it would be very cool in its own right. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at illinois.edu Wed Aug 5 15:01:34 2009 From: cjfields at illinois.edu (Chris Fields) Date: Wed, 5 Aug 2009 10:01:34 -0500 Subject: [BioLib-dev] GSL In-Reply-To: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> Message-ID: <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> On Aug 5, 2009, at 9:29 AM, Hilmar Lapp wrote: > > On Aug 5, 2009, at 2:07 AM, Pjotr Prins wrote: > >> On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote: >>> Hi Pjotr - many systems come pre-installed with GSL these days. Is >>> it >>> really wise not to just assume it as a system dependency? >>> >>> -hilmar >> >> That is a call we have to make. There are two problems with these >> type of dependencies: >> >> (1) libraries change >> >> (2) on different systems they are in different places >> >> The main reason I like to have the source base inside biolib is that >> when we do a release we have ONE source base. So bugs can be found, >> without the added complexity of (1). > > You're really just shifting the complexity of (1) from the system > administrator of a user's (or developer's) machine to yourself as > the Biolib maintainer (or whoever comes after you). As not > infrequently the user doubles as the sysadmin on her machine, this > is of course nice for the Biolib user. > > However, it does create an additional burden, and especially > responsibility, for the Biolib maintainers. I'm not convinced that > fulfilling that responsibility is one of the best ways Biolib > developers and maintainers can spend their time. I do have to second this. Also, many libraries come with some kind of config check available (what version the lib is, where the headers/ libs are, etc). This wasn't available when bioperl first added io_lib support. Also doesn't help when said code goes largely unmaintained (bioperl- ext is essentially deprecated b/c of bitrot). >> Especially over time this is a great concern. On the Perl mailing >> list you encountered that this year with the staden_io_lib module - >> the interface changed. > > I know. But it's also a very common situation that we all have to > learn how to deal with anyway. Bio::Graphics needs a certain version > of GD. Most systems come pre-installed with GD but in a version > that's too old, so most people end up having to upgrade their GD, or > install a newer version in parallel and then make sure their > environment is correct when compiling the GD perl bindings etc. The > same is typically true for DBI and the various DBD drivers. There > are numerous other examples. The same happens with perl itself. Due to worries about backwards- compat issues they have put off 5.10.1 for over a year now (it was due last summer). After a lot of back-and-forth (and a few resignations) the process is moving forward again, and 5.10.1 is imminent. The overall opinion is if a user wants the latest module updates, and if said module requires 5.10, they will need to upgrade to 5.10. >> [...] >> With (2) is a particular concern since bio* developers are all over >> the place: different distros of Linux, OSX, Cygwin, Windows. Having >> the source tree in biolib kills those birds with one stone. > > If there are no problems. As soon as there are (and there are bound > to be if the library is under active development) there may be more > birds to kill than you have stones (or time) for. > >> [...] >> So in it goes, as far as I am concerned. If only for the fact the I >> only want the latest and greatest :-) > > The other benefit that treating it as an external dependency has is > tempering that desire for the bleeding edge. The bleeding edge cuts > well, but it's full of blood too. If anything the reliance of users on bioperl's bleeding edge code (bioperl-live) has slowed development down to a crawl, and was the impetus for me to push a 1.6 release out ASAP (and the reason we have decided on restructuring bioperl for easier releases). Users who want bleeding edge code should expect bugs, possible API changes, etc. They get kudos for pointing out the bugs, sure, but I start pulling my hair out (what little I have on my head still) when I hear "Bio::Module::Foo in bioperl-live breaks or throws an error in my production code." It doesn't happen often, but enough to be frustrating. > That all being said, having the GSL SWIG-mapped as a first class > library in Biolib so that all Bio* projects can take advantage of it > would be very cool in its own right. > > -hilmar Agreed. chris From pjotr.public14 at thebird.nl Wed Aug 5 16:26:16 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:26:16 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> Message-ID: <20090805162616.GA2301@thebird.nl> On Wed, Aug 05, 2009 at 10:29:16AM -0400, Hilmar Lapp wrote: > However, it does create an additional burden, and especially > responsibility, for the Biolib maintainers. I'm not convinced that > fulfilling that responsibility is one of the best ways Biolib developers > and maintainers can spend their time. Not really. When the build system works, it is OK. Most users get a set of binary libraries. > The other benefit that treating it as an external dependency has is > tempering that desire for the bleeding edge. The bleeding edge cuts > well, but it's full of blood too. Stable installs tend to be older than 1 year. Which is a lot. > That all being said, having the GSL SWIG-mapped as a first class library > in Biolib so that all Bio* projects can take advantage of it would be > very cool in its own right. The GSL has been mapped for Perl and Ruby in ASciLib. I'll import that into biolib soon. There is another aspect. Because we have the sources together it is easier to fix stuff and send upstream. Rather then working around problems. So I think it worth our while. Pj. From pjotr.public14 at thebird.nl Wed Aug 5 16:33:08 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:33:08 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> Message-ID: <20090805163308.GB2301@thebird.nl> On Wed, Aug 05, 2009 at 10:01:34AM -0500, Chris Fields wrote: > The same happens with perl itself. Due to worries about backwards- > compat issues they have put off 5.10.1 for over a year now (it was due > last summer). That is really my point. Because biolib controls all dependencies, and names its own libraries, there are no conflicts with other versions. You can decide to safely run different versions of biolib. When all regression and unit tests succeed we are in business. The GSL is actually the only problematic one, as I have imported the autoconf toolset for it, which is kinda flaky in this setup. But I think we will get rid of that soon enough. For me, it is all about stability and predictability. I have a long history in software deployment. It is one reason I designed the build system like it is now. But I agree that, when libraries are stable enough, it makes sense to move that responsibility to the packagers. There is not a hair on my (sparsely covered) head which would include the sources of zlib. For one. Pj. From pjotr.public14 at thebird.nl Wed Aug 5 16:44:40 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 18:44:40 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090805163308.GB2301@thebird.nl> References: <20090804131317.GA15379@thebird.nl> <3a7743460908041029t4efb809fuf4604ff90d70edb5@mail.gmail.com> <20090804183915.GA18864@thebird.nl> <97812EFC-7E9C-4B32-9F66-BB3CC0346AEE@gmx.net> <20090805060747.GA21684@thebird.nl> <119B2B93-6445-4E99-AF73-7FB6B335DA0A@gmx.net> <619B8E1C-53C2-4CC6-96C6-3294A512CAF9@illinois.edu> <20090805163308.GB2301@thebird.nl> Message-ID: <20090805164440.GA4584@thebird.nl> On Wed, Aug 05, 2009 at 06:33:08PM +0200, Pjotr Prins wrote: > There is not a hair on my (sparsely covered) head which would include > the sources of zlib. For one. Hmmm. Does it mean anything when hair starts growing out of ones ears? Pj. From pjotr.public14 at thebird.nl Wed Aug 5 17:01:54 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 5 Aug 2009 19:01:54 +0200 Subject: [BioLib-dev] USE_GSL Message-ID: <20090805170154.GA6391@thebird.nl> Hi Xin, Now we have a working libsequence compile we need to link that library. I am going to hand this to you - it is a nice exercise. Basically what you need to do is link libsequence-5.0.0.dylib (or .so in Linux) against the SWIG library you generate, e.g. python/../libsequence.so. That way you import the necessary functions from GSL. I have done something similar for the biolib-core shared library. When you check biolib/tools/cmake-support/modules you can see in FindMapLibraries.cmake that when you define 'USE_CORE' it will locate the shared library and set ${CORE_LIBRARY}. In fact, you have adapted that already for OSX before(!) Here create a section USE_GSL which defines GSL_LIBRARY. This in turn is linked in FindMapSWIG.cmake - in the line SWIG_LINK_LIBRARIES. Where the library gets linked against the SWIG generated libraries. Add ${GSL_LIBRARY} there. When someone defines USE_CORE in their CMakeLists.txt file (e.g. in the Python mapping) the biolib core library gets linked in. So, what you need to do is create a similar facility when someone defines USE_GSL. Which you can do for the libsequence mapping. First fork my cmake-support tree on github to your account. Next checkout the master branch in your biolib tree, etc. Exactly what you did with the libsequence git submodule a few days ago. Pj. From pjotr.public14 at thebird.nl Mon Aug 10 09:01:40 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 11:01:40 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> Message-ID: <20090810090140.GA11161@thebird.nl> Hi Xin, On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > I have already modified related .cmake files and tested it. It looked fine.If > only the problem of my last email is solved, I think I can update the > cmake-support submodule. Good job :-). I can build libsequence and compile Python bindings now. Cool stuff. Now the final step before merging into release_candidate. After updating from my tree: git pull pjotr libsequence git submodule update add a working 'integration' test to the Python module. When you do: cd src/mappings/swig/python/libsequence cmake . make make test you'll see 1/ 1 Testing TestPythonlibsequence ***Failed the output is in Testing/Temporary/LastTest.log. Currently ../test/test_libsequence.py consists of your doctests. They are bound to be elaborate. A biolib integration test merely makes sure the build system did not fail - so it usually has a few simple tests. Rename your current doctest to ../test/doctest_libsequence.py and create a new short test (see test_example.py) that confirms the libraries are linked together and the mapping just works. Same for the Perl module. Once that test passes I'll merge into release_candidate so Mark (and perhaps others) can start testing. Pj. P.S. I had to revert some changes in cmake-support. Not sure why you changed those, but I think this is correct. From xshuai at umail.iu.edu Mon Aug 10 15:20:38 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 11:20:38 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810090140.GA11161@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> Message-ID: <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> Oh, when I pull from your libsequence branch, the file mode change from 644->755 happened again! And it seems far more files than ever changed: mode change 100644 => 100755 .gitignore mode change 100644 => 100755 CMakeLists.txt mode change 100644 => 100755 INSTALL mode change 100644 => 100755 LICENSE mode change 100644 => 100755 PROJECTNAME mode change 100644 => 100755 README mode change 100644 => 100755 Rakefile mode change 100644 => 100755 TODO mode change 100644 => 100755 VERSION mode change 100644 => 100755 contrib/README.txt mode change 100644 => 100755 doc/APIDOCUMENTATION.txt mode change 100644 => 100755 doc/BUILD.txt mode change 100644 => 100755 doc/DEPENDENCIES.txt mode change 100644 => 100755 doc/DEVELOPMENT.txt mode change 100644 => 100755 doc/EXAMPLE.txt mode change 100644 => 100755 doc/GSL.txt mode change 100644 => 100755 doc/LAYOUT.txt mode change 100644 => 100755 doc/NIX.txt mode change 100644 => 100755 doc/OSX.txt mode change 100644 => 100755 doc/PACKAGING.txt mode change 100644 => 100755 doc/PERL.txt mode change 100644 => 100755 doc/PYTHON.txt mode change 100644 => 100755 doc/RELEASE_NOTES.txt mode change 100644 => 100755 doc/REPORTING_BUGS.txt mode change 100644 => 100755 doc/ROADMAP.txt mode change 100644 => 100755 doc/RUBY.txt mode change 100644 => 100755 doc/TESTING.txt mode change 100644 => 100755 doc/TROUBLESHOOTING.txt mode change 100644 => 100755 doc/WINDOWS.txt mode change 100644 => 100755 doc/doxygen/Doxyfile mode change 100644 => 100755 doc/doxygen/mainpage.txt mode change 100644 => 100755 doc/examples/c/CMakeLists.txt ... ... ... To my surprise, the same problem occurred again and again. If I try to modify them one by one like cmake-support, too much should be done this time. On Mon, Aug 10, 2009 at 5:01 AM, Pjotr Prins wrote: > Hi Xin, > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > I have already modified related .cmake files and tested it. It looked > fine.If > > only the problem of my last email is solved, I think I can update the > > cmake-support submodule. > > Good job :-). I can build libsequence and compile Python bindings > now. Cool stuff. Now the final step before merging into > release_candidate. After updating from my tree: > > git pull pjotr libsequence > git submodule update > > add a working 'integration' test to the Python module. When you do: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > the output is in Testing/Temporary/LastTest.log. > > Currently ../test/test_libsequence.py consists of your doctests. They > are bound to be elaborate. A biolib integration test merely makes sure > the build system did not fail - so it usually has a few simple tests. > > Rename your current doctest to ../test/doctest_libsequence.py > > and create a new short test (see test_example.py) that confirms the > libraries are linked together and the mapping just works. Same for > the Perl module. > > Once that test passes I'll merge into release_candidate so Mark (and > perhaps others) can start testing. > > Pj. > > P.S. I had to revert some changes in cmake-support. Not sure why you > changed those, but I think this is correct. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 15:49:04 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 17:49:04 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <3a7743460908100820r21bc0bcev4f02a98bbaf144e9@mail.gmail.com> Message-ID: <20090810154904.GA18103@thebird.nl> Heh. It is a fine mess :-). I think the problem is we have the patch in one of the branches, and it sneaks back in every time. When you check the log you'll see patch commit 50612d79cf02e767e3b39f6f8c8a13120525c630 Author: diavy Date: Sun Jul 12 01:13:00 2009 -0400 revision form pjotr containing the file mods. Can you provide me a branch without this patch? I'll make sure to work from there. Pj. On Mon, Aug 10, 2009 at 11:20:38AM -0400, Xin Shuai wrote: > Oh, when I pull from your libsequence branch, the file mode change from > 644->755 happened again! And it seems far more files than ever changed: > mode change 100644 => 100755 .gitignore > mode change 100644 => 100755 CMakeLists.txt > mode change 100644 => 100755 INSTALL From pjotr.public14 at thebird.nl Mon Aug 10 16:02:07 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 18:02:07 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090810090140.GA11161@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> Message-ID: <20090810160207.GA18659@thebird.nl> I think your master branch is clean. I'll work from there. Pj. On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > Hi Xin, > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > I have already modified related .cmake files and tested it. It looked fine.If > > only the problem of my last email is solved, I think I can update the > > cmake-support submodule. > > Good job :-). I can build libsequence and compile Python bindings > now. Cool stuff. Now the final step before merging into > release_candidate. After updating from my tree: > > git pull pjotr libsequence > git submodule update > > add a working 'integration' test to the Python module. When you do: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > the output is in Testing/Temporary/LastTest.log. > > Currently ../test/test_libsequence.py consists of your doctests. They > are bound to be elaborate. A biolib integration test merely makes sure > the build system did not fail - so it usually has a few simple tests. > > Rename your current doctest to ../test/doctest_libsequence.py > > and create a new short test (see test_example.py) that confirms the > libraries are linked together and the mapping just works. Same for > the Perl module. > > Once that test passes I'll merge into release_candidate so Mark (and > perhaps others) can start testing. > > Pj. > > P.S. I had to revert some changes in cmake-support. Not sure why you > changed those, but I think this is correct. > > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev From pjotr.public14 at thebird.nl Mon Aug 10 17:06:05 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 19:06:05 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <20090810160207.GA18659@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> Message-ID: <20090810170605.GA18767@thebird.nl> Hi Xin, This was a bit painful, but arguably my mistake. You can pull from my branch now without problems. You may have to revert your own branch to your github master first: to throw out the reintroduced patch. Note you have later put it new files with the wrong permissions. See the patch: c92151cdc3db8b353534532baee4c70dc5a2583e it includes a number of 755 permissions. When you create a new file on your machine: touch test.me ls -l test.me what are its permissions? It should be 644 or -rw-r--r--. If they are 755 (rwxr-xr-x) you may need to change the umask on your machine: umask 022 See Internet resources on how to manage that. Pj. On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > I think your master branch is clean. I'll work from there. > > Pj. > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > Hi Xin, > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > I have already modified related .cmake files and tested it. It looked fine.If > > > only the problem of my last email is solved, I think I can update the > > > cmake-support submodule. > > > > Good job :-). I can build libsequence and compile Python bindings > > now. Cool stuff. Now the final step before merging into > > release_candidate. After updating from my tree: > > > > git pull pjotr libsequence > > git submodule update > > > > add a working 'integration' test to the Python module. When you do: > > > > cd src/mappings/swig/python/libsequence > > cmake . > > make > > make test > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > the output is in Testing/Temporary/LastTest.log. > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > are bound to be elaborate. A biolib integration test merely makes sure > > the build system did not fail - so it usually has a few simple tests. > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > and create a new short test (see test_example.py) that confirms the > > libraries are linked together and the mapping just works. Same for > > the Perl module. > > > > Once that test passes I'll merge into release_candidate so Mark (and > > perhaps others) can start testing. > > > > Pj. > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > changed those, but I think this is correct. > > > > _______________________________________________ > > BioLib-dev mailing list > > BioLib-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/biolib-dev From xshuai at umail.iu.edu Mon Aug 10 19:33:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 15:33:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810170605.GA18767@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> Message-ID: <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> Hi, Pjotr: I checked my file permission set up in my machine and it is alright. So I don't need to change the unmask. Regarding to the bad commit, I think I forgot to tell you one thing. During the process of modifying the CMake files to include gsl linking, I found you named all the dependent library with a biolib_ prefix: biolib_core, biolib_R. So I renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake setup cannot find the gsl dynamic library. So when I commit, the .gsl/ directory with all its 644 mode files are deleted and a new directory ./biolib_gsl is added. This is not the first time I do this. At the beginning, when I compile the libsequence library, I handle it similarly: I changed the ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake setup cannot find correct path. So is there anything I missed? On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins wrote: > Hi Xin, > > This was a bit painful, but arguably my mistake. You can pull from my > branch now without problems. You may have to revert your own branch > to your github master first: to throw out the reintroduced patch. > > Note you have later put it new files with the wrong permissions. See > the patch: > > c92151cdc3db8b353534532baee4c70dc5a2583e > > it includes a number of 755 permissions. When you create a new file > on your machine: > > touch test.me > ls -l test.me > > what are its permissions? It should be 644 or -rw-r--r--. If they are > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > umask 022 > > See Internet resources on how to manage that. > > Pj. > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > I think your master branch is clean. I'll work from there. > > > > Pj. > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > Hi Xin, > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > I have already modified related .cmake files and tested it. It looked > fine.If > > > > only the problem of my last email is solved, I think I can update the > > > > cmake-support submodule. > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > now. Cool stuff. Now the final step before merging into > > > release_candidate. After updating from my tree: > > > > > > git pull pjotr libsequence > > > git submodule update > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > cd src/mappings/swig/python/libsequence > > > cmake . > > > make > > > make test > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > > are bound to be elaborate. A biolib integration test merely makes sure > > > the build system did not fail - so it usually has a few simple tests. > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > and create a new short test (see test_example.py) that confirms the > > > libraries are linked together and the mapping just works. Same for > > > the Perl module. > > > > > > Once that test passes I'll merge into release_candidate so Mark (and > > > perhaps others) can start testing. > > > > > > Pj. > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > > changed those, but I think this is correct. > > > > > > _______________________________________________ > > > BioLib-dev mailing list > > > BioLib-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 20:09:32 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 22:09:32 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> Message-ID: <20090810200932.GA21413@thebird.nl> All great :-) On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > Hi, Pjotr: I checked my file permission set up in my machine and it is > alright. So I don't need to change the unmask. > > Regarding to the bad commit, > I think I forgot to tell you one thing. During the process of > modifying the CMake files to include gsl linking, I found you named > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. So I > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > directory with all its 644 mode files are deleted and a new directory > ./biolib_gsl is added. > > This is not the first time I do this. At the beginning, when I compile the > libsequence library, I handle it similarly: I changed the > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > setup cannot find correct path. > > So is there anything I missed? > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins wrote: > > > Hi Xin, > > > > This was a bit painful, but arguably my mistake. You can pull from my > > branch now without problems. You may have to revert your own branch > > to your github master first: to throw out the reintroduced patch. > > > > Note you have later put it new files with the wrong permissions. See > > the patch: > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > it includes a number of 755 permissions. When you create a new file > > on your machine: > > > > touch test.me > > ls -l test.me > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > umask 022 > > > > See Internet resources on how to manage that. > > > > Pj. > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > I think your master branch is clean. I'll work from there. > > > > > > Pj. > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > Hi Xin, > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > I have already modified related .cmake files and tested it. It looked > > fine.If > > > > > only the problem of my last email is solved, I think I can update the > > > > > cmake-support submodule. > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > now. Cool stuff. Now the final step before merging into > > > > release_candidate. After updating from my tree: > > > > > > > > git pull pjotr libsequence > > > > git submodule update > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > cd src/mappings/swig/python/libsequence > > > > cmake . > > > > make > > > > make test > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. They > > > > are bound to be elaborate. A biolib integration test merely makes sure > > > > the build system did not fail - so it usually has a few simple tests. > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > libraries are linked together and the mapping just works. Same for > > > > the Perl module. > > > > > > > > Once that test passes I'll merge into release_candidate so Mark (and > > > > perhaps others) can start testing. > > > > > > > > Pj. > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why you > > > > changed those, but I think this is correct. > > > > > > > > _______________________________________________ > > > > BioLib-dev mailing list > > > > BioLib-dev at lists.open-bio.org > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From xshuai at umail.iu.edu Mon Aug 10 20:18:51 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Mon, 10 Aug 2009 16:18:51 -0400 Subject: [BioLib-dev] GSL In-Reply-To: <20090810200932.GA21413@thebird.nl> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> <20090810200932.GA21413@thebird.nl> Message-ID: <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> Then ,do I have to throw out that commit? On Mon, Aug 10, 2009 at 4:09 PM, Pjotr Prins wrote: > All great :-) > > On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > > Hi, Pjotr: I checked my file permission set up in my machine and it is > > alright. So I don't need to change the unmask. > > > > Regarding to the bad commit, > > I think I forgot to tell you one thing. During the process of > > modifying the CMake files to include gsl linking, I found you named > > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. > So I > > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > > directory with all its 644 mode files are deleted and a new directory > > ./biolib_gsl is added. > > > > This is not the first time I do this. At the beginning, when I compile > the > > libsequence library, I handle it similarly: I changed the > > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > > setup cannot find correct path. > > > > So is there anything I missed? > > > > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins >wrote: > > > > > Hi Xin, > > > > > > This was a bit painful, but arguably my mistake. You can pull from my > > > branch now without problems. You may have to revert your own branch > > > to your github master first: to throw out the reintroduced patch. > > > > > > Note you have later put it new files with the wrong permissions. See > > > the patch: > > > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > > > it includes a number of 755 permissions. When you create a new file > > > on your machine: > > > > > > touch test.me > > > ls -l test.me > > > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > > > umask 022 > > > > > > See Internet resources on how to manage that. > > > > > > Pj. > > > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > > I think your master branch is clean. I'll work from there. > > > > > > > > Pj. > > > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > > Hi Xin, > > > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > > I have already modified related .cmake files and tested it. It > looked > > > fine.If > > > > > > only the problem of my last email is solved, I think I can update > the > > > > > > cmake-support submodule. > > > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > > now. Cool stuff. Now the final step before merging into > > > > > release_candidate. After updating from my tree: > > > > > > > > > > git pull pjotr libsequence > > > > > git submodule update > > > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > > > cd src/mappings/swig/python/libsequence > > > > > cmake . > > > > > make > > > > > make test > > > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. > They > > > > > are bound to be elaborate. A biolib integration test merely makes > sure > > > > > the build system did not fail - so it usually has a few simple > tests. > > > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > > libraries are linked together and the mapping just works. Same for > > > > > the Perl module. > > > > > > > > > > Once that test passes I'll merge into release_candidate so Mark > (and > > > > > perhaps others) can start testing. > > > > > > > > > > Pj. > > > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why > you > > > > > changed those, but I think this is correct. > > > > > > > > > > _______________________________________________ > > > > > BioLib-dev mailing list > > > > > BioLib-dev at lists.open-bio.org > > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > > > > > > -- > > Xin Shuai (David) > > PhD of Complex System in School of Informatics > > Indiana University Bloomington > > 812-606-8019 > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Mon Aug 10 20:25:08 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Mon, 10 Aug 2009 22:25:08 +0200 Subject: [BioLib-dev] GSL In-Reply-To: <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> References: <20090805165715.GA5000@thebird.nl> <3a7743460908071216g7917ce73he6e7dfd81c2a1d1b@mail.gmail.com> <3a7743460908071314o77cbe1a8j69e2e8fbbfee2866@mail.gmail.com> <20090810090140.GA11161@thebird.nl> <20090810160207.GA18659@thebird.nl> <20090810170605.GA18767@thebird.nl> <3a7743460908101233p59612c4buf0cdc1b1dcf7c063@mail.gmail.com> <20090810200932.GA21413@thebird.nl> <3a7743460908101318v4c65fdccnbd8835beee632d8f@mail.gmail.com> Message-ID: <20090810202508.GA21501@thebird.nl> The tree looks sane to me - as it is now. The renaming is there biolib_gsl. Your branch on your machine is probably dirty now. But the ones on github are fine. Destroy all the branches with the dirty patch (after making a backup). Pull your github master branch and update from my libsequence branch. Everything should by hunky dory. Pj. On Mon, Aug 10, 2009 at 04:18:51PM -0400, Xin Shuai wrote: > Then ,do I have to throw out that commit? > > On Mon, Aug 10, 2009 at 4:09 PM, Pjotr Prins wrote: > > > All great :-) > > > > On Mon, Aug 10, 2009 at 03:33:51PM -0400, Xin Shuai wrote: > > > Hi, Pjotr: I checked my file permission set up in my machine and it is > > > alright. So I don't need to change the unmask. > > > > > > Regarding to the bad commit, > > > I think I forgot to tell you one thing. During the process of > > > modifying the CMake files to include gsl linking, I found you named > > > all the dependent library with a biolib_ prefix: biolib_core, biolib_R. > > So I > > > renamed ./gsl directory to ./biolib_gsl directory. Otherwise, your cmake > > > setup cannot find the gsl dynamic library. So when I commit, the .gsl/ > > > directory with all its 644 mode files are deleted and a new directory > > > ./biolib_gsl is added. > > > > > > This is not the first time I do this. At the beginning, when I compile > > the > > > libsequence library, I handle it similarly: I changed the > > > ./clibs/libsequence to ./clibs/libsequence-1.6.6. Otherwise, your cmake > > > setup cannot find correct path. > > > > > > So is there anything I missed? > > > > > > > > > On Mon, Aug 10, 2009 at 1:06 PM, Pjotr Prins > >wrote: > > > > > > > Hi Xin, > > > > > > > > This was a bit painful, but arguably my mistake. You can pull from my > > > > branch now without problems. You may have to revert your own branch > > > > to your github master first: to throw out the reintroduced patch. > > > > > > > > Note you have later put it new files with the wrong permissions. See > > > > the patch: > > > > > > > > c92151cdc3db8b353534532baee4c70dc5a2583e > > > > > > > > it includes a number of 755 permissions. When you create a new file > > > > on your machine: > > > > > > > > touch test.me > > > > ls -l test.me > > > > > > > > what are its permissions? It should be 644 or -rw-r--r--. If they are > > > > 755 (rwxr-xr-x) you may need to change the umask on your machine: > > > > > > > > umask 022 > > > > > > > > See Internet resources on how to manage that. > > > > > > > > Pj. > > > > > > > > On Mon, Aug 10, 2009 at 06:02:07PM +0200, Pjotr Prins wrote: > > > > > I think your master branch is clean. I'll work from there. > > > > > > > > > > Pj. > > > > > > > > > > On Mon, Aug 10, 2009 at 11:01:40AM +0200, Pjotr Prins wrote: > > > > > > Hi Xin, > > > > > > > > > > > > On Fri, Aug 07, 2009 at 04:14:29PM -0400, Xin Shuai wrote: > > > > > > > I have already modified related .cmake files and tested it. It > > looked > > > > fine.If > > > > > > > only the problem of my last email is solved, I think I can update > > the > > > > > > > cmake-support submodule. > > > > > > > > > > > > Good job :-). I can build libsequence and compile Python bindings > > > > > > now. Cool stuff. Now the final step before merging into > > > > > > release_candidate. After updating from my tree: > > > > > > > > > > > > git pull pjotr libsequence > > > > > > git submodule update > > > > > > > > > > > > add a working 'integration' test to the Python module. When you do: > > > > > > > > > > > > cd src/mappings/swig/python/libsequence > > > > > > cmake . > > > > > > make > > > > > > make test > > > > > > > > > > > > you'll see 1/ 1 Testing TestPythonlibsequence ***Failed > > > > > > > > > > > > the output is in Testing/Temporary/LastTest.log. > > > > > > > > > > > > Currently ../test/test_libsequence.py consists of your doctests. > > They > > > > > > are bound to be elaborate. A biolib integration test merely makes > > sure > > > > > > the build system did not fail - so it usually has a few simple > > tests. > > > > > > > > > > > > Rename your current doctest to ../test/doctest_libsequence.py > > > > > > > > > > > > and create a new short test (see test_example.py) that confirms the > > > > > > libraries are linked together and the mapping just works. Same for > > > > > > the Perl module. > > > > > > > > > > > > Once that test passes I'll merge into release_candidate so Mark > > (and > > > > > > perhaps others) can start testing. > > > > > > > > > > > > Pj. > > > > > > > > > > > > P.S. I had to revert some changes in cmake-support. Not sure why > > you > > > > > > changed those, but I think this is correct. > > > > > > > > > > > > _______________________________________________ > > > > > > BioLib-dev mailing list > > > > > > BioLib-dev at lists.open-bio.org > > > > > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > > > > > > > > > > > > > > > > -- > > > Xin Shuai (David) > > > PhD of Complex System in School of Informatics > > > Indiana University Bloomington > > > 812-606-8019 > > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From pjotr.public14 at thebird.nl Wed Aug 12 07:15:22 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Wed, 12 Aug 2009 09:15:22 +0200 Subject: [BioLib-dev] release candidate Message-ID: <20090812071522.GA5274@thebird.nl> Hi Xin, I renamed the test file so it gets found by Cmake. However, the test fails: cd src/mappings/swig/python/libsequence cmake . make make test gives: Command: "/usr/bin/python" "./../test/test_libsequence.py" Directory: /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence "TestPythonlibsequence" start time: Aug 12 08:59 CEST Output: ---------------------------------------------------------- Traceback (most recent call last): File "./../test/test_libsequence.py", line 5, in from biolib.libsequence import * File "biolib/libsequence.py", line 7, in import _libsequence ImportError: /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int This error is caused, most likely, because we build the gsl with inline functions. INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, unsigned l ong int n); The INLINE is used for performance reasons (see http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible outside the shared library itself. However SWIG thinks it is visible, because it is defined in gsl_rng.h) and has created a mapping for it. That is why the test fails. A first good case for an integration test :-) Can you find a way to tell SWIG *not* to create a mapping for this, and similar, declarations? But first you need to ascertain this test fails on your system. If it does not, I suspect your linker finds a different GSL shared library on your system - one that has the INLINE statement switched off. In Linux we can use something like ldd libsequence-swig.so (or similar dylib) to find what libraries it links against. On my system it renders: ldd biolib/_libsequence.so linux-gate.so.1 => (0xb7f42000) libbiolib_libsequence-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/libbiolib_libsequence-0.0.5.so (0xb7acd000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) libbiolib_gsl-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so (0xb7735000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) /lib/ld-linux.so.2 (0xb7f43000) You see it uses libbiolib_gsl-0.0.5.so Pj. From xshuai at umail.iu.edu Wed Aug 12 19:56:34 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Wed, 12 Aug 2009 15:56:34 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090812071522.GA5274@thebird.nl> References: <20090812071522.GA5274@thebird.nl> Message-ID: <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> Hi, Pjotr: I don't have such kind of problem in my machine, but I did revise the rng.c file in gsl library in ./contrib after I first pulled from your libsequence branch and update the submodule. Actually speaking, what I did is restore rng.c file to its original state, since I found that your ./contrib/gsl/rng/rng.c is different from the original one(gsl-1.11 version). I don't know why it is modified in ./contrib/gsl directory (I once mentioned in my email and maybe you didn't notice that). The difference between your ./contrib/gsl/rng/rng.c and the original one is that, the modified file is missing the following part: #ifndef HIDE_INLINE_STATIC unsigned long int gsl_rng_get (const gsl_rng * r) { return (r->type->get) (r->state); } double gsl_rng_uniform (const gsl_rng * r) { return (r->type->get_double) (r->state); } double gsl_rng_uniform_pos (const gsl_rng * r) { double x ; do { x = (r->type->get_double) (r->state) ; } while (x == 0) ; return x ; } /* Note: to avoid integer overflow in (range+1) we work with scale = range/n = (max-min)/n rather than scale=(max-min+1)/n, this reduces efficiency slightly but avoids having to check for the out of range value. Note that range is typically O(2^32) so the addition of 1 is negligible in most usage. */ unsigned long int gsl_rng_uniform_int (const gsl_rng * r, unsigned long int n) { unsigned long int offset = r->type->min; unsigned long int range = r->type->max - offset; unsigned long int scale; unsigned long int k; if (n > range || n == 0) { GSL_ERROR_VAL ("invalid n, either 0 or exceeds maximum value of generator", GSL_EINVAL, 0) ; } scale = range / n; do { k = (((r->type->get) (r->state)) - offset) / scale; } while (k >= n); return k; } #endif So I just added the following part to my./contrib/gsl/rng/rng.c. (The reason I found this problem is that when I import libsequence in Python, gsl_rng_uniform is reported missing. It really took me some time to figure it out) However, when I added that part, which seems related with 'inline' definition. Then I just remove the 'inline.cc' file name from the gsl_file.txt list. And everything looked fine then. Therefore, I guess maybe you modified the original file to avoid inline problem. On Wed, Aug 12, 2009 at 3:15 AM, Pjotr Prins wrote: > Hi Xin, > > I renamed the test file so it gets found by Cmake. > > However, the test fails: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > gives: > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > Directory: > /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > Output: > ---------------------------------------------------------- > Traceback (most recent call last): > File "./../test/test_libsequence.py", line 5, in > from biolib.libsequence import * > File "biolib/libsequence.py", line 7, in > import _libsequence > ImportError: > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > This error is caused, most likely, because we build the gsl with inline > functions. > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, > unsigned l ong int n); > > The INLINE is used for performance reasons (see > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible > outside > the shared library itself. However SWIG thinks it is visible, because it is > defined in gsl_rng.h) and has created a mapping for it. That is why the > test > fails. A first good case for an integration test :-) > > Can you find a way to tell SWIG *not* to create a mapping for this, and > similar, > declarations? > > But first you need to ascertain this test fails on your system. If it does > not, > I suspect your linker finds a different GSL shared library on your system - > one > that has the INLINE statement switched off. In Linux we can use something > like > > ldd libsequence-swig.so (or similar dylib) > > to find what libraries it links against. On my system it renders: > > ldd biolib/_libsequence.so > > linux-gate.so.1 => (0xb7f42000) > libbiolib_libsequence-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/ > libbiolib_libsequence-0.0.5.so (0xb7acd000) > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > libbiolib_gsl-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so (0xb7735000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > /lib/ld-linux.so.2 (0xb7f43000) > > You see it uses libbiolib_gsl-0.0.5.so > > Pj. > > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Thu Aug 13 07:05:52 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Thu, 13 Aug 2009 09:05:52 +0200 Subject: [BioLib-dev] release candidate In-Reply-To: <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> References: <20090812071522.GA5274@thebird.nl> <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> Message-ID: <20090813070552.GA12306@thebird.nl> Hi Xin, On Wed, Aug 12, 2009 at 03:56:34PM -0400, Xin Shuai wrote: > Hi, Pjotr: I don't have such kind of problem in my machine, but I did > revise the rng.c file in gsl library in ./contrib after I first pulled from > your libsequence branch and update the submodule. The gsl tree loaded into biolib is from the original repository - so the later version has moved the inline stuff. In fact if you do: cd contrib/gsl git checkout master gitk rng/rng.c You can see patch 85b66997ea8b66cd4b07c283a2ee7823faadc740 by Brian Gough does exactly that. I think we need to track the GSL, don't you? > Actually speaking, what I did is restore rng.c file to its original state, > since I found that your ./contrib/gsl/rng/rng.c is different from the > original one(gsl-1.11 version). I don't know why it is modified in > ./contrib/gsl directory (I once mentioned in my email and maybe you didn't > notice that). The difference between your ./contrib/gsl/rng/rng.c and the > original one is that, the modified file is missing the following part: > > #ifndef HIDE_INLINE_STATIC > > unsigned long int I think the GSL now always uses the INLINE version as all current C compilers support inline. I see one solution or one work around: allow the GSL to function with SWIG by handling INLINE correctly (this should be possible) and the other where we have our own version of rng.c in ./src/clibs/gsl/src/rng.c. The last is a workaround, and, in this case perhaps acceptable. How do you want to handle this? Pj. From xshuai at umail.iu.edu Thu Aug 13 14:57:28 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Thu, 13 Aug 2009 10:57:28 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090813070552.GA12306@thebird.nl> References: <20090812071522.GA5274@thebird.nl> <3a7743460908121256j13f8daeao335ae21bce939806@mail.gmail.com> <20090813070552.GA12306@thebird.nl> Message-ID: <3a7743460908130757xe3276eflf4f37db2d8d00d5@mail.gmail.com> Oh....I see, it is the modification from the author.I think at this moment I'll take the work around solution, that is using my version in ./src/clibs/gsl/src/rng.c. Since time is limited I want to concentrate on solving more problems in testing and mapping. Maybe We can find a better solution in the future. On Thu, Aug 13, 2009 at 3:05 AM, Pjotr Prins wrote: > Hi Xin, > > On Wed, Aug 12, 2009 at 03:56:34PM -0400, Xin Shuai wrote: > > Hi, Pjotr: I don't have such kind of problem in my machine, but I did > > revise the rng.c file in gsl library in ./contrib after I first pulled > from > > your libsequence branch and update the submodule. > > The gsl tree loaded into biolib is from the original repository - so > the later version has moved the inline stuff. In fact if you do: > > cd contrib/gsl > git checkout master > gitk rng/rng.c > > You can see patch 85b66997ea8b66cd4b07c283a2ee7823faadc740 by Brian > Gough does exactly that. > > I think we need to track the GSL, don't you? > > > Actually speaking, what I did is restore rng.c file to its original > state, > > since I found that your ./contrib/gsl/rng/rng.c is different from the > > original one(gsl-1.11 version). I don't know why it is modified in > > ./contrib/gsl directory (I once mentioned in my email and maybe you > didn't > > notice that). The difference between your ./contrib/gsl/rng/rng.c and the > > original one is that, the modified file is missing the following part: > > > > #ifndef HIDE_INLINE_STATIC > > > > unsigned long int > > > > I think the GSL now always uses the INLINE version as all current C > compilers support inline. I see one solution or one work around: allow > the GSL to function with SWIG by handling INLINE correctly (this > should be possible) and the other where we have our own version of > rng.c in ./src/clibs/gsl/src/rng.c. The last is a workaround, and, in > this case perhaps acceptable. > > How do you want to handle this? > > Pj. > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Fri Aug 14 06:27:43 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Fri, 14 Aug 2009 08:27:43 +0200 Subject: [BioLib-dev] release candidate In-Reply-To: <20090812071522.GA5274@thebird.nl> References: <20090812071522.GA5274@thebird.nl> Message-ID: <20090814062743.GA22829@thebird.nl> Hi Xin, Everything compiles. Now the final bit - the integration test now expects input from stdin (a FASTA sequence). That should be read from a file instead. I have added src/test/data/fasta/example.fasta to the repository. Pj. On Wed, Aug 12, 2009 at 09:15:22AM +0200, Pjotr Prins wrote: > Hi Xin, > > I renamed the test file so it gets found by Cmake. > > However, the test fails: > > cd src/mappings/swig/python/libsequence > cmake . > make > make test > > gives: > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > Directory: /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > Output: > ---------------------------------------------------------- > Traceback (most recent call last): > File "./../test/test_libsequence.py", line 5, in > from biolib.libsequence import * > File "biolib/libsequence.py", line 7, in > import _libsequence > ImportError: /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > This error is caused, most likely, because we build the gsl with inline > functions. > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, unsigned l ong int n); > > The INLINE is used for performance reasons (see > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible outside > the shared library itself. However SWIG thinks it is visible, because it is > defined in gsl_rng.h) and has created a mapping for it. That is why the test > fails. A first good case for an integration test :-) > > Can you find a way to tell SWIG *not* to create a mapping for this, and similar, > declarations? > > But first you need to ascertain this test fails on your system. If it does not, > I suspect your linker finds a different GSL shared library on your system - one > that has the INLINE statement switched off. In Linux we can use something like > > ldd libsequence-swig.so (or similar dylib) > > to find what libraries it links against. On my system it renders: > > ldd biolib/_libsequence.so > > linux-gate.so.1 => (0xb7f42000) > libbiolib_libsequence-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/libbiolib_libsequence-0.0.5.so (0xb7acd000) > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > libbiolib_gsl-0.0.5.so => /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/libbiolib_gsl-0.0.5.so (0xb7735000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > /lib/ld-linux.so.2 (0xb7f43000) > > You see it uses libbiolib_gsl-0.0.5.so > > Pj. > > _______________________________________________ > BioLib-dev mailing list > BioLib-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biolib-dev From xshuai at umail.iu.edu Fri Aug 14 16:04:12 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Fri, 14 Aug 2009 12:04:12 -0400 Subject: [BioLib-dev] release candidate In-Reply-To: <20090814062743.GA22829@thebird.nl> References: <20090812071522.GA5274@thebird.nl> <20090814062743.GA22829@thebird.nl> Message-ID: <3a7743460908140904o8841966w765f3f72c2c2b986@mail.gmail.com> OK. I 've already updated that and set the file path in my test_libsequence.py On Fri, Aug 14, 2009 at 2:27 AM, Pjotr Prins wrote: > Hi Xin, > > Everything compiles. Now the final bit - the integration test now > expects input from stdin (a FASTA sequence). That should be read from > a file instead. I have added > > src/test/data/fasta/example.fasta > > to the repository. > > Pj. > > On Wed, Aug 12, 2009 at 09:15:22AM +0200, Pjotr Prins wrote: > > Hi Xin, > > > > I renamed the test file so it gets found by Cmake. > > > > However, the test fails: > > > > cd src/mappings/swig/python/libsequence > > cmake . > > make > > make test > > > > gives: > > > > Command: "/usr/bin/python" "./../test/test_libsequence.py" > > Directory: > /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence > > "TestPythonlibsequence" start time: Aug 12 08:59 CEST > > Output: > > ---------------------------------------------------------- > > Traceback (most recent call last): > > File "./../test/test_libsequence.py", line 5, in > > from biolib.libsequence import * > > File "biolib/libsequence.py", line 7, in > > import _libsequence > > ImportError: > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int > > > > > > This error is caused, most likely, because we build the gsl with inline > > functions. > > > > INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r, > unsigned l ong int n); > > > > The INLINE is used for performance reasons (see > > http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible > outside > > the shared library itself. However SWIG thinks it is visible, because it > is > > defined in gsl_rng.h) and has created a mapping for it. That is why the > test > > fails. A first good case for an integration test :-) > > > > Can you find a way to tell SWIG *not* to create a mapping for this, and > similar, > > declarations? > > > > But first you need to ascertain this test fails on your system. If it > does not, > > I suspect your linker finds a different GSL shared library on your system > - one > > that has the INLINE statement switched off. In Linux we can use something > like > > > > ldd libsequence-swig.so (or similar dylib) > > > > to find what libraries it links against. On my system it renders: > > > > ldd biolib/_libsequence.so > > > > linux-gate.so.1 => (0xb7f42000) > > libbiolib_libsequence-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/ > libbiolib_libsequence-0.0.5.so (0xb7acd000) > > libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000) > > libbiolib_gsl-0.0.5.so => > /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/ > libbiolib_gsl-0.0.5.so (0xb7735000) > > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000) > > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000) > > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000) > > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000) > > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000) > > libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000) > > /lib/ld-linux.so.2 (0xb7f43000) > > > > You see it uses libbiolib_gsl-0.0.5.so > > > > Pj. > > > > _______________________________________________ > > BioLib-dev mailing list > > BioLib-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/biolib-dev > -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From xshuai at umail.iu.edu Fri Aug 14 16:16:40 2009 From: xshuai at umail.iu.edu (Xin Shuai) Date: Fri, 14 Aug 2009 12:16:40 -0400 Subject: [BioLib-dev] Focus of my task during last few days. Message-ID: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> Hi, All: Since only a few days left to the project deadline, I 've tried to figured out and solved as many as problems as in the process of mapping and wrapping. However, there're still a few problems left. For some of them I know the reason but don't know to solve it, for others I just don't know the reason at all. Currently I still want to solve those problem if I can. Overall, I think libsequence can be used generally now for Python/Perl. Python unit testing is almost finished, except those problematic classes and functions. Perl unit testing still needs to add. Comparatively, integration testing are quite simple. Thus, in the last few days, I want to know what you expect me to focus: (1) Try to solve the rest of those mapping and testing problems (2) Enrich the integration testing using current usable classes and functions , to include more user case (3) Anything else. Just let me know that I can have an arrangement. -- Xin Shuai (David) PhD of Complex System in School of Informatics Indiana University Bloomington 812-606-8019 From pjotr.public14 at thebird.nl Fri Aug 14 16:23:59 2009 From: pjotr.public14 at thebird.nl (Pjotr Prins) Date: Fri, 14 Aug 2009 18:23:59 +0200 Subject: [BioLib-dev] Focus of my task during last few days. In-Reply-To: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> References: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> Message-ID: <20090814162359.GB1128@thebird.nl> I vote for (1) On Fri, Aug 14, 2009 at 12:16:40PM -0400, Xin Shuai wrote: > Hi, All: Since only a few days left to the project deadline, I 've tried to > figured out and solved as many as problems as in the process of mapping and > wrapping. However, there're still a few problems left. For some of them I > know the reason but don't know to solve it, for others I just don't know the > reason at all. Currently I still want to solve those problem if I can. > Overall, I think libsequence can be used generally now for Python/Perl. > Python unit testing is almost finished, except those problematic classes and > functions. Perl unit testing still needs to add. Comparatively, integration > testing are quite simple. > > Thus, in the last few days, I want to know what you expect me to focus: > (1) Try to solve the rest of those mapping and testing problems > (2) Enrich the integration testing using current usable classes and > functions , to include more user case > (3) Anything else. > > Just let me know that I can have an arrangement. > > > > > -- > Xin Shuai (David) > PhD of Complex System in School of Informatics > Indiana University Bloomington > 812-606-8019 From cjfields at illinois.edu Fri Aug 14 18:53:00 2009 From: cjfields at illinois.edu (Chris Fields) Date: Fri, 14 Aug 2009 13:53:00 -0500 Subject: [BioLib-dev] Focus of my task during last few days. In-Reply-To: <20090814162359.GB1128@thebird.nl> References: <3a7743460908140916y398c9478h657aff7efc0b488b@mail.gmail.com> <20090814162359.GB1128@thebird.nl> Message-ID: Same here, go for option (1). Testing is important, but as we're in the short term, I think emphasis should be on finishing the implementation first. Once that's in place we can work on tests. chris On Aug 14, 2009, at 11:23 AM, Pjotr Prins wrote: > I vote for (1) > > On Fri, Aug 14, 2009 at 12:16:40PM -0400, Xin Shuai wrote: >> Hi, All: Since only a few days left to the project deadline, I 've >> tried to >> figured out and solved as many as problems as in the process of >> mapping and >> wrapping. However, there're still a few problems left. For some of >> them I >> know the reason but don't know to solve it, for others I just don't >> know the >> reason at all. Currently I still want to solve those problem if I >> can. >> Overall, I think libsequence can be used generally now for Python/ >> Perl. >> Python unit testing is almost finished, except those problematic >> classes and >> functions. Perl unit testing still needs to add. Comparatively, >> integration >> testing are quite simple. >> >> Thus, in the last few days, I want to know what you expect me to >> focus: >> (1) Try to solve the rest of those mapping and testing problems >> (2) Enrich the integration testing using current usable classes and >> functions , to include more user case >> (3) Anything else. >> >> Just let me know that I can have an arrangement. >> >> >> >> >> -- >> Xin Shuai (David) >> PhD of Complex System in School of Informatics >> Indiana University Bloomington >> 812-606-8019