ecell-devel Mailing List for E-Cell System

Koichi Takahashi wrote:
> Hi Eric,
>
> Nathan Addy, a full-time scientific programmer at the Molecular
> Sciences Institute, will work on preparation for and packaging
> of version 3.1.106 with me during the next month.   We currently
> plan the release date to be by early June.   An update to
> the user's manual will follow.   We plan an opening of
> a development branch shortly following the release.
>
Great ! So if I understand well, the next stable will be tagged 3.1.106.

Thanks a lot for these news and good luck for the future release.
Eric

Hi Eric,

Nathan Addy, a full-time scientific programmer at the Molecular
Sciences Institute, will work on preparation for and packaging
of version 3.1.106 with me during the next month.   We currently
plan the release date to be by early June.   An update to
the user's manual will follow.   We plan an opening of
a development branch shortly following the release.

Version 3.1.105 will exist only as CVS/SVN tags to avoid
confusion in the prolonged release cycle.
Thanks for asking this.


The last twelve months have been a transitional period for us
E-Cell System development team; I moved to California, Nathan
joined the project, we started a joint project with Mitsubishi
Space Software, plus a few graduate students who
contributed a lot of code graduated.    We all have been
trying to learn how the project can be made maximally productive
in this changing, larger and growing structure.

This year will be marked as a start of a new stage for us.
Although radio silence has been filling ecell-devel mailing
list most of the time for some time, lots of exciting things
are happening underwater in the last four months.  Some of
such include a transition to a more professional and
organized software development scheme while maintaining
active interaction with the opensource community
(we will have some more open positions available soon),
and the start of design&development of the next generation
of E-Cell simulation core (E-Cell 4).

Such changes will not be limited only to the software
development team, but we, the entire E-Cell Project,
is moving towards 'E-Cell Project Version 2.0'.

We appreciate importance of continuing development, both
evolutionary and revolutionary, and timely releases.
Thank you for your patience while we work hard.
Your input will continue to be most valuable.


Best Regards,
Koichi Takahashi, PhD
Member, E-Cell Project Steering Committee







> Hi,
> 
> Is there any schedule about the final release of ecell 3.1.105 ? and the
> opening of the 3.1.106 development branch ?
> Thank you.
> Eric
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hi,

Is there any schedule about the final release of ecell 3.1.105 ? and the
opening of the 3.1.106 development branch ?
Thank you.
Eric

Koichi Takahashi wrote:
> Hi Eric,
>
>
> I think I've fixed this.  Please try again.
>
>
>
Hi,

It works, packages are built correctly, many thanks.

I have these two warnings during the ./configure though:

checking for python module gnome.ui... ./configure: line 3283: 20709
Aborted                 $PYTHON -c "$prog" 1>&5 2>&5
checking for python module gnome.ui... ./configure: line 3361: 26193
Aborted                 $PYTHON -c "$prog" 1>&5 2>&5

but compilation works fine.

Eric

Hi Eric,


I think I've fixed this.  Please try again.


What I did was mainly to use only pyexecdir, even where
pythondir is appropriate.

Distutil's policy which is to install platform-independent
files (*.py) in lib/ instead of lib64/ is understandable,
but unfortunately this somehow conflicts with RedHat's way.



Other things:

REMOVED: eri2eml, rd2dm, which are no longer up-to-date.

TODO:

- generally, the whole source tree needs some thorough cleanup.
- move toollauncher, osogo, modeleditor into ecell/ in the source tree.
- include toollauncher, osogo, modeleditor into the python module
    hierarchy (under ecell module).  Don't install them immediately
     under ${libdir}.
- rename: osogo -> ecell3-session-gui
- gecell3-session -> merge with ecell3-session-gui
- rename: modeleditor -> ecell3-modeleditor
     (link to ecell3-modeleditor-gui)
- toollauncher: ecell3-launcher?
- move ecell3/bin into somewhere inside ecell3/ecell.
- dmtool, dmtool/dmcompile:
      dependency to ecell should be avoided.  Eventually to be replaced
       by libtool?
- dmcompile
- merge ecell/pyecs and ecell/pyecell?
- PREFIX/lib/ecell/VERSION and PREFIX/share/ecell/VERSION should simply
    be like PREFIX/lib/ecell3.2/ ?
- modularities are not fully respected in many portions, mainly
   in GUI codes.  for ex. modeleditor depends on osogo.
    that means some serious refactoring is needed.
- modeleditor doesn't start on fc5.

koichi


> Hi,
> I am trying to package E-cell for Mandriva, using latest svn revision.
> There is no problem with the i586 version, but I fail with the x86_64.
> 
> I guess the problem is some hardcoded /usr/lib/ path. In
> ecell/dm/Makefile, I have:
> 
> pyexecdir = ${exec_prefix}/lib64/python2.4/site-packages <-- OK
> pythondir = ${prefix}/lib/python2.4/site-packages <-- Not OK?
> [...]
> DM_SO_DIR = ${prefix}/lib/${PACKAGE}/${VERSION} <-- Not OK?
> 
> In my BUILDROOT, I have those directories:
> 
> lib/debug/
> lib/ecell/
> lib/python2.4/
> 
> and:
> 
> lib64/libecs.la*
> lib64/libecs.so -> libecs.so.2.0.0*
> lib64/libecs.so.2 -> libecs.so.2.0.0*
> lib64/libecs.so.2.0.0*
> lib64/libemc.la*
> lib64libemc.so -> libemc.so.2.0.0*
> lib64/libemc.so.2 -> libemc.so.2.0.0*
> lib64/libemc.so.2.0.0*
> lib64/modeleditor/
> lib64/osogo/
> lib64/toollauncher/
> 
> and therefore, I get this packaging error:
> RPM build errors:
>     File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/ecell
>     File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/python2.4
> 
> 
> Am I doing something wrong ? Or is there a problem with the hardcoded
> /lib/ ?
> 
> Thanks,
> Eric
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hi Eric,

