Thread Subject: Matlab 7.4 OSX

I am running OSX 10.4.9 on a PowerPC G5 (Dual 2.0 Ghz, 3.5GB RAM).
OpenSSH_4.2p1, OpenSSL 0.9.7l, XFree86 4.3.99.903(184).

I upgraded from Matlab 2006b (7.3) to 2007a (7.4) and now I cannot
remotely invoke Matlab with disabled jvm.

$ matlab -nojvm -nosplash

Returns error:

kCGErrorRangeCheck : Window Server communications from outside of
session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the
WindowServer.Abort

$ xeyes

Shows up fine, and Matlab 7.3 works as well.

Also, I don't know if this is a related issue in any way or a
separate issue altogether, but Matlab freezes periodically on Intel
Mac (iMac 2.0GHz Core Duo; 2 GB RAM). Both Matlab 7.3 and 7.4 are
being shared to machines via NFS.

Again, this all used to work seamlessly with 2006b (and still does).

Thanks,
Tim O'Keefe

... I am seeing exactly the same problem... Matlab 7.4, OS 10.4.9,
Powermac Quad 2.5 GHz. Works fine for Matlab 7.3.

 Timothy O'Keefe wrote:
>
>
> I am running OSX 10.4.9 on a PowerPC G5 (Dual 2.0 Ghz, 3.5GB RAM).
> OpenSSH_4.2p1, OpenSSL 0.9.7l, XFree86 4.3.99.903(184).
>
> I upgraded from Matlab 2006b (7.3) to 2007a (7.4) and now I cannot
> remotely invoke Matlab with disabled jvm.
>
> $ matlab -nojvm -nosplash
>
> Returns error:
>
> kCGErrorRangeCheck : Window Server communications from outside of
> session allowed for root and console user only
> INIT_Processeses(), could not establish the default connection to
> the
> WindowServer.Abort
>
> $ xeyes
>
> Shows up fine, and Matlab 7.3 works as well.
>
> Also, I don't know if this is a related issue in any way or a
> separate issue altogether, but Matlab freezes periodically on Intel
> Mac (iMac 2.0GHz Core Duo; 2 GB RAM). Both Matlab 7.3 and 7.4 are
> being shared to machines via NFS.
>
> Again, this all used to work seamlessly with 2006b (and still
> does).
>
> Thanks,
> Tim O'Keefe

Hi,

Starting with R2007a, some products now require console access and do
not require the JVM. For example, Simulink now implements some
non-X11-based windows.

You can work around this issue by using -nodisplay (or -nodisplay with
-nojvm). If you require graphics, you can save results to PDF or
another format and view them in the Preview application. If you really
want to use an X11 display or forwarding, you can alternatively work
around this issue by removing the console_owner check (which forces
-nodisplay) from the $matlabroot/bin/matlab script, and using
(undocumented) -noawt to significantly reduce the overhead of
initializing the Java JVM.

The reason this new requirement is made at startup is because products
which require console access also require a system call
NSApplicationLoad on the main thread, which will initialize a CFRunLoop
(the native Mac event loop), and run MATLAB on another thread.
Previously, a CFRunLoop was only required for the Java JVM, but it is
now required for products that don't use Java. This all has to happen
before MATLAB starts up.

This trend is expected to continue as we chip away at the X11/non-native
aspects of MATLAB on Mac OS X, but at the same time we will still seek
to find ways to continue to support the many non-console users, so
continue to let us know how you are running MATLAB on the Mac.

We apologize for the difficulties this may have caused,

- Brian

Mac Developer
The MathWorks, Inc.


Roger Kylin wrote:
> ... I am seeing exactly the same problem... Matlab 7.4, OS 10.4.9,
> Powermac Quad 2.5 GHz. Works fine for Matlab 7.3.
>
> Timothy O'Keefe wrote:
>>
>> I am running OSX 10.4.9 on a PowerPC G5 (Dual 2.0 Ghz, 3.5GB RAM).
>> OpenSSH_4.2p1, OpenSSL 0.9.7l, XFree86 4.3.99.903(184).
>>
>> I upgraded from Matlab 2006b (7.3) to 2007a (7.4) and now I cannot
>> remotely invoke Matlab with disabled jvm.
>>
>> $ matlab -nojvm -nosplash
>>
>> Returns error:
>>
>> kCGErrorRangeCheck : Window Server communications from outside of
>> session allowed for root and console user only
>> INIT_Processeses(), could not establish the default connection to
>> the
>> WindowServer.Abort
>>
>> $ xeyes
>>
>> Shows up fine, and Matlab 7.3 works as well.
>>
>> Also, I don't know if this is a related issue in any way or a
>> separate issue altogether, but Matlab freezes periodically on Intel
>> Mac (iMac 2.0GHz Core Duo; 2 GB RAM). Both Matlab 7.3 and 7.4 are
>> being shared to machines via NFS.
>>
>> Again, this all used to work seamlessly with 2006b (and still
>> does).
>>
>> Thanks,
>> Tim O'Keefe

We didn't have a problem with 2007a on the dual G5 but we did have a
problem on the new dual quad Intel based mac. I used Brian's answer
to modify the matlab script such that when it performs the check for
remote user it automatically appends the -noawt option so that all
you have to do when you log in remotely is to type matlab in the
terminal. At the same time this doesn't change anything for the
console user. Here's how it's done:
1. Open (sudo pico) the file /Application/MATLAB74/bin/matlab
2. search for console_owner in the file, you’ll get to the following
part of the script:

if [ "$jvmflag" = "1" -a "`id -un`" !=
"`$MATLAB/bin/$ARCH/console_owner`" -a "`id -un`" != "root" ]; then
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
        you=`id -un`
        owner=`$MATLAB/bin/$ARCH/console_owner`
        if [ "$debugger" = "" ]; then
            echo “some matlab warning about not being
                    allowed to use jvm”
            if [ "$nodisplay" = "0" ]; then
                arglist="$arglist -nodisplay"
            fi
        else
            echo “another matlab warning about not being
allowed to use jvm”
        fi
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  fi

3. remove

    "$jvmflag" = "1" –a

from the first line and

    if [ "$nodisplay" = "0" ]; then
       arglist="$arglist -nodisplay"
    fi

from inside the second if statement. Then add the line:

   arglist="$arglist -noawt"

after the line

   owner=…

but before the start of the if statement. Save changes. Now you
should be able to run matlab remotely by just typing matlab.

The fix works.

I would strongly urge the MathWorks not to remove the X11 support
from matlab on OS X completely. I know I'm not the only person who
runs matlab remotely a lot and X11 is crucial for that.

Not having the remote option makes the Mac a significantly less
attractive platform. Let me know a better place to post this if there
is one.

  Stefan

Stefan Llewellyn Smith wrote:
> I would strongly urge the MathWorks not to remove the X11 support
> from matlab on OS X completely. I know I'm not the only person who
> runs matlab remotely a lot and X11 is crucial for that.
>
> Not having the remote option makes the Mac a significantly less
> attractive platform. Let me know a better place to post this if
> there
> is one.

I agree, we are using the Mac version matlab remotely over X11 on
quad Powermac G5's.
Bernhard

Agreed.

