Hans Åberg <haber...@telia.com> writes: >> On 23 May 2018, at 12:20, David Kastrup <d...@gnu.org> wrote: >> >> ... work on "the problem" has moved beyond the stage where one can >> just propose a generic solution, everybody slaps his forehead and >> gets to work and does what it takes to do. > > How about using what I suggested and what you touched upon in your > link?
Hans, with regard to the LilyPond code base you don't know what you are talking about. First, LilyPond is not in a state where you can get serious work done with Guilev2 (memory consumption and speed are too far off the mark) so the Boehm GC is just a theoretical consideration for the bulk of the code base. Second, its organization is such (using loads of STL data structures with their own allocation for storing structures containing only some SCM values) that the Boehm GC approach does not make for a good match with wholescale conservative scanning without employing mark hooks. Guilev2, including its use of the Boehm GC, is optimized for applications that are principally Scheme, and it works also for applications that are principally C++ in their approach. Or at least small. LilyPond is huge, with large resource demands, and it's sort-of half Scheme and half C++, both regarding its data structures as well as the data itself. Guilev2 support by now is workable enough that somebody actually cluing himself in and working with the respective patches/branches can get a working setup for experimentation. If you want to gather your own experience in that area and give actually qualified advice and code proposals, feel free to do so. >> So if you want to be helpful, let go of your consultants' hat and don >> the programmers' hat. > > I looked a bit at the LilyPond C++ code, but looks so 1990s, and I am > on C++17. It doesn't actually look a whole lot like code written in 1990s either since much of it is done using specific SCM/C++ glue. Not as bad as the C code base of Emacs looks (which is tied more closely into Elisp than LilyPond into Guile since Elisp does not exist as a separate interpreter inside of Emacs) but bad enough. At any rate, feel free to submit patches. Due to compatibility considerations, a currently acceptable standard to write to would be about C++11 by now. The current code base is basically C++98 since the last time C++11 features were considered, general availability and quality of compilers in distributions was mottled. It has to be noted that the code base of LilyPond is large enough that gratuitous wholesale rewrites to follow standards are not really feasible given its programmer base, and one needs to balance code aesthetics with maintainability: code that only one person feels at home with does not really help. >>> and instead of a suitable reply, I get an endless row of rants, and >>> now you fill in with those. >> >> Just as a reminder: this thread is offspring from an endless row of >> rather insulting and condescending rants about LilyPond's >> limited-precision rational numbers and you jump-started... > > I started a new thread to get away from that. > >> ...a set of lectures on the Boehm GC on it predicated on the premise >> that I don't know my way around it. Now the other guy clearly >> intended to be both insulting and condescending in order to get his >> bidding done. In contrast to that, you are only condescending and >> more or less add accidentally to the implication that everybody >> involved with LilyPond programming has to be an idiot compared to >> yourself. > > You are on the right way, but your personality gets in the way of > thinking it through. Since you don't suffer from any such similar problem, how about thinking it through yourself and submitting the finished patch(es) for review? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel