### [TNS-32] Accept symbols for 'require' and 'use' inside 'ns' Created: 19/Dec/14  Updated: 19/Dec/14

Status: Open
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Stuart Sierra Assignee: Stuart Sierra Resolution: Unresolved Votes: 0 Labels: None

 Attachments: 0001-TNS-32-handle-non-keyword-clause-heads-in-ns-form.patch Patch: Code and Test

 Description
 clojure.core.ns allows much more syntactic variation than its docstring describes. One example is (ns foo (require bar)) where require should be the keyword :require. As of 0.2.9, tools.namespace silently ignores these forms.

### [TNS-33] Accept symbols for 'require' and 'use' inside 'ns' Created: 19/Dec/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Stuart Sierra Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Attachments: 0001-TNS-33-handle-non-keyword-clause-heads-in-ns-form.patch Patch: Code and Test

 Description
 clojure.core.ns allows much more syntactic variation than its docstring describes. One example is (ns foo (require bar)) where require should be the keyword :require. As of 0.2.9, tools.namespace silently ignores these forms.

 Comments
 Comment by Stuart Sierra [ 19/Dec/14 5:44 PM ] Accidental duplicate of TNS-32

### [TNS-28] Add other Clojure suffixes to clojure.tools.namespace.file/clojure-file? Created: 25/Nov/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Major Reporter: Daniel Compton Assignee: Stuart Sierra Resolution: Duplicate Votes: 0 Labels: None

 Description
 It would be handy to use clojure.tools.namespace.file's clojure-file? function for Clojure files other than vanilla JVM Clojure. I had to copy clojure-file https://github.com/jonase/kibit/blob/master/src/kibit/driver.clj#L17-L22 to be able to let it handle cljs, cljx, and other types of Clojure files. Is it possible to add other extensions to clojure-file? or make a new extended-clojure-file? (or similar name), so that people can reuse the common tooling available in clojure.tools.namespace? I'm happy to put together a patch for whichever direction you'd prefer, making a new function, or extending the existing one (perhaps by adding a new arity with a clj-only? parameter to not break existing code).

 Comments
 Comment by Stuart Sierra [ 19/Dec/14 5:44 PM ] Duplicate of TNS-5

