# How can I access a variable in one evaluator from another evaluator?

I have two notebooks, each with a different kernel. Is there a way to grab the value of a variable in KernelA from KernelB?

-
You could try assigning the variable to a tagging rule and accessing via CurrentValue[$FrontEndSession,{TaggingRules, ...}] – Mike Honeychurch Nov 5 '12 at 21:58 You could use a file. – Sjoerd C. de Vries Nov 5 '12 at 21:59 @MikeHoneychurch interesting approach, an you give all the code for your example as a solution? – M.R. Nov 5 '12 at 22:06 IMO probably the best way is using MathLink (Mike's suggestion of course uses it indirectly). I showed how you can link up two kernels here--you may be interested in the linked MathGroup posting too. An updated version of that code is here. – Oleksandr R. Nov 5 '12 at 22:12 @OleksandrR. Could you update your answer with the latest version of the code? (you can perhaps use belisarius' notebook-in-image palette to upload it if it is long) – The Toad Nov 5 '12 at 22:28 ## 2 Answers Try this out: Lets say you have a variable called kernelA in one notebook using Kernel A. Then: CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}] = kernelA

In your other notebook, running Kernel B just evaluate

variableFromOthernotebook = CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}] Edit An alternative that might be faster (almost certainly would be if a lot of TaggingRules are used). SetOptions[$FrontEndSession, TaggingRules -> {"KernelA" -> kernelA}]

than in the other notebook:

variableFromOthernotebook = "KernelA" /.
(TaggingRules /. Options[\$FrontEndSession, TaggingRules])
-
There is significant lag in this example :( –  M.R. Nov 6 '12 at 1:06
@M.R. can you explain what you mean? A lag setting the value? A lag obtaining the value? –  Mike Honeychurch Nov 6 '12 at 5:34
@MikeH. I find your method surprisingly performant, with no obvious lag, as well as ingenious in its simplicity. A lot of optimization must go in to the front-end link, as its bandwidth for large transfers is actually higher than the approach I demonstrate (although it has a marginally higher latency). As usual, though, older versions win out in the performance stakes: using my example, Mathematica 5.2 is about twice as fast as version 8 for basic MathLink transfers... –  Oleksandr R. Nov 6 '12 at 5:46
@OleksandrR. In the past I have found that if you have to set a large number of rules (from memory 30-50), TaggingRules can slow down quite a bit but for a small number I have found it to be fairly efficient. Why is V5.2 faster than V8 for MathLink transfers? –  Mike Honeychurch Nov 6 '12 at 6:34
@MikeH. I don't really know why, but it seems with each new version, along with many new features, more overhead gets added to the fundamental operations. In this case it's probably a question of MathLink interface version 2 vs. 3, the latter being slower for some reason. Basic manipulation of DownValues is also about a third faster in 5.2 than 8. –  Oleksandr R. Nov 6 '12 at 13:20

Here is a very simple example of how to use MathLink for this sort of communication. I will use normal code blocks for kernel A and quoted code blocks for kernel B. You must evaluate these in the order shown.

MathLinkAddSharingLink[link];
SetAttributes[remoteEvaluate, HoldAllComplete];
remoteEvaluate[expr_] := (
First@Cases[
ReturnPacket[result_] :> result, {3}
]
);

The idea is that the result of evaluating expr on kernel B comes back to kernel A as the body of a ReturnPacket. Other types of packets may also be produced (for example, ExpressionPackets are generated when something is Printed), but we ignore these for present purposes.

Now:

var = Range[5];
var
(* -> var *)

remoteEvaluate[var]
(* -> {1, 2, 3, 4, 5} *)

If we care to check, we will also find that var did not suffer the indignity of unpacking and was quite unmolested in general by this process.