This is the mail archive of the email@example.com mailing list for the guile project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
>>>>> "julian" == julian gosnell <firstname.lastname@example.org> 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