freenode/#lisp - IRC Chatlog
Search
22:31:55
verisimilitude
If not, it would probably be easiest to just download it manually, if one doesn't already have Quicklisp.
22:32:16
no-defun-allowed
Nope, but if it did you wouldn't have to bother with finding them, as quicklisp would load those too.
22:32:44
no-defun-allowed
But, my advice is to install quicklisp anyway, learning CL without it is a bit lonely.
22:36:10
paule32
when starting clisp in console with loading flags, no change to start the application
22:36:23
aeth
UIOP is weird. You (probably) already have an ancient version of UIOP loaded, as a dependency for ASDF, and Quicklisp just "upgrades" UIOP to the newer version with more features. If you look at the verbose output it's recompiling functions when you quickload it, at least in SBCL.
22:36:37
pjb
paule32: now, the problem is that X servers nowadays are configured to not listen to TCP ports.
22:37:06
pjb
paule32: on linux you can use netstat -tnpl|grep 6000 to see if there's a X server listening on port 6000. If not, you won't be able to connect.
22:38:14
paule32
i realize that, but don't remember it, bud good to know, a had a project under the table, which use Xephier
22:38:52
pjb
Adding &key (display 0), I can run (paule-hw::hello-world "127.0.0.1" :display 1) and successfully display this hello world window. ps ax | grep -e 'X.*listen' --> 38628 ?? S 0:00.01 /opt/local/bin/X :1 -listen tcp -iglx
22:39:53
pjb
paule32: notice also that DISPLAY can point to a socket; eg. on macOS, it's DISPLAY=/private/tmp/com.apple.launchd.K3QVcZANEn/org.macports:0
23:26:31
lowryder
sjl: I read your "Path to Common Lisp" post some time ago, prompting me to begin a path towards common lisp. I went quite far without worrying about my editor. But now it's maybe time.
23:27:12
sjl
cool. yeah, if you've gotten comfortable with the language, the next step is the editor
23:27:29
lowryder
sjl: I'm also a vimmer, and I use vlime. I read on HN that you use a terminal in vim as a direct REPL instead of the read-only bit in vlime
23:28:22
lowryder
sjl: I was wondering: if you're modifying a lisp file and you add a function, how do you load just that new function into your running lisp without reloading the whole file?
23:30:05
sjl
Vlime has a function that will compile the current buffer's file, I have it bound to a keystroke https://hg.sr.ht/~sjl/dotfiles/browse/default/vim/vimrc#L2644
23:33:06
sjl
So I end up with my files in splits, with a terminal split and the Vlime repl output split also visible, e.g.: https://i.imgur.com/DuBD6WD.png
23:37:21
sjl
I generally use \e more than \f though, to just "compile current top-level expression" rather than the entire file at once
23:39:34
sjl
Oh, sorry, you said "without loading the whole file". Yeah that's the <localleader>e mapping there.
0:47:27
lowryder
sjl: It took me a moment, but everything became clear when I tracked down your sbcl-vlime command
1:02:06
Xach
margaritamike: there are probably a lot more libraries to save you work in other environments.
1:02:48
Xach
There are libraries to parse html and libraries to fetch web pages in lisp, but not as many choices
1:04:47
no-defun-allowed
writing a scraper in CL would be less time for everyone in the future though
1:04:48
pjb
Once upon a time, web crawling involved a lot of ad-hoc coding. For that, lisp was rather good. Nowadays, we may assume that web pages are more correctly following standard, but that's not entirely the case. So depending on the pages and their age, you may find that lisp is preferable than using other libraries that may be harder to patch.
1:05:42
pjb
On the other hand, nowadays, you would definitely want a complete javascript implementation to be able to crawl random sites correctly.
1:30:53
pjb
But the advantages of lisp can be its inconvenients; it doesn't have all batteries included. When you need to understand and modify the code, it doesn't matter. But if you just to do something predetermined fast, a canned library might be better.
1:31:29
pjb
On the other hand, IME, most of the time when you start with a canned solution, you find that it's defective in a way or another, and you end losing more time trying to make it work to your case than if you had started from scratch with lisp…
1:39:03
no-defun-allowed
you can trust pjb to be a saddist, i hope other people here are more optimistic
1:46:41
pjb
For example, once I had to write a simple program for OpenWRT. Instead of using ecl as I would have, I had to do it in python. But on that processor, python didn't support threads, so the core functionality of this program couldn't be implemented. Alternative python compilers were of no use. Eventually, I wrote it in C, but it would have been done in a fraction of the time in CL with ecl.
4:34:05
aeth
margaritamike: It's not defeatist. The main drawback of CL is that if 95% of your work is already done in a library, it's probably not a CL one
4:38:06
aeth
this is the realistic drawback of any non-top-10 language without a corporate sponser that can pay for replacement libraries
7:57:52
verisimilitude
I've been writing scraping tools for a very particular type of website lately; it's not in a finished and packaged state, though.
7:58:49
verisimilitude
I was using a special patch of DRAKMA for HTTP requests, but I've not yet written code to resume interrupted downloads and other such things; it worked well enough, though.
7:59:14
verisimilitude
I had a HDD failure, however, and so I'm currently just having my Lisp write out files for GNU wget to process, instead.
8:00:18
verisimilitude
I noticed CL-JSON was absurdly slow when processing hundreds of thousands of records, so I've been very lightly working on my own JSON library. I call it JSON-SUCKER, because that implies JSON sucks.
9:00:08
Jachy
Does lisp really need another? =P https://sites.google.com/site/sabraonthehill/home/json-libraries
9:01:33
verisimilitude
I'm going to offer the ability to work directly on the string contents of the JSON, rather than trying to make an efficient parser.
9:01:43
jackdaniel
as of NIH syndrome, I can't say it is reassuring given how many projects which already exist need more people
9:02:32
verisimilitude
This library was thought of because I'd replaced the slow CL-JSON with a simple and efficient string operation; I figured if I could get most of the way there with this approach, generalized, I'd just use it.
9:04:02
verisimilitude
Common Lisp is a language that lets me avoid working with others, which is what I prefer to do.
9:05:53
verisimilitude
Besides, I don't have any other Common Lisp libraries I could be working on, at the moment, sans one that should be rather small.
9:06:14
verisimilitude
Well, that's not true; I've been meaning to start on Gopher software in Common Lisp.
9:09:16
makomo
it's the first step to fare's "Let's consolidate CL libraries" or something like that
9:09:54
jackdaniel
and first thing to consolidate them he declared many maintained libraries "obsolete" in favour of his own uiop thing, I don't think it is the nicest of ways to invite contributors
9:12:07
Jachy
On the flip side, "Once on #haskell, I was asked why I have no large programs to my credit; I replied, 'My problem is that most programs I use already exist.'" Some NIH is acceptable to me.
9:58:50
MichaelRaskin
Re: scraping and JS — well, I do have my code for driving a sandboxed Firefox via Marionette online.
9:59:25
MichaelRaskin
(And then again I prefer to use CL-HTML5 + CSS-Selectors and some custom code to export to text in a way I like it…)
10:01:17
MichaelRaskin
Fare can realistically demand an exception re: other libraries, because ASDF needs to do a lot of things, and having a ton of dependencies for ASDF is somewhat inconvenient… But yes, this does undermine credibility of an effort for greater unification.