Re: need faster MOP....

[Bernard URBAN <Bernard.Urban@meteo.fr>]

>>>>> "julian" == julian gosnell <julian.gosnell@nomura.co.uk> writes:

    >>  Have you tried the latest guile-stklos ? (guile-stklos-1.3.1
    >> at ftp.red-bean.com, in the contrib/misc directory).  It
    >> compiles tiny-clos and some STklos classes via hobbit (that is
    >> the latest version guile-hobbit-1.3.2, also to be found at
    >> red-bean).
    >> 
    >> Several users had serious problems using hobbit and
    >> guile-stklos in the past. One of the most common problem was
    >> the use of a guile snapshot not compatible with hobbit or
    >> stklos.
    >> 
    >> Now you are FORCED to use guile-1.3, so you probably will
    >> encounter less problems...
    >> 
    >> For speed, you are much faster than interpreted, but it is not
    >> sufficient in my opinion. This is caused by the current
    >> guile-stklos not using a compiled boot-9.scm, as was the case
    >> for previous versions.  Compiling boot-9.scm was a problem to
    >> most users, so I decided not to use this, but at the expense of
    >> speed.

    julian> I remember last time I played with hobbit I found that I
    julian> had problems adapting the structure of my modules to use
    julian> compiled code rather than interpreted code.

Currently, the safe way to compile modules is to:
1) define the interface to the outside as a wrapper of interpreted code.
(e.g.: lib-hobbit in the guile-hobbit-1.3.2 distribution:

(define-module (hobbit4d lib-hobbit))

(use-modules (hobbit4d link))

(hobbit-load-from-path "hobbit4d/util")

(define-public delete delete)
(define-public some some)
(define-public pair-some pair-some)
....
)

2) define the core functionality as compiled R4RS code
(which in the above case is in file util.scm, compiled to library
libutil.so)
hobbit-load-from-path (provided by module (hobbit4d link))
is the way hobbit extends load-from-path
for compiled code (findind the place where the
*.so files lives, determining the init function to call to make all
defined symbols available).

    julian> If I have module 'b' which 'uses' module 'a' and I want to
    julian> compile module 'a' for speed, is there any way I can
    julian> simply compile it i.e. 'hob scm/a.scm' and then not have
    julian> to mess around in module 'b' to get it to load the newly
    julian> compiled code instead of the original scheme. i.e. I want
    julian> the guile module system to load the compiled code if it
    julian> finds it on the path before it looks for scheme source.

This is not a problem, if you proceed as above.
So you have the wrapper for b as:
(define-module (scm b))

(use-modules (scm a))
...

The interpreted wrapper for a is:
(define-module (scm a))

(use-modules (hobbit4d link))
(load-from-path "scm/fast-a")

(define-public define1-in-fast-a define1-in-fast-a) 
...

where fast-a.scm is compiled to libfast-a.so.

    julian> Last time I played with hobbit I am sure I had to
    julian> restructure some of my modules to use
    julian> hobbit-load-from-path instead of 'use-modules'.

Yes, but only for the wrapper part. 

But suppose now that (scm b) loads some compiled code using the public
interface of (scm a). The compiler will look for such symbols in the
root module, which is not what is wanted. By using the -m flag, the
generated code will look for the undefined symbol in the module
system, and then the behaviour will be correct. You are always safe
using -m, to the point the next hobbit release will probably
make this the default. See the README of guile-hobbit-1.3.2 in section 
"Compilation of  modules" for a simple exemple of this.

    julian> Is what I am asking sensible ? It would free me from
    julian> knowing what was and was not compiled, then I could simply
    julian> compile/seal code when I needed it optimised without
    julian> worrying about anything else.

The top of file guile-hobbit.scm begins as:

(define-module (hobbit4d guile-hobbit))
(use-modules (hobbit4d lib-hobbit))

so what you want exists...

    julian> Has anyone else done this - would it be hard ?

If what you want is the suppression of the wrapper part, it will
require some work on the internals of hobbit. But I will not tackle
this problem until the module system stabilizes and has some C support.

Regards.

--

B. Urban