felix.winkelm...@bevuta.com writes:
>> '(list a123) -> `(list ,(gensym 'a123)), where the symbol a123 is the
>> name of the TV. This symbol is used to store a value in the unification
>> trail.
>
> Note that you could store the original name on the plist of the gensym,
> then deref the chain
> '(list a123) -> `(list ,(gensym 'a123)), where the symbol a123 is the
> name of the TV. This symbol is used to store a value in the unification
> trail.
Note that you could store the original name on the plist of the gensym,
then deref the chain of gensyms/orig names when printing.
felix
Evan Hanson writes:
> Hi folks,
>
Hi Evan!
[snip]
> * Patch 0012 - I don't think the name provides much benefit, and in
> any case the way it was printed (with parens) was visually
> confusing. Better to use "; " or the like, later.
I didn't like that either. I just didn't have
> I've just pushed most of these patches, with signoffs, to a branch
> called "scrutiny-message-formatting", and I think we should merge it.
I have merged the branch into master.
The messages are nice, but may be a bit over the top, regarding
verbosity. Still, it is an improvement.
felix
felix.winkelm...@bevuta.com writes:
>> Hi folks,
>>
>> I've just pushed most of these patches, with signoffs, to a branch
>> called "scrutiny-message-formatting", and I think we should merge it.
>
> Thanks for doing this, I've ran the tests and so far things look good.
>
> I'm a bit concerned
> Hi folks,
>
> I've just pushed most of these patches, with signoffs, to a branch
> called "scrutiny-message-formatting", and I think we should merge it.
Thanks for doing this, I've ran the tests and so far things look good.
I'm a bit concerned about the verbosity of the warnings. For
Hi folks,
I've just pushed most of these patches, with signoffs, to a branch
called "scrutiny-message-formatting", and I think we should merge it.
I actually reviewed all of these some time ago, and while there are
still some changes and additions I'd like to include, I haven't had time
to
On 2019-01-12 14:49, megane wrote:
> Here's a modified patch that does these two things.
Thanks, here's a sign-off (also updated to work on Windows) as well as
the first patch again so they can be applied in sequence.
> It occurred to me that perhaps redact-gensyms shouldn't use XXX as the
>
Evan Hanson writes:
> On 2019-01-10 18:12, megane wrote:
>> Evan Hanson writes:
[snip]
>> Do you agree with approach I took about gensym'd variables in the second
>> patch? If not, I think I'll have to come up with something else.
>
> That's a nice idea, I think it's probably fine. But if
On 2019-01-10 18:12, megane wrote:
> Evan Hanson writes:
> > Here's a signed-off version of the first patch in this set. I've also
> > updated the Windows test script and added the new files to the
> > distribution manifest.
> >
> > Please feel free to review and apply this one without waiting
Evan Hanson writes:
> Here's a signed-off version of the first patch in this set. I've also
> updated the Windows test script and added the new files to the
> distribution manifest.
>
> Please feel free to review and apply this one without waiting for the
> others in megane's message. Doing it
Here's a signed-off version of the first patch in this set. I've also
updated the Windows test script and added the new files to the
distribution manifest.
Please feel free to review and apply this one without waiting for the
others in megane's message. Doing it gradually is the only way we'll
Heads up.
This needs to be updated as 0011 is now in the master branch. I'll
update both of these batches and try to write better commit messages for
them too.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
>
> Here's the patchset without the first commit.
>
Thanks, much appreciated. Now we just have to find someone who understands
the scrutinizer and can review these patches... :-)
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
On Mon, Nov 19, 2018 at 08:16:45PM +0100, felix.winkelm...@bevuta.com wrote:
> Be that as it may, I don't think such changes have any benefit. We don't
> follow a beauty contest, content is more important as the amount of
> whitespace,
> comment or indentation style and so on. Changes of
> > I'm vehemently against patches that merely change whitespace or
> > layout (patch 1/9) and make it impossible to track changes properly.
>
> You can give the -w switch to git blame to see through whitespace
> changes. Or (setq vc-git-annotate-switches '("-w")) in emacs if you're
> using
felix.winkelm...@bevuta.com writes:
>>
>> Hi,
>>
>> Here's a reworked patch set. It's not exactly small, but I tried to make
>> it pretty easy to follow. Except maybe for the last patch, which
>> digs for some extra info from the nodes.
>>
>> There's small bit of back-and-forth in the
>
> Hi,
>
> Here's a reworked patch set. It's not exactly small, but I tried to make
> it pretty easy to follow. Except maybe for the last patch, which
> digs for some extra info from the nodes.
>
> There's small bit of back-and-forth in the patches:
> - errors? is taken out of let and put
Hello,
This patch changes the warning messages so that any types are printed
with `pp` on new lines. This should make it just a bit easier to find
the reason for more complex type mismatches.
See the attachment for sample output.
diff --git a/scrutinizer.scm b/scrutinizer.scm
index
19 matches
Mail list logo
