Sabotage against guile users?

Sabotage against guile users?

[Roland Orre]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

I now intended to start using guile again. I used guile daily for my R&D
from 1995 to 2008. The last guile I built for was guile-1.8.5

However, my old module build does no longer work with guile-1.8.8
(the latest stable downloaded from savannah.gnu.org)

Previously the guile dist contained an example directory (the box)
now essential files from these directories are missing. The previous
guile-1.8.5/examples/box-dynamic-module
contained these files:
box.c          box-module.scm  Makefile     Makefile.in
box-mixed.scm  check.test      Makefile.am  README

However, when checking
guile-1.8.5/examples/box-dynamic-module
in now only contains
box.c  box-mixed.scm  box-module.scm  README
where the README file says:

** Overview
This directory includes an example program for extending Guile with a
new (and even useful) data type, putting it into a shared library, so it
can be called from an unmodified guile interpreter. Further, the shared
library defines a new guile module.
* Build Instructions
To build the example, simply type
  make libbox-module
in this directory.
*

which is obviously not doable as there i s no make file.
The manual says nothing about compiling modules.

How am I supposed to get things working, when the necessary
example files are missing and/or misleading?

[-- Attachment #2: Type: text/html, Size: 1518 bytes --]

Re: Sabotage against guile users?

[Roland Orre]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

Even though it may be obvious:
it is of course from
guile-1.8.8/examples/box-dynamic-module
where essential files (Makefile and/or Makefile.am) are missing from.

On Wed, Jul 10, 2013 at 3:11 PM, Roland Orre <roland.orre@gmail.com> wrote:

> I now intended to start using guile again. I used guile daily for my R&D
> from 1995 to 2008. The last guile I built for was guile-1.8.5
>
> However, my old module build does no longer work with guile-1.8.8
> (the latest stable downloaded from savannah.gnu.org)
>
> Previously the guile dist contained an example directory (the box)
> now essential files from these directories are missing. The previous
> guile-1.8.5/examples/box-dynamic-module
> contained these files:
> box.c          box-module.scm  Makefile     Makefile.in
> box-mixed.scm  check.test      Makefile.am  README
>
> However, when checking
> guile-1.8.5/examples/box-dynamic-module
> in now only contains
> box.c  box-mixed.scm  box-module.scm  README
> where the README file says:
>
> ** Overview
> This directory includes an example program for extending Guile with a
> new (and even useful) data type, putting it into a shared library, so it
> can be called from an unmodified guile interpreter. Further, the shared
> library defines a new guile module.
> * Build Instructions
> To build the example, simply type
>   make libbox-module
> in this directory.
> *
>
> which is obviously not doable as there i s no make file.
> The manual says nothing about compiling modules.
>
> How am I supposed to get things working, when the necessary
> example files are missing and/or misleading?
>

[-- Attachment #2: Type: text/html, Size: 2069 bytes --]

Re: Sabotage against guile users?

[Alexei Matveev]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hi, Roland,

What exactly goes wrong when you build your module?
Did you accidentally the error message?

I use this convenience command to augment the linker and compiler flags:

        LIBS += $(shell guile-config link)
        INCDIRS += $(shell guile-config compile)

Alexei

[-- Attachment #2: Type: text/html, Size: 321 bytes --]

Re: Sabotage against guile users?

[Roland Orre]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

Hi Alexi,
thanks for your reply.
The builds works fine, but when loading the module, e.g.
(use-modules (bcpnn2))
which contains
(load-extension (string-append bcpnn2-path ".libs/libbcpnn"
"scm_init_bcpnn")
I get the error message
./bcpnn2.scm:13:1: In procedure dynamic-link in expression (load-extension
(string-append bcpnn2-path ".libs/libbcpnn") "scm_init_bcpnn"):
./bcpnn2.scm:13:1: file: "/home/orre/work/guile/bcpnn-2.1/.libs/libbcpnn",
message: "file not found"
despite that directory contains a lot of recently built files like
bcpnn.o bits.o libbcpnn.a libbcpnn.la libbcpnn.lai libbcpnn.so
libbcpnn.so.0 mymath.o sets.o time.o user.o
However, I see that on a machine where this still works with guile-1.8.5 I
actually call a  bash script which sets LD_LIBRARY_PATH and
LTDL_LIBRARY_PATH as well
but the latter only for readline and LD_LIBRARY_PATH only points to guile's
libltdl/lib and guile/lib but I haven't checked if these are still
necessary.

The main problem is that I've never seen any kind of documentation upon how
doing this correct, my only documentation has been e.g
examples/box-dynamic-module/Makefile
which I've utilized and modified, but that no longer exists.

I would be very glad to be hinted about where I can actually find the
correct and precise doc for making dynamically loadable modules, which is
fundamental for anything I do.
Apart from that I really love guile. I even used the precursor to guile,
Aubrey Jaffer's scm before guile, in a similar manner, but at that time I
had to statically link scm  with my extensions.

On Wed, Jul 10, 2013 at 7:49 PM, Alexei Matveev <alexei.matveev@gmail.com>wrote:

>
> Hi, Roland,
>
> What exactly goes wrong when you build your module?
> Did you accidentally the error message?
>
> I use this convenience command to augment the linker and compiler flags:
>
>         LIBS += $(shell guile-config link)
>         INCDIRS += $(shell guile-config compile)
>
> Alexei
>

[-- Attachment #2: Type: text/html, Size: 2512 bytes --]

Re: Sabotage against guile users?

[Ludovic Courtès]

Roland Orre <roland.orre@gmail.com> skribis:

> which contains
> (load-extension (string-append bcpnn2-path ".libs/libbcpnn"
> "scm_init_bcpnn")
> I get the error message
> ./bcpnn2.scm:13:1: In procedure dynamic-link in expression (load-extension
> (string-append bcpnn2-path ".libs/libbcpnn") "scm_init_bcpnn"):
> ./bcpnn2.scm:13:1: file: "/home/orre/work/guile/bcpnn-2.1/.libs/libbcpnn",
> message: "file not found"

(Note that you shouldn’t rely on .libs.)

Probably some symbols in libbcpnn are unresolved, perhaps because some
of the libraries it needs were not found.

Can you run:

  objdump -x .libs/libbcpnn.so | grep -e '(NEED|PATH)'

and:

  ldd .libs/libbcpnn.so

> I would be very glad to be hinted about where I can actually find the
> correct and precise doc for making dynamically loadable modules, which is
> fundamental for anything I do.

In the “Linking Programs With Guile” (info "(guile) Linking Programs
With Guile"), for the Guile 2.0 manual at least.

HTH,
Ludo’.

Re: Sabotage against guile users?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

() Roland Orre <roland.orre@gmail.com>
() Wed, 10 Jul 2013 23:12:35 +0200

   I would be very glad to be hinted about where I can actually find the
   correct and precise doc for making dynamically loadable modules,
   which is fundamental for anything I do.

Me too!

Towards that end, i started cmod-play:

 http://www.gnuvola.org/software/cmod-play/

which attempts to surf the changes for "compiled modules" support over
various Guile versions.  The practical upshot of that project is evident
in Guile-PG and Guile-SDL, although cmod-play has not seen a release in
quite a few years.

Update -- Actually, this thread has prompted me to do the final touches
required for a new release (CMOD-PLAY 4.0).  Check it out!

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Sabotage against guile users?

[Ludovic Courtès]

Hello, and welcome back!  :-)

Roland Orre <roland.orre@gmail.com> skribis:

> I now intended to start using guile again. I used guile daily for my R&D
> from 1995 to 2008. The last guile I built for was guile-1.8.5
>
> However, my old module build does no longer work with guile-1.8.8
> (the latest stable downloaded from savannah.gnu.org)

No no no, the latest stable is 2.0.9, and it’s like night & day compared
to 1.8.  So while you’re at it, jump directly to 2.0.9.  ;-)

Ludo’.

Re: Sabotage against guile users?

[Roland Orre]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

On Thu, Jul 11, 2013 at 12:10 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> Hello, and welcome back!  :-)
>
> Roland Orre <roland.orre@gmail.com> skribis:
>
> > I now intended to start using guile again. I used guile daily for my R&D
> > from 1995 to 2008. The last guile I built for was guile-1.8.5
> >
> > However, my old module build does no longer work with guile-1.8.8
> > (the latest stable downloaded from savannah.gnu.org)
>
> No no no, the latest stable is 2.0.9, and it’s like night & day compared
> to 1.8.  So while you’re at it, jump directly to 2.0.9.  ;-)
>

I did a few performance tests, and so far 2.0.9 performs much worse than
1.8.8.
I do not know why, but one simple first test I did was
(define foo (fac 10000))
which for guile-1.8.8 has as average around 60 ms but for guile-2.0.9 has as
average around 212 ms (almost no time in gc in average). I also checked
by removing libgmp that libgmp was really used. Then I tried to run the
benchmark-suite which was also quite tedious, as they are not directly
compatible between 1.8.8 2.0.9, but those tests I succeded to run indicated
much worse performance, around 10 times slower for 2.0.9. I also checked
the results 35660 digits, and they were identical.

I suspect something strange to be hidden there, which I'll check with some
standard benchmark tests. I found a set at
 http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/code/benc
h/gabriel/gabriel.tgz
that I will try with later.
However, as guile-1.8.8 goes very very fast to build compared to
guile-2.0.9,
mostly due to compilation of ice-9 and my programs certainly need quite a
lot of adaptation for 2.0.9 I'll start with guile-1.8.8 (there was a lot of
work to
adapt them from guile-1.7 to guile-1.8 earlier).

The fac I used above was defined as:
(define (fac n)
  (define (iter n res)
    (if (> n 1)
        (iter (1- n) (* n res))
        res))
  (iter n 1))

/Roland


>
> Ludo’.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2783 bytes --]

Re: Sabotage against guile users?

[Roland Orre]

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

Another huge difference between guile-1.8.8 versus guile-2.0.9 is the
startup time, which makes guile-2.0.9 not at all suitable for shell
scripting
where guile-1.8.8 starts extremely fast.
So it seems as guile-1.8.8 is something to value high in a very special way.
(I've copied it to many machines, just to assure that I won't lose it)

By the way, the original problem I mentioned, i.e. lack of
docs for making dynamically linked modules, where the only docs
I've ever found is the make files for the box example
e.g. examples/box-dynamic-module
those makefiles are missing also for guile-2.0.9
OK, there is a Makefile examples/Makefile which is possibly
intended to replace the separate makefiles in
box, box-dynamic, box-dynamic-module
but then the README files under the box directories need to be updated.

On Thu, Jul 11, 2013 at 1:52 AM, Roland Orre <roland.orre@gmail.com> wrote:

> On Thu, Jul 11, 2013 at 12:10 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Hello, and welcome back!  :-)
>>
>> Roland Orre <roland.orre@gmail.com> skribis:
>>
>> > I now intended to start using guile again. I used guile daily for my R&D
>> > from 1995 to 2008. The last guile I built for was guile-1.8.5
>> >
>> > However, my old module build does no longer work with guile-1.8.8
>> > (the latest stable downloaded from savannah.gnu.org)
>>
>> No no no, the latest stable is 2.0.9, and it’s like night & day compared
>> to 1.8.  So while you’re at it, jump directly to 2.0.9.  ;-)
>>
>
> I did a few performance tests, and so far 2.0.9 performs much worse than
> 1.8.8.
> I do not know why, but one simple first test I did was
> (define foo (fac 10000))
> which for guile-1.8.8 has as average around 60 ms but for guile-2.0.9 has
> as
> average around 212 ms (almost no time in gc in average). I also checked
> by removing libgmp that libgmp was really used. Then I tried to run the
> benchmark-suite which was also quite tedious, as they are not directly
> compatible between 1.8.8 2.0.9, but those tests I succeded to run indicated
> much worse performance, around 10 times slower for 2.0.9. I also checked
> the results 35660 digits, and they were identical.
>
> I suspect something strange to be hidden there, which I'll check with some
> standard benchmark tests. I found a set at
>
> http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/code/benc
> h/gabriel/gabriel.tgz
> that I will try with later.
> However, as guile-1.8.8 goes very very fast to build compared to
> guile-2.0.9,
> mostly due to compilation of ice-9 and my programs certainly need quite a
> lot of adaptation for 2.0.9 I'll start with guile-1.8.8 (there was a lot
> of work to
> adapt them from guile-1.7 to guile-1.8 earlier).
>
> The fac I used above was defined as:
> (define (fac n)
>   (define (iter n res)
>     (if (> n 1)
>         (iter (1- n) (* n res))
>         res))
>   (iter n 1))
>
> /Roland
>
>
>>
>> Ludo’.
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4113 bytes --]

Re: Sabotage against guile users?

[Ludovic Courtès]

Roland Orre <roland.orre@gmail.com> skribis:

> Another huge difference between guile-1.8.8 versus guile-2.0.9 is the
> startup time, which makes guile-2.0.9 not at all suitable for shell
> scripting
> where guile-1.8.8 starts extremely fast.

On my machine startup times are comparable (~20ms).

What did you measure?

Then again this is dependent on the number of elements on
$GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH: more elements means more
stat(2) calls.

Ludo’.

Re: Sabotage against guile users?

[Ludovic Courtès]

Roland Orre <roland.orre@gmail.com> skribis:

> I did a few performance tests, and so far 2.0.9 performs much worse than
> 1.8.8.
> I do not know why, but one simple first test I did was
> (define foo (fac 10000))
> which for guile-1.8.8 has as average around 60 ms but for guile-2.0.9 has as
> average around 212 ms (almost no time in gc in average). I also checked
> by removing libgmp that libgmp was really used. Then I tried to run the
> benchmark-suite which was also quite tedious, as they are not directly
> compatible between 1.8.8 2.0.9, but those tests I succeded to run indicated
> much worse performance, around 10 times slower for 2.0.9. I also checked
> the results 35660 digits, and they were identical.

What that this test really measures the performance of the GC, since
bignums are heap-allocated.  Furthermore, since it’s too short (~100ms
on my machine, of which 2.0’s startup takes ~20ms, and slightly more for
1.8), the measurements are too noisy.

> The fac I used above was defined as:
> (define (fac n)
>   (define (iter n res)
>     (if (> n 1)
>         (iter (1- n) (* n res))
>         res))
>   (iter n 1))

I did these two tests anyway:

  1. Run with ‘guile -q -c '(begin (define (fac n) ...) (fac 10000))’.
     With 1.8.8, it takes ~110ms on average.
     With 2.0.9, it takes ~130ms on average.

  2. Put the definition and call in a file, and run ‘guile -q t.scm’.
     With 1.8.8, it takes ~110ms on average.
     With 2.0.9, it takes ~90ms on average.

For (1), Guile 2.0 uses its evaluator, which is not very efficient.
However, for (2), it first auto-compiles the program to bytecode, and
further runs are clearly faster than with 1.8 (again, a better benchmark
would help, but you get the idea.)

Thanks,
Ludo’.