Rob Browning <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> writes:
>
>> 1.8.0 seems to now be pretty old, and a diff of the head of
>> branch_release-1-8 against release_1-8-0 (-Nu) gives 6088 lines, of
>> which 2857 are new (ignorning hierarchy.pdf).
>>
>> The slib bug fix appear
Rob Browning <[EMAIL PROTECTED]> writes:
>
> So far, the only patch I know is going in is one to fix the
> numbers.test failure.
The array-set! breakage on bitvectors is bad too,
* unif.c (bitvector_set): Use h->writable_elements not h->elements.
Greg Troxel <[EMAIL PROTECTED]> writes:
> 1.8.0 seems to now be pretty old, and a diff of the head of
> branch_release-1-8 against release_1-8-0 (-Nu) gives 6088 lines, of
> which 2857 are new (ignorning hierarchy.pdf).
>
> The slib bug fix appears not to be present on the 1.8 branch, but I'm
> no
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> ./devel/guile-gtk
>
> Does any know of any problems with any of them with 1.8?
Version 0.5 of guile-gtk-1.2 works with either 1.6 or 1.8. (The one
you build against has to be the one it runs against of course.)
On 8/10/06, Greg Troxel <[EMAIL PROTECTED]> wrote:
Here's the list of programs that use guile (1.6) in pkgsrc.
./cad/libgeda
./databases/guile-pg
./devel/autogen
Does any know of any problems with any of them with 1.8?
I am trying to iron out "deprecated constructs" in autogen.
The latest r
I'm the maintainer for the guile entry in NetBSD pkgsrc, and am
starting to think about 1.8. pkgsrc currently has
lang/guile14(1.4.1, installed in /usr/pkg/guile/1.4)
lang/guile (1.6.8, installed in /usr/pkg)
The plan would be to copy lang/guile to guile16, and install into
/usr/pkg/g
> But I don't quite follow why a remember would be wanted in
> SCM_VALIDATE_CELL. I'd have thought it was in fact a good thing if
> the "cell" value went dead if not being checked.
Hunh!? This whole thread is about building guile in gcc 4.n on a
64-bit machine. It doesn't build, or run unless
Hi Bill,
I'd like to see the changes you made (keeping in mind your disclaimer
about "rightness").
Thanks,
Jay
On Mar 29, 2006, at 10:12 AM, Bill Schottstaedt wrote:
I just checked Fedora Core 5 with gcc 4.1, and it's broken there in
the
same way as in FC4/gcc 4.0.
(On the Mac socklen_t
I just checked Fedora Core 5 with gcc 4.1, and it's broken there in the
same way as in FC4/gcc 4.0.
(On the Mac socklen_t bug, I can pass along the changes I made, if you
want them -- as I said before, they're not "the right thing").
___
Guile-devel
Hi Neil,
On Tue, 2006-03-28 at 21:56 +0100, Neil Jerram wrote:
> The gcc on this machine is:
>
> [EMAIL PROTECTED]:~/guile-core-1.8-20060328$ gcc --version
> gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
I got different results when using gcc 3.3. Can't remember exactly how
different tho :-/
The gcc I no
Neil Jerram <[EMAIL PROTECTED]> writes:
> I believe the only important 1.8 bug still outstanding is the one
> which causes Scheme data corruption on 64-bit platforms - and which is
> usually enough to cause the build to fail in
> snarf-check-and-output-texi.
Someone has been kind enough to loan m
I believe the only important 1.8 bug still outstanding is the one
which causes Scheme data corruption on 64-bit platforms - and which is
usually enough to cause the build to fail in
snarf-check-and-output-texi.
Is there anything else of equal impact that I've forgotten?
I'm not sure how to procee
I believe the only important 1.8 bug still outstanding is the one
which causes Scheme data corruption on 64-bit platforms - and which is
usually enough to cause the build to fail in
snarf-check-and-output-texi.
Is there anything else of equal impact that I've forgotten?
I'm not sure how to procee
13 matches
Mail list logo
