* Value of given type cannot be case to its own type. @ 2021-02-10 15:12 J. Vincent Toups 2021-02-10 15:35 ` Per Bothner 0 siblings, 1 reply; 4+ messages in thread From: J. Vincent Toups @ 2021-02-10 15:12 UTC (permalink / raw) To: kawa I'm seeing this error: Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs) (lib.mecs cannot be cast to lib.mecs) Which on the face of things is kind of flabbergasting. The specific line of code which causes the issue suggests that it is indeed the case that the value lib.mecs@etc... is a lib.mecs instance and its being used as a lib.mecs instance. Any ideas? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Value of given type cannot be case to its own type. 2021-02-10 15:12 Value of given type cannot be case to its own type J. Vincent Toups @ 2021-02-10 15:35 ` Per Bothner [not found] ` <CAE8gMz2Bvb6XbCaL8cwEbbR-WMNYA+Eei91MPzJv_HAO_5fPMQ@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Per Bothner @ 2021-02-10 15:35 UTC (permalink / raw) To: J. Vincent Toups, kawa On 2/10/21 7:12 AM, J. Vincent Toups via Kawa wrote: > I'm seeing this error: > > Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs) > (lib.mecs cannot be cast to lib.mecs) > > Which on the face of things is kind of flabbergasting. The specific > line of code which causes the issue suggests that it is indeed the > case that the value lib.mecs@etc... is a lib.mecs instance and its > being used as a lib.mecs instance. We cannot possibly diagnose this without a test-case. There are various possibilities. The one that first comes to mind is a class-loader problem: There are two classes named lib.mecs, loaded using two different classloaders, and thus they are incompatible. Though that would be more likely to show up at run-time rather than compile-time. It is also possible that one of the "lib.mecs" is not a reference to an instance of the lib.mecs class (which would normally be the case), but some type that the Kawa compiler displays as lib.mecs. Off-hand I can't think of what that could be, but I would not be surprised to see that. This could be a Kawa bug, of course. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAE8gMz2Bvb6XbCaL8cwEbbR-WMNYA+Eei91MPzJv_HAO_5fPMQ@mail.gmail.com>]
* Fwd: Value of given type cannot be case to its own type. [not found] ` <CAE8gMz2Bvb6XbCaL8cwEbbR-WMNYA+Eei91MPzJv_HAO_5fPMQ@mail.gmail.com> @ 2021-02-10 16:38 ` J. Vincent Toups 2021-02-10 16:50 ` Per Bothner 0 siblings, 1 reply; 4+ messages in thread From: J. Vincent Toups @ 2021-02-10 16:38 UTC (permalink / raw) To: kawa ---------- Forwarded message --------- From: J. Vincent Toups <vincent.toups@gmail.com> Date: Wed, Feb 10, 2021 at 10:42 AM Subject: Re: Value of given type cannot be case to its own type. To: Per Bothner <per@bothner.com> I figured it out, actually. This may be something people new to Kawa experience from time to time so its worth describing here, I guess: The issue was that I had defined a class called mecs in lib and there was also a library called mecs in lib. So there were two classes lying around called lib.mecs. It makes sense in retrospect but I wonder if it might not also make sense to indicate in the class name of a library that it is produced by a define-library form rather than a class definition to prevent such classes in most cases. On Wed, Feb 10, 2021 at 10:36 AM Per Bothner <per@bothner.com> wrote: > > On 2/10/21 7:12 AM, J. Vincent Toups via Kawa wrote: > > I'm seeing this error: > > > > Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs) > > (lib.mecs cannot be cast to lib.mecs) > > > > Which on the face of things is kind of flabbergasting. The specific > > line of code which causes the issue suggests that it is indeed the > > case that the value lib.mecs@etc... is a lib.mecs instance and its > > being used as a lib.mecs instance. > > We cannot possibly diagnose this without a test-case. > > There are various possibilities. The one that first comes to mind is a > class-loader problem: There are two classes named lib.mecs, loaded using > two different classloaders, and thus they are incompatible. Though that > would be more likely to show up at run-time rather than compile-time. > > It is also possible that one of the "lib.mecs" is not a reference to > an instance of the lib.mecs class (which would normally be the case), but > some type that the Kawa compiler displays as lib.mecs. Off-hand I can't > think of what that could be, but I would not be surprised to see that. > This could be a Kawa bug, of course. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Fwd: Value of given type cannot be case to its own type. 2021-02-10 16:38 ` Fwd: " J. Vincent Toups @ 2021-02-10 16:50 ` Per Bothner 0 siblings, 0 replies; 4+ messages in thread From: Per Bothner @ 2021-02-10 16:50 UTC (permalink / raw) To: J. Vincent Toups, kawa On 2/10/21 8:38 AM, J. Vincent Toups via Kawa wrote: > The issue was that I had defined a class called mecs in lib and there > was also a library called mecs in lib. So there were two classes lying > around called lib.mecs. > > It makes sense in retrospect but I wonder if it might not also make > sense to indicate in the class name of a library that it is produced > by a define-library form rather than a class definition to prevent > such classes in most cases. This is covered in moderate detail here: https://www.gnu.org/software/kawa/Module-classes.html It is convenient and flexible to compile both a library (lib mecs) and a class mecs in package lib to the class lib.mecs. Sometimes (as you saw) there can be a clash, but I think the convenience makes up for it. Furthermore, changing it at this point might break things. Kawa should catch this situation if both classes are produced by the same invocation of the kawa command. (If not, that is arguably a bug.) However, if they're produced at different times, then it's harder to catch. Also, if Kawa is confused by an existing incompatible lib.mecs class while it is generating lib.mecs, that is also a bug. I've run into some problems like that in the past, and I've tried to fix them. If you have a reproducible simple test-case I can take a look. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-10 16:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-10 15:12 Value of given type cannot be case to its own type J. Vincent Toups 2021-02-10 15:35 ` Per Bothner [not found] ` <CAE8gMz2Bvb6XbCaL8cwEbbR-WMNYA+Eei91MPzJv_HAO_5fPMQ@mail.gmail.com> 2021-02-10 16:38 ` Fwd: " J. Vincent Toups 2021-02-10 16:50 ` Per Bothner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).