Menu
▾
▴
maxima-discuss
|
From: Camm M. <ca...@ma...> - 2025-05-14 21:55:27
|
tags 905316 forwarded max...@li...
thanks
Greetings, and thanks for your report!
=============================================================================
Dear Maintainer,
I wanted to format a list of integers in base 16, but the default output was
returned in mixed case for the letters A-F. When I added case-conversion to the
format string, maxima suddenly ends up in an infinite memory-consuming loop.
The exact same format string works in lisp within maxima.
Example:
This works as expected and prints the list as a comma-separated list of
hexadecimal integers in upper case:
> (%i1) :lisp (format t "~{0x~:@(~x~)~^, ~}~%" '(1000 2000 3000 4000) )
> 0x3E8, 0x7D0, 0xBB8, 0xFA0
> NIL
> (%i1)
while this hangs indefinitely (notice exact same string and values)
> (%i1) printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000] );
This started happening when I added the case conversion. If I remove it, the
output is as expected:
> (%i4) printf(true, "~{0x~x~^, ~}~%", [1000,2000,3000,4000] );
> 0x3E8, 0x7D0, 0xBB8, 0xFA0
> (%o4) false
=============================================================================
Take care,
--
Camm Maguire ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
|
|
From: Raymond T. <toy...@gm...> - 2025-05-15 02:08:27
|
On 5/14/25 2:55 PM, Camm Maguire wrote:
> tags 905316 for...@li...
> thanks
Who is forwarding this and where is it coming from?
> Greetings, and thanks for your report!
> =============================================================================
> Dear Maintainer,
>
> I wanted to format a list of integers in base 16, but the default output was
> returned in mixed case for the letters A-F. When I added case-conversion to the
> format string, maxima suddenly ends up in an infinite memory-consuming loop.
> The exact same format string works in lisp within maxima.
>
>
> Example:
>
>
> This works as expected and prints the list as a comma-separated list of
> hexadecimal integers in upper case:
>
>> (%i1) :lisp (format t "~{0x~:@(~x~)~^, ~}~%" '(1000 2000 3000 4000) )
>> 0x3E8, 0x7D0, 0xBB8, 0xFA0
>> NIL
>> (%i1)
> while this hangs indefinitely (notice exact same string and values)
>
>> (%i1) printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000] );
> This started happening when I added the case conversion. If I remove it, the
> output is as expected:
Doesn’t that seem to indicate that your change is the source of the
problem? can you provide a patch for your change?
​ |
|
From: Camm M. <ca...@ma...> - 2025-05-15 14:32:26
|
Greetings! I'm just processing the Debian maxima bug reports before the
freeze. This report was submitted by someone else. You can reach them
via 905...@bu..., or post to the report at
90...@bu.... I have not looked into this deeply myself.
Take care,
Raymond Toy <toy...@gm...> writes:
> On 5/14/25 2:55 PM, Camm Maguire wrote:
>
> tags 905316 forwarded max...@li...
> thanks
>
> Who is forwarding this and where is it coming from?
>
> Greetings, and thanks for your report!
> =============================================================================
> Dear Maintainer,
>
> I wanted to format a list of integers in base 16, but the default output was
> returned in mixed case for the letters A-F. When I added case-conversion to the
> format string, maxima suddenly ends up in an infinite memory-consuming loop.
> The exact same format string works in lisp within maxima.
>
>
> Example:
>
>
> This works as expected and prints the list as a comma-separated list of
> hexadecimal integers in upper case:
>
> (%i1) :lisp (format t "~{0x~:@(~x~)~^, ~}~%" '(1000 2000 3000 4000) )
> 0x3E8, 0x7D0, 0xBB8, 0xFA0
> NIL
> (%i1)
>
> while this hangs indefinitely (notice exact same string and values)
>
> (%i1) printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000] );
>
> This started happening when I added the case conversion. If I remove it, the
> output is as expected:
>
> Doesn’t that seem to indicate that your change is the source of the problem? can you provide a patch for your change?
> ​
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
--
Camm Maguire ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
|
|
From: Robert D. <rob...@gm...> - 2025-05-15 15:35:53
|
On Thu, May 15, 2025 at 7:34 AM Camm Maguire <ca...@ma...> wrote: > > Greetings! I'm just processing the Debian maxima bug reports before the > freeze. This report was submitted by someone else. You can reach them > via 905...@bu..., or post to the report at > 90...@bu.... I have not looked into this deeply myself. I see that bug report is listed at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=maxima;dist=unstable It probably wouldn't hurt to repeat that link or the appropriate direct link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905316 Robert |
|
From: Raymond T. <toy...@gm...> - 2025-05-16 01:43:35
|
On 5/15/25 8:35 AM, Robert Dodier wrote: > On Thu, May 15, 2025 at 7:34 AM Camm Maguire <ca...@ma...> wrote: >> >> Greetings! I'm just processing the Debian maxima bug reports before the >> freeze. This report was submitted by someone else. You can reach them >> via 905...@bu..., or post to the report at >> 90...@bu.... I have not looked into this deeply myself. > > I see that bug report is listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=maxima;dist=unstable > > It probably wouldn't hurt to repeat that link or the appropriate > direct link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905316 That works. But I think it would be even better if the reporter filed a maxima bug instead (or in addition to). I'm not particularly motivated to search debian bugs for maxima bugs. Sorry. |
|
From: Robert D. <rob...@gm...> - 2025-05-16 05:37:52
|
On Thu, May 15, 2025 at 6:49 PM Raymond Toy <toy...@gm...> wrote: > > It probably wouldn't hurt to repeat that link or the appropriate > > direct link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905316 > > That works. But I think it would be even better if the reporter filed a > maxima bug instead (or in addition to). Yes, that would be great, but users can't always tell whose responsibility it is to fix anything, so problems sometimes get reported back to the source of whatever they installed. > I'm not particularly motivated to search debian bugs for maxima bugs. > Sorry. Well, there's no need to apologize. We're all doing what we can. Heaven knows there's already enough to keep us busy for several lifetimes. The advantage of looking at downstream bug trackers is that presumably those are bugs which people have encountered while trying to use Maxima for some real-world (real enough to them, anyway) task; that makes the bug reports more interesting, I think. But if you don't have time to deal with it, that's A-OK! Robert |
|
From: Michel T. <ta...@lp...> - 2025-05-16 13:53:25
|
I have not seen answers for this bug, so let me point at something. On
my machine (with somewhat old versions of
softs) the printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000]
) hangs with all lisps i have, namely sbcl, ccl64,
clisp and gcl. This function printf is defined in
share/stringproc/printf.lisp Using sbcl i see it hanging in function
prepare-args where it is continually searching stuff of this sort:
2: SEARCH returned 23
2: (SEARCH "~" "}]>;%&t~")
2: SEARCH returned 7
2: (SEARCH ":" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned NIL
2: (SEARCH "@" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned NIL
2: (SEARCH "(" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned NIL
2: (SEARCH "~" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned 23
2: (SEARCH "~" "}]>;%&t~")
2: SEARCH returned 7
2: (SEARCH ")" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned NIL
2: (SEARCH "~" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
")
2: SEARCH returned 23
2: (SEARCH "~" "}]>;%&t~")
2: SEARCH returned 7
2: (SEARCH ":" "abcdefghoprstx%{}^&$[]?~<>;ABCDEFGHOPRSTX
This function is quite complicated, programmed with a lot of go tos ,
etc. and i seem to remember we have already seen recently a bug in the
same function. The author gives the following motivation for this
complicated stuff:
"
Before passing to `format' ctrls and args are both visited and modified:
E.g. `prepare-ctrls' replaces the directive ~w,d,e,x,o,p@h by ~@a
and `prepare-args' replaces the corresponding bigfloat argument by a
string.
As a consequence of this no arg can be used twice. The goto-directive ~*
is lost.
In GCL/utf-8 builds mincol specifications do not work correctly
if non-us-ascii characters are used as arguments to ~s and ~a directives.
"
Maybe this should be revisited thoroughly in maxima, but it doesn't
pertain to a gcl problem.
Le 14/05/2025 à 23:55, Camm Maguire a écrit :
> printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000] );
--
Michel Talon
|
|
From: Raymond T. <toy...@gm...> - 2025-05-16 16:20:07
|
On 5/16/25 6:53 AM, Michel Talon wrote:
> I have not seen answers for this bug, so let me point at something. On
> my machine (with somewhat old versions of
>
> softs) the printf(true, "~{0x~:@(~x~)~^, ~}~%",
> [1000,2000,3000,4000] ) hangs with all lisps i have, namely sbcl, ccl64,
>
I see similar infinite looping. Also, this causes an error:
|printf(true, "~{~(~x~) ~}~%", [1000,2000,3000,4000] );
Argument X is not a NUMBER: NIL. [Condition of type SIMPLE-TYPE-ERROR]
Restarts: 0: [MACSYMA-QUIT] Maxima top-level Backtrace: 0:
(KERNEL:TWO-ARG-+ NIL 1) 1: (1+ NIL) 2: (SPEC-POSITION "~{~(~x~)
~}~%" NIL) 3: (ITER-POSITIONS "~{~(~x~) ~}~%" 0) 4:
(PREPARE-ARGS "~{~(~x~) ~}~%" (((MLIST SIMP) 1000 2000 3000
4000)) NIL NIL) |
My guess is that printf doesn’t know what to do with the |~(...~)|:
|(%i24) printf(true, "~(~{~x~^ ~}~)~%", [1000,2000,3000,4000]
); (mlist simp) 3e8 7d0 bb8 fa0 |
​ |
|
From: Robert D. <rob...@gm...> - 2025-05-17 19:26:36
|
Maxima's printf has a lot of great things going for it, mostly inherited from Common Lisp FORMAT. As wonderful as it is, FORMAT doesn't provide a way to define new format directives or redefine existing ones. At present the Maxima-specific directives (~h for bigfloat, ~m for 2-d pretty printer output) and redefined directives (~a and ~s for 1-d output) are implemented by effectively reimplementing some large part of FORMAT, in particular the stuff for looping. I have wondered about how to handle printf in a neater way, mostly with the goal of fixing bugs, although it's not out of the question to make it simpler to define or redefine additional directives. I wonder if it's thinkable to start with an existing FORMAT implementation and then bolt on the Maxima-specific bits. I haven't investigated. Or we could take a second look at the existing printf code and see if the looping stuff could be revised. At this point I'm interested to hear comments about this stuff at a high level -- we can work out details if we can arrive at a workable plan. FWIW & all the best. Robert |
|
From: Stavros M. <mac...@gm...> - 2025-05-17 21:13:58
|
Have you tried vibe-coding? Perplexity.ai has done some amazing things for me in Python and Javascript, and some simple things in Common Lisp. Give it the code for *format* and ask it to introduce a new printing type... On Sat, May 17, 2025 at 3:26 PM Robert Dodier <rob...@gm...> wrote: > Maxima's printf has a lot of great things going for it, mostly > inherited from Common Lisp FORMAT. > > As wonderful as it is, FORMAT doesn't provide a way to define new > format directives or redefine existing ones. At present the > Maxima-specific directives (~h for bigfloat, ~m for 2-d pretty printer > output) and redefined directives (~a and ~s for 1-d output) are > implemented by effectively reimplementing some large part of FORMAT, > in particular the stuff for looping. > > I have wondered about how to handle printf in a neater way, mostly > with the goal of fixing bugs, although it's not out of the question to > make it simpler to define or redefine additional directives. > > I wonder if it's thinkable to start with an existing FORMAT > implementation and then bolt on the Maxima-specific bits. I haven't > investigated. Or we could take a second look at the existing printf > code and see if the looping stuff could be revised. > > At this point I'm interested to hear comments about this stuff at a > high level -- we can work out details if we can arrive at a workable > plan. > > FWIW & all the best. > > Robert > > > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |
|
From: Andreas E. <and...@gm...> - 2025-05-17 22:01:15
|
On Sa 17 Mai 2025 at 12:26, Robert Dodier <rob...@gm...> wrote: > Maxima's printf has a lot of great things going for it, mostly > inherited from Common Lisp FORMAT. > > As wonderful as it is, FORMAT doesn't provide a way to define new > format directives or redefine existing ones. Well, that is not really true. With the ~/name/ format control you can call user defined formats. Look at https://www.lispworks.com/documentation/HyperSpec/Body/22_ced.htm I think we could do all the maxima formats this way ond do away with the convoluted way printing is done at the moment. 'Andreas -- ceterum censeo redmondinem esse delendam |
|
From: Raymond T. <toy...@gm...> - 2025-05-18 00:07:34
|
On 5/17/25 12:26 PM, Robert Dodier wrote:
> Maxima's printf has a lot of great things going for it, mostly
> inherited from Common Lisp FORMAT.
>
> As wonderful as it is, FORMAT doesn't provide a way to define new
> format directives or redefine existing ones. At present the
> Maxima-specific directives (~h for bigfloat, ~m for 2-d pretty printer
> output) and redefined directives (~a and ~s for 1-d output) are
> implemented by effectively reimplementing some large part of FORMAT,
> in particular the stuff for looping.
As Andreas pointed out, we could probably just replace |~h|, |~m| with
CL standard |~/.../|. (At one point, not every Lisp supported this, but
I think it’s better now.)
> I wonder if it's thinkable to start with an existing FORMAT
> implementation and then bolt on the Maxima-specific bits. I haven't
> investigated. Or we could take a second look at the existing printf
> code and see if the looping stuff could be revised.
Pros:
*
We’re in control of what it means.
*
We can dictate how it behaves.
Cons:
*
It’s a ton of work to maintain and understand. (Cmucl has a single
file of 3000+ lines to implement |format| and |formatter|, and that
might not be everything needed.)
*
We have to document it all.
*
All the nuances of Lisp |format| are really complicated.
*
We’ll probably confuse users if it looks like Lisp |format| but isn’t.
I don’t have any good ideas. I think the existing printf implementation
would probably really need to parse the format string correctly and
match up the arguments to the format string. Not an easy task. Might be
easier than writing/borrowing a full |format| impl, but maybe not.
I don’t use |printf| very often, but it sure is useful when I do!
​ |
|
From: Eduardo O. <edu...@gm...> - 2025-05-18 07:42:07
|
How do I use "~m"?
Here's what I tried (on a very recent SBCL Maxima):
format([args]) := apply(?format, append([false], args));
o : a^"b";
format("~a", o); /* ((MEXPT SIMP) $A b) */
format("~s", o); /* ((MEXPT SIMP) $A "b") */
format("~m", o); /* Unknown format directive */
Thanks in advance!
Eduardo
On Sat, 17 May 2025 at 16:32, Robert Dodier <rob...@gm...> wrote:
> Maxima's printf has a lot of great things going for it, mostly
> inherited from Common Lisp FORMAT.
>
> As wonderful as it is, FORMAT doesn't provide a way to define new
> format directives or redefine existing ones. At present the
> Maxima-specific directives (~h for bigfloat, ~m for 2-d pretty printer
> output) and redefined directives (~a and ~s for 1-d output) are
> implemented by effectively reimplementing some large part of FORMAT,
> in particular the stuff for looping.
>
> I have wondered about how to handle printf in a neater way, mostly
> with the goal of fixing bugs, although it's not out of the question to
> make it simpler to define or redefine additional directives.
>
> I wonder if it's thinkable to start with an existing FORMAT
> implementation and then bolt on the Maxima-specific bits. I haven't
> investigated. Or we could take a second look at the existing printf
> code and see if the looping stuff could be revised.
>
> At this point I'm interested to hear comments about this stuff at a
> high level -- we can work out details if we can arrive at a workable
> plan.
>
> FWIW & all the best.
>
> Robert
>
>
|
|
From: Raymond T. <toy...@gm...> - 2025-05-18 14:58:36
|
On 5/18/25 12:41 AM, Eduardo Ochs wrote:
> How do I use "~m"?
> Here's what I tried (on a very recent SBCL Maxima):
>
> format([args]) := apply(?format, append([false], args));
> o : a^"b";
> format("~a", o); /* ((MEXPT SIMP) $A b) */
> format("~s", o); /* ((MEXPT SIMP) $A "b") */
> format("~m", o); /* Unknown format directive */
Use printf:
|printf(true, "~a", a^b); a^b printf(true, "~m",
a^b); b a |
​ |
|
From: Michel T. <ta...@lp...> - 2025-05-18 15:46:31
|
Le 18/05/2025 à 09:41, Eduardo Ochs a écrit :
> How do I use "~m"?
> Here's what I tried (on a very recent SBCL Maxima):
>
> format([args]) := apply(?format, append([false], args));
> o : a^"b";
> format("~a", o); /* ((MEXPT SIMP) $A b) */
> format("~s", o); /* ((MEXPT SIMP) $A "b") */
> format("~m", o); /* Unknown format directive */
>
> Thanks in advance!
> Eduardo
>
You may have an old version of printf.lisp in share/stringproc. I had
the same problem as you, but downloading
the latest version of printf.lisp from
https://sourceforge.net/p/maxima/code/ci/master/tree/ (go to history) it
works
with the examples of Raymond.
(%i1) printf(true,"~a ~%",a^b);
a^b
(%o1) false
(%i2) printf(true,"~M ~%",a^b);
error in FORMAT: Unknown format directive (character:
LATIN_CAPITAL_LETTER_M)
Automatically continuing.
(%i3) load("~/Téléchargements/printf.lisp");
(%o3) ~/Téléchargements/printf.lisp
(%i4) printf(true,"~M ~%",a^b);
b
a
(%o4) false
--
Michel Talon
|
|
From: Robert D. <rob...@gm...> - 2025-05-18 17:20:25
|
On Sun, May 18, 2025 at 12:41 AM Eduardo Ochs <edu...@gm...> wrote:
> format([args]) := apply(?format, append([false], args));
> o : a^"b";
> format("~a", o); /* ((MEXPT SIMP) $A b) */
> format("~s", o); /* ((MEXPT SIMP) $A "b") */
> format("~m", o); /* Unknown format directive */
This is kind of puzzling; you are calling Common Lisp FORMAT directly, so
one would expect that Maxima-specific stuff isn't recognized. Don't you
want Maxima's printf function?
(%i2) printf (true, "With tilde-a = ~a, tilde-s = ~s, tilde-m = ~m~%", a^b,
a^b, a^b);
b
With tilde-a = a^b, tilde-s = "a^b", tilde-m = a
(%o2) false
For the record, the ~m directive for printf first appeared in Maxima 5.45
(May 2021).
Robert
|
|
From: Eduardo O. <edu...@gm...> - 2025-05-18 23:44:51
|
Hi all!
Thanks and apologies - my mental model was wrong... =S
Initially I thought that Maxima modified FORMAT somehow -
but your examples work, and share/stringproc/printf.lisp
explains the innards very well...
Cheers! =)
Eduardo
On Sun, 18 May 2025 at 14:20, Robert Dodier <rob...@gm...> wrote:
> On Sun, May 18, 2025 at 12:41 AM Eduardo Ochs <edu...@gm...>
> wrote:
>
> > format([args]) := apply(?format, append([false], args));
> > o : a^"b";
> > format("~a", o); /* ((MEXPT SIMP) $A b) */
> > format("~s", o); /* ((MEXPT SIMP) $A "b") */
> > format("~m", o); /* Unknown format directive */
>
> This is kind of puzzling; you are calling Common Lisp FORMAT directly, so
> one would expect that Maxima-specific stuff isn't recognized. Don't you
> want Maxima's printf function?
>
> (%i2) printf (true, "With tilde-a = ~a, tilde-s = ~s, tilde-m = ~m~%",
> a^b, a^b, a^b);
> b
> With tilde-a = a^b, tilde-s = "a^b", tilde-m = a
> (%o2) false
>
> For the record, the ~m directive for printf first appeared in Maxima 5.45
> (May 2021).
>
> Robert
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X