freenode/#sbcl - IRC Chatlog
Search
20:25:05
Xach
Hi friends. A lot of the failures on http://report.quicklisp.org/2018-04-24/failure-report.html relate to changes in the latest git version of sbcl. (a few don't, like gendl, cl-openid, and cl-sendmail)
20:25:35
Xach
Once more I'm faced with thinking about whether the libraries are doing naughty things or not. Any guidance would be quite welcome.
20:29:22
Xach
like, i think people agree to the sbcl contract of "if you use internal stuff expect breakage" and are willing to risk it for stuff they can't do any other way
20:30:13
Xach
I think http://report.quicklisp.org/2018-04-24/failure-report/universal-config.html#universal-config hits another issue
20:33:07
Shinmera
Xach: I don't think that mandates (setf r-m-a) to be a function rather than a setf-expander.
20:33:53
Shinmera
I am, because in order to do what I seem to be doing there I'd have to apply it to "unroll" the list of subscripts.
20:35:00
dougk_
oh, sorry, you're using row-major-index. i misread. you want to compute the index, i thought there was a standard thing for that
20:35:19
specbot
array-row-major-index: http://www.lispworks.com/reference/HyperSpec/Body/f_ar_row.htm
20:35:25
dougk_
but you're just computing an index to use with row-major-aref so why can't you just apply ?
20:44:29
DemolitionMan
dougk_: I need a working sbcl with gsll to use them with prometheus and grafana :)
20:53:49
dougk_
my fear is that the fix for %compiler-defun is to add a fourth arg to the call in the hu.whatever code, which kind of messes things up in a different way for something else I want to change. I feel I should write to them and ask why they need to call it
20:54:47
dougk_
I almost suspect that the effect of what they want is (proclaim '(ftype function yourname)) just to avoid an "undefined" warning or something
21:07:43
jeosol
I just posed a question over at #lisp channel but since it's sbcl specific, I figure this channel is more specific.
21:09:09
jeosol
basically, i have X threads performing some calculations, one of them acquires a lock on a resource and an error results while perform calculation and the lock is not released and the other threads wait. I run on the shell and would like to just kill that thread so the others can proceed
21:12:33
pkhuong
jeosol: use a call-with-foo wrapper to always release the lock when you unwind / return.
21:13:13
pkhuong
that still leaves you open to broken state invariants if you crash in the middle of a critical section.
21:15:15
jeosol
thanks for the suggestions. What you are suggesting is to have some kind of combination of a wrapper and unwind-protect to ensure things are released in the event of an error?
21:16:42
jeosol
Not sure by what you mean by SBCL or CL specific. The calculations are still being performed within CL/SBCL. It's just that in some instances, I get inconsistent arithmetic operations (.e.g, (/ 0 0)) and others I am still catching
21:20:06
dougk_
jeosol: pkhuong means, I think, that it's not a good idea to expect that externally killing a thread that had a acquired a lock is either (1) possible at all; (2) going to release the lock; (3) not mess up invariants guarded by the lock; (4) going to anything sane whatsoever. Some combination of that.
21:21:42
jeosol
dougk_: thanks. I guess that is why I have not been able to resolve it when things stall. I will try to modify workflow to use the suggestion above.
21:21:51
dougk_
Xach: i'm able to compile hu.dwim.delico with a hack I just pushed; will write them an email
21:23:15
pkhuong
the immediate solution to the problem is to use (call-)with-foo; using scoped mutex locks is a standard good idea, not just in CL.
21:24:38
pkhuong
and the solution is to avoid (large) critical sections that can fail... which is also language-independent advice.
21:34:37
jeosol
pkhoung: thanks for the suggestions. Did some quick googling and I understand better.
21:36:00
jeosol
if anyone is interested on scoped locks I found this somewhat old paper (though in C++) http://www.cs.wustl.edu/~schmidt/PDF/ScopedLocking.pdf