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
20:32:12
mrcom
Iterate also has some issues with type declarations, and it would be nice to get rid of the reader macros (messes up source-code location tracking in SLY--general SBCL issue?).
20:34:56
Alfr
aeth, maybe it's just me using it all over the place, I guess I really like iterate for having less ordering requirements for its clauses.
20:35:33
mfiano
I have years-old issues there. I couple years ago I just decided to refuse to use any of them because of it. They simply do not work as intended for my use-cases, and the coding style is painful for me to patch myself without taking too much time away from problems higher up on my list.
20:37:28
mfiano
clack, sxql, datafly, cl-dbi, to name a few. Show-stopper bugs that made me write my own things, though I do not do much web development these days anymore, anyway.
20:37:38
aeth
(And if I was more consistent about using issues in my game engine, I'd probably have several dozen issues dating back 4 years.)
20:42:26
mfiano
I don't mean to sound so critical of other peoples' work. It's just that one of the major reasons I use CL is because it's easier to sculpt things myself with regard for my particular domain.
20:42:41
phoe
do we lack the people to fix that state of matters? do we lack the organization? do we lack discipline or money or what
20:43:53
aeth
e.g. the popular web libraries in other languages are usually well-maintained because people use them professionally
20:43:53
mfiano
I think we lack the desire, because of the ease of rolling your own and bending the language to your own thought processes.
20:46:38
phoe
aeth: I don't think it's the issue with money, I don't think the average or median of wealth and/or incomes is on the poor side when it comes to lispers
20:49:01
phoe
then again mfiano's answer is not really an answer in my opinion, because it's more than possible to write software collectively in Lisp and there's dozens of examples of that, and it's possible to write software that is maintainable even after being abandoned by its original authors and then successive maintainers
20:49:08
mfiano
I don't speak for everyone of course, but I think that in addition to the low bus factor, there is also a very low er count for the majority of Lisp software.
20:50:28
aeth
money more as money flowing to people through the project (probably indirectly) is what I had meant
20:51:02
phoe
but if new languages and paradigms appear from the level of zero professional adoption, then in theory it's also a question why Lisp with its strengths doesn't manage to do that
20:51:54
phoe
I was thinking if it's some sort of a question of bringing the software that we have from its current diaspora into one collective place
20:51:56
mfiano
Yes professional use is another factor, and Eric Normand and others have talked about the reasons extensively.
20:53:44
mfiano
Convince companies that they don't need to hire Java boilerplate data entry specialists in drones because they are cheap and expendable?
20:55:46
phoe
I wonder if we could listen to Eric Normand and learn something from the world of Clojure that grew really nice and well
20:57:41
mfiano
Java's success is mostly because developers can sneak modules into existing Java codebases seamlessly.
20:59:03
dlowe
Java's success is mostly from billions of dollars of research and marketing on Sun's part
20:59:09
mfiano
I think performance and the lack of backing by a company such as Cognitect is the biggest concern there
21:00:23
dlowe
anyway, if you want people to use something like a programming language, you have to put it between them and something they want
21:03:51
aeth
dlowe: If by "put it between them and something they want", you mean "require the usage of that language to enter some ecosystem", that definitely works, e.g. JavaScript, C#, or any language by Apple
21:04:42
aeth
dlowe: Perl failed because Perl 6 was even more of a failure than Python 3 in driving away existing users and not offering a clear upgrade path (Python eventually recovered, but was probably set back 5 years)
21:06:09
aeth
phoe: Some are just for one library (in the case of Ruby, Rails) and some are for quite a few libraries (Python), but for the most part, people use a new language when the choice has been made for them (even Emacs Lisp's popularity to some extent)
21:06:46
aeth
Arguably Python's shifting more in this direction because of machine learning libraries like Tensorflow
21:10:31
aeth
phoe: I wouldn't call it "dirty tactics", either. I mean, when Microsoft or Apple or Google does it, they're trying to push for more control, but it's a concept that works in general and includes e.g. JavaScript or even C++. Some domains just force you to use the language, generally to be involved in some ecosystem.
21:11:13
phoe
aeth: agreed. (though the domain of programming for corporate ecosystem X or Y or Z is still dirty gatekeeping in my opinion)
21:12:23
aeth
phoe: To be fair, though, Microsoft did try some language-agnostic approaches like COM.
21:14:45
phoe
aeth: I think that we shouldn't go into this alley because we have no big ecosystem of Lisp software or Lisp-related domain that might act as a reason for people to learn Lisp for
21:15:24
phoe
and the last somewhat successful Lisp-based OS died shortly after hardware it was designed for
21:16:10
aeth
phoe: I think that this is the only "alley" one can go down. The secondary and tertiary libraries aren't going to really take off without primary libraries/frameworks/applications/whatevers that drive people to the language.
21:16:11
phoe
MetaYan: oh? there was something after OpenGenera that achieved some commercial success?
21:17:03
aeth
phoe: I personally think that the main place where any language can attract lots of new programmers is probably games. People will learn any language (Java, Lua, C#, custom proprietary languages, etc.) to mod their favorite games and they're usually too young to know better (i.e. too young to focus just on the most marketable language)
21:17:34
mfiano
phoe: I think one of the best things we as Lispers can do to improve onboarding, is to have better tooling, starting first with SLIME/Sly equivalent for other editors, but in addition, extending asdf to allow versioned/package-renamed dependencies (however possible that may be) for more reproducible builds outside of the near-bleeding edge Quicklisp dist, etc
21:18:32
White_Flame
sure anyone can start a company. Getting a market & customer base is another thing
21:18:55
phoe
MetaYan: that's technically correct advice that I consider to be of little practicality
21:19:53
mfiano
Lisp has a pretty high learning curve even if you discount the learning of a [probably] new editor, configuring it, etc. Emacs is nice and all, but C++ doesn't require MSVC for effectiveness
21:21:00
aeth
I think tooling follows adoption, not the other way around, and some decently popular languages (like Lua) have terrible tooling, but people still use it because the games they want to script use it.
21:21:37
mrcom
I think perhaps Lisp is not as well suited for the niches filled by more mainstream languages.
21:21:50
mfiano
That is true, however I can't even count the number of newcomers to the language that gave up during the learning of Emacs
21:22:18
MetaYan
I can compare the joy of getting Mezzano running on hardware the other day with the aversion to even touching the computer at my last programming gig - which was digging in someone else's spaghetti code in VB.
21:23:41
Gnuxie[m]
There isn't much of an 🆑 ecosystem relative to other languages, that includes both libraries and a labour pool and other than supposed efficiency, the perceived (gains?) of taking CL (as a corperation) doesn't out weigh the risks
21:24:23
mfiano
Then you get the ocassional newcomer that uses Notepad++ complete with dangling parens (usually a student that was improperly introduced)
21:25:17
mfiano
and quickly give up because they aren't utilizing the interactive and introspective workflow Lisp was designed around
21:25:22
Gnuxie[m]
plus, you would also have to fight all the educational institutions too if you went with 🆑, since they are churning out people to write glue in Java, everything is against you
21:25:32
mrcom
Large corporate code bases tend to be structurally.. not complex, but very wide. Lots of elements with specific business-logic, but not as complex algorithms.
21:27:04
MetaYan
Even if I'm far from profocoent in Lisp, I'm tinkering with my own webserver in pure Lisp and even if it's a slow process, I find great joy (and of course occasional frustration followed by even greater joy) of using Common Lisp interactively.
21:27:32
mrcom
Corporate code needs fairly rigid APIs. It takes a lot of effort to make Lisp code rigid. Great for small teams or single developers, but not so much for large groups of teams.
21:29:58
aeth
You can enforce rigidity by requiring the use of certain custom macros, while also requiring any new DEFMACRO to be justified.
21:30:08
MetaYan
Could this be one of the reasons why people don't find Lisp to light up their programming ways? https://www.perl.org/ https://www.python.org/ https://clojure.org/ https://lisp.org/
21:30:25
mrcom
For example, even the simple concept of 'no value specified' is a big deal in the corporate world.
21:31:13
Gnuxie[m]
Does it really 'take a lot of effort'? It takes 'effort' to enforce consistency and expectation in APIs in every other language
21:32:25
mrcom
That's good for some things, especially the flexible problems we like to throw Lisp at.
21:34:39
aeth
mrcom: List? Easy since you just write your own cons. Vector? Now that's much harder because :element-type is almost certainly only going to work on simple, immutable types like numbers and characters.
21:36:18
aeth
mrcom: but you can write your own custom sequence consisting of a custom cons-like object that can only contain foos.
21:36:38
aeth
mrcom: You cannot do that for vectors/arrays... I mean, I guess you could, but it's much more complicated.
21:37:05
mrcom
Lisp is much happier with problems where 'most of the time it's a foo, but once in a while we really need a bar in there.'