Problem with modules in Guile 2.0

Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

Hi all,
  I stumbled on a strange behaviour of Guile 2.0, I have the following three files: main.scm, test-module.scm and sub/mymodule.scm which respectively contain

---- main.scm 

(load "test-modules.scm")

(inherit-modules (sub mymodule))

(display (pippo 10 20)) (display "\n")


---- sub/mymodule.scm 

(texmacs-module (sub mymodule))


(display "Loading my module\n")

(define-public (pippo a b)
 (+ a b))
 
 
---- test-modules.scm 

(define texmacs-user (current-module))
(define temp-module (current-module))

(define-macro (with-module module . body)
  `(begin
     (set! temp-module (current-module))
     (set-current-module ,module)
     ,@body
     (set-current-module temp-module)))


(define-macro (import-from . modules)
	`(process-use-modules
	  (list ,@(map (lambda (m)
			 `(list ,@(compile-interface-spec m)))
		       modules))))
      

(define-macro (inherit-modules . which-list)
  (define (module-exports which)
    (let* ((m (resolve-module which))
	   (m-public (module-ref m '%module-public-interface)))
      (module-map (lambda (sym var) sym) m-public)))
  (let ((l (apply append (map module-exports which-list))))
    `(begin
       (use-modules ,@which-list)
       (re-export ,@l))))

(define-macro (texmacs-module name . options)
  (define (transform action)
    (cond ((not (pair? action)) (noop))
	  ((equal? (car action) :use) (cons 'use-modules (cdr action)))
	  ((equal? (car action) :inherit) (cons 'inherit-modules (cdr action)))
	  ((equal? (car action) :export)
	   (display "Warning] The option :export is no longer supported\n")
	   (display "       ] Please use tm-define instead\n"))
	  (else '(noop))))
  (let ((l (map-in-order transform options)))
	(set! l (cons `(module-use! (current-module) ,texmacs-user) l))
    (display "loading ") (display name) (display "\n")
    `(begin
       (define-module ,name)
       ,@l)))

-----------

the directory structure is the following

./main.scm
./test-modules.scm
./sub/mymodule.scm

these are pieces from a larger software (GNU TeXmacs) which used to work with any version of Guile up to 1.8 and fail to work with Guile 2.0. In an interactive session, after setting the GUILE_LOAD_PATH to the working directory I get


---------------------------
Jurgen:test-modules mgubi$ GUILE_LOAD_PATH=$PWD guile
GNU Guile 2.0.5
Copyright (C) 1995-2012 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "main.scm")
;;; note: source file /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
;;;       newer than compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
;;; main.scm:3:0: warning: possibly unbound variable `inherit-modules'
;;; main.scm:3:17: warning: possibly unbound variable `sub'
;;; main.scm:3:17: warning: possibly unbound variable `mymodule'
;;; main.scm:5:9: warning: possibly unbound variable `pippo'
;;; compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm.go
main.scm:3:17: In procedure #<procedure 109cfed80 ()>:
main.scm:3:17: In procedure module-lookup: Unbound variable: sub

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 
---------------------------

The same code work fine with 1.6:

Jurgen:test-modules mgubi$ GUILE_LOAD_PATH=$PWD ../../build-64-guile-1.6.8/usr/bin/guile
guile> (version)
"1.6.8"
guile> (load "main.scm")
loading (sub mymodule)
Loading my module
30
guile> 

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

Somebody has a clue on how to fix this and what is the origin of the problem?

Thanks,

Massimiliano Gubinelli

Re: Problem with modules in Guile 2.0

[Mark H Weaver]

Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:

>   I stumbled on a strange behaviour of Guile 2.0, I have the following three files: main.scm, test-module.scm and sub/mymodule.scm which respectively contain
>
> ---- main.scm 
>
> (load "test-modules.scm")
>
> (inherit-modules (sub mymodule))
>
> (display (pippo 10 20)) (display "\n")

The problem is that 'load' is done only at run time, not compile time,
so the compiler does not have access to the macro 'inherit-modules'.
Since Guile 1.x did not have a compiler, this was not an issue.

One easy solution would be to use the 'include' macro instead.
'include' acts like '#include' in C: it splices the entire contents of
the included file in place of the 'include' form, at compilation time.

'include' did not exist in Guile 1.x, but you could do something like
this to make 'include' an alias for 'load' in Guile 1.x:

  (cond-expand
   (guile-2 #f)
   (guile (define include load)))

     Best,
      Mark

Re: Problem with modules in Guile 2.0

[Andy Wingo]

Hi!

Mark gave great answers; I just wanted to give one more option:

On Tue 06 Mar 2012 22:48, Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:

> (load "test-modules.scm")

Add a definition first:

  (cond-expand
   (guile-2
    (define-syntax-rule (begin-for-syntax form ...)
      (eval-when (load compile eval) (begin form ...))))
   (else
    (define begin-for-syntax begin)))

Then:

  (begin-for-syntax
   (load "test-modules.scm"))

Regards,

Andy
-- 
http://wingolog.org/

Re: Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

Thanks for the prompt reply to both of you. However the proposed solution do not work in my case. After implementing the begin-for-syntax alternative I now get

scheme@(guile-user)> (load "main.scm")
;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
;;; note: source file /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
;;;       newer than compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:15:34: warning: possibly unbound variable `compile-interface-spec'
;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:32:11: warning: possibly unbound variable `:use'
;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:33:11: warning: possibly unbound variable `:inherit'
;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:34:11: warning: possibly unbound variable `:export'
;;; compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
;;; WARNING: compilation of /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm failed:
;;; ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>
ERROR: In procedure scm-error:
ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 

if I understand correctly this backtrace it seems that the module is not completely loaded at compile time and there is not public interface available. How can I force the evaluation of the loaded modules in order to get a list of exported symbols?

Best
massimiliano




On Mar 7, 2012, at 9:32 PM, Andy Wingo wrote:

> Hi!
> 
> Mark gave great answers; I just wanted to give one more option:
> 
> On Tue 06 Mar 2012 22:48, Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
> 
>> (load "test-modules.scm")
> 
> Add a definition first:
> 
>  (cond-expand
>   (guile-2
>    (define-syntax-rule (begin-for-syntax form ...)
>      (eval-when (load compile eval) (begin form ...))))
>   (else
>    (define begin-for-syntax begin)))
> 
> Then:
> 
>  (begin-for-syntax
>   (load "test-modules.scm"))
> 
> Regards,
> 
> Andy
> -- 
> http://wingolog.org/

On Mar 7, 2012, at 9:32 PM, Andy Wingo wrote:

> Hi!
> 
> Mark gave great answers; I just wanted to give one more option:
> 
> On Tue 06 Mar 2012 22:48, Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
> 
>> (load "test-modules.scm")
> 
> Add a definition first:
> 
>  (cond-expand
>   (guile-2
>    (define-syntax-rule (begin-for-syntax form ...)
>      (eval-when (load compile eval) (begin form ...))))
>   (else
>    (define begin-for-syntax begin)))
> 
> Then:
> 
>  (begin-for-syntax
>   (load "test-modules.scm"))
> 
> Regards,
> 
> Andy
> -- 
> http://wingolog.org/

Re: Problem with modules in Guile 2.0

[Mark H Weaver]

Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:

> Thanks for the prompt reply to both of you. However the proposed
> solution do not work in my case.

I think it _did_ solve your original problem, but now you have moved on
to other unrelated problems.

> After implementing the
> begin-for-syntax alternative I now get
>
> scheme@(guile-user)> (load "main.scm")
> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
> ;;; note: source file /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
> ;;; newer than compiled
> /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
> ;;;
> /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:15:34:
> warning: possibly unbound variable `compile-interface-spec'

Note that 'compile-interface-spec' was an undocumented internal
procedure of Guile 1.x, and no longer exists in Guile 2.

> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:32:11: warning: possibly unbound variable `:use'
> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:33:11: warning: possibly unbound variable `:inherit'
> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:34:11: warning: possibly unbound variable `:export'

In order to use the shorter keyword syntax ':use' (instead of '#:use'),
you must set the prefix keywords reader option.  Put the following at
the beginning of your 'begin-for-syntax' form:

  (read-set! keywords 'prefix)

> ;;; compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
> ;;; WARNING: compilation of /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm failed:
> ;;; ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>
> ERROR: In procedure scm-error:
> ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> 
>
> if I understand correctly this backtrace it seems that the module is
> not completely loaded at compile time and there is not public
> interface available. How can I force the evaluation of the loaded
> modules in order to get a list of exported symbols?

I cannot reproduce this.  When I try using your example code, Guile
2.0.5 tries to compile (sub mymodule).  Are you sure that you remembered
to set GUILE_LOAD_PATH during this test run?

This is what I see:

  GNU Guile 2.0.5
  Copyright (C) 1995-2012 Free Software Foundation, Inc.
  
  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.
  
  Enter `,help' for help.
  scheme@(guile-user)> (load "main.scm")
  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
  ;;;       or pass the --no-auto-compile argument to disable.
  ;;; compiling /home/mhw/guile-modules/main.scm
  ;;; compiling /home/mhw/guile-modules/./test-modules.scm
  ;;; test-modules.scm:15:34: warning: possibly unbound variable `compile-interface-spec'
  ;;; compiled /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/test-modules.scm.go
  ;;; compiling /home/mhw/guile-modules/sub/mymodule.scm
  ;;; sub/mymodule.scm:1:0: warning: possibly unbound variable `texmacs-module'
  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `sub'
  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `mymodule'
  ;;; compiled /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/sub/mymodule.scm.go
  ;;; WARNING: compilation of /home/mhw/guile-modules/main.scm failed:
  ;;; ERROR: In procedure module-lookup: Unbound variable: texmacs-module
  sub/mymodule.scm:1:0: In procedure #<procedure 1058ebb0 ()>:
  sub/mymodule.scm:1:0: In procedure module-lookup: Unbound variable: texmacs-module
  
  Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
  scheme@(#{ g435}#) [1]> 

and the problem here is that the compilation of sub/mymodule.scm fails
because the 'texmacs-module' macro was used before it was imported into
that module.  Initially, a module imports only the (guile) module.  If
you want to use a non-standard module declaration like 'texmacs-module'
at the top of a module, you'll need to add that binding to the (guile)
module.

    Best,
     Mark

Re: Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

Hi Mark,
 thanks again. I start to understand better the Guile 2 compile system. I decided to dig into boot-9.scm to have a more precise idea of the ecosystem around my scripts. Unfortunately it seems that the basic TeXmacs scripting infrastructure need a major change to be run into Guile 2.0 and I'm afraid not to be sufficiently proficient in scheme to do this in a short time. Is there anyone on this list which would like to assist me to port GNU TeXmacs to Guile 2.0. Currently the code in svn builds fine against 2.0 so the problem is just to adapt the scheme scripts which rely on a customized module system. If you are interested you can contact me privately. In the meantime I will dig into the code hoping to find illumination among parentheses….

best
max


On Mar 8, 2012, at 3:01 AM, Mark H Weaver wrote:

> Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
> 
>> Thanks for the prompt reply to both of you. However the proposed
>> solution do not work in my case.
> 
> I think it _did_ solve your original problem, but now you have moved on
> to other unrelated problems.
> 
>> After implementing the
>> begin-for-syntax alternative I now get
>> 
>> scheme@(guile-user)> (load "main.scm")
>> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
>> ;;; note: source file /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
>> ;;; newer than compiled
>> /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
>> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
>> ;;;
>> /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:15:34:
>> warning: possibly unbound variable `compile-interface-spec'
> 
> Note that 'compile-interface-spec' was an undocumented internal
> procedure of Guile 1.x, and no longer exists in Guile 2.
> 
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:32:11: warning: possibly unbound variable `:use'
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:33:11: warning: possibly unbound variable `:inherit'
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:34:11: warning: possibly unbound variable `:export'
> 
> In order to use the shorter keyword syntax ':use' (instead of '#:use'),
> you must set the prefix keywords reader option.  Put the following at
> the beginning of your 'begin-for-syntax' form:
> 
>  (read-set! keywords 'prefix)
> 
>> ;;; compiled /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
>> ;;; WARNING: compilation of /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm failed:
>> ;;; ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>
>> ERROR: In procedure scm-error:
>> ERROR: No variable named %module-public-interface in #<directory (sub mymodule) 10507ed80>
>> 
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]> 
>> 
>> if I understand correctly this backtrace it seems that the module is
>> not completely loaded at compile time and there is not public
>> interface available. How can I force the evaluation of the loaded
>> modules in order to get a list of exported symbols?
> 
> I cannot reproduce this.  When I try using your example code, Guile
> 2.0.5 tries to compile (sub mymodule).  Are you sure that you remembered
> to set GUILE_LOAD_PATH during this test run?
> 
> This is what I see:
> 
>  GNU Guile 2.0.5
>  Copyright (C) 1995-2012 Free Software Foundation, Inc.
> 
>  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>  This program is free software, and you are welcome to redistribute it
>  under certain conditions; type `,show c' for details.
> 
>  Enter `,help' for help.
>  scheme@(guile-user)> (load "main.scm")
>  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>  ;;;       or pass the --no-auto-compile argument to disable.
>  ;;; compiling /home/mhw/guile-modules/main.scm
>  ;;; compiling /home/mhw/guile-modules/./test-modules.scm
>  ;;; test-modules.scm:15:34: warning: possibly unbound variable `compile-interface-spec'
>  ;;; compiled /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/test-modules.scm.go
>  ;;; compiling /home/mhw/guile-modules/sub/mymodule.scm
>  ;;; sub/mymodule.scm:1:0: warning: possibly unbound variable `texmacs-module'
>  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `sub'
>  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `mymodule'
>  ;;; compiled /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/sub/mymodule.scm.go
>  ;;; WARNING: compilation of /home/mhw/guile-modules/main.scm failed:
>  ;;; ERROR: In procedure module-lookup: Unbound variable: texmacs-module
>  sub/mymodule.scm:1:0: In procedure #<procedure 1058ebb0 ()>:
>  sub/mymodule.scm:1:0: In procedure module-lookup: Unbound variable: texmacs-module
> 
>  Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>  scheme@(#{ g435}#) [1]> 
> 
> and the problem here is that the compilation of sub/mymodule.scm fails
> because the 'texmacs-module' macro was used before it was imported into
> that module.  Initially, a module imports only the (guile) module.  If
> you want to use a non-standard module declaration like 'texmacs-module'
> at the top of a module, you'll need to add that binding to the (guile)
> module.
> 
>    Best,
>     Mark

Re: Problem with modules in Guile 2.0

[Mark H Weaver]

Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:

> Hi Mark,
>  thanks again. I start to understand better the Guile 2 compile
> system. I decided to dig into boot-9.scm to have a more precise idea
> of the ecosystem around my scripts. Unfortunately it seems that the
> basic TeXmacs scripting infrastructure need a major change to be run
> into Guile 2.0 and I'm afraid not to be sufficiently proficient in
> scheme to do this in a short time.

Why not convert your scripts to use the standard Guile module syntax?

> Is there anyone on this list which would like to assist me to port GNU
> TeXmacs to Guile 2.0. Currently the code in svn builds fine against
> 2.0 so the problem is just to adapt the scheme scripts which rely on a
> customized module system.

I'd be glad to take a look.  Where can I find your scripts?

   Regards,
     Mark

Re: Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

Hi Mark,

On Mar 9, 2012, at 5:29 PM, Mark H Weaver wrote:

> Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
> 
>> Hi Mark,
>> thanks again. I start to understand better the Guile 2 compile
>> system. I decided to dig into boot-9.scm to have a more precise idea
>> of the ecosystem around my scripts. Unfortunately it seems that the
>> basic TeXmacs scripting infrastructure need a major change to be run
>> into Guile 2.0 and I'm afraid not to be sufficiently proficient in
>> scheme to do this in a short time.
> 
> Why not convert your scripts to use the standard Guile module syntax?
> 

TeXmacs is currently composed of 250 scheme files for \sim 60000 lines of scheme. Guile is used for customization and for other operations which do not require special performance. All the rest of the program is written in C++, in particular the typesetter and the GUI code. It has a slightly customized module system and features contextual overloading of functions (a function can be redefined to act differently is some condition is met without modifying the module which implemented the base behaviour). We would like to preserve the current system as much as possible. Moreover we want also to be compatible with previous versions of Guile (now we support Guile 1.4 up to Guile 1.8). The code does not depend very much on specific Guile features a part form the module system.

>> Is there anyone on this list which would like to assist me to port GNU
>> TeXmacs to Guile 2.0. Currently the code in svn builds fine against
>> 2.0 so the problem is just to adapt the scheme scripts which rely on a
>> customized module system.
> 
> I'd be glad to take a look.  Where can I find your scripts?
> 

TeXmacs codebase is hosted at savannan (https://savannah.gnu.org/projects/texmacs/).  Check out the svn trunk  via

svn co svn://svn.savannah.gnu.org/texmacs/trunk

then you can find the scheme script in trunk/src/TeXmacs/progs

at boot C++ evaluate init-texmacs.scm which in turn bootstrap the custom module system defined in kernel/boot.scm and start to load modules. We have a facility to lazy load modules since in old machines the bootstrap of the scheme code is too slow. 
With the current svn you will not be able to build TeXmacs with Guile 2.0. If you are interested in that I will tell you how to do.

I still do not know very well the scheme code (almost all of it has been written by the main developer, Joris van der Hoeven). 

Massimiliano

>   Regards,
>     Mark

Re: Problem with modules in Guile 2.0

[Mark H Weaver]

Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
>> Why not convert your scripts to use the standard Guile module syntax?
>
> TeXmacs is currently composed of 250 scheme files for \sim 60000 lines
> of scheme.

Fair enough.  I see no obstacle to adapting the TeXmacs module system to
work with Guile 2.  It's just a matter of finding the cleanest way to
implement it.

> It has a slightly customized module system and features contextual
> overloading of functions (a function can be redefined to act
> differently is some condition is met without modifying the module
> which implemented the base behaviour). We would like to preserve the
> current system as much as possible.

Can you provide some specific examples of this contextual overloading of
functions, so that I might understand this feature more clearly?
Pointers to relevant documentation would also be helpful.

> With the current svn you will not be able to build TeXmacs with Guile
> 2.0. If you are interested in that I will tell you how to do.

Please do.  I would like to try to build TeXmacs with Guile 2, so that I
may better help you with the transition to Guile 2.

     Thanks,
       Mark

Re: Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

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

Hi Mark,

 I've update the svn repository and now the build process should recognize Guile 2.0. To build TeXmacs you will need the Qt framework, freetype and of course Guile. A standard

./configure --enable-qt
make

should suffice. You car run TeXmacs without installing by telling it where to find resources. Assuming you are 
in the source directory, after the make the executable is to be found in TeXmacs/bin, so the followng is enough

TEXMACS_PATH=$PWD/TeXmacs TeXmacs/bin/texmacs.bin

Scheme scripts are in TeXmacs/progs. 

The custom module macro is defined in kernel/boot/boot.scm
TeXmacs functions are defined via the tm-define macro defined in kernel/texmacs/tm-define.scm 

An example of contextual overloading allowed by tm-define : (from kernel/math/math-edit.scm:44)

(tm-define (kbd-enter t shift?)
  (:require (tree-is? t 'equation))
  (go-end-of 'equation)
  (insert-return))

here we redefine the function kdb-enter in the case the :require condition results #t. The new definition is simply added by the tm-define macro at the top of the previous with a conditional statement. I do not know if this can cause interferences with compilation. 

General documentation about TeXmacs is written in the TeXmacs document format and you can find it in the TeXmacs help menu (Help->Scheme extensions). The documentation on the main web page (www.texmacs.org) does not contain the chapters about the scheme interface. 

Maybe we should continue this discussion in private, without polluting the mailing list.

Massimiliano

On Mar 11, 2012, at 9:38 PM, Mark H Weaver wrote:

> Gubinelli Massimiliano <m.gubinelli@gmail.com> writes:
>>> Why not convert your scripts to use the standard Guile module syntax?
>> 
>> TeXmacs is currently composed of 250 scheme files for \sim 60000 lines
>> of scheme.
> 
> Fair enough.  I see no obstacle to adapting the TeXmacs module system to
> work with Guile 2.  It's just a matter of finding the cleanest way to
> implement it.
> 
>> It has a slightly customized module system and features contextual
>> overloading of functions (a function can be redefined to act
>> differently is some condition is met without modifying the module
>> which implemented the base behaviour). We would like to preserve the
>> current system as much as possible.
> 
> Can you provide some specific examples of this contextual overloading of
> functions, so that I might understand this feature more clearly?
> Pointers to relevant documentation would also be helpful.
> 
>> With the current svn you will not be able to build TeXmacs with Guile
>> 2.0. If you are interested in that I will tell you how to do.
> 
> Please do.  I would like to try to build TeXmacs with Guile 2, so that I
> may better help you with the transition to Guile 2.
> 
>     Thanks,
>       Mark


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