<< Back to previous view

[CLJS-2298] REPLs should automatically load user.(cljs|cljc) files at root of Java classpath Created: 04/Aug/17  Updated: 22/Sep/17

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Sameer Rahmani
Resolution: Unresolved Votes: 0
Labels: repl

Approval: Vetted




[CLJS-2265] Library namespaces loading before their dependencies with :none optiizations Created: 20/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Minor
Reporter: Peter Schuck Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: bug, repl


 Description   

Loading ClojureScript module that has library dependencies will fail due to the library namespaces loading before their dependencies.

For example say the have a project with a cljs-time ([com.andrewmcveigh/cljs-time "0.5.0"]) dependency, there modules

:modules {:core {:entries '#{org.modules.transitive}
                 :output-to "out/modules.js"}
          :time {:entries '#{org.modules.time}
                 :output-to "out/time.js"}}

and this code

(ns org.modules.time
  (:require [cljs-time.core :as ct]
            [cljs.loader :as loader]))

(defn display-time [time]
  time)
(ns org.modules.transitive
  (:require [cljs.loader :as loader]))

(loader/load
  :time
  (fn []
    (js/console.log ((resolve 'org.modules.time/display-time) 100))))

When the :time module is loaded the cljs-time.core is loaded, but any dependencies it may have (e.g. cljs-time.core.internal) are loaded afterwards causing the loading of the :time module to fail. After a backoff delay (around 5 seconds) the Google Closure Module Manager retries loading the :time module, this time successfully. Until the :time module is loaded successfully all module loading is subject to this backoff delay.

Demonstration Repo



 Comments   
Comment by David Nolen [ 24/Jul/17 12:33 AM ]

CLJS-2264





[CLJS-2264] Double loading of :cljs-base with :none optimizations Created: 20/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Minor
Reporter: Peter Schuck Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, repl


 Description   

If a project has these modules

:modules {:core {:entries '#{org.modules.core}
                 :output-to "out/modules.js"}
          :menu {:entries '#{org.modules.menu}
                 :output-to "out/menu.js"}}

and this root (org.modules.core) namespace

(ns org.modules.core
  (:require [cljs.loader :as loader]))

(loader/load
  :menu
  (fn [] (js/console.log "Module loaded)))

Then the :cljs-base module will be loaded twice.

The issue is that the loading of :menu causes `:cljs-base` to be loaded as well. Loading the root namespace marks :cljs-base as loaded but only at the end of the file. Under the hood ClojureScript adds

(cljs.loader/set-loaded! :core)

at the end of the :core module. By then it's too late, the :menu module has already started loading.

This is only a problem in the REPL due to the :cljs-base module being loaded through document.write.

Demonstration Repo



 Comments   
Comment by David Nolen [ 24/Jul/17 12:30 AM ]

This is not a bug. Loading modules like this at the top-level means you need to call set-loaded! yourself. In general what is being shown here is an antipattern. If you're just going to immediately load some other module why are you using code splitting?

One simple workaround is to simply put a setTimeout around this top level load.





[CLJS-2241] Multiple requires of Node.js modules in non :nodejs target are not idempotent at the REPL Created: 14/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

Type: Defect Priority: Blocker
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: js-modules, repl

Approval: Vetted

 Description   

Given the following setup:

(require '[cljs.repl :as r])
(require '[cljs.repl.browser :as rb])

(def opts
  {:browser-repl true
   :verbose true
   :npm-deps {"lodash" "4.17.4"}})

(r/repl* (rb/repl-env) opts)

Under a REPL when the target is not the Node.js the following behavior is observed:

(require '["lodash/array" :as lodash-array])

Will succeed the first time. The same require a second time produce the following stack trace:

clojure.lang.ExceptionInfo: No such namespace: module$Users$davidnolen$development$clojure$hello-world$node-modules$lodash$array, could not locate module$Users$davidnolen$development$clojure$hello_world$node_modules$lodash$array.cljs, module$Users$davidnolen$development$clojure$hello_world$node_modules$lodash$array.cljc, or JavaScript providing "module$Users$davidnolen$development$clojure$hello-world$node-modules$lodash$array" at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :root-source-info {:source-type :fragment, :source-form (require (quote ["lodash/array" :as lodash-array]))}, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:690)
	at cljs.analyzer$error.invoke(analyzer.cljc:690)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:692)
	at cljs.analyzer$analyze_deps.invokeStatic(analyzer.cljc:2111)
	at cljs.analyzer$ns_side_effects.invokeStatic(analyzer.cljc:3430)
	at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:3424)
	at cljs.analyzer$analyze_STAR_$fn__2393.invoke(analyzer.cljc:3546)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
	at clojure.core$reduce.invokeStatic(core.clj:6544)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3543)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3569)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:3553)
	at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:3350)
	at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:3498)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3543)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3569)
	at cljs.repl$evaluate_form$fn__6113.invoke(repl.cljc:496)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:496)
	at cljs.repl$eval_cljs.invokeStatic(repl.cljc:616)
	at cljs.repl$eval_cljs.invoke(repl.cljc:603)
	at cljs.repl$repl_STAR_$read_eval_print__6234.invoke(repl.cljc:865)
	at cljs.repl$repl_STAR_$fn__6240$fn__6249.invoke(repl.cljc:905)
	at cljs.repl$repl_STAR_$fn__6240.invoke(repl.cljc:904)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1224)
	at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:841)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:745)
	at user$eval1109.invokeStatic(repl.clj:19)
	at user$eval1109.invoke(repl.clj:19)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$script_opt.invokeStatic(main.clj:335)
	at clojure.main$script_opt.invoke(main.clj:330)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:379)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)


 Comments   
Comment by David Nolen [ 14/Jul/17 5:32 PM ]

fixed https://github.com/clojure/clojurescript/commit/3cf960bb161d8c5fd75b046a4a119d9d0f645409

Comment by Mike Fikes [ 14/Jul/17 8:04 PM ]

Regression for this commit tracked in CLJS-2242





[CLJS-2229] Ensure that new modules work works correctly with REPLs Created: 13/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, repl

Approval: Accepted

 Description   

We need to audit the new features and ensure they work out of the box for various REPLs. Even a cursory glance shows that we don't index node modules.



 Comments   
Comment by David Nolen [ 14/Jul/17 5:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/1d16bc50a33a6e26bebf20b4cac14a2ede373421





[CLJS-2203] REPL is turning on all warnings by default (including :invalid-array-access) Created: 09/Jul/17  Updated: 10/Jul/17  Resolved: 10/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: repl

Attachments: Text File CLJS-2203.patch    
Patch: Code
Approval: Accepted

 Description   

If you fire up a REPL and evaluate (aget #js {:foo 1} "foo") you will see the aget warning. This is because the REPL initialization code assumes that if the compiler options doesn't include warnings, that it should assume the same as :warnings true.



 Comments   
Comment by David Nolen [ 10/Jul/17 4:57 AM ]

fixed https://github.com/clojure/clojurescript/commit/149724bcb28c44bf331ff96c813c0c3aba287b0f





[CLJS-2167] Browser REPL leaves a socket open when it fails to connect to the browser Created: 04/Jul/17  Updated: 05/Jul/17

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

Type: Defect Priority: Minor
Reporter: Timothy Pote Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: browser-repl, repl

Attachments: Text File 001-CLJS-2167.patch    
Patch: Code
Approval: Screened

 Description   

Repro steps:
0. Via an nrepl session
1. Start a browser REPL but do not connect the browser
2. Interrupt the evaluation
3. Start another browser REPL

This will result in the following exception:

java.net.BindException: Address already in use (Bind failed)

Note that, though this is easiest to trigger via an nrepl session, the underlying problem is that the socket server is not being closed in the event of an exception during initialization. You can re-create this in a plain old clojure repl by setting up monospaced}}repl/set-break-handler!{{monospaced prior to starting the browser REPL.



 Comments   
Comment by Timothy Pote [ 04/Jul/17 3:57 PM ]

There are two parts to this patch:
1. Try/Catch the repl to make sure repl-env always gets a chance to clean-up
2. Make BrowserEnv interrupt its threads

Note that this patch is mostly whitespace from re-indenting after wrapping a from in try/catch.





[CLJS-1933] Support CLJS browserless remote REPL from nodejs Created: 09/Feb/17  Updated: 09/Feb/17

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

Type: Enhancement Priority: Minor
Reporter: Mike Longworth Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: enhancement, remote, repl
Environment:

Dev machine OSX - build and Cursive editing and REPL
Remote: RaspberryPI - nodejs
compiler out-files shared between devices with OSXFUSE.



 Description   

I would like to develop clojurescript for a remote nodejs target compiling cljs and running a REPL on my development machine.
https://github.com/clojure/clojurescript/wiki/Remote-REPL suggests a way of doing this however:

!) I haven't managed to get this working.
2) I don't like that the solution relies identical absolute file paths for the compiler output, better to have matching relative paths.

I made a post to request help with this but haven't managed to resolve all the issues:
https://groups.google.com/forum/#!topic/clojurescript/Y4ajOcej8Qo

I have made some progress since the post:
1) I dug into the cljs.repl.node source and found I can stop the node hang I reported by specifying repl-env :debug-port, and get:

Clojure 1.8.0
Debugger listening on port 5002
ClojureScript Node.js REPL server listening on 5001
TypeError: Cannot read property 'nameToPath' of undefined
at Object.goog.require (repl:2:49)
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
TypeError: goog.provide is not a function
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
at TCP.onread (net.js:523:20)
To quit, type: :cljs/quit

This looks like some kind of path problem but I haven't managed to resolve it.

I did some investigations with my original relative-path setup to try and identify the issues:
1) I eliminated absolute paths from the compile output by disabling analysis caching.
2) I ran wireshark on the REPL port and found that absolute paths were being sent by the REPL, this currently makes the relative path option unworkable.

I have many gaps in my knowledge of the REPL operation at the moment and I don't know what the best approach is to getting a good solution for a browserless remote repl setup.



 Comments   
Comment by David Nolen [ 09/Feb/17 12:33 PM ]

It's probably going to be easier to discuss this issue in IRC or Slack first. There's just too many different issues piled into this one. Thanks.





[CLJS-1862] allow NodeJS's NODE_MODULES to be set as a REPL option Created: 28/Nov/16  Updated: 16/Jun/17  Resolved: 16/Jun/17

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

Type: Enhancement Priority: Minor
Reporter: Marc Daya Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: nodejs, repl

Attachments: Text File 65.patch    
Patch: Code

 Description   

The NodeJS REPL that ships with ClojureScript seems to assume that all NodeJS modules are installed globally, or that node's NODE_PATH environment variable is set for the process that starts the REPL (e.g. CIDER). Allowing this to be set as a REPL option make it possible for modules to be installed and made available to the REPL by build tooling, eliminating manual steps by the user and improving repeatability.



 Comments   
Comment by David Nolen [ 28/Nov/16 4:26 PM ]

Thanks. Have you submitted your Clojure CA yet?

Comment by Marc Daya [ 29/Nov/16 2:02 PM ]

It has just been filed.

Comment by David Nolen [ 16/Jun/17 12:17 PM ]

fixed https://github.com/clojure/clojurescript/commit/93657bca464d32e375531f8f8d38e47c88c46fb0





[CLJS-1847] REPL should recognize `clojure.core/load` Created: 11/Nov/16  Updated: 11/Nov/16  Resolved: 11/Nov/16

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

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: repl

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

 Comments   
Comment by António Nuno Monteiro [ 11/Nov/16 10:39 AM ]

Attached patch with fix.

