<< Back to previous view

[CLJS-1572] REPL doesn't give error for expressions with too many right parentheses. Created: 15/Feb/16  Updated: 22/Feb/16

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.7.228
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: J David Eisenberg Assignee: David Nolen
Resolution: Unresolved Votes: 1
Labels: repl
Environment:

Fedora 23, java version "1.8.0_40", javac 1.8.0_40, clojure 1.7.0


Attachments: Text File CLJS-1572.patch    
Patch: Code

 Description   

I was expecting an error message from this; using [org.clojure/clojurescript "1.7.228"]; the Clojure REPL does produce an error.

To quit, type: :cljs/quit
cljs.user=> (+ 3 5)))))
8


 Comments   
Comment by Mike Fikes [ 16/Feb/16 12:49 PM ]

A suggestion on a strategy to fix this: Make the ClojureScript REPL sequentially process all of the forms it can read on a line, just like the Clojure REPL does:

user=> 3 (+ 3 5) 7
3
8
7

If this is done, then the fix for this ticket will fall out “for free” and the ClojureScript REPL will error when it hits a form that appears to start with ).

Comment by Mike Fikes [ 21/Feb/16 4:01 PM ]

The REPL code is very close to working the way mentioned in the previous comment. It currently does not only because this line

https://github.com/clojure/clojurescript/blob/c59e957f6230c07e7a228070dd8eb393d5b8ce40/src/main/clojure/cljs/repl.cljc#L100

invokes code that causes a new PushbackReader to wrap things (discarding things):

https://github.com/clojure/clojurescript/blob/c59e957f6230c07e7a228070dd8eb393d5b8ce40/src/main/clojure/cljs/repl.cljc#L773-L775

If you either let the PushbackReader once and let that reader fn close over it, or otherwise comment out things so that a new PushbackReader is not created for each loop / recur, you will see that the code behaves as suggested in the previous comment, having the desired effect.

The only thing I see that would need to be additionally sorted out with such a patch is being a little more clever about when need-prompt evaluates to true, etc. (otherwise polishing thing so there are no missed corner cases).

Comment by Mike Fikes [ 21/Feb/16 11:02 PM ]

Attached a patch that, in essence makes the ClojureScript REPL behave like the Clojure REPL with respect to multiple items on a line and with respect to detecting malformed input. The patch is fairly straightforward, but could use some testing. I've tried things like

cljs.user=> 3_    ; where _ here is a space

cljs.user=> 3 4 5

cljs.user=> 3)

cljs.user=> 3))

cljs.user=> 3 [4
5]

cljs.user=> (let [x 1]
(+ 1 "a"))         ;; testing to make sure line numbers are right

All the above is looking good to me.

Here is the commit comment:

Take extra care to preserve the state of in so that anything beyond
the first form remains for reading. This fundamentally makes the
ClojureScript REPL behave like the Clojure REPL. In particular, it
allows entering multiple forms on a single line (which will be evaluated
serially). It also means that if malformed input lies beyond the initial
form, it will be read and will cause an exception (just like in the
Clojure REPL).

The bulk of the complexity in this commit has to do with the case where
a new line-numbering reader is established, so that errors in forms
can be associated with line numbers, starting with line 1 being the
first line of the form. This requires a little extra handling because
the source-logging-push-back-reader introduces an extra 1-character
buffer which must be transferred back to the original (pre-bound) in,
otherwise things like an unmatched extra paren right after a well-formed
form won't be detected (as the paren would be in the 1-char buffer and
discarded.)

Also, a Java PushbackReader needs to be eliminated, as it causes things
to fail to behave like the Clojure REPL.

Comment by Mike Fikes [ 21/Feb/16 11:14 PM ]

Note that one extremely useful thing this patch enables is pasting of multiple forms into a ClojureScript REPL!

This fails if pasted using the current cljs.jar, but works with the patch applied:

(def a 1)

(def b 2)

(def c (+ a b))

c




[CLJS-1553] browser repl "EOF while reading string" when evaluating symbol "enable-console-print!" Created: 28/Jan/16  Updated: 05/Mar/16  Resolved: 05/Mar/16

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: 1.7.228
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Scott Bale Assignee: Scott Bale
Resolution: Declined Votes: 0
Labels: repl
Environment:

On client side: Chrome browser (47.0.2526.111) On Mac OS 10.10.5 Yosemite

On server side:

  • Amazon EC2 instance running amazon linux

java -version
openjdk version "1.8.0_65"
OpenJDK Runtime Environment (build 1.8.0_65-b17)
OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)


Attachments: GZip Archive cljs-hello-world.tar.gz    

 Description   

Just playing around in the browser repl, running through the CLJS quickstart, I happened upon this. I crashed the repl by attempting to evaluate enable-console-print!.

Below is output of my repl. As you can see, I can doc, source, or even invoke the function, but if I try to simply evaluate the symbol, the repl crashes with a Java runtime exception. (I was expecting the repl to output a toString representation of the enable-console-print! function object, as it would for any other symbol that resolves to a function.)

I've attached a .tar.gz file of my project, but I excluded the cljs.jar file from the root. (The IP address in core.cljs is the public IP address of the ec2 instance I was using.)

