Make a new release?

[miguelmarco]

I am planning to write an interface to Kenzo from Sage. As part or that effort, I would like to include Kenzo as an optional or experimental package inside Sage. It would be helpful for that to have a newer release (the only one you have here is from 2015). Can you please create a new one?

[gheber]

Do you mean another release tag under https://github.com/gheber/kenzo/releases ? (BTW, there are monthly Quicklisp releases.)

[miguelmarco]

Yes, that is what I mean. The idea is to have an url to download a tarball.

[sphyynx]

Francis Sergeraert => miguelmarco. ================================================== /> I am planning to write an interface to Kenzo from Sage. As part or that effort, I would like to include Kenzo as an optional or experimental package inside Sage. It would be helpful for that to have a newer release (the only one you have here is from 2015). Can you please create a new one? / The "public" version of Kenzo, available on my web site, except for minor fixes, was finished in 1998. I propose to call it Kenzo-P. Another version, never made public, has the same general organization, many modules are copies of the corresponding modules in Kenzo-P, but the kernel around the Eilenberg-Zilber theorem, twisted or not, is totally different. The same for the implementation of the Eilenberg-Moore spectral sequences; in this case Kenzo uses conjectures easy to do, experimentally always correct, but not yet proved! Good thesis subjects there... I call this version Kenzo-DVF, for it uses the powerful tool "Discrete Vector Fields", strongly improving the computing time and the space complexity. Some critical computing times are so divided by 15, allowing us to reach a few new homology and homotopy groups, so far unknown. But the difference Kenzo-DVF/Kenzo-P is not at all documented. The external layer is the same, but the kernel is totally different. A totally different version of Kenzo, called Sphynx, is now in progress, but it is obvious several years will be necessary. The general idea is to produce a Lisp code as close as mathematics as possible, with the same flexibility, now possible thanks to CLOS, on the contrary poorly used in Kenzo. You understand Kenzo is now in the contorted fixed state described above, and our work is from now on devoted to Sphynx. If you like the idea, you may include Kenzo to Sage. More precisely Kenzo-P and Kenzo-DVF, warning the users about their respective status. If a Sage user meets a specific problem with either version, we can help. Bien cordialement.

[miguelmarco]

Thank you Francis. Our plan is to include what you call Kenzo-P. More precisely, the code in this repo, since we need it to be easily loadable from embedded common lisp (it is the lisp included in Sage, and there is already a pretty fast library interface between Sage and ecl).

At some point, we might need some auxiliary functions inside Kenzo to create simplicial sets from finite data (that is how Sage does it) in order to have a more flexible interface. We could send you pull requests with these functions, or, if you prefear, we could mantain a fork with them (we would prefear to keep it all in just one fork though).

Also, I would greatly appreciate if you could add a clear license file, so there is no doubt that it is compatible with Sage license (which is GPL v3+)

[miguelmarco]

Also, I would like to ask you: is there an easy way to compile all the kenzo system in a single .fas file?

[sphyynx]

Francis Sergeraert => miguelmarco. ================================================== /> Thank you Francis. Our plan is to include what you call Kenzo-P. More precisely, the code in this repo, since we need it to be easily loadable from embedded common lisp (it is the lisp included in Sage, and there is already a pretty fast library interface between Sage and ecl). / I guess Gerd has already studied the compatibility / ECL? /> At some point, we might need some auxiliary functions inside Kenzo to create simplicial sets from finite data in order to have a more flexible interface. We could send you pull requests with these functions, or, if you prefear, we could mantain a fork with them (we would prefear to keep it all in just one fork though). / Better to fork, so that I can guarantee a version under my responsability. Except minor changes taking account of some incompatibility with some or other Lisp version, there won't be any more significant change in Kenzo. I suppose your extra functions will be useful, in which case it will be possible to merge them and give up the fork. Gerd is more experienced than I, opinion? /> Also, I would greatly appreciate if you could add a clear license file, so there is no doubt that it is compatible with Sage license (which is GPL v3+) / This was already asked for and I do not remember what have been then done. I do not think there is a real danger, so that you may add the license you like in the forked version, which will be finally merged as well. Bien cordialement.

[sphyynx]

Francis Sergeraert => miguelmarco. ================================================== /> Also, I would like to ask you: is there an easy way to compile all the kenzo system in a single .fas file? / Kenzo is a *sequence* of source files. Except the first one, cat-init, just an init file, every file is organized to be compiled *and* loaded before processing the next one. I do not claim the various choices are the best ones. I never tried to catenate all the source files in the right order and to compile. I expect problems. In principle, playing with eval-when must solve any new problem, but it's relatively technical. The lazy lispers use simply the maximal case : (eval-when (:execute :load-toplevel :compile-toplevel) ...) which can create new problems... It is also possible to create a Lisp image, but 1) such an image file is enormous, 2) I suspect the integration in Sage quite difficult, or likely impossible. _____ I add the main goal of Kenzo is not computations. I like computations, but it was written only to prove to the sceptic topologists 1) it can be written down, 2) it can even produce new results. The initial goal, before Kenzo, was only mathematical: how the various standard exact and spectral sequences of Algebraic Topology can be transformed into algorithms. Which they are not, a point most topologists do not understand. I was very anxious about computing times when beginning the work explaining why the kernel of the Eilenberg-Moore spectral sequence is poorly programmed, in an assembly-like style, to be efficient. It is efficient but quite difficult to read, quite difficult to maintain, and still more difficult to extend. Explaining why the kernel of Sphynx is so difficult to write down, I want something without these drawbacks. Bien cordialement.

[miguelmarco]

Thanks for the answers. I agree it makes sense to fork so we can experiment with the changes we need, and maybe later merge.

[miguelmarco]

BTW, i did find the way to compile into a single .fas file.

(require :asdf)
(push #P\"./\" asdf:*central-registry*)
(require :kenzo)
(asdf:make-build :kenzo :type :fasl :monolithic t :move-here #P\"./\")
(quit)

seems to do the trick. It produces a 4MB file, which is fine. I have just done trivial tests with it, but found no problem so far.

[sphyynx]

Francis Sergeraert => miguelmarco. ================================================== /> BTW, i did find the way to compile into a single .fas file. (require :asdf) (push #P\"./\" asdf:*central-registry*) (require :kenzo) (asdf:make-build :kenzo :type :fasl :monolithic t :move-here #P\"./\") (quit) / Good! The next time I need the help of an asdl wizard, I know what the competent man is. Bien cordialement.

[jcguu95]

What's the status of Kenzo-DVF and Sphynx? Any help needed?

[adlai]

BTW, i did find the way to compile into a single .fas file.

...
(asdf:make-build :kenzo :type :fasl :monolithic t :move-here #P\"./\")

seems to do the trick. It produces a 4MB file, which is fine. I have just done trivial tests with it, but found no problem so far.

Alternatively, you could try wrapping critical sections with eval-when (at worst, each file in one huge block), and then concatenating all the source files. The advantage of this approach is that you'd have one file of source code, mirroring the monolithic compiled file; although honestly the source code is probably more accessible as separate files.