This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-12
Channels
- # aleph (3)
- # announcements (15)
- # architecture (6)
- # babashka (35)
- # babashka-sci-dev (10)
- # biff (5)
- # calva (9)
- # cherry (1)
- # cider (44)
- # clj-kondo (31)
- # cljfx (1)
- # clojure (108)
- # clojure-europe (32)
- # clojure-norway (12)
- # clojurescript (15)
- # conjure (3)
- # cursive (8)
- # datahike (1)
- # datalevin (19)
- # datascript (1)
- # datomic (59)
- # emacs (4)
- # graphql (3)
- # jobs (1)
- # luminus (6)
- # meander (9)
- # membrane (45)
- # nbb (67)
- # off-topic (16)
- # portal (3)
- # remote-jobs (1)
- # scittle (8)
- # shadow-cljs (46)
- # test-check (7)
- # tools-deps (5)
- # vim (63)
- # web-security (11)
- # xtdb (15)
I found that load-string
is available from within a Scittle script, which makes it easy to expose evaluation of multi-line user entered ClojureScript from a single HTML file. Really nice!! (That is: for a lazy tinkerer like myself who really likes not needing an actual build/compilation step, if at all possible... 🙂 )
I am finding though that errors that might occur lack position information, which is unfortunate. This seems the case for both reader/parser errors as well as exceptions thrown during evaluation.
E.g.
(load-string "
(defn f [x]
(inc n)) ; clearly an error (line 3, form starts at column 3)
")
results in #error {:message Could not resolve symbol: n, :data {:type :sci/error, :line nil, :column nil, :file nil, :phase analysis}}
.
As Sci is clearly perfectly capable of providing position information, as any error in the Scittle script itself reveals, I wonder why :line
and :column
get a nil
value here. I'm guessing I just don't fully appreciate yet how exactly Sci is jumping through the hoops to facilitate it all, specifically w.r.t. the 'ctx' and 'current-namespace'.
So I wonder if there is some low hanging fruit that I am missing that might help getting to the error's line and column number within the user entered string after all. Or is this fundamental to what is(n't) possible in a Scittle script? Thanks a lot!
(The Clojure REPL provides position information:
user=> (load-string "
(defn f [x]
(inc n)) ; clearly an error (line 3, form starts at column 3)
")
Syntax error compiling at (REPL:3:3).
Unable to resolve symbol: n in this context
user=>
For this case Babashka does not however, which makes me wonder again if this is fundamental to Sci after all... :thinking_face:
Scanning the source code I do wonder whether a lack of explicit position logic in the catch
clause in sci.impl.parser/parseNext
might have something to do with it, but I am sure that there's a lot more to it.
Interestingly, the following works nicely in Babashka:
user=> (load-string "
(throw (ex-info \"!\" {}))
")
clojure.lang.ExceptionInfo: ! [at <repl>:3:4]
user=>
but the same load-string
expression in Scittle does not yield a useful stacktrace with relevant position info.
Any pointers are very much appreciated!)@jurjanpaul502 Yes, this is possible and I'm not sure why this doesn't happen properly. You could also try scittle.core.eval_string
@U04V15CAJ Thank you so much for your quick response (even this late in the day)!
I found eval-string
in the source code and wanted to invoke that, because it would be the perfect 'strange loop' 😉 but I was so far failing to actually invoke it from within a Scittle script. Attempting to invoke it directly by name yields an Could not resolve symbol: eval-string
error. An attempt to require scittle.core
yields a Could not find namespace scittle.core
error. But I just found the string scittle.core.eval_string
inside scittle.js and tried invoking it like (js/scittle.core.eval_string s)
and that does give me the same result as the load-string
invocation! Thanks! Even so, at the moment I still get a nil
value for both :line
and :column
.
it might be something in SCI where there's a check if *file*
is bound, so doing (binding [*file* ...] (load-string ..))
might also help. If that doesn't, issue welcome
Tried it by binding *file*
to the string "buffer"
and that caused the :file
entry in the error map to get the value "buffer"
, but kept the values of the :line
and :column
entries nil
. At some other time I will pursue your suggestion that SCI might need something specific, by reading some more of the source code. 🙂
👍 Yes, I will file an issue when I find some time. 🙂 [mentioned in other reply that] Invoking (js/scittle.core.eval_string s) yields the same result as (load-string s), so also no line number and/or column. I’ll construct a minimal Scittle page that reproduces this.