Hi Bruce,
In case you didn't see the other thread here on guile-devel: the bugs
with this error message (and a few others) have been fixed on the
stable-2.0 branch, such that with Guile 2.0.4 the error message would
have been something like this:
/old-home/ROOT/usr/local/share/autogen/aginfo.tp
Hi Andy,
On Sat, Jan 07, 2012 at 01:47:29AM +0100, Andy Wingo wrote:
> Cky! Clearly I should have finished ploughing through guile-devel
> before we had the pleaseure of meeting up last week. Because if I had,
> I would have asked you to deliver two files: srfi-41.scm, and
> srfi-41.test :-)
Wo
* libguile/i18n.c (scm_make_locale): Null out c_locale_name after it's
freed, so it doesn't get freed again. While this only has effect if
USE_GNU_LOCALE_API is unset, the nulling out happens in both cases,
to be consistent and robust.
(scm_nl_langinfo): Free c_result in all switch cases, i
Hi Rob,
“Unused modules are removed” and similar tests seem to depend on the
direction of the wind, unfortunately. So for now you can safely ignore
them, by adding (throw 'unresolved), or commenting them out.
I’m afraid we cannot do much better on our side. :-/
Thanks,
Ludo’.
OK,
I have skiped the usage of structs to store data and just use clever lists
with similar api
as the structs so that syntax information can be pushed down to it. With
this I get a lot of
things working again and the codebase is much cleaner. I no longer do uggly
hack with
the syntax representati
Hi Mark,
Mark H Weaver skribis:
> Perhaps we should simply add this compiler flag where its available, at
> least in the short term. What do you think?
I’ve been thinking about that too, because on some platforms GCC emits
may-break-strict-aliasing-rules warnings, notably on x86_64-freebsd8.2
Hello all,
For many years, Linux (the kernel) has used the -fno-strict-aliasing
compiler option to disable certain tricky optimizations that depend upon
a very strict reading of the aliasing rules of modern C standards. It
turns out that it's quite difficult to write robust code in the presence
o
Replying to myself...
> David Kastrup writes:
>> I am not sure about the strength of the respective dependencies, but let
>> me just say that "universally-unique gensyms" as an idea has a bad ring
>> to me. It makes the output of the compiler non-deterministic. This
>> makes a lot of simple ver
David Kastrup writes:
> I am not sure about the strength of the respective dependencies, but let
> me just say that "universally-unique gensyms" as an idea has a bad ring
> to me. It makes the output of the compiler non-deterministic. This
> makes a lot of simple verification methods (like check
Bruce Korb writes:
>> Ideally, you would also call 'scm_set_port_column_x' here. Otherwise,
>> the column numbers of errors on the first line will not be reported
>> properly.
>
> All I can do is set the first line column to zero.
> I don't track the columns.
In that case, don't bother. The col
Andy Wingo writes:
>> Thirdly, "definition in expression context" is a confusing message for
>> Scheme beginners, who are likely to make this mistake.
>
> The problem is that I'm not sure that the error message you suggest is
> correct. You show:
>
>> (let ((x 1))
>> #f
>> (define blah
On 01/26/12 22:19, Mark H Weaver wrote:
Then either it ought to have printed the location, or there are new
wrinkles in the file/line number stuff that I need to know about.
Your code looks good to me, and should allow source locations to be
properly reported in error messages.
It turns out th
Hi Mark!
Thanks for tracking down this issue. I'm sure it will make it in 2.0.4,
but I do have a couple questions.
On Fri 27 Jan 2012 08:26, Mark H Weaver writes:
> So, what does this fix? The "definition in expression context" error
> message is broken in several ways. First of all, source
13 matches
Mail list logo
