Re: What is the status of Clojure on LLVM or C?

[Marko Topolnik]

On Thursday, March 28, 2013 10:45:53 PM UTC+1, Laurent PETIT wrote:
>
> 2013/3/28 Marko Topolnik >: 
> > Or you may have just a trivial requirement for a program that both 
> starts 
> > and executes quickly. 
>
> To what extent would an LLVM / C version of a Clojure program not 
> incur startup penalty as the JVM does. 
>
> As far as I understand it, the startup cost is manyfold: 
> 1/ JVM startup 
> 2/ loading of Clojure Core 
> 3/ loading of non-lazy parts of your application (generally from 
> loading a global namespace to invoke its -main function) 
>

Yes, the problems are wider than just JVM startup. My point is that Clojure 
can't be used to build "small-is-beautiful" programs that contribute to the 
standard *nix toolchain---at least not those that don't do enough massive 
work to dwarf the initialization costs. I am comparing this to Common Lisp 
in the '80s, where both startup time and execution speed were goals held in 
high regard. Someone looking for an LLVM implementation may be having just 
such a use case in mind.

-marko

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Thu, Mar 28, 2013 at 9:26 PM, Mikera  wrote:
> On Friday, 29 March 2013 05:45:53 UTC+8, Laurent PETIT wrote:
>>
>> 2013/3/28 Marko Topolnik :
>> > Or you may have just a trivial requirement for a program that both
>> > starts
>> > and executes quickly.
>>
>> To what extent would an LLVM / C version of a Clojure program not
>> incur startup penalty as the JVM does.
>>
>> As far as I understand it, the startup cost is manyfold:
>> 1/ JVM startup
>> 2/ loading of Clojure Core
>> 3/ loading of non-lazy parts of your application (generally from
>> loading a global namespace to invoke its -main function)
>
> In my experience 1) is a small fraction of the total. A trivial "hello
> world" Java program runs in less than 0.1sec on my machine, which proves
> that JVM startup isn't really important. Or at least, far less important
> than most people think.

I certainly don't see that.  I've measured this more than a few times,
and it's several seconds for a simple "Hello World" Java application
on any machine that I can touch.  Additionally, on an embedded system,
I'm not going to have the same kind of CPU power.  For instance, the
current processor we use runs at 400MHz instead of your desktop's
3GHz.

[snip]
> It might even be slower in LLVM / C, unless you can at least match the JVM
> in terms of JIT optimisation and garbage collector efficiency, which in turn
> affects the runtime for 2+3 (I believe a garbage collector is a requirement
> to execute Clojure?). Beating the JVM isn't an easy feat.

You could argue the same for any application written in C, though I
think in practice C keeps up pretty well.  However, raw execution
speed isn't necessarily my goal.  More interesting to me is having
better tools to use.  Clojure's approach to concurrent programming is
world's better that the "share everything" approach used in C, and
it's that facility that I'd like to use the most.  But requiring the
JVM to use it--in my environment--is just too high of a price to pay.
To be honest, LLVM might be too high as well.  LLVM is certainly far
from small and lightweight. :-)

-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
--- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Marko Topolnik]

> I certainly don't see that.  I've measured this more than a few times, 
> and it's several seconds for a simple "Hello World" Java application 
> on any machine that I can touch.  Additionally, on an embedded system, 
> I'm not going to have the same kind of CPU power.  For instance, the 
> current processor we use runs at 400MHz instead of your desktop's 
> 3GHz. 
>

In fairness to Java, your measurements are the exception, not Mikera's. For 
example:

$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
$ echo 'public class Test { public static void main(String... args) { 
System.out.println("Hello"); } }' > Test.java
$ javac Test.java
$ time java Test
Hello

real 0m0.137s
user 0m0.097s
sys 0m0.034s

-marko

-- 
-- 
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/groups/opt_out.

status update on uWSGI + Ring

[Roberto De Ioris]

Hi everyone, uWSGI 1.9 (the first official release supporting clojure/ring)
has been released some week ago and three minor releases followed it.

Thanks to the reports of a bunch of clojure users and the work of Mingli
Yuan i am pleased to announce that the whole ring test-suite passes on
uWSGI+ring.

Docs ring-specific are available here:

http://uwsgi-docs.readthedocs.org/en/latest/Ring.html

(feel free to contribute if you have cool use-cases, the repository is here
https://github.com/unbit/uwsgi-docs)

but i always suggest to give a look here:

http://uwsgi-docs.readthedocs.org/en/latest/JVM.html

to understand some of the internals and the available features.


-- 
Roberto De Ioris
http://unbit.it

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Fri, Mar 29, 2013 at 5:28 AM, Marko Topolnik
 wrote:
>
>> I certainly don't see that.  I've measured this more than a few times,
>> and it's several seconds for a simple "Hello World" Java application
>> on any machine that I can touch.  Additionally, on an embedded system,
>> I'm not going to have the same kind of CPU power.  For instance, the
>> current processor we use runs at 400MHz instead of your desktop's
>> 3GHz.
>
>
> In fairness to Java, your measurements are the exception, not Mikera's. For
> example:
>
> $ java -version
> java version "1.7.0_17"
> Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> $ echo 'public class Test { public static void main(String... args) {
> System.out.println("Hello"); } }' > Test.java
> $ javac Test.java
> $ time java Test
> Hello
>
> real 0m0.137s
> user 0m0.097s
> sys 0m0.034s

