Re: Curiosity: Microkernel implemented in Guile ?
"Dr. Arne Babenhauserheide" writes: > - The compilation-messages (I hate them; these also hurt when writing > interactive utilities for the command-line, and I have too many > half-working fixes in script files to still be comfortable; I think I > once had a fix in configuration, but I lost it again — or maybe I had > just hacked Guile) I use compilation (of Wisp) in the GWL and I silence output while compiling by redirecting the current-error-port / current-output-port. -- Ricardo
Re: Curiosity: Microkernel implemented in Guile ?
Ricardo Wurmus writes: > "Dr. Arne Babenhauserheide" writes: > >> - The compilation-messages (I hate them; these also hurt when writing >> interactive utilities for the command-line, and I have too many >> half-working fixes in script files to still be comfortable; I think I >> once had a fix in configuration, but I lost it again — or maybe I had >> just hacked Guile) > > I use compilation (of Wisp) in the GWL and I silence output while > compiling by redirecting the current-error-port / current-output-port. Those are my half-working fixes, too :-) But from time to time I have a real error in a file and don’t get the compilation messages (like "using unbound variable"). That’s why I think that they are only half-working. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Curiosity: Microkernel implemented in Guile ?
OK, let's face the issues, I encountered similar problems like what you described. 1. To avoid the irritating compiling message, I have to use parameters to rebind current-error-port. 2. Sometimes folks compile the Guile code and installed it in a wrong load path, so when you run it, it will auto compile everthing again. 3. The debug information seems broken for a long time, it's not good to trace the error. But I don't think it's because of the design of Guile, it's broken when Guile had upgraded the VM implementation. It was good before that. 4. For quick experiment attempt you described, I confess I have no better idea. But it's good to hear your experiences. Best regaeds. On Sat, Jun 25, 2022, 22:36 Jean Abou Samra wrote: > > > > Le 24 juin 2022 à 09:45, Dr. Arne Babenhauserheide > > a écrit : > > > > > > Jean Abou Samra writes: > > > Le 24 juin 2022 à 03:13, Nala Ginrut a > écrit : > >>> > >>> Agreed, Guile's design was widened. > > > >> Let’s be honest: it wasn’t widened, but shifted. I don’t > >> think today’s Guile is a good fit for an extension language. > > > > Why? Which change caused it to not be good as extension language? > > > > (Also replying to Nala.) On the one hand, you have Guile without > compiled > bytecode, which is slow to run, and more importantly painful to use > because there are no error locations and often no function names in > error messages. On the other hand, Guile with bytecode takes compilation > time, which is an impediment in applications where it is merely being > used as a language that is practical to use for small extensions to an > existing program, without a need for optimized code. It forces you to > recompile even if you just touched one file, since otherwise it emits > ;;; messages about outdated .go files that create noise and/or affect > correctness. The compilation is impractical to set up when interfacing > with C if your main function is on the C side since compiling is started > from the Scheme side. There is no dependency tracking, so you need to > recompile everything whenever you change one file, which does not > encourage > quick experiments. Bytecode is fussy to integrate in installers: when > the user > unpacks an archive, you need to ensure that the .go files are unpacked > after the .scm files, otherwise Guile will consider them outdated. I > could list more … > > As a developer on one of the main applications extended with Guile in > existence (LilyPond), I would not recommend Guile to anyone looking > for an extension language for a new application today. > > Sorry for not exactly bringing enthusiasm to this otherwise interesting > thread. > > Best regards, > Jean > > > > > > >
mmap for guile
I have a candidate mmap implementation for guile (3.0.8) in github.com/mwette/guile-contrib/patch/3.0.8/mmap-api.patch It probably needs some review and update. Maybe windows mmap-file would be nice. I'm not sure I updated the configure correctly but --disable-mmap-api should remove. It exposes features 'mmap-api and 'mmap-file. scheme@(guile-user)> ,d mmap - Scheme Procedure: mmap addr len [prot [flags [fd [offset See the man page. Returns a bytevector. Note that the region returned by mmap will NOT be searched by the garbage collector for pointers. See also mmap/search. Defaults are: prot (logior PROT_READ PROT_WRITE) flags (logior MAP_ANON MAP_PRIVATE) fd -1 offset 0 scheme@(guile-user)> ,d mmap/search - Scheme Procedure: mmap/search addr len [prot [flags [fd [offset See the unix man page for mmap. Returns a bytevector. Note that the region allocated will be searched by the garbage collector for pointers. Defaults: prot (logior PROT_READ PROT_WRITE) flags (logior MAP_ANON MAP_PRIVATE) fd -1 offset 0 scheme@(guile-user)> ,d mmap-file - Scheme Procedure: mmap-file file [prot] This procedure accepts a file in the form of filename, file-port or fd. It returns a bytevector. It must not contain scheme allocated objects as it will not be searched for pointers. Default PROT is `"r"'.
guile-json 4.7.2 released
Hi, I'm happy to announce guile-json 4.7.2. This is a minor bug fix release that reverts a breaking change introduced in 4.7.1 and fixes the original issue properly (optional nested records). * About guile-json is a JSON module for Guile. It supports parsing and building JSON documents according to the http://json.org specification. - Complies with http://json.org specification. - Supports JSON Text Sequences (RFC 7464). - Supports parsing concatenated JSON documents. - Builds JSON documents programmatically using scheme data types. - Allows JSON pretty printing. * Download Compressed sources and a GPG detached signature[*]: https://download.savannah.nongnu.org/releases/guile-json/guile-json-4.7.2.tar.gz https://download.savannah.nongnu.org/releases/guile-json/guile-json-4.7.2.tar.gz.sig [*] To verify download both files and then run: gpg --keyserver keys.openpgp.org \ --recv-keys 7CEC5511C8D057A9EF17470C54D4CC6FFC7468F4 gpg --verify guile-json-4.7.2.tar.gz.sig * Changes since 4.7.2 https://github.com/aconchillo/guile-json/blob/master/NEWS Bugs and comments can be reported at https://github.com/aconchillo/guile-json/issues Happy hacking! Aleix
Re: mmap for guile
Appologies: link is https://github.com/mwette/guile-contrib/blob/main/patch/3.0.8/mmap-api.patch On 6/26/22 8:37 AM, Matt Wette wrote: I have a candidate mmap implementation for guile (3.0.8) in github.com/mwette/guile-contrib/patch/3.0.8/mmap-api.patch It probably needs some review and update. Maybe windows mmap-file would be nice. I'm not sure I updated the configure correctly but --disable-mmap-api should remove. It exposes features 'mmap-api and 'mmap-file. scheme@(guile-user)> ,d mmap - Scheme Procedure: mmap addr len [prot [flags [fd [offset See the man page. Returns a bytevector. Note that the region returned by mmap will NOT be searched by the garbage collector for pointers. See also mmap/search. Defaults are: prot (logior PROT_READ PROT_WRITE) flags (logior MAP_ANON MAP_PRIVATE) fd -1 offset 0 scheme@(guile-user)> ,d mmap/search - Scheme Procedure: mmap/search addr len [prot [flags [fd [offset See the unix man page for mmap. Returns a bytevector. Note that the region allocated will be searched by the garbage collector for pointers. Defaults: prot (logior PROT_READ PROT_WRITE) flags (logior MAP_ANON MAP_PRIVATE) fd -1 offset 0 scheme@(guile-user)> ,d mmap-file - Scheme Procedure: mmap-file file [prot] This procedure accepts a file in the form of filename, file-port or fd. It returns a bytevector. It must not contain scheme allocated objects as it will not be searched for pointers. Default PROT is `"r"'.
Re: mmap for guile
On Sun, 26 Jun 2022, Matt Wette wrote: > flags >(logior MAP_ANON MAP_PRIVATE) Why MAP_ANON instead of MAP_ANONYMOUS. The latter is more clear and you don't have to care about compatibility like C does. Also, does MAP_FIXED or MAP_FIXED_NOREPLACE is passed to `flags' if `(not (eq? addr %null-pointer))'? > scheme@(guile-user)> ,d mmap/search What's the difference with `mmap'? > scheme@(guile-user)> ,d mmap-file > - Scheme Procedure: mmap-file file [prot] > This procedure accepts a file in the form of filename, file-port or > fd. It returns a bytevector. It must not contain scheme allocated > objects as it will not be searched for pointers. Default PROT is > `"r"'. I assume that this map the entire file at offset 0 with PROT_READ? In that case, is it with MAP_SHARED or MAP_PRIVATE? I think it's important to mentioned this point. Regards, old -- Olivier Dion oldiob.dev
Re: mmap for guile
Matt Wette schreef op zo 26-06-2022 om 08:37 [-0700]: > scheme@(guile-user)> ,d mmap/search > - Scheme Procedure: mmap/search addr len [prot [flags [fd [offset > See the unix man page for mmap. Returns a bytevector. Note that > the region allocated will be searched by the garbage collector for > pointers. Defaults: The types aren't documented and I don't think just referring to the man page is sufficient, because C and Scheme have actually different APIs and semantics -- e.g., if I don't care about the address, can I set it to #false? Is it only fds or also ports? Why does the abbreviation 'addr' mean (why not in full: address, likewise for 'len')? C has its own style of error reporting, but how does this map to Scheme? Do I get a ENOENT return value, or a ENOENT system-error, an &i/o-file-is-read- only, an &i/o-filename, an &i/o-invalid-position? Is the address a raw number or a bytevector (made with pointer->bytevector) or a pointer? Is the offset inside the file, or w.r.t. the current position? I think it's fine to not document all the MAP_ flags, but I think we need at least the basics (MAP_ANONYMOUS, PROT_READ, PROT_WRITE). Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: mmap for guile
Some old mmap things that might be useful:
* https://lists.nongnu.org/archive/html/guile-devel/2013-04/msg00235.html
* https://lists.gnu.org/archive/html/bug-guile/2017-11/msg00033.html
* https://lists.gnu.org/archive/html/guile-user/2006-11/msg00013.html
+SCM_DEFINE (scm_mmap_search, "mmap/search", 2, 4, 0,
+(SCM addr, SCM len, SCM prot, SCM flags, SCM fd, SCM
offset),
+ "See the unix man page for mmap. Returns a bytevector.\n"
+ "Note that the region allocated will be searched by the
garbage\n"
+ "collector for pointers. Defaults:\n"
I think it would be a good idea to document it will be automatically
unmapped during GC, as this is a rather low-leel interface
Also, what if you mmap a region, use bytevector->pointer and pass it to
some C thing, which saves the pointer somewhere where boehm-gc can find
it and boehm-gc considers it to be live, is there something that
prevents boehm-gc from improperly calling the finalizer & unmapping the
region, causing a dangling pointer?
Also, WDYT of using ports instead of raw fds in the API? That would
play nicer with move->fdes etc.
> + GC_exclude_static_roots(ptr, (char*)ptr + len);
After an unmap, will the GC properly forget the roots information?
>+ /* Invalidate further work on this bytevector. */
>+ SCM_BYTEVECTOR_SET_LENGTH (bvec, 0);
>+ SCM_BYTEVECTOR_SET_CONTENTS (bvec, NULL);
Possibly Guile's optimiser assumes that bytevectors never change in
length (needs to be checked). So unless the relevant optimiser code is
changed, and it is documented that bytevectors can change in length, I
think it would be safer to not have an unmapping procedure in Scheme
(though a procedure for remapping it as /dev/zero should be safe).
> + bvec = scm_c_take_typed_bytevector((signed char *) c_mem + c_offset, c_len,
> + SCM_ARRAY_ELEMENT_TYPE_VU8, pointer);
Would scm_pointer_to_bytevector fit here? Also, scm_c_make_typed_bytevector
looks like something that can cause an out-of-memory-exception but the
finaliser hasn't been set yet.
>+// call fstat to get file size
>+SCM_DEFINE (scm_mmap_file, "mmap-file", 1, 1, 0,
>+(SCM file, SCM prot),
>+ "This procedure accepts a file in the form of filename,\n"
>+" file-port or fd. It returns a bytevector. It must
>not\n"
>+" contain scheme allocated objects as it will not be\n"
>+" searched for pointers. Default @var{prot} is @code{\"r\"}.")
I would restrict the C code to only ports and file descriptors, and leave file
names to a Scheme wrapper. That way, you automatically get appropriate E...
errors in case open-file fails (and maybe &i/o-filename etc. if the core Guile
FS functions are later changed to R6RS), less chance on accidentally forgetting
to close a fd (*) ...
(*) One possible problem: if the file is opened, and mmap fails, then you still
need to close the file port (and rethrow), so some exception handling is still
required, though no C-style exception handling ...
> +/* The following copied from bytevectors.c. Kludge? */
> +#define SCM_BYTEVECTOR_SET_LENGTH(_bv, _len)\
> + SCM_SET_CELL_WORD_1 ((_bv), (scm_t_bits) (_len))
> +#define SCM_BYTEVECTOR_SET_CONTENTS(_bv, _contents) \
> + SCM_SET_CELL_WORD_2 ((_bv), (scm_t_bits) (_contents))
To avoid accidental problems if bytevectors.c is modified later, I'd add add a
comment
in bytevectors.c referring to this file, to add a reminder that mmunmap
makes assumptions about the layout.
> + scm_c_define ("PAGE_SIZE", scm_from_int (getpagesize()));
From local man page:
SVr4, 4.4BSD, SUSv2. In SUSv2 the getpagesize() call is labeled
LEGACY, and in
POSIX.1-2001 it has been dropped; HP-UX does not have this call.
NOTES
Portable applications should employ sysconf(_SC_PAGESIZE) instead of
getpage‐
size():
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
[feature request] merge sxml->html from (haunt html) into guile?
Hiya Guilers, Having just wrapped up the Scribble Jam project I mentioned in my Guix Days talk on the Guile Docs makeover, I'm getting back to the topic of the documentation. I figured this is a good excuse to finally move my hiney and finally do something I've been putting off for the simple reason I find writing HTML a bore -- creating a blog where I can collect all these thoughts and tips to help improve the Guix/Guile knowledge ecosystem. So of course, I figured I will try to make the web process less boring by doing it in Guile, and naturally went to the SXML docs, as I've had some ideas for a Guile extension that combines ideas from structured writing to make an easy and fun documentation and tutorial system that can be queried from the Guile repl. I could kill two bird with one stone! So I thought... This lead me to spend the last two nights learning XSLT and XHTML. I read Peter Bex's dynamic web tutorial, and then started hitting the XSLT textbooks. And after two nights and several hundred loc, I had as you may imagine, a poor skeleton of a website from 1995. Jeez, I thought, how much work are they doing to write the Guix website in Guile? They're really sticking to XHTML? Usually I'm not the type that heads straight to examples. I typically want to get away from the world with something new, try to study it on my own, and then later look to what others are doing. In this case, that lead me to try to poke at figuring out an sxml->html transformation myself, digging through Oleg Kisleyovs papers, and various ancient texts on the merits of XHTML, XSLT, XPath, etc... but it became clear that XML really isn't just a simple markup format that can be learned quickly, and my total lack of web skills weren't going to ramp up quickly enough to go from a "My First Geocities" aesthetic to the beautiful read I had been scheming up in my imagination. Finally I caved and decided to look at the Bootstrappable source code, and voila! (haunt html) provides sxml->html... the piece of the puzzle I was missing. Massive, near comical, relief. I'd like to suggest that, with Dave Thompson's approval, we could incorporate this function into Guile as I can imagine others going through a similar process. SXML remains a powerful tool, but without a modern way to get your results on screen it can appear archaic. But also, as someone who doesn't work in web *at all*, I don't really know how often HTML changes and how much of a burden the maintenance could be for the maintainers. So if its likely to become a fussy hairball, I understand. But I do think it could be an extremely helpful addition to (sxml simple), which also is in need of documentation, so if folks would agree this would be useful I'd be happy to, in turn, provide documentation for the currently missing SXML page, covering all the functions in (sxml simple). WDYT? ez, b -- Blake Shaw Director, SWEATSHOPPE sweatshoppe.org ---
