ecell-devel Mailing List for E-Cell System

Gabor,


> > Instead, subclass Session to create, for example, OsogoSession class, and
> > override loadModel() to do GUI specific procedures before and after calling the 
> > baseclass's  loadModel() method. 
> ok
> >   Some other methods, such as run() and step()
> > may need to be redefined.
> > 
> what do you mean by that?

For example, before run() and step() osogo
needs to change its state to 'running' mode.   (display timeouts to
update plugin windows... etc)   After the run, it comes back to the idle
mode, and also need to do some jobs.


> > And also remember Osogo is a codename.   It's real name is something like
> > E-Cell 3 Session Monitor (GUI).
> > 
> so should it be ecell.Session.GUI maybe? or ecell.Session_GUI?

Well I have revealed before, the idea is to
make Osogo detachable in future.    For example, you run a SessionManager and its
GUI, monitor many runs on that screen, and if you want to pick a specific run
ongoing on a remote computer, invoke an Osogo instance for that Session instance.

To this end it seems better to name it separately than Session.

How about ecell.GtkSessionMonitor, or ecell.gtk.SessionMonitor ?

-sha

Hi, thanks for the comments.

> 
> But remember that Osogo is a GUI wrapper of Session.   
> For example, it doesn't need to have loadModel(), because Session already has it.
> 
yes that' s absolutely true. I think I left it in there by mistake. i
tried to avoid redundancy wherever I could.

> Instead, subclass Session to create, for example, OsogoSession class, and
> override loadModel() to do GUI specific procedures before and after calling the 
> baseclass's  loadModel() method. 
ok
>   Some other methods, such as run() and step()
> may need to be redefined.
> 
what do you mean by that?
> Currently it seems openWindow() methods return window object instances, 
> but how can scripts loaded after the windows are created find them?
currently I think only mainwindow can be created before you load the
script, because after you have loaded a script or model, load
script/load model is disabled. if this is to be chamged, I think
theinterface should be redesigned to add a get...Window() method for all
fundamental windows. or maybe one openWindow(aFundamentalWindowName) and
a getWindow(aFundamentalWindowName) would do it. a getWindow by name
method could have been applied to PluginWindows too.
> To avoid this problem, another option could be to give an ID to every window when
> created, and use the IDs to operate on the windows.
> 
maybe their Name?
it seems to be quite unique, your only chance to make redundant window
names is when you rename PluginWindows. but that is a user interaction
and I think it can be easily controlled.
> And also remember Osogo is a codename.   It's real name is something like
> E-Cell 3 Session Monitor (GUI).
> 
so should it be ecell.Session.GUI maybe? or ecell.Session_GUI?
Gabor

> P.S. don't use ece...@bi...
> 
OK sorry for that. 
> 
> > For the purpose of osogo scripting I plan that a new module ecell.Osoogo
> > should be introduced. the user could call the following API.
> > 
> > class osogo
> > 	startOsogo(aSession=None) 	#starts the osogo session, creates
> > Mainwindow but doesn't show it
> > 	interact()			#hands over controlto the user (gtk.mainloop())
> > 	loadModel(aFile)
> > 	printMessage(aString)		#print message to MessageWindow	
> > 	setUpdateInterval(secs)		#plugins are refreshed every secs seconds
> > 
> > 	openMainWindow() 		#shows and returns _MainWindow
> > 	openBoardWindow()		#opens and reurns _BoardWindow
> > 	openLoggerWindow()		#opens and returns _LoggerWindow
> > 	openInterfaceWindow()		#opens and returns _InterfaceWindow
> > 	openStepperWindow()		#opens and returns _StepperWindow
> > 	createPluginWindow(aType, aFullPNList)	#opens and returns _PluginWindow
> > instance of aType showing aFullPNList
> > 	addPluginToBoard(aType, aFullPNList)	#adds plugin to pluginwindow and
> > returns plugininstance 
> > 	createEntityListWindow()	#creates an EntityListWindow instance
> > 		
> > #
> > #	FUNDAMENTAL WINDOWS
> > #
> > 
> > 	class _MainWindow:
> > 		hide()
> > 		show()
> > 		close() 		#closes application
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		hideMessageWindow()
> > 		showMessageWindow()
> > 		setStepSize(aNum)
> > 		setStepTime(aType)	#0=Step, 1=Seconds
> > 		setTime(aTime)		
> > 	
> > 	class _EntityListWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		selectEntity(aFullPN)	#expands system tree and selectsentity
> > 		
> > 
> > 	class _BoardWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		setPackDirection(FORWARD or DOWN)
> > 		setLimits(anInteger)			#if DOWN packing limitation applies to rows, if
> > FORWARD, to cols
> > 		deletePluginByTitle(aPluginTitle)
> > 		
> > 	class _StepperWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		selectStepperID(aStepperID)
> > 		selectProperty(aStepperId, a Property)
> > 
> > 	class _InterfaceWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		selectPlugin(aPluginTitle)
> > 
> > 	class _LoggerWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		saveDataFile(aFullPN, directory=None, interval=None, from_time=None,
> > to_time=None) 
> > 				#saves data file and sets parameters on window, if some parameter is
> > set to None
> > 				#this may be completely redundant to a similar function in
> > ecell.Session
> > 		resetWindow()
> > 
> > #
> > #	PLUGIN WINDOWS		
> > #		
> > 
> > 	class _TracerWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		resize(width, heigth)
> > 		changeTitle(newTitle)
> > 		setStripInterval(aMinutes)
> > 		createLogger(aFullPN)		#this might be redundant to LogggerStub, but
> > may be convenient	
> > 		setScale(aScale)		#"linear" or "log10"
> > 		showHistory()
> > 		showStripChart()
> > 		logAll()
> > 		minimize()
> > 		maximize()
> > 		hideUI()			#same as minimize but plotsize doesn't change
> > 		setPlotSize(aWidth, aHeigth)
> > 		setTraceColor(aFullPN, GdkColor||ColorName||[red,green,blue]) 
> > 		setTraceVisible(aBoolean)
> > 		zoomIn(x0,x1,y0,y1)
> > 		zoomout(aNum=1)			#zoom out from aNum previous zoomins, if zero to
> > toplevel
> > 	
> > 	class _BargraphWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		changeTitle(newTitle)
> > 
> > 	class _DigitalWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		changeTitle(newTitle)
> > 
> > 	class _VariableWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		changeTitle(newTitle)
> > 		setValueFixed(aBooolean)
> > 
> > 	class _PropertyWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		changeTitle(newTitle)
> > 
> > #
> > #	Abstract Base classes
> > #
> > 	class _FundamentalWindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > #	to be inherited by _EntiyList, _Main, _Logger, _Interface, _Stepper
> > Windows. sometimes these basic methods should be overloaded
> > 
> > 	class _Pluginwindow:
> > 		hide()
> > 		show()
> > 		close() 		
> > 		position(x,y)
> > 		changeTitle(newTitle)
> > #	to be inherited  by _Tracer, _Bargraph, _Digital, _Variable,
> > _PropertyWindows
> > 
> > Mail me if you have any comments.
> > Gabor
> > 
> > _______________________________________________
> > Ecell3-devel maillist  -  Ece...@bi...
> > http://bioinformatics.org/mailman/listinfo/ecell3-devel
> > 
> 
> 

