Re: LibrePlanet 2022

[Mohammad-Reza Nabipoor]

Ho, Jose.

On Fri, Dec 17, 2021 at 08:15:19AM +0100, Jose E. Marchesi wrote:
> 
> > On 2021-12-17 at 00:18 +0330, Mohammad-Reza Nabipoor wrote:
> >
> >>   Embedding GNU poke inside your application
> >>   poke All The Things
> >>   Examples of using libpoke in applications
> >
> > I like “poke All The Things”.  Maybe having “binaries” in the title
> > could be useful.
> 
> I like this one:
> 
> "The Trojan poke: embedding GNU poke in your own program"
> 
> >> GNU poke is about manipulating structured binary data.
> >> It has two parts: a library and a cli program (the editor).
> >> Other programs can use the decoding/encoding capability of
> >> GNU poke through `libpoke` library.
> >> This talk will presents some examples of such integrations
> >> both in popular programs like `gdb` and `gas`, and also in
> >> some small ones.
> 
> I would structure the abstract as follows:
> 
> - First, what is GNU poke.  You already have that.
> 
> - Then, the fact that poke is not a monolithic program: most of the
>   functionality, in particular the Poke compiler and the IO handling, is
>   not in the `poke' application, but in a shared library called
>   `libpoke'.
> 
> - This shared library provides mechanisms that allow other programs to
>   integrate poke's capabilities in their own spheres and concepts.  This
>   support is not gratuitous: poking at structured binary data is a
>   rather general activity that is useful in a very wide range of
>   different contexts.  Consider for example the memory of running
>   processes in a system.  We could of course teach the `poke'
>   application how to attach to processes and access their memory (in
>   fact, it is supported in a very simple way) but things soon become
>   complicated: what if I need to run the program up to certain point,
>   then poke the contents of memory, then continue?  In practice we need
>   a debugger.  So instead of turning poke into a debugger, a filesystem
>   editor and partitioner, an assembler, and what not, we assimilate
>   libpoke in these programs; if the program will not come to poke, poke
>   will go to the program.
> 
> - This talk will describe the part of the libpoke API that provides the
>   integration mechanism.  Then will show in detail a couple of examples
>   of this kind of integration: poke in GDB and GAS, the GNU Debugger and
>   the GNU assembler.
> 
> "Resistance is futile."
> 


Thanks for your complete and detailed answer!

I shrinked your description a little (I thought abstracts should be
short). But I put your version after the shrinked version.
Please choose one of them :)

```text
GNU poke is about manipulating structured binary data. Most of the
functionality, in particular, the Poke compiler and IO handling, is
not in `poke' application, but instead in a shared library called
`libpoke'.
Poking at structured binary data is a rather general activity that
is useful in a very wide range of different contexts.
Rather than making `poke' capable of supporting different

contexts (e.g., becoming a debugger, a filesystem editor, disk
partitioner, an assember, and etc.), one can assimilate `libpoke'
in these programs. In short, if the program will not come to `poke',
`poke' will go to the program!

This talk will describe the part of the libpoke API that provides the
integration mechanism.  Then will show in detail a couple of examples
of this kind of integration: poke in GDB and GAS, the GNU Debugger and
the GNU assembler.

"Resistance is futile."
```

Your longer version:


```text
GNU poke is about manipulating structured binary data. Most of the
functionality, in particular, the Poke compiler and IO handling, is
not in `poke' application, but instead in a shared library called
`libpoke'.

This shared library provides mechanisms that allow other programs to
integrate poke's capabilities in their own spheres and concepts.  This
support is not gratuitous: poking at structured binary data is a
rather general activity that is useful in a very wide range of
different contexts.  Consider for example the memory of running
processes in a system.  We could of course teach the `poke'
application how to attach to processes and access their memory (in
fact, it is supported in a very simple way) but things soon become
complicated: what if I need to run the program up to certain point,
then poke the contents of memory, then continue?  In practice we need
a debugger.  So instead of turning poke into a debugger, a filesystem
editor and partitioner, an assembler, and what not, we assimilate
libpoke in these programs; if the program will not come to poke, poke
will go to the program.

This talk will describe the part of the libpoke API that provides the
integration mechanism.  Then will show in detail a couple of examples
of this kind of integration: poke in GDB and GAS, the GNU Debugger and
the GNU assembler.

"Resistance is futile."
```