Re: Chain of packets in MathLink: are packets always strictly ordered?
- To: mathgroup at smc.vnet.net
- Subject: [mg116662] Re: Chain of packets in MathLink: are packets always strictly ordered?
- From: John Fultz <jfultz at wolfram.com>
- Date: Wed, 23 Feb 2011 05:24:01 -0500 (EST)
1) Here's example code which returns two ReturnExpressionPackets...
lnk=LinkLaunch["mathkernel -mathlink"];lr:=LinkRead[lnk];lr;
LinkWriteHeld[lnk,
Hold[EvaluatePacket[SetOptions["stdout",FormatType->StandardForm]]]];lr;
LinkWriteHeld[lnk, Hold[EnterExpressionPacket[MakeExpression[BoxData[{"1","2"}],
StandardForm]]]];
(* then LinkRead[] away *)
2) Yes, if you wrap, e.g., StandardForm[] or TraditionalForm[] around the
output.
3) Not that I'm aware of, although I didn't look deeply into the question.
As far as PostScript is concerned, the additional rules to note are...
* You can receive a DisplayPacket any time before an InputNamePacket, as long as
doing so doesn't violate one of the other parts of the contract I outlined
earlier.
* After you receive a DisplayPacket, the only packet you can receive is another
DisplayPacket or a DisplayEndPacket. The final PostScript cell is built from
the concatenated strings of all of the DisplayPackets plus the final
DisplayEndPacket.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Tue, 22 Feb 2011 07:07:50 +0500, Alexey Popkov wrote:
> Thanks for the detailed response! Things are getting clearer.
>
> I have some additional questions:
>
> 1) I tried to get multilple output with EnterExpressionPacket and
> ExpressionPacket but I have not found a way to get it. In which cases it
> is produced?
>
> 2) Can ExpressionPacket be returned when expression is sent with
> EnterExpressionPacket and in the slave kernel $Output has attribute
> FormatType -> OutputForm? If it is, in which cases it is returned?
>
> 3) Is there a way to get Messages and Prints to be ExpressionPackets (or
> just to be returned in a way suitable for good-looking printing in a
> Notebook) when in the slave kernel $Output has attribute FormatType ->
> OutputForm? The text-based version of complex expressons looks ugly.
>
> P.S. I am interested in support of legacy versions of Mathematica as the
> slaves and the FrontEnd v.7.0.1 (which I use) supports legacy PostScript.
> So I'm interested in correct handling packets related to PostScript, too.
>
>
> ----- Original Message -----
> From: "John Fultz" <jfultz at wolfram.com>
> To: <lehin.p at gmail.com> <mathgroup at smc.vnet.net>
> Sent: Monday, February 21, 2011 8:44 PM
> Subject: Re: [mg116592] Chain of packets in MathLink: are packets always
> strictly ordered?
>
>
> On Mon, 21 Feb 2011 04:20:41 -0500 (EST), Alexey wrote:
>> Hello,
>>
>> The Documentation does not state clear the order of packets returned
>> by slave kernel via MathLink. It is natural to assume that (when
>> sending an input expression with head EnterExpressionPacket):
>>
>> 1) the last packet before the next InputNamePacket is always
>> ReturnExpressionPacket
>> 2) there may be always only one ReturnExpressionPacket and one
>> OutputNamePacket for one EnterExpressionPacket
>> 3) ReturnExpressionPacket always goes after OutputNamePacket
>> 4) after MessagePacket the next packet is always TextPacket with
>> contents of that message.
>> 5) when working in standard mode there may be only 7 types of returned
>> packets: InputNamePacket, OutputNamePacket, ReturnExpressionPacket,
>> DisplayPacket, DisplayEndPacket, MessagePacket, TextPacket.
>>
>> Are these assumptions true?
>>
> No, they are not. I'll pick them apart one by one...
>
> 1) If the output is suppressed by a semicolon, then you won't get any
> output-related packets. Also, you might get a ReturnTextPacket if the
> output is requested in a textual format such as OutputForm or InputForm.
>
> 2) False and false, for the same reason as above.
>
> 3) *If* you get an OutputNamePacket, it will be followed by *either* a
> ReturnExpressionPacket or a ReturnTextPacket. If an input produces
> multiple outputs, then each OutputNamePacket is followed immediately by
> its corresponding return packet.
>
> 4) True.
>
> 5) Also, ExpressionPacket. And if you accept arbitrary Mathematica
> input, you really should be prepared to accept a ReturnTextPacket as
> well. There's also the PostScript-related packets, but you might be able
> to safely assume no legacy behavior and ignore those.
>
>
> Perhaps answering your specific assumptions isn't a very good way of
> summarizing the rules, so let me summarize them. These are the rules of
> the state machine for a front end to the kernel:
>
> * Main loop evaluations (ones that assign In/Out) may begin with an
> EnterExpressionPacket or an EnterTextPacket.
>
> * Main loop evaluations are always terminated by exactly one
> InputNamePacket, regardless of how many individual inputs the enter
> packet contained.
>
> * If the main loop evaluation returns output(s), it(they) will be in the
> form of an OutputNamePacket[] followed by a ReturnTextPacket or
> ReturnExpressionPacket.
>
> * Messages are TextPackets (and theoretically could be ExpressionPackets,
> although that doesn't happen now) which are identified by being preceded
> by a MessagePacket.
>
> * All unidentified Text/ExpressionPackets are considered Print cells.
>
> * You can send a non-main-loop evaluation using EvaluatePacket. The
> kernel always responds to an EvaluatePacket with a ReturnPacket (this
> rule is slightly more complex for *the* Mathematica front end, but it
> suffices for custom front ends). Such evaluations should not be sent
> while you're waiting for an InputNamePacket.
>
> All of these rules can be observed without too much effort by launching a
> kernel from a kernel using, e.g.,
>
> lnk=LinkLaunch["mathkernel -mathlink"]
>
> and then using LinkRead/LinkWrite to communicate with the link. Although
> one needs to be careful with EvaluatePackets that their contents evaluate
> where you intended them to. I sometimes will do
> SetAttributes[EvaluatePacket, {HoldAll}] when I'm doing some sort of
> demonstration or experiment to make sure that LinkWrite isn't evaluating
> the expression before it sends it.
>
> Sincerely,
>
> John Fultz
> jfultz at wolfram.com
> User Interface Group
> Wolfram Research, Inc.