freenode/#lisp - IRC Chatlog
Search
15:04:36
jackdaniel
ACTION cheers on lukego, however he is wondering why the same effect on emacs generates approximately PI-times more wow than natively in CL ;)
15:07:04
lukego
maybe partly "ha ha only serious" hack value and partly that many of us are living inside Emacs and anything we can do there might get 100x more usage than stuff outside
15:07:48
lukego
for example every time I figure up the McCLIM listener I think "that's awesome!" and then within a minute or two I kill it to get my "real" REPL back.
15:08:27
jackdaniel
perhaps we should call the listener slime-repl and play dumb when someone tries to close it ^_^
15:09:20
lukego
credit here is to McCLIM anyway because it is doing all the real work, CLIME is just making it more accessible to emacs nerds.
15:10:36
lukego
jackdaniel: well it doesn't work. a minute in Drei is enough to drive me to distraction. Some people think of Emacs as a stop-gap hopelessly inferior Lisp machine, but I'm in the other camp that thinks Emacs is basically the most powerful program every made.
15:11:09
beach
rpg: I am trying to teach ASDF to use my custom LOAD function during SICL bootstrapping, and I am reading the ASDF manual. But I can't figure out what I am missing. Is there a convenient time for me to ask you how to do this?
15:12:41
lukego
ACTION wonders whether to push the code now or test it while actually having more than one type of presentation...
15:13:05
rpg
Here is fine, but if it would stomp on other discussions too much, I could hop over to #sicl. But will need a little time for me to finish up something. On the half hour?
15:19:03
lukego
splittist: I pushed rough initial ACCEPT support. Emacs side changes only. Some notes on the caveats @ https://github.com/nuddyco/slime/commit/8b1ea319b9d2522445454ec7b9de2e10180474bc
15:21:55
lukego
jackdaniel: btw it's pretty exciting in splittist's demo to start seeing existing CLIM code able to render into Emacs - and will have working ACCEPT. This could potentially create a two-way street where CLIM code written for the "Emacs world" and "CLIM native world" works on both sides and people can build on each others' stuff.
15:22:34
lukego
for example if clim-listener presentations could render into Emacs, then Emacs users could make clim-listener extensions of their own, and that could get folded into the upstream native clim listenre
15:23:04
lukego
ok maybe obvious :) it's a bit of a revelation to me to truly see CLIM as a flexible set of user-interfacing protocols rather than a monolithic "lisp machine user interface"
15:23:47
lukego
I know that it's always been described as such but I've never used e.g. PDF backend etc before so I never experienced that.
15:25:39
lukego
(Maybe I'm also squeamish but it's also really comforting that CLIM is not running a whole bunch of threads and event loop machinery behind the scenes here i.e. it's all the usual threads belonging to SLIME and my application that are driving execution. knowing that lifts a weight from my shoulders.)
15:26:49
lukego
yeah I don't know what's really happening in e.g. x11 mode but it seems a bit scary and opaque to me. I say that as someone who does not dare to use threads in my Lisp programs.
15:26:53
beach
jackdaniel: Don't worry, once we have the planned IDE, it will be irresistible for Common Lisp programming.
15:59:44
_death
basically inspired by http://www.karlsims.com/papers/siggraph91.html (which used starlisp on the connection machine..)
16:09:46
scymtym
flip214: if you feel adventurous, you can use https://github.com/scymtym/clim.flamegraph/tree/advice-backend to capture the kind of deterministic call tree with arguments and timing you describe
16:26:48
_death
phoe: oh, I misinterpreted your question.. the mutation is done on the genotype, i.e. an s-expression.. like (abs (and x y))
16:36:16
lukego
beach, jackdaniel: it's actually really nice the way you guys have structured projects like sicl and mcclim in such a way that they can drive towards a grand ambition but also be modular enough to act as components of other people's less ambitions systems e.g. emacs hacks, existing lisp compilers, etc. kudos :)
16:39:43
jackdaniel
mcclim was structured by previous caretakers (beach included); I only fix typos in the code and such
16:41:13
beach
People here should know that what jackdaniel just said is a gross underestimation of his role in McCLIM development.
16:44:41
beach
In my opinion, it is largely thanks to jackdaniel that McCLIM has been transformed from a useful but incomplete hack with tons of bugs to a serious library. He didn't do all the transformations himself, of course, but he was the one who took on the maintenance after years of no activity on McCLIM.
16:46:19
beach
I don't follow #clim closely enough, so I am not going to attempt a list of all the contributors, but I know that scymtym has dont quite a lot of things. I am sure jackdaniel can tell us who the others are.
16:48:05
jackdaniel
there is longi-sh authors list in the codebase; I'm too afraid that I'll forget about someone important while enumerating
16:49:12
jackdaniel
from top of my head scymtym, loke, slyrus, nsahmad, john-a-carroll, pwerkowsky; but there are more
16:49:50
jackdaniel
(half of the mentioned names are people who contribute by insightful bug reports)
17:28:19
lukego
hurray for all of you :) it's exciting to me to be starting to actually use CLIM having had CLIM-envy for a couple of decades
18:48:05
pjb
rpg_away: but this is ridiculous. Why don't you just take advantage of Lisp ability to have newlines in strings literals?
18:53:37
rpg_away
We want to allow people to have layout that will look good in source code and when displayed.
19:07:42
pjb
rpg_away: you can still indent literal strings; It's just a matter of bound box for the lisp object representation.
19:15:46
pjb
rpg_away: note: this is only a presentation. The string would be full flushed to the left (no prefix spaces on the lines). But the editor would align them to a rectangular box instead of the indented area, and would fill the left with a filler color or character to indicate it's not part of the source code. It could be the same face as the fringe, if it was distinct from the background.
19:17:38
pjb
rpg_away: this could even be implemented easily enough in emacs, when you type RET in a string literal, it would automatically indent with those ░ characters with an overlay or a compose-region or something… The source code wouldn't include them.
19:49:36
albusp
I thought reader will still use the keyword package for :cl, or does it still intern it in the current package when it encounters it? Is that why we do #:cl so that it is not interned?
19:50:09
jackdaniel
albusp: this is to inform the person who reads the code, that the symbols itself has no meaning - only the name in this context matters
19:54:47
albusp
ah, ok thanks for the answers! I further checked it on repl now, and see the difference:
19:54:47
albusp
(boundp #:testme) --> enters debugger saying testme is unbound, so the reader doesn't intern the symbol in the keyword package
19:54:47
albusp
(boundp :testme) --> T (which means it first creates the :testme symbol in the keyword package)
19:56:07
jackdaniel
symbols in the keyword package are exceptional because their value is always their name
19:57:12
pjb
and try: (values (boundp '#:testme) (setf (symbol-value '#:testme) 42) (boundp '#:testme))
19:58:12
pjb
and try: (let ((testme 42)) (values (boundp 'testme) (setf (symbol-value 'testme) 33) (boundp 'testme) testme (makunbound 'testme) (boundp 'testme) testme)) #| --> nil ; 33 ; t ; 42 ; testme ; nil ; 42 |#
19:59:16
pjb
albusp: #:foo is an uninterned symbol. But it's a symbol like any other. If you try to evaluate, CL will try to return its value slot. If that's not bound an error occurs.
20:00:10
pjb
albusp: in the case of the lexica LET testme, this doesn't bind the value slot of the symbol. With lexical let, the symbol is only used as a name to a lexical variable that is bound. Not the symbol itself.
20:00:36
pjb
But you can both bind the value slot of the symbol, and the lexical variable named by the symbol! Hence the results 42 and 33 in the example.
20:03:11
pjb
albusp: note that with defpackage, the reader know that the elements are string designators. The difference between :use cl, :use :cl, and :use #:cl are only in the interning and in what package the symbol is interned. :use cl interns a symbol named "CL" in the current package. :use :cl interns a symbol named "CL" in the package named "KEYWORD". :use #:cl doesn't intern any symbol, it just creates an uninterned symbol named "C
20:04:05
pjb
albusp: the difference being that the interned symbols are not garbage collected once the compilation is finished, since the packages are still refrenced in (list-all-packages). But the uninterned symbol (or the strings, when you :use "CL") can be garbag collected.
20:05:55
pjb
albusp: the difference between (:use cl) (:export a b c) vs (:use :cl) (:export :a :b :c) is not with (:use cl) (:export a b c) now the current packages has a whole bunch of symbols interned in it: (cl a b c), and if uou try to use the package that you just defined, you will get name conflict, between the exported symbols and the interned symbols that have the same name, but are not the same!
20:06:27
pjb
albusp: with keywords, you would get name conflicts if you tried to use the package in the "KEYWORD" package, but nobody does that, so no problem.
20:06:53
pjb
albusp: the best is to use #:foo or "FOO", I prefer the later since that makes less memory to allocate and garbage collect at compilation time.
20:13:44
pjb
albusp: Now, you can have: (defun f () (declare (special var)) var) ; note no variable named var is defined. (let ((var 42)) #| lexical variable |# (list var (let ((var 33)) (declare (special var)) #| dynamic variable var |# (list var (f))) var)) #| --> (42 (33 33) 42) |#
20:14:48
pjb
albusp: so during the execution of the inner, dynamic let, the scope of the lexical variable var of the outer, lexical let, is shadowed, and the _dynamic_ variable can be accessed even outside of the lexical scope, in the function F.
20:16:53
pjb
(let ((var 42)) #|lexical|# (setf (symbol-value 'var) 22) (list (list var (f)) (makunbound 'var) var)) #| --> ((42 22) var 42) |# here, we don't bind dynamically a dynamic variable var, but we directly set the symbol value, (it's where dynamic variable values are stored), so it can be read by F.
20:55:34
jcowan
beach: What happens when you are running CLOSOS and so am I, and I want to reuse parts of your iaage?
21:01:03
jcowan
FASLs are isomorphic to source files (or at any rate multiple files constituting a single compilation unit, whreas (frozen) Lisp images have it all.
21:03:06
phoe
jcowan: to put it another way - sounds like a need to serialize a part of the object tree of one image to a file, and intern it/merge it into the other image later
21:39:27
no-defun-allowed
The Self people had a transporter for getting objects between images. A careful reading suggests the transporter framework is just a convenient way to create methods on MAKE-LOAD-FORM.
0:12:22
White_Flame
hmm, the slime highlight in emacs doesn't work for #+not-found #p"foo". It shows the #p in comment color, but highlights the string in regular colors
0:14:19
White_Flame
paredit also considers the #p and the string to be 2 separate entities when moving parens
2:42:03
no-defun-allowed
I thought there was something in usocket which let you poll/select connections, but I can't find it. There are libraries for nonblocking IO, but they undoubtedly put you in callback hell.
2:44:58
no-defun-allowed
From memory the only way to do non-blocking IO on files involves the POSIX asynchronous IO stuff which isn't commonly used.
2:46:16
no-defun-allowed
I'm not kidding when I say this - I think the nicest way to write non-blocking IO code is to use ABCL on a Java 17 preview with the Loom extension. That way you have green threads and asynchronous IO with straight-line programs.
2:46:46
no-defun-allowed
I think libev uses another thread pool for file IO. Or maybe that was Erlang/OTP. Perhaps both.