kernel/transform.lisp fails to compile in main (d167140)

Question

kernel/transform.lisp fails to compile in main (d167140)

mikelevins opened this issue 2 years ago · comments

Compilation of transform.lisp fails. SBCL reports that in the following code on line 156:

(setf (scaling (scale self)) (p:* (scaling (scale self)) s))

the derived type of the argument S should be (SIMPLE-ARRAY SINGLE-FLOAT (3)), but instead it's (VALUES NUMBER &OPTIONAL).

The method on scale-by claims that S is a NUMBER. The definition of * in vec3.lisp doesn't say what the types of its arguments are, but the doc string claims they are vectors, and that's consistent with the compiler error reported by sbcl.

mikel evins · Answer 1 · Mon Sep 19 2022 08:13:26 GMT+0800 (China Standard Time)

@JMC-design provides fixes for this, which are now merged with main

Kaveh Kardan · Answer 2 · Wed Sep 21 2022 04:53:44 GMT+0800 (China Standard Time)

I need a sanity check. Getting a lot of undefined point methods and style warnings when compiling main from scratch.

Anyone else seeing this, or is my branch somehow out of date?

I can fix the problems, but just want a sanity check before I do.

mikel evins · Answer 3 · Wed Sep 21 2022 05:10:33 GMT+0800 (China Standard Time)

I need a sanity check. Getting a lot of undefined point methods and style warnings when compiling main from scratch.

Anyone else seeing this, or is my branch somehow out of date?

I can fix the problems, but just want a sanity check before I do.

I just nuked my local copy, cloned it anew from github, confirmed that I was on the main branch, deleted the fasl cache, loaded the asdf file, loaded kon-9, opened the GLFW window, ran test-demos.lisp, closed and opened the window, and ran test-demos again.

It all worked as expected (except that I have done nothing about the lighting bug on reopen; doh!).

Kaveh Kardan · Answer 4 · Wed Sep 21 2022 05:13:55 GMT+0800 (China Standard Time)

The demos all work, but I see lots of style warnings and undefined point methods in the transcript. Do you get those?

E.g.

; file: /Users/kaveh/Development/kons-9/src/plugins/usd.lisp
; in: DEFUN KONS-9::POINT->USD-STRING
;     (KONS-9::Y KONS-9::P)
; 
; caught STYLE-WARNING:
;   undefined function: KONS-9::Y

mikel evins · Answer 5 · Wed Sep 21 2022 05:25:59 GMT+0800 (China Standard Time)

The demos all work, but I see lots of style warnings and undefined point methods in the transcript. Do you get those?

E.g.
; file: /Users/kaveh/Development/kons-9/src/plugins/usd.lisp
; in: DEFUN KONS-9::POINT->USD-STRING
;     (KONS-9::Y KONS-9::P)
; 
; caught STYLE-WARNING:
;   undefined function: KONS-9::Y

I do, yes. From experience, I'd guess--and this is just an untutored guess; I haven't rummaged through the relevant code--that we're defining things with forward references in them. For most things, forward references are fine as long as the forward references get properly resolved before anything that depends on them is actually evaluated.

We might like to clean those up, though, just so they don't obscure more significant warnings during compilation (and to make sure that none of them are actually real problems).

Kaveh Kardan · Answer 6 · Wed Sep 21 2022 05:29:01 GMT+0800 (China Standard Time)

There are some forward references, but there are also many actual undefined functions like the one I quoted, which should be p:y and not y.

I'll work on these. Stuff our new testing should catch. :)

mikel evins · Answer 7 · Wed Sep 21 2022 05:41:29 GMT+0800 (China Standard Time)

There are some forward references, but there are also many actual undefined functions like the one I quoted, which should be p:y and not y.

I'll work on these. Stuff our new testing should catch. :)

I sure hope so! If not, smack me.

Kaveh Kardan · Answer 8 · Wed Sep 21 2022 05:46:58 GMT+0800 (China Standard Time)

All compiler warnings addressed. Fixed.