Build Guile 1.8 with CMake

hi, I'd like to introduce my guile cmake build scripts to you: https://github.com/PikachuHy/guile Its final target is to provide an MSVC-version guile, which is basic work of MSVC-version TeXmacs. At present, you can use my cmake scripts to build guile 1.8 in ubuntu 20.04 and Windows mingw3

Build Guile 1.8 with CMake

hi, I'd like to introduce my guile cmake build scripts to you: https://github.com/PikachuHy/guile Its final target is to provide an MSVC-version guile, which is basic work of MSVC-version TeXmacs. At present, you can use my cmake scripts to build guile 1.8 in ubuntu 20.04 and Windows mi

Build Guile 1.8 with CMake

hi, I'd like to introduce my guile cmake build scripts to you: https://github.com/PikachuHy/guile Its final target is to provide an MSVC-version guile, which is basic work of MSVC-version TeXmacs. At present, you can use my cmake scripts to build guile 1.8 in ubuntu 20.04 and Windows mi

Build Guile 1.8 with CMake

hi, I'd like to introduce my guile cmake build scripts to you: https://github.com/PikachuHy/guile Its final target is to provide an MSVC-version guile, which is basic work of MSVC-version TeXmacs. At present, you can use my cmake scripts to build guile 1.8 in ubuntu 20.04 and Windows mi

Re: Guile 1.8 development

On Wed 01 Mar 2017 13:14, Thien-Thi Nguyen writes: > Which git branch is best for continued Guile 1.8 development? > I know most people have no interest in 1.8, that's fine, just > kindly humor this slow janitor w/ a normative answer, thanks. > > (I guess ‘branch_release-1-8

Guile 1.8 development

Which git branch is best for continued Guile 1.8 development? I know most people have no interest in 1.8, that's fine, just kindly humor this slow janitor w/ a normative answer, thanks. (I guess ‘branch_release-1-8’, but maybe someone knows better.) -- Thien-Thi N

Re: gcc requirements for building guile 1.8.x/1.9.x

Hi, ejm skribis: > What the requirements as to the version of gcc to use in building guile 1.8.x > or 1.9.x ? Guile 1.8 (which is deprecated) and Guile 2.0 require an ANSI C89 compiler. That includes old versions of GCC. Ludo’.

gcc requirements for building guile 1.8.x/1.9.x

Hi All, What the requirements as to the version of gcc to use in building guile 1.8.x or 1.9.x ? Thanks, --Ed

guile-gnome, devel: removes guile-1.8 specific code and dependency

Hello, guile-gnome devel: removes guile-1.8 specific code and dependency Attached, patch review welcome. Happy hacking, David From 681b47b766d0c2235fe396e002fcce5a03c80a17 Mon Sep 17 00:00:00 2001 From: David PIROTTE Date: Tue, 7 Oct 2014 19:48:33 -0300 Subject

Re: 1.8 ‘send’ bug + re-engagement

.8.9, i plan to: > - audit libguile for this (writable/read-only string) class of bug > - add tests > - back/forward-port tests > - back/forward-port docs Great. > Further 1.8 releases will be similar, the goal being to transition from > point-fixes to systemic improvements. On

Re: 1.8 ‘send’ bug + re-engagement

writable/read-only string) class of bug - add tests - back/forward-port tests - back/forward-port docs Further 1.8 releases will be similar, the goal being to transition from point-fixes to systemic improvements. On the side, i plan to improve the build environment (makefiles / configure.ac / doc-m

Re: 1.8 ‘send’ bug + re-engagement

Hi, Mike Gran skribis: > The big issues with moving to 2.0 that I've seen expressed are > non-portability, I don’t think 2.0 is less portable than 1.8; there’s room for improvement (MinGW, pthread support), but it’s not a disaster either. > number of dependencies, There’s ar

Re: 1.8 ‘send’ bug + re-engagement

> > Hmm, I’d find it more important to help fix any issues that prevent > current 1.8 users from switching to 2.0, FWIW. The big issues with moving to 2.0 that I've seen expressed are non-portability, number of dependencies, API churn, and general dislike of pkg-config.  Since some of t

Re: 1.8 ‘send’ bug + re-engagement

Hi Thien-Thi! Thien-Thi Nguyen skribis: > Looking to move WIKID[0] out of the Guile 1.4.x ghetto (which is pretty > cozy, i must say), (Speaking of which, do let me know when rpx has left the ghetto, too. :-)) > i ran into a Guile 1.8 problem. Apparently, ‘send’ gratuitously >

