4:24 a.m.
Ulrich,
Thanks for the patch. You are correct that the lispref claims
that concat takes an int, but that capability was taken out of XEmacs
awhile ago, I think around 20.something. If you look in the etc/NEWS
file, you'll see the following entry:
** The `concat' function no longer accepts integer arguments.
I modified your fix - I took the approach of changing the calling
code. Perhaps some others on the list will express a preference
between patching the called function vs. the calling function.
Anyway, here's a proper 'diff -u' patch:
cvs server: Diffing .
Index: calc-alg-2.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-packages/oa/calc/calc-alg-2.el,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 calc-alg-2.el
--- calc-alg-2.el 1998/02/10 18:25:13 1.1.1.1
+++ calc-alg-2.el 2000/11/07 04:22:04
＠＠ -3215,7 +3215,7 ＠＠
(math-mul (list 'calcFunc-as var-GenCount) val)
(setq var-GenCount (math-add var-GenCount 1))
(calc-refresh-evaltos 'var-GenCount))
- (let* ((var (concat "s" (math-get-from-counter 'solve-sign)))
+ (let* ((var (concat "s" (int-to-string (math-get-from-counter
'solve-sign))))
(var2 (list 'var (intern var) (intern (concat "var-" var)))))
(if (eq solve-full 'all)
(setq math-solve-ranges (cons (list var2 1 -1)
＠＠ -3234,7 +3234,7 ＠＠
(math-mul val (list 'calcFunc-an var-GenCount))
(setq var-GenCount (math-add var-GenCount 1))
(calc-refresh-evaltos 'var-GenCount))
- (let* ((var (concat "n" (math-get-from-counter 'solve-int)))
+ (let* ((var (concat "n" (int-to-string (math-get-from-counter
'solve-int))))
(var2 (list 'var (intern var) (intern (concat "var-" var)))))
(if (and range (eq solve-full 'all))
(setq math-solve-ranges (cons (cons var2
Thanks,
vin shelton
Path:
reader4.news.rcn.net!feed1.news.rcn.net!rcn!europa.netcrusader.net!128.230.129.106!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: ulrichbackes(a)gmx.de
Newsgroups: comp.emacs.xemacs
Subject: Re: emacs 18, XEmacs 21.x, and calc v2.02f by Dave Gillespie
Date: Mon, 06 Nov 2000 16:40:10 GMT
Organization: Deja.com - Before you buy.
Lines: 46
Message-ID: <8u6mt8$fau$1(a)nnrp1.deja.com>
NNTP-Posting-Host: 62.172.163.171
X-Article-Creation-Date: Mon Nov 06 16:40:10 2000 GMT
X-Http-User-Agent: Mozilla/4.7 [de] (WinNT; I)
X-Http-Proxy: 1.0 x65.deja.com:80 (Squid/1.1.22) for client 62.172.163.171
X-MyDeja-Info: XMYDJUIDulrich_backes
Xref: reader4.news.rcn.net comp.emacs.xemacs:53830
Hi everybody,
i found a solution for the calc solver and integrator
malfunction with xemacs. I would like this to be tested
by some volunteers before the patch goes into distribution,
because this debug job was my first lisp experience.. :-)
It seems that for any reason the xemacs "concat" function does
not accept to get an integer argument. In the emacs lisp
description this is reported to work, but with xemacs actually
it does not. Maybe one has an explanation....
Anyway, a quick-and-dirty fix is to wrap
the failing function with an int-to-string():
;; xemacs-packages/lisp/calc/calc-alg-2.el
3191 (defun math-get-from-counter (name) ;; now returns a string,
;; before an integer!
NEW: (int-to-string
3192 (let ((ctr (assq name calc-command-flags)))
3193 (if ctr
3194 (setcdr ctr (1+ (cdr ctr)))
3195 (setq ctr (cons name 1)
3196 calc-command-flags (cons ctr calc-command-flags)))
3197 (cdr ctr))
NEW: )
3198 )
;; this is the call of the function:
3218 (let* ((var (concat "s" (math-get-from-counter 'solve-sign)))
^ this seems to regret integers in arg list
######### patch input follows here: ########
3191a3192
(int-to-string
3197a3199
)
############################################
Happy calculation solving,
Ulrich Backes
Sent via Deja.com http://www.deja.com/
Before you buy.
8:56 a.m.
New subject: concat Texinfo [was: emacs 18, XEmacs 21.x, and calc v2.02f]
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> You are correct that the lispref claims that concat takes an
vin> int, but that capability was taken out of XEmacs awhile ago,
vin> I think around 20.something.
I _was_ going to go fix the doc, but discovered more discrepancies.
Lispref says
(concat "abc" (list 120 (+ 256 121)) [122])
＠result{} "abcxyz"
but in reality Mule does
oops ==> "abcx,By(Bz"
(that's a Latin-2 character between x and z).
This is still considered a feature, right? --with-mule=no XEmacs does
as the manual says (computes the character modulo 256), right?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:41 a.m.
New subject: concat Texinfo [was: emacs 18, XEmacs 21.x, and calc v2.02f]
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> You are correct that the lispref claims that concat takes an
vin> int, but that capability was taken out of XEmacs awhile ago,
vin> I think around 20.something.
SJT> I _was_ going to go fix the doc, but discovered more discrepancies.
SJT> Lispref says
SJT> (concat "abc" (list 120 (+ 256 121)) [122])
SJT> ＠result{} "abcxyz"
SJT> but in reality Mule does
SJT> oops ==> "abcx-Bůz"-A
SJT> (that's a Latin-2 character between x and z).
SJT> This is still considered a feature, right? --with-mule=no XEmacs does
SJT> as the manual says (computes the character modulo 256), right?
Yes. And Emacs has the same behavior we do (modulo differences in
character representation). I suggest we steal improvements from their
latest texi for concat (could you do this, Stephen?):
＠defun concat &rest sequences
＠cindex copying strings
＠cindex concatenating strings
This function returns a new string consisting of the characters in the
arguments passed to it (along with their text properties, if any). The
arguments may be strings, lists of numbers, or vectors of numbers; they
are not themselves changed. If ＠code{concat} receives no arguments, it
returns an empty string.
＠example
(concat "abc" "-def")
＠result{} "abc-def"
(concat "abc" (list 120 121) [122])
＠result{} "abcxyz"
;; ＠r{＠code{nil} is an empty sequence.}
(concat "abc" nil "-def")
＠result{} "abc-def"
(concat "The " "quick brown " "fox.")
＠result{} "The quick brown fox."
(concat)
＠result{} ""
＠end example
＠noindent
The ＠code{concat} function always constructs a new string that is
not ＠code{eq} to any existing string.
In Emacs versions before 21, when an argument was an integer (not a
sequence of integers), it was converted to a string of digits making up
the decimal printed representation of the integer. This obsolete usage
no longer works. The proper way to convert an integer to its decimal
printed form is with ＠code{format} (＠pxref{Formatting Strings}) or
＠code{number-to-string} (＠pxref{String Conversion}).
For information about other concatenation functions, see the
description of ＠code{mapconcat} in ＠ref{Mapping Functions},
＠code{vconcat} in ＠ref{Vectors}, and ＠code{append} in ＠ref{Building
Lists}.
＠end defun
10:38 a.m.
New subject: concat Texinfo [was: emacs 18, XEmacs 21.x, and calc v2.02f]
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
SJT> This is still considered a feature, right? --with-mule=no
SJT> XEmacs does as the manual says (computes the character modulo
SJT> 256), right?
mb> Yes. And Emacs has the same behavior we do (modulo
mb> differences in character representation). I suggest we steal
mb> improvements from their latest texi for concat (could you do
mb> this, Stephen?):
OK, if Emacs does it that way, it's a feature. I need to check some
boundary cases (integers which represent no character).
What do we do about Adrian's report that no-mule XEmacs does _not_ do
the mod 256 calculation, but signals an error? Is it a bug or a
feature? I vote, with Hrvoje, "feature", implying I fix the doc for
that too.
I'll do the write-up.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8573
days inactive
8573
days old
3 comments
3 participants
participants (3)
-
Martin Buchholz -
Stephen J. Turnbull -
Vin Shelton