Comment by David Nolen [ 11/Nov/16 12:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/140eb7a7b6213f7dfb5cc01ea5e95c267d510a8b





[CLJS-1803] Use new require capability in REPLs Created: 01/Oct/16  Updated: 01/Oct/16  Resolved: 01/Oct/16

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

Type: Enhancement Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: repl

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

 Description   

With the landing of CLJS-1346, we can port REPLs to use this new functionality instead of the current hacks.



 Comments   
Comment by António Nuno Monteiro [ 01/Oct/16 7:36 AM ]

Attached patch with fix.

Couldn't find any way to break REPL requires. Appreciate it if anyone can give it a spin and report back.

Comment by David Nolen [ 01/Oct/16 1:00 PM ]

fixed https://github.com/clojure/clojurescript/commit/c9c1229b5415b5176f8520e9ca2ba0879158d188





[CLJS-1766] Set literals in REPL end up reified as ArrayMap backed PersistentHashSets. Created: 28/Aug/16  Updated: 28/Aug/16

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

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: repl


 Description   

Entering a set literal in the REPL with more than 8 elements should create a PHM backed set but instead it is array backed.

Example (in REPL):
cljs.user=> (type (.-hash-map #{1 2 3 4 5 6 7 8 9}))
cljs.core/PersistentArrayMap

This means operations such as `get` and `contains?` end up doing long scans and are slower than a user would expect.






[CLJS-1764] Double warning for undeclared Var (REPL only) Created: 26/Aug/16  Updated: 10/Jul/17  Resolved: 10/Jul/17

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

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: repl

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

 Description   

A regression occurred where an undeclared Var in a {{require}}d file causes two diagnostics:

$ more src/foo/core.cljs
(ns foo.core)

(def x 2)

abc
$ rm -rf .cljs_node_repl
$ java -cp cljs-1.9.227.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 52749
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"1.9.227"
cljs.user=> (require 'foo.core)
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
nil
cljs.user=> :cljs/quit
$ rm -rf .cljs_node_repl
$ java -cp cljs-1.9.211.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 56704
To quit, type: :cljs/quit
cljs.user=>  *clojurescript-version*
"1.9.211"
cljs.user=> (require 'foo.core)
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
nil
cljs.user=> :cljs/quit


 Comments   
Comment by David Nolen [ 16/Sep/16 2:04 PM ]

If somebody wants to do a git bisect to sort this one out, that would be awesome

Comment by António Nuno Monteiro [ 07/Nov/16 9:34 AM ]

Only seems to happen at the REPL

Comment by António Nuno Monteiro [ 13/Nov/16 3:47 PM ]

Patch with fix.

This only happened when `require`ing at the REPL. Required namespaces ended up being analyzed twice, once in `cljs.repl` and once in `cljs.closure`. The patch adds wraps compiling these NSes in `cljs.closure` in a `cljs.analyzer/no-warn`.

Comment by David Nolen [ 14/Nov/16 9:24 AM ]

How will this not effect non REPL cases?

Comment by António Nuno Monteiro [ 14/Nov/16 9:29 AM ]

I just now realized that it will probably affect those cases as well, although the `add-dependencies` function seems to (currently) only be used in `cljs.repl`. What other approach should I try? Restrict the cases where we

*analyze-deps*
at the REPL?

Comment by Thomas Heller [ 14/Nov/16 9:51 AM ]

FWIW I don't think this is related to the REPL at all.

I have been seeing doubled warnings for a while now in shadow-build but never bothered to find you why.

abc

(defn x [y] xyz)

Will always warn twice about "xzy" but only once for "abc", doesn't matter if a REPL is involved or not.

Comment by David Nolen [ 08/Jul/17 10:34 AM ]

pretty sure this was resolved when Mike Fikes fixed how we process fn bodies.

Comment by David Nolen [ 08/Jul/17 12:23 PM ]

Can confirm this is still a problem thanks to bump from António, however I do not understand the patch. It doesn't seem safe to suppress warnings here like that.

Comment by David Nolen [ 10/Jul/17 5:35 AM ]

fixed https://github.com/clojure/clojurescript/commit/d2711a2f222e56bdfa698610a59167de4124789d





[CLJS-1648] Getting Source Info into ex-info data for Analysis Errors. Created: 25/May/16  Updated: 16/Jun/17  Resolved: 10/Jun/16

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

Type: Enhancement Priority: Minor
Reporter: Bruce Hauman Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: error-reporting, repl

Attachments: Text File CLJS-1648.patch     Text File CLJS-1648.patch     Text File CLJS-1648.patch     PNG File Screen Shot 2016-05-27 at 8.52.25 AM.png    
Patch: Code

 Description   

With an eye towards improving Analysis Error messages in the REPL.

It would be nice to have the original source of the evaluated form available in the ex-data of the Analysis Error.



 Comments   
Comment by Bruce Hauman [ 25/May/16 12:52 PM ]

This patch is working fine.

Comment by David Nolen [ 26/May/16 3:23 PM ]

Lets not flip the argument order for the optional argument - `env name`.

Comment by Bruce Hauman [ 27/May/16 8:00 AM ]

Gotcha, swapped the args, updated the patch and just for fun uploaded a screenshot of figwheel using this patch.

Comment by Bruce Hauman [ 31/May/16 10:01 AM ]

This is the latest patched against master, lein tests run clean.

Comment by David Nolen [ 10/Jun/16 1:57 PM ]

fixed https://github.com/clojure/clojurescript/commit/ceb307a65aaafda260f0e76d092485932ab88edc





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

Status: Closed
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: Completed Votes: 2
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
Comment by Mike Fikes [ 24/May/16 3:19 PM ]

I tested this with Figwheel [figwheel-sidecar "0.5.0-6"] and it worked properly evaluating multiple forms on a single line, evaluating pasted forms (as in the previous comment), and it properly indicates Unmatched delimiter ) for the case in the description.

Comment by David Nolen [ 09/May/17 8:35 AM ]

fixed https://github.com/clojure/clojurescript/commit/dfadee51fa3fad58b7c4cf7de532e9a10e0f802f

Comment by Mike Fikes [ 09/May/17 9:17 AM ]

Confirmed that this change works downstream with Figwheel (currently at 0.5.10).

Comment by Antonin Hildebrand [ 13/May/17 8:28 AM ]

Just for record, I had to return to previous implementation in Dirac's REPL:
https://github.com/binaryage/dirac/commit/8f50cd17744f33c0f7258ca116e01b9b41243f14

I was unable to track the exact issue down. It has probably something to do with using :reader in repl-opts, which then creates inconsistency between in and current-in (not sure if bind-in? is true in my case).

Also I wonder if nil case should not be properly handled here:
https://github.com/clojure/clojurescript/commit/dfadee51fa3fad58b7c4cf7de532e9a10e0f802f#diff-37f2c970502705d61a0ab1f75ce8fe12R107

And also what if (readers/read-char in) returns nil here?:
https://github.com/clojure/clojurescript/commit/dfadee51fa3fad58b7c4cf7de532e9a10e0f802f#diff-37f2c970502705d61a0ab1f75ce8fe12R109





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

Status: Closed
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 Sun Sep 24 21:41:33 CDT 2017 using JIRA 4.4#649-r158309.