www.neuron.yale.edu

I was having trouble debugging some hoc code, so finally I just copied the whole thing into another file (Debug.hoc, at the bottom of post) so I could remove everything that wasn't involved and isolate the problem. After lots of massaging, I pared the code down to the following example that demonstrates the problem. When I run the code in nrniv, I get this output:

oc>xopen("./Debug.hoc")
when initialized at beginning of template, n = 100
init(): was called
before reassigning n to 10, n = 0
after reassigning n to 10, n = 10
do_something(): was called
while doing_something, n = 0
do_something(): is finished
after doing_something, n = 0
init(): is finished
1
oc>

The first problem is that even though I initialize n to 100 at the beginning of the template, in init() it is 0.

The second problem is that once n is set to 10 in init(), calling do_something() sets it to 0 again. This doesn't happen if I remove the "objref o" line in do_something, or if I remove either "a = 0" or "b = 0".

I'm running:
NEURON -- Release 5.9.10 (1601) 2006-11-01
on a rather idiosyncratic Rev A Macbook Pro.

Debug.hoc
**************************************

begintemplate Debug

a = 0
b = 0
n = 100

proc init() {
print "init(): was called"
print "before reassigning n to 10, n = ", n
n = 10
print "after reassigning n to 10, n = ", n
do_something()
print "after doing_something, n = ", n
print "init(): is finished"
}

proc do_something() {
objref o
print "do_something(): was called"
print "while doing_something, n = ", n
print "do_something(): is finished"
}

print "when initialized at beginning of template, n = ", n

endtemplate Debug

objref dbg
dbg = new Debug()

**************************************

Two things are going on here. One has to do with the way direct commands
inside a template are handled. The other is a bug.

The statement
n = 100
is a direct command. Direct commands are executed just once: at the time
when hoc makes its first pass through your code. Variable assignment
statements such as this have only a temporary effect--to quote with slight
modification from page 368 of The NEURON Book, "the value of [n] is lost
when an actual object is created, because the assignment statement is not
executed at that time." So the first time that n had a zero value is not a
bug, but just the way direct commands inside a template work. If you
need to ensure that a variable has a nonzero value, assign it in proc init().

The bug exposes itself here: n should have kept its value of 10 (it does in the version of NEURON
that I'm running). And, of course, this kind of oddness

once n is set to 10 in init(), calling do_something() sets it to 0
again. This doesn't happen if I remove the "objref o" line in do_something,
or if I remove either "a = 0" or "b = 0".

just screams "BUG!" My suggestion is that you get a more recent release
of NEURON.

The only bug is that NEURON is
not producing an error message when
it encounters the "objref o" statement
in "proc do_something()" The hoc language requires that all objref, strdef,
and double declaration statements
are executed at the time the template is
created. That is when the symbol table
is constructed and it is supposed to be
impossible to add names to the symbol table when an object instance is created from the template. It IS possible and often desirable to REdeclare an objref or double
with different array bounds within a procedure. I will look into the reason why the error message is not being printed and try to fix that.