Andy Wingo writes:
> Adopting the behavior is more or less fine. If it can be done while
> relying on the existing behavior, that is better than something ad-hoc
> in a module.
You mean somehow leveraging the existing BOM handling code of Guile
(found in the ports code) would be preferable to r
Andy Wingo writes:
> On Mon 13 Mar 2017 19:10, taylanbayi...@gmail.com (Taylan Ulrich
> "Bayırlı/Kammer") writes:
>
>> If I do binary I/O, the following situations are possible:
>>
>> 1. I'm guaranteed to get any possible bytes that happen to form a val
Andy Wingo writes:
> Hi,
>
> this is a tricky area that is not so amenable to quick patches :) Have
> you looked into what Guile already does for byte-order marks? Can you
> explain how the R6RS specification relates to this?
>
> https://www.gnu.org/software/guile/manual/html_node/BOM-Handling
Please ignore this, as it's a duplicate of #26058.
See the R6RS Libraries document page 10. The differences:
- R6RS supports reading a BOM.
- R6RS mandates an endianness argument to specify the behavior at the
absence of a BOM.
- R6RS allows an optional third argument 'endianness-mandatory' to
explicitly ignore any possible BOM.
Here's a q
See the R6RS Libraries document page 10. The differences:
- R6RS supports reading a BOM.
- R6RS mandates an endianness argument to specify the behavior at the
absence of a BOM.
- R6RS allows an optional third argument 'endianness-mandatory' to
explicitly ignore any possible BOM.
Here's a q
Here's a patch, tested minimally by running
(par-for-each (lambda (x)
(monitor
(sleep 1)
(display "foo\n")))
(iota 10))
on a quad-core. Previously it would print the "foo"s in groups of four
with a second betwe
Ping with CC to Andy. :-)
Pinging this thread with a (very slightly) updated patch. :-)
>From 7f35d515d711e255bba5a89a013d9d92034edf41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Tue, 21 Jun 2016 00:25:19 +0200
Subject: [PATCH] Hashtable-set! errors on immutable hashtable.
Also pinging this thread with a (very slightly) updated patch. :-)
>From 17599f6ce7ba0beb100e80455ff99af07333d871 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Tue, 21 Jun 2016 00:23:29 +0200
Subject: [PATCH] Hashtable-hash-function returns #f on eq
Here's a patch to fix this.
>From a3e5a705aaea725fd75280a27b971d8e45e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Sun, 24 Jan 2016 12:23:34 +0100
Subject: [PATCH] Hashtable-hash-function returns #f on eq and eqv tables.
* module/rnrs/hashtabl
I forgot to change the test suite accordingly. Here's an updated patch.
>From 7483d98cf1e5439ac62ee8da3e216a413853b40c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Sat, 23 Jan 2016 22:35:24 +0100
Subject: [PATCH 1/2] Hashtable-set! errors on immuta
Sorry about the duplicate bug report; I merged it into this one.
Here's the patch again. (Merged report seemed invisible in the web
interface.)
>From dd6c4bbbe85a57fcbb08bdc7847075bddc1f0d87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Sat, 23 Jan
I couldn't find explicit wording in R6RS on what should happen, but I
would generally expect an attempt to mutate an immutable object to
raise an error. In Guile,
(hashtable-set! (hashtable-copy (make-eq-hashtable)) 'foo 'bar)
is silently ignored.
Attached is a simple patch that raises an a
I couldn't find explicit wording in R6RS on what should happen, but I
would generally expect an attempt to mutate an immutable object to
raise an error. In Guile,
(hashtable-set! (hashtable-copy (make-eq-hashtable)) 'foo 'bar)
is silently ignored.
Taylan
Per R6RS, the following forms should return #f:
(hashtable-hash-function (make-eq-hashtable))
(hashtable-hash-function (make-eqv-hashtable))
but in Guile they return procedures.
Taylan
It seems that the 'monitor' form is currently a no-op. The form
(par-for-each (lambda (x)
(monitor
(foo)))
xs)
should be functionally equivalent to
(let ((mutex (make-mutex)))
(par-for-each (lambda (x)
A possible work-around seems to be to use 'load' or 'load-compiled' on a
module file after compiling it.
As far as I understand, the problem is that Guile somehow ends up with a
"degenerate" version of the module in the run-time after it's compiled
but not fully loaded, so we alleviate that by exp
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> This seems to be related to 'compile-file' setting
> '%file-port-name-canonicalization' to 'relative', but I don't know
> what the correct fix is.
With the following trivial
When a file to be compiled, A.scm, contains (include "B.scm"), the
compiler fails to find B.scm if the directory containing A and B are in
Guile's load path.
Here's a shell transcript showcasing the bug:
--- snip ---
$ mkdir test
$ echo '(include "test2.scm")' > test/test1.scm
$ echo '(display "f
Mark H Weaver writes:
> How about changing the first formal argument name to 'template-id' and
> changing the words "syntax object" to "identifier"?
>
> Thanks!
>Mark
Sure, updated patch attached.
Taylan
>From 2ba9474dc8e2a56524d8c6c2f640fb3fb35b2d14 Mon Sep 17 00:00:00 2001
From:
Please ignore this bug report, since it was my fault. I had a foreign
(rnrs exceptions) library in my load-path that took precedence.
Sorry about the noise.
Taylan
Apparently there's two ways to represent a list syntax object:
(datum->syntax #'x '(a b c))
=> #(syntax-object (a b c) ((top)) (hygiene guile-user))
i.e. a syntax object vector with a list payload, and
#'(a b c)
=> (#(syntax-object a ((top)) (hygiene guile-user))
#(syntax
It seems that whatever macro tries to match the guard expression's
else-clause, fails to do so when the clause contains more than one
expression, and so adds a default "else re-raise" clause after the
existing else clause.
I couldn't figure out where this happens. I grepped the whole
source tree
When there are relative paths in the load-path, `include-from-path'
seems to always interpret them relative to the directory of the file in
which the `include-from-path' is called, instead of relative to the
current working directory in effect when Guile is started.
Transcript:
--- SNIP ---
tayla
When string->number is given a number in scientific notation with a
very high exponent, it errors with "value out of range."
I don't know if that is acceptable, but what seems unacceptable is
that it errors even if the string contains further characters and is
thus not a valid number; R5RS says th
writes:
> Seems to work fine on master
I just built from the master branch to be sure and can still reproduce.
> Maybe try strace, possibly limiting it with -e connect, to reveal what
> it's actually doing.
Not sure what I should be looking for, but there is no connect() call,
no occurrence of
writes:
> I wonder, could localhost be resolving to your ethernet IP address?
> Or maybe resolving to an IPv6 address?
tub@taylan:~$ nslookup localhost
Server: 127.0.0.1
Address:127.0.0.1#53
Name: localhost
Address: 127.0.0.1
tub@taylan:~$
The local DNS server is dnsmasq.
>
After starting 'guile --listen', I can connect to it via 127.0.0.1 but
not "localhost": "Ncat: Connection refused." I don't know if
listening on "localhost" by default has any security implications?
Shell 1:
tub@taylan:~$ guile --listen
GNU Guile 2.0.11
Copyright (C) 1995-2014 Free Software Fou
29 matches
Mail list logo