The command I used to start the repl is:

java -cp cljs.jar:src clojure.main repl.clj

REPL output:

cljs.user=> (doc enable-console-print!)
-------------------------
cljs.core/enable-console-print!
([])
  Set *print-fn* to console.log
nil
cljs.user=> (source enable-console-print!)
(defn enable-console-print!
  "Set *print-fn* to console.log"
  []
  (set! *print-newline* false)
  (set! *print-fn*
    (fn [& args]
      (.apply (.-log js/console) js/console (into-array args))))
  (set! *print-err-fn*
    (fn [& args]
      (.apply (.-error js/console) js/console (into-array args))))
  nil)
nil
cljs.user=> (enable-console-print!)
nil
cljs.user=> enable-console-print!
Exception in thread "Thread-138" java.lang.RuntimeException: EOF while reading string
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.LispReader$StringReader.invoke(LispReader.java:525)
        at clojure.lang.LispReader.read(LispReader.java:263)
        at clojure.lang.LispReader.readDelimitedList(LispReader.java:1200)
        at clojure.lang.LispReader$MapReader.invoke(LispReader.java:1158)
        at clojure.lang.LispReader.read(LispReader.java:263)
        at clojure.lang.LispReader.read(LispReader.java:196)
        at clojure.lang.LispReader.read(LispReader.java:185)
        at clojure.lang.RT.readString(RT.java:1821)
        at clojure.lang.RT.readString(RT.java:1816)
        at clojure.core$read_string.invoke(core.clj:3663)
        at cljs.repl.server$dispatch_request.invoke(server.clj:148)
        at cljs.repl.server$handle_connection.invoke(server.clj:157)
        at cljs.repl.server$server_loop$fn__5056.invoke(server.clj:167)
        at clojure.core$binding_conveyor_fn$fn__4444.invoke(core.clj:1916)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.lang.Thread.run(Thread.java:745)


 Comments   
Comment by Mike Fikes [ 31/Jan/16 8:34 PM ]

I tried reproducing with the attached cljs-hello-world.tar.gz, revising the IP address to be localhost, and running everything on my local Mac with Chrome 48.0.2564.97, and I was unable to repro.

Perhaps, since this involved a network connection between AWS and your local Mac, the connection was closed during the phase when it was reading the response? In other words, I wonder if this is reproducible in general or was just a connectivity outage.

Comment by Scott Bale [ 08/Feb/16 8:33 PM ]

Thanks for checking on that Mike. I'm also unable to reproduce the crash if I run my example locally on a macbook pro (Chrome 48.0.2564.97 also; Mac's Java 8 build 1.8.0_65-b17).

However, the original behavior I'm seeing is not sporadic; it is reproducible 100% of the time. I was able to reproduce it again just now. So I guess the next step would be for me to build a debug version of cljs.jar which provides some insight into what is tripping up the LispReader$StringReader.

Comment by David Nolen [ 12/Feb/16 2:29 PM ]

Patch welcome for this one, not really use case we ever had in mind for Browser REPL.

Comment by Scott Bale [ 05/Mar/16 1:16 PM ]

I've tinkered around with this enough to satisfy myself that it is nothing to do with cljs. Sorry for the distraction.

Fwiw: I have a small clj test script that reads the body of a POST (similar to cljs browser repl env). If I run that within an ec2 instance, and send a POST from outside of ec2, then about half the time a large chunk of the post body is truncated. Length is reported correctly in header, but a bunch of characters are just missing. Openjdk bug? >shrug<





[CLJS-1008] Browser repl doesn't find upstream dependencies. Created: 05/Feb/15  Updated: 07/Feb/15  Resolved: 07/Feb/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Brian Jenkins Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: repl
Environment:

MacOS 10.9.5
Running a repl through cider & emacs.

project.clj attached.


Attachments: Text File fix-upstream-deps-from-repl.patch     File project.clj    
Patch: Code

 Description   

I found that when running piggieback from the repl like this:

```clojure
(defn piggieback-repl []
(cemerick.piggieback/cljs-repl :repl-env (cljs.repl.browser/repl-env :port 9000)) )
```

get-upstream-deps doesn't find anything.

This prevents me from being able to use piggieback with Om's new cljsjs dependency on React.

Comment on get-upstream-deps says

```
Should be run in the main thread. If
not, pass (java.lang.ClassLoader/getSystemClassLoader) to use the
system classloader.
```

I guess the repl isn't the main thread?



 Comments   
Comment by David Nolen [ 07/Feb/15 10:05 PM ]

fix https://github.com/clojure/clojurescript/commit/f311ebd121bf2385efcfba6f7bfb07251cf812f1





[CLJS-1006] Implicit dependency of clojure.browser.repl on cljs.repl Created: 05/Feb/15  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Murphy McMahon Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: repl

Attachments: Text File 1006.patch    

 Description   

The clojure.browser.repl/connect function monkey patches goog.require with :optimizations :none. The substituted version uses goog.basePath-relative URLs to retrieve assets, one of which is cljs.repl (the repl-connection callback returns "goog.require('cljs.repl')"). Therefore clojure.browser.repl has an implicit dependency on cljs.repl, which will not be able to be located if the :output-dir of application compilation (eg cljsbuild) and that passed to cljs.repl/repl* are not one in the same.



 Comments   
Comment by David Nolen [ 05/Feb/15 7:13 AM ]

fixed https://github.com/clojure/clojurescript/commit/576fd1c70933fc91180c769cb639c262b7c79071





[CLJS-1005] Browser REPL creates "out" directory no matter what Created: 05/Feb/15  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Murphy McMahon Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: repl

Attachments: Text File 1005.patch    

 Description   

Steps to reproduce:

$ lein new mies test-brepl
$ cd test-brepl
$ sed -i 's/:output-dir "out"/:output-dir "not-out"/' scripts/brepl.clj
$ ./scripts/brepl # <Ctrl-c> <Ctrl-c>
$ ls -la

Expected: Only "not-out" and ".repl-0.0-XXXX" directories should be created for compiled javascript.

Actual: "out" directory is also created.



 Comments   
Comment by David Nolen [ 05/Feb/15 7:13 AM ]

fixed https://github.com/clojure/clojurescript/commit/4bd3e6563d36871b1c5e603c35fc7bb4a9b68eb2





[CLJS-887] cljs.repl.browser does not serve css by default Created: 17/Nov/14  Updated: 12/Feb/15  Resolved: 12/Feb/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Christopher Shea Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: repl
Environment:

*


Attachments: File cljs-browser-repl-serve-css.diff    
Patch: Code

 Description   

A browser repl's server serves js, cljs, map, and html files by default, but not css.



 Comments   
Comment by John Chijioke [ 10/Dec/14 2:05 AM ]

What is css needed for from the repl?

Comment by Christopher Shea [ 10/Dec/14 9:13 AM ]

cljs.repl.browser/send-static can already send css with the appropriate MIME type, so this just seems like a minor oversight.

If you follow the Using the browser as an Evaluation Environment section of the ClojureScript wiki and have a css file linked from your html page, it will not be served, which can make it more difficult to work on your project (you won't see the effects of changing an element's class, e.g.).

As a workaround, I've been doing this when setting up my repl:

(server/dispatch-on :get
  (fn [{:keys [path]} _ _] (.endsWith path ".css"))
  browser/send-static)

It's not that my interactions with the repl require the css, it's the browser that's connected to the repl that does.

Comment by David Nolen [ 12/Feb/15 10:41 AM ]

fixed https://github.com/clojure/clojurescript/commit/43d0bb1e99aa2f23f1e7cf5004d347b6e6a70ff0





[CLJS-749] Changing ClojureScript versions may break browser REPL Created: 14/Jan/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Osbert Feng Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: repl

Attachments: Text File cljs-749.patch    
Patch: Code

 Description   

By default in a project using ClojureScript, the .repl/ directory is used to store compiled CLJS for the browser REPL. This compilation is skipped if the directory already exists (src/clj/cljs/repl/browser.clj:205:create-client-js-file). However, it really should be re-compiled if the version of ClojureScript is upgraded/changed or else the browser REPL may fail with some very difficult to interpret error messages. At the moment, it seems people simply know to delete .repl/ when changing ClojureScript versions (https://groups.google.com/forum/#!topic/clojure/C-H4gSWIUwc) but this can be extremely tough on new users when they upgrade ClojureScript for the first time.

We could append clojurescript-version to the directory name. Unfortunate that it generates a new directory each time a new version of CLJS/BrowserREPL combo is used, but shoudl not occur too often and makes it very explicit that :working-dir should be tied to CLJS version. Also developers utilizing ClojureScript though lein checkouts will still have to delete .repl/ since clojurescript-verion is only set by script/build.

See attached patch.

NOTE: I do not have a CA agreement on file, but one is in the mail.

NOTE: Sorry if this is bad form, but as a preceding commit, in cases where clojurescript-version is unbound I changed (clojurescript-version) to return "" instead of ". This is so that when clojurescript-version is unbound .repl/ will be used instead of .repl-./ Let me know if this should be considered as a separate issue.

Alternatively, we could remove the exists check entirely, and instead recompile client.js every time (repl-env) is called at the cost of slowing down browser REPL startup.



 Comments   
Comment by David Nolen [ 02/Dec/14 5:48 AM ]

Seems like a fine fix but this patch needs to be rebased to master. Thanks.

Comment by Osbert Feng [ 02/Dec/14 12:42 PM ]

Please see the updated patch. Thanks!

Comment by David Nolen [ 02/Dec/14 12:48 PM ]

Fixed https://github.com/clojure/clojurescript/commit/50cc86ff3c4c39181a198a4f9be788c149eaae00
https://github.com/clojure/clojurescript/commit/85773301cf12541a053890643d1d943a6ed361de
https://github.com/clojure/clojurescript/commit/d25aea69697cca2ef5fa8b9a6f7e4fd089685ace

Comment by David Nolen [ 02/Dec/14 12:49 PM ]

In the future squashed patches are preferred. Thanks for your contribution!





Generated at Sat Apr 30 15:47:40 CDT 2016 using JIRA 4.4#649-r158309.