freenode/#lisp - IRC Chatlog
Search
18:26:25
Fare
kilimanjaro, I have ideas on how to make debugging uniformly more bearable including on the JVM
18:29:17
jackdaniel
\o/ ECL has implemented virtual streams handled by ext:run-program (that means, that gray stream may be used as :output argument) – cleaning up code now
18:32:28
jackdaniel
either way, it is not a trivial problem because gray streams doesn't have file descriptors which could be attached to process
18:32:47
Shinmera
Wait, actually, I did know. That's why I wrote a library that does copying in the background to allow using other kinds of streams.
19:02:10
jackdaniel
rumbler31: you may for instance do (with-output-to-string (s) (ext:run-program "ls" nil :output s)) what wasn't possible before
19:02:37
jackdaniel
some badly written libraries depend on that, so they can gather system information etc
19:10:15
rumbler31
jackdaniel: so what made the stream activity in ext:run-program special in that it *wouldn't* work with the stream created by w-o-t-s, that is now different and made to work the way you expect?
19:11:26
jackdaniel
so you have nothing to attach to a newly created process and magic doesn't happen
19:13:21
rumbler31
I know you said that virtual streams don't have a descriptor above, but if using a stream created by w-o-t-s wouldn't work with the run-program call, what kinds of streams were expected to work?
19:20:09
rumbler31
thanks for the explanation, I don't usually find myself working in those layers and I'd like to learn more. I'd be interested in reading your commit
20:36:50
minion
jmercouris, memo from phoe_: https://github.com/brown/swank-client https://github.com/eudoxia0/swank-protocol
20:41:11
sjl
jmercouris: I don't know. My only solution so far has been to try to document the stuff I release as well as possible, to be the change I want to see in the world.
21:08:28
Shinmera
jmercouris: The line of questioning that goes along the lines of "Why is the lisp community not doing X" always irks me because it implies you'd like to force other people to do what you want. This never works. All you can bet on is what you do on your own. Thus, if you don't like the current situation, /you/ do something about it. If you don't like the (lack of) documentation on a project, go fix it.
21:08:57
|3b|
and then watch as the next bunch of people comes in and complains it doesn't look modern enough :p
21:17:28
Shinmera
Anyway, I think the perception of the state of documentation is biased against Lisp. For one, there's so few libraries that the chance of there being multiple libraries for a task is relatively slim. This in turn means the chance for a documented and tested library for a topic to exist is slim as well. Then there's the argument that writing a library in any other language incurs so much effort that
21:17:30
Shinmera
documentation at the end of it seems trivial or almost required because you already spent so much time writing the rest.
21:18:14
Shinmera
Given that, I doubt that, if we compare the state of documentation against other ecosystems and account for the numerical differences, Lisp would stand out as particularly bad.
21:19:11
Shinmera
Either way, complaining about it helps absolutely nobody, so you'd be doing everyone else a favour by doing literally anything else.
21:19:22
|3b|
well, there is probably some difference due to domain of experience, like JS or PHP dev being more likely to be (or at least know) web devs
21:19:46
aeth
Most Lisp libraries are done by one person as a hobby. The well-documented projects are usually either done by more than one person, or done by one person who uses it in their job.
21:20:41
aeth
and, yeah, web dev stuff tends to be well documented because you just put the documentation on the web
21:21:22
aeth
Look at languages that aren't very web-focused. e.g. C and C++ projects often have terrible documentation.
21:26:17
jmercouris
Shinmera: I've never told anyone what to do with their project. I understand your sentiment though.
21:27:02
jmercouris
I think something that's important in life is giving people the benefit of the doubt, and taking things at face value
21:27:54
jmercouris
At any rate, asking the question is not complaining, it is a sincere question that has a very real value
21:28:20
jmercouris
If somebody responded with information such as "because x, y, z" they could either justify it, or explain its cause, and then it might possibly be remedied
21:28:26
Shinmera
The answer to that question is easy: because people don't want to do it. It takes time and effort.
21:29:03
jmercouris
and yet, the laziness of people is probably relatively consistent across languages
21:29:20
jmercouris
That's a literal answer, but not THE answer, you have to abstract one more layer up
21:29:20
p_l
jmercouris: popular libraries in most other communities benefit from economies of scale
21:30:07
jmercouris
p_l: this is true, definitely more people power = more likely to have documentation
21:32:02
jmercouris
Documentation is one of THE most important things in a codebase, and it's probably a cylic thing
21:32:12
jmercouris
You find a library online, has poor documentation, hard to get started with, so you write your own
21:32:44
p_l
jmercouris: and yet documentation is routinely shit on whenever money is on the table, especially by managers telling to write it
21:33:16
jmercouris
p_l: Yeah, that is true, but it is very short sighted to not write good documentation
21:33:36
p_l
it's very, very rare that someone has the right inclinations to make good documentation
21:34:25
scymtym
i think a good basis for this discussion would have been stating what "good" and "bad" entails w.r.t. documentation
21:34:54
p_l
in my professional work, the reality was that documentation was a task in which managers would figuratively shit on devs with "you have 3 days, and I still expect the tasks we planned for those 3 days to be done"
21:36:21
p_l
so... if you want good documentation, either somehow find a way to involve people (opensource programming projects usually don't have lot of success there) or fund it
21:38:03
aeth
jmercouris: If you want people to use Lisp, make something people want to use. Documentation is not the key issue here.
21:38:37
p_l
I can't recall any case that wasn't crazy outlier where good docs happened without money. Getting people is outlier, too
21:39:03
Shinmera
I don't know if my docs qualify as good. I just write them because I fear the wrath of other people.
21:39:20
aeth
What gets people to use a language is that that language solves a problem hat they need solved. People do not use Ruby because of its documentation, they use Ruby because of Rails. etc.
21:39:44
aeth
Sure, Ruby probably has better documentation on average than Common Lisp, but Rails probably came first, and it probably wasn't that well-documented at first.
21:40:21
aeth
p_l: People use Python because it's either the easiest language in the world or the hardest, depending on if you mind the indentation rules or not.
21:41:13
p_l
aeth: I, and many other people I know, started Python because the bundled docs contained full language tutorial AND docs for all the batteries included
21:41:50
Shinmera
Part of what I really liked about Java, too, was that the javadocs are really extensive.
21:41:52
p_l
the language itself was ultimately irrelevant, and tbh later on with less need for crutches I dropped it
21:51:53
fiddlerwoaroof
But, I agree in general: the reason why I got into Python in the first place was that it had excellent documentation for its standard library
21:53:53
fiddlerwoaroof
Anyways, is there any way to signal a style-warning at compile time in a conforming program? Do I just check for the condition I want to enforce and then throw a signal in my macro?
21:54:39
Shinmera
You'll probably want to sub-condition style-warning, since the type does not carry a message, otherwise.
22:14:19
rumbler31
The documentation in most code I've ever run into has been wrong, or misleading, or doesn't cover the topics I know it handles but need to use it for. In lisp, I load the library and play with the functions till I get a live understanding of what's going on and then move forward. At least for CL though, most libraries that are more complicated that might warrant some documentation seem to have it already, even as doc
22:14:19
rumbler31
strings in the function which seems to be enough for me. I've often heard people say "the documentation in this community is bad" and from a sample size of one (myself) I haven't seen it
22:15:43
rumbler31
in the c++ community its almost mandatory that documentation exists, because people think there is one version of c++, when there are really easily 5 or more. You need to know how the library is implemented and what platforms or toolchains support the features it relies on. Less so here
22:17:03
rumbler31
and live exploring some code is what they call prototyping, and they need it because there doesn't exist a live image workflow. So they end up wiring up all the common parts of any program just to exercise the functionality of a library, the burden of which is experienced less so by the cl community (imho, sample size one)
22:17:44
rumbler31
so jmercouris: in good faith, what task do you which to undertake for which you've found documentation lacking?
22:18:57
jmercouris
rumbler31: Well, I didn't think of a particular instance that brought it up, I was just thinking about lisp in general
22:20:09
rumbler31
so you're asking because you've heard it said? or you've experienced it lately but don't necessarily have a specific example? Or a different question, do you think that there is an issue with poor/no documentation?
22:21:35
jmercouris
I think there is definitely an issue, lisp does that have discoverability, but a brief code example would save a lot of time when evaluating libraries
0:22:09
pillton
I have been mostly doing documentation for template-function and specialization-store.
0:40:13
p_l
I wonder if better availability of tooling to deliver applications, and maybe user interface, would help there
0:43:11
stylewarning
Also just having more examples of how to make and button up a Lisp app would be good
0:53:09
_death
(don't really need torch, just wanted a quick look at what kind of issues could a torch bindings writer expect)
0:59:00
sjl
does Lispworks cross compile, or do you need to buy N licenses, one per platform you want to deliver an executable for (even if you only develop on one)?
1:36:15
p_l
stylewarning: I've been toying for some time with idea for "application framework" that would abstract done of important parts which aren't "functional requirements" - like paths to app-specific directories, way to distribute easily native libs with your application, etc
1:38:38
p_l
curiously enough, it makes me think of using logical pathnames, at least as argument to merge-pathname
2:55:01
stylewarning
If it’s a tool to help apps developers make apps, they might feel like this is more wacky lisp stuff
2:57:00
p_l
stylewarning: well, quite possibly the end result will be a set of constants to refer to in code
4:34:52
vsync
is there a quick and easy way to see where quicklisp/asdf thinks a system definition lives?
4:40:38
beach
vtomole: I am still working on the CST-to-AST system as part of Cleavir. That one is going to be used in Second Climacs so that I can compile top-level forms at typing speed and report problems by highlighting text in the buffer.
4:41:23
beach
But I am making great progress. It basically seems to work for correct input. Now I need to put in more error checking and a better way of signaling problems.
5:28:43
shka
well, i will ask about this once i will iron out text that does not seems to have sense
5:29:59
beach
shka: Ask anyway. Some members of a particular language group make systematic mistakes that can be corrected.
5:31:00
shka
here it is: https://sirherrbatka.github.io/cl-data-structures/main.html#2071197507043032227
5:34:34
shka
i will correct spelling, and eventually get grammar strait so if you can just tell me if you actually understand this text... that would be great