November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: vfork revisited (was 64bit clean XEmacs) 26 years

Hrvoje Niksic

Marcus Thiessel <marcus(a)xemacs.org> writes: > | I believe Linux has something like this. I looked at under the covers > | and saw the do_fork() in the kernel takes a clone_flags argument which > | can control fairly precisely what gets duplicated in the child. > > I thought the clone was implemented for the use with kernel threads. Well, my (old and outdated) 2.0 Linux system documents clone(2) in some detail, so its use must transcend "use with kernel threads". Hopefully it has developed since the 2.0 kernel, since the flags it accepts appear to be quite sparse: pid_t clone(void *sp, unsigned long flags) DESCRIPTION clone is an alternate interface to fork, with more options. fork is equivalent to clone(0, SIGCLD|COPYVM). If sp is non-zero, the child process uses sp as its ini tial stack pointer. The low byte of flags contains the signal sent to the par ent when the child dies. flags may also be bitwise-or'ed with either or both of COPYVM or COPYFD. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Old numerical analysts never die, they just get disarrayed.

1 participants
0 comments

Re: XEmacs package web pages 26 years

Jan Vroonhof

[I am cc'ing xemacs-beta as I just realised that this mail is probably the best documentation there is currently] > I am basically trying to make sure that the reftex package > distribution is OK and works. AFAIK can see (at the moment I don't TeX that much) it works OK. The biggest open question would be how it works under Windows. The biggest problem of the package system is run-time depencies. However Reftex does not require any special stuff. > I also want to find out if it will be usefull or necessary to > document the installation procedure in the info files for RefTeX (to > achieve a state of laziness is the sense of Larry Walls definition). Well there are actually two installation procedures 1. Physically installing it and making sure XEmacs finds it (load paths, autoload). The package system reduces this to "untar the file in the right directory" or "click on the right line in the package install tool." (Basically by shifting the burden to the package creator). 2. Activating the packages. This remains the same, i.e. adding reftex to LaTeX mode hook. > Right now the installation instructions cover only the cases when > someone download the package from my own web page, or when the package > is bundled with X/Emacs. Well depending on whether you want to make a RefTeX package available yourself you can suffice with "See XEmacs 21.0 instructions on how to fetch the reftex package" or with "XEmacs 21.x users want to get the *-pkg.tar.gz tarball and untar it in ../lib/xemacs-packages and then call M-x package-admin-install-binary-package RET." after that you can procees as if RefTeX was bundled. > - How will this packaging stuff work in the end? Is there any > documentation available on the package system itself, and how the > average user is going to interface with it? There is currently (slightly outdated) user info in the XEmacs manual, which basically tells the user where to ftp the files and where to untar them or alternatively how to use XEmacs (via the menu) to fetch it for them. Since recently XEmacs can also automatically remove packages (this is needed for automatic upgrading). There is some documentation on how to build a package yourself but that is so outdated it is not helpfull. As soon at is sure that the current system is stable (which apart from Steve having more important problems to solve is the reason there has been no XEmacs 21.0 release yet) we will update the info files. > I have seen the > autoload file in the package - will that be read automatically on > startup? The structure of a package is as follows Special directories lisp/package-name/ is put in the load-path. For reasons of speed subdirectories are NOT included by default. etc/package-name/ is put the data-directory-list lib-src/package-name/ is put in the PATH used for subprocess. man/packagename/ is just used to store the texi sources for printing. special files pkg-info/package-name.MANIFEST contains a list of all the packages files info/package-name.info is added to the 'dir' file automatically at startup. The 'direntry' is used for this. lisp/auto-autoloads.elc is loaded automatically at startup. It is used to - provide package data (see _pkg.el) - Define autoloads, defvars and defcustoms. - execute other code (for instance to define a global menu entry or keybinding) It provides the feature '<package-name>-autoloads'. lisp/custom-loads.elc is loaded by custom to build the menus. lis/_pkg.el contains the package indentification. This loaded by the automatic install tools after installation to update the list of installed packages. Note that auto-autoloads.elc is NOT loaded after an install. An Emacs restart is needed load it. The info in _pkg.el is normally duplicated in the auto-autoloads file. lisp/auto-autoloads.el?, lisp/custom-loads.el? and info/package-name.info* are usually automatically generated in the package build process. To make sure your sources can be used as XEmacs packages you have to make sure 1. You have the right autoload cookies. 2. You used locate-data-file and locate-data-dir to find 'etc' stuff 3. All files with defface, defcustom and defgroup entries do not change the state of Emacs when loaded. 4. Your info files contain '＠direntry's. > - Will there be a place where the available packages are intruduced > with a short paragraph or so? A short description is indented to be in the etc/PACKAGES file in the distribution. However this currently very dated (for instance is does not mention the reftex package). I think this will be pulled before release. It is much better make some Web pages introducing the packages on www.xemacs.org. The current data the user sees in the install tool is generated from an entry like this (reftex (standards-version 1.0 version "1.09" author-version "3.41" date "1998-08-11" build-date "1998-10-11" maintainer "Carsten Dominik <dominik(a)strw.LeidenUniv.nl>" distribution stable priority medium category "wp" dump nil description "Emacs support for LaTeX cross-references, citations.." filename "reftex-1.09-pkg.tar.gz" md5sum "c7c12198809741e20431cf14a6b965c4" size 204664 provides (reftex) requires (fsf-compat xemacs-base) type regular )) With comments (reftex Name of package (standards-version 1.0 Version number of index info version "1.09" Version of the package (compared as floating point nummer to see whether an update is needed). author-version "3.41" For package containing a single elisp "program". The version of that program. date "1998-08-11" I think this is the release/fetch date of the origional build-date "1998-10-11" ...of the XEmacs package. maintainer "Carsten Dominik <dominik(a)strw.LeidenUniv.nl>" obvious distribution stable Currently this is rather undefined. If it is 'unstable' then it will not be included in the SUMO tarball (that includes all package for easy downloading). If it is 'mule' this means that it only usefull for mule users and needs a MULE enabled XEmacs. It will then be put in the 'mule-packages' package tree by the installation tools. That tree is only searched by 'mule' XEmacsen and therefore can contain package that break non-mule XEmacsen. Currently 'stable' and mule are reserved for packages that are distributed from the XEmacs ftp site. priority medium Priority 'high' means 'essential for normal operation' the other have no clear defined meaning. category "wp" dump nil Whether this package needs to be dumped with XEmacs. Currently only true for the mule-base package. description "Emacs support for LaTeX cross-references, citations.." This is currently the only description the users see. filename "reftex-1.09-pkg.tar.gz" md5sum "c7c12198809741e20431cf14a6b965c4" md5sum of the tarball. This is verified by the automatic install. (note that these index entries come from a PGP signed file). size 204664 of the tarball I think. provides (reftex) Features provided by the elisp included. requires (fsf-compat xemacs-base) Features needed for a succesfull compilation. Note NOT at runtime. type regular type = regular. All the files in this package belong together and may require each other at runtime. type= single. The .el? files in the package are independent and each may safely be deleted without impairing operation of the others. It is unlikely you will be making a 'single' package if you are not an XEmacs maintianer. > A list a user can brouse? Autogenerated from the above info entries. The reftex line looks like this reftex 1.09 1.09 Emacs support for LaTeX cross-references, citations.. The left number is the latest version and the right number the installed version. Aditional info appears in the modeline when the cursor is put over it. > If yes, > who is writing these entries, The XEmacs maintainer. He then pgp signs that list and puts it in pub/packages/package-index.LATEST.pgp on the ftp site. It is also supposed to be included in the etc dir of each XEmacs release. > what format do they have and should I > write something for RefTeX. Maybe you should write someting for the website when we get arround to makeing it. > - You say there is a history of XEmacs-beta. Is there a search engine > somewhere which has access to that history? I one looked and only > found a non-searchable archive which took forever to find anything. > (xemacs-beta is just too much for me to read regularily...) I am afraid it is not searchable currently. I am already happy it is archived at all. Jan

2 participants
1 comments

Re: [PATCH] games package 26 years

Adrian Aichner

>>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> Adrian Aichner wrote: >> there is a hard dependency on X windows in gamegrid.el >> >> Author version: 1.04 1998-06-04: Glynn Clements >> <glynn(a)sensei.co.uk> >> >> Here is a fix for that. Glynn> OK, thanks. >> Now tetris starts under Windows native build with >> >> Control Panel Display Settings Font Size: Large Fonts >> >> However, there are gaps between the individual lines that make >> up the tetris frames. Glynn> Hmm. That's exactly what this code was designed to Glynn> prevent. It keeps calling x-find-smaller-font until it gets Glynn> one which is smaller than the glyphs. Glynn> Does font-height work correctly on MS-Windows? (I don't Glynn> have an MS-Windows setup to test this on, so I can't tell). Hi Glynn, turns out (font-height ...) is broken on mswindows[1] ... (set-face-font 'default "Courier New:Regular:10") (font-height (face-property 'default 'font)) 16 (set-face-font 'default "Courier New:Regular:8") (font-height (face-property 'default 'font)) 14 Adrian Glynn> The value which it returns should be the line spacing in Glynn> pixels when all text is in that font. If the function Glynn> indicates that the font is smaller than it really is (in Glynn> terms of line spacing), then gamegrid will end up choosing Glynn> too large a font. Glynn> -- Glynn Clements <glynn(a)sensei.co.uk> Footnotes: [1] emacs-version "21.0 \"Pyrenean-pre6\" XEmacs Lucid"

2 participants
1 comments

Re: pcl-cvs buglet 26 years

Greg Klanderman

Thanks for the report. I've fixed it and the change will appear in package version 1.37. greg >>>>> "Michael" == Michael Kifer <kifer(a)cs.sunysb.edu> writes: Michael> Michael> In cvs-edit-mode, cvs-edit-mode isn't set according to the rules: Michael> (kill-all-local-variables) is missing, which minorly breaks some things Michael> (like viper).

2 participants
2 comments

Spurious "file has changed on disk" warnings on Linux 26 years

Charles G Waldman

Running XEmacs "Pyrenean-pre6" running on a Linux machine, visiting files NFS-mounted from a Linux server gives lots of spurious "file has changed on disk" warnings. I have been looking at fileio.c and found two different ways of fixing this problem, but I'm not sure which one is the Right Way. Fix #1: Cause HAVE_FSYNC to be #defined. src/sysfile.h says: #if !defined (USG) && !defined (WINDOWSNT) # define HAVE_FSYNC #endif Since s/linux.h #defines USG, the result is that HAVE_FSYNC is not defined and the fsync in write-region internal (at line 3331 in fileio.c) is not being done. Changing src/sysfile to read #if defined (LINUX) || !defined (USG) && !defined(WINDOWSNT) causes the fsync to be done, and makes the problem go away. But shouldn't the check for HAVE_FSYNC be handled by configure? Fix #2: Change order of close and stat Beginning at line 3340 in fileio.c is the following block of code. VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV /* Spurious "file has changed on disk" warnings have been observed on Suns as well. It seems that `close' can change the modtime, under nfs. (This has supposedly been fixed in Sunos 4, but who knows about all the other machines with NFS?) */ /* On VMS and APOLLO, must do the stat after the close since closing changes the modtime. */ /* As it does on Windows too - kkm */ #if !defined (WINDOWSNT) /* !defined (VMS) && !defined (APOLLO) */ fstat (desc, &st); #endif /* NFS can report a write failure now. */ if (close (desc) < 0) { failure = 1; save_errno = errno; } /* Discard the close unwind-protect. Execute the one for build_annotations (switches back to the original current buffer as necessary). */ XCAR (desc_locative) = Qnil; unbind_to (speccount, Qnil); } #if defined (WINDOWSNT) /* defined (VMS) || defined (APOLLO) */ stat ((char *) XSTRING_DATA (fn), &st); #endif ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Changing the order of the close and stat, as is done for WINDOWSNT, also eliminates the spurious warnings. (Why are the VMS and APOLLO cases commented out?) I will submit a patch for this problem to xemacs-patches, as soon as I know which of these two fixes is the "right" one - should I be fsync'ing, or should I be fstat'ing after the descriptor is closed?

1 participants
0 comments

pcl-cvs buglet 26 years

Michael Kifer

In cvs-edit-mode, cvs-edit-mode isn't set according to the rules: (kill-all-local-variables) is missing, which minorly breaks some things (like viper). --michael

1 participants
0 comments

Re: Bugs in 21.2 Beta 3 26 years

Jan Vroonhof

[I am not really sure what version of the package patches you have, I'm assuming the latest patches since atleast some of them seem to have gone in.] Heiko Muenkel <muenkel(a)tnt.uni-hannover.de> writes: > There's a bug in the function `pui-install-selected-packages'. Wrong > arguments are given to `package-get'. The following patch fixes > that. It adds also some usefull comments to the variable > `pui-package-install-dest-dir'. In my mind this variable should have a > usefull default, even if you've no packages installed. It has a usefull default. Namely 'nil'. This will cause 'nil' to be passed to the pkg-dir argument of this function. This should guess a good path in all cases. Did this guess wrong for you? (defun package-admin-get-install-dir (package pkg-dir &optional mule-related) "If PKG-DIR is non-nil return that, else return the current location of the package if it is already installed or return a location appropriate for the package otherwise." (if pkg-dir pkg-dir (let ((package-feature (intern-soft (concat (symbol-name package) "-autoloads"))) autoload-dir) (when (and (not (eq package 'unknown)) (featurep package-feature) (setq autoload-dir (feature-file package-feature)) (setq autoload-dir (file-name-directory autoload-dir)) (member autoload-dir late-package-load-path)) ;; Find the corresonding entry in late-package (setq pkg-dir (car-safe (member-if (lambda (h) (string-match (concat "^" (regexp-quote h)) autoload-dir)) late-packages)))) (if pkg-dir pkg-dir ;; Ok we need to guess (if mule-related (package-admin-get-install-dir 'mule-base nil nil) (car (last late-packages))))))) > 5. Bug (Minor): > The command `pui-list-packages' won't work, if you've no internet > access (no access to a package source directory). In my mind it should > display the list of installed packages and/or a hint, that an update > isn't possible, because there's no access to a package source directory. I am beginning too doubt 21.2 beta3 has the latest package patches now. They should fall pack to a local list. (the one included in the distribution). Is there a package-index.LATEST.pgp file in your /etc directory? > Comparison between integer and character is constant nil (50 and ?m) > [ispell-command-loop, byte-code, <compiled-function of unknown origin>, call-interactively] > I'm sorry, but I don't know how to reproduce this message. This a so called 'ebola' warning which tries to catch MULE related bugs. In this case trying to compare an integer and a character using 'eq' which used to work but doesn't now. In this case it is looks real. However I cannot find it here in ispell.el. Do you have an old version lying around somehwere? If not what does C-h v ispell-int-char give in your case? Jan

1 participants
0 comments

Re: Is 21.x going to be 64-bit clean? 26 years

Gunnar Evermann

Olivier Galibert <galibert(a)pobox.com> writes: > On Tue, Nov 03, 1998 at 05:15:37PM +0000, Gunnar Evermann wrote: > > On Tue, 3 Nov 1998, Olivier Galibert wrote: > > > I know that one. It smells like a compiler bug. > > > > > > Please try compiling with --use-union-type and tell us if it changes a > > > thing. > > > > or even better: run under dbx and find out where it is hanging. If it's a > > bug in XEmacs, we're happy for the info; if it is a bug in cc, SUN is > > happy, for the testcase... > > Out of curiosity, may I know what makes you think your approach would > be better? Uhm, sorry, no offence intended, maybe I misunderstood yur advice. I admit, I have never seen (or heard of) the above symptoms/bug, so maybe I shouldn't have commented. It's just that I feel that it's dangerous to have a separate set of required configure switches for each build environment. I remember the last time Georg tried builds on 2.7 (64bit I think). He got weird crashes (which I (but apparently nobody else) could reproduce on 2.6). Somebody remarked that he had no problems on Solaris when using 'some-combination-of-uniontype-minimal-tagbits-whatever' which proved true for Georg (and me) as well. We could very well have left it at that, but there was still a bug in XEmacs which I finally tracked down. If we find some kind of reproducable problem/crash we should IMHO track it down and not try to find some configure incantation to cover it up. (Actually I think we already had this debate some time ago). IMHO (reproducible) core dumps are the best thing for the developers. If we suspect a compiler bug, we should try to pinpoint it and contact the vendor. If this was indeed the plan, I apologize and stay out of this debate with my 'smart remarks' :-) In this special case I was hoping, if it was really a compiler bug, Charles was in a much better position to get it fixed than any of us. Gunnar

2 participants
1 comments

Re: Is 21.x going to be 64-bit clean? 26 years

Charles Stephens

>>>>> "OG" == Olivier Galibert <galibert(a)pobox.com> writes: OG> On Tue, Nov 03, 1998 at 02:30:28AM -0800, Charles Stephens wrote: >> Yes, XEmacs does compile as a 32-bit application just fine. As a >> 64-bit application, it compiles (after some electroshock therapy: >> 64-bit libaudio, compiling other support libraries for 64-bits, etc.) >> however it hangs at the following point of the make (this is a 20.4 >> example, but the same occurs with 21.x): >> >> EMACSLOADPATH="/public/Users/cfs/Build/xemacs-20.4/src/../lisp/prim" ./temacs -batch -l ../prim/update-elc.el >> >> Loading ../prim/update-elc.el... >> Loading /public/Users/cfs/Build/xemacs-20.4/src/../lisp/prim/dumped-lisp.el... >> >> temacs does not do any system calls, it just spins eating 100% of the >> CPU. OG> I know that one. It smells like a compiler bug. OG> Please try compiling with --use-union-type and tell us if it changes a OG> thing. I don't think that option works with cc. cfs -- Charles F. Stephens = cfs AT eng.sun.com Software Psychic and Illuminary = Solaris Network Sustaining = "We know what you buy, we know where you Solaris Software = live." -- Wesayso Corp. Sun Microsystems, Inc. = Menlo Park, California, USA =

2 participants
1 comments

Re: Concatenating of directory strings 26 years

Hrvoje Niksic

Heiko Muenkel <muenkel(a)tnt.uni-hannover.de> writes: > I'm asking, because I think, that without such a function code like > the following > (concat dir1 "/" dir2) How about: (expand-file-name dir2 dir1) The order is a bit counter-intuitive, but this should always work, even on systems where `(concat (file-name-as-directory dir1) dir2)' would fail. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Depression is merely anger without enthusiasm.

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 November 1998