libera/#sicl - IRC Chatlog
Search
2:41:53
moon-child
2. Finaliser does _not_ get passed the object being finalised, but rather another object, which you specify at the same time as you specify the finaliser
2:42:45
moon-child
3. Finaliser must be specified as a symbol which names a function, rather than the function itself
2:43:55
hayley
I think you could implement it with weak hash tables, when the table is allowed to have just a weak reference to the key or value.
2:44:46
hayley
We keep a list of "another object"s from #2, and a table of "another object" -> finalised object which has weak values - okay.
2:45:15
hayley
One point I've heard (outside Common Lisp) is that finalizers tend to run concurrently with application code, so you better not think your program is sequential anymore.
2:46:05
hayley
For reasons that I have likely expressed in the past, I would believe this is user error to an extent.
2:47:07
moon-child
the main use case I can imagine for finalisers is freeing system resources when coexisting with some unix. Should be no problems there. What else do people use them for?
3:13:45
mfiano
Regarding my previous statement from the other day: I decided to stop using Common Lisp as my primary language, at least for a while. A bunch of small things contributed to this decision, mostly social issues internal to the community, but some personal issues as well. I'll still be available for consulting my (often bad) opinions and (hopefully better) advice for beginners on IRC, though.
3:46:10
hayley
@moon-child: Well, the video I was thinking of was about concurrency. And all the RAII weenies appeared in the comments, because they'd have destructors run immediately and sequentially.
3:53:29
hayley
To an extent I've wondered what could happen if we could use running out of external resources to pace concurrent GC, like we have with running out of memory.
3:55:07
moon-child
(and how many of those external resources are actually cleaned up with gc finalisers rather than, say, with with-macros?)
3:55:38
hayley
I run out of GPU memory often enough, as eazy-opencl insists GPU memory should be managed with finalisers, and I hardly cons on the CPU, so I rarely GC.
3:56:01
hayley
Reminds me that my backlog includes writing a manually-managed fork of eazy-opencl. Call it hard-opencl or something.
5:07:17
adlai|alphanum
mfiano: I'm sorry that social issues have pushed you away from CL... please consider that they might only be indicative of a group of people, rather than the language itself?
5:08:00
adlai|alphanum
CL does give you more power to work alone than most languages, so naturally, less collaborative folks end up disproportionately represented.
5:08:40
adlai|alphanum
meanwhile I have a question about the GC conversations - what is the distinction between 'parallel' and 'concurrent' ?
5:09:35
mfiano
I would rather not discuss the social issues, as I don't want to offend a group of people, but I will say that some of the social issues are integrated tightly into the language, such as for instance, the reliance on a central repository (Quicklisp) and the refusal of most authors to version their software, or the tools necessary to have developers themselves manage versioned dependencies.
5:09:35
adlai|alphanum
I'd treated these two words as pretty much synonymous, although it seems from rereading conversations here that there is a significant distinction that I've missed.
5:12:32
mfiano
No, in short, languages are tools, and no tool is good at everything, despite being general-purpose; their exists more specialized tools for a particular problem domain, and the problem domains I'm interested in have recently took a sharp turn.
5:12:48
adlai|alphanum
ACTION has also taken quite a hiatus from CL (and programming in general) in recent years, mainly due to having accumulated an unmanageable hairball of code from years when his personal goal was simply to have no day without git commits... without any metric for progress towards stability of the product.
5:13:14
adlai|alphanum
however, I still keep reading, and do plan on resuming work in CL once I have a better idea of how to aim my work.
5:14:34
beach
adlai|alphanum: I think "concurrent" means that it works while the mutator is running, and "parallel" means that more than one thread is doing the GC.
5:24:37
moon-child
adlai|alphanum: I agree with beach's definitions here. In a more general sense, I think 'concurrent' means 'at the same time', while 'parallel' means 'independent'. While the terminology is somewhat loose, you can see a tenuous connection here: a concurrent gc works concurrently with an application; works at the same time as it, but is not independent, and usually fine-grained communication between
5:24:39
moon-child
the two is required in order to maintain correctness. While parallel gc attempts to find aspects of the garbage collection process which are independent of one another (and then tries to profit by executing these in different concurrency domains)
5:36:10
mfiano
Concurrency is about competetition with external factors. Parallelism is about cooperation. This is how I like to think of it, as described by Steele.
5:38:05
mfiano
I can link to the talk that you have probably seen before, if you'd like. IIRC it is quite long.
5:38:47
moon-child
I know 'how (not) to talk about parallelism', but I don't remember his talking about concurrency there
5:39:55
moon-child
in any case, this is why I say the terminology is somewhat loose. In broad terms, I think everyone agrees concurrency is 'the dangerous one', though (though it is also interesting that joe calls it 'the one you actually want'--because one concurrency domain can fail while another survives)
5:41:28
moon-child
(which being said I also think of eg reentrancy issues as concurrency issues, which do not have those desirable attributes)
5:47:01
hayley
Joe also claimed that concurrency is a natural part of modelling, as many actions in the real world have concurrency.