freenode/#lisp - IRC Chatlog
Search
5:34:08
jackdaniel
krator44: ecl works fine when embedded in cxx application, you have to compile it with -with-cxx flag
5:52:25
John[Lisbeth]
(if common-lisp-has-lexical-scoping nil (query-channel "How do I do lexical scoping with setf in common lisp"))
5:57:23
pjb
John[Lisbeth]: that's the point! You don't! This is why you're told not to use setf to create new variables! Use LET!
6:41:13
jackdaniel
I'm writing template manager as CLIM application (using cl-emb) and thinking about syntax for adding arbitrary templates. http://paste.lisp.org/display/346920 ← I'd appreciate comments on this syntax draft
6:45:51
jackdaniel
yes, content in #> END ... END is just example of template content, I mean define-template macro syntax, which signature is (defmacro define-template (name (&rest params) description &rest file-clauses ...)
6:47:07
jackdaniel
yes, it's just a draft, it will be a macro used to define templates for the abovementioned manager
7:13:42
splittist
jackdaniel: if you can special-case the Readme.org version, do you really need the heredoc stuff in the other cases?. If you treated the first line as the file name it wouldn't need to be quoted. (Although then you couldn't have filenames with #\newlines...)
7:16:10
jackdaniel
splittist: I don't want to have reader problems but I want syntax highlight. Consider file-clause body accessing package which isn't created
7:17:29
jackdaniel
also user may want to have in template something like #.(if …) , this has to be quoted as well, because otherwise it will be simply executed by a reader
7:18:15
jackdaniel
basically it is (file-name . forms-evaluating-to-strings), so you may simply put "(? @var name ?)" there, without heredoc
7:32:49
splittist
jackdaniel: fair enough. I guess my rate of starting new projects is such that I don't have a feel for the pain points... Climacs2 will, of course, solve all the syntax highlighting problems (:
7:42:35
beach
But there is a major design flaw in Second Climacs. Since people prefer to have their Common Lisp implementation unstable and unsafe (and if it isn't, they will work hard to make it that way), they also don't want their editor to crash when their Common Lisp implementation does.
7:42:36
beach
Therefore, they demand that the editor and the Common Lisp system execute in different processes. But I have no plans to implement such a thing.
9:34:40
jackdaniel
it won't be efficient with lists in CL. try: (setf *list* (nreverse *list*)) (pop *list*) (setf *list* (nreverse *list*))
9:35:18
edgar-rft
John[Lisbeth]: it's very costly in Lisp to access the last element in a list. It's better to use a tailor-made data structure for that (FIFO or doubly-linked lists etc.)
9:36:37
jackdaniel
(prog1 (car (last *list*)) (setf *list* (butlast *list*))) ; is another way to do this
9:43:29
jackdaniel
(fwiw I have somewhere util nbutlast* which returns two values, where the second is the reminder)
9:50:14
beach
jackdaniel: My version does though, but it only works if the list has at least three elements, of course.
10:15:53
jackdaniel
my first common lisp program (project at university) did excessively use lists what resulted in a terrible performance
10:18:28
_death
btw it can also be a last-like operator that can serve as a place, so you could (pop (list-end list))
10:20:00
jackdaniel
it's possible to add it given extensible sequences are supported on the implementation
12:24:49
flip214
looks good so far.... but after 15 minutes I "still" (ha!) haven't figured out how to change the color of a button (to highlight it)
12:26:29
francogrex
i noticed that inferior lisp is better than the fancy "slime repl" for certain aspects. for example loading the package rcl hangs in the repl while works perfectly fine in inferior lisp
12:34:20
flip214
hmmm.... (ql:quickload :clim-examples) rewarded me with "failed AVER: (EQ (SB-C::FUNCTIONAL-KIND SB-C::FUNCTIONAL) :TOPLEVEL-XEP)
12:34:27
jackdaniel
flip214: if you want to customize how push-button is drawn, you'll have to specialize handle-repaint on your own version
12:35:15
jackdaniel
regarding aver, I think it's internal SBCL problem (I never seen it with McCLIM, but saw it in various other software - afaik issue is reported on sbcl tracker)
12:35:31
flip214
any other simple way to get a button that stays highlighted when pressed (until some other one is pressed)?
12:36:07
jackdaniel
you may specialize internal function clim-internals::effective-gadget-background on your button (eql), or on push-button class
12:36:30
jackdaniel
but it's a hack, it may break without a warning (internals, as already mentioned)
12:39:22
jackdaniel
regarding example of how to paint a button, see Core/clim-core/gadgets.lisp (and look for handle-repaint)
12:42:06
jackdaniel
if you specialize effective-gadget-background then you'll have always the same color
12:43:03
flip214
If I need only one of 10 buttons to be active at a time, is it better to have a special and specialize the method on (eql *my-current-button*)
12:44:42
jackdaniel
I'll check on later (busy a little) - if you have more questions put them on #clim, it will be easier to spot them there for me
14:06:20
|3b|
aeth, TeMPOraL: cl-opengl error checking happens in %gl:, not gl:, so matters for both
14:07:08
|3b|
aeth: i suspect the problem on ECL is that you are using the interpreter instead of compiler for calls to GL extension functions (pretty much all of them, including core for any version past 1.x)
14:09:19
|3b|
aeth: try editing gl/bindings.lisp in cl-opengl, uncomment the 3 forms before ";;;; Thomas's version of DEFGLEXTFUN." and comment out the 3 after, then recompile the whole thing
14:10:10
|3b|
jackdaniel: if something calls COMPILE at runtime in ECL, will it get a slower function than if it used a normal DEFUN?
14:10:53
jackdaniel
but cffi uses by default dffi afair (inlining had some fails in cffi test suite)
14:11:49
jackdaniel
up to date biggest inefficiency in ECL are generic functions (because they are not compiled)
14:12:33
|3b|
ok, those are my 2 guesses for why cl-opengl in particular would be slow, if it isn't just CFFI in general
14:13:23
|3b|
(it needs to load function pointers at runtime, so currently COMPILEs a function to call the pointer when it loads the pointer)
14:22:10
jackdaniel
aeth: if :c/c++ is too strict (symbols have to be available to C world) you may try :dlopen, which is more dynamic
14:24:08
|3b|
almost all of opengl calls are through pointers rather than symbols, so not sure that would matter
14:25:01
jackdaniel
I mean :c/c++ inlines function calls, so the library must be loaded already (i.e so object)
14:47:44
|3b|
beach: as one of the people who likes to make my lisp unstable, i still appreciate your editor work. Much easier for us to add that feature to a working editor than to add that feature and a whole editor to an empty file :) Also, apologies for any past negativity / discouragement on that and your other projects
14:50:28
|3b|
and now i'm wondering how hard/annoying it would be to coordinate between emacs/slime and a CL editor working on same files, since it could be useful as a secondary editor even without process separation
14:52:37
|3b|
possibly as simple as telling the other to save, then reloading file before making changes to a saved file
14:53:04
beach
Emacs detects modified files when the buffer is about to go from non-modified to modified state.
14:54:17
beach
I think I'll concentrate on what I am doing and let someone else figure that one out.
14:58:14
|3b|
ACTION 's next best idea for the problem that would be trying to solve involves running emacs/slime on a remote linux machine, connecting to lisp/swank on local windows machine, which is pretty ugly :/
14:59:34
|3b|
(or possibly putting emacs/slime in a linux VM, which might allow simpler fileystem access and slightly better window/mouse interaction at the expense of more local ram usage)
15:00:23
|3b|
root problem is that i want access to the text contents of editor windows and ability to send input to the editor, so i can draw the interface myself. (while also having normal editor windows available)
15:01:31
|3b|
on windows, i can't run multiple text-mode clients of a single emacs instance (and even 1 doesn't work that well), which was my original plan on linux
15:03:40
|3b|
so running emacs on linux even if i still run the lisp on windows works around that problem, but not very cleanly
15:05:40
|3b|
(and even if i were running on linux, having direct access to window/buffer contents would still be nicer than just having the contents of a terminal emulator screen)
15:07:19
|3b|
and/or being able to redirect the actual display to a different backend without having to dig through a big pile of C code
15:09:47
rumbler31
|3b|: i've done the linux emacs/slime to windows lisp/swank, it wasn't that hard to setup
15:10:33
rumbler31
if you dont' want to set up the ssh redirect, there is a global for swank to change the ip swank will bind on
15:11:04
|3b|
rumbler31: yeah, messy part is the tramp and dealing with terminals instead of normal windows
15:13:39
|3b|
beach: possibly better description of root problem is that i want to be able to interact with my editor without being able to see the normal desktop screen (either due to running a full-screen 3d program, or due to using a VR HMD, which is just a harder version of same problem)
15:15:18
|3b|
and in the latter case, i also want more control over the rendering, since most 2D UIs aren't really designed for being arbitrarily transformed in 3d space and being displayed on a low-resolution non-linear pixel grid