Re: ANN: State of Clojure 2014 Survey - please contribute!!

[Bruce Durling]

I also know that Birkbeck College University of London is going to be
teaching Clojure this year.
On Oct 10, 2014 12:01 AM, "Lee Spector"  wrote:

>
> FWIW I'm another person using Clojure mostly for academic research. And
> for computer science education, e.g. I'm currently teaching a Clojure-based
> AI course. I'd be curious to know how many others of us are out there. And
> BTW I think that attention to users in these categories could help to grow
> the community.
>
>  -Lee
>
> On Oct 9, 2014, at 12:32 AM, Mars0i  wrote:
>
> > Thanks for the survey!
> >
> > I have a couple of suggestions/questions:
> >
> > For domains, there are no categories for scientific or other research
> applications.  For example, I mainly use Clojure for writing agent-based
> models for academic research.  Would a set of categories in this area be
> usedful?
> >
>
> --
> 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.

Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Colin Yates]

For clarity, can you confirm the relationship between this and ring and 
compojure? Am I right in saying the defined routes are ring compatible 
(using domkm.silk.serve) and therefore silk is a replacement for compojure 
(albeit compojure has some more middleware utilities)?

I understand I can just use silk in the UI and ring/compojure on the 
backend, but if I am using silk on the front end then simplicity would 
suggest using ring/silk on the backend.

This looks great, and I am just about to write my first 
“Clojure-all-the-way” web app using Om instead of coffeescript and ExtJS, 
and I want to make sure I don’t go down a rabbit hole (of which there are 
many!). To make life interesting, it is also a non-trivial SPA so client 
routing will help significantly.

On Tuesday, 5 August 2014 04:04:22 UTC+1, DomKM wrote:
>
> I have recently been experimenting with isomorphic Clojure and 
> ClojureScript architecture 
> .
>  
> The goal is to make Clojure[Script] web applications that can share logic 
> for routing, rendering, and other functionality in order to be able run in 
> both server-side and browser-side environments.
>
> I couldn't find a suitable routing library that worked in both Clojure and 
> ClojureScript nor could I find a routing library with a design that was 
> suitable for porting to the other platform, so I wrote one.
>
> https://github.com/DomKM/silk 
> 
>
> The core functionality of Silk is entirely compatible with both Clojure 
> and ClojureScript.
>
> Silk is easily extensible, which is especially important for an isomorphic 
> library. For example, you may have routes that, on the server, should only 
> match GET requests, but which should also work in the browser where you are 
> not routing from an HTTP request. This functionality is trivial to add to 
> Silk (and, as a convenience, is built in).
>
> In Silk, route matching and handling are decoupled. While this is an 
> important architecture concern anywhere, it is an essential feature for 
> isomorphism. Matching URLs on the server and browser will be very similar, 
> but what you do after will likely be entirely different. You can think of 
> routing in Silk as bidirectional (yes, routes are named) pure functions 
> that match URLs to extract parameters or take parameters to form URLs.
>
>  If this sounds like it could be useful for you, please give it a try and 
> let me know what you think.
>
> Thanks!
>

-- 
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: Seeking Large Companies That Employ Clojure

[Colin Yates]

+1.

Or even worse, this is an opportunity to be put on yet another recruiter’s 
automated job listing email :).

If this is some initiative for knowledge reaping/sharing in terms of 
Clojure best practices/engineering practices then why not use one of the 
many transparent mechanism (like this group for example) to at least 
articulate and start the process.

With respect, the original post has overtones of the “I have this 
(explicit/implicit) carrot, send me your details” spam, albeit in an 
engineering context.

On Thursday, 9 October 2014 20:52:47 UTC+1, Sean Corfield wrote:
>
> That's very vague. Can you explain _why_ you want to talk to such users?
>
> I'm in your target audience but I would not contact you based on such a 
> vague post. My first reaction is you're trying to sell me something...
>
> Sean
>
> On Oct 9, 2014, at 12:13 PM, Jan Drake > 
> wrote:
>
> You can learn a bit about me here .
>
> I am looking to connect with engineering teams and managers of those teams 
> that are using Clojure in enterprise and/or web scale scenarios to discuss 
> various topics important to users of Clojure at scale, in production, etc. 
>  If you are one, please contact me directly; if you know of one, please 
> make me an introduction.
>
> Onward in the great Clojure Adventure!
>
>
>
>

-- 
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] rmap - define lazy, recursive maps

[Arnout Roemers]

Hi Ben,

That's pretty nifty indeed! Maybe a tad memory intensive as it retains the 
head, but if it were a more complex, CPU intensive calculation in :next, 
that might be very worthwhile. Good stuff.

Cheers,
-Arnout

P.S. The memory consumption will be a little less when I think of a way to 
efficiently replace the backing LinkedHashMap with an actual persistent 
map, while keeping track of the evaluation order.

