Re: define-typed: checking values on proc entry and exit

[Vivien Kraus]

Hello!

This is an interesting approach, thank you.

Le vendredi 10 mai 2024 à 09:47 +0200, Dr. Arne Babenhauserheide a
écrit :
> │   ;; get the result
> │   (let ((res (helper)))
> │ ;; typecheck the result
> │ (unless (ret? res)
> │   (error "type error: return value ~a does not match ~a"
> │  res ret?))
> │ ;; return the result
> │ res))

A nice improvement would be to support multiple return values, for
instance by using call-with-values, and checking the return value with
(apply ret? res) instead of (ret? res).

What do you think?

Best regards,

Vivien

Re: [ANN] Guile Hoot 0.4.1 released!

[Vivien Kraus]

Hello!

Le mardi 30 avril 2024 à 11:40 -0400, Thompson, David a écrit :
> * Initial support for Guile's define-module syntax. Currently limited
> to #:pure modules as Hoot does not yet provide the (guile) module
> which is implicitly imported by impure modules.

Could you briefly explain how we can make such a pure module, but which
exports something? I tried to add #:pure to a module of mine, and it
complains that I’m calling define…

Thank you for the release anyway.

Vivien

Re: guile or scheme used to implement make or meson

[Vivien Kraus]

Hello!

Le mardi 12 septembre 2023 à 09:56 -0400, Olivier Dion a écrit :
> What is more realistic and useful is to make a build system in Guile
> where the DSL that replaces Makefiles is Scheme.

Since make is only a small part of a useful build system, I think it is
way easier to re-implement make in guile than do a whole new build
system.

Vivien

Re: comparator in match pattern

[Vivien Kraus]

Le mercredi 28 juin 2023 à 17:10 +0200, Damien Mattei a écrit :
> Vivien , your solution is not working:
> 
> (let ((/ 42))
>   (match (list 1 42)
>     ((c (? (cut equal? <> /)))
>  c)))
> ;;; :30:2: warning: wrong number of arguments to `# (lambda () (lambda-case ((() #f #f #f () ()) (call (toplevel equal?)
> (toplevel <>) (lexical / /-1dff1b83541ce327-407)>'
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Wrong number of arguments to 42

It works on my side (see screenshot). You did not quote the module
import line in your reply, did you forget to paste it?

(use-modules (ice-9 match) (srfi srfi-26))

Otherwise it is likely a problem with your guile installation, and I
can’t really help.

> and / is  not a variable , it is simply a separator , the / procedure
> too,and it is not quoted

I do not understand. Do you want to match against the '/ symbol or the
variable/procedure bound to "/"?

If you want to match against something that is bound to "/", then the
cut-equal solution is relevant. If you want to match against the /
symbol, then you can do either one of these:

(use-modules (ice-9 match))
(match (list 1 '/) 
  (`(,c /) 
   c))

or

