ecell-devel Mailing List for E-Cell System

I've got only approval from people.  I'll start this migration
within 24 hours from now, and post a message again when everything
is set.    Meanwhile, please refrain from write-accessing ecell cvs/svn
services on sourceforge.net.


Koichi


> Hi,
> 
> Sourceforge.net seems to have started a Subversion hosting.
> I'd like to migrate current E-Cell CVS to Subversion, as
> it is a better alternative.
> 
> I currently plan to start the migration process on this Sat
> (pacific time, Sunday JST).   This is going to take up to 24 hours
> (Monday, JST), but most likely within a couple hours.
> 
> There's no reason to hurry, if you have any reason to prefer a different
> schedule, please let me know.   Most common of such would be
> that you have an outstanding, uncommitted modification to your
> cvs checkout that cannot be finished within a day or two.
> 
> 
> Koichi
> 
> 
> -------------------------------------------------------
> 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

桜の花と恋の開花情報
http://zailing.com/too/
問）
faf...@16...

Hi,

Sourceforge.net seems to have started a Subversion hosting.
I'd like to migrate current E-Cell CVS to Subversion, as
it is a better alternative.

I currently plan to start the migration process on this Sat
(pacific time, Sunday JST).   This is going to take up to 24 hours
(Monday, JST), but most likely within a couple hours.

There's no reason to hurry, if you have any reason to prefer a different
schedule, please let me know.   Most common of such would be
that you have an outstanding, uncommitted modification to your
cvs checkout that cannot be finished within a day or two.


Koichi

That means, we are ready to resume putting out binary rpms
again (fc5/rhel4), upon completion of the gecell bug fix
and some testing.

Zak, are you still a release manager?

sha


> (1)
> 
> Fedora core Linux 5 has been around since Monday.
> It seems ecell3 works nicely again with its gcc-4.1.
> The show-stopper gcc-4.0 bug is gone.
> 
> However, I've got an error from gecell.  It used to
> work.  Who touched it last?
> 

Hi,

(1)

Fedora core Linux 5 has been around since Monday.
It seems ecell3 works nicely again with its gcc-4.1.
The show-stopper gcc-4.0 bug is gone.

However, I've got an error from gecell.  It used to
work.  Who touched it last?


(2)

Last night I've spent forty minutes to build ecell3 on my
new x86_64 workstation.   No change in sourcecode was
necessary (thanks to our past efforts on DEC Alpha),
but I modified configure.in/Makefiles.am kind of stuff.
Redhat/Fedora-x86_64 are now multi-lib, 32bit libs under
/usr/lib, and 64bit versions in /usr/lib64.   I removed
some hardcoded '/usr/lib'.

CVS already has this patch.  Please check if it doesn't break
anything on your environment.

I also removed --boost-root-dir configure option.   It now
treats boost as a regular library installed according to
the FHS standard.


-sha

Dear Koichi,

>>- I think it was Apache mailing list where I read about
>>   some rumor about the VC++ support, but I'm not sure.
>>   You can ask on libtool ML.
>
>  I see. I'm going to ask on libtool ML on a parallel with the searching.
>  I keep you up to date.

  I find the topic in the libtool ML for "Libtool support for MSVC is not done yet".
    http://lists.gnu.org/archive/html/libtool/2006-03/msg00009.html
  So, I think using the "#ifdef (_MSC_VER)" in point.
  If you have any comments, please let me know.

Best Regards,

Takeshi YUASA

