Conversation
|
Man, it must have been really late when I made the pull request. Problem with lab.separate() was super simple. Fixed now, as well as some bug fixes in messenger.c that I missed in my half-asleep state. |
Only compiled for mexa64. Also, miscelaneous PEP8 and doc updates and logging now includes _Session output.
|
rebase'd over my previous pull request, so this branch should be merge-able. Any thoughts on why it hasn't been merged, or is it just a not-enough-time thing? |
|
Just not-enough-time. I really want to sort out the Travis breakage on On Thu, Sep 10, 2015 at 10:35 PM, Bruno Beltran notifications@github.com
|
697868f to
a4feb32
Compare
|
Can I close this one? Looks like it's superseded by #218 |
|
Oh, didn't realize I had the inf-fix stuff over this branch. Putting it all in one place sounds fine to me. |
PR Contains:
The new convention for connecting to Matlab is that
follows the old behavior, while
connects to a Matlab sessions where the matlabserver.m function is being executed.
The only thing I'm having trouble getting to work is the new "separate" command, designed for when you've started a Matlab session via Matlab(executable=matlab).start() and later decide that what you need to do requires (or would just be nicer) if you were to drop into Matlab proper without having to save, exit, and reload the workspace. Combined with the ability to dynamically connect to Matlab, this could facilitate workflows that involve actively switching back and forth.
On my box, calling something like
lab = Matlab()
lab.start()
lab.separate()
opens the Matlab desktop GUI, as expected, but the ZMQ socket and context closing messages are mysteriously printed twice, and the GUI eventually exists without becoming available for use. Any ideas here?