ad a goal of making
something as simple to use as the Twine interactive fiction engine. I
posted that on the wiki for now.
-Mike Gran
ted in interesting ways.
I went ahead and threw that up on the libreplanet wiki for now
Regards,
Mike Gran
such project ready for use?
If nothing is happening on that front, I would like to put some time
into it.
Regards,
Mike Gran
On Wed, Sep 05, 2018 at 07:07:11PM -0300, David Pirotte wrote:
>
> If I were you, I'd try to run and use sbank:
>
>https://github.com/rotty/sbank.git
>
> [ even though itis a bit old and will need some love, it's retty well
> [ written and is in schee already ...
>
> t needs
On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
> Mike Gran writes:
>
> > Hey Chris,
> >
> > This is one of two errors. One problem is that Guile makes assumptions
> > about the size of long vs the size of a pointer, as do some the
> > l
ke it
easier to submit patches. We need to make it easier to incorporate
patches.
Some projects (like Pixman) have a rule that if a patch receives no
opposition after a few weeks and a couple of pings, you are free to
push it. I wonder if that would work here? Or would it be too
chaotic?
My two cents,
Mike Gran
.
Regards,
Mike Gran
l send a reworked patch for you to consider.
Regards,
Mike Gran
e reply to this e-
mail so I can gauge the feasibility of some sort of participation swag.
Regards,
Mike Gran, on behalf of the Guile team
Hello Guile-
By convention, DLLs in cygwin start with 'cyg' instead of 'lib' to avoid name
clashing.
In an autotools build like Guile, dlls are build as 'cyg'
Now that we've dumped libltdl, we don't automatically search for both 'lib' and
'cyg' on cygwin.
Should we emulate this in foreign-library
ed that it
compiles.)
Let me know what you think.
Thanks,
Mike Gran
On Thu, Sep 15, 2022 at 10:20:26PM -0700, Mike Gran wrote:
> Hello Guile Devel,
>
> I pushed a git branch: wip-modernize-autotools.
>
> It removes some obsolete tests by presuming we at least have a
> C89-compliant C library. It also uses LT_INIT for libtool, and removes
o quickly.
Also, it might be that this isn't worth doing. After all, you can run
Guile on Cygwin and Guix on WSL on Windows 10/11 already.
But some projects that depend on Guile do deliver on
Windows using customized versions of 2.2 or 1.8.
Let me know what you think.
-Mike Gran
[1]
On Tuesday, June 6, 2023 at 02:10:25 PM PDT, Thompson, David
wrote:
...
>> Janneke has also poked at Windows support a few times as well, and
>> he actually got it to run on 64-bit Windows.
>Did JIT work? When I tried this years ago it didn't. Would be a major
>victory if it works now.
There
interactions, or like in independent medical
> issues that happened at the same time as working on Guile/Guix stuff?
>I don't need to know per se but this footnote is ambiguous.
Oh sorry, I didn't imagine it could be read that way. Medically ill.
I recommend against getting old, if you can avoid it.
Regards,
Mike Gran
demonstrate current best practice.
Also, I have some doubt that users are looking at that code
for inspiration, rather than what online sources provide.
It uses "make installcheck", which is uncommon.
Regards,
Mike Gran
Hey Guile-
So I'm still plugging away at this Guile on Windows stuff.
In a tree on Github [1], I started from the top and cleaned up
the 64-bit Cygwin and MSYS problems. Cygwin and MSYS
are two related projects where you compile with GCC,
with the newlib C library, and a link to a library that
p
Hi,
I was looking at https://debbugs.gnu.org/db/pa/lguile.html
and saw that 10519 (add mini-gmp) should be closed.
How do you actually close a bug?
Thanks,
Mike Gran
Daniel-
>> How do you actually close a bug?
> An email to -done @ debbugs.gnu.org will close the bug. This is
> explained in https://elpa.gnu.org/packages/doc/debbugs-ug.html
Oh, there's an emacs mode for debbugs. Sounds useful. I'll check it out.
That doc doesn't seem to explain that sendi
> Hi,
> Would a rewrite of the Guile tests using SRFI-64 be a welcome idea?
> IMO the advantages of doing so are:
...
>Opinions?
IMHO, I think Guile should not depend too heavily on Guile for testing itself.
It is bad bootstrapping practice.
And personally, I find that errors in srfi-64 tests
> A benefit of SRFI-64 is that the SRFI-64 implementation has tests
> whereas (IIRC) Guile's custom thing doesn't.
OK two separate issues.
1. Mike G's gripes about SRFI-64.
2. Updating over 65,000 lines of test code
I don't want to be put in the position of having to make a critique of
SRFI-64,
On Sunday, July 7, 2024 at 08:58:34 AM PDT, Eli Zaretskii wrote:
>> I don't think it's worth it. If anybody's going to work on this problem,
>> I'd recommend simply adding APIs like program-arguments-bytevector,
>> getenv-bytevector and the like, returning raw bytevectors instead of strings,
>> a
>Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed
>string ports to honor it, like other port types, instead of forcing
>'error. This seems like the right thing to me, for the sake of
>consistency (in fact, I’d consider the previous behavior as a bug), but
>it’s an observable c
> From: Ludovic Courtès
>> I imagine if this particular fix goes smoothly, i will be motivated to
>> continue w/ this kind of maintenance work, where the focus is on
>> continuity and stability (perhaps likewise showing 1.6 and 1.4 some
>> love, as well).
>
> Hmm, I’d find it more important
ng is given and not allstring-for-each
terminates
Since R7RS is just going to undo the change, it hardly seems
worth changing, in my opinion.
http://www.scheme-reports.org/2012/working-group-1.html
-Mike Gran
> From: Mike Gran
>
> For what it is worth, R7RS WG1 draft 6 says "If more than one
> strings have the same length,
> when the shortest string runs out."string is given and not
> allstring-for-each terminates
Gah! Sorry, worst cut-and-paste ever. That's wha
egative image
8 concealed characters
30 black display
31 red display
32 green display
33 yellow display
34 blue display
35 magenta display
36 cyan display
37 white display
40 black background
41 red background
42 green background
43 yellow background
44 blue background
45 magenta background
46 cyan background
47 white background
Of course, each terminal
is different in practice. The only way to be sure you
are getting it right is to go through terminfo.
OTOH, these days when everything behaves almost like
color xterm, maybe parsing terminfo is just being
pedantic.
Thanks,
Mike Gran
> From: Mark H Weaver
> To: guile-devel@gnu.org
> Cc: Michael Gran
> Sent: Sunday, January 13, 2013 10:25 AM
> Subject: Scanning for coding declarations in all files (not just source)
>
Hi Mark,
> I just discovered that Guile is scanning for coding declarations in
> *all* files opened with 'ope
Hi Andy,
> From: Andy Wingo
> But no, currently the answer is locale-specific. It encodes the string
> according to the current locale, then decodes it from that encoding. If
> your locale can't encode the string, tough luck for you!
>
> This is a bit crazy. Surely the port should be textual?
oretical possibility
that a doc in encodings like ISO-8859-2 through 8859-5
could begin with 0xff 0xfe or 0xfe 0xff. They are
valid characters.
So if there is a "coding:" line in the doc, I think it
should nullify giving precedence to a UTF-16 BOM.
-Mike Gran
> From: Nala Ginrut
>
> Hi Boriani & Vepstas !
> I'm dealing with a web-framework and using guile-dbi & guile-dbd, which
> are nice thing to handle the databases. ;-)
> I found there're something obsoleted in the current code, when I tried
> to format a patch I've noticed the bug-report&patches h
> I have the feeling that we should implement our own dynamic-link
> function without libltdl. It would eliminate a dependency and allow us
> to use other search path rules, like ones that could deal with this
> case. I think the situation would actually be better on other
> architectures because
Hi-
There's something we discussed in bug report #13611 that
might be of general interest.
If you're using a gc built with --enable-parallel-marks
with Guile, you can get a SEGV during garbage collection
of a SMOB. BDW-GC v7.3 has that flag enabled by default.
It allows the garbage collector to
From: Noah Lavine
>Hello,
>>On Wed 23 Jan 2013 13:20, Daniel Llorens writes:
>>
>>> In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
>>
>>> In [4]: a[1]
>>> Out[4]: array([4, 5, 6])
>>> In [5]: a[1, 1]
>>> Out[5]: 5
>>>
>>> array-ref can be extended very simply to do that. It accumulates o
> From: David Pirotte
> do we actually have a matrice calculus [offset based the better] lib or
> binding
> or
> scheme package ? any pointer is welcome
There once was a package called guile-num. You can find it here.
www.nongnu.org/guile-num
But, it would take some work to get it to run aga
> From: Andy Wingo
> So, what do you think about always adding O_BINARY to files that Guile
> opens?
Lilypond, Gnucash, Denemo, Autogen and Emacs all run on Windows
to varying degrees. As does Gnome Games. If it doesn't break
any of them, then it might be okay. In an ideal world, there would
b
76d0d Mon Sep 17 00:00:00 2001
From: Mike Gran
Date: Tue, 26 Feb 2013 08:27:22 -0800
Subject: [PATCH] Add standalone test for smob marking
* test-suite/standalone/Makefile.am: add test-smob-mark
* test-suite/standalone/test-smob-mark.c: new test
* test-suite/standalone/.gitignore: ignore test-smob
> From: Mike Gran
> What would you think about applying the following patch?
>
> It is a standalone test that, in effect, checks to see if
> BDW-GC is running marking in its own non-Guile thread. If
> BDW does have parallel marking enabled, this test will SEGV.
> If it
> From: Andy Wingo
>I made some notes there.
>
Hi Andy,
I noticed in your comments to Nala G that you recommend using
`print-exception'. Is that intended to be public API? It doesn't
appear in the manual.
Thanks,
Mike
Hello.
There seem to be four ways to force an exit.
In boot-9, a function `quit' is defined. It appears in the manual,
but, in boot-9 it can take an argument. In the manual it never
takes an argument.
In boot-9, `exit' is aliased to quit. In the manual `exit' is
undocumented; however, in th
Hi Ludo
> Attached is a patch to use Guile’s Texinfo support [0] to build said
> file. Guile’s Texinfo parser is incomplete but sufficient to handle
> those docstrings.
> OK to commit?
If Guile depends on Guile for multiple stages the build, it becomes
difficult to recover from a problem when
> From: Mark H Weaver
>
>Andy suggested this. Okay to push to stable-2.0?
Hi Mark,
I can't imagine any possible way that this patch could make
performance worse, but, it is in the very core of the ports.
I don't think you can get away without at least a bit of
profiling.
-Mike
> From: Mark H Weaver
> Thanks for nudging me to do the measurement. To be honest, the original
> patch I posted slowed things down by 4.5%, which I found extremely
> surprising. I fixed it by adding an internal 'static' version of
> 'scm_fill_input'. So for those who doubt the cost of functio
Hi Mark
>>> Here's the new patch. Any more suggestions?
There are a couple of lines in your doc patch that aren't quite right.
"@code{UTF-16BE}, @code{UTF-16LE}, @code{UTF-16BE}, or @code{UTF-16LE}"
I assume that two of these should be UTF-32.
Also
"This is intended to multiple logical te
>>> + /* If the specified encoding is UTF-16 or UTF-32, then make
>>> + that more precise by deciding what endianness to use. */
>>> + if (strcasecmp (pt->encoding, "UTF-16") == 0)
>>> + precise_encoding = decide_utf16_encoding (port, mode);
>>> + else if (strcas
>> I discovered that 'scm_unget_byte' is kind of dumb. It puts the
> bytes
>> at the beginning of the pushback buffer instead of the end. This means
>> that every time you unget a byte, it has to shift up the existing
>> contents of the buffer, so ungetting N bytes takes O(N^2) time.
>>
>>
> From: Stjepan Horvat
>ls /usr/share/guile/site
>colorized.scm shell.scm src.scm
I guess they probably should have been put in
/usr/share/guile/site/nala/
-Mike
> UTF-8-encoded ELF symbols may be more of a problem. How could NULs in
> symbols be handled?
You could re-map NUL to one of the PUA characters, perhaps. It seems unlikely
that ELF symbols should ever contain private use characters.
-Mike
- Original Message
> From: Linas Vepstas
> To: Andy Wingo
> Cc: Ludovic Courtès ; guile-devel@gnu.org
> Sent: Sunday, June 21, 2009 2:17:46 AM
> Subject: Re: GNU Guile 1.9.0 released (alpha)
>
> 2009/6/20 Andy Wingo :
> > On Sat 20 Jun 2009 05:00, Linas Vepstas writes:
> >
> >> Run
> From: Changying Li
>
> thanks very much!
>
> BTW, when will guile support unicode ?
>
Hopefully, we will have Unicode functionality in
the second alpha version 1.9.1. There are still
a couple of issues before it can be merged
into the main tree. This should happen in a
month or so.
I'm finding that master fails to build with the following terminating
error:
---
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
"ice-9/lineio.go" "ice-9/lineio.scm"
ERROR: In procedure make_objcode_by_mmap:
ERROR: bad header on object file: "GOOF-0.5"
make[2]: *** [ice-9/line
On Thu, 2009-06-11 at 23:12 +0200, Andy Wingo wrote:
> Howdy good sir!
>
I'm back on task. I'll go through your comments from the review of a
month or so ago, and try to push the Unicode stuff next week. Things
seem stable on my end, but, some optimization work remains to be done.
With respect
> From: Ludovic Courtès
>
> Hello!
>
> Neil Jerram writes:
>
> >> Perhaps we should set up a GNU Guile Hackers Meeting (G²HM) by the time
> >> 2.0 is released?
> >
> > If it works for everyone, why not?
>
> To make things more concrete, how about August 22--23? It works for
> Andy and me.
>
Hi-
I wonder if I could get someone to check out what I've done with wide
strings and the VM on the string_abstraction2 branch with commit
efb042...
That code is quite confusing, and I may have made a mess of it. And, I
wasn't sure about alignment.
I daresay that this Unicode string stuff is no
> From: bornlibra23
>
> Hello People
> I am trying to port various GNU products to Stratus OpenVOS platform
> including the guile project. However I am stuck currently for the lack of
> wide & multibyte character support. Can somebody guide me to an
> implementation of the same that I can port f
On Fri, 2009-07-31 at 00:57 +0200, Ludovic Courtès wrote:
Hello!
>
> "Michael Gran" writes:
>
> > The branch, master has been updated
> >via 77332b21a01fac906ae4707426e00f01e62c0415 (commit)
> > from e5dc27b86d0eaa470f92cdaa9f4ed2a961338c49 (commit)
>
> Oops, I hadn't realized t
On Fri, 2009-07-31 at 01:21 +0200, Ludovic Courtès wrote:
> "Michael Gran" writes:
> My remark about user-visibility was actually regarding this commit, not
> the previous one.
>
> > +#ifndef SCM_WCHAR_DEFINED
> > +typedef scm_t_int32 scm_t_wchar;
> > +#define SCM_WCHAR_DEFINED
> > +#endif
>
> W
On Sun, 2009-08-02 at 16:40 -0700, Mike Gran wrote:
> Hi-
>
> I think I scared Ludo when I committed something, so let me try this
> instead. Attached please find the next patch toward Unicode strings. It
> is a big patch, but, it is the smallest patch I could make that added
>
On Sat, 2009-08-08 at 02:44 -0700, Mike Gran wrote:
> On Sun, 2009-08-02 at 16:40 -0700, Mike Gran wrote:
> > Hi-
> >
> > I think I scared Ludo when I committed something, so let me try this
> > instead. Attached please find the next patch toward Unicode strings. It
On Sun, 2009-08-09 at 20:22 +0200, Ludovic Courtès wrote:
> Hi Mike!
> I would feel more confident if the number of lines of tests added was
> proportional to the number of new C lines of code. Do you think some
> more tests could be added? Or maybe this will come at a later stage?
I should pr
> From: Andy Wingo
>
> Hello Guilers,
Hi Andy,
>
> Today's the 10th, we release on the 15th, ergo we're frozen.
>
Hmmm. I should have been watching the clock. I've left master in
an odd state w.r.t. strings and chars. The storage is available for
non-8-bit strings and chars, but, nothin
On Tue, 2009-08-11 at 09:39 -0400, Greg Troxel wrote:
> In srfi-13.c line 25222, SCM_MAKE_CHAR is called with an argument that
> is an unsigned char. This leads to:
>
> cc1: warnings being treated as errors
> srfi-13.c: In function 'string_titlecase_x':
> srfi-13.c:2522: warning: comparison is al
On Tue, 2009-08-11 at 08:29 -0400, Greg Troxel wrote:
> I built libunistring and tried to build master. Some tests failed, and
> also the build failed due to warnings (post to follow). I think all the
> failed tests are locale related.
>
A possible cause of some of this may be when I replaced t
On Tue, 2009-08-11 at 17:54 +0200, Ludovic Courtès wrote:
> I also noticed another problem (x86_64-unknown-linux-gnu):
>
> --8<---cut here---start->8---
> scheme@(guile-user)> (string=? "\u0100\u0101\x0102" "\u0100\u0101\x0102")
>
> Backtrace:
> In unknown fil
> From: Ludovic Courtès l...@gnu.org
> Apparently the disassembler needs to be taught Unicode:
There's a disassembler?
In the assembler, the string, symbol, keyword, and define are changed
from
--
3 bytes: string length
LENGTH bytes: one byte chars
--
to
--
3 bytes: string leng
> From: Juhani Viheräkoski moonsh...@kapsi.fi
> Hi,
>
> For me the build of the current master fails with:
>
> libtool: compile: gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I..
-I../lib
> -I../lib -pthread -Wall -Wmissing-prototypes -Werror -fvisibility=hidden -O3
-g
> -march=athlon-xp
Hi-
I hope that master is closer to building cleanly today w.r.t. strings.
- Added a cast in SCM_MAKE_CHAR. If that doesn't work, then maybe
SCM_MAKE_CHAR should become an inline function.
- Removed some signed/unsigned comparisons and conversions
- Applied Greg Troxel's patch to cast all input
Hi-
guile.m4's serial number should be bumped for releases if it has changed.
Thanks,
Mike
On Sat, 2009-08-15 at 15:06 +0200, Ludovic Courtès wrote:
> We are pleased to announce GNU Guile release 1.9.2.
Sweet.
Result from a machine. i686-pc-linux-gnu running Redhat 10 and gcc
4.3.2. As was to be expected, it all turned out OK.
Scheme compilation had two sets of warnings
-
On Sat, 2009-08-15 at 15:43 +0200, Ludovic Courtès wrote:
> Hi,
>
> Mike Gran writes:
>
> > guile.m4's serial number should be bumped for releases if it has changed.
>
> AFAICS there hasn't been any change recently. Did you spot something?
>
> Thanks
Hi-
On Mon, 2009-08-17 at 10:26 +0200, Ludovic Courtès wrote:
> Hi,
>
> Ken Raeburn writes:
>
> > On Aug 16, 2009, at 18:13, Ludovic Courtès wrote:
> >>> There's always the inline-function approach, too.
> >>
> >> Unfortunately no, because we're still not assuming `inline' keyword
> >> support
> From: Linas Vepstas
>
> 2009/8/15 Ludovic Courtès :
>
> > ** Incomplete support for Unicode characters and strings
> >
> > Internally, strings are now represented either in the `latin-1'
> > encoding, one byte per character, or in UTF-32, with four bytes per
> > character.
>
> Will this e
> From: Ludovic Courtès
> To: guile-devel@gnu.org
> Sent: Monday, August 17, 2009 8:33:03 AM
> Subject: Re: `SCM_MAKE_CHAR ()' signedness issue
>
> I'm fairly confident that for such a small piece of code inlining is
> always a good idea.
OK. If the comparison is modified to become
35 #define
> From: carlo.bramix
>
> Hello,
> unfortunately that code still fails into libguile/print.c
> Infact, a signed char just arrives to 127 and the " < 128" causes:
>
> ../../guile-git/libguile/print.c:1101: warning: comparison is always true due
> to
> limited range of data type
> ../../guile-git
On Wed, 2009-08-19 at 10:38 +0200, Ludovic Courtès wrote:
> Hello!
>
> Just a note that I've been meaning to send for some time.
>
> "Michael Gran" writes:
>
> > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=9b0c25f6d18d5be318ea3a47fd87cf7e63b689e1
>
> [...]
>
> I'm not fully convinc
On Wed, 2009-08-19 at 15:53 +0200, Ludovic Courtès wrote:
> Mike Gran writes:
>
> > On Wed, 2009-08-19 at 10:38 +0200, Ludovic Courtès wrote:
> I just wanted to hear what you and others thought about the issue,
> because I think unit tests are a crucial part of software dev
On Wed, 2009-08-19 at 09:56 -0400, Greg Troxel wrote:
> From my autobuild on master
>
> vm-i-scheme.c:437: warning: comparison is always true due to limited range of
> data type
For gcc, -Wtype-limits will catch this at compile time. Maybe we should
put that in the GCC_CFLAGS in the configure.i
On Wed, 2009-08-19 at 17:25 +0200, Ludovic Courtès wrote:
> Mike Gran writes:
> > For gcc, -Wtype-limits will catch this at compile time.
>
> IIUC this is precisely a compile-time warning. :-)
It is a compile time warning that is default for Greg, but apparently
not for Andy or I.
-Mike
On Fri, 2009-08-21 at 14:27 -0400, Greg Troxel wrote:
> I ran 'gmake -k' to get all the warnings at once. I think there are
> just two groups:
> deprecated.c:1092: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> vm-i-scheme.c:437: warning: comparison is always tr
The latest commit 'Add full Unicode capability to ports and the default
reader' 889975e51accb80491af76fc5db980aeb3edd342 adds the majority of
the functionality for non-ASCII strings.
The commit breaks functions that have to do with locale-specific case
conversion and character-sets, and some tes
Hi-
I pushed the commit for Unicode-capable srfi-14. Of all parts necessary
for Unicode, this patch has the largest amount of new code and is most
likely to cause compilation problems.
Since the default charsets such as char-set:lower-case are much larger
in the Unicode scenario, I had to change
> From: Ken Raeburn
> On Aug 27, 2009, at 17:15, Andy Wingo wrote:
> > I have reverted that part of the "eval is actually compile" commit that
> > seems to have caused you problems.
>
> Thanks; that puts it back to the "print a warning and go on" case, which lets
> me
> get other work done.
>
On Tue, 2009-09-01 at 02:14 +0200, Ludovic Courtès wrote:
> Hello!
>
> Stringbufs and bytevectors are now always "inlined" in the BDW-GC
> branch [0, 1], which means that there's no cell->buffer indirection,
> which greatly simplifies code (it also takes less room and may slightly
> improve perfor
On Mon, 2009-08-31 at 11:21 +0100, Neil Jerram wrote:
> I think there's a case here for making the docstring not identical to
> the corresponding manual text. In the manual context, the section
> begins with talking about Unicode, so "Unicode" can be assumed for
> everything that follows. But in
On Mon, 2009-08-31 at 18:40 -0700, Mike Gran wrote:
> Note that the German letter Sharp S
> (Eszett) is not uppercased before the comparison since its plural has
> two characters instead of one."
I meant to say 'its _uppercase form_ has two characters instead of one'.
- Original Message
> From: Andy Wingo
> To: Ludovic Courtès
> Cc: guile-devel@gnu.org
> Sent: Tuesday, September 1, 2009 11:25:26 AM
> Subject: Re: Unicode ports patch
>
> Hi,
>
> On Tue 01 Sep 2009 10:19, l...@gnu.org (Ludovic Courtès) writes:
>
>
> > It would be nicer if string ports were actually bytevector ports, and that
> > they were locale-independent? Or that scm_get_output_bytevector returned a
> > locale-independent (ergo 8-bit or 32-bit) vector?
>
> The latter.
The test suite requires an API for testing the correctness of the
On Sun, 2009-09-06 at 12:45 +0200, Andy Wingo wrote:
> Hey Mike,
>
> Would you mind posting to the list a "state of unicode & guile" summary?
> I'm very excited about finally being able to say "Guile does unicode",
> and was wondering what was left to do :)
>
> Andy
OK.
First, here's the stuf
> From: Neil Jerram
>
> make check fails for me in regexp.test:
>
> ...
> Running regexp.test
> guile: uncaught throw to unresolved: ()
>
> because I don't have an en_US.iso88591 locale installed, and so
>
> (with-locale "en_US.iso88591" ...)
>
> throws an 'unresolved exception.
>
M
On Wed, 2009-09-09 at 01:00 +0200, Ludovic Courtès wrote:
> Hello!
>
> "Michael Gran" writes:
>
> > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=0d05ae7c4b1eddf6257f99f44eaf5cb7b11191be
>
> [...]
>
> > - return scm_getc (input_port);
> > + return scm_get_byte_or_eof (input_port);
>
On Wed, 2009-09-09 at 09:42 +0200, Ludovic Courtès wrote:
> Hi,
> >> > - return scm_getc (input_port);
> >> > + return scm_get_byte_or_eof (input_port);
> >>
> >> This is actually an earlier change, but the prototype of scm_getc is now
> >> different from that in 1.8. Presumably, this means tha
Hi-
I guess according to the schedule there is another point release tomorow.
Just a couple of notes.
As it stands, we know the netbsd amd64 build will fail for reasons
discussed in
http://lists.gnu.org/archive/html/guile-devel/2009-08/msg00213.html
Also, the netbsd build will likely fail beca
On Wed, 2009-09-09 at 22:53 +0100, Neil Jerram wrote:
> > It is important. This is one of the problems with the whole Unicode
> > effort. There is no Unicode-capable regex library. The regexp.test
> > tries matching all bytes from 0 to 255, and it uses scm_to_locale_string
> > to prep the string
On Thu, 2009-09-10 at 12:27 +0200, Ludovic Courtès wrote:
> Hello!
>
> I built today’s ‘master’ on a ppc64 box and there are many
> regexp-related errors and a surprisingly high number of unresolved
> regexp-related tests:
>
> http://autobuild.josefsson.org/guile/log-200909100539539848000.txt
>
> From: Neil Jerram
> Mike Gran writes:
> > Here's one that doesn't work as expected.
> >
> > guile> (string-match "[:lower:]" "Hi, mom")
> > ==> #("Hi, mom" (5 . 6))
> > guile> (string-match "[:lower:
On Thu, 2009-09-10 at 17:33 +0200, Ludovic Courtès wrote:
> Do you think it would work to just leave `regexp.test' as it is in 1.8?
It would probably work, but, it offends my sense of aesthetics that the
names of the tests would be displayed in the wrong locale for the
terminal. I'm uploading ye
Hi-
With the default behavior of 1.9.x, REPL debug and backtrace are broken.
Consider the following example run using 'guile --debug' and
(debug-enable 'backtrace).
With 1.8.5
guile> (string-append "abc" (string-append "def" (string-append
On Mon, 2009-09-14 at 00:08 +0200, Ludovic Courtès wrote:
> Hello!
>
> Mike Gran writes:
>
> > ** Ports do transcoding
>
> Speaking of this, would you be willing to implement R6RS’ transcoder
> API in ‘r6rs-ports.c’? :-)
Hard to say. After September, my free ti
> From: Ludovic Courtès
>
> Hi,
>
> Mike Gran writes:
>
> > Also, the netbsd build will likely fail because there is new
> > 'condition is always true' condition in array-handle.c:103
> >
> > 100 SCM
> > 101 scm_array_handle_element
> What is a #y vector? Does anyone know?
From the 1.3.2 changelog
1998-10-18 Mikael Djurfeldt
* unif.c (scm_raprin1): Changed print syntax for byte vectors from
#bytes(...) to #y(...), and syntax for short vectors from
#short(...) to #h(...). This may seem nutty, but, like th
1 - 100 of 290 matches
Mail list logo
