freenode/#clim - IRC Chatlog
Search
8:28:06
beach
jackdaniel: I have a theory why #sicl is more popular than #ecl. I think it's that you don't utter things nearly as often as I do. :)
10:05:08
jackdaniel
beach: it might be, but on the other hand sicl is a shiny new thing, so by definition it is sexy, while ecl is an old niche implementation ;)
10:37:55
edgar-rft
I think there are just simply very few lisp programmer who work at the direct border between Lisp and C, they usually tend to use either/or, while ECL is best for using *both* together. This effect somewhat limits the number of ECL users, but it's not because ECL were a bad Lisp implementation.
10:39:41
jackdaniel
it is certainly slow without proper declarations and/or with plenty of generic functions
10:40:29
jackdaniel
n.b when you provide correct type declarations (or when the type inference is implemented), number crunching on ecl beats i.e sbcl (thanks to c compiler magic)
10:43:06
edgar-rft
...and I also wouldn't dare to talk bad about ECL in the presence of jackdaniel :-)
10:45:46
edgar-rft
No, the real reason why I'm not using ECL more often is that I'm trying to *avoid* C, even if I'm aware that this is not possible on existing operating systems in 2020 (with very rare exceptions).
10:45:48
jackdaniel
most projects I work on are brilliant in places and brilliantly flawed in other places ;-)
10:47:05
jackdaniel
unless you say, that you avoid c, but you don't avoid machine code, because i.e ccl compiles directly to a machine code ;)
10:48:02
jackdaniel
if I had all the time in a world, I'd implement a proper C compiler in Common Lisp, load the system on ecl and compile ecl with that, so I could bootstrap ecl directly from ecl ^_^
10:52:01
edgar-rft
I think in my case it's a psychological thing. I'm trying to learn C since the early 1980s and I still *hate* that language, even if I *know* that it's idiotic to hate a language because such an attitude will keep me from learning anything at all. But I can't help myself, I still hate C. It's the only language I have such problems with.
10:59:51
jackdaniel
presentation types, input streams, and after that stream thread safety and I think that we will be ready for 0.9.9 release
11:07:06
scymtym
i would like to have another go at frame-update-on-redefinition for a release. i think it's almost in mergable shape
11:37:28
jackdaniel
we can try that, thread-safety is only in my head currently, so there is some time
14:31:05
Gnuxie[m]
if I have a presentation type with a presentation method that draws a pattern and i have a command with a select gesture, why would the command be calling present with an 'SB-IMPL::CHARACTER-STRING-OSTREAM'
14:38:45
Gnuxie[m]
how do i make sure I don't do anything fancy when it's being presented in the command arguments?
14:39:35
jackdaniel
one way is to specialize the presentation method present on a textual-view and have your fancy stream have a different view
14:39:54
jackdaniel
another, less elegant, is to specialize the presentation method present on the interactor stream
14:42:35
Gnuxie[m]
well the 'fancy stream' is just an application-pane, does that not have a different view class? (I don't really know how views relate to streams tbh)
14:47:08
jackdaniel
views are orthogonals to streams and may be used to customize different interactions / ways of presenting things
14:47:37
jackdaniel
default view may be specified with an initarg (default-stream-view or something similar)
16:18:25
scymtym
Gnuxie[m]: in my experience, it is sufficient to specialize the "graphical" PRESENT method to CLIM:EXTENDED-OUTPUT-STREAM
16:19:33
scymtym
so if the interactor uses WITH-OUTPUT-TO-STRING or similar, the method will not be applicable