freenode/#lisp - IRC Chatlog
Search
5:43:28
beach
In my opinion, programmers need to know about compiler design. Not so much in order to create fast code, but in order to avoid guessing what the compiler will do, and in the process, making their code less maintainable. But there are cases, like this one, where such knowledge is needed for creating fast code.
5:53:16
fwoaroof[m]
Yeah, I've been slowly discovering in my professional career why the old lisp books cover the topics they do
5:53:38
fwoaroof[m]
Things like continuations and language design are surprisingly relevant to day-to-day programming
5:57:42
seok38
fwoaroof[m] yeah, for books on other specific languages I wouldn't trust stuff that is printed before 2012
10:50:08
p_l
fwoaroof[m]: dynamic-extent doesn't have to be respected, but generally it's suggestion that it's similar to stack allocation, so it's less of a speed optimization and more space optimization
10:51:02
p_l
non-consing code also tends to keep to function arguments and return values a lot, but to be honest when looking for that I'
12:16:31
Josh_2
hmm I have a minor problem. Im trying to create my CLIM interface for an app, and all of the output is sent to *standard-output*, however I guess the backend is going to have to run in a different thread and I will have to override the default value of *standard-output* to be a different output stream so I can display the content in a different pane. Is it going to be safe for me to read from the stream on one thread and write on
12:16:31
Josh_2
another without using a lock?? or am I gonna have to go replace all of my instances of format with one that grabs a lock first?
12:18:07
Josh_2
I wish to run the backend with or without my CLIM interface, so I don't want to go messing with it all that much
12:18:33
Bike
if it came down to that you could just have a stream object that handles locking itself, probably, so the rest of your code wouldn't have to change
12:22:38
phoe
ACTION thinks of a world in which SIGNAL automatically placed a MUFFLE restart around the signaling site for all non-serious-conditions that would work in the same way as MUFFLE-WARNING does for warnings
12:25:17
phoe
basically, "ok, I took care of this, I don't want any outer signal handlers to execute, please carry on with the standard execution flow"
12:25:53
phoe
I mean, it's trivial to write a SIGNAL* function that does exactly this, but a short discussion with someone on the Dylan condition system sparked this thought in my head
12:27:32
jackdaniel
Josh_2: if you use the *standard-output* from inside the display function, then you are not accessing the it from "foreign" thread
12:28:13
jackdaniel
generally using streams asynchronously from a different thread is risky at best (i.e CCL signals an error)
12:28:55
jackdaniel
currently McCLIM streams are *not* thread safe, however I have plans to change that by scheduling asynchronous operations as events, which will be later "properly" handled in the stream-specific thread when dequeued
12:29:55
Josh_2
jackdaniel: well I am not using *standard-output* I have my own output-stream I have created as a slot on my frame which I wish to use in place of *standard-output* with (let ((*standard-output* output-stream ... etc
12:33:21
pve
is there an actual document or wiki for the Hypothetical Future Revision, or is it just a joke?
12:34:21
jackdaniel
(clim:define-application-frame foo () ((my-stream :initform /whatever/ :reader my-stream)) …) (defmethod clim:frame-standard-output ((frame foo)) (my-stream frame))
12:36:21
phoe
there's much more important stuff to do than working on the hypothetical future revision though
15:37:45
jmercouris
Instead of class B extending class A, I want class A to somehow get the properties of class B
15:38:12
jmercouris
I mean that I want the method that specializes on class B, to also get invoked for class A objects
15:41:32
phoe
that's one obvious upside of CLOS being a runtime object system as opposed to being a compile-time object system
17:14:20
phoe
KMP has implemented a condition system in Python to convert Pythonists to the round side of the force
17:16:28
phoe
your average programmer doesn't speak Lisp but they very likely speak Python to *some* extent
17:16:51
phoe
so, hey, here's SIGNAL, here's conditions, and handlers, and restarts, and the debugger
17:20:08
phoe
I'm waiting for him to publish the sources so I can try and be the first one to post it on /r/Lisp
17:26:46
jackdaniel
isn't it just another feature from Lisp cross-polluting to other languages? I mean - when people encounter the garbage collector they don't think "wow lisp", they think "wow java"
17:28:29
jackdaniel
(or anonymous function or whatever has been adopted in X language; I don't understand excitement, unless you are happy that python will improve because you are a python programmer)
17:30:08
phoe
sure, I like hearing about this kind of stuff where nice ideas migrate into wider ecosystems