Re: [ANN] Stasis - not another static site framework

[Magnar Sveen]

Hi Jarrod,

Sounds to me like you're using harpjs mainly as an asset pipeline 
replacement? Stasis doesn't care about Jade, LESS or any such thing - 
because that is covered by other libraries that you would use along with 
it. Stasis is only concerned with 1) serving your pages live in 
development, and then 2) exporting them to disk. All sites using Stasis 
that I know 
ofuse
 
Optimus  for its frontend optimization. 
It has a LESS asset loader , but 
no one has made one for Jade. I would guess you could use 
Twixtinstead, which comes bundled with 
support for both Jade and LESS.

But again - if you're using harpjs mainly for its compilation, Stasis isn't 
a good fit. You could probably use Twixt directly instead, and do your 
compilation in the same process that is serving your web pages.

- Magnar

On Wednesday, March 5, 2014 1:08:06 AM UTC+1, Jarrod Swart wrote:
>
> This is a cool project.  I primarily use static site generators to build 
> the front-end for sites that I will use enlive to template inside my app.
>
> I currently use: http://harpjs.com for this purpose because it allows 
> easy integration of LESS and Jade which are auto recompiled & watched by 
> the dev server.  
>
> This allows minimal html/css/js to be handwritten then it gets compiled to 
> the static site, from there I use only enlive for templating.  All in all 
> it is a very fast way to create the front-end templates for web apps.
>
> How does stasis compare to this?  Could I replicate it?  Or is this just 
> too far from the intended workflow of Stasis?
>
>
> On Monday, March 3, 2014 4:51:02 PM UTC-5, Magnar Sveen wrote:
>>
>> Just a heads up that Stasis 1.0.0 has been released. The API has been 
>> stable for two months now. I've built three sites with it, and I know of 
>> two other sites built with Stasis too: 
>>
>>- The docs for SinonJS: http://sinonjs.org/ 
>>- J David Smith's blog at http://atlanis.net/blog/ 
>>
>> He even wrote a blog post about it here: 
>> http://atlanis.net/blog/posts/new-site-stasis.html
>>
>> So if you were on the fence because of the 0.x release, worry no more. :) 
>> Building a static site is an excellent way to have fun with Clojure, and 
>> get a lightning fast web site that can handle any amount of traffic.
>>
>> - Magnar
>>
>> On Thursday, January 23, 2014 11:16:48 AM UTC+1, Magnar Sveen wrote:
>>>
>>> Stasis
>>>
>>> A Clojure library of tools for developing static web sites.
>>>
>>> Another
>>>  
>>> static site framework? Why?
>>>
>>> Well, that's exactly it. I didn't want to use a framework. I don't like 
>>> the restrained feeling I get when using them. I prefer coding things over 
>>> messing around with configuration files.
>>>
>>> I want to
>>>
>>>- code my own pages
>>>- set up my own configuration
>>>- choose my own templating library
>>>- create my own damn stylesheets
>>>
>>> *Statis offers a few functions that are pretty useful when creating 
>>> static web sites.*
>>>
>>> No more. There are no batteries included.
>>>
>>> If you want a framework that makes it really quick and easy to create a 
>>> blog, you should take a look at these:
>>>
>>>- misaki  is a Jekyll inspired 
>>>static site generator in Clojure.
>>>- Madness  is a static site 
>>>generator, based on Enlive and Bootstrap.
>>>- Static  is a simple static site 
>>>generator written in Clojure.
>>>- Ecstatic  creates static web pages and 
>>>blog posts from Hiccup templates and Markdown.
>>>- incise  is an extensible static 
>>>site generator written in Clojure.
>>>
>>> They generally come with a folder where you put your blog posts in some 
>>> templating language, and a set of configuration options about how to set up 
>>> your blog. They often generate code for you to tweak.
>>> Usage
>>>
>>> The core of Stasis is two functions: serve-pages and export-pages. Both 
>>> take a map from path to contents:
>>>
>>> (def pages {"/index.html" "Welcome!"})
>>>
>>> The basic use case is to serve these live on a local server while 
>>> developing - and then exporting them as static pages to deploy on some 
>>> server.
>>>
>>> Serving
>>>  
>>> live pages locally
>>>
>>> Stasis can create a Ring handler to serve your pages.
>>>
>>> (ns example
>>>   (:require [stasis.core :as stasis]))
>>> (def app (stasis/serve-pages pages))
>>>
>>> Like with any Ring app, you point to your app in p

Om-powered HTML slide-decks

[Malcolm Sparks]

There are some HTML-based tools out there (reveal.js, slidy, impress.js, 
deck.js ...) for building slide-based presentations for conference talks.

But you usually have to write your slides in raw HTML. This feels 
cumbersome when you're used to writing LISP s-expressions with paredit. And 
if you want to build in more interactivity, you have to be proficient in 
JavaScript.

Last week I gave a presentation at QCon in London for which I built a 
slide-deck in Om. This proved (far) easier than my previous failed attempts 
with other technologies (including vanilla ClojureScript).

I've found that ClojureScript + Om/RevealJS + core.async (go-blocks) also 
makes a great platform for browser-based interactive SVG diagrams and 
animations. Not quite Flash, but almost, and in some ways better.

Anyway, I've uploaded the slides, code, instructions and everything to 
here: https://github.com/juxt/qcon2014. in case anyone else wants to try 
building an Om-based slide-deck at a future event.

-- 
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: Getting started - overcoming my first obstacles

[Frank Behrens]

Dear Florian (or anybody),

I really like how your post is so beautifully syntax highlighted.
How did you do that ?

nice day !, Frank
(PS this Frank)
 

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

Working with big datasets, merging two ordered lists by key

[Frank Behrens]

Hi,

i'm investigating if clojure can be used to solve the challenges and 
problems we have at my day job better than ruby or powershell. A very 
common use case is validating data from different  systems against some 
criteria. i believe clojure can be our silver bullet, but before that, it 
seems to be required to wrap my head around it.

So I am starting in the first level with the challenge to validate some 
data from the user database against our active directory.

