armedbear-ticket May 2021

armedbear-ticket@common-lisp.net

1 participants
3 discussions

[armedbear] #485: Non-congruent generic method signatures cannot be eval'd
by armedbear 14 Aug '21

14 Aug '21

#485: Non-congruent generic method signatures cannot be eval'd -------------------------------+------------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: interpreter Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+------------------------- <https://irclog.tymoon.eu/freenode/%23abcl?from=1611187078> {{{ 0:12:54 emaczen Is there a setting I can change in ABCL to not care if a method definition does not have all the keyword arguments as another method? 0:13:14 emaczen does not accept all of the keyword arguments defined for the generic function -- This is the ABCL error I am getting 0:13:42 emaczen SBCL and CCL do not care 0:30:42 charles` Is that only for keyword arguments, because SBCL definitely cares if I have different # of parameters for same method name 1:19:18 robertm Maybe you could use &allow-other-keys ? (Just a guess.) 1:53:50 etimmons emaczen: Based on your description and some quick tests I'm guessing you're implicitly defining the generic function with defmethod. Try using an explicit defgeneric. 1:57:24 etimmons It does appear there's a bug in how defmethod defines the lambda list of the implicit defgeneric https://plaster.tymoon.eu/view/2247#2247 2:00:37 etimmons If (fboundp function-name) is nil, a generic function is created [...] the lambda list of the generic function will mention ..... key (but no keyword arguments) }}} Eval'ing non-congruent forms fails with a {{{simple-error}}} but compiling seems to work. -- Ticket URL: <https://abcl.org/trac/ticket/485> armedbear <https://abcl.org> armedbear

1 5

Re: [armedbear] #391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\*
by armedbear 28 May '21

28 May '21

#391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\* -------------------------+------------------------------------------------- Reporter: Mark | Owner: Mark Evenson Evenson | Type: defect | Status: accepted Priority: | Milestone: 1.8.1 critical | Component: | Version: 1.5.0-dev interpreter | Keywords: cl:probe-file ext:probe-directory Resolution: | cl:directory Parent Tickets: | -------------------------+------------------------------------------------- Comment (by Mark Evenson): Don Morrison notes in <https://mailman.common-lisp.net/pipermail /armedbear-devel/2021-May/004197.html> {{{ I don’t think I have the ability to comment on bugs in the issue tracker, or, if I do, I’ve not figured out how to do it. I hope sending mail to this list for the purpose is acceptable; apologies if not. I note that #391 was opened six years ago, but remains unfixed, and, apart from apparently being pushed off from release to release, seems not to have received any love for four years. I just wanted to add a note to it that it is still being encountered in the wild, and is, at least in one user’s case, causing some pain. File names containing asterisks may not be a good idea, but sometimes we have no control over the names of files we are given. It also means at least one (uiop:subdirectories), and probably many, UIOP functions sometimes fail in what can appear to be mysterious ways on ABCL, but not other implementations. }}} -- Ticket URL: <https://abcl.org/trac/ticket/391#comment:17> armedbear <https://abcl.org> armedbear

1 0

[armedbear] #486: Deployments from abcl-aio.jar can't find ABCL-CONTRIB
by armedbear 10 May '21

10 May '21

#486: Deployments from abcl-aio.jar can't find ABCL-CONTRIB -------------------------------+---------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: other Version: 1.8.1-dev | Keywords: abcl-aio Parent Tickets: | -------------------------------+---------------------- <https://github.com/armedbear/abcl/issues/372> {{{ I ran into this when I combined abcl.jar and abcl-contrib.jar together on the classpath via Maven, but it's more directly reproduced with an AIO jar: ant -f build.xml abcl-aio.jar ... java -jar dist/abcl-aio.jar --noinform CL-USER(1): (require :abcl-contrib) ("uiop" "UIOP" "asdf" "ASDF" "JAVA" "ABCL-CONTRIB") CL-USER(2): (require :jss) #<THREAD "interpreter" {66BA4A3B}>: Debugger invoked on condition of type SIMPLE-ERROR Don't know how to REQUIRE JSS. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): My suspicion is that the resolution of the JSS system is dependent on the colocation of abcl.jar and abcl-contrib.jar on the filesystem. When I run ABCL via java -jar abcl.jar in a directory that also contains abcl- contrib.jar, it works. }}} -- Ticket URL: <https://abcl.org/trac/ticket/486> armedbear <https://abcl.org> armedbear

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket May 2021