I'm not necessarily concerned about being able to render X-window
graphics on OSX, but I'm pretty sure others do rely on this. I
already think it's bad that you can open a remote Matlab IDE on OSX
as you can on Linux, but I know what a pain X11 is.

On a more personal note, I would be extremely upset if MathWorks
moved to completely abandon the CLI interface *overall* within OSX's
Matlab. What am I going to do with this Mac cluster now? Serve
websites? ;)

Hi,

I appreciate this thread, keep your comments coming.

I'd like to clarify one thing: we will continue to support the CLI
interface on OS X and remote connections to and from OS X servers and
clients. This is also critical for MATLAB on the Mac platform working
with Distributed Computing Toolbox (which runs -nodisplay).

What's not as clear is the role of X11 interfaces on the Mac, and why
X11 is so important to some customers. We continue to receive
overwhelming feedback regarding how "non-native" the X11-based UIs are,
how poor the integration is with the rest of the OS, and customer
dissatisfaction and loss of productivity. As a result, the highest
priority for MathWorks Mac developers is to improve the user experience
and integration on the Mac platform.

If you simply can't live without an X11 connection, what is it about
MATLAB in X11 in particular that is critical to your workflow, and what
are the most important things that are currently missing with the Mac
X11 connection? Be very specific.

For Tiger (OS X 10.4), you could enable fast user switching and running
a multi-user VNC host, such as Vine Server. So, users who only needs
the CLI can use a low-bandwidth rsh or ssh connection, while users who
need to take advantage of MATLAB Desktop features or Toolbox UIs (such
as SimBiology) can connect to your server using a VNC client (such as
Chicken of the VNC), and have their own virtual desktop (not the
logged-in user's), with full desktop integration. This seems to me like
a much friendlier alternative to X11, and lets users -nojvm with R2007a
as well. Is this a viable alternative for some of you?

Apple's remote desktop energy in Leopard (OS X 10.5) is currently
focused on integrated screen sharing from the Finder, and "Back to my
Mac" for anywhere-access to a Mac, which Steve Jobs made public during
his Apple WWDC 2007 keynote presentation. These are other alternatives
that you may choose to support on your servers as well, once Leopard
becomes available.

You can find out more about the integrated screen sharing and "Back to
my Mac" here:

< http://www.apple.com/macosx/leopard/features/finder.html >
< http://www.apple.com/quicktime/qtv/wwdc07/ >

So, we could be giving customers a significantly better native Mac
experience if we supported MATLAB UIs more natively, and we could be
taking advantage of Apple innovations as well. To work towards both a
native Mac experience and an X11 experience would require us to split
our very limited Mac resources, and further delay our progress. Is that
really desirable, or are there other alternatives?

Let me know your thoughts,

- Brian

Brian Arnold
Mac Developer
The MathWorks, Inc.

Timothy O'Keefe wrote:
> Agreed.
>
> I'm not necessarily concerned about being able to render X-window
> graphics on OSX, but I'm pretty sure others do rely on this. I
> already think it's bad that you can open a remote Matlab IDE on OSX
> as you can on Linux, but I know what a pain X11 is.
>
> On a more personal note, I would be extremely upset if MathWorks
> moved to completely abandon the CLI interface *overall* within OSX's
> Matlab. What am I going to do with this Mac cluster now? Serve
> websites? ;)
>

Thank you for the response. What I am going to say is relevant only
to my use of matlab; I can't speak for anyone else.

I usually run matlab as a CLI from a window using -nojvm. It's what I
prefer. I use the full environment only for specific toolboxes which
require Java.

The critical thing about X11 is its ubiquity in general unix/linux
systems. I use a number of different machines (unix/linux) and this
way wherever I happen to be I can run matlab remotely (ssh -Y) on the
main OS X machine.

I know I can run matlab remotely without X and save figures in pdf
etc..., but that's just not efficient.

Sophisticated Leopard screen sharing might be extremely nice if I'm
on another Mac with it installed, but is not so generic. I admit I
don't fully understand what is being offered (I didn't watch the
video).

I'm not sure I understand the concerns users have with X11, for
example loss of productivity. Once matlab is running, figures are
figures and windows are windows. Is it purely installing X11? That
only needs to be done once and I would have thought most matlab users
would not find it difficult. I can see how the concerns about dual
X11/Mac development, but the entire linux matlab is X11-based so I
suppose it depends on where one makes a division between the two
platforms: above or below X11.

Hope this helps.

    Stefan

Brian Arnold wrote:
>
>
> Hi,
>
> I appreciate this thread, keep your comments coming.
>
> I'd like to clarify one thing: we will continue to support the CLI
> interface on OS X and remote connections to and from OS X servers
> and
> clients. This is also critical for MATLAB on the Mac platform
> working
> with Distributed Computing Toolbox (which runs -nodisplay).
>
> What's not as clear is the role of X11 interfaces on the Mac, and
> why
> X11 is so important to some customers. We continue to receive
> overwhelming feedback regarding how "non-native" the X11-based UIs
> are,
> how poor the integration is with the rest of the OS, and customer
> dissatisfaction and loss of productivity. As a result, the highest
>
> priority for MathWorks Mac developers is to improve the user
> experience
> and integration on the Mac platform.
>
> If you simply can't live without an X11 connection, what is it
> about
> MATLAB in X11 in particular that is critical to your workflow, and
> what
> are the most important things that are currently missing with the
> Mac
> X11 connection? Be very specific.
>
> For Tiger (OS X 10.4), you could enable fast user switching and
> running
> a multi-user VNC host, such as Vine Server. So, users who only
> needs
> the CLI can use a low-bandwidth rsh or ssh connection, while users
> who
> need to take advantage of MATLAB Desktop features or Toolbox UIs
> (such
> as SimBiology) can connect to your server using a VNC client (such
> as
> Chicken of the VNC), and have their own virtual desktop (not the
> logged-in user's), with full desktop integration. This seems to me
> like
> a much friendlier alternative to X11, and lets users -nojvm with
> R2007a
> as well. Is this a viable alternative for some of you?
>
> Apple's remote desktop energy in Leopard (OS X 10.5) is currently
> focused on integrated screen sharing from the Finder, and "Back to
> my
> Mac" for anywhere-access to a Mac, which Steve Jobs made public
> during
> his Apple WWDC 2007 keynote presentation. These are other
> alternatives
> that you may choose to support on your servers as well, once
> Leopard
> becomes available.
>
> You can find out more about the integrated screen sharing and "Back
> to
> my Mac" here:
>
> < <http://www.apple.com/macosx/leopard/features/finder.html> >
> < <http://www.apple.com/quicktime/qtv/wwdc07/> >
>
> So, we could be giving customers a significantly better native Mac
> experience if we supported MATLAB UIs more natively, and we could
> be
> taking advantage of Apple innovations as well. To work towards
> both a
> native Mac experience and an X11 experience would require us to
> split
> our very limited Mac resources, and further delay our progress. Is
> that
> really desirable, or are there other alternatives?
>
> Let me know your thoughts,
>
> - Brian
>
> Brian Arnold
> Mac Developer
> The MathWorks, Inc.
>
> Timothy O'Keefe wrote:
>> Agreed.
>>
>> I'm not necessarily concerned about being able to render
X-window
>> graphics on OSX, but I'm pretty sure others do rely on this. I
>> already think it's bad that you can open a remote Matlab IDE on
> OSX
>> as you can on Linux, but I know what a pain X11 is.
>>
>> On a more personal note, I would be extremely upset if
MathWorks
>> moved to completely abandon the CLI interface *overall* within
> OSX's
>> Matlab. What am I going to do with this Mac cluster now? Serve
>> websites? ;)
>>
>

