Note that 121 is withdrawn, so people should implement 158.
On Sat, Jan 23, 2021 at 1:38 AM Mark H Weaver wrote:
> Hi Arthur,
>
> "Arthur A. Gleckler" writes:
> > It's not a bad idea for the sample implementation to be as clear as
> > possible at the expense of performance.
>
> I agree that
Back in July 2020, Mark Weaver wrote:
Also, the provided implementations of 'generator-find', 'generator-any'
> and 'generator-every' are incorrect:
Shiro Kawai has now fixed these bugs, and they have been merged into SRFI
121. Note that even if it doesn't become part of Guile's
ach is called until it is
exhausted in left to right order.
> PS: One of my own issues with SRFI 158 is that accumulators are not
> that well-designed from a logical point of view. I summarized it here:
> https://srfi-email.schemers.org/srfi-158/msg/6219505/. A follow-up
> thread begins her
Mark Weaver wrote in July 2019:
Also, the provided implementations of 'generator-find', 'generator-any'
> and 'generator-every' are incorrect:
I appreciate your finding these bugs. I wish, however, that you had also
sent them to .
Excellent, and thank you all! I've been WIndowsless for a few weeks, but
that should change again soon.
On Sun, Feb 16, 2020 at 6:23 PM Mike Gran wrote:
> On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote:
> > Andy, I don't know if you'd want to continue this here or on
> >
\.libs\guile.exe,
pid 62833, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
I can't imagine what you can make of that.
On Sat, Jan 25, 2020 at 10:54 AM John Cowan wrote:
>
>
> On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès wrote:
>
>
>> That I understand.
ot;_rl_get_keymap_name", referenced from:
_scm_init_readline in readline.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
On Thu, Jan 23, 2020 at 3:35 PM Ludovic Courtès wrote:
> Hi,
>
>
I'm no longer talking about Cygwin (which builds fine without JIT). I'm
now talking about MacOS Catalina, which needs a core dump to debug, but on
which nobody seems to know how to enable core dumps.
On Tue, Jan 21, 2020 at 1:41 PM szgyg wrote:
> On Tue, Jan 21, 2020 at 10:01:58AM +0100,
nd SIGSEGV on
running processes and no dumps appear in /cores.
On Tue, Jan 21, 2020 at 4:02 AM Ludovic Courtès wrote:
> Hello,
>
> John Cowan skribis:
>
> > Yes, gladly, but I don't know how to get one in this context.
>
> You would unpack, configure, and build like you
Yes, gladly, but I don't know how to get one in this context. Do I need to
add some flags to the Makefile, and if so, where? (It's a twisty maze of
passages, all different.) . Note that this *is* a build with JIT enabled;
when I disable it using the env variable, there are no errors and 3.0.0
Okay, with GUILE_JIT_THRESHOLD set to -1 in the environment, I can build
Guile under Cygwin. There are two test failures which probably reflect
differences between newlib and glibc:
ERROR: time.test: strptime: GNU %s format: strftime fr_FR.utf8 - arguments:
((system-error "strptime" "~A"
Makefile:1735: all] Error 2
All previous problems (which were easy to work around) have gone away in
this release, which is progress, but it doesn't get me past Guile 2.2.
John Cowan http://vrici.lojban.org/~cowanco...@ccil.org
Your worships will perhaps be thinking that it is an
That makes three different operating environments exposing this exact build
failure: MacOS, Cygwin, Ubuntu Xenial.
On Sat, Dec 14, 2019 at 1:17 AM Aleix Conchillo Flaqué
wrote:
> Hi there!
>
> Trying to build 2.9.7 on OS X and getting the error below.
>
> I'd be happy to try more things if you
ror 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
THUNK argument is referred to
> as PROC. Should such (minor) errors be fixed? One of my patches also
> fixes a misplaced space character in the Texinfo.
>
http://mumble.net/~kelsey/r5rs-errata.html are the semi-official errata.
IMO you should incorporate them.
--
John Cowan
On Tue, Jun 20, 2017 at 10:45 PM, Mark H Weaver wrote:
I believe I've found a few mistakes in the formal denotational semantics
> for R7RS-small. The scheme-reports mailing list seems to be gone, so
> I'm not sure where to send this.
>
I'm forwarding this to
16 matches
Mail list logo