Menu
▾
▴
ecell-devel — For developers.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(13) |
Mar
(1) |
Apr
(17) |
May
(26) |
Jun
(35) |
Jul
(28) |
Aug
(17) |
Sep
(11) |
Oct
(42) |
Nov
(16) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(11) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(4) |
Jun
(19) |
Jul
(12) |
Aug
(12) |
Sep
(33) |
Oct
(3) |
Nov
(16) |
Dec
(34) |
| 2005 |
Jan
(59) |
Feb
(25) |
Mar
(9) |
Apr
(11) |
May
(8) |
Jun
(30) |
Jul
(18) |
Aug
(8) |
Sep
(12) |
Oct
(13) |
Nov
(29) |
Dec
(14) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(15) |
Apr
(11) |
May
(23) |
Jun
(14) |
Jul
(4) |
Aug
(19) |
Sep
(3) |
Oct
(34) |
Nov
(7) |
Dec
(7) |
| 2007 |
Jan
(2) |
Feb
(11) |
Mar
(15) |
Apr
|
May
(21) |
Jun
(17) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
|
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(6) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
(12) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Moriyoshi K. <mo...@sf...> - 2009-04-03 14:36:13
|
This is a known problem. The bundled libltdl no longer works with 2.x and newer releases of libtool. In this case, please install libtool 1.5.8 to some decent location and include the location of the libtool script in the PATH environment variable to run configure and make. -- moriyoshi On Fri, Apr 3, 2009 at 6:46 PM, Eric Fernandez <efe...@ph...> wrote: > Hi, > > I have an issue with libtool, when trying to compile ecell from source: > > > make[3]: Entering directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > /bin/sh ./libtool --tag=CC --mode=compile i586-mandriva-linux-gnu-gcc > -DHAVE_CONFIG_H -I. -O2 -g -pipe -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 > -mtune=generic -fasynchronous-unwind-tables -c -o ltdl.lo ltdl.c > ./libtool: line 466: CDPATH: command not found > ./libtool: line 1144: func_opt_split: command not found > libtool: Version mismatch error. This is libtool 2.2.6, but the > libtool: definition of this LT_INIT comes from an older release. > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 > libtool: and run autoconf again. > make[3]: *** [ltdl.lo] Error 63 > make[3]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell' > make: *** [all] Error 2 > > Is it possible to update ecell to latest libtool for compatibility? > > Thanks a lot. > Eric > > ------------------------------------------------------------------------------ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > |
|
From: Eric F. <efe...@ph...> - 2009-04-03 10:01:52
|
> Hi, > > I have an issue with libtool, when trying to compile ecell from > source: > > > make[3]: Entering directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > /bin/sh ./libtool --tag=CC --mode=compile > i586-mandriva-linux-gnu-gcc > -DHAVE_CONFIG_H -I. -O2 -g -pipe -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 > -mtune=generic -fasynchronous-unwind-tables -c -o ltdl.lo ltdl.c > ./libtool: line 466: CDPATH: command not found > ./libtool: line 1144: func_opt_split: command not found > libtool: Version mismatch error. This is libtool 2.2.6, but the > libtool: definition of this LT_INIT comes from an older release. > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 > libtool: and run autoconf again. > make[3]: *** [ltdl.lo] Error 63 > make[3]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell' > make: *** [all] Error 2 > > Is it possible to update ecell to latest libtool for compatibility? > > Thanks a lot. > Eric > Note this occurs not only with the SVN but also the rc3: make[5]: Entering directory `/home/zeb/svn/ecell/BUILD/ecell/ecell/libecs' /bin/sh ../libtool --tag=CXX --mode=compile i586-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../.. -I/home/zeb/svn/ecell/BUILD/ecell -I../../libltdl -I/usr/include -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -MT libecs.lo -MD -MP -MF .deps/libecs.Tpo -c -o libecs.lo libecs.cpp /bin/sh ../libtool --tag=CXX --mode=compile i586-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../.. -I/home/zeb/svn/ecell/BUILD/ecell -I../../libltdl -I/usr/include -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -MT Util.lo -MD -MP -MF .deps/Util.Tpo -c -o Util.lo Util.cpp /bin/sh ../libtool --tag=CXX --mode=compile i586-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../.. -I/home/zeb/svn/ecell/BUILD/ecell -I../../libltdl -I/usr/include -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -MT Polymorph.lo -MD -MP -MF .deps/Polymorph.Tpo -c -o Polymorph.lo Polymorph.cpp /bin/sh ../libtool --tag=CXX --mode=compile i586-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../.. -I/home/zeb/svn/ecell/BUILD/ecell -I../../libltdl -I/usr/include -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wno-pmf-conversions -MT FullID.lo -MD -MP -MF .deps/FullID.Tpo -c -o FullID.lo FullID.cpp ../libtool: line 470: CDPATH: command not found ../libtool: line 470: CDPATH: command not found ../libtool: line 470: CDPATH: command not found ../libtool: line 470: CDPATH: command not found ../libtool: line 1148: func_opt_split: command not found ../libtool: line 1148: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. Eric |
|
From: Eric F. <efe...@ph...> - 2009-04-03 09:45:23
|
Hi, I have an issue with libtool, when trying to compile ecell from source: make[3]: Entering directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' /bin/sh ./libtool --tag=CC --mode=compile i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -c -o ltdl.lo ltdl.c ./libtool: line 466: CDPATH: command not found ./libtool: line 1144: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. make[3]: *** [ltdl.lo] Error 63 make[3]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell/libltdl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/zeb/svn/ecell/BUILD/ecell' make: *** [all] Error 2 Is it possible to update ecell to latest libtool for compatibility? Thanks a lot. Eric |
|
From: Moriyoshi K. <mo...@sf...> - 2008-12-11 16:53:15
|
Could you send me the config.log in ecell/ directory? You can reach me on #ecell at irc.freenode.net. Thanks. -- moriyoshi On Fri, Dec 12, 2008 at 1:45 AM, Eric Fernandez <efe...@ph...> wrote: > Hi, > > Well, thanks for the tip. Just tried it. > > However, I get the same problem than reported early: > > checking for Boost.Python runtime library avaiability... no > configure: error: could not find Boost.Python library > configure: error: ./configure failed for ecell > error: Bad exit status from > /home/eric/svn/ecell/BUILDROOT/rpm-tmp.hsyK0S (%build) > > Note this is a rpm build, not a direct ./configure && make, but that > should be the same. > Boost Python has been entirely redesigned, could it be the problem ? > > Eric > >> -----Original Message----- >> From: mor...@gm... [mailto:mor...@gm...] On >> Behalf Of Moriyoshi Koizumi >> Sent: 11 December 2008 16:38 >> To: Eric Fernandez >> Cc: ece...@li... >> Subject: Re: [Ecell-devel] Boost Python issue & future of >> e-cell?[Scanned] >> >> Checking out can be done through http as well. >> >> svn checkout >> http://ecell.svn.sourceforge.net/svnroot/ecell/ecell3/branches >> /ecell-3.1 >> ecell-3.1 >> >> You can update to the latest revision by doing svn update in the tree >> (ecell-3.1 for the example above) >> >> Hope this works. >> >> -- moriyoshi >> > |
|
From: Eric F. <efe...@ph...> - 2008-12-11 16:42:49
|
Hi, Well, thanks for the tip. Just tried it. However, I get the same problem than reported early: checking for Boost.Python runtime library avaiability... no configure: error: could not find Boost.Python library configure: error: ./configure failed for ecell error: Bad exit status from /home/eric/svn/ecell/BUILDROOT/rpm-tmp.hsyK0S (%build) Note this is a rpm build, not a direct ./configure && make, but that should be the same. Boost Python has been entirely redesigned, could it be the problem ? Eric > -----Original Message----- > From: mor...@gm... [mailto:mor...@gm...] On > Behalf Of Moriyoshi Koizumi > Sent: 11 December 2008 16:38 > To: Eric Fernandez > Cc: ece...@li... > Subject: Re: [Ecell-devel] Boost Python issue & future of > e-cell?[Scanned] > > Checking out can be done through http as well. > > svn checkout > http://ecell.svn.sourceforge.net/svnroot/ecell/ecell3/branches > /ecell-3.1 > ecell-3.1 > > You can update to the latest revision by doing svn update in the tree > (ecell-3.1 for the example above) > > Hope this works. > > -- moriyoshi > |
|
From: Moriyoshi K. <mo...@sf...> - 2008-12-11 16:38:34
|
Checking out can be done through http as well. svn checkout http://ecell.svn.sourceforge.net/svnroot/ecell/ecell3/branches/ecell-3.1 ecell-3.1 You can update to the latest revision by doing svn update in the tree (ecell-3.1 for the example above) Hope this works. -- moriyoshi On Fri, Dec 12, 2008 at 1:29 AM, Eric Fernandez <efe...@ph...> wrote: > Hi, > > Thanks for your answer. > I am not entriely familiar with svn, especially to checkout a specific > branch. Is it the same syntax than cvs ? > > To be on the safe side, can you confirm this is correct: > svn export > https://svn.sourceforge.net/svnroot/ecell/ecell3/branches/ecell-3.1 > ecell-3.1 > > Kind regards, > Eric > >> -----Original Message----- >> From: mor...@gm... [mailto:mor...@gm...] On >> Behalf Of Moriyoshi Koizumi >> Sent: 11 December 2008 16:00 >> To: Eric Fernandez >> Cc: ece...@li... >> Subject: Re: [Ecell-devel] Boost Python issue & future of >> e-cell?[Scanned] >> >> Hi Eric, >> >> I guess you tried trunk. Unfortunately it's broken at the >> moment, and the working branch is ecell-3.1. >> >> Yes, it's still activlely maintained. (mostly by me) >> >> Regards, >> Moriyoshi >> >> -- moriyoshi > |
|
From: Eric F. <efe...@ph...> - 2008-12-11 16:27:05
|
Hi, Thanks for your answer. I am not entriely familiar with svn, especially to checkout a specific branch. Is it the same syntax than cvs ? To be on the safe side, can you confirm this is correct: svn export https://svn.sourceforge.net/svnroot/ecell/ecell3/branches/ecell-3.1 ecell-3.1 Kind regards, Eric > -----Original Message----- > From: mor...@gm... [mailto:mor...@gm...] On > Behalf Of Moriyoshi Koizumi > Sent: 11 December 2008 16:00 > To: Eric Fernandez > Cc: ece...@li... > Subject: Re: [Ecell-devel] Boost Python issue & future of > e-cell?[Scanned] > > Hi Eric, > > I guess you tried trunk. Unfortunately it's broken at the > moment, and the working branch is ecell-3.1. > > Yes, it's still activlely maintained. (mostly by me) > > Regards, > Moriyoshi > > -- moriyoshi |
|
From: Moriyoshi K. <mo...@sf...> - 2008-12-11 16:04:32
|
Hi Eric, I guess you tried trunk. Unfortunately it's broken at the moment, and the working branch is ecell-3.1. Yes, it's still activlely maintained. (mostly by me) Regards, Moriyoshi -- moriyoshi On Thu, Dec 11, 2008 at 6:22 PM, Eric Fernandez <efe...@ph...> wrote: > Hi, > > I have been maintaining the rpm package for Mandriva Linux for several > years now, and have now been put under pressure to make it work for the > development version (cooker) :) The issues I have are probably valid for > Fedora and other distros. > > I get this building error during the configure: > > checking for Boost.Python runtime library avaiability... no > configure: error: could not find Boost.Python library > configure: error: ./configure failed for ecell > > Allegedly this is because E-cell is not compatible with the new major > version of Boost. Can someone have a look at it? > > At the same time, is e-cell still maintained? What is the current status > ? > > Thanks a lot > Eric > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > |
|
From: Eric F. <efe...@ph...> - 2008-12-11 09:19:44
|
Hi, I have been maintaining the rpm package for Mandriva Linux for several years now, and have now been put under pressure to make it work for the development version (cooker) :) The issues I have are probably valid for Fedora and other distros. I get this building error during the configure: checking for Boost.Python runtime library avaiability... no configure: error: could not find Boost.Python library configure: error: ./configure failed for ecell Allegedly this is because E-cell is not compatible with the new major version of Boost. Can someone have a look at it? At the same time, is e-cell still maintained? What is the current status ? Thanks a lot Eric |
|
From: jitesh d. <jit...@gm...> - 2008-10-19 16:25:16
|
Hi Friends, My name is jitesh dundas, a researcher/software engineer. I wanted to know how can I modify or use the software( i have installed a copy on my PC) to do the following. 1) I wanted to know if I can modify the cell structure to get a damaged cell structure prototype and work towards getting a solution to repairing it. 2) I wanted to know if we are considering the external features that impact the cell structure and behavior in our project. What abt enzymes actions and external bodies. I hope anyone can tell me if any work is needed to be done on this project. I have a few ideas if one of you experts can help me to by reviewing it or giving me some guidance. Regards, Jitesh Dundas http://jiteshbdundas.blogspot.com |
|
From: Moriyoshi K. <mo...@sf...> - 2008-10-19 09:55:58
|
Hi, I really dislike this class name because of the wording that can imply the different concept (partly because I'm not well off :) What about changing it to EcellObject or EcsObject (or more simply, Object) and typedef it as PropertiedClass for BC? -- moriyoshi |
|
From: Moriyoshi K. <mo...@sf...> - 2008-02-28 15:17:44
|
Hi there, I suppose everyone has been thinking of commonizing ExpressionCompiler (plus VirtualMachine indeed) instead of just burying within the dm directory, because it is quite handy as proven by ExpressionFluxProcess and ExperssionAssignmentProcess. And I think the best timing to incorporate it in the libecs API would be the release of E-Cell 3.2. I am planning to introduce libecs::scripting namespace and move the following involved files to ecell/libecs/scripting: * ExpressionCompiler.hpp * ExpressionCompiler.cpp * VirtualMachine.cpp * VirtualMachine.hpp * Instruction.hpp What do you think of this? -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Moriyoshi K. <mo...@sf...> - 2008-02-26 13:09:03
|
Hello there, The list policy setting that controls which address to be filled in the "Reply-To" header of the delivered mail has been changed to "poster." where it was previously "list address." because the former setting is really unfamiliar outside Japan. Regards, Moriyoshi -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Moriyoshi K. <mo...@sf...> - 2008-02-25 12:23:34
|
Hi Bernhard, Thank you for contacting us. Recently we've been focusing on the distribution of handy packages to encourage first-timers to try the software, so your effort would definitely be appreciated. If you have any questions on the build system, feel free to ask us on this list. Regards, Moriyoshi 2008/2/25, Bernhard Kraft <kr...@kr...>: > Hallo, > > My name is Bernhard Kraft and I study biology/molecular biology at the > university > of Vienna. I got interested in using or probably even help developing ecell. > > For a start I created an ebuild of the most recent e-cell version for > the Gentoo > Linux distribution (www.gentoo.org) ... > > i created this ebuild by already previously created ebuilds - and just > updating the > version: > > http://bugs.gentoo.org/show_bug.cgi?id=27075 > > If it is ok for you I could ask the gentoo package team to put e-cell > into the gentoo > portage tree (like the apt-archives of debian/ubuntu) - and take care of > updating it > to recent versions. > > > > greets, > Bernhard > -- > Freiheit ist immer Freiheit des Andersdenkenden. > Rosa Luxemburg, 1871-1919 > -------------------------------------------------- > www.think-open.at > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Bernhard K. <kr...@kr...> - 2008-02-25 03:04:41
|
Hallo, My name is Bernhard Kraft and I study biology/molecular biology at the university of Vienna. I got interested in using or probably even help developing ecell. For a start I created an ebuild of the most recent e-cell version for the Gentoo Linux distribution (www.gentoo.org) ... i created this ebuild by already previously created ebuilds - and just updating the version: http://bugs.gentoo.org/show_bug.cgi?id=27075 If it is ok for you I could ask the gentoo package team to put e-cell into the gentoo portage tree (like the apt-archives of debian/ubuntu) - and take care of updating it to recent versions. greets, Bernhard -- Freiheit ist immer Freiheit des Andersdenkenden. Rosa Luxemburg, 1871-1919 -------------------------------------------------- www.think-open.at |
|
From: Moriyoshi K. <mo...@sf...> - 2008-02-24 19:20:26
|
Before entering the discussion, what do you think of boost::numeric::ublas? Should we stick to boost::multi_array anyway? As far as I know, boost::multi_array_ref doesn't provide an interface enough flexible to create a PyArray wrapper in the sense that the constructor doesn't accept the list of strides. Moriyoshi 2008/2/23, Koichi Takahashi <sh...@e-...>: > > i was wondering if the draft python array interface > can be of any help for us, at least in its concept. > i hope this will become an accepted PEP as soon as possible. > > http://numpy.scipy.org/array_interface.shtml > linked from here > http://numpy.scipy.org/ > > > nathan has been trying to use boost multi_array as an > underlying data structure behind the new Array class for > ecell4. however, one discrepancy is that in numpy, > the shape (thus its number of dimensions) of an array > is dynamics, whilst multi_array has a statically > defined # dimensions at compile time. this is not > a big problem when passing an array from C++ to Python, > but it indeed is when creating an array of user-specified, > arbitrary shape from the python side and instantiate it > on the C++ side. > > one strategy to cope with the difference is to prepare > all possible template specializations, like > <Real,1>, <Real,2> ... <Real,9> with some upper limit in > dimensions. We can write a wrapper > for this so that it looks like a dynamically shaped array > from the Python side. > > when doing so, it is important that we define an interface abstract > class as a common array interface to be used throughout all portaions > of ecell4 libecs and dynamic modules. the multiple specialized > multi_array classes could be used in a subclass extending this > interface in the initial version. in future, when we get a > full implementation of a true dynamically shaped multi array, > we can exchange the implementation with a minimum effort. > we could even use the C-API of numpy.array to implement this. > > > koichi > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Koichi T. <sh...@e-...> - 2008-02-23 02:49:12
|
i was wondering if the draft python array interface can be of any help for us, at least in its concept. i hope this will become an accepted PEP as soon as possible. http://numpy.scipy.org/array_interface.shtml linked from here http://numpy.scipy.org/ nathan has been trying to use boost multi_array as an underlying data structure behind the new Array class for ecell4. however, one discrepancy is that in numpy, the shape (thus its number of dimensions) of an array is dynamics, whilst multi_array has a statically defined # dimensions at compile time. this is not a big problem when passing an array from C++ to Python, but it indeed is when creating an array of user-specified, arbitrary shape from the python side and instantiate it on the C++ side. one strategy to cope with the difference is to prepare all possible template specializations, like <Real,1>, <Real,2> ... <Real,9> with some upper limit in dimensions. We can write a wrapper for this so that it looks like a dynamically shaped array from the Python side. when doing so, it is important that we define an interface abstract class as a common array interface to be used throughout all portaions of ecell4 libecs and dynamic modules. the multiple specialized multi_array classes could be used in a subclass extending this interface in the initial version. in future, when we get a full implementation of a true dynamically shaped multi array, we can exchange the implementation with a minimum effort. we could even use the C-API of numpy.array to implement this. koichi |
|
From: Gobind S. <gob...@ya...> - 2008-02-22 16:48:17
|
Hello, figured it out... thanks however for the reply required additional repository in source.list Sorry for posting to the wrong place Moriyoshi Koizumi <mo...@sf...> wrote: Hi, Guessing you have just upgraded your Ubuntu, did you ever try to reinstall ecell as well? Since Gutsy no longer provides boost-1.33.1, you need to use the package specifically created for that release. And in case you used the RC1 packages on sourceforge.net, please have a look at the following page: http://e-cell.org/ecell/software/downloads P.S. this lis is for discussions about the development of E-Cell, so user questions are better to post at ece...@li.... Regards, Moriyoshi 2008/2/21, Gobind Singh : > Hello, > > I was directed to you from the IRC channel. > > I have Ubuntu gutsy, but it will not run do to a problem with > libboost-python. > > ImportError: libboost_python-gcc-mt-1_33_1.so.1.33.1: > cannot open shared object file: No such file or directory > > I have libboost_python-gcc-mt-1_34_1.so.1.34.1. I was > previously able to run e-cell on feisty without problem. > > Are you familiar with this problem? It has affected both computers that I > use with ecell and were updated to gutsy. > > Thankyou > > > ________________________________ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > > -- Moriyoshi Koizumi (also reachable on ) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ecell-devel mailing list Ece...@li... https://lists.sourceforge.net/lists/listinfo/ecell-devel --------------------------------- Never miss a thing. Make Yahoo your homepage. |
|
From: Moriyoshi K. <mo...@sf...> - 2008-02-21 05:48:40
|
Hi, Guessing you have just upgraded your Ubuntu, did you ever try to reinstall ecell as well? Since Gutsy no longer provides boost-1.33.1, you need to use the package specifically created for that release. And in case you used the RC1 packages on sourceforge.net, please have a look at the following page: http://e-cell.org/ecell/software/downloads P.S. this lis is for discussions about the development of E-Cell, so user questions are better to post at ece...@li.... Regards, Moriyoshi 2008/2/21, Gobind Singh <gob...@ya...>: > Hello, > > I was directed to you from the IRC channel. > > I have Ubuntu gutsy, but it will not run do to a problem with > libboost-python. > > ImportError: libboost_python-gcc-mt-1_33_1.so.1.33.1: > cannot open shared object file: No such file or directory > > I have libboost_python-gcc-mt-1_34_1.so.1.34.1. I was > previously able to run e-cell on feisty without problem. > > Are you familiar with this problem? It has affected both computers that I > use with ecell and were updated to gutsy. > > Thankyou > > > ________________________________ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ecell-devel mailing list > Ece...@li... > https://lists.sourceforge.net/lists/listinfo/ecell-devel > > -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Gobind S. <gob...@ya...> - 2008-02-21 04:33:39
|
Hello,
I was directed to you from the IRC channel.
I have Ubuntu gutsy, but it will not run do to a problem with libboost-python.
ImportError: libboost_python-gcc-mt-1_33_1.so.1.33.1: cannot open shared object file: No such file or directory
I have libboost_python-gcc-mt-1_34_1.so.1.34.1. I was previously able to run e-cell on feisty without problem.
Are you familiar with this problem? It has affected both computers that I use with ecell and were updated to gutsy.
Thankyou
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
|
From: Moriyoshi K. <mo...@sf...> - 2007-12-24 02:46:55
|
Hi all, The E-Cell developers are proud to annouce the second release candidate of the upcoming release, 3.1.106. A few bugs were fixed for better compatibility with older systems like rhel5. We are not going to place binary packages this time, as now we have set up the repository that can be directly specified in the configuration files of your package manager (wow!) Instructions for the packages are explained in a separate page: http://dev.e-cell.org/wiki/ecell3/install/packages Hope you will enjoy them and wish your merry christmas! Changelog: * Avoided resetting LD_LIBRARY_PATH in ecell-python for the sake of inter-platform operability. This was also problematic in combination with multiple ldconfig paths. (Moriyoshi) * Fixed sample installation rule so that samples would get installed in sample-per-directory manner. (Moriyoshi) * Fixed configure scripts for dmtool and dynamic modules so that modules they produce would have right extensions that follows the libltdl's convention. (Moriyoshi) -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Moriyoshi K. <mo...@sf...> - 2007-08-20 17:30:11
|
http://geocanvas.sourceforge.net/ This simply rocks. Native widgets, fast, accompanied by a python binding and well-maintained (with a handful of unit tests). Definetely worth a try. -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Moriyoshi K. <mo...@sf...> - 2007-08-08 08:42:49
|
Hi all, I uploaded the brief outline for the presentation I did in the meeting on August 3 in SFC. Check out the page below: http://ecell.sourceforge.net/wiki/meetings/2007/8/Resources/ConceptualEntities The proposed features are under planning. Any comments are welcome. Regards, Moriyoshi -- Moriyoshi Koizumi <mor...@gm...> (also reachable on <mo...@sf...>) |
|
From: Moriyoshi K. <mo...@sf...> - 2007-07-26 03:16:17
|
2007/7/25, Koichi Takahashi <sh...@sf...>:
>
> No, sorry, that RTTI doesn't work across shared objects was simply
> new to me and I really meant it.
>
> I did actually read through your message. It seems
> we are having some communication problem again. Should be
> talk on the phone again? I might be offline for the next
> 48 hours or so but will arrive in Japan by then.
I don't think we have such a major problem now. if you think what I
have written is just awkward and uncomprehensive, please ask me. I
think you and me should make things transparent to other folks from
now on.
> For the meantime, can we start with the following?
> Without a reasonable agreement on such a fundamental thing like
> this we cannot go anywhere.
> >>>> - A class name is the class name.
> >>>> - A base class is the base class of the class in C++
> >>>> class hierarchy.
> >>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
> >>>> the class with which we specialized the ModuleMaker.
> >>> Even sounds confusing :)
I thought we are already on the same line in this. Wasn't it?
> >>> Again, how can it be done by RTTI which doesn't portably provide a
> >>> reasonable interface to determine the relevancy of given two types?
> >>> All we can do with the standard RTTI is check the identity of any two.
>
> That is true C++ typeinfo can do only identify checks and partial
> ordering. However, it boils down that what we need in DMTool is
> just a downcast, which is provided in ISO C++ as dynamic_cast.
> We can use boost::polymorphic_cast to make use of this cleanly.
> Pre-instantiation type check would be nice but as I wrote I don't
> think it is not absolutely necessary.
As I mentioned already, dynamic_cast only works with *instances*, not
the types in the place we have to know the relationships of any
dynamic modules in prior to actually create them. The reason we need
it is 1. the instantiation may cost too much 2. we are not always
supposed to instantiate.
> >>> The problem is that we designated two different tasks to ModuleMaker;
> >>> it is a module loader and an instantiator at the same time, where we
> >>> only expect the latter to be type-safe.
>
> I think I understand what you mean. Let's talk about this on the
> phone or in person later.
The fix won't be in E-Cell 3. Isn't that okay for you?
> >>> What do you think is intrusive here? I don't think it is because it
> >>> doesn't break any binary compatibility nor source-level backwards
> >>> compatibility.
>
> This is related to the point I raised repeatedly as to the relationship
> between the class itself and the DM mechanism that makes the class a DM.
> By intrusive I meant that if getTypeName() method is defined as a static
> member it forces the class to *know* the DM base class. Conceptually,
> the dependency between the class and the DM framework
> should be unidirectional, from the latter to the former.
> To keep the design clean we have to make sure the class doesn't know
> anything about the DM framework. I know the current implementation
> is not as clean as it should be but if we are putting additional
> efforts on it we should go this way.
What makes it odd is that DM is already designed to have information
about DM base classes (read: don't blame me for it :p). I think it's
rather unclean and to be addressed in the E-Cell 4, however it doesn't
have the problem like you pointed out, because DM objects are provided
createInstance() methods that are supposed to return the instances of
DM base class. Merely adding an accessor to meta information that is
crucially bound to the behavior
(I mean instantiation of object) of the class itself is not an
intrusive change in my opinion.
> >>> Practically such convention won't do well. Once the rule is broken, we
> >>> will have to be in for a mysterious bug because of unsafe type
> >>> conversion.
>
> If the rule is broken nothing works reliably. When we know there
> can be exceptions, it is called exception handling. When the
> specification prohibits exceptions, what we implement is called
> a bug catcher.
What I wrote here was not based on the assumption that we would use
dynamic casts, but we would handle dynamically loaded types by our
own. Before entering this paragraph, I already mentioned such casts
aren't usable here.
> >>> Eitherway, we cannot use dynamic cast s here, that are not as
> >>> reliable when it comes to shared object. Some platforms may provide
> >>> type safety across different objects (including .so's), but others
> >>> don't.
>
> Right. That is why I asked the previous question. It seems to me
> any decent implementations of C++ RTTI would work but if it is
> not in the ISO C++ spec and if there are important exceptions
> (older VCs?) we need to give it a deeper thought.
It is obvious handling dynamically loaded types within RTTI is
logically impossible because types are not versioned which leads into
an inconsistent situation where the application process already has a
type and the loaded module has one that has exactly the same name and
same set of methods with the same signiture, but the ancestors of
these two classes are different. Otherwise, there'd be too much
elaborated extensions in each RTTI implementation, which I haven't
heard of.
Moriyoshi
> Some DM classes use dynamic_cast internally across shared objects.
> If it can fail in some platforms we will need to rewrite them.
>
>
> koichi
>
>
>
> > Hmm.. was there anything that helped you to doubt me? That totally
> > depends on the implementation. The standards don't specify it, period.
> > I understand you have very limited time right now, but please look
> > through what I wrote in the previous mails to save the time.
> >
> > Moriyoshi
> >
> > 2007/7/25, Koichi Takahashi <sh...@sf...>:
> >> Is it true that C++ RTTI doesn't support dynamically loaded
> >> types?
> >>
> >>
> >>>> Ok let us first define the terminology;
> >>>>
> >>>> - A class name is the class name.
> >>>> - A base class is the base class of the class in C++
> >>>> class hierarchy.
> >>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
> >>>> the class with which we specialized the ModuleMaker.
> >>> Even sounds confusing :)
> >>>
> >>>> You are right that the DM base of a class is not always the same
> >>>> as the C++ base class. However, it belogs to the C++ type system
> >>>> in the sense that a DM instance is always a subclass of its DM base
> >>>> class, either direct or indirect.
> >>>> For this reason, theoretically, it should be possible to implement
> >>>> it with the standard C++ RTTI. Practically it might not be
> >>>> straightforward but let us see how it goes for the moment.
> >>> Again, how can it be done by RTTI which doesn't portably provide a
> >>> reasonable interface to determine the relevancy of given two types?
> >>> All we can do with the standard RTTI is check the identity of any two.
> >>> Neither does it support dynamically loaded types.
> >>>
> >>>> So,
> >>>>
> >>>> 1. I think providing a way to access the __DM_TYPE symbol should be ok.
> >>>> Adding ModuleMaker::getTypeName() should be ok.
> >>>> We could give these better names, maybe?
> >>>> __DM_BASE_NAME and getDMBaseName() or something?
> >>> I agree that the name __DM_TYPE is confusing. However we don't need to
> >>> change it in the E-Cell 3 branch otherwise it breaks ABI
> >>> compatibility. We have to take care of users who have a plenty of
> >>> precompiled DM's.
> >>>
> >>>> One drawback of this scheme is that if we rely on it
> >>>> we cannot make a DM that can be instantiated by different
> >>>> ModuleMakers. For example, we might want to load SpecialFooClass
> >>>> from ModuleMaker<Class> and ModuleMaker<FooClass>. This is
> >>>> possible in standard C++ RTTI but is problematic when we strictly
> >>>> check the __DM_TYPE thing when we instantiate it.
> >>> The problem is that we designated two different tasks to ModuleMaker;
> >>> it is a module loader and an instantiator at the same time, where we
> >>> only expect the latter to be type-safe.
> >>>
> >>>> 2. I don't think the last line in this macro is a good idea.
> >>>>
> >>>> #define DM_OBJECT( CLASSNAME, TYPE )\
> >>>> - static TYPE* createInstance() { return new CLASSNAME ; }
> >>>> + static TYPE* createInstance() { return new CLASSNAME ; }\
> >>>> + static const char *getTypeName() { return #TYPE; }
> >>>>
> >>>> Let us keep it non-intrusive as much as possible.
> >>>>
> >>> What do you think is intrusive here? I don't think it is because it
> >>> doesn't break any binary compatibility nor source-level backwards
> >>> compatibility.
> >>>
> >>>> 3.
> >>>>
> >>>> This
> >>>>
> >>>> Process* ProcessMaker::make( const std::string& aClassName )
> >>>>
> >>>> looks straightforward to write more concisely with dynamic_cast.
> >>>> Here you can basically assume the class the DM .so contains is
> >>>> a legitimate DM class that derives from the DM base class because
> >>>> the DM compilation mechanism that names the classes and .so filenames
> >>>> consistently takes care of it.
> >>> Practically such convention won't do well. Once the rule is broken, we
> >>> will have to be in for a mysterious bug because of unsafe type
> >>> conversion. Eitherway, we cannot use dynamic cast s here, that are not as
> >>> reliable when it comes to shared object. Some platforms may provide
> >>> type safety across different objects (including .so's), but others
> >>> don't.
> >>>
> >>> Moriyoshi
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems? Stop.
> >> Now Search log events and configuration files using AJAX and a browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> _______________________________________________
> >> Ecell-devel mailing list
> >> Ece...@li...
> >> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
--
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)
|
|
From: Koichi T. <sh...@sf...> - 2007-07-25 11:43:49
|
No, sorry, that RTTI doesn't work across shared objects was simply
new to me and I really meant it.
I did actually read through your message. It seems
we are having some communication problem again. Should be
talk on the phone again? I might be offline for the next
48 hours or so but will arrive in Japan by then.
For the meantime, can we start with the following?
Without a reasonable agreement on such a fundamental thing like
this we cannot go anywhere.
>>>> - A class name is the class name.
>>>> - A base class is the base class of the class in C++
>>>> class hierarchy.
>>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
>>>> the class with which we specialized the ModuleMaker.
>>> Even sounds confusing :)
>>> Again, how can it be done by RTTI which doesn't portably provide a
>>> reasonable interface to determine the relevancy of given two types?
>>> All we can do with the standard RTTI is check the identity of any two.
That is true C++ typeinfo can do only identify checks and partial
ordering. However, it boils down that what we need in DMTool is
just a downcast, which is provided in ISO C++ as dynamic_cast.
We can use boost::polymorphic_cast to make use of this cleanly.
Pre-instantiation type check would be nice but as I wrote I don't
think it is not absolutely necessary.
>>> I agree that the name __DM_TYPE is confusing. However we don't need to
>>> change it in the E-Cell 3 branch otherwise it breaks ABI
>>> compatibility. We have to take care of users who have a plenty of
>>> precompiled DM's.
Ok let's think about doing this for ecell4.
>>> The problem is that we designated two different tasks to ModuleMaker;
>>> it is a module loader and an instantiator at the same time, where we
>>> only expect the latter to be type-safe.
I think I understand what you mean. Let's talk about this on the
phone or in person later.
>>> What do you think is intrusive here? I don't think it is because it
>>> doesn't break any binary compatibility nor source-level backwards
>>> compatibility.
This is related to the point I raised repeatedly as to the relationship
between the class itself and the DM mechanism that makes the class a DM.
By intrusive I meant that if getTypeName() method is defined as a static
member it forces the class to *know* the DM base class. Conceptually,
the dependency between the class and the DM framework
should be unidirectional, from the latter to the former.
To keep the design clean we have to make sure the class doesn't know
anything about the DM framework. I know the current implementation
is not as clean as it should be but if we are putting additional
efforts on it we should go this way.
>>> Practically such convention won't do well. Once the rule is broken, we
>>> will have to be in for a mysterious bug because of unsafe type
>>> conversion.
If the rule is broken nothing works reliably. When we know there
can be exceptions, it is called exception handling. When the
specification prohibits exceptions, what we implement is called
a bug catcher.
Once the rule is broken, we will have to handle a mysterious bug because
of unsafe type conversion. The best way here is not to do unsafe type
conversion. IF we can use dynamic_cast here that makes use of RTTI,
we avoid a unsafe type conversion by not relying on DM_TYPE field
and therefore we can avoid one possible niche of a mysterious bug.
>>> Eitherway, we cannot use dynamic cast s here, that are not as
>>> reliable when it comes to shared object. Some platforms may provide
>>> type safety across different objects (including .so's), but others
>>> don't.
Right. That is why I asked the previous question. It seems to me
any decent implementations of C++ RTTI would work but if it is
not in the ISO C++ spec and if there are important exceptions
(older VCs?) we need to give it a deeper thought.
Some DM classes use dynamic_cast internally across shared objects.
If it can fail in some platforms we will need to rewrite them.
koichi
> Hmm.. was there anything that helped you to doubt me? That totally
> depends on the implementation. The standards don't specify it, period.
> I understand you have very limited time right now, but please look
> through what I wrote in the previous mails to save the time.
>
> Moriyoshi
>
> 2007/7/25, Koichi Takahashi <sh...@sf...>:
>> Is it true that C++ RTTI doesn't support dynamically loaded
>> types?
>>
>>
>>>> Ok let us first define the terminology;
>>>>
>>>> - A class name is the class name.
>>>> - A base class is the base class of the class in C++
>>>> class hierarchy.
>>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
>>>> the class with which we specialized the ModuleMaker.
>>> Even sounds confusing :)
>>>
>>>> You are right that the DM base of a class is not always the same
>>>> as the C++ base class. However, it belogs to the C++ type system
>>>> in the sense that a DM instance is always a subclass of its DM base
>>>> class, either direct or indirect.
>>>> For this reason, theoretically, it should be possible to implement
>>>> it with the standard C++ RTTI. Practically it might not be
>>>> straightforward but let us see how it goes for the moment.
>>> Again, how can it be done by RTTI which doesn't portably provide a
>>> reasonable interface to determine the relevancy of given two types?
>>> All we can do with the standard RTTI is check the identity of any two.
>>> Neither does it support dynamically loaded types.
>>>
>>>> So,
>>>>
>>>> 1. I think providing a way to access the __DM_TYPE symbol should be ok.
>>>> Adding ModuleMaker::getTypeName() should be ok.
>>>> We could give these better names, maybe?
>>>> __DM_BASE_NAME and getDMBaseName() or something?
>>> I agree that the name __DM_TYPE is confusing. However we don't need to
>>> change it in the E-Cell 3 branch otherwise it breaks ABI
>>> compatibility. We have to take care of users who have a plenty of
>>> precompiled DM's.
>>>
>>>> One drawback of this scheme is that if we rely on it
>>>> we cannot make a DM that can be instantiated by different
>>>> ModuleMakers. For example, we might want to load SpecialFooClass
>>>> from ModuleMaker<Class> and ModuleMaker<FooClass>. This is
>>>> possible in standard C++ RTTI but is problematic when we strictly
>>>> check the __DM_TYPE thing when we instantiate it.
>>> The problem is that we designated two different tasks to ModuleMaker;
>>> it is a module loader and an instantiator at the same time, where we
>>> only expect the latter to be type-safe.
>>>
>>>> 2. I don't think the last line in this macro is a good idea.
>>>>
>>>> #define DM_OBJECT( CLASSNAME, TYPE )\
>>>> - static TYPE* createInstance() { return new CLASSNAME ; }
>>>> + static TYPE* createInstance() { return new CLASSNAME ; }\
>>>> + static const char *getTypeName() { return #TYPE; }
>>>>
>>>> Let us keep it non-intrusive as much as possible.
>>>>
>>> What do you think is intrusive here? I don't think it is because it
>>> doesn't break any binary compatibility nor source-level backwards
>>> compatibility.
>>>
>>>> 3.
>>>>
>>>> This
>>>>
>>>> Process* ProcessMaker::make( const std::string& aClassName )
>>>>
>>>> looks straightforward to write more concisely with dynamic_cast.
>>>> Here you can basically assume the class the DM .so contains is
>>>> a legitimate DM class that derives from the DM base class because
>>>> the DM compilation mechanism that names the classes and .so filenames
>>>> consistently takes care of it.
>>> Practically such convention won't do well. Once the rule is broken, we
>>> will have to be in for a mysterious bug because of unsafe type
>>> conversion. Eitherway, we cannot use dynamic cast s here, that are not as
>>> reliable when it comes to shared object. Some platforms may provide
>>> type safety across different objects (including .so's), but others
>>> don't.
>>>
>>> Moriyoshi
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Ecell-devel mailing list
>> Ece...@li...
>> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
>
>
|
31 messages has been excluded from this view by a project administrator.
