freenode/#lisp - IRC Chatlog
Search
22:53:11
White_Flame
not knowing where you are with things, #clschool is a bit more newbie friendly, while #lisp assumes a lot more :)
23:02:25
moon-child
what's the best way to do gui in cl, barring lispworks? I saw eql, which seems to be ecl-specific; commonqt, which is still on qt4; a bunch of interfaces to tk, which apparently some people think is ugly; and a binding to gtk, which apparently looks ugly on macos and windows
23:04:23
moon-child
phoe: yeah. I don't want to be relying on a framework which isn't going to be maintained in the future
23:04:45
moon-child
jasom: really, huh, didn't know that. Theming like gtk where it's a user-applied theme, or can I make it look good from within the application?
23:05:04
jasom
moon-child: yes to both, but it's not popular enough for many people to have a user-applied theme
23:05:29
phoe
moon-child: really annoying bugs tend to sometimes get backported into qt-libs that commonqt can use
23:07:32
moon-child
I know someone made qt5 bindings for d, going through a c layer, so it's definitely possible
23:07:33
jasom
If you're willing to write your GUI in C++ and export out hooks to call into lisp, you could make a dynamically loadable library that lisp could call.
23:09:03
moon-child
I don't think it'd be worth it for me; it's not going to be a ui-heavy app. Just would be nice to use a nicer lib if it were possible
23:09:44
jasom
moon-child: D did it by making a generic DLL with bindings (QtE5Widgets) I suppose we could use that DLL from common lisp.
23:10:58
jasom
Of course I don't know if it has foreign bindings or not; it might be D specific (D can generate DLLs)
23:11:53
moon-child
d also is able to call directly into c++, which idk if they're using that at all
23:12:56
moon-child
yep. But most people don't use it because there isn't a good automatic binding generator and there are some unimplemented features. So if they're going through an intermediate dll, there's a good chance they're not using it
23:13:37
jasom
generateAlias("t_v__qp_qp_i_i_i_i_i") <-- looks like they could be using it, that looks like a C++ mangled name
23:13:39
moon-child
(aside: cl could call into qte5's c library, instead of needing to create our own. Be an annoying dependency but ¯\_(ツ)_/¯)
23:16:32
moon-child
jasom: nope. generateAlias() makes an extern(C) function, meaning c ABI and name mangling
23:17:33
moon-child
phoe: dependency on a d library is less practical than a dependency on a c|c++ library
23:22:25
jasom
moon-child: Python extsnsions are usually written in any language that can export C functions; there is a C api that allows manipulation of python objects.
23:22:38
jasom
It looks like Go's bindings might be usable: https://github.com/therecipe/qt/blob/master/gui/gui.h
23:24:15
moon-child
This issue https://github.com/ryanmelt/qtbindings/issues/131 mentions an updated version of smoke
23:57:25
lottaquestions
Hi all, I have a question about SLDB with SBCL. How does one know which frames can be restarted and which ones cannot? Also, I seem to be losing global variables when I restart frames. I how do I prevent against that?
0:38:05
dmiles
White_Flame: the real power of the locative is not what it sets.. it what it makes appear in several locations
0:40:28
White_Flame
if locatives were somehow transparently traversed, then it would have such magic effects, but probably be unworkable
0:40:44
dmiles
yeah i wanted to actualyl that it is really is about structure sharing.. to be ablke to have a CDR withotu a CONS
0:41:34
White_Flame
yeah, for purely CONS-based stuff, having a cdr iterator function instead of just a data link would be somewhat interesting
0:42:47
White_Flame
again, the main difference is if diverting pointers or accessors would be followed implicitly, instead of requiring dereferencing them manually/specifically
0:43:18
dmiles
( i was really tryign to say .. "to have structure sharing yet evenb when no structrures exist)
0:48:57
dmiles
since nowadays you have to find all 5 places and trrhe symbol value and if any one is set you have to go and update the otehr 5
0:50:05
White_Flame
while it "wastes a slot" it's less usually memory footprint & code than a 1-element structure or array
0:51:19
dmiles
what ECL used to have is a brilliant dynanmic extent on locatives that merely could forget about them or not
1:40:31
akoana
Xach: probably it is included in the hspell package (I did apt-get source --download-only hspell, there is a libhspell.c in the orig.tar.gz)
4:50:25
beach
For that kind of stuff, McCLIM is ideal, provided you want to program in Common Lisp of course.
4:51:28
beach
What are some of the characteristics of this editor? What kind of stuff will the user edit?
4:52:15
moon-child
beach: I recently started using emacs, and while I am impressed, I want to a) do better; b) make my own
4:52:50
moon-child
something that will work cross-platforms. If there are plans to add other backends 's probably fine
4:53:38
beach
There are plans for other backends. And you may want to consider writing one that you need. You will save time by implementing your editor in Common Lisp, and you will help others who need that backend.
4:54:17
moon-child
the editor was always going to be in cl, the question was just what the graphics backend would be
4:55:02
beach
When you start mixing languages where some have manual memory management, you are in for a debugging nightmare.
4:55:51
moon-child
believe me, I know it. I wrote an embedding thingy for perl6 and getting it to talk to c well was awful
4:56:21
beach
OK, then you should know that I have plans for an editor for Common Lisp code. I already wrote (first) Climacs, and I have a design for Second Climacs. And loke is working on one as well. So if you need advice, just ask.
4:57:50
beach
I do, but I don't remember by heart. You can look at Second Climacs, but I advise against trying it.
4:59:59
beach
moon-child: Because of item b above, I am not suggesting a collaboration. But I can give advice.
5:01:43
moon-child
probably don't want to collab anyway. I have different goals to emacs; what I want to make is a development of editors informed by my experience with emacs, but which is probably closer to vim in the end, which seems different from what y'all are making
5:02:18
moon-child
I saw cluffer, was thinking of using it. Also looking at the backend interface for clim to see how much work a w32 port would be
5:03:07
beach
The editor I am planning would not be designed around key bindings. The essential design would about parsing buffer contents incrementally and displaying information to the user. Key bindings is just a minor thing.
5:04:04
moon-child
with more granular levels of temporality than just permanent(-ish) config files and transient macros
9:05:26
_death
Xach: hmm now that akoana mentioned it I do remember something about static lib only.. maybe I compiled it on the server to get the dynamic library