HDTenEightyP/NetNews huggingface dataset:
From: wolfgang@wsrcc.COM (Wolfgang S. Rupprecht)
Subject: Re: Help: Decstation malloc returns too big value.
Organization: W S Rupprecht Computer Consulting, Fremont CA
Distribution: gnu
Date: Tue, 7 Apr 1992 21:47:36 GMT

ishikawa@ds5200. (Chiaki Ishikawa) writes:
>It seems that occasionally, malloc does return a value larger than
>0xFFFFFF. (I checked the return value in malloc.c by masking it with
>0xFF000000.)
>When this happens, after being stored into a lisp cell, and then
>retrieved to generate an address, the address ends up with an invalid
>(meaningless) value.

Well, you can rip out the quaint tag-in-the-address logic and put the
tag in the lisp structs itself.  Unless I'm missing some major gotcha
this should only take a week or so.

The one minor complication is that lisp integers either have to be
turned into real lisp structs or at least one bit of tag needs to be
allocated to differentiating integers from other lisp types.  Turning
lisp integers into a real storage containing type, *could* cause lots
more cons-ing to take place.  Every time one incremented a number, a
new cell would then get allocated.

Another advantage of getting the 8-bit tag out of the integer's
storage is that one can have bigger integers.  This in turn means that
one can look at bigger files.  Right now, 8 megs (total) is the limit.
If the tag were dumped elsewhere one would have enough addressing to
edit 1-2 gig files.  (Of course, one would need quite a bit of swap
space and patience if one really wanted to edit files that large.
Emacs tries to read in the whole file before it gives control back to
you.)

If someone is interested in funding this work - let me know.  It
shouldn't take more than a week of hacking.  (The result will naturely
be contributed to the FSF.)

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511

Newsgroups: gnu.emacs.bug
From: rms@ccv.FR (Richard M. Stallman)
Subject: Help: Decstation malloc returns too big value.
Reply-To: rms@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 16:15:52 GMT

	i would be happy if emacs would simply figure out that it had
	a problem when trying to read files that are too large, 
        and then told me to give up.

I made this change more than a year ago.
Are you using the current version, 18.58?


Newsgroups: gnu.emacs.bug
From: kyle@uunet.uu.net (Kyle Jones)
Subject: Re: tagging schemes (was Re: Help: Decstation malloc returns too big value.)
Organization: UUNET Technologies, Inc
Distribution: gnu
Date: Fri, 10 Apr 1992 18:59:57 GMT

wolfgang@wsrcc.COM (Wolfgang S. Rupprecht) wrote:
 > Well, you can rip out the quaint tag-in-the-address logic and put the
 > tag in the lisp structs itself.  Unless I'm missing some major gotcha
 > this should only take a week or so.

jwz@lucid.com (Jamie Zawinski) writes:
 > Making lisp integers be compound structures is a really bad idea.
 > [explanation]

What I wonder is whether the memory saved is worth the complexity
in determining types and all the bit masking that's needed to get
usable pointers.


Newsgroups: gnu.emacs.bug
From: jimb@occs.cs.oberlin.edu (Jim Blandy)
Subject: Bug report for emacs 18.58
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 17:35:55 GMT

>> The Emacs 19 Makefile offers a variable called `lisppath', which is a
>> colon-separated list of directories for Emacs to search for lisp.
>> Suppose we added another (yet another!) variable to set, perhaps
>> called `buildlisppath', which is prepended to `lisppath' when Emacs is
>> dumping; it would default to "../lisp", and you could change it to
>> "/p/emacs/lisp/hut:../lisp".
>> 
>> How does that sound?
>
>Hmm, looks a bit too complicated to me - I'd have to change two
>variables.
>
>How about this: have just one variable, extralisppath or something
>like that which is added before the /p/emacs/lisp directory.

Actually, this procedure involves two variables, too.  extralisppath
is one, and "/p/emacs/lisp" has to come from another variable, right?

Newsgroups: gnu.emacs.bug
From: palmerp@math.orst.edu (Paul A Palmer)
Subject: Re: autosave protection
Reply-To: palmerp@math.orst.edu
Organization: Dept. of Math, Oregon State University
Distribution: gnu
Date: Wed, 15 Apr 1992 21:01:11 GMT

