Re: [ANN] JSON/CLJ/EDN comparison table
How about format which can represent either graph or structure, depending on users needs? I would argue that EDN is more suitable for linked data than JSON is. Its support for identifiers and tagged elements allows for pretty straightforward serialization of linked data. See https://gist.github.com/wagjo/d6419a289a64c503010c for one possible approach. Jozef On Sunday, June 1, 2014 2:18:00 AM UTC+2, Patrick Logan wrote: Now *that* is a pretty reasonable comparison. I would quibble here and there: I don't find JSON-LD as heavy-weight as you; the benefit of universal identifiers is an advantage in the domains I work in; and the whole graph vs. struct debate... it's a lot easier to represent a struct as a simple graph than it is to represent a graph as structs + conventions, etc. But those are all needs-based trade-offs. The comparison is fair. On Saturday, May 31, 2014 3:45:24 PM UTC-7, Jozef Wagner wrote: Well the suggestion to consider JSON-LD was really out of place. Compared to JSON-LD, EDN belongs to the category of lightweight, schemaless and streaming friendly data serialization formats. JSON-LD is closer to e.g. Turtle or RDF/XML. It serves a different purpose and has different goals than EDN. JSON-LD is a representation of labeled, directed graph of nodes [1]. The smallest thing you can represent in it is a graph of nodes. You may make analogy between IRI [2] node and EDN map, but note that in JSON-LD, every property must be a valid IRI. Besides other IRI nodes as a property values, JSON-LD supports integers, floats, strings, booleans and custom types through typed values, which is something like edn tagged elements but can be only applied to string values. JSON-LD has no built in support for nils and characters, and no support for random-access vectors. JSON-LD has a concept of unordered and ordered collections (which is an improvement compared to RDF [3]), which corresponds to EDN set and list types. While the motivation behind JSON-LD is to be a simple Microdata/RDFa alternative for web services, over engineered technologies lurks underneath and they sometimes leak through the JSON-LD facade. I'm pessimistic that it will slip (again) into unnecessary complex ontologies and rigid schemas no one wants to use. [1] http://www.w3.org/TR/json-ld/#data-model-overview [2] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri [3] see section 'Decision 3' at http://manu.sporny.org/2014/json-ld-origins-2/ Jozef On Saturday, May 31, 2014 5:32:55 PM UTC+2, Patrick Logan wrote: Brilliant analysis. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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 binding for OrientDB
Hi Zubair, It seems to be more then active: https://github.com/orientechnologies/orientdb/blob/master/history.txt This is the most recent release. But the bindings for many languages seems so outdated. :( Regards On Monday, May 26, 2014 11:11:47 AM UTC-3, Zubair Quraishi wrote: Hi Eduardo, Is this Clojure OrientDB project still Active? Thanks Zubair On Tuesday, August 2, 2011 3:17:33 AM UTC+2, eduardoejp wrote: I have been working on this library for a little while and I would like to present it to you: https://github.com/eduardoejp/clj-orient I hope this can be of help for the Clojure and OrientDB communities. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
Top-down code in namspaces
Hi everyone, I'm looking to get some opinions on code style. Specifically, I like to write my code in a top-down. What I mean by that is that within a file the highest-level functions sit at the top, and are implemented in terms of lower-level functions further down. The idea is that through sensible naming, a reader should be able to stop reading at any point and still know what's going on. I was recently watching the prismatic schema presentation from the 2013 conj, and noticed they too promoted having a public section at the top of the namespace. The problem now is because of the single-pass nature of clojure's evaluation - simply writing code like this doesn't actually work. There's a few approaches i've seen from reading other's code: 1. Have an impl namespace which contains all of the helper functions for the public interface 2. Make use of (declare) forms where necessary to improve forward readability 3. Don't worry about source order, just have the api functions further down the file and live with it Some other options I considered include making really heavy use of (declare), or even defining some sort of (eval-reversed) macro which runs the code backwards. I'd like to know if people are experiencing this issue, and how you all are resolving it? Cheers Glen -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Top-down code in namspaces
a) move out helpers or core code out of the API name space b) tag stuff left not part of the API as private in the API name space c) keep the API at the bottom d) do the above iteratively as code evolves So far it's been workable ( 2 locs so far). Not too much name space switches while improving or fixing code. Luc P Hi everyone, I'm looking to get some opinions on code style. Specifically, I like to write my code in a top-down. What I mean by that is that within a file the highest-level functions sit at the top, and are implemented in terms of lower-level functions further down. The idea is that through sensible naming, a reader should be able to stop reading at any point and still know what's going on. I was recently watching the prismatic schema presentation from the 2013 conj, and noticed they too promoted having a public section at the top of the namespace. The problem now is because of the single-pass nature of clojure's evaluation - simply writing code like this doesn't actually work. There's a few approaches i've seen from reading other's code: 1. Have an impl namespace which contains all of the helper functions for the public interface 2. Make use of (declare) forms where necessary to improve forward readability 3. Don't worry about source order, just have the api functions further down the file and live with it Some other options I considered include making really heavy use of (declare), or even defining some sort of (eval-reversed) macro which runs the code backwards. I'd like to know if people are experiencing this issue, and how you all are resolving it? Cheers Glen -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
text processing function
I am doing some text processing using clojure and attempting to extract a
person's name by regex and then assign it to a map. The result I get takes
one of several forms:
nil (if i can't find the name)
[fullname]
[fullname lastname]
[fullname lastname firstname]
[fullname lastname firstname middlename]
now, basically want to assign these entries to a map like so {:fullname
some name, :lastname some name, etc...}
if there is no entry than I would like to assign it as nil, e.g. {:fullname
nil, lastname nil, etc...}
I want to code this in the most proper way. I am thinking I need to define
a function that works differently based on how long the vector is? How do
I turn the contents of the vector into function arguments?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: text processing function
Array destructuring appears to provide what you want with respect to nils
(note the extra set of square braces within the argument list):
(defn make-map
[[fullname lastname firstname middlename]]
{:fullname fullname
:lastname lastname
:firstname firstname
:middlename middlename})
(make-map [John Lou Doe Doe John Lou])
;= {:fullname John Lou Doe, :lastname Doe, :firstname John,
:middlename Lou}
(make-map [John Lou Doe Doe John])
;= {:fullname John Lou Doe, :lastname Doe, :firstname John,
:middlename nil}
(make-map [John Lou Doe Doe])
;= {:fullname John Lou Doe, :lastname Doe, :firstname nil, :middlename
nil}
(make-map [John Lou Doe])
;= {:fullname John Lou Doe, :lastname nil, :firstname nil, :middlename
nil}
(make-map [])
;= {:fullname nil, :lastname nil, :firstname nil, :middlename nil}
(make-map nil)
;= {:fullname nil, :lastname nil, :firstname nil, :middlename nil}
On Sunday, June 1, 2014 12:09:35 PM UTC-4, Glen Rubin wrote:
I am doing some text processing using clojure and attempting to extract a
person's name by regex and then assign it to a map. The result I get takes
one of several forms:
nil (if i can't find the name)
[fullname]
[fullname lastname]
[fullname lastname firstname]
[fullname lastname firstname middlename]
now, basically want to assign these entries to a map like so {:fullname
some name, :lastname some name, etc...}
if there is no entry than I would like to assign it as nil, e.g.
{:fullname nil, lastname nil, etc...}
I want to code this in the most proper way. I am thinking I need to
define a function that works differently based on how long the vector is?
How do I turn the contents of the vector into function arguments?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: text processing function
What about:
{:fullname (get result 0), :lastname (get result 1), :firstname (get result
2), :middlename (get result 3)}
If the get function can't find a result, it returns nil.
- James
On 1 June 2014 17:09, Glen Rubin rubing...@gmail.com wrote:
I am doing some text processing using clojure and attempting to extract a
person's name by regex and then assign it to a map. The result I get takes
one of several forms:
nil (if i can't find the name)
[fullname]
[fullname lastname]
[fullname lastname firstname]
[fullname lastname firstname middlename]
now, basically want to assign these entries to a map like so {:fullname
some name, :lastname some name, etc...}
if there is no entry than I would like to assign it as nil, e.g.
{:fullname nil, lastname nil, etc...}
I want to code this in the most proper way. I am thinking I need to
define a function that works differently based on how long the vector is?
How do I turn the contents of the vector into function arguments?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] JSON/CLJ/EDN comparison table
All things being equal, I would prefer a Lisp-based format rather than JSON, yes. (My involvement with that approach goes back 25 years: https://en.wikipedia.org/wiki/Electronic_Design_Interchange_Format ) But EDN + this convention would be something only my software would support, and anyone I could convince. JSON-LD is a fairly simple standard, already has a good and growing level of support, and because it is just JSON can be used directly by a lot of software without any awareness of the LD aspect. Everything is a compromise. Pro's and con's all around. On Sunday, June 1, 2014 12:04:50 AM UTC-7, Jozef Wagner wrote: How about format which can represent either graph or structure, depending on users needs? I would argue that EDN is more suitable for linked data than JSON is. Its support for identifiers and tagged elements allows for pretty straightforward serialization of linked data. See https://gist.github.com/wagjo/d6419a289a64c503010c https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fwagjo%2Fd6419a289a64c503010csa=Dsntz=1usg=AFQjCNH4biGF4OXzCJVVQ4AUHE_H_srSJg for one possible approach. Jozef On Sunday, June 1, 2014 2:18:00 AM UTC+2, Patrick Logan wrote: Now *that* is a pretty reasonable comparison. I would quibble here and there: I don't find JSON-LD as heavy-weight as you; the benefit of universal identifiers is an advantage in the domains I work in; and the whole graph vs. struct debate... it's a lot easier to represent a struct as a simple graph than it is to represent a graph as structs + conventions, etc. But those are all needs-based trade-offs. The comparison is fair. On Saturday, May 31, 2014 3:45:24 PM UTC-7, Jozef Wagner wrote: Well the suggestion to consider JSON-LD was really out of place. Compared to JSON-LD, EDN belongs to the category of lightweight, schemaless and streaming friendly data serialization formats. JSON-LD is closer to e.g. Turtle or RDF/XML. It serves a different purpose and has different goals than EDN. JSON-LD is a representation of labeled, directed graph of nodes [1]. The smallest thing you can represent in it is a graph of nodes. You may make analogy between IRI [2] node and EDN map, but note that in JSON-LD, every property must be a valid IRI. Besides other IRI nodes as a property values, JSON-LD supports integers, floats, strings, booleans and custom types through typed values, which is something like edn tagged elements but can be only applied to string values. JSON-LD has no built in support for nils and characters, and no support for random-access vectors. JSON-LD has a concept of unordered and ordered collections (which is an improvement compared to RDF [3]), which corresponds to EDN set and list types. While the motivation behind JSON-LD is to be a simple Microdata/RDFa alternative for web services, over engineered technologies lurks underneath and they sometimes leak through the JSON-LD facade. I'm pessimistic that it will slip (again) into unnecessary complex ontologies and rigid schemas no one wants to use. [1] http://www.w3.org/TR/json-ld/#data-model-overview [2] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri [3] see section 'Decision 3' at http://manu.sporny.org/2014/json-ld-origins-2/ Jozef On Saturday, May 31, 2014 5:32:55 PM UTC+2, Patrick Logan wrote: Brilliant analysis. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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 binding for OrientDB
clj-orient hasn't been updated in 2 years, while OrientDB is in very active development. Therefore, I would say that it is now quite dated. A good alternative would be to use the Tinkepop API and looking into https://github.com/clojurewerkz/archimedes - OrientDB has transitioned to using Tinkerpop as its native graph API anyway, so if you want to use the graph abstractions, then Tinkerpop seems like the best choice. On the other hand, if, like me, you are more interested in the document database (that happens to have fantastic graph-like direct links between documents), then the Java API would probably be more suitable. On 1 June 2014 15:34, Paulo Suzart paulosuz...@gmail.com wrote: Hi Zubair, It seems to be more then active: https://github.com/orientechnologies/orientdb/blob/master/history.txt This is the most recent release. But the bindings for many languages seems so outdated. :( Regards On Monday, May 26, 2014 11:11:47 AM UTC-3, Zubair Quraishi wrote: Hi Eduardo, Is this Clojure OrientDB project still Active? Thanks Zubair On Tuesday, August 2, 2011 3:17:33 AM UTC+2, eduardoejp wrote: I have been working on this library for a little while and I would like to present it to you: https://github.com/eduardoejp/clj-orient I hope this can be of help for the Clojure and OrientDB communities. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: text processing function
These are both very good and usable answers. Thank you both!
On Sunday, June 1, 2014 9:36:58 AM UTC-7, James Reeves wrote:
What about:
{:fullname (get result 0), :lastname (get result 1), :firstname (get
result 2), :middlename (get result 3)}
If the get function can't find a result, it returns nil.
- James
On 1 June 2014 17:09, Glen Rubin rubi...@gmail.com javascript: wrote:
I am doing some text processing using clojure and attempting to extract a
person's name by regex and then assign it to a map. The result I get takes
one of several forms:
nil (if i can't find the name)
[fullname]
[fullname lastname]
[fullname lastname firstname]
[fullname lastname firstname middlename]
now, basically want to assign these entries to a map like so {:fullname
some name, :lastname some name, etc...}
if there is no entry than I would like to assign it as nil, e.g.
{:fullname nil, lastname nil, etc...}
I want to code this in the most proper way. I am thinking I need to
define a function that works differently based on how long the vector is?
How do I turn the contents of the vector into function arguments?
Thanks!
--
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.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: text processing function
Just golfing for fun:
(apply hash-map (interleave [:fullname :lastname :firstname :middlename]
(concat [John Lou Doe Doe John] (repeat nil
;= {:firstname John, :lastname Doe, :middlename nil, :fullname John
Lou Doe}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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] Eastwood the Clojure lint tool version 0.1.3
Eastwood is a Clojure lint tool. It analyzes Clojure source code in Leiningen projects, reporting things that may be errors. Installation instructions are in the documentation here: https://github.com/jonase/eastwood/#installation--quick-usage The previous release was 0.1.2 in April 2014. Updates since then are described in the change log here: https://github.com/jonase/eastwood/blob/master/changes.md#changes-from-version-012-to-013 https://github.com/jonase/eastwood/blob/master/changes.md#changes-from-version-010-to-011 Probably the most noticeable changes for Eastwood users will be the following. The last bullet item is especially significant for Eastwood users, because it means that there should no longer be any conflicts between different versions of Clojure contrib libraries in the dependencies of your project being linted, and those used by Eastwood. - Added file name to all linter warnings. Issue #64 https://github.com/jonase/eastwood/issues/64. - Added column numbers to :redefd-vars warnings. - Handle ./ at beginning of :source-paths or :test-paths dir names. Fixes issue #66 https://github.com/jonase/eastwood/issues/66. - Most of the Clojure contrib libraries upon which Eastwood depends are now copied into Eastwood itself, and then renamed to have different namespace names. This helps to avoid potential conflicts between the version used by Eastwood, and the version used by Clojure projects being linted. Fixes issue #67 https://github.com/jonase/eastwood/issues/67. Below is the description Eastwood from the January 2014 release: For example, did you know that if you use clojure.test to write tests, and have multiple deftest definitions in the same namespace with the same name, then the tests in all but the last deftest will never be run, whether those tests would pass or fail? Eastwood can find those duplicate names, as well as other occurrences of the same Var name defined more than once. Eastwood can also warn about misplaced doc strings, calling deprecated functions or Java methods, expressions that are suspicious because they always return the same value (e.g. (= expr) is always true), expressions whose return value is not used and appear to have no side effects, and a few others. See the documentation linked above for a complete list. Jonas Enlund wrote the original version of Eastwood with the help of several other contributors. Version 0.1.1 is an update by Jonas, Nicola Mometto, and myself. It uses the new Clojure contrib libraries tools.reader for reading the code, and tools.analyzer and tools.analyzer.jvm for parsing the source into abstract syntax trees, making it straightforward to write many of the linters. Thanks especially to Nicola Mometto for tireless enhancements and bug fixes to those libraries. You can file issues on the Github issue tracker if you encounter problems, but please read the Known Issues section of the documentation before filing problems. Several issues have already been discovered, and their causes documented, while testing Eastwood on most of the Clojure contrib libraries, Clojure itself, and over 35 other open source libraries. Go squash some bugs! Jonas Enlund, Nicola Mometto, and Andy Fingerhut -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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] Historian : drop-in state management for React (Om / Reagent / ...)
Hello there! https://github.com/Frozenlock/historian One of the big sales pitch of React.js (and cljs immutable data structure) is how it enables us to easily make 'undo'. Here's a library that does just that. You tell it which atom(s) you want to be able to undo/redo and it will keep track of them. For example: (def my-state (atom ABC)) (hist/record! my-state :my-state) ;; then change the state of your atom (reset! my-state DEF) @my-state= DEF (hist/undo!) @my-state= ABC (hist/redo!) @my-state= DEF ;; tada! Cheers! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: text processing function
Hey Glen, it appears that zipmap most directly corresponds to your initial
question.
The only complicating aspect is your desire for nils, which (concat result
(repeat nil)) addresses.
(zipmap [:fullname :lastname :firstname :middlename] (concat result
(repeat nil)))
If it weren't for the need for nils,
(zipmap [:fullname :lastname :firstname :middlename] result)
is simple and noise-free. Note that the nils are unnecessary if later
using map destructuring:
(defn use-names [{:keys [fullname lastname firstname middlename]}]
(println fullname lastname firstname middlename))
For example, nils are generated at call time for you by the map
destructuring:
(use-names (zipmap [:fullname :lastname :firstname :middlename] [John
Lou Doe Doe John]))
;= John Lou Doe Doe John nil
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: help with the lawyers?
When dealing with lawyers, I find it best to keep things simple: Is there no other project in the entire federal government developed with Eclipse or some other EPL licensed code? Somehow, I find that hard to believe. On Friday, May 30, 2014 at 6:31, rcg wrote: Hello; Developing web site for government using Clojure on back end- lawyers reviewing EPL had objections. Would appreciate any advice on how to deal with them. Again- web site, not distributing or modifying Clojure. I have no expertise with Open Source Licenses or lawyer-ese jargon. These are the specific objections- do they even apply in the context of web services? 1. This Agreement is governed by the laws of the State of New York. Not acceptable: The federal government cannot agree to be bound by state law. 2. Each party waives its rights to a jury trial in any resulting litigation. Not acceptable: Only DOJ can control litigation. 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 (mailto:clojure@googlegroups.com) Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com (mailto: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.
