Can output of one kernel be called from another on the same PC?
up vote
3
down vote
favorite
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?
front-end
add a comment |
up vote
3
down vote
favorite
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?
front-end
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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?
front-end
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?
front-end
front-end
edited 8 hours ago
asked 8 hours ago
Maesumi
408210
408210
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago
add a comment |
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago
add a comment |
2 Answers
2
active
oldest
votes
up vote
4
down vote
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
Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something likeMathLink`CallFrontEndHeld[FrontEnd`Value["expr"]]
I feel and specify theEvaluator
...
– b3m2a1
1 hour ago
add a comment |
up vote
2
down vote
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:
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.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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
Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something likeMathLink`CallFrontEndHeld[FrontEnd`Value["expr"]]
I feel and specify theEvaluator
...
– b3m2a1
1 hour ago
add a comment |
up vote
4
down vote
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
Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something likeMathLink`CallFrontEndHeld[FrontEnd`Value["expr"]]
I feel and specify theEvaluator
...
– b3m2a1
1 hour ago
add a comment |
up vote
4
down vote
up vote
4
down vote
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
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
answered 8 hours ago
Carl Woll
66.1k385173
66.1k385173
Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something likeMathLink`CallFrontEndHeld[FrontEnd`Value["expr"]]
I feel and specify theEvaluator
...
– b3m2a1
1 hour ago
add a comment |
Clever to use the boxes as a transfer protocol. There ought to be a way to make a single call into something likeMathLink`CallFrontEndHeld[FrontEnd`Value["expr"]]
I feel and specify theEvaluator
...
– b3m2a1
1 hour ago
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
1 hour ago
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
1 hour ago
add a comment |
up vote
2
down vote
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:
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.
add a comment |
up vote
2
down vote
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:
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.
add a comment |
up vote
2
down vote
up vote
2
down vote
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:
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.
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:
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.
edited 2 hours ago
answered 3 hours ago
b3m2a1
25.8k256151
25.8k256151
add a comment |
add a comment |
Thanks for contributing an answer to Mathematica Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathematica.stackexchange.com%2fquestions%2f187404%2fcan-output-of-one-kernel-be-called-from-another-on-the-same-pc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Maybe naming your evaluator? reference.wolfram.com/language/ref/Evaluator.html
– Chris Degnen
8 hours ago
Is this a solution for you? mathematica.stackexchange.com/questions/14166/…
– Mike Honeychurch
7 hours ago
This is the cleanest and most robust solution I can think of: mathematica.stackexchange.com/a/14176/38205
– b3m2a1
5 hours ago