Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
On Thu, 17 Feb 2022 at 16:59, Blake Shaw wrote: > > https://tube.nocturlab.fr/videos/watch/2b55ca09-f0fd-4899-9cb0-9632cd90b3d1 Wow, what a great reminder of things past! I mean "past" in the sense that I used to be very strongly focused on this, but have not been for some years. The material is, happily, still very relevant in the present, so well worth addressing how it can be improved. I'm only about half way through the video so far, but already wanted to mention a couple of points. Firstly, about the Guile Recipes... I had entirely forgotten about that, but yes, it indicates that we were having the same kind of conversation about a cookbook several years ago as we are now. Undeniably the guidelines / contribution structure then did not work! Let's hope someone can devise a better structure this time around. Secondly, what I think is the overall reason the docs are such a mess... Guile has always has a central tension between Scheme-centric and C-centric usage. - Scheme-centric usage is: Write your main program and most of its code in Scheme. When you need to use something from a C library, use the FFI to do that, or dynamically load a shared object that exposes function as Scheme objects and procedures. - C-centric usage is: You already have a big main program written in C, and you only want to allow Scheme to get involved, at certain points, as part of a config/customization-language-on-steroids model. You expose some of your function as Scheme objects and procedures, and call out to a user-configured Scheme file (which can use those objects and procedures) at the relevant points in the C processing. Personally, I am now a big fan of Scheme-centric + FFI, as it means always writing Scheme and never having to hack C code. If everyone agreed on that, we could discard all the C-centric parts of the manual, and focus the rest on a clearer use case. But I very much doubt that there is clear agreement on that. In particular, the C-centric usage is really Guile's original reason for existing: to act as a universal extension language for lots of GNU programs that already exist. I think expressing that dichotomy, and arranging the docs as clearly as possible while still allowing for both sides, is still our number 1 problem. Best wishes, Neil
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
On Sat, 19 Feb 2022, Neil Jerram wrote: > Personally, I am now a big fan of Scheme-centric + FFI, as it means > always writing Scheme and never having to hack C code. If everyone > agreed on that, we could discard all the C-centric parts of the > manual, and focus the rest on a clearer use case. But I very much > doubt that there is clear agreement on that. In particular, the > C-centric usage is really Guile's original reason for existing: to act > as a universal extension language for lots of GNU programs that > already exist. All projects being different, I don't think this is possible. For example, I've added Guile bindings for Jami, which is written in C++. FFI does not have support -- as far as I know -- for C++ std::string, std::vector, std::map. So it's a necessary to use more than the FFI module. I should add that I first started using Guile because of its easy integration with the C runtime and clear documentation on how to interlop it. If it was not for that, I would probably have dismiss Guile and select Lua instead. TLDR: I don't think we should discard anything that is C-centric in the manual. -- Olivier Dion Polymtl
Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal
Il giorno sab, 19/02/2022 alle 10.33 -0500, Olivier Dion via General Guile related discussions ha scritto: > On Sat, 19 Feb 2022, Neil Jerram wrote: > > > Personally, I am now a big fan of Scheme-centric + FFI, as it means > > always writing Scheme and never having to hack C code. If everyone > > agreed on that, we could discard all the C-centric parts of the > > manual, and focus the rest on a clearer use case. But I very much > > doubt that there is clear agreement on that. In particular, the > > C-centric usage is really Guile's original reason for existing: to > > act > > as a universal extension language for lots of GNU programs that > > already exist. > > All projects being different, I don't think this is possible. For > example, I've added Guile bindings for Jami, which is written in C++. > FFI does not have support -- as far as I know -- for C++ std::string, > std::vector, std::map. So it's a necessary to use more than > the FFI module. > > I should add that I first started using Guile because of its easy > integration with the C runtime and clear documentation on how to > interlop it. If it was not for that, I would probably have dismiss > Guile and select Lua instead. > > TLDR: I don't think we should discard anything that is C-centric in > the > manual. > Probably there should be 2 distinct manuals One for each (macro) use case The cognitive overload for someone wanting to just get their feet wet and then maybe grow their thing organically is frankly unfair But even by keeping a single manual, been watching Blake's video for a while now, he offers some suggestions about how to lessen such cognitive overload on the poor newcomer
'guild compile' and C(++) extensions (in the context of LilyPond)
Hi, (Cross-posted to guile-user, guile-devel and the debbugs issue, I'm unsure where this should go.) In LilyPond, we have now made a development release with binaries using Guile 2.2. However, a major problem is that we don't ship Guile bytecode yet. Notably, one problem to get the bytecode in a build system is that we are currently forced to use GUILE_AUTO_COMPILE=1 to generate it -- which means we need to compile the entire suite of regression tests in order to exercise all files. This also means spurious test differences when Guile gets noisy about byte-compilation (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16364). In summary: it would mean a lot less headache to be able to use 'guild compile'. Unfortunately, this does not work. One issue is that our Scheme files are mostly not Guile modules, but loaded directly with primitive-load-path. This will be a lot of work to fix, but it is on our end. However, I don't understand how to get around another issue, which is how our Scheme code interfaces with C++. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52230 Basically, if a Scheme file has something like (define-public point-stencil (ly:make-stencil "" '(0 . 0) '(0 . 0))) where ly:make-stencil is a procedure defined in C++, I can get this file to compile, but I can't get files using it as a module to compile. Investigation shows that Guile is apparently trying to load the module when compiling. $ cat print.scm (define-module (print)) (display "Module running!") $ guild compile print.scm wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/print.scm.go' $ cat import.scm (use-modules (print)) $ guild compile -L . print.scm wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/print.scm.go' $ guild compile -L . import.scm Module running!wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/import.scm.go' For functions defined in C++, that does not work: they are added by the entry point in the function that scm_boot_guile calls, using scm_c_define_gsubr. They aren't defined until the program is actually run. So how is 'guild compile' supposed to work with C(++) code? Thanks in advance, Jean
Re: 'guild compile' and C(++) extensions (in the context of LilyPond)
On Sat, 19 Feb 2022, Jean Abou Samra wrote:
I had similar problem with Jami. I added C++ primitives to Guile, but
these were not load using the foreign function interface. Note, I'm
using Guile 3.0.8, but I think the same could be done for Guile 2.0.
Basically what I do is to add a `compile` command to my program so to
speak.
So usually the program does this:
main -> install_scheme_primitives() -> Run the program
And for compilation
main -> compile_in_guile() -> install_scheme_primitives() ->
compile-file
To be clear here's what install_scheme_primitives() does:
void
install_scheme_primitives()
{
/* Define modules here */
auto load_module = [](auto name, auto init){
scm_c_define_module(name, init, NULL);
};
load_module("jami account", install_account_primitives);
load_module("jami call", install_call_primitives);
load_module("jami conversation", install_conversation_primitives);
load_module("jami logger bindings", install_logger_primitives);
load_module("jami signal bindings", install_signal_primitives);
}
and here's what compile_in_guile() does:
void*
compile_in_guile(void* args_raw)
{
// ...
install_scheme_primitives();
// This string is usually formatted
scm_c_eval_string("(use-modules (system base compile))"
"(compile-file \"foo.scm\" #:output-file \"foo.go\")")
// ..
}
so now I can correctly compile any file in the project. I just add this
to Makefile.am:
MODULES = foo.scm
GOBJECTS = $(MODULES:%=%.go)
%.go: %.scm | program
@echo GUILD; ./program compile $< $@
Hope that can help.
--
Olivier Dion
Polymtl
