[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Exploiting hashes for Scheme refactoring
From: |
Nathan Benedetto Proença |
Subject: |
Exploiting hashes for Scheme refactoring |
Date: |
Mon, 05 Jul 2021 11:33:36 -0300 |
Good morning!
As a new Guix developer, I want to learn about workflows which help me
catch bugs in Scheme development.
Is it a good idea to exploit Guix hashing infrastructure to ensure that
a Scheme refactoring did not change the packages produced?
Has some developer already done that?
Are there another tools and techniques I should be aware of?
As I said in the other email I sent to the mailing list, I am interested
in upgrading the texlive package in tex.scm.
Depending on what you teach me there, a solution could involve changing
more than 100+ places where the origin of packages is specified.
Without proper tooling, this can demand a whole lot of developer time
--- be it my time, or other contributors time.
Would this imply more than 100+ patches submitted and reviewed, and
perhaps in an alternative branch which core developers would have to
maintain?
Then I noticed I could use the hashes for the packages produced as a
test of whether my refactor was satisfactory or not.
For example, let's say I want to change the signature of a function.
I could simply change the function, and Emacs my way into changing the
call sites (Occur-mode, search-replace, or perhaps a some custom
elisp).
While developing, I could simply test if the hash of a single
package was the same as its previous hash.
When I got confident with my change, I could then log to a machine
stronger than my notebook and test if *every* package I touched has the
same hash as the previous one.
This log/procedure could even be sent together with a possible patch, so
to help reviewers trust my patch.
Is this a good use of hashes?
Are there similar techniques already in place?
Thanks in advance,
Nathan
- Exploiting hashes for Scheme refactoring,
Nathan Benedetto Proença <=