Giter Club home page Giter Club logo

gendl's People

Contributors

genworks avatar teodor-gelu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gendl's Issues

Default indentation level on new line

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 ...

volume of box-solid always :unbound

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

Apparent memory leak on SBCL

This is possibly related to portable allegroserve.

Bringing up a standard Gendl web page such as

http://localhost:9000/tasty

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.

html-sections are not unregistered

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.

VRML cone

The vrml export of a geom-base cone object is inconsistent:

see the Genworks-GDL / documentation / unified-doc / examples / shock-absorber-v0.3

menu-form-control does not clear entries with :ajax-submit-on-change?

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.

Apparent memory leak on SBCL

This is possibly related to portable allegroserve.

Bringing up a standard Gendl web page such as

http://localhost:9000/tasty

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.

:ajax-submit-on-change? for form-controls always results in innerHTML refresh -- is it needed?

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.

sbcl windows: division-by-zero during build

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"))

Gendl-specific colorizing needed in glime mode

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.

Allow layout of form-controls from other objects in tree

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.

cl-lite fails on :create-asd-file? with relative pathname

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.

Child object documentation messes up indentation

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
   )
  )

camera limited to single projection-vector, needs to respect a full orientation

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.

negative volume for breps

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))

Syntax Coloring Problem

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."

precise-properties function way faster than properties function

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.

Breakage due to ASDF package changes

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.

nurbs-to-beziers sometimes unstable for rational NURBS curves

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.

VRML broken in tasty

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).

precise-properties on brep should return plist

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").

tasty viewport insensible to color changes

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.

make-gdl-app updated for this release

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.

Tasty missing JQuery UI images

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

The complete list of missing images:

source files encodings

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/

Tasty zoom-in and zoom-out

The zoom-in and zoom-out image are reversed :
image viewmag- is zoom-in and
image viewmag+ is zoom-out.

bug in brep :properties function

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
)

Indentation in Emacs of documentation form

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")

  )

Various package-related build failures recently

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.

functions vs computed-slots?

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
  • :volume message on breps according to
  • :mass message on bresp according to

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)

Safari redirects to non-existent session

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.

surf:basic-surface fails on planar topology

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
   )
  )

Tasty vector graphics carry unnecessary <script> tag with JS body inside innerHTML

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))))
 ...
))

surf:basic-surface can only handle ideally oriented curves

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)) 
   )
  )

pulldown menus disappear in tasty

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.