clojure-dev

Issues: https://clojure.atlassian.net/browse/CLJ | Guide: https://insideclojure.org/2015/05/01/contributing-clojure/
ghadi 2020-02-25T00:00:21.065600Z

imagine the API didn't exist

ghadi 2020-02-25T00:00:28.065900Z

what would you do?

2020-02-25T00:00:41.066100Z

what I do today

2020-02-25T00:00:51.066400Z

I don't know that I use it ever

2020-02-25T00:01:31.067600Z

but that doesn't mean it is good ergonomics to be like "type code into your repl and it just runs forever even if you made a mistake"

ghadi 2020-02-25T00:01:43.067900Z

that's not what I said

ghadi 2020-02-25T00:01:55.068500Z

let it run in the background, and return input control

2020-02-25T00:02:04.068900Z

no one wants that

ghadi 2020-02-25T00:02:28.069700Z

it's worse to give the people the illusion that they can stop bad loops 100% of the time without hitting the things that the Thread.stop() warns about

2020-02-25T00:02:29.069800Z

the next question in #beginners is going to be "why is clojure eating my cpu, ram, and filesystem?"

dpsutton 2020-02-25T00:05:48.073500Z

Isn’t it better to let them try and if it doesn’t work they can kill the process just as if they didn’t have the tool?

2020-02-25T00:06:43.075100Z

I am not saying Thread.stop is good, I am saying basically everything you would reason about by analogy (setting aside if the analogy is good, os processes, ec2 instances, etc) has some kind of kill switch and that is a very useful usability affordance of those systems, and it is unfortunate that we, as part of the jvm community, are unable to offer a useful feature

2020-02-25T00:10:10.078Z

It seems that interactive Clojure dev systems have a reasonably common use of Thread.stop today, from recent discussion here. I can see why -- it is expedient, and despite the warnings, often does "what you want", in a sharp-knife-that-sometimes-cuts-you kind of way. If Thread.stop is removed from a future JVM completely, it does seem that having a different approach in common use would be useful. I doubt many people want a Clojure compiler that forces interrupt status checks into all loops, though.

2020-02-25T01:32:19.079Z

our mystery seems to be resolved, but i tried using test.chuck anyway -- imagination expander :) thanks for pointing it out -- i think i may have other uses for it!

👍 1
cfleming 2020-02-25T08:53:33.083500Z

The alternative for a lot of cases to Thread.stop() is basically kill your REPL process and start again.

cfleming 2020-02-25T08:54:40.084800Z

If that’s not good, then I think at least offering Thread.stop() as an option is ok - it’s (AFAICT) always worked for me, and saved me many REPL restarts. If my app does get funky after using it, I’m still going to be restarting my process anyway.

orestis 2020-02-25T12:47:49.086100Z

For anyone following along, who like me was clueless about Thread.stop(), I found this: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html (linked from the Thread.stop() API docs)

borkdude 2020-02-25T21:21:33.091800Z

in sci I have something called :realize-max which sets a hard limit on the length of sequences being realized. of course this comes with significant overhead, but for sandboxing things like 4clojure puzzles I guess it's fine.

user=> (sci/eval-string "(range)" {:realize-max 10})
Error printing return value (ExceptionInfo) at sci.impl.max-or-throw/bottom$fn (max_or_throw.cljc:8).
Maximum number of elements realized: 10
(0 1 2 3 4 5 6 7 8 user=>