### [TNS-27] c.t.n.repl/refresh fails if :main is specified in project.clj Created: 14/Nov/14  Updated: 19/Dec/14  Resolved: 14/Nov/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Major Reporter: Keisuke Fukuda Assignee: Stuart Sierra Resolution: Declined Votes: 0 Labels: None Environment: [org.clojure/tools.namespace "0.2.7"] REPL-y 0.1.0-beta10 Clojure 1.6.0 Leiningen 2.0.0-preview10 on Java 1.8.0_20 Java HotSpot(TM) 64-Bit Server VM

 Description
 If ":main" is specified in a project.clj file, c.t.n.repl/refresh function fails. Here's the procedure to reproduce the error. $cat ~/.lein/profiles.clj {:user {:dependencies [[org.clojure/tools.namespace "0.2.7"] [spyscope "0.1.3"] [criterium "0.4.1"]] :injections [(require '(clojure.tools.namespace repl find)) (try (require 'spyscope.core) (catch RuntimeException e))] :plugins [ ]}}$ lein new myproj $cd myproj$ lein deps $lein repl nREPL server started on port 52414 REPL-y 0.1.0-beta10 Clojure 1.6.0 Exit: Control+D or (exit) or (quit) Commands: (user/help) Docs: (doc function-name-here) (find-doc "part-of-name-here") Source: (source function-name-here) (user/sourcery function-name-here) Javadoc: (javadoc java-object-or-class-here) Examples from clojuredocs.org: [clojuredocs or cdoc] (user/clojuredocs name-here) (user/clojuredocs "ns-here" "name-here") user=> (use '[clojure.tools.namespace.repl :only (refresh)]) nil user=> (refresh) :reloading (myproj.core myproj.core-test) :ok ;;; ** it works without :main in project.clj$ vi project.clj $cat project.clj (defproject myproj "0.1.0-SNAPSHOT" :description "FIXME: write description" :url "http://example.com/FIXME" :license {:name "Eclipse Public License" :url "http://www.eclipse.org/legal/epl-v10.html"} :main myproj.core :dependencies [[org.clojure/clojure "1.6.0"]])$ lein repl myproj.core=> (use '[clojure.tools.namespace.repl :only (refresh)]) nil myproj.core=> (refresh) :reloading (myproj.core myproj.core-test) :error-while-loading myproj.core-test #

 Comments
 Comment by Stuart Sierra [ 14/Nov/14 10:44 AM ] This is a known Clojure issue: reloading AOT-compiled code doesn't work. :main in Leiningen's project.clj file triggers AOT-compilation. Comment by Keisuke Fukuda [ 14/Nov/14 10:48 AM ] Stuart, I took some time to googling but couldn't reach the information. Sorry for submitting a known issue and thanks for your time.

### [TNS-25] A few doc string typos Created: 09/Sep/14  Updated: 19/Dec/14  Resolved: 19/Sep/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Trivial Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Attachments: tns-25-v1.patch Patch: Code

 Description
 Attached patch corrects a few misspellings in tools.namespace doc strings

 Comments
 Comment by Stuart Sierra [ 19/Sep/14 9:06 AM ] Thanks.

### [TNS-26] Attempted call to clojure.core/alias appears to be shadowed by local binding to name 'alias' Created: 29/Sep/14  Updated: 19/Dec/14  Resolved: 10/Oct/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Major Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Description
 I discovered this while testing a new linter for Eastwood [1], not by running code, so I don't know what the run-time effect of this issue is, but I would guess it would cause an exception to be thrown if the last line of function recover-ns is ever executed. Either that or I am really confused by the last line of function recover-ns

 Comments
 Comment by Stuart Sierra [ 10/Oct/14 9:59 AM ] Good catch, thanks! Fixed in 122e3d1d It didn't throw an exception because the local binding of alias was a symbol. When you invoke a symbol, it behaves like keywords or get, so there was no error.

### [TNS-31] Better error reporting for incorrect :after parameter of refresh Created: 08/Dec/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Petr Gladkikh Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Description
 clojure.tools.namespace.repl/refresh accepts symbol as named parameter :after. If this symbol cannot be resolved then this causes NullPointerException which is not helpful. NullPointerException's stack trace: java.lang.NullPointerException: null repl.clj:99 clojure.tools.namespace.repl/do-refresh repl.clj:142 clojure.tools.namespace.repl/refresh It would be nice to verify result of 'resolve' and throw IllegalArgumentException with appropriate message. The change would be: --- a/src/main/clojure/clojure/tools/namespace/repl.clj +++ b/src/main/clojure/clojure/tools/namespace/repl.clj @@ -96,7 +96,9 @@ (let [result (print-and-return refresh-tracker)] (if (= :ok result) (if after-sym - ((ns-resolve *ns* after-sym)) + (if-let [after-fn (ns-resolve *ns* after-sym)] + (after-fn) + (throw (IllegalArgumentException. (str "Cannot resolve 'after' function " after-sym)))) result) ;; There was an error, recover as much as we can: (do (when-not (or (false? (::unload (meta *ns*))) Used tools.namespace version 0.2.7

 Comments
 Comment by Stuart Sierra [ 19/Dec/14 3:48 PM ] Fix included in release 0.2.8

### [TNS-30] Required namespace outside of list is ignored Created: 08/Dec/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Major Reporter: Petr Gladkikh Assignee: Stuart Sierra Resolution: Not Reproducible Votes: 0 Labels: None

 Description
 I have ns declaration in form (ns current.namespace (require [second.namespace] third.namespace)) If I change file of third.namespace or one of dependencies's files then all affected namespaces are reloaded except current.namespace. If I change declaration to one below then reloading works as expected and current.namespace is reloaded if I make change in same file as above. (ns current.namespace (require [second.namespace] [third.namespace])) ; "third.namespace" is now in vector It looks like that ns parser in tools.namespace is incorrect. Documentation for clojure.core/require says: A libspec is a lib name or a vector containing a lib name followed by options expressed as sequential keywords and arguments. I think that plain namespace name in require clause should be supported by tools.namespace. Used version 0.2.7 of tools.namespace

 Comments
 Comment by Petr Gladkikh [ 08/Dec/14 12:33 PM ] I tried to play more with the reloading and it turns out that the issue is not the syntax of require but the fact that I made changes to the file. The issue is that REPL namespace is not refreshed by clojure.tools.namespace.repl/refresh even if it has file appropriately named for it's namespace and placed among other clj source files. (Explicit modification of 'current.namespace' file or re-evaluation helps, however). Seems that I can not modify or delete the issue after creation. Probably it should be deleted until I diagnose the problem better. Comment by Stuart Sierra [ 12/Dec/14 1:18 PM ] Cannot reproduce.

### [TNS-29] Parse cljs files Created: 07/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Yehonathan Sharvit Assignee: Stuart Sierra Resolution: Declined Votes: 0 Labels: None

 Attachments: 0001-add-file-clojurescript-file-and-find-find-clojurescr.patch     0001-add-file-clojurescript-file-and-find-find-clojurescr.patch Patch: Code

 Description
 Add a function clojure.tools.namespace.find/find-clojurescript-sources-in-dir to parse cljs files

 Comments
 Comment by Yehonathan Sharvit [ 07/Dec/14 10:37 AM ] This would be nice to have this function. For example lein-hiera (https://github.com/greglook/lein-hiera) relies on tools.namespace. Currently lein-hiera is not usable for cljs projects. Comment by Yehonathan Sharvit [ 07/Dec/14 11:19 AM ] a better patch: clj files are also considered as cljs source files Comment by Stuart Sierra [ 08/Dec/14 3:37 PM ] I am reluctant to add anything related to ClojureScript files until a final decision has been made regarding Feature Expressions, which may include alternative file extensions. http://dev.clojure.org/display/design/Feature+Expressions

### [TNS-20] tracker's unload order sometimes incorrect Created: 23/Aug/14  Updated: 02/Oct/14

Status: Open
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Major Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Unresolved Votes: 0 Labels: None

 Attachments: tns-20-v1.patch     tns-20-v2.patch

 Description
 The attached patch contains a new test namespace clojure.tools.namespace.load-unload-order-test that demonstrates the incorrect unload order, if you leave out the proposed fix in file track.clj

 Comments
 Comment by Andy Fingerhut [ 23/Aug/14 3:02 PM ] Patch tns-20-v1.patch contains a test that demonstrates the bug, and contains a proposed fix. Please scrutinize the proposed fix carefully, as I haven't yet convinced myself 100% that it is the right fix. Also adds one more dependency check in dependency_test.clj that I discovered while reviewing those tests, to model my dependency checking tests on. Comment by Andy Fingerhut [ 24/Aug/14 4:52 PM ] I've got some code that checks that the load and unload orders in a tools.namespace tracker are consistent with its dependencies. It is similar to the checks done now in dependencies_test.clj, except it assumes that the dependencies in the tracker are correct and verifies the load and unload orders against those. If you would be interested in a patch that added these checks to tools.namespace, perhaps along with a debug/consistency-check flag that when true causes these checks to be run every time a tracker is updated, let me know. Comment by Stuart Sierra [ 07/Sep/14 11:11 AM ] Thanks for this, Andy. I will need to study it further to convince myself this is the correct behavior. To help, can you describe what the observed problem would be from a user's point of view? We cannot assume that the dependencies in the tracker are always correct. I have demonstrable cases where they are wrong. Usually that takes the form of nonexistent namespaces left in the dependency graph from files that were deleted or had an invalid ns declaration. Comment by Andy Fingerhut [ 07/Sep/14 8:10 PM ] I have not used tools.namespace for the reload workflow that it was originally developed for, so I can't say with certainty what the effect on a user would be, but I can make some guesses that you can probably confirm more quickly than I can. The test case in the patch is one where a few Clojure source files are added to a tracker using function c.t.n.dir/scan-all. No other changes are made to the tracker. At that point, the dependencies are completely correct, and the load order calculated from those dependencies honors them, but the unload order does not. If that tracker were then used in a call to c.t.n.reload/track-reload, track-reload would call remove-lib on a library B before calling remove-lib on a library A, even though A requires or uses B. I guess your question confuses me a bit. Do you believe tools.namespace should only create trackers that have load and unload orders that honor the dependencies? Or is that a wrong assumption I was making from reading the implementation? Comment by Andy Fingerhut [ 08/Sep/14 5:52 PM ] Attaching slightly cleaned up patch tns-20-v2.patch. Identical to tns-20-v1.patch except it avoids copying a function into the new test namespace by adding a dependency on the test namespace where it is defined. Also updates the name of a deftest I had copied but not renamed in v1 of the patch. Comment by Stuart Sierra [ 19/Sep/14 4:19 PM ] I think I'm starting to get a handle on this. There's a lot going on here, and it's been more than two years since I wrote most of this code, so bear with me. At track.clj line 78 we compute the dependency order for unloading namespaces based on the dependency graph (the local deps) as it existed before the most recent set of changes. I believe that this is correct, or at least the correct intention. If we change a file such that its dependencies are different, the order in which we unload namespaces should reflect the namespaces in memory, as they were before we changed the file. When using c.t.n.dir/scan to detect and reload changed files this works correctly, at least most of the time. When adding files to a new tracker for the first time, the old dependency graph is empty, so the unload order is undefined. This is arguably incorrect but effectively meaningless, since those namespaces have not yet been loaded. In release 0.2.6, there was a bad commit which mistakenly changed c.t.n.dir/scan and scan-all to remove the files which have changed before adding them again. As a result, the dependencies of changed files were removed from the tracker's dependency graph before the unload order could be calculated, so unload order was always undefined. I have reverted that change — thanks for drawing my attention to it! Now the unload order should be "correct" after scan or scan-all, except for the first time files are added to the tracker, when unload order is undefined. The tracker doesn't currently have a way to distinguish between changed files which need unload+load and new files which only need load. Even if there were a way to distinguish between new and changed files, we can't be certain that a namespace has not been loaded by other means (e.g. require at the REPL) so it's safest to unload everything before reloading. In general, unload order shouldn't matter at all. Clojure doesn't care when namespaces are removed: the Vars are still referenced from wherever they are used. Comment by Andy Fingerhut [ 20/Sep/14 1:08 PM ] OK, makes sense. Is it already documented anywhere that the unload order is independent of the dependencies after scan-all (and perhaps other calls)? I can create a separate ticket for that if you think it is worth adding such documentation. It sounds like for the application I had in mind, the reverse of the load order is always defined, and is a correct unload order. You are welcome to close this ticket. Comment by Stuart Sierra [ 26/Sep/14 9:44 AM ] After release 0.2.7, which fixed the regression in 0.2.6, :unload order should be correct in all cases except the first time files are added to a new tracker, even with scan-all. I would appreciate it if you can confirm this in your application. It may be possible to fix the new-tracker case too. For example, commit c0b6b93d, currently on the branch TNS-20-fix-initial-unload-order. This works for the tests in your patch. I'm not sure if the same change is needed at track.clj line 104 as well. Comment by Andy Fingerhut [ 02/Oct/14 5:12 PM ] My application right now is very simple compared to the component workflow – simply use dir/scan-all to get the namespaces and their dependencies, and then print them in a particular order consistent with a correct unload order. I'm sorry, but I don't have the interest right now in testing whether the unload order is correct after doing additional operations on the tracker, since it isn't needed in my application. I do have a sanity check in my application that confirms the load order is consistent with the dependencies in my application, and will file a bug if I ever see that trigger anything, but I don't expect there is a bug there. I have switched to using the reverse of the load order in my application for what I believe should always be a correct unload order. I may look into the branch change you made, but it may fall off my radar unless my needs change.

### [TNS-18] Use linear time algorithm to calculate transitive dependencies, instead of current exponential time algorithm Created: 03/Jun/14  Updated: 19/Sep/14  Resolved: 11/Jul/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Major Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Attachments: demo-exponential-algo.patch     linear-time-no-debug.patch Patch: Code

 Description
 The function clojure.tools.namespace.dependency/transitive takes exponential time for cases where there are an exponential number of paths in the DAG (directed acyclic graph) of dependencies. I discovered this when using tools.namespace on the namespaces of project core.typed, where the total time for finding a topological order was several minutes on a reasonably fast machine. It is easy to calculate transitive dependents/dependencies in linear time in the worst case (linear in the number of dependency arcs in the DAG).

 Comments
 Comment by Andy Fingerhut [ 03/Jun/14 3:18 PM ] Patch demo-exponential-algo.patch only adds some test cases that demonstrate the exponential running time of the current algorithm for calculating transitive dependencies. Comment by Andy Fingerhut [ 03/Jun/14 3:20 PM ] Patch linear-time-no-debug.patch is one way to implement transitive dependencies in linear time. It also introduces additional protocol functions, which may not be desired. I am definitely open to suggestions on what kind of change you would like to see here (assuming you want any changes at all). Comment by Stuart Sierra [ 06/Jun/14 10:27 AM ] This is a valuable improvement — thanks, Andy! I don't want to add more methods to the protocol, but I don't see any way to avoid it right now. Ideally, transitive-dependencies would change to take a set, but that breaks backwards-compatibility. I'll give it a week or so to think about naming: transitive-dependencies-of-node-set is too long transitive-dependencies-all ? transitive-dependencies-set ? all-transitive-dependencies ? Comment by Stuart Sierra [ 11/Jul/14 4:42 PM ] Merged on master as of commit 3f946380. Will be in release 0.2.5. New functions are named transitive-dependencies-set and transitive-dependents-set. Comment by Stuart Sierra [ 19/Sep/14 9:08 AM ] Included in release 0.2.6

### [TNS-16] Some tests depend upon Clojure hash for ordering Created: 30/Jan/14  Updated: 19/Sep/14  Resolved: 31/Jan/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Minor Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Attachments: tns-16-v1.diff

 Description
 In particular there are several that do a topological sort of a dependency graph, and compare the returned node sequence against a single node order. In general there are many correct results for a topological sort, and the implementation's return order depends upon Clojure's hash function, recently changed.

 Comments
 Comment by Andy Fingerhut [ 30/Jan/14 9:40 AM ] Patch tns-16-v1.diff is one way to make the tests independent of Clojure's hash function. It implements a topo-check function that determines whether a particular node sequence order is in a valid dependency order, i.e. is a subsequence of at least one topological sorting of the nodes. Comment by Stuart Sierra [ 31/Jan/14 9:09 AM ] Given that the current tests only use very small, hand-drawn graphs, I'm going to go with the brute-force approach for now. But thanks for this patch. I'd like to hold on to it for possible future use with generated graphs and/or test.check. Comment by Stuart Sierra [ 19/Sep/14 9:08 AM ] Included in release 0.2.6

### [TNS-17] doesn't track namespace when ns decl isn't first in file Created: 04/Feb/14  Updated: 19/Sep/14  Resolved: 11/Jul/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Trevor Wennblom Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: bug, enhancement

 Description
 This was first filed for ns-tracker https://github.com/weavejester/ns-tracker/issues/15 but I understand it's more specific to tools.namespace. (I realize this is likely a very low priority, but it'd still be nice to see fixed if possible. Thanks!) It appears ns-tracker tools.namespace will cease following a namespace when there's non-commented content before the namespace declaration. works: ;-begin (ns myproject.core) (println "hi") ;-end untracked — (any of the four possibilities when uncommented, for example): ;-begin 1 ;;; (println "before ns") ;;; (println "loading" *file*) ;;; :abc (ns myproject.core) (println "hi") ;-end

 Comments
 Comment by Stuart Sierra [ 13/Jun/14 4:43 PM ] What's the use case for having a file in which the ns declaration isn't the first non-comment form? Comment by Trevor Wennblom [ 13/Jun/14 5:53 PM ] In the case that triggered the issue for me, it can be useful to see the load-order of files based on the dependencies given in ns for debugging. That is, to print a message before and after the completion of loading the namespace dependencies. I'm not sure how difficult or involved the issue would be to solve. Comment by Andy Fingerhut [ 13/Jun/14 6:42 PM ] Would the :verbose option to require perhaps give you the load-order info you want? Try something like this at a REPL, with a namespace you care about: (require '[clojure.core.typed :as ct] :verbose) In general, I think Stuart's concern would be questions like: How many forms would you expect tools.namespace to skip over before giving up? If it is a fixed number of forms before it gives up, why that number and not some other? If it is based upon some other condition to give up looking for an ns form, what would that condition be? Or would you expect it to be able to find the ns form in the body of a 'when' or 'if' form, and not at the top level? The criteria can easily start to sound kind of arbitrary, and/or complex to implement. Comment by Stuart Sierra [ 11/Jul/14 5:04 PM ] Fixed on master as of commit 3c08b722. This turned out to be an easy change. I wouldn't recommend putting anything before the ns declaration, but it's no longer required to be first. A file could also have multiple ns declarations, although clojure.tools.namespace.track will only look at the first one. Comment by Stuart Sierra [ 19/Sep/14 9:08 AM ] Included in release 0.2.6

### [TNS-19] deps-from-ns-decl can return nil Created: 06/Jun/14  Updated: 19/Sep/14  Resolved: 11/Jul/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Minor Reporter: Ambrose Bonnaire-Sergeant Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Description
 I expect this to be #{}. (ns-parse/deps-from-ns-decl '(ns cljs.core.typed "Internal functions for CLJS" (:refer-clojure :exclude [IFn]) (:require-macros [clojure.core.typed.bootstrap-cljs :as boot]))) ;=> nil

 Comments
 Comment by Stuart Sierra [ 13/Jun/14 5:04 PM ] Fixed in commit e9394727 on Git master. Please verify. Comment by Stuart Sierra [ 11/Jul/14 4:42 PM ] Merged on Git master; will be in 0.2.5 release. Comment by Stuart Sierra [ 19/Sep/14 9:08 AM ] Included in release 0.2.6

### [TNS-24] Broken tracker after mis-named namespace Created: 07/Sep/14  Updated: 11/Sep/14

Status: Open
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Minor Reporter: Stuart Sierra Assignee: Stuart Sierra Resolution: Unresolved Votes: 0 Labels: None

 Description
 A tools.namespace dependency tracker can get into an inconsistent state after attempting to load a file with a namespace declaration that does not match the file's name. Steps to reproduce: In a new Clojure project, create a file foo.clj on the classpath containing the namespace declaration (ns wrong-ns-declaration-for-foo) Then at the REPL: user=> (use 'clojure.tools.namespace.repl) nil user=> (refresh) :reloading (wrong-ns-declaration-for-foo) :error-while-loading wrong-ns-declaration-for-foo # Edit the file foo.clj so that its namespace declaration is correct: (ns foo) But at the REPL, refresh still doesn't work: user=> (refresh) :reloading (foo wrong-ns-declaration-for-foo) :error-while-loading wrong-ns-declaration-for-foo # Since tools.namespace 0.2.5, the workaround is to call clear: user=> (clear) {} user=> (refresh) :reloading (foo) :ok

 Comments
 Comment by Andy Fingerhut [ 11/Sep/14 6:38 PM ] Such files introduce problems for all kinds of tools, not just tools.namespace. I don't know all of the consequences, but two are listed here: https://github.com/jonase/eastwood#check-consistency-of-namespace-and-file-names I have added warnings in Eastwood whenever it finds files like this, and doesn't do any linting checks on any files until such things are corrected.

### [TNS-22] Function ns-file-name makes incorrect call to clojure.string/replace when File/separator is "\\" (e.g. Windows) Created: 24/Aug/14  Updated: 07/Sep/14  Resolved: 07/Sep/14

Status: Closed
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Minor Reporter: Andy Fingerhut Assignee: Stuart Sierra Resolution: Completed Votes: 0 Labels: None

 Attachments: tns-22-v1.patch Patch: Code

 Description
 On Windows, where File/separator is a string consisting of a single backslash character: user=> (require '[clojure.string :as str]) nil ;; This works as expected, because str/replace with second arg being a string handles arbitrary strings as the third arg user=> (str/replace "foo.bar" "." File/separator) "foo\\bar" ;; This gives an exception, because str/replace with second arg being a regex treats backslash characters in third arg specially. user=> (str/replace "foo.bar" #"\." File/separator) StringIndexOutOfBoundsException String index out of range: 1 java.lang.String.charAt (String.java:658) ;; This works as expected, but is more complex than the first alternative above user=> (str/replace "foo.bar" #"\." (str/re-quote-replacement File/separator)) "foo\\bar" I'd recommend using str/replace calls like the first one above when the things you want to replace are constant strings.

 Comments
 Comment by Andy Fingerhut [ 24/Aug/14 7:01 PM ] Patch tns-22-v1.patch changes the only 2 calls to clojure.string/replace I found in tools.namespace that could have their second arg be a constant string rather than a regex. Comment by Stuart Sierra [ 07/Sep/14 11:32 AM ] Thanks. Comment by Stuart Sierra [ 07/Sep/14 2:39 PM ] In release 0.2.6

### [TNS-5] Allow any valid .clj* source file to be parsed/analysed Created: 01/Nov/12  Updated: 07/Sep/14

Status: Open
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Enhancement Priority: Minor Reporter: Max Penet Assignee: Stuart Sierra Resolution: Unresolved Votes: 1 Labels: enhancement

 Attachments: e3cd6d1fa6e0c900bc1086e4a93bbc9cb343a820.patch

 Description

### [TNS-6] Attempt to reload deleted file Created: 14/Dec/12  Updated: 14/Dec/12

Status: Open
Project: tools.namespace
Component/s: None
Affects Version/s: None
Fix Version/s: None

 Type: Defect Priority: Major Reporter: Stuart Sierra Assignee: Stuart Sierra Resolution: Unresolved Votes: 1 Labels: None

 Description
 I can't identify the exact circumstances, but I have seen events where a source code file has been deleted but clojure.tools.namespace.repl/refresh still tries to reload it. Because the file doesn't exist, there's an exception when you try to load it, so you're stuck.

Generated at Sun Dec 21 08:36:14 CST 2014 using JIRA 4.4#649-r158309.