Hmmm... perhaps I was testing something more full-fledged (though not
a server application) that could be used as a skeleton for a
command-line tool.  I'll have to check.  I'm not seeing it be that
fast on my current machine, but is less that 1 second with Java
6--though this machine is rather powerful.

Still, it's not going to be that fast on a 400MHz ARM. :-)

-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
--- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Mikera]

I decided to benchmark JVM startup again, in case of any doubt, and because 
I see plenty of FUD on this issue.

Code is 
here: 
https://github.com/mikera/miscellania/blob/master/src/main/java/hello/world/App.java
timecmd bat file use to benchmark is in this SO 
answer: http://stackoverflow.com/a/6209392/214010

C:\xxx> java -version
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

C:\xxx> timecmd java -cp miscellania.jar hello.world.App
Hello World!
command took 0:0:0.10 (0.10s total)

As you can see JVM startup is 0.1s or less: in fact the entire execution of 
Hello World took 0.1 sec on my machine. Note that this is the server VM. I 
did about 20 successive runs which were all in the 0.08 to 0.12 sec range.

On Friday, 29 March 2013 17:02:34 UTC+8, John Szakmeister wrote:

> On Thu, Mar 28, 2013 at 9:26 PM, Mikera > 
> wrote: 
> > On Friday, 29 March 2013 05:45:53 UTC+8, Laurent PETIT wrote: 
> >> 
> >> 2013/3/28 Marko Topolnik : 
> >> > Or you may have just a trivial requirement for a program that both 
> >> > starts 
> >> > and executes quickly. 
> >> 
> >> To what extent would an LLVM / C version of a Clojure program not 
> >> incur startup penalty as the JVM does. 
> >> 
> >> As far as I understand it, the startup cost is manyfold: 
> >> 1/ JVM startup 
> >> 2/ loading of Clojure Core 
> >> 3/ loading of non-lazy parts of your application (generally from 
> >> loading a global namespace to invoke its -main function) 
> > 
> > In my experience 1) is a small fraction of the total. A trivial "hello 
> > world" Java program runs in less than 0.1sec on my machine, which proves 
> > that JVM startup isn't really important. Or at least, far less important 
> > than most people think. 
>
> I certainly don't see that.  I've measured this more than a few times, 
> and it's several seconds for a simple "Hello World" Java application 
> on any machine that I can touch.  Additionally, on an embedded system, 
> I'm not going to have the same kind of CPU power.  For instance, the 
> current processor we use runs at 400MHz instead of your desktop's 
> 3GHz. 
>

I suggest you recheck your measurement approach / configuration. See above 
:-)

Agreed that any embedded processor is likely much slower than a PC (mine is 
a laptop in fact). And IO speed probably makes a big difference as well if 
there are caching effects / large .jar files to load.
 

>
> [snip] 
> > It might even be slower in LLVM / C, unless you can at least match the 
> JVM 
> > in terms of JIT optimisation and garbage collector efficiency, which in 
> turn 
> > affects the runtime for 2+3 (I believe a garbage collector is a 
> requirement 
> > to execute Clojure?). Beating the JVM isn't an easy feat. 
>
> You could argue the same for any application written in C, though I 
> think in practice C keeps up pretty well.  However, raw execution 
> speed isn't necessarily my goal.  More interesting to me is having 
> better tools to use.  Clojure's approach to concurrent programming is 
> world's better that the "share everything" approach used in C, and 
> it's that facility that I'd like to use the most.  But requiring the 
> JVM to use it--in my environment--is just too high of a price to pay. 
> To be honest, LLVM might be too high as well.  LLVM is certainly far 
> from small and lightweight. :-) 
>

Agreed - the JVM is a poor fit for very tightly constrained environments. 
Excited to see what you can achieve here! 

Just don't knock the JVM unfairly, it is one of the best tools we have :-)

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Fri, Mar 29, 2013 at 5:49 AM, Mikera  wrote:
> I decided to benchmark JVM startup again, in case of any doubt, and because
> I see plenty of FUD on this issue.

Sorry, I don't mean to spread any FUD.  I'm just being loose with the
phrase "start-up time".  You're right, I should be more precise in my
terminology.  FWIW, I think when people talk about this, they're doing
the same thing: including the class loading overhead for something
other than the most trivial of examples.

[snip]
> As you can see JVM startup is 0.1s or less: in fact the entire execution of
> Hello World took 0.1 sec on my machine. Note that this is the server VM. I
> did about 20 successive runs which were all in the 0.08 to 0.12 sec range.

Yes.  It's about double that on my machine, but within reach.

[snip]
>> I certainly don't see that.  I've measured this more than a few times,
>> and it's several seconds for a simple "Hello World" Java application
>> on any machine that I can touch.  Additionally, on an embedded system,
>> I'm not going to have the same kind of CPU power.  For instance, the
>> current processor we use runs at 400MHz instead of your desktop's
>> 3GHz.
>
> I suggest you recheck your measurement approach / configuration. See above
> :-)

Okay.  I pushed up a barebones example of a command line application
here: https://github.com/jszakmeister/barebones

