i wrote a FFI to inotify system call.
https://github.com/ChaosEternal/guile-inotify2
procedures:
* inotify-init
* inotify-init1
* inotify-add-watch
* inotify-rm-watch
* inotify-read-port
the errno handle is unreliable, use with caution.
License: LGPL v3
Date: Wed, 12 Nov 2014 01:59:13 +0800
From: Chaos Eternal chaoseter...@shlug.org
and it is not very portable.
On Wed, Nov 12, 2014 at 1:55 AM, Chaos Eternal chaoseter...@shlug.org wrote:
i wrote a FFI to inotify system call.
https://github.com/ChaosEternal/guile-inotify2
Eli Zaretskii e...@gnu.org writes:
Why not use the glib file monitoring instead? It is much more
portable, and has an inotify back-end AFAIK.
If you're only after inotify, glib seems like a heavy dependency.
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG
From: David Thompson dthomps...@worcester.edu
Cc: guile-devel@gnu.org
Date: Tue, 11 Nov 2014 15:05:05 -0500
Eli Zaretskii e...@gnu.org writes:
Why not use the glib file monitoring instead? It is much more
portable, and has an inotify back-end AFAIK.
If you're only after inotify,
Eli Zaretskii e...@gnu.org writes:
But inotify is practically a single-OS solution. How does it make
sense for Guile to support file notifications only on one platform?
That effectively limits packages that use Guile as an extension
language to that single platform.
From what I could see,
Mark H Weaver m...@netris.org writes:
tantalum s...@posteo.eu writes:
with guile version 2.1.0.89-c5ea7 on an x86_64 GNU/Linux system
and the following code
(use-modules (srfi srfi-4) (rnrs bytevectors))
(define a (make-f32vector 2 0))
(define b (bytevector-copy a))
(write (list a