1.8 ‘send’ bug + re-engagement

Looking to move WIKID[0] out of the Guile 1.4.x ghetto (which is pretty cozy, i must say), i ran into a Guile 1.8 problem. Apparently, ‘send’ gratuitously demands its MESSAGE arg (a string) be writable. This loses if, e.g., MESSAGE is the result of ‘symbol->string’. Here is the fix: libgu

Re: Do we have a guile-1.8 branch?

On Thu 03 May 2012 00:04, Noah Lavine writes: >> Yes, please remove the ‘release-1.8’ branch. >> >> Something like ‘git push origin :release-1.8’ should work (search for >> “delete” in git-push(1).) >> >> Thanks, >> Ludo’. > > Oh, I never knew ho

Re: Do we have a guile-1.8 branch?

> Yes, please remove the ‘release-1.8’ branch. > > Something like ‘git push origin :release-1.8’ should work (search for > “delete” in git-push(1).) > > Thanks, > Ludo’. Oh, I never knew how to do that. It's done now. Thanks, Noah

Re: Do we have a guile-1.8 branch?

Hi Noah, Noah Lavine skribis: > Yes, I was just wondering if that was the right place to send Guile > 1.8 bugfixes. I went ahead and committed two new fixes to that branch. > They both fix build errors on my system. Good. > Unfortunately, I also made a new branch in our repos

Re: Do we have a guile-1.8 branch?

Yes, I was just wondering if that was the right place to send Guile 1.8 bugfixes. I went ahead and committed two new fixes to that branch. They both fix build errors on my system. Unfortunately, I also made a new branch in our repository called 'release-1.8' because of a git error. It i

Re: Do we have a guile-1.8 branch?

Thien-Thi Nguyen wrote: > () Noah Lavine > () Tue, 1 May 2012 17:15:28 -0400 > >And if not, would we like one? > > It would be great to have one. Yeah, there is one: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=shortlog;h=refs/heads/branch_release-1-8 I suspect that Andy mer

Re: Do we have a guile-1.8 branch?

() Noah Lavine () Tue, 1 May 2012 17:15:28 -0400 And if not, would we like one? It would be great to have one.

Do we have a guile-1.8 branch?

Hello, I was just trying to build guile 1.8 (as part of a project to track down missing documentation, which I will email about), and I found a bug. As it happens, Andy Wingo fixed that bug in this email from 2010: http://lists.gnu.org/archive/html/guile-devel/2010-03/msg00082.html However, I

Re: 1.8 release?

Hello! Andy Wingo writes: > Do you have time to roll a 1.8.8 release? It would be really great to > fix those build errors due to new ltdl and gcc. Yes, I’ll look into it within the next couple of weeks. > NEWS appears mostly up to date, though a crawl through the commit logs > yields some tha

1.8 release?

Hi Ludovic, Do you have time to roll a 1.8.8 release? It would be really great to fix those build errors due to new ltdl and gcc. NEWS appears mostly up to date, though a crawl through the commit logs yields some that are not yet noted. FWIW, I'm currently working on getting recent 1.9.x additio

Re: guile-1.8 question

2009/10/15 Andy Wingo : > The ports C interface is rather crufty, as you have found :) Do you have > any suggestions, or a patch? Keep in mind that we need to maintain > backwards compatibility with these interfaces. What do you think about documented additional function like this? -- SCM scm_c_fd

Re: guile-1.8 question

On Wed 14 Oct 2009 09:33, Stanislav Ievlev writes: > 2009/10/14 Stanislav Ievlev : >> As I understand you should mark scm_fdes_to_port as a deprecated and >> don't use it in own code (e.g. in socket.c). > Ooops, I'm wrong. > scm_fdes_to_port works is like "scm_C_fdopen", however function name > i

Re: guile-1.8 question

2009/10/14 Stanislav Ievlev : > As I understand you should mark scm_fdes_to_port as a deprecated and > don't use it in own code (e.g. in socket.c). Ooops, I'm wrong. scm_fdes_to_port works is like "scm_C_fdopen", however function name is not good ;)

Re: guile-1.8 question

As I understand you should mark scm_fdes_to_port as a deprecated and don't use it in own code (e.g. in socket.c). 2009/10/14 Stanislav Ievlev : > Greetings! > > There are several functions exists to convert file descriptor into guile port: > * scm_fdes_to_ports - search for fdes in already opened

guile-1.8 question

Greetings! There are several functions exists to convert file descriptor into guile port: * scm_fdes_to_ports - search for fdes in already opened ports * scm_fdes_to_port - looks like internal function, not documented, but exists in header files. * scm_fdopen - looks like public function. What is

Re: Removing memoizers from the 1.8 public API?

Hi Neil, Neil Jerram writes: > If the temptation is strong, though, I'd add that > > - 4d0949 looks safe. It's arguably just a bug that these functions > were ever exposed, and I don't think that anyone will actually have > found them useful outside libguile. Agreed. I'll eventually commi

Re: Removing memoizers from the 1.8 public API?

l...@gnu.org (Ludovic Courtès) writes: > Hello! > > I'm tempted to apply these two patches to 1.8: > > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=4d0949ea45c46dd13e767a8a3342d02caef1b483 > > http://git.savannah.gnu.

Removing memoizers from the 1.8 public API?

Hello! I'm tempted to apply these two patches to 1.8: http://git.savannah.gnu.org/cgit/guile.git/commit/?id=4d0949ea45c46dd13e767a8a3342d02caef1b483 http://git.savannah.gnu.org/cgit/guile.git/commit/?id=b3ce13b667634be30ab2d74b8ccb1de190d7aeeb It cleans the name space and potent

Re: 1.8 branch test failure

Barry Fishman writes: > The same thing happens with Ubuntu Jaunty. I Don't think it is Guile > failing. It the test that caused problems: > > (open-input-pipe "read && echo $REPLY") > > In Ubuntu and NetBSD, Bash is not the default shell, so "read" requires > an argument. From the /bin/sh s

Re: 1.8 branch test failure

Neil Jerram writes: > Greg Troxel writes: > >> Git tree... release_1-8-6-53-g66f3b6c >> GCC version... gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb1 20080202) >> Differences: >> End differnces. >> >> [snip] >> >> FAIL: popen.test: open-input-pipe: open-input-pipe process gets >> (current-inpu

Re: 1.8 branch test failure

Neil Jerram writes: > Greg Troxel writes: > >> Git tree... release_1-8-6-53-g66f3b6c >> GCC version... gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb1 20080202) >> Differences: >> End differnces. >> >> [snip] >> >> FAIL: popen.test: open-input-pipe: open-input-pipe process gets >> (current-inpu

Re: 1.8 branch test failure

Greg Troxel writes: > Git tree... release_1-8-6-53-g66f3b6c > GCC version... gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb1 20080202) > Differences: > End differnces. > > [snip] > > FAIL: popen.test: open-input-pipe: open-input-pipe process gets > (current-input-port) as stdin That looks to be

1.8 branch test failure

Git tree... release_1-8-6-53-g66f3b6c GCC version... gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb1 20080202) Differences: End differnces. [snip] FAIL: popen.test: open-input-pipe: open-input-pipe process gets (current-input-port) as stdin [snip] Totals for this test run: passes:

Re: 1.8 autobuild fails

Greg Troxel writes: > +#if HAVE_SYS_TYPES_H > +# include > +#endif Thanks, this should be fixed now. Ludo'.

Re: 1.8 autobuild fails

Yes, it's new. Git tree... release_1-8-6-44-ge9c9fd3 This is my 1.8 branch autobuild: http://autobuild.josefsson.org/guile/log-200905090633244263000.txt And yes, including sys/types.h fixes this. At least on BSD, one generally needs to include sys/types.h before random header fil

Re: 1.8 autobuild fails

Greg Troxel writes: > This fails in test-round.c. It's likely like "foo.h needs sys/types.h" > but I haven't looked yet - just wanted to point it out. > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/pkg/include > -I../../test-suite/standalone -I../.. -I../.. -I/usr/pkg/include -pthread -g > -O

Re: 1.8 autobuild fails

round.c:30: > /usr/include/machine/fpu.h:14: error: expected specifier-qualifier-list > before 'uint16_t' > /usr/include/machine/fpu.h:30: error: expected specifier-qualifier-list > before 'uint16_t' > gmake[4]: *** [test_round-test-round.o] Error 1 > gmake[4]: Lea

1.8 autobuild fails

r-qualifier-list before 'uint16_t' /usr/include/machine/fpu.h:30: error: expected specifier-qualifier-list before 'uint16_t' gmake[4]: *** [test_round-test-round.o] Error 1 gmake[4]: Leaving directory `/home/gdt/BUILD-GUILE-1.8/guile/test-suite/standalone' pgpT0mxvO31cE.pgp Description: PGP signature

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Good morning! Hello again! >> Just one nit: I think there's now only 1 piece of Automake magic being >> relied on, so you could update that text (in Makefile.am) and remove >> the "2. ". > > Right, I did this: > > > http://git.savannah.gnu.org/cgit/gui

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Hi Greg, > > Greg Troxel writes: > >> I don't think that's true at all. It could be that for running Linux on >> arm pdas that's what most people do, but for the far more general case >> there is normal cross compiling as autoconf has supported for years

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

Hi Greg, Greg Troxel writes: > I don't think that's true at all. It could be that for running Linux on > arm pdas that's what most people do, but for the far more general case > there is normal cross compiling as autoconf has supported for years. > > I am working on a project that does cross bu

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Hmm, right. OTOH, my impression was that tools like Scratchbox had > taken the world over, meaning that cross-compilation usually takes place > as "native" compilation in an emulated target environment. I don't think that's true at all. It could be that

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

Good morning! Neil Jerram writes: > l...@gnu.org (Ludovic Courtès) writes: >> Maybe we could detect in `configure' whether we are >> cross-compiling and conditionalize build of >> `stack-limit-calibration.scm' on that? > > No, that sounds too tricky. I'm persuaded now that your change is > goo

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Hi Neil, Hi again! > Neil Jerram writes: > >> I'm not sure about moving stack-limit-calibration.scm from TESTS to >> BUILT_SOURCES. The point of putting it in TESTS was to help with >> cross-compiling. When cross-compiling, my understanding is that >>

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

Hi Neil, Neil Jerram writes: > I'm not sure about moving stack-limit-calibration.scm from TESTS to > BUILT_SOURCES. The point of putting it in TESTS was to help with > cross-compiling. When cross-compiling, my understanding is that > `make' should be run in a build host environment, and `make

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > The good news is that `master' also builds and tests fine on this > platform with these two patches: Indeed. Following the fixes that we did for MacOS earlier in the 1.8.x series, it's good to know that something else hasn't re

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

The good news is that `master' also builds and tests fine on this platform with these two patches: http://git.savannah.gnu.org/cgit/guile.git/commit/?id=6cc323e2ff4e555d58e115032016a50ef15a1948 http://git.savannah.gnu.org/cgit/guile.git/commit/?id=7ca96180f00800414a9cf855e5ca4dceb9baca07

Guile 1.8 success on `i386-apple-darwin9.6.0'

Hello, For the record, I successfully tested a recent `branch_release-1-8' snapshot on `i386-apple-darwin9.6.0' (Mac OS X "Leopard"). The only quirk was the linker complaining when creating libguile: libtool: link: gcc -dynamiclib -o .libs/libguile.17.dylib .libs/libguile_la-alist.o .libs/l

Fwd: guile-1.8 1.8.5+1-4 MIGRATED to testing

2008/8/31 Subject: guile-1.8 1.8.5+1-4 MIGRATED to testing To: [EMAIL PROTECTED] FYI: The status of the guile-1.8 source package in Debian's testing distribution has changed. Previous version: 1.8.4+1-2 Current version: 1.8.5+1-4 -- This email is automatically generated; the Debian R

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

Hi, "Neil Jerram" <[EMAIL PROTECTED]> writes: > Another possibility (which came from talking to Stepan Kasal) is that > the code is failing because aux is being inlined. To avoid this, we > can use instead the find_stack_direction code from Autoconf and > Gnulib, in which find_stack_direction ca

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

2008/5/31 Neil Jerram <[EMAIL PROTECTED]>: > 2008/5/29 Thiemo Seufer <[EMAIL PROTECTED]>: >> Neil Jerram wrote: >>> 2008/5/28 Thiemo Seufer <[EMAIL PROTECTED]>: >>> > >>> > After a closer look I believe the logic of the test is just plain wrong: >>> > >>> > aux (l) unsigned long l; >>> > { int x; e

Re: Fwd: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

or have you regenerated > it? If the latter, the bug could be being introduced by different > versions of the autotools than the ones we used upstream. > > I wish I could reproduce this myself, so I could investigate in > detail! I've downloaded the Debian package source (for > g

Fwd: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Forwarding this to guile-devel, without the 13M attachment.] -- Forwarded message -- From: Neil Jerram <[EMAIL PROTECTED]> Date: 2008/5/31 Subject: Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures) To: Thiemo Seufer <[EMAIL PROTECTED]> Cc: [EMAIL PROTE

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

Neil Jerram wrote: > 2008/5/28 Thiemo Seufer <[EMAIL PROTECTED]>: > > > > After a closer look I believe the logic of the test is just plain wrong: > > > > aux (l) unsigned long l; > > { int x; exit (l >= ((unsigned long)&x)); } > > main () { int q; aux((unsigned long)&q); }, > > > > The test return

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

Neil Jerram wrote: > 2008/5/24 Thiemo Seufer <[EMAIL PROTECTED]>: > > > Neil Jerram wrote: > > > > > > I believe those definitions came from the Boehm GC library. Do you > > happen > > > to know whether similar improvements have already been applied to Boehm > > GC? > > > > The development versio

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

2008/5/28 Thiemo Seufer <[EMAIL PROTECTED]>: > > After a closer look I believe the logic of the test is just plain wrong: > > aux (l) unsigned long l; > { int x; exit (l >= ((unsigned long)&x)); } > main () { int q; aux((unsigned long)&q); }, > > The test returns true for a downward-growing stack,

Re: guile-1.8 and goops c-api

Sorry to reply to myself but I detected the problem. My code is correct and working as expected but scm_add_slot() will segfault anyways because of bug #22369. I checked it agianst the present cvs head and it still an issue. Applying the supplied patch fixes the problem. In existing code the same

guile-1.8 and goops c-api

Hi, I'm sending out an SOS to the guile-devel list! Is there anybody out there able to provide me with a decent, working example on how to export a goops-class using guile-1.8 c-api _only_?? I tried really hard over the past two days and neither have I found any working code nor could I g

Re: Guile 1.8 GC issues

2007/10/25, Ludovic Courtès <[EMAIL PROTECTED]>: > * The "minyield" grows too fast. This is a consequence of > `scm_iadjust_minyield ()' seeing too little collected cells. > Actually, the "big" increase of "minyield" (visible on my graphs) > occurs when it sees zero collected cells.

Re: cell heap usage in 1.8 vs 1.6

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > * the heap gets more and more underutilized, although it seems to > eventually stabilize somewhere around 5% (!) utilization (i.e., > total/alive = 20); The main reason appears to be that the size of individual segments grows exponentia

Re: cell heap usage in 1.8 vs 1.6

ind that currently heap is never reclaimed, so its total size can only increase. Likewise, "min yield" can only increase, as its typically a fraction (40% by default) of the total heap size. Strangely enough, with 1.8, `alive-cell-heap' remains exactly constant until iteration

Re: cell heap usage in 1.8 vs 1.6

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > I'm having trouble in my charting program with the amount of heap space > allocated for cells in 1.8. It ends up allocating more and more heap > (as reported by gc-stats 'cell-heap-segments and confirmed by > mallinfo(

Re: cell heap usage in 1.8 vs 1.6

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Ludovic Courtès) writes: >> Hopefully removal of globals made it slightly simpler to follow... > > No, that's made it harder to see what actually changed. I was referring to the code, not to the dif

Re: cell heap usage in 1.8 vs 1.6

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > As good as 1.6? Total space is bigger, but at least it doesn't grow unboundedly. > Hopefully removal of globals made it slightly simpler to follow... No, that's made it harder to see what actually changed. I suppose a block copy of the changes wit

Re: cell heap usage in 1.8 vs 1.6

Hey, Kevin Ryde <[EMAIL PROTECTED]> writes: > Ah yes, it's better there. As good as 1.6? > What bit is the operative fix? I couldn't find exactly. The ChangeLog entry on 2006-01-04 gives some hints about functions to look at. There's also this post: http://lists.gnu.org/archive/html/guile-de

Re: cell heap usage in 1.8 vs 1.6

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > Did you try running it with HEAD? There were small GC-stats "cleanups" > committed there that are not in 1.8, so it may be worth trying. Ah yes, it's better there. What bit is the operative fix? Both the per-freelist

Re: what am I doing wrong building 1.8?

Hi, "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > Complete output can be found at: > > > What's that: open("/usr/lib/libsandbox.so", O_RDONLY) = 3 Doesn't it somehow virtua

Re: what am I doing wrong building 1.8?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ludovic � wrote: > Hi, > > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > >> Ludovic � wrote: > >>> Strange. I use the exact same version of `gnulib-tool' here and it >>> finds it without any problem. Does "test -f configure.in" return tr

Re: what am I doing wrong building 1.8?

Hi, "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > Ludovic � wrote: >> Strange. I use the exact same version of `gnulib-tool' here and it >> finds it without any problem. Does "test -f configure.in" return true? > > Yes, it does. Then I'm clueless. Can you somehow trace what `gnulib

Re: cell heap usage in 1.8 vs 1.6

Hi Kevin, Kevin Ryde <[EMAIL PROTECTED]> writes: > I'm having trouble in my charting program with the amount of heap space > allocated for cells in 1.8. It ends up allocating more and more heap > (as reported by gc-stats 'cell-heap-segments and confirmed by > mal

Re: what am I doing wrong building 1.8?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ludovic � wrote: >>> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: >>> + gnulib-tool --update gnulib-tool: *** cannot find ./configure.ac gnulib-tool: *** Stop. >>> Normally, it should find `configure.in' (at least it does here).

Re: what am I doing wrong building 1.8?

Hi, "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > Ludovic � wrote: >> Hi, >> >> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: >> >>> + gnulib-tool --update >>> gnulib-tool: *** cannot find ./configure.ac >>> gnulib-tool: *** Stop. >> >> Normally, it should find `configure.in' (a

Re: what am I doing wrong building 1.8?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ludovic � wrote: > Hi, > > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > >> + gnulib-tool --update >> gnulib-tool: *** cannot find ./configure.ac >> gnulib-tool: *** Stop. > > Normally, it should find `configure.in' (at least it does here).

Re: what am I doing wrong building 1.8?

Hi, "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> writes: > + gnulib-tool --update > gnulib-tool: *** cannot find ./configure.ac > gnulib-tool: *** Stop. Normally, it should find `configure.in' (at least it does here). Are you running `autogen.sh' out-of-source-directory or something like that?

Re: what am I doing wrong building 1.8?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In a similar vein, autogen.sh complains about a missing configure.ac when trying to build head: + set -e + '[' -f GUILE-VERSION ']' + echo '' + autoconf --version autoconf (GNU Autoconf) 2.61 Copyright (C) 2006 Free Software Foundation, Inc. This is

cell heap usage in 1.8 vs 1.6

I'm having trouble in my charting program with the amount of heap space allocated for cells in 1.8. It ends up allocating more and more heap (as reported by gc-stats 'cell-heap-segments and confirmed by mallinfo()), apparently without bound. I've got between 150k and 200k objects

Re: what am I doing wrong building 1.8?

Hi Neil, Neil Jerram <[EMAIL PROTECTED]> writes: > I looked into this area a few months ago. To be honest, I can't > remember the details clearly now, but does either of the following > help? > > http://www.nabble.com/Patch-to-fix-working-of-autogen.sh-tf3130537.html#a8836699 > http://www.nabble

Re: what am I doing wrong building 1.8?

[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > [EMAIL PROTECTED] (Ludovic Courtès) writes: > >> Apparently, it's Automake's responsibility to install `config.rpath'. >> Why this doesn't happen is a mystery to me. I'll try to investigate >> that later on. > > Actually, it's gettextize/autop

Re: what am I doing wrong building 1.8?

Hi Ludovic, [EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > Andy Wingo <[EMAIL PROTECTED]> writes: > >> If I pass --enable-maintainer-mode to configure this problem goes away, >> and the build completes. Is this expected? > > I think so, because people building from the tarball get a usable

Re: what am I doing wrong building 1.8?

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > Apparently, it's Automake's responsibility to install `config.rpath'. > Why this doesn't happen is a mystery to me. I'll try to investigate > that later on. Actually, it's gettextize/autopoint's job, so that file is supposed to be installed "onc

Re: what am I doing wrong building 1.8?

Hi Andy, Andy Wingo <[EMAIL PROTECTED]> writes: > I can get things to work again if I copy ./config.rpath into build-aux/. > A bug, perhaps? Maybe (I'm feeling a bit ashamed too since I'm the guilty party ;-)). Apparently, it's Automake's responsibility to install `config.rpath'. Why this doesn

Re: what am I doing wrong building 1.8?

Hi, Andy Wingo <[EMAIL PROTECTED]> writes: > If I pass --enable-maintainer-mode to configure this problem goes away, > and the build completes. Is this expected? I think so, because people building from the tarball get a usable `.info' file and (presumably) `version.texi' as well (in case they w

Re: what am I doing wrong building 1.8?

A followup problem: [Should these go to bug-guile or something?] make[3]: Entering directory `/home/wingo/src/guile-1.8/doc/ref' GUILE="/home/wingo/src/guile-1.8/pre-inst-guile" ../../scripts/snarf-guile-m4-docs ../../guile-config/guile.m4 > ./autoconf-macro

what am I doing wrong building 1.8?

Hello hackers! What am I doing wrong when building guile from the 1.8 branch? I'm a bit ashamed to write, but this doesn't seem normal, and I've seen the same on head: cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/guile \ co -r branch_release-1-8 -d guile-1.8 g

Re: slowness in guile 1.8

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > For 1.8, I'm pretty much inclined to commit a similar patch, i.e., where > `module-make-local-var!' and `scm_m_define' are copied from HEAD. This > would break code that does things like: > > (define foo (begin (s

Re: slowness in guile 1.8

Hi, On Sat, 2007-05-26 at 16:45 +0200, Ludovic Courtès wrote: > I committed the patch below to HEAD. Great! > For 1.8, I'm pretty much inclined to commit a similar patch, i.e., where > `module-make-local-var!' and `scm_m_define' are copied from HEAD. This > would

Re: slowness in guile 1.8

pression evaluation and `scm_sym2var' in `scm_m_define ()' (which is concerned only with top-level defines), thereby fixing the `(define round round)' case. At the same time, it breaks the aforementioned test from `syntax.test', but there's nothing wrong with that. For 1.

Re: slowness in guile 1.8

Hi Andy! Andy Wingo <[EMAIL PROTECTED]> writes: > On Fri, 2007-05-25 at 20:12 +0200, Ludovic Courtès wrote: >> Alas, it breaks the following test in `syntax.test': > > I'm not sure what "it" is in this case; I assume you mean the fix to > module-make-local-var!. "It" means "the reordering of `ev

Re: slowness in guile 1.8

Replying to myself, On Sat, 2007-05-26 at 12:49 +0200, Andy Wingo wrote: > On Fri, 2007-05-25 at 20:12 +0200, Ludovic Courtès wrote: > > (pass-if "binding is created before expression is evaluated" > > (= (eval '(begin > > (define foo > > (begin > >

Re: slowness in guile 1.8

Hey Ludovic, Thanks for looking at this! On Fri, 2007-05-25 at 20:12 +0200, Ludovic Courtès wrote: > Alas, it breaks the following test in `syntax.test': I'm not sure what "it" is in this case; I assume you mean the fix to module-make-local-var!. > (pass-if "binding is created before expressi

Re: slowness in guile 1.8

etrec' (Section 5.2.2); top-level defines should behave similarly for new variables (Section 5.2.1). For top-level defines as in `(define round round)', the rule is that `define' is equivalent to `set!' when the variable is already bound (Section 5.2.1). This justifies the change mad

slowness in guile 1.8

Hello guile devs, I am doing some profiling with guile-gnome and guile 1.8. It is significantly slower than 1.6. One reason in guile-gnome is the thinking behind e.g. this change from 2004: 2004-12-22 Marius Vollmer <[EMAIL PROTECTED]> * boot-9.scm (module-make-local-var!)

Re: another merge from 1.8

Kevin Ryde <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: >> >> Anyway, does the 1.8 ChangeLog look OK now? > > Yes, but I think I changed my mind about putting it in at the orginal > date. That might make it look like it was in 1.8.0 o

Re: another merge from 1.8

Neil Jerram <[EMAIL PROTECTED]> writes: > > Anyway, does the 1.8 ChangeLog look OK now? Yes, but I think I changed my mind about putting it in at the orginal date. That might make it look like it was in 1.8.0 or 1.8.1 (which it wasn't of course). Would you like to move it up

Re: another merge from 1.8

Kevin Ryde <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: >> >> I also had to specify a new encoding for the 1.8 ChangeLogs, > > Is that when you let emacs do a merge or update? The same happened to > me and it offered some strange diffs

Re: another merge from 1.8

fo about when the > change was actually added to the target branch. Shouldn't matter, usually, hopefully. > (Merged from CVS HEAD on 2007-01-28.) Sounds fine for a back-merge like this (I wouldn't see a need in a forward merge though). > I also had to specify a new encod

  1   2   >