Re: [Jitter] Print contexts, generalised

[Jose E. Marchesi]

>> the coin: we don't want to print stuff thru Jitter, but we want to be
>> called(back) by Jitter so we can print stuff.
>
> Let us define "calling" in terms of explicit calls to user functions.
>
> a.1) libpoke calls the PVM API generated by Jitter, when "disassembling
>      a PVM program" (in Jitter terms "printing a PVM routine"); that VM
>      code will include literal constants, to be printed in a custom way.
> a.2) libpoke can also call the PVM API generated by Jitter to do
>      native-code disassembling: that is easier, because it does not
>      require any user customisation.  But you still want styling if you
>      are using libtextstyle, when libpoke is linked in poke.
>
> b)   libpoke will do its work in autonomy, printing PVM or Poke
>      programs.  It can use its own machinery, but it could also build
>      that on top of Jitter's, as a thin abstraction.
>
> a.1) and a.2) require simple calls from libpoke to Jitter functions.
> But, and this is probably what you want, those call end up going through
> functions pointed by functions supplied by libpoke itself.

Exactly.  We are on the same page :)

> What the example in my email does not show is how to define a Jitter
> print context kind.  You find three examples in jitter-print.c , but
> they are all "trivial" in the sense that they do not use decorations.

We will be also a "trivial" client.  In fact, libpoke itself doesn't do
any kind of decoration.  It just calls its client callbacks for
begin_class, end_class, and so on.

> I am now writing a little print context kind finally making use of
> libtextstyle ; how to link it without having libtextstyle as a
> dependency of Jitter (which I will avoid) is a question to fine-tune a
> little.  I understand that you will use my wrapper, and you would like
> to write your own instead; therefore mine will serve as an example.
>
> There will of course be some duplication of effort, as we already
> discussed in private, but I think that the libtextstyle wrapper will be
> completely trivial, on my side.  I would like to show you soon.

Ok.  But we can't use it.  It is up to libpoke's client to decide what
to do to print the stuff... if it prints it at all.  It may be
discarding it, or storing it in some file, or sending it to the outer
space as far as we are concerned :)

Thats why it is so important for us that:
1) Jitter doesn't link with libtextstyle and
2) Jitter doesn't print anything to the terminal.  Everything should go
   thru the callbacks.

>> So, I am guessing, we have to define what you can a new "context
>> kind".
>
> Correct.
>
>> What in the example above is "char_start".  In our case it would be a
>> "poke_term".
>
> char_star means “char *”, the data type: it is just a '\0'-terminated
> string.  The functionality similar to what you have in pk_term_if goes
> to an instance of struct jitter_print_context_kind_struct .
>
>> Am I correct?
>>
>> In that case, what is the interface we would have to implement to Jitter
>> calls us in order to print stuff?
>
> In reference to the points above you will need to:
>
> a.{1,2}) Define a jitter print context kind, and use it in your custom
>          data printers (the functions whose name you write inside argument
>          lists inside the .jitter file -- maybe you have only one such
>          function)
>
>
> b)       Maybe there is nothing to do, unless you want to reuse
>          functionality.
>
> For the a part, I think you should implement a jitter print context
> printing to a pk_term.

Yep, makes sense.
Thanks!