Re: Should we distribute libltdl?

[tomas]

On Wed, Mar 09, 2005 at 04:08:07PM +0100, Marius Vollmer wrote:
> [EMAIL PROTECTED] writes:
> 
> > Can't guile distribute libltdl but only use
> > it iff there's no local version found (or if the user states her
> > intention by configure magic)?
> 
> That is how it works right now.  I am not happy about the fact that
> Guile does this silently and that it is a configure decision that
> persists in the build tree.
> 
> What I would be happy with is to include a copy of libltdl in the
> Guile distribution but to have it completely ignored by configure and
> the Makefiles.  When libltdl is not found in the system, a message
> could be printed that instructs the user to install libltdl, maybe by
> using the included sources.

Makes the most sense to me too. This way a user can decide whether
to let her packaging system deal with it or not.

Installing silently libltdl can be a source of woes (even statically
linking it, since Guile can be linked to other apps which themselves
may use a slightly different version of libltdl: watch Apache and
expat coming in differently via different modules: hours of fun).

Regards -- and thanks for the great work again

-- tomás


pgpKwZ3E8lH1v.pgp
Description: PGP signature
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

sxml simple, sxml->xml and namespaces

[tomas]

Gentle guile folks,

I'm playing around with (sxml simple) and stumbled upon something
I think might be a bug. Consider the following snippet:

  #!/usr/bin/guile -s
  !#
  (use-modules (sxml simple))
  
  ;; An XML with two namespaces (one default)
  (define the-svg "


  ")
  
  ;; Note how SXML handles QNames (just concatenating NS and
  ;; local-name with a colon):
  (define the-sxml
(with-input-from-string the-svg xml->sxml))
  (format #t "~A\n" the-sxml)
  
  ;; If we try to serialize this: kaboom!
  (sxml->xml the-sxml)
  
The parsing into SXML goes well, the (format ...) outputs what
I'd expect. But the (sxml->xml ...) dies with:

  ERROR: In procedure scm-error:
  ERROR: Invalid QName: more than one colon http://www.w3.org/2000/svg:svg

I had a look at sxml simple and think the problem is that the
function check-name (which is the one throwing the error) expects
the name to be a QName (i.e. either a Name or a namespace abbreviation
plus a colon plus a Name).

But SXML tacks the whole namespaces to names (i.e. the whole
"http://www.w3.org/1999/xlink";, for example -- not the "xlink").

When serializing to XML, we should go the way back, finding abbreviations
for the namespaces used, prefixing the names with those abbreviations
and issuing namespace declarations for those abbreviations (those funny
xmlns:foo attributes).

I've tried my hand at a patch which "works for me". Basically, what it
does is to thread an extra parameter "nsmap", representing a mapping
(namespace -> ns-abbreviation) valid at "this" position and below in
the tree. When new, unseen namespaces come up, new abbreviations are
"invented" (ns-abbrev-new), collected and the corresponding declarations
printed. When recursing to sub-elements, the new mappings are added to
the nsmap passed down.

The result after the patch for the above example (a bit embellished)
looks like this:

  http://www.w3.org/2000/svg";>

http://www.w3.org/1999/xlink"; />
  
  
Pretty clumsy, but basically correct.

The attached patch is against "GNU Guile 2.0.5-deb+1-3". The relevant
code hasn't changed up to the current development version.

I'm not very happy with the patch as-is. Among other things,

 - I had a hard time doing what I wanted in a non-clumsy way.
   Especially, ns-abbr is a strange function and not very clear
   because it tries to do several things at once: replace the
   namespace by its abbreviation, signal a new mapping item
   whenever this abbreviation was new. But how to achieve this
   elegantly without doing several look-ups?

 - The namespace declarations are tacked at the end of the attribute
   list. This is plain opportunism: the tag may carry a namespace,
   and each of the attribute names too. Thus, it's very handy to
   collect all the unseen mappings (new-namespaces in element->xml)
   and output them at the end of the attribute list.

   But in XML it is usual to put the namespace declarations before
   the attributes (the "canonical" XML order even prescribes that).

 - The sxml code is pretty careful to not munge around too much
   with strings, but to output things ASAP to the port. I think
   I might be a bit more careful in that department.

 - In other XML libraries the user gets a choice on preferred
   namespace mappings (e.g. I'd like http://www.w3.org/2000/svg
   to be the default namespace -- or http://www.w3.org/1999/xlink
   to be abbreviated as 'xlink'). This could be achieved by
   passing a function as an optional parameter which gets a try
   at a new namespace before ns-abbr-new gets at it.

I'd be happy to prepare a patch against whatever version makes
sense once we get some consensus on how to do it right.

Thanks & regards
-- tomás
--- /usr/share/guile/2.0/sxml/simple.scm	2012-03-18 20:16:21.0 +0100
+++ /home/tomas/lib/guile/sxml/simple.scm	2015-04-08 22:29:30.049277842 +0200
@@ -37,29 +37,38 @@
 argument, @var{port}, which defaults to the current input port."
   (ssax:xml->sxml port '()))
 
-(define check-name
-  (let ((*good-cache* (make-hash-table)))
-(lambda (name)
-  (if (not (hashq-ref *good-cache* name))
-  (let* ((str (symbol->string name))
- (i (string-index str #\:))
- (head (or (and i (substring str 0 i)) str))
- (tail (and i (substring str (1+ i)
-(and i (string-index (substring str (1+ i)) #\:)
- (error "Invalid QName: more than one colon" name))
-(for-each
- (lambda (s)
-   (and s
-(or (char-alphabetic? (string-ref s 0))
-(eq? (string-ref s 0) #\_)
-(error "Invalid name starting character" s name))
-(string-for-each
-

Re: Guile Assembler

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jun 23, 2015 at 02:28:41PM +0800, Nala Ginrut wrote:
> hi Panicz!
> 
> On Mon, 2015-06-22 at 22:49 +0200, Panicz Maciej Godek wrote:
> > My repo is available here:
> > 
> > https://bitbucket.org/panicz/envy/src
> 
> Thanks for the hint!
> There's tiny problem IMO, (define ((number/base base) (l ...)) is not
> supported in Guile, but I do see something similar in Racket, say:
> ==code==
> (define ((number/base base) l) l)
> ===end==

What does number/base do? Does it change the read syntax of numbers?

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWJIxMACgkQBcgs9XrR2kbEGwCggNu2MaiEGUVBEnE9Mc/AHE8p
ztgAn0IAZXfu9S+DvnKpkFrPeCwoHCpv
=K4F9
-END PGP SIGNATURE-

Re: Guile Assembler

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jun 23, 2015 at 05:19:56PM +0800, Nala Ginrut wrote:
> On Tue, 2015-06-23 at 11:12 +0200, to...@tuxteam.de wrote:
> > What does number/base do? Does it change the read syntax of numbers?
> > 
> 
> I think it defines a function (number/base base) first, then use it as
> argument of the outer function...
> 
> http://docs.racket-lang.org/reference/define.html

Hm. Where's the difference to Guile's define? And why do you have double
parentheses in your example?

Still a bit lost.

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWJJnMACgkQBcgs9XrR2kZd6wCeP0SNvz+/6KxiizHrPn/kMR37
QqIAniGp6tORga2nPZ+qcFiyBF4UiBMf
=P5LB
-END PGP SIGNATURE-

Re: Guile Assembler

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jun 23, 2015 at 05:30:42PM +0800, Nala Ginrut wrote:
> On Tue, 2015-06-23 at 11:27 +0200, to...@tuxteam.de wrote:
> > Hm. Where's the difference to Guile's define? And why do you have double
> > parentheses in your example?
> > 
> > Still a bit lost.
> 
> hmm...do you read the pasted code in the repo? ;-)

Not yet, I must admit. But nevermind, got it. It looks like a definition
for a parametric func or for a half-curried func, depending on how you
squint at it ;-)

That explains the second set of parens.

thanks, regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWJKrYACgkQBcgs9XrR2kYA2ACcDO9pimsVDHUrWmb9gP5vsTAk
tlMAnAmBAyJmLoTRiP1NPuqjAfoSWIQF
=a+Ly
-END PGP SIGNATURE-

Re: Guile Assembler

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jun 23, 2015 at 11:33:06PM +0200, Panicz Maciej Godek wrote:
> >
> > > > Hm. Where's the difference to Guile's define? And why do you have
> > > > double parentheses in your example?

[...]

> Hi,
> sorry to answer that late, but I erroneously sent the previous answer only
> to Nala.

Thanks
 
[...]

> The modification of "define" originates, I believe, from the book
> "Structure and Interpretation of Classical Mechanics" by Gerald Sussman and
> Jack Wisdom [1] [...]

Thanks for the nice explanation. As stated upstream, once Nala hit me over
the head, I saw the light :-)

> curried-definitions) module [2]. The idea is that
> 
> (define ((f x) y)
>   (list x y))
> 
> is equivalent to

I agree that it is a nice extrapolation from (define foo ...) to
(define (foo x) ...).

[...]

> In addition, the module allows me to use the "let" and "let*" forms with
> multiple values:
> 
> (let ((a (b c) (values 1 '(2 3
>   (+ a b c))

Any chance to see that in Guile?

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWKa4wACgkQBcgs9XrR2kaneACeLoC3A0wv+gxEWgzxcVIrTd4C
K4EAn2RalYt5OYidPB6fI/rylblMEVUg
=+mEy
-END PGP SIGNATURE-

Re: New logo and website design proposal

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Oct 12, 2015 at 03:26:21PM +0200, Ludovic Courtès wrote:
> Aleix Conchillo Flaqué  skribis:
> 
> > I have a suggestion: would it be possible to show only one code sample in
> > the Code examples section? [...]

> I agree that it would be nice, if possible.
> 
> OTOH the current web site has the advantage of being JavaScript-free.

FWIW I do appreciate this trait highly.

thanks
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlYbsGEACgkQBcgs9XrR2kaYggCcClsJOdetNmtdZOzuuZ/a33p8
qLcAnidPbN+xlHDosW6Hk3LsJoVd98O9
=06cp
-END PGP SIGNATURE-

Re: New logo and website design proposal

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Oct 12, 2015 at 01:15:59PM -0500, Luis Felipe López Acevedo wrote:

[...]

> I'm fine with Aleix suggestion. And it can be done so that the
> examples are shown in a descent way without the effects for people
> who don't use JavaScript.

Wohoo!

Luis Felipe, you are my hero :-)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlYcAw8ACgkQBcgs9XrR2kZ6jACfYd/9K+4h+fZM7sXFwlFt60qG
9pkAn3/VhXxHvxXBjUYatpMsk0U5KimR
=9YSf
-END PGP SIGNATURE-

Re: Reading data from a file descriptor

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote:
> Jan Synáček  writes:
> 
> > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann 
> > wrote:
> >
> > Also note that if there's no requirement to actually implement
> > this in
> > C, there's `fdes->inport' and `fdes->outport' on the Scheme level,
> > so
> > something like the following would be analogous to the C example
> > code
> > posted:
> > 
> > (import (ice-9 binary-ports))
> > 
> > (define (process-fd fd)
> > (let ((port (fdes->inport fd)))
> > (display "read: ")
> > (display (get-bytevector-n port 100))
> > (display "\n")))
> > 
> > (process-fd (acquire-valid-fd))
> > 
> >
> > This is something very similar that I ended up with. Just instead of
> > get-byte-vector, I used read-string!/partial.
> 
> I would advise against using 'read-string!/partial' or any of the
> procedures in (ice-9 rw).  This is a vestigial module from Guile 1.8
> when strings were arrays of bytes, which they no longer are.  We should
> probably mark them as deprecated.
> 
> For one thing, when we switch to using UTF-8 as the internal string
> encoding, it will not be possible to keep 'read-string!/partial'
> efficient.  It will necessarily have to do an encoding conversion.
> 
> In Guile 2+, I would advise using byte vectors when working with binary
> data.  Portions of these can be converted to strings with a given
> encoding if desired.  I might be able to give better advice if I knew
> more about what you are doing here.

Mark,

what Jan is after (and what I'd like to have too) is something
akin to Unix read(2) with O_NONBLOCK: provide a buffer, request
(up to) N bytes from the file (descriptor) and get an answer
(with possibly less bytes).

I tried that a while ago and was surprised that I had to resort
to (character) strings, with all the downsides you mention. Something
like that for byte vectors would be awesome. Either it exists (and
neither Jan nor me have succeeded in finding it) or it doesn't.

I'll go have a look later to see whether my recollection is accurate.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZJ0/kACgkQBcgs9XrR2kb93QCdF1K/IT/Ma+CkOFAqQgul9px/
tDMAnRoki8ODfD3tqwZSyL1GArAfDnpn
=AuBJ
-END PGP SIGNATURE-

Re: Reading data from a file descriptor

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Nov 16, 2015 at 11:54:33AM +0100, Amirouche Boubekki wrote:
> On 2015-11-13 21:41, Jan Synáček wrote:

[...]

> >I have an open fd to a unix socket and I want to read data from it. I
> >know that the data is going to be only strings, but I don't know the
> >length in advance.
> 
> Do you know a delimiter? maybe it's the null char?
> 
> TCP is stream oriented, it's not structured at this layer into messages
> or segments. You need some knowledge about the byte stream to be able to
> split it into different meaningful piece for the upper layer.

I think I "got" Jan's request, because I've been in a similar
situation before: delimiter is not (yet) part of it. What he's
looking for is an interface à la read(2), meaning "gimme as much
as there is in the queue, up to N bytes, and tell me how much
you gave me". Of course, putting stuff in a byte vector would
be preferable; the only functions I've seen[1] which "do" that
interface are read-string!/partial and write-string/partial
operate on strings, not byte arrays, alas.

> In Python the socket.recv method returns bytestring but still you
> have to parse
> to bytestring to make sure the delimiter is not in the middle of the
> string. What
> I mean is that in theory you might socket.recv the end of an
> application level message
> and the beginning of another using the same call.

Not (yet) about delimiters.

> Otherwise said, the only thing that could make sens for a (recv)
> procedure is
> to return the full content of the inbound network buffer for the
> given socket
> as a bytevector but it will still require work to to make things work...

Exactly, see above. A delimiter, or just feed the thing to an
incremental scanner/parser (e.g. a finite state machine, which
can get its input spoonwise).

> Have a look at the implementation. IMO the solution is to build a
> loop with
> (read-char) [1] looking for the *end char* to stop the loop.

If your application is set up to accept partial buffers of arbitraty
length, it seems a bit wasteful to have a buffered read (which is
definitely beneath `read-char') going through a character-wise
read into a new buffered read...

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZK+Q8ACgkQBcgs9XrR2kaV6QCdFkPPiAZqhyC4knvJroGyq2+m
I0QAnicg8Cz5VL2I9VfWm7GcMLNhvNsM
=dk4d
-END PGP SIGNATURE-

Re: Reading data from a file descriptor

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 01:55:17PM +, Chris Vine wrote:
> On Tue, 17 Nov 2015 13:52:21 +0100
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On Tue, Nov 17, 2015 at 12:59:56PM +, Chris Vine wrote:
> > > On Tue, 17 Nov 2015 10:53:19 +0100  
> > 
> > [...]
> > 
> > > guile's R6RS implementation has get-bytevector-some, which will do
> > > that for you, with unix-read-like behaviour.  
> > 
> > Thank you a thousand. You made me happy :-)
> 
> I suppose it is worth adding that it might not be optimally efficient
> for all uses, as there is no get-bytevector-some! procedure which
> modifies an existing bytevector and takes a maximum length value.  I
> guess it is a matter of 'suck it and see', efficiency-wise.
> 
> If you are sending/receiving binary packets, it might be better to make
> them of fixed size and use get-bytevector-n!.  (Unfortunately,
> get-bytevector-n! does block until n is fulfilled according to R6RS:
> "The get-bytevector-n! procedure reads from binary-input-port, blocking
> as necessary, until count bytes are available from binary-input-port or
> until an end of file is reached".)

:-(

As I noted before, it's a while since I attempted that. I was looking
for an equivalent of read(2) and write(2): simple, efficient, easy to
understand semantics (if you discount the EOF problem for now).

Perhaps the limitations you mention above steered me towards
read-string!/partial and friends, then.

Thanks & regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZLLJcACgkQBcgs9XrR2kbS9gCeNM696u8KT9Fzq0fSifH8YKa3
VjEAn0KKx5Im4UNxUumiy0RroiKT3iDU
=nAXY
-END PGP SIGNATURE-

Re: Reading data from a file descriptor

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Nov 23, 2015 at 10:07:11PM +0100, Andreas Rottmann wrote:
>  writes:

[...]

> > what Jan is after (and what I'd like to have too) is something
> > akin to Unix read(2) with O_NONBLOCK: [...]

> The procedure with the closest semantics is R6RS
> `get-bytevector-some`. While the R6RS says it will block if no data is
> available, a quick look at Guile source code seems to indicate that it
> probably works with non-blocking I/O -- I'd say it should return EOF if
> called on a non-readable, non-blocking port, and otherwise not block,
> and return the data available. This is all just from a quick
> inspection, without running any actual code.

Thanks a bunch for looking into it. I'll give it a try and report back.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZUgjsACgkQBcgs9XrR2kbScACdH6hoWVVX6m6oCk1O3Fq+S1Pn
EI4AnRvOO3QSBMq/GmU8Mzctm4VliTMe
=Nyl4
-END PGP SIGNATURE-

Re: [PATCH] gnu: Add erlang.

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> > On Mon 04 Jan 2016 06:20, Steve Sprang  writes:
> > 
> > > From http://www.erlang.org/download/otp_src_18.2.1.tar.gz...
> > > ERROR: Bad qstring header component: kMSMAn68110840
[...]

[Andy Wingo]
> > The Etag value is invalid:
> > 
> >   https://tools.ietf.org/html/rfc7232#section-2.3
> > 
> > We could relax Guile's etag parser to assume that an etag not starting
> > with either W/ or " is a strong etag without quotes.  To do that you
> > would patch guile's http.scm to say:

On Mon, Jan 04, 2016 at 08:13:25PM +0800, Nala Ginrut wrote:
> Someone had reported the similar problem to Artanis:
> https://github.com/NalaGinrut/artanis/issues/44
> 
> It's because some client (firefox, in this case) emits wrong header [...]

Thirded. It doesn't make sense to be too strict on the InterWebs.

And we can invoke Postel's Law [1] on that, RFCs and all :-)

[1] 

thanks
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlaKX3sACgkQBcgs9XrR2kbMPACffyBhOkhaR2sKnn1/LzhyjPzp
sDEAnRCyJMUUXDULBQ8Yv1mpYrUNDVB1
=zjKF
-END PGP SIGNATURE-

Re: anyone define port types?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 28, 2016 at 09:04:42PM +0200, Andy Wingo wrote:
> Hi!
> 
> I am working on improving our port implementation to take advantage of
> the opportunity to break ABI in 2.2.  I am wondering how much I can
> break C API as well -- there are some changes that would allow better
> user-space threading
> (e.g. http://thread.gmane.org/gmane.lisp.guile.devel/14158/focus=15463
> or Chris Webber's 8sync).

Yes, please!

uh -- I mean... even if I had anything broken by that change I'd be
very excited. Like it.

thanks
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlb6NZ0ACgkQBcgs9XrR2kZtzgCdFH4J5PD840WqWNSFNEI4wV/9
/cgAn2Twn7dhpXIX96+oydu6KLkjHlLF
=8Ijx
-END PGP SIGNATURE-

Re: Reading data from a file descriptor

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 20, 2016 at 12:40:53PM +0200, Andy Wingo wrote:
> On Tue 17 Nov 2015 14:55, Chris Vine  writes:
> 
> > On Tue, 17 Nov 2015 13:52:21 +0100
> >> On Tue, Nov 17, 2015 at 12:59:56PM +, Chris Vine wrote:

[...]

> >> > guile's R6RS implementation has get-bytevector-some, which will do
> >> > that for you, with unix-read-like behaviour.  

[...]

> > I suppose it is worth adding that it might not be optimally efficient
> > for all uses, as there is no get-bytevector-some! procedure which
> > modifies an existing bytevector and takes a maximum length value.  I
> > guess it is a matter of 'suck it and see', efficiency-wise.
> 
> I would be happy to support such an interface though.  I guess it would
> take a keyword or optional argument indicating a minimum number of bytes
> to fill, and if that number is 0 it would never block; sound about
> right?

Assuming I understood everything involved -- yes, it sounds spot-on.

Thanks
- - t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldnzF4ACgkQBcgs9XrR2kbbkQCeJtkFrSRYBz9UTX9+pO1v7E3r
hKYAn03UD5dhTe9hPpYusaBqTYOu2MbW
=WJhe
-END PGP SIGNATURE-

Re: sxml simple, sxml->xml and namespaces

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 20, 2016 at 10:56:26AM +0200, Andy Wingo wrote:
> Greetings gentle Guiler,
> 
> Apologies for the long delay here.

No worries. Thanks for looking into it.

I'm myself deeply embroiled in things (not Guile, alas!) so my
response times might be... less than ideal too. And I appreciate
your spare cycles being spent in parts of Guile which are far
beyond my grasp ;-)

>  I'm with you regarding namespaces
> and sxml->xml.  In the past I made sure to always get the namespaces
> attached to the root element via the @ xmlns attributes, and then have
> namespaced uses just be local names, not qnames, and that way sxml->xml
> works fine.  But, perhaps that doesn't cover all cases in a nice way.
> Do you still have thoughts on this patch?  Is the right thing for you?
> In any case we need better documentation in the manual about how to deal
> with namespaces and SXML, in practice, with examples.

The patch is less than elegant. I'll have a look at the patch Ricardo
proposes, which I think is much more Scheme-y and will try to respond
whithin this week.

Thanks®ards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldn0QAACgkQBcgs9XrR2kZ6ewCbBi+Sn5k13Er0+AUS43zI+svS
N10An26EKgwmj4fmtUrGH74nqDZSDjHS
=sjpn
-END PGP SIGNATURE-

Re: sxml simple, sxml->xml and namespaces

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 20, 2016 at 12:52:47PM +0200, Ricardo Wurmus wrote:

[...]

> Here is another proposal, mirroring what is done in “xml->sxml”:
> 

Hey, thanks, Ricardo!

Let me have a look at your patch and see whether I can wrap my head
around it :-)

I'll have some feedback this week, promised.

Thanks a lot
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldn0WYACgkQBcgs9XrR2kb2hACfX0seqPBw9iKBi5XlW/2aV32p
ugoAnjiPPAq2M+uObdzsl0eIIwlMGVQJ
=qQKG
-END PGP SIGNATURE-

Re: Web site now uses Haunt

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Nov 10, 2016 at 06:12:22PM +0100, Ludovic Courtès wrote:

[...]

> So now the news page is more pleasant to the eye:
> 
>   https://www.gnu.org/software/guile/news/

Nice! Like it.

thanks
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlglgosACgkQBcgs9XrR2kakPACfchu1JNohStGjDa6za3p3iryG
pRgAn30b0Cmm3WER9JvKkHfL3ff4O9Sl
=qioL
-END PGP SIGNATURE-

Re: srfi-1 take and drop seriously broken

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> Jan Synáček writes:
> 
> > scheme@(guile-user)> ,use (srfi srfi-1)
> > scheme@(guile-user)> (take (list 1 2 3) 4)
> > ERROR: In procedure list-head:
> > ERROR: In procedure list-head: Wrong type argument in position 1
> > (expecting pair): ()
> 
> That's expected.
> 
> > scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> > ERROR: In procedure list-tail:
> > ERROR: In procedure list-tail: Wrong type argument in position 1
> > (expecting pair): ()
> 
> That too.
> 
> > Please, tell me that this is just a mistake...
> 
> It's just a mistake!
> 
> > This can't be true. I still can't believe it. This is from
> > 2.0.11. Please, tell me that the implementation is fixed in 2.2.
> 
> You'd have to give me more clues about what it is that puzzles you
> and why.
> 
> > Yours truly puzzled,
> 
> Do you possibbly mean something like
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> (use-modules (srfi srfi-1))
> scheme@(guile-user)> (take '(list 1 2 3) 4)
> $1 = (list 1 2 3)
> scheme@(guile-user)> (drop '(list 1 2 3) 4)
> $2 = ()
> --8<---cut here---end--->8---

Hm. Jan's example should work, nevertheless. And it does work for me:

  tomas@rasputin:~$ guile
  GNU Guile 2.0.11.133-d680
  Copyright (C) 1995-2014 Free Software Foundation, Inc.
  
  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.
  
  Enter `,help' for help.
  scheme@(guile-user)> (use-modules (srfi srfi-1))
  scheme@(guile-user)> (take (list 1 2 3 4) 4)
  $1 = (1 2 3 4)
  
Hmmm.

(note my Guile version, which is a tad beyond "plain" 2.0.11;
but FWIW it works for me in Guile 1.8 too)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgwyYsACgkQBcgs9XrR2kZKGwCfdjI4+zOQFWgaM+WMZb95v22x
gi8An10EyxTJ+NAgO/FWqwjcQ3CiuMWC
=EXVs
-END PGP SIGNATURE-

Re: srfi-1 take and drop seriously broken

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Nov 20, 2016 at 05:32:25AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Nov 2016 22:52:12 +0100
> > From: 
> > 
> > On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> > > Jan Synáček writes:
> > > 
> > > > scheme@(guile-user)> ,use (srfi srfi-1)
> > > > scheme@(guile-user)> (take (list 1 2 3) 4)

[...]

> >   scheme@(guile-user)> (take (list 1 2 3 4) 4)
> >   $1 = (1 2 3 4)
> 
> Your example has 4 members in the list, while the original one had
> only 3.

Ahem. Juxtaposing, and now that you say it :-)

To be honest, the first example was Jan's, the second mine. In between
there must have been some funky spell checker in my wetware (if you're
taking four there's got to be at least four, right?).

Thanks for pointing that out
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgxeJEACgkQBcgs9XrR2kbcWgCfWMSWwVkOCoscrSpwirlDZ0gz
MEAAn2QG43XO8UE0HtN1S574jY5J0FaF
=6wCA
-END PGP SIGNATURE-

Re: Slow compilation of guile-2.1.x

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Nov 25, 2016 at 08:31:23AM +0100, Jan Synáček wrote:
> Hello,
> 
> while building guile-2.1.4 for Fedora, I noticed that the compilation
> got *really* slow. I didn't measure it precisely, but as can be seen
> from [1] (about 20 minutes) and [2] (about 100 minutes with make check
> disabled), the time difference between the builds is roughly 80
> minutes... Release notes mention that the VM has been rewritten and
> the source is now compiled into ELF, but is it supposed to be this
> slow?

Are you building from scratch? Because then yes, 2.1.x is expected
to bootstrap slowly [1]. The solution offered ATM is delivering a
half-bootstrapped system [2].

TL;DR the compiler has become much smarter, but also tougher to
build (but read the refs anyway: they're a worthy read).

regards

[1] 
https://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
[2] https://wingolog.org/archives/2016/02/04/guile-compiler-tasks

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlg3+BQACgkQBcgs9XrR2kb1rgCdEfvVwjdh1Ap/DnWzLoNUc/9q
w2cAnjGohbe3VzBN3gdjzzJpy2uekkqH
=ET1E
-END PGP SIGNATURE-

Re: Slow compilation of guile-2.1.x

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Nov 28, 2016 at 09:47:08AM +0100, Jan Synáček wrote:
> On Fri, Nov 25, 2016 at 9:36 AM,   wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Fri, Nov 25, 2016 at 08:31:23AM +0100, Jan Synáček wrote:
> >> Hello,

[...]

> > Are you building from scratch? Because then yes, 2.1.x is expected
> > to bootstrap slowly [1]. The solution offered ATM is delivering a
> > half-bootstrapped system [2].
> 
> Yes, but even a small (about 3 modules and a few 100s LoC) project of
> mine compiles about 3 times slower.

You mean not bootstrapping the system but using a fully bootstrapped
Guile to compile *your* stuff? Hmmm.

> > TL;DR the compiler has become much smarter, but also tougher to
> > build (but read the refs anyway: they're a worthy read).
> >
> > regards
> >
> > [1] 
> > https://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
> > [2] https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
> 
> Thank you, I wasn't aware of these. Good to know that it's not a bug.

I'm far from being in the position to decide whether there's a bug, alas.
Perhaps more knowledgeable folks could chime in: Is a factor of 3 when
compiling to be expected?

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlg7+hwACgkQBcgs9XrR2kYM3ACfZpBENm0jEorf5T45Qz5nxDIy
GIAAn0HjqJd+OMX8eQQt1WLCor7S0ewp
=DGQp
-END PGP SIGNATURE-

Re: GNU Guile 2.1.5 released (beta)

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Dec 11, 2016 at 05:25:19PM -0800, Matt Wette wrote:

[...]

> Sorry to keep posting on this.  I will stop soon.

[this from the peanut gallery: feel free to ignore]

Please don't! Even if I don't own a Mac, and even if I'll try to avoid
that in the future if I can: I do follow your postings with great
interest. Valuable lessons in portability. So thanks for them :-)

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlhOhqIACgkQBcgs9XrR2kYktACfdqa2Y2+oLsdhRP2zoXMhW31z
mzIAn15XEhJ/r3cBO2bo8KPKXh8XwVKR
=0PTT
-END PGP SIGNATURE-

Re: Stuff I noticed compiling 2.0.13

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jan 06, 2017 at 08:14:11AM +0100, Michael Vehrs wrote:
> Dear developers,
> 
> on Debian 8.6 (jessie), configure failed to find the right
> libreadline, or failed to determine its version. Despite having
> libreadline 6.0 installed, configure complained about needing at
> least version 2.1. I then built and installed libreadline 7.0, and
> used --with-readline-prefix, but the warning persisted. However, it
> seems to have compiled with readline support, since at least basic
> readline features are working.

I'm perhaps making a fool of myself by asking the obvious, but...
you had libreadline-dev installed, had you?

(Apologies in advance, but lacking context I thought better ask
than not).

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlhvVIYACgkQBcgs9XrR2ka9fgCeKvUgn8RXvkENvNsGyXbeLSLG
nSIAnjeqczuq/3Af4GGNxWaF+uQt7whX
=c3fn
-END PGP SIGNATURE-

Re: RFC: (ice-9 sandbox)

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Apr 14, 2017 at 12:52:19PM +0200, Andy Wingo wrote:

[...]

> Concretely for this use case, assuming that we can solve the immutable
> literal problem, I propose to remove sigils entirely.  Thoughts welcome
> here.

There's still the "cultural value" of such sigils, which eases the
communication between humans. That'll depend on what other Schemes
do, and how current pedagogical literature is set up. Readability
and all that. Cultures are bound to change, though.

Of course, really marking things as immutable (the "technical" bit)
is still very cool.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljwvcUACgkQBcgs9XrR2kYZTACcDPuqBDCiuPT9Etz3YS1m6Mta
TT4AniJs2TRtp899aiuleeV1FqYo1be7
=nA1X
-END PGP SIGNATURE-

Re: [PATCH] On Hurd, don't use not implemented madvise()

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 01, 2017 at 07:29:03PM -0400, Mark H Weaver wrote:
> Manolis Ragkousis  writes:

[...]

> > Also from my understanding not using madvise() ends up in slower
> > performance but it doesn't create problems to the program, right?
> 
> Some programs for Guile 2.2 may take advantage of the dynamically
> expandable stacks, because it allows programs to written in a more
> natural way.  Such programs may in some cases temporarily allocate a lot
> of stack space.  If this memory can never be reclaimed on Hurd, that may
> cause problems for some programs.

This would at least suggest having a way to query whether madvise is
available, through some introspection (giving the program a chance
to adapt its behavior)?

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkxJFYACgkQBcgs9XrR2kbyNgCeJPtTvHeBJhIgiDHcIfip7aWt
e9kAn3fMsRpzS99+e0szQ7cuGo+X8Q/K
=9/ui
-END PGP SIGNATURE-

Re: [PATCH] On Hurd, don't use not implemented madvise()

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jun 02, 2017 at 10:00:18PM -0400, Mark H Weaver wrote:
>  writes:

[...]

> > This would at least suggest having a way to query whether madvise is
> > available, through some introspection (giving the program a chance
> > to adapt its behavior)?
> 
> First of all, you should read this for background:
> 
>   https://wingolog.org/archives/2014/03/17/stack-overflow

Done.

> If you've done that, then you should understand that this new feature in
> guile-2.2 fundamentally changes the way we can express loops in Scheme
> that build recursive data structures where scalability is important.

[...]

Yes, I got that: in a nutshell, getting the stack auto-extended instead
of being blown out of existence by a segfault or similar.

> Consider how frequently patterns like this occur.  Do you really want to
> duplicate every piece of code with a loop of this form?  It would be
> better to just give up on this new feature entirely.
> 
> Anyway, even if you did duplicate your code, that would not solve the
> problem, because many procedures in Guile itself are now written in the
> nicer way to take advantage of this.  One such example is 'map'.

You are right, duplicating every piece of code doesn't seem to be
a Good Thing.

I rather proposed the introspection for those who want to come up
with whatever other ideas: it might be they'll want to warn the user
right off at the beginning ("uh, oh: no madvise: expect a rough ride",
so they can then segfault without guilt :)

> I'm quite fond of the Hurd design, and I hope it continues to grow, but
> it's unrealistic to expect developers to write loops like this in a
> fundamentally less clear way to cater to an experimental OS that has so
> few users.
> 
> Does that make sense?

It does. As I said, I just proposed that, if Guile decides to use
madvise() dynamically (by "bypassing" ENOSYS -- that's IMO a good idea
anyway), it should give the user a possibility to check for that very
fact ("do we, actually, have an madvise()?"). WDYT?

Cheers
- -- tomás

> 
>Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkyWhwACgkQBcgs9XrR2kYkSACdE8BsW58sCblJWhv0PSQV7+wO
9vYAnjezj0Fr9jg0I7SJDsJBG2pQhLhK
=wSGI
-END PGP SIGNATURE-

Re: Rename GNU fdisk to GUILE diskutils

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 12, 2017 at 10:01:41PM -0200, David Pirotte wrote:
> Hi Christian,
> 
> > >> IMHO the programming language/compiler a utility is written with is an 
> > >> implementation detail that should not manifest itself in the utility's 
> > >> name.  In this case, I think "GNU Distutils" would be better.  
> 
> > >   "GNU Diskutils"
> 
> > > 1+
> > > David  
> 
> > I'm sorry but I do not agree. Guile is not an implementation detail in
> > this case. It means that the package is based on Guile. It's like xterm
> > (a terminal for x window), gnome-terminal (a terminal based on the GNOME
> > framework) and so on.
> 
> It is, by definition, an implementation detail [...]

I strongly agree. You don't call "ls" "C ls", or  "nroff" "Shell nroff",
or "automake" "Perl automake". This somewhat conveys that "if you aren't
a Pythonista (or whatever), this program is not for you".

But hey, I'm not the author :-)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlow5i0ACgkQBcgs9XrR2kYXRQCfej4VuR39ncCZeIQf+m3DbTIV
TvUAn3XttenUAYv9TR3Hi5DqpQaiw702
=YeCC
-END PGP SIGNATURE-

Re: Simple picture language

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 26, 2018 at 11:51:23PM +0200, Ricardo Wurmus wrote:
> Hi Guilers,
> 
> I wrote a simple SVG-based picture language.  To try it:

[...]

> What do you think?

Thanks for that!

This prompted me to get my Geiser setup in working order and
I must say, it was totally worth it. Thank you for my best Easter
egg ever :-)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrBSUMACgkQBcgs9XrR2kYxTgCbBcsiu1E+mYPvlbhvo6T8pu9C
DgwAn1EuK3qYmP95YrjvjpezxWrI3mSz
=pVkK
-END PGP SIGNATURE-

Re: A problem with licenses

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, May 30, 2018 at 01:36:43PM +0300, Tommi Höynälänmaa wrote:
> 
> I have published some guile-based software under GNU GPL and LGPL.
> However, when I open the Debian packages with Ubuntu Software
> Installation (18.04) the application claims that the software is
> proprietary. How can I fix this?

I think the relevant doc is here:

  https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#copyright

> The relevant packages are:
> 
>   http://www.iki.fi/tohoyn/theme-d/theme-d_1.1.0_amd64.deb
> http://www.iki.fi/tohoyn/theme-d/th-scheme-utilities_1.4.1_all.deb
>   http://www.iki.fi/tohoyn/theme-d/libthemedsupport_1.1_amd64.deb

I'll try to have a look into your packages later (ATM drowning in
stuff), perhaps I can spot something.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsOgAMACgkQBcgs9XrR2kZH/ACfSemA0xVTEpyQvp3hJiUnUYay
i7oAn2kOVKlujffGbUE5POqGmZVHPPC7
=6yyw
-END PGP SIGNATURE-

Re: A problem with licenses

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, May 30, 2018 at 01:36:43PM +0300, Tommi Höynälänmaa wrote:
> 
> I have published some guile-based software under GNU GPL and LGPL.
> However, when I open the Debian packages with Ubuntu Software
> Installation (18.04) the application claims that the software is
> proprietary. How can I fix this?
> 
> The relevant packages are:
> 
>   http://www.iki.fi/tohoyn/theme-d/theme-d_1.1.0_amd64.deb
> http://www.iki.fi/tohoyn/theme-d/th-scheme-utilities_1.4.1_all.deb
>   http://www.iki.fi/tohoyn/theme-d/libthemedsupport_1.1_amd64.deb

OK, I had a look into the packages. I see you have a copyright
under usr/share/doc//copyright (possibly coming from
debian/copyright in your source package, but I can't see that).

Perhaps the Ubuntu installer can see better if you follow the
standard syntax outlined in

  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Basically, in its minimal form, something like

  Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

  Files: *
  Copyright: 2000-2018 Eva Lu Ator
  License: GPL-3+

But I'm still guessing.

HTH
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsTBx4ACgkQBcgs9XrR2kZgFgCfXeQyTkrADkdusvZNPuGBbKe9
VZsAmweowUtrvEraRd04QKtmnV6mEFpn
=o05K
-END PGP SIGNATURE-

Re: multi-lingual guile: language strictness

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jul 13, 2018 at 07:53:51PM -0700, Matt Wette wrote:
> Hi All,
> 
> I posed a question on #guile IRC last weekend asking for use cases
> for making Guile [...]

> as another option, rename with an extension monicker (e.g., javascriptx)?

+1 for a "pidgin-" prefix (somewhat tongue-in-cheek ;-P

Or perhaps "pidguin-"?

But more seriously: I like the "extension" (be it prefix or suffix)
pattern most: people see what's intended and that it isn't the
"real thing".

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAltJoJIACgkQBcgs9XrR2kZ0AACcCoYBZWsoxEmFKHqd5pYbf/aJ
ZkkAmgIc0TENvbSMMC3qGO6EmlzVfBwj
=GN9e
-END PGP SIGNATURE-

Re: Compiling guile-2.2.4 for mingw

[tomas]

On Tue, Nov 20, 2018 at 03:31:25PM +0100, Christoph Buck wrote:
> Hi!
> 
> Currently i try to compile guile-2.2.4 under mingw64 bit. I had some
> minor issues in the c source code which i managed to fix by applying
> some of the patches from https://github.com/mkeeter/guile-mingw. Namely 

[...]

> > ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> > In procedure bytevector-u64-set!: Value out of range: -149659645
> > make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> > make[2]: Leaving directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> > make[1]: *** [Makefile:1857: all-recursive] Error 1
> > make[1]: Leaving directory '/home/Christoph.Buck/guile-2.2.4'
> > make: *** [Makefile:1743: all] Error 2

This looks a bit like an integer wraparound. It could well be that mingw
has a different size for some of its integral types (long int?).

Sorry, this is from a big distance here...

Cheers
-- t


signature.asc
Description: Digital signature

Re: Unexpectedly low read/write performance of open-pipe

[tomas]

Just wow.

I was aware for a while that Guile's I/O "story" wasn't stellar.
So I was watching this thread, as my awe grew, mail by mail.

Thanks Rob, Mark and all the others. This was really impressive.

You rock.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: [PATCH] Add current-suspendable-io-status parameter

[tomas]

On Mon, May 13, 2019 at 06:54:38PM +0800, Nala Ginrut wrote:
> Hi folks!
> Here's a patch to add current-suspendable-io-status:
> Its result is a pair: (finished-bytes . rest-bytes)

Sorry for this possibly dumb question, but... is there a way
to be non-blocking even if there are no readable/writable
bytes at all? Or would one have to do multi-threading (and
let the single threads [1] block) for that?

Thanks

[1] not necessarily "operating system" threads

-- tomás


signature.asc
Description: Digital signature

Re: [PATCH] Add current-suspendable-io-status parameter

[tomas]

On Wed, May 15, 2019 at 12:25:05PM +0100, Chris Vine wrote:
> On Wed, 15 May 2019 12:09:19 +0200
>  wrote:

> > Sorry for this possibly dumb question [...]

> With guile-2.2/3.0, you install suspendable ports and parameterize
> current-read-waiter and/or current-write-waiter.  There is an example
> here [...]

Thanks :)

Cheers
-- t


signature.asc
Description: Digital signature

Re: [PATCH] Add current-suspendable-io-status parameter

[tomas]

On Wed, May 15, 2019 at 07:25:37PM +0800, Nala Ginrut wrote:
> hi Tomas!
> For Guile, if you enabled suspendable-port, you may schedule the
> blocking task captured by delimited continuation.
> And use I/O multiplex mechanism (say, select or epoll) for monitoring
> the file descriptor (or port).

So basically it's like C -- you call read() or write() when select/epoll
tells you that this socket wants to play with you. Thanks!

Thanks to Chris qnd you

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

[tomas]

On Thu, Jun 06, 2019 at 05:40:39AM -0400, Mark H Weaver wrote:
> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal digits), without restricting the 64-bit pointer space at
> all, and without any loss of arithmetic precision.

[...]

Impressive bitfiddling feat. Thanks for the enjoyable explanation, too!

Cheers
-- t


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

On Mon, Aug 26, 2019 at 06:39:02PM +0200, Thomas Morley wrote:
> Am So., 25. Aug. 2019 um 22:22 Uhr schrieb Andy Wingo :
> >
> > We are pleased to announce GNU Guile release 2.9.4.  This is the fourth
> > pre-release of what will eventually become the 3.0 release series.
> 
> > We encourage you to test this release and provide feedback to
> > guile-devel@gnu.org, and to file bugs by sending mail to
> > bug-gu...@gnu.org.
> 
> Hi,
> 
> I did in my guile-git-repository:
> 
> git fetch
> git pull -r
> git checkout v2.9.4
> git checkout -b guile-2.9.4
> make clean
> sh autogen.sh
> ./configure
> make
> sudo make install
> 
> All went well, but then doing:
> ~$ guile
> returns:
> guile: error while loading shared libraries: libguile-3.0.so.0: cannot
> open shared object file: No such file or directory
> 
> But
> ~$ locate libguile-3.0.so.0
> returns:
> /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0
> /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0.0.0

Hm. After having done "sudo make install" above, I'd expect libguile
to land in /usr/local/lib somewhere: go look there.

 - Are you starting the "right" guile? (probably)
   What does "which guile" say?
 - What does "/usr/bin/ldd $(which guile) say?

Perhaps you have to add /usr/local/lib to /etc/ld.so.conf (or some
file below /etc/ld.so.conf.d) and run ldconfig.

HTH
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

On Mon, Aug 26, 2019 at 08:13:45PM +0200, Thomas Morley wrote:

[...ldconfig...]

> Hi tomás,
> 
> thanks for your hints.
> I've got it work by running nothing else than
> sudo ldconfig
> 
> But I wonder, shouldn't it work out of the box with 'sudo make install' ?

As far as I know it should be libtool's job, yes. But I might be wrong.

For me, it worked out of the box, but it's not the first installation
I do.

For someone more "in the know", perhaps your autotools versions might be
of interest.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

On Mon, Aug 26, 2019 at 03:12:47PM -0400, Mark H Weaver wrote:
> Hi Thomas,
> 
> Thomas Morley  writes:

[...]

> > But I wonder, shouldn't it work out of the box with 'sudo make install' ?
> 
> Running 'ldconfig' is not always appropriate, and therefore the vast
> majority of programs do *not* run 'ldconfig' in "make install" [...]

OK, that makes sense. I take my post back :-)

It was anyway based on a dim memory.

[...]

> In theory we could try to make a guess, but there's no reliable way for
> the build system to know whether it is appropriate or not, and in
> practice it is usually done as a separate step in most modern systems.

I think "making a guess" doesn't sound very attractive...

Cheers
-- t


signature.asc
Description: Digital signature

Re: missing word in "Building CPS" v 2.9.4

[tomas]

On Thu, Sep 05, 2019 at 07:04:07AM -0700, Matt Wette wrote:
> The reference manual for 2.9.4, Section 9.4.4.3 titled "Building
> CPS", paragraph 2, has sentence starting:
> 
> "Construction is handled by a set of mutually builder macros:"
> 
> I think there is a missing word between "mutually" and "builder". No
> clue what it is.

This being Scheme, I'd bet for "recursive" ;-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Stepping back up as a co-maintainer

[tomas]

On Thu, Oct 17, 2019 at 12:24:03PM +0200, Mikael Djurfeldt wrote:
> I think we should trust what Mark says and not second guess him.

Definitely. I think this should count for *all*. Second-guessing anyone
in this difficult situation can only add more difficulties on top.

I think each of us should apply Hanlon's razor with much generosity.

Towards all people involved (that doesn't mean we should paper over
the obvious problems we have, mind you).

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.5 Released [beta]

[tomas]

On Fri, Nov 22, 2019 at 04:22:39PM +0100, Andy Wingo wrote:
> We are pleased to announce GNU Guile release 2.9.5.  This is the fifth
> pre-release of what will eventually become the 3.0 release series.

Thanks!

Compiling now. And oh, thank you for all the magic (and for
explaining it to us mere muggles :-)

Thanks also to all the other magicians here.

Cheers
-- t


signature.asc
Description: Digital signature

Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]

[tomas]

On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote:
> 
> On 12/2/19 6:28 AM, Matt Wette wrote:
> >I'm building 2.9.5 now but running into errors (ubuntu 18.04):

[...]

> So, as a random check, I first verified that I could reproduce the
> above error at the command line.  I did.
> 
> Then I removed "-Oresolve-primitives" and it compiled without
> error.   Any help?

Thanks -- I seem to be stuck at an earlier point, see my other
post; but once I get past that, your hint will surely be helpful.

Cheers & thanks
-- tomás


signature.asc
Description: Digital signature

Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]

[tomas]

On Tue, Dec 03, 2019 at 10:15:35AM +0100, to...@tuxteam.de wrote:
> On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote:
> > 
> > On 12/2/19 6:28 AM, Matt Wette wrote:
> > >I'm building 2.9.5 now but running into errors (ubuntu 18.04):
> 
> [...]
> 
> > So, as a random check, I first verified that I could reproduce the
> > above error at the command line.  I did.
> > 
> > Then I removed "-Oresolve-primitives" and it compiled without
> > error.   Any help?
> 
> Thanks -- I seem to be stuck at an earlier point, see my other
> post; but once I get past that, your hint will surely be helpful.

OK, solved this one -- will try to follow up with the rest.

I just had to set GUILE_PROGS in etc/configure.ac besides GUILE_PKG,
like so:

  GUILE_PKG([3.0])
  GUILE_PROGS([2.9.5])

Configure now does "something". Next steps later.

Thanks so far -- and looking forward to playing nyacc :-)

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]

[tomas]

On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote:
> 
> On 12/2/19 6:28 AM, Matt Wette wrote:
> >I'm building 2.9.5 now but running into errors (ubuntu 18.04):
> >/bin/bash: line 6: 14657 Segmentation fault  (core dumped)
> >GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
> >--target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L
> >"/home/mwette/proj/guile/guile-2.9.5/module" -L
> >"/home/mwette/proj/guile/guile-2.9.5/guile-readline" -o
> >"system/vm/linker.go" "../module/system/vm/linker.scm"
> So, as a random check, I first verified that I could reproduce the
> above error at the command line.  I did.
> 
> Then I removed "-Oresolve-primitives" and it compiled without
> error.   Any help?

OK -- compiles successfully now. I realize in hindsight that
my answers sometimes went (only) to guile-devel, so I re-quote
that one where I "solved" configury:

> OK, solved this one -- will try to follow up with the rest.
> 
> I just had to set GUILE_PROGS in etc/configure.ac besides GUILE_PKG,
> like so:
> 
>   GUILE_PKG([3.0])
>   GUILE_PROGS([2.9.5])
> 
> Configure now does "something". Next steps later.

So far, so good. Now it compiles "cleanly" (but there's no -Oresolve-primitives
option in sight in all of the compile; no idea why).

A cursory test (with the example from the man page)
shows signs of life. Yay!

Thanks
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.7 Released [beta]

[tomas]

(Sorry for the cross-post, see below)

On Fri, Dec 13, 2019 at 09:23:46PM -0500, John Cowan wrote:
> I am getting the following build error on both Cygwin and Ubuntu Xenial.
> All is well until:
> 
>   BOOTSTRAP GUILEC system/vm/linker.go
> /bin/bash: line 6: 16683 Segmentation fault  (core dumped)
> GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
> --target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L
> "/home/rr828893/guile-2.9.7/module" -L
> "/home/rr828893/guile-2.9.7/guile-readline" -o "system/vm/linker.go"
> "../module/system/vm/linker.scm"
> Makefile:1930: recipe for target 'system/vm/linker.go' failed
> make[2]: *** [system/vm/linker.go] Error 139
> make[2]: Leaving directory '/home/rr828893/guile-2.9.7/bootstrap'
> Makefile:1849: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/rr828893/guile-2.9.7'
> Makefile:1735: recipe for target 'all' failed
> make: *** [all] Error 2

This sounds exactly like the bug Matt Wette is stumbling upon.
He posted to guile-devel@, so I don't know whether you missed
it, in any case it's here in the archive [1].

FWIW, Matt worked around it by removing "-Oresolve-primitives"
from the compile options.

I don't know whether there's a bug report on it already.

Cheers

[1] https://lists.gnu.org/archive/html/guile-devel/2019-12/msg00011.html

-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.8 Released [beta]

[tomas]

On Fri, Jan 03, 2020 at 01:34:59PM +0800, Nala Ginrut wrote:
> When I was trying to compile Artanis, the configure threw an error:
> 
> checking for Guile version >= 3.0... configure: error: Guile 3.0 required,
> but 2.9.8 found
> 
> 
> Here's what I put in configure.ac:
> GUILE_PKG(2.2 2.3 2.9 3.0)
> 
> My question is "what's the correct config here"?

Hm. I think I had that with nyacc too. This worked for me:

  GUILE_PKG([3.0])
  GUILE_PROGS([2.9.5])

I think this is due to our currently apocalyptic [1] situation:

  tomas@trotzki:~/src/guile/nyacc$ guile
  GNU Guile 2.9.5
  [...]
  
  Enter `,help' for help.
  scheme@(guile-user)> (version)
  $1 = "2.9.5"
  scheme@(guile-user)> (effective-version)
  $2 = "3.0"

(replace 2.9.5 for 2.9.8 as appropriate).

Cheers
[1] Although apocalyptic has often a negative connotation, I'm using
   it here in its more original sense [2], i.e. full of gleeful
   expectation :-)

[2] https://en.wiktionary.org/wiki/apocalyptic

-- tomás


signature.asc
Description: Digital signature

Re: Removal of hppa support

[tomas]

On Mon, Jan 27, 2020 at 12:30:15PM -0500, Stefan Monnier wrote:
> > Initially in Guile I planned to use GNU Lightning, in part because of
> > its great platform support.  However it turned out to not be the right
> > thing, and reluctantly I ended up doing something that was more like a
> > rewrite than a refactor.
> [...]
> > If someone would like to write an IA64 backend for Lightening, I would
> 
> So, do I understand correctly that Light*e*ning is the name you chose
> for Guile's rewrite of GNU Lightning?
> 
> Do you think it could be useful separately from Guile?

There's some infornmative text here:

https://wingolog.org/archives/2019/05/24/lightening-run-time-code-generation

Cheers
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Sat, Mar 27, 2021 at 10:19:20PM +0100, Maxime Devos wrote:
> Hi,
> 
> [CC'ing some Guile and Guix maintainers because this is
> important for the security of Guix System.]

[snipped CC, since my answer is just a thankyou]

> I want to explain why these patches (and the O_FLAGS (*)
> patch) should be included in Guile [...]

*THANK YOU*

This from someone striving to make Guile the "default tool for
around the house".

Cheers
 - t


signature.asc
Description: Digital signature

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

[tomas]

On Sat, Aug 07, 2021 at 12:31:09PM +0200, Taylan Kammer wrote:
> On 06.08.2021 16:33, Vijay Marupudi wrote:
> > Hello!
> > 
> > I was curious if Guile would be willing to provide a series of
> > new procedures for resizing contiguous memory regions.

[...]

> Sounds like a good idea to me.  I didn't know realloc() was a
> thing in C (I don't write much C) and I suppose it's not possible
> to implement equivalent functionality with equivalent performance
> purely in Scheme.
> 
> I'm on vacation for the next three weeks and will try to write a
> patch to implement this if no one beats me to it. :-)
> 
> One consideration is how this should behave in the case of
> bytevectors that were created from an FFI pointer [...]

Hm. I don't understand. Realloc /may/ return a different pointer
from the one it receives, for example if there isn't enough
room "beyond" the currently allocated. It will copy over the
contents, but if someone is holding a pointer to the old area
(as I understand you, this will be the case with an FFI pointer),
this isn't going to end well...

And then there is the constraint that the (original) pointer
passed to realloc /must/ be one returned by one of the malloc
family (how would the allocator know the original size otherwise?)

Cheers
 - t


signature.asc
Description: Digital signature

Re: more advanced bytevector => supervectors

[tomas]

On Thu, Sep 02, 2021 at 12:11:12PM -0700, Matt Wette wrote:
> maybe guile could consider regexp's in scheme
> see  https://ds26gte.github.io/pregexp/index.html

This would have other advantages (e.g. suspendable match
off a port), right?

Cheers
 - t


signature.asc
Description: Digital signature

Re: (inf) min max

[tomas]

On Tue, Sep 28, 2021 at 10:15:30AM +0200, Stefan Israelsson Tampe wrote:
> Why is (min (inf) 1) = 1.0  inexact?

Because inf's result is inexact. The same as (min 3 3.5) is inexact,
too.

It seems that the `inexactness' is contagious across arithmetic
generics (I haven't found an explicit place in the Guile docs;
the racket docs are more explicit about that).

Cheers
 - t


signature.asc
Description: Digital signature

Re: (inf) min max

[tomas]

On Tue, Sep 28, 2021 at 11:55:06AM +0200, Stefan Israelsson Tampe wrote:
> Then this does not work well
> 
> (fold min (inf) (list 1
> 200
> 3 4))
> 
> which is a pity, we should have an exact inf as well

Yeah, the idea of a numerical "tower" breaks down a bit in
the presence of arbitrarily big ints and exact fractions of
those. Suddenly, IEEE 754 aren't (always) at the tower's
"top".

It is as if someone attached a balcony to one of the
tower's sides and put an even taller tower on top of
that :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: guile and libgccjit

[tomas]

On Sun, Oct 10, 2021 at 09:57:13AM +0200, Linus Björnstam wrote:
> The the current JIT is, in my understanding, more or less a stepping stone 
> towards native compilation. The current JIT is very small and lightweight, 
> without any tracing, meaning things like register allocation is flexible 
> going forward.
> 
> I am not a maintainer, nor heavily involved, but I believe libgccjit would be 
> a step sideways considering the above. 

I think there's some (very readable!) rationale on why Andy chose a
relatively "simple" JIT in his blog [1]. It's a fork of GNU lightning.
The post explains why the powerful optimisations built into new
versions of Lightning seem contraproductive for Guile. Since libgccjit
will have even more powerful optimisations (it's gcc, after all!), I
guess the same arguments hold.

Note that Emacs is currently integrating an Elisp compiler based on
libgccjit. But as far as I can see, it's more an AOT compiler than a
JIT.

Cheers
[1] https://wingolog.org/archives/2019/05/24/lightening-run-time-code-generation
 - t


signature.asc
Description: Digital signature

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

[tomas]

On Sun, Feb 06, 2022 at 07:44:31AM +0100, Linus Björnstam wrote:
> 
> On Sat, 5 Feb 2022, at 18:31, Stefan Israelsson Tampe wrote:
> > 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?
> > There should  be a good reason or? this is a pretty fundamental change 
> > that I support but then we should not be lazy not trying to understand 
> > the design choices of the old beards.
> 
> In other languages let starts a new lexical context which can be expensive. I 
> don't know guile internals but a let without any defines is trivially 
> converted to a begin by the optimizer.

It seems that in Guile 3 the expander is smart enough for an empty
bindings list in let:

| tomas@trotzki:~$ guile
| GNU Guile 3.0.7.6-22120
| Copyright (C) 1995-2021 Free Software Foundation, Inc.

[...]

| scheme@(guile-user)> ,expand (let () (message #t "Yikes"))
| $1 = (message #t "Yikes")
| scheme@(guile-user)> ,expand (let ((x 3)) (message #t "Yikes ~S" x))
| $2 = (let ((x 3)) (message #t "Yikes ~S" x))

...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 "Yikes"))

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[tomas]

On Sun, Feb 06, 2022 at 10:45:54AM +0100, Linus Björnstam wrote:
> You need to use ,optimize. 

Thanks you both, Maxime and Linus, for giving me a new lantern :)

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[tomas]

On Sun, Feb 06, 2022 at 09:28:15PM +0100, Maxime Devos wrote:
> 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 to the more general
> 'let'?

Hm. Perhaps it's just ergonomics of sorts. The intention of `begin' seems
somehow clearer than a `let' with no bindings (or, more insidious, with
unused bindings ;)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: GNU Guile 3.0.8 released

[tomas]

On Fri, Feb 11, 2022 at 06:51:50PM +, Chris Vine wrote:
> On Fri, 11 Feb 2022 19:03:17 +0100
> Ricardo Wurmus  wrote:
> > Aleix Conchillo Flaqué  writes:
> > > On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  
> > > wrote:
> > >
> > >> 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 [...]
> > >>
> > >>
> > > Am I the only one who has not received the announcement?
> > 
> > No.  I also haven’t received it.
> 
> I didn't receive it either, on either guile-user or guile-devel.  It
> looks as if something may be amiss with the mailing list servers.

FWIW, I did receive it, and the To: header field looks innocent enough:

  To: guile-u...@gnu.org, guile-sour...@gnu.org, guile-devel@gnu.org, 
info-...@gnu.org

Here are the more envelope-ish headers:

  From guile-devel-bounces+tomas=tuxteam...@gnu.org Fri Feb 11 08:48:40 2022
  Return-path: 
  Envelope-to: to...@tuxteam.de
  Delivery-date: Fri, 11 Feb 2022 08:48:40 +0100
  Received: from lists.gnu.org ([209.51.188.17])
  by mail.tuxteam.de with esmtps  (TLS1.2) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  (Exim 4.94.2)
  (envelope-from )
  id 1nIQfY-rR-Jv
  for to...@tuxteam.de; Fri, 11 Feb 2022 08:48:40 +0100

...so it seems it came through guile-devel@

I haven't checked whether the DKIM signature is good, though. So maybe...

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Heads-up: LilyPond now running Guile 2.2

[tomas]

On Fri, Mar 18, 2022 at 12:17:56AM +0100, Jean Abou Samra wrote:
> For your information:
> 
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1250

You rock! Seriously Thanks.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Tom Lord passing

[tomas]

On Tue, Jul 19, 2022 at 04:31:41PM -0700, Andy Tai wrote:
> Thomas Lord was an early (or the first?) maintainer of guile
> 
> from https://berkeleydailyplanet.com/issue/2022-06-26/article/49837
> 
> Obituaries
> 
> Thomas Lord
> 1966-2022

[...]

Thanks for the reminder. I know I'll miss him.

Cheers
-- 
tomás


signature.asc
Description: PGP signature

Re: avoid character encoding/escaping in sxml->xml or htmlprag's sxml->html

[tomas]

On Sat, Aug 20, 2022 at 05:05:22PM -0700, Aleix Conchillo Flaqué wrote:
> Hi Maxime,
> 
> On Sat, Aug 20, 2022 at 2:48 PM Maxime Devos  wrote:
> >
> > The GuileScript looks nice, for interested readers, see <
> https://github.com/aconchillo/guilescript>
> >
> > On 20-08-2022 21:59, Aleix Conchillo Flaqué wrote:
> >
> > However, I'm not able to find a way to avoid character encoding/escaping
> and the generated code inside 

Re: avoid character encoding/escaping in sxml->xml or htmlprag's sxml->html

[tomas]

On Sun, Aug 21, 2022 at 12:16:54PM +0200, Maxime Devos wrote:
> On 21-08-2022 02:05, Aleix Conchillo Flaqué wrote:
> 
> > According to the spec, embedding inline content in the 

Re: help needed with stderr redirection

[tomas]

On Sat, Oct 22, 2022 at 01:29:05AM +0200, Csepp wrote:
> I have this short snippet of code for a Guix related utility script and
> for the love of the Glowcloud it does not want to work.  I want to
> filter stderr for certain lines and they are not being redirected.  When
> running the full script from a shell, it correctly captures standard
> out, but all the warnings and errors from the subprocess and/or its
> children go directly to the terminal.
> 
> I looked in the Guix sources to see how others do it and found mention
> of a possibly related bug:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52835
> Is that still relevant?  Because debuggs is just, khm, great, I don't
> see any clear indication of what its status is.
> 
> (define (with-input-from-make thunk)
>   (with-error-to-port
>   (current-output-port)
> (lambda _
>   (with-input-from-port
>   (open-pipe* OPEN_READ "make")
> thunk

I think `with-error-to-port' just directs the error messages of the
current process. Not the ones of the subprocess you are invoking with
open-pipe*. Could that be the case?

To get a better idea of what's going on, you can let a subshell handle
that redirection for you, substitute `open-pipe*' with the star-less
variable and try:

  (open-pipe OPEN_READ "make 2>&1")

If that works as you expect, you can work your way from there. If not,
we've learnt something :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Guile VM interpreter in GraalVM Truffle framework

[tomas]

On Fri, Dec 23, 2022 at 09:51:11PM +0100, Maxime Devos wrote:
> On 23-12-2022 18:06, Arvydas Silanskas wrote:
> > Good day,
> > 
> > I have aspirations to run scheme on graalvm's truffle framework. And on
> > superficial research, it seems implementing a Guile VM bytecode
> > interpreter could be easiest path. I just want to inquire, if someone
> > already had similar ideas and in secrecy is working or planning to on
> > this? If you're familiar with truffle (I'm not), any insights on "guile
> > on graal" would also be welcome.
> > 
> > Best regards
> > 
> > Arvydas
> 
> Scheme has a notion of ephemerons and weak hash tables.

Perhaps relevant in this context:

https://wingolog.org/archives/2022/11/28/are-ephemerons-primitive

(disclaimer: my vision tends to blur on those things :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: patch for mmap and friends

[tomas]

On Sat, Jan 14, 2023 at 04:18:58PM +0100, Maxime Devos wrote:

[...]

> (While it is recommended for Scheme code to keep a reference to the port to
> manually close afterwards, to free resources faster than waiting for GC, it
> is not actually required.)

Oh, oh. I've got a little anecdote to share here. The context was a Java
application, running on Sun medium-sized iron. It was slow & clumsy and
the customer decided to double the machine's RAM (these were times where
200 MB were quite a thing).

The application crashed a couple of times a day. Some log file poking
later it became clear: at the other side there was an Oracle database
and the app was exhausting the (limited) max number of connections
allowed for the license they had. More RAM -> less GC and the app was
relying on the object destructors to dispose of the unneeded database
connections.

There I learnt one shouldn't ever use memory as proxy for other
resources :-)

(The end of the story was that we could convince the user to have an
application under a free license and a free database :)

Cheers
-- 
t



signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Fri, Mar 17, 2023 at 06:25:55PM +0100, Mikael Djurfeldt wrote:
> Can you write a Guile Scheme program which displays a bouncing ball?
> 
> As an AI language model, I cannot create a full graphical program directly
> within this text-based environment. However, I can provide you with an
> example of a simple bouncing ball simulation using the Guile Scheme
> programming language and the SDL2 (Simple DirectMedia Layer) library, which
> is commonly used for creating graphical applications.
> 
> To start, you'll need to have Guile and the Guile-SDL2 bindings installed.
> The following instructions are for a Debian-based system:
> 
>1. Install Guile:
> 
> csharp
  ^^
> 
> sudo apt-get install guile-2.2

[...]

Did it literally write "csharp"? With some fantasy, I guess it
is trying to evoke a root shell, but with some malice, I'd say
Microsoft is sleazily touting some product of theirs.

I'd apply Clarke's Razor:"A sufficiently advanced form of malice
is not distinguishable from stupidity"

;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 08:55:03AM +0100, Mikael Djurfeldt wrote:
> >1. Install Guile:
> 
> > >
> > > csharp
> >   ^^
> > >
> > > sudo apt-get install guile-2.2
> >
> > [...]
> >
> > Did it literally write "csharp"? With some fantasy, I guess it
> > is trying to evoke a root shell, but with some malice, I'd say
> > Microsoft is sleazily touting some product of theirs.
> >
> 
> No, in the browser the bash lines were presented in windows which had the
> text "bash" in the title bar, but GPT-4 is a bit sloppy in that text can
> "leak in" from other documents, so the first two windows had the title
> csharp instead of bash.

Actually, I think those were associating the convention of suggesting
a root shell prompt by a '#', aka a "sharp sign". Given the flooding
of ghithub with csharp, the thing probably dreamt up the "c" before
the "sharp". Note that those are exactly the two lines you would
execute as root (not that I would ever execute a command suggested
by ChatGPT as root,mind you).

This is what I was hinting at with that pastiche of Hanlon's Razor
and Clarke's Third Law. If you're doing statistical "AI", no harm
is provably intended. But the dice might be loaded ;-)

>  When I then just marked a region in the browser and
> copied, the text from the title windows got copied too (and *I*, being a
> bit sloppy, didn't notice it :).

Those small details are the interesting parts. :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 09:22:43AM +0100, Mikael Djurfeldt wrote:
> BTW, in the bouncing ball example, I find it amazing that I could get an
> improvement of the code by complaining:
> 
> But all those SDL_ calls look like C bindings. Please use guile-sdl2
> bindings.
> 
> (It was also quite entertaining that I had to ask it to write the code
> "according to the guile-sdl2 manual".)

Perhaps you didn't know, but you are training the model :-)

This is called gamification, latest known in early 2000s. Luis von
Ahn [1] did quite a bit of pioneering work in that (he called it
"human computation", his PhD was "Games With a Purpose", Google
licensed a game from him to make people "out there" tag images for
them.

So I'd say this is established "technology".

Cheers

[1] https://en.wikipedia.org/wiki/Luis_von_Ahn
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 09:41:37AM +0100, Mikael Djurfeldt wrote:
> On Sat, Mar 18, 2023 at 9:36 AM  wrote:

[...]

> > Perhaps you didn't know, but you are training the model :-)
> >
> 
> Unfortunately not. I'm prompting it within its 32000 token (GPT-4)
> attention span. Next conversation the model is back to exactly the same
> state again. Then, of course, it is possible that OpenAI chooses to filter
> out something from the dialogs it has had.

You don't think that those coversations end up as raw data for the
next model? I'd be surprised, but you know definitely more than me.

> So, a trick you can do is to start out every session with a standard set of
> prompts (like "keep it short" or whatever) which will then act as a kind of
> configuration.

Oh, that's interesting!

Thanks
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 10:03:15AM +0100, Mikael Djurfeldt wrote:

[...]

> > I know very little apart from knowing what deep learning is and having
> > skimmed the "Attention is all you need"-paper.

That's already more than I do, I think. Thanks for the pointer :)

> >I only meant that you are
> > not training the model during and between sessions.

No, I don't think we are yet at "real time model training". But who knows.

> > It is certainly
> > possible that OpenAI filters out things from the dialogs to use as part of
> > training for the next version. They warn you that they may take data from
> > the dialogs. If and how they do that I don't know.

I'm pretty sure that this is the plan (besides, of course, of trying to
assess, understand public reaction to the whole idea, and perhaps to
steer public perception, as far as possible).

> Or, as GPT-4 would phrase it: I apologize for the confusion in my previous
> answer. You may be right that I'm training the next version of the model. :)

:-D

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 11:49:27AM +0100, Stefan Israelsson Tampe wrote:
> [...] Learning how to use ChatGpt to improve
> your code quality and productivity is how we should approach it. And the
> more experienced you are, the more effective use you will have of it.

The stench of Microsoft [1] is just too unsupportable to me. Luckily
I'm old and hope to be soon out-of-market anyway.

Cheers

[1] insert any other corporate overlord here.
-- 
t


signature.asc
Description: PGP signature

Re: GPT-4 knows Guile! :)

[tomas]

On Sat, Mar 18, 2023 at 09:21:37AM +0100, Dr. Arne Babenhauserheide wrote:
> 
>  writes:
> > I'd apply Clarke's Razor:"A sufficiently advanced form of malice
> > is not distinguishable from stupidity"
> 
> I love this! Thank you for sharing!

I reflected a bit on its genesis. It started while working deep
in a big company's belly -- I observed that, while the majority
of the people working in there where nice persons, the whole had
something evil in its behaviour and actions. There I came up with
the concept of "emergent evil", like the emergent behaviour you
might observe in an anthill.

While pondering this, I further realised that higher management's
job was to actually steer this emergent behaviour, and came to
the conclusion that a higher manager wasn't worth its salt if
(s)he didn't master this skill (and wouldn't probably stay at
this job). Whether that happens consciously or unconciously.

Mix in some plausible deniability ("steer", not "do"), and that
pastiche came up.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: (. wtf?)

[tomas]

On Sun, May 07, 2023 at 09:06:21PM +0300, Dmitry Alexandrov wrote:
> On Fri, 05 May 2023 16:35 Ludovic Courtès  wrote:
> > (call-with-input-string "(. wtf?)" read)
> >
> > ⇒ wtf?
> >
> > #Guile #Scheme
> 
> Hey!^W  Sorry...
> 
> Dear Guile developer,
> 
> your tweet made me deeply concerned.  Is it a sign that this behaviour is 
> going to be ‘fixed’ eventually?
> 
> Besides actually being (imho) the only right thing to do: explanation below 
> aside, just compare:
> #+begin_src scheme
> (define (fu bar) ...)
> (λ (bar) ...)
> (define (fu . quux) ...)
> (λ (. quux) ...)
> #+end_src
> 
> it is required for compatibility with elisp; where itʼs not only observed 
> de-facto:
> #+begin_src elisp
> '(. foo)
> ;; ⇒ foo
> #+end_src
> 
> but explicitly documented in (info "(elisp) Dotted Pair Notation") as well:
> #+begin_quote
>As a somewhat peculiar side effect of ‘(a b . c)’ and ‘(a . (b . c))’
> being equivalent, for consistency this means that if you replace ‘b’
> here with the empty sequence, then it follows that ‘(a . c)’ and ‘(a . (
> . c))’ are equivalent, too.  This also means that ‘( . c)’ is equivalent
> to ‘c’, but this is seldom used.
> #+end_quote

You seem to be somewhat upset, but I don't quite understand what
your gripe is. Is it the (define (...) ...) shorthand function
definition in Guile? Is it Guile's incompatibility with Emacs
Lisp (no wonder: the first is a Scheme, the second a Lisp: they
are related, but pretty different)?

Could you explain a bit better?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: (. wtf?)

[tomas]

On Mon, May 08, 2023 at 07:31:11AM +0200, Dr. Arne Babenhauserheide wrote:
> 
>  writes:
> 
> > You seem to be somewhat upset, but I don't quite understand what
> > your gripe is.
> 
> If I understood it correctly, they interpret the 'wtf? as expressing
> "this is a problem that should be changed" and wanted to say
> (equal? '(. a) 'a) should stay #true in Guile and consequently
> (call-with-input-string "(. wtf?)" read) ⇒ wft? should stay as it is.
> 
> The behavior of '(. a) is implementation dependent for Scheme. Some examples:
> 
> - guile: 'a
> - kawa: 'a
> - chez: error
> - chicken: error

Got it, thanks.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: (. wtf?)

[tomas]

On Mon, May 08, 2023 at 01:53:31PM +0300, Dmitry Alexandrov wrote:
>  wrote:
> >> it is required for compatibility with elisp
> >
> > Is it Guile's incompatibility with Emacs Lisp
> 
> As of now, they are compatible in that regard.
> 
> > (no wonder: the first is a Scheme, the second a Lisp: they are related, but 
> > pretty different)
> 
> Yet, but if I am not mistaken, =scheme= and =elisp= share the bits of reader, 
> that are responsible for the subject.

Thanks, Arne found the right hint for me :)

Cheers
-- 
t


signature.asc
Description: PGP signature

[semi-OT] Snarfing [was: [PATCH v2] doc: Document SRFI 64.]

[tomas]

On Wed, Nov 22, 2023 at 09:42:49PM +0100, Maxime Devos wrote:

[...]

> (I assume 'snarfing' is a form of copying here.)

Basically yes. Something like "stealing", perhaps because the source
isn't aware of the fact that it has got a new use.

The term is old UNIX tradition [1]. From there, it probably diffused
into GNU.

Cheers
[1] http://catb.org/jargon/html/S/snarf.html

-- 
t


signature.asc
Description: PGP signature

Re: Problems with running Network Socket Examples

[tomas]

On Sun, Nov 26, 2023 at 09:59:58PM +0100, Erik Grun wrote:
> Hello, Guile-Devel,
> 
> I just can't get the Network Socket Examples[1] to work. I am using Guile
> 3.0.7.
> 
> An obvious mistake seems to be, that the docs use different ports for client
> (80) and server (2904), but even if I use the same port (2904), I only get
> this error message:
> 
> Backtrace:
> In ice-9/boot-9.scm:
>1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
> 5 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>  724:2  4 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
>  619:8  3 (_ #(#(#)))
> In ice-9/boot-9.scm:
> 2835:4  2 (save-module-excursion _)
>4380:12  1 (_)
> In /home/egnun/client.scm:
>   7:14  0 (_)
> 
> /home/egnun/client.scm:7:14: Unbound variable: read-line
> 
> After some research I found out, that I need to include this line.
>  (use-modules (ice-9 rdelim))

Yes, I'd consider both of the above as downright doc bugs: the missing
of (ice-9 rdelim) in the client code and letting the client aim at a
different port the server is set up to listen to.

As for the third...

> When I do that, it seems to kinda work?
> 
> Hello client
> Backtrace:

[...]

> ERROR: In procedure %read-line:
> In procedure fport_read: Connection was reset by peer

... it is working "as it is supposed to": the server closes the
connection after sending the reply -- the client isn't set up
to expect this and complains (note that it dutifully prints the
server's answer "Hello client" before).

So this one is confusing, but we'd need a bit more of discussion
on how to "fix" it without complicating the examples too much.

Ideas?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Non-blocking web server

[tomas]

On Sun, Mar 24, 2024 at 03:41:32PM -0400, Ryan Raymond wrote:
> Hello, all.
> I was able to build a non-blocking web-server using network sockets.
> However, the existing guile web/server.scm implementation is
> single-threaded and therefore blocking [...]

How does "single-threaded" imply "blocking"? I mean: multithreading
does have its uses, no question (especially if you want to leverage
more than one CPU core).

As one example, Nginx, arguably the fastest of the web servers
out there isn't based on threads for concurrency.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [PATCH 1/3] Make string-length documentation more correct

[tomas]

On Wed, Jun 26, 2024 at 01:46:28PM +0200, Maxime Devos wrote:
> 
> >>  >-Returns the number of characters in the given @var{string}.
> >> +Returns the number of bytes in the given @var{string}.
> >>  
> >> This is false. For example, (string-length "😀") is 1, whereas in all 
> >> encodings I know of it is >more than one byte. Also, R5RS says: [...]
> >
> >Maybe `the number of codepoints` will work here.
> >
> >(string-length "👨‍🏭") ;; => 3
> >(string-length "é") ;; => 2
> >
> >The number of characters here is 1 in both cases.
> 
> No, in Unicode (and Guile equates character=Unicode character) all characters 
> correspond to a single codepoint.

It's more subtle than that: Unicode knows about "combining characters",
so it's quite possible that Andrew's "é" consists of two code points
(FWIW, it arrives to me as just one, but perhaps there was some
canonicalization [1] step in between).

ISTR that "Unicode character" is actually synonymous the same than "Unicode
code point" -- but the common meaning of "character" is more fuzzy. Perhaps
it's wise to avoid that word when trying to be precise.

Cheers

[1] https://en.wikipedia.org/wiki/Unicode_normalization

-- 
t


signature.asc
Description: PGP signature

Re: Improving the handling of system data (env, users, paths, ...)

[tomas]

On Sat, Jul 06, 2024 at 03:32:17PM -0500, Rob Browning wrote:
> 
> 
> * Problem
> 
> System data like environment variables, user names, group names, file
> paths and extended attributes (xattr), etc. are on some systems (like
> Linux) binary data, and may not be encodable as a string in the current
> locale.

Since this might get lost in the ensuing discussion, yes: in Linux (and
relatives) file names are byte arrays, not strings.

> It's perhaps worth noting, that while typically unlikely, any given
> directory could contain paths in an arbitrary collection of encodings:

Exactly: it's the creating process's locale what calls the shots. So
if you are in a multi-locale environment (e.g. users with different
encodings) this will happen.

> At a minimum, I suggest Guile should produce an error by default
> (instead of generating incorrect data) when the system bytes cannot be
> encoded in the current locale.

Yes, perhaps.

[iso-8859-1]

> There are disadvantages to this approach, but it's a fairly easy
> improvement.

I'm not a fan of this one: watching Emacs's development, people end
up using Latin-1 as a poor substitute of "byte array" :-)

> The most direct (and compact, if we do convert to UTF-8) representation
> would bytevectors, but then you would have a much more limited set of
> operations available (i.e. strings have all of srfi-13, srfi-14, etc.)
> unless we expanded them (likely re-using the existing code paths).  Of
> course you could still convert to Latin-1, perform the operation, and
> convert back, but that's not ideal.

It would be the right one, and let users deal with explicit conversions
from/to strings, so they see the issues happening, but alas, you are
right: it's very inconvenient.

> Finally, while I'm not sure how I feel about it, one notable precedent
> is Python's "surrogateescape" approach[5], which shifts any unencodable
> bytes into "lone Unicode surrogates", a process which can (and of course
> must) be safely reversed before handing the data back to the system.  It
> has its own trade-offs/(security)-concerns, as mentioned in the PEP.

FWIW, that's more or less what Emacs's internal encoding does: it is roughly
UTF-8, but reserves some code points to odd bytes (which it then displays
as backslash sequences). It's round-trip safe, but has its own set of sharp
edges, and naive [1] users get caught in them from time to time.

What's my point? Basically, that we shouldn't try to get it 100% right,
because there's possibly no way, and we pile up a lot of complexity which
is very difficult to get rid of (most languages have their painful transitions
to tell stories about).

I think it's ok to try some guesswork to make user's lives easier, but
perhaps to (by default) fail noisily at the least suspicion than to carry
happily away with wrong results.

Guessing UTF-8 seems a safe bet: for one, everybody (except Javascript) is
moving in that direction, for the other, you notice quickly when it isn't
(as opposed to ISO-8859-x, which will trundle along, producing funny content).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: The Guile junk drawer and a C plea

[tomas]

On Wed, Jul 17, 2024 at 11:44:09AM -0400, Olivier Dion wrote:
> On Wed, 17 Jul 2024, Lassi Kortela  wrote:

[...]

> > If the (guile ...) names are adopted, I suggest you keep the existing 
> > (ice-9 ...) libraries indefinitely but no longer advertise them in the 
> > manual.
> 
> I concur.  We can keep ice-9 indefinitely for backward support but also
> because it is a piece of Guile history.  Even when Guile 4 is out, I
> think ice-9 should be kept to ease transition from 3 to 4.  At the same
> time, major version bumping also mean API breakage .. so it might be a
> good opportunity.

To me, this makes most sense.

> However, if a (guile ...) hierarchy is introduced, all mentions to
> ice-9, except the historical note, ought to be removed from the manual.

Well -- perhaps except an explicit mention as a "historical term" (with
index entry) to help people understand/fix old code...

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Portable imports

[tomas]

On Sat, Jul 20, 2024 at 09:18:53PM +0200, Maxime Devos wrote:

[...]

> Also, AFAIK that %3a encoding isn’t necessary (and neither recognised(^)) in 
> Guile – I don’t think Guile does any percent encoding(*). I think naming the 
> file “srfi/:1.scm” would work fine, although it’s not something I’ve tried 
> before. (There might be a problem with Makefile if ‘make’ doesn’t like the :, 
> but I have some ideas for simple ways around that.)

For civilised file systems, yes. Windows will balk at the colon.
(Windows balks at lots of funny things in file names: the colon,
I somewhat expect, from DOS inheritance, but AFAIR, "+" is also
a no-go).

I guess that's where this funky URL encoding was intended to fix.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [PATCH] Per-module reader, take #2

[Tomas Zerolo]

On Thu, Oct 20, 2005 at 09:48:50AM +0200, Ludovic Court?s wrote:
> Hi Neil,
> 
> Neil Jerram <[EMAIL PROTECTED]> writes:
> 
> > I don't think it should be connected with modules, though.  In my
> > view:
> >
> > - modules should be about identifier access and visibility (including
> >   issues such as possible separate compilation in future), and nothing
> >   else  (and yes, this does imply that #:use-syntax was a mistake)
> 
> Right.
> 
> > - the appropriate unit of scope for your custom readers should be the
> >   file, not the module; for two reasons in particular:
> 
> This makes sense, too.

[snip]

But don't we loose the possibility then to have ``embedded goo´´ (say,
for example, something like a snippet of SQL in an otherwise Scheme
file)? This would be, I think, one of the nifty uses for pluggable
readers...

May be I'm completely off-base, since quite swamped ATM. If so, ignore.

Thanks
-- tomás


signature.asc
Description: Digital signature
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [PATCH] Per-module reader, take #3

[Tomas Zerolo]

On Thu, Dec 15, 2005 at 07:47:13PM +, Neil Jerram wrote:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
> 
> > OTOH, http://community.schemewiki.org/?variable-naming-convention
> > suggests a different naming convention.
> 
> Now that really is a horrible convention.  Hmm, how can we best
> confuse someone coming to Scheme from another language for the first
> time?

To be fair, they seem just to be reporting on current use (which is an
useful service).

Now I'm not implying to say that I like current use (which is somewhat
fragmented across Scheme implementations as well).

Regards
-- tomas


signature.asc
Description: Digital signature
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [PATCH] Per-module reader, take #3

[Tomas Zerolo]

On Fri, Dec 16, 2005 at 08:32:02AM +, Neil Jerram wrote:
> [EMAIL PROTECTED] (Tomas Zerolo) writes:
> 
> > On Thu, Dec 15, 2005 at 07:47:13PM +, Neil Jerram wrote:
> >> [EMAIL PROTECTED] (Ludovic Courtès) writes:
> >> 
> >> > OTOH, http://community.schemewiki.org/?variable-naming-convention
> >> > suggests a different naming convention.
> >> 
> >> Now that really is a horrible convention.  Hmm, how can we best
> >> confuse someone coming to Scheme from another language for the first
> >> time?
> >
> > To be fair, they seem just to be reporting on current use (which is an
> > useful service).
> 
> I wasn't criticising the people who compiled the Wiki page; it's a
> very useful page.  I'm specifically casting aspersions on the idea of
> the apparent `$name' convention for fluids.

Right, sorry. On re-reading this is definitely the more plausible
interpretation.

regards
-- tomas


signature.asc
Description: Digital signature
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Exposing `scm_i_mem2number ()'

[Tomas Zerolo]

On Wed, Feb 15, 2006 at 11:57:12PM +0200, Marius Vollmer wrote:
[...]
> But, what about scm_string_to_number (scm_from_locale_string (...))?
> Isn't that good enough?

Alas, attractive as it is it won't work: number representations vary
across locale settings (basically, it's decimal point and thousands
separator :-(

Regards
-- tomás


signature.asc
Description: Digital signature
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Guile 3.0.7 can not be compiled on Fedora rawhide

[Tomas Korbar]

Hi Guys,
I am trying to package guile 3.0.7 into Fedora but I encountered a problem.
In sources, there is a header lib/libc-config.h and then there is
preprocessor condition for presence of __attribute_maybe_unused__ macro.
This macro is newly defined in the latest version of glibc which we have in
Fedora rawhide but other macros upon which guile relies are not defined,
specifically it is __attribute_nonnull__. Do you have any idea how to solve
this situation? Currently guile 3.0.7 can not be compiled on Fedora rawhide
without manual removal of previously described conditional.

Thanks for any help.

[PATCH] doc: Extend documentation for (ice-9 match)

[Tomas Volf]

Extend the documentation for (ice-9 match) module with explanation of
some of the patterns and also provide more examples for them.  That
should make it more useful for people trying to use the module for the
first time just based on the documentation.

* doc/ref/match.texi (Pattern Matching): Explain some patterns and
provide more examples
---
When I tried to use (ice-9 match) for the first time, I was not able to,
except the most basic usage.  The documentation was not very helful, so
I went to the IRC.  I got help, but I was also asked to try to
contribute to the docs with examples that would have helped me in the
first place.

I think even more additions would be useful, but I still do not
understand the pattern matching fully, so they are not a part of this
patch.  Examples would be: How and when I should use quasi-patterns?
What does `ooo' stand for?  Does `box' refer to SRFI-111 or something
else?

I was following the HACKING file, so I added myself into the THANKS
file, I am not sure if I was supposed to for this relatively trivial
change.

 THANKS |  1 +
 doc/ref/match.texi | 75 ++
 2 files changed, 76 insertions(+)

diff --git a/THANKS b/THANKS
index aa4877e95..bb07cda83 100644
--- a/THANKS
+++ b/THANKS
@@ -38,6 +38,7 @@ Contributors since the last release:
  BT Templeton
   David Thompson
Bake Timmons
+ Tomas Volf
  Mark H Weaver
   Göran Weinholt
Ralf Wildenhues
diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index f5ea43118..b5a0147fa 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -181,6 +181,81 @@ The names @code{quote}, @code{quasiquote}, @code{unquote},
 @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
 @code{___} cannot be used as pattern variables.
 
+@code{string}, @code{number}, and others refer to literal strings,
+numbers, and others.  Therefore pattern @code{string} binds the value to
+identifier @code{string}, pattern @code{"string"} matches if the value
+is @code{"string"}.  Example demonstrating this (by using very bad
+naming):
+
+@example
+(let ()
+  (match "foo"
+(number number)))
+@result{} "foo"
+@end example
+
+The field operator (@code{(= field pat)}) has no relation to the fields
+of SRFI-9 records.  The @code{field} should be an expression evaluating
+to a procedure taking a single argument, and @code{pat} is matched
+against the return value.  Simple example:
+
+@example
+(let ()
+  (match '(1 2)
+((= cadr x)
+ x)))
+@result{} 2
+@end example
+
+The record operator(@code{($ record-name pat_1 ... pat_n)}) can be used
+for matching SRFI-9 and SRFI-99 records.  Patterns are matched against
+the slots in order, not all have to be present, and there is no way to
+skip a slot.  Example demonstrating the usage:
+
+@example
+(define-record-type 
+  (make-foo bar baz zab)
+  foo?
+  (bar foo-bar)
+  (baz foo-baz)
+  (zab foo-zab))
+
+(let ((obj (make-foo 1 '2 "three")))
+  (match obj
+;; Make sure obj is a  instance, with bar slot being a number
+;; and zab slot being a string.  We do not care about baz slot,
+;; therefore we use _ to match anything.
+(($  (? number?) _ (? string?))
+ "ok")))
+@result{} "ok"
+@end example
+
+If you need to ensure that a value is of a specific record type and at
+the same time bind it to a variable, the record operator will not be
+enough by itself, since you can only capture the fields.  You would need
+to combine it with other patterns, for example @code{(? foo? obj)}.
+
+When you need to apply multiple patterns, or a check and a pattern, you
+can use (@code{(? predicate pat_1 ... pat_n)}) for that.  The patterns
+are evaluated is if in the @code{(and ...)}.  If, for example, you want
+to check something is a symbol and at the same time bind the value to a
+variable, it could look like this:
+
+@example
+(let ()
+  (match '(delete . some-id)
+(('delete . (? symbol? id))
+ ;; We now could, for example, use the id to delete from some alist.
+ id)))
+@result{} some-id
+@end example
+
+@c FIXME: Remove this remark once everything is clearly described and
+@c consulting the comment is no longer necessary.
+If you are unclear about how something works, you can try consulting the
+large comment at the top of the @code{module/ice-9/match.upstream.scm}
+file in your guile distribution.
+
 Here is a more complex example:
 
 @example
-- 
2.41.0

Re: [PATCH] doc: Extend documentation for (ice-9 match)

[Tomas Volf]

Hello,

thanks for the review!  My reactions are below.

On 2023-09-20 00:57:33 +0200, Maxime Devos wrote:
> 
> 
> Op 06-09-2023 om 16:06 schreef Tomas Volf:
> > Extend the documentation for (ice-9 match) module with explanation of
> > some of the patterns and also provide more examples for them.  That
> > should make it more useful for people trying to use the module for the
> > first time just based on the documentation.
> >
> > * doc/ref/match.texi (Pattern Matching): Explain some patterns and
> > provide more examples
> > ---
> > When I tried to use (ice-9 match) for the first time, I was not able to,
> > except the most basic usage.  The documentation was not very helful, so
> > I went to the IRC.  I got help, but I was also asked to try to
> > contribute to the docs with examples that would have helped me in the
> > first place.
> >
> > I think even more additions would be useful, but I still do not
> > understand the pattern matching fully, so they are not a part of this
> > patch.  Examples would be: How and when I should use quasi-patterns?
> > What does `ooo' stand for?  Does `box' refer to SRFI-111 or something
> > else?
> Note: there is a previous patch for improving (ice-9 match) documentation
> named ‘[PATCH v3] docs/match: pattern matcher example makeover’, though IIRC
> it needed some changes.  Maybe you can adapt some things from it.  As long
> as it doesn't descend in fake gatekeeping accusations again, it would be
> nice if it wasn't for nothing.

I managed to find it, and there even seems to be a v4.  I sadly do not have the
time to work through it right now, and I do not want to make any promises
regarding if/when I will have it.  So for now I incorporated your feedback and
will sent it as v v2.

> 
> Smaller incremental improvements like this would also be nice, though.
> 
> >
> > I was following the HACKING file, so I added myself into the THANKS
> > file, I am not sure if I was supposed to for this relatively trivial
> > change.
> I think you aren't supposed to (whether it is trivial or not).  Instead, I
> think that others are supposed to add you to THANKS, otherwise you would be
> thanking yourself.  That is, however, a personal disagreement I have with
> HACKING.
> 
> I think that triviality or not is irrelevant; time spent on evaluating
> whether something is trivial or not is better spent on doing more
> contributors.  Besides, THANKS says ‘Contributors since the last release’,
> not ‘Contributors of non-trivial changes since the last release’.

Makes sense, removed.

> 
> >
> >   THANKS |  1 +
> >   doc/ref/match.texi | 75 ++
> >   2 files changed, 76 insertions(+)
> >
> > diff --git a/THANKS b/THANKS
> > index aa4877e95..bb07cda83 100644
> > --- a/THANKS
> > +++ b/THANKS
> > @@ -38,6 +38,7 @@ Contributors since the last release:
> >BT Templeton
> > David Thompson
> >  Bake Timmons
> > + Tomas Volf
> >Mark H Weaver
> > Göran Weinholt
> >  Ralf Wildenhues
> > diff --git a/doc/ref/match.texi b/doc/ref/match.texi
> > index f5ea43118..b5a0147fa 100644
> > --- a/doc/ref/match.texi
> > +++ b/doc/ref/match.texi
> > @@ -181,6 +181,81 @@ The names @code{quote}, @code{quasiquote},
> @code{unquote},
> >   @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
> >   @code{___} cannot be used as pattern variables.
> >
> > +@code{string}, @code{number}, and others refer to literal strings,
> > +numbers, and others.  Therefore pattern @code{string} binds the value to
> > +identifier @code{string}, pattern @code{"string"} matches if the value
> > +is @code{"string"}.
> It would do pause after ‘therefore’, not ‘before’.  Might just be a personal
> thing, though.  Also, something about joining two sentences with a comma
> instead of ‘and’ bothers me.  Also², I find it difficult to tell whether
> adding ‘the’ before ‘pattern’ would be better or worse. What do you think?

Maybe.  I am not that skilled with articles, so I defer to you here.  It at
least does not sound worse to me.

> 
> ‘Therefore, pattern @code{string} binds the value to
> 
> > Therefore the pattern @code{string} binds the value to
> > the identifier @code{string} and the pattern [...].
> 
> >  Example demonstrating this (by using very bad
> > +naming):
> Maybe ‘An example’?  But again, dunno.

Here as well.

> 
> > +
> > +@example
> > +(let ()
> > +  (match "foo"
> > + 

[PATCH v2] doc: Extend documentation for (ice-9 match)

[Tomas Volf]

Extend the documentation for (ice-9 match) module with explanations of
some of the patterns and also provide more examples for them.  That
should make it more useful for people trying to use the module for the
first time just based on the documentation.

* doc/ref/match.texi (Pattern Matching): Explain some patterns and
provide more examples.
---
Incorporate feedback from the review, mainly:
- drop myself from THANKS file, someone else can thank me if they want to
- remove most of unnecessary lets
- spelling and wording fixes
- add new paragraph describing (and ...)

 doc/ref/match.texi | 84 ++
 1 file changed, 84 insertions(+)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index f5ea43118..6e43d59b1 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -181,6 +181,90 @@ The names @code{quote}, @code{quasiquote}, @code{unquote},
 @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
 @code{___} cannot be used as pattern variables.
 
+@code{string}, @code{number}, and others refer to literal strings,
+numbers, and others.  Therefore, the pattern @code{string} binds the
+value to the identifier @code{string} and the pattern @code{"string"}
+matches if the value is @code{"string"}.  An example demonstrating this
+(by using very bad naming):
+
+@example
+(match "foo"
+  (number number))
+@result{} "foo"
+@end example
+
+The field operator (@code{(= field pat)}) has no relation to the fields
+of records.  The @code{field} should be an expression evaluating to a
+procedure taking a single argument, and @code{pat} is matched against
+the return value.  Simple example:
+
+@example
+(match '(1 2)
+  ((= cadr x)
+   x))
+@result{} 2
+@end example
+
+The record operator(@code{($ record-name pat_1 ... pat_n)}) can be used
+for matching records.  Patterns are matched against the slots in order,
+not all have to be present, and there is no way to skip a slot.  An
+example demonstrating the usage:
+
+@example
+(define-record-type 
+  (make-foo bar baz zab)
+  foo?
+  (bar foo-bar)
+  (baz foo-baz)
+  (zab foo-zab))
+
+(let ((obj (make-foo 1 '2 "three")))
+  (match obj
+;; Make sure obj is a  instance, with bar slot being a number
+;; and zab slot being a string.  We do not care about baz slot,
+;; therefore we use _ to match anything.
+(($  (? number?) _ (? string?))
+ "ok")))
+@result{} "ok"
+@end example
+
+If you need to ensure that a value is of a specific record type and at
+the same time bind it to a variable, the record operator will not be
+enough by itself, since you can only capture the fields.  You would need
+to combine it with other patterns, for example @code{(? foo? obj)}.
+
+When you need to apply multiple patterns, or a check and a pattern, you
+can use (@code{(? predicate pat_1 ... pat_n)}) for that.  The patterns
+are evaluated as if in the @code{(and ...)}.  If, for example, you want
+to check whether something is a symbol and at the same time bind the
+value to a variable, it could look like this:
+
+@example
+(match '(delete . some-id)
+  (('delete . (? symbol? id))
+   ;; We now could, for example, use the id to delete from some alist.
+   id))
+@result{} some-id
+@end example
+
+The @code{(and ...)} is of course useful as well, especially if no
+predicate is required.  While you could use @code{(const #t)} as the
+predicate, using @code{(and ...)} is better.  For example, capturing an
+object iff it is a list of at least two items can be done like this:
+
+@example
+(match '(foo baz bar)
+  ((and (a b ...) lst)
+   lst))
+@result{} (foo baz bar)
+@end example
+
+@c FIXME: Remove this remark once everything is clearly described and
+@c consulting the comment is no longer necessary.
+If you are unclear about how something works, you can try consulting the
+large comment at the top of the @code{module/ice-9/match.upstream.scm}
+file in your guile distribution.
+
 Here is a more complex example:
 
 @example
-- 
2.41.0

[PATCH] doc: Fix example in list-transduce example.

[Tomas Volf]

While the `.' might be correct from a grammatical point of view (I do
not know), it turns the example into invalid scheme code, which is not
ideal.  New users (like me) might try to copy the whole line and wonder
why it does not work (like I did).  So delete it.

* doc/ref/srfi-modules.texi (SRFI-171 General Discussion): Delete the
trailing . from the example.
---
 doc/ref/srfi-modules.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 0cdf56923..09b591e89 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -5748,7 +5748,7 @@ reducer with result-so-far and the maybe-transformed 
input.
 A simple example is as following:
 
 @example
-(list-transduce (tfilter odd?) + '(1 2 3 4 5)).
+(list-transduce (tfilter odd?) + '(1 2 3 4 5))
 @end example
 
 This first returns a transducer filtering all odd
-- 
2.41.0

[PATCH v3] doc: Extend documentation for (ice-9 match)

[Tomas Volf]

Extend the documentation for (ice-9 match) module with explanations of
some of the patterns and also provide more examples for them.  That
should make it more useful for people trying to use the module for the
first time just based on the documentation.

* doc/ref/match.texi (Pattern Matching): Explain some patterns and
provide more examples.
---
v2:
* drop myself from THANKS file, someone else can thank me if they want to
* remove most of unnecessary lets
* spelling and wording fixes
* add new paragraph describing (and ...)

v3:
Attempt to resolve feedback regarding the let usage:

> Whether you choose to to inline it or not, please do it consistently.

I removed all of them except two.  The very first one, since in this case I
believe it leads to the comments being more readable:

(let ((l '(hello (world
  (match l   ;; <- the input object
(('hello (who))  ;; <- the pattern
 who)))  ;; <- the expression evaluated upon matching

It also creates a nice contrast with the second example, which now also
demonstrates that you do not have to use the let, and the object can be inline.

Second case is the "more complex example", where I believe the let again leads
to significantly more readable code (keeping alice and bob together) to outweigh
the perceived inconsistency.

If requested, I can of course nuke these two usages as well.

 doc/ref/match.texi | 90 +++---
 1 file changed, 86 insertions(+), 4 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index f5ea43118..774fc856e 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -50,10 +50,9 @@ list---i.e., the symbol @code{world}.  An error would be 
raised if
 The same object can be matched against a simpler pattern:
 
 @example
-(let ((l '(hello (world
-  (match l
-((x y)
- (values x y
+(match '(hello (world))
+  ((x y)
+   (values x y)))
 @result{} hello
 @result{} (world)
 @end example
@@ -181,6 +180,89 @@ The names @code{quote}, @code{quasiquote}, @code{unquote},
 @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
 @code{___} cannot be used as pattern variables.
 
+@code{string}, @code{number}, and others refer to literal strings,
+numbers, and others.  Therefore, the pattern @code{string} binds the
+value to the identifier @code{string} and the pattern @code{"string"}
+matches if the value is @code{"string"}.  An example demonstrating this
+(by using very bad naming):
+
+@example
+(match "foo"
+  (number number))
+@result{} "foo"
+@end example
+
+The field operator (@code{(= field pat)}) has no relation to the fields
+of records.  The @code{field} should be an expression evaluating to a
+procedure taking a single argument, and @code{pat} is matched against
+the return value.  Simple example:
+
+@example
+(match '(1 2)
+  ((= cadr x)
+   x))
+@result{} 2
+@end example
+
+The record operator(@code{($ record-name pat_1 ... pat_n)}) can be used
+for matching records.  Patterns are matched against the slots in order,
+not all have to be present, and there is no way to skip a slot.  An
+example demonstrating the usage:
+
+@example
+(define-record-type 
+  (make-foo bar baz zab)
+  foo?
+  (bar foo-bar)
+  (baz foo-baz)
+  (zab foo-zab))
+
+(match (make-foo 1 '2 "three")
+  ;; Make sure obj is a  instance, with bar slot being a number
+  ;; and zab slot being a string.  We do not care about baz slot,
+  ;; therefore we use _ to match anything.
+  (($  (? number?) _ (? string?))
+   "ok"))
+@result{} "ok"
+@end example
+
+If you need to ensure that a value is of a specific record type and at
+the same time bind it to a variable, the record operator will not be
+enough by itself, since you can only capture the fields.  You would need
+to combine it with other patterns, for example @code{(? foo? obj)}.
+
+When you need to apply multiple patterns, or a check and a pattern, you
+can use (@code{(? predicate pat_1 ... pat_n)}) for that.  The patterns
+are evaluated as if in the @code{(and ...)}.  If, for example, you want
+to check whether something is a symbol and at the same time bind the
+value to a variable, it could look like this:
+
+@example
+(match '(delete . some-id)
+  (('delete . (? symbol? id))
+   ;; We now could, for example, use the id to delete from some alist.
+   id))
+@result{} some-id
+@end example
+
+The @code{(and ...)} is of course useful as well, especially if no
+predicate is required.  While you could use @code{(const #t)} as the
+predicate, using @code{(and ...)} is better.  For example, capturing an
+object iff it is a list of at least two items can be done like this:
+
+@example
+(match '(foo baz bar)
+  ((and (a b ...) lst)
+   lst))
+@result{} (foo baz bar)
+@end example
+
+@c FIXME: Remove this remark once everything is clearly described and
+@c consulting the comment is no longer necessary.
+If you are unclear about how something works, you can try consulting the
+large comment at the top of the @code{module/ice-9/mat

[PATCH] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On modern file-systems (BTRFS, ZFS) it is possible to copy a file using
copy-on-write method.  For large files it has the advantage of being
much faster and saving disk space (since identical extents are not
duplicated).  This feature is stable and for example coreutils' `cp'
does use it automatically (see --reflink).

This commit adds support for this feature into our
copy-file (scm_copy_file) procedure.  Same as `cp', it defaults to
'auto, meaning the copy-on-write is attempted, and in case of failure
the regular copy is performed.

No tests are provided, because the behavior depends on the system,
underlying file-system and its configuration.  That makes it challenging
to write a test for it.  Manual testing was performed instead:

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB36.00KiB   0.00B  /tmp/cow

$ cat cow-test.scm
(copy-file "/tmp/cow" "/tmp/cow-unspecified")
(copy-file "/tmp/cow" "/tmp/cow-always" #:copy-on-write 'always)
(copy-file "/tmp/cow" "/tmp/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/tmp/cow-never" #:copy-on-write 'never)
(copy-file "/tmp/cow" "/dev/shm/cow-unspecified")
(copy-file "/tmp/cow" "/dev/shm/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/dev/shm/cow-never" #:copy-on-write 'never)
$ ./meta/guile -s cow-test.scm

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB   0.00B36.00KiB  /tmp/cow
  36.00KiB   0.00B36.00KiB  /tmp/cow-always
  36.00KiB   0.00B36.00KiB  /tmp/cow-auto
  36.00KiB36.00KiB   0.00B  /tmp/cow-never
  36.00KiB   0.00B36.00KiB  /tmp/cow-unspecified

$ sha1sum /tmp/cow* /dev/shm/cow*
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-always
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-unspecified
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-unspecified

This commit also adds to new failure modes for (copy-file).

Failure to copy-on-write when 'always was passed in:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'always)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: copy-on-write failed: Invalid cross-device link

Passing in invalid value for the #:copy-on-write keyword argument:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'nevr)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: invalid value for #:copy-on-write: nevr

* NEWS: Add note for copy-file supporting copy-on-write.
* configure.ac: Check for linux/fs.h.
* doc/ref/posix.texi (File System)[copy-file]: Document the new
signature.
* libguile/filesys.c (clone_file): New function cloning a file using
FICLONE, if supported.
(k_copy_on_write): New keyword.
(sym_always, sym_auto, sym_never): New symbols.
(scm_copy_file): New #:copy-on-write keyword argument.  Attempt
copy-on-write copy by default.
* libguile/filesys.h: Update signature for scm_copy_file.
---
My first C patch to Guile.  I am not used to the GNU coding style, so I
apologize in advance if I got something wrong.  I tried.

I believe the 'auto is correct default, mimicking how coreutils' cp works.

 NEWS   |  9 ++
 configure.ac   |  1 +
 doc/ref/posix.texi |  9 +-
 libguile/filesys.c | 74 +++---
 libguile/filesys.h |  2 +-
 5 files changed, 82 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index b319404d7..9147098c9 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,15 @@ definitely unused---this is notably the case for modules 
that are only
 used at macro-expansion time, such as (srfi srfi-26).  In those cases,
 the compiler reports it as "possibly unused".

+** copy-file now supports copy-on-write
+
+The copy-file procedure now takes an additional keyword argument,
+#:copy-on-write, specifying whether copy-on-write should be done, if the
+underlying file-system supports it.  Possible values are 'always, 'auto
+and 'never, with 'auto being the default.
+
+This speeds up copying large files a lot while saving the disk space.
+
 * Bug fixes

 ** (ice-9 suspendable-ports) incorrect UTF-8 decoding
diff --git a/configure.ac b/configure.ac
index d0a2dc79b..c46586e9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,7 @@ AC_SUBST([SCM_I_GSC_HAVE_STRUCT_DIRENT64])
 #   sys/sendfile.h - non-POSIX, found in glibc
 #
 AC_CHECK_HEADERS([complex.h fenv.h io.h memory.h process.h \
+linux/fs.h \
 sys/dir.h sys/ioctl.h sys/select.h \
 sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.

[PATCH] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Until now, the ./meta/guile was not mentioned anywhere, and therefore it
was not obvious how to run the locally compiled Guile without installing
it.

While modifying the file, I took the liberty to also mention a bit about
compiling Guile using Guix.

Finally, the header lines where cleaned up, ensuring all of them end at
70 and have a leading space.

* HACKING (Hacking It Yourself): Add Guix instructions.  Add a note
about meta/guile script.
(Sample GDB Initialization File),
(Naming conventions): Clean up the header line.
---
I think this will make it easier for people to start hacking on the Guile.

 HACKING | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/HACKING b/HACKING
index 387643bf7..ae39218fa 100644
--- a/HACKING
+++ b/HACKING
@@ -26,6 +26,26 @@ http://www.gnu.org/software/guile/mail/mail.html for more 
info.

 Hacking It Yourself ==

+You can spawn a shell with all the required dependencies using GNU Guix
+by running the following command:
+
+guix shell -D -f guix.scm --pure
+
+In this way, you can effortlessly compile Guile from the Git checkout
+with just these three lines:
+
+guix shell -D -f guix.scm --pure -- ./autogen.sh
+guix shell -D -f guix.scm --pure -- ./configure --enable-mini-gmp
+guix shell -D -f guix.scm --pure -- make
+
+Once that finishes, you can execute your newly compiled Guile using the
+./meta/guile script:
+
+$ ./meta/guile -v | head -n1
+guile (GNU Guile) 3.0.9.139-d7cf5-dirty
+
+For more manual approach, read on.
+
 When Guile is obtained from Git, a few extra steps must be taken
 before the usual configure, make, make install.  You will need to have
 up-to-date versions of the tools as listed below, correctly installed.
@@ -73,7 +93,7 @@ Here is the authoritative list of tool/version/platform 
tuples that
 have been known to cause problems, and a short description of the problem.


-Sample GDB Initialization File=
+Sample GDB Initialization File ===

 In GDB, you probably want to load the gdbinit file included with Guile,
 which defines a number of GDB helpers to inspect Scheme values.
@@ -215,7 +235,7 @@ The goal is to reduce (and over time, eliminate) spurious 
diffs.
 For Emacs users:
   (add-hook 'before-save-hook 'delete-trailing-whitespace)

-Naming conventions =
+Naming conventions ===

 We use certain naming conventions to structure the considerable number
 of global identifiers.  All identifiers should be either all lower
--
2.41.0

Re: [PATCH] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Thank you for the review.

On 2023-12-04 22:06:42 +0100, Maxime Devos wrote:
>
>
> Op 29-11-2023 om 17:40 schreef Tomas Volf:
> > +guix shell -D -f guix.scm --pure -- ./configure --enable-mini-gmp
>
> Also -fexcess-precision=standard (see #49368 / #49659 on debbugs) (at least
> for i*86, should be harmless for other architectures though).

That explains why I did not catch it (I did run the test suite, but I am on
x86_64).

Out of curiosity, since it should be harmless elsewhere, is there a reason this
is not a flag set by default?

>
> Also --disable-jit when on the Hurd.
>
> You might want to check if static libraries are built by default (*), and if
> so, add --disable-static to reduce compilation time.
>
> (*) can be tested with "find . -name '*.a'" after "make" -- don't worry
> about libgnu.a, IIUC only libguile-3.0.a / .so is important.
>
> Best regards,
> Maxime Devos.

I added a note regarding the Hurd and the disabling of static libraries.

Will send v2.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

[PATCH v2] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Until now, the ./meta/guile was not mentioned anywhere, and therefore it
was not obvious how to run the locally compiled Guile without installing
it.

While modifying the file, I took the liberty to also mention a bit about
compiling Guile using Guix.

Finally, the header lines where cleaned up, ensuring all of them end at
70 and have a leading space.

* HACKING (Hacking It Yourself): Add Guix instructions.  Add a note
about meta/guile script.
(Sample GDB Initialization File),
(Naming conventions): Clean up the header line.
---
v2:
Add note regarding JIT and GNU Hurd.  Add note regarding -fexcess-precision.
Add --disable-static and explain it.

 HACKING | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/HACKING b/HACKING
index 387643bf7..5926fb275 100644
--- a/HACKING
+++ b/HACKING
@@ -26,6 +26,40 @@ http://www.gnu.org/software/guile/mail/mail.html for more 
info.

 Hacking It Yourself ==

+You can spawn a shell with all the required dependencies using GNU Guix
+by running the following command:
+
+guix shell -D -f guix.scm --pure
+
+In this way, you can effortlessly compile Guile from the Git checkout
+with just these three lines:
+
+guix shell -D -f guix.scm --pure -- ./autogen.sh
+guix shell -D -f guix.scm --pure -- ./configure \
+--enable-mini-gmp --disable-static
+guix shell -D -f guix.scm --pure -- make
+
+Disabling of the static libraries is optional, but it does speed up the
+builds, and you are unlikely to need them for local development.
+
+  Note: Currently JIT causes Guile to crash in obscure ways on GNU Hurd,
+so on that platform you want to also pass the --disable-jit flag
+to the configure script.
+
+  Note: On any i*86 architecture, you also need to pass in the compiler
+flag -fexcess-precision=standard in order to get the test suite
+to pass.  That can be done by passing an additional argument to
+the configure script:
+ CFLAGS='-g -O2 -fexcess-precision=standard'
+
+Once that finishes, you can execute your newly compiled Guile using the
+./meta/guile script:
+
+$ ./meta/guile -v | head -n1
+guile (GNU Guile) 3.0.9.139-d7cf5-dirty
+
+For more manual approach, read on.
+
 When Guile is obtained from Git, a few extra steps must be taken
 before the usual configure, make, make install.  You will need to have
 up-to-date versions of the tools as listed below, correctly installed.
@@ -73,7 +107,7 @@ Here is the authoritative list of tool/version/platform 
tuples that
 have been known to cause problems, and a short description of the problem.


-Sample GDB Initialization File=
+Sample GDB Initialization File ===

 In GDB, you probably want to load the gdbinit file included with Guile,
 which defines a number of GDB helpers to inspect Scheme values.
@@ -215,7 +249,7 @@ The goal is to reduce (and over time, eliminate) spurious 
diffs.
 For Emacs users:
   (add-hook 'before-save-hook 'delete-trailing-whitespace)

-Naming conventions =
+Naming conventions ===

 We use certain naming conventions to structure the considerable number
 of global identifiers.  All identifiers should be either all lower
--
2.41.0

Re: How to abort a read from a socket after some time?

[Tomas Volf]

Hello,

thank you very much for the email and the suggested approach, I will try it out.
I just have one more question:

On 2024-01-22 00:46:23 +0100, M wrote:
> >
> > All code below runs after handler is set:
> >
> >(sigaction SIGALRM (lambda _ (display "Alarm!\n")))
>
> Assuming the read-char takes too long, the kernel sends a SIGALRM to Guile. 
> Hence, the C signal handler is run (which sets some fields somewhere 
> indicating that this handler should be run later in the sense of 
> system-async-mark), and the syscall behind read-char returns EINTR.
>
> As this is a fake error (passing it on as a Scheme exception would result in 
> rather messy semantics, e.g. consider the case where things are interrupted 
> twice in a row, time such that the exception handler itself is interrupted 
> with a new exception), Guile decides to retry the syscall

I am confused about this.  I read the documentation for sigaction, and there is
this text for the flags argument:

  -- Variable: SA_RESTART
  If a signal occurs while in a system call, deliver the signal
  then restart the system call (as opposed to returning an
  ‘EINTR’ error from that call).

Based on that my expectation was to get EINTR.  But since the syscall seems to
be restarted even without the SA_RESTART, what exactly does this flag do then?

Thank you,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

RFC: Changing the initial value of %default-port-conversion-strategy

[Tomas Volf]

Greetings,

during my current quest to get more G-expressions working with UTF-8 input, I
have read the Guile's documentation, in particular '(guile)Encoding', and I
think change in default behavior is warranted.

Currently the initial value of %default-port-conversion-strategy is 'substitute.
I would like to propose changing it to 'error on the ground of preventing subtle
bugs and data corruption.

Just a reminder, when 'substitute is used, any non-representable character is
replaced with #\?.  No error is signaled and user has no way to detect it even
happened.  I just do not believe that to be a reasonable default.

Let us take a look for example at test-suite/standalone/test-mb-regexp.  It
contains this code:

(regexp-exec
 (make-regexp "(.)(.)(.)")
 (string (integer->char 200) #\x (integer->char 202)))

That might look sensible until you realize that the following regexp *also*
matches:

(make-regexp "(\\?)(.)(\\?)")

This is just asking for potential bugs (possibly security related) and data
corruption.  The 'substitute strategy should of course stay (if someone actually
needs it), but the default should really be changed to 'error.

Work-wise it is very feasible, the change is minimal (single line both in
ports.c and in documentation) and just few tests break:
* test-mb-regexp:
But this just demonstrates code that should have not worked in the first
place.  IMO.
* test-bad-identifiers:
Requires setlocale to UTF-8 locale and converting one source file
(guardians.c) from latin1 to UTF-8.
* ports.test:
This explicitly tests the default value, so it needs to be adjusted.

Real world impact should be limited, since most people are likely to run with
LANG set to *some* UTF-8 locale.  And if you do not have that, I (and I expect
majority of engineers) would prefer correctness over convenience.

I strongly believe the current default is wrong and dangerous, but I am
obviously interested what other people think, hence this message.  Please let me
know what you think.  Should I put this into actual patch?  Does it have chance
to be accepted and merged into the master?

Thank you for reading and have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature