This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (10)
- # bangalore-clj (2)
- # beginners (2)
- # clara (3)
- # cljs-dev (39)
- # clojars (2)
- # clojure (21)
- # clojure-art (2)
- # clojure-austin (6)
- # clojure-berlin (5)
- # clojure-gamedev (4)
- # clojure-russia (1)
- # clojure-spec (15)
- # clojure-uk (4)
- # clojurescript (4)
- # cursive (3)
- # datomic (1)
- # events (5)
- # flambo (6)
- # hoplon (55)
- # jobs (20)
- # lein-figwheel (2)
- # om (8)
- # onyx (1)
- # pedestal (4)
- # perun (3)
- # protorepl (2)
- # re-frame (8)
- # reagent (48)
- # slack-help (1)
- # specter (5)
- # yada (46)
Is there a way to prevent infinite loop in self-host
For instance, on the browser evaluating
(range) stucks forever...
Is there a way to pass a timeout?
@dnolen what about
could it help to wrap
eval-str with a
(with-redefs [*print-length* 1000] …) block?
@viebel a wild idea: you could wrap whole expression in a go-like macro, then do a deep code walk and decorate all looping constructs with some interruptible helper code - this won’t solve it for general case (e.g. external js fn looping forever), but could solve it for code entered by klipse users
very wild @darwin
My main use case is for the klipse plugin where code is evaluated “instantaneously” (i.e. after 20 msec of inactivity)
And the user is typing (range 10)
but between range and 10 there is a small delay (> 20 msec), so the evaluation is triggered with (range)
and the browser gets stuck
thinking about it more, you have full control over self-host cljs compiler in klipse, could hack cljs compiler to emit interruptible code
another idea is to do execution in a webworker and instrument it from the main frame (e.g kill it after some time)
Yeah, the webworker is probably the cleanest solution
yes, but there are other challenges, once you allow people to interact with DOM and other browser APIs you have another huge issue
I think first idea has a merit to it too, it could be as easy as tweaking how recur/loop gets emitted, with each recur you would call a callback, which would “sleep” for other browser code to run and then check a flag and throw if program should be interrupted
and by “sleep” I mean running callbacks from a parallel even loop you would manage by hand
Yeah. But my main concern is the
I just tried to wrap
eval-str with a
(with-redefs [*print-length* 1000] …) and it worked
(str …) of the
Range type calls
@darwin I know that there are other obvious cases...
Now that I found a solution to my main pain, I’m available to solve the real issue
What is the way to tweak how recur/loop gets emitted?
I mean - how do I do it technically?
another (#3) idea: use an iframe instead of webworker, it will have full DOM access and clean “environment” as a bonus, with proper content-origin you will be able to drive it from your klipse app
> how do I do it technically? I can’t help here, have never done anything similar, just throwing ideas around
@darwin is it possible to kill an iframe that is stuck in an infinite loop?