In article <ef53b75.7@webcrossing.raydaftYaTP>,
 "Stefan Llewellyn Smith" <sgls@ucsd.edu> wrote:

> I usually run matlab as a CLI from a window using -nojvm. It's what I
> prefer. I use the full environment only for specific toolboxes which
> require Java.

FYI, you can use the plain CLI interface and Java by specifying the
-nodesktop option instead of -nojvm.

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

Dear Brian,

We want our cake and to eat it too.

If we are sitting in front of our mac , we want matlab to be pretty
and OS friendly. On the other hand giving up X11 loses much of the
functionality that we have come to depend on.

For example, on Linux, a single powerful server/workstation can run
multiple copies of matlab simultaneously. I can log in start a
matlab job and log out, and not have to worry about other users
logging in to the machine. Then i can log back in, display some
figures to see the progress of the job and log back out.

This is the functionality I want with OSX also.

But I think this tension is not specific to MATLAB. It is a general
problem with the OSX. For example, I have a mysql server running on
osx. There are nice gui tools that work when I'm sitting in front of
my mac, but these tools do not work over X11 (Although, the linux
versions of the tools do). If I'm sitting at a computer at another
university, I might not have permission to install the tools locally.
 

Would it be possible to change the graphics calls depending on
whether is ia console or remote user? So we can have our cake and
eat it too?

Another possibility is a flag at startup that tells matlab to run in
X11 mode or aqua mode. With X11 being the default mode, and the aqua
mode being set through Matlab.app

-Jeffrey Erlich

 Brian Arnold wrote:
>
>
> Hi,
>
> I appreciate this thread, keep your comments coming.
>
> I'd like to clarify one thing: we will continue to support the CLI
> interface on OS X and remote connections to and from OS X servers
> and
> clients. This is also critical for MATLAB on the Mac platform
> working
> with Distributed Computing Toolbox (which runs -nodisplay).
>
> What's not as clear is the role of X11 interfaces on the Mac, and
> why
> X11 is so important to some customers. We continue to receive
> overwhelming feedback regarding how "non-native" the X11-based UIs
> are,
> how poor the integration is with the rest of the OS, and customer
> dissatisfaction and loss of productivity. As a result, the highest
>
> priority for MathWorks Mac developers is to improve the user
> experience
> and integration on the Mac platform.
>
> If you simply can't live without an X11 connection, what is it
> about
> MATLAB in X11 in particular that is critical to your workflow, and
> what
> are the most important things that are currently missing with the
> Mac
> X11 connection? Be very specific.
>
> For Tiger (OS X 10.4), you could enable fast user switching and
> running
> a multi-user VNC host, such as Vine Server. So, users who only
> needs
> the CLI can use a low-bandwidth rsh or ssh connection, while users
> who
> need to take advantage of MATLAB Desktop features or Toolbox UIs
> (such
> as SimBiology) can connect to your server using a VNC client (such
> as
> Chicken of the VNC), and have their own virtual desktop (not the
> logged-in user's), with full desktop integration. This seems to me
> like
> a much friendlier alternative to X11, and lets users -nojvm with
> R2007a
> as well. Is this a viable alternative for some of you?
>
> Apple's remote desktop energy in Leopard (OS X 10.5) is currently
> focused on integrated screen sharing from the Finder, and "Back to
> my
> Mac" for anywhere-access to a Mac, which Steve Jobs made public
> during
> his Apple WWDC 2007 keynote presentation. These are other
> alternatives
> that you may choose to support on your servers as well, once
> Leopard
> becomes available.
>
> You can find out more about the integrated screen sharing and "Back
> to
> my Mac" here:
>
> < <http://www.apple.com/macosx/leopard/features/finder.html> >
> < <http://www.apple.com/quicktime/qtv/wwdc07/> >
>
> So, we could be giving customers a significantly better native Mac
> experience if we supported MATLAB UIs more natively, and we could
> be
> taking advantage of Apple innovations as well. To work towards
> both a
> native Mac experience and an X11 experience would require us to
> split
> our very limited Mac resources, and further delay our progress. Is
> that
> really desirable, or are there other alternatives?
>
> Let me know your thoughts,
>
> - Brian
>
> Brian Arnold
> Mac Developer
> The MathWorks, Inc.
>
> Timothy O'Keefe wrote:
>> Agreed.
>>
>> I'm not necessarily concerned about being able to render
X-window
>> graphics on OSX, but I'm pretty sure others do rely on this. I
>> already think it's bad that you can open a remote Matlab IDE on
> OSX
>> as you can on Linux, but I know what a pain X11 is.
>>
>> On a more personal note, I would be extremely upset if
MathWorks
>> moved to completely abandon the CLI interface *overall* within
> OSX's
>> Matlab. What am I going to do with this Mac cluster now? Serve
>> websites? ;)
>>
>

Honestly, I know certain people will jump on me for saying this, but,
if you think Matlab can be *that much better* by abandoning X11
support, then so be it.

