Some non-standard O_* flags are missing

, O_NOLINK and O_NOATIME, the others don't matter for me, though they may be useful for others. Could extra O_* flags be exported to Guile (in libguile/filesys.c) on systems where they are defined? Greetings, Maxime -- Maxime Devos PGP Key: C1F3 3EE2 0C52 8FDB 7DD7 011F 49E3 EE22 1917 25EE Freenode

Re: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Linus Björnstam schreef op do 17-06-2021 om 14:57 [+0200]: > Guile already does definitions in expression context in > the bodies of lambda and let-variants. I think this is > not a big problem since any valid r6rs code is still valid guile. ‘Guile already does definitions in expression context

Re: Ephemerons, self-referentality in weak hashtables

Christopher Lemmer Webber schreef op di 18-05-2021 om 11:46 [-0400]: > Hello, > > I'm finally taking some time to port Goblins to Guile, in-between other > tasks anyway. In Goblins there is a weak hashtable that maps current > actor references to their current behavior. I found that for >

Re: thoughts on targetting the web

Andy Wingo schreef op za 19-06-2021 om 22:20 [+0200]: > 5. Garbage collection. *We should re-use the host GC*. Although it > would be possible to manage a heap in linear memory, that has > retention problems due to cycles between the Guile heap and the JS > heap. I could be

Re: Ephemerons, self-referentality in weak hashtables

Maxime Devos schreef op zo 20-06-2021 om 17:01 [+0200]: > Christopher Lemmer Webber schreef op di 18-05-2021 om 11:46 [-0400]: > > Hello, > > > > I'm finally taking some time to port Goblins to Guile, in-between other > > tasks anyway. In Goblins there is a weak