Really, it's just Clojure plus tools.cli, and a small snippet in main.
 Running this 10 times, I'm seeing about 3.07s on my machine to
execute this example.  I built in with "lein2 uberjar", and did:

:: time java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar
{:faux bar, :help false}
Hello, World!
java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar  3.09s user
0.28s system 186% cpu 1.804 total

:: java -version
java version "1.6.0_43"
Java(TM) SE Runtime Environment (build 1.6.0_43-b01-447-10M4203)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01-447, mixed mode)

> Agreed that any embedded processor is likely much slower than a PC (mine is
> a laptop in fact). And IO speed probably makes a big difference as well if
> there are caching effects / large .jar files to load.

Definitely.

[snip]
> Agreed - the JVM is a poor fit for very tightly constrained environments.
> Excited to see what you can achieve here!
>
> Just don't knock the JVM unfairly, it is one of the best tools we have :-)

I don't mean to do that.  The JVM is an amazing piece of software.  I
just happen to be in circles where folks believe it's the answer to
everything, and unfortunately, it's not.  It has some limitations and
it isn't well-suited to every problem.  Even at 100ms for the start-up
time, that's still pretty non-trivial for a command line application.
The real question is whether we can get something like the barebones
example to fire up and run in a similar amount of time.

As you said: I'm excited to see what can be achieved in this space!

-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
--- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Marko Topolnik]

On Friday, March 29, 2013 11:37:36 AM UTC+1, John Szakmeister wrote:

> On Fri, Mar 29, 2013 at 5:49 AM, Mikera > 
> wrote: 
> > I decided to benchmark JVM startup again, in case of any doubt, and 
> because 
> > I see plenty of FUD on this issue. 
>
> Okay.  I pushed up a barebones example of a command line application 
> here: https://github.com/jszakmeister/barebones 
>
> Really, it's just Clojure plus tools.cli, and a small snippet in main. 
>  Running this 10 times, I'm seeing about 3.07s on my machine to 
> execute this example.  I built in with "lein2 uberjar", and did: 
>
> :: time java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar 
> {:faux bar, :help false} 
> Hello, World! 
> java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar  3.09s user 
> 0.28s system 186% cpu 1.804 total 
>
> :: java -version 
> java version "1.6.0_43" 
> Java(TM) SE Runtime Environment (build 1.6.0_43-b01-447-10M4203) 
> Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01-447, mixed mode) 
>

Yes, you are involving Clojure startup here, which turns the tables 
altogether. This is far more work than just Java startup: all the 
namespaces must be initialized: all their def'd values calculated at 
runtime and assigned. Some of these may involve quite heavyweight service 
startup. This is the real issue in the Clojure startup story: it is not 
aggressively optimized towards zero startup time. It is a problem that 
carries over to other underlying implementations.

-marko

-- 
-- 
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/groups/opt_out.

Re: appengine-magic leiningen plugin and template

[Gregg Reynolds]

On Thursday, March 28, 2013 5:29:54 AM UTC-5, Gregg Reynolds wrote:
>
> Hi,
>
> People working with appengine--magic might be interested in a 
> template-and-plugin pair I've put together over the past week.  This is my 
> first crack at leiningen (and I'm fairly new to Clojure as well), so 
> comments and suggests would be helpful.
>

Update:  figured out how to make gaem/gaem-template work with multiple 
servlets using the dev_appserver that comes with the gae sdk.  Multiple 
servlets won't work with the repl; you have to use one monolithic servlet. 
 Also fixed some bugs in the mustache templating. So the gaem-template 
should work out of the box on both dev_appserver and uploaded to GAE.

Cheers,

Gregg

-- 
-- 
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/groups/opt_out.

Jenkins plugins in clojure

[Erlis Vidal]

Hi guys,

I was just wondering if someone in the group have written any jenkins
plugin using clojure not java as programming language?

I'm about to start writing a plugin but I would like to use this
opportunity and use clojure.

Anyone have any information about this?

Thanks!
Erlis

-- 
-- 
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/groups/opt_out.

WAT? BigInt instead of Long?

[Peter Mancini]

(class 1) java.lang.Long ;check!
(class (* (/ 1 255) 254)) clojure.lang.Ratio ;check!
(class (* (/ 1 255) 255)) clojure.lang.BigInt ;WAT?

Should not example 3 and example 1 end up the same? (Noob question, I know, 
but this didn't make sense to me and I thought I was doing something wrong 
when I saw 1N coming back.)

-- 
-- 
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/groups/opt_out.

Re: [ANN] http-kit 2.0.0 released

[xumingmingv]

Good Job!

在 2013-3-29，下午2:03，"Shen, Feng"  写道：

> Hello folks. 
> 
> I just released version 2.0.0 of http-kit. 
> 
> 
> 2.0.0 (2013/3/29)
> Unify WebSocket and HTTP long polling/streaming with Channel protocol and 
> with-channel (API breaks with the RC)
> WebSocket support sending and receiving binary frame with byte[]
> Support HTTP streaming
> WebSocket message ordering is guaranteed by server
> 
> Updated documentation: http://http-kit.org/server.html
> 
> Let's build amazing realtime applications with Clojure, using http-kit.
> 
> The with-channel API is not compatible with the RC releases. The new is 
> better and much easier to understand and use. The old's documentation can be 
> found here
> 
> - feng
> 
> -- 
> -- 
> 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/groups/opt_out.
>  
>  

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Ryan Neufeld]