>Dear Koichi,
>
>>- Two flags must be given to gcc: -msse2 -mfpmath=sse.
>>   Was this what you tried?
>
>  I have executed the "-msse2 -mfpmath=sse" option on 32 bit machine.
>  As a result, this gcc result is almost equal the vc8.0.
>  So, I have executed on 64 bit
>    and this gcc result is almost equal the vc8.0, too.
>    (see the result in an attached file)
>  I understand the casus is the "32bit" compile.
>
>  I appliciate your pointed advice.
>
>>- I think it was Apache mailing list where I read about
>>   some rumor about the VC++ support, but I'm not sure.
>>   You can ask on libtool ML.
>
>  I see. I'm going to ask on libtool ML on a parallel with the searching.
>  I keep you up to date.
>
>Best Regards,
>
>Takeshi YUASA
>>
>>- Two flags must be given to gcc: -msse2 -mfpmath=sse.
>>   Was this what you tried?
>>
>>- I think it was Apache mailing list where I read about
>>   some rumor about the VC++ support, but I'm not sure.
>>   You can ask on libtool ML.
>>
>>   libltdl.c has the following code, which appears to be
>>   for Windows.  This may be Cygwin/Mingw specific, or
>>   maybe more generic.   I guess if it is properly configured
>>   it should run on VC, but you may need to run autoconf
>>   to do so.
>>
>>/* --- LOADLIBRARY() INTERFACE LOADER --- */
>>
>>#ifdef __WINDOWS__
>>
>>...
>>
>>   module = LoadLibrary (searchname);
>>
>>
>>
>>Koichi
>>
>>
>>
>>> Dear Koichi,
>>> 
>>>   I appreciate your many useful advices.
>>> 
>>> 
>>>>  Was the gcc version compiled without -fpmath=sse ?
>>>>  If so, my guess is that this difference can be
>>>>  explained by the FP units used (80bit-long x87 or IEEE 64bit sse2).
>>> 
>>> 
>>>   I'm preparing a 64bit machine.
>>>   So I've tried executing the gcc version
>>>     which was compiled with "-mfpmath=387" on a 32bit one.
>>>   The result have not been changed as expected.
>>> 
>>> 
>>>>  Eventually these platform dependence
>>>>  should be absorbed by GNU libtool, and I've read somewhere
>>>>  that they are currently working on such VC++ support.
>>> 
>>> 
>>>   I'm searching the site which is right on target.
>>>   But I still cannot.
>>>   Please let me know if you can find it.

Dear Koichi,

>- Two flags must be given to gcc: -msse2 -mfpmath=sse.
>   Was this what you tried?

  I have executed the "-msse2 -mfpmath=sse" option on 32 bit machine.
  As a result, this gcc result is almost equal the vc8.0.
  So, I have executed on 64 bit
    and this gcc result is almost equal the vc8.0, too.
    (see the result in an attached file)
  I understand the casus is the "32bit" compile.

  I appliciate your pointed advice.

>- I think it was Apache mailing list where I read about
>   some rumor about the VC++ support, but I'm not sure.
>   You can ask on libtool ML.

  I see. I'm going to ask on libtool ML on a parallel with the searching.
  I keep you up to date.

Best Regards,

Takeshi YUASA
>
>- Two flags must be given to gcc: -msse2 -mfpmath=sse.
>   Was this what you tried?
>
>- I think it was Apache mailing list where I read about
>   some rumor about the VC++ support, but I'm not sure.
>   You can ask on libtool ML.
>
>   libltdl.c has the following code, which appears to be
>   for Windows.  This may be Cygwin/Mingw specific, or
>   maybe more generic.   I guess if it is properly configured
>   it should run on VC, but you may need to run autoconf
>   to do so.
>
>/* --- LOADLIBRARY() INTERFACE LOADER --- */
>
>#ifdef __WINDOWS__
>
>...
>
>   module = LoadLibrary (searchname);
>
>
>
>Koichi
>
>
>
>> Dear Koichi,
>> 
>>   I appreciate your many useful advices.
>> 
>> 
>>>  Was the gcc version compiled without -fpmath=sse ?
>>>  If so, my guess is that this difference can be
>>>  explained by the FP units used (80bit-long x87 or IEEE 64bit sse2).
>> 
>> 
>>   I'm preparing a 64bit machine.
>>   So I've tried executing the gcc version
>>     which was compiled with "-mfpmath=387" on a 32bit one.
>>   The result have not been changed as expected.
>> 
>> 
>>>  Eventually these platform dependence
>>>  should be absorbed by GNU libtool, and I've read somewhere
>>>  that they are currently working on such VC++ support.
>> 
>> 
>>   I'm searching the site which is right on target.
>>   But I still cannot.
>>   Please let me know if you can find it.

