[LOGIC-107] Less dependencies for non-dev environments? Created: 22/Jan/13 Updated: 22/Jan/13 Resolved: 22/Jan/13 |
|
| Status: | Resolved |
| Project: | core.logic |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Enhancement | Priority: | Minor |
| Reporter: | Jeroen van Dijk | Assignee: | David Nolen |
| Resolution: | Completed | Votes: | 0 |
| Labels: | feedback | ||
| Description |
|
I am considering using core.logic, but after looking into its dependencies I am hesitating. Should I really pull in datomic and google closure if I just want to use core.logic in a normal Clojure project? |
| Comments |
| Comment by Jeroen van Dijk [ 22/Jan/13 10:28 AM ] |
|
Sorry I think I spoke to soon. When I include core.logic in my project it doesn't pull in other dependencies, I have been misled by the project.clj of core.logic which declares Google closure and datomic as dependencies. Apologies for the disturbance and thanks for a great library. |
| Comment by David Nolen [ 22/Jan/13 10:37 AM ] |
|
Yes the project.clj is for development purposes only. It's not used to resolve dependencies. |
[CLJ-1207] Importing a class that does not exist fails to report the name of the class that did not exist Created: 29/Apr/13 Updated: 10/May/13 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.5 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Major |
| Reporter: | Howard Lewis Ship | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | feedback | ||
| Environment: |
1.5.1, OS X |
||
| Waiting On: | Howard Lewis Ship |
| Description |
|
Pop quiz: What Java class is missing from the classpath? java.lang.NoClassDefFoundError: Could not initialize class com.annadaletech.nexus.util.logging__init
at java.lang.Class.forName0 (Class.java:-2)
java.lang.Class.forName (Class.java:264)
clojure.lang.RT.loadClassForName (RT.java:2098)
clojure.lang.RT.load (RT.java:430)
clojure.lang.RT.load (RT.java:411)
clojure.core$load$fn__5018.invoke (core.clj:5530)
clojure.core$load.doInvoke (core.clj:5529)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$load_one.invoke (core.clj:5336)
clojure.core$load_lib$fn__4967.invoke (core.clj:5375)
clojure.core$load_lib.doInvoke (core.clj:5374)
clojure.lang.RestFn.applyTo (RestFn.java:142)
clojure.core$apply.invoke (core.clj:619)
clojure.core$load_libs.doInvoke (core.clj:5413)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invoke (core.clj:619)
clojure.core$require.doInvoke (core.clj:5496)
clojure.lang.RestFn.invoke (RestFn.java:512)
novate.console.app$eval1736$loading__4910__auto____1737.invoke (app.clj:1)
novate.console.app$eval1736.invoke (app.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6619)
clojure.lang.Compiler.eval (Compiler.java:6608)
clojure.lang.Compiler.load (Compiler.java:7064)
user$eval1732.invoke (NO_SOURCE_FILE:1)
clojure.lang.Compiler.eval (Compiler.java:6619)
clojure.lang.Compiler.eval (Compiler.java:6582)
clojure.core$eval.invoke (core.clj:2852)
clojure.main$repl$read_eval_print__6588$fn__6591.invoke (main.clj:259)
clojure.main$repl$read_eval_print__6588.invoke (main.clj:259)
clojure.main$repl$fn__6597.invoke (main.clj:277)
clojure.main$repl.doInvoke (main.clj:277)
clojure.lang.RestFn.invoke (RestFn.java:1096)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__584.invoke (interruptible_eval.clj:56)
clojure.lang.AFn.applyToHelper (AFn.java:159)
clojure.lang.AFn.applyTo (AFn.java:151)
clojure.core$apply.invoke (core.clj:617)
clojure.core$with_bindings_STAR_.doInvoke (core.clj:1788)
clojure.lang.RestFn.invoke (RestFn.java:425)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:41)
clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__625$fn__628.invoke (interruptible_eval.clj:171)
clojure.core$comp$fn__4154.invoke (core.clj:2330)
clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__618.invoke (interruptible_eval.clj:138)
clojure.lang.AFn.run (AFn.java:24)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:603)
java.lang.Thread.run (Thread.java:722)
If you guess "com.annadaletech.nexus.util.logging__init" you are wrong! Wait, I'll give you a hint: (ns com.annadaletech.nexus.util.logging
(:use [clojure.string :only [trim-newline]]
[clojure.pprint :only [code-dispatch pprint with-pprint-dispatch *print-right-margin*]])
(:import [java.io StringWriter]
[org.slf4j MDC MarkerFactory Marker LoggerFactory]
[java.util.concurrent.locks ReentrantLock]))
Oh, sorry, did that not help? The correct answer is "org.slf4j.MDC". Having that information in the stack trace would have saved me nearly an hour. I think it is worth the effort to get that reported correctly. |
| Comments |
| Comment by Gabriel Horner [ 10/May/13 1:56 PM ] |
|
When I try this on a fresh project, I get this error: Howard, could you give us a project.clj or better yet a github repository that recreates this issue? |
| Comment by Howard Lewis Ship [ 10/May/13 4:51 PM ] |
|
I'll see what I can do. Probably be next week. Thanks for looking at this. |
[CLJ-1131] Importing a non-existent class causes an exception that does not fully identify the source file Created: 17/Dec/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Howard Lewis Ship | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | feedback | ||
| Description |
|
I'm in the process of stripping out some OSGi support, and I missed one import. The exception identifies "init.clj", but I'd prefer to see the full path there, as I have a few different "init.clj" files in my overall project. :core-services:compileClojure Reflection warning, com/annadaletech/nexus/services/registry.clj:37 - call to unregisterAll can't be resolved. Reflection warning, com/annadaletech/nexus/services/registry.clj:131 - call to getConfiguration can't be resolved. Reflection warning, com/annadaletech/nexus/services/registry.clj:150 - call to getConfiguration can't be resolved. Exception in thread "main" java.lang.ClassNotFoundException: org.osgi.framework.ServiceRegistration, compiling:(init.clj:1) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3387) at clojure.lang.Compiler.compile1(Compiler.java:7035) at clojure.lang.Compiler.compile1(Compiler.java:7025) at clojure.lang.Compiler.compile(Compiler.java:7097) at clojure.lang.RT.compile(RT.java:387) at clojure.lang.RT.load(RT.java:427) at clojure.lang.RT.load(RT.java:400) at clojure.core$load$fn__4890.invoke(core.clj:5415) at clojure.core$load.doInvoke(core.clj:5414) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5227) at clojure.core$compile$fn__4895.invoke(core.clj:5426) at clojure.core$compile.invoke(core.clj:5425) at clojuresque.tasks.compile$main$fn__64.invoke(compile.clj:23) at clojuresque.cli$with_command_line_STAR_.invoke(cli.clj:92) at clojuresque.tasks.compile$main.doInvoke(compile.clj:6) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:601) at clojure.lang.Var.invoke(Var.java:419) at clojuresque.Driver.main(Driver.java:39) Caused by: java.lang.ClassNotFoundException: org.osgi.framework.ServiceRegistration |
| Comments |
| Comment by Gabriel Horner [ 17/May/13 3:56 PM ] |
|
While it's reasonable to want this for your case, having long path names in a stacktrace could be inconvenient for others. I'd recommend posting your desired change on the dev list - https://groups.google.com/forum/?fromgroups#!forum/clojure-dev . If they're ok with it, then I'd recommend submitting a patch. |
[CLJ-1130] Invoking a static method with the wrong number of arguments results in a NoSuchFieldException, rather than a proper message that the arguments could not be matched to the method Created: 17/Dec/12 Updated: 06/Jan/13 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Howard Lewis Ship | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | feedback | ||
| Description |
|
My code inadventently invoked a method that expected a single parameter, but passed no parameters. The exception: Exception in thread "main" java.lang.NoSuchFieldException: getService, compiling:(com/annadaletech/nexus/services/registry.clj:168) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462) at clojure.lang.Compiler.analyze(Compiler.java:6262) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443) at clojure.lang.Compiler.analyze(Compiler.java:6262) at clojure.lang.Compiler.access$100(Compiler.java:37) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5883) .... Caused by: java.lang.NoSuchFieldException: getService at java.lang.Class.getField(Class.java:1520) at clojure.lang.Compiler$StaticFieldExpr.<init>(Compiler.java:1180) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:923) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455) ... 78 more That threw me for a bit; really, it looks like the compiler is attempting to access a field and invoke it as an IFn. However, a proper message would be "getService() requires 1 parameter, not 0" (or something to that effect). Even "invalid number of parameters for SmashRuntime/getService()" would be better. |
| Comments |
| Comment by Michael Drogalis [ 06/Jan/13 6:44 PM ] |
|
It looks like it's first trying to resolve a field by name, since field access with / is legal. For example: user=> (Integer/parseInt) user=> (Integer/MAX_VALUE) Would trying to resolve a method before a field fix this? |
[CLJ-1129] Invalid ns macro can yield a difficult to trace exception Created: 17/Dec/12 Updated: 19/Dec/12 Resolved: 19/Dec/12 |
|
| Status: | Closed |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Howard Lewis Ship | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | aot, feedback | ||
| Description |
|
I inadvertently stripped off the namespace part of my ns macro, so that it was (ns (:use .... Clearly a user error, but an easy one. However, the result (from the REPL or the AOT compiler) was not ideal: Exception in thread "main" java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to clojure.lang.Named at clojure.core$name.invoke(core.clj:1489) at clojure.core$root_resource.invoke(core.clj:5210) at clojure.core$load_one.invoke(core.clj:5227) at clojure.core$compile$fn__4895.invoke(core.clj:5426) at clojure.core$compile.invoke(core.clj:5425) at clojuresque.tasks.compile$main$fn__64.invoke(compile.clj:23) at clojuresque.cli$with_command_line_STAR_.invoke(cli.clj:92) at clojuresque.tasks.compile$main.doInvoke(compile.clj:6) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:601) at clojure.lang.Var.invoke(Var.java:419) at clojuresque.Driver.main(Driver.java:39) The problem here is that there is no indication of what file was being loaded and compiled at the time of the error. Since I was in the middle of refactoring a big swath of code, I had some work to do to track down which file I had mangled. I would like to see a little more logging to the System/err to identify what resource file was being read and compiled by the compiler at the time of the exception. |
| Comments |
| Comment by Andy Fingerhut [ 18/Dec/12 1:12 AM ] |
|
Howard, is this perhaps a duplicate of CLJ-939? Let me know, and I can close this ticket as a duplicate if so. |
| Comment by Howard Lewis Ship [ 18/Dec/12 11:10 AM ] |
|
Yes, looks like a dupe to me. Sorry about that, I did do a search for existing issue before adding mine, but they can be hard to find. |
| Comment by Andy Fingerhut [ 19/Dec/12 1:09 AM ] |
|
Closed as duplicate of CLJ-939. |