search

rtoy / maxima

A Clone of Maxima's repo
Other
0 stars 0 forks source link

Ezunits won't compile with #180

Closed rtoy closed 4 months ago

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:07 Created by andreas070898 on 2016-10-27 10:14:08 Original: https://sourceforge.net/p/maxima/bugs/3232

After upgrading my computer to Ubuntu 16.10, I can no longer load the ezunits module. Here's what I observe:

andreas@E7450:~$ maxima

Maxima 5.37.2 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) load(ezunits);

Compiling /tmp/gazonk_11422_0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_11422_0.lsp.
Unrelocated non-local symbol: _GLOBAL_OFFSET_TABLE_
Maxima encountered a Lisp error:

 Condition in MACSYMA-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR: The assertion !emsg("Unrelocated non-local symbol: %s\n",st1+sym->st_name) on line 236 of sfaslelf.c in function relocate_symbols failed

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i2) a: 10 ` m;
(%o2)                               10 ` m
(%i3) a `` km;
(%o3)                 apply_units_conversion(10 ` m, km)

Which shows that some of the functionality is loaded, but the function apply_units_conversion is not implemented yet.

Additional info about my version and build:

(%i2) bug_report();

Please report bugs to:
    http://sourceforge.net/p/maxima/bugs
To report a bug, you must have a Sourceforge account.
Please include the following information with your bug report:
-------------------------------------------------------------
Maxima version: "5.37.2"
Maxima build date: "2015-10-30 02:08:33"
Host type: "x86_64-unknown-linux-gnu"
Lisp implementation type: "GNU Common Lisp (GCL)"
Lisp implementation version: "GCL 2.6.12"
-------------------------------------------------------------
The above information is also reported by the function 'build_info()'.

(%o2) 
(%i3) build_info();
(%o3) 
Maxima version: "5.37.2"
Maxima build date: "2015-10-30 02:08:33"
Host type: "x86_64-unknown-linux-gnu"
Lisp implementation type: "GNU Common Lisp (GCL)"
Lisp implementation version: "GCL 2.6.12"
rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:09 Created by andreas070898 on 2016-10-27 10:54:11 Original: https://sourceforge.net/p/maxima/bugs/3232/#9458

So, I tried removing line 256 form the file ezunits_functions.mac: compile (constantp_not0, constantp_not1, mult_expr_nontrivialconstfactorsp, / nondimensionalp, / unitopp, unitp, nonconstantp); which removed the error and apparantly fixed all problems. Clearly, this is a problem in the compilation. However, I don't know what's going on in this compilation, so I can't hunt this bug any further. Do anyone know this codebase in more detail?

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:11 Created by robert_dodier on 2016-11-03 14:49:20 Original: https://sourceforge.net/p/maxima/bugs/3232/#c05d

Diff:


--- old
+++ new
@@ -1,4 +1,6 @@
 After upgrading my computer to Ubuntu 16.10, I can no longer load the ezunits module. Here's what I observe:
+
+~~~~
 andreas@E7450:~$ maxima

 Maxima 5.37.2 http://maxima.sourceforge.net
@@ -24,10 +26,13 @@
 (%o2)                               10 ` m
 (%i3) a `` km;
 (%o3)                 apply_units_conversion(10 ` m, km)
+~~~~

 Which shows that some of the functionality is loaded, but the function apply_units_conversion is not implemented yet.

 Additional info about my version and build:
+
+~~~~
 (%i2) bug_report();

 Please report bugs to:
@@ -51,3 +56,4 @@
 Host type: "x86_64-unknown-linux-gnu"
 Lisp implementation type: "GNU Common Lisp (GCL)"
 Lisp implementation version: "GCL 2.6.12"
+~~~~
rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:13 Created by robert_dodier on 2016-11-03 14:49:20 Original: https://sourceforge.net/p/maxima/bugs/3232/#4151

Hmm. Can you verify that the Lisp function compiler works at all? Please try this:

(%i1) :lisp (defun myfun (x) (1+ x))
(%i1) :lisp (compile 'myfun)

Does that cause an error?

If not can you please try this too:

(%i1) myfun(x) := x + 1;
(%i2) compile (myfun);
rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:16 Created by andreas070898 on 2016-11-06 10:57:56 Original: https://sourceforge.net/p/maxima/bugs/3232/#e23f

Apparently, the LISP compiler is indeed broken:

Maxima 5.37.2 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) :lisp (defun myfun (x) (1+ x))

MYFUN
(%i1) :lisp (compile 'myfun)

Compiling /tmp/gazonk_6628_0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_6628_0.lsp.
Unrelocated non-local symbol: _GLOBAL_OFFSET_TABLE_
Maxima encountered a Lisp error:

 Condition in COMPILE [or a callee]: INTERNAL-SIMPLE-ERROR: The assertion !emsg("Unrelocated non-local symbol: %s\n",st1+sym->st_name) on line 236 of sfaslelf.c in function relocate_symbols failed

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i1)

Thank you for your response, and my appologies for not responding earlier. I've been wondering if this could be caused by the recent upgrade of the GCC-toolchain from 5.x to 6. Would this be at all possible? Best regards

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:18 Created by robert_dodier on 2016-11-07 01:33:46 Original: https://sourceforge.net/p/maxima/bugs/3232/#fa7b

Thanks for the update. Since the GCL Lisp compiler calls GCC, my guess is that it's necessary to use the same GCC to compile GCL as whatever is executed when COMPILE is called. If it is convenient to you, maybe you can consider reverting to the previously-installed version of GCC. Otherwise, you might consider rebuilding GCL using the new version of GCC.

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:20 Created by andreas070898 on 2016-11-08 16:06:55 Original: https://sourceforge.net/p/maxima/bugs/3232/#4711

I tried reverting to gcc5. Didn't change a thing. But the GCL command wasn't even in my $PATH and the package wasn't installed. Could maxima (or at least the downstream version) be shipping with its own? I'm not sure on how to compile GCL on my own. I guess I would have to tell Maxima to use my new version instead of... what? The GCL that wasn't there? It's internal copy?

On a different note, I'm currently working on a big-ish school project, which takes a lot of my time, so my response times will probably continue like this the next month or so. Of course I hope we can find the bug earlier, but now you're warned ;)

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:22 Created by robert_dodier on 2016-11-27 21:24:59 Original: https://sourceforge.net/p/maxima/bugs/3232/#3799

rtoy commented 4 months ago

Imported from SourceForge on 2024-07-02 08:15:24 Created by robert_dodier on 2016-11-27 21:25:00 Original: https://sourceforge.net/p/maxima/bugs/3232/#2910

I've changed ezunits (commit ad86a80) so that it does not call compile so that should avoid this problem. It appears that compiling those functions doesn't make ezunits any faster so it's no loss to make this change. Closing this report as fixed. Thanks for your help, I appreciate it very much.