In article <m0lZGcV-0001BuC@fly.cnuce.cnr.IT> pot@fly.cnuce.cnr.it (Francesco Potorti`) writes:

   I agree this is a SERIOUS problem.  Probably it would be enough to set
   mode 600 for all autosave files

Can this be done? If so, would someone please tell me how? 
I just reread the info pages on autosave files, but it's not mentioned there. 

--
Paul Palmer
Department of Mathematics     	E-mail: palmerp@math.orst.edu
Kidder Hall 368
Oregon State University, Corvallis, Oregon 97331-4605

	 "It's moving so fast, it's standing still." - William Gibson

Newsgroups: gnu.emacs.bug
From: Mark.Easter@fsi-ssd.UUCP
Subject: 18.57 bug report
        marke%fsi-ssd@uunet.uu.net <fsi-ssd!marke@uunet.uu.net>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 12:41:50 GMT

dispnew.c is dependent on lisp.h but the dependency is not provided for
in ymakefile; therefore, when using RCS for configuration management
and a make is done in a "clean" emacs filesystem, lisp.h won't be
checked out and an error occurs.

The same problem exists for x11term.c which is dependent on sinkll.h
and sinkllmask.h.

The same problem exists for dired.o which is dependent on regex.h.

The same problem exists for unexec.o which is dependent on getpagesize.h.

Additional background:

We run in a multiplatform environment and are currently supporting gnu
software on the Concurrent (formerly Masscomp) 8000, Harris 1000 and
4000, IBM 6000, and a variety of Sun systems.  All gnu software is in a
single filesystem which is remote mounted on all systems on the
network.  All gnu software is immediately loaded into RCS upon
installation, symbolic names are assigned to platform specific
variants, ie. ci -f18.57.1 -nAIX config.h, and each directory is
rcsclean"ed".  When building a package, we have a makefile that
determines the platform it is executing on, checks out the platform
specific modules, and the recursively starts the gnu Makefile to build
the appropriate variant and install it in the appropriate place in the
filesystem.  RCS automatically checks out all non-variant modules as
they are referenced during the make process.  In this environment,
incomplete specification of dependencies results in required modules
not being checked out and associated compilation errors. 

This is, admittedly, a small thing, and I don't mind making the changes
to ymakefile and etc. each time a new rev comes out.  Do you want
problems like this reported or would you rather not be bothered?

I also have a s-rtu.h and m-ccc8000.h for the Concurrent 8000 series,
and a s-cx_ux.h and m-m88k.h for the Harris 4000 series systems.  Would
you like me to send these along?

Lastly, is there any projection for when the next rev of emacs is due
out?  Is there a way to know if a gnu package has been revised without
constantly checking uunet's ls-lR.Z, ie. a news group or something
where this information is posted?

Thanks
Mark Easter
uunet!fsi-ssd!marke

Newsgroups: gnu.emacs.bug
From: byrd@comp.vuw.ac.nz (Mike Williams)
Subject: Re: Fix to defvar of lpr-command
Organization: Victoria University of Wellington, New Zealand.
Distribution: gnu
Date: Thu, 9 Apr 1992 00:06:36 GMT

>>> On Tue, 7 Apr 1992 12:50:43 GMT,
>>> "SG" == gildea@expo.lcs.mit.edu (Stephen Gildea) writes:

SG> You probably only use a few values of lpr-command, right?  So you
SG> might find it even more convenient to define a few interactive
SG> commands that setq lpr-command.  For example:

SG> (defun set-enscript ()
SG>   "Set lpr-command to enscript."
SG>   (interactive)
SG>   (setq lpr-command "enscript"))

  Or even provide a function which will complete on a list of
  possibilities: 

    (defvar possible-lpr-commands '("lpr" "enscript"))
    
    (defun set-lpr-command (COMMAND)
      (interactive
       (list (completing-read (format "Lpr command (%s): " lpr-command)
                              (mapcar 'list possible-lpr-commands)))
       (if (and COMMAND (not (string= COMMAND "")))
           (setq lpr-command COMMAND))))

    /---------------------- byrd@comp.vuw.ac.nz ----------------------\
    | Mike Williams, Computer Science, Victoria University, Aotearoa. |
    \------------ My words, which are mine, belong to me. ------------/

Newsgroups: gnu.emacs.bug
From: grabiner@zariski.harvard.edu (David Grabiner)
Subject: Supercite bug: sc-fill-paragraph must set mark
Organization: Harvard University Dept. of Mathematics
Distribution: gnu
Date: Wed, 8 Apr 1992 02:41:10 GMT

I reported this bug previously; I have now tracked it down.

I am using Supercite 2.1, VM 5.31, and GNUS 3.13 under GNU Emacs 18.57.3
on a Sun 4.

The command C-c C-q (sc-fill-paragraph-manually) sometimes dies with a
"Wrong type argument: integer-or-marker-p, nil" error, usually when I am
replying to a message in VM.  The cause is an attempt to scan the region
when no mark is set; the fix should be to mark the current paragraph
when you run sc-fill-paragraph or sc-fill-paragraph-hook.

Here are what appear to be the offending lines, with the fix indicated.

(defun sc-fill-paragraph-manually (arg)
  "Fill current cited paragraph.
Really just runs the hook sc-fill-paragraph-hook, however it does set
the global variable sc-fill-arg to the value of ARG.  This is
currently the only way to pass an argument to a hookified function."
  (interactive "P")
  (setq sc-fill-arg arg)
  (run-hooks 'sc-fill-paragraph-hook))

(defun sc-fill-paragraph ()
  "Supercite's paragraph fill function.
   (more documentation deleted)"
  (save-excursion
    ;; (mark-paragraph) needed here!
    (let ((pnt (point))
	  (fill-prefix (sc-guess-fill-prefix)))

(defun sc-guess-fill-prefix ()
  "Guess the fill prefix used on the current line.
   (more documentation deleted)"
  (save-excursion
    ;; scan for first non-blank line in the region
    (beginning-of-line)
    (while (and (< (point) (mark))
		(eolp))
      (forward-line 1))

Here is a backtrace which shows the error that occurs: (the indented
line was part of the byte-code line in the trace, but I separated it so
that news programs which lose the byte-code won't lose the cleartext on
the same line)

 (wrong-type-argument integer-or-marker-p nil)
  <(159 nil)
  (and ...)
  (while ...)
  (save-excursion ...)
  sc-guess-fill-prefix()
  (let ...)
  (save-excursion ...)
  sc-fill-paragraph()
  funcall(sc-fill-paragraph)
  byte-code("7	[hooklist sym value boundp lambda mapcar funcall] 6)
  run-hooks(sc-fill-paragraph-hook)
  sc-fill-paragraph-manually(nil)
* call-interactively(sc-fill-paragraph-manually)

--
David Grabiner, grabiner@zariski.harvard.edu
"We are sorry, but the number you have dialed is imaginary."
"Please rotate your phone 90 degrees and try again."
Disclaimer: I speak for no one and no one speaks for me.

Newsgroups: gnu.emacs.bug
From: Kimmo.SUominen@lut.fi (Kimmo Suominen)
Subject: Re: can't compile epoch 4.? on my hpux 8.0 machine
Organization: Lappeenranta University of Technology, Finland
Distribution: gnu
Date: Tue, 14 Apr 1992 20:42:43 GMT

>>>>> "Paolo" == Paolo Montrasio <montra@ghost.dsi.unimi.it> writes:

Paolo> [regular output of temacs...]
Paolo> Loading local/netunam...
Paolo> Loading local/gnuserv...
Paolo> Pure Lisp storage exhausted
Paolo> ^^^^^^^^^^^^^^^^^^^^^^^^^^^

In std GNU Emacs this means you must increase PURESIZE in src/config.h
and I guess the same goes for Epoch.  I still need to compile Epoch...
--
Kim                      /  Internet: Kimmo.Suominen@lut.fi
"That's what I think."  /   Bitnet:   KIM@FINFILES


Newsgroups: gnu.emacs.bug
From: gildea@expo.lcs.mit.edu (Stephen Gildea)
Subject: byte-compiler optimization for "let"
Organization: X Consortium, MIT Laboratory for Computer Science
Distribution: gnu
Date: Tue, 7 Apr 1992 12:29:50 GMT

If a let (or let*) form binds no variables, the byte compiler
still emits an unbind instruction (a harmless "unbind 0") at
the close of the form.  Since macros may generate such let
forms, this is worth optimizing.

The following diffs are against Emacs 18.58.

 < Stephen


*** emacs-18.58/lisp/bytecomp.el	Wed Oct 23 20:42:20 1991
--- lisp/bytecomp.el	Fri Apr  3 10:35:33 1992
***************
*** 842,848 ****
  	(byte-compile-variable-ref 'byte-varbind (car (car varlist))))
        (setq varlist (cdr varlist))))
    (byte-compile-body (cdr (cdr form)))
!   (byte-compile-out 'byte-unbind (length (car (cdr form)))))
  
  (put 'let* 'byte-compile 'byte-compile-let*)
  (defun byte-compile-let* (form)
--- 842,849 ----
  	(byte-compile-variable-ref 'byte-varbind (car (car varlist))))
        (setq varlist (cdr varlist))))
    (byte-compile-body (cdr (cdr form)))
!   (if (car (cdr form))
!       (byte-compile-out 'byte-unbind (length (car (cdr form))))))
  
  (put 'let* 'byte-compile 'byte-compile-let*)
  (defun byte-compile-let* (form)
***************
*** 857,863 ****
  	(byte-compile-variable-ref 'byte-varbind (car (car varlist))))
        (setq varlist (cdr varlist))))
    (byte-compile-body (cdr (cdr form)))
!   (byte-compile-out 'byte-unbind (length (car (cdr form)))))
  
  (put 'save-excursion 'byte-compile 'byte-compile-save-excursion)
  (defun byte-compile-save-excursion (form)
--- 858,865 ----
  	(byte-compile-variable-ref 'byte-varbind (car (car varlist))))
        (setq varlist (cdr varlist))))
    (byte-compile-body (cdr (cdr form)))
!   (if (car (cdr form))
!       (byte-compile-out 'byte-unbind (length (car (cdr form))))))
  
  (put 'save-excursion 'byte-compile 'byte-compile-save-excursion)
  (defun byte-compile-save-excursion (form)

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: Re: Help: Decstation malloc returns too big value.
Organization: Boston University Computer Science Department
Distribution: gnu
Date: Fri, 10 Apr 1992 20:41:52 GMT

In article <castor.702831203@drizzle> castor@drizzle.stanford.edu (Castor Fu) writes:

   I would be happy if emacs would simply figure out that it had a problem
   when trying to read files that are too large, and then told me to give
   up.  I tried editing a 13 megabyte file yesterday, and emacs happily
   tried to do so, but simply behaved erratically rather than indicating
   that I was doing something wrong.

This is fixed in Emacs 18.58.

-- 
Enjoy,

Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: enami@sys.PTg.sony.co.JP (enami tsugutomo)
Subject: bug in Fcall_interactively
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 08:35:11 GMT

In GNU Emacs 18.57.5 of Wed Apr  8 1992 on kitt (berkeley-unix)

In Fcall_interactively(), `tem' may (or may not:) points junk area if
garbage collection is occured during `for (i = 1; *tem; i++)' loop.

Here is an example code of bug.  Execute them one by one according to
the comments, then you will get wrong result in minibuffer.

	;; evalute a following sexp.
	(progn
	  (garbage-collect)
	  (setq string (make-string 100 1))
	  (defun hoge (a b)
	    (interactive "f1: \nf2: ")
	    (message "%s %s" a b)))
	
	;; do M-x hoge,
	;; and before answer in minibuffer, swith to this buffer
	;; and evaluate a following sexp.
	(progn
	  (setq string nil)
	  (garbage-collect)
	  (make-string 200 2)
	  nil)
	;; then return to the minibuffer and answer the question.

The following patch will fix the problem.

							-- enami
--- 1.1	1992/04/08 03:55:59
+++ callint.c	1992/04/08 04:11:08
@@ -201,7 +201,14 @@
 	goto lose;
       specs = Fcar (Fcdr (specs));
       if (XTYPE (specs) == Lisp_String)
+#if 0
 	string = XSTRING (specs)->data;
+#else
+      {
+	string = (unsigned char *) alloca (XSTRING (specs)->size + 1);
+	bcopy (XSTRING (specs)->data, string, XSTRING (specs)->size + 1);
+      }
+#endif
       else
 	{
 	  i = num_input_chars;

Newsgroups: gnu.emacs.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: cal.el bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 09:11:55 GMT

Cal.el incorrectly prints the calendar for 1752.  

The output of `(generate-month 9 1752 0)' is:

   September 1752
 S  M Tu  W Th  F  S
                1  2 
 3  4  5  6  7  8  9 
10 11 12 13 14 15 16 
17 18 19 20 21 22 23 
24 25 26 27 28 29 30 


However, 1752, in "England and her colonies", September looked like
this:
 
       Sep 1752 
 S  M Tu  W Th  F  S    
       1  2 14 15 16    
17 18 19 20 21 22 23    
24 25 26 27 28 29 30


	-mib

Newsgroups: gnu.emacs.bug
From: farrell@fjord.reo.dec.com (John M. Farrell)
Subject: Re: Help: Decstation malloc returns too big value.
Organization: Digital Equipment Corporation - UK Engineering
Distribution: gnu
Date: Tue, 7 Apr 1992 10:51:11 GMT

>>>>> On 7 Apr 92 05:42:51 GMT, ishikawa@ds5200. (Chiaki Ishikawa) said:

In article <9204061142.AA15106@ds5200.local> ishikawa@ds5200. (Chiaki Ishikawa) writes:

Chiaki> SYSTEM: 	DEC ULTRIX ds5200 4.1 0 RISC 	Decstation 5200.

Chiaki> SYMPTOM: 	Emacs crashes in routines alloc.c since sometimes malloc()
Chiaki> returns a very large address, that is a value that has non-zero value
Chiaki> in the upper 8 bits.

Chiaki> Example:	malloc returns 0x01000120

I suspect you have incorrectly specfied the machine type in config.h - you
want m-pmax.h and not m-mips.h for the machine dependent config.

The Ultrix heap starts at 0x01000000 by default. The dectsation config file
(m-pmax.h) has:

#define DATA_START 0x10000000
#define DATA_SEG_BITS 0x10000000

which tells emacs how to mask out the high order bits when storing a pointer
into a cons cell and restore them when retrieving it.

If you use the m-mips.h config file, you force Ultrix to use a non-default
start address for the heap (0x800000) which seems to cause some problems.


--
John M. Farrell                 | Internet: farrell@fjord.reo.dec.com
Digital Equipment Corporation   | 
P.O. Box 121                    | "One foot in the grave, 
Reading, RG1 0TU, UK.           |  and one foot on the pedal", TP     

Newsgroups: gnu.emacs.bug
From: jskudlarek@std.mentorg.COM (Joseph Skudlarek)
Subject: RE \(...\)? won't match-beginning/end
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 05:51:26 GMT

The follow test case attempts to show that applying a ? operator to a
\( ... \) grouping construct makes it unavailable for matching
substring usage later on.

(emacs-version)
"GNU Emacs 18.57.5 of Wed May 15 1991 on rlischner (Domain/OS)"

Thanks again for truly wonderful software.

/Jskud


(defun demo (str)
  (interactive "sString: ")
  (showme "\\(/[^/]*\\)?.+$" str)
  (showme "\\(/[^/]*\\).+$" str)
  )

(defun showme(pattern str)
  (let (left middle right)
	 (setq left (string-match pattern str)
			 middle (match-beginning 1)
			 right (match-end 1))
	 (print
		(format "str=%s left=%s middle=%s right=%s" str left middle right))))

(with-output-to-temp-buffer
	 "*pattern match bug output*"
  (demo "")
  (demo "a")
  (demo "a/b")
  (demo "a/b/c"))

The result on my machine

"str= left=nil middle=nil right=nil"

"str= left=nil middle=nil right=nil"

"str=a left=0 middle=nil right=nil"

"str=a left=nil middle=nil right=nil"

"str=a/b left=0 middle=nil right=nil"

"str=a/b left=1 middle=1 right=2"

"str=a/b/c left=0 middle=nil right=nil"

"str=a/b/c left=1 middle=1 right=3"

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: search-forward with 0 repeat count fails
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 13:41:30 GMT

Calling search-forward with a repeat count of 0 fails in two ways:

1. If point is not near enough to the beginning of the buffer,
search-forward will move backward the length of the search string.

2. If point is too near the beginning of the buffer, search-forward will
signal an error.

Calling search-forward with a repeat count of 0 should do *absolutely
nothing*.

-- 
Enjoy,

Joe Wells <jbw@cs.bu.edu>

Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: gildea@expo.lcs.mit.edu (Stephen Gildea)
Subject: Re: Fix to defvar of lpr-command
Organization: X Consortium, MIT Laboratory for Computer Science
Distribution: gnu
Date: Tue, 7 Apr 1992 12:50:43 GMT

    [Request for lpr-command to be a user option.]

You probably only use a few values of lpr-command, right?  So you
might find it even more convenient to define a few interactive
commands that setq lpr-command.  For example:

(defun set-enscript ()
  "Set lpr-command to enscript."
  (interactive)
  (setq lpr-command "enscript"))

(defun set-print ()
  "Set lpr-command to print."
  (interactive)
  (setq lpr-command "print"))


 < Stephen
   MIT X Consortium

Newsgroups: gnu.emacs.bug
From: pd@kubism.ku.dk (Peter Dalgaard SFE)
Subject: C-Z, C-\ can cause Fatal error (3)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 20:25:10 GMT

Is this a well-known bug: On a Sun 4 running emacs 18.57, hitting C-Z,
C-\ with sufficiently unfortunate timing results in emacs receiving a
SIGQUIT and dying.

Trouble is, some keyboards have the two keys adjacent which makes it
easy to hit the combination by fat-fingering. Even worse, if C-S has
been swapped with C-\ because of flow-control snafu, you can kill emacs
when trying to save a file.

A quick fix, of course, is to have emacs disable SIGQUIT by plugging in
a SIG_IGN instead of fatal_error_signal in emacs.c, but I'm not
altogether sure one wants to do that.

	Peter Dalgaard
	Statistical Research Unit
	U. Copenhagen

Newsgroups: gnu.emacs.bug