freenode/#lisp - IRC Chatlog
Search
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
18:07:58
phoe
;; oh, it didn't go out the way I've planned - I need to perfect my way of sending ICS invitations
18:15:50
Fare
Was the #.(ALEXANDRIA:RANDOM-ELT *OLM-MAIL-GREETINGS*) a deliberate joke or a mistake? Poe's Law.
19:24:44
Josh_2
Hi. With CLIM how do I have a pane update all the time instead of only when I input a command into the interactor?
19:25:19
Josh_2
I have a pane that is supposed to read from a constantly updated stream and then display what it has read
19:41:01
ioa
phoe I did mention dylan on the condition-system question, but I don't think we talked about it.
19:42:37
flip214
dlowe: it looks to me as if ITERATE tries to interpret COUNT or even CL:COUNT like with CONC, COLLECT etc. clauses
19:59:27
Alfr
Should it be there in the first place? From iterate's manual section 2.3: "However, when there is a conflict with Common Lisp, only the present-participle form may be used (e.g. unioning). This is to prevent iterate clauses from clashing with Common Lisp functions."
20:02:45
mfiano
It should not. There was an SO answer about this question recently that suggested reporting a bug to either update the documentation, or deleting the synonym. I'm unsure if that was ever realized though.
20:05:14
Alfr
Getting rid of that in the docs would be bad, that would then also make reduce harder to access and maybe also other things.
20:07:26
mfiano
Here it is: https://stackoverflow.com/questions/59261705/how-can-i-use-the-function-count-inside-an-iterate-form
20:08:16
mfiano
"I've sent a bug repot to the mailing list and cc'd you. Thanks for explaining this to me!". So it has been reported, but you know how it goes with a lot of Lisp libraries. Bus factor of 1 or less.
20:11:11
mrcom
flip214: (setf (symbol-function 'foo-cnt) #'cl:count) (iterate (for i below 4) (sum (foo-cnt 1 '(1 2 1 0)))) ;; => 8
20:17:11
Alfr
mfiano, it's not that lispers don't know how to fix it, but more that it's (at least to me) unclear whether it's still actively maintained. Of course, apart from this and the documented limitations which boils down to the need of a better code walker, I've never noticed it to break, i.e. not much maintenance required.
20:19:29
Alfr
mfiano, we wouldn't lose the ability to maintain it, if he/she got hit by a bus ... were we to know that fact.
20:19:35
phoe
I guess that us lispers kinda grew used to life with the fact that we live on big piles of Heisenberg-abandoned code that gets unburied and refreshed now and then when it's necessary
20:20:56
phoe
this isn't strictly about Lisp, but it's definitely visible in the Lisp community because there's few people in the community in general compared to languages considered mainstream nowadays
20:21:28
mfiano
A blessing, because Lisp being as flexible and expressive as it is, allows a single developer to mold the language to their domain. After all, code is just a projection of ones' own mind.
20:22:05
Alfr
phoe, some libraries also are at some point "finished" as in having implemented all they purport to do.
20:22:06
mfiano
So it's no wonder why Lispers don't work together that well. It's often easier to express ideas suitable for themself rather than conform to someone elses'.
20:26:09
Alfr
phoe, fork locally and change it should I really need that change, but usually I'll just work around it; especially when it's something as commonly used as iterate.
20:27:46
Alfr
mfiano, I'd be also quite reluctant to publicly fork a repo just for what I deem to be a bug.
20:27:53
mfiano
Software is finished when it does what it intends to do correctly, and without any bugs. But the number of bugs is proportional to the number of users, and their funny input and use-cases. If you ever think you're "finished", just (incf *users*).
20:28:24
aeth
ITERATE is commonly used? I haven't really seen it in use and I've tried to use it before, but it has this sort of uncanny valley effect where it's close enough to LOOP that I come to it with my LOOP expectations, but different enough that few of those LOOP expectations work, making it a library that's not very easy to use ime.
20:29:09
phoe
if you do this instinctively then I can imagine there's other people who do the same because it's impossible to effectively update an upstream project that has no maintainer
20:30:19
Alfr
phoe, if I can establish contact w/ maintainers and they say that they'll accept changes, I do.
20:31:07
phoe
see several fukamachiware projects which have had open PRs and issues for months if not years; even though the author is active and the projects are commonly used, they are effectively abandoned because no one maintains them
20:31:51
phoe
I use them as examples because they're both prominent in their popularity and notorious for their almost-working-ness and impenetrable code