2014-05-05 22:08 GMT+02:00 mynomoto :
> The default lein template has clojure 1.5.1 hardcoded. It will only change
> when it's updated there.
>
I was wondering the same also. Would it not be a good idea to have the
possibility to overrule this?
On Monday, May 5, 2014 4:10:38 P
omoto wrote:
>
> The default lein template has clojure 1.5.1 hardcoded. It will only change
> when it's updated there.
> You can check the lein ancient help with `lein help ancient`. There you
> will find how to include clojure on the verification.
>
> HTH,
> Marcelo
The default lein template has clojure 1.5.1 hardcoded. It will only change
when it's updated there.
You can check the lein ancient help with `lein help ancient`. There you
will find how to include clojure on the verification.
HTH,
Marcelo
On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim
I have Clojure 1.6.0 installed so why does `lein new app myapp` default
to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade
:all` doesn't return an upgrade for Clojure 1.5.1
gvim
--
You received this message because you are subscribed to the Google
Groups "Cloj
ok I think got it working at least black frame shows up.
On Monday, January 27, 2014 12:51:45 PM UTC-8, Kuba Roth wrote:
>
> Hi there,
> I'm trying to get Penumbra working with clojure 1.5.1 and was wondering if
> there is still anyone using that library...?
>
> Also I&#x
Hi there,
I'm trying to get Penumbra working with clojure 1.5.1 and was wondering if
there is still anyone using that library...?
Also I've just discovered a fork of penumbra in the clojars
(https://clojars.org/prismofeverything/penumbra/versions/0.6.12) which
claims to be compa
Thanks for your answer.
I'm wrapping the Java methods so. Without regret or remorse :)
--
--
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 - p
need something specific to work with
socket, so you can work that way without regrets.
Regards
Plínio
On Sun, Aug 11, 2013 at 3:04 PM, Christian Sperandio
wrote:
> Hi,
>
> Is there a socket management with Clojure 1.5.1?
>
> I found the create-server function in the clojure.contri
Hi,
Is there a socket management with Clojure 1.5.1?
I found the create-server function in the clojure.contrib but (except any
error) the clojure.contrib is outdated with the last version of Clojure.
And I didn't find any clue about client socket management.
Should I wrap Java classes?
T
That works a treat - thanks.
On 8 July 2013 16:49, Neale Swinnerton wrote:
> Hi Col,
>
> On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates wrote:
>
>> Alternatively, in the vein of just getting things done, can I do some
>> emacs fu to automatically load clojure.repl? Silly me - of course I can -
>
Ah yes - nice find.
On 8 July 2013 17:24, Tim Visher wrote:
> On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates
> wrote:
> > If using clojure 1.4.0 then when I start nrepl (CcMj) then I the
> > clojure.repl namespace is automatically 'used. If I upgrade to Clojure
> &
On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates wrote:
> If using clojure 1.4.0 then when I start nrepl (CcMj) then I the
> clojure.repl namespace is automatically 'used. If I upgrade to Clojure
> 1.5.1 then it doesn't. I can still (use 'clojure.repl) but is this a bug?
>
Hi Col,
On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates wrote:
> Alternatively, in the vein of just getting things done, can I do some
> emacs fu to automatically load clojure.repl? Silly me - of course I can -
> this is emacs :). No idea what that fu would be though... Any hints?
>
>
Since nrepl
Hi all,
If using clojure 1.4.0 then when I start nrepl (CcMj) then I the
clojure.repl namespace is automatically 'used. If I upgrade to Clojure
1.5.1 then it doesn't. I can still (use 'clojure.repl) but is this a bug?
I can't believe I would be the first to spot this
On 7/1/13 3:49 AM, Gerrard McNulty wrote:
> Suppose I had code like:
>
> ((fn [rs] (take-last 3 rs)) (range 2000))
>
> This seems to run fine with no head holding. But if I write something like:
>
> (defn- log [f]
> (println "start")
> (f)
> (println "end"))
>
> ((fn [rs] (log #(take
Hi Meikel,
That works for me too. I can use that when I control the definition of
that function. However sometimes I don't e.g. when I use with-redefs,
which calls with-redefs-fn.
On Monday, July 1, 2013 12:23:34 PM UTC+1, Meikel Brandmeyer (kotarak)
wrote:
>
> Hi,
>
> I did a slight variati
Hi,
I did a slight variation which does not close over the head and it seems to
work fine.
(defn log
[f & args]
(println "start")
(apply f args)
(println "stop"))
((fn [xs] (log take-last 3 xs)) (range 2))
Kind regards
Meikel
--
--
You received this message because you are s
Suppose I had code like:
((fn [rs] (take-last 3 rs)) (range 2000))
This seems to run fine with no head holding. But if I write something like:
(defn- log [f]
(println "start")
(f)
(println "end"))
((fn [rs] (log #(take-last 3 rs))) (range 2000))
Then this seems to hold on to the
Ah OK, I didn't realise. I thought the vars would be locally scoped, i.e.
semantically equivalent to 'let'ed symbols.
Thanks everyone for contributing.
On Friday, 21 June 2013 14:49:52 UTC+1, Jim foo.bar wrote:
>
> On 21/06/13 14:34, Colin Yates wrote:
>
> Is it correct but simply non-idiom
On 21/06/13 15:06, Andy Fingerhut wrote:
Colin showed pretty clearly in his email that he was using "lein
uberjar" followed by running the JVM explicitly with his own command
line, so Leiningen has no way to affect the JVM command line options
in that case.
oops! I thought Michael meant the g
2013/6/21 Jim - FooBar();
> Did you read the entire thread?
> both Jason and Leon (who originally posted) admit that this was the
> problem...Stuart even opened this issue:
> https://github.com/technomancy/leiningen/pull/1230
>
Leiningen's default only apply if you, hm, run Leiningen.
If you ru
:jvm-opts and that ticket for Leiningen only affect the options passed to
the JVM if you let Leiningen invoke the JVM for you, e.g. via "lein run ..."
Colin showed pretty clearly in his email that he was using "lein uberjar"
followed by running the JVM explicitly with his own command line, so
Lein
Did you read the entire thread?
both Jason and Leon (who originally posted) admit that this was the
problem...Stuart even opened this issue:
https://github.com/technomancy/leiningen/pull/1230
the very last post reads:
I should follow up on this and clarify that core.matrix's esum is in
fact a
2013/6/21 Jim - FooBar();
> If you're using leiningen, add this entry to your project.clj and rerun
> your benchmarks.
>
> :jvm-opts ^replace []
>
Original post suggests the code is executed by building an uberjar running
java -jar target/…
so Leiningen default JVM options are not relevant.
--
2013/6/21 Colin Yates
> Is it correct but simply non-idiomatic?
It's not how defs are supposed to be used. It's like using fields for
everything in Java
even though you could use local variables for a lot of things, just because
you can.
def produces a shared (well, namespace-local) var. You p
On 21/06/13 14:34, Colin Yates wrote:
Is it correct but simply non-idiomatic?
no no it's actually very *dangerous*...by doing this you're essentially
introducing mutable global state in your program and Clojure is a
language that strives hard to minimise mutable and especially global
state!
Thanks Jim and David.
David, can you expand on why it is incorrect? That is such a strong word.
Is it correct but simply non-idiomatic?
Also note that if I move the body out of the 'let' version of the array
into another function passing in the array then the performance is the same
as the 'def
Using `def` like that is simply incorrect. `def` should always be at the
top level unlike say Scheme.
I would first remove all internal defs and then rerun your benchmarks.
On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates wrote:
> Hi all,
>
> I am doing some (naive and trivial) performance tests b
a start would be to set *warn-on-reflection* & *unchecked-math* to
true...I think you're not properly type-hinting your 'aget' calls.
areduce is the fastest way to sum up an array of primitives given that
there are no reflective calls. This takes just over 19 ms on my humble
machine and don't f
Hi all,
I am doing some (naive and trivial) performance tests before deciding
whether and how to use Clojure for some performance critical number
cruching and I wanted help understanding the behaviour.
I am defining an array inside a function, setting the contents to be 1 and
then summing them
Hi Stream,
I have resolved the problem you are referring to. See comment in the issue
you have opened
https://github.com/apolenur/vert.x-mod-lang-clojure/issues/1
Regards, Alexi
On Monday, 17 June 2013 23:15:37 UTC-4, Stream wrote:
>
>
>
> 在 2013年5月9日星期四UTC+8下午2时00分54秒，Stream写道：
>>
>> Hi all
在 2013年5月9日星期四UTC+8下午2时00分54秒，Stream写道：
>
> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
> clojure.lang.Compiler.LOADER, cl) );
>
> but throws exception that cojure.lang.Compiler.LOADER is
Daniel hinted at it in his response and it's been discussed several
times in the past but most of clojure.lang.RT and pretty much all of
clojure.lang.{anything-else} is considered a private implementation
detail and subject to change, so relying on it in code is very
brittle. I think Rich has indic
is not this one is it ?
https://github.com/CmdrDats/clj-minecraft/blob/master/javasrc/cljminecraft/BasePlugin.java#L82
On Thu, May 9, 2013 at 7:12 PM, AtKaaZ wrote:
> is there any chance that we can see the full code (maybe's on github
> already?)
>
>
> On Thu, May 9, 2013 at 9:00 AM, stream w
is there any chance that we can see the full code (maybe's on github
already?)
On Thu, May 9, 2013 at 9:00 AM, stream wrote:
> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
> clojure.lang.Comp
Caused by: java.lang.NullPointerException
at clojure.lang.RT.*baseLoader*(RT.java:2043)
hmm, it's almost as if:
static final public Var LOADER = Var.create().setDynamic();
had no effect as in: LOADER=null;
On Thu, May 9, 2013 at 4:51 PM, semperos wrote:
> Is there a reason you don't us
Is there a reason you don't use one of the methods exposed in
clojure.lang.RT, e.g., makeClassLoader() or baseLoader() ?
On Thursday, May 9, 2013 2:00:54 AM UTC-4, Stream wrote:
>
> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pus
Hi all
i wanna change the classloader of Clojure RT. in 1.5.1
so , i try to
clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
clojure.lang.Compiler.LOADER, cl) );
but throws exception that cojure.lang.Compiler.LOADER is null
Caused by: java.lang.NullPointerException
at c
Fixed, thanks.
Stu
On Sun, Mar 10, 2013 at 7:28 PM, wrote:
> I think there's a typo in the download link on
> http://clojure.org/downloads:
>
> It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
> /clojure-1.5.1.zip<http://repo1.maven.org/maven2/or
I think there's a typo in the download link on http://clojure.org/downloads:
It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
/clojure-1.5.1.zip<http://repo1.maven.org/maven2/org/clojure/clojure/1.5.0/clojure-1.5.1.zip>
whereas it should be http://repo1.maven.org
fyi - Rich's .idea/ crept in on the bug fix commit.
On Sunday, March 10, 2013 8:35:34 PM UTC+2, Stuart Halloway wrote:
>
> Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
>
> https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ
>
> Get
Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ
Getting Clojure:
Web: http://clojure.org/downloads
Lein/Maven: :dependencies [[org.clojure/clojure "1.5.1"]]
Note that it will
42 matches
Mail list logo
