[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guilev1/2 musing
Re: guilev1/2 musing
Fri, 25 Jan 2019 00:21:41 +0100
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Valentin Villenave <address@hidden> writes:
> On 1/24/19, David Kastrup <address@hidden> wrote:
>> Development happens on Guile2, none on Guile1.
> That’s what I’m worried about: if we *were* to include guile1 as a git
> submodule (effectively forking it, although I don’t imagine many Lily
> devs are gonna be fiddling with its codebase), what are the
> sustainability prospects in the long run? (e.g. when new major GCC /
> glibc / whatever versions come around, breaking compatibility at some
If you take a look at the Guile repository, the 1.8 branch already broke
with Texinfo developments, possibly also gcc (don't remember) and Thien
Thi Nguyen (I think) pushed a few fixes for that.
Pretty sure that Thien Thi still uses Guile 1 for some application. At
any rate, the kind of fixes needed in such cases are usually
comparatively straightforward to come up with.
> *Or* can we safely regard Guile v1 as "stable" and reliable on a
> long-term perspective (much like you no longer need to worry about new
> version of TeX coming out, or a very narrow number of other programs
> deemed "frozen in perfection")?
Not really. Non-catastropic bugs are definitely not getting fixed.
> If so, sticking with v1 would mean better performance, greater
> stability *and* acceptable sustainability (and besides as you noted,
> even Guile v2 depends on very few devs, thus keeping the
> getting-hit-by-a-bus factor fairly high anyway). And including Guile
> v1 as a submodule could make life easier for users whose distros no
> longer offer a guile1(-devel) package, couldn’t it?
> On an unrelated subject, am I the only one puzzled by the fact that,
> although the global situation with Guile 2.0 was a mess, still they
> went ahead and released new major versions, a.k.a. 2.2 and 2.4? Or is
> it a year-based release cycle where the numbers don’t mean anything?
> Very unusual within GNU programs.
Who is "they"? How many "developer branch" commits do you see from
anybody else but Andy Wingo that aren't forward-ported bug fixes from
the more stable branches? The Guile compiler and VM is his playground
for compiler technology. There is no discussion whatsoever regarding
its development (and/or the unstable branches) on the Guile mailing
lists, and commits are partly back-and-forth with stuff not working in
between and complete recodings of stuff sometimes. The other
"developers" clean up on the stable branches, cherry-picking into the
unstable branch where necessary.
There are definitely impressive benchmark improvements as long as you
don't look at string handling too much and don't pass data into and out
of Guile again and don't use the API. As a native Scheme environment
rather than as an extension language needing to interface with C++ and
other stuff, there are interesting things in there. It's just a bad
match for what we have been doing with Guile and need to do with it.
- guilev1/2 musing, Thomas Morley, 2019/01/24
- Re: guilev1/2 musing, Thomas Morley, 2019/01/24
- Re: guilev1/2 musing, Karlin High, 2019/01/24
- Re: guilev1/2 musing, Valentin Villenave, 2019/01/25
- Re: guilev1/2 musing, David Kastrup, 2019/01/25
- Re: guilev1/2 musing, Thomas Morley, 2019/01/25
- Re: guilev1/2 musing, Valentin Villenave, 2019/01/28
- Re: guilev1/2 musing, Thomas Morley, 2019/01/28