Calling Parent Class' Protected Static Method
Hi, In an instance method in child class "veeds.wowza.Module", I want to call a protected static method "getLogger" in the parent class "ModuleBase" At first, I tried ( (.getLogger this) ) which compiled but failed at runtime java.lang.IllegalArgumentException: No matching field found: getLogger for class veeds.wowza.Module then I tried ( (. veeds.wowza.Module (getLogger)) ) ( (veeds.wowza.Module/getLogger) ) ( (ModuleBase/getLogger) ) but all failed to compile saying java.lang.NoSuchFieldException: getLogger. What am I doing wrong? The entire class looks like this (ns veeds.wowza.module (:import (com.wowza.wms.module ModuleBase IModuleOnApp )) (:gen-class :name veeds.wowza.Module :extends com.wowza.wms.module.ModuleBase :implements [com.wowza.wms.module.IModuleOnApp])) ; overriding onAppStart in ModuleBase (defn -onAppStart "" [this appInstance] (.info (. veeds.wowza.Module (getLogger)) "onAppStart")) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: leiningen - a Clojure build tool
Leiningen and Clojar are LEGEN... wait for it... DARY! Anyways, just wanted to say thanks. On Nov 19, 1:23 pm, Alex Osborne wrote: > meb wrote: > > Was the name Leiningen inspired by the Esquire short story "Leiningen > > vs. Ants"? That would be a brilliantly obscure way to challenge the > > predominance of ant. Or did you have another reference in mind. > > From the Leiningen README: > > "Leiningen!" he shouted. "You're insane! They're not creatures you can > fight--they're an elemental--an 'act of God!' Ten miles long, two miles > wide--ants, nothing but ants! And every single one of them a fiend from > hell... -- from Leiningen Versus the Ants by Carl Stephenson > > For those who haven't heard of it: > > http://en.wikipedia.org/wiki/Leiningen_Versus_the_Ants > > The story seems to be online in various places, like this one: > > http://www.americanliterature.com/Stephenson/SS/LeiningenVersustheAnt... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
HOWTO: Compojure Development without Web Server Restarts using VimClojure
I figured this out recently; hopefully this is helpful to others. 1. Install VimClojure http://kotka.de/projects/clojure/vimclojure.html - vimclojure offers a number of features, but the documentation is hidden in a text file inside ~/.vim/doc/clojure.txt (you can also read it here: http://bitbucket.org/kotarak/vimclojure/src/tip/doc/clojure.txt) - you need to put your source files in the classpath when running the nailgun server; if you use lein, you can install lein-nailgun as a dev- dependency and call "lein nailgun" to run the nailgun server 2. Fire up vim; open up the files you want to edit. 3. Type "\sr" to open a REPL. 4. Call (run-server ) in the REPL to start your server. 5. Edit some of the source files on which your server runs. When you're done, type "\ef", which evaluates the entire file in the REPL. 6. Refresh your browser. Voila! P.S It's possible to do something similar in swank, but I've never used it before so I wouldn't know. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: combining vimclojure, classpaths and leiningen
Just wanted to say that lein-nailgun is just a very primitive plugin, which is why you're seeing all kinds of problems. Essentially, it's a one-liner that calls the main function in com.martiansoftware.nailgun.NGServer. To call nailgun as a server inside a plugin, I think the only way would be to invoke a child process with the arguments you suggested (i.e java -server ..blah blah). I'll try to see if it'll work when I get some free time (tomo night?). On Dec 3, 8:13 am, bOR_ wrote: > Additionally, Ato's nailgun also generates two warnings upon > installing with 'lein deps': > > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > invalid. It will be ignored for artifact resolution. Reason: Not a > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > invalid. It will be ignored for artifact resolution. Reason: Not a > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > > but these don't seem to have a negative effect. > > On Dec 3, 3:19 pm, bOR_ wrote: > > > Second question: how do I access documentation of a lein nailgun > > plugin? I know how to start it, but to stop it, I now just kill its > > pid. > > > On Dec 2, 2:16 pm, bOR_ wrote: > > > > Q: I noticed that the leinnailgunruns as java -client. Being used to > > > seeing -server everywhere, I wonder if the -client bit makes sense, > > > and if it slows down simulations that are running in the vimclojure > > > environment. > > > > ps x | grep java > > > > 29248 pts/1 Sl 0:01 java -client -cp src/:classes/:lib/plexus- > > > utils-1.5.5.jar:lib/maven-profile-2.0.10.jar:lib/maven-plugin- > > > registry-2.0.10.jar:lib/plexus-container-default-1.0-alpha-9- > > > stable-1.jar:lib/maven-artifact-manager-2.0.10.jar:lib/ > > > jtidy-4aug2000r7-dev.jar:lib/maven-ant-tasks-2.0.10.jar:lib/ant- > > > launcher-1.6.2.jar:lib/ant-1.6.2.jar:lib/classworlds-1.1- > > > alpha-2.jar:lib/wagon-http-shared-1.0-beta-2.jar:lib/maven-repository- > > > metadata-2.0.10.jar:lib/wagon-http-lightweight-1.0-beta-2.jar:lib/ > > > leiningen-1.0.0-20091119.123056-1.jar:lib/clojure-1.1.0- > > > alpha-20091126.000150-7.jar:lib/maven-error-diagnostics-2.0.10.jar:lib/ > > > clojure-contrib-1.0-20091130.190214-24.jar:lib/ > > > automaton-1.11.2.jar:lib/maven-artifact-2.0.10.jar:lib/lein-nailgun-0.1.0.jar:lib/wagon-file-1.0-beta-2.jar:lib/wagon-provider- > > > api-1.0-beta-2.jar:lib/maven-settings-2.0.10.jar:lib/xml- > > > apis-1.0.b2.jar:lib/maven-project-2.0.10.jar:lib/plexus- > > > interpolation-1.1.jar:lib/vimclojure-2.1.2.jar:lib/maven- > > > model-2.0.10.jar::/home/boris/.m2/repository/leiningen/leiningen/0.5.0/ > > > leiningen-0.5.0.jar leiningen.corenailgun > > > > On Nov 27, 4:19 pm, Meikel Brandmeyer wrote: > > > > > Hi, > > > > > On Nov 27, 4:16 pm, bOR_ wrote: > > > > > > using vimclojures'nailgun, I would have a line like this added to > > > > > my .vimrc file. Can I still use that? > > > > > > let vimclojure#NailgunClient = "/home/boris/opt/vimclojure/ng" > > > > > You still need this. Leiningen only starts the server, will this is > > > > the client. Without telling VC where to find the client, you cannot > > > > talk to the server. So this is required. > > > > > Sincerely > > > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: combining vimclojure, classpaths and leiningen
Also, ato's nailgun is just a plain nailgun server. It doesn't have any of the vimclojure stuff attached to it. All the extra dependencies from lein-nailgun is from vimclojure.jar. On Dec 3, 8:13 am, bOR_ wrote: > Additionally, Ato's nailgun also generates two warnings upon > installing with 'lein deps': > > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > invalid. It will be ignored for artifact resolution. Reason: Not a > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > invalid. It will be ignored for artifact resolution. Reason: Not a > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > > but these don't seem to have a negative effect. > > On Dec 3, 3:19 pm, bOR_ wrote: > > > Second question: how do I access documentation of a lein nailgun > > plugin? I know how to start it, but to stop it, I now just kill its > > pid. > > > On Dec 2, 2:16 pm, bOR_ wrote: > > > > Q: I noticed that the leinnailgunruns as java -client. Being used to > > > seeing -server everywhere, I wonder if the -client bit makes sense, > > > and if it slows down simulations that are running in the vimclojure > > > environment. > > > > ps x | grep java > > > > 29248 pts/1 Sl 0:01 java -client -cp src/:classes/:lib/plexus- > > > utils-1.5.5.jar:lib/maven-profile-2.0.10.jar:lib/maven-plugin- > > > registry-2.0.10.jar:lib/plexus-container-default-1.0-alpha-9- > > > stable-1.jar:lib/maven-artifact-manager-2.0.10.jar:lib/ > > > jtidy-4aug2000r7-dev.jar:lib/maven-ant-tasks-2.0.10.jar:lib/ant- > > > launcher-1.6.2.jar:lib/ant-1.6.2.jar:lib/classworlds-1.1- > > > alpha-2.jar:lib/wagon-http-shared-1.0-beta-2.jar:lib/maven-repository- > > > metadata-2.0.10.jar:lib/wagon-http-lightweight-1.0-beta-2.jar:lib/ > > > leiningen-1.0.0-20091119.123056-1.jar:lib/clojure-1.1.0- > > > alpha-20091126.000150-7.jar:lib/maven-error-diagnostics-2.0.10.jar:lib/ > > > clojure-contrib-1.0-20091130.190214-24.jar:lib/ > > > automaton-1.11.2.jar:lib/maven-artifact-2.0.10.jar:lib/lein-nailgun-0.1.0.jar:lib/wagon-file-1.0-beta-2.jar:lib/wagon-provider- > > > api-1.0-beta-2.jar:lib/maven-settings-2.0.10.jar:lib/xml- > > > apis-1.0.b2.jar:lib/maven-project-2.0.10.jar:lib/plexus- > > > interpolation-1.1.jar:lib/vimclojure-2.1.2.jar:lib/maven- > > > model-2.0.10.jar::/home/boris/.m2/repository/leiningen/leiningen/0.5.0/ > > > leiningen-0.5.0.jar leiningen.corenailgun > > > > On Nov 27, 4:19 pm, Meikel Brandmeyer wrote: > > > > > Hi, > > > > > On Nov 27, 4:16 pm, bOR_ wrote: > > > > > > using vimclojures'nailgun, I would have a line like this added to > > > > > my .vimrc file. Can I still use that? > > > > > > let vimclojure#NailgunClient = "/home/boris/opt/vimclojure/ng" > > > > > You still need this. Leiningen only starts the server, will this is > > > > the client. Without telling VC where to find the client, you cannot > > > > talk to the server. So this is required. > > > > > Sincerely > > > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: combining vimclojure, classpaths and leiningen
Hmm at this point, I think it makes more sense to add vimclojure in your dev-dependencies, and then running java -server -Xms256m -Xmx2048m -cp 'src:classes:lib/*' com.martiansoftware.nailgun.NGServer 127.0.0.1 & I know that the next version of leiningen will likely have some sort of "run" command. Hopefully, it'll incorporate running java classes as well. If not, one could easily make an alias for the above command in their UNIX environment. On Dec 3, 3:58 pm, Gilbert wrote: > Also, ato's nailgun is just a plain nailgun server. It doesn't have > any of the vimclojure stuff attached to it. All the extra dependencies > from lein-nailgun is from vimclojure.jar. > > On Dec 3, 8:13 am, bOR_ wrote: > > > > > Additionally, Ato's nailgun also generates two warnings upon > > installing with 'lein deps': > > > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > > invalid. It will be ignored for artifact resolution. Reason: Not a > > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > > [WARNING] POM for 'org.clojars.ato:nailgun:pom:0.7.1:compile' is > > invalid. It will be ignored for artifact resolution. Reason: Not a > > v4.0.0 POM. for project org.clojars.ato:nailgun at /home/boris/.m2/ > > repository/org/clojars/ato/nailgun/0.7.1/nailgun-0.7.1.pom > > > but these don't seem to have a negative effect. > > > On Dec 3, 3:19 pm, bOR_ wrote: > > > > Second question: how do I access documentation of a lein nailgun > > > plugin? I know how to start it, but to stop it, I now just kill its > > > pid. > > > > On Dec 2, 2:16 pm, bOR_ wrote: > > > > > Q: I noticed that the leinnailgunruns as java -client. Being used to > > > > seeing -server everywhere, I wonder if the -client bit makes sense, > > > > and if it slows down simulations that are running in the vimclojure > > > > environment. > > > > > ps x | grep java > > > > > 29248 pts/1 Sl 0:01 java -client -cp src/:classes/:lib/plexus- > > > > utils-1.5.5.jar:lib/maven-profile-2.0.10.jar:lib/maven-plugin- > > > > registry-2.0.10.jar:lib/plexus-container-default-1.0-alpha-9- > > > > stable-1.jar:lib/maven-artifact-manager-2.0.10.jar:lib/ > > > > jtidy-4aug2000r7-dev.jar:lib/maven-ant-tasks-2.0.10.jar:lib/ant- > > > > launcher-1.6.2.jar:lib/ant-1.6.2.jar:lib/classworlds-1.1- > > > > alpha-2.jar:lib/wagon-http-shared-1.0-beta-2.jar:lib/maven-repository- > > > > metadata-2.0.10.jar:lib/wagon-http-lightweight-1.0-beta-2.jar:lib/ > > > > leiningen-1.0.0-20091119.123056-1.jar:lib/clojure-1.1.0- > > > > alpha-20091126.000150-7.jar:lib/maven-error-diagnostics-2.0.10.jar:lib/ > > > > clojure-contrib-1.0-20091130.190214-24.jar:lib/ > > > > automaton-1.11.2.jar:lib/maven-artifact-2.0.10.jar:lib/lein-nailgun-0.1.0.j > > > > ar:lib/wagon-file-1.0-beta-2.jar:lib/wagon-provider- > > > > api-1.0-beta-2.jar:lib/maven-settings-2.0.10.jar:lib/xml- > > > > apis-1.0.b2.jar:lib/maven-project-2.0.10.jar:lib/plexus- > > > > interpolation-1.1.jar:lib/vimclojure-2.1.2.jar:lib/maven- > > > > model-2.0.10.jar::/home/boris/.m2/repository/leiningen/leiningen/0.5.0/ > > > > leiningen-0.5.0.jar leiningen.corenailgun > > > > > On Nov 27, 4:19 pm, Meikel Brandmeyer wrote: > > > > > > Hi, > > > > > > On Nov 27, 4:16 pm, bOR_ wrote: > > > > > > > using vimclojures'nailgun, I would have a line like this added to > > > > > > my .vimrc file. Can I still use that? > > > > > > > let vimclojure#NailgunClient = "/home/boris/opt/vimclojure/ng" > > > > > > You still need this. Leiningen only starts the server, will this is > > > > > the client. Without telling VC where to find the client, you cannot > > > > > talk to the server. So this is required. > > > > > > Sincerely > > > > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Chestnut 0.7.0
I ran into this same behavior, and then I realized it only happened if I run the "lein new" command if I'm *already in* a previously-created project created with "lein new chestnut". I'm guessing that something in the generated project.clj interferes some of the lein new behavior somehow. At any rate, running lein new in a directory without a project.clj file in it is working fine for me. Tim On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote: > > I tested the v 0.7.0 of chestnut and I encountered the following error. > The v 0.6.0 works fine. > > $ lein new chestnut test-app > Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from > clojars > Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from > clojars > Exception in thread "main" java.lang.ExceptionInInitializerError > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at clojure.lang.RT.loadClassForName(RT.java:2093) > at clojure.lang.RT.load(RT.java:430) > at clojure.lang.RT.load(RT.java:411) > at clojure.core$load$fn__5066.invoke(core.clj:5641) > at clojure.core$load.doInvoke(core.clj:5640) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:5446) > at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) > at clojure.core$load_lib.doInvoke(core.clj:5485) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$load_libs.doInvoke(core.clj:5524) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$require.doInvoke(core.clj:5607) > at clojure.lang.RestFn.invoke(RestFn.java:421) > at stencil.core$loading__4958__auto__.invoke(core.clj:1) > at stencil.core__init.load(Unknown Source) > at stencil.core__init.(Unknown Source) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at clojure.lang.RT.loadClassForName(RT.java:2093) > at clojure.lang.RT.load(RT.java:430) > at clojure.lang.RT.load(RT.java:411) > at clojure.core$load$fn__5066.invoke(core.clj:5641) > at clojure.core$load.doInvoke(core.clj:5640) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:5446) > at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) > at clojure.core$load_lib.doInvoke(core.clj:5485) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$load_libs.doInvoke(core.clj:5524) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$require.doInvoke(core.clj:5607) > at clojure.lang.RestFn.invoke(RestFn.java:512) > at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11) > at leiningen.new.templates__init.load(Unknown Source) > at leiningen.new.templates__init.(Unknown Source) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at clojure.lang.RT.loadClassForName(RT.java:2093) > at clojure.lang.RT.load(RT.java:430) > at clojure.lang.RT.load(RT.java:411) > at clojure.core$load$fn__5066.invoke(core.clj:5641) > at clojure.core$load.doInvoke(core.clj:5640) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:5446) > at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) > at clojure.core$load_lib.doInvoke(core.clj:5485) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$load_libs.doInvoke(core.clj:5524) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$require.doInvoke(core.clj:5607) > at clojure.lang.RestFn.invoke(RestFn.java:512) > at leiningen.new$loading__4958__auto__.invoke(new.clj:1) > at leiningen.new__init.load(Unknown Source) > at leiningen.new__init.(Unknown Source) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at clojure.lang.RT.loadClassForName(RT.java:2093) > at clojure.lang.RT.load(RT.java:430) > at clojure.lang.RT.load(RT.java:411) > at clojure.core$load$fn__5066.invoke(core.clj:5641) > at clojure.core$load.doInvoke(core.clj:5640) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:5446) > at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) > at clojure.core$load_lib.doInvoke(core.clj:5485) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$load_libs.doInvoke(core.clj:5524) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:626) > at clojure.core$require.doInvoke(core.clj:5607) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at leiningen.core.utils$require_resolve.invoke(utils.clj:80) > at leiningen.core.utils$require_resolve.invoke(utils.clj:83) > at leiningen.core.main$lookup_task_var.invoke(main.clj:68) > at leiningen.core.main$pass
Re: [ANN] Chestnut 0.7.0
Oh, that's odd. I don't have any entries in my own user plugins for "lein
new" templates. (I'm assuming you meant ~/.lein/profiles.clj, right?)
Is there some reason you have them in there? "lein new chestnut" should
work just fine without them, but maybe I'm not understanding what you're
trying to do.
Tim
On Monday, March 9, 2015 at 6:30:48 PM UTC-4, webber wrote:
>
> I've commented chestnut/lein-template from the ~/.lein/projects.clj as
> follows, then it worked.
> It worked using 0.6.0 if there was the chestnut/lein-template definition.
> Was my usage wrong ?
>
> {:user {:plugins [
> [lein-try "0.4.3"]
> ;[lein-pprint "1.1.1"]
> [lein-ancient "0.6.4" :exclusions
> [org.clojure/core.cache]]
> [lein-bikeshed "0.2.0"]
> [lein-ritz "0.7.0"]
> [lein-marginalia "0.8.0"]
> [http-kit/lein-template "1.0.0-SNAPSHOT"]
> [cider/cider-nrepl "0.9.0-SNAPSHOT"]
> [cljs-complete "0.1.1"]
> ;;[chestnut/lein-template "0.7.0"]
> ;;[chestnut/lein-template "0.6.0"]
> ]
> :dependencies [;;[nrepl-inspect "0.4.1"]
>[compliment "0.2.0"]
>[ritz/ritz-nrepl-middleware "0.7.0"]
>[cider/cider-nrepl "0.9.0-SNAPSHOT"]
>[alembic "0.2.1"]
>[org.clojure/tools.nrepl "0.2.7"]
>]
>
> :repl-options {:nrepl-middleware
>[cider.nrepl.middleware.classpath/wrap-classpath
> cider.nrepl.middleware.complete/wrap-complete
> cider.nrepl.middleware.info/wrap-info
> cider.nrepl.middleware.inspect/wrap-inspect
> cider.nrepl.middleware.stacktrace/wrap-stacktrace
> cider.nrepl.middleware.trace/wrap-trace
> ]}
>
> }}
>
> Makoto
>
>
>> I ran into this same behavior, and then I realized it only happened if I
>> run the "lein new" command if I'm *already in* a previously-created
>> project created with "lein new chestnut". I'm guessing that something in
>> the generated project.clj interferes some of the lein new behavior somehow.
>> At any rate, running lein new in a directory without a project.clj file in
>> it is working fine for me.
>>
>> Tim
>>
>> On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:
>>>
>>> I tested the v 0.7.0 of chestnut and I encountered the following error.
>>> The v 0.6.0 works fine.
>>>
>>> $ lein new chestnut test-app
>>> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from
>>> clojars
>>> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from
>>> clojars
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:270)
>>> at clojure.lang.RT.loadClassForName(RT.java:2093)
>>> at clojure.lang.RT.load(RT.java:430)
>>> at clojure.lang.RT.load(RT.java:411)
>>> at clojure.core$load$fn__5066.invoke(core.clj:5641)
>>> at clojure.core$load.doInvoke(core.clj:5640)
>>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>>> at clojure.core$load_one.invoke(core.clj:5446)
>>> at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>>> at clojure.core$load_lib.doInvoke(core.clj:5485)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>> at clojure.core$apply.invoke(core.clj:626)
>>> at clojure.core$load_libs.doInvoke(core.clj:5524)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>> at clojure.core$apply.invoke(core.clj:626)
>>> at clojure.core$require.doInvoke(core.clj:5607)
>>> at clojure.lang.RestFn.invoke(RestFn.java:421)
>>> at stencil.core$loading__4958__auto__.invoke(core.clj:1)
>>> at stencil.core__init.load(Unknown Source)
>>> at stencil.core__init.(Unknown Source)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:270)
>>> at clojure.lang.RT.loadClassForName(RT.java:2093)
>>> at clojure.lang.RT.load(RT.java:430)
>>> at clojure.lang.RT.load(RT.java:411)
>>> at clojure.core$load$fn__5066.invoke(core.clj:5641)
>>> at clojure.core$load.doInvoke(core.clj:5640)
>>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>>> at clojure.core$load_one.invoke(core.clj:5446)
>>> at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>>> at clojure.core$load_lib.doInvoke(core.clj:5485)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>> at clojure.core$apply.invoke(core.clj:626)
>>> at clojure.core$load_libs.doInvoke(core.clj:5524)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>> at clojure.core$apply.invoke(core.clj:626)
>>> at clojure.core$require.doInvoke(core.clj:5607)
>>> at clojure.lang.RestFn.invoke(RestFn.java:512)
>>> at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11)
>>> at leining
Re: [ANN] lein-collisions: a plugin to find classpath collisions
I'm not sure if it's something else in my project's somewhat baroque dependency tree that causes this, but after I add lein-collisions to my project's plugins, I'm unable to get it to pass lein's :pedantic? tests due to overlapping versions in its own dependencies: http://pastebin.com/js93Mrzw ...and in fact the only way I can get it to pass dependency checks is if I add a lot of :exclusions, up to and including org.slf4j/slf4j-api at which point it aborts with a runtime error "java.lang.ClassNotFoundException: org.slf4j.LoggerFactory". Is anyone else seeing this? Thanks Tim On Monday, July 13, 2015 at 10:05:41 AM UTC-4, Herwig Hochleitner wrote: > > 2015-07-09 19:01 GMT+02:00 Andy Fingerhut >: > >> I think it would be helpful to include that text in your README on Github >> somewhere. >> > > Done. Good idea, thanks Andy! > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Grimoire: up to date Clojure web docs
Well, clojure-grimoire.com is available, FWIW. Tim On Saturday, July 12, 2014 2:46:18 AM UTC-4, Reid McKenzie wrote: > > While I appreciate the interest, I think that attempting to "officiate" > Grimoire is a bad move. > > We already have "clojure.org". "clojure.org" is the only official site. > Grimoire is not condoned by Rich. Using #"clo?j.*\.org would detract > from any future documentation effort Rich and co. may make and implies a > blessing which I do not have, do not seek and do not expect to get. See > http://arrdem.com/2014/07/12/of_mages_and_grimoires/ for more on the > subject. > > Furthermore the #"clo?j.*" is also confusing due to existing namespace > contention from clojuredocs.org and clojure-doc.org let alone > clojure.org should it overnight grow better docs. Case in point: I lost > the link to http://getclojure.com/ for several months until it was > mentioned in IRC in the last week because it fell down the back of my > mental couch with the rest of the "*jure" namespace. > > Reid > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Deref Nil
In this specific case, I might personally use something like:
(render-image (some-> product-image-list first deref))
...or maybe write a little function that does the above. Alternately, in
(render-image) you might start out with (if (nil? cursor) (default-image)
(code-to-render @cursor)). You'd need to check for nil to render the
default image even if deref was nil-punnable, right?
Tim
On Monday, September 12, 2016 at 4:30:00 AM UTC-4, Deon Moolman wrote:
>
> Hi Tim,
>
> Thanks for your feedback, I appreciate it! :)
>
> Ye, I've been tempted and bitten by atoms-in-atoms before, and that's no
> fun - My case here is slightly different though, I have a single atom and
> construct cursors to paths within, which are swappable and deref'able like
> normal atoms, but they modify the value of the original atom (just their
> allocated slice inside though).
>
> I'll give a bit of detail on one very specific usecase I have, my
> structure looks like so:
>
> My atom (and its value) looks like so:
>
> (atom
> {:product
>[{:product/id 1 :product/name "Cooker"}
> {:product/id 2 :product/name "Pan"}]
>:image
>[{:image/id 1 :image/url "..." :image/product 1}]})
>
> And I have a function (reverse-lookup) that will take a product id and
> return a list of cursors that point to the individual images for a product,
> so:
>
> (reverse-lookup :image/product 1) => [(cursor {:image/id :image/url "..."
> :image/product 1})]
> (reverse-lookup :image/product 2) => []
>
> If I'm only interested in, say, rendering the first image, I can call
> (render-image
> @(first product-image-list)) - without nil-punning, I have to do add an
> if to every usage, where I'd rather just handle nil to a default image
> placeholder inside render-image.
>
> I also have a function will literally return the first (and likely only)
> element in the lookup, which will also return a cursor or nil if not found.
> One could argue that the data needs integrity checking in that case before
> getting into the atom, but in my case I'd rather just nil-pun all the
> things since it's not exactly a big deal.
>
> Anyhow - back to the original question - I'm wondering if there's anything
> I'm missing about the decision to not nil-pun deref - If it's simply a
> matter of 'didn't really think of it', that's fine, I'm quite content to
> work around it, but if there's a deeper philosophical reason, then I'm keen
> to add it to my understanding of the underlying foundation of clojure.
>
> Thanks again for all the feedback, I really do appreciate your time!
>
> Cheers,
> - Deon
>
> On Sat, Sep 10, 2016 at 9:08 PM, Timothy Baldridge > wrote:
>
>> I've worked with a model much like this, and as an experience report: it
>> resulted in a lot of pain. Atoms inside atoms, or really more than one atom
>> for the entire state of your app results in to many sources of mutability.
>> On top of that, you have the problem of async updates: some part of your
>> state may or may not exist depending if some async call to the server has
>> completed yet. I can't say much more without seeing your code, but I would
>> use this as an opprotunity to re-think the design of the app a bit.
>>
>> If you are getting nils in unexpected places you can either nil-prune
>> (what you're asking for here), or you can ask "why am I getting a nil here
>> when I didn't expect it...how can I keep from doing this in the future?".
>> Perhaps the answer is as simple as never calling the render function of a
>> component until all its state exists (Om.Next takes an approach somewhat
>> like this).
>>
>> On Sat, Sep 10, 2016 at 11:12 AM, Deon Moolman > > wrote:
>>
>>> Hi Sean,
>>>
>>> Good point - as you have noticed, my use case is in ClojureScript - I'm
>>> using reagent cursors (hence the deref) fairly heavily to chop my main atom
>>> up and send only the relevant bits to components, but still allow them to
>>> locally modify their state.
>>>
>>> In my specific case, I do lookups for parts of the tree that may not
>>> exist, and in that case 'nil' is the obvious return value.
>>>
>>> Cheers,
>>> - Deon
>>>
>>> On Fri, Sep 9, 2016 at 6:55 PM, Sean Corfield >> > wrote:
>>>
Like Stuart, I don’t encounter atom-or-nil as a common pattern – could
you explain why you have functions that might return an atom or might
return nil?
FYI, We have about 40,000 lines of Clojure at World Singles and just a
handful of atoms (and most of those are going away as we refactor the code
to use Component more extensively).
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
On 9/9/16, 1:10 AM, "Deon Moolman" >>> on behalf of cmdr...@gmail.com > wrote:
Hey all,
I'm having some pain with atoms
Re: Sum types in Clojure? Better to represent as tagged records or as variant vectors?
I've used tagged unions to represent lookup identifiers for variant types
and found them to be pleasant to work with. I think part of the reason they
don't seem useful in the context of this discussion is that many of the
examples given have not actually been variants. For example, in [:image/file
"/images/image" :jpeg], every value will have those three data elements,
and for {:status :response :result val}, every value will have both of
those fields, and their values will be the same type. The identifiers I was
working with were in heterogenous collections, so I might have [:image/ref
45] or [:user/name "bob"] or [:project/element "project-slug" 435].
It would certainly be just as easy to use {:collection/type ::person
:user/name "bob"} and {:collection/type ::project :project/slug
"project-slug" :project/element 435}, but I like the concision of the
tagged unions.
On Friday, August 25, 2017 at 4:30:37 PM UTC-4, tbc++ wrote:
>
> >> they're a little nicer to type and read
>
> And that's where I have to disagree. The problem with most of these
> options is they complect ordering with meaning.
>
> [:image/file "/images/image" :jpeg]
>
> Here I have no idea what these values mean. I have to have out-of-band
> information about what offset in the vector corresponds to what value.
> Functions have this same problem, look no further than `cons` vs `conj` to
> see potential confusion on argument ordering.
>
> So why don't we only use maps for function arguments? Well mostly to make
> the functions easier to manipulate by humans. But some of the best
> libraries for web APIs (AWS) that I've used have used almost an exclusively
> map based interface.
>
> Once again I have to repeat my mantra about DSLs. Don't start with DSLs.
> Start with maps. Build everything off of maps. They're extensible, easy to
> introspect, and can drive a host of metaprogramming algorithms. If maps are
> to hard to understand, build constructor functions on top of them. Then
> finally build a DSL on top, if you need it.
>
> Frankly, I have so many things I have to remember during programming. I'd
> much rather see a very uniform map-based interface. Than any sort of nested
> vectors, tagged values, or anything else.
>
> Surely we can't say that this:
> >> [[:image/file :image/web] :image.file/path "/images/image" :
> image.file/format :jpeg :image.web/url "www.myimage.com/image"]
>
> Is a better interface than:
>
> {:image.file/path "/images/image"
> :image.file/format :jpeg
> :image.web/url "www.myimage.com/image"}
>
> And as I said before, spec is designed from the start to support data in
> this format. Stating "this is a file", "this is a web image". Is just book
> keeping that doesn't need to be done. Is a map a :image/web? Well check its
> members and see if they match the spec. If they match, then you have a
> :image/web. No need for sum types, tags, wrapping values in vectors. Simply
> state what a thing should have for it to conform to an interface, and
> forget whatever else might be in there. It couldn't be simpler.
>
> On Fri, Aug 25, 2017 at 11:59 AM, Didier >
> wrote:
>
>> Thanks for everyone's great input.
>>
>> Currently, I see the big distinction being concise vs extension. Maybe
>> for streaming variants would be better as the format would be smaller to
>> transfer over a wire. And for small short lived programs, or things you
>> know won't need extension, variants offer a slightly more convenient
>> structure to work with.
>>
>> I think both can be specced easily. S/or a few s/tuple to spec a variant.
>> And multi-spec over a set for the map version.
>>
>> I'd like to explore then the issue of extensibility with variants. How
>> would you extend them, is there really no way? This is some of my
>> brainstorming thoughts.
>>
>> 1) How to design a variant of more then one value?
>>
>>
>> 1.1)
>>
>> I know this is a standard variant of one value:
>>
>> [:image/web "www.myimage.com/image.jpg"]
>>
>> I believe to extend it to more values, you would do:
>>
>> [:image/file "/images/image" :jpeg]
>>
>> That is, you'd threat it as a constructor function, which creates an
>> :image/file type and takes an ordered list of arguments. This way, each
>> variant type can even be overloaded on their arguments the way you'd
>> overload a function.
>>
>> [:image/file "/images/image"]
>>
>> Can default to format :png for example, when using the one arg
>> constructor.
>>
>> 1.2)
>>
>> An alternative is to keep variants as vector pairs, and nest them.
>>
>> [:image/file [:image/file-path "/images/image"] [:image/file-format:jpeg]]
>>
>> In this form, variants are more like their map counterpart. Each element
>> is named and itself a variant.
>>
>> 1.3)
>>
>> You could also decide to limit variants to strict pairs, so the second
>> element of any variant is either a variant or a vector of variants.
>>
>> [:image/file [[:image/file-path "/images/image"]
>> [:image/file-format:jpeg]]]
>>
>>
Re: Poll for a new name for clojure eclipse plugin 'clojure-dev'
+1 from me. I don't think extremely literal names are bad things where plugins are concerned. Tim Mike Hinchey wrote: > I vote for EclipseClojure or eclipse-clojure. It's not as fun as some > of the others, but do you really need a distinct brand on this > project? I think easy to understand and search for is better. As > Clojure becomes more mainstream, people won't care about a clever name > of this project, they just want the solid integration. > > -Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
