astmatcher-demo exposes major bugs in bclasp 0.3-test-7-8-g42f5e53

Georgiy Tugai georgiy.tugai at gmail.com
Fri Jul 10 12:13:14 UTC 2015


"Bad keyword argument" apparently means that a Lisp lambda-list (without
&allow-other-keys) is receiving a keyword which is not in the set of
known arguments.

MATCH-RUN's argument signature has changed since astmatcher-demo was
first written, thus the issue.

I understand that Clasp is alpha software and thus unexpected major API
changes are business as usual, however it'd be nice to have some
backwards compatibility or graceful failure (whether a message to the
effect of "use this instead", or more useful error messages; e.g. "bad
keyword argument" reporting the symbol name rather than a pointer).

In this particular case, backwards compatibility can be achieved quite
easily, however if there are few current users of this API (other than
astmatcher-demo), this would only create code cruft in Clasp.

Regards,
Georgiy

On 10 Jul, Georgiy Tugai wrote:
> Most of these issues have been resolved as of 0.3-test-8-4-g653ee86,
> however the "Bad keyword argument" error is still extant.
> 
> Regards,
> Georgiy
> 
> On 09 Jul, Georgiy Tugai wrote:
> > I decided to test astmatcher-demo[1] (known to be working on f7948ae
> > i.e. tip of master) on bclasp 0.3-test-7-8-g42f5e53 (tip of newbuild at
> > the time).
> > 
> > First, there is a missing external symbol
> > NEW-DEDUPLICATING-REFACTORING-TOOL (called from
> > src/lisp/clang-tool.lsp). I assumed that NEW-REFACTORING-TOOL would be a
> > suitable replacement, evaluated the calling function definition (C-M-x
> > in SLIME) and moved on.
> > 
> > Then, a series of undefined symbols (see Table 1) followed, each one
> > "fixed" by C-M-x.
> > 
> > After this, astmatcher-demo's GET-CLASSES fails with "Bad keyword
> > argument" followed by a large number (for example, 69993087673325; a
> > decimal pointer address?) which was different between bclasp instances.
> > 
> > On further investigation, it is interesting to note that LOADing
> > clang-tool.lsp rather than REQUIREing 'clang-tool results in more
> > undefined symbol errors (including the external symbol
> > REPLACEMENTS-AS-LIST). I believe this is indicative of a significant
> > difference between evaluation and compilation in bclasp.
> > 
> > Table 1: clang-tool.lsp symbols misreported as undefined
> > +----------------+--------------------------------------+
> > |           DEFUN|IDENTIFY-HINT-ENVIRONMENT             |
> > |DEFINE-CONDITION|NODE-MATCHER-AMBIGUOUS-ERROR          |
> > |           DEFUN|ERROR-UNLESS-VALID-PREDICATE          |
> > |     DEFCONSTANT|+NODE-MATCHERS+                       |
> > |           DEFUN|IDENTIFY-NODE-MATCHER-ENVIRONMENT     |
> > |     DEFCONSTANT|+TRAVERSAL-MATCHERS+                  |
> > |           DEFUN|IDENTIFY-TRAVERSAL-MATCHER-ENVIRONMENT|
> > |           DEFUN|APPLICABLE-MATCHER-P                  |
> > |           DEFUN|MATCH-RUN                             |
> > +----------------+--------------------------------------+
> > 
> > References
> > [1] https://github.com/drmeister/astmatcher-demo
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/clasp-devel/attachments/20150710/d091e2da/attachment.sig>


More information about the clasp-devel mailing list