Can Dynamic FFI in Guile handle pass by value struct?

[Zhu Zihao]

Hi, Guile users!

I'm working on a Guile binding to tree-sitter, an incremental parsing
library. Consider we have something like(actually taken from
tree-sitter's header file)

```
typedef struct {
  uint32_t context[4];
  const void *id;
  const TSTree *tree;
} TSNode;

uint32_t ts_node_end_byte(TSNode);
```

I'd like to write binding like

```
(pointer->procedure uint32 (dynamic-func "ts_node_end_byte" %libtree-sitter) 
`((,uint32 * *)))
```

As the function defined in header, we need to pass a TSNode struct by
value to ts_node_end_type. But I'm not sure how to do it in Dynamic FFI.
There's make-c-struct in (system foreign), but it'll return a pointer to
the struct.

I check the doc but can't find something useful, Can guile Dynamic FFI
pass a C struct by value or we must do it in static FFI?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

guile-hall issues converting my project to a hall project

[Zelphir Kaltstahl]

Hello Guile Users!

I decided to try to use guile-hall to convert my project at
https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
For that purpose I created a separate branch
"wip-guix-package-using-guile-hall"
(branch: 
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-package-using-guile-hall
commit:
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3ebd497adcce6b683e82),
from which I am starting to run commands.

It seems, that many of guile-hall's defaults are wrong for my project
and I need to adapt a lot of its settings. It also tells me to report
unsupported file types, but I cannot do that in the guile-hall
repository, because I cannot log in on Gitlab, because Gitlab has a
"clever" "check of my browser", which simply loops forever reloading the
"browser check" website … My guess: The check requires third party
cookies to be set. So I am going to write about it here and hope someone
knows how to proceed.

The example call in the readme of
https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:


hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute


I am not sure what exactly the prefix is. `hall init --help` only tells
me: "Prefix of the project.", which does not help me. It basically has
zero more information for me. Does this already have to do with the
Makefile, which is created later? I leave prefix at "guile" for now.
What is "frobnigator"? I think it is the name of the project, because in
`hall init --help` it says that the syntax is:


hall initiate [-cx] NAME
 [-a "Alyssa P. Hacker"]
 [-l gpl3+]
 [-p guile]
 [-w "https://website.mine";]


(I like the SICP reference, btw.) `NAME` is the only thing that I cannot
translate anything else to be in the command above. I think it would be
better to not use something confusing like "frobnigator", which people
might not know what that even is, and use a generic word like
"my-project-name".

So the command I run is:


hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib 
--license 'agpl3+' --execute


What I like about it is, that everything seems to be dry-run, except
when adding `--execute`. That makes things less scary.

Then hall creates a bunch of files, but most things seem not to consider
my actual already existing project structure. hall never asks me what my
test directory is or what file my license information is in. I think it
would be good to have those things available as command line arguments,
so that I do not need to fix things afterwards, which differ from the
defaults.

I will list the things, that I need to change to correct values after
the hall command has finished and steps I am taking, from the
perspective of a first time user, because perhaps it can help improving
guile-hall:

(1) Remove my old license file, which was not `COPYING` but `LICENSE`.
Here I do not really care about in which file it is. It would be great,
if hall asked me about the `LICENSE` file though. Perhaps a list of
common names of license files could be added to hall and it could check
for those?

(2) In `guix.scm` the version is wrong. It should be `(version
"0.2.0")`, not `(version "0.1")`. The git repository already has a tag
`0.2.0`, but I think, that "0.1" is a default value, which is simply put
into `guix.scm`. Here a `--version` argument would be good to have, with
the default still being `0.1.0` or `0.1`. I think 3 parts is the better
choice, because it makes processing version numbers easier. Every
version number would have 3 parts. Always. And it could be made a list
of 3 symbols or even numbers as well. But if they are only numbers, one
could not have something like "rc" for release candidate or stuff like
that. Also not everyone might want to use version numbers like these. I
have seen projects using the date as version number.

(3) After adapting the version number, the `source` has to be adapted as
well to reflect the change in version. At this point I get insecure
about the whole thing. "Will Guix be able to find this archive? Will it
look only for a version number consisting of 2 parts? Will anything
break later in the process, because I am not following the same
versioning syntax and have 3 parts instead of 2 parts written in the
string?"

(4) In the `guix.scm` native inputs are defined. The concept of that is
very unclear in my mind. I read about that previously on the Guix pages,
but I already forgot again what native inputs are and how they differ
from inputs. Anyway, probably not so important right now. However, they
list "texinfo". My project does not make use of texinfo at all. But I am
insecure now about removing it. Perhaps hall will not be able to deal
with it, if I remove it, so I am leaving it there for now. Hopefully I
can remove it later and make my dependencies fewer (?).

(5) In `hall.scm` the version is wro

Re: rfc: next guile 1.8.x release

[John Cowan]

On Sun, Jan 31, 2021 at 12:36 PM Massimiliano Gubinelli <
m.gubine...@gmail.com> wrote:


> Chibi is too slow


I'll just mention here that Chibi's file include/chibi/features.h has many
feature macros (at the C level) that can be changed to make Chibi
smaller/faster: for example, you could disable Unicode support, R7RS module
support, etc.  If you do that, rebuild, and re-benchmark, the results might
be more pleasant.  There would still be the issue of making whatever
changes are required to adapt the existing code to Chibi, of course.

> So Guile 1.8 today remains a very good piece of software,


I propose (and I think this would make the Guile team happier) that you
fork Guile 1.8.x into a new project with a new name (Canny Scheme, Foxy
Scheme, or Sneaky Scheme, perhaps?).  That way you can maintain it for
your own use, it will be easier for packagers to work with since it will
have its own version number sequence, and it will be available to others
who want small, fast, somewhat Guile-compatible code.

Whether this would be a GNU project or not would need to be resolved by the
powers that GNU, of course.

In my mind Guile 1.8 is a very different language than Guile 2/3


Agreed: a different dialect of Scheme should have its own name.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas.   --Jacques Lacan, "L'Etourdit"