Type-error in KERNEL::INVALID-ARRAY-INDEX-ERROR-HANDLER: 44 is not of type (INTEGER 0 (44)) about quicklisp-client HOT 10 CLOSED

Can you include the output of (lisp-implementation-version) and so-forth to identify which ANSI CL implementation you are encountering this problem on?

from quicklisp-client.

from quicklisp-client.

Thank you for sharing the backtrace. That can be helpful.

What kind of Common Lisp are you using?

What are the files in /usr/share/emacs/presscode-earth/press-net/press-crypto? Those are not normally part of the Quicklisp load process.

from quicklisp-client.

Kindly thank You for comments.

Basically I am trying to avoid all external packages in an attempt to build the global voting system with the logging through the ssh, omitting all security risks related to the web browsers etc.

The goal is to sell the global voting system to the Governments, including the US one, as the votes counting is still ongoing, and the politicians are saying that it needs to be improved, because a lot of tensions can be avoided by having a robust voting solution in place.

Coming back to merit, the packages are easy to use, but without a full understanding of their underlying code it is rather unfair to say that "all code is safe".

Therefore there are so many links like: /usr/share/emacs/presscode-earth/press-net/press-crypto, I am writing patiently things from scratch, using only a very few external packages.

They will be also eliminated at the very end, but for example the Ironclad is massive - for the global voting system I only need 3% of it, but to extract this 3% it requires Budda under the tree, for 9 years : ). Nothing complicated, but the functions depend on the other functions, and so on.

The whole voting system works (worked..), until upgrading the Virtual Machine from Ubuntu 16.04 to 20.04, to get the newest OS, with an enhanced security.

IMPLEMENTATION_VERSION
CMU Common Lisp 21c (21C Unicode), running on ai.pressiton.com
With core: /usr/local/lib/cmucl/lib/lisp-sse2.core
Dumped on: Tue, 2018-10-02 13:00:50+02:00 on ai.pressiton.com
Send questions and bug reports to:[email protected],
or see http://www.pressiton.com/ines3/?module=cmucl_development.
Loaded subsystems:
Unicode 1.29 with Unicode version 6.2.0
Python 1.1, target Intel x86/sse2
CLOS based on Gerd's PCL 2010/03/19 15:19:03
Gray Streams Protocol Support
CLX X Library Telent CLX 0.7.3 + CMUCL mods, based on MIT R5.02
Motif toolkit and graphical debugger 1.0

CMUCL is used for the same reasons described above, it never let me down, and its code is well written by the CMU scientists.

SBCL / Lispworks are much bigger and more modern, but for the global voting system CMUCL is ideal.

The very moment when the system breaks is this one (errors are shown in the first post)

#-quicklisp
(let ((quicklisp-init #P"/usr/share/emacs/quicklisp/setup.lisp"))
(when (probe-file quicklisp-init)
(load quicklisp-init)))

(Quicklisp works perfect on Ubuntu 12, 14,16, 18, I was using it on the other VM-s, no issues, this is the first time when something happened)

So the problem is not related to CMUCL, as the other parts of the system works fine, it seems to me that it is the Ubuntu20.04 vs Quicklisp challenge.

And I hope Quicklisp will win it - please advise.

from quicklisp-client.

That sounds like quite interesting work!

SBCL being by far the most popular and best supported Common Lisp implementation, which furthermore is a direct descendant of CMUCL which has been vastly improved in countless ways, you should probably consider giving it a chance. This is likely to resolve many hurdles before you even encounter them.

from quicklisp-client.

This is a quiet thinking, but if this "global voting system" takes off somehow, I would like to setup a SPAC fund, with a goal of acquiring companies which use a Common Lisp as the main language in their business.

This may or may not to attract investors, but it was not done yet, and there is a big issue of synchronizing the IT part of the businesses at the M&A-s, it more and more often turns into a painful process because of the IT complexity, and it fails at the end.

So let's try to turn things around, and to treat the core programming language as the driver for the M&A decisions. We will see what investors say.

from quicklisp-client.

Sorry, I don't believe this is related to Quicklisp, but is a side-effect of your unusual combination of libraries, OS, and CL implementation.

from quicklisp-client.

Just a quick one - thank You the comments.
Stating that something "is not related" is equally important as finding error itself, because it is narrowing a searching path.

I did one thing more, namely I put a starting package of quicklisp
#-quicklisp
(let ((quicklisp-init #P"/usr/share/emacs/quicklisp/setup.lisp"))
(when (probe-file quicklisp-init)
(load quicklisp-init)))

at the very top of the site-init.lisp.

The INVALID-ARRAY-INDEX-ERROR-HANDLER is not showing up again, but other errors do show up when a quicklisp is loaded.

Why it is happening I dont know, because this unusual combination described above + quicklisp works perfectly on a second VM with the Ubuntu 18.

The first VM was only upgraded to the Ubuntu20, nothing else, so this error was a surprise, but I will eventually figure things up.

from quicklisp-client.

Restarts:
0: [RETRY ] Retry compiling #<CL-SOURCE-FILE "asdf" "build" "asdf">.

This seems like the compiler fails at compiling ASDF for whatever reason. I cannot really debug this further without a backtrace.

from quicklisp-client.

Thank You @phoe, it all works now, by starting all Quicklisp packages from the very top of the init.lisp.

Before this a Quicklisp packages were placed in positions where there where needed, and all worked fine.

Only when upgrading one of the VM-s to the Ubuntu20 the problem occurred, a previous upgrades from 14 to 16 and 18 went fine. I don't like not to know the reasons of the errors, because it often backfires later, but will leave this one alone for a time being. It all works properly.

from quicklisp-client.