Gabor,


At the first glance the API seems to be well designed.  I'll look into
that more closely.


But remember that Osogo is a GUI wrapper of Session.   
For example, it doesn't need to have loadModel(), because Session already has it.

Instead, subclass Session to create, for example, OsogoSession class, and
override loadModel() to do GUI specific procedures before and after calling the 
baseclass's  loadModel() method.   Some other methods, such as run() and step()
may need to be redefined.

Currently it seems openWindow() methods return window object instances, 
but how can scripts loaded after the windows are created find them?
To avoid this problem, another option could be to give an ID to every window when
created, and use the IDs to operate on the windows.

And also remember Osogo is a codename.   It's real name is something like
E-Cell 3 Session Monitor (GUI).

-sha

P.S. don't use ece...@bi...


> For the purpose of osogo scripting I plan that a new module ecell.Osoogo
> should be introduced. the user could call the following API.
> 
> class osogo
> 	startOsogo(aSession=None) 	#starts the osogo session, creates
> Mainwindow but doesn't show it
> 	interact()			#hands over controlto the user (gtk.mainloop())
> 	loadModel(aFile)
> 	printMessage(aString)		#print message to MessageWindow	
> 	setUpdateInterval(secs)		#plugins are refreshed every secs seconds
> 
> 	openMainWindow() 		#shows and returns _MainWindow
> 	openBoardWindow()		#opens and reurns _BoardWindow
> 	openLoggerWindow()		#opens and returns _LoggerWindow
> 	openInterfaceWindow()		#opens and returns _InterfaceWindow
> 	openStepperWindow()		#opens and returns _StepperWindow
> 	createPluginWindow(aType, aFullPNList)	#opens and returns _PluginWindow
> instance of aType showing aFullPNList
> 	addPluginToBoard(aType, aFullPNList)	#adds plugin to pluginwindow and
> returns plugininstance 
> 	createEntityListWindow()	#creates an EntityListWindow instance
> 		
> #
> #	FUNDAMENTAL WINDOWS
> #
> 
> 	class _MainWindow:
> 		hide()
> 		show()
> 		close() 		#closes application
> 		position(x,y)
> 		resize(width, heigth)
> 		hideMessageWindow()
> 		showMessageWindow()
> 		setStepSize(aNum)
> 		setStepTime(aType)	#0=Step, 1=Seconds
> 		setTime(aTime)		
> 	
> 	class _EntityListWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		selectEntity(aFullPN)	#expands system tree and selectsentity
> 		
> 
> 	class _BoardWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		setPackDirection(FORWARD or DOWN)
> 		setLimits(anInteger)			#if DOWN packing limitation applies to rows, if
> FORWARD, to cols
> 		deletePluginByTitle(aPluginTitle)
> 		
> 	class _StepperWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		selectStepperID(aStepperID)
> 		selectProperty(aStepperId, a Property)
> 
> 	class _InterfaceWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		selectPlugin(aPluginTitle)
> 
> 	class _LoggerWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		saveDataFile(aFullPN, directory=None, interval=None, from_time=None,
> to_time=None) 
> 				#saves data file and sets parameters on window, if some parameter is
> set to None
> 				#this may be completely redundant to a similar function in
> ecell.Session
> 		resetWindow()
> 
> #
> #	PLUGIN WINDOWS		
> #		
> 
> 	class _TracerWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		resize(width, heigth)
> 		changeTitle(newTitle)
> 		setStripInterval(aMinutes)
> 		createLogger(aFullPN)		#this might be redundant to LogggerStub, but
> may be convenient	
> 		setScale(aScale)		#"linear" or "log10"
> 		showHistory()
> 		showStripChart()
> 		logAll()
> 		minimize()
> 		maximize()
> 		hideUI()			#same as minimize but plotsize doesn't change
> 		setPlotSize(aWidth, aHeigth)
> 		setTraceColor(aFullPN, GdkColor||ColorName||[red,green,blue]) 
> 		setTraceVisible(aBoolean)
> 		zoomIn(x0,x1,y0,y1)
> 		zoomout(aNum=1)			#zoom out from aNum previous zoomins, if zero to
> toplevel
> 	
> 	class _BargraphWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		changeTitle(newTitle)
> 
> 	class _DigitalWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		changeTitle(newTitle)
> 
> 	class _VariableWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		changeTitle(newTitle)
> 		setValueFixed(aBooolean)
> 
> 	class _PropertyWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		changeTitle(newTitle)
> 
> #
> #	Abstract Base classes
> #
> 	class _FundamentalWindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> #	to be inherited by _EntiyList, _Main, _Logger, _Interface, _Stepper
> Windows. sometimes these basic methods should be overloaded
> 
> 	class _Pluginwindow:
> 		hide()
> 		show()
> 		close() 		
> 		position(x,y)
> 		changeTitle(newTitle)
> #	to be inherited  by _Tracer, _Bargraph, _Digital, _Variable,
> _PropertyWindows
> 
> Mail me if you have any comments.
> Gabor
> 
> _______________________________________________
> Ecell3-devel maillist  -  Ece...@bi...
> http://bioinformatics.org/mailman/listinfo/ecell3-devel
> 

Use empy.  To include a file,

@include( 'filename' )

see the manual.

sha

> Does ECELL 3 support include method for large models? For example, if I 
> have 4 models, and I want to have them work as a single model, can I 
> just do something like  include model1.em etc.? If not, will anyone work 
> on that? It should necessary for large sacle modeling.
> 
> Thanks.
> Bin
> 
> _______________________________________________
> Ecell3-devel maillist  -  Ece...@bi...
> http://bioinformatics.org/mailman/listinfo/ecell3-devel
> 

Hi,

I am designing settings window in Osogo.
I am planning to have the following prefernces on the window. Please mail me if you think any of them are obsolete or other preferences/preference groups should be taken on the list.
preferences can be set in a  general and a model specific way. The settings window automatically saves the general settings to a ~/osogo.ini and the model specific settings in the model-dir/osogo.ini

Settings:

MainWindow
	At start up show:
		EntityWindow		(yes/no)
		MessageWindow		(yes/no)
		BoardWindow		(yes/no)
		InterfaceWindow		(yes/no)
		LoggerWindow		(yes/no)

	Parameters:
		Update Interval		[] seconds , after which pluginwindows are updated, currently 150
		Step Interval		[] initial value for step interval on MainWindow, currently 1
		() Sec  () Step		interpretation of stepinterval (currently Sec)

TracerWindow
	Start up parameters
		Strip Interval		interval to show on X frame when trace history is not shown (strip mode)
		Automatically create loggers (yes/no)
		Show history		(yes/no) 	whether to pop up in history mode(if possible)

	Colors
		Background		currently grey
		Axis, cathegory labels	currently black
		1. trace		currently red
		2. trace		currently blue
		.
		.
		12. trace		color chooser

	Preferred Plot Size		default size (currently 600x350)
		width: 		heigth:

	Preferred Small Size		size when minimized (currently 400x250 )
		width: 		heigth

BargraphWindow
	Preferred Size
		width: 		heigth:

	Colors
		Background		currently grey
		To 	   [x0]	[color] when value is < x0 (currently 0, black)
		From x0 to [x1] [color]	when value is between x1 and x0  (currently 10, blue)
		From x1 to [x2] [color]	when value is between x2 and x1 (currently 100, yellow )
		From x2 to [x3] [color]	when value is between x3 and x1 (currently 1000, red )
		From x3		[color]	when value is bigger than x3 (currently black)	
	(there could be more steps than three if needed)

Gabor



--------------------
talk21 your FREE portable and private address on the net at http://www.talk21.com

Hi.

I think ecell3 must do test for Version 3.2 release.

test (member that has charge) 

1,Command(ecell3-*),GUI,Modeling test(tomo)
2,Algorithm accuracy test(kaizu)
3,Standard Process test(ishida)

We will do three tests and maybe finish in May.
Please give us cooperation when find some bugs.

tomo

Hi,
I=20have=20finished=20implementing=20a=20complete=20set=20of=20changes=20to=20osogo,=20mainly=20improvements=20on=20TracerWindow,=20BoardWindow,=20EntityListWindow.
And=20also=20checked=20it=20into=20CVS,=20so=20it=20is=20ready=20to=20be=20included=20in=20the=20release.
I=20welcome=20any=20comments.=20I=20have=20already=20got=20some=20from=20Hu=20Bin.

In=20the=20next=20phase=20I=20am=20going=20to=20concentrate=20on
1.=20implementing=20preferences=20window
2.=20designing=20and=20implementing=20osogo=20scripting=20language.
Ideas/user=20requirements=20are=20welcome.
Gabor

>=20Thanks=20gabor,
>
>By=20removing=20gnome=20part=20from=20Osogo,=20it=20must=20be=20much=20easier=20to=20run=20it=20on
>Windows=20and=20Mac=20OSX.
>
>=20I=20hope=20I=20can=20do=20it=20before=20the=20new=20deadline.
>=20when=20is=20it,=20BTW,=20
>
>When=20the=20bug=20is=20fixed:)=20=20=20
>
>=20maybe=20Wednesday=3F=20
>
>Good=20guess,=20perhaps.=20=20=20But=20if=20you=20have
>something=20to=20be=20included=20in=20the=20new=20release,=20let=20me=20know.=20=20=20We=20can=20wait
>for=20it.=20
>
>
>-sha
>
>
>
>
>-------------------------------------------------------
>This=20SF.net=20email=20is=20sponsored=20by:=20If=20flattening=20out=20C++=20or=20Java
>code=20to=20make=20your=20application=20fit=20in=20a=20relational=20database=20is=20painful,=20
>don't=20do=20it!=20Check=20out=20ObjectStore.=20Now=20part=20of=20Progress=20Software.
<a=20Target=3D'_new'=20Href=3D'<a=20Target=3D'_new'=20Href=3D'http://talk21.btopenworld.com/redirect.html=3Fhttp://talk21.btopenworld.com/redirect.html=3Fhttp://www.objectstore.net/sourceforge''>http://talk21.btopenworld.com/redirect.html=3Fhttp://www.objectstore.net/sourceforge'</a>><a=20Target=3D'_new'=20Href=3D'http://talk21.btopenworld.com/redirect.html=3Fhttp://www.objectstore.net/sourceforge'>http://www.objectstore.net/sourceforge</a></a>
>_______________________________________________
>Ecell-devel=20mailing=20list
>Ece...@li...
>https://lists.sourceforge.net/lists/listinfo/ecell-devel



--------------------
talk21=20your=20FREE=20portable=20and=20private=20address=20on=20the=20net=20at=20<a=20Target=3D'_new'=20Href=3D'http://talk21.btopenworld.com/redirect.html=3Fhttp://www.talk21.com'>http://www.talk21.com</a>



--------------------
talk21=20your=20FREE=20portable=20and=20private=20address=20on=20the=20net=20at=20http://www.talk21.com

Thank you for the report, 


> I verified PythonProcess run time on Droslphila model about 
> the case of ODE45Stepper and fixedODE1Stepper,
> and compared to Process run time.

> run 100 sec.
> 
> Process :
> 	FixedODE1Stepper       |         ODE45Stepper
> 	                                   |
> real              0m1.129s              |              0m0.281s
                       ^^^^^^^^^

This seems like an irregular result.  Twice as long as usr time.  
Probably caused by busy system (disk IO?).

> usr               0m0.620s              |              0m0.230s
> 	                                   |
> sys              0m0.040s              |              0m0.030s
> 
> -----------------------------------------------
> 


To compare the performance difference between PythonProcess and native C++
Processes, the FixedODE1Stepper result is more suitable than variable-stepsize ODE45.

Here is a simplified comparison of usr times of FixdeODE1 runs:


            PythonProcess      Native (C++)      Speed Difference

100s    24.010s                 0.620s                 40x
1000s  238.210s               4.470s                 53.2x


PythonProcess is about 50 times slower.     This is too slow, but the number
is less than around 10, I think it withstands real use.

For optimization there are several ways:

(1) Find a faster way to execute PyCodeObject than PyEval_EvalCode().
       PyEval-EvalCode() does a bunch of argument interpretation and checks before
       actually call eval_frame(), which is the main python interpreter loop.

(2) Optimize the PyCodeObject.    Perhaps Psyco could be used.
        http://psyco.sourceforge.net/index.html
        A problem regarding this is currently there seems to be no way to optimize
        PyCodeObject by Psyco.    I'm asking the author about this.

      Another option is weave, which is a part of scipy.  (www.scipy.org)

(3) Use a different syntax than Python.
       For example, Pyrex allows mixing Python and C-like statements.
       Even embedding C++ code fragment can be an option, although this discards
       the benefit of simpler Python syntax.   


-sha

Hi everyone.

I verified PythonProcess run time on Droslphila model about 
the case of ODE45Stepper and fixedODE1Stepper,
and compared to Process run time.

Here is the result.


run 100 sec.

Process :
	FixedODE1Stepper       |         ODE45Stepper
	                                   |
real              0m1.129s              |              0m0.281s
	                                   |
usr               0m0.620s              |              0m0.230s
	                                   |
