This does not work with nrngui yet. Maybe IPython embeded shell does not know threads enough to not to block them. I may be able to have a look at the IPython/Shell.py later...
Or it might be something else when embeding python...
There are no specific plans in that regard. However, since NEURON is organized as a collection of shared objects, it seems to me that it would be straightforward to load the NEURON portion from a Python process.
As Micheal pointed out, doNotify() need to be called periodically in a separate thread to make mainmenu reacting to GUI operations.
IPython is doing similar things to GTK, Qt GUIs, but it is said to do it via python binding of those toolkits. Does anyone know of existence of an Interview python binding?
I should mention that there is a development branch for NEURON + Python at https://facets-vm3.kip.uni-heidelberg.d ... etsetcall/ http://neuralensemble.kip.uni-heidelber ... getsetcall
where changeset 17 contains a first pass at allowing NEURON to be an extension to Python. There are instructions in the log message about how to build and some
tentative discussion about how to put the
doNotify into a loop timer so InterViews can handle its window events.
The loop timer I have been experimenting with is (if you don't have an hh.ses file handy, comment that out and uncomment the nrngui.hoc load statement)
[hines@localhost npy]$ cat testext.py
import sys
sys.path.append("/home/hines/lib64/python")
import hoc
h = hoc.HocObject()
#h('load_file("nrngui.hoc")')
h('load_file("hh.ses")')
import threading
import time
def f() :
#h.doEvents()
h.doNotify()
#print "timer"
class LoopTimer(threading.Thread) :
"""
a Timer that calls f every interval
"""
def __init__(self, interval, fun) :
"""
@param interval: time in seconds between call to fun()
@param fun: the function to call on timer update
"""
self.interval = interval
self.fun = fun
threading.Thread.__init__(self)
self.setDaemon(True)
def run(self) :
while True:
self.fun()
time.sleep(self.interval)
timer = LoopTimer(.05, f)
timer.start()
print "hello"
[hines@localhost npy]$
eacheon wrote:
would an nrn.load_dll(path_to_so) be provided so external mechanisms can be loaded?
This sounds like a good idea to me, however I must admit I don't know the specifics of NEURON's mechanism loader. We did have some problems getting pynest to dynamically load external mechanisms, but we were trying to allow NEST/SLI calls to load mechanisms. A python call should be much less problematic to implement ... and the hoc dll loader should probably be disabled when using hoc as a python module ... with a message "please use nrn.load_mechanism(path_to_so)"
By referring to 'dll' I assume you are talking about the mswin version. Because some people have been experiencing difficulty on new machines with loading the old style nrnmech.dll (see https://www.neuron.yale.edu/phpBB2/viewtopic.php?t=750
11 Sep 2007 message by hines) I've switched to standard mswin dlls. As a side effect of this change there are now cygnrniv.dll and cygIVhines-3.dll which should be importable into python (and ipython) as well as the nrnmech.dll.