Personally, I think dividing your efforts so that you can maintain
this hybrid native/X11 OSX Matlab is not worth it. You could use the
extra time to develop other things..... like a DAT Toolbox >:(

If you REALLY REALLY REALLY need remote X11 graphics, just go with
Linux; or invoke Matlab remotely from a Linux machine somewhere. Will
Matlab install on Linux running on a PowerPC or Intel Mac?

-T

In article <ef53b75.10@webcrossing.raydaftYaTP>,
Tim O'Keefe <timo@brown.edu> wrote:

>If you REALLY REALLY REALLY need remote X11 graphics, just go with
>Linux; or invoke Matlab remotely from a Linux machine somewhere.

Let's see.. my wife's Mac sitting across the room from me; my wife's
faster Mac sitting beside me; or ssh to the bastion machines
at work and ssh from there to one of work's Linux servers.
Good response; very good response; or literally 73 seconds to
bring up Matlab across the network.

Gee, Tim, could I *please* *please* have the option that takes
18 seconds to get a response from pressing a key, and which
drops a third of the keys that I type?
--
  "law -- it's a commodity"
                         -- Andrew Ryan (The Globe and Mail, 2005/11/26)

Tim,

Let's assume (safely) that Mathworks is going to continue to develop
the linux matlab with full X11 support.

The question then becomes, how much extra work is it to port (and
support) an X11 version for mac? My naive expectation, is that it
isn't that hard. Many free X11 software projects compile on macs
with no problem. Why can't Matlab do the same?

-Jeff

 Tim O'Keefe wrote:
>
>
> Honestly, I know certain people will jump on me for saying this,
> but,
> if you think Matlab can be *that much better* by abandoning X11
> support, then so be it.
>
> Personally, I think dividing your efforts so that you can maintain
> this hybrid native/X11 OSX Matlab is not worth it. You could use
> the
> extra time to develop other things..... like a DAT Toolbox >:(
>
> If you REALLY REALLY REALLY need remote X11 graphics, just go with
> Linux; or invoke Matlab remotely from a Linux machine somewhere.
> Will
> Matlab install on Linux running on a PowerPC or Intel Mac?
>
> -T

If it was easy, and an attractive solution for MathWorks (to port
everything as X11 to the Mac), that's the way it would be. But for
*whatever* reason (and they have explained why), they don't want to.

To quote Brian (from earlier):

"We could be giving customers a significantly better native Mac
experience if we supported MATLAB UIs more natively, and we could be
taking advantage of Apple innovations as well. To work towards both a
native Mac experience and an X11 experience would require us to split
our very limited Mac resources, and further delay our progress."

In response to this, I say, the sprinkling of X11 in the OSX build is
not worth (in my opinion) the absence of certain functionality and
toolboxes that are found in Windows and Linux Matlab e.g., DAT
Toolbox, Instrument Control Toolbox, etc. These aren't just minor
hobblings either; this is simply an incomplete distribution.

... and of course, with Vine Server/Viewer and new Leopard features,
there are alternatives to X11. They may not be pretty, but they're
out there. And Windows users are still alive.

Jeffrey Erlich wrote:
>
>
> Tim,
>
> Let's assume (safely) that Mathworks is going to continue to
> develop
> the linux matlab with full X11 support.
>
> The question then becomes, how much extra work is it to port (and
> support) an X11 version for mac? My naive expectation, is that it
> isn't that hard. Many free X11 software projects compile on macs
> with no problem. Why can't Matlab do the same?
>
> -Jeff
>
> Tim O'Keefe wrote:
>>
>>
>> Honestly, I know certain people will jump on me for saying
this,
>> but,
>> if you think Matlab can be *that much better* by abandoning X11
>> support, then so be it.
>>
>> Personally, I think dividing your efforts so that you can
> maintain
>> this hybrid native/X11 OSX Matlab is not worth it. You could
use
>> the
>> extra time to develop other things..... like a DAT Toolbox
>:(
>>
>> If you REALLY REALLY REALLY need remote X11 graphics, just go
> with
>> Linux; or invoke Matlab remotely from a Linux machine
somewhere.
>> Will
>> Matlab install on Linux running on a PowerPC or Intel Mac?
>>
>> -T

I don't know anybody working on a Mac complaining about not having a
"full experience". Most of the people I know using macs are doing so
because they don't like the "wonderful experience" they got on
windows machines (otherwise they would move to windows and have the
full experience of marvels that the windows matlab version has to
offer). As far as I am concerned, the loss of a X11 version for mac
would eliminate the advantage of a mac: the mac offers ease of
administration and the media type of programs one can find on windows
combined with the possibility of compiling and running programs UNIX
style (remotely, in the background, all that and more). I don't know
what exactly people don't experience on the mac version of matlab,
but let me tell you what I experienced on the windows version of it:
trouble with C and Forstran compilers, trouble running in the
background, trouble running a loop that calls stand alone C or
Fortran executables (the workaround involving Cygwin and a lot of
wasted time to get it work properly). Remembering my last experience
with Matlab on Windows sends shivers down my spine, so if X11 Matlab
disappears on macs, I'll probably move to linux machines... But
that's just me.

calin wrote:
>
>
> I don't know anybody working on a Mac complaining about not having
> a
> "full experience". Most of the people I know using macs are doing
> so
> because they don't like the "wonderful experience" they got on
> windows machines (otherwise they would move to windows and have the
> full experience of marvels that the windows matlab version has to
> offer). As far as I am concerned, the loss of a X11 version for mac
> would eliminate the advantage of a mac: the mac offers ease of
> administration and the media type of programs one can find on
> windows
> combined with the possibility of compiling and running programs
> UNIX
> style (remotely, in the background, all that and more). I don't
> know
> what exactly people don't experience on the mac version of matlab,
> but let me tell you what I experienced on the windows version of
> it:
> trouble with C and Forstran compilers, trouble running in the
> background, trouble running a loop that calls stand alone C or
> Fortran executables (the workaround involving Cygwin and a lot of
> wasted time to get it work properly). Remembering my last
> experience
> with Matlab on Windows sends shivers down my spine, so if X11
> Matlab
> disappears on macs, I'll probably move to linux machines... But
> that's just me.

 
The problem is, people DO want different things. For you, remote
operation and compiling are important, and X11 seems to be a
necessity. I don't work remotely, I don't compile, but I spend my
days working in Simulink with huge models and the X11 version of
Simulink has an awful GUI that makes me nervous after 10 minutes
(even the delete key works differently in different Simulink windows.
For me, that's UNACCEPTABLE).
I ended up running Parallels on my Mac just for Simulink - i.e., a
program that is officially supported... If I had known of such
problems in advance, I wouldn't have bought a Mac.
Honestly, I think TMW should just find out how many Mac users would
prefer doing away with X11 for a more Mac-like, native interface or
keep X11 for Linux-style features at the expense of interface
coherence (and, for me, productivity). The minority will have to use
PCs, or virtualization, or bootcamp, whatever, to run Win or Linux;
the majority should have the right to fully enjoy using Matlab on
their macs.
Of course, in an ideal world, both groups would be satisfied at the
same time, but it doesn't look like that's a possibility...

Claude

Hi

I fully echo Stefan's earlier post. Matlab on Mac derives
its usefulness from the fact that I can run it remotely
via ssh from any unix/linux box. Apart from running matlab
on my mac laptop, this is the most typical usage for myself
and many of my colleagues. The fact that X11 is central to
this makes this thread truly alarming.

Yes, there are alternatives such as VNC, which in fact I use
extensively to connect between Mac's. But there is no guarantee that
such software will be available when I need it (and is often not on
linux boxes), while X11 is always
there and always works.

Surely, Matlab on Mac has more serious problems than a
"non native" UI. How about expending the effort on providing
64 bit support, multithreading the sparse matrix kernels, etc etc?

Samar

"Samar Khatiwala" <spk@ldeo.columbia.edu> wrote in message
news:ef53b75.16@webcrossing.raydaftYaTP...
> Hi
>
> I fully echo Stefan's earlier post. Matlab on Mac derives
> its usefulness from the fact that I can run it remotely
> via ssh from any unix/linux box. Apart from running matlab
> on my mac laptop, this is the most typical usage for myself
> and many of my colleagues. The fact that X11 is central to
> this makes this thread truly alarming.
>
> Yes, there are alternatives such as VNC, which in fact I use
> extensively to connect between Mac's. But there is no guarantee that
> such software will be available when I need it (and is often not on
> linux boxes), while X11 is always
> there and always works.
>
> Surely, Matlab on Mac has more serious problems than a
> "non native" UI. How about expending the effort on providing
> 64 bit support, multithreading the sparse matrix kernels, etc etc?

There are lots of developers working on different aspects of MATLAB. The
developers working on the MATLAB user interface are not necessarily the same
developers who work on the language and who would need to be the ones to add
64-bit support to the language or the developers who work on sparse matrices
and would need to be the ones who add multithreading capability to sparse
matrices. You can see this if you look at the Careers section of our
website:

http://www.mathworks.com/company/jobs/

If you look just at MATLAB developer positions, you'll see for instance that
we have graphics developer positions, deployment developer positions, GUI
developer positions, language developer positions, etc.

BTW, as a shameless plug for anybody interested in any positions they see on
that webpage, this is a pretty good place to work. Just thought I'd mention
it :)

--
Steve Lord
slord@mathworks.com

Steven Lord wrote:
>
>
>
> "Samar Khatiwala" <spk@ldeo.columbia.edu> wrote in message
> news:ef53b75.16@webcrossing.raydaftYaTP...
>> Hi
>>
>> I fully echo Stefan's earlier post. Matlab on Mac derives
>> its usefulness from the fact that I can run it remotely
>> via ssh from any unix/linux box. Apart from running matlab
>> on my mac laptop, this is the most typical usage for myself
>> and many of my colleagues. The fact that X11 is central to
>> this makes this thread truly alarming.
>>
>> Yes, there are alternatives such as VNC, which in fact I use
>> extensively to connect between Mac's. But there is no guarantee
> that
>> such software will be available when I need it (and is often
not
> on
>> linux boxes), while X11 is always
>> there and always works.
>>
>> Surely, Matlab on Mac has more serious problems than a
>> "non native" UI. How about expending the effort on providing
>> 64 bit support, multithreading the sparse matrix kernels, etc
> etc?
>
> There are lots of developers working on different aspects of
> MATLAB. The
> developers working on the MATLAB user interface are not necessarily
> the same
> developers who work on the language and who would need to be the
> ones to add
> 64-bit support to the language or the developers who work on sparse
> matrices
> and would need to be the ones who add multithreading capability to
> sparse
> matrices. You can see this if you look at the Careers section of
> our
> website:
>
> <http://www.mathworks.com/company/jobs/>
>
> If you look just at MATLAB developer positions, you'll see for
> instance that
> we have graphics developer positions, deployment developer
> positions, GUI
> developer positions, language developer positions, etc.
>
> BTW, as a shameless plug for anybody interested in any positions
> they see on
> that webpage, this is a pretty good place to work. Just thought
> I'd mention
> it :)
>
> --
> Steve Lord
> slord@mathworks.com
>
>
>

Hi,

I don't want anyone to feel alarmed by this discussion; nothing is set
in stone. I appreciate hearing the whole gamut of what works, what
doesn't, how different people are using the Mac version, and what all of
the different customer needs and requirements are. If you communicate
your needs clearly enough, it helps us avoid doing the wrong thing. And
if you see enough conflict between different requirements, it might help
some of you understand why we are attempting to do things that may be in
conflict with your particular requirements.

I'd like to clarify a few things:

- MATLAB Desktop's UI and significant Toolboxes such as SimBiology and
Distributed Computing Toolbox leverage Apple's Java, which in turn
leverages Apple's Cocoa framework for a native OS X user experience.
None of these UIs function over an X11 connection, because Apple's Java
doesn't support this. This is the most significant distinction between
Linux/Solaris versions of MATLAB, and the Mac version. We would not
like to be in the business of porting and maintaining a ported version
of Sun's (X11-based) Java on OS X.

- There is an X11 implementation of Figures which does run on the Mac,
and works, but has had unexpected costs both in terms of maintenance and
consistency, because of the integration required with Simulink and the
Desktop UI. If you run with -nodesktop or -nojvm, you may not be aware
of how painful it is.

- For those who use Simulink, its UI in the past was developed using X11
directly, but is now increasingly using TrollTech Qt, which is
Carbon-based on the Mac platform. In R2007a, Simulink is an X11/Carbon
hybrid. We no longer would like to maintain a port of the X11 version
of Qt, for the same reason that we would not like to be in the business
of maintaining a non-Apple X11-based Java on OS X.

- For those of you who adamantly oppose the loss of X11 forwarding, I'd
like to assure you that if we can sustain X11-forwarding support for
your usage models, we will try to do so, but we're not likely to grow
the support (for the reasons I have outlined earlier, which have been
re-posted). In order to help us set priorities, can you please
articulate what is coming over the X11 pipe (from a Mac MATLAB) that you
require? Is it simply data visualization in Figures, is it one of the
the legacy UI's built using Figures, or are there other requirements?
Are you missing out on Toolboxes and features in new releases which
currently require Java? If so, which ones? What is holding you back
from exploring other options (besides X11 forwarding)?

Please continue with this dialog, thanks,

Brian

mostafa ahmed wrote:
> Steven Lord wrote:
>
>>
>> "Samar Khatiwala" <spk@ldeo.columbia.edu> wrote in message
>> news:ef53b75.16@webcrossing.raydaftYaTP...
>>
>>> Hi
>>>
>>> I fully echo Stefan's earlier post. Matlab on Mac derives
>>> its usefulness from the fact that I can run it remotely
>>> via ssh from any unix/linux box. Apart from running matlab
>>> on my mac laptop, this is the most typical usage for myself
>>> and many of my colleagues. The fact that X11 is central to
>>> this makes this thread truly alarming.
>>>
>>> Yes, there are alternatives such as VNC, which in fact I use
>>> extensively to connect between Mac's. But there is no guarantee
>>>
>> that
>>
>>> such software will be available when I need it (and is often
>>>
> not
>
>> on
>>
>>> linux boxes), while X11 is always
>>> there and always works.
>>>
>>> Surely, Matlab on Mac has more serious problems than a
>>> "non native" UI. How about expending the effort on providing
>>> 64 bit support, multithreading the sparse matrix kernels, etc
>>>
>> etc?
>>
>> There are lots of developers working on different aspects of
>> MATLAB. The
>> developers working on the MATLAB user interface are not necessarily
>> the same
>> developers who work on the language and who would need to be the
>> ones to add
>> 64-bit support to the language or the developers who work on sparse
>> matrices
>> and would need to be the ones who add multithreading capability to
>> sparse
>> matrices. You can see this if you look at the Careers section of
>> our
>> website:
>>
>> <http://www.mathworks.com/company/jobs/>
>>
>> If you look just at MATLAB developer positions, you'll see for
>> instance that
>> we have graphics developer positions, deployment developer
>> positions, GUI
>> developer positions, language developer positions, etc.
>>
>> BTW, as a shameless plug for anybody interested in any positions
>> they see on
>> that webpage, this is a pretty good place to work. Just thought
>> I'd mention
>> it :)
>>
>> --
>> Steve Lord
>> slord@mathworks.com
>>
>>
>>
>>

Data visualization in figures while running CLI remotely. I don't
care about anything else.

I assume the "Figures" that you refer to in your second paragraph is
something different. I'm talking about figure(1); plot; etc...
running remotely.

Sorry if I'm repeating myself.

  Stefan

 Brian Arnold wrote:
>
>
> Hi,
>
> I don't want anyone to feel alarmed by this discussion; nothing is
> set
> in stone. I appreciate hearing the whole gamut of what works, what
>
> doesn't, how different people are using the Mac version, and what
> all of
> the different customer needs and requirements are. If you
> communicate
> your needs clearly enough, it helps us avoid doing the wrong thing.
> And
> if you see enough conflict between different requirements, it might
> help
> some of you understand why we are attempting to do things that may
> be in
> conflict with your particular requirements.
>
> I'd like to clarify a few things:
>
> - MATLAB Desktop's UI and significant Toolboxes such as SimBiology
> and
> Distributed Computing Toolbox leverage Apple's Java, which in turn
> leverages Apple's Cocoa framework for a native OS X user
> experience.
> None of these UIs function over an X11 connection, because Apple's
> Java
> doesn't support this. This is the most significant distinction
> between
> Linux/Solaris versions of MATLAB, and the Mac version. We would
> not
> like to be in the business of porting and maintaining a ported
> version
> of Sun's (X11-based) Java on OS X.
>
> - There is an X11 implementation of Figures which does run on the
> Mac,
> and works, but has had unexpected costs both in terms of
> maintenance and
> consistency, because of the integration required with Simulink and
> the
> Desktop UI. If you run with -nodesktop or -nojvm, you may not be
> aware
> of how painful it is.
>
> - For those who use Simulink, its UI in the past was developed
> using X11
> directly, but is now increasingly using TrollTech Qt, which is
> Carbon-based on the Mac platform. In R2007a, Simulink is an
> X11/Carbon
> hybrid. We no longer would like to maintain a port of the X11
> version
> of Qt, for the same reason that we would not like to be in the
> business
> of maintaining a non-Apple X11-based Java on OS X.
>
> - For those of you who adamantly oppose the loss of X11 forwarding,
> I'd
> like to assure you that if we can sustain X11-forwarding support
> for
> your usage models, we will try to do so, but we're not likely to
> grow
> the support (for the reasons I have outlined earlier, which have
> been
> re-posted). In order to help us set priorities, can you please
> articulate what is coming over the X11 pipe (from a Mac MATLAB)
> that you
> require? Is it simply data visualization in Figures, is it one of
> the
> the legacy UI's built using Figures, or are there other
> requirements?
> Are you missing out on Toolboxes and features in new releases which
>
> currently require Java? If so, which ones? What is holding you
> back
> from exploring other options (besides X11 forwarding)?
>
> Please continue with this dialog, thanks,
>
> Brian
>
> mostafa ahmed wrote:
>> Steven Lord wrote:
>>
>>>
>>> "Samar Khatiwala" <spk@ldeo.columbia.edu> wrote in
message
>>> news:ef53b75.16@webcrossing.raydaftYaTP...
>>>
>>>> Hi
>>>>
>>>> I fully echo Stefan's earlier post. Matlab on Mac
derives
>>>> its usefulness from the fact that I can run it remotely
>>>> via ssh from any unix/linux box. Apart from running
matlab
>>>> on my mac laptop, this is the most typical usage for
myself
>>>> and many of my colleagues. The fact that X11 is central
to
>>>> this makes this thread truly alarming.
>>>>
>>>> Yes, there are alternatives such as VNC, which in fact
I use
>>>> extensively to connect between Mac's. But there is no
guarantee
>>>>
>>> that
>>>
>>>> such software will be available when I need it (and is
often
>>>>
>> not
>>
>>> on
>>>
>>>> linux boxes), while X11 is always
>>>> there and always works.
>>>>
>>>> Surely, Matlab on Mac has more serious problems than a
>>>> "non native" UI. How about expending the effort on
providing
>>>> 64 bit support, multithreading the sparse matrix
kernels, etc
>>>>
>>> etc?
>>>
>>> There are lots of developers working on different aspects
of
>>> MATLAB. The
>>> developers working on the MATLAB user interface are not
> necessarily
>>> the same
>>> developers who work on the language and who would need to
be the
>>> ones to add
>>> 64-bit support to the language or the developers who work
on
> sparse
>>> matrices
>>> and would need to be the ones who add multithreading
capability
> to
>>> sparse
>>> matrices. You can see this if you look at the Careers
section of
>>> our
>>> website:
>>>
>>> <http://www.mathworks.com/company/jobs/>
>>>
>>> If you look just at MATLAB developer positions, you'll see
for
>>> instance that
>>> we have graphics developer positions, deployment developer
>>> positions, GUI
>>> developer positions, language developer positions, etc.
>>>
>>> BTW, as a shameless plug for anybody interested in any
positions
>>> they see on
>>> that webpage, this is a pretty good place to work. Just
thought
>>> I'd mention
>>> it :)
>>>
>>> --
>>> Steve Lord
>>> slord@mathworks.com
>>>
>>>
>>>
>>>
>

