Re: Running Clojure apps using less memory.

[Jason Basanese]

Thanks guys! Going through your various tips helped me get the memory usage 
down below the limit. Now things are running nicely.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 1.8.40

[Rangel Spasov]

No more warnings, thank you! : )

On Monday, March 28, 2016 at 5:19:26 AM UTC-7, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.8.40"]
>
> This release addresses some minor unintentional interactions with 3rd 
> party ClojureScript tooling like Figwheel.
>
> As always feedback welcome!
>
> ## 1.8.40
>
> ### Fixes
> * CLJS-1603: Only warn for misspelled comp/REPL opts
> * :warning-handlers missing for known compiler options
> * CLJS-1592: Self-host: Robustness for core tests
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Clojure apps using less memory.

[Josh Tilles]

Hi Jason,

I have a hunch that you have more Java processes running than you need 
and/or are aware of. For example, by running your Clojure app via lein run 
-m clojureweb.core/serve, you have two Java processes: one for Leiningen, 
and a separate one (started by Leiningen) for your app. It’s unlikely that 
you need Leiningen’s JVM to stick around, so you should probably try 
starting your app with the command lein *trampoline* run -m 
clojureweb.core/serve. (For details, see “Server-side Projects” in the 
Leiningen tutorial 

.)
Also, you didn’t mention how you were starting your REPL(s), but I’m going 
to assume that you were using lein repl; if so, that’s the source of *yet 
another* Java process or two. In order to refrain from needing to keep 
other JVMs running, you might want to use Clojure 1.8’s built-in socket 
server REPL 

 instead.

Cheers,
Josh

P.S. You mentioned that you’re relatively new to Clojure—welcome! =)

On Monday, March 28, 2016 at 8:11:49 AM UTC-4, Jason Basanese wrote:
>
> Hello all! I'm new to this forum. My name Is Jason Basanese and I am a 
> relatively new clojurist.
>
> I recently began hosting my first small full stack Clojure web app. While 
> doing this I ran into memory problems with my admittedly small load server. 
> The maximum it can take in temp memory is 741MB. Too much of that memory is 
> consumed giving an error when I try to run two REPLs on the server. One for 
> testing and editing code and the other for leaving the app running. My 
> other dynamic content websites which use php directly with Apache use 
> minimal memory. Why is it that running a Clojure app like such "lein run -m 
> clojureweb.core/serve" takes up so much memory? Here is the code of the 
> function I am running with that command. 
>
> (defn serve [& args]
>   (org.apache.log4j.BasicConfigurator/configure)
>   (run-server
>(logger/wrap-with-logger
> (reload/wrap-reload app))
>{:port 8080}))
>
> Are the logger or the wrap-reload making it take up so much memory? Is 
> there a better way to run Clojure apps that is less robust? Or is using a 
> relatively large amount of memory just a bullet to bite when using Clojure? 
> Yes I know an obvious solution would just be to upgrade the server, but 
> where's the fun in that?
>
> Requests for more detail, comments, answers and opinions all welcome!
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Clojure apps using less memory.

[Nando Breiter]

If you want to get more deeply into JVM memory tuning, *perhaps* jClarity's
Censum tool can help: https://www.jclarity.com/censum/. It will run an
analysis of your specific applications memory usage patterns and make
suggestions how to configure the JVM for it.



Aria Media Sagl
+41 (0)76 303 4477 cell
skype: ariamedia

On Mon, Mar 28, 2016 at 4:45 PM, Gary Trakhman 
wrote:

> I always work in a single process, REPL and server, there's no need to
> separate them out generally.
>
> You might have better luck with the G1 collector, in addition to JVM
> tuning.  The G1 has the useful property of giving memory back to the OS
> when a GC is performed.
> Use the command-line flag: -XX:+UseG1GC
>
> If this is confusing, in short, PHP is 'interpreted', thus it's leaner and
> slower than a 'compiled' language like clojure.  There's a lot of stuff
> that needs to be loaded for clojure to work (the compiler lives in memory),
> and you'll take a hit in startup-time and memory footprint.  Some of this
> is java-specific, probably CLJS on V8 can do better in terms of memory
> footprint.
>
> On Mon, Mar 28, 2016 at 10:36 AM Michael Willis 
> wrote:
>
>> You can tune memory usage by passing parameters to the JVM:
>>
>> http://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html
>>
>> The sample leiningen project file has an example of how to pass
>> parameters to the JVM:
>>
>>
>> https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L264
>>
>> Hope that helps,
>> Michael Willis
>>
>>
>>
>> On Monday, March 28, 2016 at 7:11:49 AM UTC-5, Jason Basanese wrote:
>>>
>>> Hello all! I'm new to this forum. My name Is Jason Basanese and I am a
>>> relatively new clojurist.
>>>
>>> I recently began hosting my first small full stack Clojure web app.
>>> While doing this I ran into memory problems with my admittedly small load
>>> server. The maximum it can take in temp memory is 741MB. Too much of that
>>> memory is consumed giving an error when I try to run two REPLs on the
>>> server. One for testing and editing code and the other for leaving the app
>>> running. My other dynamic content websites which use php directly with
>>> Apache use minimal memory. Why is it that running a Clojure app like such
>>> "lein run -m clojureweb.core/serve" takes up so much memory? Here is the
>>> code of the function I am running with that command.
>>>
>>> (defn serve [& args]
>>>   (org.apache.log4j.BasicConfigurator/configure)
>>>   (run-server
>>>(logger/wrap-with-logger
>>> (reload/wrap-reload app))
>>>{:port 8080}))
>>>
>>> Are the logger or the wrap-reload making it take up so much memory? Is
>>> there a better way to run Clojure apps that is less robust? Or is using a
>>> relatively large amount of memory just a bullet to bite when using Clojure?
>>> Yes I know an obvious solution would just be to upgrade the server, but
>>> where's the fun in that?
>>>
>>> Requests for more detail, comments, answers and opinions all welcome!
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Predicat 0.2.2

[Sébastien Bocq]

Hi Adrian, thanks for the positive feedback. For Manifold, I think
validation failures could simply be sent over a channel using the d/error!
function. Ideally, failure messages are something users should be able to
build on top of these frameworks/libraries and not something enforced with
a hard dependency. If you were thinking about asynchronous error
propagation that accumulate a trace of failures on nodes in a process
network, that is a different and a lot more complicated subject that is
well beyond the scope of this library. That being said, this is also a vary
interesting subject that definitely deserves attention.

2016-03-28 6:32 GMT+02:00 :

