Re: ANN: a Clojure docs site, and github organization

[nchurch]

> Just to keep in touch with our marvelous legal systems in North America, read 
> this:
...
> how much I am frustrated by this shattered world

Indeed!  The law is nothing but an overly complex, haphazardly
designed, historically encrufted programming language for morals.

Its compiler is frighteningly well-maintained, though.

On Oct 6, 6:24 pm, Softaddicts  wrote:
> It works for Oracle because they have the $$$ to support it. You just 
> confirmed
> that we are on the same wavelength, they have the weapons to nail anyone who
> would like to exercise exclusive rights on some contribution made under their 
> CA
> even if that individual lives in Kazakhstan.
>
> They have the infra structure and several offices in various
> Countries and continents to cover their ass.
>
> Just to keep in touch with our marvelous legal systems in North America, read 
> this:
>
> http://hrdailyadvisor.blr.com/archive/2010/08/20/Epinions_Employment_...
>
> The first question/answer is pretty instructive. It's easier to avoid the 
> whole issue
> with a piece of paper. Maybe in ten years things will have settled somehow.
> The above is dated from 2010 that's not far away.
>
> I will not anything else to this thread, the world is as it is. I you think 
> that you are
> frustrated, maybe we should have a drink together and I could explain how
> much I am frustrated by this shattered world
>
> Do you expect to drop at the Conj ?
>
> Luc
>
>
>
>
>
>
>
>
>
> > 2012/10/7 Softaddicts 
>
> > > The validity of a scanned signature or electronic keys is subject to
> > > interpretation
> > > and assessment on a per case basis especially in civil contracts by the
> > > diverse
> > > legal systems on Earth.
>
> > > It's not the Clojure community that is behind, it's the legal systems of
> > > many countries
> > > that did not follow the pace of technology. Some will not recognize
> > > scanned signatures
> > > at all.
>
> > > On the other hand, original hand written signatures are recognized almost
> > > every where.
>
> > A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many
> > lawyers as
> > Clojure/core, lawyers several times as experienced and about x10,000 times
> > as much experience with this stuff as a company. And it works for them.
>
> > > As much as you complain about the paper CA, you should complain about
> > > the legal systems of these countries that do not follow US and western
> > > Europe
> > > attempts to recognize technology changes and adapt to it.
>
> > > You analyze the issue by the wrong end
>
> > > It's not a technology issue, it's a legal one.
>
> > > You could have the best electronic authentication scheme, if it's not
> > > recognized by a country's legal system, it's useless in court in this
> > > country.
> > > If claims rights on contributions not backed by a CA in a valid form as
> > > defined in this
> > > country, it's a lost case.
>
> > > Big organizations have the tools and budgets to fight in various legal
> > > systems
> > > out there. Not small open source projects or projects without big 
> > > sponsors.
>
> > > I understand and approve the requirement of the original hand written
> > > signature in
> > > this context. That's a real life issue that cannot be dealt with by
> > > technology alone.
>
> > > If a national mail system is not able to get reliably an envelope to the 
> > > US
> > > within 4/5 weeks, I would be very concerned about the state of their legal
> > > system.
>
> > Sorry to break it to you, but legal systems outside of a few countries are
> > seriously
> > broken and it will take decades and many lives to fix this. And I assure
> > you, people who
> > live in those countries are just as concerned as you are, thanks for caring.
>
> > So the system is how it is. Clojure/core can
> > accept this unfortunate fact and find a way to accept CA submissions
> > electronically.
>
> > Or they can ignore all the complaints (again, not about the CA per se, but
> > how it is currently submitted) and lose many potential contributions.
>
> > Contributions from people who really want to make Clojure better, ready to
> > spend
> > many hours of their time contributing but were not lucky enough to be born
> > in the Wonderland called Canada, where the law rules and the sun shines (at
> > least 2 months of the year).
>
> > It always starts with contributing something small. Then something else
> > small.
> > Then something slightly more significant. And next thing you know, you are
> > a major
> > contributor. That's how it started for every single active OSS contributor
> > I know.
> > --
> > MK
>
> >http://github.com/michaelklishin
> >http://twitter.com/michaelklishin
>
> > --
> > 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,

Re: Some Friend documentation and regarding documentation in general

[Dave Della Costa]

Hi Chas,

Great, I'm glad you think this is a useful contribution, and thanks for
the encouraging words!

To address some specific points:

> I know that Friend's docs are
> particularly dense, especially for anyone that just wants to use the
> stuff.  That's probably due to my using the docs to talk through the
> library's design more than anything else, in part to help potential
> workflow authors understand what's going on,

Yes, the Friend README is dense, but at the same time it is really 
helpful to have that volume of information there (especially rather than 
not at all).  What I would like to do is help provide some transitional 
material from a more basic integration level up to the level of detail 
you provide in your README.


I'm wondering if you are game for changing that into a structure 
somewhat like how Ring and Compojure are structured--I personally feel 
like those have a great setup:


- Basic high-level information in the main README, with links to
  - Wiki with detailed examples and rationale, and
  - API docs

So, that's my proposal, and I'm happy to do a pull request 
re-structuring the README to fit in this pattern (or something 
else...just one proposal) if you're interested.


Also, it's awesome, but damn, that Tolkien quote is long. ;-)

> in part to provoke
> people into protesting certain decisions (this is my first swing at
> writing an authentication/authorization library, which should petrify
> you... ;-)