- Two flags must be given to gcc: -msse2 -mfpmath=sse.
   Was this what you tried?

- I think it was Apache mailing list where I read about
   some rumor about the VC++ support, but I'm not sure.
   You can ask on libtool ML.

   libltdl.c has the following code, which appears to be
   for Windows.  This may be Cygwin/Mingw specific, or
   maybe more generic.   I guess if it is properly configured
   it should run on VC, but you may need to run autoconf
   to do so.

/* --- LOADLIBRARY() INTERFACE LOADER --- */

#ifdef __WINDOWS__

...

   module = LoadLibrary (searchname);



Koichi



> Dear Koichi,
> 
>   I appreciate your many useful advices.
> 
> 
>>  Was the gcc version compiled without -fpmath=sse ?
>>  If so, my guess is that this difference can be
>>  explained by the FP units used (80bit-long x87 or IEEE 64bit sse2).
> 
> 
>   I'm preparing a 64bit machine.
>   So I've tried executing the gcc version
>     which was compiled with "-mfpmath=387" on a 32bit one.
>   The result have not been changed as expected.
> 
> 
>>  Eventually these platform dependence
>>  should be absorbed by GNU libtool, and I've read somewhere
>>  that they are currently working on such VC++ support.
> 
> 
>   I'm searching the site which is right on target.
>   But I still cannot.
>   Please let me know if you can find it.
> 
> 
> Best Regards,
> 
> Takeshi YUASA
> 
> 
> -------------------------------------------------------
> 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

Dear Koichi,

  I appreciate your many useful advices.

>   Was the gcc version compiled without -fpmath=sse ?
>   If so, my guess is that this difference can be
>   explained by the FP units used (80bit-long x87 or IEEE 64bit sse2).

  I'm preparing a 64bit machine.
  So I've tried executing the gcc version
    which was compiled with "-mfpmath=387" on a 32bit one.
  The result have not been changed as expected.

>   Eventually these platform dependence
>   should be absorbed by GNU libtool, and I've read somewhere
>   that they are currently working on such VC++ support.

  I'm searching the site which is right on target.
  But I still cannot.
  Please let me know if you can find it.


Best Regards,

Takeshi YUASA

Yuasasan,

I've gone through your patch.  Here are some comments:

- First of all, the last thing we would like to see is
   a branching of the sourcecode.  To this end the next
   step for you would be to clean up the patch so that
   a single codebase can be built on all the platforms
   ecell3 currently supports, preferably with GNU autotools as much
   as possible.   My comments below go from this standpoint.

- Two things you did look like including stdafx.h from
   everywhere and adding DllMain functions.
   Eventually these platform dependence
   should be absorbed by GNU libtool, and I've read somewhere
   that they are currently working on such VC++ support.
   For the meantime, can these modifications and VC++-specific
   project files etc. be (1) concentrated/modularized
   into a place or two?  And (2) inclusion of these headers
   should be automatically switched on/off (ideally by autoconf).

- dllimport/export prefixes need to be added for some DM functions.
   Cygwin/MinGW environments look like do this automatically,
   but it seems VC++ doesn't.  I have been actually recognizing
   the advantage of notifying the compiler if it is compiling
   a DM shared library or something else (like the
   main libecs).  Maybe some preprocessor symbols can be #defined?
   We can discuss more.

- MethodProxy:  Yes, it might need some work to make it portable
   while maintaining the speed, and this class is critical
   to get maximum performance from the scheduler and the virtual
   machine embedded in ExpressionProcesses.   I think what you
   did might decrease the speed of simulation at most 15-20%
   in the worst case.

   It is inspired by FastDelegate by Clugston and another approach
   by Ryazanov.

   http://www.codeproject.com/cpp/FastDelegate.asp
   http://www.codeproject.com/cpp/ImpossiblyFastCppDelegate.asp

   I liked Ryazanov's approach slightly more than Clugstons, so
   my implementation reflects that.

   What I would like to emphasize here, though, are that (1) my
   preliminary implementation should have been at least ISO
   C++-compilant, as Ryazanov's one was so, and that (2)
   Clugston showed an even faster (although non-ISO C++)
   implementation can be made portable to virtually all
   existing platforms including VC++/gcc.

   We need more work for this.

