freenode/lisp - IRC Chatlog
Search
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.
8:19:56
beach
muresanvlad_: Some people write applications that never allocate any memory. In that case the garbage collector is never alled.
8:23:48
trittweiler
muresanvlad_, In a C program, how often do you think malloc is called on average?
8:24:50
muresanvlad_
it's quite different. The GC can be called when you create a new variable,string or function
8:26:38
trittweiler
Doesn't it depend on the way the program is written? A C program doing a lot of text processing, would call malloc quite often, no?
8:27:19
muresanvlad_
right, I just wanted to know for an average small program how often the gc can be called once per second
8:28:25
loke
Major collections (the ones that take time) could be run every few minutes, even for large applciations. In some cases, several hours can pass.
8:29:24
loke
Usually, GC's split their heap into generations, since it has been shown that most memory gets collected almost instantaneously.
8:30:04
beach
muresanvlad_: There are small programs that don't allocate any memory, and there are others that allocate a lot. It is completely meaningless to talk about averages here.
8:30:07
loke
So memory gets allocated on the young generation, and after a while gets “promoted”. The old generation is only GC'ed when it fills up, which means that it can take quite some time becfore the majority of memory is ever GC'ed
8:31:54
loke
If you really want to, you can always look at the GC in a specific implementation (and its settings) and then write a program that directly targets theat particular GC implementation.
8:32:26
loke
Just like you can write programs that directly target the malloc implementation in a given operating system and trigger some naty behaviour (like fragmentation)
8:36:09
aeth
If you need to avoid the GC in part of your program or profile exactly where/when the allocations happen/etc., SBCL ime is the easiest for this.
8:37:43
aeth
Murii__: It's pretty easy to see exactly how much or how little the GC is called in SBCL
8:37:55
beach
Murii__: There is a very deep result in the GC literature which is that as the size of your heap increases compared to the working set of your application, the cost of garbage collection as a fraction of your application execution time goes to 0.
8:39:07
beach
Murii__: People also imagine that manual memory management like malloc()/free() is cheaper than tracing garbage collection. That is not true at all.
8:40:31
beach
Murii__: The amount of work that malloc()/free() have to do is definitely not negligible. Do you know how an implementation of those works?
8:41:33
aeth
Murii__: You can see a lot about what's going on in SBCL's GC with the stuff mentioned here (and its profiling stuff in general): http://www.sbcl.org/manual/#Garbage-Collection
8:41:47
beach
Murii__: I just implemented a version of Doug Lea's algorithm, and I studied Paul Wilson's excellent survey paper about memory allocators.
8:42:57
beach
Murii__: Again you are confused. The algorithms used by typical malloc()/free() implementations can be learned without writing a single line of C code. They general purpose allocator techniques that work in any language.
8:45:20
loke
I also have experience in the subject. More so than the average programmer at the very least. I think a lot of people on this channel know what they are talking about.
8:46:39
lieven
Murii__: go read up on the boehm-gc stuff for example. There are cases of existing C programs speeding up when linked with it. It basically replaces the stdlib's malloc/free pair with its own where free is a nop and does gc.
8:53:14
schweers`
beach: a garbage collecting system would not necessarily have anything directly resembling malloc, right?
8:54:00
loke
schweers: if you define malloc() as being “something that provides free memory to whomever requests it” then it must have. :-)
8:54:40
jackdaniel
ACTION waits for infinite-memory-systems, where no garbage needs to be freed or collected :-)
8:55:57
schweers`
Murii__: quite possible, I wanted to know if it must be this way for all garbage collectors. I assumed that this is not the case, and beach confirmed this.
8:56:00
loke
jackdaniel: Some application are written as such. I've seen very memory hugly Java applications running with the GC turned off. They just restart the application every night (effectively creating a single GC :-) )
8:56:34
schweers`
loke: my bias tells me that this is stupid. is there a legitimate reason for this?
8:57:07
loke
(they don't actually turn it off, but they set the heap size to a ridiculous size, and tune it so that it only GC's if it absolutely needs to, which is never)
8:57:12
beach
schweers`: A good Common Lisp system will have a "nursery", i.e. a generation of youngest objects from which new objects are allocated. And they use a copying collector, so that allocation is just a matter of testing and incrementing a pointer.
8:58:10
loke
schweers: well, they are essentially working around limitations in the software. As the customer dataset grew, they needed more and more heap. Once they git a heap size of around 50 GB or more, the full GC took so long that it blocked transactions in the system.
8:58:17
beach
schweers`: Whereas the standard implementation of malloc() has to look for a best-fit block among all free blocks in memory.
8:58:56
loke
beach: No need to even test the pointer. An allocation is literally just an ADD instruction.
8:59:10
schweers`
loke: my question may sound naive but ... why not have smaller collections on the way? As far as I know, the jvm has this as default behavior anyway, right?
8:59:21
loke
beach: You set of a readonly memory page after the free heap, and then you'll get a SEGV when you hit it, which can trigger a minor GC
9:00:55
loke
beach: That's the reason why you can't load the JVM into SBCL wusing FFI. Both of them tries to handle SEGV and they confuse eachother leading to a crash.