Building Racket CS? Please switch to github:racket/ChezScheme

[Matthew Flatt]

The makefiles at https://github.com/racket/racket used to pull
ChezScheme from https://github.com/mflatt/ChezScheme, but I've switched
that to https://github.com/racket/ChezScheme (because it appears that
Racket-specific patches will be need for a long time).

For now, I'll keep pushing to https://github.com/mflatt/ChezScheme, but
I'll stop eventually. So, if you have a clone of that repo --- maybe in
"racket/src/build/ChezScheme" as created by `make cs` --- please switch
it to point at https://github.com/racket/ChezScheme.

[Paulo Matos]

On 21/04/2019 17:44, Matthew Flatt wrote:
> The makefiles at https://github.com/racket/racket used to pull
> ChezScheme from https://github.com/mflatt/ChezScheme, but I've switched
> that to https://github.com/racket/ChezScheme (because it appears that
> Racket-specific patches will be need for a long time).

Did you truly mean 'long' here or 'longer'? As I read it, it feels that
there are some issues upstreaming to ChezScheme that won't be solved any
time soon, if ever.

Could you please expand what sort of patches cannot be easily upstreamed
to Chez?

--
Paulo Matos

[Matthew Flatt]

At Tue, 23 Apr 2019 10:42:39 +0200, "'Paulo Matos' via Racket Developers" wrote:
> On 21/04/2019 17:44, Matthew Flatt wrote:
> > The makefiles at https://github.com/racket/racket used to pull
> > ChezScheme from https://github.com/mflatt/ChezScheme, but I've switched
> > that to https://github.com/racket/ChezScheme (because it appears that
> > Racket-specific patches will be need for a long time).
>
> Did you truly mean 'long' here or 'longer'?

I'll stick with "long".

> Could you please expand what sort of patches cannot be easily upstreamed
> to Chez?

Some open pull requests at https://github.com/cisco/ChezScheme/pull/:

#190 - ordered guardians 7/2017
#192 - cptypes 7/2017 - 7/2018
#237 - procedure wrappers 12/2017
#254 - avoid some recompiles 1/2018
#296 & #377 - values enforced 5/2018 - 12/2018
#335 - memory debugging 7/2018
#336 - continuation marks 7/2018
#375 - fasl read repair 12/2018
#376 - vfasl 12/2018
#378 - memory accounting 1/2019

The oldest one, #190, hasn't been merged because it's a significant
change to the GC, and it requires some duplication of information
within the implementation: an extra dispatch on various shapes of data.
This sort of problem might be resolved (in a way that appeals to the
Chez Scheme maintainers) by generating the GC's code from a centralized
description of object shapes/traversals, and that would also help with
#335 and #376.

More generally, #190, #237, #376, and #378 solve problems that are
important to Racket, but not to Chez Scheme users generally, and so the
code--benefit tradeoff is not motivating to the Chez Scheme
maintainers.

#192 (Gustavo's work) is similar, but on its own scale. It's much more
code, but the potential benefit to Chez Scheme users is also much
greater. My guess is that this one gets merged before any of the
others.

#266, #377, and #336 are about continuation marks and related semantic
choices. The Chez Scheme maintainers are unconvinced of the value of
continuation marks and constraining the compiler to sometimes preserve
non-tailness.

#375 seems like a straightforward improvement to me, so ¯\_(ツ)_/¯.

#254 and #335 not exactly Racket-specific, but maybe others would
approach the motivating problems differently than I have.

There are another dozen or so small patches that I haven't turned into
PRs because they tend to be even more Racket-specific. It doesn't make
sense to pile those on.


To be clear, the Chez Scheme maintainers have been quick to merge
changes that more obviously benefit all Chez Scheme users. A recent
example is the addition of LZ4 compression as an alternative to zlib;
that was a relatively invasive change to the build and a pile of new
glue code, but it was refined and merged quickly and has since been
improved.


Matthew

[Matthew Flatt]

At Tue, 23 Apr 2019 10:18:05 -0400, Matthias Felleisen wrote:
> Would it make sense to fork Chez?

While we have already forked Chez Scheme in the sense that GitHub
reports at the top of https://github.com/racket/ChezScheme/, I think
our fork is more usefully described as a set of patches to Chez Scheme.
I've tried to keep the Racket-specific changes organized that way (with
each patch recorded in a branch), and we sync with the main Chez Scheme
repo regularly. This approach should continue working for the
foreseeable future.