Re: [JOB] Remote Clojure Dev 2 month quick project 20-40 hours per week

[Buck Ryan]

Hi Art,

This is right up my alley. I have four years of experience with Clojure and 
have used it to build a variety of applications, including ones that 
interact with Kafka. I would love to talk more - you can reach me at 
b...@buckryan.com 

Thanks!


On Wednesday, March 14, 2018 at 2:01:14 PM UTC-4, Arturo Carrillo wrote:
>
> Hello everyone!
>
> Needing some help or referrals here. 
>
> The Clojure community is crazy small, but there seems to be a lot of you 
> out there that are super passionate about it.
>
> I am working with a Marketing company and they need some Clojure help 
> ASAP. 2 month fully remote. However, if candidates want to work on-site, 
> they will arrange an extended hotel for the duration of the project. 20-40 
> hours per week.
>
> They are flexible because they understand that it is such a short duration 
> and attracting someone to work full-time for two months is a challenge. 
>
>
>
> Working with Clojure, Kafka, and Elastic search.
>
> They don't want to exceed $95 per hour on a w2 basis, but if you have your 
> own corporation we can do C2C and go a little higher. 
>
> Do you know anyone who is interested in a Clojure project?
>
> Help a brotha out.
>
> FYI (Clojure seems to be gaining a lot of popularity with companies), 
> stayed tuned. You all may have the opportunities to work with it at the 
> production level soon. 
>
> -Art
>
>
>

-- 
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] Book "The Clojure Standard Library - Annotated Reference"

[Ryan Fowler]

I love the idea.

​A gotchas section of some sort could be useful. For instance, a detail
about `case` to consider mentioning is that Java Constants don't work as
tests.

ryans-mbp:~% cat test.clj
(let [incoming-character Character/LINE_SEPARATOR]
  (println "case w/ constant"
   (case incoming-character
 Character/LINE_SEPARATOR :line-separator
 :unknown))
  (println "case w/ int "
   (case incoming-character
 13 :line-separator
 :unknown)))

ryans-mbp:~% java -jar $CLOJURE test.clj
case w/ constant :unknown
case w/ int  :line-separator

​I think I understand why this doesn't work but it feels like it should
work. And without prior knowledge, I don't think I would assume that
constants don't work.

​Ryan​


On Wed, Dec 7, 2016 at 4:57 PM, Alex Miller <a...@puredanger.com> wrote:

> This is a cool idea so thanks for working on it.
>
> I was going to buy this (as I buy most of the Clojure books that come out)
> but $48 for an unfinished ebook put me off so I didn't. I totally get why a
> physical book of this length would be that much (because paper is expensive
> right now), but I don't get it with the ebook (particularly EA)? I know you
> likely have little control over this, so it's not really fair to complain
> to you, but maybe you can feed it back to your editor.
>
> While pretty thorough, that case description is still lacking a
> description of one important feature - grouping multiple tests that have
> the same output in a list. Basically this line from the doc string:
>
> (test-constant1 ... test-constantN)  result-expr
>
>
> Example:
>
> (case 3
>   (1 2 3) "1, 2, or 3"
>   4 "4"
>   (5 6 7) "5, 6, or 7")
>
> ;;=> "1, 2, or 3"
>
> I think most people are unaware of this feature and seems like it's the
> kind of thing you'd want in the book.
>
> Alex
>
> On Wednesday, December 7, 2016 at 12:14:29 PM UTC-6, Renzo Borgatti wrote:
>>
>> Hi all,
>>
>> I'm very happy to announce the early access of a new book: "Clojure
>> Standard Library - Annotated Reference" by Manning. Although it's a
>> reference of the roughly 700+ functions (and macros) coming out of the box
>> with the Clojure jar file, it is not designed to read as a boring list.
>> Think of all the Stackoverflow, mailing lists, ClojureDocs, articles, blogs
>> all mashed together to create an essay for each function. The book website
>> is:
>>
>> https://www.manning.com/books/clojure-standard-library
>>
>> It contains now a total of 4 chapters (around 200 pages) or ~30
>> functions, starting with some of the most important available in the
>> standard library. Here's a sample of “case" how it appears on the book
>> http://tinyurl.com/hekc55u to give you an idea of the kind of treatment
>> they get. Needless to say any feedback is highly appreciated. Any question
>> please shout here, personally at reborg*at*reborg.net or on the book
>> forum.
>>
>> Regards,
>> Renzo
>>
> --
> 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: Clojure as a first programming language?

[Ryan Waters]

It's a question simply stated with an answer that depends on a lot of
things. And, as is often the case with the person giving an answer, without
asking other people I can only relate it to my own experiences with clojure
and programming in general.

The fun and freeing thing about clojure is the flexible ways it allows you
to program and think about programming challenges.  There's a number of
reasons that make this true.  Languages I've used in the past at times felt
like their design was limiting, usually in the form of making easy things
easy and hard things harder than necessary.  Maybe they provided too much
"help" and turned inner workings into a difficult-to-know black box, or
they provided concurrency building blocks without providing a safe
framework to prevent a novice programmer from shooting themselves in the
foot, or they were designed in such a way that locking in developer
mindshare was a primary motivator.  I don't think clojure has these
problems.

Diving into a new language requires good learning resources, particularly
in the ways you find most natural to use.  Are you self-sufficient?  Is
documentation enough or would it be faster and more useful to be able to
ask someone questions?  Do you have any higher education in programming?
Buy some clojure books and spend time with them.  The mailing list, IRC and
slack, et. al. can all be resources for specific questions but more general
questions (even this one) can be more difficult to answer.

Pick something you want to make and explore what different languages have
to offer and you'll naturally find one that resonates with you.  I love
clojure.  It's not perfect but it's still smarter than I am, which I
appreciate.  It rarely gets in my way.



On Thu, Dec 1, 2016 at 12:22 PM, Nur Azhar  wrote:

> Hi,
>
> it's almost 8 years later and I am going to ask these same question since
> it wasn't really answered
>
> Thanks for taking the time to read. I’m interested in trying out Clojure
>> for my first programming language--at least, the first programming language
>> in which I intend to commit myself to becoming proficient.
>> http://stackoverflow.com/questions/10509283/clojure-as-
>> a-first-programming-language
>>
> I hope someone replies
>
> On Tuesday, December 1, 2009 at 1:38:58 PM UTC+8, Towle wrote:
>>
>> Hi all,
>>
>> Thanks for taking the time to read my post. I'm interested to get some
>> opinions from experienced Clojure programmers on whether the language
>> would be a good first language to learn, or rather to learn in-depth.
>> I have minimal experienced with more common languages like Java, HTML,
>> and C++, but having the personality I do, felt compelled to shop
>> around a bit before choosing a first language to learn seriously on a
>> deep and intuitive level-- perhaps my odd notion of there being a
>> connection between a programmer and the first language s/he
>> understands on that high of a level. So after shopping around
>> thoroughly and picking up bits about on theoretical computer science
>> and the history of programming languages, I decided to pick up a Lisp;
>> I'm intrigued by the greater concept/idea behind the Lisp family of
>> languages.
>>
>> After a long while trying to figure out which of the Lisps would be a
>> good first choice, I stumbled across Clojure and immediately thought
>> it a brilliant idea, conceding of course that at my current level of
>> knowledge, I likely have no idea what a brilliant idea in computer
>> programming looks like. Regardless, it still feels brilliant.
>>
>> As I see it, among other features of the language, the idea of a Lisp
>> designed to be a capable choice for "real-world" code applications,
>> that is a Lisp which embodies the spirit of that family of languages
>> yet one which resolves many of the "practicality" complaints which
>> stand as hurdles on a Lisp's path to real-world use. For my situation,
>> that of a student who wants both a) to learn a first language I can
>> have a real, intellectual appreciation for and b) to begin the journey
>> to "expertise" in a language it would be practical to code web
>> applications in.
>>
>> So, Clojure programmers, am I wrong? Should I pass on Clojure in favor
>> of another langauge? Or learn Common Lisp or Scheme first, then try my
>> hand at Clojure? Am I mistaken for a different reason? Or perhaps
>> there are some criteria I should consider before diving in?
>>
>> Thanks in advance, and again for taking the time to read.
>> --Towle
>>
> --
> 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 

[ANN] data.xml 0.1.0-beta2

[Ryan Senior]

data.xml is a Clojure contrib library that parses and emits XML.

Github: https://github.com/clojure/data.xml
Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md

Information on updating the dependency is here
.

0.1.0-beta2 fixes some bugs found in the new namespaces feature of
0.1.0-beta1 and adds support for doctypes.

Thanks to Herwig Hochleitner and Christian Egli for their contributions!

-- 
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: lein repl and own functions

[Ryan Fowler]

you might find success with putting some injections in your
~/.lein/profiles.clj file.


{:user {:injections [(defn foo[] (println "foo"))]}}

On Thu, Jul 14, 2016 at 1:13 PM, Cecil Westerhof 
wrote:

> 2016-07-14 20:06 GMT+02:00 Timothy Baldridge :
>
>> There probably is, since the user.clj file can exist anywhere on the
>> classpath. So it should be possible to add an entry to profile.clj and add
>> a classpath folder to some global location.
>>
>> However, I'm not sure I would recommend this approach. IMO, it's better
>> to keep all the development tools for a project with the project itself.
>> With a local user.clj you can check that into git and have it the next time
>> you share/re-download the project
>> ​.
>>
>
> ​It is more for when I am doing lein repl, not for projects. I could make
> a dummy project and always do lein repl there, but I find that a bit of a
> bother. I will look into it.
>
>> ​
>>
>> On Thu, Jul 14, 2016 at 11:50 AM, Cecil Westerhof > > wrote:
>>
>>>
>>> 2016-07-14 18:18 GMT+02:00 Timothy Baldridge :
>>>
 Anything found in src/user.clj will be automatically loaded when lein
 repl starts.

>>>
>>> ​That works only for that directory. With my Bash script the functions
>>> where always included. Is there no way to do it always?​
>>>
>>>
>>>
 On Thu, Jul 14, 2016 at 7:52 AM, Cecil Westerhof <
 cldwester...@gmail.com> wrote:

> When I first worked with Clojure I used a Bash script with had:
> rlwrap java -cp "${CP}" clojure.main --init "${CLOJURE_INIT}"
> --repl
>
> In this way I had several of my own functions in the REPL. Now I
> started again with Clojure I understood I should use ‘lein repl’. Is there
> a method to get my own functions also included when using ‘lein repl’?
>

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

-- 
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: instrumenting clojure.core

[Ryan Fowler]

> On Jun 12, 2016, at 10:45 AM, Alex Miller <a...@puredanger.com> wrote:
> 
> Still much to be determined about this but I expect that specs for core will 
> be provided and maintained by us, because while there are a lot of obvious 
> specs in core, there are also a lot of far more subtle ones.

I think this is the right choice and I'm looking forward to seeing the details. 
My gut says that the better error messages alone are going to help 
significantly in convincing colleagues to work through learning Clojure.

Awesome work so far.

Ryan

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

instrumenting clojure.core

[Ryan Fowler]

Is there an effort to write specs for Clojure's core namespaces? Apologies
if this has already been addressed.

I've been tinkering with trivial (and probably wrong) fdefs on
clojure.core/map and clojure.core/identity. It seems that the spec
exception messages are way better than what we have now.

Code is here: https://gist.github.com/ryfow/69a64e966d48258dfa9dcb5aa74005eb


=
Before instrumenting clojure.core/map
=
Form: (into [] (map nil [1 2 3] [1 2 3]))
Exception Class:  java.lang.NullPointerException
Message:  nil

Form: (into [] (map 1 [1 2 3] [1 2 3]))
Exception Class:  java.lang.ClassCastException
Message:  java.lang.Long cannot be cast to clojure.lang.IFn

Form: (into [] (map identity 4))
Exception Class:  java.lang.IllegalArgumentException
Message:  Don't know how to create ISeq from: java.lang.Long

=
After instrumenting clojure.core/map
=
Form: (into [] (map nil [1 2 3] [1 2 3]))
Exception Class:  clojure.lang.ExceptionInfo
Message:  Call to #'clojure.core/map did not conform to spec:
In: [0] val: nil fails at: [:args :fn] predicate: ifn?
:clojure.spec/args  (nil [1 2 3] [1 2 3])


Form: (into [] (map 1 [1 2 3] [1 2 3]))
Exception Class:  clojure.lang.ExceptionInfo
Message:  Call to #'clojure.core/map did not conform to spec:
In: [0] val: 1 fails at: [:args :fn] predicate: ifn?
:clojure.spec/args  (1 [1 2 3] [1 2 3])


Form: (into [] (map identity 4))
Exception Class:  clojure.lang.ExceptionInfo
Message:  Call to #'clojure.core/map did not conform to spec:
In: [1] val: 4 fails at: [:args :seq] predicate: sequential?
:clojure.spec/args  (#object[clojure.core$identity 0x15a04efb
"clojure.core$identity@15a04efb"] 4)


=
Before instrumenting clojure.core/identity
=
Form: (into [] (map identity [1 2 3] [1 2 3]))
Exception Class:  clojure.lang.ArityException
Message:  Wrong number of args (2) passed to: core/identity

=
After instrumenting clojure.core/identity
=
Form: (into [] (map identity [1 2 3] [4 5 6]))
Exception Class:  clojure.lang.ExceptionInfo
Message:  Call to #'clojure.core/identity did not conform to spec:
In: [1] val: (4) fails at: [:args] predicate: (cat :one-argument identity),
 Extra input
:clojure.spec/args  (1 4)

-- 
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] HugSQL 0.4.0 release

[Ryan Fowler]

Great release, Curtis! I'm looking forward to cleaning up some of my
composition hacks.



On Mon, Feb 15, 2016 at 8:04 AM, Curtis Summers <
curtis.summ...@layerware.com> wrote:

> I'm happy to announce the 0.4.0 release of HugSQL.
>
> HugSQL is a Clojure library for embracing SQL in your projects.
>
> This release focuses on composability features.  Specifically, we now have 
> Clojure
> Expressions  providing the full
> power of Clojure within your SQL templates.  We also have Snippets
>  to create partial SQL statements
> that can be composed into larger queries.
>
> http://www.hugsql.org/
>
>
> Changes from 0.3.x to 0.4.0
>
>- Escape colon in SQL (issue #13
>)
>- def-db-fns-from-string & def-sql-fns-from-string (issue #16
>)
>- Added several functions that operate on individual SQL statements,
>which are useful at the REPL or for one-off composing.  (See Other
>Useful Functions )
>- Specify a function as private and other metadata (issue #17
>)
>- Better support for Returning Execute and Insert w/ Return Keys (See 
> Insert
>Usage ) (issues #8
> and #15
>)
>- Clojure Expressions 
>- Snippets 
>- Parameter Name Deep-Get 
>for drilling down into parameter data
>- Better docs & tests
>
> A big thank you to those of you who submitted suggestions and bugs during
> this cycle.  HugSQL is better because of your input.
>
> What is HugSQL?  HugSQL...
>
>
>-
>- is of the opinion that SQL is the right tool for the job when
>working with a relational database.
>- uses simple conventions in your SQL files to define (at compile
>time) database functions in your Clojure namespace, creating a clean
>separation of Clojure and SQL code.
>- supports runtime replacement of SQL Value Parameters (e.g., where id
>= :id), SQL Identifiers (i.e. table/column names), and SQL Keywords. You
>can also implement your own parameter types.
>- features Clojure Expressions and Snippets providing the full
>expressiveness of Clojure and the composability of partial SQL statements
>when constructing complex SQL queries.
>- has protocol-based adapters supporting multiple database libraries
>and ships with adapters for clojure.java.jdbc (default) and clojure.jdbc
>
> Thanks!
>
> Curtis Summers
>
> --
> 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: Scripting with Clojure / "slow" boot time

[Ryan Fowler]

On Tue, Feb 9, 2016 at 12:36 PM, Alex Miller  wrote:

> I'm doing some research on slow Clojure boot time and would be interested
> in collecting info about example use cases where it's been a problem for
> people.
>

​The following snippet helps me visualize load times. It might be helpful
to others.​ The output is a bit long, so I just added the code and
usage/output in a gist at https://gist.github.com/ryfow/4283b64b4dd205d610e8

