[PATCH] Improved error detection and reporting in RESTART-BIND

[Spiros Bousbouras]

On  Fri, 19 Jul 2019 22:15:42 +0200  Daniel Kochmański wrote:
> thank you for your contribution. We do not accept patches over mailing
> list. Instead we prefer merge requests on our repository.

So
    If you want your code in Embeddable Common-Lisp project, please
    send a patch to mailing list with additional tag [PATCH] in
    subject.

which appears in  common-lisp.net/project/ecl/static/quarterly/ecl-quarterly.org
is no longer valid ? I don't recall this being mentioned on the mailing list.

> This makes
> possible peer review, requeesting changes and continous integration.
> 
> Repository is located here:
> https://gitlab.com/embeddable-common-lisp/ecl
> 
> Please create a git commit with detailed commit message and make a merge
> request there. Branch used for development is called "develop" (it will
> be cloned as default unless you specify it otherwise).
> 
> If you are not familiar with gitlab workflow here's how it goes:
> - [on gitlab] create an account on the platform
> - [on gitlab] fork the repository into your personal userspace
> - [locally] clone the repository from your fork
> - [locally] do appriate changes on your computer and make git commit
> - [locally] push to your local repository
> - [on gitlab] go to merge requests tab and select "new merge request"

Unfortunately  gitlab.com  gives at present an SSL error with all my browsers
so I would have to move to a newer version of Linux before I'm able to access
it and it will be a while before I get around to that. I note that I can
access  gitlab.common-lisp.net .I'm mentioning this because  ecl-quarterly.org
says

   After 15.3.7 release there are a few changes going on. We are now
   hosted at gitlab.com (however it would be nice to move to
   gitlab.common-lisp.net, just /not now/),

> While this patch is small and I could manage merging it (although it is
> made against ecl 16.1.3 version, so patch may fail against develop
> branch), I'm anxious about setting a precedence - working with patches
> manually is more time-consuming on my part. I hope that this explanation
> is sufficient to you.

Yes , I understand. In any case it turns out that the mailing list mangled
the code. At 2 places when my patch has  ", at forms" , that is a comma followed
by the at sign followed by "forms" , the list shows this as  ", at forms" .
This is probably a bug with the list software. I'm sending this message
BASE64 encoded so we'll see if the  comma-at  sequence suffers the same
transformation.