> This looks really interesting and useful. Thanks for sharing. Thinking out
> loud, it would be interesting to see these failures integrated with
> something like Probe (https://github.com/VitalLabs/probe), which could
> not only record the failures but also potentially feed them into a
> monitoring system. Also, in tandem with Manifold (
> https://github.com/ztellman/manifold), I could see this greatly aiding
> asynchronous error tracing.
>
>
> On Sunday, March 27, 2016 at 8:03:46 PM UTC-4, Sébastien Bocq wrote:
>>
>> Hi all,
>>
>> I'm pleased to announce Predicat , a
>> new validation library that permits to create and compose predicate
>> functions whose failures always carry the expression and the input of
>> the predicate that fails.
>>
>> See readme on github for the motivation examples:
>> https://github.com/sbocq/predicat
>>
>> I hope you find it useful!
>>
>> Sébastien
>>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/TVQC7pfjWtg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Clojure apps using less memory.

[Gary Trakhman]

I always work in a single process, REPL and server, there's no need to
separate them out generally.

You might have better luck with the G1 collector, in addition to JVM
tuning.  The G1 has the useful property of giving memory back to the OS
when a GC is performed.
Use the command-line flag: -XX:+UseG1GC

If this is confusing, in short, PHP is 'interpreted', thus it's leaner and
slower than a 'compiled' language like clojure.  There's a lot of stuff
that needs to be loaded for clojure to work (the compiler lives in memory),
and you'll take a hit in startup-time and memory footprint.  Some of this
is java-specific, probably CLJS on V8 can do better in terms of memory
footprint.

On Mon, Mar 28, 2016 at 10:36 AM Michael Willis 
wrote:

> You can tune memory usage by passing parameters to the JVM:
>
> http://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html
>
> The sample leiningen project file has an example of how to pass parameters
> to the JVM:
>
>
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L264
>
> Hope that helps,
> Michael Willis
>
>
>
> On Monday, March 28, 2016 at 7:11:49 AM UTC-5, Jason Basanese wrote:
>>
>> Hello all! I'm new to this forum. My name Is Jason Basanese and I am a
>> relatively new clojurist.
>>
>> I recently began hosting my first small full stack Clojure web app. While
>> doing this I ran into memory problems with my admittedly small load server.
>> The maximum it can take in temp memory is 741MB. Too much of that memory is
>> consumed giving an error when I try to run two REPLs on the server. One for
>> testing and editing code and the other for leaving the app running. My
>> other dynamic content websites which use php directly with Apache use
>> minimal memory. Why is it that running a Clojure app like such "lein run -m
>> clojureweb.core/serve" takes up so much memory? Here is the code of the
>> function I am running with that command.
>>
>> (defn serve [& args]
>>   (org.apache.log4j.BasicConfigurator/configure)
>>   (run-server
>>(logger/wrap-with-logger
>> (reload/wrap-reload app))
>>{:port 8080}))
>>
>> Are the logger or the wrap-reload making it take up so much memory? Is
>> there a better way to run Clojure apps that is less robust? Or is using a
>> relatively large amount of memory just a bullet to bite when using Clojure?
>> Yes I know an obvious solution would just be to upgrade the server, but
>> where's the fun in that?
>>
>> Requests for more detail, comments, answers and opinions all welcome!
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] core.memoize 0.5.9

[Alex Miller]

core.memoize is a Clojure contrib library providing pluggable support for 
memoization with caches from core.cache.

   - README and source: https://github.com/clojure/core.memoize
   - Leiningen dependency information: [org.clojure/core.memoize "0.5.9"]
   
Changes in 0.5.9:

   - Bump core.cache dependency to 0.6.5

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Clojure apps using less memory.

[Michael Willis]

You can tune memory usage by passing parameters to the JVM:

http://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html

The sample leiningen project file has an example of how to pass parameters 
to the JVM:

https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L264

Hope that helps,
Michael Willis


On Monday, March 28, 2016 at 7:11:49 AM UTC-5, Jason Basanese wrote:
>
> Hello all! I'm new to this forum. My name Is Jason Basanese and I am a 
> relatively new clojurist.
>
> I recently began hosting my first small full stack Clojure web app. While 
> doing this I ran into memory problems with my admittedly small load server. 
> The maximum it can take in temp memory is 741MB. Too much of that memory is 
> consumed giving an error when I try to run two REPLs on the server. One for 
> testing and editing code and the other for leaving the app running. My 
> other dynamic content websites which use php directly with Apache use 
> minimal memory. Why is it that running a Clojure app like such "lein run -m 
> clojureweb.core/serve" takes up so much memory? Here is the code of the 
> function I am running with that command. 
>
> (defn serve [& args]
>   (org.apache.log4j.BasicConfigurator/configure)
>   (run-server
>(logger/wrap-with-logger
> (reload/wrap-reload app))
>{:port 8080}))
>
> Are the logger or the wrap-reload making it take up so much memory? Is 
> there a better way to run Clojure apps that is less robust? Or is using a 
> relatively large amount of memory just a bullet to bite when using Clojure? 
> Yes I know an obvious solution would just be to upgrade the server, but 
> where's the fun in that?
>
> Requests for more detail, comments, answers and opinions all welcome!
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on idiomatic API design

[Johan Haleby]

Thanks everyone for your input. I just wanted to say that I have an initial
version of the library available at my github
 page if anyone is interested.

On Sat, Mar 12, 2016 at 3:43 PM, Timothy Baldridge 
wrote:

> "Idiomatic" is always a hard word to define, and I think some of the
> points made here are good, but let me also provide a few guidelines I try
> to abide by when writing an API:
>
> Start with data, preferably hash maps. At some point your API will be
> consumed by someone else's program. Macros make it hard to compose api
> calls in a sane matter using code. So stick with hash maps and pure data.
> Something like the following:
>
> {:host "foo.bar.com"
>  :port 80
>  :path "/some/path/i/want"
>  :params {:name :value :key :value2}}
>
> Now if it comes time to modify/process/compose this request we can use
> normal Clojure functions like assoc/conj to build this request map. Of
> course, using this approach normally results in a explosion of data, so
> pretty it up with helper functions:
>
> (make-request-map "http://foo.bar.com/some/path/i/want; {:name :value})
>
> The key here, is that these helper functions should emit the data you
> specified in the first step.
>
> And finally, write macros as a last resort to pretty up the user
> experience even further. In short:
>
> 1) Start with data to allow clojure code to easily access your API
> 2) Make generating that data simpler by writing helper functions to
> generate data
> 3) (Optionally) Write a DSL to make user interaction easier.
>
> Timothy
>
> On Sat, Mar 12, 2016 at 6:41 AM, Johan Haleby 
> wrote:
>
>> Thanks a lot for your support and insights. I'm going to rewrite it to
>> use "with-open" as we speak.
>>
>> On Sat, Mar 12, 2016 at 2:37 PM, Marc Limotte 
>> wrote:
>>
>>> Look at the source for the clojure.core with-open macro.  In the repl:
>>> `(source with-open)`.
>>>
>>> I think Gary is right.  with-open does exactly what you need, I should
>>> have thought of that, and you should probably use it.  But if you want to
>>> get your version working, trying to understand what the with-open macro is
>>> doing.  Your implementation can be simpler because you only have one
>>> explicit binding.  Essentially you'll create a let as a backquoted form and
>>> then splice in the explicit symbol from the user:
>>>
>>>
>>>`(let [~sym ...server-instance-or-uri...] ... )
>>>
>>>
>>> marc
>>>
>>>
>>>
>>>
>>> On Sat, Mar 12, 2016 at 1:57 AM, Johan Haleby 
>>> wrote:
>>>


 On Wed, Mar 9, 2016 at 7:32 PM, Marc Limotte 
 wrote:

> With the macro approach, they don't need to escape it.
>

 Do you know of any resources of where I can read up on this? I have the
 macro working with an implicit "uri" generated but I don't know how to make
 it explicit (i.e. defined by the user) the way you proposed.


>
> On Wed, Mar 9, 2016 at 12:52 PM, Johan Haleby 
> wrote:
>
>> Thanks a lot for your support Marc, really appreciated.
>>
>> On Wed, Mar 9, 2016 at 5:33 PM, Marc Limotte 
>> wrote:
>>
>>> Yes, I was assuming the HTTP calls happen inside the
>>> with-fake-routes! block.
>>> I missed the part about the random port.  I se 3 options for that:
>>>
>>> *Assign a port, rather than random*
>>>
>>> (with-fake-routes!  ...)
>>>
>>>
>>> But then, of course, you have to worry about port already in use.
>>>
>>> *An atom*
>>>
>>> (def the-uri (atom nil))
>>> (with-fake-routes! the-uri
>>>   ...
>>>   (http/get @the-uri "/x"))
>>>
>>> *A macro*
>>>
>>> A common convention in Clojure would be to pass it a symbol (e.g.
>>> `uri` that is bound by the macro), rather implicitly creating `uri`.
>>>
>>> (with-fake-routes! [uri option-server-instance]
>>>
>>> route-map
>>>
>>> (http/get uri "/x"))
>>>
>>>
>> Didn't know about this convention so thanks for the tip. But is your
>> snippet above actually working code or does the user need escape "uri" 
>> and "
>> option-server-instance" using a single-quotes, i.e.
>>
>> (with-fake-routes! [*'*uri *'*option-server-instance] ...)
>>
>>
>>>
>>> or, with a pre-defined server
>>>
>>> (def fake-server ...)
>>> (with-fake-routes!
>>>
>>> route-map
>>>
>>> (http/get (:uri fake-server) "/x"))
>>>
>>>
>>> marc
>>>
>>>
>>>
>>> On Wed, Mar 9, 2016 at 1:00 AM, Johan Haleby >> > wrote:
>>>


 On Wed, Mar 9, 2016 at 6:20 AM, Johan Haleby <
 johan.hal...@gmail.com> wrote:

> Thanks for your feedback, exactly what I wanted.
>
> On 

[ANN] core.cache 0.6.5

[Alex Miller]

core.cache is a Clojure contrib library providing a cache protocol and 
implementations of several caching strategies.

   - README and source: https://github.com/clojure/core.cache
   - Leiningen dependency information: [org.clojure/core.cache "0.6.5"]
   
Changes in 0.6.5:

   - Bump tools.priority-map dependency to 0.0.7
   - CCACHE-41  Implement 
   Iterable in defcache (compatibility for Clojure 1.7+)
   - CCACHE-44  Avoid equals 
   comparison on cache miss for performance
   - CCACHE-37  Fix typo in 
   docstring

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Klipse 0.2.0 - a simple and elegant online cljs compiler and evaluator.

[Yehonathan Sharvit]

[ANN] Klipse 0.2.0 - a simple and elegant online cljs compiler and
evaluator.

The latest additions:

1. mobile support

2. `js_only` and `eval_only` mode

3. share your KLIPSE: embed your code in `cljs_in` url parameter


All the details here:
http://blog.klipse.tech/clojure/2016/03/27/klipse-manual.html


Happy KLIPSING!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: ClojureScript 1.8.40

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.8.40"]

This release addresses some minor unintentional interactions with 3rd party
ClojureScript tooling like Figwheel.

As always feedback welcome!

## 1.8.40

### Fixes
* CLJS-1603: Only warn for misspelled comp/REPL opts
* :warning-handlers missing for known compiler options
* CLJS-1592: Self-host: Robustness for core tests

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Running Clojure apps using less memory.

[Jason Basanese]

Hello all! I'm new to this forum. My name Is Jason Basanese and I am a 
relatively new clojurist.

I recently began hosting my first small full stack Clojure web app. While 
doing this I ran into memory problems with my admittedly small load server. 
The maximum it can take in temp memory is 741MB. Too much of that memory is 
consumed giving an error when I try to run two REPLs on the server. One for 
testing and editing code and the other for leaving the app running. My 
other dynamic content websites which use php directly with Apache use 
minimal memory. Why is it that running a Clojure app like such "lein run -m 
clojureweb.core/serve" takes up so much memory? Here is the code of the 
function I am running with that command. 

(defn serve [& args]
  (org.apache.log4j.BasicConfigurator/configure)
  (run-server
   (logger/wrap-with-logger
(reload/wrap-reload app))
   {:port 8080}))

Are the logger or the wrap-reload making it take up so much memory? Is 
there a better way to run Clojure apps that is less robust? Or is using a 
relatively large amount of memory just a bullet to bite when using Clojure? 
Yes I know an obvious solution would just be to upgrade the server, but 
where's the fun in that?

Requests for more detail, comments, answers and opinions all welcome!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.