I already have all the parts to make it work: Which is to make a hash by 
user_id from the database table, export a textfile from AD, each line 
representing a user, parse it, merge the information from the 
user_table_hash, and voila. 

I did not finish to implement this. So I don't know if this naive approach 
will work with 400.000 records in the user database and 100.000 in the 
textfile.
But I already think about how I could implement this in a more memory 
efficient way.

So my simple question:

I have user_textfile (100.000 records) which can be parsed into a unordered 
list of user-maps.
I have user_table in the database(400.000 record) which I can query with 
order and gives me an ordered list of user-maps.

So I would first order the user_textfile and then conj the user_table 
ordered list into it, while doing the database query.
Is that approach right ? How would I then merge the two ordered lists like 
in the example below?

(defn user_textfile
  ([:id1 {:name 'Frank'}]
   [:id3 {:name 'Tim'}]))  

(defn user_database
  ([:id1 {:age 38}]
   [:id2 {:age 27}]
   [:id3 {:age 18}]
   [:id4 {:age 60}])) 

(merge-sorted-lists user_database user_textfile)
=>
  ([:id1 {:name 'Frank' :age 38}]
   [:id3 {:name 'Tim'   :age 18}]))  

Any feedback is appreciated.
Have a nice day,
Frank

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

More functional Quil

[J . Pablo Fernández]

Hello Clojurians,

I'm starting to play with Processing and I want to use my favorite 
programming language for it, so I started using 
Quil. 
The problem is that Processing has a imperative architecture and makes my 
Clojure code look bad. For those that don't know Processing/Quil, here's a 
little overview that's relevant to this email.

Processing is a language and a library that makes it easy to draw on the 
screen to do generative art, simulations, etc. Processing programs have two 
methods, a setup method that is run once, at the beginning, and then a draw 
method that is run over and over. Literally something like:

Walker w;

void setup() {
  w = new Walker();
}

void draw() {
  w.render();
  w.walk();
}

I'm using a hypothetical walker, an entity that walks around the screen. 
More or less taken from here: http://natureofcode.com/book/introduction/

My understanding is that the equivalent Clojure code using Quil would look 
like this:

(defn setup []
  (set-state! :walker (atom (create-walker

(defn draw []
  (render-walker @(state :walker))
  (swap! (state :walker) walk))

Quil stores a map in the meta-data of the Processing applet and let's you 
access it. Since I need the state to change, I'm storing the walker in an 
atom. I found examples out there following more or less this structure. I'm 
not happy with this structure, it doesn't feel functional enough.

When thinking about this, I got reminded of Erlang processes, specially 
with OTP, where you have a function that's called over and over to which 
the state is passed and which returns the next state. Following that 
structure I would like to implement it like this:

(defn setup []
  [(create-walker)])

(defn draw [walker]
  (render-walker walker)
  [(walk walker)])

The result of calling setup is a vector containing the attributes to draw, 
and the result of draw is a vector containing the attributes that will be 
used in the next call to draw.

Does this make sense? Does it look cleaner to you guys?

I achieved that by writing this wrappers for setup and draw:

(defn setup-wrapper []
  (set-state! :state (atom (setup

(defn draw-wrapper []
  (swap! (state :state)
 (fn [s] (apply draw s

My concern with this is that now the whole state is in one single atom that 
I'm replacing on each frame and that might not be good. Is it copying the 
whole state or can Clojure use its copy-on-demand feature even for atoms? 
Is there a better way of doing this?

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.

Need help understanding a lazy sequence function

[Asfand Yar Qazi]

Hi,

I'm trying to understand the following function (from 
http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Lazy_Fibonacci#Self-Referential_Version):

(def fib-seq
  (lazy-seq
(map +
  (cons 0 (cons 0 fib-seq))
  (cons 1 fib-seq

I'm trying to understand how this works.  In particular, I do not 
understand what the recursive call to fib-seq will return when the sequence 
is lazily evaluated.

Here's my understanding so far:

The first time fib-seq is invoked, it has no head, and the function is the 
tail.  So we go into the first collection, where we append 0 and 0 to 
fib-seq, which then '(0 0) .  This is then mapped with the second 
collection, which (because fib-seq has not returned anything yet) is '(1) . 
 Shouldn't map then raise an error because it is effectively being called 
as (map + (0 0) (1)) ?

I would be very grateful for any insights.

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: More functional Quil

[Laurent PETIT]

Hello,

To be honest I don't see any fundamental difference between your first
attempt and the improvement: both share the fact that the mutation of the
state happens within the draw function. So in both cases, you have a
temporal coupling between updating the state of the app and rendering a new
view of the app's state.

I would suggest that you don't swap! at all within draw, just deref and
render the result of the dereffing.

And, in another thread, at potentially a totally different pace than the
redrawing's pace, update the application's state accordingly to business
rules / constraints.

Schematically, something like this:

(def app-state (atom (init-state)))

(defn draw [...]
  (let [app-snapshot (deref app-state)]
  ... call quil primitives to render the application state snapshot
...))

(future
  ... logic which updates the app-state atom depending on business rules /
constraints, in a separate thread ...)


HTH,

-- 
Laurent



2014-03-09 13:47 GMT+01:00 J. Pablo Fernández :

> Hello Clojurians,
>
> I'm starting to play with Processing and I want to use my favorite
> programming language for it, so I started using 
> Quil.
> The problem is that Processing has a imperative architecture and makes my
> Clojure code look bad. For those that don't know Processing/Quil, here's a
> little overview that's relevant to this email.
>
> Processing is a language and a library that makes it easy to draw on the
> screen to do generative art, simulations, etc. Processing programs have two
> methods, a setup method that is run once, at the beginning, and then a draw
> method that is run over and over. Literally something like:
>
> Walker w;
>
> void setup() {
>   w = new Walker();
> }
>
> void draw() {
>   w.render();
>   w.walk();
> }
>
> I'm using a hypothetical walker, an entity that walks around the screen.
> More or less taken from here: http://natureofcode.com/book/introduction/
>
> My understanding is that the equivalent Clojure code using Quil would look
> like this:
>
> (defn setup []
>   (set-state! :walker (atom (create-walker
>
> (defn draw []
>   (render-walker @(state :walker))
>   (swap! (state :walker) walk))
>
> Quil stores a map in the meta-data of the Processing applet and let's you
> access it. Since I need the state to change, I'm storing the walker in an
> atom. I found examples out there following more or less this structure. I'm
> not happy with this structure, it doesn't feel functional enough.
>
> When thinking about this, I got reminded of Erlang processes, specially
> with OTP, where you have a function that's called over and over to which
> the state is passed and which returns the next state. Following that
> structure I would like to implement it like this:
>
> (defn setup []
>   [(create-walker)])
>
> (defn draw [walker]
>   (render-walker walker)
>   [(walk walker)])
>
> The result of calling setup is a vector containing the attributes to draw,
> and the result of draw is a vector containing the attributes that will be
> used in the next call to draw.
>
> Does this make sense? Does it look cleaner to you guys?
>
> I achieved that by writing this wrappers for setup and draw:
>
> (defn setup-wrapper []
>   (set-state! :state (atom (setup
>
> (defn draw-wrapper []
>   (swap! (state :state)
>  (fn [s] (apply draw s
>
> My concern with this is that now the whole state is in one single atom
> that I'm replacing on each frame and that might not be good. Is it copying
> the whole state or can Clojure use its copy-on-demand feature even for
> atoms? Is there a better way of doing this?
>
> 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.
>

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

Re: More functional Quil

[J . Pablo Fernández]

On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>
> Hello, 
>
> To be honest I don't see any fundamental difference between your first 
> attempt and the improvement: both share the fact that the mutation of the 
> state happens within the draw function. So in both cases, you have a 
> temporal coupling between updating the state of the app and rendering a new 
> view of the app's state.
>

Yes, what's happening in both cases is very similar, but the function draw 
in the "functional" style, in my opinion, is easier to read and maybe it's 
also easier to test.
 

> I would suggest that you don't swap! at all within draw, just deref and 
> render the result of the dereffing.
>
> And, in another thread, at potentially a totally different pace than the 
> redrawing's pace, update the application's state accordingly to business 
> rules / constraints.
>
> Schematically, something like this: 
>
> (def app-state (atom (init-state)))
>
> (defn draw [...]
>   (let [app-snapshot (deref app-state)]
>   ... call quil primitives to render the application state snapshot 
> ...))
>
> (future
>   ... logic which updates the app-state atom depending on business rules / 
> constraints, in a separate thread ...)
>

I never worked with future, this is exciting, but I have some questions. Do 
you mean that future is completely separate from draw? I'm just getting 
started, but draw is not only a function to draw, but as a side effect is 
the clock of the app, as it's called according to the set frames per second 
and you normally *take a step* en each draw. Would draw create these 
futures for the next draw?

-- 
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: More functional Quil

[Laurent PETIT]

2014-03-09 14:21 GMT+01:00 J. Pablo Fernández :

>
>
> On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>>
>> Hello,
>>
>> To be honest I don't see any fundamental difference between your first
>> attempt and the improvement: both share the fact that the mutation of the
>> state happens within the draw function. So in both cases, you have a
>> temporal coupling between updating the state of the app and rendering a new
>> view of the app's state.
>>
>
> Yes, what's happening in both cases is very similar, but the function draw
> in the "functional" style, in my opinion, is easier to read and maybe it's
> also easier to test.
>
>
>> I would suggest that you don't swap! at all within draw, just deref and
>> render the result of the dereffing.
>>
>> And, in another thread, at potentially a totally different pace than the
>> redrawing's pace, update the application's state accordingly to business
>> rules / constraints.
>>
>> Schematically, something like this:
>>
>> (def app-state (atom (init-state)))
>>
>> (defn draw [...]
>>   (let [app-snapshot (deref app-state)]
>>   ... call quil primitives to render the application state snapshot
>> ...))
>>
>> (future
>>   ... logic which updates the app-state atom depending on business rules
>> / constraints, in a separate thread ...)
>>
>
> I never worked with future, this is exciting, but I have some questions.
> Do you mean that future is completely separate from draw? I'm just getting
> started, but draw is not only a function to draw, but as a side effect is
> the clock of the app, as it's called according to the set frames per second
> and you normally *take a step* en each draw. Would draw create these
> futures for the next draw?
>

future is just a detail in what I was trying to explain.
If your logic ties the frame rate and the stepping function, then forget
about what I was suggesting. You just will have to ensure that all your
logic+rendering time is below the app's clock rate, of course.


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

How to use function "doubles" ?

[ru]

(doubles (into-array [1.2 2.2]))
#

???

-- 
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: How to use function "doubles" ?

[Jozef Wagner]

(double-array [1.2 2.2])

doubles just cast object into a double array, which fails if the object is
not already one. It does not convert arbitrary array into array of doubles.
doubles is used in few cases, when you need to pass array of doubles
instead of just Object (or to get rid of reflection/to improve performance
of some loop which uses double array)

Jozef


On Sun, Mar 9, 2014 at 3:23 PM, ru  wrote:

> (doubles (into-array [1.2 2.2]))
> # cannot be cast to [D>
>
> ???
>
> --
> 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: Need help understanding a lazy sequence function

[Atamert Ölçgen]

Hello,

(take 1 fib-seq) => (1)


Which can also be seen as[*] (map + (0) (1))

(map + '(0) '(1)) => (1)


Makes sense?

(take 2 fib-seq) => (1 1)


Here the recursive definition (note that it's not a function, fib-seq
simply a Var that holds a LazySeq object) comes into play. We already know
the first element in the sequence, so:

(map + '(0 0) '(1 1)) => (1 1)


The second 1 there is the first element of the fib-seq.


*: I'm using vague language intentionally here. Anyone who knows the right
term please correct me.


On Sun, Mar 9, 2014 at 12:54 PM, Asfand Yar Qazi  wrote:

> Hi,
>
> I'm trying to understand the following function (from
> http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Lazy_Fibonacci#Self-Referential_Version
> ):
>
> (def fib-seq
>   (lazy-seq
> (map +
>   (cons 0 (cons 0 fib-seq))
>   (cons 1 fib-seq
>
> I'm trying to understand how this works.  In particular, I do not
> understand what the recursive call to fib-seq will return when the sequence
> is lazily evaluated.
>
> Here's my understanding so far:
>
> The first time fib-seq is invoked, it has no head, and the function is the
> tail.  So we go into the first collection, where we append 0 and 0 to
> fib-seq, which then '(0 0) .  This is then mapped with the second
> collection, which (because fib-seq has not returned anything yet) is '(1) .
>  Shouldn't map then raise an error because it is effectively being called
> as (map + (0 0) (1)) ?
>
> I would be very grateful for any insights.
>
> 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.
>



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

Om-powered HTML slide-decks

[Base]

This is really cool.  Could you share some examples of the SVG animations you 
have been playing with?  

-- 
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: Getting started - overcoming my first obstacles

[Florian Salihovic]

That's actually quite easy. I saved my script as a github gist and copied 
it from there ... with all the highlighting etc.

Cheers Florian



Am Sonntag, 9. März 2014 10:36:44 UTC+1 schrieb Frank Behrens:
>
> Dear Florian (or anybody),
>
> I really like how your post is so beautifully syntax highlighted.
> How did you do that ?
>
> nice day !, Frank
> (PS this Frank)
>  
>

-- 
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: Working with big datasets, merging two ordered lists by key

[Timothy Washington]

Hey Frank,

Try opening up a repl, and running this *for* comprehension.

(def user_textfile [[:id1 {:name 'Frank'}] [:id3 {:name 'Tim'}]])
(def user_database [[:id1 {:age 38}] [:id2 {:age 27}] [:id3 {:age 18}]
[:id4 {:age 60}]])

(for [i user_textfile
j user_database
:when (= (first i) (first j))]
{(first i) (merge (second i) (second j))})

*({:id1 {:age 38, :name Frank'}} {:id3 {:age 18, :name Tim'}})  ;; result
from repl *



Hth

Tim Washington
Interruptsoftware.com 


On Sun, Mar 9, 2014 at 5:33 AM, Frank Behrens  wrote:

> Hi,
>
> i'm investigating if clojure can be used to solve the challenges and
> problems we have at my day job better than ruby or powershell. A very
> common use case is validating data from different  systems against some
> criteria. i believe clojure can be our silver bullet, but before that, it
> seems to be required to wrap my head around it.
>
> So I am starting in the first level with the challenge to validate some
> data from the user database against our active directory.
>
> I already have all the parts to make it work: Which is to make a hash by
> user_id from the database table, export a textfile from AD, each line
> representing a user, parse it, merge the information from the
> user_table_hash, and voila.
>
> I did not finish to implement this. So I don't know if this naive approach
> will work with 400.000 records in the user database and 100.000 in the
> textfile.
> But I already think about how I could implement this in a more memory
> efficient way.
>
> So my simple question:
>
> I have user_textfile (100.000 records) which can be parsed into a
> unordered list of user-maps.
> I have user_table in the database(400.000 record) which I can query with
> order and gives me an ordered list of user-maps.
>
> So I would first order the user_textfile and then conj the user_table
> ordered list into it, while doing the database query.
> Is that approach right ? How would I then merge the two ordered lists like
> in the example below?
>
> (defn user_textfile
>   ([:id1 {:name 'Frank'}]
>[:id3 {:name 'Tim'}]))
>
> (defn user_database
>   ([:id1 {:age 38}]
>[:id2 {:age 27}]
>[:id3 {:age 18}]
>[:id4 {:age 60}]))
>
> (merge-sorted-lists user_database user_textfile)
> =>
>   ([:id1 {:name 'Frank' :age 38}]
>[:id3 {:name 'Tim'   :age 18}]))
>
> Any feedback is appreciated.
> Have a nice day,
> Frank
>
> --
> 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: Working with big datasets, merging two ordered lists by key

[Moritz Ulrich]

I think it would be more efficient to read one of the inputs into a
map for random access instead of iterating it every time.

On Sun, Mar 9, 2014 at 4:48 PM, Timothy Washington  wrote:
> Hey Frank,
>
> Try opening up a repl, and running this for comprehension.
>
> (def user_textfile [[:id1 {:name 'Frank'}] [:id3 {:name 'Tim'}]])
> (def user_database [[:id1 {:age 38}] [:id2 {:age 27}] [:id3 {:age 18}] [:id4
> {:age 60}]])
>
> (for [i user_textfile
> j user_database
> :when (= (first i) (first j))]
> {(first i) (merge (second i) (second j))})
>
> ({:id1 {:age 38, :name Frank'}} {:id3 {:age 18, :name Tim'}})  ;; result
> from repl
>
>
>
> Hth
>
> Tim Washington
> Interruptsoftware.com
>
>
> On Sun, Mar 9, 2014 at 5:33 AM, Frank Behrens  wrote:
>>
>> Hi,
>>
>> i'm investigating if clojure can be used to solve the challenges and
>> problems we have at my day job better than ruby or powershell. A very common
>> use case is validating data from different  systems against some criteria. i
>> believe clojure can be our silver bullet, but before that, it seems to be
>> required to wrap my head around it.
>>
>> So I am starting in the first level with the challenge to validate some
>> data from the user database against our active directory.
>>
>> I already have all the parts to make it work: Which is to make a hash by
>> user_id from the database table, export a textfile from AD, each line
>> representing a user, parse it, merge the information from the
>> user_table_hash, and voila.
>>
>> I did not finish to implement this. So I don't know if this naive approach
>> will work with 400.000 records in the user database and 100.000 in the
>> textfile.
>> But I already think about how I could implement this in a more memory
>> efficient way.
>>
>> So my simple question:
>>
>> I have user_textfile (100.000 records) which can be parsed into a
>> unordered list of user-maps.
>> I have user_table in the database(400.000 record) which I can query with
>> order and gives me an ordered list of user-maps.
>>
>> So I would first order the user_textfile and then conj the user_table
>> ordered list into it, while doing the database query.
>> Is that approach right ? How would I then merge the two ordered lists like
>> in the example below?
>>
>> (defn user_textfile
>>   ([:id1 {:name 'Frank'}]
>>[:id3 {:name 'Tim'}]))
>>
>> (defn user_database
>>   ([:id1 {:age 38}]
>>[:id2 {:age 27}]
>>[:id3 {:age 18}]
>>[:id4 {:age 60}]))
>>
>> (merge-sorted-lists user_database user_textfile)
>> =>
>>   ([:id1 {:name 'Frank' :age 38}]
>>[:id3 {:name 'Tim'   :age 18}]))
>>
>> Any feedback is appreciated.
>> Have a nice day,
>> Frank
>>
>> --
>> 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" 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: Om-powered HTML slide-decks

[haosdent]

An awesome slide.


On Sun, Mar 9, 2014 at 11:15 PM, Base  wrote:

> This is really cool.  Could you share some examples of the SVG animations
> you have been playing with?
>
> --
> 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 Regards,
Haosdent Huang

-- 
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: Om-powered HTML slide-decks

[Ben Mabey]

On 3/9/14, 3:45 AM, Malcolm Sparks wrote:
There are some HTML-based tools out there (reveal.js, slidy, 
impress.js, deck.js ...) for building slide-based presentations for 
conference talks.


But you usually have to write your slides in raw HTML. This feels 
cumbersome when you're used to writing LISP s-expressions with 
paredit. And if you want to build in more interactivity, you have to 
be proficient in JavaScript.


Last week I gave a presentation at QCon in London for which I built a 
slide-deck in Om. This proved (far) easier than my previous failed 
attempts with other technologies (including vanilla ClojureScript).


I've found that ClojureScript + Om/RevealJS + core.async (go-blocks) 
also makes a great platform for browser-based interactive SVG diagrams 
and animations. Not quite Flash, but almost, and in some ways better.


Anyway, I've uploaded the slides, code, instructions and everything to 
here: https://github.com/juxt/qcon2014. in case anyone else wants to 
try building an Om-based slide-deck at a future event.



These look great Malcom!  It so happens that I'm presenting on 
core.async next month and so having some cljs interactive examples will 
be very helpful.  Thanks for sharing!


-Ben

--
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: Om-powered HTML slide-decks

[Malcolm Sparks]

Sure. For SVG examples please view the presentation here: 
http://qcon.juxt.pro - I'm sorry it isn't (yet) responsive or 
touch-sensitive (getting it working on my laptop before the talk became the 
overriding priority) so you'll need a keyboard to control it. Use the 
left/right arrow keys to navigate between slides.

SVG animations are on slides 19, 20, 22, 26, 29 and 30.

Source code is here: 
https://github.com/juxt/qcon2014/blob/master/src-cljs/qcon/main.cljs

Thanks in part to Ŝablono[1] providing the Hiccup syntax, blending together 
SVG, ClojureScript and Om component state is easy :-

[:g {:transform "translate(30,0)"
  :onClick (fn [_] (new-random-pick owner))}
  [:rect
 {:x 0 :y 65 :width 100 :height 100 :fill "black" :stroke "white" 
:stroke-width 3}]
 (when-let [n (om/get-state owner :pending-put)]
   [:text {:x 20 :y 150 :style {:font-size "64pt" :color "white"} :fill 
"white"} (str n)])]

[1] Ŝablonp - https://github.com/r0man/sablono


On Sunday, 9 March 2014 15:15:29 UTC, Base wrote:
>
> This is really cool.  Could you share some examples of the SVG animations 
> you have been playing with?  

-- 
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: Compiling Clojure security knowledge

[Christopher Poile]

On Monday, September 2, 2013 8:10:10 PM UTC-6, Nelson Morris wrote:
>
>
> 
>
> Several of Yesod's responses to other items on the list are humorous in 
> there vagueness, but in my experience for clojure:
>
> 1.Injection:   Done by JDBC's prepared statements, and clojure.jdbc's use 
> of them
> 2. XSS injection:   Depends on templating.  Hiccup requires explicit `(h 
> ..)` calls.  laser is escape by default.  I am unsure about enlive, 
> clabango, or others.
> 3. Authentication & Session Management:  I've used friend for 
> authentication, and bcrypt for encryption.  lib-noir has some functions 
> that use bcrypt, but I've not used it. Session management can be specified 
> by the :store given to wrap-session, and defaults to a in memory store.  A 
> cookie store also exists that provides some protection against cookie 
> mutation.  Immutant provides a store that can work across a cluster.
> 4. Insecure Reference:  There is not a standard ORM or similar, so 
> handling only the correct parameters is up to you.
> 5. CSRF:  ring-anti-forgery provides a way to add CSRF prevention tokens
> 6. Security Misconfiguration: This seems to be the domain of chef, pallet, 
> puppet, capistrano or another deployment tool.  I'm not sure I want my 
> libraries to mess with deployments.
> 7. Insecure Cryptographic Storage: Use bcrypt. See 3.
> 8. Failure to Restrict URL access: I've used friend for authorization.
> 9. Insufficient Transport Layer Protection: I'd recommend letting your 
> front end server handle this and redirect to https.  I believe lib-noir has 
> a middleware that will redirect from http to https if needed. Consider 
> passing `:secure true` to `wrap-cookies` if you have an https only site.
> 10. Unvalidated Redirects and Forwards: Url generation is a weakspot in a 
> compojure based setup. For comparison, pedestal-service wrote its own 
> routing dsl and stores the routes in a way that allows url generation based 
> on the context passed in.
>
> I believe the use of many small libraries is what causes the lack of a 
> single spot for this documentation. I've picked up most of what I described 
> above by knowing the authors / what to google / asking + watching irc. 
>  That does seem like an unfortunate situation for anyone new to have to 
> learn.
>
> -
> Nelson Morris
>

Thank you to Nelson for compiling this list. Since it was posted a number 
of months ago, has anyone recently written or stumbled over a go-to site 
for security in Clojure web/non-web apps? The clojure-sec group seems to be 
dead, but let me know if we should take the thread over there.

-
Christopher Poile

-- 
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: Adatx - Test driven development... literally.

[Ludwik Grodzki]

... and here's an example of how it works:

(def workings
 (adatx/prob-solve
  {
  :symvec['+ '- '* '/ 'x1 'x2]
  :prog-holder   '(fn [x1 x2] :adatx.prog-hold/prog)
  :in-out-pairs  [{:in [1 2] :out 4}
  {:in [1 3] :out 5}
  {:in [2 3] :out 7}
  {:in [4 3] :out 11}]
  :sandbox :none}))
(adatx/get-solution workings); => (fn [x1 x2] (+ x1 x1 x2))





On Saturday, 8 March 2014 21:30:56 UTC, Ludwik Grodzki wrote:
>
> Hello Clojure Group.
>
> I've put together a little library that writes clojure code for you... 
> given test input/output examples and a heuristic of relevant functions.
>
> https://github.com/LudoTheHUN/adatx
>
> Feedback + contributions very welcome.
>
> Regards.
>
> Ludwik.
>
>

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

[soft/philosophical] event handers in cljs

[t x]

Hi,

  Before core.async, the way I did event handling in cljs was:


## approach 1
  goog.events.listen(... , callback-func)

  After learning core.async, I read (and liked the idea of):

## approach 2
  * (defn global-events (core.async/chan 1))
  * shove all events on to global-events
  * have a go-thread 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: 1.6.0-beta2 / sumatra / graal / okra / hsa / gpgpu

[Jules]

Well - not sure about interest levels :-) but I am soldiering on.

I've tidied up and checked in the code I mentioned and some more stuff that 
I am playing with.

If you are running Fedora 20 x86_64 then you are only a few lines of 
cut-n-paste away from being able to build yourself a working graal-enabled 
jdk8.

Here is the project - Clumatra !

https://github.com/JulesGosnell/clumatra

please get in touch if you're interested.


Jules

-- 
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] self-build, a self contained build server

[ronen]

self-build is a simple build server currently focused on simplicity and 
easy setup, its main goal is to enable a continues build by just running:

$ lein self-build jobs.edn

Right from within a lein project thus saving us from the need to setup 
Jenkins or other more complex solutions.

Check https://github.com/narkisr/self-build for more info

-- 
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: Working with big datasets, merging two ordered lists by key

[Timothy Washington]

Hmm, the *for* comprehension yields a lazy sequence of results. So the
penalty should only occur when one starts to use / evaluate the result.
Using maps is a good idea. But I think you'll have to use another algorithm
(not *for*) to get the random access you seek.

Frank could try a *clojure.set/intersection* to find common keys between
the lists. then *order* and *map* / *merge* the 2 lists.

Beyond that, I can't see a scenario where some iteration won't have to
search the space for matching keys (which I think
*clojure.set/intersection* does).
A fair point all the same.


Tim Washington
Interruptsoftware.com 


On Sun, Mar 9, 2014 at 12:13 PM, Moritz Ulrich  wrote:

> I think it would be more efficient to read one of the inputs into a
> map for random access instead of iterating it every time.
>
> On Sun, Mar 9, 2014 at 4:48 PM, Timothy Washington 
> wrote:
> > Hey Frank,
> >
> > Try opening up a repl, and running this for comprehension.
> >
> > (def user_textfile [[:id1 {:name 'Frank'}] [:id3 {:name 'Tim'}]])
> > (def user_database [[:id1 {:age 38}] [:id2 {:age 27}] [:id3 {:age 18}]
> [:id4
> > {:age 60}]])
> >
> > (for [i user_textfile
> > j user_database
> > :when (= (first i) (first j))]
> > {(first i) (merge (second i) (second j))})
> >
> > ({:id1 {:age 38, :name Frank'}} {:id3 {:age 18, :name Tim'}})  ;; result
> > from repl
> >
> >
> >
> > Hth
> >
> > Tim Washington
> > Interruptsoftware.com
> >
> >
> > On Sun, Mar 9, 2014 at 5:33 AM, Frank Behrens 
> wrote:
> >>
> >> Hi,
> >>
> >> i'm investigating if clojure can be used to solve the challenges and
> >> problems we have at my day job better than ruby or powershell. A very
> common
> >> use case is validating data from different  systems against some
> criteria. i
> >> believe clojure can be our silver bullet, but before that, it seems to
> be
> >> required to wrap my head around it.
> >>
> >> So I am starting in the first level with the challenge to validate some
> >> data from the user database against our active directory.
> >>
> >> I already have all the parts to make it work: Which is to make a hash by
> >> user_id from the database table, export a textfile from AD, each line
> >> representing a user, parse it, merge the information from the
> >> user_table_hash, and voila.
> >>
> >> I did not finish to implement this. So I don't know if this naive
> approach
> >> will work with 400.000 records in the user database and 100.000 in the
> >> textfile.
> >> But I already think about how I could implement this in a more memory
> >> efficient way.
> >>
> >> So my simple question:
> >>
> >> I have user_textfile (100.000 records) which can be parsed into a
> >> unordered list of user-maps.
> >> I have user_table in the database(400.000 record) which I can query with
> >> order and gives me an ordered list of user-maps.
> >>
> >> So I would first order the user_textfile and then conj the user_table
> >> ordered list into it, while doing the database query.
> >> Is that approach right ? How would I then merge the two ordered lists
> like
> >> in the example below?
> >>
> >> (defn user_textfile
> >>   ([:id1 {:name 'Frank'}]
> >>[:id3 {:name 'Tim'}]))
> >>
> >> (defn user_database
> >>   ([:id1 {:age 38}]
> >>[:id2 {:age 27}]
> >>[:id3 {:age 18}]
> >>[:id4 {:age 60}]))
> >>
> >> (merge-sorted-lists user_database user_textfile)
> >> =>
> >>   ([:id1 {:name 'Frank' :age 38}]
> >>[:id3 {:name 'Tim'   :age 18}]))
> >>
> >> Any feedback is appreciated.
> >> Have a nice day,
> >> Frank
> >>
> >> --
> >> 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

Re: More functional Quil

[Nikita Beloglazov]

Hi Pablo

You can find similar old thread on Quil github repo: 
https://github.com/quil/quil/pull/19 It may serve as good background what 
other people considered to make Quil more "functional-style".

I like your suggestion though I would split your :draw function to 2 fns: 
an :update function, which only purpose is to update state and :draw which 
draws state and doesn't change the world at all. If this approach is 
implemented - other handler functions like :mouse-move, :key-pressed are 
also need to become update-like functions - they should take state as 
argument and return new state.

The only problem is that it is not backward compatible at all. But probably 
we still can do it... We can add option :fun-mode? true (stands for 
functional-mode) which enables all these changes - :draw takes state as 
argument, new :update function is added for modifying state, all handlers 
behave like :update. This option is enabled per-sketch. It requires 
additional work on Quil internals, but I think it is doable. This option 
can be implemented in coming quil 2.0 and it would be great feature to 
have. 

One more thing we could do to make it more functional-like - pass "changed" 
values to handlers directly. Currently when :key-pressed handler is called 
- no argument is passed to the function and you need to use (key-code) or 
(raw-key) functions to identify which key was pressed. I think this 
parameters should be explicitly passed to the function.

What do you think?

Nikita

On Sunday, March 9, 2014 1:21:58 PM UTC, J. Pablo Fernández wrote:
>
>
>
> On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>>
>> Hello, 
>>
>> To be honest I don't see any fundamental difference between your first 
>> attempt and the improvement: both share the fact that the mutation of the 
>> state happens within the draw function. So in both cases, you have a 
>> temporal coupling between updating the state of the app and rendering a new 
>> view of the app's state.
>>
>
> Yes, what's happening in both cases is very similar, but the function draw 
> in the "functional" style, in my opinion, is easier to read and maybe it's 
> also easier to test.
>  
>
>> I would suggest that you don't swap! at all within draw, just deref and 
>> render the result of the dereffing.
>>
>> And, in another thread, at potentially a totally different pace than the 
>> redrawing's pace, update the application's state accordingly to business 
>> rules / constraints.
>>
>> Schematically, something like this: 
>>
>> (def app-state (atom (init-state)))
>>
>> (defn draw [...]
>>   (let [app-snapshot (deref app-state)]
>>   ... call quil primitives to render the application state snapshot 
>> ...))
>>
>> (future
>>   ... logic which updates the app-state atom depending on business rules 
>> / constraints, in a separate thread ...)
>>
>
> I never worked with future, this is exciting, but I have some questions. 
> Do you mean that future is completely separate from draw? I'm just getting 
> started, but draw is not only a function to draw, but as a side effect is 
> the clock of the app, as it's called according to the set frames per second 
> and you normally *take a step* en each draw. Would draw create these 
> futures for the next draw?
>

-- 
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] durable-queue: an in-process disk-backed queue

[Leif]

Hi, Zach.

I was trying to benchmark at different values of the :fysnc-* parameters, 
and I noticed that it didn't matter what value of :fsync-interval I set, 
the performance was constant, and about what it is with both :fsync-put? 
and :fsync-take? disabled.

Any suggestions on how to test if data is actually being synced to disk at 
my specified interval?

Please forgive my suspicious nature,
Leif

On Friday, March 7, 2014 4:21:44 PM UTC-5, Zach Tellman wrote:
>
> I added the above-described features a few weeks back, but only got around 
> to marking 0.1.1 today.  Fsync batching is described at the end of the 
> README, let me know if you have any questions.
>
> On Friday, February 7, 2014 11:52:11 AM UTC-8, Zach Tellman wrote:
>>
>> Hi Bob,
>>
>> Right now the API only allows for single puts, and fsyncing is 
>> all-or-nothing.  However, this is just an artifact of my major use case for 
>> the library, which relies on upstream batching of tasks.  I'm planning an 
>> 0.1.1 release which has an explicit `sync` method, and support for 
>> sync-intervals (i.e. sync twice a second) and sync-thresholds (i.e. sync 
>> every ten puts or takes).  The use case you describe could be achieved by 
>> disabling automatic syncing, and doing a series of puts and takes followed 
>> by a call to `sync`.
>>
>> If you have thoughts or suggestions on how this can be more useful for 
>> you, please let me know.
>>
>> Zach
>>
>>
>> On Fri, Feb 7, 2014 at 5:26 AM, Bob Hutchison wrote:
>>
>>>
>>> On Feb 6, 2014, at 6:45 PM, Zach Tellman  wrote:
>>>
>>> At Factual we get a lot of data thrown at us, and often don't have 
>>> control over the rate at which it comes in.  As such, it's preferable that 
>>> our buffer isn't bounded by the process' memory, since a temporary blip in 
>>> throughput may cause GC pauses, OOM exceptions, and other things that will 
>>> only exacerbate the problem.  It's also preferable that if the process 
>>> dies, we won't lose any data which hasn't yet escaped the process.  A 
>>> disk-backed queue satisfies both of these requirements.
>>>
>>> As such, I'm happy to announce that we're open sourcing 'durable-queue': 
>>> https://github.com/Factual/durable-queue.  It's a small, fast, 
>>> pure-Clojure implementation that in our production systems is responsible 
>>> for processing billions of entries daily.  We believe it has broad 
>>> applications, and are excited to see how others will use it.
>>>
>>>
>>> What excellent timing! I’ve been looking at ZeroMQ, RabbitMQ, and Kafka 
>>> for the last week or so. ZMQ is awfully attractive for what I’m trying to 
>>> do, but there are a few things it doesn’t do that I need done. I had begun 
>>> thinking of building something similar on top of Redis.
>>>
>>> You mention the idea of batching to reduce the impact of fsync. Is there 
>>> an API for batching puts? Is there a way to batch a complete! and put! new 
>>> tasks to the queue?
>>>
>>> One pattern that keeps coming up is:
>>>- take a single task from the queue
>>>- execute the task, which might generate a set of new tasks to be 
>>> queued on the same queue (and likely on other queues too)
>>>- signal completion, and put the new tasks
>>>
>>> Cheers,
>>> Bob
>>>
>>>
>>> Zach
>>>
>>> P.S. If this sort of work is interesting to you, Factual is hiring: 
>>> https://groups.google.com/forum/#!searchin/clojure/factual/clojure/8bPIEnNpfyQ/lvv-9gkVozAJ
>>>
>>> -- 
>>> 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/groups/opt_out.
>>>
>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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 a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/4tZFWdMKvjw/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> clojure+u...@googlegroups.com.
>>> For more options, vis

Re: [soft/philosophical] event handers in cljs

[Sam Ritchie]

Well, I typically have multiple channels. No need to have a single 
global event bus for everything. With multiple channels, you can have a 
bunch of local event loops.



t x 
March 9, 2014 1:43 PM
Hi,

Before core.async, the way I did event handling in cljs was:


## approach 1
goog.events.listen(... , callback-func)

After learning core.async, I read (and liked the idea of):

## approach 2
* (defn global-events (core.async/chan 1))
* shove all events on to global-events
* have a go-thread 

--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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: More functional Quil

[Lee Spector]

FWIW I'm not crazy about these suggestions because they seem to me to be mostly 
cosmetic, and actually negative if they end up leading to multiple incompatible 
modes of operation. The Processing model seems to me to be intrinsically 
imperative, and it's also well-known by lots of people and easy to understand. 
The current Quil scheme, which provides fairly direct access to Processing's 
existing model from Clojure, still allows us to write functional-style code for 
all of the interesting stuff that we do within/between calls to the imperative 
Processing calls. And it allows one to translate Processing ideas into Quil 
relatively easily. So I like it like it is :-).

 -Lee

On Mar 9, 2014, at 8:29 PM, Nikita Beloglazov wrote:

> Hi Pablo
> 
> You can find similar old thread on Quil github repo: 
> https://github.com/quil/quil/pull/19 It may serve as good background what 
> other people considered to make Quil more "functional-style".
> 
> I like your suggestion though I would split your :draw function to 2 fns: an 
> :update function, which only purpose is to update state and :draw which draws 
> state and doesn't change the world at all. If this approach is implemented - 
> other handler functions like :mouse-move, :key-pressed are also need to 
> become update-like functions - they should take state as argument and return 
> new state.
> 
> The only problem is that it is not backward compatible at all. But probably 
> we still can do it... We can add option :fun-mode? true (stands for 
> functional-mode) which enables all these changes - :draw takes state as 
> argument, new :update function is added for modifying state, all handlers 
> behave like :update. This option is enabled per-sketch. It requires 
> additional work on Quil internals, but I think it is doable. This option can 
> be implemented in coming quil 2.0 and it would be great feature to have. 
> 
> One more thing we could do to make it more functional-like - pass "changed" 
> values to handlers directly. Currently when :key-pressed handler is called - 
> no argument is passed to the function and you need to use (key-code) or 
> (raw-key) functions to identify which key was pressed. I think this 
> parameters should be explicitly passed to the function.
> 
> What do you think?
> 
> Nikita

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

Request for Mentors for GSoC Projects

[zcaudate]

I'm happy to mentor the Typed Clojure Beginner Tutorial, Annotations & Error 
Messages and/or the typed Clojurescript Annotations

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

Request for Mentors for GSoC Projects

[zcaudate]

I'm happy to mentor the Typed Clojure Beginner Tutorial, Annotations & Error 
Messages and/or the typed Clojurescript Annotations

-- 
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] Stasis - not another static site framework

[Jarrod Swart]

Awesome, thanks for bringing these great libraries to my attention!

-- 
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: More functional Quil

[Gary Trakhman]

FWIW, I've got an example of a decoupled update/draw loop here:
https://github.com/gtrak/quilltest/blob/master/src/quilltest/balls.clj


On Sun, Mar 9, 2014 at 10:16 PM, Lee Spector  wrote:

>
> FWIW I'm not crazy about these suggestions because they seem to me to be
> mostly cosmetic, and actually negative if they end up leading to multiple
> incompatible modes of operation. The Processing model seems to me to be
> intrinsically imperative, and it's also well-known by lots of people and
> easy to understand. The current Quil scheme, which provides fairly direct
> access to Processing's existing model from Clojure, still allows us to
> write functional-style code for all of the interesting stuff that we do
> within/between calls to the imperative Processing calls. And it allows one
> to translate Processing ideas into Quil relatively easily. So I like it
> like it is :-).
>
>  -Lee
>
> On Mar 9, 2014, at 8:29 PM, Nikita Beloglazov wrote:
>
> > Hi Pablo
> >
> > You can find similar old thread on Quil github repo:
> https://github.com/quil/quil/pull/19 It may serve as good background what
> other people considered to make Quil more "functional-style".
> >
> > I like your suggestion though I would split your :draw function to 2
> fns: an :update function, which only purpose is to update state and :draw
> which draws state and doesn't change the world at all. If this approach is
> implemented - other handler functions like :mouse-move, :key-pressed are
> also need to become update-like functions - they should take state as
> argument and return new state.
> >
> > The only problem is that it is not backward compatible at all. But
> probably we still can do it... We can add option :fun-mode? true (stands
> for functional-mode) which enables all these changes - :draw takes state as
> argument, new :update function is added for modifying state, all handlers
> behave like :update. This option is enabled per-sketch. It requires
> additional work on Quil internals, but I think it is doable. This option
> can be implemented in coming quil 2.0 and it would be great feature to have.
> >
> > One more thing we could do to make it more functional-like - pass
> "changed" values to handlers directly. Currently when :key-pressed handler
> is called - no argument is passed to the function and you need to use
> (key-code) or (raw-key) functions to identify which key was pressed. I
> think this parameters should be explicitly passed to the function.
> >
> > What do you think?
> >
> > Nikita
>
> --
> 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.

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Clojure Programmer/Data Scientist at Weft

http://functionaljobs.com/jobs/8692-clojure-programmer-data-scientist-at-weft



Senior Clojure Developer at Sonic Boom Wellness

http://functionaljobs.com/jobs/8691-senior-clojure-developer-at-sonic-boom-wellness



Cheers,

Sean Murphy

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