Re: [Jitter] Print contexts, generalised

[Luca Saiu]

On 2020-11-15 at 20:26 +0100, Jose E. Marchesi wrote:

>>From a poke perspective, I think we are interested on the other side of
> 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.

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.

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.

> 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.

--interrupted.  I am sending you the message now.  Please reply if there
is something still not clear.

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature