Guile 1.5.8 beta available for testing.

Guile 1.5.8 beta available for testing.

[Rob Browning]

We are pleased to annouce the availability of Guile 1.5.8 for testing.
Please report problems to guile-devel@gnu.org or bug-guile@gnu.org.

Note that the 1.5.X series is a BETA series, intended only for
testing, so please don't put it into a distribution or anything
similar.

This release is only a minor update from 1.5.7 -- guile-snarf has
been changed to not require the input file to be the first argument
after the optional -o.  Apparently this was breaking too many other
programs.  Since this update was so minor, Marius and I agreed that
the release date should remain unchanged.  So unless any release
critical bugs bugs are found beforehand, the first 1.6 stable
version, 1.6.1, will be released on or after this weekend.

You can find the beta release here:

  ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/

If you're interested in testing, please try as much of the following
as is convenient:

        - Unset GUILE_LOAD_PATH.

        - Remove automake and autoconf from your path, or turn off
          their execute bits, or something.  (Users must be able to
          build from the tarfile without installing those tools.)  As
          an example, you could disable the tools during the test like
          so:

            mkdir /tmp/stub
            cat > /tmp/stub/do-nothing <<EOF
            #!/bin/sh
            echo warning: $0 called
            sleep 10
            exit 0
            EOF
            chmod +x /tmp/stub/do-nothing
            ln /tmp/stub/do-nothing /tmp/stub/automake
            ln /tmp/stub/do-nothing /tmp/stub/autoconf	# etc
            PATH=/tmp/stub:$PATH

        - Configure, "make", "make check", and "make install".  Make
          sure to remove your previous install tree before the "make
          install".

        - Make sure LD_LIBRARY_PATH doesn't include anything
          unnecessary -- though at the moment it (or
          LTDL_LIBRARY_PATH) will need to include guile's lib
          directory if that directory is not already in the normal
          places libltdl looks.

        - Run the test suite on the installed version.
            ./check-guile -i [INSTALL_PATH]/bin/guile

        - Look at the install tree (with "find | sort" or similar) and
          make sure nothing seems obviously amiss.

        - Make sure readline works.

        - You might try the example code in the doc directory.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Rob Browning <rlb@defaultvalue.org> wrote:
: We are pleased to annouce the availability of Guile 1.5.8 for testing.
: Please report problems to guile-devel@gnu.org or bug-guile@gnu.org.
: 
: Note that the 1.5.X series is a BETA series, intended only for
: testing, so please don't put it into a distribution or anything
: similar.
: 
: This release is only a minor update from 1.5.7 -- guile-snarf has
: been changed to not require the input file to be the first argument
: after the optional -o.  Apparently this was breaking too many other
: programs.  Since this update was so minor, Marius and I agreed that
: the release date should remain unchanged.  So unless any release
: critical bugs bugs are found beforehand, the first 1.6 stable
: version, 1.6.1, will be released on or after this weekend.

I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6
was released.

  Lars J


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

Hi all.

Some notes from a Linux build:

gcc32 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./.. -I../libltdl -g -O2 -Wall -Wmissing-prototypes -c numbers.c -MT numbers.lo -MD -MP -MF .deps/numbers.TPlo  -fPIC -DPIC -o .libs/numbers.lo
In file included from numbers.c:4277:
../libguile/num2integral.i.c: In function `scm_short2num':
../libguile/num2integral.i.c:91: warning: comparison is always true due to limited range of data type
In file included from numbers.c:4285:
../libguile/num2integral.i.c: In function `scm_num2ushort':
../libguile/num2integral.i.c:64: warning: comparison is always true due to limited range of data type
I think I reported this before for another gcc version.

Application tests:
1. correctness: seems to be o.k.
   (can not finish these tests because Scheme processes that
   normally stay around 200MB grow and grow under Guile to over 1GB)
2. speed: around 40 times slower than compiled bigloo
   -> o.k. for Guile objectives
3. process size: see 1.
   -> I could need helpful hints here.

Greetings
Sven


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Sven Hartrumpf <Sven.Hartrumpf@FernUni-Hagen.de> writes:

> 1. correctness: seems to be o.k.
>    (can not finish these tests because Scheme processes that
>    normally stay around 200MB grow and grow under Guile to over 1GB)

Can you give details?  I.e., what processes show this behaviour.  What
was the last version that worked correctly?  How did you configure
Guile?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 28 Aug 2002 16:21:24 +0200, Marius Vollmer <mvo@zagadka.ping.de> wrote: 
> > 1. correctness: seems to be o.k.
> >    (can not finish these tests because Scheme processes that
> >    normally stay around 200MB grow and grow under Guile to over 1GB)
> 
> Can you give details?

Hope so.

> I.e., what processes show this behaviour.

A medium-sized program doing lots of symbol, string, and list construction.
Really GC-intensive programs (around 30% of runtime with bigloo).

> What was the last version that worked correctly?

None. By "normally stay around 200MB" I meant other Scheme implementations
not a former version of Guile.

> How did you configure Guile?

standard way:
./configure # anything better here?
make
make check
make install

Before I started my program, I activated readline support and did this:
guile> (debug-disable 'debug) ; anything better here?
(show-file-name #t stack 0 depth 20 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap)
guile>

Greetings
Sven


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Sven Hartrumpf <Sven.Hartrumpf@FernUni-Hagen.de> writes:

> > I.e., what processes show this behaviour.
> 
> A medium-sized program doing lots of symbol, string, and list construction.
> Really GC-intensive programs (around 30% of runtime with bigloo).

Is that program available somewhere so that we can try it ourselves?

Looks like a good test case for the GC and maybe we can find a way to
better tune ours.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lynn Winebarger]

On Wednesday 28 August 2002 10:34, Marius Vollmer wrote:
> Sven Hartrumpf <Sven.Hartrumpf@FernUni-Hagen.de> writes:
> 
> > > I.e., what processes show this behaviour.
> > 
> > A medium-sized program doing lots of symbol, string, and list construction.
> > Really GC-intensive programs (around 30% of runtime with bigloo).
> 
> Is that program available somewhere so that we can try it ourselves?
> 
> Looks like a good test case for the GC and maybe we can find a way to
> better tune ours.

      It would be good to know how it behaves with scm, as a point of reference.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

"Lars J. Aas" <larsa@sim.no> writes:

> I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
> fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6 was
> released.

I'm not yet satisfied with the analysis.  As far as I can see, the
problem lies not with SCM_LONG_BIT being unsigned incorrectly, but
with SCM_MOST_POSITIVE_FIXNUM being unsigned incorrectly.

We compute SCM_MOST_POSITIVE_FIXNUM like this

  ((((scm_t_signed_bits) 1) << (SCM_I_FIXNUM_BIT - 1)) - 1)

where SCM_I_FIXNUM_BIT is unsigned when SCM_LONG_BIT is.  However, the
type of the result of a bit-shift operator is that of the promoted
left operand (6.5.7;3 in the ANSI C standard).  So
SCM_MOST_POSITIVE_FIXNUM is signed since scm_t_signed_bits is.

Your compiler seems to get this wrong, right?

A fix would be to move the scm_t_signed_bits cast one level up, and
also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
deriding comment about MS on the code.  OK?

Is that the only issue holding off a plain build of 1.5.8 with the
Microsoft compiler?  If there are others, we shouldn't bother to work
around this particular bug in the release.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Han-Wen Nienhuys]

Sven.Hartrumpf@FernUni-Hagen.de writes:
> > I.e., what processes show this behaviour.
> 
> A medium-sized program doing lots of symbol, string, and list construction.
> Really GC-intensive programs (around 30% of runtime with bigloo).

The synthetic benchmark I use for GC testing spends at 25% an
artificially high amount of time in GC -- Yours is Real Life and takes
30% GC time?

Could you test what happens with current CVS GUILE? I revised the GC
part of GUILE, and wonder how it compares to both 1.6 and other
packages. Do you have any specifics regarding the GC of Bigloo? (Is it
Boehm, generational, conservative?)

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 28 Aug 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> Could you test what happens with current CVS GUILE? I revised the GC
> part of GUILE, and wonder how it compares to both 1.6 and other
> packages.

Will take some days.

> Do you have any specifics regarding the GC of Bigloo? (Is it
> Boehm, generational, conservative?)

Boehm, version 6.1


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Han-Wen Nienhuys]

Sven.Hartrumpf@FernUni-Hagen.de writes:
> On 28 Aug 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> > Could you test what happens with current CVS GUILE? I revised the GC
> > part of GUILE, and wonder how it compares to both 1.6 and other
> > packages.
> 
> Will take some days.

OK. Do check the output of (gc-stats) - it often gives a hint to
what's happening.

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
: "Lars J. Aas" <larsa@sim.no> writes:
: > I'd appreciate it if the SCM_POSFIXABLE() bug, steming from the
: > fallback SCM_LONG_BIT define in __scm.h, was fixed before 1.6 was
: > released.
: 
: I'm not yet satisfied with the analysis.  As far as I can see, the
: problem lies not with SCM_LONG_BIT being unsigned incorrectly, but
: with SCM_MOST_POSITIVE_FIXNUM being unsigned incorrectly.
: 
: We compute SCM_MOST_POSITIVE_FIXNUM like this
: 
:   ((((scm_t_signed_bits) 1) << (SCM_I_FIXNUM_BIT - 1)) - 1)
: 
: where SCM_I_FIXNUM_BIT is unsigned when SCM_LONG_BIT is.  However, the
: type of the result of a bit-shift operator is that of the promoted
: left operand (6.5.7;3 in the ANSI C standard).  So
: SCM_MOST_POSITIVE_FIXNUM is signed since scm_t_signed_bits is.
: 
: Your compiler seems to get this wrong, right?
: 
: A fix would be to move the scm_t_signed_bits cast one level up, and
: also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
: deriding comment about MS on the code.  OK?

Sounds reasonable.

This works:

#define SCM_MOST_POSITIVE_FIXNUM \
  (((scm_t_signed_bits) (1 << (SCM_I_FIXNUM_BIT - 1))) - 1)

compiler version info for comment:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86

: Is that the only issue holding off a plain build of 1.5.8 with the
: Microsoft compiler?

Nope.  The msvc compiler needs to follow the __MINGW32__ path most of
the time, so I had to update most of those #if conditionals.  There
are some issues with opendir()/readdir()/closedir(), so I had to disable
those bindings.  I also disabled all the compiled srfis (4, 13&14?).

: If there are others, we shouldn't bother to work
: around this particular bug in the release.

OK.

  Lars J


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[tomas]

On Mon, Aug 26, 2002 at 12:34:48PM -0500, Rob Browning wrote:
> 
> We are pleased to annouce the availability of Guile 1.5.8 for testing.
> Please report problems to guile-devel@gnu.org or bug-guile@gnu.org.
> 

[...]

>         - Make sure LD_LIBRARY_PATH doesn't include anything
>           unnecessary -- though at the moment it (or
>           LTDL_LIBRARY_PATH) will need to include guile's lib
>           directory if that directory is not already in the normal
>           places libltdl looks.

Test results on an oldish Debian Woody on Intel (so pretty vanilla):

after the usual unpacking, ./configure, make, make install make check
(which seems satisfied), and make install (all defaults, so installation
goes to /usr/local/), calling guile:

| spu@flunda:~/guile/guile-1.5.8$ guile
| ERROR: In procedure dynamic-link:
| ERROR: file: "libguilereadline-v-12", message: "file not found"

(there were some old guile libs in /usr/lib. Removing them didn't change
anything).

An strace reveals where guile is looking for this lib. Here's the bit which
looks relevant to me:

| open("/lib/libguilereadline-v-12.la", O_RDONLY) = -1 ENOENT (No such file or directory)
| open("/usr/lib/libguilereadline-v-12.la", O_RDONLY) = -1 ENOENT (No such file or directory)
| open("libguilereadline-v-12.la", O_RDONLY) = -1 ENOENT (No such file or directory)

Setting LD_LIBRARY_PATH seems to fix the problem for me:

| spu@flunda:~$ LD_LIBRARY_PATH=/usr/local/lib guile
| guile> (version)
| "1.5.8"
| guile> 

NOTE: Yes, I have /usr/local/lib in /etc/ld.so.conf. Careful as I am ;-) I ran
/sbin/ldconfig, which didn't change anything (and the strace shows that guile finds
its other libs unter /usr/local/lib anyway, it's just this libguilereadline-v-12)

Thanks for the work, and I'm jumping excitedly up and down in expectation of
guile 1.6 :-)

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Rob Browning]

tomas@fabula.de writes:

> Setting LD_LIBRARY_PATH seems to fix the problem for me:
>
> | spu@flunda:~$ LD_LIBRARY_PATH=/usr/local/lib guile
> | guile> (version)
> | "1.5.8"
> | guile> 
>
> NOTE: Yes, I have /usr/local/lib in /etc/ld.so.conf. Careful as I am
> ;-) I ran /sbin/ldconfig, which didn't change anything (and the
> strace shows that guile finds its other libs unter /usr/local/lib
> anyway, it's just this libguilereadline-v-12)
>
> Thanks for the work, and I'm jumping excitedly up and down in expectation of
> guile 1.6 :-)

I believe you have to set LD_LIBRARY_PATH.  libltdl doesn't pay any
attention to ld.so.conf, though I believe it does look in /lib and
/usr/lib   :/

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[tomas]

On Thu, Aug 29, 2002 at 11:22:15AM -0500, Rob Browning wrote:
> tomas@fabula.de writes:
> 
> > Setting LD_LIBRARY_PATH seems to fix the problem for me:
> >
> > | spu@flunda:~$ LD_LIBRARY_PATH=/usr/local/lib guile
> > | guile> (version)
> > | "1.5.8"
> > | guile> 
> >
> > NOTE: Yes, I have /usr/local/lib in /etc/ld.so.conf. Careful as I am
> > ;-) I ran /sbin/ldconfig, which didn't change anything (and the
> > strace shows that guile finds its other libs unter /usr/local/lib
> > anyway, it's just this libguilereadline-v-12)
> >
> > Thanks for the work, and I'm jumping excitedly up and down in expectation of
> > guile 1.6 :-)
> 
> I believe you have to set LD_LIBRARY_PATH.  libltdl doesn't pay any
> attention to ld.so.conf, though I believe it does look in /lib and
> /usr/lib   :/

That'd match what strace sees. Hmmm. So libltdl is the baddy here. I'll
set LD_LIBRARY_PATH then, until something niceer comes up... (not saying
that I won't look into it, but ATM I'm messed in a Python project =:-@

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[tomas]

On Thu, Aug 29, 2002 at 11:22:15AM -0500, Rob Browning wrote:
> tomas@fabula.de writes:
> 
> > Setting LD_LIBRARY_PATH seems to fix the problem for me:

[...]

> I believe you have to set LD_LIBRARY_PATH.

On an additional note (as I'm testing Ralf's mod_guile), you
have to set LD_LIBRARY_PATH for other applications using guile
as well (in this case Apache), which is sometimes awkward.

Is there another possibility to make libltdl work more
reasonably? Are you taking patches? (oh, my goodness, for
Guile 1.6.1+, of course ;-)

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Rob Browning]

tomas@fabula.de writes:

> On an additional note (as I'm testing Ralf's mod_guile), you
> have to set LD_LIBRARY_PATH for other applications using guile
> as well (in this case Apache), which is sometimes awkward.
>
> Is there another possibility to make libltdl work more
> reasonably? Are you taking patches? (oh, my goodness, for
> Guile 1.6.1+, of course ;-)


Well, there are some options wrt to libltdl, but most of them involve
modifying libltdl's search path (via its api, envt vars, etc.), but
then you have some fairly thorny questions about how that should be
done given the possibility that other shared libraries (or an app
guile's linked against) might be trying to do the same thing.

I think we'd hoped to wait until 1.7 development to try to come up
with a more correct solution, but it *is* a little awkward to require
people to set envt vars just to run guile when they're installing to
/usr/local.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lynn Winebarger]

On Thursday 29 August 2002 12:49, Rob Browning wrote:
> Well, there are some options wrt to libltdl, but most of them involve
> modifying libltdl's search path (via its api, envt vars, etc.), but
> then you have some fairly thorny questions about how that should be
> done given the possibility that other shared libraries (or an app
> guile's linked against) might be trying to do the same thing.

     This seems like it's a serious problem for any program that might
want to use multiple libraries that each use dynamic linking via
ltdl (and that could include guile itself using some such library).  
Someone with strictly positive clout should bring this up with libtool's 
authors (localizing search paths).  
   If environment variable override is a must, they should let the 
individual library choose the variable name,  or a prefix (like GUILE -> 
GUILE_LIBRARY_PATH) (or choose to go along with the global 
LTDL_LIBRARY_PATH).

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> I believe you have to set LD_LIBRARY_PATH.

We should add that to the docs, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> I think we'd hoped to wait until 1.7 development to try to come up
> with a more correct solution, but it *is* a little awkward to
> require people to set envt vars just to run guile when they're
> installing to /usr/local.

Yes, one option would be to make libltdl parse /etc/ld.so.conf on
systems that have it.

On the other hand, you have to set PATH already, why not also
LD_LIBRARY_PATH?  It would be system wide, or session wide setting,
not a per-process setting.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lynn Winebarger]

On Thursday 29 August 2002 13:55, Marius Vollmer wrote:
> Rob Browning <rlb@defaultvalue.org> writes:
> > I think we'd hoped to wait until 1.7 development to try to come up
> > with a more correct solution, but it *is* a little awkward to
> > require people to set envt vars just to run guile when they're
> > installing to /usr/local.
> 
> Yes, one option would be to make libltdl parse /etc/ld.so.conf on
> systems that have it.
> 
> On the other hand, you have to set PATH already, why not also
> LD_LIBRARY_PATH?  It would be system wide, or session wide setting,
> not a per-process setting.

     The problem is for people who muddle with several development projects
at once.  You might want to test development versions of both libfoo and the
libfoo dependent appbar concurrently in /usr/local, but still want appbar to 
use the stable version of libfoo in /usr/lib because appbar has enough instability 
of its own.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lynn Winebarger]

On Thursday 29 August 2002 14:17, Lynn Winebarger wrote:
> On Thursday 29 August 2002 13:55, Marius Vollmer wrote:
> > Rob Browning <rlb@defaultvalue.org> writes:
> > > I think we'd hoped to wait until 1.7 development to try to come up
> > > with a more correct solution, but it *is* a little awkward to
> > > require people to set envt vars just to run guile when they're
> > > installing to /usr/local.
> > 
> > Yes, one option would be to make libltdl parse /etc/ld.so.conf on
> > systems that have it.
> > 
> > On the other hand, you have to set PATH already, why not also
> > LD_LIBRARY_PATH?  It would be system wide, or session wide setting,
> > not a per-process setting.
> 
>      The problem is for people who muddle with several development projects
> at once.  You might want to test development versions of both libfoo and the
> libfoo dependent appbar concurrently in /usr/local, but still want appbar to 
> use the stable version of libfoo in /usr/lib because appbar has enough instability 
> of its own.
> 
      I forgot to mention: You also want the stable appbar that lives in /usr
to use the stable version of libfoo.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

>      The problem is for people who muddle with several development
> projects at once.  You might want to test development versions of
> both libfoo and the libfoo dependent appbar concurrently in
> /usr/local, but still want appbar to use the stable version of
> libfoo in /usr/lib because appbar has enough instability of its own.

The stable and unstable versions of libfoo should have different major
version numbers, so there should be no conflict.  You would need to
compile two versions of appbar, one that is linked against the stable
version of libfoo and one that is linked against the unstable one.

In my view, shared libraries are in a flat namespace.  Conceptually,
they are all in a single 'virtual' directory.  This single directory
is constructed from multiple 'physical' directories by merging them.
Ideally, this merging should happen in the filesystem, via somekind of
unionfs, say, but normally, it is just done with LD_LIBRARY_PATH or
something else and some rules that are not consistently followed by
the several library-accessing tools.

You might want to have different environments, each with it own way to
construct te single virtual library directory, but a program should
not try to put itself into its own environment.  That will lead to
chaos, in my opinion.

The best we can do, is to make the rules for constructing the library
directory consistent.  It is silly that ld finds its libraries in
different places as ld.so, for example.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

"Lars J. Aas" <larsa@sim.no> writes:

> : A fix would be to move the scm_t_signed_bits cast one level up, and
> : also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
> : deriding comment about MS on the code.  OK?
> 
> Sounds reasonable.

However, in CVS HEAD, we use these definitions, to make them
computable by the preprocessor:

#define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
#define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
#define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)

Does this work as well?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[tomas]

On Thu, Aug 29, 2002 at 07:42:35PM +0200, tomas wrote:
> On Thu, Aug 29, 2002 at 11:22:15AM -0500, Rob Browning wrote:
> > tomas@fabula.de writes:
[...]
> On an additional note (as I'm testing Ralf's mod_guile), you
                                        ^^^^^^

Oops, wrong attribution. It's Dale's mod_guile, with some
modifications by Ralf. Sorry for that...

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Lars J. Aas]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
: "Lars J. Aas" <larsa@sim.no> writes:
: 
: > : A fix would be to move the scm_t_signed_bits cast one level up, and
: > : also in SCM_MOST_NEGATIVE_FIXNUM.  We should do that and put a
: > : deriding comment about MS on the code.  OK?
: > 
: > Sounds reasonable.
: 
: However, in CVS HEAD, we use these definitions, to make them
: computable by the preprocessor:
: 
: #define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
: #define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
: #define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)
: 
: Does this work as well?

Yes, the following snippet works out of the box with no tweaks
necessary for the defines.

  Lars J

----------------------------------------------------------------------------

#include <stdio.h>
#include <limits.h>

typedef signed long scm_t_signed_bits;

#ifdef LONG_BIT
# define SCM_LONG_BIT LONG_BIT
#else
# define SCM_LONG_BIT (SCM_CHAR_BIT * sizeof (long) / sizeof (char))
#endif

#define SCM_T_SIGNED_BITS_MAX LONG_MAX

#define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
#define SCM_MOST_POSITIVE_FIXNUM ((SCM_T_SIGNED_BITS_MAX-3)/4)
#define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1)

#define SCM_POSFIXABLE(n) ((n) <= SCM_MOST_POSITIVE_FIXNUM)

int
main(int argc, char ** argv)
{
  int val;
  fprintf(stderr, "test 1 - ");
  if ( SCM_POSFIXABLE(-1) ) fprintf(stderr, "success\n");
  else                      fprintf(stderr, "failure\n");
  fprintf(stderr, "test 2 - ");
  val = -1;
  if ( SCM_POSFIXABLE(val) ) fprintf(stderr, "success\n");
  else                       fprintf(stderr, "failure\n");
  return 0;
}



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 28 Aug 2002, Sven Hartrumpf <Sven.Hartrumpf@FernUni-Hagen.de> wrote: 

> On 28 Aug 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> > Could you test what happens with current CVS GUILE? I revised the GC
> > part of GUILE, and wonder how it compares to both 1.6 and other
> > packages.
> 
> Will take some days.

Some days have passed :-) And here are the results for recent SCM,
guile 1.5.8, and guile 1.7.0 snapshot (guile-core.unstable-20020830.tar.gz)

Impl.          Time   RAM
SCM 5d6         5877s 386MB (The used SCM version is not optimized for speed.)
Guile 1.5.8    13273s 971MB
Guile 20020830 -      - (program runs for ever with a size of 258MB)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 28 Aug 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> > > I.e., what processes show this behaviour.
> > 
> > A medium-sized program doing lots of symbol, string, and list construction.
> > Really GC-intensive programs (around 30% of runtime with bigloo).
> 
> The synthetic benchmark I use for GC testing spends at 25% an
> artificially high amount of time in GC --
> Yours is Real Life

Yes.

> and takes 30% GC time?

Yes, depending on the implementation between 20 and 40%.
Sven


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Han-Wen Nienhuys]

Sven.Hartrumpf@FernUni-Hagen.de writes:
> Impl.          Time   RAM
> SCM 5d6         5877s 386MB (The used SCM version is not optimized for speed.)
> Guile 1.5.8    13273s 971MB
> Guile 20020830 -      - (program runs for ever with a size of 258MB)

Is there some way for me to run this program over here in a debugger?
If that's not possible, then you could give us some hints. My hunch is
that GC is triggered in recent GUILEs too often, but I can't tell from
here if that is so, and why it does.

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 4 Sep 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> Sven writes:
> > Impl.          Time   RAM
> > SCM 5d6         5877s 386MB (The used SCM version is not optimized for speed.)
> > Guile 1.5.8    13273s 971MB
> > Guile 20020830 -      - (program runs for ever with a size of 258MB)
> 
> Is there some way for me to run this program over here in a debugger?
No :-(
> If that's not possible, then you could give us some hints. My hunch is
> that GC is triggered in recent GUILEs too often, but I can't tell from
> here if that is so, and why it does.
How can I make the GC verbose?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Han-Wen Nienhuys]

Sven.Hartrumpf@FernUni-Hagen.de writes:
> On 4 Sep 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> > Sven writes:
> > > Impl.          Time   RAM
> > > SCM 5d6         5877s 386MB (The used SCM version is not optimized for speed.)
> > > Guile 1.5.8    13273s 971MB
> > > Guile 20020830 -      - (program runs for ever with a size of 258MB)
> > 
> > Is there some way for me to run this program over here in a debugger?
> No :-(
> > If that's not possible, then you could give us some hints. My hunch is
> > that GC is triggered in recent GUILEs too often, but I can't tell from
> > here if that is so, and why it does.
> How can I make the GC verbose?

Insert printfs in scm_igc () (gc.c) and scm_i_sweep_all_segments()
(gc-segment.c), the argument they take is the type of object being
allocated. Also, you could insert a

  scm_display(scm_gc_stats(), scm_current_error_port ())

at the end of scm_igc, halfway in scm_gc_for_newcell().

Also there's some printfs in gc-malloc.c that you could switch on.

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Guile 1.5.8 beta available for testing.

[Sven Hartrumpf]

On 5 Sep 2002, Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote: 
> > How can I make the GC verbose?
> 
> Insert printfs in scm_igc () (gc.c) and scm_i_sweep_all_segments()
> (gc-segment.c), the argument they take is the type of object being
> allocated. Also, you could insert a
> 
>   scm_display(scm_gc_stats(), scm_current_error_port ())
> 
> at the end of scm_igc, halfway in scm_gc_for_newcell().
> 
> Also there's some printfs in gc-malloc.c that you could switch on.

Thanks. I was lazy and just added in libguile/gc.h:
#define DEBUGINFO (Maybe rename it?)

(Then, I had to add #include <stdio.h> in libguile/gc-freelist.c to avoid
an gcc error.)

I will report the results to Han-Wen.

Sven


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel