Re: What to use use for writing GUI's

[Cecil Westerhof]

2014-05-04 15:50 GMT+02:00 Timothy Baldridge :

> I highly recommend taking a look again at JavaFX2. The latest version
> (released as part of Java 8 or as a separate jar with Java 7) has a very
> unified API and is a joy to work with.
>
> I've been hacking on a library that provides a data centric API to
> JavaFX2. The cool thing is that most of it is self writing. Since the API
> is so consistent, reflection can be used to discover how most of the
> components work. Here's an example of what the UI description layer looks
> like.
>
>
> https://github.com/halgari/com.tbaldridge.slide/blob/master/src/com/tbaldridge/slide.clj#L266
>
> This library uses core.async to bind components to data. So the binding
> :text<- (bindings/get-in a [:text]) will bind a control's text to whatever
> is in the atom a at the path [:text]. Likewise the :text->
> (bindings/assoc-in a [:text]) will keep the atom up to date with the
> contents of a text box.
>
> I haven't tested this on any platform but Mac, but I've seen tutorials of
> JavaFX2 running on Linux and Windows, so I assume it's all fully cross
> platform.
>

​As I understood it, you have to include the JavaFX jar yourself with it.

At the moment I think I stay with seesaw. Looks very easy to use. When I am
‘proficient’ with making front-ends  could re-evaluate.



> On Sun, May 4, 2014 at 4:44 AM, Daniel Kersten  wrote:
>
>> I'm a massive fan of Qt and have done a lot of Qt/QML in C++ in the past,
>> but lately when I've needed to do a GUI (and could use Clojure), I've been
>> making it Web based and using ClojureScript with Om. Since jetty/http-kit
>> run nicely as embedded servers, you could have your application run locally
>> and launch a browser (rather than running it on a server) if you wanted,
>> and if you have the ClojureScript talk to the Clojure "server" through
>> sente, you _almost_ won't even notice its not all plain Clojure since
>> communication looks more or less like a core.async channel.
>>
>> Might be a bit much to learn if you're new to Clojure, though.
>>
>> I haven't used swing or Qt in Clojure, so can't comment on them.
>>
>>
>> On 4 May 2014 10:44, Cecil Westerhof  wrote:
>>
>>> 2014-05-04 10:20 GMT+02:00 Cecil Westerhof :
>>>
>>>


 2014-05-04 10:09 GMT+02:00 Colin Fleming :

 There's really no "only" way to do anything in Clojure, since you can
> always drop down to Java interop. So anything that's available to Java is
> available to Clojure, too. Not all the options have a nice Seesaw-like
> wrapper over it of course, but they're generally still quite usable. I do 
> a
> reasonable amount of Swing work without Seesaw, mostly because it takes a
> while to start up, but Seesaw has a lovely API if that's not such an issue
> for you. Swing is generally a fine option, if you look at IntelliJ you'll
> see it's possible to make it quite pretty and functional, although it's a
> lot of work to get to that stage.
>
> Other options are QTJambi or SWT - I don't know anything about Pivot
> and the demos didn't work for me either in Firefox or Safari but it looks
> like that might be an option too. JavaFX may also be an option, although I
> don't know much about it. Or you can go for more esoteric options like
> embedding Chromium in a native app wrapper and use ClojureScript, which is
> what LightTable and other projects do.
>
> It really depends on your requirements, but the above are all viable
> options.
>

 ​Well, I am a newbie with GUI, so best to start with seesaw if there is
 no real reason not to use Swing I think then. (I do not remember why Swing
 was discouraged.) I have to look into the start-up time. I did not know
 about that.

 By the way: as I understood it JavaFX is only an option if you only
 develop for Windows.

>>>
>>>  ​I see that there is also clj-swing. What would are the advantages of
>>> either compared to the other?
>>>
>>
-- 
Cecil Westerhof

-- 
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: What to use use for writing GUI's

[Cecil Westerhof]

2014-05-04 17:32 GMT+02:00 Gary Verhaegen :

> I'm no expert, but the arguments I have seen against Swing are
> almost always about the API, so they do not really apply to seesaw.
>
> The other arguments were about the non-native look, but I seem to remember
> that seesaw took care of that too.
>

​Well for the moment I stick to seesaw then. I tried hello-seesaw and that
works really well. It went first wrong, but that was a stupid mistake of me
in the project file.
 ​


> Well, I am a newbie with GUI, so best to start with seesaw if there is no
> real reason not to use Swing I think then. (I do not remember why Swing was
> discouraged.) I have to look into the start-up time. I did not know about
> that.
>

-- 
Cecil Westerhof

-- 
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: What to use use for writing GUI's

[Fabien Todescato]

>From Java 7 onwards, JavaFX is part of the runtime. I strongly recommend you 
>take a look at JavaFX, the very regular and powerful API will allow you to 
>build innovative UIs.

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-04 17:40 GMT+02:00 Evan Rowley :

> Most functional languages have design features that enhance their
> security. I'm referring to Clojure, Haskell, and Erlang, but this won't be
> limited to those three. As someone who was hired to handle cyber security
> needs of a contracting IT company, my personal and professional opinion is
> this: I would trust someone who programs in a functional language to create
> _and_ maintain software that is relatively more secure.


​Have you any pointers about this?

​


> But you know what? While Microsoft and Adobe were focusing on making their
> products easier to use for their next target market, the Clojure devs were
> busy designing a language that is error-
>

​Often easy of use is contrary to safety. I do not say that they cannot be
combined, but making a program saver can make it harder to use and making a
program easier to use can make it less save.

​


> were building lame FTP clients into their development tools, the Lein devs
> were doing better by integrating Maven's build and dependency management
> into a dead-simple deployment tool that
>

​I was very pleasantly surprised how lein worked. :-D

​


> works well with all kinds of online code repositories. Code repositories
> which by the way, nether Adobe or Microsoft had (at the time) encouraged
> the use of. Even though much of Clojure is still terminal based (i.e., REPL
> ), at least there aren't multiple levels of undocumented and proprietary
> abstraction. With Clojure, you can get as abstract or as low level as you
> want (OpenJDK,
>

​Well, I find the REPL a big plus.

​


> By now I might sound critical of other developers, but you have to
> understand that many of these groups get paid A LOT of money to create
> things correctly.
>

​Nothing wrong about being critical. (In reason.)
​


> On 4 May 2014 08:24, Cecil Westerhof  wrote:
>
>> I heard the stand that functional programming made it difficult to write
>>> secure programs. I do not know enough of functional programming yet to
>>> determine the value of a statement like this. What is the take here about
>>> it?
>>>
>>
-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-04 21:59 GMT+02:00 Adam Saleh :

> Well, what does it mean to write secure programs? Citation needed :)
>

​Well, the statement was that for secure programming you needed to program
modular. It was hinted that when you program functional you can not program
modular. I would not know why, but as I said: I am new to functional
programming. And I did not have to write very secure programming neither.
Never had to write financial or medical software.

I was thinking it was FUD, but better save as sorry. When there are thinks
to look out for, it would be god to know them.



> So ... it deppends :D
>

​That is always the case of-course, but it was suggested that functional
programming made it inherently difficult.​

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-04 23:40 GMT+02:00 Magnus Therning :

> On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote:
> > I heard the stand that functional programming made it difficult to
> > write secure programs. I do not know enough of functional
> > programming yet to determine the value of a statement like this.
> > What is the take here about it?
>
> It would be interesting to hear WHY functional programming would yield
> less secure programs.  What would then be the paradigm that results in
> most security?  Imperative, logical?
>

​Modular, the suggestion being that that could not be done in a functional
language.

​


> It's widely acknowledged that writing secure programs is difficult.
>

​Agreed, and often an afterthought, which makes it even more difficult. :'(

​


> state that is easy to argue about.  That means we want immutability as
> deeply rooted in the language as possible.
>

​It is something to get used too, but I found it a lot less difficult as I
imagined. And with learning the language better, it will become easier I
expect.

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-05 5:48 GMT+02:00 Wei Hsu :

> Perhaps Cecil is referring to this article, Clojure web security is worse
> than you 
> think,
>  describing
> the immature state of Clojure's web security libraries. I
>

​No, it was suggested that for secure programming you needed to do it
modular and that this was not possible with a functional language.

But off-course this is important also.

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-05 8:21 GMT+02:00 Magnus Therning :

> any language" ;)  However, choosing language wisely will allow you to
> concentrate on solving the 'real' problem at hand, and relieve you
> from solving unrelated problems (memory management, dealing with
> pointers, etc).  It will also simplify reasoning about your code.  I
>

​That is why I do not understand that (where I live) they think you can
only be a good programmer if you only program in one language.

They should listen to Bjarne Stroustrup:
We do not consider it possible to be a professional in the realm of
software,
even if you are not primarily a programmer,
without knowing more than one language.

Or Herbert Mayer:
No programming language is perfect.
There is not even a single best language;
there are only languages well suited or perhaps poorly suited for
particular purposes.

-- 
Cecil Westerhof

-- 
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: What to use use for writing GUI's

[Cecil Westerhof]

2014-05-05 9:56 GMT+02:00 Fabien Todescato :

> From Java 7 onwards, JavaFX is part of the runtime. I strongly recommend
> you take a look at JavaFX, the very regular and powerful API will allow you
> to build innovative UIs.
>

​I see you are right. Two problems:
- Can I expect everyone that is going to use my application to have at
least Java 7?
- ​

​
http://docs.oracle.com/javafx/2/installation_2-2/javafx-installation-linux.htmstates:
​Web Start applications and Web applications (plugin) features are
currently not supported on the Linux platform.

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Magnus Therning]

On Mon, May 5, 2014 at 10:09 AM, Cecil Westerhof  wrote:
> 2014-05-04 23:40 GMT+02:00 Magnus Therning :
>
>> On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote:
>> > I heard the stand that functional programming made it difficult to
>> > write secure programs. I do not know enough of functional
>> > programming yet to determine the value of a statement like this.
>> > What is the take here about it?
>>
>> It would be interesting to hear WHY functional programming would yield
>> less secure programs.  What would then be the paradigm that results in
>> most security?  Imperative, logical?
>
>
> Modular, the suggestion being that that could not be done in a functional
> language.