Hey, sorry for the delay in answering your question Michael.

We will definitely be accepting pull requests. In fact, we've already 
accepted a few minor pulls from community members.

I know you've been an outspoken critic of the Clojure contribution process 
- we understand that pain, and want to do things differently with Pedestal. 
This means Github for issues and pull-requests, easy-to-submit CAs, etc. 
Hopefully once we've proven out these more modern workflows we can start to 
backport them into the Clojure process.

I have to ask you this: is there anything we've missed, or do you have any 
suggestions you'd like implemented in the Pedestal project?

- Ryan @ Relevance

On Sunday, March 24, 2013 12:30:10 AM UTC-4, Michael Klishin wrote:
>
>
> 2013/3/24 Sean Corfield >
>
>> Contributor Agreements were available for signing at Clojure/West so
>> I'm guessing it will be under the same process as Clojure itself...
>>
>
> They have electronic CA:
> http://pedestal.io/#contribute
>
> My question is about pull requests, not the CA.
> -- 
> 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, 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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Michael Klishin]

2013/3/29 Ryan Neufeld 

> This means Github for issues and pull-requests, easy-to-submit CAs, etc.
> Hopefully once we've proven out these more modern workflows we can start to
> backport them into the Clojure process.
>
> I have to ask you this: is there anything we've missed, or do you have any
> suggestions you'd like implemented in the Pedestal project?
>

Ryan,

This is very good news. One thing I'd like to see is a way for the
community to contribute to pedestal.io (the site)
using the same process.

Thanks to everyone involved in these process improvements for Pedestal. I
have doubts that Clojure will ever be developed
the same way but it's great to see Pedestal not following the route of
Clojure Contrib.
-- 
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, 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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Rich Morin]

On Mar 29, 2013, at 03:44, Marko Topolnik wrote:
> Yes, you are involving Clojure startup here, which turns the tables
> altogether. This is far more work than just Java startup: all the
> namespaces must be initialized: all their def'd values calculated
> at runtime and assigned. Some of these may involve quite heavyweight
> service startup. This is the real issue in the Clojure startup story:
> it is not aggressively optimized towards zero startup time. It is a
> problem that carries over to other underlying implementations.

So, a naive question.  How much of this work could be pre-calculated
and/or deferred until the values are needed?

-r

 -- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation


-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Herwig Hochleitner]

2013/3/29 Marko Topolnik 

> Yes, you are involving Clojure startup here, which turns the tables
> altogether. This is far more work than just Java startup: all the
> namespaces must be initialized: all their def'd values calculated at
> runtime and assigned. Some of these may involve quite heavyweight service
> startup. This is the real issue in the Clojure startup story: it is not
> aggressively optimized towards zero startup time. It is a problem that
> carries over to other underlying implementations.
>

The opposite is also true and weighs more heavy in this case, I think. Java
is not optimized for good startup times. In particular, you can't embed any
composite constants in byte code. Not even arrays. That means every last
piece of metadata has to be allocated and built from scratch at startup.
Every class for every toplevel fn has to be loaded (a process that involves
deserialization aswell), initialized and instantiated.

In a native code implementation of clojure, all the statically known
functions, data and metadata structures could be directly embedded into the
binary. Thus the init cost of a namespace with defn as the only toplevel
forms could be near zero.

-- 
-- 
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/groups/opt_out.

EDN syntax document contains an apparent omission.

[Cedric Greevey]

https://github.com/edn-format/edn#equality should probably mention keywords
in this list:

"nil, booleans, strings, characters, and symbols are equal to values of the
same type with the same edn representation."

-- 
-- 
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/groups/opt_out.

Re: EDN syntax document contains an apparent omission.

[Andy Fingerhut]

Up at the top of the page you link to, there is a button labeled "Issues"
(at least if you are logged in with a free-to-create Github account), and
you can create an issue for this there.

Andy

On Fri, Mar 29, 2013 at 10:01 AM, Cedric Greevey  wrote:

> https://github.com/edn-format/edn#equality should probably mention
> keywords in this list:
>
> "nil, booleans, strings, characters, and symbols are equal to values of
> the same type with the same edn representation."
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Cedric Greevey]

On Fri, Mar 29, 2013 at 11:26 AM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2013/3/29 Ryan Neufeld 
>
>> This means Github for issues and pull-requests, easy-to-submit CAs, etc.
>> Hopefully once we've proven out these more modern workflows we can start to
>> backport them into the Clojure process.
>>
>> I have to ask you this: is there anything we've missed, or do you have
>> any suggestions you'd like implemented in the Pedestal project?
>>
>
> Ryan,
>
> This is very good news.
>

It's a definite improvement ... but "please print and sign the agreement,
then scan and mail"? There are a growing number of people that do
*everything* online, to the point of not having a printer, not having a
scanner, or not having either.

Of course, the same people tend to have trouble with the quaint notion that
a funny-looking squiggle emitted by pen onto paper is somehow a securer
form of authentication than a 128-bit cryptographic signature of a document
hash. :)

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Ryan Neufeld]

I definitely hear you - getting pedestal.io open for contributions is a 
goal of mine too. Maybe I can have a conversation with you about your 
experience on ClojureWerkz docs?


> Ryan,
>
> This is very good news. One thing I'd like to see is a way for the 
> community to contribute to pedestal.io (the site)
> using the same process.
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Paul deGrandis]

Cedric,

I don't own a printer, so I end up making heavy use of http://hellofax.com/

I'd point people there if they want to keep the whole process digital for 
themselves.

Cheers,
Paul

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Michael Klishin]

2013/3/29 Ryan Neufeld 

> Maybe I can have a conversation with you about your experience on
> ClojureWerkz docs?


Feel free to contact me directly.
-- 
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, 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/groups/opt_out.

ANN Monger 1.5.0 is released

[Michael Klishin]

Monger [1] is a Clojure MongoDB driver for a more civilized age: easy to
use, with sane
defaults, very fast, well documented, and with batteries included.

1.5.0 release notes:
http://blog.clojurewerkz.org/blog/2013/03/30/monger-1-dot-5-0-is-released/

1. http://clojuremongodb.info
-- 
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, 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/groups/opt_out.

ANN Quartzite 1.1.0 is released

[Michael Klishin]

Quartzite [1] is a powerful scheduling library built on top of Quartz
scheduler [2].

1.1.0 release notes:
http://blog.clojurewerkz.org/blog/2013/03/30/quartzite-1-dot-1-0-is-released/

1. http://clojurequartz.info
2. http://quartz-scheduler.org/
-- 
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, 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/groups/opt_out.

Re: Clojure libraries on remote machines

[Softaddicts]

Look at apache archiva. You can install it on a computer that has internet 
access
and allow computers being barred from internet access to use it as a maven repo
providing they have access to this single computer that runs archiva.

Archiva can act as a cache using proxies for external repos. You just need to 
configure
the missing ones (like clojars). The artifacts will be pulled once for everyone.

You can also publish artifacts that have not been published to maven yet.

Your internal computers will not even be aware of this.

You will need to change the default repo in your project.clj files to refer to
the archiva repo.

Archiva is light weight and easy to setup.

Luc P.


> Hi,
> 
> I have a few machines without internet connection. We have a ubuntu
> repository mirror, so I can install clojure using apt-get.
> 
> But, how do I install clojure libraries with all dependencies for projects
> on these machines? Even maven is not an option here.
> 
> 
> ramesh
> 
> -- 
> -- 
> 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/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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/groups/opt_out.

Invoke a specific multimethod

[JvJ]

Is it possible to invoke a particular multimethod and bypass the dispatch 
function?

For instance, suppose that I have a multimethod with a dispatch value of 
::foo, and it's a really complex method.

Now, I want all cases where the dispatch function returns nil to use the 
same multimethod.  Is there a way I can intercept the nil and
pass it directly on to the ::foo multimethod?

-- 
-- 
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/groups/opt_out.

Floating point comparator issue?

[JvJ]

Alright check this out:

;; Normal subtraction as comparator sorts in ascending order
(sort-by identity #(- %1 %2)   [1  -1])
(-1 1)

;; Reverse subtraction as comparator sorts in descending order
(sort-by identity #(- %2 %1)   [1  -1])
(1 -1)

;;===
;; And now with values of -0.1, 0.1

;; Reverse subtraction as comparator sorts in descending order
(sort-by identity #(- %2 %1)   [0.1  -0.1])
(0.1 -0.1)

;; Normal subtraction STILL sorts in descending order??
(sort-by identity #(- %1 %2)   [0.1  -0.1])
(0.1 -0.1)

-- 
-- 
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/groups/opt_out.

Re: Floating point comparator issue?

[Alan Malloy]

Comparator.compare returns an int. (int 0.2) and (int -0.2) both
return 0. Thus, your comparator is returning 0, saying "I don't care
what order these go in".

On Mar 29, 6:44 pm, JvJ  wrote:
> Alright check this out:
>
> ;; Normal subtraction as comparator sorts in ascending order
> (sort-by identity #(- %1 %2)   [1  -1])
> (-1 1)
>
> ;; Reverse subtraction as comparator sorts in descending order
> (sort-by identity #(- %2 %1)   [1  -1])
> (1 -1)
>
> ;;===
> ;; And now with values of -0.1, 0.1
>
> ;; Reverse subtraction as comparator sorts in descending order
> (sort-by identity #(- %2 %1)   [0.1  -0.1])
> (0.1 -0.1)
>
> ;; Normal subtraction STILL sorts in descending order??
> (sort-by identity #(- %1 %2)   [0.1  -0.1])
> (0.1 -0.1)

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Jean Niklas L'orange]

On Friday, March 29, 2013 5:04:33 AM UTC+1, tbc++ wrote:

> This is something I've thought/talked about for some time now. In reality 
> this is one of the reasons I started Mjolnir. I would like to see an 
> implementation of Clojure on LLVM. Mjolnir is several months away from 
> being able to handle a project like this, but I took the time tonight to 
> type up my thoughts on the topic. 
>
> https://github.com/halgari/clojure-metal/blob/master/README.md
>
> I'd love to hear anyone's input on this doc. I just typed this up, so it's 
> a bit rough, but it should communicate some of the ideas I have.
>
> Timothy Baldridge
>

Looks interesting to me, and what you describe is in my eyes a sound 
approach. Seems like you've been thinking about this for some time, esp. 
considering the talk you gave recently. Unfortunately I weren't there, but 
when one gives a talk on this topic, it's evident one has thought a lot 
about it.

What I found lacking was how one should design the Clojure core of 
Clojure-metal. Should one simply convert Clojure as it is right now, or 
should one take into account the lessons learned from creating Clojure? I'm 
sure Rich has some ideas on what should be done differently from what is 
currently done in Clojure right now, though perhaps aimed for the JVM 
implementation, and not in general. (Maybe you talked about this at 
Clojure/West?)

-- Jean Niklas L'orange

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Timothy Baldridge]

I really didn't discuss this in my talk at all. My talk focused more around
Mjolnir and how it allows for construction of compilers in general. That
being said, yes, this has been the hidden agenda behind the library from
the start.

For those who didn't see the talk, Mjolnir exposes access to LLVM through a
set of typed S-expressions. This allows us to use macros, clojure
namespaces, and the entire clojure runtime to construct compilers. An
example of a "bare-bones" lisp compiler can be found here:
https://github.com/halgari/mjolnir/blob/master/src/examples/simple_lisp.clj

clojure-metal is a unique beast from the other implementations of Clojure.
Most Clojure implementations are built on top of OOP VMs. If you are
writing a VM from scratch you don't have a OOP system to built on. So I
think the answer to your question is somewhere between ClojureScript and
Clojure on the JVM. Protocol based from the bottom up, but with a custom
runtime.

The guiding idea would be something like this:

* Nothing but protocols (like ClojureScript)
* First-class Namespaces (like Clojure)
* Everything is assigned to a name spaced var (like Clojure)
* Ints, Floats, Doubles, BigDecimals (via GMP), etc. (like Clojure)
* Refrain from "if instance(foo, IBar)" dispatching, instead use protocols.
This would remove much of RT.java


Timothy Baldridge



On Fri, Mar 29, 2013 at 8:50 PM, Jean Niklas L'orange  wrote:

> On Friday, March 29, 2013 5:04:33 AM UTC+1, tbc++ wrote:
>
>> This is something I've thought/talked about for some time now. In reality
>> this is one of the reasons I started Mjolnir. I would like to see an
>> implementation of Clojure on LLVM. Mjolnir is several months away from
>> being able to handle a project like this, but I took the time tonight to
>> type up my thoughts on the topic.
>>
>> https://github.com/halgari/**clojure-metal/blob/master/**README.md
>>
>> I'd love to hear anyone's input on this doc. I just typed this up, so
>> it's a bit rough, but it should communicate some of the ideas I have.
>>
>> Timothy Baldridge
>>
>
> Looks interesting to me, and what you describe is in my eyes a sound
> approach. Seems like you've been thinking about this for some time, esp.
> considering the talk you gave recently. Unfortunately I weren't there, but
> when one gives a talk on this topic, it's evident one has thought a lot
> about it.
>
> What I found lacking was how one should design the Clojure core of
> Clojure-metal. Should one simply convert Clojure as it is right now, or
> should one take into account the lessons learned from creating Clojure? I'm
> sure Rich has some ideas on what should be done differently from what is
> currently done in Clojure right now, though perhaps aimed for the JVM
> implementation, and not in general. (Maybe you talked about this at
> Clojure/West?)
>
> -- Jean Niklas L'orange
>
> --
> --
> 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/groups/opt_out.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
-- 
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/groups/opt_out.

Re: clojurescript memory management

[Evan Mezeske]

Are you having trouble with the ClojureScript compiler running out of 
memory?

lein-cljsbuild runs the ClojureScript compiler in a fairly "clean room" 
Leiningen project, with only a few things from your project.clj being 
passed through (for instance, things that affect the classpath).  It 
wouldn't be difficult to pass through other things if they're important. 
 Feel free to open a bug on https://github.com/emezeske/lein-cljsbuild, 
preferably with details about why passing through Java options is important.

On Thursday, March 28, 2013 11:37:34 AM UTC-7, Tyler Gillies wrote:
>
> It seems like cljsbuild is ignoring my Xmx setting in my project.clj, 
>  anyone have experience with controlling memory with cljsbuild?
>
> I know the setting is correct because my normal clj repl is minding limit
>

-- 
-- 
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/groups/opt_out.

GSoC 2013: What's next?

[Daniel Solano Gómez]

Hello, all,

First, a big thanks to everyone who has helped build up our Project
Ideas page[1].  Without your help, we would have a much weaker
application for participating in this year's Google Summer of Code
(GSoC).

Earlier today, the application period for mentoring organisations
closed.  Over the next week, Google will be reviewing all of these
applications and selecting the organisations that will be participating
in this year's program.  Their selections will be announced at 19:00 UTC
on the 8 April.  (As an aside, it may not be too late to add project
ideas over the weekend.)

If Clojure is selected to participate again this year, then the time
will begin for students to start preparing their applications.  This
will be the time for students to start getting in contact with potential
mentors and begin preparing their applications.

The student application period will be from 22 Apr-3 May.  Once the
student application period closes, we will need to review and rank all
of the proposals that we received.  This will mark the beginning of a
period where we will find out how many students we will get as an
organisation, and then we will need to make our final selections of
students and mentors by 24 May.  On 27 May, Google will announce the
accepted students.

Again, thank you again to all of you who have helped us put together
what I believe is a strong application.  Here's to hoping we will see
Clojure participate in GSoC for our second time.

Sincerely,

Daniel

[1]: http://dev.clojure.org/display/community/Project+Ideas


signature.asc
Description: Digital signature

Re: Invoke a specific multimethod

[George Oliver]

On Friday, March 29, 2013 6:19:19 PM UTC-7, JvJ wrote:
>
> Is it possible to invoke a particular multimethod and bypass the dispatch 
> function?
>
> For instance, suppose that I have a multimethod with a dispatch value of 
> ::foo, and it's a really complex method.
>
> Now, I want all cases where the dispatch function returns nil to use the 
> same multimethod.  Is there a way I can intercept the nil and
> pass it directly on to the ::foo multimethod?
>

You could use the default multimethod to catch nil, and then call the multi 
with ::foo. 

-- 
-- 
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/groups/opt_out.

Re: Clojure Style Guide

[Erlis Vidal]

Alan,

Thanks for this. I've enjoy (and learn) a lot reading your clojure style
guide! Great job. I think it deserve a link in clojure-docs.org I couldn't
find anything similar on that page, wich I use a lot too.

Regards,
Erlis


On Fri, Mar 29, 2013 at 3:45 PM, Alan Thompson wrote:

> Hey - Just saw a nice article on this in (def newsletter) .  It looks like
> quite a good reference on the subject.
>
> https://github.com/bbatsov/clojure-style-guide
>
> Alan Thompson
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Aaron]

I'm working on a Clojure DSL for generating C code called c-in-clj: 
https://github.com/aaronc/c-in-clj.  Right now it only works on ClojureCLR, 
but could be ported to Clojure JVM if someone desired.  The API should be 
considered unstable but I have been using to generate real production code.

This isn't a Clojure in C implementation, it just lets me take advantage of 
Clojure features for generating the C code the way I want to.  For me, I 
feel like it covers (or will cover) most of the use cases I have for a 
Clojure C.  At the same time, it could be used as the foundation for 
writing Clojure in C.  If someone does feel inspired to take on this task, 
I can explain how to do it with this library.

On Wednesday, March 27, 2013 4:05:03 PM UTC-4, Joe Graham wrote:
>
> Hi Group,
> Good afternoon I hope everyone is well.  I just wanted to reach out to 
> this group and get the current status of Clojure today on the LLVM compiler 
> or C based implementation?  Has anyone looked into a Julia implementation? 
>  Just trying to get a roadmap on the main forks before searching on every 
> permutation of this question.  Thanks so much for your help and valuable 
> input of this group.
>
> BR_joe
>

-- 
-- 
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/groups/opt_out.

Re: What is the status of Clojure on LLVM or C?

[Marko Topolnik]

On Friday, March 29, 2013 5:37:19 PM UTC+1, Herwig Hochleitner wrote:
>
> 2013/3/29 Marko Topolnik >
>
>> Yes, you are involving Clojure startup here, which turns the tables 
>> altogether. This is far more work than just Java startup: all the 
>> namespaces must be initialized: all their def'd values calculated at 
>> runtime and assigned. Some of these may involve quite heavyweight service 
>> startup. This is the real issue in the Clojure startup story: it is not 
>> aggressively optimized towards zero startup time. It is a problem that 
>> carries over to other underlying implementations.
>>
>
> The opposite is also true and weighs more heavy in this case, I think. 
> Java is not optimized for good startup times. In particular, you can't 
> embed any composite constants in byte code. Not even arrays. That means 
> every last piece of metadata has to be allocated and built from scratch at 
> startup. Every class for every toplevel fn has to be loaded (a process that 
> involves deserialization aswell), initialized and instantiated.
>
> In a native code implementation of clojure, all the statically known 
> functions, data and metadata structures could be directly embedded into the 
> binary. Thus the init cost of a namespace with defn as the only toplevel 
> forms could be near zero.
>

An excellent point. Indeed, the semantics of the JVM are not specfiically 
geared towards quick startup. Do mind, however, that this is just 
specification we're talking about. An implementation may perform any 
optimization as long as it maintains the semantics. As an obvious example, 
take the startup of the JVM itself, which loads and initializes many 
hundreds of classes, and sets up a myriad of internal datastructures, 
within 100-200 ms. This kind of optimization is unfortunately not something 
client code can participate in, and that's where many problems start. 
Clojure would basically need its own custom JVM derivation which would 
provide an accessible way to "fossilize" a namespace and turn it into a 
binary blob that can be loaded in microsecoonds, resulting in a fully 
initialized image in memory.

At a certain point in this departure from the JVM comes a moment where it 
is saner to start from scratch and build your own runtime, but that means 
you undo some 15 years of experience in building and optimizing a runtime 
for heayweight production systems. Some lessons can be carried over, but a 
huge spectrum of fine detials will be left for you to reinvent.

As long as the JVM is alive and strong I doubt we shall ever see a native 
implementation that wouldn't cause frustration to its users, because it 
won't be the universally best choice. For many years to come nothing will 
be able to dethrone the JVM at the server side, where startup time means 
nothing and long-running stability is precious. So whatever runtime you 
choose, it will take you only that far before its specific limitations 
start giving you a headache.

But hey, that's life: no language has conquered all the bases. Otherwise C 
would by now be just a tale from the elders.

-marko

-- 
-- 
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/groups/opt_out.

Re: Clojure Style Guide

[Colin Fleming]

I agree - I thoroughly enjoyed this.


On 30 March 2013 08:45, Alan Thompson  wrote:

> Hey - Just saw a nice article on this in (def newsletter) .  It looks like
> quite a good reference on the subject.
>
> https://github.com/bbatsov/clojure-style-guide
>
> Alan Thompson
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Problem with map (only when running on browser)

[Nico]

I have the following code:

(defn log-call [call]
  (.log js/console (pr-str call)))

(defn generate-report []
  ;; Get the data from the textarea calls_log
  (let [all-calls (.split (.-value (.getElementById js/document 
"calls_log")) "\n")
[calls-headers & calls-log] all-calls]
  
; Output all calls to the console log
;(.log js/console (pr-str calls-log 
(map log-call calls-log)))


That code works on the REPL connected to the browser, and the date is 
displayed on the console. However, the compiled code doesn't run on the 
browser. I've tried debugging it with Chrome, but I'm not getting any 
errors, and I don't really know what's going on when following it step by 
step.

If I comment the last line and uncomment the second to last, the code works 
on the browser. So basically if I don't do the map, it works. I am very 
confused.

I only started using ClojureScript today, and already had a bunch of 
problems (including not being able to get domina 1.0.2-SNAPSHOT to work, 
trying to follow the moder_cljs tutorial), so I would really appreciate 
some help with this. Thank you very much!


Nico

-- 
-- 
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/groups/opt_out.

Re: [ANN] Pedestal Application Framework

[Jeremiah Dodds]

Cedric Greevey  writes:

> It's a definite improvement ... but "please print and sign the agreement, then
> scan and mail"? There are a growing number of people that do *everything*
> online, to the point of not having a printer, not having a scanner, or not
> having either.
>
> Of course, the same people tend to have trouble with the quaint notion that a
> funny-looking squiggle emitted by pen onto paper is somehow a securer form of
> authentication than a 128-bit cryptographic signature of a document hash. :)
>
> -- 

Those people may be interested in sites like https://www.hellofax.com/
when faced with "needing" to print, sign, and scan some paper-trail :P

-- 
Jeremiah Dodds

blog   : http://jdodds.github.com
github : https://github.com/jdodds
freenode/skype : exhortatory
twitter: kaens

-- 
-- 
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/groups/opt_out.

Re: Apply elements in a vector as arguments to function

[Marko Topolnik]

ClojureDocs currently show just the original docstring followed by 
user-contributed examples. I think a lot of readers would benefit from 
somethig like this:

apply
(apply f args* argseq)
*Scripture:* Applies fn f to the argument list formed by prepending args to 
argseq.
*Interpretation: *The first argument (f) is a function and the last 
argument is a sequence (argseq). Calls f with elements of argseq as its 
arguments. If more arguments are specified (args*), they are added to the 
beginning of the argseq to form the complete argument list with which f is 
called.
*
*
*Examples:* (as usual)


-marko

On Wednesday, March 27, 2013 11:33:04 AM UTC+1, Marko Topolnik wrote:
>
> Now that Michael mentioned it, the docstring of *apply* says
>
> Applies fn f to the argument list formed by prepending intervening 
>> arguments to args.
>
>
> I challenge any Clojure newbie to decipher this Hickeyism for me. This is 
> of course no exception; most of clojure.core is like that.
>
> I can personally testify to having learned (and *had to* learn) much more 
> from source code than from docstrings. M-. has always been my best 
> friend; C-d C-d came merely as a hint from Rich while solving the 
> "compile me in your head" puzzle.
>
> -marko
>
> On Wednesday, March 27, 2013 11:17:05 AM UTC+1, Ryan wrote:
>>
>> The idea that people should read the source to get reasonably 
>>> straightforward stuff done is wrong and does a lot of long term damage to 
>>> the community.
>>
>>
>> I believe Jim meant to check the source to figure out how does it work, 
>> not that the way it's implemented is the most proper way to implement it.
>> If that's not what you wanted to point out can you please explain?
>>
>> On Wednesday, March 27, 2013 5:13:35 AM UTC+2, Michael Klishin wrote:
>>>
>>>
>>> 2013/3/27 Jim - FooBar(); 
>>>
 aaa see? always check the docs first and the sources second (if 
 available)...I should have done that as well :)
>>>
>>>
>>> Definitely don't just check the sources and think it's something normal.
>>>
>>> Complain loudly to maintainers on this list that their documentation has 
>>> gaps and they should
>>> clarify this and that. The idea that people should read the source to 
>>> get reasonably straightforward
>>> stuff done is wrong and does a lot of long term damage to the community.
>>> -- 
>>> 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, 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/groups/opt_out.