freenode/#lisp - IRC Chatlog
Search
6:33:12
azrazalea2
I've noticed in my sbcl 2.10 from the debian package the *evalhook* global doesn't exist. Is this intended behavior? From what I could tell, *evalhook*/*applyhook* was part of standard but I haven't used it before so might be wrong?
6:36:35
azrazalea2
So I was looking into it because I'm wanting to make a simple bot calculator by accepting lisp forms as a string from a user and then evaluating and returning them. I wanted those hooks so I could validate what types of data they had sent using *evalhook* to check overall types (numbers and symbols only) and *applyhook* to validate the functions
6:36:36
azrazalea2
are in a whitelist. Is the best way to do this going to be to use `read` and then walk the forms myself?
6:40:38
beach
That's one possibility. There are several other options. You could use Eclector to read the form. Then you can control how symbols are created and you can have those symbols interned in the package of your choice.
6:42:39
beach
Or, you can do what I do for SICL bootstrapping. I evaluate the forms relative to a first-class global environments of my choice.
6:47:34
azrazalea2
Well, I might eventually want to get more fancy and allow setting and expansion of local variables but to start with my needs were pretty simple. Just cons based lists with the basic numeric operations (including sqrt, expt, etc etc) as the first element and either another valid list or a numeric value as arguments.
6:48:17
azrazalea2
I can write it myself relatively easily, but I was looking to see if I didn't have ot
13:31:19
VincentVega
Hi! With parachute, how do I run all known tests? `(mapcar #'parachute:test (parachute:package-tests *package*))' includes repeating tests, since some are suites and have children. Hmmm.....
14:26:20
beach
It is going great, thank you. I recently finished adapting the high-level intermediate code to the required structure according to may draft paper on call-site optimization, and I am now thinking about register allocation.
14:58:51
Josh_2
Does someone have an example of how I should structure my tests so they are seperate but I can use asdf to invoke them?
15:04:01
ex_nihilo
Yesterday I posted a question here about what seems to me to be a peculiar interaction between the Slime repl and user i/o with code run from a file. No responses yet; any takers? The question was posted over several messages, but I can repost if someone wants me to.
15:32:46
Josh_2
can I write my own metaclass that would mean all associated methods would only be evaluated conditionally, basically I want to check if I have freed some memory with an associated object before any methods (but one) are called?
15:33:08
Josh_2
theres no point calling something like (identity-keys <object>) if I had previously freed the pointer assocated with <object>
15:54:35
Bike
ex_nihilo: i think that's just slime? dunno. does the same thing happen when you run your lisp from the shell or whatnot?
15:55:17
Bike
Josh_2: I'm not sure I totally understand what you want, but method combinations can do completely arbitrary things.
15:57:08
ex_nihilo
Bike: no. If I run the code as a script from a shell it works as expected, and if I type the code directly into the Slime repl it runs as expected. It is only when I send the code from a Slime buffer to the repl, e.g., with slime-compile-and-run, that the behavior gets wonky.
15:57:33
puchacz
Bike: having read your article, the memory barrier linux kernel article and lispworks doc, I decided that the portable way between lisps of starting a thread with a new lambda or submitting a lambda to a queue to be executed by a long running thread is:
15:59:50
puchacz
(let ((arg1 "something") (arg2 3) (started-p)) (write-barrier) (submit-lambda (lambda () (loop :until started-p) (read-barrier) (use arg1 arg2))))
15:59:55
ex_nihilo
Bike: that's fair enough; what seemed most peculiar to me was that (let ((line (read-line))) (format t "~A~%" line)) works as expected when typed directly into a Slime repl, but not when sent to a Slime repl from a file.
16:01:09
puchacz
as barriers are not about timings, but partial ordering only, so in this "design pattern" when I see started-p as true, I know that other variable was already written.
16:01:34
puchacz
Bike - not really, how would I know that a lock is already available in a lexical variable?
16:02:02
puchacz
(let ((lock (bt:make-lock))) (submit-lambda () ... car I really assume lock is bound) )?
16:03:10
Bike
that's true. i suppose it would need to be a lock used by the actual long living thread
16:03:48
puchacz
yes. also lock protected section does not protect against reodering from before lock acquire to after lock release.
16:04:10
puchacz
and I want to make sure that arg1 arg2 are bound and objects they point to are fully written to memory
16:04:40
puchacz
and in the loop in my example you can add :do (bt:yield) to make the wait less busy
16:04:56
Josh_2
Bike: well I have a lot of various methods for various classes but almost all of them utilize a foreign pointer, I don't want the methods to execute their bodies if the pointer has previously been freed, but I don't want to go and write a :before / :around method for all of them
16:09:12
Bike
i would guess there's not a difference between binding it to T, and binding it to NIL and then setting it to T. i mean, you're kind of implicitly assuming that if the lambda doesn't read started-p = T, it will read started-p = NIL, no?
16:09:28
Bike
and my basic concern is that i suspect the queue just uses locks itself, in which case you don't need to do any synchronization
16:09:46
Bike
like, if submit = (with-lock (queue-lock) (enqueue lambda)) and the work thread does (with-lock (queue-lock) (dequeue))
16:12:22
puchacz
according to the memory-barriers.txt article, lock only ensures the right ordering between acquire and release, so using a lock on dequeuing only does not protect arg1 and arg2. by binding started-p to nil and then setting it to t I am (1) assuming that lisp is designed well enough that started-p will never be a garbage, but indeed it will have nil
16:13:38
puchacz
I did not figure out how to do it with fewer assumptions and not using globally available lock
16:13:41
Bike
if the enqueuing and dequeing work with locks it will be synchronized. When you do the enqueue, queue-lock is released, which gives you a write barrier, so arg1 and arg2 are written.
16:15:28
Bike
i mean if you're at this level, then for the lambda to observe started-p = nil, you are assuming some kind of write barrier anyway, right?
16:17:06
puchacz
lispworks docs is very careful about the objects that are pointed by these lexical variables. they are not guaranteed to be fully committed
16:18:18
puchacz
they say though that a variable will have any of the values it ever had, never garbage or something else
16:20:56
josrr
ex_nihilo: out of curiosity I tried it in SLY; this is what happened: https://www.rufina.link/video/vokoscreen-2021-02-20_10-12-49.mp4