search

Ferada / cl-cffi-gtk

#cl-cffi-gtk on Freenode. A Lisp binding to GTK+3. SBCL/CCL/ABCL (ECL/CLISP unstable)
http://www.crategus.com/books/cl-cffi-gtk
41 stars 8 forks source link

Cache parsed types. #32

Open Ferada opened 5 years ago

Ferada commented 5 years ago

Instead of recreating them all the time. Might be addressing some of the issues reported in https://github.com/crategus/cl-cffi-gtk/issues/69. In the long run might be worth more addressing this in CFFI directly.

stacksmith commented 5 years ago

Every little bit helps, as far as I am concerned. I get flak when I complain about hundreds of kilobytes wasted - it's not 1990, I know... But all this stuff piles up causing problems at some point. It's like letting your garden get overgrown to the point you have no idea what's behind the thorns. I'll tell you what's there - rats, ticks and occasionally a crazy guy living in a tent who may burn down your house. Speaking of CFFI, I spent a few hours tracking down the long path from defcfun to something that actually calls a foreign function (in SBCL). I am sad to say I never got to a conclusive end, after disassembling, decompiling and just trying to follow the sources. I know that between cl-cffi-gtk and CFFI there are four (I think) places where objects get cached for various reasons, and I found a few other places that create new objects for no explainable reason. For instance, deep below CFFI,

(SB-ALIEN:EXTERN-ALIEN "gtk_text_buffer_set_text"
(FUNCTION SB-ALIEN:VOID SB-SYS:SYSTEM-AREA-POINTER
        SB-SYS:SYSTEM-AREA-POINTER SB-ALIEN:INT))
#<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X5020B060 :TYPE (FUNCTION (VALUES)
    SB-SYS:SYSTEM-AREA-POINTER  SB-SYS:SYSTEM-AREA-POINTER  (SB-ALIEN:SIGNED 32) &REST)>

This one is interesting: if you call it a few times you will see that it returns the same SAP, but with a different alien object. There are many places that have so-called type parses hiding deep inside. i've been working on a cleaner interface to GTK objects, using several layers that are clearly defined, and it seems to be helpful. I had to completely rewrite gtk buffer, iter, mark bindings to work with untyped pointers at the low level, and get lispier and safer with higher levels.
For objects like gtk-text-buffer, which are pretty much static, it makes sense to just get the raw pointer and use it in all the bindings. It does not change, and it needs no translation. I blabbed about iters enough, but it is so lightweight to use them the way God had intended. I also wrote a ffdb library that is basically a database for a group of related bindings. I have one for buffer, one for iter, etc. It is a repository of all binding information and may be used to instantly generate a set of bindings at any layer - which is great for experimenting, say to make all gtk-text-iters structure pointers etc. I am also very excited about a layer of bindings that can use a lexical environment. So you can bind a buffer pointer and every binding inside the environment can use it instead of the usual parameter passing. In fact I have a stream-like object binding a buffer, 3 iters and a mark. All the bindings in that environment can use them as parameters, and you have to provide just the missing ones...