gendl issueshttps://gitlab.common-lisp.net/groups/gendl/-/issues2015-03-31T02:17:17Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/125:ajax-submit-on-change? for form-controls always results in innerHTML refresh...2015-03-31T02:17:17ZDave Cooper:ajax-submit-on-change? for form-controls always results in innerHTML refresh -- is it needed?*Created by: genworks*
As it is currently, if you have a sheet-section with a form-control (a type of base-form-control from gwl/form-elements/source/primitives.lisp), and specify :ajax-submit-on-change? t, this will _always_ result i...*Created by: genworks*
As it is currently, if you have a sheet-section with a form-control (a type of base-form-control from gwl/form-elements/source/primitives.lisp), and specify :ajax-submit-on-change? t, this will _always_ result in the inner-html being "dirty" (i.e. :unbound) after the submission, therefore the innerHTML for the sheet-section will be refreshed via Ajax. In case that the form-control itself is the _only_ thing which was modified as a result of the submission, it might not be strictly necessary to refresh the HTML -- after all, the browser already has the correct state.
It has been reported by Reinier van Dijk that this over-zealous updating of the inner-html for the sheet-section sometimes "messes up the UI." On the other hand, allowing the inner-html to update does guarantee that the View (i.e. the content of the web page) will exactly match the Model (i.e. the sheet-section and form-control objects in Gendl). In other words, updating the inner-html acts to confirm for the user that the intended values from the View (browser) were indeed passed successfully into the server (the Model), through the Controller (i.e. the gdlAjax logic).
A self-contained example of how the UI can be "messed up" by the refresh of the inner-html of the sheet-section containing the form-control in question will be of great assistance in determining whether this is behavior which should be changed. In theory, it would be possible to detect when the form-control value is indeed the _only_ thing affected by the Ajax submission, and in that case to suppress the refreshing of the inner-html.
**Imported comments:**
*By genworks on 2013-01-12 22:57:53 UTC*
@reiniervandijk you may be interested in following this Issue.https://gitlab.common-lisp.net/gendl/gendl/-/issues/124menu-form-control does not clear entries with :ajax-submit-on-change?2015-03-31T02:17:17ZDave Coopermenu-form-control does not clear entries with :ajax-submit-on-change?*Created by: genworks*
Reported by @reiniervandijk (with a proposed contributed solution).
When menu-form-control is used with multiple selections and :ajax-submit-on-change? t, and you deselect all the entries, nothing is sent to...*Created by: genworks*
Reported by @reiniervandijk (with a proposed contributed solution).
When menu-form-control is used with multiple selections and :ajax-submit-on-change? t, and you deselect all the entries, nothing is sent to the server and so the clearing of the entries is ineffective.
This needs a self-contained test case and implementation of solution. Note that we intend to replace the messy raw base64-encoding with a cl-json (JSON) approach for all the data exchange for gdlAjax, so this might be a good trigger point to move to that approach rather than continuing to add to the spaghetti that is the current gdl-ajax-call in skeleton-ui-element.
**Imported comments:**
*By genworks on 2013-01-14 19:30:34 UTC*
Fix commited in gdl/gwl/static/gwl/js/gdlajax.js
https://gitlab.common-lisp.net/gendl/gendl/-/issues/123Mixed-case in sheet-sections or child object causes havoc2015-03-31T02:17:16ZDave CooperMixed-case in sheet-sections or child object causes havoc*Created by: genworks*
Reported by @reiniervandijk
If child objects (e.g. sheet-section's) have mixed-case in their names, it causes a failure of said sheet-section to update.
This is urgent and needs a test-case put together a...*Created by: genworks*
Reported by @reiniervandijk
If child objects (e.g. sheet-section's) have mixed-case in their names, it causes a failure of said sheet-section to update.
This is urgent and needs a test-case put together and a fix prepared.
**Imported comments:**
*By genworks on 2013-01-14 19:29:10 UTC*
Fix is committed in gdl/gwl/source/answer.lisp. https://gitlab.common-lisp.net/gendl/gendl/-/issues/122sbcl windows: division-by-zero during build2021-07-23T02:47:41ZDave Coopersbcl windows: division-by-zero during build*Created by: avodonosov*
If you check windows versions of SBCL here -
http://common-lisp.net/project/cl-test-grid/library/genworks-gdl -
you may see DIVISION-BY-ZERO errors.
Example log:
http://cl-test-grid.appspot.com/blob?key=104608...*Created by: avodonosov*
If you check windows versions of SBCL here -
http://common-lisp.net/project/cl-test-grid/library/genworks-gdl -
you may see DIVISION-BY-ZERO errors.
Example log:
http://cl-test-grid.appspot.com/blob?key=1046080
Strange that it happens only on SBCL windows, but I reproduced it.
Quicklisp 2012-12-23.
```
(ql:quickload :gdl-tasty).
....
debugger invoked on a DIVISION-BY-ZERO in thread
#<THREAD "main thread" RUNNING {23EFED39}>:
arithmetic error DIVISION-BY-ZERO signalled
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry
compiling #<CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">.
1: [ACCEPT] Continue, treating
compiling #<CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">
as having been successful.
2: [ABORT ] Give up on "gdl-tasty"
3: Exit debugger, returning to top level.
(SB-KERNEL:TWO-ARG-/ -1.0d0 0.0d0)
0] backtrace
0: (SB-KERNEL:TWO-ARG-/ -1.0d0 0.0d0)
1: (ACOS -1.0d0)
2: (ANGLE-BETWEEN-VECTORS
#(0.0d0 1.0d0 0.0d0)
#(0.0d0 -1.0d0 0.0d0)
NIL
:EPSILON
NIL
:-VE
NIL)
3: (ALIGNMENT
:TOP
#(0.0d0 0.0d0 1.0d0)
:LEFT
#(1.0d0 0.0d0 0.0d0)
:REAR
#(0.0d0 1.0d0 0.0d0))
4: (SB-INT:SIMPLE-EVAL-IN-LEXENV
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0))
#<NULL-LEXENV>)
5: (SB-INT:SIMPLE-EVAL-IN-LEXENV
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
#<NULL-LEXENV>)
6: (SB-INT:SIMPLE-EVAL-IN-LEXENV
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION))
#<NULL-LEXENV>)
7: (SB-INT:SIMPLE-EVAL-IN-LEXENV
(PROGN
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
#<NULL-LEXENV>)
8: (SB-EXT:EVAL-TLF
(PROGN
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
1
#<NULL-LEXENV>)
9: (SB-C::EVAL-COMPILE-TOPLEVEL
((SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
(#1=(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
#2=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION))
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) #1#)
(DEFCONSTANT +IDENTITY-LH-MATRIX+ #2#) SB-C::ORIGINAL-SOURCE-START 0 1))
10: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
11: (SB-C::PROCESS-TOPLEVEL-FORM
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION))
((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
#1=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP # :LEFT # :REAR #))
'NIL (SB-C:SOURCE-LOCATION)))
(DEFCONSTANT +IDENTITY-LH-MATRIX+ #1#) SB-C::ORIGINAL-SOURCE-START 0 1)
(:COMPILE-TOPLEVEL))
12: (SB-C::PROCESS-TOPLEVEL-PROGN
((SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
#1=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP # :LEFT # :REAR #))
'NIL (SB-C:SOURCE-LOCATION)))
(DEFCONSTANT +IDENTITY-LH-MATRIX+ #1#) SB-C::ORIGINAL-SOURCE-START 0 1)
(:COMPILE-TOPLEVEL))
13: (SB-C::PROCESS-TOPLEVEL-FORM
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
(MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))
'NIL (SB-C:SOURCE-LOCATION)))
((DEFCONSTANT +IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0))))
SB-C::ORIGINAL-SOURCE-START 0 1)
NIL)
14: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
(DEFCONSTANT +IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0)))))
15: (SB-C::PROCESS-TOPLEVEL-FORM
(DEFCONSTANT +IDENTITY-LH-MATRIX+
(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
(SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
(MAKE-VECTOR 0 1 0))))
(SB-C::ORIGINAL-SOURCE-START 0 1)
NIL)
16: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
(COM.GENWORKS.LISP:DEFINE-CONSTANT +IDENTITY-LH-MATRIX+
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1)
:LEFT (MAKE-VECTOR 1 0 0)
:REAR (MAKE-VECTOR 0 1 0))))
17: (SB-C::PROCESS-TOPLEVEL-FORM
(COM.GENWORKS.LISP:DEFINE-CONSTANT +IDENTITY-LH-MATRIX+
(ALIGNMENT :TOP (MAKE-VECTOR 0 0 1)
:LEFT (MAKE-VECTOR 1 0 0)
:REAR (MAKE-VECTOR 0 1 0)))
(SB-C::ORIGINAL-SOURCE-START 0 1)
NIL)
18: (SB-C::SUB-SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >)
19: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::SUB-COMPILE-FILE))
20: ((FLET #:WITHOUT-INTERRUPTS-BODY-369 :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
21: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
#<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::SUB-COMPILE-FILE)
{28E9D5}>
#<SB-THREAD:MUTEX "World Lock"
owner: #<SB-THREAD:THREAD "main thread" RUNNING {23EFED39}>>
T
NIL)
22: ((LAMBDA () :IN SB-C::SUB-COMPILE-FILE))
23: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
24: (SB-C::SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >)
25: (COMPILE-FILE
#P"C:/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/gdl/geom-base/wire/source/base-object.lisp"
:OUTPUT-FILE
#P"C:/Users/anton/AppData/Local/common-lisp/cache/sbcl-1.1.0.45-win-x86/C/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-201211
25-git/gdl/geom-base/wire/source/ASDF-TMP-base-object.fasl"
:VERBOSE
NIL
:PRINT
NIL
:EXTERNAL-FORMAT
:DEFAULT
:TRACE-FILE
NIL
:BLOCK-COMPILE
NIL
:EMIT-CFASL
NIL)
26: (ASDF:COMPILE-FILE*
#P"C:/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/gdl/geom-base/wire/source/base-object.lisp"
:OUTPUT-FILE
#P"C:/Users/anton/AppData/Local/common-lisp/cache/sbcl-1.1.0.45-win-x86/C/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-201211
25-git/gdl/geom-base/wire/source/base-object.fasl"
:EXTERNAL-FORMAT
:DEFAULT)
27: ((LAMBDA (&REST ASDF::FLAGS) :IN ASDF:PERFORM))
28: ((SB-PCL::FAST-METHOD ASDF::CALL-WITH-AROUND-COMPILE-HOOK
(ASDF:COMPONENT T))
#<unused argument>
#<unused argument>
#<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">
#<CLOSURE (LAMBDA # :IN ASDF:PERFORM) {26C39E1D}>)
29: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
#<unused argument>
#<unused argument>
#<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
#<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
30: ((SB-PCL::EMF ASDF:PERFORM)
#<unused argument>
#<unused argument>
#<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
#<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
31: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS (T T))
#<unused argument>
#<unused argument>
#<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
#<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
32: ((FLET CALL-NEXT-METHOD :IN "C:/Users/anton/quicklisp/asdf.lisp"))
```
**Imported comments:**
*By genworks on 2013-01-13 18:20:40 UTC*
I can replicate
(acos -1)
--> DIVIDE BY ZERO ERROR
on SBCL Windows, but not on any other platform combination of:
Mac: LW, SBCL, CCL
WIndows: ACL, CCL
Linux: ACL, CCL, SBCL
Isn't the acos of -1 correctly supposed to be pi?
Could this be a bug with the acos function on SBCL Windows?
On Sun, Jan 13, 2013 at 1:03 PM, Anton Vodonosov
<notifications@github.com>wrote:
> If you check windows versions of SBCL here -
> http://common-lisp.net/project/cl-test-grid/library/genworks-gdl -
> you may see DIVISION-BY-ZERO errors.
>
> http://cl-test-grid.appspot.com/blob?key=1046080
>
> Strange that it happens only on SBCL windows, but I reproduced it.
> Quicklisp 2012-12-23.
>
> (ql:quickload :gdl-tasty).
>
> ....
> debugger invoked on a DIVISION-BY-ZERO in thread
> #<THREAD "main thread" RUNNING {23EFED39}>:
> arithmetic error DIVISION-BY-ZERO signalled
>
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [RETRY ] Retry
> compiling #<CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">.
> 1: [ACCEPT] Continue, treating
> compiling #<CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">
> as having been successful.
> 2: [ABORT ] Give up on "gdl-tasty"
> 3: Exit debugger, returning to top level.
>
> (SB-KERNEL:TWO-ARG-/ -1.0d0 0.0d0)
>
> 0] backtrace
>
> 0: (SB-KERNEL:TWO-ARG-/ -1.0d0 0.0d0)
> 1: (ACOS -1.0d0)
> 2: (ANGLE-BETWEEN-VECTORS
> #(0.0d0 1.0d0 0.0d0)
> #(0.0d0 -1.0d0 0.0d0)
> NIL
> :EPSILON
> NIL
> :-VE
> NIL)
> 3: (ALIGNMENT
> :TOP
> #(0.0d0 0.0d0 1.0d0)
> :LEFT
> #(1.0d0 0.0d0 0.0d0)
> :REAR
> #(0.0d0 1.0d0 0.0d0))
> 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0))
> #<NULL-LEXENV>)
> 5: (SB-INT:SIMPLE-EVAL-IN-LEXENV
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> #<NULL-LEXENV>)
> 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION))
> #<NULL-LEXENV>)
> 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV
> (PROGN
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> #<NULL-LEXENV>)
> 8: (SB-EXT:EVAL-TLF
> (PROGN
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> 1
> #<NULL-LEXENV>)
> 9: (SB-C::EVAL-COMPILE-TOPLEVEL
> ((SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> (#1=(SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> #2=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION))
> (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) #1#)
> (DEFCONSTANT +IDENTITY-LH-MATRIX+ #2#) SB-C::ORIGINAL-SOURCE-START 0 1))
> 10: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> 11: (SB-C::PROCESS-TOPLEVEL-FORM
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION))
> ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> #1=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP # :LEFT # :REAR #))
> 'NIL (SB-C:SOURCE-LOCATION)))
> (DEFCONSTANT +IDENTITY-LH-MATRIX+ #1#) SB-C::ORIGINAL-SOURCE-START 0 1)
> (:COMPILE-TOPLEVEL))
> 12: (SB-C::PROCESS-TOPLEVEL-PROGN
> ((SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> #1=(IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP # :LEFT # :REAR #))
> 'NIL (SB-C:SOURCE-LOCATION)))
> (DEFCONSTANT +IDENTITY-LH-MATRIX+ #1#) SB-C::ORIGINAL-SOURCE-START 0 1)
> (:COMPILE-TOPLEVEL))
> 13: (SB-C::PROCESS-TOPLEVEL-FORM
> (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
> (SB-C::%DEFCONSTANT '+IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT
> (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))
> 'NIL (SB-C:SOURCE-LOCATION)))
> ((DEFCONSTANT +IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0))))
> SB-C::ORIGINAL-SOURCE-START 0 1)
> NIL)
> 14: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
> (DEFCONSTANT +IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0)))))
> 15: (SB-C::PROCESS-TOPLEVEL-FORM
> (DEFCONSTANT +IDENTITY-LH-MATRIX+
> (IF (BOUNDP '+IDENTITY-LH-MATRIX+)
> (SYMBOL-VALUE '+IDENTITY-LH-MATRIX+)
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1) :LEFT (MAKE-VECTOR 1 0 0) :REAR
> (MAKE-VECTOR 0 1 0))))
> (SB-C::ORIGINAL-SOURCE-START 0 1)
> NIL)
> 16: ((FLET SB-C::DEFAULT-PROCESSOR :IN SB-C::PROCESS-TOPLEVEL-FORM)
> (COM.GENWORKS.LISP:DEFINE-CONSTANT +IDENTITY-LH-MATRIX+
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1)
> :LEFT (MAKE-VECTOR 1 0 0)
> :REAR (MAKE-VECTOR 0 1 0))))
> 17: (SB-C::PROCESS-TOPLEVEL-FORM
> (COM.GENWORKS.LISP:DEFINE-CONSTANT +IDENTITY-LH-MATRIX+
> (ALIGNMENT :TOP (MAKE-VECTOR 0 0 1)
> :LEFT (MAKE-VECTOR 1 0 0)
> :REAR (MAKE-VECTOR 0 1 0)))
> (SB-C::ORIGINAL-SOURCE-START 0 1)
> NIL)
> 18: (SB-C::SUB-SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >)
> 19: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::SUB-COMPILE-FILE))
> 20: ((FLET #:WITHOUT-INTERRUPTS-BODY-369 :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
> 21: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
> #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::SUB-COMPILE-FILE)
> {28E9D5}>
> #<SB-THREAD:MUTEX "World Lock"
> owner: #<SB-THREAD:THREAD "main thread" RUNNING {23EFED39}>>
> T
> NIL)
> 22: ((LAMBDA () :IN SB-C::SUB-COMPILE-FILE))
> 23: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
> 24: (SB-C::SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >)
> 25: (COMPILE-FILE
> #P"C:/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/gdl/geom-base/wire/source/base-object.lisp"
> :OUTPUT-FILE
> #P"C:/Users/anton/AppData/Local/common-lisp/cache/sbcl-1.1.0.45-win-x86/C/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-201211
> 25-git/gdl/geom-base/wire/source/ASDF-TMP-base-object.fasl"
> :VERBOSE
> NIL
> :PRINT
> NIL
> :EXTERNAL-FORMAT
> :DEFAULT
> :TRACE-FILE
> NIL
> :BLOCK-COMPILE
> NIL
> :EMIT-CFASL
> NIL)
> 26: (ASDF:COMPILE-FILE*
> #P"C:/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/gdl/geom-base/wire/source/base-object.lisp"
> :OUTPUT-FILE
> #P"C:/Users/anton/AppData/Local/common-lisp/cache/sbcl-1.1.0.45-win-x86/C/Users/anton/quicklisp/dists/quicklisp/software/genworks-gdl-201211
> 25-git/gdl/geom-base/wire/source/base-object.fasl"
> :EXTERNAL-FORMAT
> :DEFAULT)
> 27: ((LAMBDA (&REST ASDF::FLAGS) :IN ASDF:PERFORM))
> 28: ((SB-PCL::FAST-METHOD ASDF::CALL-WITH-AROUND-COMPILE-HOOK
> (ASDF:COMPONENT T))
> #<unused argument>
> #<unused argument>
> #<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">
> #<CLOSURE (LAMBDA # :IN ASDF:PERFORM) {26C39E1D}>)
> 29: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
> #<unused argument>
> #<unused argument>
> #<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
> #<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
> 30: ((SB-PCL::EMF ASDF:PERFORM)
> #<unused argument>
> #<unused argument>
> #<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
> #<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
> 31: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS (T T))
> #<unused argument>
> #<unused argument>
> #<ASDF:COMPILE-OP (:VERBOSE NIL) {27762A61}>
> #<ASDF:CL-SOURCE-FILE "gdl-geom-base" "wire/source/base-object">)
> 32: ((FLET CALL-NEXT-METHOD :IN "C:/Users/anton/quicklisp/asdf.lisp"))
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/46>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By avodonosov on 2013-01-13 18:34:59 UTC*
Yes, seems to be a bug in sbcl windows.
I've asked in sbcl-devel about it, in this thread (my message probably hasn't yet got into the archive) :
http://sourceforge.net/mailarchive/forum.php?thread_name=CAJ9X%3DkYPRAjOqpKLh64SVz99c-4VqmkCuj0VtvBH19CpA51y3g%40mail.gmail.com&forum_name=sbcl-develhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/119Tasty vector graphics carry unnecessary <script> tag with JS body inside inne...2015-03-31T02:17:15ZDave CooperTasty vector graphics carry unnecessary <script> tag with JS body inside innerHTML*Created by: reiniervandijk*
Gendl server responds with unnecessarily large data on viewport geometry changes while viewing vector graphics. This is due to the fact that JS data is carried both inside the innerHTML part of the response ...*Created by: reiniervandijk*
Gendl server responds with unnecessarily large data on viewport geometry changes while viewing vector graphics. This is due to the fact that JS data is carried both inside the innerHTML part of the response AND in the jsToEval part. The latter is clear, while the former seems unnecessary. Refresh events in the browser will not cast problems.
Solution: in base-ajax-graphics-sheet.lisp, comment out:
```lisp
(define-lens (html-format base-ajax-graphics-sheet)()
:output-functions
(....
(vector-graphics
.....
;;; (let ((raphael-string (the raphael-string)))
;;; (htm ((:script :type "text/javascript")
;;; (str raphael-string))))
...
))
```
**Imported comments:**
*By genworks on 2013-07-09 22:26:05 UTC*
Commenting out the script in the section's innerHTML is not a solution, because the JS still has to be there as part of the normal page (i.e. we still want the JS to get evaluated on a normal browser refresh or similarly if this page is being loaded originally and not through gdlAjax).
The solution in cases like this where there is a redundancy between the js-to-eval and the contents of script tags in the innerhtml is to parse and evaluate the javascript code directly from within the innerHTML as part of the Ajax update function. It looks like this:
```javascript
var codes = elem.getElementsByTagName("script");
for(var i=0;i<codes.length;i++)
{
eval(codes[i].text);
}
```
This also simplifies server-side logic and removes knotty dependency issues.
On the application side, for sheet-sections where the js-to-eval is known to be redundant with what is included in one or more script tags in the inner-html, the protocol will be to specify:
```common-lisp
(js-to-eval :parse)
```
instead of giving actual javascript content. The keyword :parse is recognized and the respond-with-new-html-sections (server-side) and gdlUpdate (client-side) will behave accordingly.
This has been implemented in a local feature branch which will be pushed to master for upcoming release. (all of respond-with-new-html-sections has been cleaned up and rewritten in proper GDL style for better robustness and ease of maintenance).
https://gitlab.common-lisp.net/gendl/gendl/-/issues/118Tasty missing JQuery UI images2016-11-02T23:22:57ZDave CooperTasty missing JQuery UI images*Created by: reiniervandijk*
Most Jquery UI icons/images are not published. This will result in the browser casting errors.
Some of which can be found online, for example:
![Jquery icon](https://github.com/jquery/jquery-ui/blob/mast...*Created by: reiniervandijk*
Most Jquery UI icons/images are not published. This will result in the browser casting errors.
Some of which can be found online, for example:
![Jquery icon](https://github.com/jquery/jquery-ui/blob/master/themes/base/images/ui-icons_222222_256x240.png?raw=true)
The complete list of missing images:
+ Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:9000/static/gwl/style/images/ui-icons_222222_256x240.png
+ Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:9000/static/gwl/style/images/ui-bg_flat_75_f9f9f9_40x100.png
+ Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:9000/static/gwl/style/images/ui-bg_highlight-hard_75_b6b6b6_1x100.png
+ Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:9000/static/gwl/style/images/ui-bg_highlight-hard_65_bed73b_1x100.png
+ Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:9000/static/gwl/style/images/ui-bg_highlight-hard_75_e6e6e6_1x100.pnghttps://gitlab.common-lisp.net/gendl/gendl/-/issues/117volume of box-solid always :unbound2015-03-31T02:17:14ZDave Coopervolume of box-solid always :unbound*Created by: reiniervandijk*
Object surf:box-solid inherits both surf:brep and geom-base:box. Object geom-base:box defines volume as multiplication of width, length, height. Object surf:brep defines it as the result of a geometry kernel...*Created by: reiniervandijk*
Object surf:box-solid inherits both surf:brep and geom-base:box. Object geom-base:box defines volume as multiplication of width, length, height. Object surf:brep defines it as the result of a geometry kernel function call. Unfortunately the slot-status of :volume is now always set to :unbound, no matter if volume was already evaluated or not. This is in absolute contrast to lean computing on the basis of dependency tracking. Suggestion to keep volume message definition according to box and remove brep definition.
```lisp
gdl-user> (make-self 'box-solid :width 2 :length 3 :height 4)
#<box-solid @ #x26ccd92a>
gdl-user> (the (slot-status :volume))
:unbound
gdl-user> (the volume)
24.000000000000007
gdl-user> (the (slot-status :volume))
:unbound
**Imported comments:**
*By genworks on 2013-01-22 19:30:04 UTC*
That is because :volume in the geometry kernel is a function and not a computed-slot per se. That is because it accepts a tolerance argument, and computed-slots cannot accept arguments.
We may want to make this into a cached-function, although we have not much real-world testing experience with cached-functions yet.
Will have to think this one over.
*By reiniervandijk on 2013-01-22 19:35:01 UTC*
Note that I had already explained exactly what the reasons were for this behavior, no need to repeat. Cached-functions may be a nice approach, however, please note that the issue I address here is that:
"it is only reasonable for a user to expect that volume is a computed slot"
however, is contrast, it behaves completely different. This causes massive misuse, hence a serious issue.
*By genworks on 2015-01-30 23:21:10 UTC*
Indeed maybe we can override the volume for this specific brep and just compute it directly as we do for box...
*By genworks on 2015-01-30 23:21:16 UTC*
moving to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/116functions vs computed-slots?2021-07-23T02:53:12ZDave Cooperfunctions vs computed-slots?*Created by: reiniervandijk*
IMPORTANT!!!
In order to make clearer to Gendl users that functions don't behave in a similar way to (computed-) slots, I strongly suggest to make the difference clearer in the code and exploit dependency t...*Created by: reiniervandijk*
IMPORTANT!!!
In order to make clearer to Gendl users that functions don't behave in a similar way to (computed-) slots, I strongly suggest to make the difference clearer in the code and exploit dependency tracking better. The slots below (just a few examples, the list can be almost endless) are the result of a function evaluation, however interpreted and consequently used by the layman user as computed slot with expected associated behavior:
- :total-length on curve
- :volume on brep
- :mass on brep
Instead of causing this confusion, create new functions:
- assess-total-length
- assess-volume
- assess-mass
with their counterparts being computed-slots:
- :total-length message on curve according to
```lisp ((total-length (the assess-total-length)))
- :volume message on breps according to
```lisp ((volume (the assess-volume )))
- :mass message on bresp according to
```lisp ((mass (the assess-mass)))
This will make sure that the user will always refer to slots and consequently, things are not recomputed unnecessarily over and over again if dependencies didn't change. Example below demonstrates that misuse may have huge performance impacts:
```lisp
(in-package :gdl-user)
(define-object test-object (box-solid)
:input-slots
((width 2)
(length 3)
(height 4))
:computed-slots
((volume-computed (the volume))
)
)
gdl-user> (make-self 'test-object)
#<test-object @ #x288afb72>
gdl-user> (time (dotimes (i 10000) (the volume)))
; cpu time (non-gc) 35.615029 sec user, 0.093601 sec system
; cpu time (gc) 0.031200 sec user, 0.000000 sec system
; cpu time (total) 35.646229 sec user, 0.093601 sec system
; real time 107.751000 sec (00:01:47.751000) (33.17%)
; space allocation:
; 721,758 cons cells, 10,461,192 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
gdl-user> (time (dotimes (i 10000) (the volume-computed)))
; cpu time (non-gc) 0.000000 sec user, 0.000000 sec system
; cpu time (gc) 0.000000 sec user, 0.000000 sec system
; cpu time (total) 0.000000 sec user, 0.000000 sec system
; real time 0.005000 sec ( 0.0%)
; space allocation:
; 81 cons cells, 1,024 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
**Imported comments:**
*By genworks on 2013-01-22 19:42:00 UTC*
The reason most things are functions rather than computed-slots is because they can accept arguments, so they can return different return-values if they are called with different values for the arguments. This eliminates the possibility of caching, unless we introduce :cached-functions, which are available already in Gendl, but on an experimental basis (they have not been exercised heavily yet).
In addition to thinking about some kind of naming conventions, I think it would also be helpful to extend Slime's function completion to work with Gendl functions, so it will be obvious when entering a Gendl function that it is indeed a function (and not a simple computed-slot), and what the arguments are. This work was started several years ago before we had really rolled out Slime as a default environment, and it is time now to dust it off and make it very much available as part of the environment!
As you mention, an obvious alternative to cached-functions, where an application wants to call a Gendl function with a particular set of arguments (and arguably simpler/clearer than a cached function) is to establish a new normal (cached) computed-slot to catch (and cache) the return-value of the function call.
*By reiniervandijk on 2013-01-22 19:49:32 UTC*
I think that would be very useful and most sincere to the user, giving him/her exactly what he wants: ultimate speed with the ability to still flexibly call functions with non-default values for the inputs. Note that I assume that the computed-slots here call the associated function with the (as can be reasonably expected) default values for the function inputs.
Ever considered memoize hacks for lisp? I feel it might cause extra delays for rarely used functions, in which cases it may not pay off.
http://www.common-lisp.net/project/araneida/araneida-release/memoization.lisp
*By genworks on 2013-01-22 23:36:38 UTC*
Here's an example of how you make a cached-function (which does memoization) in Gendl (this is experimental and undocumented, but has actually been in there for a long time!):
```lisp
(define-object cached-try ()
:functions ((factorial :cached
(n)
(if (= n 0) 1 (* n (the (factorial (1- n))))))))
```
The alternative I mentioned above is that (as it stands today), the _user_ can go ahead and establish a new computed-slot to cache results when desired, if one does not already exist built-in to the Gendl primitive in question.
No matter how many cached "catcher" slots we add, there will still always be uncached functions in Gendl, and the opportunity for users to call these unknowingly. So the main point is to give the user a clear way of knowing when such a function is being used, so it will not be mistaken for a cached slot. Normally, the uniform syntax is a good thing - during initial development you don't want to have to think too much about such things, or have to use different syntax or some contrived naming convention to distinguish cached slots from functions. But for sure the user needs some easy transparent notification. I think Slime feedback would be one effective way of doing that, at least for the users who choose to use Slime.
Another possibility would be a compiler switch to turn on warnings when Gendl functions are being called with no arguments -- something like "Uncached function called with no arguments -- are you sure you don't want a cached slot to catch that value?" --- and maybe even auto-generate such a slot.
A lot to think about. But first steps will be to make a way to loudly notify the user, before trying too much clever automation which (if not done perfectly) could confuse matters even worse...https://gitlab.common-lisp.net/gendl/gendl/-/issues/115Indentation in Emacs of documentation form2015-03-31T02:17:13ZDave CooperIndentation in Emacs of documentation form*Created by: reiniervandijk*
It is currently a pain to have a :documentation section indented like (Emacs SLIME mode):
```lisp
(define-object MyObject ()
:documentation
(:author "me"
:date "2013-01-30"
:version 1
...*Created by: reiniervandijk*
It is currently a pain to have a :documentation section indented like (Emacs SLIME mode):
```lisp
(define-object MyObject ()
:documentation
(:author "me"
:date "2013-01-30"
:version 1
:description "some description")
)
```
Emacs by default will indent code like:
```lisp
(define-object MyObject ()
:documentation
(:author "me"
:date "2013-01-30"
:version 1
:description "some description")
)
```
**Imported comments:**
*By genworks on 2013-01-30 20:46:00 UTC*
Also (previously from Issue 55 submitted by reiniervandijk) the indentation is broken for :objects which carry documentation.
Consider:
```lisp
(define-object MyObject (base-object)
:objects
((MyChild :type 'MyType
:pass-down (something)) ;; <- Correct
)
)
```
In case one would start adding a documentation string to this child object, the indentation is messed up beyond repair. The :pass-down message argument in this case can not be indented correctly (only with manual whitespaces).
```lisp
(define-object MyObject (base-object)
:objects
(("Mytype. My Description."
MyChild :type 'MyType
:pass-down (something)) ;; <- Error is here
)
)
```
*By genworks on 2013-01-30 20:50:10 UTC*
There are still more questionable indentation rules from the current gdl.el as well, which need to be fixed. They should be listed as comments under this Issue.
*By genworks on 2013-02-01 04:22:47 UTC*
According to emacs gurus, achieving the first indentation automatically would be extremely difficult.
Suggestion to "punt" and simply drop the first item to the next line:
```lisp
(define-object MyObject ()
:documentation
(:author
"me"
:date "2013-01-30"
:version 1
:description "some description")
)
```
Not the best answer I know, and we will leave this issue open for comment.
*By genworks on 2013-02-01 04:25:07 UTC*
I am not able to replicate the problem for child objects with comments. But I have seen that before. I am not quite sure why but in my development environment I see for example:
```common-lisp
(define-object manifold-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(merged :type 'merged-solid :other-brep (the box :face-breps :list-elements))
("merge trial"
merged2 :type 'merged-solid
:other-brep (the box :face-breps :list-elements)
:make-manifold? t)))
```
*By reiniervandijk on 2013-02-01 08:00:41 UTC*
Hard to judge from github indentation what the results are in your development env. Seems that you are exactly replicating it for merged2, but I might be wrong. The documentation section solution I can live with. In fact, that was exactly what I was doing for each key-value pair (so newline on each list entry).https://gitlab.common-lisp.net/gendl/gendl/-/issues/114Default indentation level on new line2015-03-31T02:17:13ZDave CooperDefault indentation level on new line*Created by: reiniervandijk*
It's sort of annoying to type code right now in Emacs (Slime mode). Whenever I move to the next line (pressing ENTER or C+n), the indentation level moves to the left border of the screen. A manual TAB input ...*Created by: reiniervandijk*
It's sort of annoying to type code right now in Emacs (Slime mode). Whenever I move to the next line (pressing ENTER or C+n), the indentation level moves to the left border of the screen. A manual TAB input is then required to indent or a C-M-q on the entire expression when finished. It sort of delays the scripting process. So, to illustrate
```lisp
(defun foo ()
here ...
```
Ideally, it should be:
```lisp
(defun foo ()
here ...
```
**Imported comments:**
*By genworks on 2013-01-30 21:01:45 UTC*
This is mentioned in emacs/gdl.el, with a solution:
;;
;; Use C-j for newline-and-indent. If you really like it, you can bind
;; it to [Enter] by uncommenting the following line (from
;; http://emacswiki.org/emacs/AutoIndentation).
;;
;;(global-set-key (kbd "C-m") 'newline-and-indent)
;;
We will add mention of this to the Manual.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/113Child object documentation messes up indentation2015-03-31T02:17:12ZDave CooperChild object documentation messes up indentation*Created by: reiniervandijk*
Apart from the aforementioned issues on indentation, I've just encountered a more severe issue, that can not be resolved with some extra work (viz. TAB or C-M-q have no effect). Consider:
```lisp
(defi...*Created by: reiniervandijk*
Apart from the aforementioned issues on indentation, I've just encountered a more severe issue, that can not be resolved with some extra work (viz. TAB or C-M-q have no effect). Consider:
```lisp
(define-object MyObject (base-object)
:objects
((MyChild :type 'MyType
:pass-down (something)) ;; <- Correct
)
)
```
In case one would start adding a documentation string to this child object, the indentation is messed up beyond repair. The :pass-down message argument in this case can not be indented correctly (only with manual whitespaces).
```lisp
(define-object MyObject (base-object)
:objects
(("Mytype. My Description."
MyChild :type 'MyType
:pass-down (something)) ;; <- Error is here
)
)
```
**Imported comments:**
*By genworks on 2013-01-30 20:47:14 UTC*
I have merged this in with Issue 53.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/112surf:basic-surface fails on planar topology2015-03-31T02:17:12ZDave Coopersurf:basic-surface fails on planar topology*Created by: reiniervandijk*
Whenever the input curves of surf:basic-surface form a plane, the following error occurs:
_!! This section threw error: #(0.0 0.0 0.0) has Euclidean length zero; cannot unitize. !!_
Please replicate us...*Created by: reiniervandijk*
Whenever the input curves of surf:basic-surface form a plane, the following error occurs:
_!! This section threw error: #(0.0 0.0 0.0) has Euclidean length zero; cannot unitize. !!_
Please replicate using:
```lisp
(define-object basic-surface-test (base-object)
:computed-slots
((display-controls (list :color :orange)))
:objects
((curve-bottom :type 'linear-curve :start #(0.0 0.0 0.0) :end (translate (the-child :start) :right 3))
(curve-right :type 'linear-curve :start (the curve-bottom :end) :end (translate (the-child :start) :front 2))
(curve-top :type 'linear-curve :start (the curve-right :end) :end (translate (the-child :start) :left 2))
(curve-left :type 'linear-curve :start (the curve-top :end) :end (the curve-bottom :start))
(3d-curve :type 'fitted-curve :points (list (the curve-top :end) (translate (the curve-top :end) :up 1) (the curve-bottom :start)))
(issue :type 'basic-surface
:pass-down (curve-bottom curve-right curve-top curve-left))
(works :type 'basic-surface
:pass-down (curve-bottom curve-right curve-top)
:curve-left (the 3d-curve :reverse)) ;; <-- see next issue
)
)
```
**Imported comments:**
*By genworks on 2015-01-30 23:19:27 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/111surf:basic-surface can only handle ideally oriented curves2015-03-31T02:17:11ZDave Coopersurf:basic-surface can only handle ideally oriented curves*Created by: reiniervandijk*
The surf:basic-surface object produces weird results when curves are not oriented (from start to end) as expected. However, nowhere does the documentation mention constraints on orientations of curves... Rep...*Created by: reiniervandijk*
The surf:basic-surface object produces weird results when curves are not oriented (from start to end) as expected. However, nowhere does the documentation mention constraints on orientations of curves... Reproduce with:
```lisp
(define-object basic-surface-test2 (base-object)
:computed-slots
((display-controls (list :color :orange)))
:objects
((curve-bottom :type 'linear-curve :start #(0.0 0.0 0.0) :end (translate (the-child :start) :right 3))
(curve-right :type 'linear-curve :start (the curve-bottom :end) :end (translate (the-child :start) :front 2))
(curve-top :type 'linear-curve :start (the curve-right :end) :end (translate (the-child :start) :left 2))
;; (curve-left :type 'linear-curve :start (the curve-top :end) :end (the curve-bottom :start))
(3d-curve :type 'fitted-curve :points (list (the curve-top :end) (translate (the curve-top :end) :up 1) (the curve-bottom :start)))
(issue :type 'basic-surface
:pass-down (curve-bottom curve-right curve-top)
:curve-left (the 3d-curve))
(works :type 'basic-surface
:pass-down (curve-bottom curve-right curve-top)
:curve-left (the 3d-curve :reverse))
)
)
```
**Imported comments:**
*By genworks on 2013-01-30 20:57:45 UTC*
Would it be reasonable for the object to reverse curves automatically to achieve reasonable results, or should the documentation simply mention that curves should be in a consistent direction in order to achieve desired results?
*By reiniervandijk on 2013-01-30 21:15:06 UTC*
If you know the rules of how to orient curves in a way that the geometry kernel expects, I would be in favor of the object doing it automatically on behalf of user. As long as you did not implement it yet, consider adding this to documentation and provide intuitive error messages on failure.
*By genworks on 2015-01-30 23:17:51 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/109PNG output currently broken2015-03-31T02:17:10ZDave CooperPNG output currently broken*Created by: genworks*
PNG output in tasty currently appears broken with error
"Undefined variable pdf::*root-page*"
*Created by: genworks*
PNG output in tasty currently appears broken with error
"Undefined variable pdf::*root-page*"
https://gitlab.common-lisp.net/gendl/gendl/-/issues/107bug in brep :properties function2015-03-31T02:17:10ZDave Cooperbug in brep :properties function*Created by: reiniervandijk*
Typo in properties function, :edge-tess-toleance should be :edge-tess-tolerance.
```lisp
(define-object brep (geometry-kernel-object-mixin base-object)
;;; more stuff
("Plist with keys: :area, :vo...*Created by: reiniervandijk*
Typo in properties function, :edge-tess-toleance should be :edge-tess-tolerance.
```lisp
(define-object brep (geometry-kernel-object-mixin base-object)
;;; more stuff
("Plist with keys: :area, :volume, :barycenter. Returns the approximate area, volume,
and barycenter (center of mass) for the brep. These are computed with tessellation techniques,
which may be less precise than the analytic techniques used in precise-properties, but should
be faster to compute and exhibit more stability.
:&key ((tolerance (the adaptive-tolerance)) \"Controls how precisely the properties are computed\")"
properties
(&key (edge-tess-tolerance (the adaptive-tolerance))
(face-tess-tolerance (the adaptive-tolerance)))
(brep-compute-properties *geometry-kernel* self :edge-tess-toleance edge-tess-tolerance
:face-tess-tolerance face-tess-tolerance))
;;; more stuff
)
```
**Imported comments:**
*By genworks on 2013-02-01 04:15:44 UTC*
Fixed in github, fix will be in next release. https://gitlab.common-lisp.net/gendl/gendl/-/issues/106negative volume for breps2015-03-31T02:17:10ZDave Coopernegative volume for breps*Created by: reiniervandijk*
All breps have negative volumes when computed with properties funtions. Replicate:
```lisp
> (make-self 'surf:box-solid :width 1 :length 2 :height 3)
#<box-solid @ #x28c4c3a2>
> (the properties)
(:are...*Created by: reiniervandijk*
All breps have negative volumes when computed with properties funtions. Replicate:
```lisp
> (make-self 'surf:box-solid :width 1 :length 2 :height 3)
#<box-solid @ #x28c4c3a2>
> (the properties)
(:area 22.0 :volume -6.0 :barycenter #(0.0 0.0 0.0))
```
**Imported comments:**
*By genworks on 2015-01-30 23:13:41 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/105precise-properties on brep should return plist2015-03-31T02:17:09ZDave Cooperprecise-properties on brep should return plist*Created by: reiniervandijk*
It seems counter-intuitive that the precise-properties function on a brep object returns multiple values, of which the primary return value is a single number. It would be better to return a plist (as primar...*Created by: reiniervandijk*
It seems counter-intuitive that the precise-properties function on a brep object returns multiple values, of which the primary return value is a single number. It would be better to return a plist (as primary return value), to enable the capture of all relevant properties at once, just like the properties function returns a plist. Now, a user (interested in multiple properties at the same time) would have to write multiple-value-bind or multiple-value-list statements to cache all properties for further reference. This would result in more boilerplate code and it would therefore be easier to skip this step at all. Moreover, what's in a name .... (that is, "properties").
**Imported comments:**
*By genworks on 2013-02-01 04:14:14 UTC*
To maintain backward compatibility, added a new slot `precise-properties-plist` which returns a plist. https://gitlab.common-lisp.net/gendl/gendl/-/issues/104precise-properties function way faster than properties function2015-03-31T02:17:09ZDave Cooperprecise-properties function way faster than properties function*Created by: reiniervandijk*
Quoting YADD for brep object:
"properties .... Returns the approximate area, volume, and barycenter (center of mass) for the brep. These are computed with tessellation techniques, which may be less precis...*Created by: reiniervandijk*
Quoting YADD for brep object:
"properties .... Returns the approximate area, volume, and barycenter (center of mass) for the brep. These are computed with tessellation techniques, which may be less precise than the analytic techniques used in precise-properties, but **should be faster to compute and exhibit more stability**."
However, my experience tells that this is absolute not true for most breps (except perhaps a box-solid). Consider:
```lisp
(define-object blend-sample (base-object)
:objects
((box :type 'box-solid
:length 10 :width 20 :height 15)
(blend :type 'blended-solid
:display-controls (list :color :blue)
:default-radius 3
:brep (the box))))
```
Then try:
```lisp
> (make-self 'gdl-user::blend-sample)
#<gdl-user::blend-sample @ #x27b0741a>
> (time (the blend properties))
; While compiling #'(:internal (:anonymous-lambda 184) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 6.396041 sec user, 0.000000 sec system
; cpu time (gc) 0.000000 sec user, 0.000000 sec system
; cpu time (total) 6.396041 sec user, 0.000000 sec system
; real time 6.391000 sec (100.1%)
; space allocation:
; 1,317 cons cells, 15,576 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
(:area 1058.0302322356551 :volume -2688.485700513146 :barycenter #(4.624379521278622e-8 -1.7689643795993214e-8 4.7812516743011945e-8))
> (time (the blend precise-properties))
; While compiling #'(:internal (:anonymous-lambda 185) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 0.280801 sec user, 0.000000 sec system
; cpu time (gc) 0.000000 sec user, 0.000000 sec system
; cpu time (total) 0.280801 sec user, 0.000000 sec system
; real time 0.273000 sec (102.9%)
; space allocation:
; 70 cons cells, 1,184 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
1058.0352607385712
2688.5042009812973
2688.5042009812973
(:area-static-moments #(-4.8989093613727164e-5 2.1550662467006987e-5 -3.6839482398947886e-5) :area-moments-of-inertia
#(45373.564825689886 15113.217009644091 28017.912378078006) :area-products-of-inertia
#(-5.661023038829527e-4 -1.8689825015688562e-4 3.1346315859082097e-4) :area-second-moment-about-coordinate-axii
#(43131.129387722096 73391.47720376788 60486.781835333975) :volume-static-moments #(-3.238828467146959e-4 -1.1071887268114139e-4 4.421746052652778e-5)
:volume-moments-of-inertia #(81217.79700024093 19928.14881472922 44950.66790316432) :volume-products-of-inertia
#(-0.002875729270495866 0.004025920538448073 0.0015461265159991131) :volume-second-moment-about-coordinate-axii
#(64878.81671789356 126168.46490340521 101145.94581497014))
```
Observe that precise-properties is around 25 times faster here than the properties function. The ratio might be even worse for other breps (but I hope this single example makes the point clear). There are occasions in which the ratio might be in the order of precise-properties being 1000's of times faster (returns almost instantaneous).
As the documentation is misleading and the behavior is really not as expected, I consider this a serious issue. Further investigation into why the kernel (or the interaction with it) results in such behavior, is desired. Moreover, from a performance standpoint 6.4s for such a straight-forward brep is quite worrying.
**Imported comments:**
*By genworks on 2015-01-30 23:10:03 UTC*
moving to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/103make-manifold? operation only on final boolean-merge please.2015-03-31T02:17:08ZDave Coopermake-manifold? operation only on final boolean-merge please.*Created by: reiniervandijk*
Consider a user creating a merged-solid from multiple breps (more than 2) and set:make-manifold? t. While doing so, he will get bummer! warnings about the make-manifold operation failing on all but the last ...*Created by: reiniervandijk*
Consider a user creating a merged-solid from multiple breps (more than 2) and set:make-manifold? t. While doing so, he will get bummer! warnings about the make-manifold operation failing on all but the last boolean merge (assuming the input breps proper of course). Logically, trying manifold operations on intermediate results makes little sense, since they will most likely have a non-manifold topology.
Two things:
1. Only perform make-manifold operation on last boolean merge
2. Consider the performance impact. Might you not slow down the whole process by asking the kernel to try this (unnecessary) operation every time?
Replicate:
```lisp
(define-object manifold-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(merged :type 'merged-solid :other-brep (the box :face-breps :list-elements))
(merged2 :type 'merged-solid :other-brep (the box :face-breps :list-elements) :make-manifold? t)))
````
And then:
```lisp
> (make-self 'manifold-sample)
#<manifold-sample @ #x281d9fb2>
> (the merged :bounding-box)
Merging ((:face-breps 1) :box) into merge object
Merging ((:face-breps 2) :box) into merge object
Merging ((:face-breps 3) :box) into merge object
Merging ((:face-breps 4) :box) into merge object
Merging ((:face-breps 5) :box) into merge object
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
> (the merged2 :bounding-box)
Merging ((:face-breps 1) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 2) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 3) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 4) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 5) :box) into merge object
Manifold Success!
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
```
**Imported comments:**
*By genworks on 2013-02-01 04:10:02 UTC*
This is fixed in current github in surf/source/boolean.lisp. (By the way, yes we will be adding an (update-gdl) option to pull from github, but for now you have to manually pull and load from github if you want early previews).
```common-lisp
gdl-user> (make-self 'manifold-sample)
#<manifold-sample @ #x368853d2>
gdl-user> (the merged2 bounding-box)
Merging ((:face-breps 1) :box) into merge object
Merging ((:face-breps 2) :box) into merge object
Merging ((:face-breps 3) :box) into merge object
Merging ((:face-breps 4) :box) into merge object
Merging ((:face-breps 5)
:box) into merge object, trying to make manifold...
Manifold Success!
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
gdl-user>
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/102Why does my solid have 0.0 volume?2015-03-31T02:17:08ZDave CooperWhy does my solid have 0.0 volume?*Created by: reiniervandijk*
Okay, finally got my head around this after experiencing this problem multiple times. For a lot of boolean-operations (merging, uniting, etc.) where open faces are the input, the resulting brep will not be a...*Created by: reiniervandijk*
Okay, finally got my head around this after experiencing this problem multiple times. For a lot of boolean-operations (merging, uniting, etc.) where open faces are the input, the resulting brep will not be a true solid and have a volume of 0.0. The only way to get around this is to make another explicit 'manifold-solid with that former brep as input, since there are no :make-manifold? messages to set (with the exception of merged-solid). Only then will the new brep be a true solid (with 2 regions) with a real volume. I don't think the whole manifold story is well explained in the documentation, actually not at all. This is a serious issue right now.
Replicate:
```lisp
(define-object volume-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(merged :type 'merged-solid :other-brep (the box :face-breps :list-elements))
(united :type 'united-solid :other-brep (the box :face-breps :list-elements))
(merged-manifold :type 'manifold-solid :brep (the merged))
(united-manifold :type 'manifold-solid :brep (the united))
)
)
```
Then try:
```lisp
> (make-self 'volume-sample)
#<volume-sample @ #x27e80aea>
> (the merged :volume)
0.0
> (the united :volume)
warn? = t ;; <-- for what?
0.0
> (the merged-manifold :volume)
Manifold Success!
8.0
> (the united-manifold :volume)
Manifold Success!
8.0
```
I guess you see the pattern. This should definitely become clearer from documentation or warnings, because now user is just disappointed. Strange enough, the properties function does return values:
```lisp
> (the merged :properties)
(:area 24.0 :volume -7.999999999999999 :barycenter #(0.0 0.0 0.0))
> (the united :properties)
(:area 24.0 :volume -7.999999999999999 :barycenter #(0.0 0.0 0.0))
```
**Imported comments:**
*By genworks on 2015-01-30 23:08:06 UTC*
moving to internal tracking list.