I suspect part of the problem, for pyexecdir,
is old automake/autoconf.  What versions are you using?

The other, DM_SO_DIR, it's a bug.  I'll work on it.

Koichi


> Hi,
> I am trying to package E-cell for Mandriva, using latest svn revision.
> There is no problem with the i586 version, but I fail with the x86_64.
> 
> I guess the problem is some hardcoded /usr/lib/ path. In
> ecell/dm/Makefile, I have:
> 
> pyexecdir = ${exec_prefix}/lib64/python2.4/site-packages <-- OK
> pythondir = ${prefix}/lib/python2.4/site-packages <-- Not OK?
> [...]
> DM_SO_DIR = ${prefix}/lib/${PACKAGE}/${VERSION} <-- Not OK?
> 
> In my BUILDROOT, I have those directories:
> 
> lib/debug/
> lib/ecell/
> lib/python2.4/
> 
> and:
> 
> lib64/libecs.la*
> lib64/libecs.so -> libecs.so.2.0.0*
> lib64/libecs.so.2 -> libecs.so.2.0.0*
> lib64/libecs.so.2.0.0*
> lib64/libemc.la*
> lib64libemc.so -> libemc.so.2.0.0*
> lib64/libemc.so.2 -> libemc.so.2.0.0*
> lib64/libemc.so.2.0.0*
> lib64/modeleditor/
> lib64/osogo/
> lib64/toollauncher/
> 
> and therefore, I get this packaging error:
> RPM build errors:
>     File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/ecell
>     File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/python2.4
> 
> 
> Am I doing something wrong ? Or is there a problem with the hardcoded
> /lib/ ?
> 
> Thanks,
> Eric
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hi,
I am trying to package E-cell for Mandriva, using latest svn revision.
There is no problem with the i586 version, but I fail with the x86_64.

I guess the problem is some hardcoded /usr/lib/ path. In
ecell/dm/Makefile, I have:

pyexecdir = ${exec_prefix}/lib64/python2.4/site-packages <-- OK
pythondir = ${prefix}/lib/python2.4/site-packages <-- Not OK?
[...]
DM_SO_DIR = ${prefix}/lib/${PACKAGE}/${VERSION} <-- Not OK?

In my BUILDROOT, I have those directories:

lib/debug/
lib/ecell/
lib/python2.4/

and:

lib64/libecs.la*
lib64/libecs.so -> libecs.so.2.0.0*
lib64/libecs.so.2 -> libecs.so.2.0.0*
lib64/libecs.so.2.0.0*
lib64/libemc.la*
lib64libemc.so -> libemc.so.2.0.0*
lib64/libemc.so.2 -> libemc.so.2.0.0*
lib64/libemc.so.2.0.0*
lib64/modeleditor/
lib64/osogo/
lib64/toollauncher/

and therefore, I get this packaging error:
RPM build errors:
    File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/ecell
    File not found: /home/zeb/rpm/tmp/ecell-buildroot/usr/lib64/python2.4


Am I doing something wrong ? Or is there a problem with the hardcoded
/lib/ ?

Thanks,
Eric

A small correction:

> svn co https://svn.sourceforge.net/svnroot/ecell/ecell3/trunk ecell

This gets you the trunk version under the directory named ecell.

If you prefer the same behavior as cvs, check out into 'ecell3'
directory:

svn co https://svn.sourceforge.net/svnroot/ecell/ecell3/trunk ecell3

kt




> (svn.sf.net didn't work for me, use svn.sourceforge.net)
> 
> - Please check if it works ok in your environment, and report
>   any problem on this ML.
> - I didn't migrate ecell/ecell3-web, but just the ecell3 source
>   tree.  This is because we are now working to make the new
>   www.e-cell.org to replace the web page.
> - You can basically start working on it (write-access) now, but
>   if you want to be 100% safe, I recommend to wait a few more
>   days to see if people come up with problems.
> - CVS is now not linked from the sourceforge project page, but
>   data is still there.
> 
> For more instructions/web see:
> http://sourceforge.net/svn/?group_id=72485
> 
> and the Subversion book:
> http://svnbook.red-bean.com/en/1.1/index.html
> 
> 
> Koichi
> 
> 

Hi ecell-devel,


I couldn't keep the promised schedule, sorry, but ecell Subversion
service is now ready.  The migration task was not as simple as
it appeared, and the automated mechanism on sf.net didn't work
for me.  I manually did part of the procedure, and had to re-import
binary files (png/gif/jpg) which were not marked with -kb options
in the original CVS repository.

To check out from the new repository, do something like

svn co https://svn.sourceforge.net/svnroot/ecell/ecell3/trunk ecell

(svn.sf.net didn't work for me, use svn.sourceforge.net)

- Please check if it works ok in your environment, and report
  any problem on this ML.
- I didn't migrate ecell/ecell3-web, but just the ecell3 source
  tree.  This is because we are now working to make the new
  www.e-cell.org to replace the web page.
- You can basically start working on it (write-access) now, but
  if you want to be 100% safe, I recommend to wait a few more
  days to see if people come up with problems.
- CVS is now not linked from the sourceforge project page, but
  data is still there.

For more instructions/web see:
http://sourceforge.net/svn/?group_id=72485

and the Subversion book:
http://svnbook.red-bean.com/en/1.1/index.html


Koichi