Re: [ANN] Stasis - not another static site framework
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
ofhttps://github.com/magnars/stasis#are-there-any-full-fledged-examples-to-look-atuse
Optimus https://github.com/magnars/optimus for its frontend optimization.
It has a LESS asset loader https://github.com/magnars/optimus-less, but
no one has made one for Jade. I would guess you could use
Twixthttps://github.com/AvisoNovate/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.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#another-static-site-framework-whyAnother
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 https://github.com/liquidz/misaki is a Jekyll inspired
static site generator in Clojure.
- Madness http://algernon.github.io/madness/ is a static site
generator, based on Enlive and Bootstrap.
- Static http://nakkaya.com/static.html is a simple static site
generator written in Clojure.
- Ecstatic http://samrat.me/ecstatic/ creates static web pages and
blog posts from Hiccup templates and Markdown.
- incise https://github.com/RyanMcG/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.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#usageUsage
The core of Stasis is two functions: serve-pages and export-pages. Both
take a map from path to contents:
(def pages {/index.html h1Welcome!/h1})
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.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#serving-live-pages-locallyServing
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 project.clj:
:ring {:handler example/app}
and start it with lein ring server-headless.
https://gist.github.com/magnars/32dbca91bdb0987ea4ba#exporting-the-pagesExporting
the pages
To export, just give Stasis some pages and a target directory:
(defn export
Om-powered HTML slide-decks
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
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
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
Hello Clojurians,
I'm starting to play with Processing and I want to use my favorite
programming language for it, so I started using
Quilhttps://github.com/quil/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
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
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 pup...@pupeno.com:
Hello Clojurians,
I'm starting to play with Processing and I want to use my favorite
programming language for it, so I started using
Quilhttps://github.com/quil/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 options, visit https://groups.google.com/d/optout.
Re: More functional Quil
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
2014-03-09 14:21 GMT+01:00 J. Pablo Fernández pup...@pupeno.com: 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 ?
(doubles (into-array [1.2 2.2])) #ClassCastException java.lang.ClassCastException: [Ljava.lang.Double; 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.
Re: How to use function doubles ?
(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 soro...@oogis.ru wrote: (doubles (into-array [1.2 2.2])) #ClassCastException java.lang.ClassCastException: [Ljava.lang.Double; 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
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 ayq...@gmail.com 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
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
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
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 http://interruptsoftware.com
On Sun, Mar 9, 2014 at 5:33 AM, Frank Behrens fbehr...@gmail.com 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
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 twash...@gmail.com 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 fbehr...@gmail.com 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
An awesome slide. On Sun, Mar 9, 2014 at 11:15 PM, Base basselh...@gmail.com 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
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
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
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.
... 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
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 ! from global-events and process there ### Question I'm now shifting back to liking approach 1 a bit more. The reason being: at the point where I define the GUI element, I also define it's behavior. Approach 2 has this weird coupling, where it's like: I'm going to define my GUI elements at location X. Then, at location Y, which centralizes event processing, I'm going to define how each event is handled. What are people's takes on this? Am I doing approach 2 incorrectly, or does approach 1 actually has it's merits? 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: 1.6.0-beta2 / sumatra / graal / okra / hsa / gpgpu
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
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
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 http://interruptsoftware.com
On Sun, Mar 9, 2014 at 12:13 PM, Moritz Ulrich mor...@tarn-vedra.de 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 twash...@gmail.com
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 fbehr...@gmail.com
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
Re: More functional Quil
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
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 hutch...@recursive.cawrote: On Feb 6, 2014, at 6:45 PM, Zach Tellman za...@factual.com 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, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated -
Re: [soft/philosophical] event handers in cljs
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 mailto:txrev...@gmail.com 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 ! from global-events and process there ### Question I'm now shifting back to liking approach 1 a bit more. The reason being: at the point where I define the GUI element, I also define it's behavior. Approach 2 has this weird coupling, where it's like: I'm going to define my GUI elements at location X. Then, at location Y, which centralizes event processing, I'm going to define how each event is handled. What are people's takes on this? Am I doing approach 2 incorrectly, or does approach 1 actually has it's merits? Thanks! -- Sam Ritchie (@sritchie) Paddleguru Co-Founder 703.863.8561 www.paddleguru.com http://www.paddleguru.com/ Twitter http://twitter.com/paddleguru// Facebook http://facebook.com/paddleguru -- 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. inline: compose-unknown-contact.jpg
Re: More functional Quil
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
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
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
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
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 lspec...@hampshire.edu 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.