(use-modules (ice-9 match))
(match (list 1 '/) 
  ((c '/) 
   c))

> in Racket this works:
> 
> (match (list container index1-or-keyword index2-or-keyword)
> 
>   ((list c (== /) (== /)) (displayln "T[/ /]"))

This is not a self-contained example, I don’t know what is index*-or-
keyword. Is it the division function or whatever is bound to / at that
time? The / symbol?

Vivien

Re: comparator in match pattern

[Vivien Kraus]

Le mercredi 28 juin 2023 à 15:51 +0200, Vivien Kraus a écrit :
> So, you want to match against the / symbol, not the value of a
> variable
> named /?

Sorry, I misread. You actually have a variable named /.

So this code is the only relevant one:

(use-modules (ice-9 match) (srfi srfi-26))
(let ((/ 42)) 
  (match (list 1 42) 
((c (? (cut equal? <> /))) 
 c)))

Vivien

Re: comparator in match pattern

[Vivien Kraus]

Le mercredi 28 juin 2023 à 15:38 +0200, Damien Mattei a écrit :
> scheme@(guile-user)> (use-modules (ice-9 match))
> scheme@(guile-user)> (match (list 1 /) ((list c (cut equal? <> /))

So, you want to match against the / symbol, not the value of a variable
named /?

The simplest case would be to use quasiquote/unquote syntax in the
pattern:

(match (list 1 '/) 
  (`(,c /) 
   c))

should give: 1, the value of c

If you don’t understand quasiquote/unquote, you can use the slightly
uglier:

(match (list 1 '/) 
  ((c '/) 
   c))

If / is the name of a variable (why not), you can do:

(use-modules (srfi srfi-26))
(let ((/ 42)) 
  (match (list 1 42) 
((c (? (cut equal? <> /))) 
 c)))

In any case, no need to write "list" in the pattern.

Vivien

Re: comparator in match pattern

[Vivien Kraus]

Hello!

Le mercredi 28 juin 2023 à 10:44 +0200, Damien Mattei a écrit :
> does it exists in Guile something like == in Racket,
> documented here:
> https://docs.racket-lang.org/reference/match.html#%28form._%28%28lib._racket%2Fmatch..rkt%29._~3d~3d%29%29

>From what I understand, (== something) would be translated as (? (cut
equal? <> something)) if you import srfi-26 for cut (or cute, if
something needs to be evaluated once).

Vivien

Re: overload a procedure

[Vivien Kraus]

Hi Damien,

Le dimanche 19 février 2023 à 18:45 +0100, Damien Mattei a écrit :
> ok now i come to the scheme problem implementing the two solutions;
> in
> scheme i can not use types so i use type predicates (number? verctor?
> string? list?)to identify the good function depending of the
> parameters
> types find with the predicates.
> i tried with macro and recursive function with this solution:
> 
> example of use::
> (overload + add-vect-vect vector? vector?)

Did you try GOOPS? It provides that kind of functionality.

(use-modules (oop goops) (srfi srfi-43))
(define-method (+ (a ) (b )) (vector-append a b))
(+ #(1 2 3) #(4 5))

Vivien

Re: relocatable guile on windows

[Vivien Kraus]

Hello,

Le samedi 03 décembre 2022 à 18:48 -0800, Mike Gran a écrit :
> To help deliver a game as a single zip or tar file, a new configure
> option --enable-relative-paths is added.  This installs all of guile
> into the $(prefix)/app directory, and modifies the loading logic to
> search for scheme, compiled scheme, and extension files relative to
> the location of the executable.  The applications and all shared
> object library files are in the root of that directory. 
> $(prefix)/app
> is just a staging directory, and that directory can be renamed and
> relocated.

This is a common problem for all programs, and gnulib has a working
solution for that:
https://www.gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html

Also, this chapter describes a few more things gnulib can do for
windows:
https://www.gnu.org/software/gnulib/manual/html_node/Native-Windows-Support.html

I hope this can help make your work more maintainable.

Best regards,

Vivien

Re: Fibers web server: use multiple server sockets

[Vivien Kraus]

Hello Dale,

There are 2 init systems that matter: shepherd (because it’s guile and
used in guix) and systemd (because nearly everyone uses it).

Le mercredi 02 novembre 2022 à 18:15 +, dsm...@roadrunner.com a
écrit :
> How about not starting the web server until network interfaces are
> fully up?

As far as I understand, there is no such thing with shepherd. As for
systemd, this [1] is an interesting read and it shows that it’s up to
me to write my server such that it can adapt to dynamic configuration
changes.

[1] https://systemd.io/NETWORK_ONLINE/

Vivien

Fibers web server: use multiple server sockets

[Vivien Kraus]

Dear guile fiber users,

Fibers is a library that I would very much like to use. It provides a
nice web server. However, as I recently discovered, in a standard
GNU/Linux server, not all network interfaces and addresses are up when
the server is about to start (especially so with dhcp). I have a nice
solution for that: every now and then, the server calls getaddrinfo. If
a previously bound address does not appear anymore in the return value,
then close the socket it was bound to. If a new address is returned by
the function, create a new socket for it and bind it to the new address
(and listen). This means that if a new address appears for the host
argument, then the server will eventually listen to it without having
to restart anything. If an address is dropped, eventually the server
will stop listening to it.

I would like to have that in the fibers web server. However, I
understand that not everyone would want it, or some would do it
differently (e.g. by using guile-netlink or something else). I think
the web server should make “listen”, “fcntl” (for set-nonblocking!) and
“accept” generic (with parameters, or GOOPS, or…?) so that I could fit
my weird thing within the call to accept.
Ultimately, everything could be expressed in terms of “accept” and have
the default implementation call listen and set-nonblocking! lazily
during the first call to accept. 

What do you think? Should the fibers web server try to do the
getaddrinfo thing by itself or be extensible and let me do it myself?
Are you OK with GOOPS? Do you prefer parameters? Do you have other
options?

Best regards,

Vivien

Re: Does the eval-when example work?

[Vivien Kraus]

Le jeudi 20 octobre 2022 à 10:53 +0200, Maxime Devos a écrit :
>  If so, this is not exactly what I am looking for. I am looking for a
> > way to run the (date) form during the compilation phase, and save
> > the
> > date to the compilation unit so that it does not change. Is this
> > possible?
> 
> I don't know the answer, but for (bit-for-bit) reproducibility,
> please 
> support something like 
> .

I have to confess, I lied to you. I’m not interested in the compilation
date. What I want is to encode the typelib path at compile time, so I
can tell guile-gi where to find the typelibs (including the recursive
pkg-config requirements). Now that I know how to do that, I don’t have
to propagate any inputs, and I don’t have to keep pkg-config around at
run-time (except if the compilation cache gets invalidated, but who
does that).

Does the eval-when example work?

[Vivien Kraus]

Dear guile users,

The manual, section 6.8.8, presents the eval-when form with an example:

(use-modules (srfi srfi-19))
(eval-when (expand load eval)
  (define (date) (date->string (current-date
(define-syntax %date (identifier-syntax (date)))
(define *compilation-date* %date)

I take the liberty to add:

(display *compilation-date*)
(newline)

Now, when I save to test.scm and run guile -s test.scm, it gets
compiled and it displays the current date. However, if I run this
command a second time, the file is not recompiled, but the compilation
date changes. Is it intended?

If so, this is not exactly what I am looking for. I am looking for a
way to run the (date) form during the compilation phase, and save the
date to the compilation unit so that it does not change. Is this
possible?

Best regards,

Vivien

Re: Some help needed to use curl lib to download binary file

[Vivien Kraus]

Hello,

I see in the paste:

> ;; function taken on
> https://gist.github.com/amirouche/138a27bdbef5a672a0135f90ca26ec41
> ;; then adapted to use cookie jar
> (define-public (http-get url cookie-exist)
>   ;; Create a Curl handle
>   (let ((handle (curl-easy-init)))
>     ;; Set the URL from which to get the data
>     (curl-easy-setopt handle 'url url)
>     (if cookie-exist
>     (curl-easy-setopt handle 'cookie "cookie.txt")
>     (curl-easy-setopt handle 'cookiejar "cookie.txt"))
> 
>     ;; Request that the HTTP headers be included in the response
>     (curl-easy-setopt handle 'header #t)
>     ;; Get the result as a Latin-1 string
>     (let* ((response-string (curl-easy-perform handle))
>    ;; Create a string port from the response
>    (response-port (open-input-string response-string))
>    ;; Have the (web response) module to parse the response
>    (response (read-response response-port))
>    (body (utf8->string (read-response-body response
>   (close response-port)
>   ;; Have the (web response) module extract the body from the
>   ;; response
>   (values response body

So here the call expects the response to be UTF-8 text. If it is a
binary file that you are downloading, the function will raise an
exception. Guile has that python3 feeling where you are supposed to
know in advance whether what you are using is text or binary, which is
hurting you here. 

However, you can avoid the problem by either having bytevectors
everywhere, so removing the call to utf8->string and bind the "body"
variable directly to (read-response-body response), or pretend that you
know better than guile and pretend that it is latin-1-encoded, so you
lose no information and guile won’t complain. In that case, load (ice-9
iconv) and replace (utf8->string …) with (bytevector->string … "ISO-
8859-1").

If you go the first route, you get a bytevector back. If you go the
second one, you get a string, but you must remember that it contains
raw bytes and not text (unless the response body was indeed text).

There are some cases when you might want to have such strings-that-
contain-binary-or-text, such as if you want to use the strings API on
them and the bytevector API does not provide what you want, or you want
to interface with NUL-terminated strings. In other cases you might
prefer bytevectors. Anyway, there is no encoding cost to convert
between strings-that-contain-binary-or-toxt and bytevectors, it is as
simple as a copy.

> ;; write content into file
> (call-with-output-file “download.zip” (lambda (current-output-port)
>     (get-file get-file-link)
>     (put-bytevector (current-
> output-port) body)))

call-with-output-file calls its function argument with a port. Plus,
you just ignore the result of get-file, so instead you should do
something with it.

If you chose to have get-file return a bytevector, you can do:

(call-with-output-file "download.zip"
  (lambda (port)
    (put-bytevector port (get-file get-file-link)))
  #:binary #t)

If get-file returns a string, you can do:

(call-with-output-file "download.zip"
  (lambda (port)
    (put-string port (get-file get-file-link)))
  #:encoding "ISO-8859-1")

Best regards,

Vivien

Re: [ANN] nyacc 1.07.0 released

[Vivien Kraus]

Hello,

Thank you for your work on the missing link between C and scheme!

Le lundi 30 mai 2022 à 09:14 -0700, Matt Wette a écrit :
> It provides a decent C parser and a `FFI Helper' tool to help create
> Guile Scheme bindings for C-based libraries.

If it becomes a full C compiler one day, how will you explain the name
to newer generations?

> NYACC is free software; the full source distribution is available
> through
> 
> * the tarball repository:
>  https://download.savannah.gnu.org/releases/nyacc/
> 
> * the git repository:
>  git://git.savannah.nongnu.org/nyacc.git

Could you update it in guix also?

Best regards,

Vivien

Re: Module dependencies

[Vivien Kraus]

Hello Jérémy,

Le samedi 19 mars 2022 à 11:10 +0100, Jérémy Korwin-Zmijowski a écrit :
> I would like to visualize all the modules a given module depend on.

Guix seems to do it in (guix modules), see extract-dependencies, but
I’m not sure it’s very robust.

Re: Exception handling - symbol for encoding exception type?

[Vivien Kraus]

Hello Zelphir,

Le mardi 08 mars 2022 à 17:11 +, Zelphir Kaltstahl a écrit :
> Is the idea, that one should rely merely on the existing
> exception types, which are:
> 
> + assertion-failure
> + non-continuable
> + implementation-restriction
> + lexical
> + syntax
> + undefined-variable
> 
> and that one should not try to create additional types? Or
> is the idea to encode more specifics into the ?
I’m a big fan of the new exceptions, but I had the same question at
first. I tried some code that put everything into the message, I tried
some more code where every possible exception had its type and
contained its parameters, and at the end I settled on this rule of
thumb: if you’re doing something in your code and an exception might be
raised, catch it and raise it again with an additional message
(internationalize it please). If your program needs to perform more
tasks, such as banning the user that raised the exception, create a new
exception type with as few parameters as necessary (most of mine have
none), and raise an occurence of it as well as the internationalized
message. You can use make-exception to create an exception composed of
a new message and an existing exception, and no information will be
lost.

More generally, don’t bother with a new exception type until you need
it to do something useful.

Of course, this is my opinion, others may view the problem differently.

Vivien


signature.asc
Description: This is a digitally signed message part

Re: Newbie thoughts on Guile Hall + Guix

[Vivien Kraus]

Hello, 

Le dimanche 06 février 2022 à 11:35 -0500, Olivier Dion via General
Guile related discussions a écrit :
> As much as I like hall for pure Guile project,
> it's difficult to integrate extension libraries written in C. 

While this is certainly true, I think that nyacc is on the right track
to let us use C libraries without writing a single line of C code.

Vivien

Questions about PEG parsing

[Vivien Kraus via General Guile related discussions]

Dear guile users,

There are two ways to make a parser with guile: the undocumented
LALR(1) parser generator, for which I don’t know how to reuse grammar
elements, and the PEG parser.

The manual shows an example for a PEG parser. According to wikipedia,
which is cited in the manual itself, PEG can have exponential worst-
case complexity. However, I can’t figure out an example that would
produce this behavior. Could you show me one? Does Guile do anything to
help this, like using memoization as in the packrat parser?

Another thing is that the parser does not seem to accept production
rules, and instead returns a compressed tree with some nodes lumped
together or ignored depending on the grammar extension <--, <- or <. It
seems impossible to ignore part of a rule, that’s why the tutorial uses
a dedicated NL token:

passwd <- entry* !.
entry <-- (! NL .)* NL*
NL < '\n'

So, I have to create a new terminal token for each delimiter I want to
match, but discard. Is it not possible to do something like this
instead, to ignore only a part of the rule?

passwd <- entry* !.
entry <-- (! '\n' .)* ( < ('\n'*))

Finally, the result of a match is a compressed tree, where nodes are
rule names and leaves are matched text. This is not very useful, I
would prefer to be able to specify a production rule. It seems that I
can inject a production, for instance to parse a natural number:

(use-modules (ice-9 peg) (ice-9 match))

(define-peg-string-patterns "DIGIT- <- [0-9]")
(define (DIGIT . args)
  (match (apply DIGIT- args)
(#f #f)
((length value)
 `(,length ,(- (char->integer (string-ref value 0))
   (char->integer #\0))

That way, I can reuse the DIGIT function in another parser:

(define-peg-string-patterns "NATURAL- <- DIGIT+")
(define (NATURAL . args)
  (match (apply NATURAL- args)
(#f #f)
((length (digits ...))
 (let produce ((sum 0) (digits digits))
   (match digits
 (() `(,length ,sum))
 ((significant digits ...)
  (produce (+ (* sum 10) significant) digits)))

(peg:tree (match-pattern NATURAL "256"))

Are there downsides? Maybe the production should be pure, if the result
gets memoized?

Best regards,

Vivien

Trying to fix propagated-inputs in Guix for Guile libraries

[Vivien Kraus via General Guile related discussions]

Dear guile users,

I am thinking about how to avoid using propagated inputs with guile
modules. In Guix, we may have different incompatible versions of a
library. It might not be the case right now (are all guile-json
versions really incompatible?), but we may be able to avoid some
trouble in the future if we’re prepared.

For C code, the solution is to make shared objects, and use the rpath
option in each linked object to know where to find its dependencies (
https://en.wikipedia.org/wiki/Rpath).

The fact that this behavior works for C lets me wonder why there’s no
such thing in guile. Is it because, as it is a live environment, users
are supposed to know better what library to use?

In any case, if I wanted to have something like rpath in guile, I would
want to do something like:

(define-module (foo)
  #:use-module ((dependency) #:from "/gnu/store/xxx-dependency-
1.0/share/guile/site/3.0"))

However, the path is only known after the configure step, so it’s not a
good thing to write it down in the source code. So, we would only write
it down in the bytecode, with a new compiler switch.

The next question is, what to do with the source code? Would it be OK
to have a different behavior for uncompiled source? After all, since
it’s not compiled, configure has not run so there is no reason to think
that the library author could find better dependencies than the user.
Or, could we decide not to install source code (.scm) when installing a
library, and only install .go files? Does guile even works if there’s
no corresponding source code for a compiled module?

Vivien

Re: Exception handler installed when handling a continuable exception

[Vivien Kraus via General Guile related discussions]

Hello, I finally figured it out:

Le mercredi 25 août 2021 à 21:08 +0200, Maxime Devos a écrit :
> This also happens without #:continuable?.
> Here's a simpler test case:
> 
> (with-exception-handler
>   (lambda (exn)
> (catch #t
>   (lambda () (error "to be caught"))
>   (lambda e (pk 'caught! e
>   (lambda () (error "oops")))
> ---> In procedure raise-exceptiont: to be caught
> 
> I don't know if this is a bug.
It is not, it was in the documentation the whole time. The effective
handler is the outmost handler, unless #:unwind? is #t. I was tricked
by the obscure scheme jargon, but this works as expected:

(with-exception-handler
  (lambda (exn)
(catch #t
  (lambda () (error "to be caught"))
  (lambda e (pk 'caught! e
  (lambda () (error "oops"))
  #:unwind? #t)

Re: foreign objects and the garbage collector

[Vivien Kraus via General Guile related discussions]

Hello,

Le samedi 04 septembre 2021 à 07:41 -0500, Tim Meehan a écrit :
> I'd rather not compile anything in C, and just use the tools in Guile to
> interact with libgps. Is there a way to get Guile's garbage collector to
> call "gps_close" on the opaque structure returned by "gps_open"?
I think it would be best to do it yourself. Maybe the garbage collector will 
not run immediately (if at all), and if each creation uses "precious" resources 
(such as file descriptors), you might run
into a shortage before the garbage collector is triggered. This is not 
considered by people writing the C API of course, because they assume you would 
close the thing as soon as possible. (Also, if
calling the close function is mandatory, for instance to run code that’s not 
just freeing resources, and the garbage collector does not have a chance to 
run, then it’s another problem. However, I
doubt your library does something like that). 

If you want to avoid the problem, you should explicitely bind and call the 
gps-close function and not rely on the garbage collector to do it for you. You 
can use dynamic-wind to open and close
resources as needed.

That being said, make-pointer (from (system foreign-library)) is probably what 
you are expecting. It should work with gps_close.

Best regards,

Vivien

Pattern matching: what does (= f pat) do?

[Vivien Kraus via General Guile related discussions]

Dear guile users,

The pattern matching manual has a strange description for the (= f pat)
pattern. It reads:

(= field pat)   a ``field'' of an object

However, the next example shows how you can apply a function in field
without having anything to do with a field of an object.

Based on the given example, and some experiments on my part, I think
that the description should be:

(= f pat) applies f, and matches pat in the result

Am I correct?

Vivien

Exception handler installed when handling a continuable exception

[Vivien Kraus via General Guile related discussions]

Dear guile users,

When an exception is raised with #:continuable?, and when the handler
returns a value, then the program continues.

This is why this program prints "hello":

(use-modules (ice-9 exceptions))

(with-exception-handler
(lambda (exn)
  ;; We want to return "hello"
  "hello\n")
  (lambda ()
(format (current-error-port)
(raise-exception (make-exception-with-message "What should I say?")
 #:continuable? #t

Now, in the handler, I may want to handle other kinds of exceptions:

(use-modules (ice-9 exceptions))

(with-exception-handler
(lambda (exn)
  ;; We want to return "hello"
  (false-if-exception
   ;; Shouldn’t this error be ignored?
   (error "messing around"))
  "hello\n")
  (lambda ()
(format (current-error-port)
(raise-exception (make-exception-with-message "What should I say?")
 #:continuable? #t

Is this a bug?

Best regards,

Vivien

Re: Syntax locations are ambiguous: can we track source 'offset' and 'length'?

[Vivien Kraus via General Guile related discussions]

Ludovic Courtès writes:
>> I’m happy to see this pretty-print-with-comments function. I want guile
>> to have a tool that can automatically reformat scheme code, to avoid
>> indentation problems with code reviews and pointless discussions about
>> style. We could even tweak text editors to convert between different
>> styles for viewing the source and for git commits. I’m sure wisp people
>> would like it. I hope to see "guix style" one day :)
>
> It *is* ‘guix style’.  :-)
>
> Currently the command is focusing on one very specific style issue, but
> we could certainly expand it for more general formatting.

I did not notice because it is not in master yet. But that’s good news,
at least for guix now.

Vivien

Re: Syntax locations are ambiguous: can we track source 'offset' and 'length'?

[Vivien Kraus via General Guile related discussions]

Ludovic Courtès writes:
>> I am trying to use the guile reader to read scheme comments, in
>> addition to the syntax elements. I know with syntax-source where a
>> syntax object starts, and I can know where it ends by using a spying
>> soft port and re-reading it. However, the #\return ambiguity makes all
>> my efforts pointless.
>
> As you know, ‘read-syntax’ appeared in 3.0.7, so it’s brand new and we
> could certainly extend (ice-9 read) with more features, including
> reading comments.
I did not know that, to be honest.

> In the meantime, I needed the ability to read comments in Guix,
> including with Guile < 3.0.7, so I hacked up this thing:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/style.scm?h=core-updates=8419221620191d2988c22f6e7811d9ce1e0837bf#n50
>
> It can read and write while preserving comments.
I was tempted not to use the guile reader and go and implement a new
reader like you did, but I was too afraid to miss one important thing in
the syntax.

I’m happy to see this pretty-print-with-comments function. I want guile
to have a tool that can automatically reformat scheme code, to avoid
indentation problems with code reviews and pointless discussions about
style. We could even tweak text editors to convert between different
styles for viewing the source and for git commits. I’m sure wisp people
would like it. I hope to see "guix style" one day :)

Re: Syntax locations are ambiguous: can we track source 'offset' and 'length'?

[Vivien Kraus via General Guile related discussions]

Keith Wright writes:
> Well, I think it is too special interest and
> way too damn big for a general user discussion list.

I am sorry, I made a double mistake by send it here and sending it
inline, because I did not realize that updating gnulib would be so
huge. I suggest that we move to the bug report for further discussions.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49870

Syntax locations are ambiguous: can we track source 'offset' and 'length'?

[Vivien Kraus via General Guile related discussions]

Dear guilers,

I’m playing with syntaxes as first-class objects, and I notice that the
syntax source location is ambiguous:

(syntax-case
(call-with-input-string "(a\r b)" read-syntax) ()
  ((a b)
   (values (syntax-source #'a) (syntax-source #'b

=>

$1 = ((line . 0) (column . 1))
$2 = ((line . 0) (column . 1))

This is obviously because of #\return.

I am trying to use the guile reader to read scheme comments, in
addition to the syntax elements. I know with syntax-source where a
syntax object starts, and I can know where it ends by using a spying
soft port and re-reading it. However, the #\return ambiguity makes all
my efforts pointless.

In (system base lalr), the source location contains a filename, line
and column, but also an offset and length. However, these last 2 get
dropped in source-location->source-properties. I could not find out
whether this is relevant to read-syntax.

So, is there a way to track source offset and length for syntax
objects?

Best regards,

Vivien

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

Hello Aleix !

Le dimanche 01 août 2021 à 23:27 -0700, Aleix Conchillo Flaqué a
écrit :
> Unfortunately guile-json doesn't follow srfi-180 api (it was created
> much sooner), but regarding alists' keys it can support both symbols
> and strings. So you can do (scm->json '((foo . "bar"))) or (scm->json 
> '(("foo" . "bar"))) and both would work the same.

Exactly! The problem is in the other way around, json->scm. By default,
I get stringly-keyed objects, so I add another pass to convert them to
symbolicly-keyed objects.

> By the way, a long time ago I also worked on guile-jwt (
> https://github.com/aconchillo/guile-jwt) which is SUPER basic
> compared to what you've done. I was planning to add JWK support at
> some point. I'm wondering if we could take your code and merge it
> into guile-jwt so other projects can use it. What do you think? Right
> now I don't have much time but if you say it's fine I could work on
> it whenever I'm free.

That would be awesome, but working with C bindings is a pain with
guile. If you inherit all the JWS and JWK code, I still need to keep
them around for things like hashing the URIs for the cache and resource
server and generating random numbers. The clever thing to do would be
to switch to guile-gcrypt first (so that I don’t have any more C) and
then move the code to guile-jwt (we can still change the API if you
prefer another one, I don’t have a 1.0 release yet).

Since that code will most likely be run on web servers, have you
considered releasing it under the AGPL?

Best regards,

Vivien

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

Hello,

Le samedi 31 juillet 2021 à 10:58 +0200, Dr. Arne Babenhauserheide a
écrit :
> Maybe some hacks I needed for my (unfinished) implementation of the
> downloadmesh can be useful to you:

The "missing headers" were missing in Guile, but I added them for my
server (I did it with declare-header!, whereas you used declare-opaque-
header!, but we had the same idea).

The lack of unicode support is more of a concern for me, and something
has to happen on Guile’s side. This is why I submitted a patch.

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

Hello,

Le samedi 31 juillet 2021 à 14:14 +0800, Nala Ginrut a écrit :
> Is it possible to cooperate with a modern web framework? It seems it
> doesn't require JS and browser, so I don't know if http can still
> work as usual.

It is not tied to a particular framework, the specification is based on
HTTP. Guile has by default almost everything we need, 
https://www.gnu.org/software/guile/manual/guile.html#Web

The missing parts are a couple of HTTP headers that are simple to
handle.

However, I’d like to have uri-decode handle unicode characters, because
most URIs nowadays are IRIs and they have unescaped unicode characters.
That’s why I sent this patch:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49085

Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

Hello Guile users,

I’m writing a Solid server in guile:

https://disfluid.planete-kraus.eu/
https://labo.planete-kraus.eu/webid-oidc.git/

The main point of Solid [1] is to separate the web applications from
the data they use in an interoperable way.

It’s in the spirit of Activitypub, but closer to the current
architecture of the web. So, whenever you see "Log in with ", you could easily demand that the application let you log in
with your identity on your Solid pod.

If that takes off, we’ll be able to run any competing web application
with any data storage ("pod"), because the communication is
interoperable and the vocabulary used is public. Which means that we
will be able to easily replace proprietary program with free programs!
The best thing is, we won’t even need to develop for a web browser.
That’s a cool solution to the JavaScript trap.

Now, we need to make sure that there is a freedom-respecting way to
develop applications. This is why I’m writing this project. With a
clear focus on user freedom, we will maximize our chances to avoid the
future JS traps. In this regard, disfluid is not Solid.

[1]: https://solidproject.org/

(web client) with suspendable ports

[Vivien Kraus via General Guile related discussions]

Dear guile users,

(web client) defines a few handy methods to make requests, such as
http-get. I would like to try the suspendable ports interface, so that
while I wait for the server to send the response, I can do something
else.

However, it requires that the socket port is passed the O_NONBLOCK
flag. For HTTP URIs, it is possible since open-socket-for-uri returns a
file port. However, it is not the case for HTTPS URIs.

The guile web client should let me set this flag early (before TLS
negociation) so that I can avoid blocking because of a malicious (or
buggy) server. Ideally, DNS lookup should be non-blocking too.

Or is there a way to do this that I missed?

Best regards,

Vivien

Re: re-writing algorithms in Guile

[Vivien Kraus via General Guile related discussions]

Le mardi 29 juin 2021 à 09:56 +0200, to...@tuxteam.de a écrit :
> On Mon, Jun 28, 2021 at 04:38:50PM -0500, Tim Meehan wrote:
> > Say for instance, I have found an algorithm for scalar function
> > minimization on a website, written in C. It is posted with a
> license for
> > use. If I write something based on this hypothetical code, is it
> then
> > clearly also licensed in the same manner?
> 
> Definitely not: a license is about copyright, and copyright protects
> the
> expression of an idea, not the idea itself (the Lord of the Rings is
> under
> copyright, but if you write a novel involving very old talking trees,
> you
> dont infringe on that).

The idea is the algorithm, but the expression of the idea is the C
program. If you copy the C program, you are indeed bound by the license
of the C program.

> You might want to not use exactly the same variable names, just to
> make sure :)

I would not do that. It will just make the program harder to read.

Re: re-writing algorithms in Guile

[Vivien Kraus via General Guile related discussions]

Hello,

Le mardi 29 juin 2021 à 04:09 +, Nate Rosenbloom a écrit :
> since the algorithm itself
> stays the same.

This reason is not stated in the Stack Exchange post, and I believe
it’s inaccurate (although, I am not a lawyer either). I think the
reason is that you are reading the original implementation to write
your own, so you are some kind of a compiler, or translator (as for
human spoken languages). As such, what you write is mostly the other
person’s work, so you should not claim copyright about it.

However, if you are writing a computer program based on the description
of the algorithm that you would find in a peer-reviewed scientific
paper (that’s what you should be doing, because the paper will prove to
you that the algorithm is correct and efficient at solving the
problem), then it’s a different story, because copying mathematical
expressions is OK (it is proven that it’s the only correct outcome, so
there’s no copyright to claim here).

Re: Python-on-guile

[Vivien Kraus via General Guile related discussions]

Hello,

Le dimanche 25 avril 2021 à 12:54 +0200, Dr. Arne Babenhauserheide a
écrit :
> (next frontier: compete with math that’s implemented via numpy — you
> can find RPython implementations of the basics of numpy in the
> pypy-sources:
> https://foss.heptapod.net/pypy/pypy/-/tree/branch/default/pypy/module/micronumpy
> )

I think it would be wiser to use guile arrays to implement the same
things as numpy.

Are char* and signed char* compatible (SCM_BYTEVECTOR_CONTENTS)?

[Vivien Kraus via General Guile related discussions]

Hello,

I’m trying to use a bytevector from C.

1. According to an example in the manual, SCM_BYTEVECTOR_CONTENTS can
be assigned to a char*.

2. Also from the manual, it is a signed char*.

3. I've found this question online saying they are not compatible (
https://stackoverflow.com/questions/12769500/why-is-char-not-compatible-with-signed-char-or-unsigned-char
).

As I understand it, at least one of the above 3 affirmations is
incorrect. Could someone clarify this to me?

A Web client with cache for guile!

[Vivien Kraus via General Guile related discussions]

Dear guilers,

With the help of promises and futures, I was able to write a small
caching web client for guile.

https://web-client-with-cache.planete-kraus.eu/

This is one step on my journey to write a Solid server for guile. Solid
uses a decentralized authentication protocol (
https://solid.github.io/authentication-panel/solid-oidc/) which needs
servers and identity providers to cache different types of files, such
as openid configurations and the web profile of users and applications.
The authentication protocol can be compared to the HTTP signatures used
by Activitypub servers, except that Solid webid-oidc can work directly
from a web browser.  Solid servers themselves are required to provide
web ETags for all the resources they manage, so a good client cache
should understand Cache-Control headers (often used for offline caching
of openid configurations) as well as the ETags.

Because of the recent announce of the guile potluck on this list,
combined with the recent release of guile-oauth, I thought there could
be some shared interest for this subject.

Best regards,

Vivien