That is indeed an interesting statement.  I would LOVE to hear why use
of functional languages would prevent modularity.  Especially since so
many VERY knowledgeable people claim that functional programming
yields more composable software.  I'm having a hard time reconciling
that something can be composable but not modular.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

-- 
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: Tools.nrepl middleware-dependency sorting issues

[Jony Hudson]

I'm not sure it's relevant, but one thing that caught me out is that the 
"interruptible-eval" middleware has a hard dependency on the "pr-values" 
middleware (i.e. it depends 
on #'clojure.tools.nrepl.middleware.pr-values/pr-values). I found this 
caused trouble when I was trying to insert my own pr'ing middleware.


Jony

-- 
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: Core.logic appendo for string?

[Tassilo Horn]

David Nolen  writes:

> There's no easy way to do this beyond making your own relational
> string type as you've suggested.

FWIW, I had the same need as Adam and the poor-man's solution below is
enough for my use-case.

--8<---cut here---start->8---
(defn ground?
  "Returns true, if `x` is ground.
  `x` must have been `walk`ed before!"
  [x]
  (not (ccl/lvar? x)))

(defn ^:private str-splits [s]
  (loop [idx 0, r []]
(if (<= idx (count s))
  (recur (inc idx)
 (conj r [(subs s 0 idx) (subs s idx)]))
  r)))

(defn stro
  ([x y xy]
 (fn [a]
   (let [wx  (cclp/walk a x)
 wy  (cclp/walk a y)
 wxy (cclp/walk a xy)]
 (cond
  (and (ground? wx) (ground? wy) (ground? wxy))
  (if (= (str wx wy) wxy) (ccl/succeed a) (ccl/fail a))

  (and (ground? wx) (ground? wy))
  (or (ccl/unify a xy (str wx wy))
  (ccl/fail a))

  (and (ground? wx) (ground? wxy) (string? wxy)
   (.startsWith ^String wxy wx))
  (or (ccl/unify a y (subs wxy (count wx)))
  (ccl/fail a))

  (and (ground? wy) (ground? wxy) (string? wxy)
   (.endsWith ^String wxy wy))
  (or (ccl/unify a x (subs wxy 0 (- (count wxy) (count wy
  (ccl/fail a))

  (ground? wxy)
  (ccl/to-stream
   (->> (map (fn [[s1 s2]]
   (ccl/unify a [x y] [s1 s2]))
 (str-splits wxy))
(remove not)))

  ;; TODO: we should not fail here...
  :else (ccl/fail a)
  ([x y z xyz]
 (ccl/fresh [front]
   (ccl/conde
;; This one works if x and y are ground
[(stro x y front)
 (stro front z xyz)]
;; This one works if xyz is ground
[(stro front z xyz)
 (stro x y front)]
--8<---cut here---end--->8---

Of course it's not fully relational, but it's enough when you just need
to concatenate strings, or inversely, split strings at a certain
separator, e.g., full name <=> first name, last name.

Bye,
Tassilo

-- 
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: NoClassDefFoundError when AOT compiling namespace using protocol

[Colin Fleming]

So it turns out this is an ordering problem. I worked around it by first
compiling the namespace containing the protocol, and then the namespace
using it. I guess there's a bug in the transitive compilation.

Cheers,
Colin


On 3 May 2014 21:52, Colin Fleming  wrote:

> Hi all,
>
> I'm having a strange problem when AOT compiling some code I just added. I
> have a namespace that, amongst other things, returns qualified names of
> things:
>
> (ns plugin.names
>   ...)
>
> (defprotocol QualifiedNamed
>   (qualified-name ^String [this]))
>
> (extend-protocol QualifiedNamed
>   nil
>   (qualified-name [this] nil)
>   PsiClass
>   (qualified-name [this] (.getQualifiedName this))
>   ... etc etc ...
>   Object
>   (qualified-name [this] nil))
>
> Now, when I require this namespace and try to use it, I get a failure
> during AOT compilation via Ant of the using namespace:
>
> java.lang.NoClassDefFoundError: plugin/names/QualifiedNamed
> at plugin.lookup__init.load(Unknown Source)
> at plugin.lookup__init.(Unknown Source)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> Caused by: java.lang.ClassNotFoundException: plugin.names.QualifiedNamed
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>
> However when I compile this same code within Cursive, it works, even from
> a clean build. I assumed this was some kind of ordering issue of the
> compiled namespaces, but shouldn't transitive compilation take care of that?
>
> Cheers,
> Colin
>

-- 
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: devops-ish questions regarding Clojure webapp server-side REPL usage

[Deyan Yotsov]

Many thanks to both of you, your answers were very helpful!

Regards,
Deyan

On 05/04/2014 11:28 PM, Akos Gyimesi wrote:

Hi Deyan,
I also think that it's usually better to have a standalone Clojure app 
with a built-in HTTP server, and possibly with a reverse proxy as a 
frontend. You will have much more control this way, and Tomcat will 
not surprise you with wiping your hotfixes.
About thread handling: it's important to note that Clojure starts some 
threads, too. For example, agents run on a dedicated thread pool. So 
if you use an external web server, it will only control a few of the 
threads in your application.
About app startup: you can start the nREPL and the webserver in 
parallel (as James suggested), or you can go on a different route: 
start only a webserver, and integrate Drawbridge 
 (a HTTP transport layer for 
nREPL) into the web app. We use this approach in prod, and it has a 
few advantages:
1. We can have a web-based console on the admin page, which is often 
useful (we can debug from any device that has a browser)
2. Drawbridge is implemented as a Ring handler, so it is easy to 
extend it with additional features like user authentication, logging, etc.
3. We generate the full app code+docs with Marginalia, and bundle it 
with the web-based REPL. This way we can easily look up the code that 
was released to the server, which is usually easier than finding the 
commit that runs on the server, and checking it out into our favorite 
editor.

Regards,
Akos
On Sun, May 4, 2014, at 03:47 AM, Deyan Yotsov wrote:
> Hello!
>
> I am working on a small Clojure web application, and while still in the
> early stages of development, I have been thinking, among other things,
> about a deployment plan.
>
> The production environment for the webapp will be a CentOS server (not
> virtual), the webapp will be sitting behind an Apache gateway on the
> same machine, the webapp will be deployed in a single instance (no load
> balancing involved), and there will be no ssl support. These pieces of
> information are probably irrelevant to what will follow, but I thought
> I'd include them just in case, and maybe they can be summarized as: I
> will not be using Heroku or Google app engine or Amazon.
>
> I want to leverage the REPL (not Clojurescript browser REPL, but Clojure
> server-side REPL) on prod for two things:
> a. being able to check the status of the webapp by connecting to the
> REPL and querying things, derefing atoms, etc.
> b. hot-deploying small fixes without restarting the webapp by redefining
> not-^:dynamic vars through the REPL
>
> I am very excited about a. and b., but also somewhat unsure about what
> the implications of using them are.
>
> 1. Some web servers, including Tomcat, have the functionality to unload
> a webapp if it is getting no requests for a while, and reload it when a
> request comes in. If I want to use such a web server, I need to make
> sure this functionality is switched off, or otherwise it will interfere
> with b., as live var redefinitions will be lost upon webapp reload,
> correct?
>
> 2. I suppose that the REPL is running in a separate thread. I feel
> uncomfortable with having this thread started by the webapp, especially
> having in mind that it is a long-running thread. The web server is
> already managing a thread pool for handling incoming requests. Ideally,
> this thread pool should also be the one responsible for starting the
> REPL thread. Is there a web server that offers this functionality more
> or less out of the box?
>
> 3. When developing a webapp, it is common to first start a REPL, and
> then, from inside this REPL, start a web server. Would doing the same
> thing for production deployment solve my concern 2.? I guess it should,
> because then the REPL will be the "main" thread, and not some
> long-running thread started by the webapp without the knowledge of the
> web server's thread pool manager. Also, while this way of deploying
> webapps is very different from how it is typically done in the Java
> world, I find it beneficial, as one would typically want to do a bit of
> a. immediately after startup, and have a more transparent startup
> overall. Or are there any indications that this way of starting up is
> not appropriate for prod?
>
> Thank you!
> Deyan
>
> --
> 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.

Re: Achieving structural sharing when composing data

[Alex Miller]

To clarify slightly, the Java Language Specification section 5.1.7 requires 
that the implementation cache *boxed* ints from -128 to 127, boolean 
true/false, and characters from \u and \u007f. Because Clojure defaults 
to boxing in many cases you'll see the same effect.

The persistent collections do go through factories and already cache one 
special case: empty list/vector/set/map. This is also where the choice is 
made as to the type of persistent map (array or hash impl) based on size 
(https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L1457).
 

I think in general, there is not enough commonality across programs for the 
cost of the check to be more costly than the benefits to be saved in memory 
so this is not something Clojure would ever do generically. But, if this is 
tradeoff is important to you, then creating your own factory function for 
collections and memoizing it would be a good way to achieve that. 


On Sunday, May 4, 2014 10:21:28 PM UTC-5, Leif wrote:
>
>
> The general technique in lisp is called hash consing (a.k.a. flyweight 
> pattern, a.k.a. interning).  Java strings, clojure symbols, and keywords 
> are interned.  And small integers, apparently.
>
> The basic idea is to create memoized versions of all the data constructors 
> and only use them.  This is basically what you did in your example and what 
> Gary suggested.  So, if you truly wanted something general, you'd probably 
> have to reimplement a lot of clojure.core, or restrict yourself to a small 
> number of constructor fns.  
>
> If the vectors in your example are the only composite structure that needs 
> sharing, and they represent points, say:
>
> (def mk-point (memoize (fn [x y] [x y]))) ; obviously lots of options here 
> (caching strategy, weak refs)
>
> (def m1 {:a (mk-point 1 2)})
>
> (def m2 (assoc m1 :b (mk-point 1 2)))
>
> (identical? (m2 :a) (m2 :b)) ; => true
>
> If the maps themselves need to be shared, you'll have to make your own 
> version of assoc, dissoc, maybe conj & into, etc etc, and remember to 
> always use them.  It could get complicated.
>
> --Leif
>
> On Saturday, May 3, 2014 10:27:29 PM UTC-4, Mike Fikes wrote:
>>
>> Are there common techniques or idioms for achieving structural sharing 
>> when composing data where equivalences exist?
>>
>> (My motivation is to reduce heap usage for a particular problem I'm 
>> working on that involves a lot of repeated data.)
>>
>> As a specific example, consider sharing equivalent map values:
>>
>> (def m1 {:a [1 2]})
>>
>> (def m2 (assoc m1 :b [1 2]))
>>
>>
>> (identical? (m2 :a) (m2 :b))
>>
>> ;; => false
>>
>>
>> For this simple example, I can force sharing by introducing a variant of 
>> assoc which looks at existing values:
>>
>>
>> (defn assoc-id [map key val] (assoc map key (get (apply hash-set (vals 
>> map)) val val)))
>>
>>
>> And using it results in a map with two identical values:
>>
>>
>> (def m3 (assoc-id m1 :b [1 2]))
>>
>>
>> (identical? (m3 :a) (m3 :b))
>>
>> ;; => true
>>
>>
>> But, of course, this approach could get to be expensive and/or unwieldy 
>> if not done carefully.
>>
>>
>> So, I was wondering if there are general techniques in this area. I'm 
>> sure I'm not the first to come across it. We already get this 
>> automatically for boxing of small integers:
>>
>>
>> (identical? 5 5)
>>
>> ;; => true
>>
>>
>> (identical? 500 500)
>>
>> ;; => false
>>
>>
>> So I suppose I'm essentially looking for the same idea but for larger 
>> non-primitive "values".
>>
>>
>>
>>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Mars0i]

(There are now three recent threads on documentation in the Clojure Google 
group*.  *The other threads are "Code Genres" and "Deep Thinking".  It was 
actually *da...@axiom-developer.org's May* 4 post in "Deep Thinking" that 
stimulated these remarks; I posted in this thread only because 
it has "documentation" in the title, so the intent is clearer, but if 
you're new to these discussions, you should read the other threads as well.)

A thought crystallized out of my slight discomfort with some of the remarks 
on documentation in this group lately.  I kept thinking "I have written 
good documentation in the past (sometimes), when other programmers with 
whom I worked didn't.  And we didn't have any special tools.  Just text 
editors.   Why do I need special tools for documentation?"  (Of course I do 
think special tools for documentation can be a good thing. sometimes, but I 
kept having this thought all the same.)

We're programmers, so it's natural to try to problems by programming.  In 
trying to improve documentation this could involve programming in the usual 
sense (writing code), or programming the programmers (creating informal or 
more formal standards for documentation).

I used to work as a professional programmer, but now I'm a professor in a 
humanities discipline.  (I do Clojure programming as part of some of my 
research projects.)  I think a lot about writing clearly and about 
teaching.  For both, there are are methods, guidelines, rules of thumb, 
things to try out, etc., but the most important thing is to try to think 
through what your intended audience needs in order to understand.  And in 
the end, there are no fixed rules.  Just figure out what your readers or 
students need, however you do it.

That's exactly what good documentation involves: Figuring out what other 
programmers will need when they read your code.  (And figuring out how to 
communicate that.)

I think that some of the ideas that people have been proposing in these 
threads are good.  There are some things that it's good to do routinely, 
even if you aren't thinking much about the intended audience.  And the 
right tools and conventions can help convey information more clearly.  
Obviously, a lot of the discussion here is already focused on thinking 
about needs readers of code, so in a sense I'm not saying anything new.

Still, thinking about programmers I've worked with in the past, a part of 
me wonders whether part of what's needed is not programming (with code or 
rules), but also a focus on cultivation of a set of skills that are not 
*programming* skills per se.  Good tools or rules will only get us so far.

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

Re: why is this failing on a list

[Erlis Vidal]

Hi Roelof,

I start the 4Clojure exercises and I did a little project so I can keep a
record of my solutions. It's really simple but also I've found it really
helpful to see where my errors are.

You can fork it from here... if you want.

https://github.com/erlis/4Clojure

You only have there the first 5 or 6 ones, the only thing you have to do is
continue adding exercises and your answers. This will help you also to
become familiar with your dev environment. I'm using Emacs but you can use
whatever you want.

Regards,
Erlis


On Sun, May 4, 2014 at 11:06 AM, James Reeves  wrote:

> Remember that indexes work from zero. So if you have a collection of 3
> elements:
>
> (nth ["a" "b" "c"] 2)  =>  "c"
> (nth ["a" "b" "c"] 1)  =>  "b"
> (nth ["a" "b" "c"] 0)  =>  "a"
>
> I'd encourage you to open a REPL and try the solution you have to see what
> you get if you get stuck. Often some experimentation will show you what
> you're doing wrong.
>
> - James
>
>
> On 4 May 2014 15:58, Roelof Wobben  wrote:
>
>> oke,
>>
>> Then I think I have to work with a if then :
>>
>> The second test is already a vector but the thirth not
>>
>> (= (__ ["a" "b" "c"]) "b")
>>
>> (= (__ [[1 2] [3 4]]) [1 2])
>>
>> I tried already the nth but I was also failing  on the first. I think
>> because of count because you cannot know how many values you have.
>>
>> (fn secondlast [v]
>>   (nth v (-(count v)1)))
>>
>>
>> Roelof
>>
>> Op zondag 4 mei 2014 16:49:45 UTC+2 schreef Lee:
>>
>>>
>>>
>>> On May 4, 2014, at 10:42 AM, Roelof Wobben  wrote:
>>>
>>> > For 4clojure I have to find the second to last item.
>>> >
>>> > So I did this:
>>> >
>>> > (fn secondlast [v]
>>> >   (get v (-(count v)1)))
>>> >
>>> > Now it's only failing at this test :  (= (__ (list 1 2 3 4 5)) 4)
>>> >
>>> > Can anyone tell me where I did take the wrong way.
>>>
>>>
>>> The "get" function with integer keys works for vectors but not for
>>> lists:
>>>
>>> => (get [7 8 9] 1)
>>> 8
>>> => (get '(7 8 9) 1)
>>> nil
>>>
>>> So one option would be to call "vec" on the list before calling get:
>>>
>>> => (get (vec '(7 8 9)) 1)
>>> 8
>>>
>>> Another option would be to use "nth" instead of "get".
>>>
>>>  -Lee
>>>
>>>  --
>> 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.

test.check :autotest ?

[boz]

Is there an :autotest for test.check with Leiningen?

Something like midje, where you can do: lein midje :autotest

Many thanks,
boz

-- 
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] packthread 0.1.0

[Jason Felice]

I've never seen synthread.  I'll investigate in probably a few days.


On Sat, May 3, 2014 at 9:52 AM, Jozef Wagner  wrote:

> Thanks for releasing this library. How does it compare to the synthread
> library [1] [2] ? Seems like both libraries have the same goal.
>
> Jozef
>
> [1] https://github.com/LonoCloud/synthread
> [2] http://www.infoq.com/presentations/Macros-Monads
>
>  --
> 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: Functional programming and security

[Cecil Westerhof]

2014-05-05 12:05 GMT+02:00 Magnus Therning :

> On Mon, May 5, 2014 at 10:09 AM, Cecil Westerhof 
> wrote:
> > 2014-05-04 23:40 GMT+02:00 Magnus Therning :
> >
> >> On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote:
> >> > I heard the stand that functional programming made it difficult to
> >> > write secure programs. I do not know enough of functional
> >> > programming yet to determine the value of a statement like this.
> >> > What is the take here about it?
> >>
> >> It would be interesting to hear WHY functional programming would yield
> >> less secure programs.  What would then be the paradigm that results in
> >> most security?  Imperative, logical?
> >
> >
> > Modular, the suggestion being that that could not be done in a functional
> > language.
>
> That is indeed an interesting statement.  I would LOVE to hear why use
> of functional languages would prevent modularity.  Especially since so
> many VERY knowledgeable people claim that functional programming
> yields more composable software.  I'm having a hard time reconciling
> that something can be composable but not modular.
>

​Well I was already thinking it was FUD, but thought it good to check. I am
now sure I can ignore the statements.​


-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Gregg Reynolds]

On Mon, May 5, 2014 at 5:05 AM, Magnus Therning  wrote:

> On Mon, May 5, 2014 at 10:09 AM, Cecil Westerhof 
> wrote:
> > 2014-05-04 23:40 GMT+02:00 Magnus Therning :
> >
> >> On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote:
> >> > I heard the stand that functional programming made it difficult to
> >> > write secure programs. I do not know enough of functional
> >> > programming yet to determine the value of a statement like this.
> >> > What is the take here about it?
> >>
> >> It would be interesting to hear WHY functional programming would yield
> >> less secure programs.  What would then be the paradigm that results in
> >> most security?  Imperative, logical?
> >
> >
> > Modular, the suggestion being that that could not be done in a functional
> > language.
>
> That is indeed an interesting statement.  I would LOVE to hear why use
> of functional languages would prevent modularity.  Especially since so
> many VERY knowledgeable people claim that functional programming
> yields more composable software.  I'm having a hard time reconciling
> that something can be composable but not modular.
>

Indeed.  Functionism seems to go hand-in-hand with abstract data types,
which is good for modularity.  My recollection is that the module
systemis one
of major selling points of Standard ML, for example.

In general functional languages seem to represent a large step on the way
to the convergence of programs and proofs (see e.g.
Idris for
an example further down that road) so I would expect better security
characteristics from functional programs as compare to stuff written in
imperative, OO etc. languages.

-Gregg

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

Re: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Mon, May 5, 2014 at 9:32 AM, Mars0i  wrote:
...

> the end, there are no fixed rules.  Just figure out what your readers or
> students need, however you do it.
>
> That's exactly what good documentation involves: Figuring out what other
> programmers will need when they read your code.  (And figuring out how to
> communicate that.)
>
> I think that some of the ideas that people have been proposing in these
> threads are good.  There are some things that it's good to do routinely,
> even if you aren't thinking much about the intended audience.  And the
> right tools and conventions can help convey information more clearly.
> Obviously, a lot of the discussion here is already focused on thinking
> about needs readers of code, so in a sense I'm not saying anything new.
>
> Still, thinking about programmers I've worked with in the past, a part of
> me wonders whether part of what's needed is not programming (with code or
> rules), but also a focus on cultivation of a set of skills that are not
> *programming* skills per se.  Good tools or rules will only get us so far.
>

That sounds about right to me; communication (writing) skills, mainly.  Of
course, my degree is in the humanities, so I would say that.  Now I think
of computation as a new addition to the classic liberal arts.

I'm beginning to think that the Clojure documentation system may be
optimal.  Not "best possible", just optimal: does what it does (meets
programmer needs) just well enough to survive.  If it were genuinely
failing us in some important way, it would be changed.

-Gregg

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

Re: Functional programming and security

[Magnus Therning]

On Mon, May 5, 2014 at 10:20 AM, Cecil Westerhof  wrote:
> 2014-05-05 8:21 GMT+02:00 Magnus Therning :
>
>> any language" ;)  However, choosing language wisely will allow you to
>> concentrate on solving the 'real' problem at hand, and relieve you
>> from solving unrelated problems (memory management, dealing with
>> pointers, etc).  It will also simplify reasoning about your code.  I
>
>
> That is why I do not understand that (where I live) they think you can only
> be a good programmer if you only program in one language.

It sounds like you have a bit of teaching to do ;)  Start with
printing a few copies of Why FP Matters
(http://sector0.dk/public_files/why_fp_matters.pdf) and hand them out.
 Eric Raymond's How to Become a Hacker
(http://www.catb.org/~esr/faqs/hacker-howto.html) is also a good read,
pay attention to what he says about LISP:

LISP is worth learning for a different reason — the profound
enlightenment experience you will have when you finally get it. That
experience will make you a better programmer for the rest of your
days, even if you never actually use LISP itself a lot.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

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

http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel

[Valentin Luchko]

Could you explain me why after 
clients;; => {#/0:0:0:0:0:0:0:1%0:60071> true}
(into {} clients) ; => #
I get 

How {#/0:0:0:0:0:0:0:1%0:60071> 
true} is transformed to #?
I suspect it is because I use AsyncChannel as a key, but what is going on?
 



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

Clojure compiled without Eval

[Andrew Stine]

I'm wondering if there is a way to generate Clojure executables/jars 
without the embedded Clojure compiler/interpreter. In older lisps there is 
usually the option to generate an executable with unused bits of the 
language expunged for performance reasons. Clojurescript already sort of 
works this way so I can't think why this would be impossible with Clojure 
specifically.

-- 
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: Clojure compiled without Eval

[Gary Trakhman]

There's a GSOC project to this effect:
http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-LeanJVMRuntime

Reid McKenzie's going to be working on it.


On Mon, May 5, 2014 at 1:06 PM, Andrew Stine  wrote:

> I'm wondering if there is a way to generate Clojure executables/jars
> without the embedded Clojure compiler/interpreter. In older lisps there is
> usually the option to generate an executable with unused bits of the
> language expunged for performance reasons. Clojurescript already sort of
> works this way so I can't think why this would be impossible with Clojure
> specifically.
>
> --
> 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: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel

[Timothy Baldridge]

Can you put the sourcecode in refheap or gist? I can't make sense of your
initial post.

Timothy


On Mon, May 5, 2014 at 11:03 AM, Valentin Luchko  wrote:

> Could you explain me why after
> clients;; => {# /0:0:0:0:0:0:0:1%0:<->/0:0:0:0:0:0:0:1%0:60071> true}
> (into {} clients) ; => # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>
> I get  implementation of method: :take! of protocol:
> #'clojure.core.async.impl.protocols/ReadPort found for class: nil
> AsyncChannel is from http-kit
>
> and
> (merge {} clients) ;; # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>
>
> How {#/0:0:0:0:0:0:0:1%0:60071>
> true} is transformed to # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>?
> I suspect it is because I use AsyncChannel as a key, but what is going on?
>
>
>
>
>  --
> 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.
>



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

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

Re: Clojure equivalent of special common lisp vars: still looking for that zen place...

[John Gabriele]

On Saturday, May 3, 2014 10:53:40 AM UTC-4, Bob Hutchison wrote:
>
>
> On May 3, 2014, at 9:45 AM, Dave Tenny > 
> wrote:
>
> I'm still struggling with how to write the most readable, simple clojure 
> code
> to deal with dynamically bindings.
>
> What is the graceful clojure equivalent of common lisp special variables 
> for the following scenario.
>
> If I were writing common lisp I'd just do something like (pardon if my 
> lisp is rusty here):
>
> (defvar *x* 1)
> ... do stuff with *x* ...
> (setq *x* 2)
> ... do stuff with *x* ...
> (let ((*x* 3))  (do stuff with *x*...)
> ;; do stuff with *x* that's currently at 2
>
>
> The way I'm tempted to do this in clojure is
>
> (def ^{:dynamic true} *x* (atom 1))
> ... do stuff with @*x* ...
> (reset! *x* 2)
> ... do stuff with @*x* ...
> (binding [*x* (atom 3)] (do stuff with @*x*))
>
>
> You can also just write it:
>
> (def ^:dynamic *x* (atom 1))
>
> which is a little less verbose.
>
>
My understanding is that it's more common to *either*

  * use `(def ^:dynamic *x* 1)`, *or*
  * use `(def x (atom 1))`,

but not both at the same time.

That is to say, either you specifically want at dynamic var which you can 
change via a `binding`, or else you just want a global mutable (the atom).

Would love to be corrected if I'm wrong though.

-- John

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

Re: Clojure equivalent of special common lisp vars: still looking for that zen place...

[Gary Trakhman]

Sometimes you do want a mutable thing with thread-local binding, noir does
this for it's mutable session-flash stuff:
https://github.com/noir-clojure/lib-noir/blob/master/src/noir/session.clj#L95

I don't really recommend the approach, but I could see it being convenient.


On Mon, May 5, 2014 at 1:38 PM, John Gabriele  wrote:

> On Saturday, May 3, 2014 10:53:40 AM UTC-4, Bob Hutchison wrote:
>>
>>
>> On May 3, 2014, at 9:45 AM, Dave Tenny  wrote:
>>
>> I'm still struggling with how to write the most readable, simple clojure
>> code
>> to deal with dynamically bindings.
>>
>> What is the graceful clojure equivalent of common lisp special variables
>> for the following scenario.
>>
>> If I were writing common lisp I'd just do something like (pardon if my
>> lisp is rusty here):
>>
>> (defvar *x* 1)
>> ... do stuff with *x* ...
>> (setq *x* 2)
>> ... do stuff with *x* ...
>> (let ((*x* 3))  (do stuff with *x*...)
>> ;; do stuff with *x* that's currently at 2
>>
>>
>> The way I'm tempted to do this in clojure is
>>
>> (def ^{:dynamic true} *x* (atom 1))
>> ... do stuff with @*x* ...
>> (reset! *x* 2)
>> ... do stuff with @*x* ...
>> (binding [*x* (atom 3)] (do stuff with @*x*))
>>
>>
>> You can also just write it:
>>
>> (def ^:dynamic *x* (atom 1))
>>
>> which is a little less verbose.
>>
>>
> My understanding is that it's more common to *either*
>
>   * use `(def ^:dynamic *x* 1)`, *or*
>   * use `(def x (atom 1))`,
>
> but not both at the same time.
>
> That is to say, either you specifically want at dynamic var which you can
> change via a `binding`, or else you just want a global mutable (the atom).
>
> Would love to be corrected if I'm wrong though.
>
> -- John
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: Functional programming and security

[Brian Craft]

I would never have guessed modularity as a reason to worry about security 
in fp.

I worry about immutability in fp, wrt security. Security requires 
mutability in order to remove sensitive data from memory, and from app 
history. A FIPS review, for example, requires demonstrating where in your 
code you explicitly zero memory that holds sensitive passwords. If you code 
entirely with immutable data structures, that's going to be problematic. If 
you've stuck it in some structure that retains historical application state 
so you can "undo", that's even more problematic. If you build debug 
workflows that require reloading historical application states that contain 
data that must not be persisted for privacy reasons, how badly does your 
workflow suffer when you are required to stop storing this data?


On Monday, May 5, 2014 3:17:42 AM UTC-7, Magnus Therning wrote:
>
> On Mon, May 5, 2014 at 10:20 AM, Cecil Westerhof 
> > 
> wrote: 
> > 2014-05-05 8:21 GMT+02:00 Magnus Therning 
> > >: 
>
> > 
> >> any language" ;)  However, choosing language wisely will allow you to 
> >> concentrate on solving the 'real' problem at hand, and relieve you 
> >> from solving unrelated problems (memory management, dealing with 
> >> pointers, etc).  It will also simplify reasoning about your code.  I 
> > 
> > 
> > That is why I do not understand that (where I live) they think you can 
> only 
> > be a good programmer if you only program in one language. 
>
> It sounds like you have a bit of teaching to do ;)  Start with 
> printing a few copies of Why FP Matters 
> (http://sector0.dk/public_files/why_fp_matters.pdf) and hand them out. 
>  Eric Raymond's How to Become a Hacker 
> (http://www.catb.org/~esr/faqs/hacker-howto.html) is also a good read, 
> pay attention to what he says about LISP: 
>
> LISP is worth learning for a different reason — the profound 
> enlightenment experience you will have when you finally get it. That 
> experience will make you a better programmer for the rest of your 
> days, even if you never actually use LISP itself a lot. 
>
> /M 
>
> -- 
> Magnus Therning  OpenPGP: 0xAB4DFBA4 
> email: mag...@therning.orgjabber: 
> mag...@therning.org 
> twitter: magthe   http://therning.org/magnus 
>

-- 
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: Managing State Changes, using Component

[Timothy Washington]

Responses inlined ...


On Mon, May 5, 2014 at 12:35 AM, Atamert Ölçgen  wrote:

>
> Hello Timothy,
>
>
> On Sat, May 3, 2014 at 8:49 PM, Timothy Washington wrote:
>
>>
>> Also, have you tried confirming that only one :a is instantiated?
>>>
>>
>>  That one *:a* is not the same instance throughout all the dependant
>> components. Seems that it's the [*:core :a*] bit that's passed to all
>> the components in the *'start* *'stop* functions. I say this, because
>> when one of my dependant components updated an atom in it's own [*:local
>> :a*], it was [*:core :a*] that reflected that change.
>>
>>
> I'm not sure if I follow correctly. Looking at your code, (ca/component-a
> env) should be called exactly once and the resulting value should be the
> :a. Then, when other components that depend on :a gets initialized, their
> [:local :a]'s should be exactly the same value. If the value we're talking
> about is an atom, i.e. ca/component-a returns an atom, then modifying this
> atom in one component (as you say above [:local :a]) would cause it's
> value, when [:core :a] is dereferenced, to be the new value. So if I'm not
> missing something, the situation you describe above is exactly how it
> should work.
>

Yes, so modifying an atom in [*:local :a*] (in ca/component-a)
*did*reflect in the new [*:core
:a*].

The problem I found, was that if I later try to access [*:local :a*] (in
ca/component-a), I *did not* see that change reflected.



>
> If you, however, say add a debug print in ca/component-a, and see that
> it's called more than once, you should file a bug report.
>

I just assumed that this was the expected behaviour. But I'll check it to
see if it's a bug.



>  --
> Kind Regards,
> Atamert Ölçgen
>
> -+-
>
> www.muhuk.com
>
>

Thanks

Tim Washington
Interruptsoftware.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.

Re: Achieving structural sharing when composing data

[Mike Fikes]

Thanks Gary, Leif, Alex!

I suspected memoization might be the way to go—the leap I needed to make 
was: writing my own data constructors.


On Monday, May 5, 2014 9:10:40 AM UTC-4, Alex Miller wrote:
>
> To clarify slightly, the Java Language Specification section 5.1.7 
> requires that the implementation cache *boxed* ints from -128 to 127, 
> boolean true/false, and characters from \u and \u007f. Because Clojure 
> defaults to boxing in many cases you'll see the same effect.
>
> The persistent collections do go through factories and already cache one 
> special case: empty list/vector/set/map. This is also where the choice is 
> made as to the type of persistent map (array or hash impl) based on size (
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L1457
> ). 
>
> I think in general, there is not enough commonality across programs for 
> the cost of the check to be more costly than the benefits to be saved in 
> memory so this is not something Clojure would ever do generically. But, if 
> this is tradeoff is important to you, then creating your own factory 
> function for collections and memoizing it would be a good way to achieve 
> that. 
>
>
> On Sunday, May 4, 2014 10:21:28 PM UTC-5, Leif wrote:
>>
>>
>> The general technique in lisp is called hash consing (a.k.a. flyweight 
>> pattern, a.k.a. interning).  Java strings, clojure symbols, and keywords 
>> are interned.  And small integers, apparently.
>>
>> The basic idea is to create memoized versions of all the data 
>> constructors and only use them.  This is basically what you did in your 
>> example and what Gary suggested.  So, if you truly wanted something 
>> general, you'd probably have to reimplement a lot of clojure.core, or 
>> restrict yourself to a small number of constructor fns.  
>>
>> If the vectors in your example are the only composite structure that 
>> needs sharing, and they represent points, say:
>>
>> (def mk-point (memoize (fn [x y] [x y]))) ; obviously lots of options 
>> here (caching strategy, weak refs)
>>
>> (def m1 {:a (mk-point 1 2)})
>>
>> (def m2 (assoc m1 :b (mk-point 1 2)))
>>
>> (identical? (m2 :a) (m2 :b)) ; => true
>>
>> If the maps themselves need to be shared, you'll have to make your own 
>> version of assoc, dissoc, maybe conj & into, etc etc, and remember to 
>> always use them.  It could get complicated.
>>
>> --Leif
>>
>> On Saturday, May 3, 2014 10:27:29 PM UTC-4, Mike Fikes wrote:
>>>
>>> Are there common techniques or idioms for achieving structural sharing 
>>> when composing data where equivalences exist?
>>>
>>> (My motivation is to reduce heap usage for a particular problem I'm 
>>> working on that involves a lot of repeated data.)
>>>
>>> As a specific example, consider sharing equivalent map values:
>>>
>>> (def m1 {:a [1 2]})
>>>
>>> (def m2 (assoc m1 :b [1 2]))
>>>
>>>
>>> (identical? (m2 :a) (m2 :b))
>>>
>>> ;; => false
>>>
>>>
>>> For this simple example, I can force sharing by introducing a variant of 
>>> assoc which looks at existing values:
>>>
>>>
>>> (defn assoc-id [map key val] (assoc map key (get (apply hash-set (vals 
>>> map)) val val)))
>>>
>>>
>>> And using it results in a map with two identical values:
>>>
>>>
>>> (def m3 (assoc-id m1 :b [1 2]))
>>>
>>>
>>> (identical? (m3 :a) (m3 :b))
>>>
>>> ;; => true
>>>
>>>
>>> But, of course, this approach could get to be expensive and/or unwieldy 
>>> if not done carefully.
>>>
>>>
>>> So, I was wondering if there are general techniques in this area. I'm 
>>> sure I'm not the first to come across it. We already get this 
>>> automatically for boxing of small integers:
>>>
>>>
>>> (identical? 5 5)
>>>
>>> ;; => true
>>>
>>>
>>> (identical? 500 500)
>>>
>>> ;; => false
>>>
>>>
>>> So I suppose I'm essentially looking for the same idea but for larger 
>>> non-primitive "values".
>>>
>>>
>>>
>>>

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

Why does `lein new` default to clojure 1.5.1?

[gvim]

I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
:all` doesn't return an upgrade for Clojure 1.5.1


gvim

--
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: Managing State Changes, using Component

[Stuart Sierra]

At what point did you **create** the Atom in :a? Any mutable references 
which need to be shared among all usages of a component must be created in 
the **constructor**, not the `start` or `stop` methods.

-S


On Wednesday, April 30, 2014 5:13:15 PM UTC-4, frye wrote:
>
> Hi all, 
>
> I'm having a weird state problem with 
> Component. 
> Let's say I have a system component, like in fig.1. Starting / stopping and 
> loading state is fine. 
> However, let's say I have 2 other components (:updater , :reader) that use 
> component :a. This is the problem that occurs.
>
>1. When *:updater*, modifies an atom in *:a*, that change appears in 
>path [*:core :a*], not path [*:updater :a*] or [*:a*]. 
>2. Because of the abouve, when *:reader* goes to it's local path [
>*:reader :a*] to read that change, it doesn't see those modifications. 
>3. Using this scheme, *:a* is duplicated 4 times, in the system map. 
>However, the modifications only appear in path [*:core :a*]. Thus 
>:reader is unable to access it (it's local [*:a*] is unchanged). 
>
>
> (def system-components [:a :updater :reader])
>
> (defrecord Core [env] component/Lifecycle
>   (start [this] ...)
>   (stop [this] ...))
>
> (defn component-core [env]
>
>   (component/system-map
>:a (component/using
>   (ca/component-a env)
>   {})
>:updater (component/using
>  (cs/component-updater env)
>  {:a :a})
>:reader(component/using
>  (cs/component-reader env)
>  {:a :a})
>:core (component/using
> (map->Foobar {:env env})
> {:a :a 
>
>  :updater :updater 
>
>  :reader :reader })))
>
> *fig.1 *
>
>
> I was hoping to use Component to manage all internal application state. 
> But maybe it's not designed for this use case (state changes between 
> components). I imagine that immutability is preventing all those duplicates 
> from seeing the modifications. However, in this case I do need an update to 
> :a in one component, to be accessed by another component. 
>
> Any suggestions on patterns here? I'm also looking at 
> component/update-system.
>  
> But again, I don't have access to the core *system* var, from within my 
> components. 
>
>
> Any insights appreciated 
>
> Tim Washington 
> Interruptsoftware.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.

Re: Why does `lein new` default to clojure 1.5.1?

[mynomoto]

The default lein template has clojure 1.5.1 hardcoded. It will only change 
when it's updated there.
You can check the lein ancient help with `lein help ancient`. There you 
will find how to include clojure on the verification.

HTH,
Marcelo

On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>
> I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
> :all` doesn't return an upgrade for Clojure 1.5.1 
>
> gvim 
>

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

Problem when trying to import SAT4J java class

[Ronan BARZIC]

Hi,

I'm trying to use the SAT4J java library (http://www.sat4j.org) from 
Clojure.
I've create a clojure app with "lein new app sat4j-app"

I've edited the project.clj file to :

(defproject sat4j-app "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [
 [org.clojure/clojure "1.5.1"]
 [org.ow2.sat4j/org.ow2.sat4j.sat "2.3.5"]
 [org.ow2.sat4j/org.ow2.sat4j.core "2.3.5"]  
 ]
  :main sat4j-app.core
  :profiles {:uberjar {:aot :all}})

If I run lein deps, I can see that leiningen can find the sta4j modules :

Retrieving 
org/ow2/sat4j/org.ow2.sat4j.sat/2.3.5/org.ow2.sat4j.sat-2.3.5.pom from 
central
Retrieving 
org/ow2/sat4j/org.ow2.sat4j.pom/2.3.5/org.ow2.sat4j.pom-2.3.5.pom from 
central
Retrieving org/ow2/ow2/1.5/ow2-1.5.pom from central
Retrieving 
org/ow2/sat4j/org.ow2.sat4j.core/2.3.5/org.ow2.sat4j.core-2.3.5.pom from 
central


And I can compile and run the default code (no sat4j import yet).
The problem occurs when I try to use import in my main clojure code :

(ns sat4j-app.core
  (:gen-class)
  (:import org.ow2.sat4j/org.ow2.sat4j.core Vec ))

I then get a Class not found exception (Vec is suppoed to be defined in the 
core module)
I don't know which syntax to use in the import statement. 
I've also tried (:import org.ow2.sat4j.core Vec ), (:import 
org.ow2.sat4j.core.Vec ) without success.

To make think even more confusing, I did a local build of sat4j and I found 
(using javadoc html page) that the Vec class is defined as 
org.sat4j.core.Vec
not org.ow2.sat4j.core.Vec. 
So I tried (:import org.sat4j.core.Vec ) and (:import org.sat4j.core Vec ) 
without success.

Any clue ?


Thank you


Ronan










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

Re: Why does `lein new` default to clojure 1.5.1?

[Alex Miller]

The default leiningen templates have already been updated to Clojure 1.6.0:
https://github.com/technomancy/leiningen/commit/a296ff8918a581c975f49127d7e37a3f0c510d22

However, I don't think that change will be visible till the next lein 
release.


On Monday, May 5, 2014 3:08:56 PM UTC-5, mynomoto wrote:
>
> The default lein template has clojure 1.5.1 hardcoded. It will only change 
> when it's updated there.
> You can check the lein ancient help with `lein help ancient`. There you 
> will find how to include clojure on the verification.
>
> HTH,
> Marcelo
>
> On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>>
>> I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
>> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
>> :all` doesn't return an upgrade for Clojure 1.5.1 
>>
>> gvim 
>>
>

-- 
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: Problem when trying to import SAT4J java class

[Jason Felice]

The form should be:

(:import [org.sat4j.core Vec]) ; note the square braces.


On Mon, May 5, 2014 at 3:29 PM, Ronan BARZIC  wrote:

> Hi,
>
> I'm trying to use the SAT4J java library (http://www.sat4j.org) from
> Clojure.
> I've create a clojure app with "lein new app sat4j-app"
>
> I've edited the project.clj file to :
>
> (defproject sat4j-app "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :dependencies [
>  [org.clojure/clojure "1.5.1"]
>  [org.ow2.sat4j/org.ow2.sat4j.sat "2.3.5"]
>  [org.ow2.sat4j/org.ow2.sat4j.core "2.3.5"]
>  ]
>   :main sat4j-app.core
>   :profiles {:uberjar {:aot :all}})
>
> If I run lein deps, I can see that leiningen can find the sta4j modules :
> 
> Retrieving
> org/ow2/sat4j/org.ow2.sat4j.sat/2.3.5/org.ow2.sat4j.sat-2.3.5.pom from
> central
> Retrieving
> org/ow2/sat4j/org.ow2.sat4j.pom/2.3.5/org.ow2.sat4j.pom-2.3.5.pom from
> central
> Retrieving org/ow2/ow2/1.5/ow2-1.5.pom from central
> Retrieving
> org/ow2/sat4j/org.ow2.sat4j.core/2.3.5/org.ow2.sat4j.core-2.3.5.pom from
> central
> 
>
> And I can compile and run the default code (no sat4j import yet).
> The problem occurs when I try to use import in my main clojure code :
>
> (ns sat4j-app.core
>   (:gen-class)
>   (:import org.ow2.sat4j/org.ow2.sat4j.core Vec ))
>
> I then get a Class not found exception (Vec is suppoed to be defined in
> the core module)
> I don't know which syntax to use in the import statement.
> I've also tried (:import org.ow2.sat4j.core Vec ), (:import
> org.ow2.sat4j.core.Vec ) without success.
>
> To make think even more confusing, I did a local build of sat4j and I
> found (using javadoc html page) that the Vec class is defined as
> org.sat4j.core.Vec
> not org.ow2.sat4j.core.Vec.
> So I tried (:import org.sat4j.core.Vec ) and (:import org.sat4j.core Vec
> ) without success.
>
> Any clue ?
>
>
> Thank you
>
>
> Ronan
>
>
>
>
>
>
>
>
>
>
>  --
> 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: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel

[Valentin Luchko]

Here is the gist
https://gist.github.com/valichek/ba510de9ff2cf3d0c502

P.S. sorry if my first post was odd
понедельник, 5 мая 2014 г., 20:03:09 UTC+3 пользователь Valentin Luchko 
написал:
>
> Could you explain me why after 
> clients;; => {# /0:0:0:0:0:0:0:1%0:<->/0:0:0:0:0:0:0:1%0:60071> true}
> (into {} clients) ; => # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>
> I get  implementation of method: :take! of protocol: 
> #'clojure.core.async.impl.protocols/ReadPort found for class: nil
> AsyncChannel is from http-kit
>
> and
> (merge {} clients) ;; # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>
>
> How {#/0:0:0:0:0:0:0:1%0:60071> 
> true} is transformed to # clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a>?
> I suspect it is because I use AsyncChannel as a key, but what is going on?
>  
>
>
>
>

-- 
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: JSON authentication with cemerick/friend?

[Ivan Schuetz]

Concerning the workflow with the ajax-login... for some reason the 
middleware to set params with json body of my POST isn't working.

As a workaround I added this to ajax-login, to parse the params:

(checore/parse-string (slurp (:body request)) true)  



I had also to remove the interactive-form workflow I had... now my 
middleware looks like this:


   (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)
:login-url "/login"
:workflows [
(ajax-login)
]})



I do have the middlewares supposedly responsible for setting :params ... 
not idea why this is not being done. This is the complete block:

(def app
  (->
  (handler/api app-routes)

  (format/wrap-restful-format)

  (middleware/wrap-json-body)
  (middleware/wrap-json-params)
  (middleware/wrap-json-response)

   (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)
:login-url "/login"
:workflows [
(ajax-login)
]})

  )
  )

But well, it works for now.



Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
>
> Also I couldn't find which library you're using for "get-headers" 
> function... or is it a self made one?
>
> I found a get-headers in ring-servlet...
> https://github.com/ring-clojure/ring/tree/master/ring-servlet
>
> Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work
>
> And also in a netty adapter library
>  [ring-netty-adapter "0.0.3"]
>
> Also didn't work... for now I commented this line out, since it's not 
> necessary to get my curl test working. But it would be nice if you provide 
> the dependencies.
>
>
>
> Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
>>
>> Here is an example from our ajax-login form. After reading Sam's 
>> excellent writeup it should be understandable.
>>
>> https://gist.github.com/ebaxt/11244031
>>
>> kl. 00:28:45 UTC+2 torsdag 24. april 2014 skrev Ivan Schuetz følgende:
>>>
>>> Hi,
>>>
>>> I'm trying to get a simple use case running - send a login request to 
>>> /login and get success or fail response, preferably in JSON format.
>>>
>>> I followed the example in https://github.com/cemerick/friend#workflows
>>>
>>>
>>> (def users {"root" {:username "root"
>>> :password (creds/hash-bcrypt "admin_password")
>>> :roles #{::admin}}
>>> "jane" {:username "jane"
>>> :password (creds/hash-bcrypt "test")
>>> :roles #{::user}}})
>>>
>>>
>>> (defroutes app-routes
>>>
>>>   (GET "/test" [] {:body {:my-map "helo"}})
>>>   
>>>   (route/resources "/")
>>>   
>>>   (route/not-found "Not found"))
>>>
>>> (def app
>>>   (->
>>>   (handler/api app-routes)
>>>   (middleware/wrap-json-body)
>>>   (middleware/wrap-json-response)
>>>
>>>(friend/authenticate {:credential-fn (partial 
>>> creds/bcrypt-credential-fn users)
>>> :workflows [
>>> (workflows/interactive-form)]})
>>>   )
>>>   )
>>>
>>>
>>>
>>> I'm testing with curl:
>>>
>>> curl -v --data "username=jane&password=test" http://localhost:3000/login
>>>
>>> Or:
>>>
>>> curl -v --request POST  "
>>> http://localhost:3000/login?username=jane&password=test";
>>>
>>> And I get:
>>>
>>> * About to connect() to localhost port 3000 (#0)
>>> *   Trying ::1...
>>> * connected
>>> * Connected to localhost (::1) port 3000 (#0)
>>> > POST /login?username=jane&password=test HTTP/1.1
>>> > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 
>>> OpenSSL/0.9.8y zlib/1.2.5
>>> > Host: localhost:3000
>>> > Accept: */*
>>> > 
>>> < HTTP/1.1 302 Found
>>> < Date: Wed, 23 Apr 2014 22:25:15 GMT
>>> < Location: http://localhost:3000/login?&login_failed=Y&username=
>>> < Content-Length: 0
>>> < Server: Jetty(7.6.8.v20121106)
>>> < 
>>> * Connection #0 to host localhost left intact
>>> * Closing connection #0
>>>
>>>
>>> This looks like authentication failed, but the data is correct. I 
>>> reviewed the curl request, and this seems to be the correct way to send a 
>>> POST. But &username= gives me the impression it's not being parsed 
>>> correctly.
>>>
>>> Also, how can I get a JSON response instead of only a header?
>>>
>>> Thanks.
>>>
>>> P.S. Maybe it would be positive if this library has an own Google Group.
>>>
>>

-- 
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://g

Re: Managing State Changes, using Component

[Timothy Washington]

Ahh, so that was it then. Yeah, I definitely created that atom in the start
method.

Thanks very much.


Tim Washington
Interruptsoftware.com 


On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra
wrote:

> At what point did you **create** the Atom in :a? Any mutable references
> which need to be shared among all usages of a component must be created in
> the **constructor**, not the `start` or `stop` methods.
>
> -S
>
>
>
> On Wednesday, April 30, 2014 5:13:15 PM UTC-4, frye wrote:
>>
>> Hi all,
>>
>> I'm having a weird state problem with 
>> Component.
>> Let's say I have a system component, like in fig.1. Starting / stopping and
>> loading state is fine.
>> However, let's say I have 2 other components (:updater , :reader) that
>> use component :a. This is the problem that occurs.
>>
>>1. When *:updater*, modifies an atom in *:a*, that change appears in
>>path [*:core :a*], not path [*:updater :a*] or [*:a*].
>>2. Because of the abouve, when *:reader* goes to it's local path [
>>*:reader :a*] to read that change, it doesn't see those
>>modifications.
>>3. Using this scheme, *:a* is duplicated 4 times, in the system map.
>>However, the modifications only appear in path [*:core :a*]. Thus
>>:reader is unable to access it (it's local [*:a*] is unchanged).
>>
>>
>> (def system-components [:a :updater :reader])
>>
>> (defrecord Core [env] component/Lifecycle
>>   (start [this] ...)
>>   (stop [this] ...))
>>
>> (defn component-core [env]
>>
>>   (component/system-map
>>:a (component/using
>>   (ca/component-a env)
>>   {})
>>:updater (component/using
>>  (cs/component-updater env)
>>  {:a :a})
>>:reader(component/using
>>  (cs/component-reader env)
>>  {:a :a})
>>:core (component/using
>> (map->Foobar {:env env})
>> {:a :a
>>
>>  :updater :updater
>>
>>  :reader :reader })))
>>
>> *fig.1 *
>>
>>
>> I was hoping to use Component to manage all internal application state.
>> But maybe it's not designed for this use case (state changes between
>> components). I imagine that immutability is preventing all those duplicates
>> from seeing the modifications. However, in this case I do need an update to
>> :a in one component, to be accessed by another component.
>>
>> Any suggestions on patterns here? I'm also looking at
>> component/update-system.
>> But again, I don't have access to the core *system* var, from within my
>> components.
>>
>>
>> Any insights appreciated
>>
>> Tim Washington
>> Interruptsoftware.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.
>

-- 
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: JSON authentication with cemerick/friend?

[Sam Ritchie]

(middleware/wrap-json-params) slurps the body up completely - this 
is a mutation, so you won't be able to access the body again.



Ivan Schuetz 
May 5, 2014 3:49 PM
Concerning the workflow with the ajax-login... for some reason the 
middleware to set params with json body of my POST isn't working.


As a workaround I added this to ajax-login, to parse the params:

(checore/parse-string (slurp (:body request)) true)



I had also to remove the interactive-form workflow I had... now my 
middleware looks like this:



   (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)

:login-url "/login"
:workflows [
(ajax-login)
]})



I do have the middlewares supposedly responsible for setting :params 
... not idea why this is not being done. This is the complete block:


(def app
  (->
  (handler/api app-routes)

  (format/wrap-restful-format)
  (middleware/wrap-json-body)
  (middleware/wrap-json-params)
  (middleware/wrap-json-response)

   (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)

:login-url "/login"
:workflows [
(ajax-login)
]})

  )
  )

But well, it works for now.



Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
--
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.
Ivan Schuetz 
April 25, 2014 10:53 AM
Also I couldn't find which library you're using for "get-headers" 
function... or is it a self made one?


I found a get-headers in ring-servlet...
https://github.com/ring-clojure/ring/tree/master/ring-servlet

Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work

And also in a netty adapter library
 [ring-netty-adapter "0.0.3"]

Also didn't work... for now I commented this line out, since it's not 
necessary to get my curl test working. But it would be nice if you 
provide the dependencies.




Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
--
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.
Erik Bakstad 
April 24, 2014 12:51 AM
Here is an example from our ajax-login form. After reading Sam's 
excellent writeup it should be understandable.


https://gist.github.com/ebaxt/11244031

kl. 00:28:45 UTC+2 torsdag 24. april 2014 skrev Ivan Schuetz følgende:
--
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.
Ivan Schuetz 
April 23, 2014 4:28 PM
Hi,

I'm trying to get a simple use case running - send a login request to 
/login and get success or fail response, preferably in JSON format.


I followed the example in https://github.com/cemerick/friend#workflows 

Re: JSON authentication with cemerick/friend?

[Ivan Schuetz]

The snippet provided by Eric doesn't use the body... it returns a function 
that accepts params as argument, but they were not being passed... body was 
set instead, that's why I added slurp.

So maybe there's something wrong with the  (middleware/wrap-json-params), 
because it's evidently not having effect.


Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>
> (middleware/wrap-json-params) slurps the body up completely - this is 
> a mutation, so you won't be able to access the body again.
>
>   Ivan Schuetz 
>  May 5, 2014 3:49 PM
> Concerning the workflow with the ajax-login... for some reason the 
> middleware to set params with json body of my POST isn't working.
>
> As a workaround I added this to ajax-login, to parse the params:
>
> (checore/parse-string (slurp (:body request)) true)  
>
>
>
> I had also to remove the interactive-form workflow I had... now my 
> middleware looks like this:
>
>
>(friend/authenticate {:credential-fn (partial 
> creds/bcrypt-credential-fn users)
> :login-url "/login"
> :workflows [
> (ajax-login)
> ]})
>
>
>
> I do have the middlewares supposedly responsible for setting :params ... 
> not idea why this is not being done. This is the complete block:
>
> (def app
>   (->
>   (handler/api app-routes)
>
>   (format/wrap-restful-format)
> 
>   (middleware/wrap-json-body)
>   (middleware/wrap-json-params)
>   (middleware/wrap-json-response)
>
>(friend/authenticate {:credential-fn (partial 
> creds/bcrypt-credential-fn users)
> :login-url "/login"
> :workflows [
> (ajax-login)
> ]})
>
>   )
>   )
>
> But well, it works for now.
>
>
>
> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>   Ivan Schuetz 
>  April 25, 2014 10:53 AM
> Also I couldn't find which library you're using for "get-headers" 
> function... or is it a self made one?
>
> I found a get-headers in ring-servlet...
> https://github.com/ring-clojure/ring/tree/master/ring-servlet
>
> Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work
>
> And also in a netty adapter library
>  [ring-netty-adapter "0.0.3"]
>
> Also didn't work... for now I commented this line out, since it's not 
> necessary to get my curl test working. But it would be nice if you provide 
> the dependencies.
>
>
>
> Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>   Erik Bakstad 
>  April 24, 2014 12:51 AM
> Here is an example from our ajax-login form. After reading Sam's excellent 
> writeup it should be understandable.
>
> https://gist.github.com/ebaxt/11244031
>
> kl. 00:28:45 UTC+2 torsdag 24. april 2014 skrev Ivan Schuetz følgende:
> -- 
> 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...@googleg

Re: JSON authentication with cemerick/friend?

[Ivan Schuetz]

Sorry. I mean accepts the request map as an argument. This map doesn't 
contain the parameters.


Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:
>
> The snippet provided by Eric doesn't use the body... it returns a function 
> that accepts params as argument, but they were not being passed... body was 
> set instead, that's why I added slurp.
>
> So maybe there's something wrong with the  (middleware/wrap-json-params), 
> because it's evidently not having effect.
>
>
> Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>>
>> (middleware/wrap-json-params) slurps the body up completely - this is 
>> a mutation, so you won't be able to access the body again.
>>
>>   Ivan Schuetz
>>  May 5, 2014 3:49 PM
>> Concerning the workflow with the ajax-login... for some reason the 
>> middleware to set params with json body of my POST isn't working.
>>
>> As a workaround I added this to ajax-login, to parse the params:
>>
>> (checore/parse-string (slurp (:body request)) true)  
>>
>>
>>
>> I had also to remove the interactive-form workflow I had... now my 
>> middleware looks like this:
>>
>>
>>(friend/authenticate {:credential-fn (partial 
>> creds/bcrypt-credential-fn users)
>> :login-url "/login"
>> :workflows [
>> (ajax-login)
>> ]})
>>
>>
>>
>> I do have the middlewares supposedly responsible for setting :params ... 
>> not idea why this is not being done. This is the complete block:
>>
>> (def app
>>   (->
>>   (handler/api app-routes)
>>
>>   (format/wrap-restful-format)
>> 
>>   (middleware/wrap-json-body)
>>   (middleware/wrap-json-params)
>>   (middleware/wrap-json-response)
>>
>>(friend/authenticate {:credential-fn (partial 
>> creds/bcrypt-credential-fn users)
>> :login-url "/login"
>> :workflows [
>> (ajax-login)
>> ]})
>>
>>   )
>>   )
>>
>> But well, it works for now.
>>
>>
>>
>> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>   Ivan Schuetz
>>  April 25, 2014 10:53 AM
>> Also I couldn't find which library you're using for "get-headers" 
>> function... or is it a self made one?
>>
>> I found a get-headers in ring-servlet...
>> https://github.com/ring-clojure/ring/tree/master/ring-servlet
>>
>> Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work
>>
>> And also in a netty adapter library
>>  [ring-netty-adapter "0.0.3"]
>>
>> Also didn't work... for now I commented this line out, since it's not 
>> necessary to get my curl test working. But it would be nice if you provide 
>> the dependencies.
>>
>>
>>
>> Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>   Erik Bakstad
>>  April 24, 2014 12:51 AM
>> Here is an example from our ajax-login form. After reading Sam's 
>> excellent writeup it should be understandable.
>>
>> https://gist.github.com/ebaxt/11244031
>>
>> kl. 00:28:45 UTC+2 torsdag 24. april 2014 skrev Ivan Schuetz følgende:
>> -- 
>> 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 m

Re: Converting sequence from sort into a list

[Sean Corfield]

My question would be: why do you specifically need a list? i.e., why isn't a 
sequence good enough?

Sean

On May 3, 2014, at 6:30 AM, Dave Tenny  wrote:
> After nosing around all I've come up with via clojure mechanisms is to use 
> (apply list (sort ...)).
> It seems to work well enough for lists of arbitrary size (subject to usual 
> memory/size limitations of large lists).
> 
> I also considered some native java abuse such as 
> java.util.Arrays.asList(Enumeration),
> though I didn't quickly find a way to convert the clojure.lang.ArraySeq from 
> my sort() in testing to an Enumeration.
> 
> Guess I'm set for now, I was just hoping to avoid consing a new list on my 
> sort result in order to get a specific collection type.




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] packthread 0.1.0

[Sean Corfield]

A specific case: when I worked at Adobe, we could not use any open source 
library whose license was not one of a standard set of pre-approved licenses. 
During a license audit (oh joy!) I had to approach a couple of OSS projects we 
had started to use in order to persuade them to change their license to one of 
the approved ones.

(and it also led us to request one project change from LGPL to something more 
"friendly" to corporate use since that project generated code that merged with 
your own code and it was a grey area how exactly that merged code would be 
affected by LGPL - lawyers are interesting creatures and can be pedantic beyond 
anything we software developers might consider reasonable)

It's much more likely however that such companies would simply discount your 
library than ask you to change the license, so you may never be asked that 
question: your library will just be quietly ignored :)

Sean

On May 3, 2014, at 7:10 AM, James Reeves  wrote:

> Some software companies, particularly larger ones, are careful about the 
> licenses of software they use in their products. With a standard open source 
> license it's often easy to get approval, because licenses like MIT are very 
> common.
> 
> Software with a custom license is trickier, because it's not a case of 
> rubber-stamping a license known to be safe. Someone with legal training would 
> have to look over the license and certify it as being safe to use.
> 
> This also applies to dependencies. If a library happens to use packthread, 
> then suddenly that library becomes legally suspect as well. Is MIT compatible 
> with your license? Is EPL?
> 
> The benefit to using an existing open source license is that their legal 
> position is clear. Even though your license is simple, IANAL, so I wouldn't 
> be able to say for sure there's no hidden subtlety there that might impact my 
> project if I use it. It may be that there will never be an issue, but why 
> should I risk it?
> 
> - James
> 
> 
> On 3 May 2014 13:46, Jason Felice  wrote:
> Hi!
> 
> I'm pretty familiar with legal license stuff (though IANAL).  I wouldn't mind 
> considering changing it at the point where someone wants to use it but can't 
> - because that would carry with it a specific reason we can think about.
> 
> -Jason
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

clojure.zip: skip a node

[Pascal Germroth]

Hi,

I'm using clojure.zip to edit a tree by visiting each location using 
zip/next, possibly using zip/replace to alter the tree.
There are cases where I replace a part of the tree with another tree that 
will/must not be visited, but I couldn't find a good way to skip nodes, 
since
(zip/next (zip/replace loc new-subtree)) will walk right into my new tree, 
and I can't use (zip/right (zip/replace loc new-subtree)) as the replaced 
location might already be the rightmost.

Is there a built-in function I missed, or a zip enhancement library I could 
use?

(defn skip
  "returns the next location that is not a child of this one"
  [loc]
  (if (or (z/end? loc) (nil? loc))
loc
(loop [loc loc]
  (or (z/right loc)
  (recur (z/up loc))

I came up with this replacement, does that seem like a good idea, or am I 
using zip completely wrong (because what I really would like to do is 
iterate backwards through the tree, starting at the end, using zip/prev; 
but there's also no function to just jump to the end as far as I can tell)


Cheers,

-- 
pascal

-- 
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: JSON authentication with cemerick/friend?

[Erik Bakstad]

We're using a custom jsonparam-extractor middleware that basically does 
this:

(update-in req [:params] assoc :json-params (read-json b true))

I should probably have clarified this, sorry.

Also, we're not using form-login so I haven't tested if the two workflows 
work together. It shouldn't be a problem to make them work together though.

kl. 02:31:30 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>
> Sorry. I mean accepts the request map as an argument. This map doesn't 
> contain the parameters.
>
>
> Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:
>>
>> The snippet provided by Eric doesn't use the body... it returns a 
>> function that accepts params as argument, but they were not being passed... 
>> body was set instead, that's why I added slurp.
>>
>> So maybe there's something wrong with the  (middleware/wrap-json-params), 
>> because it's evidently not having effect.
>>
>>
>> Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>>>
>>> (middleware/wrap-json-params) slurps the body up completely - this 
>>> is a mutation, so you won't be able to access the body again.
>>>
>>>   Ivan Schuetz
>>>  May 5, 2014 3:49 PM
>>> Concerning the workflow with the ajax-login... for some reason the 
>>> middleware to set params with json body of my POST isn't working.
>>>
>>> As a workaround I added this to ajax-login, to parse the params:
>>>
>>> (checore/parse-string (slurp (:body request)) true)  
>>>
>>>
>>>
>>> I had also to remove the interactive-form workflow I had... now my 
>>> middleware looks like this:
>>>
>>>
>>>(friend/authenticate {:credential-fn (partial 
>>> creds/bcrypt-credential-fn users)
>>> :login-url "/login"
>>> :workflows [
>>> (ajax-login)
>>> ]})
>>>
>>>
>>>
>>> I do have the middlewares supposedly responsible for setting :params ... 
>>> not idea why this is not being done. This is the complete block:
>>>
>>> (def app
>>>   (->
>>>   (handler/api app-routes)
>>>
>>>   (format/wrap-restful-format)
>>> 
>>>   (middleware/wrap-json-body)
>>>   (middleware/wrap-json-params)
>>>   (middleware/wrap-json-response)
>>>
>>>(friend/authenticate {:credential-fn (partial 
>>> creds/bcrypt-credential-fn users)
>>> :login-url "/login"
>>> :workflows [
>>> (ajax-login)
>>> ]})
>>>
>>>   )
>>>   )
>>>
>>> But well, it works for now.
>>>
>>>
>>>
>>> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>   Ivan Schuetz
>>>  April 25, 2014 10:53 AM
>>> Also I couldn't find which library you're using for "get-headers" 
>>> function... or is it a self made one?
>>>
>>> I found a get-headers in ring-servlet...
>>> https://github.com/ring-clojure/ring/tree/master/ring-servlet
>>>
>>> Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work
>>>
>>> And also in a netty adapter library
>>>  [ring-netty-adapter "0.0.3"]
>>>
>>> Also didn't work... for now I commented this line out, since it's not 
>>> necessary to get my curl test working. But it would be nice if you provide 
>>> the dependencies.
>>>
>>>
>>>
>>> Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>   Erik Bakstad
>>>  April 24, 2014 12:51 AM
>>> Here is an example from our ajax-login form. Afte

Re: JSON authentication with cemerick/friend?

[Erik Bakstad]

We're using a custom jsonparam-extractor middleware that basically does 
this:

(update-in req [:params] assoc :json-params (read-json (slurp (:body req)) 
true))

I should probably have clarified this, sorry.

Also, we're not using interactive-form so I haven't tested if the two 
workflows work together. It shouldn't be a problem to make them work 
together though.

kl. 02:31:30 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>
> Sorry. I mean accepts the request map as an argument. This map doesn't 
> contain the parameters.
>
>
> Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:
>>
>> The snippet provided by Eric doesn't use the body... it returns a 
>> function that accepts params as argument, but they were not being passed... 
>> body was set instead, that's why I added slurp.
>>
>> So maybe there's something wrong with the  (middleware/wrap-json-params), 
>> because it's evidently not having effect.
>>
>>
>> Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>>>
>>> (middleware/wrap-json-params) slurps the body up completely - this 
>>> is a mutation, so you won't be able to access the body again.
>>>
>>>   Ivan Schuetz
>>>  May 5, 2014 3:49 PM
>>> Concerning the workflow with the ajax-login... for some reason the 
>>> middleware to set params with json body of my POST isn't working.
>>>
>>> As a workaround I added this to ajax-login, to parse the params:
>>>
>>> (checore/parse-string (slurp (:body request)) true)  
>>>
>>>
>>>
>>> I had also to remove the interactive-form workflow I had... now my 
>>> middleware looks like this:
>>>
>>>
>>>(friend/authenticate {:credential-fn (partial 
>>> creds/bcrypt-credential-fn users)
>>> :login-url "/login"
>>> :workflows [
>>> (ajax-login)
>>> ]})
>>>
>>>
>>>
>>> I do have the middlewares supposedly responsible for setting :params ... 
>>> not idea why this is not being done. This is the complete block:
>>>
>>> (def app
>>>   (->
>>>   (handler/api app-routes)
>>>
>>>   (format/wrap-restful-format)
>>> 
>>>   (middleware/wrap-json-body)
>>>   (middleware/wrap-json-params)
>>>   (middleware/wrap-json-response)
>>>
>>>(friend/authenticate {:credential-fn (partial 
>>> creds/bcrypt-credential-fn users)
>>> :login-url "/login"
>>> :workflows [
>>> (ajax-login)
>>> ]})
>>>
>>>   )
>>>   )
>>>
>>> But well, it works for now.
>>>
>>>
>>>
>>> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>   Ivan Schuetz
>>>  April 25, 2014 10:53 AM
>>> Also I couldn't find which library you're using for "get-headers" 
>>> function... or is it a self made one?
>>>
>>> I found a get-headers in ring-servlet...
>>> https://github.com/ring-clojure/ring/tree/master/ring-servlet
>>>
>>> Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work
>>>
>>> And also in a netty adapter library
>>>  [ring-netty-adapter "0.0.3"]
>>>
>>> Also didn't work... for now I commented this line out, since it's not 
>>> necessary to get my curl test working. But it would be nice if you provide 
>>> the dependencies.
>>>
>>>
>>>
>>> Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>   Erik Bakstad
>>>  April 24, 2014 12:51 AM
>>> Here is an example from