- Directories named *CLR and EcellCoreLib.hpp etc.:

   All I can comment on these is that the dependency
   should be unidirectional, VC/C# related things to ecell,
   but not vice versa.
   As for *CLR, all I can say is I'm still not sure if
   this approach is the way you/we should go.

- dmtool/:   it's got a mess.  Didn't libltdl work well?

- From here below are mainly coding style things.
   Modifications like:
+        const int anIndex( (const int)thePriorityQueue.size() );

   C-style cast is discouraged by the coding standard.  Isn't there
   any other way?

- I saw something like this in your patch:

-template < class CLASS, typename RET >
+template < typename CLASS, typename RET >

   Use of class and typename keywords are rigidly defined in
   the coding standard, and in this case CLASS must be class,
   not typename.   Did you have any problem compiling it on VC?

- There might be more, but are basically trivial coding things.


Koichi


> Dear Koichi,
> 
>     I have compiled the "Ecell" on the VC8.0 .
>     So, I have executed the "Sample/Simple" and the "Sample/Drosophila" model.
>     But, I found the difference between the GCC result and the VC8.0 one.
> 
>     Could you verify the result ?
> 
>     The VC8.0 patch is attached to this mail.
>     I describe below some information.
> 
>     If you need to the VC8.0 project files, please teach me the upload server.
>     The size of the VC8.0 project files is about 340 kilo byte.
>     (This mail server has a 40 kilo byte limit to the size of an attached file.)
> 
>     Let me know if you have any question.
> 
> # Compiler
> 	Visual Studio 2005 Team Edition for Software Developers
> 
> # Result
> 	diff_model.txt
> 
> # Source
> 	The patches and the unique file of the VC8.0
> 
> # How to Boost Compile (ver.1.33.1)
> 	 1. To install the python 2.4 to the random directory.
> 	 2. To download the "boost" module from under the URL
> 	     and to unpack to the random directory.
> 	     http://sourceforge.net/project/showfiles.php?group_id=7586
> 	 3. To download the "boost-jam" module from above the URL
> 	     and to unpack to the "boost" unpacked directory.
> 	 4. To set the compiler. To execute under the comannd.
> 	     "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
> 	 5. To compile the "boost" using under the comannd.
> 	     cd [the "boost" unpacked directory]
> 	     "bjam -sTOOLS=vc-8_0 --with-python-root=[the python installed directory]
> 	       --prefix=[the random directory] install"
> 
> # How to GSL Compile (ver.1.7)
> 	 1. To download the "VC++ GSL" module (cvsgslwin.lzh) from under the URL
> 	     and to unpack.
> 	     http://www.tmps.org/index.php?GNU%20Scientific%20Library%20for%20Windows
> 	     (Japanese Only)
> 	 2. To open the "GSLLIBMT.dsw" with all "yes" answers.
> 	 3. To compile the "gslcblas" project.
> 	 4. To compile the "gsl" project.
> 	 5. To download the "GSL" module from under the URL, to unpack
> 	     and to pick up all header files.
> 	     http://www.gnu.org/software/gsl/#downloading
> 
> # How to Compile and Execute
> 	 0. To compile the "Boost" and the "GSL".
> 	 1. To create the "EcellCoreLib" project on the VC8.0.
> 	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
> 	 2. To load all files in the "EcellCoreLib" directory.
> 	 3. To compile and create the "EcellCoreLib.lib" and the "EcellCoreLib.dll".
> 
> 	 4. To create the "ExpressionFluxProcess" project.
> 	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
> 	 5. To load all files in the "ExpressionFluxProcess" directory.
> 	 6. To compile including the "EcellCoreLib.lib"
> 	        and create the "ExpressionFluxProcess.dll".
> 
> 	 7. To do the "FixedODE1Stepper", the "MichaelisUniUniFluxProcess"
> 	        and the "ODE45Stepper" as before.
> 
> 	 8. To create the "EcellCoreLibCLR" project.
> 	        ([Visual C++]->[CLR]->[ClassLibrary])
> 	 9. To load all files in the "EcellCoreLibCLR" directory.
> 	10. To compile including the "EcellCoreLib.lib"
> 	        and create the "EcellCoreLibCLR.dll".
> 
> 	11. To execute the "EcellCoreLibCLRCon" project.
> 	        ([Visual C++]->[CLR]->[CLRConsoleApplication])
> 	12. To load all files in the "EcellCoreLibCLRCon" directory.
> 	13. To compile referencing the "EcellCoreLibCLR.dll"
> 	        and create the "EcellCoreLibCLRCon.exe".
> 
> Best Regards,
> 
> Takeshi YUASA

Was the gcc version compiled without -fpmath=sse ?
If so, my guess is that this difference can be
explained by the FP units used (80bit-long x87 or IEEE 64bit sse2).


Koichi



> Dear Koichi,
> 
>     I have compiled the "Ecell" on the VC8.0 .
>     So, I have executed the "Sample/Simple" and the "Sample/Drosophila" model.
>     But, I found the difference between the GCC result and the VC8.0 one.
> 
>     Could you verify the result ?
> 
>     The VC8.0 patch is attached to this mail.
>     I describe below some information.
> 
>     If you need to the VC8.0 project files, please teach me the upload server.
>     The size of the VC8.0 project files is about 340 kilo byte.
>     (This mail server has a 40 kilo byte limit to the size of an attached file.)
> 
>     Let me know if you have any question.
> 
> # Compiler
> 	Visual Studio 2005 Team Edition for Software Developers
> 
> # Result
> 	diff_model.txt
> 
> # Source
> 	The patches and the unique file of the VC8.0
> 
> # How to Boost Compile (ver.1.33.1)
> 	 1. To install the python 2.4 to the random directory.
> 	 2. To download the "boost" module from under the URL
> 	     and to unpack to the random directory.
> 	     http://sourceforge.net/project/showfiles.php?group_id=7586
> 	 3. To download the "boost-jam" module from above the URL
> 	     and to unpack to the "boost" unpacked directory.
> 	 4. To set the compiler. To execute under the comannd.
> 	     "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
> 	 5. To compile the "boost" using under the comannd.
> 	     cd [the "boost" unpacked directory]
> 	     "bjam -sTOOLS=vc-8_0 --with-python-root=[the python installed directory]
> 	       --prefix=[the random directory] install"
> 
> # How to GSL Compile (ver.1.7)
> 	 1. To download the "VC++ GSL" module (cvsgslwin.lzh) from under the URL
> 	     and to unpack.
> 	     http://www.tmps.org/index.php?GNU%20Scientific%20Library%20for%20Windows
> 	     (Japanese Only)
> 	 2. To open the "GSLLIBMT.dsw" with all "yes" answers.
> 	 3. To compile the "gslcblas" project.
> 	 4. To compile the "gsl" project.
> 	 5. To download the "GSL" module from under the URL, to unpack
> 	     and to pick up all header files.
> 	     http://www.gnu.org/software/gsl/#downloading
> 
> # How to Compile and Execute
> 	 0. To compile the "Boost" and the "GSL".
> 	 1. To create the "EcellCoreLib" project on the VC8.0.
> 	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
> 	 2. To load all files in the "EcellCoreLib" directory.
> 	 3. To compile and create the "EcellCoreLib.lib" and the "EcellCoreLib.dll".
> 
> 	 4. To create the "ExpressionFluxProcess" project.
> 	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
> 	 5. To load all files in the "ExpressionFluxProcess" directory.
> 	 6. To compile including the "EcellCoreLib.lib"
> 	        and create the "ExpressionFluxProcess.dll".
> 
> 	 7. To do the "FixedODE1Stepper", the "MichaelisUniUniFluxProcess"
> 	        and the "ODE45Stepper" as before.
> 
> 	 8. To create the "EcellCoreLibCLR" project.
> 	        ([Visual C++]->[CLR]->[ClassLibrary])
> 	 9. To load all files in the "EcellCoreLibCLR" directory.
> 	10. To compile including the "EcellCoreLib.lib"
> 	        and create the "EcellCoreLibCLR.dll".
> 
> 	11. To execute the "EcellCoreLibCLRCon" project.
> 	        ([Visual C++]->[CLR]->[CLRConsoleApplication])
> 	12. To load all files in the "EcellCoreLibCLRCon" directory.
> 	13. To compile referencing the "EcellCoreLibCLR.dll"
> 	        and create the "EcellCoreLibCLRCon.exe".
> 
> Best Regards,
> 
> Takeshi YUASA

Dear Koichi,

    I have compiled the "Ecell" on the VC8.0 .
    So, I have executed the "Sample/Simple" and the "Sample/Drosophila" model.
    But, I found the difference between the GCC result and the VC8.0 one.

    Could you verify the result ?

    The VC8.0 patch is attached to this mail.
    I describe below some information.

    If you need to the VC8.0 project files, please teach me the upload server.
    The size of the VC8.0 project files is about 340 kilo byte.
    (This mail server has a 40 kilo byte limit to the size of an attached file.)

    Let me know if you have any question.

# Compiler
	Visual Studio 2005 Team Edition for Software Developers

# Result
	diff_model.txt

# Source
	The patches and the unique file of the VC8.0

# How to Boost Compile (ver.1.33.1)
	 1. To install the python 2.4 to the random directory.
	 2. To download the "boost" module from under the URL
	     and to unpack to the random directory.
	     http://sourceforge.net/project/showfiles.php?group_id=7586
	 3. To download the "boost-jam" module from above the URL
	     and to unpack to the "boost" unpacked directory.
	 4. To set the compiler. To execute under the comannd.
	     "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
	 5. To compile the "boost" using under the comannd.
	     cd [the "boost" unpacked directory]
	     "bjam -sTOOLS=vc-8_0 --with-python-root=[the python installed directory]
	       --prefix=[the random directory] install"

# How to GSL Compile (ver.1.7)
	 1. To download the "VC++ GSL" module (cvsgslwin.lzh) from under the URL
	     and to unpack.
	     http://www.tmps.org/index.php?GNU%20Scientific%20Library%20for%20Windows
	     (Japanese Only)
	 2. To open the "GSLLIBMT.dsw" with all "yes" answers.
	 3. To compile the "gslcblas" project.
	 4. To compile the "gsl" project.
	 5. To download the "GSL" module from under the URL, to unpack
	     and to pick up all header files.
	     http://www.gnu.org/software/gsl/#downloading

# How to Compile and Execute
	 0. To compile the "Boost" and the "GSL".
	 1. To create the "EcellCoreLib" project on the VC8.0.
	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
	 2. To load all files in the "EcellCoreLib" directory.
	 3. To compile and create the "EcellCoreLib.lib" and the "EcellCoreLib.dll".

	 4. To create the "ExpressionFluxProcess" project.
	        ([Visual C++]->[Win32]->[Win32ConsoleApplication]->[DLL])
	 5. To load all files in the "ExpressionFluxProcess" directory.
	 6. To compile including the "EcellCoreLib.lib"
	        and create the "ExpressionFluxProcess.dll".

	 7. To do the "FixedODE1Stepper", the "MichaelisUniUniFluxProcess"
	        and the "ODE45Stepper" as before.

	 8. To create the "EcellCoreLibCLR" project.
	        ([Visual C++]->[CLR]->[ClassLibrary])
	 9. To load all files in the "EcellCoreLibCLR" directory.
	10. To compile including the "EcellCoreLib.lib"
	        and create the "EcellCoreLibCLR.dll".

	11. To execute the "EcellCoreLibCLRCon" project.
	        ([Visual C++]->[CLR]->[CLRConsoleApplication])
	12. To load all files in the "EcellCoreLibCLRCon" directory.
	13. To compile referencing the "EcellCoreLibCLR.dll"
	        and create the "EcellCoreLibCLRCon.exe".

Best Regards,

Takeshi YUASA