##Gendl®
The Gendl public repository has moved to the gitlab instance running at common-lisp.net!
Please update your links to here:
Archive of old version, visit gendl.org for current version --- #gendl on libera.chat
Home Page: http://www.gendl.org
License: GNU Affero General Public License v3.0
##Gendl®
The Gendl public repository has moved to the gitlab instance running at common-lisp.net!
Please update your links to here:
slime/glime mode from dist/emacs/gdl.el does not fully colorize Gendl-specific operators, such as "the," "the-object," "the-child."
color-theme implementation needs to be customized to highlight these operators.
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:
The complete list of missing images:
The camera (e.g. for input to a base-view) currently consists of a single :projection-vector, which is not enough fully to specify a camera. It needs to be oriented like a box or any other base-object, so you can twist the view around and make e.g. the 3D :rear direction point to the top of the 2D sheet containing the viewport.
Color changes or line-thickness changes do not have an effect anymore in the viewport. At least for gdl1582-windows-2012113000 it hasn't. Note that the tree node does behave appropriately.
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").
Leader-line is not displayed in SVG/VML format. This object is not exported as a VRML object.
!!! The .png and .jpg format is Ok.!!!
As reported by Reinier van Dijk --- these should be separate conditionals, with separate conditional replacement code in the gdl-ajax.js javascript.
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:
(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:
> (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.
Safari tends to redirect toplevel GWL URLs to the previous session ID, which can be timed out or will be non-existent if the Gendl session has been restarted. The make-gwl-object needs to handle this in a reasonable way.
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:
(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
)
)
It is currently a pain to have a :documentation section indented like (Emacs SLIME mode):
(define-object MyObject ()
:documentation
(:author "me"
:date "2013-01-30"
:version 1
:description "some description")
)
Emacs by default will indent code like:
(define-object MyObject ()
:documentation
(:author "me"
:date "2013-01-30"
:version 1
:description "some description")
)
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"))
Specifically cone, spherical-cap, and global-polygon-projection need to be addressed. Suggest implementing with simple triangular tessellation, rather than trying to use any built-in VRML or X3D shape primitives.
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:
(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).
(define-object MyObject (base-object)
:objects
(("Mytype. My Description."
MyChild :type 'MyType
:pass-down (something)) ;; <- Error is here
)
)
If a GDL is running with GWL webserver on e.g. port 9000 already, then a new one will crash when it tries to call gwl:start-gwl. This should detect the running server and roll to the next port (e.g. 9001).
All breps have negative volumes when computed with properties funtions. Replicate:
> (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))
One window resize event results in 2 identical gdlAjax requests being sent to the server. Resulting in twice the data traffic. This is unnecessary and should be corrected inside the initlayout JS code.
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.
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.
A fix for this has been provided by Reinier van Dijk, as well as suggestion to upgrade to JQuery latest (1.6.2, I believe). The fix is in Genworks Support email and needs to be integrated to our tasty/menu code and jquery snapshot here.
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:
Instead of causing this confusion, create new functions:
with their counterparts being computed-slots:
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:
(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)
PDF stream is opened in wrong mode (e.g. ascii vs binary) for png and jpeg output-formats.
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:
(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))
)
)
None of the systems build any more, as there's a reference to QL:FOO in the sources. Quicklisp isn't available as a dependency for libraries to use, sorry.
The vrml export of a geom-base cone object is inconsistent:
see the Genworks-GDL / documentation / unified-doc / examples / shock-absorber-v0.3
Recent versions of ASDF do not export DIRECTORY-PATHNAME-P or any utilities anymore.
This breaks Genworks-GDL.
The fix is to either
1- use ASDF-UTILS that exports all these utilities, or
2- use internal symbols like ASDF::DIRECTORY-PATHNAME-P if you really can't or won't depend on ASDF-UTILS.
Please test with a new ASDF (such as 2.25), without loading any system-provided ASDF via require.
My apologies for the breakage.
As gdlAjax works currently, the form-controls have to be local to the sheet (or sheet-section) where they are laid out. It should be possible to use form-controls which are in child objects or other objects (e.g. passed in as inputs) and laid out in the current sheet. It should also be possible to construct HTML strings using form-controls from current sheet, and pass those HTML strings into other objects to be laid out (or as inner-html input).
This will require change to form-control-processor, and should be backward compatible since it is an extension of the way things work currently.
After recent commits, VRML is now broken in tasty (but works in ta2).
Allegro console shows the following output:
4-aserve-worker: 05/14/12 - 08:10:59 - while processing command "GET /sessions/103d35b74b3/viewport/model.wrl HTTP/1.1"
got error symbol-value got 2 args, wanted 1 arg.
I believe everything was still working fine on Friday (05/11).
In GWL base-ajax-sheet, a dynamic sequence of sheet-section elements may cause problems. In case sheet-sections are dynamically removed, the html-sections list does not update. Sheet-sections can be added dynamically, because the recursive register! strategy will work. However, when removing sections, there is not unregister! strategy in place. It may be argued that this is a limitation of GWL as it stands today, however since this is never documented anywhere, the user can not assume differently than this being a bug (one is allowed to assume that dependency tracking will be properly set-up). A working example will be provided.
(ql:quickload :genworks-gdl) fails in quicklisp 2012-11-25 on lisps, which were working in the previous quicklisp, e.g. SBCL.
new log:
http://cl-test-grid.appspot.com/blob?key=801816
previous log:
http://cl-test-grid.appspot.com/blob?key=550328
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
(defun foo ()
here ...
Ideally, it should be:
(defun foo ()
here ...
Typo in properties function, :edge-tess-toleance should be :edge-tess-tolerance.
(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
)
Currently crashes when trying to start AllegroServe on port 9000 when one is already running.
Website application requires product configurator, download wizard, and customer license file manager.
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.
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
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.
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
and drawing a robot will consume a large amount of heap, simply reloading this page several times will exhaust the SBCL heap. On Allegro CL it is using just a fraction of the memory and garbage collection always seems to bring the used oldspace back to baseline.
So there is some kind of memory leak going on with the SBCL platform. I need to develop a more standardized way of testing for this but in the meantime if anyone has any clues, I will be very interested!
Note that you can clear all web sessions with
(gwl:clear-all-instances)
So, in theory you should be able to make unlimited web pages and clear them with (gwl:clear-all-instances), and garbage collection should bring things back to baseline.
EDIT: A programmatic way to replicate this is:
(in-package :gdl-user)
(dotimes (n 1000) (net.aserve.client:do-http-request "http://localhost:9000/newsite") (gwl:clear-all-instances))
You will exhaust your heap for sure. If you want to stop before exhausting the heap just do it 50 or 100 instead of 1000 times. Then perhaps it will be possible to examine the heap and see what is taking up all the space.
It appears that cl-lite generates bogus .asd files when called on a relative pathname with :create-asd-file? t.
I have called it on surf/ directory with full pathname, so the .asd file there is now correct.
But, the cl-lite itself needs to be fixed to generate proper .asd files when called with relative pathnames.
Here are some example failure logs:
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-all_gdl-all.txt
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-surf_gdl-surf.txt
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-build_gdl-build.txt
There are others, if it helps.
Code colors in GDL 1581 is not the same as in 1580 for example previously the :sequence (:size ... it was pink, now is yellow. In principle the pink is absent ":input-slots, :functions, :computed-slots, :hidden-objects, :objects, :type etc."
Just like the title says, and this is very much affected by the display-tolerance parameter.
We have example code which throws the error (in Genworks Support email).
Note that the code for the smlib interface module is not part of this git repo - issues relating to this module might be moved to a different Issues list.
The zoom-in and zoom-out image are reversed :
image viewmag- is zoom-in and
image viewmag+ is zoom-out.
Here are some failures I've gotten recently for a few GDL systems:
::: genworks-gdl from git://github.com/genworks/Genworks-GDL.git
=================================
FAIL: "fail_genworks-gdl_gdl-aero-demo-1_gdl-aero-demo-1.txt"
=================================
unhandled LOAD-SYSTEM-DEFINITION-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C13C3}>: Error while trying to load definition for system gdl-surf from pathname /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/surf/gdl-surf.asd: don't recognize component type LISP
=================================
FAIL: "fail_genworks-gdl_gdl-build_gdl-build.txt"
=================================
unhandled SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C1363}>: The name "GDL-USER" does not designate any package.
=================================
FAIL: "fail_genworks-gdl_gdl-translators_gdl-translators.txt"
=================================
;
; caught ERROR:
; READ error during COMPILE-FILE: Package GWL does not exist.Line: 23, Column: 19, File-Position: 877Stream: #<SB-SYS:FD-STREAM for "file /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/gdl/apps/translators/xml/source/package.lisp" {1004A47B13}>
=================================
FAIL: "fail_genworks-gdl_gdl-wind-demo-1_gdl-wind-demo-1.txt"
=================================
unhandled SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C13C3}>: The name "GDL-USER" does not designate any package.
=================================
FAIL: "fail_genworks-gdl_gdl-xml_gdl-xml.txt"
=================================
;
; caught ERROR:
; READ error during COMPILE-FILE: Package GWL does not exist.Line: 23, Column: 19, File-Position: 877Stream: #<SB-SYS:FD-STREAM for "file /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/gdl/apps/translators/xml/source/package.lisp" {1004A3DBD3}>
I'm using a recent SBCL on AMD64.
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:
(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))))
...
))
I get "The name "SURF" does not designate any package" when trying to build today.
PNG output in tasty currently appears broken with error
"Undefined variable pdf::root-page"
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
and drawing a robot will consume a large amount of heap, simply reloading this page several times will exhaust the SBCL heap. On Allegro CL it is using just a fraction of the memory and garbage collection always seems to bring the used oldspace back to baseline.
So there is some kind of memory leak going on with the SBCL platform. I need to develop a more standardized way of testing for this but in the meantime if anyone has any clues, I will be very interested!
Note that you can clear all web sessions with
(gwl:clear-all-instances)
So, in theory you should be able to make unlimited web pages and clear them with (gwl:clear-all-instances), and garbage collection should bring things back to baseline.
EDIT: A programmatic way to replicate this is:
(in-package :gdl-user)
(dotimes (n 1000) (net.aserve.client:do-http-request "http://localhost:9000/newsite") (gwl:clear-all-instances))
You will exhaust your heap for sure. If you want to stop before exhausting the heap just do it 50 or 100 instead of 1000 times. Then perhaps it will be possible to examine the heap and see what is taking up all the space.
The encoding used by lisp implementation to read source files is often depends on environment.
Example, when GDL doesn't build because the default encoding used by lisp implementation is not UTF-8:
http://cl-test-grid.appspot.com/blob?key=792731
If you want the sources to be more reliably build on systems were UTF8 is not default encoding, you may specify the encoding in your .asdf files:
#+asdf-unicode :encoding #+asdf-unicode :utf-8
The chapter about source file encoding in ASDF manual:
http://common-lisp.net/project/asdf/asdf/Miscellaneous-additional-functionality.html#Miscellaneous-additional-functionality
P.S. you may find build status of genworks-gdl and other libraries on different lisps here:
http://common-lisp.net/project/cl-test-grid/library/
Enhance the :gdl-build package to support a compatible make-gdl-app function as compatible as possible to the 1580 make-gdl-app. Also used for internal builds. Also automate the generating of customer license files for proprietary customers.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.