October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Question for bytecompiler gurus `require' and bytecompilation 26 years

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> ;;; bar.el --- do something interesting >> ... >> (require 'foo) >> ... >> ;;; bar.el ends here >> >> >> What difference (if any) does it make if foo.el (assuming foo.elc >> hasn't been bytecompiled yet) or foo.elc is loaded? > It should make zero difference (except for totally weird things), It's the "totally weird things" that I'm asking about. > as far as I know. What prompted you to ask that question? Why does it matter? I'm working on building XEmacs package Lisp. Did you read the message I posted earlier in the day about this? If loading .els and .elcs via `require' in bytecompilation are identical, then I can dispense with the order of bytecompilation requirement. I've done some testing of this in InfoDock, but it hasn't been particularly strenuous and hasn't reached a comfortable level of testing for me. NEWSFLASH: For all the people asking for `make install' for XEmacs lisp packages, I have a working make install target that I'm in the middle of committing to CVS.

1 participants
0 comments

Re: Question for bytecompiler gurus `require' and bytecompilation 26 years

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > ;;; bar.el --- do something interesting > ... > (require 'foo) > ... > ;;; bar.el ends here > > > What difference (if any) does it make if foo.el (assuming foo.elc > hasn't been bytecompiled yet) or foo.elc is loaded? It should make zero difference (except for totally weird things), as far as I know. What prompted you to ask that question? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Lost in Static 18 / And the storm is closing in now

1 participants
0 comments

Re: mailcrypt-3.5b7 test package 26 years

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > I've uploaded a test XEmacs package of Mailcrypt-3.5b7 which has > support for GNU Privacy Guard (the GNU PGP replacement) and PGP 5. This doesn't work very well, alas, but I'm working with the maintainer on an XEmacs and Gnus friendly update.

1 participants
0 comments

Re: Question for bytecompiler gurus `require' and bytecompilation 26 years

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > What's the difference between > > (require 'foo) > > when foo.el *only* is found, and foo.elc is found? I don't understand this question. AFAIK, (require 'foo) does something like this: (defun require (feature file) (unless (featurep feature) (load (or file (symbol-name feature))) (or (featurep feature) (error "%s not provided" feature)))) only the actual C version does additional load-history hacks. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

1 participants
0 comments

Question for bytecompiler gurus `require' and bytecompilation 26 years

SL Baur

What's the difference between (require 'foo) when foo.el *only* is found, and foo.elc is found?

1 participants
0 comments

Re: XEmacs 21.2-beta3-pre1/XEmacs 21.0-pre15-pre2 committed in CVS 26 years

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: ... APA> I ediff-ed it against my fairly up-to-date version, sorted APA> the same way. APA> The diffs are frightening: APA> package sizes are off by very few bytes. Consequently all APA> md5sums are different. > Steven, > I just checked a few packages in > /ftp＠ftp.xemacs.org:/pub/xemacs/packages: > and all sizes indicate package-get-base.el in Pyrenean-pre2 to be > wrong. > I'll try building now with my package-get-base-latest.el of yesterday. It's pretty clear I can't tell my head from my ass. O.K. package-get-base.el is getting `cvs remove'd immediately from the core and I'll think up some other method of keeping it straight.

1 participants
0 comments

Re: The tm* binaries should not live in core XEmacs 26 years

SL Baur

