I think that both of these issues can be solved by adding stuff here,
before starting the webserver:

https://github.com/arokem/python-matlab-bridge/blob/master/pymatbridge/pymatbridge.py#L84

both a call to dbclear all, to be on the safe side and also something
that would put an overloaded version of keyboard (that basically does
nothing?) to the top of the path. Does that sound about right?

On Tue, Jan 15, 2013 at 8:25 PM, Steven Pav [email protected]:

Some Matlab code passed to the server could cause it to hang indefinitely.
For example, calling a keyboard statement. Also, it is common practice to
have a
dbstop if error
in one's startup.m file. This has the same effect as %pdb in iPython:
when an error is encountered, the Matlab interpreter waits for user input.
This would be bad in the 'headless' environment of the web server.
At the very least we should have a
dbclear all in webserver.m
We should also try to overload keyboard.m
I have done this before, and it works, but it may depend on the order in
which paths are added.

There may be other lurking such gotchas, but these are the principal ones,
I think.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13.

oh, I see, put it in the python call. that might work.
I was thinking of adding some of this logic directly to webserver, but being able to switch it off with a 'debugging' flag (for testing the code from the Matlab command line). This is to keep the Matlab logic with the Matlab code, and because I'm not sure how long it might all get.

I'm not sure what the overloaded keyboard should do. throw a warning, then continue?

An alternative is to use that empty startup.m file that's in there, which
can be called in the python string before starting up the webserver. We can
put whatever matlab code we think needs to happen on startup in there. So -
call 'dbclear all' and put our 'matlab' directory at the top of the PATH
(so that overloaded functions get called).

That would still allow debugging things from the Matlab command line, and
would keep webserver clean.

On Wed, Jan 16, 2013 at 10:18 AM, Steven Pav [email protected]:

oh, I see, put it in the python call. that might work.
I was thinking of adding some of this logic directly to webserver, but
being able to switch it off with a 'debugging' flag (for testing the code
from the Matlab command line). This is to keep the Matlab logic with the
Matlab code, and because I'm not sure how long it might all get.

I'm not sure what the overloaded keyboard should do. throw a warning,
then continue?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-12332171.

in a large matlab install (uh, like the one I am taming), it is likely that the webserver.m tree will be installed without the startup.m file. Moreover, it is not terribly clear, from the MathWorks 'documentation,' whether a given startup.m file will be sourced. Typically if the directory from which Matlab is invoked contains a startup.m, it will be sourced, but that is not the case for pymatbridge. The fallback is ~/matlab/startup.m, then it looks through the rest of the path. For post R2008 or so, I think there is an option to set the environment variable MATLAB_USE_USERPATH and use userpath, but the precedence rules are not clear to me.
It still seems the safest option is to put it directly in webserver.m at the risk of adding another 'mode'.

I agree that we don't necessarily want to assume that this would run as a
standard startup file, because different things will happen in different
situations, as you pointed out.

Thinking about this a bit more maybe we should name this file something
else (prepare_matlab_environment.m?) and put it on the same tree as
webserver.m, and call that?

I am just thinking that we might want to avoid additional complication to
the webserver code, which may (or may not...) be useful in other contexts
that don't require these specific preparation steps. At this point, I think
we've converged on 6 of one or half-a-dozen of the other, though :-)

On Wed, Jan 16, 2013 at 2:55 PM, Steven Pav [email protected]:

in a large matlab install (uh, like the one I am taming), it is likely
that the webserver.m tree will be installed without the startup.m file.
Moreover, it is not terribly clear, from the MathWorks 'documentation,'
whether a given startup.m file will be sourced. Typically if the
directory from which Matlab is invoked contains a startup.m, it will be
sourced, but that is not the case for pymatbridge. The fallback is
~/matlab/startup.m, then it looks through the rest of the path. For post
R2008 or so, I think there is an option to set the environment variable *
MATLAB_USE_USERPATH* and use userpath, but the precedence rules are not
clear to me.
It still seems the safest option is to put it directly in webserver.m at
the risk of adding another 'mode'.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-12345239.

one 'solution' we had to running Matlab in headless mode was to create a directory of all the functions which had to be overridden (overrode?). I don't remember what was in it besides keyboard. Maybe there was input too. Then to switch to headless mode, there was a function that would add that subdirectory to the path.

If there was such a directory below the one containing webserver.m, then it would automatically get included by the addpath(genpath( )) call, but might not be added when debugging from Matlab UI (depending on one's path setup.)

That seems like a good solution. For example, adding a directory called
'overload' in some known location in our code and grabbing it on that
addpath call. We can start by adding keyboard in there and see what else
comes up. I guess that you would have to remember to manually add this
directory to your path when debugging.

On Thu, Jan 17, 2013 at 8:24 PM, Steven Pav [email protected]:

one 'solution' we had to running Matlab in headless mode was to create a
directory of all the functions which had to be overridden (overrode?). I
don't remember what was in it besides keyboard. Maybe there was inputtoo. Then to switch to headless mode, there was a function that would add
that subdirectory to the path.

If there was such a directory below the one containing webserver.m, then
it would automatically get included by the addpath(genpath( )) call, but
might not be added when debugging from Matlab UI (depending on one's path
setup.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-12407251.