5

I have two instances of Mathematica running on the same PC. Can I call the output of one from the other?

For example if Out[100] is on kernel1 how do I refer to it on kernel2?

Maesumi
  • 775
  • 3
  • 11
  • Maybe naming your evaluator? https://reference.wolfram.com/language/ref/Evaluator.html – Chris Degnen Dec 05 '18 at 22:40
  • Is this a solution for you? https://mathematica.stackexchange.com/questions/14166/how-can-i-access-a-variable-in-one-evaluator-from-another-evaluator/14168#14168 – Mike Honeychurch Dec 05 '18 at 23:39
  • This is the cleanest and most robust solution I can think of: https://mathematica.stackexchange.com/a/14176/38205 – b3m2a1 Dec 06 '18 at 01:13
  • 1
    Do you mean two Mathematica instances or two different kernels under the same FE/Mathematica? – Kuba Dec 06 '18 at 08:49
  • @Kuba If I have two open notebooks how do I tell if they are from two kernels or two instances of Mathematica? If I try to open another Mathematica it asks for a license. So my guess is that mine are two kernels. – Maesumi Dec 06 '18 at 20:29
  • @Maesumi You can tell by the parent process. And since you opened them you can tell because you know anyway. Don't get me wrong, wording you have used suggests something else that you 'guess', which is way more difficult to solve so that information matters. If you opened two notebooks in MMA and set separate kernels for them, just say so instead of 'two instances'. – Kuba Dec 07 '18 at 07:25

2 Answers2

10

Update

(comparison to other answers)

This answer doesn't require the remote kernel to do anything, in contrast I believe to the linked answers as well as @b3m2a1's answer. For example, if the remote kernel is computing something, it will not be able to send results to the inspecting kernel.

(multiple Mathematica sessions)

If you indeed have multiple Mathematica sessions, then the Front End will not have access to both kernels. In this case you may use the Channel or Socket frameworks to communicate between the kernels, but I won't bother with this unless the question is clarified.

(improved answer)

Also, I cleaned up the function a bit, so that it is simpler, and so that it can work with arbitrary expressions (not just Out).

SetAttributes[RemoteValue, HoldFirst]
RemoteValue[expr_, kernel_] := Uncompress @ First @ FrontEndExecute @ ExportPacket[
    BoxData @ DynamicBox[Compress @ expr, Evaluator->kernel],
    "PlainText"
]

And, the same example as before:

RemoteValue[Out[28], "Local 2"]
% + 1

1596

1597

Original answer

There is probably a much simpler method, but here is one possibility:

RemoteValue[line_, kernel_] := Uncompress @ First @ FrontEndExecute @ ExportPacket[
    Cell[
        BoxData @ ToBoxes @ Dynamic[Compress @ Out[line], Evaluator -> kernel],
        "Output"
    ],
    "PlainText"
]

It's hard to simulate multiple kernels in an answer, but this is what I get when I use the above:

RemoteValue[28, "Local 2"]
% + 1

1596

1597

where the input in the "Local 2" kernel was 798 2, and the second line shows that the actual value is available.

Another possibility if you just want to see the output is to use Dynamic:

r = Dynamic[Out[28], Evaluator->"Local 2"]

1596

but in this case the actual value is not available:

Head @ r

Dynamic

Carl Woll
  • 130,679
  • 6
  • 243
  • 355
  • Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something like MathLink`CallFrontEndHeld[FrontEnd`Value["expr"]] I feel and specify the Evaluator... – b3m2a1 Dec 06 '18 at 05:44
7

Update

Here's how we'd do this for your case specifically. Assuming we created and connected a tunnel called "shuttle". First we do this on kernel 1:

TunnelWrite["shuttle", Evaluate@Out[32]]

And then on kernel 2:

TunnelRead["shuttle", Hold]

{Hold[{1, 2, 3, 9}]}

The hold is optional. I just added it for flavor.

Original

Here's another option that works directly at the MathLink level and so has more efficient data transport.

I wrote a layer or five on top of LinkCreate and friends to help ease some of the dangers and difficulties of using Links for inter-kernel communication.

The package is called KernelTunnels. Here's an example:

tunneling

We can see I create a tunnel with TunnelCreate in the first kernel (just a link+metadata) called "shuttle". The tunnel data is written to a temporary .mx file so as to allow good unified interprocess communication.

In the second kernel I then connect to the same tunnel with TunnelConnect. At this point the two are attached to each other and can communicate freely.

TunnelWrite will write to the LinkObject and TunnelRead will drain everything off the link, wrapping it in the head passed as the second argument first. Note that TunnelWrite writes the unevaluated expression by default, so you'll need to use Evaluate if you want to circumvent this behavior.

There's also some stuff in there for adding handlers for TunnelRead (it can be different on both ends).

If this is useful I can properly document the API, but these functions are the heart of it.

b3m2a1
  • 46,870
  • 3
  • 92
  • 239
  • Doesn't OP mean two MMAs as opposed to two kernels under the same FE? – Kuba Dec 06 '18 at 08:00
  • Unclear...that case is just fundamentally impossible without dumping to disk, though, I think. Although LinkConnect might work just without the shared memory argument. – b3m2a1 Dec 06 '18 at 08:47