Op donderdag 9 oktober 2014 02:53:38 UTC+2 schreef Ben:
>
> This is pretty nifty:
>
> user=> (require '[rmap.core :as rmap])
> nil
> user=> (def fibs (rmap/rmap FIBS {:a 0 :b 1 :next (-> FIBS (update-in [:a] 
> (constantly (:b FIBS))) (update-in [:b] (constantly (+ (:b FIBS) (:a 
> FIBS)}))
> #'user/fibs
> user=> (defn fib [n] (loop [fibs fibs n n] (if (zero? n) (:a fibs) (recur 
> (:next fibs) (dec n)
> #'user/fib
> user=> (fib 40)
> 102334155
>
>

-- 
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] Example project to illustrate usage of system library

[Atamert Ölçgen]

On Fri, Oct 10, 2014 at 2:06 PM, Daniel Szmulewicz <
daniel.szmulew...@gmail.com> wrote:

> Yes, because locally you are in the repl already. The repl in production
> is brought in explicitly to be able to login/debug remotely into the
> application where it’s hosted.
> Does that make sense?
>

Makes sense. Thanks.


>
> On Friday, October 10, 2014 7:13:39 AM UTC+3, Atamert Ölçgen wrote:
>>
>> prod-system has a REPL but dev-system doesn't. Is this intentional?
>>
>> https://github.com/danielsz/system/blob/master/example/
>> src/example/systems.clj
>>
>> On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz 
>> wrote:
>>
>>> Hello everybody,
>>>
>>> I noticed a demand for examples in how to put together a web app with
>>> the reloaded approach (Stuart Sierra's components).
>>>
>>> For this reason, I've published an example project in the system
>>> library.
>>>
>>> https://github.com/danielsz/system/tree/master/example
>>>
>>> Enjoy.
>>>
>>> Please let me know if you have comments/suggestions/etc.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> -+-
>> --+
>> +++
>>
>> www.muhuk.com
>>
>  --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2371

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2371"]

This release includes minor fixes, faster collection iterators, and
stays in sync with the latest transducers changes in Clojure master.

### Fixes
* CLJS-862: fix inconsistent re-pattern
* CLJS-866: Faulty ns macro desugaring
* CLJS-869: When preamble is not found in source directory, compiler
does not report 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/d/optout.

Re: ANN: ClojureScript 0.0-2371

[Julien Eluard]

Hi David,

thanks once again for the continuous effort to improve the ClojureScript 
compiler.

Some warnings are now printed when using a specific `include-macros` syntax. I 
wanted to confirm that this syntax was indeed incorrect.
An example is: [secretary.core :as secretary :include-macros true :refer 
[defroute]]

Is the proper way to include macros to rely on the top-level `require-macros` 
keyword?

Thanks,
Julien

Le vendredi 10 octobre 2014 09:07:31 UTC-3, David Nolen a écrit :
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2371
> 
> 
> 
> Leiningen dependency information:
> 
> 
> 
> [org.clojure/clojurescript "0.0-2371"]
> 
> 
> 
> This release includes minor fixes, faster collection iterators, and
> 
> stays in sync with the latest transducers changes in Clojure master.
> 
> 
> 
> ### Fixes
> 
> * CLJS-862: fix inconsistent re-pattern
> 
> * CLJS-866: Faulty ns macro desugaring
> 
> * CLJS-869: When preamble is not found in source directory, compiler
> 
> does not report 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/d/optout.

Re: ANN: ClojureScript 0.0-2371

[Shaun LeBron]

(:require [secretary.core :as secretary :include-macros true])
; desugars to add=>  (:require-macros [secretary.core :as secretary])

(:require [secretary.core :as secretary :refer-macros [defroute])
; desugars to add=> (:require-macros [secretary.core :as secretary :refer 
[defroute]])

This changed to its original intended behavior so we can use :refer and 
:refer-macros together in the same require spec, without using a redundant 
`:include-macros true` as a separator to distinguish what we're referring.

On Friday, October 10, 2014 8:29:07 AM UTC-5, Julien Eluard wrote:
> Hi David,
> 
> 
> 
> thanks once again for the continuous effort to improve the ClojureScript 
> compiler.
> 
> 
> 
> Some warnings are now printed when using a specific `include-macros` syntax. 
> I wanted to confirm that this syntax was indeed incorrect.
> 
> An example is: [secretary.core :as secretary :include-macros true :refer 
> [defroute]]
> 
> 
> 
> Is the proper way to include macros to rely on the top-level `require-macros` 
> keyword?
> 
> 
> 
> Thanks,
> 
> Julien
> 
> 
> 
> Le vendredi 10 octobre 2014 09:07:31 UTC-3, David Nolen a écrit :
> 
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> > 
> 
> > 
> 
> > 
> 
> > README and source code: https://github.com/clojure/clojurescript
> 
> > 
> 
> > 
> 
> > 
> 
> > New release version: 0.0-2371
> 
> > 
> 
> > 
> 
> > 
> 
> > Leiningen dependency information:
> 
> > 
> 
> > 
> 
> > 
> 
> > [org.clojure/clojurescript "0.0-2371"]
> 
> > 
> 
> > 
> 
> > 
> 
> > This release includes minor fixes, faster collection iterators, and
> 
> > 
> 
> > stays in sync with the latest transducers changes in Clojure master.
> 
> > 
> 
> > 
> 
> > 
> 
> > ### Fixes
> 
> > 
> 
> > * CLJS-862: fix inconsistent re-pattern
> 
> > 
> 
> > * CLJS-866: Faulty ns macro desugaring
> 
> > 
> 
> > * CLJS-869: When preamble is not found in source directory, compiler
> 
> > 
> 
> > does not report 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/d/optout.

[ANN] Nginx-Clojure v0.2.6 Released!

[Xfeep]

0.2.6 (2014-10-10)
   
   1. Fix Bug: rewrite handler does not handle write event correctly with 
   thread pool mode or coroutine mode (issue #43)
   2. Fix Bug: built-in jvm variable #{pno} doesn't work (issue #44)
   3. Fix Bug: rewrite_handler_name does not work without content handler 
   (issue #45). Thanks Eric Kubacki  for 
   finding this bug.
   4. Fix Bug: rewrite handler does not handle write event correctly with 
   thread pool mode or coroutine mode (issue #43)
   5. Documents : Correct some inaccuracies and add section about logging 
   in Chapter More about Nginx-Clojure 
   
   6. Binaries: built with the lastest stable Nginx v1.6.2 which released 
   at 2014-09-16.



Web Site   http://nginx-clojure.github.io/
Source Hosted on Github https://github.com/nginx-clojure/nginx-clojure
Google Group (mailing list) 
https://groups.google.com/forum/#!forum/nginx-clojure

-- 
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] Nginx-Clojure v0.2.6 Released!

[Laurens Van Houtven]

Hi xfeep,


Thanks for the work! Looks awesome. Unfortunately the github website appears to 
be broken in FF32 (displays fine in Chrome).


cheers
lvh



On 10 Oct 2014, at 16:03, Xfeep  wrote:

> 
> 0.2.6 (2014-10-10)
> 
>   • Fix Bug: rewrite handler does not handle write event correctly with 
> thread pool mode or coroutine mode (issue #43)
>   • Fix Bug: built-in jvm variable #{pno} doesn't work (issue #44)
>   • Fix Bug: rewrite_handler_name does not work without content handler 
> (issue #45). Thanks Eric Kubacki for finding this bug.
>   • Fix Bug: rewrite handler does not handle write event correctly with 
> thread pool mode or coroutine mode (issue #43)
>   • Documents : Correct some inaccuracies and add section about logging 
> in Chapter More about Nginx-Clojure
>   • Binaries: built with the lastest stable Nginx v1.6.2 which released 
> at 2014-09-16.
> 
> 
> Web Site   http://nginx-clojure.github.io/
> Source Hosted on Github https://github.com/nginx-clojure/nginx-clojure
> Google Group (mailing list) 
> https://groups.google.com/forum/#!forum/nginx-clojure
> 
> -- 
> 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.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[ANN] Tawny-OWL 1.2

[Phillip Lord]

I am pleased to annouce the 1.2.0 release of Tawny-OWL, now available on
clojars and github (http://github.com/phillord/tawny-owl).

What is Tawny-OWL
=

Tawny-OWL allows construction of OWL ontologies, in a evaluative, functional
and fully programmatic environment. Think of it as the ontology engineering
equivalent of [R](http://www.r-project.org/). It has many advantages over
traditional ontology engineering tools, also described in a
[video introduction](https://vimeo.com/89782389).

- An interactive shell or REPL to explore and create ontologies.
- Source code, with comments, editable using any of a range of IDEs.
- Fully extensible -- new syntaxes, new data sources can be added by users
- Patterns can be created for individual ontologies; related classes can be
  built easily, accurately and maintainably.
- A unit test framework with fully reasoning.
- A clean syntax for versioning with any VCS, integrated with the IDE
- Support for packaging, dependency resolution and publication
- Enabled continuous integration with both ontology and software dependencies


For the Clojure developer
=

Tawny-OWL is predominately designed as a programmatic application for ontology
development, but it can be used as an API. OWL ontologies are a set of
statements about things and their relationships; underneath these statements
map to a subset of first-order logic which makes it possible to answer 
questions about these statements using highly-optimised reasoners.


Take Wing
=

Although in it's early stage, a rich manual is now being written for Tawny-OWL
https://github.com/phillord/take-wing
http://homepages.cs.ncl.ac.uk/phillip.lord/take-wing/take_wing.html

Changes
===
The main feature for the 1.2 release has been the incorporation of core.logic,
through (ab)use of the Tawny's querying facilities. A tighter integration
should be possible, having core.logic work directly over the OWL API, but this
was relatively simple to implement. It is performant enough for most uses (the
Gene Ontology renders to Clojure data structures in 1-2 seconds on my

One other substantial change is an aggressive micro-optimisation of
default-ontology and broadcast-ontology functionality. This functionality is
used in many parts of Tawny-OWL, so this results in a significant performance
enhancement.

Full change log is available.

https://github.com/phillord/tawny-owl/blob/master/docs/releases.md



-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Pedestal 0.3.1

[Paul deGrandis]

I'm extremely happy to announce the release of Pedestal 0.3.1

In this release you'll find many goodies:
 * NIO support
 * Immutant added as a platform type
 * Transit support
 * Improved SSE capabilities
 * A new route format
 * And more

Please see the official release notes for all of the details: 
https://github.com/pedestal/pedestal/releases/tag/0.3.1

Thanks to everyone who helped out in anyway, and many thanks to those who 
are happily using Pedestal.  There's even more great stuff coming up in the 
next release!

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/d/optout.

Re: [ANN] Nginx-Clojure v0.2.6 Released!

[Xfeep]

Hi ivh

Thanks for your notice.

Do you mean http://nginx-clojure.github.io/ appears to be broken in FF32 ? 
 I can not reproduce it.

Could you please give more information about it by reporting an issue at 
 https://github.com/nginx-clojure/nginx-clojure.github.io/issues/new ? 

Thanks.

Regards.
Xfeep

On Friday, October 10, 2014 10:40:30 PM UTC+8, Laurens Van Houtven wrote:
>
> Hi xfeep, 
>
>
> Thanks for the work! Looks awesome. Unfortunately the github website 
> appears to be broken in FF32 (displays fine in Chrome). 
>
>
> cheers 
> lvh 
>
>
>
> On 10 Oct 2014, at 16:03, Xfeep > wrote: 
>
> > 
> > 0.2.6 (2014-10-10) 
> > 
> > • Fix Bug: rewrite handler does not handle write event correctly 
> with thread pool mode or coroutine mode (issue #43) 
> > • Fix Bug: built-in jvm variable #{pno} doesn't work (issue #44) 
> > • Fix Bug: rewrite_handler_name does not work without content 
> handler (issue #45). Thanks Eric Kubacki for finding this bug. 
> > • Fix Bug: rewrite handler does not handle write event correctly 
> with thread pool mode or coroutine mode (issue #43) 
> > • Documents : Correct some inaccuracies and add section about 
> logging in Chapter More about Nginx-Clojure 
> > • Binaries: built with the lastest stable Nginx v1.6.2 which 
> released at 2014-09-16. 
> > 
> > 
> > Web Site   http://nginx-clojure.github.io/ 
> > Source Hosted on Github https://github.com/nginx-clojure/nginx-clojure 
> > Google Group (mailing list) 
> https://groups.google.com/forum/#!forum/nginx-clojure 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@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+u...@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: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dylan Butman]

 

I’ve been using silk in conduction with compojure. Most middleware aren’t 
compojure specific, but I’ve just found it easier to stick with base level 
compojure routes and then pass uris to silk for pattern matching. This is 
mostly because there is such a wealth of documentation and examples to draw 
from with compojure. For example, session management, login flows with 
friends, etc have already been solved and there is plenty of code to strip. 
Silk wouldn’t complicated them (in some cases it might simplify), but when 
the wheel rolls, push it.


I’ve been approaching silk solely as a library for pattern matching within 
the specific domain of urls, which it does very cleanly. More importantly, 
it’s currently the only one that does it in both clojure and clojurescript, 
which makes it possible to have the same routing code used on client and 
server, which is necessary if you want to do server rendering, or more 
complicated websocket updates. 

-- 
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: Recursive codec/frames in gloss?

[john walker]

What information do you want after this is decoded? Do you want the sum of 
byte0 ... byten, as well as the actual payload? Do you also want the 
header-length?

On Thursday, October 9, 2014 11:34:59 PM UTC-7, Ken Restivo wrote:
>
> I'm playing around with Gloss, trying to decode a packet, part of which 
> has the following nested struture: 
>
> header-length (1 byte, value n) 
> byte0 ... byten (count defined by that header-length byte) 
>actual payload (length of which is the sum of the values of the 
> above bytes) 
>
> So instead of a fixed-size value (uint16, uint32, uint64, etc) defining 
> the size of the payload, there's a variable-length  list of bytes (up to 
> 255),  which has to be summed, to determine the length of the payload. 
>
> Pretty easy to do imperatively, but I got lost in the dense forest of 
> gloss's abstractions, and couldn't figure out if it makes sense to try to 
> handle a case like this with it. 
>
> -ken 
>

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

best way to edit EDN value in cljs

[Dustin Getz]

I have an arbitrarily nested EDN value stored in an atom in ClojureScript.

What is the best way to make edits to an arbitrary subtree of this value?

-- 
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: best way to edit EDN value in cljs

[Mike Fikes]

Can you use update-in or assoc-in?

On Friday, October 10, 2014 2:28:26 PM UTC-4, Dustin Getz wrote:
>
> I have an arbitrarily nested EDN value stored in an atom in ClojureScript.
>
> What is the best way to make edits to an arbitrary subtree of this value?
>

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

Why is my function faster with eval?

[Michael Blume]

So I'm reading a bunch of rows from a huge csv file and marshalling those 
rows into maps using the first row as keys. I wrote the function two 
ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
version with eval is twice as fast and I'm kind of curious about why. 
Presumably the eval'd function still implicitly contains a list of keys, 
it's still implicitly treating each row as a seq and walking it, so I'm 
wondering what the seq-destructuring and the map literal are doing under 
the hood that's faster.

-- 
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: Recursive codec/frames in gloss?

[danneu]

I took a stab at it for 10 minutes, but I'm way too rusty.

Last year I implemented the blockchain wire protocol with gloss that might 
be helpful: https://gist.github.com/danneu/7397350

Here's the spec: https://en.bitcoin.it/wiki/Protocol_specification

The var-int-codec is a somewhat complex 
example: https://gist.github.com/danneu/7397350#file-1-codec-clj-L55-L83

I remember using `compile-frame` whenever I got stuck so I could implement 
its pre/post-process fns to transform data that I couldn't figure out how 
to fully define in a frame.

(compile-frame
   _frame_
   ;; Pre-encode
   (fn [_]
 ...)
   ;; Post-decode
   (fn [_]
 ...))

-- 
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] Nginx-Clojure v0.2.6 Released!

[Plínio Balduino]

Hi Laurens

Are you trying to access http or https? If you use HTTPSEverywhere like me,
the browser will try to load the https version, that really doesn't work
and you'll see only an horizontal strip.

I hope it can help you

Xfeep: thank you very much. I'm moving my web applications to nginx-clojure
and it's really awesome.

Regards

P Balduino

On Fri, Oct 10, 2014 at 12:16 PM, Xfeep  wrote:

> Hi ivh
>
> Thanks for your notice.
>
> Do you mean http://nginx-clojure.github.io/ appears to be broken in FF32
> ?  I can not reproduce it.
>
> Could you please give more information about it by reporting an issue at
> https://github.com/nginx-clojure/nginx-clojure.github.io/issues/new ?
>
> Thanks.
>
> Regards.
> Xfeep
>
> On Friday, October 10, 2014 10:40:30 PM UTC+8, Laurens Van Houtven wrote:
>>
>> Hi xfeep,
>>
>>
>> Thanks for the work! Looks awesome. Unfortunately the github website
>> appears to be broken in FF32 (displays fine in Chrome).
>>
>>
>> cheers
>> lvh
>>
>>
>>
>> On 10 Oct 2014, at 16:03, Xfeep  wrote:
>>
>> >
>> > 0.2.6 (2014-10-10)
>> >
>> > • Fix Bug: rewrite handler does not handle write event
>> correctly with thread pool mode or coroutine mode (issue #43)
>> > • Fix Bug: built-in jvm variable #{pno} doesn't work (issue
>> #44)
>> > • Fix Bug: rewrite_handler_name does not work without content
>> handler (issue #45). Thanks Eric Kubacki for finding this bug.
>> > • Fix Bug: rewrite handler does not handle write event
>> correctly with thread pool mode or coroutine mode (issue #43)
>> > • Documents : Correct some inaccuracies and add section about
>> logging in Chapter More about Nginx-Clojure
>> > • Binaries: built with the lastest stable Nginx v1.6.2 which
>> released at 2014-09-16.
>> >
>> >
>> > Web Site   http://nginx-clojure.github.io/
>> > Source Hosted on Github https://github.com/nginx-clojure/nginx-clojure
>> > Google Group (mailing list) https://groups.google.com/
>> forum/#!forum/nginx-clojure
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clo...@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+u...@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+u...@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" 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: Why is my function faster with eval?

[Laurent PETIT]

Hello,

Can you show the code you use for benchmarking?

Le vendredi 10 octobre 2014, Michael Blume  a écrit :

> So I'm reading a bunch of rows from a huge csv file and marshalling those
> rows into maps using the first row as keys. I wrote the function two ways:
> https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the version
> with eval is twice as fast and I'm kind of curious about why. Presumably
> the eval'd function still implicitly contains a list of keys, it's still
> implicitly treating each row as a seq and walking it, so I'm wondering what
> the seq-destructuring and the map literal are doing under the hood that's
> faster.
>
> --
> 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.
>


-- 
Laurent Petit

-- 
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: Why is my function faster with eval?

[Sean Corfield]

It may be more to do with the difference between `for` and `map`. How do these 
versions compare in your benchmark:

(defn read-to-maps-partial [rows]
  (let [headers (->>
  rows
  first
  (take-while (complement #{""}))
  (map keyword))]
(map (partial zipmap headers) (rest rows

(defn read-to-maps-fn [rows]
  (let [headers (->>
  rows
  first
  (take-while (complement #{""}))
  (map keyword))
mapper (fn [row] (zipmap headers row))]
(map mapper (rest rows

Sean

On Oct 10, 2014, at 11:42 AM, Michael Blume  wrote:
> So I'm reading a bunch of rows from a huge csv file and marshalling those 
> rows into maps using the first row as keys. I wrote the function two ways: 
> https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the version 
> with eval is twice as fast and I'm kind of curious about why. Presumably the 
> eval'd function still implicitly contains a list of keys, it's still 
> implicitly treating each row as a seq and walking it, so I'm wondering what 
> the seq-destructuring and the map literal are doing under the hood that's 
> faster.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is my function faster with eval?

[Ben Wolfson]

I believe it's because the `mapper` function is just creating and returning
a map literal. The "mapper" function in the evaled version is something
like this:

user> (def names '[n1 n2 n3 n4])
#'user/names
user> (def headers '[h1 h2 h3 h4])
#'user/headers
user> `(fn [[~@names]] ~(zipmap headers names))
(clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a
map literal, whose keys are already known.

Whereas in the first version, zipmap has to be called, iterating over
headers and names each time.

On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield  wrote:

> It may be more to do with the difference between `for` and `map`. How do
> these versions compare in your benchmark:
>
> (defn read-to-maps-partial [rows]
>   (let [headers (->>
>   rows
>   first
>   (take-while (complement #{""}))
>   (map keyword))]
> (map (partial zipmap headers) (rest rows
>
> (defn read-to-maps-fn [rows]
>   (let [headers (->>
>   rows
>   first
>   (take-while (complement #{""}))
>   (map keyword))
> mapper (fn [row] (zipmap headers row))]
> (map mapper (rest rows
>
> Sean
>
> On Oct 10, 2014, at 11:42 AM, Michael Blume  wrote:
> > So I'm reading a bunch of rows from a huge csv file and marshalling
> those rows into maps using the first row as keys. I wrote the function two
> ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the
> version with eval is twice as fast and I'm kind of curious about why.
> Presumably the eval'd function still implicitly contains a list of keys,
> it's still implicitly treating each row as a seq and walking it, so I'm
> wondering what the seq-destructuring and the map literal are doing under
> the hood that's faster.
>
>


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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: Why is my function faster with eval?

[Michael Blume]

https://github.com/MichaelBlume/eval-speed

eval-speed.core=> (time-fn read-to-maps)
"Elapsed time: 5551.011069 msecs"
nil
eval-speed.core=> (time-fn read-to-maps-fn)
"Elapsed time: 5587.256991 msecs"
nil
eval-speed.core=> (time-fn read-to-maps-partial)
"Elapsed time: 5606.649172 msecs"
nil
eval-speed.core=> (time-fn read-to-maps-eval)
"Elapsed time: 2627.521592 msecs"
nil

Ben, I'd still like to understand exactly what work the CPU is doing in the 
uneval'd version that it's skipping in the eval'd version. It seems like in 
the generated bytecode there's going to be *some* concept of iterating 
through the row in either case, if only as part of the destructuring 
process.


On Friday, October 10, 2014 1:07:08 PM UTC-7, Ben wrote:
>
> I believe it's because the `mapper` function is just creating and 
> returning a map literal. The "mapper" function in the evaled version is 
> something like this:
>
> user> (def names '[n1 n2 n3 n4])
> #'user/names
> user> (def headers '[h1 h2 h3 h4])
> #'user/headers
> user> `(fn [[~@names]] ~(zipmap headers names))
> (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
> map literal, whose keys are already known.
>
> Whereas in the first version, zipmap has to be called, iterating over 
> headers and names each time.
>
> On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield  > wrote:
>
>> It may be more to do with the difference between `for` and `map`. How do 
>> these versions compare in your benchmark:
>>
>> (defn read-to-maps-partial [rows]
>>   (let [headers (->>
>>   rows
>>   first
>>   (take-while (complement #{""}))
>>   (map keyword))]
>> (map (partial zipmap headers) (rest rows
>>
>> (defn read-to-maps-fn [rows]
>>   (let [headers (->>
>>   rows
>>   first
>>   (take-while (complement #{""}))
>>   (map keyword))
>> mapper (fn [row] (zipmap headers row))]
>> (map mapper (rest rows
>>
>> Sean
>>
>> On Oct 10, 2014, at 11:42 AM, Michael Blume > > wrote:
>> > So I'm reading a bunch of rows from a huge csv file and marshalling 
>> those rows into maps using the first row as keys. I wrote the function two 
>> ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
>> version with eval is twice as fast and I'm kind of curious about why. 
>> Presumably the eval'd function still implicitly contains a list of keys, 
>> it's still implicitly treating each row as a seq and walking it, so I'm 
>> wondering what the seq-destructuring and the map literal are doing under 
>> the hood that's faster.
>>
>>
>
>
> -- 
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which 
> may be sweet, aromatic, fermented or spirit-based. ... Family and social 
> life also offer numerous other occasions to consume drinks for pleasure." 
> [Larousse, "Drink" entry]
>
>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: Why is my function faster with eval?

[Ashton Kemerling]

Did you run it enough times to fully warm up the JVM?

On Fri, Oct 10, 2014 at 4:21 PM, Michael Blume 
wrote:

> https://github.com/MichaelBlume/eval-speed
> eval-speed.core=> (time-fn read-to-maps)
> "Elapsed time: 5551.011069 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-fn)
> "Elapsed time: 5587.256991 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-partial)
> "Elapsed time: 5606.649172 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-eval)
> "Elapsed time: 2627.521592 msecs"
> nil
> Ben, I'd still like to understand exactly what work the CPU is doing in the 
> uneval'd version that it's skipping in the eval'd version. It seems like in 
> the generated bytecode there's going to be *some* concept of iterating 
> through the row in either case, if only as part of the destructuring 
> process.
> On Friday, October 10, 2014 1:07:08 PM UTC-7, Ben wrote:
>>
>> I believe it's because the `mapper` function is just creating and 
>> returning a map literal. The "mapper" function in the evaled version is 
>> something like this:
>>
>> user> (def names '[n1 n2 n3 n4])
>> #'user/names
>> user> (def headers '[h1 h2 h3 h4])
>> #'user/headers
>> user> `(fn [[~@names]] ~(zipmap headers names))
>> (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
>> map literal, whose keys are already known.
>>
>> Whereas in the first version, zipmap has to be called, iterating over 
>> headers and names each time.
>>
>> On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield > > wrote:
>>
>>> It may be more to do with the difference between `for` and `map`. How do 
>>> these versions compare in your benchmark:
>>>
>>> (defn read-to-maps-partial [rows]
>>>   (let [headers (->>
>>>   rows
>>>   first
>>>   (take-while (complement #{""}))
>>>   (map keyword))]
>>> (map (partial zipmap headers) (rest rows
>>>
>>> (defn read-to-maps-fn [rows]
>>>   (let [headers (->>
>>>   rows
>>>   first
>>>   (take-while (complement #{""}))
>>>   (map keyword))
>>> mapper (fn [row] (zipmap headers row))]
>>> (map mapper (rest rows
>>>
>>> Sean
>>>
>>> On Oct 10, 2014, at 11:42 AM, Michael Blume >> > wrote:
>>> > So I'm reading a bunch of rows from a huge csv file and marshalling 
>>> those rows into maps using the first row as keys. I wrote the function two 
>>> ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
>>> version with eval is twice as fast and I'm kind of curious about why. 
>>> Presumably the eval'd function still implicitly contains a list of keys, 
>>> it's still implicitly treating each row as a seq and walking it, so I'm 
>>> wondering what the seq-destructuring and the map literal are doing under 
>>> the hood that's faster.
>>>
>>>
>>
>>
>> -- 
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks, which 
>> may be sweet, aromatic, fermented or spirit-based. ... Family and social 
>> life also offer numerous other occasions to consume drinks for pleasure." 
>> [Larousse, "Drink" entry]
>>
>>  
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To 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.

Re: Why is my function faster with eval?

[Sean Corfield]

Ah, interesting... I hadn't considered it was running the zipmap at 
compile-time so it only runs it once as opposed to running it for each row!

Sean

On Oct 10, 2014, at 1:06 PM, Ben Wolfson  wrote:
> I believe it's because the `mapper` function is just creating and returning a 
> map literal. The "mapper" function in the evaled version is something like 
> this:
> 
> user> (def names '[n1 n2 n3 n4])
> #'user/names
> user> (def headers '[h1 h2 h3 h4])
> #'user/headers
> user> `(fn [[~@names]] ~(zipmap headers names))
> (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
> map literal, whose keys are already known.
> 
> Whereas in the first version, zipmap has to be called, iterating over headers 
> and names each time.




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is my function faster with eval?

[Ben Wolfson]

it's not quite at compile-time (since it's a dynamic call to eval, after
all, and "names" and "headers" aren't known at compile time), but it is
calling it eval-time, for lack of a better phrase.

On Fri, Oct 10, 2014 at 1:35 PM, Sean Corfield  wrote:

> Ah, interesting... I hadn't considered it was running the zipmap at
> compile-time so it only runs it once as opposed to running it for each row!
>
> Sean
>
> On Oct 10, 2014, at 1:06 PM, Ben Wolfson  wrote:
> > I believe it's because the `mapper` function is just creating and
> returning a map literal. The "mapper" function in the evaled version is
> something like this:
> >
> > user> (def names '[n1 n2 n3 n4])
> > #'user/names
> > user> (def headers '[h1 h2 h3 h4])
> > #'user/headers
> > user> `(fn [[~@names]] ~(zipmap headers names))
> > (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just
> a map literal, whose keys are already known.
> >
> > Whereas in the first version, zipmap has to be called, iterating over
> headers and names each time.
>
>
>


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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: Why is my function faster with eval?

[Sean Corfield]

On Oct 10, 2014, at 1:46 PM, Ben Wolfson  wrote:
> it's not quite at compile-time (since it's a dynamic call to eval, after all, 
> and "names" and "headers" aren't known at compile time), but it is calling it 
> eval-time, for lack of a better phrase.

Yes, I meant when it compiles the code that eval executes at, er, run-time :)

Sean

> On Fri, Oct 10, 2014 at 1:35 PM, Sean Corfield  wrote:
> Ah, interesting... I hadn't considered it was running the zipmap at 
> compile-time so it only runs it once as opposed to running it for each row!
> 
> Sean
> 
> On Oct 10, 2014, at 1:06 PM, Ben Wolfson  wrote:
> > I believe it's because the `mapper` function is just creating and returning 
> > a map literal. The "mapper" function in the evaled version is something 
> > like this:
> >
> > user> (def names '[n1 n2 n3 n4])
> > #'user/names
> > user> (def headers '[h1 h2 h3 h4])
> > #'user/headers
> > user> `(fn [[~@names]] ~(zipmap headers names))
> > (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
> > map literal, whose keys are already known.
> >
> > Whereas in the first version, zipmap has to be called, iterating over 
> > headers and names each time.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN: State of Clojure 2014 Survey - please contribute!!

[Mars0i]

I'd be interested in a site that lists examples of academic projects in 
Clojure.  (I know of a few Clojure projects in areas of interest to me.)  
But only a little bit interested--not enough for me to create such a site.

-- 
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} defun: A beautiful macro to define clojure functions with pattern match.

[Mars0i]

I think it *is* a beautiful macro.

On Sep 14, 2014, at 7:45 AM, adrian...@mail.yu.edu  wrote:
>
> Friendly advice: when you describe anything you create with adjectives 
> like beautiful, it comes off as unnecessarily arrogant to native English 
> speakers.
>
> Adrian
>
> On Sunday, September 14, 2014 2:47:28 AM UTC-4, dennis wrote:
>>
>>
>> Hi , i am pleased to introduce defun 
>> : a beautiful macro to define 
>> clojure functions with pattern match.
>>
>> Some examples:
>>
>>
>> (defun say-hi
>>
>>   ([:dennis] "Hi,good morning, dennis.")
>>
>>   ([:catty] "Hi, catty, what time is it?")
>>
>>   ([:green] "Hi,green, what a good day!")
>>
>>   ([other] (str "Say hi to " other)))
>>
>>
>> (say-hi :dennis)
>>
>> ;;  "Hi,good morning, dennis."
>>
>> (say-hi :catty)
>>
>> ;;  "Hi, catty, what time is it?"
>>
>> (say-hi :green)
>>
>> ;;  "Hi,green, what a good day!"
>>
>> (say-hi "someone")
>>
>> ;;  "Say hi to someone"
>>
>>
>> Recursive function? It's all right:
>>
>> (defun count-down
>>
>>   ([0] (println "Reach zero!"))
>>
>>   ([n] (println n)
>>
>>  (recur (dec n
>>
>> (defun fib
>>
>> ([0] 0)
>>
>> ([1] 1)
>>
>> ([n] (+ (fib (- n 1)) (fib (- n 2)
>>
>>
>>
>> Guard functions? it's all right:
>>
>> (defun valid-geopoint?
>>
>> ([(_ :guard #(and (> % -180) (< % 180)))
>>
>>   (_ :guard #(and (> % -90) (< % 90)))] true)
>>
>> ([_ _] false))
>>
>>
>> (valid-geopoint? 30 30)
>>
>> ;; true
>>
>> (valid-geopoint? -181 30)
>>
>> ;; false
>>
>>
>> It's really cool,all the magic are from core.match, much more details 
>> please see 
>> https://github.com/killme2008/defun
>>
>>
>> -- 
>> 庄晓丹 
>> Email:killm...@gmail.com xzh...@avos.com
>> Site:   http://fnil.net
>> Twitter:  @killme2008
>>
>>
>>   -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@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: Schrodinger's cat in clojure?

[Mars0i]

On Saturday, September 13, 2014 9:01:53 AM UTC-5, Lee wrote:
>
> So now one of my first steps when I'm faced with a confusing bug is to 
> stamp out all of the laziness except where I'm really doing things lazily 
> on purpose, for a good reason. I've also come to think that the 
> pervasiveness and defaultness of laziness in Clojure may not really be so 
> wonderful after all. Laziness is beautiful when you want it, and when you 
> do want it it's beautiful that so much of Clojure works with it so 
> effortlessly and transparently, but it can also produce subtle problems 
> when things aren't purely functional (which is a lot of the time, in my 
> experience, sometimes for subtle reasons). 
>

In my response the State of Clojure survey question "What do you think is 
Clojure's most glaring weakness / blind spot / problem?", I wrote: 
"Laziness. "  I also said that I love it.   Both.  Most of the time it 
doesn't matter much, so if you got rid of laziness there, all you'd do is 
get rid of laziness bugs (and many questions from newbies).  Maybe an ideal 
world would be one in which there was a global setting to turn laziness on 
and off.  When you want it, have it, and know your risks.  After looking at 
the source for some of the lazy functions, I've come to suspect that such a 
feature would be completely nontrivial.

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

Keyword comparison performance

[Jony Hudson]

Hi All,

 I've been optimising a piece of code lately, and have come to wonder about 
the performance of keyword comparison. Specifically, I'm not sure whether 
the performance I'm seeing is what is expected. The data structures page on 
clojure.org [1] indicates that keywords "provide very fast equality tests". If 
I micro-benchmark with criterium, then I find the following:

As a baseline, comparing integers with `(= 0 1)` takes around 4ns.

Comparing keywords with `(= :plus :minus)` takes around 30ns.

This is about the same amount of time it takes to compare strings, `(= 
"plus" "minus")`, which comes in at about 25ns.

This surprised me, as I would have guessed that "fast" would have been 
closer to the integer performance than the string performance. It's worth 
saying that I don't know a lot about benchmarking, but I do have some 
"real" code that's performance depends heavily on comparisons, and it seems 
to line up performance-wise with these micro-benchmarks.

So, am I doing something silly (like I don't know about the fast = for 
keywords)? Or, are my expectations wrong, and this is about how long "fast" 
should be? Or is there a performance bug lurking?

I'm using Clojure 1.6.0 (but have tried 1.5.0 and 1.7.0-alpha1 with similar 
results).
x86_64 Mac OS X 10.9.5 4 cpu(s)

Java HotSpot(TM) 64-Bit Server VM 25.5-b02

Thanks in advance for any input,


Jony

[1] http://clojure.org/data%5Fstructures

-- 
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: State of Clojure 2014 Survey - please contribute!!

[Jony Hudson]

If this is the unofficial survey post of academics using Clojure then I'd 
better add myself to the list :-)

@Bruce do you know what course they're going to be teaching Clojure on at 
Birkbeck?


Jony


On Friday, 10 October 2014 08:08:28 UTC+1, Bruce Durling wrote:
>
> I also know that Birkbeck College University of London is going to be 
> teaching Clojure this year. 
> On Oct 10, 2014 12:01 AM, "Lee Spector"  > wrote:
>
>>
>> FWIW I'm another person using Clojure mostly for academic research. And 
>> for computer science education, e.g. I'm currently teaching a Clojure-based 
>> AI course. I'd be curious to know how many others of us are out there. And 
>> BTW I think that attention to users in these categories could help to grow 
>> the community.
>>
>>  -Lee
>>
>> On Oct 9, 2014, at 12:32 AM, Mars0i > 
>> wrote:
>>
>> > Thanks for the survey!
>> >
>> > I have a couple of suggestions/questions:
>> >
>> > For domains, there are no categories for scientific or other research 
>> applications.  For example, I mainly use Clojure for writing agent-based 
>> models for academic research.  Would a set of categories in this area be 
>> usedful?
>> >
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: Schrodinger's cat in clojure?

[Mars0i]

On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
>
>  Maybe an ideal world would be one in which there was a global setting to 
> turn laziness on and off.  When you want it, have it, and know your risks.  
> After looking at the source for some of the lazy functions, I've come to 
> suspect that such a feature would be completely nontrivial.
>

Oh, wait, Rich Hickey's blog post about transducers 
 says:





*But transducers can also be used for:a la carte laziness...
collection/iteration/laziness-free transforming reductions *

Not certain what this means.  Haven't fully grokked reducers.

-- 
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: Why is my function faster with eval?

[Jason Wolfe]

Zipmap doesn't use transients, so calling it at runtime will be 
significantly slower than constructing a literal map.  

http://dev.clojure.org/jira/browse/CLJ-1005

On Friday, October 10, 2014 11:42:14 AM UTC-7, Michael Blume wrote:
>
> So I'm reading a bunch of rows from a huge csv file and marshalling those 
> rows into maps using the first row as keys. I wrote the function two ways: 
> https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the version 
> with eval is twice as fast and I'm kind of curious about why. Presumably 
> the eval'd function still implicitly contains a list of keys, it's still 
> implicitly treating each row as a seq and walking it, so I'm wondering what 
> the seq-destructuring and the map literal are doing under the hood that's 
> faster.
>

-- 
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: Keyword comparison performance

[Stephen Gilardi]

>  I've been optimising a piece of code lately, and have come to wonder about 
> the performance of keyword comparison. Specifically, I'm not sure whether the 
> performance I'm seeing is what is expected. The data structures page on 
> clojure.org [1] indicates that keywords "provide very fast equality tests". 
> If I micro-benchmark with criterium, then I find the following:
> 
> As a baseline, comparing integers with `(= 0 1)` takes around 4ns.
> 
> Comparing keywords with `(= :plus :minus)` takes around 30ns.

I ran the same test and saw similar results.

I noticed that using "identical?" instead of "=" brings the performance much 
closer to the integer case because "identical?" does less work.

In most cases, equal keywords are also identical because the keyword objects 
are cached by clojure.lang.Keyword/intern. If you don't need to worry about the 
case of multiple Clojure runtimes being loaded by separate classloaders[1], and 
if you're in control of the code doing the comparison, you could change to 
using "identical?" for better performance.

Treatment of keyword equality and identity also came up during the development 
of ClojureScript. I found this discussion interesting: 
https://groups.google.com/forum/#!topic/clojurescript/bSFK6CEE3PE .

--Steve

[1] https://groups.google.com/d/msg/clojure/ZW2udohC1lA/6wLcEpQj_LoJ

-- 
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] Nginx-Clojure v0.2.6 Released!

[Xfeep]

Hi Balduino, 

Thank you.

This site use CDN http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.0.min.js 
for 
jquery , so for security the browser won't load these javascript source 
when we access it by HTTPS.

Regards.
Xfeep

On Saturday, October 11, 2014 3:11:52 AM UTC+8, Plinio Balduino wrote:
>
>
> Hi Laurens
>
> Are you trying to access http or https? If you use HTTPSEverywhere like 
> me, the browser will try to load the https version, that really doesn't 
> work and you'll see only an horizontal strip.
>
> I hope it can help you
>
> Xfeep: thank you very much. I'm moving my web applications to 
> nginx-clojure and it's really awesome.
>
> Regards
>
> P Balduino
>
> On Fri, Oct 10, 2014 at 12:16 PM, Xfeep > 
> wrote:
>
>> Hi ivh
>>
>> Thanks for your notice.
>>
>> Do you mean http://nginx-clojure.github.io/ appears to be broken in FF32 
>> ?  I can not reproduce it.
>>
>> Could you please give more information about it by reporting an issue at  
>> https://github.com/nginx-clojure/nginx-clojure.github.io/issues/new ? 
>>
>> Thanks.
>>
>> Regards.
>> Xfeep
>>
>> On Friday, October 10, 2014 10:40:30 PM UTC+8, Laurens Van Houtven wrote:
>>>
>>> Hi xfeep, 
>>>
>>>
>>> Thanks for the work! Looks awesome. Unfortunately the github website 
>>> appears to be broken in FF32 (displays fine in Chrome). 
>>>
>>>
>>> cheers 
>>> lvh 
>>>
>>>
>>>
>>> On 10 Oct 2014, at 16:03, Xfeep  wrote: 
>>>
>>> > 
>>> > 0.2.6 (2014-10-10) 
>>> > 
>>> > • Fix Bug: rewrite handler does not handle write event 
>>> correctly with thread pool mode or coroutine mode (issue #43) 
>>> > • Fix Bug: built-in jvm variable #{pno} doesn't work (issue 
>>> #44) 
>>> > • Fix Bug: rewrite_handler_name does not work without content 
>>> handler (issue #45). Thanks Eric Kubacki for finding this bug. 
>>> > • Fix Bug: rewrite handler does not handle write event 
>>> correctly with thread pool mode or coroutine mode (issue #43) 
>>> > • Documents : Correct some inaccuracies and add section about 
>>> logging in Chapter More about Nginx-Clojure 
>>> > • Binaries: built with the lastest stable Nginx v1.6.2 which 
>>> released at 2014-09-16. 
>>> > 
>>> > 
>>> > Web Site   http://nginx-clojure.github.io/ 
>>> > Source Hosted on Github https://github.com/nginx-clojure/nginx-clojure 
>>> > Google Group (mailing list) https://groups.google.com/
>>> forum/#!forum/nginx-clojure 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> > Groups "Clojure" group. 
>>> > To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@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: [ANN] Nginx-Clojure v0.2.6 Released!

[Yuexiang Zhang]

We fixed this problem now.

Both https://nginx-clojure.github.io/ and http://nginx-clojure.github.io/
 can work now.

Regards.
Xfeep

On Sat, Oct 11, 2014 at 9:49 AM, Xfeep  wrote:

> Hi Balduino,
>
> Thank you.
>
> This site use CDN http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.0.min.
> js for jquery , so for security the browser won't load these javascript
> source when we access it by HTTPS.
>
> Regards.
> Xfeep
>
> On Saturday, October 11, 2014 3:11:52 AM UTC+8, Plinio Balduino wrote:
>>
>>
>> Hi Laurens
>>
>> Are you trying to access http or https? If you use HTTPSEverywhere like
>> me, the browser will try to load the https version, that really doesn't
>> work and you'll see only an horizontal strip.
>>
>> I hope it can help you
>>
>> Xfeep: thank you very much. I'm moving my web applications to
>> nginx-clojure and it's really awesome.
>>
>> Regards
>>
>> P Balduino
>>
>> On Fri, Oct 10, 2014 at 12:16 PM, Xfeep  wrote:
>>
>>> Hi ivh
>>>
>>> Thanks for your notice.
>>>
>>> Do you mean http://nginx-clojure.github.io/ appears to be broken in
>>> FF32 ?  I can not reproduce it.
>>>
>>> Could you please give more information about it by reporting an issue at
>>>  https://github.com/nginx-clojure/nginx-clojure.github.io/issues/new ?
>>>
>>> Thanks.
>>>
>>> Regards.
>>> Xfeep
>>>
>>> On Friday, October 10, 2014 10:40:30 PM UTC+8, Laurens Van Houtven wrote:

 Hi xfeep,


 Thanks for the work! Looks awesome. Unfortunately the github website
 appears to be broken in FF32 (displays fine in Chrome).


 cheers
 lvh



 On 10 Oct 2014, at 16:03, Xfeep  wrote:

 >
 > 0.2.6 (2014-10-10)
 >
 > • Fix Bug: rewrite handler does not handle write event
 correctly with thread pool mode or coroutine mode (issue #43)
 > • Fix Bug: built-in jvm variable #{pno} doesn't work (issue
 #44)
 > • Fix Bug: rewrite_handler_name does not work without content
 handler (issue #45). Thanks Eric Kubacki for finding this bug.
 > • Fix Bug: rewrite handler does not handle write event
 correctly with thread pool mode or coroutine mode (issue #43)
 > • Documents : Correct some inaccuracies and add section about
 logging in Chapter More about Nginx-Clojure
 > • Binaries: built with the lastest stable Nginx v1.6.2 which
 released at 2014-09-16.
 >
 >
 > Web Site   http://nginx-clojure.github.io/
 > Source Hosted on Github https://github.com/nginx-cloju
 re/nginx-clojure
 > Google Group (mailing list) https://groups.google.com/foru
 m/#!forum/nginx-clojure
 >
 > --
 > You received this message because you are subscribed to the Google
 > Groups "Clojure" group.
 > To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/1vPRW5x-Uu8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://grou