freenode/#clim - IRC Chatlog
Search
4:22:09
beach
Good to know you are fine. Yes, lots of McCLIM progress. SICL is making progress as well. No major module left to write, but some are still being worked on.
4:50:32
beach
I don't know if the current state of SICL applies to that definition. It is still executing in a host Common Lisp, but lots of stuff "just works", so it that is a good sign. Also, some of the heavy stuff, like the compiler, is still not running as SICL code, but directly by the host, for reasons of bootstrapping.
5:05:54
slyrus
beach: Ok, I'll have to check it out. Have you still been working with the clasp folks?
5:12:37
beach
Sort of, yes. Bike and karlosz are working on type inference for the Cleavir-based Clasp compiler. But I am trying to debug as little code as possible, so I am not using their code yet.
9:08:13
jackdaniel
this one is funny (found on twitter): "C is awesome because it defers problems to runtime, at which point people might not be able to find me."
11:10:50
scymtym
could you look at #1040 in the meantime? it makes clim-fig much less flickery, helps with render debugging and should be easy
11:12:30
jackdaniel
sorry, I won't be around computer until the rest of the day (tomorrow I will be around 11)
11:16:01
jackdaniel
I have a memory with the issue, that when the layout was changed (even to the same one), dimensions were recomputed to something else (or the window moved?); I'll need to check if #1040 does not "hide" that issue before that very issue is solved (given my memory does not play tricks on me)
12:50:07
contrapunctus
Can one use McCLIM (LLGPL) to make public domain (Unlicensed/WTFPL) programs?
12:56:18
contrapunctus
jackdaniel: thanks! So IIUC, as long as McCLIM and the PD program are not distributed together?
12:58:17
contrapunctus
Oh, they can indeed be distributed together. I misunderstood LGPL 😅 Thanks again!
13:11:49
lonjil
Note that if you distribute dumped and executable cores to users, to comply with the LGPL you probably need to distribute all the FASLs as well so that users can "relink" (load into a fresh image) your application with their own source code copy of the library. I'm not quite sure how everything in the LGPL translates to Lisp, but something like that would need to be done I think.
13:12:56
jackdaniel
I wrote this some time ago: https://common-lisp.net/project/ecl/posts/ECL-license.html
13:15:43
lonjil
I'm not talking about anti-tivoisation. If an LGPL 2.1 library is *statically linked* into a binary, then an unfinished binary needs to be provided, which can then be linked with another copy of the library in question.
13:16:48
jackdaniel
that's a fad which was refuted in a few places already (especially in CL context), I (once again) point at the issue I've linked above
13:17:13
jackdaniel
I don't remember places where it has been refuted, but a good example is legal interpretation provided by lispworks
13:58:23
Gnuxie[m]
is it possible for the panes in a layout to be dynamic, ie, instead of switching the behaviour of a pane by having some logic in the display function, you instead just swap which pane is being displayed in that place in the application frame layout?
14:06:51
scymtym
Gnuxie[m]: the simplest way to do this is having multiple layouts and switching between them. this is, of course, not very attractive for multiple variants of a complex layout that only differ in a small detail. so another way would be to use a pane as a container and programmatically replace its child
14:08:14
scymtym
this is an example that's probably at the boundary of practicality of the layout-based approach: https://github.com/McCLIM/McCLIM/blob/master/Apps/Clouseau/src/application.lisp#L50
14:08:51
scymtym
and the corresponding command: https://github.com/McCLIM/McCLIM/blob/master/Apps/Clouseau/src/application.lisp#L116
14:14:35
Gnuxie[m]
right I see, that's interesting, thanks, I'll have to investigate composite panes a bit