Apologies for including only the post with the suggested fix to
running MATLAB remotely from OSX...

I removed & added as pointed out in step 3, but I still have no
graphic display when running matlab remotely from the Mac Os X server
we have here. Shouldn't I get the graphic display with this
workaround? Or did I misunderstand something within this thread?

Now, when I try to run matlab remotely it displays the software
membrane logo (which it's an improvement from what I use to get when
I tried to run it remotely)... but afterwards it returns to the
command line output in my xterm.

The resulting matlab script (portion) I have is:

    if [ "`id -un`" != "`$MATLAB/bin/$ARCH/console_owner`" -a "`id
-un`" != "root" ];
 then
#+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++
        you=`id -un`
        owner=`$MATLAB/bin/$ARCH/console_owner`
        arglist="$arglist -noawt"
        if [ "$debugger" = "" ]; then
            echo
"-------------------------------------------------------------------
--------"
            echo "no console message..."
            echo
"-------------------------------------------------------------------
--------"
        else
            echo
"-------------------------------------------------------------------
--------"
            echo "debug message..."
            echo
"-------------------------------------------------------------------
--------"
        fi
#+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++
    fi
fi
if [ "$jvmflag" = "0" ]; then
    arglist="$arglist -nojvm"
elif [ "$desktopflag" = "0" ]; then
    arglist="$arglist -nodesktop"
fi

Am I missing something here? Should I also do something else (like
in the last IF), to get the graphics & desktop on my remote session?

Thanks for your help.

Mauricio

 Calin wrote:
>
>
> We didn't have a problem with 2007a on the dual G5 but we did have
> a
> problem on the new dual quad Intel based mac. I used Brian's answer
> to modify the matlab script such that when it performs the check
> for
> remote user it automatically appends the -noawt option so that all
> you have to do when you log in remotely is to type matlab in the
> terminal. At the same time this doesn't change anything for the
> console user. Here's how it's done:
> 1. Open (sudo pico) the file /Application/MATLAB74/bin/matlab
> 2. search for console_owner in the file, you’ll get to the
> following
> part of the script:
>
> if [ "$jvmflag" = "1" -a "`id -un`" !=
> "`$MATLAB/bin/$ARCH/console_owner`" -a "`id -un`" != "root" ]; then
> #++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> you=`id -un`
> owner=`$MATLAB/bin/$ARCH/console_owner`
> if [ "$debugger" = "" ]; then
> echo “some matlab warning about not being
> allowed to use jvm”
> if [ "$nodisplay" = "0" ]; then
> arglist="$arglist -nodisplay"
> fi
> else
> echo “another matlab warning about not being
> allowed to use jvm”
> fi
> #++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> fi
>
> 3. remove
>
> "$jvmflag" = "1" –a
>
> from the first line and
>
> if [ "$nodisplay" = "0" ]; then
> arglist="$arglist -nodisplay"
> fi
>
> from inside the second if statement. Then add the line:
>
> arglist="$arglist -noawt"
>
> after the line
>
> owner=…
>
> but before the start of the if statement. Save changes. Now you
> should be able to run matlab remotely by just typing matlab.

Hi,

That is the correct behavior on OS X. MATLAB on Mac OS X never
supported running the MATLAB Desktop through X11 forwarding, because it
is built using Java, and Apple's Java does not support X11 forwarding.

In this mode, you will only be able to display some graphics (plots and
Figure-based GUIs) if the server has X11 forwarding enabled and the
client and server are set up to do the forwarding to the client. But
not the MATLAB Desktop.

- Brian

Mauricio Argote-Cortes wrote:
> Apologies for including only the post with the suggested fix to
> running MATLAB remotely from OSX...
>
> I removed & added as pointed out in step 3, but I still have no
> graphic display when running matlab remotely from the Mac Os X server
> we have here. Shouldn't I get the graphic display with this
> workaround? Or did I misunderstand something within this thread?
>
> Now, when I try to run matlab remotely it displays the software
> membrane logo (which it's an improvement from what I use to get when
> I tried to run it remotely)... but afterwards it returns to the
> command line output in my xterm.
>
> The resulting matlab script (portion) I have is:
>
> if [ "`id -un`" != "`$MATLAB/bin/$ARCH/console_owner`" -a "`id
> -un`" != "root" ];
> then
> #+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++
> you=`id -un`
> owner=`$MATLAB/bin/$ARCH/console_owner`
> arglist="$arglist -noawt"
> if [ "$debugger" = "" ]; then
> echo
> "-------------------------------------------------------------------
> --------"
> echo "no console message..."
> echo
> "-------------------------------------------------------------------
> --------"
> else
> echo
> "-------------------------------------------------------------------
> --------"
> echo "debug message..."
> echo
> "-------------------------------------------------------------------
> --------"
> fi
> #+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++
> fi
> fi
> if [ "$jvmflag" = "0" ]; then
> arglist="$arglist -nojvm"
> elif [ "$desktopflag" = "0" ]; then
> arglist="$arglist -nodesktop"
> fi
>
> Am I missing something here? Should I also do something else (like
> in the last IF), to get the graphics & desktop on my remote session?
>
> Thanks for your help.
>
> Mauricio
>
> Calin wrote:
>>
>> We didn't have a problem with 2007a on the dual G5 but we did have
>> a
>> problem on the new dual quad Intel based mac. I used Brian's answer
>> to modify the matlab script such that when it performs the check
>> for
>> remote user it automatically appends the -noawt option so that all
>> you have to do when you log in remotely is to type matlab in the
>> terminal. At the same time this doesn't change anything for the
>> console user. Here's how it's done:
>> 1. Open (sudo pico) the file /Application/MATLAB74/bin/matlab
>> 2. search for console_owner in the file, you’ll get to the
>> following
>> part of the script:
>>
>> if [ "$jvmflag" = "1" -a "`id -un`" !=
>> "`$MATLAB/bin/$ARCH/console_owner`" -a "`id -un`" != "root" ]; then
>> #++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> you=`id -un`
>> owner=`$MATLAB/bin/$ARCH/console_owner`
>> if [ "$debugger" = "" ]; then
>> echo “some matlab warning about not being
>> allowed to use jvm”
>> if [ "$nodisplay" = "0" ]; then
>> arglist="$arglist -nodisplay"
>> fi
>> else
>> echo “another matlab warning about not being
>> allowed to use jvm”
>> fi
>> #++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> fi
>>
>> 3. remove
>>
>> "$jvmflag" = "1" –a
>>
>> from the first line and
>>
>> if [ "$nodisplay" = "0" ]; then
>> arglist="$arglist -nodisplay"
>> fi
>>
>> from inside the second if statement. Then add the line:
>>
>> arglist="$arglist -noawt"
>>
>> after the line
>>
>> owner=…
>>
>> but before the start of the if statement. Save changes. Now you
>> should be able to run matlab remotely by just typing matlab.

This issue affected our lab of about 6 grad students as
well. We don't regularly forward anything over X11, but
it is VERY important that we have remote command line access
as any user. We have a small farm (about 5, soon to be
about 10) of intel and ppc macs that we distribute
experiments on.

As others point out, having portions of the interface
forwardable over X11 is very nice functionality, but it is
not critical in our particular mode of usage.

Thanks for being so responsive!
Drew, Shankar, et al at UIUC

I just tried this and met with partial success. When a user
logging in remotely is NOT currently the console user, it
works just fine modulo the following warning:

"Process Manager already initialized can't fully enable
headless mode"

However, if the remote user happens to also be the console
user, a dock icon opens up. That is a minor annoyance, but
what is a real problem is that then when the console logs
out, the remote session is toasted. Our expected behavior
is for the remote session to not interact with the console
session at all, aside from an extra entry or two in the
(usually invisible) process list.

Thanks,
Drew

Calin <buia@physics.unc.edu> wrote in message
<ef53b75.2@webcrossing.raydaftYaTP>...
 I used Brian's answer
> to modify the matlab script such that when it performs the
check for
> remote user it automatically appends the -noawt option so
that all
> you have to do when you log in remotely is to type matlab
in the
> terminal. At the same time this doesn't change anything
for the
> console user. Here's how it's done:
> 1. Open (sudo pico) the file
...

I agree that data vis via figures while running CLI remotely
is the primary feature that I need while running MATLAB
remotely on my work Mac Pro. Just for clarification because
I cannot seem to find a clear answer anywhere, does this
actually work presently in a MATLAB R2007a installation on
Mac OS X? Are the steps to enable it non-trivial?




"Stefan Llewellyn Smith" <sgls@ucsd.edu> wrote in message
<ef53b75.20@webcrossing.raydaftYaTP>...
> Data visualization in figures while running CLI remotely.
I don't
> care about anything else.
>
> I assume the "Figures" that you refer to in your second
paragraph is
> something different. I'm talking about figure(1); plot; etc...
> running remotely.
>
> Sorry if I'm repeating myself.
>
> Stefan
>
> Brian Arnold wrote:
> >
> >
> > Hi,
> >
> > I don't want anyone to feel alarmed by this discussion;
nothing is
> > set
> > in stone. I appreciate hearing the whole gamut of what
works, what
> >
> > doesn't, how different people are using the Mac version,
and what
> > all of
> > the different customer needs and requirements are. If you
> > communicate
> > your needs clearly enough, it helps us avoid doing the
wrong thing.
> > And
> > if you see enough conflict between different
requirements, it might
> > help
> > some of you understand why we are attempting to do
things that may
> > be in
> > conflict with your particular requirements.
> >
> > I'd like to clarify a few things:
> >
> > - MATLAB Desktop's UI and significant Toolboxes such as
SimBiology
> > and
> > Distributed Computing Toolbox leverage Apple's Java,
which in turn
> > leverages Apple's Cocoa framework for a native OS X user
> > experience.
> > None of these UIs function over an X11 connection,
because Apple's
> > Java
> > doesn't support this. This is the most significant
distinction
> > between
> > Linux/Solaris versions of MATLAB, and the Mac version.
We would
> > not
> > like to be in the business of porting and maintaining a
ported
> > version
> > of Sun's (X11-based) Java on OS X.
> >
> > - There is an X11 implementation of Figures which does
run on the
> > Mac,
> > and works, but has had unexpected costs both in terms of
> > maintenance and
> > consistency, because of the integration required with
Simulink and
> > the
> > Desktop UI. If you run with -nodesktop or -nojvm, you
may not be
> > aware
> > of how painful it is.
> >
> > - For those who use Simulink, its UI in the past was
developed
> > using X11
> > directly, but is now increasingly using TrollTech Qt,
which is
> > Carbon-based on the Mac platform. In R2007a, Simulink is an
> > X11/Carbon
> > hybrid. We no longer would like to maintain a port of
the X11
> > version
> > of Qt, for the same reason that we would not like to be
in the
> > business
> > of maintaining a non-Apple X11-based Java on OS X.
> >
> > - For those of you who adamantly oppose the loss of X11
forwarding,
> > I'd
> > like to assure you that if we can sustain X11-forwarding
support
> > for
> > your usage models, we will try to do so, but we're not
likely to
> > grow
> > the support (for the reasons I have outlined earlier,
which have
> > been
> > re-posted). In order to help us set priorities, can you
please
> > articulate what is coming over the X11 pipe (from a Mac
MATLAB)
> > that you
> > require? Is it simply data visualization in Figures, is
it one of
> > the
> > the legacy UI's built using Figures, or are there other
> > requirements?
> > Are you missing out on Toolboxes and features in new
releases which
> >
> > currently require Java? If so, which ones? What is
holding you
> > back
> > from exploring other options (besides X11 forwarding)?
> >
> > Please continue with this dialog, thanks,
> >
> > Brian

Brian Arnold <barnold@mathworks.com> wrote in message
<46852A41.2090004@mathworks.com>...
> Hi,
>
> I appreciate this thread, keep your comments coming.
>

I haven't read the entirety of this thread but I just wanted to register one
more voice in favour of keep the CLI *and* the X11 based interface. I use the
CLI in a terminal exclusively, and often remotely. I use X11 based graphics
remotely only occasionaly, but even when working on a local machine, I
*much* prefer X11 based graphics.

The Quartz/Aqua window manager on OS X is fine for just a few pretty
browser/email/etc windows, but when using Matlab, I will often have 9 or 10
figure windows and a few terminals open. To make this at all managable I
use a tiling window manager (ion3) in a full screen X11 session. I would hate
to have to go back to working with a messy stack of fifteen or so Aqua
window.

So, to sum up, Matlab would be almost unusable for me with CLI and X11
graphics support and a relativly high level of independence from the console.
It's not so much remote X11 graphics that I use (though it does occasionally
come in very useful) but X11 on the local box, because for serious work, the
mouse heavy, eye-candy-laden OS X Aqua UI experience you seem to be
striving for is, IMO, an inappropriate hindrance. Having as much as possible
under X11 gives me the freedom to set up my working environment the way I
like it.

Anyway, not to seem ungrateful, thanks for making Matlab as good as it is!
Regards,
Samer

Hi, well hope this isn't too off-topic, but following on this
discussion, I am trying to decide how well the Matlab interface on OS
X is going to work for me, and if it is going to cause problems
compared to the linux version. I am a Mac user primarily, but have
been using Matlab under linux on a network of machines in my old lab.
I am starting a new project where we are thinking of getting a Mac
Pro. Let me try to explain what I've been doing...

Under linux, I have been running say 8 copies of Matlab (or programs
compiled via mcc) on various different (or the same) machines via x11,
so that the gui of each of them is outputting its display onto one
linux display (perhaps on different virtual desktops), which I can
monitor remotely via VNC on my Mac. I use the figure windows for
monitoring progress of the algorithms while they are running.

Now I may be wrong, but I'm not sure that this kind of thing is
currently possible to replicate on OS X Matlab? Can I, for instance,
start multiple instances of Matlab on the same or different machines
and have them display graphical output onto different virtual
desktops, e.g. spaces, on the one Mac? Can multiple users do this
simultaneously? Can they be controlled via VNC?

I'm not sure about the first question, I think in theory it is
possible with x11, but I haven't tried. I think Vine Server with fast
user switching would make the vnc control work up to a point -
although it seems each user cannot have more than one login on OS X
(i.e. multiple vnc sessions) as on linux.

On another point I'm also hoping 64bit Matlab support may eventually
come for OS X... for now would the best workaround be to just install
a version of linux on the Mac Pro? Or has anyone tried running a
64bit linux version of Matlab under virtualisation?

regards
Tom Bishop

On Jul 9 2007, 3:38=A0pm, Brian Arnold <barn...@mathworks.com> wrote:
> Hi,
>
> I don't want anyone to feel alarmed by this discussion; nothing is set
> in stone. =A0I appreciate hearing the whole gamut of what works, what
> doesn't, how different people are using the Mac version, and what all of
> the different customer needs and requirements are. =A0If you communicate
> your needs clearly enough, it helps us avoid doing the wrong thing. =A0And=

> if you see enough conflict between different requirements, it might help
> some of you understand why we are attempting to do things that may be in
> conflict with your particular requirements.
>
> I'd like to clarify a few things:
>
> -MATLABDesktop's UI and significant Toolboxes such as SimBiology and
> Distributed Computing Toolbox leverage Apple's Java, which in turn
> leverages Apple's Cocoa framework for a native OS X user experience. =A0
> None of these UIs function over an X11 connection, because Apple's Java
> doesn't support this. =A0This is the most significant distinction between
> Linux/Solaris versions ofMATLAB, and the Mac version. =A0We would not
> like to be in the business of porting and maintaining a ported version
> of Sun's (X11-based) Java on OS X.
>
> - There is an X11 implementation of Figures which does run on the Mac,
> and works, but has had unexpected costs both in terms of maintenance and
> consistency, because of the integration required with Simulink and the
> Desktop UI. =A0If you run with -nodesktop or -nojvm, you may not be aware
> of how painful it is.
>
> - For those who use Simulink, its UI in the past was developed using X11
> directly, but is now increasingly using TrollTech Qt, which is
> Carbon-based on the Mac platform. =A0In R2007a, Simulink is an X11/Carbon
> hybrid. =A0We no longer would like to maintain a port of the X11 version
> of Qt, for the same reason that we would not like to be in the business
> of maintaining a non-Apple X11-based Java on OS X.
>
> - For those of you who adamantly oppose the loss of X11 forwarding, I'd
> like to assure you that if we can sustain X11-forwarding support for
> your usage models, we will try to do so, but we're not likely to grow
> the support (for the reasons I have outlined earlier, which have been
> re-posted). =A0In order to help us set priorities, can you please
> articulate what is coming over the X11 pipe (from a MacMATLAB) that you
> require? =A0Is it simply data visualization in Figures, is it one of the
> the legacy UI's built using Figures, or are there other requirements? =A0
> Are you missing out on Toolboxes and features in new releases which
> currently require Java? =A0If so, which ones? =A0What is holding you back
> from exploring other options (besides X11 forwarding)?
>
> Please continue with this dialog, thanks,
>
> Brian
>