I have to be honest and say I am not a security guy either; but I have 
been doing this long enough that I'm not entirely naive about web 
security (and I really doubt you are from what you've written).  It 
seems like you're starting from a good basis by attempting to emulate 
some of the other systems you listed--stuff like Warden (which I'm 
familiar with) and Spring Security (which I have to learn more about).


In the end, I think the best thing is to get the software out there as 
quickly as possible and describe your thought process--exactly as you've 
done.


And once I've implemented more Friend-based apps, I'll have a better 
idea of suggestions to make to improve both architecture and 
security--so I'll speak up when I've got more experience with it.


> I daresay you're getting the jump on me in both directions, which I
> really appreciate.

Great--if you think this is a good direction then I'll keep working on 
all of this stuff.


> I think a good next step would be for me to create a Friend
> organization (of course https://github.com/friend is taken! :-P),

Doh.  Damnit, there's nothing there, that's annoying.  I wonder if we 
could politely ask them to hand it over and see if whoever is there is 
open to the possibility...


Well, another option is to format it like ring:

https://github.com/ring-clojure/ring

...something like "friend-clojure" perhaps?

> so
> that you and others can readily contribute tutorials, example
> projects, and more that can be gradually cultivated into canonical,
> easily-approachable code and content.

Okay, sounds great!  Just let me know, and I'll start adding this stuff 
to that group.


Cheers,
DD

(12/10/07 6:33), Chas Emerick wrote:

Hi Dave,

This is a metric ton of awesome; thank you very much for taking the
time and effort to put all this together.  And, BTW, based on what
I've seen so far, I never would have thought you were new to Clojure.
:-)

cont'd…

On Oct 6, 2012, at 11:49 AM, Dave Della Costa wrote:


I think Chas Emerick writes much better docs than much of what
accompanies most Clojure libraries, but he's quite an advanced
Clojure developer, and he's moving very fast--so as a newbie, I had
difficulty even with his relatively good docs for Friend.  And I
suspect you'll be getting more and more folks from the web
development world in the next few years like me.  So it will be
good to have things from the perspective of someone not just trying
to grok the libraries that exist, but also trying to understand how
Clojure works, and how the eco-system fits together.


Noted re: Friend's docs.  I've actually fallen behind a bit on my
documentation activities this year; both Friend and nREPL are
underdocumented at the moment. I know that Friend's docs are
particularly dense, especially for anyone that just wants to use the
stuff.  That's probably due to my using the docs to talk through the
library's design more than anything else, in part to help potential
workflow authors understand what's going on, in part to provoke
people into protesting certain decisions (this is my first swing at
writing an authentication/authorization library, which should petrify
you... ;-)

I've known for some time that I'd like to have a companion project
that implements all sorts of common usage scenarios that can be
easily pushed up to heroku in order to facilitate experimentation.
Pairing those with end-user-focused tutorials would be even better.
I daresay you're getting the jump on me in both directions, which I
really appreciate.

Preferred business rules engines in or used by Clojure?

[Grant Rettke]

Hi,

May you please share your experience or preferences for rules engines
written in or used from Clojure?

My goal is to:

1. Allow rule definitions separate from the code (though I view rule
definitions as programming to be performed by the programmer).
2. Allow rules to be defined in modules.
3. Provide debugging features such that I may sit with a business
user, and start with a particular scenario of data, and walk them
through how the rules transform the data. The goal is to be able to
answer questions from the business eg "I didn't expect this result,
why is it this way?.
4. Debugging.
5. Nice editing.
6. Find something nice for 3-9 month projects with 2-4 developers; in
other words not looking for an enterprise system with licensing priced
accordingly.
7. Any technology is an option because we can probably use it with
some form of interop.
8. Find something that people use for real work for a long time.
9. Find something that costs not more than a thousand USD.
10. Find something that changes how you think, has materials to help
change that, and gets you down the path of thinking about how to write
system with rules engines rather than shoe-horn them into a corner.

Best wishes,

Grant

-- 
((λ (x) (x x)) (λ (x) (x x)))
http://www.wisdomandwonder.com/
ACM, AMA, COG, IEEE

-- 
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: [CFP] October Amsterdam Clojure -- Saturday October 27

[skuro]

Hi all,

The final schedule is finally online and registrations are open (the event 
is completely FREE to attend, but seating is limited). A full day of 
Clojure fun, with speakers coming from all over Europe. Check out the 
details at:

http://amsclj.nl/october.html
http://lanyrd.com/2012/octamsclj/

Book your seat at:

http://www.meetup.com/The-Amsterdam-Clojure-Meetup-Group/events/74036402/

Thanks,
c.

Il giorno giovedì 19 luglio 2012 19:12:31 UTC+2, skuro ha scritto:
>
> Dear Clojurians,
>
> as it already happened the past two  
> years,
>  
> the Dutch Clojure community will organize the October Amsterdam Clojure 
> 2012, to be held on Saturday, October 27th.
> We're now opening the Call For Presentations, we will give the stage to 
> the best 10 tracks to be voted by the end of September by all the Meetup 
> members.
>
> You can find more info on the (free!) event , 
> the meetup  or 
> go straight to the presentation submission 
> form.
>  
> We will close the CFP on September 12th.
>
> Looking forward to seeing your proposals and meeting you in October in 
> Amsterdam!
> Thanks,
> c.
>

-- 
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: Preferred business rules engines in or used by Clojure?

[Marc Dzaebel]

http://www.jboss.org/drools is a suite of tools. ~100 man years were 
necessary for this open source tool. I would not try to reimplement it in 
Clojure, but it's Java :-)

-- 
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

apply: increase performance by 60% for fixed length

[Marc Dzaebel]

*apply *is slow. However you can increase performance by 60% with the 
following macro, if you have a fixed length in S.

(defmacro *applyn *[n f & s]
(loop [curr `(list* ~@s), n n, vars[] vals[]]
(if(pos? n)
   (let[v(gensym)]
(recur v (dec n) (conj(conj vars v) (if (seq vars) (list 
'next curr) curr))
   (conj vals(list 'first v
  `(let[~@vars] ~(cons f (seq vals))

(let[t(fn[](*apply   *+ '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
100] (t ; ~680 msec
(let[t(fn[](*applyn *10 + '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
100] (t ; ~220 msec

So, if you have inner loops, that must be optimized for performance, you 
might remember this possibility. Even other functions could be optimized 
this way. However, "*premature optimization* is the root of all evil". 
Beside, the generated code is more space consuming.

*Marc*

-- 
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

How do ClojureScript protocol functions work?

[Timothy Baldridge]

While digging through the CLJS sources I've seen that protocols use some
sort of odd bitmask optimization. Is this documented anywhere?

Or as a more general question, is the way protocols are implemented in CLJS
documented at all?

Thanks,

Timothy

-- 
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: How do ClojureScript protocol functions work?

[David Nolen]

On Sun, Oct 7, 2012 at 5:44 PM, Timothy Baldridge wrote:

> While digging through the CLJS sources I've seen that protocols use some
> sort of odd bitmask optimization. Is this documented anywhere?
>
> Or as a more general question, is the way protocols are implemented in
> CLJS documented at all?
>
> Thanks,
>
> Timothy
>

Nothing beyond the source. The bitmask optimization was because V8 was
penalizing us for adding too many non-function properties onto the
prototypes like so:

cljs.core.Vector.prototype.cljs$core$ISeq = true;

This was done to support satisfies?. We can now know that vectors satisfy
ISeq. But as I said above, it turned out as we began implementing the
persistent data structures and implementing many protocols - V8 would
deoptimize when using this approach.

So we needed a different way to encode this information. Every
deftype/record instance now has a 1 or 2 integer fields which represents a
bit mask of all the core protocols that a particular type implements.

V8 stopped penalizing us and this approach has the added benefit of
satisfies? now being nearly as fast as native instanceof.

David

-- 
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: apply: increase performance by 60% for fixed length

[Alan Malloy]

This is nonsense. If s is fixed-size at compile-time, you would never use 
apply to begin with. Why bother with (applyn 10 + [1 2 3 4 5 6 7 8 9 10]) 
when you could just write (+ 1 2 3 4 5 6 7 8 9 10)?

On Sunday, October 7, 2012 2:15:28 PM UTC-7, Marc Dzaebel wrote:
>
> *apply *is slow. However you can increase performance by 60% with the 
> following macro, if you have a fixed length in S.
>
> (defmacro *applyn *[n f & s]
> (loop [curr `(list* ~@s), n n, vars[] vals[]]
> (if(pos? n)
>(let[v(gensym)]
> (recur v (dec n) (conj(conj vars v) (if (seq vars) (list 
> 'next curr) curr))
>(conj vals(list 'first v
>   `(let[~@vars] ~(cons f (seq vals))
>
> (let[t(fn[](*apply   *+ '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
> 100] (t ; ~680 msec
> (let[t(fn[](*applyn *10 + '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
> 100] (t ; ~220 msec
>
> So, if you have inner loops, that must be optimized for performance, you 
> might remember this possibility. Even other functions could be optimized 
> this way. However, "*premature optimization* is the root of all evil". 
> Beside, the generated code is more space consuming.
>
> *Marc*
>

-- 
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: optimized clojurescript->js file throws exception but debug version does not?

[David Nolen]

On Sat, Oct 6, 2012 at 11:14 PM, Andrew  wrote:

> What about the --output_wrapper part?
>
> My clojurescript js never calls the minified foreign library directly:
> What I have is [1] some plain non-optimized javascript that calls [2]
> CodeMirror for the code and position, then calls [3] my clojurescript js to
> find out how to do the requested paredit thing, and then calls [2]
> CodeMirror again to do it.
>
> So [3] never calls [2]
>
> [2] and [3] export stuff so that [1] can call them.
>
> And my problem is that [2] isn't wrapped in an anonymous function. How do
> I get cljsbuild to tell Closure to use --output_wrapper? (Also, I guess
> there's a good reason why it doesn't always wrap its output?)
>

Seems like a simple useful option we should expose.

http://dev.clojure.org/jira/browse/CLJS-388

David

-- 
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

mysql unix domain connection

[Brian Craft]

I'm trying to use clojure.java.jdbc to connect to a mysql server. So far it 
only gives me connection errors. I suspect it's trying to connect over 
tcp/ip instead of unix domain sockets (which are preferred by mysql for 
local connections). Can it make a unix domain connection?

-- 
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

cli latency

[Brian Craft]

The two second

delay to...

do anything...

is making...

me crazy.

I should probably be asking this on a java forum. I'm evaluating clojure 
for a project that needs some number of cli tools (as well as server and 
browser code) to be delivered to customers. Are there any good solutions to 
the start-up delay? I've seen tools that run java as a service, so it's 
always up, but I'm not crazy about the idea of requiring this of our users. 
IIRC emacs had similar problems in the 90's, and the solution was to store 
the initial VM state so it didn't need to be recreated on every invocation. 
I'm probably getting the details wrong. And I expect there's some good 
reason this doesn't work with java. Is there?

-- 
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

compiler: throw Error instead of a string?

[Michal Gornisiewicz]

Hello,


I found an issue with the compiler and/or repl code.

Here, the compiler emits code which throws a string if there's a call with 
incorrect arity:
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L468

Shouldn't this be throwing Error (or a subclass instead)?


One place this is a problem is in the repl, here:
https://github.com/clojure/clojurescript/blob/master/src/cljs/clojure/browser/repl.cljs#L31

which catches js/Error and so doesn't catch the above exception, which is a 
string.

PS - On a related note, how does one catch strings in ClojureScript?



Michal

-- 
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: Smarter code reloading with tools.namespace 0.2.0

[Mika Raento]

Hi

Looks great! I'd just finished writing my own ns declaration parser when I 
found that you'd already put it all together :-)

What I'd like to use this for is re-running affected tests. A 
straightforward way to make this possible would be to make (refresh) return 
the list of reloaded namespaces. I can submit the code to do this if you 
like the idea. I guess an alternative way would be to add some kind of a 
hook mechanism, but that gets more complex in the case where reloading 
fails.

(BTW, I submitted a pull request on github to actually use refresh-dirs)

BR,

   Mika Raento

On Friday, October 5, 2012 4:56:51 PM UTC+3, Stuart Sierra wrote:
>
> Announcing... tools.namespace 0.2.0. Just released, it will reach 
> Maven Central in a few hours. 
>
> Short summary: reload code in the REPL with greater accuracy and 
> awareness of dependencies. 
>
> Full documentation in the README: 
> https://github.com/clojure/tools.namespace 
>
> This is my latest attempt at making REPL development more convenient, 
> building on work that reaches back to Lazytest and some of my earliest 
> contribs. 
>
> It is hopefully a step towards "Never Close a REPL": 
> http://dev.clojure.org/display/design/Never+Close+a+REPL 
>
> Have fun, let me know how it goes! 
> -S 
>

-- 
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: Smarter code reloading with tools.namespace 0.2.0

[Stuart Sierra]

Hi Mika,

Due to the current governing process of the Clojure contributor agreement, 
I cannot accept GitHub pull requests, only patches submitted via 
http://dev.clojure.org/jira

My intent is for the functions in clojure.tools.namespace.repl to be a 
high-level API for direct invocation by users. All the components are 
exposed in the namespaces c.t.n.track, c.t.n.files, etc. You should be able 
to compose the various pieces for different use cases. If you encounter a 
place where this is not possible, let me know and I will look into it.

-S

-- 
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: compiler: throw Error instead of a string?

[David Nolen]

On Sat, Oct 6, 2012 at 4:32 PM, Michal Gornisiewicz wrote:

> Hello,
>
>
> I found an issue with the compiler and/or repl code.
>
> Here, the compiler emits code which throws a string if there's a call with
> incorrect arity:
>
> https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L468
>
> Shouldn't this be throwing Error (or a subclass instead)?
>
>
> One place this is a problem is in the repl, here:
>
> https://github.com/clojure/clojurescript/blob/master/src/cljs/clojure/browser/repl.cljs#L31
>
> which catches js/Error and so doesn't catch the above exception, which is
> a string.
>
> PS - On a related note, how does one catch strings in ClojureScript?
>
>
>
> Michal
>

Thanks for the report. I opened a ticket for this:
http://dev.clojure.org/jira/browse/CLJS-389

David

-- 
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: compiler: throw Error instead of a string?

[Herwig Hochleitner]

Javascript native try-catch is available as the compiler builtin try* form.
cljs.core/try desugars into try* + a type dispatch in catch blocks.

So to catch Strings you would write (try ... (catch js/String e ...)) and
to catch everything (try* ... (catch e ...))

-- 
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: cli latency

[Stuart Sierra]

JVM startup time has always been issue. Various tricks help: client mode, 
smaller heaps, tiered compilation (available in Java 7). Clojure adds 
another layer, which can be partially mitigated with AOT-compilation. But 
you'll never get the kind of instant command-line response that C can give 
you.

The JVM doesn't support saving and restoring an "image" of memory like some 
VMs.

One workaround is to write your command-line tools to run within a 
dedicated "shell" that only has to be started once. Like writing your own 
REPL, but customized for your users.

Also consider alternative backends: ClojureScript can emit code for 
Node.JS, and I think there is an experimental port that compiles to native 
code (via Scheme).

-S

-- 
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: Question on mandatory arguments for -> and ->> macros

[Stuart Sierra]

>From the look of the source, there's no reason why ->> couldn't have 
arity-1. I guess it just doesn't come up much.

-S

-- 
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: Preferred business rules engines in or used by Clojure?

[Stuart Sierra]

Hi Grant,

I am not aware of a rules engine written in Clojure, unless you are willing 
to consider a logic language like Datalog (Datomic) or Prolog (core.logic).

Various rule-based systems exist for Java, but I would expect them to be 
very Java-centric.

-S

-- 
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

File endings proposal for easier cross-compiling

[Jonathan Fischer Friberg]

Hi,

In my opinion, cross-compiler projects is way too complicated to pull off.
When they really shouldn't be.
Therefore, I'm proposing the following file ending scheme:

.clj - detected by all compilers. In a cross-compiler project, .clj files
contains code not specific to the compiler.

.cljj - detected by the jvm compiler, contains jvm specific code.

.cljs - detected by clojurescript, contains clojurescript specific code.

.cljclr - detected by clojureCLR, ...

and so on.

It's important to note that the actual content of the files is not checked.
That is, a .clj file can still
contain compiler-specific code.
Moreover, the point of this scheme is not the actual file endings, but the
fact that each compiler has it's own file ending in addition to .clj.

The advantages of this scheme are:

1. Cross-compiler code becomes ridiculously easy to separate. Say you want
to draw something on-screen, using java2D in the jvm, and a canvas in
javascript.
Then simply create a draw.cljj file for the java2D code, and a draw.cljs
file for the canvas code. Easy!

2. Backwards-compatible with most existing projects.
Since .clj is still detected by all compilers, and .cljs is detected by
clojurescript, existing projects will still be correctly detected and
compiled.


So, what do you think?

Jonathan

-- 
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: cli latency

[Alex Miller]

There are a few people that have worked on this problem for Java and other 
JVM projects by basically NOT starting a new JVM or pre-starting the JVM. 
Some places to start:

- Drip - https://github.com/flatland/drip (targeting Clojure specifically)
- Nailgun - http://www.martiansoftware.com/nailgun/ (used heavily in the 
JRuby world)

Jave SE 6u10 includes the Quick Starter too (really intended for applets) 
preloads class data to make it warm. Not sure if that can be leveraged 
somehow or that anyone has ever tried to specific to Clojure code. 

My impression is that the slow part of starting a Clojure program is not 
the Java startup as much as loading Clojure itself and the Clojure code to 
run. AOT should help some with loading your own code as you won't need to 
compile it.



On Sunday, October 7, 2012 11:50:52 AM UTC-5, Brian Craft wrote:
>
> The two second
>
> delay to...
>
> do anything...
>
> is making...
>
> me crazy.
>
> I should probably be asking this on a java forum. I'm evaluating clojure 
> for a project that needs some number of cli tools (as well as server and 
> browser code) to be delivered to customers. Are there any good solutions to 
> the start-up delay? I've seen tools that run java as a service, so it's 
> always up, but I'm not crazy about the idea of requiring this of our users. 
> IIRC emacs had similar problems in the 90's, and the solution was to store 
> the initial VM state so it didn't need to be recreated on every invocation. 
> I'm probably getting the details wrong. And I expect there's some good 
> reason this doesn't work with java. Is there?
>

-- 
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: cli latency

[Grant Rettke]

On Sun, Oct 7, 2012 at 11:50 AM, Brian Craft  wrote:
> The two second
>
> delay to...
>
> do anything...
>
> is making...
>
> me crazy.

Although JRebel is for JEE, it seems like an interesting thing for a fast REPL.

-- 
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: File endings proposal for easier cross-compiling

[Joseph Smith]

I like the idea of a scheme like this. 


On Oct 8, 2012, at 1:44 AM, Jonathan Fischer Friberg  
wrote:

> Hi,
> 
> In my opinion, cross-compiler projects is way too complicated to pull off. 
> When they really shouldn't be.
> Therefore, I'm proposing the following file ending scheme:
> 
> .clj - detected by all compilers. In a cross-compiler project, .clj files 
> contains code not specific to the compiler.
> 
> .cljj - detected by the jvm compiler, contains jvm specific code.
> 
> .cljs - detected by clojurescript, contains clojurescript specific code.
> 
> .cljclr - detected by clojureCLR, ...
> 
> and so on.
> 
> It's important to note that the actual content of the files is not checked. 
> That is, a .clj file can still
> contain compiler-specific code.
> Moreover, the point of this scheme is not the actual file endings, but the 
> fact that each compiler has it's own file ending in addition to .clj.
> 
> The advantages of this scheme are:
> 
> 1. Cross-compiler code becomes ridiculously easy to separate. Say you want to 
> draw something on-screen, using java2D in the jvm, and a canvas in javascript.
> Then simply create a draw.cljj file for the java2D code, and a draw.cljs file 
> for the canvas code. Easy! 
> 
> 2. Backwards-compatible with most existing projects. 
> Since .clj is still detected by all compilers, and .cljs is detected by 
> clojurescript, existing projects will still be correctly detected and 
> compiled.
> 
> 
> So, what do you think?
> 
> Jonathan
> -- 
> 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 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 Ritz 0.5.0

[bruce li]

2012/10/6 Hugo Duncan 

> bruce li  writes:
>
> > I'm trying ritz and having some issues with SLDB that really confused
> > me. When I switch on the slime-break-on-exception, it seems it sometimes
> > doesn't work. The SLDB buffer won't pop up and I sometimes can see the
> > exceptions in the terminal (but sometimes not :(  ).
>
> Probably https://github.com/pallet/ritz/issues/51


Ah, this is exactly the issue. Thanks a lot!


> > By the way, it seems ritz 0.5.0 does not work with Lein 1. I'm wondering
> if
> > Ritz is planned to support Lein 2 only from then on?
>
> I broke it unintentionally - I wonder how many are still using lein1.
> Continuing to support lein 1 is obviously more complicated, but should
> be feasible.

I got it. Now I'm trying to switch to lein 2. Thanks again.

-- 
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: a Clojure docs site, and github organization

[gaz jones]

While on this topic, is it possible for someone with admin privileges
to disable the "Issues" tabs in the contrib projects? There is a
consistent drip of people sending pull requests or opening bugs which
have to be redirected to JIRA. All of the contrib projects now point
to JIRA in the README for both these things.

On Sun, Oct 7, 2012 at 2:40 AM, nchurch  wrote:
>> Just to keep in touch with our marvelous legal systems in North America, 
>> read this:
> ...
>> how much I am frustrated by this shattered world
>
> Indeed!  The law is nothing but an overly complex, haphazardly
> designed, historically encrufted programming language for morals.
>
> Its compiler is frighteningly well-maintained, though.
>
> On Oct 6, 6:24 pm, Softaddicts  wrote:
>> It works for Oracle because they have the $$$ to support it. You just 
>> confirmed
>> that we are on the same wavelength, they have the weapons to nail anyone who
>> would like to exercise exclusive rights on some contribution made under 
>> their CA
>> even if that individual lives in Kazakhstan.
>>
>> They have the infra structure and several offices in various
>> Countries and continents to cover their ass.
>>
>> Just to keep in touch with our marvelous legal systems in North America, 
>> read this:
>>
>> http://hrdailyadvisor.blr.com/archive/2010/08/20/Epinions_Employment_...
>>
>> The first question/answer is pretty instructive. It's easier to avoid the 
>> whole issue
>> with a piece of paper. Maybe in ten years things will have settled somehow.
>> The above is dated from 2010 that's not far away.
>>
>> I will not anything else to this thread, the world is as it is. I you think 
>> that you are
>> frustrated, maybe we should have a drink together and I could explain how
>> much I am frustrated by this shattered world
>>
>> Do you expect to drop at the Conj ?
>>
>> Luc
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > 2012/10/7 Softaddicts 
>>
>> > > The validity of a scanned signature or electronic keys is subject to
>> > > interpretation
>> > > and assessment on a per case basis especially in civil contracts by the
>> > > diverse
>> > > legal systems on Earth.
>>
>> > > It's not the Clojure community that is behind, it's the legal systems of
>> > > many countries
>> > > that did not follow the pace of technology. Some will not recognize
>> > > scanned signatures
>> > > at all.
>>
>> > > On the other hand, original hand written signatures are recognized almost
>> > > every where.
>>
>> > A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many
>> > lawyers as
>> > Clojure/core, lawyers several times as experienced and about x10,000 times
>> > as much experience with this stuff as a company. And it works for them.
>>
>> > > As much as you complain about the paper CA, you should complain about
>> > > the legal systems of these countries that do not follow US and western
>> > > Europe
>> > > attempts to recognize technology changes and adapt to it.
>>
>> > > You analyze the issue by the wrong end
>>
>> > > It's not a technology issue, it's a legal one.
>>
>> > > You could have the best electronic authentication scheme, if it's not
>> > > recognized by a country's legal system, it's useless in court in this
>> > > country.
>> > > If claims rights on contributions not backed by a CA in a valid form as
>> > > defined in this
>> > > country, it's a lost case.
>>
>> > > Big organizations have the tools and budgets to fight in various legal
>> > > systems
>> > > out there. Not small open source projects or projects without big 
>> > > sponsors.
>>
>> > > I understand and approve the requirement of the original hand written
>> > > signature in
>> > > this context. That's a real life issue that cannot be dealt with by
>> > > technology alone.
>>
>> > > If a national mail system is not able to get reliably an envelope to the 
>> > > US
>> > > within 4/5 weeks, I would be very concerned about the state of their 
>> > > legal
>> > > system.
>>
>> > Sorry to break it to you, but legal systems outside of a few countries are
>> > seriously
>> > broken and it will take decades and many lives to fix this. And I assure
>> > you, people who
>> > live in those countries are just as concerned as you are, thanks for 
>> > caring.
>>
>> > So the system is how it is. Clojure/core can
>> > accept this unfortunate fact and find a way to accept CA submissions
>> > electronically.
>>
>> > Or they can ignore all the complaints (again, not about the CA per se, but
>> > how it is currently submitted) and lose many potential contributions.
>>
>> > Contributions from people who really want to make Clojure better, ready to
>> > spend
>> > many hours of their time contributing but were not lucky enough to be born
>> > in the Wonderland called Canada, where the law rules and the sun shines (at
>> > least 2 months of the year).
>>
>> > It always starts with contributing something small. Then something else
>> > small.
>> > Then something slightly more significant. And next thing you kno

Re: ANN: a Clojure docs site, and github organization

[John Gabriele]

On Sunday, October 7, 2012 9:32:45 PM UTC-4, Gaz wrote:
>
> While on this topic, is it possible for someone with admin privileges 
> to disable the "Issues" tabs in the contrib projects? There is a 
> consistent drip of people sending pull requests or opening bugs which 
> have to be redirected to JIRA. All of the contrib projects now point 
> to JIRA in the README for both these things. 
>
>
Maybe ping this thread (which I see you participated in) listing the libs 
that still have "Issues" enabled:

https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/9ZTZXdBR6XU

---John

-- 
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: apply: increase performance by 60% for fixed length

[Ben Wolfson]

On Sun, Oct 7, 2012 at 3:53 PM, Alan Malloy  wrote:
> This is nonsense. If s is fixed-size at compile-time, you would never use
> apply to begin with. Why bother with (applyn 10 + [1 2 3 4 5 6 7 8 9 10])
> when you could just write (+ 1 2 3 4 5 6 7 8 9 10)?

Why bother to write (+ 1 2 3 4 5 6 7 8 9 10) when you could just write 55?

In order to write (+ 1 2 3 4 5 6 7 ...) you need more than just the
length of the list, you need to know its contents as well.

(let [s (take 10 (infinite-stream-of-random-integers))] (applyn 10 + s))

will work right---you know the length of s---but you're not going to
be able to just directly apply +.

I'm skeptical for a different reason:

user=> (let[t(fn[](apply   + '(1 2 3 4 5 6 7 8 9 10)))]
(time(dotimes [_ 100] (t
"Elapsed time: 1736.91518 msecs"
nil
user=> (let[t(fn[](applyn 10 + '(1 2 3 4 5 6 7 8 9 10)))]
(time(dotimes [_ 100] (t
"Elapsed time: 2375.503756 msecs"
nil

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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: apply: increase performance by 60% for fixed length

[Wes Freeman]

What version of clojure are you guys using, just to understand this a
little better? I think apply was given a boost in 1.3 or 1.4--I'm a
relative newbie, myself.

Wes

On Sun, Oct 7, 2012 at 10:56 PM, Ben Wolfson  wrote:

> On Sun, Oct 7, 2012 at 3:53 PM, Alan Malloy  wrote:
> > This is nonsense. If s is fixed-size at compile-time, you would never use
> > apply to begin with. Why bother with (applyn 10 + [1 2 3 4 5 6 7 8 9 10
> ])
> > when you could just write (+ 1 2 3 4 5 6 7 8 9 10)?
>
> Why bother to write (+ 1 2 3 4 5 6 7 8 9 10) when you could just write 55?
>
> In order to write (+ 1 2 3 4 5 6 7 ...) you need more than just the
> length of the list, you need to know its contents as well.
>
> (let [s (take 10 (infinite-stream-of-random-integers))] (applyn 10 + s))
>
> will work right---you know the length of s---but you're not going to
> be able to just directly apply +.
>
> I'm skeptical for a different reason:
>
> user=> (let[t(fn[](apply   + '(1 2 3 4 5 6 7 8 9 10)))]
> (time(dotimes [_ 100] (t
> "Elapsed time: 1736.91518 msecs"
> nil
> user=> (let[t(fn[](applyn 10 + '(1 2 3 4 5 6 7 8 9 10)))]
> (time(dotimes [_ 100] (t
> "Elapsed time: 2375.503756 msecs"
> nil
>
> --
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks,
> which may be sweet, aromatic, fermented or spirit-based. ... Family
> and social life also offer numerous other occasions to consume drinks
> for pleasure." [Larousse, "Drink" entry]
>
> --
> 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 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: Preferred business rules engines in or used by Clojure?

[Leandro Oliveira]

https://github.com/hraberg/mimir

The author call it experimenta, but seems nice.

[ ]s
Leandro.

On Sun, Oct 7, 2012 at 8:33 PM, Stuart Sierra
wrote:

> Hi Grant,
>
> I am not aware of a rules engine written in Clojure, unless you are
> willing to consider a logic language like Datalog (Datomic) or Prolog
> (core.logic).
>
> Various rule-based systems exist for Java, but I would expect them to be
> very Java-centric.
>
> -S
>
>
>  --
> 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 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: Question on mandatory arguments for -> and ->> macros

[Shantanu Kumar]

On Monday, 8 October 2012 04:57:06 UTC+5:30, Stuart Sierra wrote:
>
> From the look of the source, there's no reason why ->> couldn't have 
> arity-1. I guess it just doesn't come up much.
>

Arity-1 for ->> would be useful to let somebody comment out forms as 
follows:

(->> foo
  #_(bar baz)
  #_quux)

I can file an issue on JIRA if this makes sense.

Shantanu

-- 
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: apply: increase performance by 60% for fixed length

[Alan Malloy]

On Sunday, October 7, 2012 7:56:53 PM UTC-7, Ben wrote:
>
> On Sun, Oct 7, 2012 at 3:53 PM, Alan Malloy > 
> wrote: 
> > This is nonsense. If s is fixed-size at compile-time, you would never 
> use 
> > apply to begin with. Why bother with (applyn 10 + [1 2 3 4 5 6 7 8 9 
> 10]) 
> > when you could just write (+ 1 2 3 4 5 6 7 8 9 10)? 
>
> Why bother to write (+ 1 2 3 4 5 6 7 8 9 10) when you could just write 55? 
>
> In order to write (+ 1 2 3 4 5 6 7 ...) you need more than just the 
> length of the list, you need to know its contents as well. 
>
> (let [s (take 10 (infinite-stream-of-random-integers))] (applyn 10 + s)) 
>
> will work right---you know the length of s---but you're not going to 
> be able to just directly apply +. 
>

Of course apply will work fine. 
 
user> (apply + (take 10 (range)))
45

All applyn does is make the argument-unpacking code happen in your clojure 
source file instead of in RestFn.java, which is optimized for it, in 
exchange for the extremely small cost of dispatching on length. And since + 
only has different definitions for 0, 1, 2, or more arguments, that just 
means checking whether the argument sequence is 0, 1, 2, or more items 
long. 

-- 
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: apply: increase performance by 60% for fixed length

[Ben Wolfson]

On Sun, Oct 7, 2012 at 10:02 PM, Alan Malloy  wrote:
> On Sunday, October 7, 2012 7:56:53 PM UTC-7, Ben wrote:
>>
>> On Sun, Oct 7, 2012 at 3:53 PM, Alan Malloy  wrote:
>> > This is nonsense. If s is fixed-size at compile-time, you would never
>> > use
>> > apply to begin with. Why bother with (applyn 10 + [1 2 3 4 5 6 7 8 9
>> > 10])
>> > when you could just write (+ 1 2 3 4 5 6 7 8 9 10)?
>>
>> Why bother to write (+ 1 2 3 4 5 6 7 8 9 10) when you could just write 55?
>>
>> In order to write (+ 1 2 3 4 5 6 7 ...) you need more than just the
>> length of the list, you need to know its contents as well.
>>
>> (let [s (take 10 (infinite-stream-of-random-integers))] (applyn 10 + s))
>>
>> will work right---you know the length of s---but you're not going to
>> be able to just directly apply +.
>
>
> Of course apply will work fine.

What I meant by "directly apply +" wasn't "call apply with first
argument +", but "call (+ 1 2 ...)". I was responding to your
suggestion that one just write (+ 1 2 3 4 5 6 7 8 9 10).

> All applyn does is make the argument-unpacking code happen in your clojure
> source file instead of in RestFn.java, which is optimized for it, in
> exchange for the extremely small cost of dispatching on length.

Sure, but that's a different reason for finding applyn silly than the
one you initially gave, which was that one could bypass calling apply
altogether and just write (+ 1 2 ...).

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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: apply: increase performance by 60% for fixed length

[Ben Wolfson]

On Sun, Oct 7, 2012 at 8:01 PM, Wes Freeman  wrote:
> What version of clojure are you guys using, just to understand this a little
> better? I think apply was given a boost in 1.3 or 1.4--I'm a relative
> newbie, myself.

Ah using 1.4 I do see a speedup:

clojure-test.core> (let[t(fn[](apply   + '(1 2 3 4 5 6 7 8 9
10)))] (time(dotimes [_ 100] (t
"Elapsed time: 832.403941 msecs"
nil
clojure-test.core> (let[t(fn[](applyn 10   + '(1 2 3 4 5 6 7 8 9
10)))] (time(dotimes [_ 100] (t
"Elapsed time: 368.181313 msecs"
nil

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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: cli latency

[Shantanu Kumar]

Another option is Avian if it works for you: http://oss.readytalk.com/avian/


On Monday, 8 October 2012 05:22:53 UTC+5:30, Alex Miller wrote:
>
> There are a few people that have worked on this problem for Java and other 
> JVM projects by basically NOT starting a new JVM or pre-starting the JVM. 
> Some places to start:
>
> - Drip - https://github.com/flatland/drip (targeting Clojure specifically)
> - Nailgun - http://www.martiansoftware.com/nailgun/ (used heavily in the 
> JRuby world)
>
> Jave SE 6u10 includes the Quick Starter too (really intended for applets) 
> preloads class data to make it warm. Not sure if that can be leveraged 
> somehow or that anyone has ever tried to specific to Clojure code. 
>
> My impression is that the slow part of starting a Clojure program is not 
> the Java startup as much as loading Clojure itself and the Clojure code to 
> run. AOT should help some with loading your own code as you won't need to 
> compile it.
>
>
>
> On Sunday, October 7, 2012 11:50:52 AM UTC-5, Brian Craft wrote:
>>
>> The two second
>>
>> delay to...
>>
>> do anything...
>>
>> is making...
>>
>> me crazy.
>>
>> I should probably be asking this on a java forum. I'm evaluating clojure 
>> for a project that needs some number of cli tools (as well as server and 
>> browser code) to be delivered to customers. Are there any good solutions to 
>> the start-up delay? I've seen tools that run java as a service, so it's 
>> always up, but I'm not crazy about the idea of requiring this of our users. 
>> IIRC emacs had similar problems in the 90's, and the solution was to store 
>> the initial VM state so it didn't need to be recreated on every invocation. 
>> I'm probably getting the details wrong. And I expect there's some good 
>> reason this doesn't work with java. Is there?
>>
>

-- 
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: apply: increase performance by 60% for fixed length

[Jean Niklas L'orange]

On Sunday, October 7, 2012 11:15:28 PM UTC+2, Marc Dzaebel wrote:
>
> *apply *is slow. However you can increase performance by 60% with the 
> following macro, if you have a fixed length in S. 


> [...]
>
> (let[t(fn[](*apply   *+ '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
> 100] (t ; ~680 msec
> (let[t(fn[](*applyn *10 + '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
> 100] (t ; ~220 msec
>

Interesting, even though it's impractical to use it on an already defined 
list. Usually, I want to work with list or sequences I've generated with 
other functions, like so:

(let[t(fn[](applyn 10 + (range 1 11)))] (time(dotimes [_ 100] (t ; 
~ 950 msec
(let[t(fn[](applyn + (range 1 11)))] (time(dotimes [_ 100] (t ; ~ 
940 msec

(In addition, apply is in this case is not really what you want to do with 
this list - you should use reduce instead.)
(let[t(fn[](reduce + (range 1 11)))] (time(dotimes [_ 100] (t ; ~ 
890 msec

Curiously, if I vec the result, I get a completely different answer:

(let[t(fn[](applyn 10 + (vec (range 1 11] (time(dotimes [_ 100] 
(t ; ~ 1330 msec
(let[t(fn[](apply + (vec (range 1 11] (time(dotimes [_ 100] (t 
; ~ 1410 msec
(let[t(fn[](reduce + (vec (range 1 11] (time(dotimes [_ 100] (t 
; ~ 1340 msec

This is hardly any scientific test though, so I'll leave the conclusion to 
someone with a more rigorous testing scheme.

-- 
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