sys              0m0.040s              |              0m0.030s

-----------------------------------------------

PythonProcess :
	FixedODE1Stepper       |          ODE45Stepper
	                                   |
real              0m24.067s            |              0m1.276s
                                               |
usr               0m24.010s            |              0m1.210s
	                                   |
sys               0m0.040s             |              0m0.020s

------------------------------------------------



run 1000 sec.

Process :
	FixedODE1Stepper       |         ODE45Stepper
	                                   |
real              0m4.539s              |              0m0.346s
	                                   |
usr               0m4.470s              |              0m0.300s
	                                   |
sys              0m0.040s              |              0m0.030s

-----------------------------------------------

PythonProcess :
	FixedODE1Stepper       |          ODE45Stepper
	                                   |
real               3m58.270s           |              0m5.986s
                                               |
usr                3m58.210s           |              0m5.900s
	                                   |
sys               0m0.030s             |              0m0.040s

------------------------------------------------


isida

Thanks gabor,

By removing gnome part from Osogo, it must be much easier to run it on
Windows and Mac OSX.

> I hope I can do it before the new deadline.
> when is it, BTW, 

When the bug is fixed:)   

> maybe Wednesday? 

Good guess, perhaps.   But if you have
something to be included in the new release, let me know.   We can wait
for it. 


-sha

hi,

I=20have=20just=20checked=20in=20a=20few=20changes=20to=20Osogo,=20and=20if=20anyone=20has=20some=20time=20and=20lust=20for=20it,=20please=20test=20it.
changes:
-got=20rid=20of=20gnome=20dependency
-small=20bugfixes(messagewindow=20didn't=20change)
-tracerwindow=20is=20now=20resizeable
-tracerwindow=20has=20now=202=20states:=20in=20one=20state=20only=20the=20plot=20area=20can=20be=20seen,=20in=20the=20another=20the=20whole=20user=20interface.=20one=20can=20swap=20between=20the=20two=20traces=20by=20doubleclicking=20on=20the=20plotarea
-boardwindow=20shrinks=20to=20fit=20when=20something=20is=20removed.
-boardwindow=20has=20a=20max=20pixel=20size=20and=20a=20scrollbar=20in=20case=20the=20content=20doesn't=20fit
-tracerwindow=20and=20plotterpluginwindow=20is=20worked=20into=20one=20class:=20TracerWindow,=20so=20PlotterPluginWindow.py=20should=20be=20removed=20from=20CVS=20(I=20dont't=20know=20how=20to=20do=20it)
-similarly=20TracerPlot=20and=20Plot=20is=20reduced=20to=20one=20class=20:=20Plot=20but=20no=20file=20needs=20to=20be=20removed.

I=20am=20still=20working=20on=20TracerWindow=20because=20I=20would=20like=20to=20display=20the=20short=20names=20of=20traces=20on=20the=20plot=20when=20the=20List=20of=20traces=20cannot=20be=20seen.
I=20hope=20I=20can=20do=20it=20before=20the=20new=20deadline.
when=20is=20it,=20BTW,=20maybe=20Wednesday=3F=20
Gabor

>=20hi,
>
>
>During=20the=20accuracy=20test,=20kaizu=20found=20a=20=20suspected=20scheduler=20bug=20which=20only=20affects
>multi-stepper=20simulations.
>
>Due=20to=20this=20issue=20the=20release=20of=203.1.96=20has=20been=20postponed=20until=20the=20bug=20is=20identified=20and
>fixed.=20=20=20We=20feel=20that=20=20it=20can=20be=20done=20in=20a=20few=20days.
>
>The=20CVS=20is=20now=20reopened=20to=20everyone,=20and=20changes=20can=20be=20checked=20in.
>If=20you=20want=20to=20make=20sure=20your=20change=20will=20be=20included=20in=20the=20next=20version,
>mail=20me=20before.
>
>
>-sha
>
>
>
>
>
>-------------------------------------------------------
>This=20SF.net=20email=20is=20sponsored=20by:=20If=20flattening=20out=20C++=20or=20Java
>code=20to=20make=20your=20application=20fit=20in=20a=20relational=20database=20is=20painful,=20
>don't=20do=20it!=20Check=20out=20ObjectStore.=20Now=20part=20of=20Progress=20Software.
><a=20Target=3D'_new'=20Href=3D'http://talk21.btopenworld.com/redirect.html=3Fhttp://www.objectstore.net/sourceforge'>http://www.objectstore.net/sourceforge</a>
>_______________________________________________
>Ecell-devel=20mailing=20list
>Ece...@li...
>https://lists.sourceforge.net/lists/listinfo/ecell-devel



--------------------
talk21=20your=20FREE=20portable=20and=20private=20address=20on=20the=20net=20at=20http://www.talk21.com

hi,


During the accuracy test, kaizu found a  suspected scheduler bug which only affects
multi-stepper simulations.

Due to this issue the release of 3.1.96 has been postponed until the bug is identified and
fixed.   We feel that  it can be done in a few days.

The CVS is now reopened to everyone, and changes can be checked in.
If you want to make sure your change will be included in the next version,
mail me before.


-sha

hi people,

We are preparing for the release of 3.1.96.   
Maru will pack rpms and tarballs next monday (JST).
So the patch deadline for that version to be included is this sunday.

Let me know if there is any problem with this schedule.

I believe 3.1.96 will be functional enough for general users, except the complete user's manual.
After that version we will do some intensive testing to see if
it is ready to become 3.2.   The next release can be either 3.1.97 or 3.2.

Of course there would be many things to do even after 3.2, including debugs.


-sha

Hi Satya.

Now I try porting Ecell3 to Mac OSX.
Specially, I suffer What GUI use in Mac OSX.

Your excellent job serves as a very useful references.

Thank you!!

Satya Arjunan <sa...@tt...> wrote:

> Hi Shafi and everyone,
> 
> I have successfully ported Ecell3 to Cygwin. A sreenshot of it is 
> available at
> http://satya.host.sk/ecellcyg.jpg
> 
> 
> E-Cell dependencies
> .....................
> 
> `-- e-cell3
>     |-- gnome-python
>     |   |-- libgnome
>     |   |   |-- esound
>     |   |   |   `-- audiofile
>     |   |   |-- gnome-vfs
>     |   |   |   |-- Gconf
>     |   |   |   |   `-- ORBit
>     |   |   |   |       |-- libIDL
>     |   |   |   |       `-- linc
>     |   |   |   |-- gnome-mime-data
>     |   |   |   `-- libbonobo
>     |   |   |       `-- bonobo-activation
>     |   |   `-- libxslt
>     |   |       `-- libxml
>     |   `-- pyorbit
>     |       `-- libgnomeui
>     |           `-- libgnomecanvas
>     |               `-- pango (pangoft2)
>     |                   `-- Xft
>     |                       |-- fontconfig
>     |                       |   `-- freetype
>     |                       `-- xrender
>     |                           `-- render
>     |-- libgsl
>     |-- pygtk
>     |   `-- gtk2
>     |       |-- atk
>     |       |-- glib
>     |       `-- pango
>     `-- python-numeric
>        
> 
> After testing each of the above dependencies, I have found that each of 
> them are tightly dependent, meaning that won't compile without their 
> respective dependencies (shown above). In other words they are the least 
> number of prerequisite libraries to compile E-Cell on Cygwin.
> 
>  From the figure above, if we were able to discard the requirement of 
> gnome-python, a lot of libraries can be avoided. So I think, as 
> suggested by shafi, the next step would be to introduce an option in 
> E-Cell to --disable-gnome. I will start with this task after automating 
> the configure procedure such that it will permit E-Cell to run on 
> Cygwin. The automation will include the following modifications to 
> E-Cell (when configured on Cygwin):
> 
> 1. in topdir/ecell/configure.in, remove:
> AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")
> if test "$LIBDL" = ""; then
> AC_MSG_ERROR([The libdl could not be found.])
> fi
> AC_SUBST(LIBDL)
> 
> in topdir/ecell/configure.in:
> dnl AC_LIBLTDL_INSTALLABLE
> dnl AC_LIBLTDL_CONVENIENCE
> AC_WITH_LTDL
> 
> 2. in topdir/ecell/libecs/Defs.hpp, replace:
> #include <stdint.h>
> with
> #include <sys/types.h>
> 
> 3. in topdir/configure.in
> dnl AC_LIBLTDL_INSTALLABLE
> dnl AC_LIBLTDL_CONVENIENCE
> AC_WITH_LTDL
> AC_SUBST(INCLTDL)
> AC_SUBST(LIBLTDL)
> AC_LIBTOOL_DLOPEN
> AC_PROG_LIBTOOL
> dnl
> AC_CONFIG_SUBDIRS( ecell bin dmtool )
> dnl
> 
> in topdir/dmtool/dmcompile.in
> SHLEXT=.dll
> 
> in topdir/ecell/dm/Makefile.am
> SOS = ${DMS:.cpp=.dll}
> %.dll : %.cpp
> 
> in topdir/ecell/libecs/Makefile.am
> libecs_la_LDFLAGS= -version-info 2:0:0 -no-undefined #-rpath ${libdir}
> 
> in topdir/ecell/libemc/Makefile.am
> libemc_la_LDFLAGS = -version-info 2:0:0 -no-undefined
> libemc_la_LIBADD=$(LIBECS) $(LIBLTDL) -lstdc++
> 
> in topdir/ecell/pyecell/Makefile.am
> _tableio_la_LDFLAGS= -module -export-dynamic -avoid-version -no-undefined
> _tableio_la_LIBADD=-L/usr/lib/python2.2/config -lpython2.2
> 
> in topdir/ecell/pyecs/Makefile.am
> _ecs_la_LDFLAGS= -module -export-dynamic -avoid-version -no-undefined
> _ecs_la_LIBADD=$(LIBECS) $(LIBEMC) -lstdc++ $(LIBLTDL) 
> -L/usr/lib/python2.2/config -lpython2.2
> 
> rename topdir/ecell/pyecell/ecell/ECS.py to ECS_.py
> 
> in topdir/ecell/pyecell/ecell/ecssupport.py, FullID.py, ObjectStub.py, 
> __init__.py replace
>     from ECS import *
> with
>     from ECS_ import *
> 
> 
> in topdir/ecell/pyecell/ecell/Plugin.py, MainWindow.py replace
>     from ecell.ECS import *
> with
>     from ecell.ECS_ import *
> 
> in topdir/osogo/OsogoPluginManager.py, OsogoPluginWindow.py, Plugin.py 
> replace
>     from ecell.ECS import *
> with
>     from ecell.ECS_ import *
> 
> in topdir/test/test.py, testeml.py replace
>     from ecell.ECS import *
> with
>     from ecell.ECS_ import *
> 
> in topdir/bin/ecell-dmc.in
> LDFLAGS="$LDFLAGS -lecs -lgsl"
> 
> Installation Steps (CVS version)
> ................................
> 1. ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
> --with-included-ltdl=no
> 2. cp /usr/autotool/devel/bin/libtool .
> 3. cp /usr/autotool/devel/bin/libtool dmtool/
> 4. cp /usr/autotool/devel/bin/libtool ecell/
> 5. cp /usr/autotool/devel/bin/libtool libltdl/
> 6. make
> 7. make install
> 
> satya
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hi Shafi and everyone,

I have successfully ported Ecell3 to Cygwin. A sreenshot of it is 
available at
http://satya.host.sk/ecellcyg.jpg


E-Cell dependencies
.....................

`-- e-cell3
    |-- gnome-python
    |   |-- libgnome
    |   |   |-- esound
    |   |   |   `-- audiofile
    |   |   |-- gnome-vfs
    |   |   |   |-- Gconf
    |   |   |   |   `-- ORBit
    |   |   |   |       |-- libIDL
    |   |   |   |       `-- linc
    |   |   |   |-- gnome-mime-data
    |   |   |   `-- libbonobo
    |   |   |       `-- bonobo-activation
    |   |   `-- libxslt
    |   |       `-- libxml
    |   `-- pyorbit
    |       `-- libgnomeui
    |           `-- libgnomecanvas
    |               `-- pango (pangoft2)
    |                   `-- Xft
    |                       |-- fontconfig
    |                       |   `-- freetype
    |                       `-- xrender
    |                           `-- render
    |-- libgsl
    |-- pygtk
    |   `-- gtk2
    |       |-- atk
    |       |-- glib
    |       `-- pango
    `-- python-numeric
       

After testing each of the above dependencies, I have found that each of 
them are tightly dependent, meaning that won't compile without their 
respective dependencies (shown above). In other words they are the least 
number of prerequisite libraries to compile E-Cell on Cygwin.

 From the figure above, if we were able to discard the requirement of 
gnome-python, a lot of libraries can be avoided. So I think, as 
suggested by shafi, the next step would be to introduce an option in 
E-Cell to --disable-gnome. I will start with this task after automating 
the configure procedure such that it will permit E-Cell to run on 
Cygwin. The automation will include the following modifications to 
E-Cell (when configured on Cygwin):

1. in topdir/ecell/configure.in, remove:
AC_CHECK_LIB(dl, dlopen, LIBDL="-ldl")
if test "$LIBDL" = ""; then
AC_MSG_ERROR([The libdl could not be found.])
fi
AC_SUBST(LIBDL)

in topdir/ecell/configure.in:
dnl AC_LIBLTDL_INSTALLABLE
dnl AC_LIBLTDL_CONVENIENCE
AC_WITH_LTDL

2. in topdir/ecell/libecs/Defs.hpp, replace:
#include <stdint.h>
with
#include <sys/types.h>

3. in topdir/configure.in
dnl AC_LIBLTDL_INSTALLABLE
dnl AC_LIBLTDL_CONVENIENCE
AC_WITH_LTDL
AC_SUBST(INCLTDL)
AC_SUBST(LIBLTDL)
AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
dnl
AC_CONFIG_SUBDIRS( ecell bin dmtool )
dnl

in topdir/dmtool/dmcompile.in
SHLEXT=.dll

in topdir/ecell/dm/Makefile.am
SOS = ${DMS:.cpp=.dll}
%.dll : %.cpp

in topdir/ecell/libecs/Makefile.am
libecs_la_LDFLAGS= -version-info 2:0:0 -no-undefined #-rpath ${libdir}

in topdir/ecell/libemc/Makefile.am
libemc_la_LDFLAGS = -version-info 2:0:0 -no-undefined
libemc_la_LIBADD=$(LIBECS) $(LIBLTDL) -lstdc++

in topdir/ecell/pyecell/Makefile.am
_tableio_la_LDFLAGS= -module -export-dynamic -avoid-version -no-undefined
_tableio_la_LIBADD=-L/usr/lib/python2.2/config -lpython2.2

in topdir/ecell/pyecs/Makefile.am
_ecs_la_LDFLAGS= -module -export-dynamic -avoid-version -no-undefined
_ecs_la_LIBADD=$(LIBECS) $(LIBEMC) -lstdc++ $(LIBLTDL) 
-L/usr/lib/python2.2/config -lpython2.2

rename topdir/ecell/pyecell/ecell/ECS.py to ECS_.py

in topdir/ecell/pyecell/ecell/ecssupport.py, FullID.py, ObjectStub.py, 
__init__.py replace
    from ECS import *
with
    from ECS_ import *


in topdir/ecell/pyecell/ecell/Plugin.py, MainWindow.py replace
    from ecell.ECS import *
with
    from ecell.ECS_ import *

in topdir/osogo/OsogoPluginManager.py, OsogoPluginWindow.py, Plugin.py 
replace
    from ecell.ECS import *
with
    from ecell.ECS_ import *

in topdir/test/test.py, testeml.py replace
    from ecell.ECS import *
with
    from ecell.ECS_ import *

in topdir/bin/ecell-dmc.in
LDFLAGS="$LDFLAGS -lecs -lgsl"

Installation Steps (CVS version)
................................
1. ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--with-included-ltdl=no
2. cp /usr/autotool/devel/bin/libtool .
3. cp /usr/autotool/devel/bin/libtool dmtool/
4. cp /usr/autotool/devel/bin/libtool ecell/
5. cp /usr/autotool/devel/bin/libtool libltdl/
6. make
7. make install

satya

>> no symbols defined
>>
> It says no symbols, so it found the file but had a linking problem.
>
Thanks, I was looking at the wrong direction all along. I will check 
about the symbols.

> Does cygwin has objdump or nm command?
>
Yes it has both of the commands. Unfortunately I have never used them. I 
will look about them in internet now.

satya

> RuntimeError: DMException: Failed to find or load a DM [ODE23Stepper]: 
> no symbols defined

It says no symbols, so it found the file but had a linking problem.

> I suspect it is because of the lt_dlopenext (ecell local copy) does not 
> look for dll.a. But I know it got the path right because when I changed 
> the extension of ODE23Stepper.dll.a to ODE23Stepper.la, I can see that 

I'm not quite familiar with cygwin environment, but if .dll.a is a
shared library file, you can't rename it to .la.   .la must be a text
file.

Does cygwin has objdump or nm command?


> Has this got to do with the bug that you mentioned in libltdl?

no, but check the changelog of libtool.


sha

Shafi,

>Ok I guess you may need to tweak something about the difference in dynamic
>loading of .dll/.so.   For this first try to update ecell3/libltdl to the 
>latest cvs version.  (it's a part of GNU libtool, and ecell3 has a local copy
>because I once stuck by a bug which is not fixed in the release version
>but in the cvs version.)
>  
>

I am having a problem with the dynamic loading of shared libraries. In 
cygwin, the .so files are given the extension dll.a. For some reason, 
the ported ecell system can't seem to locate and load the file during 
runtime. For example I get the following error when I ran a test program:

$ ecell3-session test.ess
Traceback (most recent call last):
  File "/usr/bin/ecell3-session", line 164, in ?
    main()
  File "/usr/bin/ecell3-session", line 159, in main
    aSession.loadScript( anEssFile, aParameters )
  File "/usr/lib/python2.2/site-packages/ecell/Session.py", line 49, in 
loadScript
    execfile( ecs, aContext )
  File "test.ess", line 5, in ?
    loadModel( 'c1.eml' )
  File "/usr/lib/python2.2/site-packages/ecell/Session.py", line 94, in 
loadModel
    self.__loadStepper( anEml )
  File "/usr/lib/python2.2/site-packages/ecell/Session.py", line 378, in 
__loadStepper
    str( aStepper ) )
RuntimeError: DMException: Failed to find or load a DM [ODE23Stepper]: 
no symbols defined


I suspect it is because of the lt_dlopenext (ecell local copy) does not 
look for dll.a. But I know it got the path right because when I changed 
the extension of ODE23Stepper.dll.a to ODE23Stepper.la, I can see that 
it has loaded the library with the following sigsegv error:

$ ecell3-session test.ess
PyECS: SIGSEGV. Invalid memory reference.

Has this got to do with the bug that you mentioned in libltdl?

satya

Satya,


> >- Linux/GNOME:   The primary platform.
> >
> >   Everything including ecell3 core, osogo, SessionManager (distributed computing
> >   platform for ecell3), and the E-Cell Modeling Environment runs on this.
> >  
> >   The Modeling Environment, especially GUI parts, tweaks the full power of GNOME 
> >   at the cost of portability.    The core must stay portable, and Osogo should be
> >   able to run without GNOME, though.
> >
> Does that mean in future, gtk should be sufficient and GNOME would not 
> be required to run Osogo?

It is intended to be.   In future Osogo and the Modeling Environment will be merged, but
it will still be able to configure it with --without-gnome or something and disable the
modeling components (only the session monitor functionalities). 

But as you pointed out, currently it depends on libglade and some other things.   
The dependency to libgnome may be removed.   
As far as I know it's only for gnome-about panel.


> At first I thought Gtk2 should be enough but it seems although Osogo 
> uses a little part of gnome such as  gnome-python, this part in turn has 
> other gnome dependencies (libgnome and libglade). So far I have 
> installed the following packages on the native cygwin (latest version 
> 1.3.22-1) just to let ecell3 configure, compile and install without errors:
> 
> 3. libxml2-2.5.4
> 4. libxslt-1.0.27
> 5. glib-2.2.1
> 6. linc-1.0.1
> 7. libIDL-0.8.0
> 8. ORBit2-2.6.1
> 9. intltool-0.25
> 10. bonobo-activation-2.2.1.1
> 11. libbonobo-2.2.1
> 12. pango-1.2.1
> 13. atk-1.2.2
> 14. gtk+-2.2.1
> 15. Gconf-2.2.0
> 16. gconf-editor-0.4.0
> 17. gnome-mime-data-2.2.0
> 18. gnome-vfs-2.2.3
> 19. audiofile-0.2.3
> 20. esound-0.2.29
> 21. libgnome-2.2.0.1
> 22. libart_lgpl-2.3.11
> 23. libglade-2.0.1

Certainly no need to have bonobo, pango and ORBit, at least!


> the Xwin, it says it requires gnome.ui. I am guessing the gnome.ui is in 
> libgnomeui. To install libgnomeui the following libraries would need to 
> be installed,

See osogo's source.  It should be easy to remove gnome part.

Did you try to build only python-gtk2?  



> Naturally, I have the same problem in rootless mode of Xwin. On the 
> other hand, when I try to run ecell in scripting mode, ecell3-session, I 
> also get some win32 error. This I am assuming is because I have not 
> compiled ecell with correct parameters. I am working on this part now.

Ok I guess you may need to tweak something about the difference in dynamic
loading of .dll/.so.   For this first try to update ecell3/libltdl to the 
latest cvs version.  (it's a part of GNU libtool, and ecell3 has a local copy
because I once stuck by a bug which is not fixed in the release version
but in the cvs version.)


-sha


P.S.

> I think not yet. I will let you know when it is ready. Hopefully I can 
> show you something when you get here ( TTCK). Hubin told me that you 
> will be coming here next week. May I know on which day?

Nice.   I'll be there before next weekend.  I'll call hubin or write an email when I depart.

hi,


NRProcess has been renamed to GillespieProcess.
Also some optimizations has been given (removed several ifs.).
NRStepper remains the same.

hubin, I think this doesn't change the behavior, but could you test it?


ex.

Stepper NRStepper( NR )
{
}

System CompartmentSystem( / )
{
    StepperID NR;

     Variable...

     Process GillespieProcess( GP1 )
     {
     }
    
}


sha

>- Linux/GNOME:   The primary platform.
>
>   Everything including ecell3 core, osogo, SessionManager (distributed computing
>   platform for ecell3), and the E-Cell Modeling Environment runs on this.
>  
>   The Modeling Environment, especially GUI parts, tweaks the full power of GNOME 
>   at the cost of portability.    The core must stay portable, and Osogo should be
>   able to run without GNOME, though.
>
Does that mean in future, gtk should be sufficient and GNOME would not 
be required to run Osogo?

>- Windows, Mac OSX, and others:  'Viewer' platforms.
>
>   At least osogo (which is a gtk application), or an alternative session monitor GUI if
>   gtk cannot be used, should run on these platforms.
>
>   These platforms are basically not intended for serious modeling, but for just running the
>   models constructed on the Linux/GNOME modeling environment. 
>   (e.g. demonstration, simulation experiments by biologists)
>  
>
I think it is a good approach. I feel cygwin is a slow platform for 
serious modelling.

>Because only a little part of Osogo uses GNOME components, it need not be full
>GNOME.  Gtk2 is enough.   Of course it's amazing if GNOME runs seamlessly on
>Windows.
>
> Can this do root-less mode?

At first I thought Gtk2 should be enough but it seems although Osogo 
uses a little part of gnome such as  gnome-python, this part in turn has 
other gnome dependencies (libgnome and libglade). So far I have 
installed the following packages on the native cygwin (latest version 
1.3.22-1) just to let ecell3 configure, compile and install without errors:

3. libxml2-2.5.4
4. libxslt-1.0.27
5. glib-2.2.1
6. linc-1.0.1
7. libIDL-0.8.0
8. ORBit2-2.6.1
9. intltool-0.25
10. bonobo-activation-2.2.1.1
11. libbonobo-2.2.1
12. pango-1.2.1
13. atk-1.2.2
14. gtk+-2.2.1
15. Gconf-2.2.0
16. gconf-editor-0.4.0
17. gnome-mime-data-2.2.0
18. gnome-vfs-2.2.3
19. audiofile-0.2.3
20. esound-0.2.29
21. libgnome-2.2.0.1
22. libart_lgpl-2.3.11
23. libglade-2.0.1

I installed them following the Gnome 2 installation order 
(http://www.gnome.org/start/2.2/notes/rninstallation.html). It is worth 
noting that there might still be some libraries in the above list that 
can be discarded. Nevertheless, at present when I try to run gecell on 
the Xwin, it says it requires gnome.ui. I am guessing the gnome.ui is in 
libgnomeui. To install libgnomeui the following libraries would need to 
be installed,

libgnomecanvas
libbonoboui
gnome-icon-theme
libgnomeui

Naturally, I have the same problem in rootless mode of Xwin. On the 
other hand, when I try to run ecell in scripting mode, ecell3-session, I 
also get some win32 error. This I am assuming is because I have not 
compiled ecell with correct parameters. I am working on this part now.

>Good!   Are the modifications ready to uploaded to CVS?
>  
>
I think not yet. I will let you know when it is ready. Hopefully I can 
show you something when you get here ( TTCK). Hubin told me that you 
will be coming here next week. May I know on which day?

satya

Satya,


Ok, the platform strategy I envision is like this:

- Linux/GNOME:   The primary platform.

   Everything including ecell3 core, osogo, SessionManager (distributed computing
   platform for ecell3), and the E-Cell Modeling Environment runs on this.
  
   The Modeling Environment, especially GUI parts, tweaks the full power of GNOME 
   at the cost of portability.    The core must stay portable, and Osogo should be
   able to run without GNOME, though.

   This makes sense because the primary target users of E-Cell are mainly bioinformatics
   specialists engaging in non-trivial modeling/simulation projects.    Such people are
   assumed to be able to prepare and feel comfortable with this main platform.


- Windows, Mac OSX, and others:  'Viewer' platforms.

   At least osogo (which is a gtk application), or an alternative session monitor GUI if
   gtk cannot be used, should run on these platforms.

   These platforms are basically not intended for serious modeling, but for just running the
   models constructed on the Linux/GNOME modeling environment. 
   (e.g. demonstration, simulation experiments by biologists)



> Yes, infact there is another site at sourceforge devoted to gnome2 on 
> cygwin. It is at,
> http://cygnome2.sourceforge.net/test-patches/

Can this do root-less mode?
Because only a little part of Osogo uses GNOME components, it need not be full
GNOME.  Gtk2 is enough.   Of course it's amazing if GNOME runs seamlessly on
Windows.
   

> They have released some preliminary patches for gnome2. I have installed 
> most of the gnome2 packages on cygwin. I have introduced some patches to 
> latest versions (1.99.16) of python gtk and gnome-python as well for 
> them to work on cygwin. After a lot of tweaking directly to the 
> configure files and makefiles of ecell3 (cvs version), I have finally 
> managed to compile it on cygwin without disabling gtk *with osogo*. 

Good!   Are the modifications ready to uploaded to CVS?


-sha

>>of these modules cannot coexist. I think once you change the name, it 
>>would also solve the problem. For the time being I have renamed ecs.py 
>>to ecs_.py. I have changed its calls in other modules as well.
>>    
>>
>
>One way is remove ECS.py completely and move the contents to __init__.py.
>This might be better.
>  
>
Ok then.

>By the way, is Windows port going well?
>
>
>It seems there are some projects working on gtk on Win32.   
>'Osogo on Windows' worth a try.
>  
>
Yes, infact there is another site at sourceforge devoted to gnome2 on 
cygwin. It is at,
http://cygnome2.sourceforge.net/test-patches/
They have released some preliminary patches for gnome2. I have installed 
most of the gnome2 packages on cygwin. I have introduced some patches to 
latest versions (1.99.16) of python gtk and gnome-python as well for 
them to work on cygwin. After a lot of tweaking directly to the 
configure files and makefiles of ecell3 (cvs version), I have finally 
managed to compile it on cygwin without disabling gtk *with osogo*. 
However, it does not work yet. I believe it because of some libraries 
which are not converted from static to dll files. I am working on it 
now. But I feel the prospects are quite good.

satya

>Native:
>
>http://www.gimp.org/~tml/gimp/win32/downloads.html
>
>and on CygWin.
>
>http://web.sfc.keio.ac.jp/~s01397ms/cygwin/index.html.en
>(incidentally he is a Keio student) 
>
>
>sha
>
>
>  
>

> About the renaming of the python module from 'ecell.ecs' to 'ecell.emc', 
> does that mean ecell.ecs will no longer exist? 

No.

Previously ecell.ecs held a single class 'Simulator', which is a python wrapper to
libemc's Simulator class.   There was an inconsistency.   It should have been named 
'ecell.emc' in the first place.

Now ecell.ecs has wrappers to libecs classes such as Process, VariableReference and
System.    It is not intended for frontend development.  Actually these classes are
not instantiatable from Python.
These classes are used in more low-level things such as the PythonProcess.


> because currently, there is a problem in cygwin due to the filename 
> conflict of ECS.py and ecs.py. Since cygwin is not case sensitve, both 
> of these modules cannot coexist. I think once you change the name, it 
> would also solve the problem. For the time being I have renamed ecs.py 
> to ecs_.py. I have changed its calls in other modules as well.

One way is remove ECS.py completely and move the contents to __init__.py.
This might be better.


By the way, is Windows port going well?


It seems there are some projects working on gtk on Win32.   
'Osogo on Windows' worth a try.

Native:

http://www.gimp.org/~tml/gimp/win32/downloads.html

and on CygWin.

http://web.sfc.keio.ac.jp/~s01397ms/cygwin/index.html.en
(incidentally he is a Keio student) 


sha

Hi shafi,

About the renaming of the python module from 'ecell.ecs' to 'ecell.emc', 
does that mean ecell.ecs will no longer exist? I would like to know 
because currently, there is a problem in cygwin due to the filename 
conflict of ECS.py and ecs.py. Since cygwin is not case sensitve, both 
of these modules cannot coexist. I think once you change the name, it 
would also solve the problem. For the time being I have renamed ecs.py 
to ecs_.py. I have changed its calls in other modules as well.

satya

Kouichi Takahashi wrote:

Kouichi Takahashi wrote:

>hi,
>
>One often-mentioned flaw of E-Cell was it forces users to write C++ code to add a new
>type of reaction mechanism.
>
>Now Python scripting of the simulation in EML is possible by two new DM classes;
>PythonProcess and PythonFluxProcess.    These works are based on code
>by Nayuta Iwata contributed this March.
>
>To implement this beautifully,  'ecell.ecs' module was renamed to 'ecell.emc'.
>'ecell.ecs' now holds classes used by the new PythonProcess classes.
>
>PythonFluxProcess can accept a Python expression which represents a simple continuous
>rate equations, such as michaelis-menten's equation.
>
>PythonProcess is more generic.   initialize() and process() methods 
>can be scripted in Python.
>
>
>I'll write a full documentation for the user's manual, but here is a brief introduction:
>
>To use PythonFluxProcess,  set an expression to 'Expression' property.
>For example,
>
>Process PythonFluxProcess( P )
>{
>    Expression "S0.Value * 1.3e-3";
>
>    VariableReferenceList [ S0 'Variable:.:S -1 ];
>}
>
>Here 'S0.Concentration * 1.3e-3' is the expression.  
>The expression must be evaluated to have a unit of [the number of molecules] / [sec]. 
>'S0' is a VariableReference object.  VariableReference has the following properties.     
>
>properties of VariableReference:
>
>S0.Concentration   -> concentration of S0, read-only
>S0.Value                ->  value of S0, read-write
>S0.Coefficient        ->  coefficient given to S0, in this case it is -1.   read-only
>S0.Fixed                ->  0 if false, non-zero if true.   read-only
>
>(It also has IsAccessor, TotalVelocity, and Velocity properties.)
>
>
>PythonProcess is more flexible.   InitializeMethod and ProcessMethod properties can be set.
>
>Process PythonProcess( P1 ) 
>{
>     InitializeMethod "Kcat = 1.0; Km = 1.0e-3";
>     ProcessMethod "self.setFlux( Kcat * S0.Concentration / ( Km + S0.Concentration ) )";
>
>     VariableReferenceList (...same as above...);
>}
>
>where 'self' is the Process object itself.    
>Process has some methods including the following:
>
>self.setFlux()
>self.addValue()
>self.getSuperSystem()
>
>properties of Processes are also available:
>
>self.Activity
>self.Priority
>self.StepperID
>
>meanings of these methods and properties are the same as the C++ version.
>Yes, PythonProcess is actually a FluxProcess.  The only difference between PythonProcess
>and PythonFluxProcess is the way it accepts Python code;  
>Expression or [Initialize/Process]Method.
>
>The setFlux() method also takes [num] / [sec].   To convert from concentration to [num],
>use getSuperSystem().VolumeN_A.
>
>ProcessMethod "self.setFlux( S0.Concentration * self.getSuperSytem().VolumeN_A * 1.3e-3 )";
>
>This can also be used in PythonFluxProcess:
>
>Expression "S0.Concentration * self.getSuperSytem().VolumeN_A * 1.3e-3";
>
>
>Currently EM does not support multi-line properties.   Taka-ken is now working to extend
>the EM syntax. 
>
>
>-sha
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Ecell-devel mailing list
>Ece...@li...
>https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
>  
>