​​(def ^:dynamic *indent* 0)
(alter-var-root
 #'clojure.core/load
 (fn [orig]
   (fn [& paths]
 (let [t (System/nanoTime)
   r (binding [*indent* (inc *indent*)]
   (apply orig paths))]
   (binding [*out* *err*]
 (println (apply str (repeat *indent* " ")) (/ (- (System/nanoTime)
t) 100.0)  paths)
 (flush))
   r

;; Require namespace in question here
(require 'clojure.core.async)

-- 
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: java.lang.NoSuchFieldError: __thunk__0__

[Ryan Fowler]

I just submitted http://dev.clojure.org/jira/browse/CLJ-1886

I was able to narrow down the problem space a little bit, but it's still
gnarly.

Ryan

On Mon, Jan 25, 2016 at 4:27 AM, Nicola Mometto <brobro...@gmail.com> wrote:

> Can you log this issue in clojure's JIRA?
>
> On Friday, January 15, 2016 at 11:21:17 PM UTC, Ryan Fowler wrote:
>>
>> I've got a head-scratcher.
>>
>> A combination of aot compiling, ring-jetty, slf4j-timbre, timbre and
>> core.async causes "java.lang.NoSuchFieldError: __thunk__0__"
>>
>> I've created a repo that reproduces the problem for me, but I'm out of my
>> depth at this point. Unfortunately I couldn't seem to get rid of any more
>> dependencies.
>>
>> https://github.com/ryfow/weird-aot
>>
>> If anyone is interested in digging around with me on this, please say so.
>> Here's some stack trace to entice you:
>>
>> Exception in thread "main" java.lang.NoSuchFieldError: __thunk__0__,
>> compiling:(/private/tmp/weird-aot/compile.clj:1:1)
>> at clojure.lang.Compiler.load(Compiler.java:7239)
>> at clojure.lang.Compiler.loadFile(Compiler.java:7165)
>> at clojure.main$load_script.invoke(main.clj:275)
>> at clojure.main$script_opt.invoke(main.clj:337)
>> at clojure.main$main.doInvoke(main.clj:421)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.lang.Var.invoke(Var.java:379)
>> at clojure.lang.AFn.applyToHelper(AFn.java:154)
>> at clojure.lang.Var.applyTo(Var.java:700)
>> at clojure.main.main(main.java:37)
>> Caused by: java.lang.NoSuchFieldError: __thunk__0__
>> at clojure.tools.analyzer.jvm.utils__init.load(Unknown Source)
>> at clojure.tools.analyzer.jvm.utils__init.(Unknown Source)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:340)
>> at clojure.lang.RT.classForName(RT.java:2154)
>> at clojure.lang.RT.classForName(RT.java:2163)
>> at clojure.lang.RT.loadClassForName(RT.java:2182)
>> at clojure.lang.RT.load(RT.java:436)
>> at clojure.lang.RT.load(RT.java:412)
>> at clojure.core$load$fn__5448.invoke(core.clj:5866)
>> at clojure.core$load.doInvoke(core.clj:5865)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.core$load_one.invoke(core.clj:5671)
>> at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
>> at clojure.core$load_lib.doInvoke(core.clj:5710)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invoke(core.clj:632)
>> at clojure.core$load_libs.doInvoke(core.clj:5749)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invoke(core.clj:632)
>> at clojure.core$require.doInvoke(core.clj:5832)
>> at clojure.lang.RestFn.invoke(RestFn.java:703)
>> at
>> clojure.tools.analyzer.jvm$loading__5340__auto1169.invoke(jvm.clj:9)
>> at clojure.tools.analyzer.jvm__init.load(Unknown Source)
>> at clojure.tools.analyzer.jvm__init.(Unknown Source)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:340)
>> at clojure.lang.RT.classForName(RT.java:2154)
>> at clojure.lang.RT.classForName(RT.java:2163)
>> at clojure.lang.RT.loadClassForName(RT.java:2182)
>> at clojure.lang.RT.load(RT.java:436)
>> at clojure.lang.RT.load(RT.java:412)
>> at clojure.core$load$fn__5448.invoke(core.clj:5866)
>> at clojure.core$load.doInvoke(core.clj:5865)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.core$load_one.invoke(core.clj:5671)
>> at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
>> at clojure.core$load_lib.doInvoke(core.clj:5710)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invoke(core.clj:632)
>> at clojure.core$load_libs.doInvoke(core.clj:5749)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invoke(core.clj:632)
>> at clojure.core$require.doInvoke(core.clj:5832)
>> at clojure.lang.RestFn.invoke(RestFn.java:805)
>> at
>> clojure.core.async.impl.ioc_macros$loading__5340__auto675.invoke(ioc_macros.clj:12)
>> at clojure.core.async.impl.ioc_macros__init.load(Unknown Source)
>> at clojure.core.async.impl.ioc_macros__init

java.lang.NoSuchFieldError: __thunk__0__

[Ryan Fowler]

I've got a head-scratcher.

A combination of aot compiling, ring-jetty, slf4j-timbre, timbre and
core.async causes "java.lang.NoSuchFieldError: __thunk__0__"

I've created a repo that reproduces the problem for me, but I'm out of my
depth at this point. Unfortunately I couldn't seem to get rid of any more
dependencies.

https://github.com/ryfow/weird-aot

If anyone is interested in digging around with me on this, please say so.
Here's some stack trace to entice you:

Exception in thread "main" java.lang.NoSuchFieldError: __thunk__0__,
compiling:(/private/tmp/weird-aot/compile.clj:1:1)
at clojure.lang.Compiler.load(Compiler.java:7239)
at clojure.lang.Compiler.loadFile(Compiler.java:7165)
at clojure.main$load_script.invoke(main.clj:275)
at clojure.main$script_opt.invoke(main.clj:337)
at clojure.main$main.doInvoke(main.clj:421)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NoSuchFieldError: __thunk__0__
at clojure.tools.analyzer.jvm.utils__init.load(Unknown Source)
at clojure.tools.analyzer.jvm.utils__init.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at clojure.lang.RT.classForName(RT.java:2154)
at clojure.lang.RT.classForName(RT.java:2163)
at clojure.lang.RT.loadClassForName(RT.java:2182)
at clojure.lang.RT.load(RT.java:436)
at clojure.lang.RT.load(RT.java:412)
at clojure.core$load$fn__5448.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$load_libs.doInvoke(core.clj:5749)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$require.doInvoke(core.clj:5832)
at clojure.lang.RestFn.invoke(RestFn.java:703)
at
clojure.tools.analyzer.jvm$loading__5340__auto1169.invoke(jvm.clj:9)
at clojure.tools.analyzer.jvm__init.load(Unknown Source)
at clojure.tools.analyzer.jvm__init.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at clojure.lang.RT.classForName(RT.java:2154)
at clojure.lang.RT.classForName(RT.java:2163)
at clojure.lang.RT.loadClassForName(RT.java:2182)
at clojure.lang.RT.load(RT.java:436)
at clojure.lang.RT.load(RT.java:412)
at clojure.core$load$fn__5448.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$load_libs.doInvoke(core.clj:5749)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$require.doInvoke(core.clj:5832)
at clojure.lang.RestFn.invoke(RestFn.java:805)
at
clojure.core.async.impl.ioc_macros$loading__5340__auto675.invoke(ioc_macros.clj:12)
at clojure.core.async.impl.ioc_macros__init.load(Unknown Source)
at clojure.core.async.impl.ioc_macros__init.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at clojure.lang.RT.classForName(RT.java:2154)
at clojure.lang.RT.classForName(RT.java:2163)
at clojure.lang.RT.loadClassForName(RT.java:2182)
at clojure.lang.RT.load(RT.java:436)
at clojure.lang.RT.load(RT.java:412)
at clojure.core$load$fn__5448.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$load_libs.doInvoke(core.clj:5749)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$require.doInvoke(core.clj:5832)
at 

Re: [Clojurescript] .getElementById returns NULL

[Ryan Fowler]

On Sun, Jan 3, 2016 at 8:04 PM, Nathan Smutz  wrote:

>
> (.log js/console (. js/document getElementById "test-content"))
>
>
​I suspect you need something more like this: ​
 (.log js/console (.getElementById js/document "test-content"))​

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

[ANN] data.xml 0.1.0-beta1

[Ryan Senior]

data.xml is a Clojure contrib library that parses and emits XML.

Github: https://github.com/clojure/data.xml
Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md

Information on updating the dependency is here
<https://github.com/clojure/data.xml#installation---beta>.

The key feature of 0.1.0-beta1 is full support for namespaces. XML
namespaces are complex and integrating that in with the data.xml library
required extensive changes to the internals of data.xml. Because of that,
we're releasing this as a beta to hopefully get some feedback on the
namespace support. Docs on using namespaces can be found in the README
<https://github.com/clojure/data.xml#namespace-support>.

Huge shout-out to Herwig Hochleitner for doing this work! Namespace support
was an often requested but difficult to implement feature. This fills a big
gap in what the library can support.

-Ryan

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

[ANN] Boot 2.5

[Ryan Neufeld]

Great upgrades! Keep up the good work. 

-- 
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 / H2 interop problem

[Ryan Waters]

I'm probably making a dumb mistake but I've been unable to import the
necessary classes to do transactions in H2 (MVMap interface).

I receive the following error at the repl:
---
user=> (in-ns 'asdf.core)
#object[clojure.lang.Namespace 0x46d3c2c8 "asdf.core"]
asdf.core=> (clojure.core/load-file "src/asdf/core.clj")

CompilerException java.lang.ClassNotFoundException:
org.h2.mvstore.db.TransactionStore.Transaction,
compiling:(/home/rwaters/asdf/src/asdf/core.clj:1:1)
asdf.core=>
---

Here's my project.clj:
(defproject asdf "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.7.0"]
 [com.h2database/h2 "1.4.189"]])

And here's core.clj:
(ns asdf.core
  (:import [org.h2.mvstore MVMap MVStore]
   [org.h2.mvstore.db TransactionStore]
   [org.h2.mvstore.db.TransactionStore Transaction]))


Notice how the imports before 'Transaction' are successful.  I can't seem
to import any class defined in org.h2.mvstore.db.TransactionStore:
https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/mvstore/db/TransactionStore.java

I was using the following test code as a point of reference:
https://github.com/h2database/h2database/blob/master/h2/src/test/org/h2/test/store/TestTransactionStore.java

Thank you,
Ryan

-- 
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 / H2 interop problem

[Ryan Waters]

That works!  I guess I haven't had to import an inner class before.

Thanks.

On Tue, Dec 8, 2015 at 9:09 AM, Alex Miller <a...@puredanger.com> wrote:

> You probably want TransactionStore$Transaction - that's how the jvm refers
> to inner classes.
>
>
> On Tuesday, December 8, 2015 at 9:06:08 AM UTC-6, Ryan Waters wrote:
>>
>> I'm probably making a dumb mistake but I've been unable to import the
>> necessary classes to do transactions in H2 (MVMap interface).
>>
>> I receive the following error at the repl:
>> ---
>> user=> (in-ns 'asdf.core)
>> #object[clojure.lang.Namespace 0x46d3c2c8 "asdf.core"]
>> asdf.core=> (clojure.core/load-file "src/asdf/core.clj")
>>
>> CompilerException java.lang.ClassNotFoundException:
>> org.h2.mvstore.db.TransactionStore.Transaction,
>> compiling:(/home/rwaters/asdf/src/asdf/core.clj:1:1)
>> asdf.core=>
>> ---
>>
>> Here's my project.clj:
>> (defproject asdf "0.1.0-SNAPSHOT"
>>   :dependencies [[org.clojure/clojure "1.7.0"]
>>  [com.h2database/h2 "1.4.189"]])
>>
>> And here's core.clj:
>> (ns asdf.core
>>   (:import [org.h2.mvstore MVMap MVStore]
>>[org.h2.mvstore.db TransactionStore]
>>[org.h2.mvstore.db.TransactionStore Transaction]))
>>
>>
>> Notice how the imports before 'Transaction' are successful.  I can't seem
>> to import any class defined in org.h2.mvstore.db.TransactionStore:
>>
>> https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/mvstore/db/TransactionStore.java
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fh2database%2Fh2database%2Fblob%2Fmaster%2Fh2%2Fsrc%2Fmain%2Forg%2Fh2%2Fmvstore%2Fdb%2FTransactionStore.java=D=1=AFQjCNGYr8ZgI5CvN_pau3GmKi_GAgI8Zg>
>>
>> I was using the following test code as a point of reference:
>>
>> https://github.com/h2database/h2database/blob/master/h2/src/test/org/h2/test/store/TestTransactionStore.java
>>
>> Thank you,
>> Ryan
>>
>> --
> 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.

HP Fortify Security Scanner and Clojure

[ryan medlin]

A customer requires that we scan our clojure projects with this tool:

http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/


They must get some meaningful report from this.

So I thought, well why don't I compile and then decompile the class files 
and then scan those to at least give them something.

However when I do that I get a TON of high security issues in multiple 
dependencies (ring, clojure.core)

Here is the most prevalent:

https://cwe.mitre.org/data/definitions/476.html

/* */ package nio;
/* */ 
/* */ import clojure.lang.AFunction;
/* */ import clojure.lang.IFn;
/* */ import clojure.lang.RT;
/* */ import clojure.lang.Var;
/* */ import java.nio.Buffer;
/* */ import java.nio.ByteBuffer;
/* */ 
/* */ public final class core$fn__1869 extends AFunction
/* */ {
/* 284 */   public static final Var const__0 = (Var)RT.var("clojure.core", 
"make-array");
/* */ 
/* */   public Object invoke(Object x)
/* */   {
/* 297 */ x = null; Object x = ((ByteBuffer)x).duplicate();
/* 298 */ Object array = ((IFn)const__0.getRawRoot()).invoke(Byte.TYPE, 
Integer.valueOf(((Buffer)x).remaining()));
/* 299 */ x = null; ((ByteBuffer)x).get((byte[])array); array = null; 
return array;
/* */   }
/* */ }


Decompiler:

http://jd.benow.ca/

Id the decompiler somehow generating code with these security issues and 
the actual bytecode does not have them maybe?


I have no idea how to move forward with this.  We have to "check a box" for 
them in corporate speak yet there is no clear path to run a dependable 
security scan against the codebase.


Yes I realize this is silly to demand running this tool.

Any other tools out there that might be able to scan Clojure code like this?



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

Announcing Clojure Remote — Clojure's first remote conference

[Ryan Neufeld]

Hey folks,

I'm pleased to announce Clojure will have its first remote conference
next February. Visit http://www.clojureremote.com to sign up for
announcements and help shape the conference.

-Ryan Neufeld

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

Recommendations for a schema-based data language for use in Hadoop?

[Ryan Schmitt]

Hi Clojure people,

I'm currently working on some problems in the big data space, and I'm more 
or less starting from scratch with the Hadoop ecosystem. I was looking at 
ways to work with data in Hadoop, and I realized that (because of how 
InputFormat splitting works) this is a use case where it's actually pretty 
important to use a data language with an external schema. This probably 
means ruling out Edn (for performance and space efficiency reasons) and 
Fressian (managing the Fressian caching domain seems like it could get 
complicated), which are my default solutions for everything, so now I'm 
back to the drawing board. I'd rather not use something braindead like JSON 
or CSV.

It seems like there are a few language-agnostic data languages that are 
popular in this space, such as:

* Thrift
* Protobuf
* Avro

But since the Clojure community has very high standards for data languages, 
as well as a number of different libraries that run code on Hadoop, I was 
wondering if anyone could provide a recommendation for a fast, extensible, 
and well-designed data language to use. (Recommendations of what to avoid 
are also welcome.)

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

Re: easy clojure.core.cache interaction

[Ryan Waters]

Also worth mentioning is that the implementation is many-thread friendly,
so using a cache:
1) won't be a single thread bottleneck (as in the case of using an
unadorned agent)
2) work is done on the calling threads

Granted, there's a race condition where two threads trying to find the same
thing at the exact same time will result in one thread doing the work and
the other thread waiting (and therefore you don't know which thread would
be doing the work) but this should be exceedingly rare and the work-or-wait
is happening where it should be anyway.

A previous version of the function had the work being done within the agent
which would have killed parallelized I/O for me (in a separate project).


On Thu, Jun 11, 2015 at 9:32 PM, Ryan Waters ryan.or...@gmail.com wrote:

 https://gist.github.com/rwat/4abcebcb4cfae956f382

 I've enjoyed using clojure.core.cache for caching results from time
 expensive operations involving I/O, etc. and feel like this is the sort of
 function that makes c.c.cache as simple to use as possible.  e.g. all it
 becomes is:

 (cache-interact c f k xs)

 where c is the cache (agent), f is the function that generates the value
 you're looking for if it isn't already cached, k is the key to search for
 and xs is optional extra arguments that are apply'ed to f.

 I could have used an agent or atom to store the cache but I don't know how
 much is 'too much' to perform within an atom reset!/swap!.  The operations
 performed within the critical section are all fast but there's a handful of
 them so I decided to err on the side of using an agent.

 Also, I apologize for some of the symbol names.  I don't make it a habit
 to name things in that style.

 I would appreciate any feedback / recommendations for improvement.

 Thank you,
 Ryan


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

easy clojure.core.cache interaction

[Ryan Waters]

https://gist.github.com/rwat/4abcebcb4cfae956f382

I've enjoyed using clojure.core.cache for caching results from time
expensive operations involving I/O, etc. and feel like this is the sort of
function that makes c.c.cache as simple to use as possible.  e.g. all it
becomes is:

(cache-interact c f k xs)

where c is the cache (agent), f is the function that generates the value
you're looking for if it isn't already cached, k is the key to search for
and xs is optional extra arguments that are apply'ed to f.

I could have used an agent or atom to store the cache but I don't know how
much is 'too much' to perform within an atom reset!/swap!.  The operations
performed within the critical section are all fast but there's a handful of
them so I decided to err on the side of using an agent.

Also, I apologize for some of the symbol names.  I don't make it a habit to
name things in that style.

I would appreciate any feedback / recommendations for improvement.

Thank you,
Ryan

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

RFC: Collider: Clojure's collections for Java developers

[Ryan Schmitt]

I've been developing a library that wraps Clojure's collections for use in 
Java 8 development:

https://github.com/rschmitt/collider

http://rschmitt.github.io/collider/javadoc/

Like my other major Java project, DynamicObject 
http://rschmitt.github.io/dynamic-object/, the goal here is two-fold:

(1) Bring the best of Clojure to Java developers (without ruining it), 
thereby making functional programming easier and more familiar
(2) Make the Clojure jar file as common as possible on people's classpaths, 
thereby lowering the bar to Clojure adoption

I'd appreciate any feedback people have on the design: how things are 
structured, named, documented, tested, and so on. I haven't decided to 
stabilize the library yet, so there's still time for breaking changes to be 
made.

Incidentally, the main project I'm aware of that's similar to this is clj-ds 
https://github.com/krukow/clj-ds, a standalone partial fork of Clojure. 
That also looks like a good approach to me, and fairly well-executed; it 
just has different tradeoffs. In particular, I like being able to target 
Java 8. I also like being able to wrap whatever version of Clojure is on 
the runtime classpath.

-- 
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: About transients no longer being safe in 1.7-alpha2

[Ryan Schmitt]

Will someone remember to update http://clojure.org/transients once 1.7.0 is 
released?

On Monday, November 3, 2014 at 1:57:58 AM UTC-8, Daniel Marjenburgh wrote:

 Hi,

 I just want to address this issue (CLJ-1498 
 http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in 
 1.7-alpha2 and I haven't seen a lot of discussion around it, even though 
 it's quite a big change.

 With this change the following code is possible:

 (let [m (transient {:a 0})
   futs (for [n (range 100)]
  (future (assoc! m :a (inc (:a m)]
   (mapv deref futs) ; wait until futures are done
   (persistent! m))


 The results will vary per run, where it used to throw 
 an IllegalAccessError: Transient used by non-owner thread.

 I understand the problems of not being able to have 1 go routine access a 
 transient, even though it would be safe, but this solution feels like it's 
 throwing out the baby with the bathwater. Basically, it's doing away with 
 what the following block on clojure.org http://clojure.org/transients
  says:

 *Transients enforce thread isolation**.* Because each result of a 
 transient operation shares (mutable) structure with the previous, it would 
 be very dangerous if more than one thread were to manipulate a transient at 
 once. In order to prevent this, transients will detect any (read or write) 
 use from a thread other than the one that created them and throw an 
 exception.

  


 This may not sound like a concurrency story, but single-thread isolation 
 is actually a very useful concurrency semantic. The whole point of using 
 transients is that doing so is safe, because their use is an isolated 
 implementation detail of otherwise functional code. Having that be enforced 
 means that some things that would normally be very hard to make safe with 
 ordinary mutable data structures become easy.


 I don't have a good solution for dealing with transients and logical 
 threads, but I would much prefer keeping the semantics of transients as 
 they are and maybe pass an option to transient to disable owner checking.


-- 
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: Edn, Fressian, Transit: which of these formats have a future?

[Ryan Schmitt]

Thanks for this breakdown; a lot of what you're saying about Transit is 
stuff I had inferred from prior announcements, but it's still enlightening 
to see an explicit comparison to Edn and Fressian.

On Sunday, March 15, 2015 at 7:51:55 PM UTC-7, Alex Miller wrote:

 Hi Ryan,

 To answer the big question, all of these data formats are in active use at 
 Cognitect and while I make no promises, I expect them all to be alive and 
 active for the knowable future. Each of them targets a different niche but 
 all of them share the qualities of transmitting extensible typed values.

 edn is the best choice for human-readable data. It is however, less 
 efficient to transmit and depends on writing a high-performance parser - 
 this is a high bar in some language environments. edn is most attractive 
 right now to Clojure users b/c of its proximity to Clojure itself. While it 
 has many advantages as an extensible readable literal data format, it's an 
 uphill battle to sell that against other data formats that already have 
 greater mindshare and tooling in other language communities.

 fressian is the highest performance option - it takes full advantage of a 
 number of compression tricks and has support for arbitrary user-extensible 
 caching. Again, it requires a fair amount of effort to write a fressian 
 library though so it's probably best for JVM-oriented endpoints right now. 
 By seeking greatest performance, fressian also makes tradeoffs that narrow 
 its range of use and interest group.

 transit is a pragmatic midpoint between these two. It focuses, like 
 fressian, on program-to-program data transmission however, the data can be 
 made readable (like edn) via the json-verbose mode. Like fressian, transit 
 contains caching capabilities but they are more limited and not 
 user-extensible.  transit is designed primarily to have the most 
 high-quality implementations per lowest effort - effectively shooting for 
 greater reach than either edn or fressian by lower the bar to 
 implementation. The bar is lowered by reusing high-performance parser for 
 either JSON or messagepack which exist in a large number of languages. Of 
 particular importance is leveraging the very high performance JSON parsers 
 available in JavaScript runtimes, making transit viable as a browser-side 
 endpoint for a fraction of the effort required to write a high performance 
 edn or fressian endpoint. As transit explicitly seeks reach and 
 portability, it is naturally the format with the broadest potential usage.

 Hopefully that lays out the landscape a bit more. With respect to support, 
 all of these formats are supported by Cognitect. Like everyone else, we're 
 managing priorities across a large number of projects. Filing issues is 
 great, voting on issues is great, reports like this are great. External 
 tooling is welcome (like pretty printers, etc). Because we use these 
 projects inside internal Cognitect projects and products, we do not 
 currently have a community contribution model for most of these as there 
 may be impacts that are not publicly visible. That could change in the 
 future.

 I am not an expert on everything you mention below but at a glance it 
 looks like on-point feedback and I will raise it with the appropriate 
 people and we can follow back here or on the relevant issues as needed.

 Thanks,
 Alex

 On Sunday, March 15, 2015 at 8:40:21 PM UTC-5, Ryan Schmitt wrote:

 I'm the author of dynamic-object 
 https://github.com/rschmitt/dynamic-object, an open source library 
 that makes Clojure's data modeling power available to Java programmers. 
 This includes features like serialization and deserialization. I'll copy 
 this small usage example from the README to give you a sense of how it 
 works:

 public interface Album extends DynamicObjectAlbum {
   @Key(:artist) String getArtist();
   @Key(:album)  String getAlbum();
   @Key(:tracks) int getTracks();
   @Key(:year)   int getYear();
 }


 String edn = {:artist \Meshuggah\, :album \Chaosphere\, :tracks 8, 
 :year 1998};Album album = DynamicObject.deserialize(edn, Album.class);
 album.getArtist(); // = Meshuggah


 dynamic-object has always been opinionated about using Edn as the primary 
 data language on the wire, for a number of reasons. For a long time, I also 
 thought about adding Fressian support to dynamic-object, and I've recently 
 done so on an experimental basis. (It looks like this 
 https://github.com/rschmitt/dynamic-object/blob/440ecd2f385d1cec80496ba7007bd0755023b19c/src/test/java/com/github/rschmitt/dynamicobject/FressianTest.java.)
  
 Some time after I initially released dynamic-object, Transit was also 
 released, with support for various encodings (JSON, JSON-Verbose, 
 MessagePack).

 In working (to different extents) with these data languages, I've had 
 some apprehensions about all of them.

- There is a lack of tooling available for Edn, such as validators 
and pretty-printers. I spent a while looking

Re: Edn, Fressian, Transit: which of these formats have a future?

[Ryan Schmitt]

Nippy looks like an interesting project; I wasn't familiar with it. 
However, it seems to be very Clojure-centric. Which is fine, at least for 
certain use cases; it just doesn't really occupy the part of the 
serialization format design space that I'm most interested in for 
dynamic-object.

On Monday, March 16, 2015 at 9:30:45 PM UTC-7, Lucas Bradstreet wrote:

 I have had a lot of success with nippy 
 https://github.com/ptaoussanis/nippy, which is quite well documented. We 
 had problems with fressian round tripping Clojure collections, as you've 
 described.

 It has a number of other features (compression, encryption) that I may end 
 up using. It has given attention to backwards compatibility, and there is a 
 mode to turn this backwards compatibility off if it is not required. 

 Lucas 



 On 16 Mar 2015, at 09:40, Ryan Schmitt rsch...@u.rochester.edu 
 javascript: wrote:

 I'm the author of dynamic-object 
 https://github.com/rschmitt/dynamic-object, an open source library that 
 makes Clojure's data modeling power available to Java programmers. This 
 includes features like serialization and deserialization. I'll copy this 
 small usage example from the README to give you a sense of how it works:

 public interface Album extends DynamicObjectAlbum {
   @Key(:artist) String getArtist();
   @Key(:album)  String getAlbum();
   @Key(:tracks) int getTracks();
   @Key(:year)   int getYear();
 }


 String edn = {:artist \Meshuggah\, :album \Chaosphere\, :tracks 8, :year 
 1998};Album album = DynamicObject.deserialize(edn, Album.class);
 album.getArtist(); // = Meshuggah


 dynamic-object has always been opinionated about using Edn as the primary 
 data language on the wire, for a number of reasons. For a long time, I also 
 thought about adding Fressian support to dynamic-object, and I've recently 
 done so on an experimental basis. (It looks like this 
 https://github.com/rschmitt/dynamic-object/blob/440ecd2f385d1cec80496ba7007bd0755023b19c/src/test/java/com/github/rschmitt/dynamicobject/FressianTest.java.)
  
 Some time after I initially released dynamic-object, Transit was also 
 released, with support for various encodings (JSON, JSON-Verbose, 
 MessagePack).

 In working (to different extents) with these data languages, I've had some 
 apprehensions about all of them.

- There is a lack of tooling available for Edn, such as validators and 
pretty-printers. I spent a while looking for an Edn equivalent of python 
-mjson.tool and never found one. Clojure's built-in pprint function does 
not work out-of-the-box to pretty print arbitrary values, and also appears 
to handle some data structures, such as records, incorrectly. (pprint 
 omits 
reader tags when printing records.) pprint's underlying implementation, 
cl-format, is extremely powerful and could almost certainly be used to 
build a validating Edn pretty-printer, but it would have an unacceptably 
long startup time.
- There is a lack of high-quality Edn implementations for different 
languages. Because the Edn spec is not very formal or complete, there 
 seems 
to be some uncertainty regarding what constitutes an Edn implementation in 
the first place. For instance, clojure.edn parses the Ratio type as a 
builtin, even though it is mentioned nowhere in the spec. (Issue 
https://github.com/edn-format/edn/issues/64.) There are also 
oddities such as the recommended C++ implementation 
https://github.com/shaunxcode/edn-cpp describing itself as 
experimental.
- Fressian's reference Java implementation is almost totally 
undocumented. This is a problem, because I'm writing a library that 
 targets 
Java developers; they won't be going through the Clojure bindings (which 
are decently documented). Fressian's source code is outstanding, but it's 
still not documentation.
- Due to the lack of documentation, it's not clear which parts of 
Fressian are actually stable. Stuart Halloway's data.fressian talk 
 included 
some parentheticals about the extension points being subject to change, 
which so far they haven't, but that might only be because of the following 
point...
- Fressian does not seem to have gotten any attention since the 
initial launch. People have submitted GitHub issues 
https://github.com/Datomic/fressian/issues, including one 
surprisingly high-quality bug report, but they have all been ignored. The 
JIRA is mostly tumbleweeds.
- The Clojure bindings for Fressian, namely data.fressian, are 
essentially incomplete. With the exception of maps, Clojure collection 
types do not round trip, and in at least one case (vectors) that is 
 because 
of a blocking issue http://dev.clojure.org/jira/browse/DFRS-1 in the 
underlying Fressian implementation.
- There are no documented best practices for the use of Fressian or 
some of its more advanced features like chunking. It is not clear

Edn, Fressian, Transit: which of these formats have a future?

[Ryan Schmitt]

I'm the author of dynamic-object 
https://github.com/rschmitt/dynamic-object, an open source library that 
makes Clojure's data modeling power available to Java programmers. This 
includes features like serialization and deserialization. I'll copy this 
small usage example from the README to give you a sense of how it works:

public interface Album extends DynamicObjectAlbum {
  @Key(:artist) String getArtist();
  @Key(:album)  String getAlbum();
  @Key(:tracks) int getTracks();
  @Key(:year)   int getYear();
}


String edn = {:artist \Meshuggah\, :album \Chaosphere\, :tracks 8, :year 
1998};Album album = DynamicObject.deserialize(edn, Album.class);
album.getArtist(); // = Meshuggah


dynamic-object has always been opinionated about using Edn as the primary 
data language on the wire, for a number of reasons. For a long time, I also 
thought about adding Fressian support to dynamic-object, and I've recently 
done so on an experimental basis. (It looks like this 
https://github.com/rschmitt/dynamic-object/blob/440ecd2f385d1cec80496ba7007bd0755023b19c/src/test/java/com/github/rschmitt/dynamicobject/FressianTest.java.)
 
Some time after I initially released dynamic-object, Transit was also 
released, with support for various encodings (JSON, JSON-Verbose, 
MessagePack).

In working (to different extents) with these data languages, I've had some 
apprehensions about all of them.

   - There is a lack of tooling available for Edn, such as validators and 
   pretty-printers. I spent a while looking for an Edn equivalent of python 
   -mjson.tool and never found one. Clojure's built-in pprint function does 
   not work out-of-the-box to pretty print arbitrary values, and also appears 
   to handle some data structures, such as records, incorrectly. (pprint omits 
   reader tags when printing records.) pprint's underlying implementation, 
   cl-format, is extremely powerful and could almost certainly be used to 
   build a validating Edn pretty-printer, but it would have an unacceptably 
   long startup time.
   - There is a lack of high-quality Edn implementations for different 
   languages. Because the Edn spec is not very formal or complete, there seems 
   to be some uncertainty regarding what constitutes an Edn implementation in 
   the first place. For instance, clojure.edn parses the Ratio type as a 
   builtin, even though it is mentioned nowhere in the spec. (Issue 
   https://github.com/edn-format/edn/issues/64.) There are also oddities 
   such as the recommended C++ implementation 
   https://github.com/shaunxcode/edn-cpp describing itself as 
   experimental.
   - Fressian's reference Java implementation is almost totally 
   undocumented. This is a problem, because I'm writing a library that targets 
   Java developers; they won't be going through the Clojure bindings (which 
   are decently documented). Fressian's source code is outstanding, but it's 
   still not documentation.
   - Due to the lack of documentation, it's not clear which parts of 
   Fressian are actually stable. Stuart Halloway's data.fressian talk included 
   some parentheticals about the extension points being subject to change, 
   which so far they haven't, but that might only be because of the following 
   point...
   - Fressian does not seem to have gotten any attention since the initial 
   launch. People have submitted GitHub issues 
   https://github.com/Datomic/fressian/issues, including one surprisingly 
   high-quality bug report, but they have all been ignored. The JIRA is mostly 
   tumbleweeds.
   - The Clojure bindings for Fressian, namely data.fressian, are 
   essentially incomplete. With the exception of maps, Clojure collection 
   types do not round trip, and in at least one case (vectors) that is because 
   of a blocking issue http://dev.clojure.org/jira/browse/DFRS-1 in the 
   underlying Fressian implementation.
   - There are no documented best practices for the use of Fressian or some 
   of its more advanced features like chunking. It is not clear how to read 
   and write Fressian in a way that facilitates (for instance) ranged reads 
   from the middle of a resource. It is not clear when checksums should be 
   used and how they should be validated. It is not clear whether tags should 
   be namespaced, or how. The only namespaced tag in data.fressian is for 
   IRecord; none of the other type tags are namespaced. It's not clear whether 
   this is due to bugwards compatibility.
   - Transit is advertised 
   https://github.com/cognitect/transit-format#implementations as a 
   work-in-progress. This is the main reason I haven't seriously considered 
   adding Transit support to dynamic-object.
   - However, what happens when Transit is stabilized (if that ever 
   happens)? Since Transit offers a msgpack encoding, will Fressian then be 
   irrelevant (except for legacy use cases)? There's a FUD aspect here--I like 
   Fressian and I want dynamic-object to support it, but I don't want to back 
   

problems using leiningen on Ubuntu 14.10 (and solved)

[Ryan Waters]

What follows is an issue I was having with leiningen on a couple new linux
installations.

This writeup is only tangentially related to Clojure but I wanted to email
it out there for others who may run into this same issue.  The following is
relevant for Debian (Jessie) and Ubuntu Server 14.10 as of today.  I forget
which openjdk I was using on debian but on ubuntu it's openjdk-8-jdk.  I'm
also using Leiningen 2.5.1 which I installed via the lein bash script
method.

PROBLEM:

I would get the following when running 'lein deps' within one of my project
directories:
---
Could not transfer artifact lein-cljsbuild:lein-cljsbuild:pom:1.0.3 from/to
central (https://repo1.maven.org/maven2/): java.lang.RuntimeException:
Unexpected error: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment
variable.
---

Some searches suggested I might have an empty java keystore which turned
out to be the case:
---
keytool -list -keystore
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/security/cacerts -v
Enter keystore password:

...

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 0 entries
---

SOLUTION:

An explanation of the root problem with a resolution can be found here:
https://justus.berlin/2015/01/connection-problems-with-ssltls-peers-in-java-on-ubuntu-server-14-12-with-fix/

In short, it appears the keystore generation script that should run after a
jdk ubuntu+debian package is installed doesn't end up running when it needs
to, so one must:

---
root@gl:~# rm /etc/ssl/certs/java/cacerts
root@gl:~# /var/lib/dpkg/info/ca-certificates-java.postinst configure
---

Again, all credit to 'justus.berlin' for this fix.

- - -

Sidenote - I had an unrelated problem with wget and curl connecting to
/any/ SSL website under Debian Jessie, even with 'ca-certificates' package
installed.  That's just lame.

Anyway, I hope this helps save somebody some time and/or bumps up google
search results for the link above.

Thanks,
Ryan

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

[ANN] chic-text 0.2.0 - Helpful functions for formatting console output

[Ryan McGowan]

chic-text http://www.ryanmcg.com/chic-text/ is a library of functions 
that formats strings for console output.  It allows content to be specified 
in columns (sequence of strings) or functions of a collection (one function 
per column, one item in the collection per row). It even defines a summary-fn 
for integration 
http://www.ryanmcg.com/chic-text/#clojure.tools.cli-integration with 
clojure.tools.cli https://github.com/clojure/tools.cli.

I am using this in incise http://www.ryanmcg.com/incise/. This library 
was spun off of that project, so yeah, it is small and simple, but I 
figured others could benefit from it.

I'd be happy for any feedback/contribution. Thanks!

   - Main - http://www.ryanmcg.com/chic-text/
   - API - http://www.ryanmcg.com/chic-text/api/
   - Source - https://github.com/RyanMcG/chic-text

-- 
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: State of Simulation Testing Survey - 2015

[Ryan Neufeld]

Hey again,

I just wanted to let everyone know that I've published the results of the 
2015 Simulation Testing survey. You can find them here:

http://www.rkn.io/2015/03/07/state-of-sim-testing-results/

-Ryan

On Tuesday, February 3, 2015 at 8:40:14 PM UTC-6, Ryan Neufeld wrote:

 Hey folks!
  
 As you probably know, there's always lots of new and exciting developments 
 in Clojure-land. One, more recent technique that has me really excited has 
 been *Simulation Testing*. I've used Simulant to implement simulation 
 tests on a few projects this last year with great success, and I'm really 
 curious to hear about if/how others are using the technique.
  
 To that end, I've put together a survey on sim-testing–*The State of 
 Simulation Testing*–that I hope can become an annual fixture both inside 
 and outside of the Clojure community. Once the ballots have closed on 
 February 20th, I'll tally and report upon the results on my blog.
  
 If you've considered, implemented or even out-right rejected simulation 
 testing, I'm curious to hear more from you:
  
 http://bit.ly/state-of-sim-testing-2015
  
 Thanks for your time,
 Ryan Neufeld 
  

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

ANN: fixturex, A library for creating and using fixtures

[Ryan McGowan]

Fixturex is a library of functions and macros for using and creating 
fixtures. It is particularly useful when namespace level fixtures are not 
specific enough.

I'd be happy for any feedback/contribution. Thanks!

   - Main - http://www.ryanmcg.com/fixturex/
   - API - http://www.ryanmcg.com/fixturex/api/
   - Source - https://github.com/RyanMcG/fixturex


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

State of Simulation Testing Survey - 2015

[Ryan Neufeld]

Hey folks!

As you probably know, there's always lots of new and exciting
developments in Clojure-land. One, more recent technique that has me
really excited has been *Simulation Testing*. I've used Simulant to
implement simulation tests on a few projects this last year with great
success, and I'm really curious to hear about if/how others are using
the technique.

To that end, I've put together a survey on sim-testing–*The State of
Simulation Testing*–that I hope can become an annual fixture both inside
and outside of the Clojure community. Once the ballots have closed on
February 20th, I'll tally and report upon the results on my blog.

If you've considered, implemented or even out-right rejected simulation
testing, I'm curious to hear more from you:

http://bit.ly/state-of-sim-testing-2015

Thanks for your time, Ryan Neufeld

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

vertigo question

[Ryan Waters]

In working with vertigo I've found the need to parameterize the struct
field I wish to examine.  Unfortunately vertigo doesn't seem to like vars
in its macros.  For example:

- - - -
;; vs is 'vertigo.structs and vc is 'vertigo.core

(vs/def-typed-struct mystruct :ints (vs/array vs/uint32 10))
(def ^:mystruct vert (vc/marshal-seq mystruct [{:ints (range 10)}]))

(vc/get-in vert [0 :ints 1])
1  ;; works, returns 1

(let [^clojure.lang.Keyword x :ints] (vc/get-in vert [0 x 1]))
CompilerException java.lang.IllegalArgumentException: 'x' is assumed to be
numeric, which isn't accepted by mystruct,
compiling:(form-init1370835477311955482.clj:1:38)


- - - -
I originally ran into this when using vc/over within vc/doreduce.  I'm
using vertigo 0.1.3.

Thanks!
Ryan

-- 
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: Pedestal comparison to Sente/HTTPKit

[Ryan Neufeld]

Glad to hear you enjoyed the video.

Anyone taking a look at Pedestal should feel free to hit us up on our 
Google Group (https://groups.google.com/forum/#!forum/pedestal-users) 
should they have any questions.

On Monday, January 26, 2015 at 4:00:56 PM UTC-6, Mike Haney wrote:

 Forgot to mention, as far as raw performance/latency of HTTP servers go, 
 you can find a comparison here: 
 https://github.com/ptaoussanis/clojure-web-server-benchmarks 
 https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fptaoussanis%2Fclojure-web-server-benchmarkssa=Dsntz=1usg=AFQjCNHgYwFHUpltoLIYp5dxQY8M988a_A

-- 
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: #db/id[:db.part/db] throws an exception

[Ryan Neufeld]

There are still some errors in there. My bad. Someone came in with a pull 
request and I'll test it works. 

Generally all the code should have worked originally--I tested every 
recipe--but I may have missed one or two. 

-Ryan

 On Dec 17, 2014, at 1:02 AM, edw...@kenworthy.info wrote:
 
 I've tried that already but then Clojure complains about there being an 
 uneven number of elements in a map.
 
 Curious though: did the original code ever actually work? Is it something 
 that was deprecated?
 
 Have to say I am happy if that's the case, the original seemed unnecessarily 
 arcane where as a standard function call is obvious.
 
 On Tuesday, December 16, 2014 11:42:10 PM UTC, Ryan Neufeld wrote:
 Yeah, we shouldn't be telling you to use reader literals like that. 
 Preferred is a call to (d/tempid ...). I'm updating the code now 
 (https://github.com/clojure-cookbook/clojure-cookbook/blob/master/06_databases/6-11_schema.asciidoc)
 
 On Tuesday, December 16, 2014 2:01:00 PM UTC-6, edw...@kenworthy.info wrote:
 I'm following the Clojure Cookbook recipe for defining a schema in datomic.
 
 One of the forms is: #db/id[:db.part/db] but this generates an exception 
 clojure.lang.ExceptionInfo: No reader function for tag id :: {:column 25, 
 :line 27, :type :reader-exception}
 
 Can anyone offer any insight?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/Ki6WWN3n2JU/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: #db/id[:db.part/db] throws an exception

[Ryan Neufeld]

Yeah, we shouldn't be telling you to use reader literals like that. 
Preferred is a call to (d/tempid ...). I'm updating the code now 
(https://github.com/clojure-cookbook/clojure-cookbook/blob/master/06_databases/6-11_schema.asciidoc)

On Tuesday, December 16, 2014 2:01:00 PM UTC-6, edw...@kenworthy.info wrote:

 I'm following the Clojure Cookbook recipe for defining a schema in datomic.

 One of the forms is: #db/id[:db.part/db] but this generates an exception 
 clojure.lang.ExceptionInfo: 
 No reader function for tag id :: {:column 25, :line 27, :type 
 :reader-exception}

 Can anyone offer any insight?


-- 
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.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?

[Ryan Schmitt]

 It turns out there are some subtle issues which can cause incorrect 
 behavior were clojure.core/read to blindly wrap a PushbackReader around its 
 argument:
 https://groups.google.com/d/msg/clojure/_tuypjr2M_A/W1EcEbMUg_cJ


 That sounds like magic. The user wrapping a PushbackReader around a 
 BufferedReader doesn't cause problems, but the library function doing so 
 does? Why would where the wrapping takes place make a difference? Is the 
 *only* problem the rare case of reading more than one object from the same 
 stream? A docstring warning to wrap manually *in those cases* would 
 suffice, then, no?


It's not a question of *where* the wrapping takes place, it's a question of 
who holds a reference to the wrapped Reader and what their expectations 
are. The reason that clojure.core/read cannot wrap its argument in a 
PushbackReader is that it doesn't know who else holds a reference to that 
argument. Let's say I have a BufferedReader that initially contains the 
following two Edn elements:

string1string2

Let's also say that I have a version of clojure.edn/read that accepts a 
BufferedReader and (unsoundly) wraps it in a PushbackReader. After the 
first read call, the PushbackReader clojure.core/read created will contain 
the following:

string2

But the BufferedReader might only contain the following:

string2

Since the PushbackReader created by clojure.core/read will be garbage 
collected after the function returns, it will be impossible to parse any 
more data correctly out of this reader. And this won't even break all of 
the time--it will only *occasionally* break, in the cases where a 
non-whitespace element gets pushed back into the PushbackReader and then 
garbage collected.

As for the motivation behind using a PushbackReader at all: 
http://en.wikipedia.org/wiki/Parsing#Lookahead

-- 
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.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?

[Ryan Schmitt]

Can anyone come up with an example of a case where the call to 
clojure.edn/read leaves an unread character in the PushbackReader? Looking 
briefly at the EdnReader source, I only see cases where the pushback buffer 
is used internally, in order to save a character that is later consumed 
during the same call to read. If this is true, and if this behavior could 
be guaranteed for all time and for all possible versions of Edn, then it 
would in fact be possible--although not necessarily worth it--for 
clojure.edn/read to accept a BufferedReader, or even an arbitrary Reader, 
as input.

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

[ANN] Clara Rules 0.7.0 Released

[Ryan Brush]

I just pushed release 0.7.0 of Clara, a forward-chaining production rule 
engine in Clojure.  Beyond some bug fixes and performance improvements, the 
most significant new feature is described at [1]: support for any variable 
bound in a constraint is visible to arbitrary expressions in subsequent 
constraints. 

I also have created a separate Google group for Clara at [2]. Clara is now 
being used significantly at my day job and there have been enough external 
questions that a separate space makes sense.

The rate of significant changes to Clara's core is slowing down, but from 
my obviously biased perspective I think that's because Clara is maturing 
into a good alternative to other JVM-based production rule engines. I 
suspect most members of this group would rather write Clojure than in a DSL 
specific to some rule engine...which is what Clara aims to do. 

Best,
Ryan

[1]
*https://github.com/rbrush/clara-rules/issues/66*
[2]
*https://groups.google.com/forum/#!forum/clara-rules* 

-- 
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] Cryogen - Static Site Generator

[Ryan McGowan]

Pretty cool. I'll have to compare it with incise 
http://www.ryanmcg.com/incise/ in detail later.

On Thursday, November 13, 2014 1:27:44 PM UTC-8, Carmen La wrote:

 Check out my first project! As the title says, it's a static site 
 generator :)

 Blog post: http://carmenla.me/blog/posts/12-11-2014-post1.html
 Github repo: https://github.com/lacarmen/cryogen

 Any feedback is appreciated :)


-- 
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] async-sockets - work with sockets using core.async channels

[Ryan Waters]

I was just starting to use Sente [1] (which relies on httpkit [2]) and this
conversation is a real eye opener.  Unless a person uses a library that
supports backpressure, as mentioned earlier, your
transport-concern-made-opaque-because-of-core-async must become an
application-level concern.  The far-side of the communication would have to
respond with an application level acknowledgement for local sends and the
local side would need to not send data unless acks were received for
previously sent data.

E.g. this could be implemented with core.async by using a pair of channels
(instead of a single channel) for all 'sends' where one channel is used for
data while the other channel waits for acknowledgement of put data (a
'control' channel).  This would have the unfortunate side effect of hurting
throughput.  A better system would be to allow for a certain number of
unacknowledged sends before backing off.  Of course, now a person is
implementing what was created for TCP at the level of their application.

Christophe's approach means you at least wouldn't have to do the above,
replacing it instead with a per backend implementation.  I hope somebody
else is able to explain it better.

Looking forward to an Aleph rewrite!!

- - -
[1] https://github.com/ptaoussanis/sente
[2] https://github.com/http-kit/http-kit

On Sat, Oct 11, 2014 at 8:01 PM, Julian juliangam...@gmail.com wrote:

 Hi Zach,

 Thanks for the clarity of thought that went into this post.

 Perhaps it is obvious to everyone but me, but I saw this post by
 Christophe Grande yesterday that appears to address these concerns:
 Back-pressurized interop for core.async
 https://twitter.com/cgrand/status/520566182194450432
 https://gist.github.com/cgrand/767673242b7f7c27f35a

 I'm interested to hear if this solves your problem or is about something
 else.

 Cheers
 Julian


 On Wednesday, 8 October 2014 17:00:02 UTC+11, Zach Tellman wrote:

 The reason the thread-per-connection approach is nice is because it
 correctly propagates backpressure.  If we're copying data from a source to
 a sink (let's say reading it in from the network and writing to a file),
 it's possible that the production of data may outstrip the consumption.  If
 this happens, we need to make sure the producer slows down, or we risk
 running out of memory.  In Java, the producer is typically connected to the
 consumer via a blocking queue, and if the queue fills up the producer can't
 send anything more to the consumer.  A Java socket is one such queue, and
 if it fills up it will exert backpressure via TCP.  This will work no
 matter how many queues or other mechanisms separate the producer and
 consumer.

 However, every attempt I've seen to marry core.async to an async network
 stack has been fundamentally broken, in that it doesn't do this.  Often,
 they'll just use 'put!', which works fine until the channel's queue fills
 up, and 1024 pending puts are accumulated, and finally the channel throws
 an exception.  Alternately, they'll use a blocking put on the channel,
 which means that any backpressure will also extend to whatever other
 connections are sharing that thread or the thread pool.  Note that the
 software that uses core.async in this way may work flawlessly in a wide
 variety of cases, but there's still an intractable failure mode lying in
 wait.

 In some cases, such as http-kit's websocket mechanism, there's no way to
 even exert backpressure (you register a callback, and have no way to
 indicate in your callback that you can't handle more messages).  This means
 that any attempt to use http-kit in conjunction with core.async will be
 subtly but fundamentally broken.  Arguably, even without core.async in the
 equation it's broken.  This is not a good state of affairs.  I'll admit
 that it took me a few failures in production to realize how important
 correct handling of backpressure is, but this isn't something that our
 ecosystem can afford to ignore, especially as Clojure is used for
 larger-scale projects.

 I will note that I am working on a solution to this, in the form of the
 upcoming Aleph release [1].  This will model every network connection via
 streams that can trivially be converted into core.async channels [2], and
 which exert backpressure over TCP wherever necessary without requiring a
 thread per connection.  A formal beta should be available in the near
 future (it's already handling billions of requests a day in production
 without issue).

 Zach

 [1] https://github.com/ztellman/aleph/tree/0.4.0
 [2] https://github.com/ztellman/manifold



 On Tuesday, October 7, 2014 1:36:16 PM UTC-7, adrian...@mail.yu.edu
 wrote:

 It's not about 'safety' (depending on what that means in this context),
 but as Zach pointed out, if you aren't careful about backpressure you can
 run into performance bottlenecks with unrestrained async IO operations
 because although they let you code as if you could handle an unlimited
 amount of connections, obviously that isn't true. 

[ANN] Stray - An alternative routing library for Compojure

[Kelker Ryan]

Repo: https://github.com/runexec/stray StrayStray is an alternative routing library for Compojure;; Leiningen Dependency

[stray "1.01"]

(ns example
  (:require [stray.core :refer [router]]))

(def routes
  {:public {:index-page {:http/path "/"
 :http/method :GET
 :http/req :namespace.core/example-handler}
:user-page {:http/path "/user/:id"
:http/method :GET
:http/req :namespace.core/handler}}
   :dev {:new-welcome-page {:http/path "/welcome/:user"
:http/method :GET
:http/req :project.users/new-welcome}}})

(defn example-handler [req]
  (str "req: " (keys req)))

;; lein ring servers in project.clj
;; :ring {:handler namespace.core/public-app}

(def public-app (router routes :public))

(def dev-app (router routes :dev))

TutorialCreate a Projectlein new example-project
Add to project.clj:dependencies [[stray "1.01"]]
:plugins [[lein-ring "0.8.12"]]
:ring {:handler example-project.core/public-app}
Refer router in src/example_project/core.clj(ns example-project.core
  (:require [stray.core :refer [router]]))
Define routes(def routes
  {:public {:hello-page {:http/path "/hello/:name"
 :http/method :GET
 :http/req :example-project.core/hello-handler}}
   {:dev {:hello-page {:http/path "/hello/:name"
   :http/method :GET
   :http/req :example-project.core/hello-handler}}}
   {:other {:hello-page {:http/path "/hello/:name"
 :http/method :GET
 :http/req :example-project.core/hello-handler)
Define handlers(defn hello-handler [req]
  "I got a ring/compojure request!!!")

Define applications(def public-app (router routes :public))
Save and runlein ring server




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

[ANN] PossibleDB 0.1 - Serverside DataScript

[Kelker Ryan]

PossibleDBPossibleDB is a Datomic Database Server clone built with DataScript, RethinkDB, Clojure, ClojureScript, and NodeJS.warning: highly alphaYou can see PossibleDB in action @ http://vimeo.com/107237345PossibleDB Server1) git clone https://github.com/runexec/PossibleDB2) cd PossibleDB/possibledb/3) npm install rethinkdb4) chmod +x possibledb.js5) ./possibledb.js {optional port}Clojure Client(:require [possibledb-client.core :as db])

(db/connect! [host port])

(db/q [^:String db-name query-coll])

(db/transact! [^:String db-name data-coll])

(db/create-db! [^:String db-name])
Leiningen[possibledb-client "1.0"]Gradlecompile "possibledb-client:possibledb-client:1.0"Mavendependency
groupIdpossibledb-client/groupId
artifactIdpossibledb-client/artifactId
version1.0/version
/dependency
DocumentationPossibleDB is the bridge between DataScript and RethinkDB. Please refer to https://github.com/tonsky/datascript



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

[ANN] Strap 0.1.0

[Kelker Ryan]

Strap is a faster Clojure project builder

https://github.com/runexec/strap

$ time strap.js my-project om compojure prismatic/om-tools secretary

https://clojars.org/repo/prismatic/om-tools/maven-metadata.xml
https://clojars.org/repo/om/om/maven-metadata.xml
https://clojars.org/repo/compojure/compojure/maven-metadata.xml
https://clojars.org/repo/secretary/secretary/maven-metadata.xml

real0m1.204s
user0m0.497s
sys 0m0.053s

$ cat my-project/project.clj

(defproject my-project 0.1.0-SNAPSHOT
  :description FIXME: write this!
  :url http://example.com/FIXME;

  :dependencies [[org.clojure/clojure 1.6.0]
 [org.clojure/core.async 0.1.338.0-5c5012-alpha]
 [prismatic/om-tools 0.3.3]
 [om 0.7.1]
 [compojure 1.1.9]
 [secretary 1.2.1]]

  :plugins [[lein-cljsbuild 1.0.4-SNAPSHOT]]

  :source-paths [src]

  :cljsbuild {
  :builds [{:id strap
:source-paths [src]
:compiler {:output-to strap.js
   :output-dir out
   :target :nodejs
   :optimizations :simple}}]})

$ ls -R my-project/

my-project/:
src/  project.clj

my-project/src:
my_project/

my-project/src/my_project:
core.clj

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

Re: How do you typecast and insert a Postgres enum value using Clojure JDBC?

[Ryan Neufeld]

For posterity, you should create a PGobject object. See instructions how in 
http://naiquevin.github.io/using-postgresqls-enum-types-with-korma.html

On Wednesday, February 6, 2013 2:59:14 AM UTC-6, James Thornton wrote:

 For example, here is a product table in PostgreSQL with status as an enum:

 create type product_status as enum ('InStock', 'OutOfStock');

 create table product (
 pidint primary key default nextval('product_pid_seq'),
 skutext not null unique,
 name   text not null,
 descriptiontext not null,
 quantity   int not null,
 cost   numeric(10,2) not null,
 price  numeric(10,2) not null,
 weight numeric(10,2),
 status product_status not null);

 Typical Clojure code to insert a product would be:

 (def prod-12345 {:sku 12345
  :name My Product
  :description yada yada yada
  :quantity 100
  :cost 42.00
  :price 59.00
  :weight 0.3
  :status InStock})
 (sql/with-connection db-spec
(sql/insert-record :product product-12345))

 However, status is an enum so you can't insert it as a normal string 
 without casting it to an enum:

 'InStock'::product_status

 I know you can do it with a prepared statement, such as:

 INSERT INTO product (name, status) VALUES (?, ?::product_status)

 But is there a way to do it without using a prepared statement?

 From StackOverflow: 

 http://stackoverflow.com/questions/14719207/how-do-you-insert-a-postgres-enum-value-using-clojure-jdbc

 - James


-- 
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] Clara 0.6.0

[Ryan Brush]

Hey Alan, 

The Storm example was an experiment showing we could distribute the 
engine's working memory between processes, but the needs for it haven't 
materialized as much as other use cases, so I haven't been maintaining or 
growing that part of the system.

This may change in the future. If there's interest in improved Storm 
integration that's something we can kick around, and I would like to get 
back to that at some point. But for the time being I've focused on making 
the core of Clara a solid basis for expert systems.

As a side note, I always like to hear ideas on Clara's direction, and of 
course contributions are welcome. 

-Ryan

On Monday, July 28, 2014 11:37:36 AM UTC-5, Alan Moore wrote:

 Awesome - thanks for the update!

 Does the storm example work with the new version?

 Alan



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

[ANN] Clara 0.6.0

[Ryan Brush]

Clara, a rule engine in pure Clojure and ClojureScript,  has released 
version 0.6.0. The headliners are:

   - Durability. There are no facilities to store and reload session state. 
   I consider this experimental since the format may change non-passively 
   between releases, but it can be used under those constraints. See  
   *https://github.com/rbrush/clara-rules/wiki/Durability* for details.
   - Performance. Several significant performance optimizations were made. 
   This was the basis for this post: 
   *http://www.toomuchcode.org/blog/2014/06/16/micro-bench-macro-optimize/*
   - Better explainability of why rules fired. See 
   *https://github.com/rbrush/clara-rules/wiki/Inspection*
   - Upgraded to Clojure 1.6.0 (no changes required for the upgrade)
   - Details and other references can be found in the change log: 
   *https://github.com/rbrush/clara-rules/blob/master/CHANGELOG.md*

I’m not quite ready to promise there will never be another breaking change, 
but at this point Clara’s core and APIs are stable and I think it’s a 
viable alternative to other rule engines on the JVM. There are a couple 
other features I want to add to the core, but I plan on spending more time 
on some simple tooling to make rules in Clojure easier to create, explore, 
and understand.

Also, please feel free to post any questions or suggestions for Clara here. 
Thanks!

-Ryan

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

Puppet Labs is hiring Clojure developers

[Ryan Senior]

Hi, everyone! Puppet Labs [0][1] builds open source and commercial systems 
automation tools. We're in every major linux distribution, and we're 
managing literally millions of systems at a wide variety of shops (from 
Google to GitHub to Spotify to CERN to SpaceX to NYSE ...). Even if you've 
not heard of us specifically, chances are extremely high that you've used a 
service powered by our tech under-the-hood. For a sampling of the kinds of 
things we're into, you can look at the videos from last year's Puppetconf 
[2].

We have a number of commercial and open source projects written in Clojure, 
and have plans for a bunch more. We recently released Trapperkeeper [3] 
[4], a Clojure-based framework for long-running applications and services. 
We also develop PuppetDB [5], a centralized storage system for our 
automation tools (see our talk from Clojure/West 2013 [6]). Our clojure 
code is deployed in tens of thousands of datacenters all over the planet, 
helping ops folk sleep better at night. :)

We're looking for senior engineers that can help us refine our existing 
stuff and build awesome new stuff!

* you should know Clojure (duh)
* you should care about reliability and performance
* big plus if you can point us at some clojure code you've written
* big plus if you are also conversant in Ruby
* big plus if you're familiar with Puppet or similar automation tools
* as much of our work is open source, big plus if you know your way around 
github, pull requests, travis-ci, etc.

While Puppet Labs is based out of Portland, OR (USA), our team is 
distributed. We don't care where in the US you live. 

To apply, visit our job posting [7]. If you have more questions, feel free 
to email me: ryan.senior _at_ puppetlabs.com or talk with me at Lambda Jam 
[8], where I’m speaking [9] about how we’re using Prismatic Schema. Thanks!

[0] http://puppetlabs.com
[1] http://en.wikipedia.org/wiki/Puppet_Labs
[2] http://puppetlabs.com/resources/puppetconf-2013
[3] https://github.com/puppetlabs/trapperkeeper
[4] 
http://puppetlabs.com/blog/clojure-nerds-puppet-labs-application-services
[5] https://github.com/puppetlabs/puppetdb
[6] http://www.infoq.com/presentations/PuppetDB
[7] http://links.puppetlabs.com/clj-job
[8] http://www.lambdajam.com/
[9] https://a.confui.com/-iEH2gTI7

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

[ANN] Grimoire 0.2.0

[Ryan Neufeld]

This is fantastic! Thanks for all the hard work you've put in. 

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

[ANN] Initial release of dynamic-object: a library to bring Clojure data (and metadata) to Java

[Ryan Schmitt]

I've published the first releases of dynamic-object to Maven. 
dynamic-object (https://github.com/rschmitt/dynamic-object) is an effort to 
bring the flexibility and power of Clojure data and the Edn data language 
to Java developers in the most direct way possible. This library is 
intended to serve Neal Ford's Master Plan for Clojure Enterprise Mindshare 
Domination https://www.youtube.com/watch?v=2WLgzCkhN2g, which is based on 
the observation that dominant technologies often got their start by 
sneaking into the enterprise in a grassroots way. Rich Hickey stated 
https://www.youtube.com/watch?feature=player_detailpagev=I5iNUtrYQSM#t=3613 
that he would like Clojure data to be one of those roots, and 
dynamic-object is all about making that happen.

I'd love to hear any feedback or questions from anyone who finds this idea 
interesting. I'm sure a lot of us have one foot in the Clojure world and 
one foot in the Java world, and I'm sure the Clojure foot is happier than 
the Java foot. My hope is that by building bridges from Clojure to Java, we 
can take some of the pain out of Java development (in the short term) and 
make Clojure's ideas, and its jar file 
https://www.youtube.com/watch?feature=player_detailpagev=2WLgzCkhN2g#t=1226, 
much more widespread (in the long term).

-- 
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: Style-question: self-named attribute getters?

[Ryan Schmitt]

Most Clojure libraries I've seen only give you a handful of namespaces. I 
would expect a moderately large Clojure library to expose, say, half a 
dozen at most. Remember that Clojure has no concept of star imports, even 
for Java classes, and imports will generally be qualified somehow (e.g. 
clojure.set :as set), so exposing a large number of fragmented namespaces 
will make things seriously inconvenient for your users.

On Wednesday, June 25, 2014 6:34:50 PM UTC-7, Mark P wrote:

 I've only recently started real clojure development, so very much still 
 learning what styles work and what don't.  I have a question about naming 
 attribute getters...

 Suppose I want to model fruit entities.  I will use a hash-map to 
 represent the data for each such entity, and will defn a make function to 
 construct fruit instances.  I will put make and any other fruit-related 
 functions within a new namespace myprog.fruit.

 Because my data representation is a map, strictly speaking I don't need 
 any attribute getter functions.  Because I could simply use the attribute 
 keywords in the map as my getter functions, eg (:color fru).  But I will 
 create actual getter functions within my namespace anyway, for a few 
 reasons.

1. It will signal to any users of my fruit library, which attributes 
are official and are expected to be used / supported, versus attributes 
which are more of an implementation detail.
2. Some attributes will simply be (defn color [fru] (:color fru)), 
whereas others are less direct, eg (defn red? [fru] (= :red fru)) or 
another eg (defn packingvol [{:keys [size]}] (* size size size)).  
3. Down the track I can change my data representation, and just 
reimplement the getter functions.  Users of my fruit library who have 
 stuck 
to my getter functions interface will not need to change a thing.

 This approach seems okay to me so far, though I am open to critiques and 
 alternative suggestions.  But one issue has come to mind... leading to the 
 question of this post...

 At the end of 2. above, I have defined a local let symbol size as part 
 of the map destructuring.  But it so happens I have already defined a size 
 getter, namely (defn size [fru] (:size fru)).  So within the definition of 
 packingvol my size getter is masked by the local symbol size.  Now I'm 
 not sure this masking causes much harm... I don't actually need to use the 
 size getter here, and if I really needed it I could always use 
 myprog.fruit/size...  But something still makes me feel uncomfortable 
 about it, maybe because this masking could end up happening a lot within my 
 fruit.clj source code file.

 Now I could just switch to a new naming convention for my getters, ie 
 color-get, red?-get, size-get, packingvol-get etc.  But I'm not 
 sure I like the extra verbosity.  And for users of my fruit library - who 
 will be working in a different namespace - this problem mostly goes away as 
 they will probably be namespace-qualifying access to my getters.

 Is using self-named attribute getters a good idea?

 Thanks,

 Mark.



-- 
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] Initial release of dynamic-object: a library to bring Clojure data (and metadata) to Java

[Ryan Schmitt]

I am aware of edn-java; it has a very different scope than this library. 
edn-java is basically a pure Java implementation of an Edn parser, and it 
exposes the parsed data as mutable, untyped Java collections (e.g. an Edn 
map becomes a java.util.HashMap?, ?). I wanted to bring Clojure's entire 
data *philosophy *to Java: not just Edn, but also immutable persistent 
collections, metadata, and generic manipulation using functions like 
clojure.data/diff and clojure.core/merge.

At the same time, I wanted a way to put a typed facade in front of Clojure 
data, in order to prevent a lot of awkward unidiomatic downcasting; I also 
wanted a way for users to be able to validate, as a separate step, that 
these types are correct, instead of just getting a ClassCastException or 
NullPointerException further down the line. So you might say that I'm not 
just trying to replace JSON; I'm also trying to replace JavaBeans (or 
POJO's, or DTO's, or whatever you call them). Edn is a lot better than 
JSON, but Clojure data is *unbelievably *superior to traditional JavaBeans.

You raise an interesting point about the relationship between tree-shaking 
and security. There is one place in the library where I'm using eval; I 
need it for defmethod, because the only alternative I'm aware of is 
MultiFn, which is an implementation detail. Were it not for that, it would 
be nice if dynamic-object could ship with a stripped-down version of 
Clojure that could avoid the entire security discussion.

On Thursday, June 26, 2014 9:16:17 AM UTC-7, Mikera wrote:

 I think this is a great idea and I certainly support this effort.

 One thought that springs to mind is that it would be nice to be able to 
 use the Clojure interfaces and  data structures in Java *without* pulling 
 in the whole of Clojure as a dependency. Clojure is a bit of a heavyweight 
 dependency (with non-trivial load time impact?) and it would certainly be 
 easier to sneak the data structures into a Java project if it were a 
 slimmer dependency. This would also avoid concerns about security / risk of 
 eval functionality etc.

 Also - I assume you are familiar with edn-java (
 https://github.com/bpsm/edn-java)? It would be good to make sure your 
 work is aligned with this

 On Thursday, 26 June 2014 07:08:50 UTC+1, Ryan Schmitt wrote:

 I've published the first releases of dynamic-object to Maven. 
 dynamic-object (https://github.com/rschmitt/dynamic-object) is an effort 
 to bring the flexibility and power of Clojure data and the Edn data 
 language to Java developers in the most direct way possible. This library 
 is intended to serve Neal Ford's Master Plan for Clojure Enterprise 
 Mindshare Domination https://www.youtube.com/watch?v=2WLgzCkhN2g, 
 which is based on the observation that dominant technologies often got 
 their start by sneaking into the enterprise in a grassroots way. Rich 
 Hickey stated 
 https://www.youtube.com/watch?feature=player_detailpagev=I5iNUtrYQSM#t=3613
  
 that he would like Clojure data to be one of those roots, and 
 dynamic-object is all about making that happen.

 I'd love to hear any feedback or questions from anyone who finds this 
 idea interesting. I'm sure a lot of us have one foot in the Clojure world 
 and one foot in the Java world, and I'm sure the Clojure foot is happier 
 than the Java foot. My hope is that by building bridges from Clojure to 
 Java, we can take some of the pain out of Java development (in the short 
 term) and make Clojure's ideas, and its jar file 
 https://www.youtube.com/watch?feature=player_detailpagev=2WLgzCkhN2g#t=1226,
  
 much more widespread (in the long term).



-- 
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: Style-question: self-named attribute getters?

[Ryan Schmitt]

In object-oriented programming, encapsulation is always and everywhere 
regarded as a highly significant design virtue, but the Clojure people have 
a bit of a different assessment, particularly when it comes to information. 
In one talk, Rich Hickey pointed out that encapsulation is for hiding 
implementation details, but information doesn't *have* an implementation; 
there are no innards to encapsulate *unless you add them*. Stuart Halloway 
gave one talk where he made a brilliant point about how abstraction is 
valuable for *commands*, because then it limits what you have to know, but 
it's not valuable for *queries*, because then the abstraction (i.e. the 
custom accessors that encapsulate your data) only limits what you can 
perceive.

And of course, there's Alan Perlis's old saw that it is better to have a 
hundred functions operate on one data structure than to have ten functions 
operate on ten data structures--that is to say, by using generic data 
structures (e.g. maps) to directly represent information in your domain, 
you can reuse all of the generic functions that operate on those data 
structures, whereas encapsulated data screws your clients because it 
renders all of their generic collections libraries useless. (This is one of 
the ways in which OOP has failed to deliver on its promise of pervasive 
code reuse.)

Some of Rich Hickey's talks that touch on the subject:

http://www.infoq.com/presentations/Value-Values
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

As for your particular example, I recommend looking at defrecord, which 
generates a data structure that behaves like a map (it can be perceived and 
manipulated generically), as well as various constructors and readers and 
so forth for that type. defrecord also lets you specify protocols for your 
data type. See:

http://clojure.org/datatypes

Also be sure to check out Prismatic's survey of Clojure's choices for doing 
object-like things:

https://github.com/Prismatic/eng-practices/blob/master/clojure/20130926-data-representation.md#data-types

On Wednesday, June 25, 2014 6:34:50 PM UTC-7, Mark P wrote:

 I've only recently started real clojure development, so very much still 
 learning what styles work and what don't.  I have a question about naming 
 attribute getters...

 Suppose I want to model fruit entities.  I will use a hash-map to 
 represent the data for each such entity, and will defn a make function to 
 construct fruit instances.  I will put make and any other fruit-related 
 functions within a new namespace myprog.fruit.

 Because my data representation is a map, strictly speaking I don't need 
 any attribute getter functions.  Because I could simply use the attribute 
 keywords in the map as my getter functions, eg (:color fru).  But I will 
 create actual getter functions within my namespace anyway, for a few 
 reasons.

1. It will signal to any users of my fruit library, which attributes 
are official and are expected to be used / supported, versus attributes 
which are more of an implementation detail.
2. Some attributes will simply be (defn color [fru] (:color fru)), 
whereas others are less direct, eg (defn red? [fru] (= :red fru)) or 
another eg (defn packingvol [{:keys [size]}] (* size size size)).  
3. Down the track I can change my data representation, and just 
reimplement the getter functions.  Users of my fruit library who have 
 stuck 
to my getter functions interface will not need to change a thing.

 This approach seems okay to me so far, though I am open to critiques and 
 alternative suggestions.  But one issue has come to mind... leading to the 
 question of this post...

 At the end of 2. above, I have defined a local let symbol size as part 
 of the map destructuring.  But it so happens I have already defined a size 
 getter, namely (defn size [fru] (:size fru)).  So within the definition of 
 packingvol my size getter is masked by the local symbol size.  Now I'm 
 not sure this masking causes much harm... I don't actually need to use the 
 size getter here, and if I really needed it I could always use 
 myprog.fruit/size...  But something still makes me feel uncomfortable 
 about it, maybe because this masking could end up happening a lot within my 
 fruit.clj source code file.

 Now I could just switch to a new naming convention for my getters, ie 
 color-get, red?-get, size-get, packingvol-get etc.  But I'm not 
 sure I like the extra verbosity.  And for users of my fruit library - who 
 will be working in a different namespace - this problem mostly goes away as 
 they will probably be namespace-qualifying access to my getters.

 Is using self-named attribute getters a good idea?

 Thanks,

 Mark.



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

Re: Style-question: self-named attribute getters?

[Ryan Schmitt]

The question of how to specify the shape of your data is an important 
one, and I think one of the contributions of Clojure is the way it isolates 
that problem, instead of complecting it with object-oriented design or 
static type checking. You might look at Prismatic Schema, a library that 
offers declarative data description and validation without the baggage of 
OOP or the complexity of static typing:

https://www.youtube.com/watch?v=o_jtwIs2Ot8
https://github.com/Prismatic/schema

There's also core.typed, an optional static type system for Clojure that 
allows you to specify your data's shape as a type of map, called a 
heterogeneous map:

https://github.com/clojure/core.typed/wiki/Types#heterogeneous-maps

There's also my own dynamic-object, which is an attempt to bring these 
ideas to Java development without ruining them:

https://github.com/rschmitt/dynamic-object (see in particular 
https://github.com/rschmitt/dynamic-object#schema-validation)

You can implement all the convenience functions you want; as long as you're 
not using them to encapsulate or abstract away your data, they're probably 
harmless. A function like 'red?' doesn't seem like it's adding too much 
value, but a less trivial function could easily be worth providing as part 
of your API. Just because your clients *can* use generic collections 
operations doesn't necessarily mean that they should *have to*.

I'm not sure I understand your question about namespacing. Creating a 
namespace for your code is basically mandatory--are you asking about the 
ideal granularity of namespaces? Prismatic has another eng-practices 
document dealing with namespace organization:

https://github.com/Prismatic/eng-practices/blob/master/clojure/20130927-ns-organization.md

On Wednesday, June 25, 2014 8:37:26 PM UTC-7, Mark P wrote:

 Thanks Ryan, Mike and James for your comments and info.  Ryan I will 
 follow up the links you posted.

 In the meantime, a request for some clarification...

 I have read / watched clojure stuff along these lines... ie that data 
 hiding (in an immutable data context) is bad.  I thought my approach was 
 taking this into account.  Ie, I am actually using a hash-map for my fruit 
 instance data (rather than say closures for true data hiding) and this is 
 not hidden - it is freely accessible to users of my fruit library.  Users 
 can choose to use getter functions or use more direct map access 
 techniques.  The getter functions sort of provide self documentation about 
 interface intent, without restricting/forcing users to be limited to this 
 if the interface has weaknesses.  I guess I was trying to take the best 
 from both approaches.  But maybe you are telling me that even this 
 watered-down-encapsulation is not good?

 Ryan you are suggesting that maybe defrecord is the way to go.  I haven't 
 read about that yet, so I will look into that.

 But just suppose I wanted to stick with using raw hash-maps for my data. 
  Would you suggest that instead of my current approach, I should...

- Not implement any getter function when a keyword accessor will do. 
 Eg don't implement (defn color [fru] (:color fru)), just let library 
 users 
do (:color fru) themselves.
- Do still implement other getters, eg (defn red? [fru] (= :red fru)) 
and eg (defn packingvol [{:keys [size]}] (* size size size)).
- What about make?  Do I still implement a fruit constructor 
function, or do I leave it to users to use usual hash-map constructors? 
 (And if I should not implement a fruit constructor, how do I indicate to 
users the shape that a fruit hash-map should take?  Do I just document 
 this 
in comments?)
- Was I right to construct a new namespace for my fruit-related data 
and functions?

 Thanks,

 Mark.

 On Thursday, 26 June 2014 11:42:01 UTC+9:30, Ryan Schmitt wrote:

 In object-oriented programming, encapsulation is always and everywhere 
 regarded as a highly significant design virtue, but the Clojure people have 
 a bit of a different assessment, particularly when it comes to information. 
 In one talk, Rich Hickey pointed out that encapsulation is for hiding 
 implementation details, but information doesn't *have* an 
 implementation; there are no innards to encapsulate *unless you add them*. 
 Stuart Halloway gave one talk where he made a brilliant point about how 
 abstraction is valuable for *commands*, because then it limits what you 
 have to know, but it's not valuable for *queries*, because then the 
 abstraction (i.e. the custom accessors that encapsulate your data) only 
 limits what you can perceive.

 And of course, there's Alan Perlis's old saw that it is better to have a 
 hundred functions operate on one data structure than to have ten functions 
 operate on ten data structures--that is to say, by using generic data 
 structures (e.g. maps) to directly represent information in your domain, 
 you can reuse all of the generic functions that operate on those data

Help with basic macros

[Ryan Yogan]

Hi, I am trying to understand macros and I am having trouble with the 
basics, I am working through some koans and I am stuck, an explanation not 
just a solution would be amazing.

I would like to create a macro that can provide the following

(if-else ( 5 2))
= nil

(if-else ( 5 2) :then 'sure)
= sure

(if-else ( 5 2) :else 'no-way :then 'sure)
= sure

(if-else ( 5 2) :else 'no-way :then
  (println 'this-is-random) 'sure)
= this is random
sure

I know this is not efficient and do would make more sense, but I am trying 
to understand a use case for this and how to accomplish this.

Thank you!

-- 
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: Understanding when compilation occurs - for function producing functions

[Ryan Schmitt]

 Okay. Functions as values. Go look at the IFn interface, 

 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java.
  



 Thanks for the link - this helps!  When the clojure compiler generates a 
 class type that conforms to this interface, does it generate a .java file 
 which is then compiled using the java compiler?  I am guessing not.  I am 
 guessing that clojure knows how to generate a byte code version of a class 
 type directly.


The Clojure compiler generates .class files and Java bytecode directly, 
using the ASM http://asm.ow2.org/index.html library. Note that Clojure 
code is always compiled to Java bytecode, even in the REPL; Clojure is 
never directly interpreted. There are some good resources on how Clojure 
compilation works:

http://clojure.org/compilation
http://www.deepbluelambda.org/programming/clojure/how-clojure-works-a-simple-namespace
 
(namespaces also get compiled to Java classes, which is a bit less 
intuitive)
http://stackoverflow.com/questions/3123662/compiling-clojure (if you want 
to play around with invoking the Clojure compiler directly)

-- 
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: RFC: dynamic-object, a library for working with Clojure data in Java

[Ryan Schmitt]

This has proven to be somewhat complicated, but I've finally pushed a 
release of 0.1 to the staging repository. (I also added support for 
validating nested collections.) If all goes well, it should be available 
via Maven Central within a day or two.

On Monday, June 16, 2014 7:09:07 PM UTC-7, Atamert Ölçgen wrote:

 Absolutely. I don't believe consumers (of open source projects) are 
 entitled to anything anyway. I think it's a cool project and I hope it gets 
 the attention.



 On Tue, Jun 17, 2014 at 1:02 AM, Ryan Schmitt rsch...@u.rochester.edu 
 javascript: wrote:

 I'll look into it, I'm just sort of reluctant because I don't think 
 people take beta warnings seriously. In the meantime, if all you want is a 
 .jar file, you can just clone the git repo and run the Gradle build. You 
 should also be able to open up the repo as an IntelliJ project. (Let me 
 know if you can't, by the way--I've tested both approaches on multiple 
 operating systems with the intention that they should *just work*.)


 On Sunday, June 15, 2014 8:38:25 PM UTC-7, Atamert Ölçgen wrote:

 Perhaps if you make it easily available (making an early release) more 
 people would use it and you might get more feedback then. You can always 
 change interfaces, conventions etc.



 On Mon, Jun 16, 2014 at 3:09 AM, Ryan Schmitt rsch...@u.rochester.edu 
 wrote:

 Set, Util, and List are actually just interfaces, and Clojure's 
 collections implement them. The destructive operations throw 
 UnsupportedOperationException of course, which is actually explicitly 
 allowed by the spec:

  * pThe destructive methods contained in this interface, that is, 
 the
  * methods that modify the map on which they operate, are specified to 
 throw
  * ttUnsupportedOperationException/tt if this map does not support 
 the
  * operation.  If this is the case, these methods may, but are not 
 required
  * to, throw an ttUnsupportedOperationException/tt if the 
 invocation would
  * have no effect on the map.  For example, invoking the {@link 
 #putAll(Map)}
  * method on an unmodifiable map may, but is not required to, throw the
  * exception if the map whose mappings are to be superimposed is 
 empty.

 This conversion is recursive; for instance, a ListListInteger will 
 be internally stored as an immutable persistent ListListLong. However, 
 this behavior is not documented, partially because it hasn't been tested 
 to 
 my satisfaction yet and partially because validation does not currently 
 work with nested collections.

 The library isn't available on Maven yet; I want more feedback on the 
 design before I make a commitment to the current interfaces, conventions, 
 and behaviors.


 On Sunday, June 15, 2014 7:56:30 PM UTC-7, Atamert Ölçgen wrote:

 Really cool library, thanks for sharing. I was initially irked by the 
 use of (mutable) Java collection interfaces, but then I read that they're 
 made immutable when passed to the builder. I assume they're recursively 
 converted to persistent representations.

 It reminded me of Guava's immutable classes a little. (Not persistent, 
 no serialization)

 Is it available via maven?




 On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rsch...@u.rochester.edu
  wrote:

  I've been developing a library to bring Clojure data to Java 
 developers. By Clojure data I mean both Clojure's persistent immutable 
 data structures *and* serialized Edn data. I wanted access to 
 Clojure's capabilities without having to use Clojure-Java interop 
 directly or make use of downcasting. Obviously it would be preferable to 
 just use Clojure, but this is intended as the next best thing for 
 developers who for whatever reason are currently stuck with Java.

 https://github.com/rschmitt/dynamic-object

 I'm looking for feedback on the design and implementation. The README 
 is reasonably thorough, and the tests 
 https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
  
 contain hundreds of usage examples. If anyone has any questions, I'll be 
 glad to field them here.
  
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient 
 with your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, 
 send an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  
  -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo

Re: RFC: dynamic-object, a library for working with Clojure data in Java

[Ryan Schmitt]

I'll look into it, I'm just sort of reluctant because I don't think people 
take beta warnings seriously. In the meantime, if all you want is a .jar 
file, you can just clone the git repo and run the Gradle build. You should 
also be able to open up the repo as an IntelliJ project. (Let me know if 
you can't, by the way--I've tested both approaches on multiple operating 
systems with the intention that they should *just work*.)

On Sunday, June 15, 2014 8:38:25 PM UTC-7, Atamert Ölçgen wrote:

 Perhaps if you make it easily available (making an early release) more 
 people would use it and you might get more feedback then. You can always 
 change interfaces, conventions etc.



 On Mon, Jun 16, 2014 at 3:09 AM, Ryan Schmitt rsch...@u.rochester.edu 
 javascript: wrote:

 Set, Util, and List are actually just interfaces, and Clojure's 
 collections implement them. The destructive operations throw 
 UnsupportedOperationException of course, which is actually explicitly 
 allowed by the spec:

  * pThe destructive methods contained in this interface, that is, the
  * methods that modify the map on which they operate, are specified to 
 throw
  * ttUnsupportedOperationException/tt if this map does not support the
  * operation.  If this is the case, these methods may, but are not 
 required
  * to, throw an ttUnsupportedOperationException/tt if the invocation 
 would
  * have no effect on the map.  For example, invoking the {@link 
 #putAll(Map)}
  * method on an unmodifiable map may, but is not required to, throw the
  * exception if the map whose mappings are to be superimposed is empty.

 This conversion is recursive; for instance, a ListListInteger will be 
 internally stored as an immutable persistent ListListLong. However, 
 this behavior is not documented, partially because it hasn't been tested to 
 my satisfaction yet and partially because validation does not currently 
 work with nested collections.

 The library isn't available on Maven yet; I want more feedback on the 
 design before I make a commitment to the current interfaces, conventions, 
 and behaviors.


 On Sunday, June 15, 2014 7:56:30 PM UTC-7, Atamert Ölçgen wrote:

 Really cool library, thanks for sharing. I was initially irked by the 
 use of (mutable) Java collection interfaces, but then I read that they're 
 made immutable when passed to the builder. I assume they're recursively 
 converted to persistent representations.

 It reminded me of Guava's immutable classes a little. (Not persistent, 
 no serialization)

 Is it available via maven?




 On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rsch...@u.rochester.edu 
 wrote:

  I've been developing a library to bring Clojure data to Java 
 developers. By Clojure data I mean both Clojure's persistent immutable 
 data structures *and* serialized Edn data. I wanted access to 
 Clojure's capabilities without having to use Clojure-Java interop 
 directly or make use of downcasting. Obviously it would be preferable to 
 just use Clojure, but this is intended as the next best thing for 
 developers who for whatever reason are currently stuck with Java.

 https://github.com/rschmitt/dynamic-object

 I'm looking for feedback on the design and implementation. The README 
 is reasonably thorough, and the tests 
 https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
  
 contain hundreds of usage examples. If anyone has any questions, I'll be 
 glad to field them here.
  
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  
  -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout

RFC: dynamic-object, a library for working with Clojure data in Java

[Ryan Schmitt]

I've been developing a library to bring Clojure data to Java developers. By 
Clojure data I mean both Clojure's persistent immutable data structures 
*and* serialized Edn data. I wanted access to Clojure's capabilities 
without having to use Clojure-Java interop directly or make use of 
downcasting. Obviously it would be preferable to just use Clojure, but this 
is intended as the next best thing for developers who for whatever reason 
are currently stuck with Java.

https://github.com/rschmitt/dynamic-object

I'm looking for feedback on the design and implementation. The README is 
reasonably thorough, and the tests 
https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
 
contain hundreds of usage examples. If anyone has any questions, I'll be 
glad to field them here.

-- 
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: RFC: dynamic-object, a library for working with Clojure data in Java

[Ryan Schmitt]

Set, Util, and List are actually just interfaces, and Clojure's collections 
implement them. The destructive operations throw 
UnsupportedOperationException of course, which is actually explicitly 
allowed by the spec:

 * pThe destructive methods contained in this interface, that is, the
 * methods that modify the map on which they operate, are specified to throw
 * ttUnsupportedOperationException/tt if this map does not support the
 * operation.  If this is the case, these methods may, but are not required
 * to, throw an ttUnsupportedOperationException/tt if the invocation 
would
 * have no effect on the map.  For example, invoking the {@link 
#putAll(Map)}
 * method on an unmodifiable map may, but is not required to, throw the
 * exception if the map whose mappings are to be superimposed is empty.

This conversion is recursive; for instance, a ListListInteger will be 
internally stored as an immutable persistent ListListLong. However, 
this behavior is not documented, partially because it hasn't been tested to 
my satisfaction yet and partially because validation does not currently 
work with nested collections.

The library isn't available on Maven yet; I want more feedback on the 
design before I make a commitment to the current interfaces, conventions, 
and behaviors.

On Sunday, June 15, 2014 7:56:30 PM UTC-7, Atamert Ölçgen wrote:

 Really cool library, thanks for sharing. I was initially irked by the use 
 of (mutable) Java collection interfaces, but then I read that they're made 
 immutable when passed to the builder. I assume they're recursively 
 converted to persistent representations.

 It reminded me of Guava's immutable classes a little. (Not persistent, no 
 serialization)

 Is it available via maven?




 On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rsch...@u.rochester.edu 
 javascript: wrote:

 I've been developing a library to bring Clojure data to Java developers. 
 By Clojure data I mean both Clojure's persistent immutable data 
 structures *and* serialized Edn data. I wanted access to Clojure's 
 capabilities without having to use Clojure-Java interop directly or make 
 use of downcasting. Obviously it would be preferable to just use Clojure, 
 but this is intended as the next best thing for developers who for whatever 
 reason are currently stuck with Java.

 https://github.com/rschmitt/dynamic-object

 I'm looking for feedback on the design and implementation. The README is 
 reasonably thorough, and the tests 
 https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
  
 contain hundreds of usage examples. If anyone has any questions, I'll be 
 glad to field them here.
  
 -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  

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

Re: [ANN] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Ryan Brush]

Hey Ru,

I avoided Miss Manners simply because it doesn't represent the usage patterns I 
have or expect, so I just have been profiling against the data I have for my 
use case.

Of course, Ms Manners may be a a better reflection of your needs, in which case 
it could be a good benchmark. Micro-benchmarking is full of pitfalls, so your 
mileage may vary.

-Ryan

-- 
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] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Ryan Brush]

I'm less familiar with Waltz. It looks like a good way to exercise some 
worst-case scenarios in the rule engines as well. Like Ms Manners I don't 
think this is a very representative usage pattern but it could expose 
problems in extreme cases.

-Ryan

On Wednesday, May 14, 2014 8:28:41 AM UTC-5, ru wrote:

 Hello Ryan,

 Have you look at Waltz test? You may be interested of this. Its CLIPS 
 source is in examples folder of rete4frames.

 -Ru

 понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:

 New feature: added Java interface. Eclipse project example.

 Home: https://github.com/rururu/rete4frames

 Have fun!

 Sincerely,
   Ru



-- 
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] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Ryan Brush]

It's cool to see different approaches to Rete in Clojure. I think a solid 
implementation could really disrupt Drools. Why would I want to write in a 
limited rule language if I can get rule-like semantics and the 
expressiveness of Clojure at the same time? Of course I'm going to be 
biased towards Clara, but more important is the fact that Clojure provides 
a stronger foundation for expert systems than anything else out there. This 
is an opportunity for Clojure to make inroads. 

Regarding the benchmarking questions, I'm sure Drools will run Ms. Manners 
and other benchmarks faster than Clara at this point. This is partially 
because I've emphasized correctness and simplicity in Clara first, although 
I've recently started doing some significant profiling and optimizations. 
But Ms. Manners is really a poor example of typical rule engine use...it 
was created specifically to exercise some worst case scenarios. It's also 
constraint-oriented, so I'd actually use core.logic to solve that problem 
before I'd use any forward-chaining approach.

More important is to ask whether a system is fast enough for your needs. I 
gladly pay some overhead for persistent data structures because they are 
fast enough and save me a lot of time. (And I can spend that time 
optimizing the real bottlenecks of the program!)  These advantages tend to 
pay off in surprising ways, such as the recent excitement around how fast 
React and Om are. Clara will get optimized, but not at the cost of Clojure 
ideals like immutability.

In any case, it's great to see activity around Rete in Clojure. Clara was 
designed for a particular problem space I've been working in, but it's 
certainly not the only approach we should consider.

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

[ANN] Clojure RETE implementation - CLIPS-like expert system

[Ryan Brush]

Hi Tim,

Yes. Clara does Rete-style structural sharing of equivalent rule constraints, 
and then compiles those constraints into Clojure expressions. This actually 
happens when a rule session is created for a set of rules, but this is memoized 
by default so you only pay that cost the first time.

There are some opportunities to do more fine-grained sharing of parts of rule 
constraints, but that's an optimization we haven't gotten to yet. :)

-Ryan

-- 
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 Cookbook is out

[Ryan Neufeld]

Should be out any day now. The O’Reilly store has been selling them in print 
for almost a week, and our release date was supposed to be the 24th…

-Ryan 


On March 31, 2014 at 8:37:16 PM, Marcus Blankenship (mar...@creoagency.com) 
wrote:

Cool!

I just tried to buy this on Amazon and it’s not available.  Is the paper 
version out yet?

On Mar 31, 2014, at 5:35 PM, Brian Craft craft.br...@gmail.com wrote:

Just wanted to say how much I like this book. I got a copy at Clojure/West. 
Though it's structured like a reference book, I'm enjoying reading it 
cover-to-cover, and learning a lot. The discussion sections provide valuable 
contexts for many libraries and features that had previously escaped me.

On Friday, March 21, 2014 6:25:38 AM UTC-7, Ryan Neufeld wrote:
Thanks everyone, it was a blast working on the book.

Until next Thursday, you can get 50% off the digital version of the book with 
the coupon WKCLJUR

-Ryan
On Thursday, March 20, 2014 10:23:36 AM UTC-4, Thomas wrote:
woooh

More good books is good for Clojure. Going to order mine today. And a BIG BIG 
BIG thank you for everyone who has contributed, that is what I love about 
Clojure (almost ;) ) most, the community!!!

Thomas

On Thursday, March 20, 2014 1:15:57 PM UTC, Nando Breiter wrote:
I got an email from O'Reilly this morning saying that the Clojure Cookbook had 
been released, and bought it immediately. Thanks to everyone who contributed! 
It's very helpful.

http://shop.oreilly.com/product/0636920029786.do

Nando


Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

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

Best,
Marcus

Marcus Blankenship
\\\ Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

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

Re: Clojure Cookbook is out

[Ryan Neufeld]

Wow, that’s crazy, 4/30!? I’m not sure what’s going on there, but if you want 
it way sooner, try O’Reilly.

-Ryan 


On March 31, 2014 at 8:44:43 PM, Marcus Blankenship (mar...@creoagency.com) 
wrote:

Ok, cool.  Amazon just sent me a note offering to cancel my pre-order of the 
book, saying they didn’t think they could get it until 4/30.  I actually had to 
go back to their site and reconfirm the order, or it would be cancelled.

Needless to say, I took the time to reconfirm. ;-)


Marcus


On Mar 31, 2014, at 5:40 PM, Ryan Neufeld r...@cognitect.com wrote:

Should be out any day now. The O’Reilly store has been selling them in print 
for almost a week, and our release date was supposed to be the 24th…

-Ryan 


On March 31, 2014 at 8:37:16 PM, Marcus Blankenship (mar...@creoagency.com) 
wrote:

Cool!

I just tried to buy this on Amazon and it’s not available.  Is the paper 
version out yet?
On Mar 31, 2014, at 5:35 PM, Brian Craft craft.br...@gmail.com wrote:

Just wanted to say how much I like this book. I got a copy at Clojure/West. 
Though it's structured like a reference book, I'm enjoying reading it 
cover-to-cover, and learning a lot. The discussion sections provide valuable 
contexts for many libraries and features that had previously escaped me.

On Friday, March 21, 2014 6:25:38 AM UTC-7, Ryan Neufeld wrote:
Thanks everyone, it was a blast working on the book.

Until next Thursday, you can get 50% off the digital version of the book with 
the coupon WKCLJUR

-Ryan
On Thursday, March 20, 2014 10:23:36 AM UTC-4, Thomas wrote:
woooh

More good books is good for Clojure. Going to order mine today. And a BIG BIG 
BIG thank you for everyone who has contributed, that is what I love about 
Clojure (almost ;) ) most, the community!!!

Thomas

On Thursday, March 20, 2014 1:15:57 PM UTC, Nando Breiter wrote:
I got an email from O'Reilly this morning saying that the Clojure Cookbook had 
been released, and bought it immediately. Thanks to everyone who contributed! 
It's very helpful.

http://shop.oreilly.com/product/0636920029786.do

Nando


Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

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

Best,
Marcus

Marcus Blankenship
\\\ Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Best,
Marcus

Marcus Blankenship
\\\ Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

probably a noobie question: apparent memory leak

[Ryan Waters]

I have some code that blows up the heap and I'm not sure why.  I've reduced
it down to the following.

I've tried to make sure the atom doesn't have boundless growth and I didn't
think 'while' hangs on to the head of sequences so I'm embarrassed to say
I'm stumped.


(defn leaks-memory
  []
  (let [mem (atom [])
chunksize 1000
threshold 2000]
  (while true
(swap! mem conj (rand-int 100))

; every 'chunksize' item past 'threshold'
(when (and (= 0 (mod (count @mem) chunksize))
   ( (count @mem) threshold))
  (swap! mem subvec chunksize)

-- 
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: probably a noobie question: apparent memory leak

[Ryan Waters]

If you do a (count @mem) it reports the length of the atom's vector isn't
growing without bounds.  It seems counterintuitive that the parts of the
old vector wouldn't get garbage collected because the atom no longer points
to them.  But I guess I need to rtfd.

Thank you.


On Sat, Mar 29, 2014 at 10:07 AM, Aaron Cohen aa...@assonance.org wrote:



 On Sat, Mar 29, 2014 at 10:09 AM, Ryan Waters ryan.or...@gmail.comwrote:

 I have some code that blows up the heap and I'm not sure why.  I've
 reduced it down to the following.

 I've tried to make sure the atom doesn't have boundless growth and I
 didn't think 'while' hangs on to the head of sequences so I'm embarrassed
 to say I'm stumped.


 (defn leaks-memory
   []
   (let [mem (atom [])
 chunksize 1000
 threshold 2000]
   (while true
 (swap! mem conj (rand-int 100))

 ; every 'chunksize' item past 'threshold'
 (when (and (= 0 (mod (count @mem) chunksize))
( (count @mem) threshold))
   (swap! mem subvec chunksize)

 (doc subvec)

 Returns a persistent vector of the items in vector from
 start (inclusive) to end (exclusive). If end is not supplied,
 defaults to (count vector). This operation is O(1) and very fast, as
 the resulting vector shares structure with the original and no
 trimming is done.

 subvec is fast, but it's not saving you any memory.

 --
 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: probably a noobie question: apparent memory leak

[Ryan Waters]

Nice!  I hadn't seen that before.

Thank you both.


On Sat, Mar 29, 2014 at 3:29 PM, Jonas jonas.enl...@gmail.com wrote:

 You could give core.rrb-vector[1]. From the docs:

 The main API entry points are clojure.core.rrb-vector/catvec,
 performing vector concatenation, and clojure.core.rrb-vector/subvec, which
 produces a new vector containing the appropriate subrange of the input
 vector (in contrast to clojure.core/subvec, which returns a view on the
 input vector).

 [1] https://github.com/clojure/core.rrb-vector


 On Saturday, March 29, 2014 8:42:25 PM UTC+2, Ryan Waters wrote:

 If you do a (count @mem) it reports the length of the atom's vector isn't
 growing without bounds.  It seems counterintuitive that the parts of the
 old vector wouldn't get garbage collected because the atom no longer points
 to them.  But I guess I need to rtfd.

 Thank you.


 On Sat, Mar 29, 2014 at 10:07 AM, Aaron Cohen aa...@assonance.orgwrote:



 On Sat, Mar 29, 2014 at 10:09 AM, Ryan Waters ryan@gmail.comwrote:

 I have some code that blows up the heap and I'm not sure why.  I've
 reduced it down to the following.

 I've tried to make sure the atom doesn't have boundless growth and I
 didn't think 'while' hangs on to the head of sequences so I'm embarrassed
 to say I'm stumped.


 (defn leaks-memory
   []
   (let [mem (atom [])
 chunksize 1000
 threshold 2000]
   (while true
 (swap! mem conj (rand-int 100))

 ; every 'chunksize' item past 'threshold'
 (when (and (= 0 (mod (count @mem) chunksize))
( (count @mem) threshold))
   (swap! mem subvec chunksize)

 (doc subvec)

 Returns a persistent vector of the items in vector from
 start (inclusive) to end (exclusive). If end is not supplied,
 defaults to (count vector). This operation is O(1) and very fast, as
 the resulting vector shares structure with the original and no
 trimming is done.

 subvec is fast, but it's not saving you any memory.

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.


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


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

Re: Clojure Cookbook is out

[Ryan Neufeld]

Thanks everyone, it was a blast working on the book.

Until next Thursday, you can get 50% off the digital version of the book 
with the coupon *WKCLJUR http://bit.ly/cc-wkcljr*

-Ryan
On Thursday, March 20, 2014 10:23:36 AM UTC-4, Thomas wrote:

 woooh

 More good books is good for Clojure. Going to order mine today. And a BIG 
 BIG BIG thank you for everyone who has contributed, that is what I love 
 about Clojure (almost ;) ) most, the community!!!

 Thomas

 On Thursday, March 20, 2014 1:15:57 PM UTC, Nando Breiter wrote:

 I got an email from O'Reilly this morning saying that the Clojure 
 Cookbook had been released, and bought it immediately. Thanks to everyone 
 who contributed! It's very helpful.

 http://shop.oreilly.com/product/0636920029786.do

 Nando


 Aria Media Sagl
 Via Rompada 40
 6987 Caslano
 Switzerland

 +41 (0)91 600 9601
 +41 (0)76 303 4477 cell
 skype: ariamedia
  


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

[ANN] New Caribou Release: Version 0.14.0

[Ryan Spangler]

Hello Clojure People,

Happy to announce the release of a new version of Caribou!  
http://let-caribou.in/

There are a lot of improvements in this latest release.  We have tried to 
incorporate all of the feedback we have received since its initial release 
(which has been massive!).  A small selection of the improvements:

* *Heroku support fully integrated.*  This turned out to be a big deal for 
a lot of people, and there were some hoops to jump through before getting a 
database set up.  I am happy to say this has been vastly streamlined and 
improved, as well as fully documenting the process from provision to 
deploy: http://caribou.github.io/caribou/docs/deploying.html (at the bottom 
of that page).

* *Routing streamlined and simplified.  *We had this split into two steps 
before, but it is way simpler now.  Also fixed a couple issues people were 
having with HTTP methods in nested routes.  Polaris is also now fully 
integrated:  https://github.com/caribou/polaris

* *Immutant removed as a direct dependency.*  A lot of people complained 
about having to download all of Immutant even if they weren't using it! 
 This is no longer necessary, as you can now deploy to Immutant with 
options directly in your project.clj without ever making it a dependency of 
your project.

* *Templating engine can be swapped out for anything.*  You can now use 
whatever you want for templating, including Selmer:  
https://github.com/yogthos/Selmer  (yogthos himself contributed this pull 
request!)  Check out the bottom of this page for more details:  
http://caribou.github.io/caribou/docs/templates.html

And many more (check out the docs for a full list of features: 
http://caribou.github.io/caribou/docs/outline.html ).  

As there were a lot of changes (not all of them backwards compatible), we 
made a guide for upgrading Caribou to the latest version if you already 
have an instance running somewhere:

  http://caribou.github.io/caribou/docs/upgrading.html !

Hopefully that will help out for anyone has a Caribou site under 
development (let us know if anything comes up!)

Thanks to everyone who contributed feedback, issues and pull requests, and 
thanks to everyone who is using it to build awesome things.  We are working 
hard to make it as useful as possible, and having real world feedback has 
been invaluable to that cause.  

Lastly, check out the roadmap for the direction we are going:  
http://caribou.github.io/caribou/docs/roadmap.html  (Spoiler:  we got a UX 
person!)

We are open to any and all feedback on this or anything else!  Thanks again.

- Caribou Team

-- 
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/groups/opt_out.

Re: Using Apache Daemon with Clojure

[Ryan Neufeld]

Hey Aaron,

I've responded on GitHub where you entered an 
issue: https://github.com/clojure-cookbook/my-daemon/issues/1

-Ryan

On Sunday, February 9, 2014 11:25:21 AM UTC-5, Aaron France wrote:


 Hi, 

 I'm following the Clojure Cookbook blogpost[1] in order to Daemonize a 
 clojure application. Yet the provided code[2] does not work on my system. 

 When running the incantation to get JSVC to run, firstly I needed to 
 change it to use the full path to the JSVC binary. This is fine. 

 However, when it tries to run, it complains with: 

 Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader 

 Yet I am following their instructions *to the letter*. 

 Any ideas guys/gals? 

 Aaron 


 [1] http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ 
 [2] https://github.com/clojure-cookbook/my-daemon 


-- 
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/groups/opt_out.

[ANN] clara-rules 0.4 released

[Ryan Brush]

The 0.4.0 release of Clara is up on Clojars. The github page is at [1].

The theme of this release is rules as data, which I wrote about at [2]. 
In a nutshell, all rules and the Rete network itself are defined by 
well-defined data structures (via Prismatic Schema), which opens a lot of 
doors:

* Alternate front ends to Clara can now be written, generating rules in the 
schema-compliant format. If the defrule-style DSL isn't your thing, you 
can generate rules via any mechanism you want.
* Tooling can now be written to inspect the rules and their relationships, 
with some examples in the blog at [2].
* The Rete network itself is also a schema-defined data structure, opening 
the door for visualizing the working memory itself. 

There are some breaking changes for the ClojureScript support: I moved the 
logic to generate a Rete network in ClojureScript to be driven at compile 
time...meaning we can assemble an optimized network on the server, rather 
than having the client do that computation every time it loads. Details and 
an example are linked at [3]. I haven't yet used the ClojureScript version 
in anger, but am maintaining it because there is interest and it's cool 
to see this running in a browser. ;)

I expect future releases to be smaller and more frequent. Getting Clara on 
a solid basis of well-defined structures was a significant effort, but I 
think it puts it in a stronger position with a number of advantages over 
existing rule engines.

[1]
https://github.com/rbrush/clara-rules
[2]
http://www.toomuchcode.org/blog/2014/01/19/rules-as-data/
[3]
https://github.com/rbrush/clara-rules/wiki/ClojureScript

-- 
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/groups/opt_out.

Re: Should predicates always have one argument?

[Ryan]

Thank you all for your answers, they helped me a lot :)

Cheers

On Saturday, February 1, 2014 12:10:42 AM UTC+2, Ivan L wrote:

 I typically wrap stuff with (partial) for easier reading.  In your example 
 you might use something like following.

 (defn are-valid
   [maps validator]
   (let [valid? (partial validator)]
 (map valid? maps)))

 On Friday, January 31, 2014 11:44:38 AM UTC-5, Ryan wrote:

 Hello,

 I am wondering if all my predicates should be one argument functions 
 because I run into a couple of cases where I needed more than one.

 For example, I have a function called valid-params? which takes two 
 parameters; the validator to use and a maps parameter.
 Is this approach wrong/not the clojure way?

 What are my alternatives? Should I just use a different function name 
 which does not have a question mark at the end that implies that is a 
 predicate?

 Cheers,

 Ryan



-- 
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/groups/opt_out.

Should predicates always have one argument?

[Ryan]

Hello,

I am wondering if all my predicates should be one argument functions 
because I run into a couple of cases where I needed more than one.

For example, I have a function called valid-params? which takes two 
parameters; the validator to use and a maps parameter.
Is this approach wrong/not the clojure way?

What are my alternatives? Should I just use a different function name which 
does not have a question mark at the end that implies that is a predicate?

Cheers,

Ryan

-- 
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/groups/opt_out.

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

[Ryan McGowan]

Very minimalist. I appreciate that. As the author of incise I'd like to 
point out a few things though. :)

   1. You did not specifically say that incise forced some sort of 
   templating option though it was implied (along with the other static site 
   generators). Incise does not force any such options on you (in fact hiccup 
   will not even be included in incise-core in 0.2.0). It is also not specific 
   to html file generation though there are some helpful functions built in to 
   incise to support that very common use case. The layouts feature (similar 
   to create-page in what-the-emacs) is entirely opt in as well.
   2. You can create your own stylesheets too. I'm not sure what this was 
   getting at...
   3. While incise does require an input directory and an output directory 
   it is configurable.

Of course, if stasis has been around when I decided I wanted to start a 
blog, incise probably wouldn't be around. The two tools can be 
easily contrasted by this statement though:

No configuration options. You have to make them.


Incise's goal is to be extensible so someone can write an asciidoc parser 
(that may take some user defined configuration options) that leverages all 
of the other things that have already been done by integrating with it. 
 This makes sharing implementations easier. The stasis way to do this is 
for everyone to write it and integrate themselves.  Often the later is more 
fun and offers a bit more control, but the former is easier.

Those are my initial thoughts at least.

On Thursday, January 23, 2014 2:31:17 AM UTC-8, Magnar Sveen wrote:

 Oh, look at that. Thanks! :)


 On Thu, Jan 23, 2014 at 11:27 AM, Dmitry Groshev 
 lambda...@gmail.comjavascript:
  wrote:

 And here is a link to the project, just in case you've missed it like I 
 did: https://github.com/magnars/stasis :)


 On Thursday, January 23, 2014 2:16:48 PM UTC+4, Magnar Sveen wrote:

 Stasis

 A Clojure library of tools for developing static web sites.
 https://gist.github.com/magnars/32dbca91bdb0987ea4ba#another-static-site-framework-whyAnother
  
 static site framework? Why? 

 Well, that's exactly it. I didn't want to use a framework. I don't like 
 the restrained feeling I get when using them. I prefer coding things over 
 messing around with configuration files.

 I want to

- code my own pages
- set up my own configuration
- choose my own templating library
- create my own damn stylesheets

 *Statis offers a few functions that are pretty useful when creating 
 static web sites.*

 No more. There are no batteries included.

 If you want a framework that makes it really quick and easy to create a 
 blog, you should take a look at these:

- misaki https://github.com/liquidz/misaki is a Jekyll inspired 
static site generator in Clojure. 
- Madness http://algernon.github.io/madness/ is a static site 
generator, based on Enlive and Bootstrap.
- Static http://nakkaya.com/static.html is a simple static site 
generator written in Clojure. 
- Ecstatic http://samrat.me/ecstatic/ creates static web pages and 
blog posts from Hiccup templates and Markdown.
- incise https://github.com/RyanMcG/incise is an extensible static 
site generator written in Clojure. 

 They generally come with a folder where you put your blog posts in some 
 templating language, and a set of configuration options about how to set up 
 your blog. They often generate code for you to tweak.
  https://gist.github.com/magnars/32dbca91bdb0987ea4ba#usageUsage 

 The core of Stasis is two functions: serve-pages and export-pages. Both 
 take a map from path to contents:

 (def pages {/index.html h1Welcome!/h1})

 The basic use case is to serve these live on a local server while 
 developing - and then exporting them as static pages to deploy on some 
 server.
 https://gist.github.com/magnars/32dbca91bdb0987ea4ba#serving-live-pages-locallyServing
  
 live pages locally 

 Stasis can create a Ring handler to serve your pages.

 (ns example
   (:require [stasis.core :as stasis]))
 (def app (stasis/serve-pages pages))

 Like with any Ring app, you point to your app in project.clj:

 :ring {:handler example/app}

 and start it with lein ring server-headless.
 https://gist.github.com/magnars/32dbca91bdb0987ea4ba#exporting-the-pagesExporting
  
 the pages 

 To export, just give Stasis some pages and a target directory:

 (defn export []
   (stasis/export-pages pages target-dir))

 When you've got this function, you can create an alias for leiningen:

 :aliases {build-site [run -m example/export]}

 and run lein build-site on the command line. No need for a lein plugin.
  https://gist.github.com/magnars/32dbca91bdb0987ea4ba#example-appsExample 
 apps? 

 The static page that prompted me to write Stasis is currently closed 
 source, but I'm in the process of turning my 4 other static sites over. The 
 simplest, and first to be done, is:

- 

whattheemacsd.com 

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

[Ryan McGowan]

Thanks! I agree. I think they both have there uses as things stand right 
now.

Maybe Incise could even use Stasis as a lib to build its more elaborate 
 features on top of?


I was thinking the same thing. Unfortunately, I think there are a few 
blockers right now (serving is done very differently, string content is not 
required). I'll have to think more about how the stasis way of serving and 
exporting compares to incise's.

On Thursday, January 23, 2014 6:07:32 PM UTC-8, Magnar Sveen wrote:

 Very minimalist. I appreciate that.


 Thank you :-) And let me say that out of the five frameworks, I think 
 Incise is the most exciting - with its focus on extensibility.

 This makes sharing implementations easier. The stasis way to do this is 
 for everyone to write it and integrate themselves.  Often the later is more 
 fun and offers a bit more control, but the former is easier.


 Agreed. Now, I prefer control and fun over ease - but that might be a bad 
 choice in many situations.

 My feeling is that both Stasis and Incise have their place, and can live 
 happily alongside each other. Maybe Incise could even use Stasis as a lib 
 to build its more elaborate features on top of?

 - Magnar



-- 
-- 
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/groups/opt_out.

Re: Best way to loop a map of maps

[Ryan]

Thank you for your input Thomas.

All replies have definitely been very useful :)

Cheers,

Ryan

On Tuesday, December 10, 2013 1:57:38 PM UTC+2, Thomas Heller wrote:

 Oh nvm, just saw that it was suggested before.

 But maybe this is new:

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)

 (defn nested-seq [m]
   (for [[outer-key collections] m
 [collection-name collection] collections
 [string-id data] collection]
 {:outer-key outer-key :collection-name collection-name :string-id 
 string-id :data data}
 ))

 (pprint (nested-seq m))

 ;; produces
 ({:outer outerKeyA,
   :collection-name :innerKeyA,
   :string-id string id,
   :data {:foo 1, :bar 2}}
  {:outer outerKeyB,
   :collection-name :innerKeyB,
   :string-id string id,
   :data {:bar 5, :baz 10}})



 for list comprehensions behave like doseq except that they return whatever 
 the body does, thus letting you move your side effects somewhere else.

 Maybe this helps,
 /thomas

 On Tuesday, December 10, 2013 12:48:56 PM UTC+1, Thomas Heller wrote:

 FWIW you can simplify the nested doseqs like this

 (doseq [[outer-keys collections] m
 [collection-name collection] collections
 [string-id data] collection]
   ;; do stuff with the above
   )

 HTH,
 /thomas


 On Wednesday, December 4, 2013 12:05:14 AM UTC+1, Ryan wrote:

 Hi all,

 I am trying to figure out a better way to loop the following map than 
 using nested doseq. The map has the following structure:

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)


 So, right now i am doing the following:

 (doseq [[outer-keys collections] m]
   (doseq [[collection-name collection] collections]
 (doseq [[string-id data] collection]
   ;; do stuff with all the above 
 )))


 Is there a more idiomatic/better way to do deeply nested 
 iterations/traversal of map of maps?

 Thank you for any replies!

 Ryan 



-- 
-- 
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/groups/opt_out.

Re: pre-conditions on !

[Kelker Ryan]

Can't you just test the value before placing a value in a channel?  22.01.2014, 16:27, "t x" txrev...@gmail.com:Hi,## Question:  For a channel, is it possible to put a pre-condition of sorts on a channel?  For example:  (let [chan (async/chan 100)]    (set-pre-condition! chan even?)    (put! chan 1) ;; exception thrown    (!! chan 3) ;; exception thrown  )## Asides  It's important that I want the exception to be thrown at the time of put, NOT at the time of take via ! or !!. Thanks! --  --  You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en ---  You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Re: [ANN] incise 0.1.0 - An extensible static site generator

[Ryan McGowan]

Hey Jan,

My decisions were mostly in an effort to reduce the number of hard
dependencies. If you do a search on the incise repository for
hiccuphttps://github.com/RyanMcG/incise/search?q=hiccupref=cmdform,
you'll see it is not used in any core functionality (besides server to
generate a trivial 404 page). The only place hiccup is really used are in
layout implementations. You could easily implement a layout without using
any of the helper macros (deflayout, defpartial) that supports hiccup
instead. Version 0.2.0 is going to break apart the project to remove as
many dependencies as possible from incise-core.

Thanks,

Ryan


On Tue, Jan 14, 2014 at 12:26 AM, Jan Herich jan.her...@gmail.com wrote:

 Hello Ryan,

 Thank you for the project, i was always missing a good static site
 generator written in clojure !
 You took some interesting design decisions with extensibility. I'm
 currently working on the
 similar project https://github.com/janherich/gutenberg, even if my
 design is very different, because my needs are different - i want to
 have templates in pure html and be able to declaratively specify specific
 areas, because of that
 my project is based on enlive html library.


 Dňa utorok, 14. januára 2014 8:35:33 UTC+1 Ryan McGowan napísal(-a):

 Hi all!

 After consuming quite a bit of my spare time for the past several months,
 I have finally released version 0.1.0 https://clojars.org/incise of
 incise. It is a static site generator written in Clojure (of course). I
 like it quite a bit and I think others might benefit from it too.  I am
 very open to contributions, suggestions or criticisms (just open an
 issue) https://github.com/RyanMcG/incise/issues.

 Necessary links:

- https://clojars.org/incise
- http://www.ryanmcg.com/incise/ - README generated into website
using itself (it's called being meta).
- https://github.com/RyanMcG/incise
- https://github.com/RyanMcG/lein-incise - Yes there is a plugin
- http://www.ryanmcg.com/2014/1/13/static-website-generation-
with-incise/ - Very short post about it. Basically points to the
README and makes the disclaimer that it's not a big deal.
- https://github.com/RyanMcG/incise-example-project - super simple
example project
- http://www.ryanmcg.com/incise-example-project/ - and its generated
output

 Thanks,

 Ryan McGowan

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/8AI4JIfVCB8/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Re: go kill infinite loop

[Kelker Ryan]

Maybe something like this?

(go-loop [c (chan)]
  (let [x (! c)]
(when-not (= :break x)
  (doing some things x)
  (recur c

14.01.2014, 14:28, Ben Mabey b...@benmabey.com:
 On Mon Jan 13 18:11:10 2014, t x wrote:

  Consider the following code block:

  (defn make-stupid []
    (go (loop []
  (recur

  (def x (make-stupid))

  ;; ... is there a way to kill this infinite go-loop ?

 No, you can not kill the loop with the go channel that is bound to x.
 You need to return a stop, a.k.a. poison, channel that the go block
 checks before recurring. Something like:

 (let [stop (chan)]
   (go
    (loop []
  (when (alt! stop false :default :keep-going)
    ...
    (recur
   stop)

 -Ben

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

[ANN] incise 0.1.0 - An extensible static site generator

[Ryan McGowan]

Hi all!

After consuming quite a bit of my spare time for the past several months, I 
have finally released version 0.1.0 https://clojars.org/incise of incise. 
It is a static site generator written in Clojure (of course). I like it 
quite a bit and I think others might benefit from it too.  I am very open 
to contributions, suggestions or criticisms (just open an 
issue)https://github.com/RyanMcG/incise/issues
.

Necessary links:

   - https://clojars.org/incise
   - http://www.ryanmcg.com/incise/ - README generated into website using 
   itself (it's called being meta).
   - https://github.com/RyanMcG/incise
   - https://github.com/RyanMcG/lein-incise - Yes there is a plugin
   - http://www.ryanmcg.com/2014/1/13/static-website-generation-with-incise/ - 
   Very short post about it. Basically points to the README and makes the 
   disclaimer that it's not a big deal.
   - https://github.com/RyanMcG/incise-example-project - super simple 
   example project
   - http://www.ryanmcg.com/incise-example-project/ - and its generated 
   output
   
Thanks,

Ryan McGowan

-- 
-- 
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/groups/opt_out.

In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Kelker Ryan]

In your opinion, what's the best, and what's the worst aspects of using Clojure?

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

Re: [ANN] Hoplon: web applications in Clojure and ClojureScript

[Ryan Spangler]

 The hlisp part of Hoplon - the compiler bit that converts HTML to 
 ClojureScript - was designed and implemented specifically to avoid having 
 to do this.  It's our opinion (and experience) that admission of the DOM as 
 a data structure instead of a piece of the program introduces tremendous 
 complexity.  This data structure must be explicitly interpreted, evaluated, 
 and updated in complicated ways that tend to couple tightly to both overall 
 state logic and DOM quirks.  That said, Hoplon markup can be manipulated as 
 data the way any other Lisp program sanely can - via hygienic macros. 


I am curious about this.  I have had the opposite experience.  Whenever I 
use a library based on macros I find myself wanting to do something with 
them the macro writer did not expect, and being forced to wrap the macros 
in functions so I can compose things programmatically (which seems to me 
like unnecessary complexity).  I can't pass macros around as arguments, 
store them in a list, or apply them to arguments in a general way.  

On the other hand, if I am just working with a data structure, I can write 
functions to manipulate the data in novel ways and even use many functions 
that already exist to manipulate data without having to recreate that 
functionality for a specific domain (like looping, merging, search and 
replace etc).  

So I am curious specifically what flexibility you are gaining by using 
macros (things you can't do with functions and data) that would offset the 
flexibility you sacrifice with macros?  I am open to being convinced on 
this point!

-- 
-- 
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/groups/opt_out.

Re: Parsing large XML files

[Ryan Senior]

As far as I know, using zippers like that will need the whole XML data
structure to be in memory.  data.xml returns fast because it's lazy (uses
pull parsing).  Until you start traversing down the structure, it won't
parse more of it.  data.xml should also be fully streaming, so it shouldn't
require the full 500 MB XML file in memory unless you're doing something to
require that.

Traversing the structure that data.xml emits directly should not consume
heap, but you wouldn't be able to use XPath.  I've not used it, but there
is an XPath wrapper library here: https://github.com/kyleburton/clj-xpath.
Briefly looking at the code, it looks like it's using DOM parsing, so it
would consume heap. You could bump your max heap (-Xmx from the command
line) if you had the extra memory and weren't worried about the docs
getting larger.

-Ryan


On Tue, Dec 17, 2013 at 4:57 AM, Peter Ullah peterul...@gmail.com wrote:


 Hi all,

 I'm attempting to parse a large (500MB) XML, specifically I am trying to
 extract various parts using XPath. I've been using the examples presented
 here:
 http://clojure-doc.org/articles/tutorials/parsing_xml_with_zippers.html
 and all was going when tested against small files, however now that I am
 using the larger file Fireplace/Vim just hangs and my laptop gets hot then
 I get a memory exception.

 I've been playing around with various other libraries such as
 clojure.data.xml and and found that the following works perfectly well for
 parsing... but when I come to search inside root, things start to snarl up
 again.

 (ns example.core
   (:require [clojure.java.io :as java.io]
 [clojure.data.xml :as data.xml]
 ))

 (def large-file /path-to-large-file)

 ;; using clojure.data.xml returns quickly with no problems whereas
 clojure.xml/parse from the link above causes problems..
 (def root
   ( - large-file
java.io/input-stream
data.xml/parse
))

 (class root) ;clojure.data.xml.Element

 Does anyone know a way of searching within root that won't consume the
 heap?

 Forgive me, I'm new to Clojure and these forums, I've searched through
 previous posts but not managed to answer my own question.

 Thanks in advance.

 --
 --
 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/groups/opt_out.


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

[ANN] - jMonkeyEngine3 game dev for Clojure

[Kelker Ryan]

 As far as I know, I've created the first lein template that allows you to run jMonkeyEngine3  from Clojure without any configuration. Create a projectlein new jme3 project-name-here
Download depscd project-name-here; lein deps
Run the demolein run
Game Engine:  http://jmonkeyengine.org/Github:  https://github.com/runexec/clj-jme3 



-- 
-- 
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/groups/opt_out.

Re: [ANN] - jMonkeyEngine3 game dev for Clojure

[Kelker Ryan]

I'm sorry to hear that. I run Arch tux x86_64, but I've looked around for some 
possible OSX solutions and it looks like there's a known issue with liblwjgl 
and Java 7 on Macs.

Here are some things you might want to look into.

Fixing LWJGL Java 7 Mac - https://www.youtube.com/watch?v=03R7CZoSa0A
LWJGL on OSX with Java 7 - https://wiki.spout.org/LWJGL#Mac_OS_X_and_Java_7
lwjgl on osx/java7 - http://www.java-gaming.org/index.php?topic=27748.0

13.12.2013, 05:56, David Nolen dnolen.li...@gmail.com:
 Nice, I tried it but got the following error under OS X:
 Exception in thread LWJGL Renderer Thread java.lang.UnsatisfiedLinkError: 
 Can't load library: /.../jme-test/liblwjgl.dylib

 I see that it's under /.../jme-test/target/native/macosx

 On Thu, Dec 12, 2013 at 3:40 PM, Kelker Ryan theinter...@yandex.com wrote:
 As far as I know, I've created the first lein template that allows you to 
 run jMonkeyEngine3  from Clojure without any configuration.

 Create a project

 lein new jme3 project-name-here

 Download deps

 cd project-name-here; lein deps

 Run the demo

 lein run

 Game Engine:  http://jmonkeyengine.org/
 Github: https://github.com/runexec/clj-jme3

 --
 --
 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/groups/opt_out.

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - 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/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Re: Best way to loop a map of maps

[Ryan]

I've seen postwalk and prewalk but never really played around with them so 
I will give it a shot.

Thanks for your input!

Ryan

On Tuesday, December 10, 2013 10:29:51 AM UTC+2, Jeroen van Dijk wrote:

 Don't forget about the option of walking over a map by using 
 clojure.walk/postwalk or clojure.walk/prewalk

 I use these functions often lately. Especially useful if you have to 
 update values in your map and they could occur anywhere. It is a bit tricky 
 to get working at first, because the return value of each step needs to 
 match the structure that is currently walked. For that reason you sometimes 
 need to switch between a postwalk instead of a prewalk etc.

 Try this for a demo

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)

 (clojure.walk/postwalk-demo m)




 On Thu, Dec 5, 2013 at 11:06 AM, Ryan areka...@gmail.com javascript:wrote:

 Thanks guys for the useful answers :)

 Ryan


 On Wednesday, December 4, 2013 1:27:57 AM UTC+2, James Ferguson wrote:

 `update-in` could be helpful, depending on what exactly you're doing.

 (doseq [keyA keys, keyB otherkeys]
   (update-in m [keyA keyB] some-function))

 On Tuesday, December 3, 2013 6:05:14 PM UTC-5, Ryan wrote:

 Hi all,

 I am trying to figure out a better way to loop the following map than 
 using nested doseq. The map has the following structure:

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)


 So, right now i am doing the following:

 (doseq [[outer-keys collections] m]
   (doseq [[collection-name collection] collections]
 (doseq [[string-id data] collection]
   ;; do stuff with all the above 
 )))


 Is there a more idiomatic/better way to do deeply nested 
 iterations/traversal of map of maps?

 Thank you for any replies!

 Ryan 

  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

[ANN] Static Prime - Alpha 2

[Kelker Ryan]

Static Prime is a static website editor and server written in Clojure and ClojureScript. Visual Documentation Video Demo (Vimeo) Video Demo (Dailymotion)Supportsin browser mouse only layout arrangementdynamic template loading for static filesstatic site indexmultiple adminshtml and markdown editingwrite, edit, delete pagesChangesLinks under each category are now least to greatest sortedImproved editing input and preview areasFixed read/write errors for file names that end with white spaceIncreased editor input and preview sizes + fixed css conflict



-- 
-- 
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/groups/opt_out.

Re: require :require

[Kelker Ryan]

I believe one is a directive and the other is a function.:require doesn't need the values to be quoted (:require xyz)require needs values to be quoted so that they're not evaluated when passed as arguments (require 'xyz)I could be wrong though.  06.12.2013, 18:17, "BillZhang" jingege...@gmail.com:hi all,What's the differences between those two snippets?1.(ns a  (require [a.b])) 2.(ns a  (:require [a.b])) They all works in my code! thx~ --  --  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/groups/opt_out.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Re: Best way to loop a map of maps

[Ryan]

Thanks guys for the useful answers :)

Ryan

On Wednesday, December 4, 2013 1:27:57 AM UTC+2, James Ferguson wrote:

 `update-in` could be helpful, depending on what exactly you're doing.

 (doseq [keyA keys, keyB otherkeys]
   (update-in m [keyA keyB] some-function))

 On Tuesday, December 3, 2013 6:05:14 PM UTC-5, Ryan wrote:

 Hi all,

 I am trying to figure out a better way to loop the following map than 
 using nested doseq. The map has the following structure:

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)


 So, right now i am doing the following:

 (doseq [[outer-keys collections] m]
   (doseq [[collection-name collection] collections]
 (doseq [[string-id data] collection]
   ;; do stuff with all the above 
 )))


 Is there a more idiomatic/better way to do deeply nested 
 iterations/traversal of map of maps?

 Thank you for any replies!

 Ryan 



-- 
-- 
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/groups/opt_out.

Re: How would I do this in Clojure?

[Kelker Ryan]

user (def a-blah (atom [1 2 3]))#'user/a-blahuser (defn blah [] (let [x (first @a-blah)] (swap! a-blah rest) x))#'user/blahuser (blah)1user (blah)2user (blah)3user (blah)nil  06.12.2013, 03:46, "David Simmons" shortlypor...@gmail.com:Hi I'd like to be able to define a function that is passed a vector of items and returns a function such that each time the returned function is called it returns the next item in my-vector. For example  (def blah (my-function [1 2 3]) (blah) = 1(blah) = 2(blah) = 3 Is this possible? cheers Dave  --  --  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/groups/opt_out.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Best way to loop a map of maps

[Ryan]

Hi all,

I am trying to figure out a better way to loop the following map than using 
nested doseq. The map has the following structure:

(def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)


So, right now i am doing the following:

(doseq [[outer-keys collections] m]
   (doseq [[collection-name collection] collections]
 (doseq [[string-id data] collection]
   ;; do stuff with all the above 
 )))


Is there a more idiomatic/better way to do deeply nested 
iterations/traversal of map of maps?

Thank you for any replies!

Ryan 

-- 
-- 
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/groups/opt_out.

Any elegant solutions for this problem?

[Ryan]

Hi all,

I have a vector which contains an unknown number of repetitions of the 
following pattern:

String, followed by 1 or more integers

For example:

String
Integer
String
Integer
Integer
String
Integer
Integer
Integer
String
Integer

What I am trying to do is to create a vector of pairs which each pair will 
be the string and the integers followed.

Real example:

foo
1
bar
10
20
clown
5

should convert to:

[[foo 1] [bar 10] [bar 20] [clown 5]]

I did try to play around with partition-by, partition and instance? but I 
couldn't get it quite right. 

Thank you for your time

-- 
-- 
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/groups/opt_out.

Re: Any elegant solutions for this problem?

[Ryan]

Thanks both for your answers.

@Ben, that seems to do it. I was trying to make it a bit nicer but failed

@john, that was my original approach but it does not produce what I want. 
The result of that is 

((foo 1) (bar 10 20) (clown 5)) 


but I need

((foo 1) (bar 10) (bar 20) (clown 5)) 


Ryan. 

On Sunday, December 1, 2013 9:21:14 PM UTC+2, john walker wrote:

 Sorry, I spoke without seeing that you were aware of partition-by. Here's 
 one that isn't vectorized.

 (def v [foo 1 bar 10 20 clown 5])
 (- v
 (partition-by string?)
 (partition 2)
 (map #(apply concat %)))

 On Sunday, December 1, 2013 2:10:04 PM UTC-5, Ben wrote:

 user= (def v [foo 1 bar 2 3 baz 4])
 #'user/v
 user= (first (reduce (fn [[res s] e] (if (string? e) [res e] [(conj res 
 [s e]) s])) [[] nil] v))
 [[foo 1] [bar 2] [bar 3] [baz 4]] 

 On Sun, Dec 1, 2013 at 10:57 AM, Ryan areka...@gmail.com wrote:

 Hi all,

 I have a vector which contains an unknown number of repetitions of the 
 following pattern:

 String, followed by 1 or more integers

 For example:

 String
 Integer
 String
 Integer
 Integer
 String
 Integer
 Integer
 Integer
 String
 Integer

 What I am trying to do is to create a vector of pairs which each pair 
 will be the string and the integers followed.

 Real example:

 foo
 1
 bar
 10
 20
 clown
 5

 should convert to:

 [[foo 1] [bar 10] [bar 20] [clown 5]]

 I did try to play around with partition-by, partition and instance? but 
 I couldn't get it quite right. 

 Thank you for your time

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




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

  

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

Re: Any elegant solutions for this problem?

[Ryan]

Haha, no worries, it happens :)

That seems to work nice as well!

Ryan

On Sunday, December 1, 2013 9:36:47 PM UTC+2, john walker wrote:

 I swear english is my first language. This one isn't elegant, but at least 
 you know you aren't alone:

 (- [foo 1 bar 10 20 clown 5]
  (partition-by string?)
  (partition 2)
  (map #(apply concat %))
  (map #(let [x (first %)]
  (for [y (rest %)]
[x y])))
  (reduce into []))

 On Sunday, December 1, 2013 2:21:14 PM UTC-5, john walker wrote:

 Sorry, I spoke without seeing that you were aware of partition-by. Here's 
 one that isn't vectorized.

 (def v [foo 1 bar 10 20 clown 5])
 (- v
 (partition-by string?)
 (partition 2)
 (map #(apply concat %)))

 On Sunday, December 1, 2013 2:10:04 PM UTC-5, Ben wrote:

 user= (def v [foo 1 bar 2 3 baz 4])
 #'user/v
 user= (first (reduce (fn [[res s] e] (if (string? e) [res e] [(conj res 
 [s e]) s])) [[] nil] v))
 [[foo 1] [bar 2] [bar 3] [baz 4]] 

 On Sun, Dec 1, 2013 at 10:57 AM, Ryan areka...@gmail.com wrote:

 Hi all,

 I have a vector which contains an unknown number of repetitions of the 
 following pattern:

 String, followed by 1 or more integers

 For example:

 String
 Integer
 String
 Integer
 Integer
 String
 Integer
 Integer
 Integer
 String
 Integer

 What I am trying to do is to create a vector of pairs which each pair 
 will be the string and the integers followed.

 Real example:

 foo
 1
 bar
 10
 20
 clown
 5

 should convert to:

 [[foo 1] [bar 10] [bar 20] [clown 5]]

 I did try to play around with partition-by, partition and instance? but 
 I couldn't get it quite right. 

 Thank you for your time

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




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

  

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

Re: Any elegant solutions for this problem?

[Ryan]

Nice James, I like it :)

Ryan

On Sunday, December 1, 2013 10:02:32 PM UTC+2, James Reeves wrote:

 There's also:

 (- xs
  (partition-by string?)
  (partition 2)
  (mapcat (fn [[[s] xs]] (for [x xs] [s x]


 - James


 On 1 December 2013 19:39, Ryan areka...@gmail.com javascript: wrote:

 Haha, no worries, it happens :)

 That seems to work nice as well!

 Ryan


 On Sunday, December 1, 2013 9:36:47 PM UTC+2, john walker wrote:

 I swear english is my first language. This one isn't elegant, but at 
 least you know you aren't alone:

 (- [foo 1 bar 10 20 clown 5]
  (partition-by string?)
  (partition 2)
  (map #(apply concat %))
  (map #(let [x (first %)]
  (for [y (rest %)]
[x y])))
  (reduce into []))

 On Sunday, December 1, 2013 2:21:14 PM UTC-5, john walker wrote:

 Sorry, I spoke without seeing that you were aware of partition-by. 
 Here's one that isn't vectorized.

 (def v [foo 1 bar 10 20 clown 5])
 (- v
 (partition-by string?)
 (partition 2)
 (map #(apply concat %)))

 On Sunday, December 1, 2013 2:10:04 PM UTC-5, Ben wrote:

 user= (def v [foo 1 bar 2 3 baz 4])
 #'user/v
 user= (first (reduce (fn [[res s] e] (if (string? e) [res e] [(conj 
 res [s e]) s])) [[] nil] v))
 [[foo 1] [bar 2] [bar 3] [baz 4]] 

 On Sun, Dec 1, 2013 at 10:57 AM, Ryan areka...@gmail.com wrote:

 Hi all,

 I have a vector which contains an unknown number of repetitions of 
 the following pattern:

 String, followed by 1 or more integers

 For example:

 String
 Integer
 String
 Integer
 Integer
 String
 Integer
 Integer
 Integer
 String
 Integer

 What I am trying to do is to create a vector of pairs which each pair 
 will be the string and the integers followed.

 Real example:

 foo
 1
 bar
 10
 20
 clown
 5

 should convert to:

 [[foo 1] [bar 10] [bar 20] [clown 5]]

 I did try to play around with partition-by, partition and instance? 
 but I couldn't get it quite right. 

 Thank you for your time

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




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

   -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

Re: I need a vector not a list?

[Kelker Ryan]

Vectors are mostly for speed and maintaining value sequence order. Try this = (vec (reverse [1 2 3]))Not this = (apply vector (reverse [1 2 3]))As an alternative you can do this = (into [] (reverse [1 2 3]))You can always use mapv when calling fun for each coll object.Try this = (mapv #(* 2 %) [1 2 3])Not this = (apply vector (map (partial * 2) [1 2 3]))  01.12.2013, 06:15, "Andy Smith" the4thamig...@googlemail.com:Hi,I am trying to understand the manipulation of vectors from an efficiency point of view. For example if I want to reverse a vector I can do the following (apply vector (reverse [1 2 3]))My understanding is that reverse will create a new list object (3 2 1) then this will be used to construct a new vector object [3 2 1]. What can I use to construct a new vector directly instead of having the intermediate list object being constructed?I have read about rseq as providing something like a reverse iterator to the same underlying vector, which may be a great solution in this case, but my question is really about the more general case of any function that manipulates a vector e.g. the following also returns a list rather than a vector as desired,(map (partial * 2) [1 2 3]) again forcing me to use apply vector e.g.(apply vector (map (partial * 2) [1 2 3]))Why dont we have a version of map that returns a vector when given a vector? We can do this kind of thing in other languages with templates/generics why not clojure?There is obviously some basic principle/understanding that I am missing here. This kind of thing surely cant be very efficient, can it?Andy --  --  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/groups/opt_out.



-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - 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/groups/opt_out.

[ANN] Clara 0.3.0: Rete in ClojureScript

[Ryan Brush]

Clara 0.3.0, a forward-chaining rules engine in pure Clojure, has been 
released.  The headliner is ClojureScript support, although a handful of 
fixes and optimizations were included as well. 

Some discussion of the ClojureScript port is in that group:
https://groups.google.com/forum/#!topic/clojurescript/MMwjpcFUPqE

The github project:
https://github.com/rbrush/clara-rules

Example usage from ClojureScript:
https://github.com/rbrush/clara-examples/blob/master/src/main/clojurescript/clara/examples/shopping.cljs

Feel free to ping me (@ryanbrush) with any questions or suggestions, or log 
issues via github.

-Ryan

-- 
-- 
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/groups/opt_out.

[ANN] manners 0.2.0 released

[Ryan McGowan]

A validation library built on using predicates properly.

I just released a new version of my take on a simple, general purpose 
validation library.  Version 0.2.0 includes a chaining feature very much 
like (and inspired by) the chain function in 
vladhttps://github.com/logaan/vlad, 
another validation library. For the remote few who are familiar with 
manners, to implement this the definition of a manner has changed slightly 
to allow one or more predicate message pairs (previously only one was 
allowed).

https://github.com/RyanMcG/manners

-- 
-- 
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/groups/opt_out.

Releasing Static Prime: A static website editor and server written in Clojure and ClojureScript.

[Kelker Ryan]

Static PrimeA static website editor and server written in Clojure and ClojureScript. Visual Documentation Supportsin browser mouse only layout arrangementdynamic template loading for static filesstatic site indexmultiple adminshtml and markdown editingwrite, edit, delete pages



-- 
-- 
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/groups/opt_out.