[Moved to xemacs-beta] William M Perry <wmperry(a)aventail.com> writes in xemacs-review(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org: >> >> [On May 16 of this year] >> >> > ... they should be part of the package. This also fixes the problem >> > that the binaries don't get picked up if you don't build in $(srcdir). >> >> I've finally made a decent method of dealing with scripts. The tm and >> Gnats scripts have been removed from the next XEmacs 21.0/21.2 releases. >> >> I still don't have a good idea what to do about "C" executables in the >> XEmacs package lisp context. William has proposed configure, but the >> solution for W3 works stand-alone and that's not what I want for building >> XEmacs distributions. > What do you mean standalone? Standalone in the sense that you can plop it down anywhere on a sytem with just a functional emacs and have it work. Standalone also in the sense that it carries around all the autoconf cruft files (config.sub, config.guess, configure.in, etc.). > The Emacs/W3 configure script could easily be chained as part of a > bigger group of programs by using something like this in a top-level > 'packages' source tree: > AC_CONFIG_SUBDIRS(w3 tm leim vm . . . ) > Autoconf is smart enough that if the subdirectory isn't there, then it > won't output it in the ＠subdirs＠ chunk in the Makefile. Have you looked at how I currently have the xemacs-packages directory hierarchy arranged? Here's a brief summary. * Major design goals ** Hierarchical in structure and grouped by major functionality. The top level of the structure looks something like: xemacs-packages/: comm/ games/ libs/ mule/ oa/ os/ prog/ wp/ Lisp packages are stored in the second level. For example, the games directory looks like: xemacs-packages/games/: cookie/ games/ mine/ misc-games/ where each of the directories represents a package. Each package is stored in CVS as a separate individual module. There are a number of `glue' files to paste everything together. xemacs-packages/package-compile.el handles setting up the load path and feeding .el files to the bytecompiler. xemacs-packages/XEmacs.rules common Makefile rules that are to be `include'd by each individual package Makefile. xemacs-packages/Makefile Top level Makefile responsible for calling sub-Makefiles. Each functional directory has a Makefile that calls each of the package Makefiles in turn. This is all complicated by the fact that order is important in compiling. The `xemacs-base', `fsf-compat', `mule-base' and various other packages are so frequently used as libraries by other packages that they need to be bytecompiled first. Thus it is not possible to blindly do a depth first walk of the tree (eg. in shell script: for group in *; do cd ${group} for package in *; do cd ${package} make done done ** Provide a clean room-type controlled environment for bytecompilation. It is a deliberate feature that the source directories are not directly usable as an XEmacs package run-time hierarchy. Rules for building individual packages bring in only the environment necessary for bytecompilation and everything else is ignored. In particular, except for core lisp, *all* of the XEmacs run-time Lisp in the binary being used for bytecompilation is ignored. Thus, barring radical changes in the bytecode, it should be possible a year from now to bootstrap a Lisp run-time for XEmacs 21.5 with an XEmacs 21.0 executable. ** The ability to issue single commands at the top level to perform building, cleaning, etc. At the current time, the working targets are `clean' -- wipe out .elcs, but not auto-autoloads.el and custom-load.el files, `distclean' -- wipe out everything except raw source, `bindist' -- generate a directory of binary package tarballs for distribution via ftp.xemacs.org. A planned, but currently unimplemented target is `install' -- bypass tarball generation and install directly into a run-time XEmacs package hierarchy. It is also planned that the `install' target be able to consult some kind of configuration to limit what gets installed. For example, it should be possible to have the VM (a random choice) package present as source but not installed into the run-time. ** The ability to gracefully handle missing modules to the extent possible. In other words, if the `gnus' package isn't present, toplevel commands shouldn't fail. ** The ability to deal with Mule -vs- Non-Mule builds. Non-Mule building should fail gracefully, but not otherwise impede progress. Everything described to this point except as noted has been implemented. My implementation is heavily dependent on GNU make and works in fairly un-make-like fashion except at the individual package level. Thus, if autoconf is up to the task, there is nothing conceptually prohibiting its usage other than my own almost-total lack of expertise with it. * Stuff that isn't being handled that should be. ** There is no good way to build binary executables. This has to be carefully thought out. There is a dual purpose that must be kept -- building for distribution must not build and include binaries but building for local use should. ** There is no good way to bootstrap 100% from source. That is, given an XEmacs core distribution tarball from ftp.XEmacs.org and given a fresh `cvs checkout' of all the XEmacs packages, there isn't a single command to issue to build everything. The steps would be roughly: 1. Configure XEmacs and build all the way to temacs. 2. Use temacs to build run-time packages of fsf-compat and mule-base (in that order) and install them into the directory being used to build XEmacs. 3. Go back to the core and create a dumped XEmacs binary, which will now work due to the presence of Mule elcs. 4. Go back to the package source area and wipe out the products of step 2. 5. Build the package world and install it into the location that the XEmacs binary will find it. 6. Make install in the XEmacs core. Note: this isn't very different than how XEmacs 20.4 is built from scratch. The temacs bytecompiling in step 2 is equivalent to running update-elc.el. ** single-file packages are not completely implemented. Packages labelled `single-file' are otherwise unrelated collections of independent Lisp files. It is intended by design that one may specify a subset of files in them and only build & install the subset. Implementing this is probably along the same lines as the subset install feature described above. What kind of magic can you do with autoconf to help? Any questions? :-)

1 participants
0 comments

Re: auto-save questions and suggestions 26 years

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Hrvoje> "c:\\Winnt\\Profiles\\AichnerA\\autosave\\#c:\\Winnt\\Profiles\\AichnerA\\N > Hrvoje> ews\\drafts\\drafts\\1#" > > Hrvoje> Is that the default? Why is auto-save-directory set to > Hrvoje> anything other than nil? It defaults to nil under Unix. > > Umpf! Thanks for pointing this out. As a service to he XEmacs > community I load sample.emacs from within my site-start.el and go > from there. This way I notice if some recommended practice changes > or sample.emacs breaks so some reason or other. sample.emacs > changes auto-save defaults. That is a very good and useful idea; thanks for doing that. > Yesterday I tried customizing the variables in question via > customize-variable but these customizations didn't show up in > .emacs. > > Today, encouraged by your mail, I tried again and all is just dandy! Strange... > >> (defcustom auto-save-directory nil > >> > >> ;; Don't make this user-variable-p, it should be set in .emacs > >> and ;; left at that. In particular, it should remain constant > >> across ;; several Emacs session to make recover-all-files work. > >> > >> ;; However, it's OK for it to be customizable, as most of the > >> ;; customizable variables are set at the time `.emacs' is read. > >> ;; -hniksic > >> > >> I fail to see how and why a user of the trusting kind should > >> have to figure out that his customization of > >> auto-save-directory (even though one can set it for the current > >> session) does not get saved in (custom-set-variables ...) > > Hrvoje> What on earth do you mean by that? Are you sure you > > I thought the comment indicated the variable couldn't be changed and > saved via customize. The comment wants to say that writing (setq auto-save-directory "something") ; or M-x set-variable ... in the middle of your session is a bad idea; you have to set the variable in .emacs for it to work consistently. So making it a user-option (user-options are variables the docstring of which begins with `*') would be wrong because it would "invite" people to set it interactively, which doesn't work. However, it does make sense to use Customize with that variable because the customization will be stored at the end of .emacs. So, in Customize, `Set' will not do the right thing, but `Save' will. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Idle RAM is the Devil's playground.

1 participants
0 comments

Re: auto-save questions and suggestions 26 years

Adrian Aichner

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> Hello auto-save experts! >> >> Having trouble with auto-save on Windows NT natively build >> XEmacs, I found some facts and more questions. >> >> --------------------------------------------------------------- >> auto-saving in XEmacs NT native build does not work by default: >> --------------------------------------------------------------- >> >> auto-save-directory "c:\\Winnt\\Profiles\\AichnerA\\autosave\\" >> >> will cause an illegal >> >> buffer-auto-save-file-name >> Hrvoje> "c:\\Winnt\\Profiles\\AichnerA\\autosave\\#c:\\Winnt\\Profiles\\AichnerA\\N Hrvoje> ews\\drafts\\drafts\\1#" Hrvoje> Is that the default? Why is auto-save-directory set to Hrvoje> anything other than nil? It defaults to nil under Unix. Hello Hrvoje, Umpf! Thanks for pointing this out. As a service to he XEmacs community I load sample.emacs from within my site-start.el and go from there. This way I notice if some recommended practice changes or sample.emacs breaks so some reason or other. sample.emacs changes auto-save defaults. Yesterday I tried customizing the variables in question via customize-variable but these customizations didn't show up in .emacs. Today, encouraged by your mail, I tried again and all is just dandy! All the customizations are there: cd C:\Winnt\Profiles\AichnerA\ egrep -ni "auto-save|custom" .emacs NUL Compilation started at Sun Oct 11 23:15:54 1998 .emacs:124:(custom-set-variables .emacs:137: '(auto-save-timeout 30 t) .emacs:168: '(auto-save-interval 100) .emacs:170: '(auto-save-directory nil) .emacs:200: '(auto-save-file-format t) .emacs:262: '(auto-save-offer-delete t) grep finished (22 matches found) at Sun Oct 11 23:15:55 My analysis of what happened yesterday is this: I probably had set the variables with set-variable before invoking customize-variable. Since custom didn't change the variable, it didn't care to save it when I pushed the "Save" button. We can write this off as a cockpit error, I guess. Thanks for your help, Hrvoje! Adrian Hrvoje> Perhaps under Windows we should default `auto-save-hash-p' Hrvoje> so that setting `auto-save-directory' works? But I don't Hrvoje> like doing that if there is another solution, because the Hrvoje> docs say that auto-save-hash-p defeats Hrvoje> `recover-all-files'. Thanks for pointing this out. I agree that nil is a good default worth keeping. >> Workaround: Setting auto-save-directoy to nil, which makes >> files being auto-saved in the same directory as >> buffer-file-name, making file names legal when TEMP or TMP >> contain a drive spec. Hrvoje> That "workaround" is actually the default behaviour under Hrvoje> Unix. >> Question: How could this problem be fixed? I suppose >> buffer-auto-save-file-name should have any embedded drive:\ or >> \\computer-name component stripped? Hrvoje> No, because then you wouldn't be able to differentiate Hrvoje> between the autosave for c:\foo and the autosave for Hrvoje> d:\foo. Yep. >> (defcustom auto-save-directory nil >> >> ;; Don't make this user-variable-p, it should be set in .emacs >> and ;; left at that. In particular, it should remain constant >> across ;; several Emacs session to make recover-all-files work. >> >> ;; However, it's OK for it to be customizable, as most of the >> ;; customizable variables are set at the time `.emacs' is read. >> ;; -hniksic >> >> I fail to see how and why a user of the trusting kind should >> have to figure out that his customization of >> auto-save-directory (even though one can set it for the current >> session) does not get saved in (custom-set-variables ...) Hrvoje> What on earth do you mean by that? Are you sure you I thought the comment indicated the variable couldn't be changed and saved via customize. This was probably due to my cockpit error, described above. Hrvoje> understood the quoted comment? Probably not. >> Only by looking at the above source-code will one get the hint >> that one has to (setq auto-save-directory nil) in ones .emacs >> file. Hrvoje> `M-x customize-variable RET auto-save-directory RET' Hrvoje> should also work. Yes, it does today, now that I did it right. >> Question: Why shouldn't the following initialization code for >> auto-save-interval >> >> (put 'auto-save-interval 'custom-type 'integer) (put >> 'auto-save-interval 'factory-value '(300)) (custom-add-to-group >> 'auto-save 'auto-save-interval 'custom-variable) >> >> be made into a plain (defcustom ...)? Hrvoje> Is `defcustom' defined at the time auto-save is loaded? Dunno. >> Question: Why can't auto-save-timeout be a (defcustom ...) Hrvoje> auto-save-timeout *is* a customizable variable. I'm not Hrvoje> sure why it's not initialized via `defcustom'. However, Hrvoje> `M-x customize-variable RET auto-save-timeout RET' will do Hrvoje> the right thing. Same as above. This works fine. Hrvoje> -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Hrvoje> Zagreb, Croatia Hrvoje> --------------------------------+-------------------------------- Hrvoje> If anything goes wrong, blame the random-number generator! -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: auto-save questions and suggestions 26 years

Adrian Aichner

>>>>> "Sean" == Sean MacLennan <seanm(a)storm.ca> writes: Sean> FWIIW, here is my the code from my .emacs as it pertains to Sean> auto-save. Thanks Sean! I tried it and it works. Hrvoje just pointed out hat auto-save-hash-p defeats recover-all-files, a feature I don't want to be without. Having the autosave files scattered around on slowing performance for remote files is the lesser evil for me right now. Regards, Adrian Sean> It has been a long time since I messed with it (since April Sean> according to the changelog). As the comment says, I could Sean> only get auto-save running under NT by using the hash Sean> mode. I cannot remember what the problem was..... -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta October 1998