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?
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/
---------- 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/
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/