freenode/#lisp - IRC Chatlog
Search
19:52:20
jeosol
what is the better way to run a lisp code remotely?. I will be away soon, but I can ssh to the linux box. I don't have executables created right now. I am aware of nohup but then I need to create some script? non?
19:53:03
jeosol
I wanted to see if you guys do something special, or the old, normal linux way is okay
19:56:13
JuanDaugherty
i think ur supposed to just be able to use shebang in sbcl but I've never tried it
20:03:14
jeosol
ok, I need to give this some thought since I'm still testing. for now, I just create new functions (to test new options) and just run it after loading.
21:27:15
jmercouris
jeosol: https://www.common-lisp.net/project/slime/doc/html/Connecting-to-a-remote-lisp.html
23:44:52
White_Flame
jeosol: you can also just ssh -X into your remote box and launch emacs, to bring up a remote environment on your screen
23:45:31
White_Flame
while it's simple, it can hurt though if you drop your connection at an inopportune time
23:50:24
equwal
I used to do remote lisp programming to keep logs of IRC. TRAMP works really well once you get it setup and move past the learning cure: https://www.emacswiki.org/emacs/TrampMode. Also, there is no input lag, and no risk of data loss.
23:59:02
equwal
The basic idea is it seamlessly sets up your buffers to download, be edited, and upload when you do normal file-open and save commands in emacs.
3:16:01
loke
So odd... It was pointed out on #emacs that CLHS doesn't seem to specify what the default comparator for FIND is. I know it's EQL, but where does it actually say so in the CLHS?
3:19:00
Lord_Nightmare
has anyone considered making a more updated spec for common lisp than the 1988 one? how would one even create a commitee to do that?
3:19:24
specbot
Satisfying a One-Argument Test: http://www.lispworks.com/reference/HyperSpec/Body/17_bb.htm
4:07:20
aeth
Lord_Nightmare: You would have to get the authors of the various implementations to agree to it. At a bare minimum, SBCL and CCL. Either not participating would probably be enough to kill the effort. Of course, the other implementations (especially ECL, SICL, and Clasp, which are all active on IRC) should ideally also participate.
4:08:15
aeth
You don't need a new *ANSI standard*. It's not like any of us use the ANSI standard, anyway. We all use the Hyperspec and/or a freely available draft of the ANSI standard.
4:09:53
aeth
What you'd probably get are threads, unicode, paths, and whatever's currently trendy (pure functional programming? lazy lists? async/await?).
4:32:47
beach
Lord_Nightmare: Designing a language is tricky business. We are lucky that Common Lisp was designed by a collection of very smart and highly knowledgeable people, in contrast to some of the languages in use today. It is very easy to get it wrong if you are not a language expert and a compiler expert.
4:32:48
beach
Furthermore, Common Lisp has a commercial aspect to it as well. There are the two major vendors that need to be taken into account. So a committee would have to include representatives for them as well as people who know their technical details and their computing history.
4:36:58
aeth
The free implementations that I know of are SBCL, CCL, ECL, ABCL, CLISP, CMUCL, MKCL, Clasp, Mezzano (I think it uses SBCL for bootstrapping and then runs its own implementation in the OS itself), and SICL. The commercial implementations that I know of are Allegro, LispWorks, Scieneer, Genera, and mocl.
4:38:26
aeth
If you wanted to be complete you could probably get away with just having representatives from SBCL, CCL, ECL, ABCL, CLISP, CMUCL, Clasp, SICL, Allegro, and LispWorks. That's 10: 8 FOSS and 2 commercial.
4:40:56
aeth
Those are just the implementations. There are other interests that would want representation, too.
5:01:43
krwq
is there a way to get function/macro signature without defining a macro wrapper for defining them? (external library ok)
5:04:30
beach
It is not required to return anything useful. The commercial vendors would be very upset if you could get the source of their compiler for instance.
5:07:02
krwq
beach: do you perhaps know of any library which would tell me compiler/interpreter infered types for the arguments as well?
5:22:40
Lord_Nightmare
from what i gather, genera/opengenera seems pretty dead, except for a few people keeping it alive by keeping lisp machines running, and to some extent emulation
5:23:14
Lord_Nightmare
the only reason symbolics still exists in any form i think is because of some long government maintenance contracts, and i don't see those lasting more than another decade at most
5:24:03
Lord_Nightmare
hopefully once the money dries up, whoever owns it will dump what's left of it open under some sort of usable open source license
5:24:59
jeosol
btw, good discussion regarding CL above. One of my friends, not a CL user told me why I used a dead language ... lol
5:26:26
Lord_Nightmare
my issue with common lisp is from hearing that a lot of the idiosyncrasies in it date to incompatible implementations amongs the early lisp machines and forks in the late 70s/early 80s, which is why there are five subtly different equality comparison operators
5:27:00
Lord_Nightmare
and at least some of 'common lisp' was gathering up a lot of these differences and canonizing many of them in a giant common framework
5:27:55
Lord_Nightmare
its been 30 years since 1988, and much of the reasoning for having redundancy like there originally was is no longer really relevant anymore
5:28:42
Lord_Nightmare
I'm not advocating chopping anythig out of the language, but deprecating some stuff might be a good idea, for later removal
5:30:02
Lord_Nightmare
nothing, right now. I'd rather use a lisp implementation like SBCL that I can use on a modern system without having to jump through hoops
5:31:00
Lord_Nightmare
my issue with genera is i think it should probably be lumped in the 'dead' pile, at least very soon
5:31:39
beach
Lord_Nightmare: I don't quite understand what your agenda is. Why do you care about things you don't use?
5:33:36
Lord_Nightmare
anyway, I'm cluttering up the channel with my harebrained schemes, i'll shut up now.
5:34:22
beach
Lord_Nightmare: Ideas about updating the standard pop up here regularly, usually by relative newbies who know nothing about language design, compiler technology, garbage collection technology, synchronization primitives, or anything. They also know nothing about standardization, and the complex social interactions required to create a language like Common Lisp.
6:03:29
beach
Lord_Nightmare: I do have a project to update the standard, but it is VERY modest compared to most suggestions I see here: https://github.com/robert-strandh/Well-Specified-Common-Lisp
6:05:06
Lord_Nightmare
my idea was more to 'mark the less useful leftovers which could probably be removed', since i understand the roots of common lisp are over 50 years old and a lot of people poured a lot of thought into it
6:06:18
beach
Lord_Nightmare: That would be one of the less useful modifications. People can just ignore them. They only pose problems to people implementing Common Lisp systems.