Lisp HUG Maillist Archive

Odd graph layout with pinboard objects of different height

Hello lispworkers,

Please estimate the following graph:

(defun node-children (node)
  (when (< node 16)
    (list (* node 2) (1+ (* node 2)))))

(defun node-pane (graph node)
  (if (< node 16)
      (make-instance 'capi:expandable-item-pinboard-object
        :data node  :visible-min-height 32
         :graphics-args (list :font (gp:find-best-font graph
              (gp:make-font-description :size 16))))
      (make-instance 'capi:item-pinboard-object :data node)))

(capi:contain
  (make-instance 'capi:graph-pane
    :roots '(1)
    :children-function 'node-children
    :node-pane-function 'node-pane
    :edge-pinboard-class 'capi:right-angle-line-pinboard-object
    :layout-function :right-left))

In my view, the leaves look displaced vertically relative to their parents.

The :edge-pinboard-class and :layout-function initargs are given for
emphasizing the effect - the graph looks odd even with default values.

Is this by design?
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru


Optimization needed for Zach beane's zlib implementation now used in cl-pdf

I've added Zach Beane's zlib implementation in Lisp (salza) to cl-pdf
It works only in LW (and maybe ACL) for now.
You now have to choose the zlib compression used in cl-pdf.asd

The code is here:

http://www.fractalconcept.com:8000/public/open-source/cl-pdf/
http://www.fractalconcept.com/download/cl-pdf-current.tgz

The compression is not optimized yet for LW and is 5.4 times slower than the
C one for now.

So as I know that some of us here are #'disassemble fans ;-) I'm making a
call for optimazation so that the LW version can be as fast as the C one or
at least as fast as in SBCL/ACL etc...

Here is some bench:

(setf test-str (format nil "~s" (apropos-list "clos")))

(time (dotimes (i 100) (salza::compress-string test-str) nil))

Timing the evaluation of (dotimes (i 100) (salza:compress-string test-str)
nil)

user time    =      2.693
system time  =      0.000
Elapsed time =   0:00:03
Allocation   = 54366696 bytes standard / 3318073 bytes conses

Looks like there are some fixnum optimizations to add !

Marc



Updated at: 2020-12-10 08:53 UTC