freenode/#lisp - IRC Chatlog
Search
8:02:46
phoe
pillton: correct, it has a mechanism for that, you can use its functions inside macros.
8:31:19
beach
jdz: Sadly, many of the discussions here involve using Common Lisp to do unsafe things such as accessing memory directly.
8:40:52
beach
Well, since most people think Common Lisp is irrelevant as well, then one might as well use a language that is unsafe by design, rather than trying to twist an otherwise safe language into doing unsafe things.
8:51:09
p_l
beach: I'd argue that since our computational substrate doesn't provide some higher abstraction by itself, we should strive to give all the power we can while simultaneously making the easy problems trivial, hard problems easy, and insane problems doable, for the end user of the tool
8:56:14
jackdaniel
while direct memory access may be considered unsafe it is only a minor bug which may be avoided (that is a case for using language which manage memory for the programmer, I'm all for that and we have a lot of mainstream languages doing that too) - avoiding this class of problems doesn't make a language safe though
8:57:14
beach
So you are saying, Common Lisp is unsafe anyway, so we might as well go the extra mile to make it totally useless?
8:58:38
jackdaniel
what I'm saying is that trading "unsafe" language to Common Lisp is trading one "unsafe" language to another "unsafe" language, so it is not a very good argument to switch
9:00:20
jackdaniel
(for instance Java doesn't have direct memory access but many people seem to dislike it and software written in it still has bugs which lead to unsafe behavior, yet some of bloat could be mitigated with macro abstraction which it lacks)
9:01:48
p_l
beach: CL is "safer" in the default state. Essentially giving "sane defaults" while at the same time providing ways to expand *when needed*
9:02:01
otwieracz
Do you have any ideas for examples how to handle file upload properly with clack/ningle?
9:02:17
p_l
beach: someone nicely described "low-level language" as one where issues irrelevant to problem being solved are important :)
9:05:10
aeth
And I'd love not to have to use CFFI at all. If we add window, input, sound, and 3D graphics to the next version of the standard, I guess that'll get rid of a lot of reasons to use it.
9:08:42
jackdaniel
/another kind of safety improvement would be static typing which some could argue (me included) would be an overkill for CL/
9:09:45
aeth
Because CL has sequence-generic and number-generic things, declaring types for sequences/arrays and numbers makes a big difference.
9:10:10
aeth
I think the compiler can normally tell what type is expected by what functions are being used on it, although I could be wrong.
9:10:46
aeth
I do wish it was standard that type declarations checked and aren't assumed when safety != 0, though
9:11:05
jackdaniel
aeth: by static typing I don't mean declarations but rather some enforcement from the compiler to make various informations certain and available at compilation time
9:11:51
aeth
jackdaniel: It could be done, there would just need to be a way to handle functions differently.
9:12:49
aeth
fiddlerwoaroof_: pretty much, you'd just wrap a function foo with (the return-type (foo ...)) or (the (values return-type-0 return-type-1) (foo ...))
9:12:57
beach
jackdaniel: So what they do with languages that enforce static typing is to make the type system so restrictive that it severely hinders programmer productivity.
9:14:29
fiddlerwoaroof_
minion: memo for Xach: I added a new Makefile to the repository that should work without any external dependencies. Just Make -f Makefile.minimal mkapp
9:20:20
aeth
jackdaniel: I think the future is a mix between static and dynamic typing within one language
9:20:53
aeth
Languages are slowly inching their way in that direction in different ways (of course, Lisp has always had type declarations)
9:21:09
pillton
beach: The discussion I had with aeth regarding unsafe array access was to eliminate redundant index checks.
9:21:52
Shinmera
beach: I don't /want/ to do unsafe stuff, but I do want to get things done. Sometimes getting things done requires doing unsafe stuff. The benefit is that others won't have to anymore once someone has made a library that does it for them.
9:21:57
aeth
Ideally I can do one check before tons of arefs instead of one check on every aref. Very niche situation to need so many arefs, pretty much just matrix*
9:23:24
Shinmera
jackdaniel: In actuality tech is moving more like a dry cleaner. The same stuff being done over and over.
9:24:05
beach
Shinmera: I totally agree. Stuff like that should be isolated behind some Common Lisp abstraction layer. The reason I uttered something in the first place, is that the discussions here are disproportionately about unsafe stuff, suggesting that not only do we hide stuff behind abstractions, but many applications programmers do it as a normal part of the application.
9:24:13
p_l
language standards take time, and just for graphics in one API family there were significant changes since 2000. Let's see, around 5 big changes?
9:24:16
jackdaniel
Shinmera: if it were just that. as an example: websockets are build on top of ton of abstractions, which when peeked at the bottom is build on top of sockets
9:24:59
pillton
beach: Ok. I don't really classify this problem as wanting to make CL programs unsafe.
9:25:01
aeth
beach: It might just be because the FFI stuff is harder and less obvious than native Lisp stuff
9:25:20
beach
I am also very surprised that we still continue to claim that some features must be IN THE STANDARD in order to be useful, even though many people use languages without any standard whatsoever, and many others use libraries that are not part of the standard of the programming language they have chosen to use.
9:26:08
p_l
beach: true. Personally, I'd rather see more cooperation on the CDR front, as essentially "enshrining" common library code
9:27:01
aeth
p_l: If SBCL, CCL, and ECL developers can agree on some language extension (CDR or otherwise), it will reach most users, at least in #lisp
9:27:13
aeth
But if SBCL, CCL, and ECL developers ignore it, then it probably won't reach too many people
9:27:42
aeth
SBCL, CCl, ECL, ABCL, CLISP, CMUCL, MKCL, Clasp, and Mezzano are the only living FOSS implementations I could find.
9:28:06
p_l
aeth: I think a bunch of people would have to band to work on implementation of such extensions, because frankly speaking I think current set of developers already has enough on their plate
9:29:34
aeth
MKCL is the only one I can't access through Roswell to run tests on. Well, I can't access Clasp, either, because it has a compilation error, but I can't see that compilation error from Roswell, I just see a Lisp stack trace saying the subprocess make failed
9:30:56
jackdaniel
and roswell has more issues with its abstraction, it was impossible for me to add hand-compiled implementation to it (even if it was sbcl)
9:31:01
aeth
I don't use Roswell to get access of CL in general, I use it to get access of CLs that would be hard to get access to manually.
9:31:53
aeth
p_l: that would help... what really is needed in general is some way to run tests on SBCL, CCL, ECL, ABCL, CLISP, CMUCL, and Clasp.
9:34:35
aeth
There might be an alternative that does SLIME + testing, I'd love to know, I'd consider using it instead if it's more stable
9:35:36
Cymew
A community vote system really would be a nice thing to have, integrated in ql and in github.
9:37:35
aeth
p_l: and, yeah, it would have to take a lot of coordination (and perhaps one person who knows the internals of several implementations) to get some extensions
9:38:31
Cymew
aeth: "This system is good and alive -> 5 stars" or "This system is not maintained -> 1 star".
9:39:34
Cymew
I actually started to read the quicklisp code to figure out how to add features to it, then a paying job came around...
9:39:53
aeth
I would say with the majority of libraries I have to read the code because there's essentially 0 documentation
9:40:11
Cymew
aeth: I think the exact details could be discussed, but yes I agree that is very important.
9:41:02
aeth
Rating based on documentation would be tricky, though, because do you reset it if it adds documentation?
9:41:08
jackdaniel
that sounds like a way for people who don't do to say people who do what to do ;-)
9:41:10
beach
Cymew: I think a voting system is an excellent idea. That's the main problem with finding something appropriate, namely knowing the opinions of others.
9:42:09
aeth
jackdaniel: but if there's a 5-star library with 1-star documentation, that gives someone looking for something to do a good suggestion of what they can do
9:42:27
aeth
I don't think people are going to reject documentation patches unless they're incorrect
9:45:37
aeth
On the subject of documentation, how many public classes have :documentation filled out?
9:47:34
Shinmera
ACTION can't wait for the inevitable drama of people getting upset over their libraries getting low ratings
9:48:55
Shinmera
So you won't find (:documentation "foo") in my code, but that doesn't mean it isn't documented
10:54:40
shaftoe
there's a voting system already... the library downloads per month or how many other libraries depend on it
10:55:16
shaftoe
you might give split-sequence 1 star, but it's one of the more heavily depended on and downloaded libs
10:58:00
shaftoe
one example where a popularity/rating system would be handy, was with graph libraries... there's at least 3 on quicklisp with various licenses and featuresets
11:04:46
shaftoe
likewise, updated for 2018 comparison articles would be good material for any aspiring lisp blogger
11:06:11
Shinmera
Benchmarking is the same problem in any language. The tricky bit is finding representative samples.
11:06:51
ebzzry
In SLIME, is there a way to muffle the warnings caused by `sb-ext:*on-package-variance*`
11:22:13
aeth
There are some libraries I don't like that I download anyway because they're dependencies of dependencies of dependencies of dependencies.
11:22:52
aeth
As in, I would never actually select those libraries for a project. I won't name names, though.
11:30:52
aeth
Nah, most of the libraries I don't like were from the 2000-2010 era of Lisp, possibly without even having any updates since that time. Usually unpatched for years. Probably abandoned.
11:38:05
aeth
I'll name one because it's fairly common and because it's bad and because I've criticized it here before. A bit newer than the time range I was talking about. cl-json.
11:40:23
aeth
Unless its documentation is wrong. I'll test it out since I already have it downloaded
11:41:23
aeth
Nope, nil produces "null". Someone honestly sat down and thought generating "null" was a more reasonable default than "false".
12:29:16
schweers
quick question: given a file-descriptor (on linux), can I create a common lisp file-stream?
13:31:26
tazjin
has anyone here used this JWT/JOSE implementation? https://github.com/fukamachi/jose
13:39:42
Cymew
I do note a distinct shortage of docs, as per our earlier conversation in this channel. Have seen worse, though.
13:44:47
tazjin
Cymew: assuming you're responding to me, the docs shortage isn't really the problem (API is very straightforward), it just doesn't quite seem to do what I expect :P
13:48:52
Cymew
That would be a problem. Myself, I have not used it. The author have written quite a few systems, and not all easy to use. I suspect overexposure to ruby, considering how some of the web stuff looks like.
14:44:23
Shinmera
For those using the Plaster paste service <http://plaster.tymoon.eu> there's now an Emacs extension for added convenience. https://github.com/Shirakumo/plaster#emacs-integration
15:33:07
sjl
flip214: good news: the vlime author appears to be fine https://twitter.com/l04m33/status/951091266187493376
15:45:27
crsc
Nice to know. I installed vlime yesterday and it works fine for me. Hopefully he will come back in the future.
16:22:13
makomo
hah, hi there :D, i watched your (old?) stream about running lisp on an arudino and solving some PE problems
16:22:21
sjl
I generally use my initials for more tech-related things like github/irc and longer names for non tech stuff like photos