I have to apologise for the massive hatched-job I did with that "rebase"! :P Some references to my own modules were left in, other variables mixed up, etc.
I think it's in better shape now. Checked that tests run at least! It's the same feature branch URL <https://github.com/dadinn/guile/tree/wip-hygienic-expect>... but I've force pushed it! ;) Best regards, Daniel Dinnyes On Sun, 11 Jun 2023 at 16:48, Daniel Dinnyes <dinny...@gmail.com> wrote: > I've rebased my changes onto a fork of Guile's main branch on Github: > https://github.com/dadinn/guile/tree/wip-hygienic-expect > > Added back the original attributions and comments. > I've also tried to follow the branch-naming conventions. 😉 > > Also, I've added a module ice-9/expect-tests for some comprehensive tests. > Wasn't sure where to place it, and how to integrate into the existing > test-suite. > > Not sure how to send a PR by email, but I suppose it should be easy to > pull, by adding my fork as an additional remote. > > Best regards, > Daniel Dinnyes > > > On Mon, 29 May 2023 at 22:33, Maxime Devos <maximede...@telenet.be> wrote: > >> >p 29-05-2023 om 03:40 schreef Daniel Dinnyes: >> > Thanks for the reply. >> > >> > On Sun, 28 May 2023 at 14:39, Maxime Devos <maximede...@telenet.be >> > <mailto:maximede...@telenet.be>> wrote: >> > >> > I think this would gather more replies if: >> > >> > 1. It is sent as a patch that can be applied to the Guile source >> > tree. >> > >> > (You wrote: >> > >> > > If the community likes this implementation, I would be happy to >> > > apply/rebase my changes onto the official repo, and then we can >> go >> > > from there! >> > >> > but to determine whether I'm happy with it, it would be convenient >> if >> > this were a proper patch.) >> > (I'm not actually reviewing Guile stuff at the moment, but I find it >> > likely that some others might hold the same view.) >> > >> > >> > Regarding patches, I think I've read somewhere that GNU wants >> > contributions in some different format, >> > than just URLs to pull-able GIT repos. Could you share with me some >> > guide how to do such patches, >> > or what format they are needed? >> >> Format: the result of 'git send-email', or 'git format-patch + attach >> the patch as an attachment'. I've heard that the guide at >> <https://git-send-email.io/> for 'git send-email' is good. >> >> Still, setting up a fork + sending a PR (by e-mail), while not the most >> preferred format, would still be pretty good (‘git diff’ can then be >> used!). >> >> > I am assuming this <https://git.savannah.gnu.org/cgit/guile.git/> is >> the >> > repo of current guile tree, onto which to apply my changes. >> >> Yes. >> >> > Onto which branch? >> >> The branch named 'main'. >> >> > Would it possible to fork the repo on savannah, and then raise a PR >> from >> > there instead of patches? >> >> Savannah doesn't have a notion of 'forks' AFAIK. (Emphasis on the ‘I >> don't know’ in ‘AFAIK’, maybe it actually does have them in some form.) >> >> However, you can do a PR ‘manually’ by setting up a fork of the repo at >> some random hosting site of your choice, pushing some commits there, and >> sending a (free-form) e-mail to guile-devel@gnu.org with a message >> containing information on where to find the repository and which >> branch/commit. >> >> (You don't need PR / fork buttons to do PRs and forks!) >> >> > Also, I've tried to create account on savannah, but it keeps getting >> > deleted. >> > What would you recommend I do to ensure my account doesn't get removed? >> >> I don't have clue; I only fetch from savannah, I don't have an account >> there. >> >> > [...] >> > I am not sure I would agree with your assessment about /illegality/, >> and >> > the /derivative work/ categorization. >> > Even though these macros happen to expand to something similar as the >> > original ice-9 implementation, >> > the code itself is quite significantly different! If this is to be used >> > in ice-9, it would have to completely >> > replace the original expect.scm file, as nothing was copy/pasted from >> > there. The fact that parameter binding >> > names are the same is necessary for backwards compatibility, so those >> > wouldn't count even under the US laws >> > <https://www.bbc.co.uk/news/technology-56639088>. >> >> I assumed it is a derivative work because you presented it as a ‘rewrite >> of [the original]’. Maybe it's possible to rewrite something a lot >> until its no longer a derivative work (I don't know if that's possible), >> but by default I'd assume that rewrites are derivative works. >> >> I didn't use ‘same procedure names’ as a reason (as you wrote, those >> aren't a problem). >> >> > On second thought, I am wrong! The expect-select helper function looks >> > like a direct copy-paste job... little naughty me! >> >> TBC, I ascribe no guilt. The thing is that I've noticed in the past >> that people often use the GPL without knowing what that entails >> precisely, which can have unintended consequences, like e.g. >> unintentionally licensing something as GPLv1+ instead of GPLv3+ (or >> GPLv3+ instead of GPLv3, but that mistake is actually pretty convenient >> for distributions :P). >> >> (Also, Guile relies on the (L)GPL as a form of protection against some >> forms of malice, so I think it's important that we also follow the >> (L)GPL terms itself.) >> >> > Nevertheless, I would be happy to add the necessary notices if that is >> > required. >> > Also, IIRC there would be another copyright assignment administrative >> work >> > somewhere down the line? >> >> The copyright assignment used to be required, but nowadays its optional. >> Still, it does appear to be preferred. You would get an e-mail by a >> Guile maintainer with more info, it's not something you initiate yourself. >> >> The page https://www.fsf.org/licensing/contributor-faq sort-of implies >> the opposite, but IIRC there is another page somewhere or gnu.org that >> doesn't; I don't know what's up with that. (Either way, I'd think that >> things will work out in the end.) >> >> Best regards, >> Maxime Devos >> >
