Hello, I've committed the new internal of Guile Emacs which uses GOOPS. Now we have three primitive procedures: `%lisp-eval', `%lisp-apply', and `%lisp->scheme'. They work like this: (%lisp-eval '(current-buffer)) => #<foreign-object <emacs-buffer> 40457800> (eq? (%lisp-eval '(current-buffer)) (%lisp-eval '(current-buffer))) => #t (define buffer (%lisp-eval '(current-buffer))) (define name (%lisp-apply 'buffer-name (list buffer))) name => #<foreign-object <emacs-string> 403cf4b0> (%lisp->scheme name) => "*scratch*" So we are now ready to implement the new Emacs Scheme code that utilizes GOOPS: (define (buffer-string) (%lisp-eval '(buffer-string))) (define-generic substring) (define-method (substring (string <emacs-string>) start end) (%lisp-apply 'substring (list string start end))) (define-generic eval-string) (define-method (eval-string (string <emacs-string>)) (eval-string (%lisp->scheme string))) (eval-string (substring (buffer-string) 0 10)) For now, the old procedures (i.e., lisp-eval, lisp-apply, etc.) still exist, so this version should not break the existing Scheme code. After rewriting the code by using the new procedures, I'll remove the old procedures. (I'll be busy for more few days, so it will be after May 10.) Some additional changes from NEWS: *** Guile Emacs turns on Guile's debugging features at startup time if the command line option --debug-init is given. *** Guile Emacs now displays an error and backtrace in the *Message* buffer in detail when error-on-debug is non-nil. *** The Lisp functions `scheme-apply' and `scmref-to-lisp' are removed. Have fun! -- Kei
Hello, (This message is about Guile Emacs, but is also something about Guile in general.) I'm thinking of not using procedure-with-setter to refer to Lisp variables. The binding to Lisp variables is dynamic, and I'm not sure about the Guile's dynamic features. One Guile's (kind of) dynamic variable is fluid, which changes the value depending on the current dynamic root. A fluid uses fluid-ref and fluid-set! to access the value. I guess we'd better use the same way for Lisp variables. This is a GOOPS version of lisp-ref/set!: (define-class <lisp-variable> () (sym #:accessor sym #:init-keyword #:symbol) (var #:allocation #:virtual #:slot-ref (lambda (i) (%lisp-eval (sym i))) #:slot-set! (lambda (i v) (%lisp-eval `(setq ,(sym i) ',v)) *unspecified*) #:getter lisp-ref #:setter lisp-set!)) (define-method (write (obj <lisp-variable>) port) (display "#<lisp-variable " port) (display (sym obj) port) (display ">" port)) (define name (make <lisp-variable> #:symbol 'user-full-name)) name => #<lisp-variable user-full-name> (lisp-ref name) => #<foreign-object <emacs-string> 40480ce0> (%lisp->scheme (lisp-ref name)) => "Keisuke Nishida" The new Emacs Scheme code might look like this: (insert (lisp-ref user-full-name)) We could do the same thing more naturally by defining a procedure so as to accept <lisp-variable>: (define-method (insert (obj <lisp-variable>)) (insert (lisp-ref obj))) (insert user-full-name) However, this requires us to define similar methods for all procedures, which is practically impossible. In order to write the latter natural expression (in the sense of Emacs Lisp), I guess we have to modify the Guile's evaluator so that it handles special objects like this: (define foo (make-dynamic-object (lambda () (make-variable #f)) (lambda (variable) (variable-ref variable)) (lambda (variable value) (variable-set! variable value)))) foo => #f (set! foo "Hello") foo => "Hello" Using this object, a fluid can be written as (define foo (make-dynamic-object (lambda () (make-fluid)) (lambda (fluid) (fluid-ref fluid)) (lambda (fluid value) (fluid-set! fluid value)))) foo => #f (set! foo "Hello") foo => "Hello" and our Lisp reference can be written as (define foo (make-dynamic-object (lambda () 'user-full-name) (lambda (symbol) (%lisp-eval symbol)) (lambda (symbol value) (%lisp-eval `(setq ,symbol ',value))))) foo => #<foreign-object <emacs-string> 40480ce0> (set! foo "Hello") foo => #<foreign-object <emacs-string> 40480ce8> I asked about the Guile's new top-level environment if I could use it to do my job, but the answer was no. The environment also seems to be (kind of) static; that is, environment-ref/set! is called only once at evaluation time (not at run time). I believe make-dynamic-object can be implemented, but I'm not sure whether it is a good thing or not. What do people think? Thanks, -- Kei
Keisuke Nishida <kxn30@po.cwru.edu> wrote:
>I've committed the new internal of Guile Emacs which uses GOOPS.
I just tried it and noticed that M-x scheme-interaction-mode
didn't work with new Guile Emacs.
Here is a log:
% cvs update -dP
% (cd src/emacs-20.6 && cvs diff -c -r emacs_20_6) > emacs-20.6.patch
% rm -rf emacs-20.6
% tar zxf emacs-20.6.tar.gz
% tar zxf leim-20.6.tar.gz
% cd emacs-20.6
% patch -p0 < ../emacs-20.6.patch
% autoconf
% ./configure && make
% su
# make install
# cd ..
# rm -rf /usr/local/share/emacs/20.6/scheme
# mkdir /usr/local/share/emacs/20.6/scheme
# cp -ra emacs /usr/local/share/emacs/20.6/scheme
# exit
% cp .emacs.scm ~
% ldd /usr/local/bin/emacs
libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6 (0x40013000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4004e000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40061000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400ad000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400b6000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400cd000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400d9000)
libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40183000)
libm.so.6 => /lib/libm.so.6 (0x401c2000)
libc.so.6 => /lib/libc.so.6 (0x401de000)
libguile.so.8 => /usr/local/lib/libguile.so.8 (0x402d1000)
libgoopscore.so.3 => /usr/local/lib/libgoopscore.so.3 (0x40346000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libdl.so.2 => /lib/libdl.so.2 (0x40352000)
% emacs
Is there any wrong?
-- Satoru Takabayashi
Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > >I've committed the new internal of Guile Emacs which uses GOOPS. > > I just tried it and noticed that M-x scheme-interaction-mode > didn't work with new Guile Emacs. > > Here is a log: Did you try this? 4. Recompile patched Emacs Lisp files: % emacs -q -batch -f batch-byte-recompile-directory lisp > % cvs update -dP > % (cd src/emacs-20.6 && cvs diff -c -r emacs_20_6) > emacs-20.6.patch > % rm -rf emacs-20.6 > % tar zxf emacs-20.6.tar.gz > % tar zxf leim-20.6.tar.gz > % cd emacs-20.6 > % patch -p0 < ../emacs-20.6.patch If you extract the source files directly in guile-emacs/src, then you don't need to create a patch every time. I'll add a new file INSTALL.CVS for CVS users. -- Kei
Keisuke Nishida <kxn30@po.cwru.edu> wrote: >> Here is a log: > >Did you try this? > >4. Recompile patched Emacs Lisp files: > > % emacs -q -batch -f batch-byte-recompile-directory lisp Thank you for pointing this out. I forgot to do it when I reported. I just rebuilt Guile Emacs and the problem were solved. >If you extract the source files directly in guile-emacs/src, then >you don't need to create a patch every time. I'll add a new file >INSTALL.CVS for CVS users. OK, I extracted the source files of emacs-20.6.tar.gz in guile-emacs/src. It released me from creating a patch every time but I feel the installation is still rather troublesome. | 4. Recompile patched Emacs Lisp files: | | % emacs -q -batch -f batch-byte-recompile-directory lisp | | 5. Regenerate the configure script: | | % autoconf How about preparing `autogen.sh' in the CVS to automate these forgetful procedures? | 7. Install the "emacs" subdirectory to somewhere: | | # cd .. | # mkdir /usr/local/share/emacs/scheme | # cp -r emacs /usr/local/share/emacs/scheme Can it be done with `make install' as I proposed before? Probably, it is good to distribute Guile Emacs as an all-in-one package instead of patch files to emacs-20.6. People may have difficulty in installation and give up. -- Satoru Takabayashi
Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > How about preparing `autogen.sh' in the CVS to automate > these forgetful procedures? Good idea. I'll make it. > | 7. Install the "emacs" subdirectory to somewhere: > | > | # cd .. > | # mkdir /usr/local/share/emacs/scheme > | # cp -r emacs /usr/local/share/emacs/scheme > > Can it be done with `make install' as I proposed before? You can do "ln -s . /usr/local/share/emacs/scheme" instead if you want. > Probably, it is good to distribute Guile Emacs as an > all-in-one package instead of patch files to emacs-20.6. > People may have difficulty in installation and give up. Right, though I guess most users of Guile Emacs are good developers :) We can do so when we release Guile Emacs 1.0, but it is easier to distribute a small tarball for now. (I don't want to release over 10MB packages once a month.) -- Kei
Keisuke Nishida <kxn30@po.cwru.edu> wrote: >> Probably, it is good to distribute Guile Emacs as an >> all-in-one package instead of patch files to emacs-20.6. >> People may have difficulty in installation and give up. > >Right, though I guess most users of Guile Emacs are good developers :) Maybe true but I want more people to use Guile Emacs. I'm hooked on Scheme and propagate how Scheme is exciting to my colleagues everyday. They'll need Guile Emacs soon. :-) >We can do so when we release Guile Emacs 1.0, but it is easier to >distribute a small tarball for now. (I don't want to release over >10MB packages once a month.) Probably 10 MB packages don't count because more and more people have fast connections to the Internet nowadays. -- Satoru Takabayashi
Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > >Right, though I guess most users of Guile Emacs are good developers :) > > Maybe true but I want more people to use Guile Emacs. I'm > hooked on Scheme and propagate how Scheme is exciting to my > colleagues everyday. They'll need Guile Emacs soon. :-) That's my hope :) > Probably 10 MB packages don't count because more and more > people have fast connections to the Internet nowadays. I guess we should distribute binary packages (i.e., .rpm or .deb) instead of distributing a 10MB source package. We could distribute only a binary guile-emacs, scheme files, and some lisp files by requiring package managers to install other emacs-common files. -- Kei
Keisuke Nishida <kxn30@po.cwru.edu> wrote: >> Maybe true but I want more people to use Guile Emacs. I'm >> hooked on Scheme and propagate how Scheme is exciting to my >> colleagues everyday. They'll need Guile Emacs soon. :-) > >That's my hope :) Guile Emacs is an excellent environment for enjoying Scheme programming. I can be happy all the year alone on a desert island if I have a UNIX machine with Guile Emacs and the textbook called Structure and Interpretation of Computer Programs. Of course a desert island with the Internet connection is better. :) >> Probably 10 MB packages don't count because more and more >> people have fast connections to the Internet nowadays. > >I guess we should distribute binary packages (i.e., .rpm or .deb) >instead of distributing a 10MB source package. I have a friend of a rpm hacker. I ask him for the SPEC file for Guile Emacs. Once the SPEC file is created, you can easily build the rpm package with rpm command if you use Red Hat Linux. What's your platform, Keisuke? -- Satoru Takabayashi
Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > Guile Emacs is an excellent environment for enjoying Scheme > programming. I can be happy all the year alone on a desert > island if I have a UNIX machine with Guile Emacs and the > textbook called Structure and Interpretation of Computer > Programs. Of course a desert island with the Internet > connection is better. :) I guess you'll need the connection for a newer Guile Emacs :) > I have a friend of a rpm hacker. I ask him for the SPEC > file for Guile Emacs. Once the SPEC file is created, you can > easily build the rpm package with rpm command if you use Red > Hat Linux. What's your platform, Keisuke? That's great. I'm using RH 6.1. -- Kei