Re: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Linus Björnstam schreef op wo 16-06-2021 om 21:11 [+0200]: > Hi there! > > This patch updates some derived conditional forms (and do and and-let*) > to support definitions in expression context. Meaning it makes this valid > code: > > (cond > ((pred? arg) > (define a (something arg)) >

Add ‘expt’ to the list of effect-free primitives

From b9d0faf091c316d0811d73df9eea134dc23f8ed6 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 16 May 2021 20:32:34 +0200 Subject: [PATCH] =?UTF-8?q?Add=20=E2=80=98expt=E2=80=99=20to=20the=20list?= =?UTF-8?q?=20of=20effect-free=20primitives.?= MIME-Version: 1.0 Content-Type: text/plain

Re: [PATCH] Remove unused variable.

Roel Janssen schreef op ma 24-05-2021 om 15:01 [+0200]: > Hi Guilers, > > While compiling Guile with "-Wall" I noticed this unused declaration. I think you ned to modfy gnulib-local/lib/localcharset.c.diff as well. It seems like the original localcharset.c comes from gnulib and it has been

Casts to pointer from integer of different size?

Hi guilers, While debugging a build failure of guile on the core-updates branch of guix (see https://isues.guix.gnu.org/49368) when build for i686 (guix build --system=i686-linux), I noticed some following warnings which look suspicious (plenty of tests are passing though, it is only the test

Re: GC + Java finalization

Jonas Hahnfeld schreef op za 03-07-2021 om 19:26 [+0200]: > > Normally scm_remember_upto_here is used for that. > > I think I tried, but it wasn't available. Or I mistyped, not sure. It is defined in . Actually, the special case scm_remember_upto_here_1 would be prefered, because it

Re: GC + Java finalization

Jonas Hahnfeld schreef op za 03-07-2021 om 19:26 [+0200]: > Sorry, I should have been clearer: Chains don't become uncollectable, > but a chain of N objects takes N collections to be completely reclaimed > (because Java finalization prepares for the possibility that a free > function makes an

Re: [PATCH] Bindings to *at functions & allowing more functions to operate on ports

rob piko schreef op di 04-05-2021 om 18:58 [-0400]: > Hello Maxime, > > > * Use O_NOFOLLOW to *not* follow the symbolic link. > > Patch for adding O_NOFOLLOW to guile: > > According to the man pages for the O_NOFOLLOW: > > > If the trailing component (i.e., basename) of pathname is > >

Linking to libraries in the ELF?

Hi guilers, I've got this crazy idea a few days ago, about the FFI interface. When a program written in C is compiled with some shared libraries, these libraries are referred to in special [insert ELF terminology here] of the binary. I wonder if it would be reasonable and feasible to do

Re: [PATCH] srfi-64: fix unused variable warnings

On Thu, 2021-04-01 at 23:12 -0700, Aleix Conchillo Flaqué wrote: > Hi Maxime, > > Thank you for your comments! > > On Thu, Apr 1, 2021 at 4:37 AM Maxime Devos wrote: > > > For example, in: > > > > > (define (%test-comp2 comp x) > > >

Re: [PATCH] Bindings to *at functions & allowing more functions to operate on ports

Hi, [CC'ing some Guile and Guix maintainers because this is important for the security of Guix System.] I want to explain why these patches (and the O_FLAGS (*) patch) should be included in Guile. Functions like "openat" are important to avoid TOCTTOU (time-of-check to time-of-use)

Re: [PATCH] Allow null bytes in UNIX sockets.

On Mon, 2021-03-29 at 17:37 +0200, Leo Prikler wrote: > The current socket address constructors all assume, that there are no > null bytes in the socket path. This assumption does not hold in Linux, > which uses an initial null byte to demarcate abstract sockets and > ignores all further null

Re: [PATCH] srfi-64: fix unused variable warnings

On Wed, 2021-03-31 at 23:11 -0700, Aleix Conchillo Flaqué wrote: > * module/srfi/srfi-64/testing.scm: remove unused name variable and use > let instead of let*. > I don't think this is the correct approach with respect to side effects. For example, in: > (define (%test-comp2 comp x) >

[PATCH] Bindings to *at functions & allowing more functions to operate on ports

operating on ports where I think it's needed. I haven't assigned copyright to the FSF, how would this work? Greetings, Maxime From e4deaca45606a9ade686e7cf447c9cec93e8c9e2 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sat, 6 Mar 2021 21:39:52 +0100 Subject: [PATCH 01/17] Add

Re: Some non-standard O_* flags are missing

On Tue, 2021-03-09 at 21:36 +0100, Andy Wingo wrote: > Hi :) Sure, would be happy to accept a patch for these. See and messages above. I'll look at updating NEWS and the manual later. > It's adding > more definitions to the base

Re: Preventing file descriptor leak to execl'd processes

On Sat, 2021-03-06 at 17:55 +0100, Marius Bakke wrote: > Hello Guilers, > > [...] > > It works great, except that the script filename (/tmp/test-shell) has > an open file descriptor which leaks into the new process: > > [...] > > I've managed to work around it by setting FD_CLOEXEC on it: > >

[PATCH] Add scm_remember_upto_here to functions using a port's fd.

Oops, I forgot to add myself to THANKS. Seems rather presumptive of me, but it's recommended by HACKING ... From b3fe19e393b88a5227f9f1b9e1f5de09985c4e3d Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sat, 6 Mar 2021 21:39:52 +0100 Subject: [PATCH] Add scm_remember_upto_here to functions using

[PATCH] Add scm_remember_upto_here to functions using a port's fd.

: Brian Crowder Christopher Cramer Josh Datko + Maxime Devos David Diffenbaugh Hyper Division Erik Dominikus diff --git a/libguile/filesys.c b/libguile/filesys.c index 020c9cf7b..60311501e 100644 --- a/libguile/filesys.c +++ b

Fix for ‘,trace (method ()) --> no applicable method for ...’

Hi guile, Attached is a fix for <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50608> and a similar issue for 'procedure-name'. Greetings, Maxime. From fe518ed4fb2c7e55f69a229349e3183ccfdcfc97 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Wed, 15 Sep 2021 19:57:20 +0200 Subject: [PAT

Re: Request to add *-resize! functions for contiguous mutable data structures.

Vijay Marupudi schreef op vr 06-08-2021 om 09:33 [-0500]: > Hello! > > I was curious if Guile would be willing to provide a series of > new procedures for resizing contiguous memory regions. > > (bytevector-resize! new-size [fill]) > (vector-resize! new-size [fill]) > > The [fill] parameter

Re: new function

Damien Mattei schreef op do 23-09-2021 om 19:27 [+0200]: > yes i know parsing the whole code is the only portable solution, but it is > slow,even on a few dozen of lines the slowing is visible ,so i can even think > of that on one thousand lines... > > I finally succeed in Guile with simple

Re: Maintenance and future of Guile

Hi, Blake Shaw schreef op ma 20-12-2021 om 03:05 [+0700]: > personally I've been programming for about 15 years now but my career > has been entirely in new media (video, graphics, audio), so while > I've > worked with plenty of lower-level libraries over the years, I didn't > start to get an

Re: Scheme+

Linus Björnstam schreef op ma 20-12-2021 om 09:15 [+0100]: > I played around with it and it seems to rely heavily on mutation, > which makes guile (and chez and racket for that matter) box the > values. That adds a layer of indirection to memory access, meaning > slower code (apart from the more

Re: GC + Java finalization

Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]: > From 33af6a98c6801e7b4880d1d3f78f7e2097c2174e Mon Sep 17 00:00:00 > 2001 > From: Jonas Hahnfeld > Date: Fri, 2 Jul 2021 23:03:17 +0200 > Subject: [PATCH 2/3] Avoid matching calls of scm_gc_free > > There is no point in registering

Re: GC + Java finalization

Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]: > +  SCM *smobs = scm_gc_malloc (sizeof(SCM) * SMOBS_COUNT, "smobs"); > + >    int i; >    mark_call_count = 0; >    for (i = 0; i < SMOBS_COUNT; i++) > -    make_x (); > +    smobs[i] = make_x (); >    scm_gc (); smobs doesn't need to be

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > > > -  rx = scm_gc_malloc_pointerless (sizeof (regex_t), "regex"); > > > +  rx = scm_malloc (sizeof (regex_t)); > > > > If the regex why scm_gc_malloc_pointerless -> scm_malloc? > > Is rx not pointerless? > > Not sure I understand the

Re: GC + Java finalization

Maxime Devos schreef op vr 19-11-2021 om 13:44 [+]: > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]: > > Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos: > > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > &g

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:55 [+0100]: > Am Freitag, dem 19.11.2021 um 13:48 + schrieb Maxime Devos: > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > > > > > -  rx = scm_gc_malloc_pointerless (sizeof (regex_t), > > > > >

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:35 [+0100]: > Am Freitag, dem 19.11.2021 um 13:15 + schrieb Maxime Devos: > > Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]: > > > +  SCM *smobs = scm_gc_malloc (sizeof(SCM) * SMOBS_COUNT, > > > "

Re: GC + Java finalization

Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]: > +  /* For guardians, we use unordered finalization `a la Java. */ Maybe add the reasons why this is only done when a guardian is created? E.g., /* Don't use unordered finalization when not using guardians,     because Java finalization

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > > You coud simply ... > > > > > > > -  scm_gc_free (rx, sizeof(regex_t), "regex"); > > > +  free (rx); > > > > drop the scm_gc_free AFAIK. > > No, I cannot as explained in the patch summary: If we use scm_gc_free > in a free

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:53 [+0100]: > [...] > The straight-forward solution is to statically tie the lifetime of > regex_t to that of the smob. Which we cannot do with GC, but simply > with malloc+free - as implemented in the patch. OK, but for clarity I recommend adding a

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]: > Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos: > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > > > > You coud simply ... > > > > > > > > > > &g

Re: GC + Java finalization

Jonas Hahnfeld schreef op vr 19-11-2021 om 15:52 [+0100]: > Am Freitag, dem 19.11.2021 um 14:14 + schrieb Maxime Devos: > > [...] > > > > From your other responses, I now know it is actually related to > > (non- > > )Java style finalisation, but my comment

[PATCH v2 02/14] Allow file ports in ‘readlink’.

* configure.ac: Detect whether ‘readlinkat’ is defined. * libguile/filesys.c (scm_readlink): Support file ports when ‘readlinkat’ exists. (scm_init_filesys): Provide ‘chdir-ports’ when it exists. * doc/ref/posix.texi (File System): Document it. * test-suite/tests/filesys.test ("readlink"):

[PATCH v2 00/14] Bindings to *at functions

. Maxime Devos (14): Allow file ports in ‘chdir’ when supported. Allow file ports in ‘readlink’. Allow file ports in ‘utime’. Define ‘symlinkat’ wrapper when supported. Define bindings to ‘mkdirat’ when the C function exists. Correct documentation of ‘mkdir’ w.r.t. the umask. Define

[PATCH v2 10/14] Define a Scheme binding to ‘unlinkat’ when it exists.

‘unlinkat’ is used for both unlinking regular files and removing empty directories. * configure.ac: Detect if ‘unlinkat’ exists. * doc/ref/posix.texi (File System): Document why there is no ‘rmdirat’ procedure, and document the ‘delete-file-at’ procedure. * libguile/filesys.c (scm_rmdir):

[PATCH v2 09/14] Define a Scheme binding to ‘fchmodat’ when it exists.

* configure.ac: Detect existence of fchmodat. * libguile/filesys.c (scm_chmodat): New procedure. * libguile/filesys.h (scm_chmodat): Make it part of the API. * test-suite/tests/filesys.test ("chmodat"): Test it. --- configure.ac | 4 +-- libguile/filesys.c| 36

[PATCH v2 04/14] Define ‘symlinkat’ wrapper when supported.

* configure.ac: Detect whether ‘symlinkat’ exists. * libguile/filesys.c (scm_symlinkat): Define a Scheme binding when it exists. * libguile/filesys.h: Make the binding part of the public C API. * doc/ref/posix.texi (File System): Document the binding. * test-suite/tests/filesys.test

[PATCH v2 03/14] Allow file ports in ‘utime’.

ware Foundation, Inc. + Copyright 2021 Maxime Devos This file is part of Guile. @@ -1648,13 +1649,14 @@ SCM_DEFINE (scm_tmpfile, "tmpfile", 0, 0, 0, #undef FUNC_NAME SCM_DEFINE (scm_utime, "utime", 1, 5, 0, -(SCM pathname, SCM actime, SCM modtime, SCM actimens,

[PATCH v2 13/14] Define Scheme bindings to ‘openat’ when available.

* configure.ac: Detect if ‘openat’ is defined. * libguile/filesys.c (flags_to_mode): Extract from ... (scm_mode): ... here. (scm_open_fdes_at, scm_openat): Define the Scheme bindings. * libguile/filesys.h (scm_open_fdes_at, scm_openat): Make them part of the API. * doc/ref/posix.texi (File

[PATCH v2 01/14] Allow file ports in ‘chdir’ when supported.

--- a/doc/ref/guile.texi +++ b/doc/ref/guile.texi @@ -14,7 +14,8 @@ This manual documents Guile version @value{VERSION}. Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software Foundation, -Inc. +Inc. \\ +Copyright (C) 2021 Maxime Devos Permission is granted to copy, distribute and

[PATCH v2 08/14] Define a Scheme binding to ‘renameat’ when it exists.

* configure.ac: Detect if ‘renameat’ is defined. * libguile/filesys.c (scm_renameat): Define a Scheme binding to the ‘renameat’ system call. * doc/ref/posix.texi (File System): Document it. * libguile/filesys.h (scm_renameat): Make it part of the C API. * test-suite/tests/filesys.test

[PATCH v2 05/14] Define bindings to ‘mkdirat’ when the C function exists.

* configure.ac: Detect if ‘mkdirat’ exists. * libguile/filesys.c (scm_mkdirat): Define the Scheme binding. * doc/ref/posix.texi (File System): Document it. --- configure.ac | 2 +- doc/ref/posix.texi| 6 ++ libguile/filesys.c| 25

[PATCH v2 14/14] Update NEWS.

--- NEWS | 12 1 file changed, 12 insertions(+) diff --git a/NEWS b/NEWS index 710b8ddda..922543a31 100644 --- a/NEWS +++ b/NEWS @@ -12,6 +12,9 @@ Changes in 3.0.8 (since 3.0.7) ** Fix compilation of (ash x N), where N is a literal, at -O1 and below ** Texinfo and XML parsers are

Re: [PATCH v2 01/14] Allow file ports in ‘chdir’ when supported.

Maxime Devos schreef op di 16-11-2021 om 11:06 [+]: >  Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software > Foundation, > -Inc. > +Inc. \\ > +Copyright (C) 2021 Maxime Devos \\ doesn't work. I'll try something else

[PATCH v2 07/14] Define AT_REMOVEDIR and others when available.

* libguile/posix.c (scm_init_posix): Define (in Scheme) AT_REMOVEDIR and AT_EACCESS when defined (in C). --- libguile/posix.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libguile/posix.c b/libguile/posix.c index bd7f40ca8..a6f7c9a0d 100644 --- a/libguile/posix.c +++

[PATCH v2 12/14] Define a Scheme binding to ‘fstatat’ when available.

* configure.ac: Detect if ‘fstatat’ is defined. * libguile/filesys.c (scm_statat): Define a Scheme binding to ‘fstatat’. * libguile/filesys.h (scm_statat): Make it part of the C API. * doc/ref/posix.texi (File System): Document it. * libguile/syscalls.h (fstatat_or_fstatat64): Choose between

Re: [PATCH v2 14/14] Update NEWS.

Maxime Devos schreef op di 16-11-2021 om 11:06 [+]: > [...] > +** Fix documentation of ‘mkdir’ > +   Previously, the documentation implied the umask was ignored if > the > +   mode was set explicitely.  However, this is not the case. As noted by Thien-Thi Nguyen, the spelling

[PATCH v2 11/14] Define a Scheme binding to ‘fchownat’ when it exists.

* configure.ac: Detect whether ‘fchownat’ is available. * libguile/filesys.c (scm_chownat): Define a Scheme binding to ‘fchownat’ when available. * libguile/filesys.h (scm_chownat): Make it part of the API. * doc/ref/posix.texi (File System): Document it. --- configure.ac | 4 ++--

Re: [PATCH v2 01/14] Allow file ports in ‘chdir’ when supported.

Maxime Devos schreef op di 16-11-2021 om 12:18 [+]: > Maxime Devos schreef op di 16-11-2021 om 11:06 [+]: > >  Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software > > Foundation, > > -Inc. > > +Inc. \\ > > +Copyright (C) 2021 Maxime Devos > >

Re: GC + Java finalization

Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]: > diff --git a/libguile/random.c b/libguile/random.c > index 63da7f5d6..ac400a9fd 100644 > --- a/libguile/random.c > +++ b/libguile/random.c > @@ -324,9 +324,7 @@ scm_c_random_bignum (scm_t_rstate *state, SCM m) >    /* we know the result

Re: [PATCH] New function array-mutable?

lloda schreef op do 25-11-2021 om 17:40 [+0100]: > [...] Suggestion: add a few tests to test-suite/tests/arrays.test: (pass-if-equal "new" #t (array-mutable? (make-array #f '(1 2) '(3 4 (pass-if-equal "empty (two-dimensional)" #t (array-mutable? (array-copy #1( (pass-if-equal

Re: [PATCH] New function array-mutable?

lloda schreef op do 25-11-2021 om 17:40 [+0100]: > +Arrays with empty roots are not considered immutable because > +@code{array-set!} operations with valid indices won't fail (since > there > +are no valid indices). > + > +@example > +(array-mutable? #()) @result{} #t > +@end example > +@end deffn

Re: [PATCH] New function array-mutable?

Hi, lloda schreef op do 25-11-2021 om 20:08 [+0100]: I think literal arrays are always immutable, and one could base the test on that. > Is such a function useful in some other context? If one has an array which is already immutable, it can be referenced freely and copying it seems unnecessary.

Re: Java finalization & smobs?

Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]: > On the one hand, the docs for smobs state "must assume .. all SCM > values that it references have already been freed and are thus > invalid", which suggests that smob freeing happens in random order, > which is consistent with what we

Re: Java finalization & smobs?

Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]: > We can change our mark routines to avoid the crash, but it's unclear > to us if this behavior is intended or not, and we worry that this > will > come back to bite us in the future. > [...] > [... things about Java-style finalisation

Re: Java finalization & smobs?

Hi, Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]: > which is consistent with what we see. On the other hand, Guile sets > up > BDWGC with GC_java_finalization=1, which should keep GC dependencies At least in Guile 3, that's done in scm_init_guardians. While that's always called in

Re: [patch] Add instructions for sending patches

Hi, Dr. Arne Babenhauserheide schreef op za 11-12-2021 om 16:12 [+0100]: > + (p "To contribute small improvements, please send patches to > " > +    (a (@ (href "mailto:guile-devel@gnu.org;)) > "guile-devel@gnu.org") > +   ".") What about contributing _large_ improvements? Where

[PATCH v2] Parse #{{}}# properly.

Maxime Devos schreef op zo 18-07-2021 om 21:47 [+0200]: > It turns out that the test fails when the patch > is applies to guile@3.0.7. I'll rebase and try > to figure things out. With the revised patch, tests succeed and the Guile library now compiles successfully. Greetings, Max

Fwd: [PATCH] Parse #{{}}# properly.

9fb7cff1a2544aae3827db1a781be6e5c367d8c0 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 18 Jul 2021 19:59:32 +0200 Subject: [PATCH] ice-9/read: Parse #{}}# properly. This is a regression since Guile 3.0.2 and breaks compilation of a Guile library. * module/ice-9/read.scm (%read)[read

Re: Fwd: [PATCH] Parse #{{}}# properly.

It turns out that the test fails when the patch is applies to guile@3.0.7. I'll rebase and try to figure things out. signature.asc Description: This is a digitally signed message part

Re: Guile optimizations slowing down the program?

Jean Abou Samra schreef op wo 09-03-2022 om 00:31 [+0100]: > In summary, the less Guile optimizes, the faster LilyPond runs. Is that > something expected? I don't think so, but I don't have a clue how this happens ... Greetings, Maxime signature.asc Description: This is a digitally signed

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op vr 21-01-2022 om 20:21 [-0500]: > +SCM_DEFINE (scm_utf8_range_to_string, "utf8->string", > +    1, 2, 0, > +    (SCM utf, SCM start, SCM end), > +    "Return a newly allocate string that contains from the > UTF-8-" > +    "encoded contents

Re: [PATCH] Enable utf8->string to take a range

Maxime Devos schreef op wo 09-03-2022 om 14:27 [+0100]: > That's not quite correct, seems like Guile uses another encoding, but > still. Nevermind, seems like a misinterpreded a comment and #vu8(97 0 98) is valid UTF-8 after all, it's just not possible to encode it as a zero- terminated

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op vr 21-01-2022 om 20:21 [-0500]: > +SCM_DEFINE (scm_utf8_range_to_string, "utf8->string", > +    1, 2, 0, > +    (SCM utf, SCM start, SCM end), > +    "Return a newly allocate string that contains from the > UTF-8-" > +    "encoded contents

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op vr 21-01-2022 om 20:21 [-0500]: > +SCM_DEFINE (scm_utf16_range_to_string, "utf16->string", > +    1, 3, 0, > +    (SCM utf, SCM endianness, SCM start, SCM end), > +    "Return a newly allocate string that contains from the > UTF-8-" > +   

Re: [PATCH] Enable utf8->string to take a range

Maxime Devos schreef op wo 09-03-2022 om 14:24 [+0100]: > This is incorrect, since the nul character is encoded even though > UTF- > proper does not allow encoding the nul character -- UTF-8 with an > encoding of the nul character is sometimes called ‘modified UTF-8’. That's not q

Re: hastbables in scheme, are they slow? using goops is this madness

Stefan Israelsson Tampe schreef op di 22-02-2022 om 00:05 [+0100]: > 2. For very large hash tables C based solutions are about 1.5-2.0 > faster. > (for-each (lambda (i) (hashq-set! h i i)) (iota 2000)) For what sizes is Scheme faster, and for what sizes is Scheme faster? Where is the cut-off

Re: Are source locations broken?

Jean Abou Samra schreef op vr 25-03-2022 om 21:11 [+0100]: > Please have a look at: > > $ ./libguile/guile test.scm > ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 > ;;;   or pass the --no-auto-compile argument to disable. > ;;; compiling

Re: Are source locations broken?

Maxime Devos schreef op vr 25-03-2022 om 21:22 [+0100]: Here's a minimal reproducer: $ cat trtr.scm: > foo $ guild compile trtr.scm > : warning: possibly unbound variable `foo' > wrote `$HOME/.cache/guile/ccache/3.0-LE-8-4.6/$HOME/trtr.scm.go' Curiously, it seems that source locat

A lexical use-modules?

Hi, [ CC'ing guix-devel@ because this functionality could be useful in Guix package definitions ] Currently, use-modules cannot be meaningfully used inside procedures, unless '(current-module)' is always the module in which the procedure is defined. I wondered if some kind of 'lexical

Re: A lexical use-modules?

Maxime Devos schreef op za 26-03-2022 om 20:21 [+0100]: > (define-syntax use-module/lexical >   ;; todo: integrate into (use-modules ...)? >   (lambda (s) >     (syntax-case s () >   ((_ foo) >    (let* ((module-name (syntax->datum #'foo)) >   (inte

Re: A lexical use-modules?

[Re-added guile-devel# to CC] Stefan Israelsson Tampe schreef op zo 27-03-2022 om 16:37 [+0200]: > I mean that modul-ref is a hash-table lookup, and that's more > expensive as you say. I suggested that lexical variables should be > let bound > because you can deduce more things with them e.g. in

Re: A lexical use-modules?

Stefan Israelsson Tampe schreef op zo 27-03-2022 om 11:53 [+0200]: Hmm actually you only have lexical macros that reference module variables. That is not lexical variables which have more optimisation associated with it at least used to. But is better speedwise than the hash lookups I suggested.

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Stefan Israelsson Tampe schreef op vr 04-02-2022 om 21:11 [+0100]: > using an implicit let in conditionals are bad in that you cannot > escape from the let form which means that you loos > conditional defines for example in the toplevel. e.g. [...] While old versions of Guile (Guile 1.8?) did

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

to...@tuxteam.de schreef op zo 06-02-2022 om 10:27 [+0100]: > ...but doesn't "see" whether bindings are actually used (quite > possibly > those go away in a later optimisation phase, though): > > | scheme@(guile-user)> ,expand (let ((x 3)) (message #t "Yikes")) > | $3 = (let ((x 3)) (message #t

Re: GNU Guile 3.0.8 released

Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]: > We are delighted to announce GNU Guile release 3.0.8, the latest in the [...] > The Guile 3.0.8 release mixes maintenance and optimizations [...] Is there any reason the fix was not

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Stefan Israelsson Tampe schreef op zo 06-02-2022 om 21:13 [+0100]: > Hmm just why conditionals use begin and not let, I'd assume the reason is that this is how it has been done in the past and because of performance reasons (which don't seem to apply anymore?), so I guess that we could now switch

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Stefan Israelsson Tampe schreef op zo 06-02-2022 om 22:10 [+0100]: > I think you are right on this, I looked at the scheme spec and I find > no trace for using a let or not or not in the spec. > So it is an implementation detail. Now, this is important, if I want > to write portable code if cond

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Maxime Devos schreef op zo 06-02-2022 om 22:26 [+0100]: > FWIW, Guile already exports unportable syntax in (rnrs base): > R6RS doesn't mention named let anywhere, yet Guile exports it as > 'let' > in (rnrs base) anyway. Nevermind, R6RS has named let: <http://www.r6rs.org/final/htm

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Stefan Israelsson Tampe schreef op za 05-02-2022 om 18:31 [+0100]: > Hmm this was wrong, I mean > > For conditional variables we have a default begin. So then why on > earth do you not have an implicit let?, Just laziness? Do you mean Guile in general, or the particular example I gave? Also, I

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Stefan Israelsson Tampe schreef op vr 04-02-2022 om 22:40 [+0100]: > Anyhow conditional defining vars is a common theme in other languages > so I think it was kind of natural to implement if as it was done. AFAIK no Lisp or Scheme except for Guile < 2.0 implements conditionally defining local

Re: Fwd: [Patch] definitions in when, unless, do as well as in cond- and case-clauses

Hi, > > (define foo 'bar) ;; <--- ^^^ > > (define-syntax foobar > > (syntax-rules (foo) > > ((_ foo) > > (begin (pk "it's a foo!") foo)) > > ((_ goo) > > (begin (pk "it's not a foo ...") goo > > > > (define (zebra stripes) > > (if stripes > > (define foo 'quux))

Re: [PATCH] Added srfi-214: flexvectors

Vijay Marupudi schreef op do 20-01-2022 om 10:34 [-0500]: > My latest patch now has documentation, mostly derived from the SRFI- > 214 > documentation. Who would have figured that conversion to texinfo > would be the > most time consuming part of this patch? > > I would like advice on how to

Re: [PATCH] Added srfi-214: flexvectors

Vijay Marupudi schreef op do 20-01-2022 om 12:57 [-0500]: > > Here are two examples in the wild (slib): > > Thanks, the patch, which is attached, now attributes credit > appropriately. > > Thank you very much for your help Maxime. I believe there is nothing > else pending and that the patch is

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op do 20-01-2022 om 22:23 [-0500]: > --- a/libguile/bytevectors.c > +++ b/libguile/bytevectors.c > [...] Boundary conditions can be tricky, I would recommend writing some tests. Greetings, Maxime. signature.asc Description: This is a digitally signed message part

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op do 20-01-2022 om 22:23 [-0500]: > +@deffn {Scheme Procedure} utf8->string utf [start [end]] >  @deffnx {Scheme Procedure} utf16->string utf [endianness] >  @deffnx {Scheme Procedure} utf32->string utf [endianness] >  @deffnx {C Function} scm_utf8_to_string (utf) >

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op do 20-01-2022 om 22:23 [-0500]: > +  c_start = scm_to_size_t (start); > +  if (SCM_UNLIKELY (c_start >= c_len)) > +    { > +  scm_out_of_range (FUNC_NAME, start); > +    } > + > +  if (!scm_is_eq (end, SCM_UNDEFINED)) > + { > +   c_end

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op do 20-01-2022 om 22:23 [-0500]: > +  c_start = scm_to_size_t (start); This seems suboptimal because if start > SIZE_MAX, then this will throw an 'out-of-range' exception without attributing it to 'utf8->string' (untested). Greetings, Maxime. signature.asc

Re: [PATCH] Enable utf8->string to take a range

Vijay Marupudi schreef op vr 21-01-2022 om 15:20 [-0500]: +  (pass-if-exception "utf8->string range: end < start" +  exception:out-of-range +  (let* ((utf8 (string->utf8 "gnu guile"))) +    (utf8->string utf8 1 0))) + [other tests] It would be nice to check multibyte characters as

Re: [PATCH] Added srfi-214: flexvectors

Vijay Marupudi schreef op wo 19-01-2022 om 10:44 [-0500]: > > If no copyright assignment has happend, then the copyright still > > belongs to the author > > -- from the Git repository's LICENSE:  Copyright © Adam Nelson > > (2020)). > > While possibly you might have made some small changes to > >

Re: [PATCH] Added srfi-214: flexvectors

Vijay Marupudi schreef op wo 19-01-2022 om 08:51 [-0500]: > > however, the README says ‘by Adam Nelson’.  Did you reach some kind > > of > > agreement with Adam Nelson about copyright assignment?  And since > > SRFIs > > are licensed under Expat (not 100% sure), wouldn't this need to be > > the >

Re: (web server) serving on both ipv6 and ipv4?

Dr. Arne Babenhauserheide schreef op wo 19-01-2022 om 08:57 [+0100]: > Hi, > > > with both fibers server and (web server) there is a split between IPv4 > and IPv6: > > > IPv4: > > (fibers:run-server handler-with-path #:family AF_INET #:port port #:addr > INADDR_ANY) > > (run-server

Re: [PATCH] Added srfi-214: flexvectors

Vijay Marupudi schreef op di 18-01-2022 om 21:34 [-0500]: > Hello, > > I have attached to this email a patch to add support for srfi-214, > flexvectors. > > I have made as few changes to the code from the sample implementation. > > If this is accepted, I can work on adding to the documentation.

Re: Hygienic rewrite of (ice-9 expect)

to personally not being able to figure out what to do with the patches, I wasn't referring to some specific technical issue. Best regards, Maxime Devos. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

  1   2   3   >