Clojure data science community update - Aug. 2022 - Kira McLean

[Daniel Slutsky]

This Scicloj community update by Kira McLean is clarifying the intent of 
some current community efforts around Clojure & Data.

https://www.youtube.com/watch?v=63-KGa3Flac

Among other things, it is telling how Scicloj is gradually opening up to 
address not only Clojurians, not just programmers, but also "people with 
data" of various backgrounds.

Kira's Clojure Data Cookbook is reviving some past documentation projects, 
and is such an important step in the direction we need, I think.

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

Re: Digest for clojure@googlegroups.com - 1 update in 1 topic

['Harvie Griffith Jr.' via Clojure]

The tests mentioned in the Changes have better examples. This link specifically:

https://clojure.atlassian.net/browse/CLJ-2685

Sam Griffith
stayp...@mac.com
512-771-8153

Sent from my iPhone



> On Mar 23, 2022, at 6:23 PM, clojure@googlegroups.com wrote:
> 
> 
> clojure@googlegroups.com  Google Groups   
> Topic digest 
> View all topics
> Clojure 1.11 is now available! - 1 Update
> Clojure 1.11 is now available!
> Mark Engelberg : Mar 22 10:30PM -0700 
> 
> Exciting! Thanks for the new release.
>  
> Where can I find more information about the new iteration function? The
> docstring alone isn't sufficient for me to understand how to use it
> effectively.
>  
> On Tue, Mar 22, 2022 at 9:22 AM Alex Miller 
> wrote:
>  
> Back to top
> You received this digest because you're subscribed to updates for this group. 
> You can change your settings on the group membership page.
> To unsubscribe from this group and stop receiving emails from it send an 
> email to clojure+unsubscr...@googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/2CC6611F-0C28-472C-873D-0B54E53A8034%40mac.com.

[ANN] Dutch Clojure Day 2017 Update, and Final Call for RFP

[Vijay Kiran]

Hello Everyone,

The team behind Dutch Clojure Day is hard at work and I'd like to share 
some quick updates :

- We have a nice venue confirmed in the centre of Amsterdam - http://tq.co 
- We have some great sponsors for our event this time:
• http://www.adgoji.com - *Platinum*
• https://juxt.pro/index.html - Silver
• https://infi.nl  - Silver
• http://www.functionalbytes.nl - Drinks

Our RFP is going to close on 31st January, if you want to submit your talk 
proposal, hurry now and submit via Google form 
 :) 

We will be publishing speaker line-up in the first half of February!

For more details and tickets keep checking http://clojuredays.org and/or 
follow us on twitter https://twitter.com/clojuredays


Looking forward to see you in Amsterdam,
DCD Organisers



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 infrastructure update

[Alex Miller]

Yes, would very much like to have these under https.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 infrastructure update

[John Jacobsen]

Great news, Alex.  

One question not on your list: are there any plans to put JIRA behind 
HTTPS?  I went to change my password recently and noticed my 
username/password would be sent in the clear.
>
>
Thanks for all the work you do for the community.

John J.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 infrastructure update

[Alex Miller]

I have been working with our hosting provider (thanks Contegix!) to upgrade
the hosts underneath *dev.clojure.org * (JIRA and
confluence) and *build.clojure.org * (Hudson).
The new hosts are much more recent versions of the OS and seem to be faster.

I cut *dev* over tonight. There were about 7 ticket changes in CLJS that
were lost due to when we copied the data today but I have manually
recreated those on the new version. afaik, everything is done with this
migration other than re-enabling notification emails on the new box which
will happen next. If you experience anything strange, please let me know.
Ideally, everything should look and work exactly the same.

*build* will take a bit longer before I make the switch. We upgraded from
the ancient version of Hudson we were on (which was blocking the ability to
do contrib builds with cljc) to newest version of Jenkins. Significant
portions of the build system are working again (kudos to Jenkins
community), but I still have some issues to work through and things to
test. Hopefully that will be next week.

I would dearly love to upgrade the JIRA/Confluence/Crowd versions we're on
too, but this is a significant undertaking intertwined with software
licensing and hosting considerations. Over the course of the last year, I
have spent several full weeks worth of time analyzing aspects of this and
doing (largely failing) test runs. It will get done eventually, but it's
not ready yet.

Alex

PS. By sending this I risk opening up questions about infrastructure and
other choices, so let me preempt some of those. :) We have no plans at this
time to: use anything other than jira or confluence, accept github PRs,
change the CA, change the license, or change the contribution model. These
topics have been rehashed on the mailing list a number of times and I don't
think anything has changed such that it's worth doing so again. If you want
to bend my ear, I will be at the Conj. :)

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

Re: How to update state in a webapp

[babysnakes]

Thanks Brian, nice idea :)

I also added load/save functionality from the atom when reloading the 
environment in development.


On Sunday, May 29, 2016 at 2:57:56 PM UTC+3, Brian Platz wrote:
>
> In a web-app you probably want the thread safety an atom provides, so it 
> would be a good choice.
>
> You can include a reference to your atom in your system config if you want 
> to retain the reloaded-like / dependency injection pattern:
>
> (def changing-config (atom {}))
>
> ;; system-map
> (def sys-map
>  {:a "a"
>   :b 42
>   :c changing-config})
>
> (defn my-handler
>  [handler sys-map]
>  (fn [req] {:status 200 :body @(:c sys-map)}))
>
>
> On Saturday, May 28, 2016 at 2:16:32 PM UTC-4, babysnakes wrote:
>>
>> Hey all,
>>
>> I don't have a lot of experience with clojure but I did write a few small 
>> services in clojure. Until now the state of the services I wrote were 
>> static so I constructed a system map (more or less following Stuart 
>> Sierra's reloaded workflow - without using the component framework) and 
>> injected it to the various handlers via middleware closure. This works 
>> great when the state is static. Now I have to write a small service where 
>> the state should be updated (I have to periodically pull new 
>> configurations). The first place I can think of to put this state is in a 
>> global atom, but I was wondering if there's a pattern that allows me to 
>> dynamically update global state without using global atom.
>>
>> Thanks in advance
>>
>> Haim
>>
>

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

Re: How to update state in a webapp

[Brian Platz]

In a web-app you probably want the thread safety an atom provides, so it 
would be a good choice.

You can include a reference to your atom in your system config if you want 
to retain the reloaded-like / dependency injection pattern:

(def changing-config (atom {}))

;; system-map
(def sys-map
 {:a "a"
  :b 42
  :c changing-config})

(defn my-handler
 [handler sys-map]
 (fn [req] {:status 200 :body @(:c sys-map)}))


On Saturday, May 28, 2016 at 2:16:32 PM UTC-4, babysnakes wrote:
>
> Hey all,
>
> I don't have a lot of experience with clojure but I did write a few small 
> services in clojure. Until now the state of the services I wrote were 
> static so I constructed a system map (more or less following Stuart 
> Sierra's reloaded workflow - without using the component framework) and 
> injected it to the various handlers via middleware closure. This works 
> great when the state is static. Now I have to write a small service where 
> the state should be updated (I have to periodically pull new 
> configurations). The first place I can think of to put this state is in a 
> global atom, but I was wondering if there's a pattern that allows me to 
> dynamically update global state without using global atom.
>
> Thanks in advance
>
> Haim
>

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

How to update state in a webapp

[babysnakes]

Hey all,

I don't have a lot of experience with clojure but I did write a few small 
services in clojure. Until now the state of the services I wrote were 
static so I constructed a system map (more or less following Stuart 
Sierra's reloaded workflow - without using the component framework) and 
injected it to the various handlers via middleware closure. This works 
great when the state is static. Now I have to write a small service where 
the state should be updated (I have to periodically pull new 
configurations). The first place I can think of to put this state is in a 
global atom, but I was wondering if there's a pattern that allows me to 
dynamically update global state without using global atom.

Thanks in advance

Haim

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Possible to override assoc-in or update-in?

[JvJ]

That was actually the example I used to implement this.  As it turns out, 
assoc-in, update-in, etc. work on anything that supports assoc.

On Wednesday, 20 April 2016 13:39:40 UTC-7, Andy Fingerhut wrote:
>
> I don't know if assoc-in etc. work on the clojure.data.priority-map data 
> structures, but your questions at least reminded me of the implementation 
> of that data structure, which uses two maps internally to maintain the 
> priority map, and keeps their contents consistent with each other [1].  It 
> also implements all of the methods that regular Clojure maps do, so all 
> normal map operations work on priority-maps, too.  Its implementation may 
> give you some ideas for one way to do what you are hoping for.
>
> Andy
>
> [1] https://github.com/clojure/data.priority-map
>
>
> On Wed, Apr 20, 2016 at 10:18 AM, JvJ > 
> wrote:
>
>> I had a bit of trouble fully understanding the EAV concept or the pldb 
>> code.  There's not a good overview of EAV architecture that doesn't focus 
>> on databases.  I'm not much of a DB guy.  So, I'm not sure if I got the 
>> essence of the EAV pattern with my new implementation, but here it is 
>> anyway:
>>
>> I think the legacy of object-orientation was so embedded in my brain that 
>> I failed to see the simple solution: rows and columns.  I was thinking of 
>> items in the map as "containers" of items, when I could have been thinking 
>> of them as rows in a table.  The table is effectively a sparse matrix.
>>
>> The implementation's main map is of type { [row col]->Item }.  It also 
>> uses two other maps: row-idx:{row->{col item}} and 
>> col-idx:{col->{row->item}}.
>>
>> Whenever an assoc occurs on key [r c] and item i, here is how the values 
>> are updated:
>> main-map<-(assoc main-map [r c] i)
>> row-idx<-(assoc-in row-idx [r c] i)
>> col-idx<-(assoc-in col-idx [c r] i)
>>
>> This way, we efficiently maintain row-idx and col-idx, two complementary 
>> nested maps that mirror each others' structure.
>>
>> Did I get close to the EAV pattern here?  Also, I wonder if this approach 
>> is scalable to higher-dimensional tables, for instance where each item is 
>> associated with a 3-tuple.
>>
>> On Monday, 18 April 2016 17:18:45 UTC-7, tbc++ wrote:
>>>
>>> Core.logic has one such implementation: 
>>> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
>>>  
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fcore.logic%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fclojure%2Fclojure%2Fcore%2Flogic%2Fpldb.clj&sa=D&sntz=1&usg=AFQjCNGjJWdatQscPmDIx3xpBMuwPmOH7A>
>>>  
>>> might be a place to start. 
>>>
>>> On Mon, Apr 18, 2016 at 5:35 PM, JvJ  wrote:
>>>
>>>> Can you point me to a working example of one of these structures?
>>>>
>>>> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>>>>
>>>>> And by "fairly common these days", I mean that I run into this sort of 
>>>>> structure a lot in clojure with anything that is trying to logic or query 
>>>>> operations. Probably isn't that common outside of projects in that 
>>>>> domain. 
>>>>>
>>>>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge >>>> > wrote:
>>>>>
>>>>>> assoc-in is defined in terms of assoc: 
>>>>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>>>>
>>>>>> And this structure is fairly common these days, it's basically a 
>>>>>> index of tuples [e a v], and you're creating a eav index and then an av 
>>>>>> index. Datomic does this same sort of thing, for the datom [e a v t] it 
>>>>>> creates indices for :eavt :avet and a few others that escape my memory 
>>>>>> at 
>>>>>> the moment.  
>>>>>>
>>>>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:
>>>>>>
>>>>>>> I'm implementing a map data structure where most of the values are 
>>>>>>> maps or sets, and these values can be cross-indexed by the keys they 
>>>>>>> contain.  I don't know if it already has a name, but I'm calling it a 
>>>>>>> cross-map.  It's similar to a two-way map, but they're not the same 
>>>>>>> thing.
>

Re: Possible to override assoc-in or update-in?

[Andy Fingerhut]

I don't know if assoc-in etc. work on the clojure.data.priority-map data
structures, but your questions at least reminded me of the implementation
of that data structure, which uses two maps internally to maintain the
priority map, and keeps their contents consistent with each other [1].  It
also implements all of the methods that regular Clojure maps do, so all
normal map operations work on priority-maps, too.  Its implementation may
give you some ideas for one way to do what you are hoping for.

Andy

[1] https://github.com/clojure/data.priority-map


On Wed, Apr 20, 2016 at 10:18 AM, JvJ  wrote:

> I had a bit of trouble fully understanding the EAV concept or the pldb
> code.  There's not a good overview of EAV architecture that doesn't focus
> on databases.  I'm not much of a DB guy.  So, I'm not sure if I got the
> essence of the EAV pattern with my new implementation, but here it is
> anyway:
>
> I think the legacy of object-orientation was so embedded in my brain that
> I failed to see the simple solution: rows and columns.  I was thinking of
> items in the map as "containers" of items, when I could have been thinking
> of them as rows in a table.  The table is effectively a sparse matrix.
>
> The implementation's main map is of type { [row col]->Item }.  It also
> uses two other maps: row-idx:{row->{col item}} and
> col-idx:{col->{row->item}}.
>
> Whenever an assoc occurs on key [r c] and item i, here is how the values
> are updated:
> main-map<-(assoc main-map [r c] i)
> row-idx<-(assoc-in row-idx [r c] i)
> col-idx<-(assoc-in col-idx [c r] i)
>
> This way, we efficiently maintain row-idx and col-idx, two complementary
> nested maps that mirror each others' structure.
>
> Did I get close to the EAV pattern here?  Also, I wonder if this approach
> is scalable to higher-dimensional tables, for instance where each item is
> associated with a 3-tuple.
>
> On Monday, 18 April 2016 17:18:45 UTC-7, tbc++ wrote:
>>
>> Core.logic has one such implementation:
>> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fcore.logic%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fclojure%2Fclojure%2Fcore%2Flogic%2Fpldb.clj&sa=D&sntz=1&usg=AFQjCNGjJWdatQscPmDIx3xpBMuwPmOH7A>
>> might be a place to start.
>>
>> On Mon, Apr 18, 2016 at 5:35 PM, JvJ  wrote:
>>
>>> Can you point me to a working example of one of these structures?
>>>
>>> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>>>
>>>> And by "fairly common these days", I mean that I run into this sort of
>>>> structure a lot in clojure with anything that is trying to logic or query
>>>> operations. Probably isn't that common outside of projects in that domain.
>>>>
>>>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge 
>>>> wrote:
>>>>
>>>>> assoc-in is defined in terms of assoc:
>>>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>>>
>>>>> And this structure is fairly common these days, it's basically a index
>>>>> of tuples [e a v], and you're creating a eav index and then an av index.
>>>>> Datomic does this same sort of thing, for the datom [e a v t] it creates
>>>>> indices for :eavt :avet and a few others that escape my memory at the
>>>>> moment.
>>>>>
>>>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:
>>>>>
>>>>>> I'm implementing a map data structure where most of the values are
>>>>>> maps or sets, and these values can be cross-indexed by the keys they
>>>>>> contain.  I don't know if it already has a name, but I'm calling it a
>>>>>> cross-map.  It's similar to a two-way map, but they're not the same 
>>>>>> thing.
>>>>>>
>>>>>> For instance, a common operation would be something like "give me all
>>>>>> values of this map that contain the key :a."
>>>>>>
>>>>>> In order to do this efficiently, I'm maintaining a second map that
>>>>>> maps keys in the values of the main map to keys of the main map whose
>>>>>> values contain that key.
>>>>>>
>>>>>> If that sounds confusing, consider this:
>>>>>> main-map:
>>>>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:

Re: Possible to override assoc-in or update-in?

[JvJ]

I had a bit of trouble fully understanding the EAV concept or the pldb 
code.  There's not a good overview of EAV architecture that doesn't focus 
on databases.  I'm not much of a DB guy.  So, I'm not sure if I got the 
essence of the EAV pattern with my new implementation, but here it is 
anyway:

I think the legacy of object-orientation was so embedded in my brain that I 
failed to see the simple solution: rows and columns.  I was thinking of 
items in the map as "containers" of items, when I could have been thinking 
of them as rows in a table.  The table is effectively a sparse matrix.

The implementation's main map is of type { [row col]->Item }.  It also uses 
two other maps: row-idx:{row->{col item}} and col-idx:{col->{row->item}}.

Whenever an assoc occurs on key [r c] and item i, here is how the values 
are updated:
main-map<-(assoc main-map [r c] i)
row-idx<-(assoc-in row-idx [r c] i)
col-idx<-(assoc-in col-idx [c r] i)

This way, we efficiently maintain row-idx and col-idx, two complementary 
nested maps that mirror each others' structure.

Did I get close to the EAV pattern here?  Also, I wonder if this approach 
is scalable to higher-dimensional tables, for instance where each item is 
associated with a 3-tuple.

On Monday, 18 April 2016 17:18:45 UTC-7, tbc++ wrote:
>
> Core.logic has one such implementation: 
> https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fcore.logic%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fclojure%2Fclojure%2Fcore%2Flogic%2Fpldb.clj&sa=D&sntz=1&usg=AFQjCNGjJWdatQscPmDIx3xpBMuwPmOH7A>
>  
> might be a place to start. 
>
> On Mon, Apr 18, 2016 at 5:35 PM, JvJ > 
> wrote:
>
>> Can you point me to a working example of one of these structures?
>>
>> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>>
>>> And by "fairly common these days", I mean that I run into this sort of 
>>> structure a lot in clojure with anything that is trying to logic or query 
>>> operations. Probably isn't that common outside of projects in that domain. 
>>>
>>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge  
>>> wrote:
>>>
>>>> assoc-in is defined in terms of assoc: 
>>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>>
>>>> And this structure is fairly common these days, it's basically a index 
>>>> of tuples [e a v], and you're creating a eav index and then an av index. 
>>>> Datomic does this same sort of thing, for the datom [e a v t] it creates 
>>>> indices for :eavt :avet and a few others that escape my memory at the 
>>>> moment.  
>>>>
>>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:
>>>>
>>>>> I'm implementing a map data structure where most of the values are 
>>>>> maps or sets, and these values can be cross-indexed by the keys they 
>>>>> contain.  I don't know if it already has a name, but I'm calling it a 
>>>>> cross-map.  It's similar to a two-way map, but they're not the same thing.
>>>>>
>>>>> For instance, a common operation would be something like "give me all 
>>>>> values of this map that contain the key :a."
>>>>>
>>>>> In order to do this efficiently, I'm maintaining a second map that 
>>>>> maps keys in the values of the main map to keys of the main map whose 
>>>>> values contain that key.
>>>>>
>>>>> If that sounds confusing, consider this:
>>>>> main-map:
>>>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>>>>
>>>>> Corresponding cross-indices:
>>>>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>>>>
>>>>> As you can see, each key maintains references to those entries where 
>>>>> it is found.
>>>>>
>>>>> When a nested update occurs that adds an entry to one of the main 
>>>>> map's values, the efficient thing to do would be to simply conj that new 
>>>>> key onto its corresponding cross-index set.
>>>>>
>>>>> However, I am trying to implement this as a clojure IPersistentMap, 
>>>>> and the only method I can override is assoc, not assoc-in.
>>>>>
>>>>> Using regular assoc, I would have to compare the old value's keys to 
>>>>> the new v

Re: Possible to override assoc-in or update-in?

[Timothy Baldridge]

Core.logic has one such implementation:
https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/pldb.clj
might be a place to start.

On Mon, Apr 18, 2016 at 5:35 PM, JvJ  wrote:

> Can you point me to a working example of one of these structures?
>
> On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>>
>> And by "fairly common these days", I mean that I run into this sort of
>> structure a lot in clojure with anything that is trying to logic or query
>> operations. Probably isn't that common outside of projects in that domain.
>>
>> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge 
>> wrote:
>>
>>> assoc-in is defined in terms of assoc:
>>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>>
>>> And this structure is fairly common these days, it's basically a index
>>> of tuples [e a v], and you're creating a eav index and then an av index.
>>> Datomic does this same sort of thing, for the datom [e a v t] it creates
>>> indices for :eavt :avet and a few others that escape my memory at the
>>> moment.
>>>
>>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:
>>>
>>>> I'm implementing a map data structure where most of the values are maps
>>>> or sets, and these values can be cross-indexed by the keys they contain.  I
>>>> don't know if it already has a name, but I'm calling it a cross-map.  It's
>>>> similar to a two-way map, but they're not the same thing.
>>>>
>>>> For instance, a common operation would be something like "give me all
>>>> values of this map that contain the key :a."
>>>>
>>>> In order to do this efficiently, I'm maintaining a second map that maps
>>>> keys in the values of the main map to keys of the main map whose values
>>>> contain that key.
>>>>
>>>> If that sounds confusing, consider this:
>>>> main-map:
>>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>>>
>>>> Corresponding cross-indices:
>>>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>>>
>>>> As you can see, each key maintains references to those entries where it
>>>> is found.
>>>>
>>>> When a nested update occurs that adds an entry to one of the main map's
>>>> values, the efficient thing to do would be to simply conj that new key onto
>>>> its corresponding cross-index set.
>>>>
>>>> However, I am trying to implement this as a clojure IPersistentMap, and
>>>> the only method I can override is assoc, not assoc-in.
>>>>
>>>> Using regular assoc, I would have to compare the old value's keys to
>>>> the new value's keys and find the set difference of the two, which is not
>>>> an O(1) operation.
>>>>
>>>> Is there any way to override the behaviour of nested associations or
>>>> updates?
>>>>
>>>> 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
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> “One of the main causes of the fall of the Roman Empire was that–lacking
>>> zero–they had no way to indicate successful termination of their C
>>> programs.”
>>> (Robert Firth)
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
> --
> You received this message because you are subscribed to the

Re: Possible to override assoc-in or update-in?

[JvJ]

Can you point me to a working example of one of these structures?

On Monday, 18 April 2016 16:30:17 UTC-7, tbc++ wrote:
>
> And by "fairly common these days", I mean that I run into this sort of 
> structure a lot in clojure with anything that is trying to logic or query 
> operations. Probably isn't that common outside of projects in that domain. 
>
> On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge  > wrote:
>
>> assoc-in is defined in terms of assoc: 
>> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>>
>> And this structure is fairly common these days, it's basically a index of 
>> tuples [e a v], and you're creating a eav index and then an av index. 
>> Datomic does this same sort of thing, for the datom [e a v t] it creates 
>> indices for :eavt :avet and a few others that escape my memory at the 
>> moment.  
>>
>> On Mon, Apr 18, 2016 at 5:08 PM, JvJ > 
>> wrote:
>>
>>> I'm implementing a map data structure where most of the values are maps 
>>> or sets, and these values can be cross-indexed by the keys they contain.  I 
>>> don't know if it already has a name, but I'm calling it a cross-map.  It's 
>>> similar to a two-way map, but they're not the same thing.
>>>
>>> For instance, a common operation would be something like "give me all 
>>> values of this map that contain the key :a."
>>>
>>> In order to do this efficiently, I'm maintaining a second map that maps 
>>> keys in the values of the main map to keys of the main map whose values 
>>> contain that key.
>>>
>>> If that sounds confusing, consider this:
>>> main-map:
>>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>>
>>> Corresponding cross-indices:
>>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>>
>>> As you can see, each key maintains references to those entries where it 
>>> is found.
>>>
>>> When a nested update occurs that adds an entry to one of the main map's 
>>> values, the efficient thing to do would be to simply conj that new key onto 
>>> its corresponding cross-index set.
>>>
>>> However, I am trying to implement this as a clojure IPersistentMap, and 
>>> the only method I can override is assoc, not assoc-in.
>>>
>>> Using regular assoc, I would have to compare the old value's keys to the 
>>> new value's keys and find the set difference of the two, which is not an 
>>> O(1) operation.
>>>
>>> Is there any way to override the behaviour of nested associations or 
>>> updates?
>>>
>>> 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 
>>> 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>> zero–they had no way to indicate successful termination of their C 
>> programs.”
>> (Robert Firth) 
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: Possible to override assoc-in or update-in?

[Timothy Baldridge]

And by "fairly common these days", I mean that I run into this sort of
structure a lot in clojure with anything that is trying to logic or query
operations. Probably isn't that common outside of projects in that domain.

On Mon, Apr 18, 2016 at 5:28 PM, Timothy Baldridge 
wrote:

> assoc-in is defined in terms of assoc:
> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901
>
> And this structure is fairly common these days, it's basically a index of
> tuples [e a v], and you're creating a eav index and then an av index.
> Datomic does this same sort of thing, for the datom [e a v t] it creates
> indices for :eavt :avet and a few others that escape my memory at the
> moment.
>
> On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:
>
>> I'm implementing a map data structure where most of the values are maps
>> or sets, and these values can be cross-indexed by the keys they contain.  I
>> don't know if it already has a name, but I'm calling it a cross-map.  It's
>> similar to a two-way map, but they're not the same thing.
>>
>> For instance, a common operation would be something like "give me all
>> values of this map that contain the key :a."
>>
>> In order to do this efficiently, I'm maintaining a second map that maps
>> keys in the values of the main map to keys of the main map whose values
>> contain that key.
>>
>> If that sounds confusing, consider this:
>> main-map:
>> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>>
>> Corresponding cross-indices:
>> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>>
>> As you can see, each key maintains references to those entries where it
>> is found.
>>
>> When a nested update occurs that adds an entry to one of the main map's
>> values, the efficient thing to do would be to simply conj that new key onto
>> its corresponding cross-index set.
>>
>> However, I am trying to implement this as a clojure IPersistentMap, and
>> the only method I can override is assoc, not assoc-in.
>>
>> Using regular assoc, I would have to compare the old value's keys to the
>> new value's keys and find the set difference of the two, which is not an
>> O(1) operation.
>>
>> Is there any way to override the behaviour of nested associations or
>> updates?
>>
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>



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

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

Re: Possible to override assoc-in or update-in?

[Timothy Baldridge]

assoc-in is defined in terms of assoc:
https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L5901

And this structure is fairly common these days, it's basically a index of
tuples [e a v], and you're creating a eav index and then an av index.
Datomic does this same sort of thing, for the datom [e a v t] it creates
indices for :eavt :avet and a few others that escape my memory at the
moment.

On Mon, Apr 18, 2016 at 5:08 PM, JvJ  wrote:

> I'm implementing a map data structure where most of the values are maps or
> sets, and these values can be cross-indexed by the keys they contain.  I
> don't know if it already has a name, but I'm calling it a cross-map.  It's
> similar to a two-way map, but they're not the same thing.
>
> For instance, a common operation would be something like "give me all
> values of this map that contain the key :a."
>
> In order to do this efficiently, I'm maintaining a second map that maps
> keys in the values of the main map to keys of the main map whose values
> contain that key.
>
> If that sounds confusing, consider this:
> main-map:
> {:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}
>
> Corresponding cross-indices:
> {:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}
>
> As you can see, each key maintains references to those entries where it is
> found.
>
> When a nested update occurs that adds an entry to one of the main map's
> values, the efficient thing to do would be to simply conj that new key onto
> its corresponding cross-index set.
>
> However, I am trying to implement this as a clojure IPersistentMap, and
> the only method I can override is assoc, not assoc-in.
>
> Using regular assoc, I would have to compare the old value's keys to the
> new value's keys and find the set difference of the two, which is not an
> O(1) operation.
>
> Is there any way to override the behaviour of nested associations or
> updates?
>
> 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.
>



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

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

Possible to override assoc-in or update-in?

[JvJ]

I'm implementing a map data structure where most of the values are maps or 
sets, and these values can be cross-indexed by the keys they contain.  I don't 
know if it already has a name, but I'm calling it a cross-map.  It's similar to 
a two-way map, but they're not the same thing.

For instance, a common operation would be something like "give me all values of 
this map that contain the key :a."

In order to do this efficiently, I'm maintaining a second map that maps keys in 
the values of the main map to keys of the main map whose values contain that 
key.

If that sounds confusing, consider this:
main-map: 
{:foo {:a 1 :b 2} :bar {:a 2 :c 4} :baz {:b 3 :c 5}}

Corresponding cross-indices:
{:a #{:foo :bar} :b #{:foo :baz} :c #{:bar :baz}}

As you can see, each key maintains references to those entries where it is 
found.

When a nested update occurs that adds an entry to one of the main map's values, 
the efficient thing to do would be to simply conj that new key onto its 
corresponding cross-index set.

However, I am trying to implement this as a clojure IPersistentMap, and the 
only method I can override is assoc, not assoc-in.

Using regular assoc, I would have to compare the old value's keys to the new 
value's keys and find the set difference of the two, which is not an O(1) 
operation.

Is there any way to override the behaviour of nested associations or updates?

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.

[DOCS] clojure.org Feb update

[Alex Miller]

I've been meaning to do an update on clojure.org, now that it's been a 
little over a month since we switched over to the new site.

I'm very happy with everything I've seen on the operational side - the 
Clojure web site has had much less down time than the old host, is serving 
the site much faster, and has generally made things far easier to manage. 
We've had a few spiky days where traffic was about double the normal and my 
only knowledge of that was in noticing it in the stats after the fact, 
rather than alarms going off. :)

Bigger changes since initial deploy (see commits for gory details):
- We now support https and are serving about 1/3 of our traffic now via 
https
- Added robots.txt and bumped the Google indexer to look at our sitemap - 
thanks Daniel Compton
- Added many contributors <http://clojure.org/community/contributors>
- Added many companies <http://clojure.org/community/companies> (ping me if 
you want to be added, or send a PR if you're a contributor)
- Added many events <http://clojure.org/community/events> (many already 
over!)
- Added more books <http://clojure.org/community/books> - thanks aadrian on 
github
- Added more resources <http://clojure.org/community/resources>, 
particularly video training - thanks aadrian on github
- Updated cheatsheet <http://clojure.org/api/cheatsheet> - thanks Andy 
Fingerhut
- Added contrib library descriptions <http://clojure.org/api/api> - 
thanks ZhiFeng Hu
- Added comparators <http://clojure.org/guides/comparators> guide - thanks 
Andy Fingerhut and Jose Donizetti
- Added reader conditionals <http://clojure.org/guides/reader_conditionals> 
guide - thanks Daniel Compton
- Added threading macros <http://clojure.org/guides/threading_macros> guide 
- thanks Paulus Esterhazy
- Updated latest Clojure release from 1.7 to 1.8, added docs on socket 
server 
<http://clojure.org/reference/repl_and_main#_launching_a_socket_server> and 
direct 
linking <http://clojure.org/reference/compilation#directlinking>
- Periodically moving older news items from the old clojure.com blog (which 
is deprecated and moving towards decommissioning) into the news area
- Closed 26 PRs and 30 issues

The clojure.org site is open for contributions and there are lots of ways 
you could help if you want to add content. There are a number of requests 
for open content 
<https://github.com/clojure/clojure-site/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Abacklog+label%3Acontent+no%3Aassignee+>
 
if someone is interested. For more on contributing to the site, see: 
http://clojure.org/community/contributing_site.


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

data.xml update

[Herwig Hochleitner]

Hello Everybody,

it took me about a year and multiple failed rewrites, to admit, that
keeping a compatibility mode for the current prefix-emitting hack in
clojure.data.xml, is just to much of a hassle and complexity nightmare for
it to be worth it.
So now, non-namespaced names are represented as plain keywords as before,
but namespaced names are represented as QNames, or shorthanded to a
prefixed keyword according to an aliasing mechanism, see updated
http://dev.clojure.org/display/DXML/Namespaced+XML

I'm pretty happy with the resulting rewrite (
https://github.com/bendlas/data.xml) and I think it's a great time now, to
try it out and help sand off the edges.
Please let me know, how well this approach could support your use case for
namespaced xml.

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: Single-atom update ordering guarantees

[Fluid Dynamics]

On Tuesday, June 9, 2015 at 4:24:16 PM UTC-4, Michael Gardner wrote:
>
> Thanks. That does appear to provide the guarantee I was looking for. 
>
> > On Jun 9, 2015, at 12:14 PM, Andy Fingerhut  > wrote: 
> > 
> > swap! is implemented using Java's AtomicReference class and its 
> compareAndSet method.  I haven't dug into the Java source code implementing 
> that class, but you can read the Java documentation for all Atomic* Java 
> classes here: 
> > 
> > 
> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html
>  
> > 
> > The summary there is that all accesses to Atomic* classes should have 
> similar memory model guarantees as Java fields declared volatile.  I don't 
> have a good authoritative link handy for Java documentation on volatile, 
> but the basic idea is that they should not be cached locally by individual 
> threads, but be visible to all. 
>

My own recollection jibes with this: atom changes are memory-barriered.

OTOH, if the atom is swap!ped concurrently by other threads, all bets are 
off. Some other thread might dec it in between your thread's inc and dec of 
it. If you need to guard against that as well, then you need refs and 
dosync and to inc and then dec within a transaction. Then the whole 
sequence of events of "... inc ... dec ..." becomes atomic from the 
perspective of other threads, and not just the inc and the dec, separately.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Single-atom update ordering guarantees

[Michael Gardner]

Thanks. That does appear to provide the guarantee I was looking for.

> On Jun 9, 2015, at 12:14 PM, Andy Fingerhut  wrote:
> 
> swap! is implemented using Java's AtomicReference class and its compareAndSet 
> method.  I haven't dug into the Java source code implementing that class, but 
> you can read the Java documentation for all Atomic* Java classes here:
> 
> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html
> 
> The summary there is that all accesses to Atomic* classes should have similar 
> memory model guarantees as Java fields declared volatile.  I don't have a 
> good authoritative link handy for Java documentation on volatile, but the 
> basic idea is that they should not be cached locally by individual threads, 
> but be visible to all.
> 
> Andy
> 
> 
> On Tue, Jun 9, 2015 at 11:33 AM, Michael Gardner  wrote:
> I'm talking about a scenario where a single thread does inc, followed shortly 
> by dec. Obviously from that thread's perspective, the value will never be 
> zero, but what about as seen by other threads?
> 
> My understanding of Java's memory model is that instructions within a single 
> thread *can* get reordered, and Java only guarantees that they will *appear* 
> to have executed in order from the perspective of the executing thread. Other 
> threads might see those instructions as executing out-of-order. What I'm 
> wondering is whether atoms are subject to this as well.
> 
> > On Jun 9, 2015, at 10:16 AM, Andy Fingerhut  
> > wrote:
> >
> > I am not sure why Atamert says "No".
> >
> > If the (swap! a inc) and (swap! a dec) are executed in different threads, 
> > and they can occur in either order because there is no synchronization 
> > between those threads that prevents one of the two possible orders from 
> > occurring, then another thread *could* see a value of 0, if and when the 
> > (swap! a dec) occurs first.
> >
> > If the (swap! a inc) and (swap! a dec) are executed sequentially in a 
> > single thread, and no other thread is modifying a, then by normal 
> > sequential execution the atom should change from 1 to 2, then from 2 back 
> > to 1.
> >
> > Andy
> >
> > On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen  wrote:
> >
> >
> > On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner  wrote:
> > This might be blindingly obvious to some, but I can't find any discussion 
> > about it. Let's say I have code like the following:
> >
> > (def a (atom 1))
> > ...
> > (swap! a inc)
> > (swap! a dec)
> >
> > Is there any possibility of another thread seeing a=0? If not, what 
> > provides this guarantee?
> >
> > No. Not if those two swap! calls are made from different threads.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > Kind Regards,
> > Atamert Ölçgen
> >
> > ◻◼◻
> > ◻◻◼
> > ◼◼◼
> >
> > www.muhuk.com
> > www.olcgen.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsu

Re: Single-atom update ordering guarantees

[Andy Fingerhut]

swap! is implemented using Java's AtomicReference class and its
compareAndSet method.  I haven't dug into the Java source code implementing
that class, but you can read the Java documentation for all Atomic* Java
classes here:

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html

The summary there is that all accesses to Atomic* classes should have
similar memory model guarantees as Java fields declared volatile.  I don't
have a good authoritative link handy for Java documentation on volatile,
but the basic idea is that they should not be cached locally by individual
threads, but be visible to all.

Andy


On Tue, Jun 9, 2015 at 11:33 AM, Michael Gardner 
wrote:

> I'm talking about a scenario where a single thread does inc, followed
> shortly by dec. Obviously from that thread's perspective, the value will
> never be zero, but what about as seen by other threads?
>
> My understanding of Java's memory model is that instructions within a
> single thread *can* get reordered, and Java only guarantees that they will
> *appear* to have executed in order from the perspective of the executing
> thread. Other threads might see those instructions as executing
> out-of-order. What I'm wondering is whether atoms are subject to this as
> well.
>
> > On Jun 9, 2015, at 10:16 AM, Andy Fingerhut 
> wrote:
> >
> > I am not sure why Atamert says "No".
> >
> > If the (swap! a inc) and (swap! a dec) are executed in different
> threads, and they can occur in either order because there is no
> synchronization between those threads that prevents one of the two possible
> orders from occurring, then another thread *could* see a value of 0, if and
> when the (swap! a dec) occurs first.
> >
> > If the (swap! a inc) and (swap! a dec) are executed sequentially in a
> single thread, and no other thread is modifying a, then by normal
> sequential execution the atom should change from 1 to 2, then from 2 back
> to 1.
> >
> > Andy
> >
> > On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen  wrote:
> >
> >
> > On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner 
> wrote:
> > This might be blindingly obvious to some, but I can't find any
> discussion about it. Let's say I have code like the following:
> >
> > (def a (atom 1))
> > ...
> > (swap! a inc)
> > (swap! a dec)
> >
> > Is there any possibility of another thread seeing a=0? If not, what
> provides this guarantee?
> >
> > No. Not if those two swap! calls are made from different threads.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > Kind Regards,
> > Atamert Ölçgen
> >
> > ◻◼◻
> > ◻◻◼
> > ◼◼◼
> >
> > www.muhuk.com
> > www.olcgen.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send ema

Re: Single-atom update ordering guarantees

[Michael Gardner]

I'm talking about a scenario where a single thread does inc, followed shortly 
by dec. Obviously from that thread's perspective, the value will never be zero, 
but what about as seen by other threads?

My understanding of Java's memory model is that instructions within a single 
thread *can* get reordered, and Java only guarantees that they will *appear* to 
have executed in order from the perspective of the executing thread. Other 
threads might see those instructions as executing out-of-order. What I'm 
wondering is whether atoms are subject to this as well.

> On Jun 9, 2015, at 10:16 AM, Andy Fingerhut  wrote:
> 
> I am not sure why Atamert says "No".
> 
> If the (swap! a inc) and (swap! a dec) are executed in different threads, and 
> they can occur in either order because there is no synchronization between 
> those threads that prevents one of the two possible orders from occurring, 
> then another thread *could* see a value of 0, if and when the (swap! a dec) 
> occurs first.
> 
> If the (swap! a inc) and (swap! a dec) are executed sequentially in a single 
> thread, and no other thread is modifying a, then by normal sequential 
> execution the atom should change from 1 to 2, then from 2 back to 1.
> 
> Andy
> 
> On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen  wrote:
> 
> 
> On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner  wrote:
> This might be blindingly obvious to some, but I can't find any discussion 
> about it. Let's say I have code like the following:
> 
> (def a (atom 1))
> ...
> (swap! a inc)
> (swap! a dec)
> 
> Is there any possibility of another thread seeing a=0? If not, what provides 
> this guarantee?
> 
> No. Not if those two swap! calls are made from different threads.
>  
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Kind Regards,
> Atamert Ölçgen
> 
> ◻◼◻
> ◻◻◼
> ◼◼◼
> 
> www.muhuk.com
> www.olcgen.com
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Single-atom update ordering guarantees

[Andy Fingerhut]

I am not sure why Atamert says "No".

If the (swap! a inc) and (swap! a dec) are executed in different threads,
and they can occur in either order because there is no synchronization
between those threads that prevents one of the two possible orders from
occurring, then another thread *could* see a value of 0, if and when the
(swap! a dec) occurs first.

If the (swap! a inc) and (swap! a dec) are executed sequentially in a
single thread, and no other thread is modifying a, then by normal
sequential execution the atom should change from 1 to 2, then from 2 back
to 1.

Andy

On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen  wrote:

>
>
> On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner 
> wrote:
>
>> This might be blindingly obvious to some, but I can't find any discussion
>> about it. Let's say I have code like the following:
>>
>> (def a (atom 1))
>> ...
>> (swap! a inc)
>> (swap! a dec)
>>
>> Is there any possibility of another thread seeing a=0? If not, what
>> provides this guarantee?
>>
>
> No. Not if those two swap! calls are made from different threads.
>
>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
> www.olcgen.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Single-atom update ordering guarantees

[Atamert Ölçgen]

On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner  wrote:

> This might be blindingly obvious to some, but I can't find any discussion
> about it. Let's say I have code like the following:
>
> (def a (atom 1))
> ...
> (swap! a inc)
> (swap! a dec)
>
> Is there any possibility of another thread seeing a=0? If not, what
> provides this guarantee?
>

No. Not if those two swap! calls are made from different threads.


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



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com
www.olcgen.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.

Single-atom update ordering guarantees

[Michael Gardner]

This might be blindingly obvious to some, but I can't find any discussion about 
it. Let's say I have code like the following:

(def a (atom 1))
...
(swap! a inc)
(swap! a dec)

Is there any possibility of another thread seeing a=0? If not, what provides 
this guarantee?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update multiple values in vector at once

[Leon Grapenthin]

(defn upd-vec [input-vector ids new-values]
  (apply assoc input-vector (interleave ids new-values)))

(upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])

;=> [0 1.44 0 1.45 0] 


On Monday, March 30, 2015 at 8:05:44 PM UTC+2, Alexandr wrote:
>
> Hello everybody,
>
> How can I update values in the vector given vector of id-s and new values?
>
> For example
>
> (defn upd-vec [input-vector ids new-values]
> 
> )
>
> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45]) 
>
> Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update multiple values in vector at once

[Alexandr]

Thanks a lot!

On Monday, March 30, 2015 at 8:11:25 PM UTC+2, Michał Marczyk wrote:
>
> (defn upd-vec [input-vector ids new-values]
>   (reduce-kv #(assoc %1 %3 (new-values %2)) input-vector ids))
>
> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
> ;= [0 1.44 0 1.45 0]
>
>
> On 30 March 2015 at 20:05, Alexandr > 
> wrote:
>
>> Hello everybody,
>>
>> How can I update values in the vector given vector of id-s and new values?
>>
>> For example
>>
>> (defn upd-vec [input-vector ids new-values]
>> 
>> )
>>
>> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45]) 
>>
>> Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)
>>
>> -- 
>> 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.

Re: Update multiple values in vector at once

[Michał Marczyk]

(defn upd-vec [input-vector ids new-values]
  (reduce-kv #(assoc %1 %3 (new-values %2)) input-vector ids))

(upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
;= [0 1.44 0 1.45 0]


On 30 March 2015 at 20:05, Alexandr  wrote:

> Hello everybody,
>
> How can I update values in the vector given vector of id-s and new values?
>
> For example
>
> (defn upd-vec [input-vector ids new-values]
> 
> )
>
> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
>
> Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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.

Update multiple values in vector at once

[Alexandr]

Hello everybody,

How can I update values in the vector given vector of id-s and new values?

For example

(defn upd-vec [input-vector ids new-values]

)

(upd-vec [0 0 0 0 0] [1 3] [1.44 1.45]) 

Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

Hi Kovas, so far the mesh types (GMesh & BasicMesh) were mainly used for 3d
printing rather than viz purposes and have not yet support for vertex or
face attributes. It is something I still need to port over from the
previous version of the lib. I held off on that so far to first let the
WebGL conversion parts settle (almost done) and will address this in the
next month. The aim is to provide an attribute structure allowing any type
of attribute along with serializers for common attribs (UVs, colors, IDs)
for WebGL and provide hooks to interpolate attribs (e.g. for subdivisions).
Ultimately this might even become available for other types too, i.e.
directly on the cuboid, aabb, lines etc.

As for the current state: I've created a gist showing how this can be
achieved currently, in principle:

https://gist.github.com/postspectacular/894fc58d75005069a546

Thanks for the feedback, as always highly appreciated!

K.
Hi Karsten,

Technical usage question.

I want to associate a color to each face of a cuboid, tesselate the cuboid,
and end up with an array of vertices and an array of matching colors.

My problem is associating the colors of the cuboid faces to their
tessellated versions. AFAICT tessellation simply produces new faces and
does not have facilities for propagating annotations from the old face to
the new faces. Furthermore, because the faces are stored in an unordered
set, it is not possible to somehow match the new faces to the old ones
based on ordering, at least in this simple case.

I tried to work around this by supplying the face set as an empty vector to
the mesh constructor. Unfortunately this doesn't work because the creation
of the new mesh simply calls the default constructor function, so the new
faces end up getting poured into a set anyway.

If instead, it called (empty) on the faces of the supplied mesh, this
workaround could work. However it is brittle, requiring to one know ahead
of time how many new faces will be generated for each input face.

Is there a better way to do this?

Thanks!


















On Wed, Feb 25, 2015 at 6:13 PM, Karsten Schmidt  wrote:

> That's a good point, Bruce! To be honest, I don't know anymore, but it
> makes complete sense to change it. Consider it done! :)
>
> As for your mapping question, yes, of course! I've done a few of them.
> E.g. the first pic on the website [1] was a project for The ODI in
> 2013 and is a map of different council/borough stats of London (here
> knife crime). The shape files were first retrieved & processed with
> the thi.ng/trio lib directly from the UK statistics office's SPARQL
> endpoint [2], then projected to Mercator, converted to 2d polygons,
> smoothed them and then extruded as 3D walled meshes and exported as
> STL files using geom. To create that rendered image, another function
> then combined all borough meshes into a complete render scene for
> Luxrender (using the luxor lib). Since this all was for a 60sec
> animation, I also wrote the tweeny lib for that project to allow me to
> define the timeline for the various camera, mesh, light & shader
> changes. The whole bundle was then sent to EC2 and rendered on 340+
> CPUs... basically, spawned a private render farm.
>
> Alternatively with < 30 lines of code you could query any UK
> constituency (or use similar endpoints for other countries), do those
> initial shape transformations and send the resulting STL mesh file
> straight to a 3D printer... For online use, of course the SVG or WebGL
> modules would be more interesting, but these really would just deal
> with that last transformation/visualization step, i.e. turning a
> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
> stuff it into WebGL buffer to display...
>
> For more flexible mapping, it'd be great to port some/all of the
> projections from [3] in its own clj lib for easier (and non-JS
> related) access...
>
> [1] http://thi.ng/img/04.jpg
> [2] http://statistics.data.gov.uk/doc/statistical-geography
> [3] https://github.com/d3/d3-geo-projection/
>
> Hth!
>
> On 25 February 2015 at 22:34, Bruce Durling  wrote:
> > Karsten,
> >
> > Is there a reason why you went with a README.md and then an index.org
> > rather than a plain README.org?
> >
> > (love all the rest of it and loved your use of it at The Barbican. I
> > need to get my head around it all. I'm wondering if I can use it for
> > some of the geographic and other charting things I do a lot of).
> >
> > cheers,
> > Bruce
> >
> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
> wrote:
> >> Hi guys,
> >>
> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
> >> Clojurescript libs for computational/generative design & data
> >> visualization tasks.
> >>
> >> I just wanted to give a little heads up that this project has recently
> >> seen a number of releases and, as a whole, by now is generally quite
> >> stable and usable (*is used*) for realworld projects (although most
> >> libs remain in constant parallel development 

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[kovas boguta]

On Thu, Mar 12, 2015 at 8:18 PM, kovas boguta 
wrote:

>
> I want to associate a color to each face of a cuboid, tesselate the
> cuboid, and end up with an array of vertices and an array of matching
> colors.
>

To clarify, I want to turn the cuboid into a mesh, and then do the
tessellation of the mesh. Tessellating the cuboid directly gives me the
faces in an obvious predictable order. However I want the mesh b/c theres
other computations I want to perform with it.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[kovas boguta]

Hi Karsten,

Technical usage question.

I want to associate a color to each face of a cuboid, tesselate the cuboid,
and end up with an array of vertices and an array of matching colors.

My problem is associating the colors of the cuboid faces to their
tessellated versions. AFAICT tessellation simply produces new faces and
does not have facilities for propagating annotations from the old face to
the new faces. Furthermore, because the faces are stored in an unordered
set, it is not possible to somehow match the new faces to the old ones
based on ordering, at least in this simple case.

I tried to work around this by supplying the face set as an empty vector to
the mesh constructor. Unfortunately this doesn't work because the creation
of the new mesh simply calls the default constructor function, so the new
faces end up getting poured into a set anyway.

If instead, it called (empty) on the faces of the supplied mesh, this
workaround could work. However it is brittle, requiring to one know ahead
of time how many new faces will be generated for each input face.

Is there a better way to do this?

Thanks!


















On Wed, Feb 25, 2015 at 6:13 PM, Karsten Schmidt  wrote:

> That's a good point, Bruce! To be honest, I don't know anymore, but it
> makes complete sense to change it. Consider it done! :)
>
> As for your mapping question, yes, of course! I've done a few of them.
> E.g. the first pic on the website [1] was a project for The ODI in
> 2013 and is a map of different council/borough stats of London (here
> knife crime). The shape files were first retrieved & processed with
> the thi.ng/trio lib directly from the UK statistics office's SPARQL
> endpoint [2], then projected to Mercator, converted to 2d polygons,
> smoothed them and then extruded as 3D walled meshes and exported as
> STL files using geom. To create that rendered image, another function
> then combined all borough meshes into a complete render scene for
> Luxrender (using the luxor lib). Since this all was for a 60sec
> animation, I also wrote the tweeny lib for that project to allow me to
> define the timeline for the various camera, mesh, light & shader
> changes. The whole bundle was then sent to EC2 and rendered on 340+
> CPUs... basically, spawned a private render farm.
>
> Alternatively with < 30 lines of code you could query any UK
> constituency (or use similar endpoints for other countries), do those
> initial shape transformations and send the resulting STL mesh file
> straight to a 3D printer... For online use, of course the SVG or WebGL
> modules would be more interesting, but these really would just deal
> with that last transformation/visualization step, i.e. turning a
> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
> stuff it into WebGL buffer to display...
>
> For more flexible mapping, it'd be great to port some/all of the
> projections from [3] in its own clj lib for easier (and non-JS
> related) access...
>
> [1] http://thi.ng/img/04.jpg
> [2] http://statistics.data.gov.uk/doc/statistical-geography
> [3] https://github.com/d3/d3-geo-projection/
>
> Hth!
>
> On 25 February 2015 at 22:34, Bruce Durling  wrote:
> > Karsten,
> >
> > Is there a reason why you went with a README.md and then an index.org
> > rather than a plain README.org?
> >
> > (love all the rest of it and loved your use of it at The Barbican. I
> > need to get my head around it all. I'm wondering if I can use it for
> > some of the geographic and other charting things I do a lot of).
> >
> > cheers,
> > Bruce
> >
> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
> wrote:
> >> Hi guys,
> >>
> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
> >> Clojurescript libs for computational/generative design & data
> >> visualization tasks.
> >>
> >> I just wanted to give a little heads up that this project has recently
> >> seen a number of releases and, as a whole, by now is generally quite
> >> stable and usable (*is used*) for realworld projects (although most
> >> libs remain in constant parallel development to make them more feature
> >> complete). I've collated a number of images of projects and links to
> >> the most important libs here:
> >>
> >> http://thi.ng/
> >>
> >> Most notably of those:
> >>
> >> http://thi.ng/geom
> >> By far the largest sub-project and backbone for most others: A 2D/3D
> >> geometry package w/ comprehensive vector algebra, swizzling,
> >> intersections, matrix types & helpers, quaternions, pure shape
> >> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> >> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> >> engine (only particles, springs, behaviors)... Most of this lib is
> >> pure geometry w/ no rendering specifics, although there're separate
> >> modules for SVG rendering w/ shader support & decorators [1], WebGL
> >> wrapper and converters from shapes/meshes to VBOs and various shader
> >> presets/utils.
> >>
> >> http://thi.ng/shadergraph

Re: Could use a better error message here (using a list in update-in)

[John Gabriele]

Ok, done (CLJ-1672). Though, as an aside, that site doesn't allow 
connection via https. One has to send all their credentials in the clear...


On Tuesday, March 10, 2015 at 11:17:58 AM UTC-4, Stuart Sierra wrote:
>
> Please file a ticket in JIRA and tag it with "errormsg"
> http://dev.clojure.org/display/community/Creating+Tickets
>
> –S
>
>
> On Tuesday, March 10, 2015 at 3:13:36 PM UTC, John Gabriele wrote:
>>
>> In Clojure v1.6.0. This one confused me when I'd accidentally passed a 
>> list in to `update-in` instead of a vector:
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Could use a better error message here (using a list in update-in)

[Stuart Sierra]

Please file a ticket in JIRA and tag it with "errormsg"
http://dev.clojure.org/display/community/Creating+Tickets

–S


On Tuesday, March 10, 2015 at 3:13:36 PM UTC, John Gabriele wrote:
>
> In Clojure v1.6.0. This one confused me when I'd accidentally passed a 
> list in to `update-in` instead of a vector:
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

Could use a better error message here (using a list in update-in)

[John Gabriele]

In Clojure v1.6.0. This one confused me when I'd accidentally passed a list 
in to `update-in` instead of a vector:

~~~
some-app.core=> (update-in [:a :b :c] [1] name)
[:a "b" :c]
some-app.core=> (update-in '(:a :b :c) [1] name)

NullPointerException   clojure.core/name (core.clj:1518)
~~~

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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] thi.ng collection update (CLJ/CLJS)

[Daniel]

This is incredible work. Thanks for sharing!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

This draft anim was created for The ODI and shows 2 years (summer
2011-2013) worth of London knife crime (based on open data ambulance &
A&E reports):

http://media.thi.ng/2013/odi/20131029-heatmap-draft-1280x960.mp4

On 26 February 2015 at 00:42, Dylan Butman  wrote:
> I totally thought that map was a photo of 3d printed shapes, but it makes
> sense that you're using luxrender now. Is there a video of the animation
> online somewhere?
>
> On Wed Feb 25 2015 at 6:13:25 PM Karsten Schmidt  wrote:
>>
>> That's a good point, Bruce! To be honest, I don't know anymore, but it
>> makes complete sense to change it. Consider it done! :)
>>
>> As for your mapping question, yes, of course! I've done a few of them.
>> E.g. the first pic on the website [1] was a project for The ODI in
>> 2013 and is a map of different council/borough stats of London (here
>> knife crime). The shape files were first retrieved & processed with
>> the thi.ng/trio lib directly from the UK statistics office's SPARQL
>> endpoint [2], then projected to Mercator, converted to 2d polygons,
>> smoothed them and then extruded as 3D walled meshes and exported as
>> STL files using geom. To create that rendered image, another function
>> then combined all borough meshes into a complete render scene for
>> Luxrender (using the luxor lib). Since this all was for a 60sec
>> animation, I also wrote the tweeny lib for that project to allow me to
>> define the timeline for the various camera, mesh, light & shader
>> changes. The whole bundle was then sent to EC2 and rendered on 340+
>> CPUs... basically, spawned a private render farm.
>>
>> Alternatively with < 30 lines of code you could query any UK
>> constituency (or use similar endpoints for other countries), do those
>> initial shape transformations and send the resulting STL mesh file
>> straight to a 3D printer... For online use, of course the SVG or WebGL
>> modules would be more interesting, but these really would just deal
>> with that last transformation/visualization step, i.e. turning a
>> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
>> stuff it into WebGL buffer to display...
>>
>> For more flexible mapping, it'd be great to port some/all of the
>> projections from [3] in its own clj lib for easier (and non-JS
>> related) access...
>>
>> [1] http://thi.ng/img/04.jpg
>> [2] http://statistics.data.gov.uk/doc/statistical-geography
>> [3] https://github.com/d3/d3-geo-projection/
>>
>> Hth!
>>
>> On 25 February 2015 at 22:34, Bruce Durling  wrote:
>> > Karsten,
>> >
>> > Is there a reason why you went with a README.md and then an index.org
>> > rather than a plain README.org?
>> >
>> > (love all the rest of it and loved your use of it at The Barbican. I
>> > need to get my head around it all. I'm wondering if I can use it for
>> > some of the geographic and other charting things I do a lot of).
>> >
>> > cheers,
>> > Bruce
>> >
>> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
>> > wrote:
>> >> Hi guys,
>> >>
>> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
>> >> Clojurescript libs for computational/generative design & data
>> >> visualization tasks.
>> >>
>> >> I just wanted to give a little heads up that this project has recently
>> >> seen a number of releases and, as a whole, by now is generally quite
>> >> stable and usable (*is used*) for realworld projects (although most
>> >> libs remain in constant parallel development to make them more feature
>> >> complete). I've collated a number of images of projects and links to
>> >> the most important libs here:
>> >>
>> >> http://thi.ng/
>> >>
>> >> Most notably of those:
>> >>
>> >> http://thi.ng/geom
>> >> By far the largest sub-project and backbone for most others: A 2D/3D
>> >> geometry package w/ comprehensive vector algebra, swizzling,
>> >> intersections, matrix types & helpers, quaternions, pure shape
>> >> primitives with ~50 protocols for polymorphic enquiry & manipulation,
>> >> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
>> >> engine (only particles, springs, behaviors)... Most of this lib is
>> >> pure geometry w/ no rendering specifics, although there're separate
>> >> modules for SVG rendering w/ shader support & decorators [1], WebGL
>> >> wrapper and converters from shapes/meshes to VBOs and various shader
>> >> presets/utils.
>> >>
>> >> http://thi.ng/shadergraph
>> >> GLSL (WebGL) pure function library & dependency graph (based on
>> >> com.stuartsierra/dependency), GLSL minification during CLJS compile
>> >> time
>> >>
>> >> http://thi.ng/color
>> >> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category
>> >> schemes)
>> >>
>> >> http://thi.ng/luxor
>> >> Complete scene compiler DSL for http://luxrender.net, based around
>> >> thi.ng/geom
>> >>
>> >> http://thi.ng/morphogen
>> >> Declarative 3D form evolution through tree-based transformations,
>> >> basically an AST generator of geometric operations to transform a
>> >> single seed node into co

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Dylan Butman]

I totally thought that map was a photo of 3d printed shapes, but it makes
sense that you're using luxrender now. Is there a video of the animation
online somewhere?

On Wed Feb 25 2015 at 6:13:25 PM Karsten Schmidt  wrote:

> That's a good point, Bruce! To be honest, I don't know anymore, but it
> makes complete sense to change it. Consider it done! :)
>
> As for your mapping question, yes, of course! I've done a few of them.
> E.g. the first pic on the website [1] was a project for The ODI in
> 2013 and is a map of different council/borough stats of London (here
> knife crime). The shape files were first retrieved & processed with
> the thi.ng/trio lib directly from the UK statistics office's SPARQL
> endpoint [2], then projected to Mercator, converted to 2d polygons,
> smoothed them and then extruded as 3D walled meshes and exported as
> STL files using geom. To create that rendered image, another function
> then combined all borough meshes into a complete render scene for
> Luxrender (using the luxor lib). Since this all was for a 60sec
> animation, I also wrote the tweeny lib for that project to allow me to
> define the timeline for the various camera, mesh, light & shader
> changes. The whole bundle was then sent to EC2 and rendered on 340+
> CPUs... basically, spawned a private render farm.
>
> Alternatively with < 30 lines of code you could query any UK
> constituency (or use similar endpoints for other countries), do those
> initial shape transformations and send the resulting STL mesh file
> straight to a 3D printer... For online use, of course the SVG or WebGL
> modules would be more interesting, but these really would just deal
> with that last transformation/visualization step, i.e. turning a
> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
> stuff it into WebGL buffer to display...
>
> For more flexible mapping, it'd be great to port some/all of the
> projections from [3] in its own clj lib for easier (and non-JS
> related) access...
>
> [1] http://thi.ng/img/04.jpg
> [2] http://statistics.data.gov.uk/doc/statistical-geography
> [3] https://github.com/d3/d3-geo-projection/
>
> Hth!
>
> On 25 February 2015 at 22:34, Bruce Durling  wrote:
> > Karsten,
> >
> > Is there a reason why you went with a README.md and then an index.org
> > rather than a plain README.org?
> >
> > (love all the rest of it and loved your use of it at The Barbican. I
> > need to get my head around it all. I'm wondering if I can use it for
> > some of the geographic and other charting things I do a lot of).
> >
> > cheers,
> > Bruce
> >
> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
> wrote:
> >> Hi guys,
> >>
> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
> >> Clojurescript libs for computational/generative design & data
> >> visualization tasks.
> >>
> >> I just wanted to give a little heads up that this project has recently
> >> seen a number of releases and, as a whole, by now is generally quite
> >> stable and usable (*is used*) for realworld projects (although most
> >> libs remain in constant parallel development to make them more feature
> >> complete). I've collated a number of images of projects and links to
> >> the most important libs here:
> >>
> >> http://thi.ng/
> >>
> >> Most notably of those:
> >>
> >> http://thi.ng/geom
> >> By far the largest sub-project and backbone for most others: A 2D/3D
> >> geometry package w/ comprehensive vector algebra, swizzling,
> >> intersections, matrix types & helpers, quaternions, pure shape
> >> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> >> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> >> engine (only particles, springs, behaviors)... Most of this lib is
> >> pure geometry w/ no rendering specifics, although there're separate
> >> modules for SVG rendering w/ shader support & decorators [1], WebGL
> >> wrapper and converters from shapes/meshes to VBOs and various shader
> >> presets/utils.
> >>
> >> http://thi.ng/shadergraph
> >> GLSL (WebGL) pure function library & dependency graph (based on
> >> com.stuartsierra/dependency), GLSL minification during CLJS compile
> >> time
> >>
> >> http://thi.ng/color
> >> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category
> schemes)
> >>
> >> http://thi.ng/luxor
> >> Complete scene compiler DSL for http://luxrender.net, based around
> thi.ng/geom
> >>
> >> http://thi.ng/morphogen
> >> Declarative 3D form evolution through tree-based transformations,
> >> basically an AST generator of geometric operations to transform a
> >> single seed node into complex 3D objects
> >>
> >> http://thi.ng/tweeny
> >> Interpolation of nested (presumably animation related) data
> >> structures. Allows tweening of deeply nested maps/vectors with
> >> completely flexible tween fns/targets and hence easy definition of
> >> complex timelines
> >>
> >> http://thi.ng/validate
> >> Purely functional, composable data validation & optional corrections
> >

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

Computational design = using computational approaches to design
problems, for anything from analysis, implementation to
representation...

CSG is indeed only for meshes since it's based on BSP partitioning and
because of that also has a few edge cases (due to float precision)
where it breaks down and can cause small holes to appear (but these
can be fixed with Meshlab/Blender etc). Does OpenSCAD *not* use
tessellated geometry for boolean ops? I always was under the
impression it does too... need to double check! The other way to do it
(and actually easier) is via voxels. There's a really old iso surface
implementation in [1], but that needs a complete rewrite and is
therefore not bundled with any current releases...

Again, I wish there would be more activity in Clojureland underway in
these non-web-tech related fields (we have dozens of server & dom
libs, but not that much for design, modelling, architecture,
fabrication). That's not trying to be defensive in any way, but a
single person can only do that much and all the features & tools
provided so far were purely developed on a need to have basis
(obviously with a priority to be as re-usable as possible).

Hth! K.

On 25 February 2015 at 23:21, Jason Felice  wrote:
> So... what is "computational design"?
>
> I've been using OpenSCAD to make models for 3D printing, and I keep wishing
> for a Clojure syntax and real functions and things.  Is this it?
>
> (It doesn't seem to have constructive solid geometry for things which aren't
> meshes.)
>
> -Jason
>
> On Wed, Feb 25, 2015 at 4:13 PM, Karsten Schmidt  wrote:
>>
>> That's a good point, Bruce! To be honest, I don't know anymore, but it
>> makes complete sense to change it. Consider it done! :)
>>
>> As for your mapping question, yes, of course! I've done a few of them.
>> E.g. the first pic on the website [1] was a project for The ODI in
>> 2013 and is a map of different council/borough stats of London (here
>> knife crime). The shape files were first retrieved & processed with
>> the thi.ng/trio lib directly from the UK statistics office's SPARQL
>> endpoint [2], then projected to Mercator, converted to 2d polygons,
>> smoothed them and then extruded as 3D walled meshes and exported as
>> STL files using geom. To create that rendered image, another function
>> then combined all borough meshes into a complete render scene for
>> Luxrender (using the luxor lib). Since this all was for a 60sec
>> animation, I also wrote the tweeny lib for that project to allow me to
>> define the timeline for the various camera, mesh, light & shader
>> changes. The whole bundle was then sent to EC2 and rendered on 340+
>> CPUs... basically, spawned a private render farm.
>>
>> Alternatively with < 30 lines of code you could query any UK
>> constituency (or use similar endpoints for other countries), do those
>> initial shape transformations and send the resulting STL mesh file
>> straight to a 3D printer... For online use, of course the SVG or WebGL
>> modules would be more interesting, but these really would just deal
>> with that last transformation/visualization step, i.e. turning a
>> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
>> stuff it into WebGL buffer to display...
>>
>> For more flexible mapping, it'd be great to port some/all of the
>> projections from [3] in its own clj lib for easier (and non-JS
>> related) access...
>>
>> [1] http://thi.ng/img/04.jpg
>> [2] http://statistics.data.gov.uk/doc/statistical-geography
>> [3] https://github.com/d3/d3-geo-projection/
>>
>> Hth!
>>
>> On 25 February 2015 at 22:34, Bruce Durling  wrote:
>> > Karsten,
>> >
>> > Is there a reason why you went with a README.md and then an index.org
>> > rather than a plain README.org?
>> >
>> > (love all the rest of it and loved your use of it at The Barbican. I
>> > need to get my head around it all. I'm wondering if I can use it for
>> > some of the geographic and other charting things I do a lot of).
>> >
>> > cheers,
>> > Bruce
>> >
>> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
>> > wrote:
>> >> Hi guys,
>> >>
>> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
>> >> Clojurescript libs for computational/generative design & data
>> >> visualization tasks.
>> >>
>> >> I just wanted to give a little heads up that this project has recently
>> >> seen a number of releases and, as a whole, by now is generally quite
>> >> stable and usable (*is used*) for realworld projects (although most
>> >> libs remain in constant parallel development to make them more feature
>> >> complete). I've collated a number of images of projects and links to
>> >> the most important libs here:
>> >>
>> >> http://thi.ng/
>> >>
>> >> Most notably of those:
>> >>
>> >> http://thi.ng/geom
>> >> By far the largest sub-project and backbone for most others: A 2D/3D
>> >> geometry package w/ comprehensive vector algebra, swizzling,
>> >> intersections, matrix types & helpers, quaternions, pure shape
>> >> primitives with ~5

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Jason Felice]

So... what is "computational design"?

I've been using OpenSCAD to make models for 3D printing, and I keep wishing
for a Clojure syntax and real functions and things.  Is this it?

(It doesn't seem to have constructive solid geometry for things which
aren't meshes.)

-Jason

On Wed, Feb 25, 2015 at 4:13 PM, Karsten Schmidt  wrote:

> That's a good point, Bruce! To be honest, I don't know anymore, but it
> makes complete sense to change it. Consider it done! :)
>
> As for your mapping question, yes, of course! I've done a few of them.
> E.g. the first pic on the website [1] was a project for The ODI in
> 2013 and is a map of different council/borough stats of London (here
> knife crime). The shape files were first retrieved & processed with
> the thi.ng/trio lib directly from the UK statistics office's SPARQL
> endpoint [2], then projected to Mercator, converted to 2d polygons,
> smoothed them and then extruded as 3D walled meshes and exported as
> STL files using geom. To create that rendered image, another function
> then combined all borough meshes into a complete render scene for
> Luxrender (using the luxor lib). Since this all was for a 60sec
> animation, I also wrote the tweeny lib for that project to allow me to
> define the timeline for the various camera, mesh, light & shader
> changes. The whole bundle was then sent to EC2 and rendered on 340+
> CPUs... basically, spawned a private render farm.
>
> Alternatively with < 30 lines of code you could query any UK
> constituency (or use similar endpoints for other countries), do those
> initial shape transformations and send the resulting STL mesh file
> straight to a 3D printer... For online use, of course the SVG or WebGL
> modules would be more interesting, but these really would just deal
> with that last transformation/visualization step, i.e. turning a
> thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
> stuff it into WebGL buffer to display...
>
> For more flexible mapping, it'd be great to port some/all of the
> projections from [3] in its own clj lib for easier (and non-JS
> related) access...
>
> [1] http://thi.ng/img/04.jpg
> [2] http://statistics.data.gov.uk/doc/statistical-geography
> [3] https://github.com/d3/d3-geo-projection/
>
> Hth!
>
> On 25 February 2015 at 22:34, Bruce Durling  wrote:
> > Karsten,
> >
> > Is there a reason why you went with a README.md and then an index.org
> > rather than a plain README.org?
> >
> > (love all the rest of it and loved your use of it at The Barbican. I
> > need to get my head around it all. I'm wondering if I can use it for
> > some of the geographic and other charting things I do a lot of).
> >
> > cheers,
> > Bruce
> >
> > On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt 
> wrote:
> >> Hi guys,
> >>
> >> thi.ng is a collection of over a dozen largely x-platform Clojure &
> >> Clojurescript libs for computational/generative design & data
> >> visualization tasks.
> >>
> >> I just wanted to give a little heads up that this project has recently
> >> seen a number of releases and, as a whole, by now is generally quite
> >> stable and usable (*is used*) for realworld projects (although most
> >> libs remain in constant parallel development to make them more feature
> >> complete). I've collated a number of images of projects and links to
> >> the most important libs here:
> >>
> >> http://thi.ng/
> >>
> >> Most notably of those:
> >>
> >> http://thi.ng/geom
> >> By far the largest sub-project and backbone for most others: A 2D/3D
> >> geometry package w/ comprehensive vector algebra, swizzling,
> >> intersections, matrix types & helpers, quaternions, pure shape
> >> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> >> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> >> engine (only particles, springs, behaviors)... Most of this lib is
> >> pure geometry w/ no rendering specifics, although there're separate
> >> modules for SVG rendering w/ shader support & decorators [1], WebGL
> >> wrapper and converters from shapes/meshes to VBOs and various shader
> >> presets/utils.
> >>
> >> http://thi.ng/shadergraph
> >> GLSL (WebGL) pure function library & dependency graph (based on
> >> com.stuartsierra/dependency), GLSL minification during CLJS compile
> >> time
> >>
> >> http://thi.ng/color
> >> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category
> schemes)
> >>
> >> http://thi.ng/luxor
> >> Complete scene compiler DSL for http://luxrender.net, based around
> thi.ng/geom
> >>
> >> http://thi.ng/morphogen
> >> Declarative 3D form evolution through tree-based transformations,
> >> basically an AST generator of geometric operations to transform a
> >> single seed node into complex 3D objects
> >>
> >> http://thi.ng/tweeny
> >> Interpolation of nested (presumably animation related) data
> >> structures. Allows tweening of deeply nested maps/vectors with
> >> completely flexible tween fns/targets and hence easy definition of
> >> complex timelines

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

That's a good point, Bruce! To be honest, I don't know anymore, but it
makes complete sense to change it. Consider it done! :)

As for your mapping question, yes, of course! I've done a few of them.
E.g. the first pic on the website [1] was a project for The ODI in
2013 and is a map of different council/borough stats of London (here
knife crime). The shape files were first retrieved & processed with
the thi.ng/trio lib directly from the UK statistics office's SPARQL
endpoint [2], then projected to Mercator, converted to 2d polygons,
smoothed them and then extruded as 3D walled meshes and exported as
STL files using geom. To create that rendered image, another function
then combined all borough meshes into a complete render scene for
Luxrender (using the luxor lib). Since this all was for a 60sec
animation, I also wrote the tweeny lib for that project to allow me to
define the timeline for the various camera, mesh, light & shader
changes. The whole bundle was then sent to EC2 and rendered on 340+
CPUs... basically, spawned a private render farm.

Alternatively with < 30 lines of code you could query any UK
constituency (or use similar endpoints for other countries), do those
initial shape transformations and send the resulting STL mesh file
straight to a 3D printer... For online use, of course the SVG or WebGL
modules would be more interesting, but these really would just deal
with that last transformation/visualization step, i.e. turning a
thi.ng.geom.Polygon2 into an SVG  node or tesselate it and
stuff it into WebGL buffer to display...

For more flexible mapping, it'd be great to port some/all of the
projections from [3] in its own clj lib for easier (and non-JS
related) access...

[1] http://thi.ng/img/04.jpg
[2] http://statistics.data.gov.uk/doc/statistical-geography
[3] https://github.com/d3/d3-geo-projection/

Hth!

On 25 February 2015 at 22:34, Bruce Durling  wrote:
> Karsten,
>
> Is there a reason why you went with a README.md and then an index.org
> rather than a plain README.org?
>
> (love all the rest of it and loved your use of it at The Barbican. I
> need to get my head around it all. I'm wondering if I can use it for
> some of the geographic and other charting things I do a lot of).
>
> cheers,
> Bruce
>
> On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt  wrote:
>> Hi guys,
>>
>> thi.ng is a collection of over a dozen largely x-platform Clojure &
>> Clojurescript libs for computational/generative design & data
>> visualization tasks.
>>
>> I just wanted to give a little heads up that this project has recently
>> seen a number of releases and, as a whole, by now is generally quite
>> stable and usable (*is used*) for realworld projects (although most
>> libs remain in constant parallel development to make them more feature
>> complete). I've collated a number of images of projects and links to
>> the most important libs here:
>>
>> http://thi.ng/
>>
>> Most notably of those:
>>
>> http://thi.ng/geom
>> By far the largest sub-project and backbone for most others: A 2D/3D
>> geometry package w/ comprehensive vector algebra, swizzling,
>> intersections, matrix types & helpers, quaternions, pure shape
>> primitives with ~50 protocols for polymorphic enquiry & manipulation,
>> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
>> engine (only particles, springs, behaviors)... Most of this lib is
>> pure geometry w/ no rendering specifics, although there're separate
>> modules for SVG rendering w/ shader support & decorators [1], WebGL
>> wrapper and converters from shapes/meshes to VBOs and various shader
>> presets/utils.
>>
>> http://thi.ng/shadergraph
>> GLSL (WebGL) pure function library & dependency graph (based on
>> com.stuartsierra/dependency), GLSL minification during CLJS compile
>> time
>>
>> http://thi.ng/color
>> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes)
>>
>> http://thi.ng/luxor
>> Complete scene compiler DSL for http://luxrender.net, based around 
>> thi.ng/geom
>>
>> http://thi.ng/morphogen
>> Declarative 3D form evolution through tree-based transformations,
>> basically an AST generator of geometric operations to transform a
>> single seed node into complex 3D objects
>>
>> http://thi.ng/tweeny
>> Interpolation of nested (presumably animation related) data
>> structures. Allows tweening of deeply nested maps/vectors with
>> completely flexible tween fns/targets and hence easy definition of
>> complex timelines
>>
>> http://thi.ng/validate
>> Purely functional, composable data validation & optional corrections
>> for nested data. Supports both maps & vectors, wildcards, comes with
>> many predefined validators, but extensible...
>>
>> http://thi.ng/trio
>> A generic, non-RDF specific triple store API and feature rich
>> SPARQL-like query engine
>> (and my prime example of using the literate programming approach with
>> org-mode[2][3])
>>
>> Last but not least: Super special thanks are due to the following people:
>>
>> Rich, Alex + r

Re: [ClojureScript] [ANN] thi.ng collection update (CLJ/CLJS)

[Bruce Durling]

Karsten,

Is there a reason why you went with a README.md and then an index.org
rather than a plain README.org?

(love all the rest of it and loved your use of it at The Barbican. I
need to get my head around it all. I'm wondering if I can use it for
some of the geographic and other charting things I do a lot of).

cheers,
Bruce

On Wed, Feb 25, 2015 at 5:06 AM, Karsten Schmidt  wrote:
> Hi guys,
>
> thi.ng is a collection of over a dozen largely x-platform Clojure &
> Clojurescript libs for computational/generative design & data
> visualization tasks.
>
> I just wanted to give a little heads up that this project has recently
> seen a number of releases and, as a whole, by now is generally quite
> stable and usable (*is used*) for realworld projects (although most
> libs remain in constant parallel development to make them more feature
> complete). I've collated a number of images of projects and links to
> the most important libs here:
>
> http://thi.ng/
>
> Most notably of those:
>
> http://thi.ng/geom
> By far the largest sub-project and backbone for most others: A 2D/3D
> geometry package w/ comprehensive vector algebra, swizzling,
> intersections, matrix types & helpers, quaternions, pure shape
> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> engine (only particles, springs, behaviors)... Most of this lib is
> pure geometry w/ no rendering specifics, although there're separate
> modules for SVG rendering w/ shader support & decorators [1], WebGL
> wrapper and converters from shapes/meshes to VBOs and various shader
> presets/utils.
>
> http://thi.ng/shadergraph
> GLSL (WebGL) pure function library & dependency graph (based on
> com.stuartsierra/dependency), GLSL minification during CLJS compile
> time
>
> http://thi.ng/color
> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes)
>
> http://thi.ng/luxor
> Complete scene compiler DSL for http://luxrender.net, based around thi.ng/geom
>
> http://thi.ng/morphogen
> Declarative 3D form evolution through tree-based transformations,
> basically an AST generator of geometric operations to transform a
> single seed node into complex 3D objects
>
> http://thi.ng/tweeny
> Interpolation of nested (presumably animation related) data
> structures. Allows tweening of deeply nested maps/vectors with
> completely flexible tween fns/targets and hence easy definition of
> complex timelines
>
> http://thi.ng/validate
> Purely functional, composable data validation & optional corrections
> for nested data. Supports both maps & vectors, wildcards, comes with
> many predefined validators, but extensible...
>
> http://thi.ng/trio
> A generic, non-RDF specific triple store API and feature rich
> SPARQL-like query engine
> (and my prime example of using the literate programming approach with
> org-mode[2][3])
>
> Last but not least: Super special thanks are due to the following people:
>
> Rich, Alex + rest of clojure.core
> David (+everyone else involved) for the immense effort on making CLJS
> proper useful,
> Chas, Kevin and anyone else working on CLJX...
> none of this would have been possible without these amazing tools!
>
> Best, K.
>
> Ps. There're a number of other libs in this collection which are in
> dire need of updating (last touched spring 2013) - these are related
> to general OpenCL functionality and voxel rendering. Some of the
> example images on the above site were created with these...
>
> [1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org
> [2] https://github.com/thi-ng/trio/blob/master/src/query.org
> [3] http://orgmode.org/
>
> --
> Karsten Schmidt
> http://postspectacular.com | http://thi.ng/
>
> --
> Note that posts from new members are moderated - please be patient with your 
> first post.
> ---
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/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/d/optout.

Re: [ANN] thi.ng collection update (CLJ/CLJS)

[Dylan Butman]

Hey Karsten,

Really glad to see you've been continuing the awesome work here! I used 
toxiclibs extensively when I first starting programming in processing and it 
was hugely influential for me! I've been drifting away from computational 
design since then but I'm hoping to get some serious time to play with your 
clojure work soon.

Best
Dylan

On Wednesday, February 25, 2015 at 12:07:01 AM UTC-5, Karsten Schmidt wrote:
> Hi guys,
> 
> thi.ng is a collection of over a dozen largely x-platform Clojure &
> Clojurescript libs for computational/generative design & data
> visualization tasks.
> 
> I just wanted to give a little heads up that this project has recently
> seen a number of releases and, as a whole, by now is generally quite
> stable and usable (*is used*) for realworld projects (although most
> libs remain in constant parallel development to make them more feature
> complete). I've collated a number of images of projects and links to
> the most important libs here:
> 
> http://thi.ng/
> 
> Most notably of those:
> 
> http://thi.ng/geom
> By far the largest sub-project and backbone for most others: A 2D/3D
> geometry package w/ comprehensive vector algebra, swizzling,
> intersections, matrix types & helpers, quaternions, pure shape
> primitives with ~50 protocols for polymorphic enquiry & manipulation,
> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
> engine (only particles, springs, behaviors)... Most of this lib is
> pure geometry w/ no rendering specifics, although there're separate
> modules for SVG rendering w/ shader support & decorators [1], WebGL
> wrapper and converters from shapes/meshes to VBOs and various shader
> presets/utils.
> 
> http://thi.ng/shadergraph
> GLSL (WebGL) pure function library & dependency graph (based on
> com.stuartsierra/dependency), GLSL minification during CLJS compile
> time
> 
> http://thi.ng/color
> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes)
> 
> http://thi.ng/luxor
> Complete scene compiler DSL for http://luxrender.net, based around thi.ng/geom
> 
> http://thi.ng/morphogen
> Declarative 3D form evolution through tree-based transformations,
> basically an AST generator of geometric operations to transform a
> single seed node into complex 3D objects
> 
> http://thi.ng/tweeny
> Interpolation of nested (presumably animation related) data
> structures. Allows tweening of deeply nested maps/vectors with
> completely flexible tween fns/targets and hence easy definition of
> complex timelines
> 
> http://thi.ng/validate
> Purely functional, composable data validation & optional corrections
> for nested data. Supports both maps & vectors, wildcards, comes with
> many predefined validators, but extensible...
> 
> http://thi.ng/trio
> A generic, non-RDF specific triple store API and feature rich
> SPARQL-like query engine
> (and my prime example of using the literate programming approach with
> org-mode[2][3])
> 
> Last but not least: Super special thanks are due to the following people:
> 
> Rich, Alex + rest of clojure.core
> David (+everyone else involved) for the immense effort on making CLJS
> proper useful,
> Chas, Kevin and anyone else working on CLJX...
> none of this would have been possible without these amazing tools!
> 
> Best, K.
> 
> Ps. There're a number of other libs in this collection which are in
> dire need of updating (last touched spring 2013) - these are related
> to general OpenCL functionality and voxel rendering. Some of the
> example images on the above site were created with these...
> 
> [1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org
> [2] https://github.com/thi-ng/trio/blob/master/src/query.org
> [3] http://orgmode.org/
> 
> -- 
> Karsten Schmidt
> http://postspectacular.com | http://thi.ng/

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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] thi.ng collection update (CLJ/CLJS)

[adriaan . sticker]

Just took a look at your website,

Very nice project. In my opinion a prime example that clojure is suitable 
for large projects.

I don't know if anyone ever thought about it. But I guess the geom library 
would be a good option as a backend for a plotting library (ggplot style). 
(eg in incanter, gorilla repl ...) 
Especially since it both works in clojure and clojurescript. 

greets and keep up the good work

Op woensdag 25 februari 2015 06:07:09 UTC+1 schreef Karsten Schmidt:
>
> Hi guys, 
>
> thi.ng is a collection of over a dozen largely x-platform Clojure & 
> Clojurescript libs for computational/generative design & data 
> visualization tasks. 
>
> I just wanted to give a little heads up that this project has recently 
> seen a number of releases and, as a whole, by now is generally quite 
> stable and usable (*is used*) for realworld projects (although most 
> libs remain in constant parallel development to make them more feature 
> complete). I've collated a number of images of projects and links to 
> the most important libs here: 
>
> http://thi.ng/ 
>
> Most notably of those: 
>
> http://thi.ng/geom 
> By far the largest sub-project and backbone for most others: A 2D/3D 
> geometry package w/ comprehensive vector algebra, swizzling, 
> intersections, matrix types & helpers, quaternions, pure shape 
> primitives with ~50 protocols for polymorphic enquiry & manipulation, 
> meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics 
> engine (only particles, springs, behaviors)... Most of this lib is 
> pure geometry w/ no rendering specifics, although there're separate 
> modules for SVG rendering w/ shader support & decorators [1], WebGL 
> wrapper and converters from shapes/meshes to VBOs and various shader 
> presets/utils. 
>
> http://thi.ng/shadergraph 
> GLSL (WebGL) pure function library & dependency graph (based on 
> com.stuartsierra/dependency), GLSL minification during CLJS compile 
> time 
>
> http://thi.ng/color 
> RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes) 
>
> http://thi.ng/luxor 
> Complete scene compiler DSL for http://luxrender.net, based around 
> thi.ng/geom 
>
> http://thi.ng/morphogen 
> Declarative 3D form evolution through tree-based transformations, 
> basically an AST generator of geometric operations to transform a 
> single seed node into complex 3D objects 
>
> http://thi.ng/tweeny 
> Interpolation of nested (presumably animation related) data 
> structures. Allows tweening of deeply nested maps/vectors with 
> completely flexible tween fns/targets and hence easy definition of 
> complex timelines 
>
> http://thi.ng/validate 
> Purely functional, composable data validation & optional corrections 
> for nested data. Supports both maps & vectors, wildcards, comes with 
> many predefined validators, but extensible... 
>
> http://thi.ng/trio 
> A generic, non-RDF specific triple store API and feature rich 
> SPARQL-like query engine 
> (and my prime example of using the literate programming approach with 
> org-mode[2][3]) 
>
> Last but not least: Super special thanks are due to the following people: 
>
> Rich, Alex + rest of clojure.core 
> David (+everyone else involved) for the immense effort on making CLJS 
> proper useful, 
> Chas, Kevin and anyone else working on CLJX... 
> none of this would have been possible without these amazing tools! 
>
> Best, K. 
>
> Ps. There're a number of other libs in this collection which are in 
> dire need of updating (last touched spring 2013) - these are related 
> to general OpenCL functionality and voxel rendering. Some of the 
> example images on the above site were created with these... 
>
> [1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org 
> [2] https://github.com/thi-ng/trio/blob/master/src/query.org 
> [3] http://orgmode.org/ 
>
> -- 
> Karsten Schmidt 
> http://postspectacular.com | http://thi.ng/ 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

Hi guys,

thi.ng is a collection of over a dozen largely x-platform Clojure &
Clojurescript libs for computational/generative design & data
visualization tasks.

I just wanted to give a little heads up that this project has recently
seen a number of releases and, as a whole, by now is generally quite
stable and usable (*is used*) for realworld projects (although most
libs remain in constant parallel development to make them more feature
complete). I've collated a number of images of projects and links to
the most important libs here:

http://thi.ng/

Most notably of those:

http://thi.ng/geom
By far the largest sub-project and backbone for most others: A 2D/3D
geometry package w/ comprehensive vector algebra, swizzling,
intersections, matrix types & helpers, quaternions, pure shape
primitives with ~50 protocols for polymorphic enquiry & manipulation,
meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
engine (only particles, springs, behaviors)... Most of this lib is
pure geometry w/ no rendering specifics, although there're separate
modules for SVG rendering w/ shader support & decorators [1], WebGL
wrapper and converters from shapes/meshes to VBOs and various shader
presets/utils.

http://thi.ng/shadergraph
GLSL (WebGL) pure function library & dependency graph (based on
com.stuartsierra/dependency), GLSL minification during CLJS compile
time

http://thi.ng/color
RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes)

http://thi.ng/luxor
Complete scene compiler DSL for http://luxrender.net, based around thi.ng/geom

http://thi.ng/morphogen
Declarative 3D form evolution through tree-based transformations,
basically an AST generator of geometric operations to transform a
single seed node into complex 3D objects

http://thi.ng/tweeny
Interpolation of nested (presumably animation related) data
structures. Allows tweening of deeply nested maps/vectors with
completely flexible tween fns/targets and hence easy definition of
complex timelines

http://thi.ng/validate
Purely functional, composable data validation & optional corrections
for nested data. Supports both maps & vectors, wildcards, comes with
many predefined validators, but extensible...

http://thi.ng/trio
A generic, non-RDF specific triple store API and feature rich
SPARQL-like query engine
(and my prime example of using the literate programming approach with
org-mode[2][3])

Last but not least: Super special thanks are due to the following people:

Rich, Alex + rest of clojure.core
David (+everyone else involved) for the immense effort on making CLJS
proper useful,
Chas, Kevin and anyone else working on CLJX...
none of this would have been possible without these amazing tools!

Best, K.

Ps. There're a number of other libs in this collection which are in
dire need of updating (last touched spring 2013) - these are related
to general OpenCL functionality and voxel rendering. Some of the
example images on the above site were created with these...

[1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org
[2] https://github.com/thi-ng/trio/blob/master/src/query.org
[3] http://orgmode.org/

-- 
Karsten Schmidt
http://postspectacular.com | http://thi.ng/

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

project.clj dependencies auto-update

[Nikita Beloglazov]

TL;DR if you have clojure project on github you can setup Hatnik 
<http://hatnik.com/> to update dependencies by pull request once new 
versions are available

Hatnik is a project we started at ClojureCup. It allows you to subscribe to 
any libraries and perform certain actions once new versions are available. 
Recently we've added build file support meaning that now you can specify 
github repo or URL to project.clj and we will extract libraries from it. 
How to setup:

   1. Go to http://hatnik.com and login.
   2. Click "Add project".
   3. Enter project name (any text you want, this is not github repo name).
   4. Enter build file, it can be either user/repo or full URL. If you 
   specify user/repo, we assume there is a project.clj file in root directory.
   5. Select action type. By default it is "Email": you'll get email 
   notifications once new version of a dependency has been released. You might 
   want to switch to pull request. 
   6. Click "Create". It may take some time to process your project.clj 
   file. After it is done you should see all dependencies displayed along with 
   their latest versions.
   7. Forget about Hatnik until a dependency has been updated. Then you'll 
   see pull request waiting for your approval.

Hatnik is especially nice when you have tests and CI integrated with 
github. This way you can see whether pull request breaks your project or 
not almost immediately without any efforts and merge it if everything is 
ok! Note: currently Hatnik doesn't open initial pull request that updates 
all deps to latest versions. It will open pull request next time a 
dependency is released. To perform this initial update you can use 
lein-ancient <https://github.com/xsc/lein-ancient> plugin or don't do 
anything and let Hatnik update deps as they're released. 
Hatnik is an open source project and you can find it on (surprise, 
surprise) github: https://github.com/nbeloglazov/hatnik Idea is similar to 
Artifact 
Listener <https://www.artifact-listener.org/>, VersionEye 
<https://www.versioneye.com/>, Jarkeeper <https://jarkeeper.com/>, but 
Hatnik can not only notify you about deps changes but can also help you to 
update them. 

If you find bugs or have some ideas how to impove Hatnik, please create an 
issue on github. Future plans are to support more build file formats 
(pom.xml, build.sbt, Gemfile and others), support libraries from other 
languages (ruby, js, python), improve UI. If you're interested in helping 
with development, please send me a short email or open issue with your idea 
so we can discuss it.

Thanks,
Nikita

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

Re: Better update function

[Juvenn Woo]

Dear Steve,  

I’m new in clojure as well, but if we try to break up your one function into 
two, we’d have the following:

(defn update1
  "Given a two-level nested vector of maps, two keys for each map, and
  an update function. Apply the function in the inner map, and returns
  nested structure."
  [vect [k1 k2] f]
  (map
    (fn [m] (update-in m [k1] update2 k2 f))
vect))

(defn update2
  "Given a vector of maps, a key for the map, and an update function.
  Apply the function to value of the key."
  [vect k f]
  (map
    (fn [item] (update-in item [k] f))
vect))

which seems easier to follow than one, though YMMV.


Best,
--  
jv
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Monday, December 22, 2014 at 12:34 PM, Steve Ashton wrote:

> I'm trying to figure out if there is a better / more concise / more generic 
> way to write an update function. The data I have is a vector of maps 
> containing vectors of maps.  
> For example:
> [{:values [{:y 1 :x 4}{:y 2 :x 7}]}{:values [{:y 5 :x 8}]}]
>  
> The goal is to update all the :y values or all the :x values according to a 
> passed-in function. As a concrete example, I'd like to invert the sign of all 
> the :y values.
>  
> So here's the working function which I've come up with:
>  
> (defn update-nested-fields  
> "Updates a vector of maps containing vectors of maps"
> [col [k1 k2] f]
> (map (fn [outer-map]  
> (update-in outer-map  
> [k1]  
> (fn [inner-col]  
> (map
> (fn [inner-map]  
> (update-in inner-map [k2] f))  
> inner-col  
> col))
>  
>  
> ;; invert the :y values
> (update-nested-fields  
> [{:values [{:y 1 :x 4}{:y 2 :x 7}]}{:values [{:y 5 :x 8}]}]
> [:values :y]
> (partial * -1))
>  
>  
>  
> As you can see, at a simple level it is: (map (update-in (map (update-in f))).
>  
> I'm really wondering if I'm missing an obvious simplification. I've tried to 
> decide if a threading macro would help, but I don't see how, since the outer 
> collection is provided to the outermost map function, rather than the 
> inner-most function.  
>  
>  
>  
>  
>  
>  
>  
> --  
> You 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.

Better update function

[Steve Ashton]

I'm trying to figure out if there is a better / more concise / more generic 
way to write an update function. The data I have is a vector of maps 
containing vectors of maps. 
For example:
  [{:values [{:y 1 :x 4}{:y 2 :x 7}]}{:values [{:y 5 :x 8}]}]

The goal is to update all the :y values or all the :x values according to a 
passed-in function. As a concrete example, I'd like to invert the sign of 
all the :y values.

So here's the working function which I've come up with:

(defn update-nested-fields 
  "Updates a vector of maps containing vectors of maps"
  [col [k1 k2] f]
  (map (fn [outer-map] 
 (update-in outer-map 
[k1] 
(fn [inner-col] 
  (map
   (fn [inner-map] 
     (update-in inner-map [k2] f))   
   inner-col 
   col))

;; invert the :y values
(update-nested-fields 
 [{:values [{:y 1 :x 4}{:y 2 :x 7}]}{:values [{:y 5 :x 8}]}]
 [:values :y]
 (partial * -1))



As you can see, at a simple level it is: (map (update-in (map (update-in 
f))).

I'm really wondering if I'm missing an obvious simplification. I've tried 
to decide if a threading macro would help, but I don't see how, since the 
outer collection is provided to the outermost map function, rather than the 
inner-most function. 







-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

[JUAN ANTONIO Ruz]

and about ..."something that's hard to do with just Component, and easy to 
do with BigBang"
in my last example 
https://github.com/milesian/bigbang-example/blob/master/src/bigbang_example/core.clj#L60-L64

I could use 3 different library update-system actions in a specific start 
sequence (highlighting the decomplected topic too ):
{:before-start [[*identity*/add-meta-key system-map]
   [*co-dependency*/assoc-co-dependencies system-atom]
   [*identity*/assoc-meta-who-to-deps]]
 :after-start  [[*co-dependency*/update-atom-system system-atom]
[*aop*/wrap logging-function-invocation]]}



El viernes, 12 de diciembre de 2014 14:08:18 UTC, JUAN ANTONIO Ruz escribió:
>
> Hi James!
>
> You're right I wrote a lot about the relation between "component 
> definition", "update-system fn" and "system customization" but very little 
> about BigBang...
>
> Basically with the minimal code provided 
> <https://github.com/milesian/BigBang/blob/master/src/milesian/bigbang.clj>
>  (only 11LOC)  I tried to highlight the difference between an *"updated 
> system"* and a *"started system"* (an updated system using 
> component/start fn). A "started system" can only use those 
> update(s)-system that happen "*before start *(update-system % 
> component/start)*"* or "*before getting out of start function invocation 
> *(update-system 
> % #(comp fn4 fn3 component/start fn2 fn1))." 
> And taking into account that all update-system functions receive and 
> return the component, we can derive that all before update(s)-system 
> functions can be compose in the last one *(update-system % #(comp ... fn6 
> fn5 *fn4 fn3 component/start fn2 fn1* fn0 fn-1 fn-2 fn-3 ... ))*
>
> BigBang only adds 2 keywords *:before-start :after-start* and lets you 
> think and write your update(s)-actions with more clarity  (and you can 
> reuse them better too)
>
> You can check this example code with different started system actions and 
> results
>
> https://github.com/milesian/bigbang-example/blob/master/src/bigbang_example/core.clj
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmilesian%2Fbigbang-example%2Fblob%2Fmaster%2Fsrc%2Fbigbang_example%2Fcore.clj&sa=D&sntz=1&usg=AFQjCNHrA9e8ba5_ZfL65fLn5a1W4H-kDw>
>
> And if you look at the "decomplected" actions (identity 
> <https://github.com/milesian/identity/blob/master/src/milesian/identity.clj>
> , aop <https://github.com/milesian/aop/blob/master/src/milesian/aop.clj>, 
> co-dependency 
> <https://github.com/tangrammer/co-dependency/blob/master/src/tangrammer/component/co_dependency.clj#L37-L50>)
>  
> you can realise that they are really minimal and simple
>
> So summarising, BigBang easy you to write better your stuartsierra system 
> customization code
>
> I hope that this explanation helped you :)
> Thanks a lot for your review!
> Juan
>
>
>
>
>
>
>
>
>
>
> El viernes, 12 de diciembre de 2014 00:42:12 UTC+1, James Reeves escribió:
>>
>> I've read through the README, but I still don't feel like I understand 
>> what problem this library is trying to solve.
>>
>> Could you perhaps provide an example of something that's hard to do with 
>> just Component, and easy to do with BigBang?
>>
>> - James
>>
>> On 11 December 2014 at 17:31, JUAN ANTONIO Ruz  
>> wrote:
>>
>>> Hi folks, 
>>> I wanted to share here BigBang, my library proposal in customization the 
>>> way stuartsierra/component system starts.
>>>
>>> I'll copy here "*Why did I write this library*?" 
>>>
>>> After trying to get working Aspect Oriented Programming and Reverse 
>>> Dependency Injection in stuartuartsierra/component systems I realized that 
>>> system customization topic wasn't treated as it deserved
>>>
>>> Once I wrote this BigBang lib, my previous tries (AOP 
>>> <https://github.com/milesian/aop> and co-dependency 
>>> <https://github.com/tangrammer/co-dependency>) come up with more better 
>>> design, indeed this BigBang library is basically a very tiny and simple 
>>> pattern, but very useful :)
>>>
>>> I think can be interesting to get a read to this README 
>>> <https://github.com/milesian/BigBang/blob/master/README.md> because 
>>> besides presenting my solution pattern, I tried to highlight and review 
>>> very basic and  important topics as can be "what is a component?" or "how 
>>> does your sys

Re: [ANN] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

[JUAN ANTONIO Ruz]

Hi James!

You're right I wrote a lot about the relation between "component 
definition", "update-system fn" and "system customization" but very little 
about BigBang...

Basically with the minimal code provided 
<https://github.com/milesian/BigBang/blob/master/src/milesian/bigbang.clj> 
(only 
11LOC)  I tried to highlight the difference between an *"updated system"* 
and a *"started system"* (an updated system using component/start fn). A
 "started system" can only use those update(s)-system that happen "*before 
start *(update-system % component/start)*"* or "*before getting out of 
start function invocation *(update-system % #(comp fn4 fn3 component/start 
fn2 fn1))." 
And taking into account that all update-system functions receive and return 
the component, we can derive that all before update(s)-system functions can 
be compose in the last one *(update-system % #(comp ... fn6 fn5 *fn4 fn3 
component/start fn2 fn1* fn0 fn-1 fn-2 fn-3 ... ))*

BigBang only adds 2 keywords *:before-start :after-start* and lets you 
think and write your update(s)-actions with more clarity  (and you can 
reuse them better too)

You can check this example code with different started system actions and 
results
https://github.com/milesian/bigbang-example/blob/master/src/bigbang_example/core.clj

And if you look at the "decomplected" actions (identity 
<https://github.com/milesian/identity/blob/master/src/milesian/identity.clj>
, aop <https://github.com/milesian/aop/blob/master/src/milesian/aop.clj>, 
co-dependency 
<https://github.com/tangrammer/co-dependency/blob/master/src/tangrammer/component/co_dependency.clj#L37-L50>)
 
you can realise that they are really minimal and simple

So summarising, BigBang easy you to write better your stuartsierra system 
customization code

I hope that this explanation helped you :)
Thanks a lot for your review!
Juan










El viernes, 12 de diciembre de 2014 00:42:12 UTC+1, James Reeves escribió:
>
> I've read through the README, but I still don't feel like I understand 
> what problem this library is trying to solve.
>
> Could you perhaps provide an example of something that's hard to do with 
> just Component, and easy to do with BigBang?
>
> - James
>
> On 11 December 2014 at 17:31, JUAN ANTONIO Ruz  > wrote:
>
>> Hi folks, 
>> I wanted to share here BigBang, my library proposal in customization the 
>> way stuartsierra/component system starts.
>>
>> I'll copy here "*Why did I write this library*?" 
>>
>> After trying to get working Aspect Oriented Programming and Reverse 
>> Dependency Injection in stuartuartsierra/component systems I realized that 
>> system customization topic wasn't treated as it deserved
>>
>> Once I wrote this BigBang lib, my previous tries (AOP 
>> <https://github.com/milesian/aop> and co-dependency 
>> <https://github.com/tangrammer/co-dependency>) come up with more better 
>> design, indeed this BigBang library is basically a very tiny and simple 
>> pattern, but very useful :)
>>
>> I think can be interesting to get a read to this README 
>> <https://github.com/milesian/BigBang/blob/master/README.md> because 
>> besides presenting my solution pattern, I tried to highlight and review 
>> very basic and  important topics as can be "what is a component?" or "how 
>> does your system start?"
>>
>> Hope you enjoy it!
>>
>> https://github.com/milesian/BigBang
>>
>>
>>  -- 
>> 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.

Re: [ANN] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

[James Reeves]

I've read through the README, but I still don't feel like I understand what
problem this library is trying to solve.

Could you perhaps provide an example of something that's hard to do with
just Component, and easy to do with BigBang?

- James

On 11 December 2014 at 17:31, JUAN ANTONIO Ruz 
wrote:

> Hi folks,
> I wanted to share here BigBang, my library proposal in customization the
> way stuartsierra/component system starts.
>
> I'll copy here "*Why did I write this library*?"
>
> After trying to get working Aspect Oriented Programming and Reverse
> Dependency Injection in stuartuartsierra/component systems I realized that
> system customization topic wasn't treated as it deserved
>
> Once I wrote this BigBang lib, my previous tries (AOP
>  and co-dependency
> ) come up with more better
> design, indeed this BigBang library is basically a very tiny and simple
> pattern, but very useful :)
>
> I think can be interesting to get a read to this README
>  because
> besides presenting my solution pattern, I tried to highlight and review
> very basic and  important topics as can be "what is a component?" or "how
> does your system start?"
>
> Hope you enjoy it!
>
> https://github.com/milesian/BigBang
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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.

[ANN] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

[JUAN ANTONIO Ruz]

Hi folks, 
I wanted to share here BigBang, my library proposal in customization the 
way stuartsierra/component system starts.

I'll copy here "*Why did I write this library*?" 

After trying to get working Aspect Oriented Programming and Reverse 
Dependency Injection in stuartuartsierra/component systems I realized that 
system customization topic wasn't treated as it deserved

Once I wrote this BigBang lib, my previous tries (AOP 
 and co-dependency 
) come up with more better 
design, indeed this BigBang library is basically a very tiny and simple 
pattern, but very useful :)

I think can be interesting to get a read to this README 
 because besides 
presenting my solution pattern, I tried to highlight and review very basic 
and  important topics as can be "what is a component?" or "how does your 
system start?"

Hope you enjoy it!

https://github.com/milesian/BigBang


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

[UPDATE] Spring/Clojure integration / changing Clojure references via JMX attributes

[henrik42]

Hello again,

just in case anybody is following this - I added stuff that lets you 
publish your mutable references (atom, ref, var) as JMX attributes so that 
you may use jconsole to change things at runtime. 

https://github.com/henrik42/spring-break#changing-mutable-state-references-via-jmx-attributes

Publishing is as easy as




  


-- Henrik

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

[UPDATE] Spring/Clojure integration / Clojure functions via JMX

[henrik42]

Hi folks,
I added code that lets you call your clojure functions via JMX operations.

https://github.com/henrik42/spring-break#jmxmbeans

Cheers Henrik

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[Bertrand Dechoux]

@Francois Rey : I totally forgot that Datomic could be used on regular data 
structures. Thanks a lot, it might indeed be something to investigate.

@Frank Castellucci : Indeed, I guess someone working with ontologies would 
have the same concerns. Thanks for all the pointers.

Le vendredi 11 juillet 2014 03:48:51 UTC+2, Frank Castellucci a écrit :
>
> Bertrand
>
> I've been doing a lot of Ontology (OWL) with directed graphs (with cycles) 
> and DAGS. One application we went with the nested map structure however now 
> that I've been working on a normalized BPMN/XPDL utility ( 
> https://github.com/FrankC01/tributary 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FFrankC01%2Ftributary&sa=D&sntz=1&usg=AFQjCNGzsWatrlDLLVU4uXDM-UEbR_wDjA>
>  
> ) I'm becoming enamored with the in XML format produced by xml-parse and 
> then zipping it up. Coupled with clojures 'functional' nature, zippers 
> become your friend really quickly and provide a most generic way of dealing 
> with any graph with any number of layers.
>
> The next step will be a normalized DSL on top of the zippers and using 
> things like hickory-parse/data.zip selector concepts.
>
> For the Ontology work we use datomic as the persist mechanism.
>
>
>
> On Thursday, July 10, 2014 4:26:33 AM UTC-4, Bertrand Dechoux wrote:
>>
>> Hi,
>>
>> I have various general questions about how one can perform simple and 
>> flexible graph query/update.
>>
>> If we start by a structure being nested maps then I know about 
>> get-in/update-in/assoc-in. The common point about these functions is that 
>> they all take a path to where the data is in the superstructure and that 
>> this path is only a sequence of keys, which may or not be symbols.
>>
>> 1) What happens when one layer of this superstructure is not a map but a 
>> sequence? For the sake of the argument, we can keep the discussion simple 
>> by only arguing about the vector case.
>>
>> Typically instead of
>> { :key1 { :key2 val }}
>>
>> we now have
>> { :key1 [{ :key2 val }]}
>>
>> Of course, one can perform get/update/assoc using map/reduce. However, it 
>> means that the code using this superstructure is taking a hit on 
>> complexity/maintenance each time a non-map layer must be crossed. Of 
>> course, the simplicity/beauty of the current implementation is that a path 
>> can point to at most one target substructure/value. Is there a way to do 
>> something similar with a more general definition of a path? One would 
>> assume that it is something that might be handled by xml/html modification 
>> libraries (think xpath or css selector) but this problem is more general 
>> and not domain specific. Is there a clean library that handle that case 
>> without being tied to html/xml?
>>
>> 2) How to deal with more general superstructure like a graph?
>>
>> One could build an immutable graph but I don't believe it is something 
>> that can be done by nesting immutable maps and vectors. One solution to 
>> deal with 'entity'--'entity' relationships is for one of the member to own 
>> only an identifier to get the other member from another reference structure.
>>
>> (from the basic OM tutorial:)
>>
>> {:people
>>  [{:type :student :first "Ben" :last "Bitdiddle"}
>>   {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 
>> :6946]}]
>>  :classes
>>  {:6001 "The Structure and Interpretation of Computer Programs"
>>   :6946 "The Structure and Interpretation of Classical Mechanics"
>>   :1806 "Linear Algebra"}}
>>
>>
>> It is, of course, again, manually possible to get/update/assoc using 
>> map/reduce.  But then, again, this is the same problematic as with the 
>> first question : each time a relation needs to be crossed, the code using 
>> this superstructure is taking a hit on complexity/maintenance. How do you 
>> usually deal with this problematic?
>>
>> For both question 1) and 2), a more appropriate data structure might be 
>> the answer like a graph/semantic-like store (Datomic or something else). 
>> The questions are about intermediary solutions which would be less heavier.
>>
>> 3) How does Demeter lives with graph traversal?
>>
>> This law is often heard in the OOP world but it is a bit more general 
>> than that. When a long path on a superstructure is specified then if one 
>> intermediary layer is introduced later, all hardcoded paths will be broken 

Re: 101 on simple and flexible graph query/update?

[Frank Castellucci]

Bertrand

I've been doing a lot of Ontology (OWL) with directed graphs (with cycles) 
and DAGS. One application we went with the nested map structure however now 
that I've been working on a normalized BPMN/XPDL utility 
( https://github.com/FrankC01/tributary ) I'm becoming enamored with the in 
XML format produced by xml-parse and then zipping it up. Coupled with 
clojures 'functional' nature, zippers become your friend really quickly and 
provide a most generic way of dealing with any graph with any number of 
layers.

The next step will be a normalized DSL on top of the zippers and using 
things like hickory-parse/data.zip selector concepts.

For the Ontology work we use datomic as the persist mechanism.



On Thursday, July 10, 2014 4:26:33 AM UTC-4, Bertrand Dechoux wrote:
>
> Hi,
>
> I have various general questions about how one can perform simple and 
> flexible graph query/update.
>
> If we start by a structure being nested maps then I know about 
> get-in/update-in/assoc-in. The common point about these functions is that 
> they all take a path to where the data is in the superstructure and that 
> this path is only a sequence of keys, which may or not be symbols.
>
> 1) What happens when one layer of this superstructure is not a map but a 
> sequence? For the sake of the argument, we can keep the discussion simple 
> by only arguing about the vector case.
>
> Typically instead of
> { :key1 { :key2 val }}
>
> we now have
> { :key1 [{ :key2 val }]}
>
> Of course, one can perform get/update/assoc using map/reduce. However, it 
> means that the code using this superstructure is taking a hit on 
> complexity/maintenance each time a non-map layer must be crossed. Of 
> course, the simplicity/beauty of the current implementation is that a path 
> can point to at most one target substructure/value. Is there a way to do 
> something similar with a more general definition of a path? One would 
> assume that it is something that might be handled by xml/html modification 
> libraries (think xpath or css selector) but this problem is more general 
> and not domain specific. Is there a clean library that handle that case 
> without being tied to html/xml?
>
> 2) How to deal with more general superstructure like a graph?
>
> One could build an immutable graph but I don't believe it is something 
> that can be done by nesting immutable maps and vectors. One solution to 
> deal with 'entity'--'entity' relationships is for one of the member to own 
> only an identifier to get the other member from another reference structure.
>
> (from the basic OM tutorial:)
>
> {:people
>  [{:type :student :first "Ben" :last "Bitdiddle"}
>   {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 
> :6946]}]
>  :classes
>  {:6001 "The Structure and Interpretation of Computer Programs"
>   :6946 "The Structure and Interpretation of Classical Mechanics"
>   :1806 "Linear Algebra"}}
>
>
> It is, of course, again, manually possible to get/update/assoc using 
> map/reduce.  But then, again, this is the same problematic as with the 
> first question : each time a relation needs to be crossed, the code using 
> this superstructure is taking a hit on complexity/maintenance. How do you 
> usually deal with this problematic?
>
> For both question 1) and 2), a more appropriate data structure might be 
> the answer like a graph/semantic-like store (Datomic or something else). 
> The questions are about intermediary solutions which would be less heavier.
>
> 3) How does Demeter lives with graph traversal?
>
> This law is often heard in the OOP world but it is a bit more general than 
> that. When a long path on a superstructure is specified then if one 
> intermediary layer is introduced later, all hardcoded paths will be broken 
> ie in multiple locations in the code base. One would like to store local 
> structure knowledge in a single place. How do you usually deal with this 
> problematic?
>
> I have yet to take a serious look at lenses and their composition, they 
> are probably an element of answer, but they are more often seen in more 
> statically typed langage.
>
> Thanks for any feedback.
>
> Bertrand
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[François Rey]

Also of interest is datomic datalog on regular clojure data structures 
and records:

https://gist.github.com/stuarthalloway/2645453
https://gist.github.com/stuarthalloway/3068749

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[Bertrand Dechoux]

*@*Thomas Heller: It's a bit cleaner indeed. That way, a 'join-like' 
operation does not need to know about the structure. But the three 
problematics from my post are still unsolved.

*@Francois Rey:* I believe walk/prewalk/postwalk (and zipper?) might be the 
building blocks for implementing query/update based on a more flexible path 
definition. But by themselves, they are a bit low level. They indeed are 
beautiful and useful abstractions but I think another abstraction, even 
higher, could be built.

*@Daniel Neal:* I will look into it. I am new to lenses as I said. I don't 
know if a lens can target multiple structures at once (first question).

(def s { :key1 [{ :key2 { :key3 val } }]})
(update-in s [:key1 :all :key2 :key3] inc)

The principle might work with a custom lens but I guess it is likely the 
implementation for the traversal must be changed in order to handle a 
sequence at each step. But at least I have a place where I can start from.

Bertrand


Le jeudi 10 juillet 2014 13:26:57 UTC+2, Daniel Neal a écrit :
>
> > Is there a way to do something similar with a more general definition of 
> a path? 
>
> The lens library Fresnel (https://github.com/ckirkendall/fresnel) might 
> be worth a look - it abstracts
> get-in/assoc-in into lenses which can store/retrieve state from complex 
> structures (and can be composed). 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[Daniel Neal]

> Is there a way to do something similar with a more general definition of 
a path? 

The lens library Fresnel (https://github.com/ckirkendall/fresnel) might be 
worth a look - it abstracts
get-in/assoc-in into lenses which can store/retrieve state from complex 
structures (and can be composed). 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[François Rey]

On 10/07/14 10:26, Bertrand Dechoux wrote:
For both question 1) and 2), a more appropriate data structure might 
be the answer like a graph/semantic-like store (Datomic or something 
else). The questions are about intermediary solutions which would be 
less heavier.


I would suggest you look into the walk 
/prewalk 
/postwalk 
 functions. 
These are able to traverse arbitrary nested data structures while 
building a different or modified data structure.



3) How does Demeter lives with graph traversal?

This law is often heard in the OOP world but it is a bit more general 
than that. When a long path on a superstructure is specified then if 
one intermediary layer is introduced later, all hardcoded paths will 
be broken ie in multiple locations in the code base. One would like to 
store local structure knowledge in a single place. How do you usually 
deal with this problematic?


I have yet to take a serious look at lenses and their composition, 
they are probably an element of answer, but they are more often seen 
in more statically typed langage.


The walk /prewalk 
/postwalk 
 can support 
some resilience with respects to structural changes if one can recognize 
what any data structure represents at any level based on its content 
(e.g. a :type key).


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: 101 on simple and flexible graph query/update?

[Thomas Heller]

I usually just give every ENTITY in my system a primary id and structure 
everything in a nested map.

{:people {1 {:id 1 :type :student :name "Ben" :taking-classes #{1 2}}
  2 ...}
 :classes {1 {:id 1 :name "Clojure 101"}
   2 ...}}

This basically looks like a database table. You can also go with something 
a little more flat.

{1 {:type :student, :name "Ben" :taking-classes #{3}}
 3 {:type :class, :name "Clojure 101"}}

Usually needs some form of indexing otherwise you are taking some 
performance hits if you have alot of entities in your system. You dont want 
to (->> (vals @data) (filter #(= :class (:type %))) every time you want to 
list all :classes.

Nothing fancy but it is simple. 


On Thursday, July 10, 2014 10:26:33 AM UTC+2, Bertrand Dechoux wrote:
>
> Hi,
>
> I have various general questions about how one can perform simple and 
> flexible graph query/update.
>
> If we start by a structure being nested maps then I know about 
> get-in/update-in/assoc-in. The common point about these functions is that 
> they all take a path to where the data is in the superstructure and that 
> this path is only a sequence of keys, which may or not be symbols.
>
> 1) What happens when one layer of this superstructure is not a map but a 
> sequence? For the sake of the argument, we can keep the discussion simple 
> by only arguing about the vector case.
>
> Typically instead of
> { :key1 { :key2 val }}
>
> we now have
> { :key1 [{ :key2 val }]}
>
> Of course, one can perform get/update/assoc using map/reduce. However, it 
> means that the code using this superstructure is taking a hit on 
> complexity/maintenance each time a non-map layer must be crossed. Of 
> course, the simplicity/beauty of the current implementation is that a path 
> can point to at most one target substructure/value. Is there a way to do 
> something similar with a more general definition of a path? One would 
> assume that it is something that might be handled by xml/html modification 
> libraries (think xpath or css selector) but this problem is more general 
> and not domain specific. Is there a clean library that handle that case 
> without being tied to html/xml?
>
> 2) How to deal with more general superstructure like a graph?
>
> One could build an immutable graph but I don't believe it is something 
> that can be done by nesting immutable maps and vectors. One solution to 
> deal with 'entity'--'entity' relationships is for one of the member to own 
> only an identifier to get the other member from another reference structure.
>
> (from the basic OM tutorial:)
>
> {:people
>  [{:type :student :first "Ben" :last "Bitdiddle"}
>   {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 
> :6946]}]
>      :classes
>  {:6001 "The Structure and Interpretation of Computer Programs"
>   :6946 "The Structure and Interpretation of Classical Mechanics"
>   :1806 "Linear Algebra"}}
>
>
> It is, of course, again, manually possible to get/update/assoc using 
> map/reduce.  But then, again, this is the same problematic as with the 
> first question : each time a relation needs to be crossed, the code using 
> this superstructure is taking a hit on complexity/maintenance. How do you 
> usually deal with this problematic?
>
> For both question 1) and 2), a more appropriate data structure might be 
> the answer like a graph/semantic-like store (Datomic or something else). 
> The questions are about intermediary solutions which would be less heavier.
>
> 3) How does Demeter lives with graph traversal?
>
> This law is often heard in the OOP world but it is a bit more general than 
> that. When a long path on a superstructure is specified then if one 
> intermediary layer is introduced later, all hardcoded paths will be broken 
> ie in multiple locations in the code base. One would like to store local 
> structure knowledge in a single place. How do you usually deal with this 
> problematic?
>
> I have yet to take a serious look at lenses and their composition, they 
> are probably an element of answer, but they are more often seen in more 
> statically typed langage.
>
> Thanks for any feedback.
>
> Bertrand
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.

101 on simple and flexible graph query/update?

[Bertrand Dechoux]

Hi,

I have various general questions about how one can perform simple and 
flexible graph query/update.

If we start by a structure being nested maps then I know about 
get-in/update-in/assoc-in. The common point about these functions is that 
they all take a path to where the data is in the superstructure and that 
this path is only a sequence of keys, which may or not be symbols.

1) What happens when one layer of this superstructure is not a map but a 
sequence? For the sake of the argument, we can keep the discussion simple 
by only arguing about the vector case.

Typically instead of
{ :key1 { :key2 val }}

we now have
{ :key1 [{ :key2 val }]}

Of course, one can perform get/update/assoc using map/reduce. However, it 
means that the code using this superstructure is taking a hit on 
complexity/maintenance each time a non-map layer must be crossed. Of 
course, the simplicity/beauty of the current implementation is that a path 
can point to at most one target substructure/value. Is there a way to do 
something similar with a more general definition of a path? One would 
assume that it is something that might be handled by xml/html modification 
libraries (think xpath or css selector) but this problem is more general 
and not domain specific. Is there a clean library that handle that case 
without being tied to html/xml?

2) How to deal with more general superstructure like a graph?

One could build an immutable graph but I don't believe it is something that 
can be done by nesting immutable maps and vectors. One solution to deal 
with 'entity'--'entity' relationships is for one of the member to own only 
an identifier to get the other member from another reference structure.

(from the basic OM tutorial:)

{:people
 [{:type :student :first "Ben" :last "Bitdiddle"}
  {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 :6946]}]
 :classes
 {:6001 "The Structure and Interpretation of Computer Programs"
  :6946 "The Structure and Interpretation of Classical Mechanics"
  :1806 "Linear Algebra"}}


It is, of course, again, manually possible to get/update/assoc using 
map/reduce.  But then, again, this is the same problematic as with the 
first question : each time a relation needs to be crossed, the code using 
this superstructure is taking a hit on complexity/maintenance. How do you 
usually deal with this problematic?

For both question 1) and 2), a more appropriate data structure might be the 
answer like a graph/semantic-like store (Datomic or something else). The 
questions are about intermediary solutions which would be less heavier.

3) How does Demeter lives with graph traversal?

This law is often heard in the OOP world but it is a bit more general than 
that. When a long path on a superstructure is specified then if one 
intermediary layer is introduced later, all hardcoded paths will be broken 
ie in multiple locations in the code base. One would like to store local 
structure knowledge in a single place. How do you usually deal with this 
problematic?

I have yet to take a serious look at lenses and their composition, they are 
probably an element of answer, but they are more often seen in more 
statically typed langage.

Thanks for any feedback.

Bertrand

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Clojure.contrib.sql: How do I update ALL the rows of a database table?

[Sean Corfield]

On Jun 26, 2014, at 4:03 PM, Raoul Duke  wrote:
> e.g. things that turn up in google:
> http://dev.clojure.org/display/doc/Clojure+Contrib+Libraries

Which says:

"If you currently depend on the "Monolithic Contrib", you are encouraged to 
look at the new modular contrib projects to see if your dependency could be 
replaced by specific modular dependencies, as this will make your transition to 
Clojure 1.3 and beyond easier (certain parts of the "Monolithic Contrib" are no 
longer compatible with Clojure 1.3 and beyond)."

And it links to this page: 
http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go which, 
amongst other things, says:

"clojure.contrib.sql
• Migrated to clojure.java.jdbc"

What wording would you suggest we add to either/both of these pages?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Clojure: Clojure.contrib.sql: How do I update ALL the rows of a database table?

[Raoul Duke]

er, should the various pages be updated to say that they are all super
deprecated now?
e.g. things that turn up in google:
http://dev.clojure.org/display/doc/Clojure+Contrib+Libraries

On Thu, Jun 26, 2014 at 3:58 PM, Sean Corfield  wrote:
> Clojure Contrib libraries are all deprecated and very out of date.
>
> For clojure.contrib.sql, you'll want to use clojure.java.jdbc instead.
> Complete (community-maintained) documentation can be found here:
>
> http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html
>
> Reference documentation can be found here:
>
> http://clojure.github.io/java.jdbc/
>
> Sean
>
> On Jun 25, 2014, at 7:40 AM, June  wrote:
>
> clojuredocs.org/clojure_contrib/clojure.contrib.sql/… How do I set the where
> clause to 1=1?
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Clojure.contrib.sql: How do I update ALL the rows of a database table?

[Sean Corfield]

Clojure Contrib libraries are all deprecated and very out of date.

For clojure.contrib.sql, you'll want to use clojure.java.jdbc instead. Complete 
(community-maintained) documentation can be found here:

http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html

Reference documentation can be found here:

http://clojure.github.io/java.jdbc/

Sean

On Jun 25, 2014, at 7:40 AM, June  wrote:
> clojuredocs.org/clojure_contrib/clojure.contrib.sql/… How do I set the where 
> clause to 1=1?




signature.asc
Description: Message signed with OpenPGP using GPGMail

Clojure: Clojure.contrib.sql: How do I update ALL the rows of a database table?

[June]

*clojuredocs.org/clojure_contrib/clojure.contrib.sql/…* 
<http://clojuredocs.org/clojure_contrib/clojure.contrib.sql/update-values#example_953>
 
How do I set the where clause to 1=1? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Ustun Ozgur]

On Tuesday, June 10, 2014 11:35:34 PM UTC+3, Sergey Didenko wrote:
>
> Sorry if that was already answered,
>
> Is there a possibility to get rid of this legalwall?
>
>
Interestingly, node.js has just done that 
today: http://www.joyent.com/blog/broadening-node-js-contributions

Ustun



>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Sergey Didenko]

I look at it from the psychological point of view.

There is a similar design decision in a website world - mandatory login vs
relaxed login. For years a lot of webmasters were quite inert to even look
at possibility to relax login requirement for core site activities.

However in the online shopping field which is very competitive webmasters
realized that for example adding products to the cart without login gives
better conversion rates.

We don't need to sign anything to answer on StackOverflow, even login is
not required now. We don't need to sign anything to make "GitHub pull
requests" to a lot of projects. Somehow it makes life smoother.

I don't know what impact of this barrier can be for Clojure. I realize it
can be quite negligible.

However as example I have not signed some papers for my Google Closure
library patch in the past. It just looked so absurd to fill some papers for
"if (!variable)" => "if (variable === 0)" kind of fix.

I realize that there are real world constraints and the world is not
perfect and the world is not even close to be perfect. But dreaming about
better ways is a part of Clojure community, isn't it?

May be the best solution is just to be vocal that the sign process is quick
and easy now. Or may be doing nothing about it because there are more
priority tasks.

I hope I convey my perspective better now.

P.S. Please don't "cut my air away" :))

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Atamert Ölçgen]

Excuse my ignorance. But from what I've read, it all seems fair game.
Essentially contributors are assigning the same rights they have to
project's creator, no? What exactly feels wrong to you?


On Tue, Jun 10, 2014 at 8:35 PM, Sergey Didenko 
wrote:

> Sorry if that was already answered,
>
> Is there a possibility to get rid of this legalwall?
>
> I realize that there are good intents behind the existing practice, but it
> feels a bit wrong for an open source artifact in the digital age of instant
> sharing.
>
>
>
>
> > Starting today, we have updated the Clojure Contributor Agreement
>>> process.
>>>
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

Re: Clojure Contributor Agreement process update

[Luc Prefontaine]

 What about the real world
constraints ?

As far as I know, everyone needs
air, water, heat, and a minimal food 
ration to survive.

The day I cut your air away, I bet
you'll be suddenly be very concerned
about the 'the physical world' and
that you will relinquish the 
'digital age' way back in some
remote primitive place in your brain :)

Ok, lawyers are not as vital as air,
however they flourish on litigation
systems like some plants in dump
yards.

The day you are stuck in a lawsuit
or the day someone steals something
you have created and you have not
cared about these 'real' things you 
are left alone on an ice bank, plenty 
of air I agree but seldom provided
with a grocery store and a Starbuck...

Contrary to popular belief, sharing does not imply that you
allow others to steal your ideas so
they can make $ out of them or claim
that it's now their own
and that you should get lost.

I hope you stay anchored in the
real world :)))

Luc P.

> Sorry if that was already answered,
> 
> Is there a possibility to get rid of this legalwall?
> 
> I realize that there are good intents behind the existing practice, but it
> feels a bit wrong for an open source artifact in the digital age of instant
> sharing.
> 
> 
> 
> > Starting today, we have updated the Clojure Contributor Agreement
> >> process.
> >>
> >
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to 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 Prefontaine 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.

Re: Clojure Contributor Agreement process update

[Timothy Baldridge]

Welcome to the "real world", where programmer ideals are often overridden
by the concerns of lawyers. That's what it comes down to, you have to do it
this way in the US (and other places) or risk legal issues.

https://www.clahub.com/pages/why_cla

Timothy


On Tue, Jun 10, 2014 at 2:35 PM, Sergey Didenko 
wrote:

> Sorry if that was already answered,
>
> Is there a possibility to get rid of this legalwall?
>
> I realize that there are good intents behind the existing practice, but it
> feels a bit wrong for an open source artifact in the digital age of instant
> sharing.
>
>
>
>
> > Starting today, we have updated the Clojure Contributor Agreement
>>> process.
>>>
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: Clojure Contributor Agreement process update

[Sergey Didenko]

Sorry if that was already answered,

Is there a possibility to get rid of this legalwall?

I realize that there are good intents behind the existing practice, but it
feels a bit wrong for an open source artifact in the digital age of instant
sharing.



> Starting today, we have updated the Clojure Contributor Agreement
>> process.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Michael O'Keefe]

Thank you for all you do. This is wonderful!

-Michael O'Keefe

On Tuesday, June 10, 2014 6:49:52 AM UTC-6, Tim Visher wrote:
>
> (boom) 
>
> On Mon, Jun 9, 2014 at 1:23 PM, Alex Miller  > wrote: 
> > Starting today, we have updated the Clojure Contributor Agreement 
> process. 
> > The prior process which involved signing and mailing a form has been 
> > replaced with an online e-signing process. 
> > 
> > Existing contributors that have signed the Contributor Agreement are 
> > unaffected - those agreements are still in effect. New signers will use 
> the 
> > online process. 
> > 
> > Information has been updated at: 
> > http://clojure.org/contributing 
> > 
> > As always, we welcome your contributions to the Clojure community and 
> hope 
> > that we can continue to improve Clojure together! 
> > 
> > - Alex Miller, Rich Hickey, and the Clojure team 
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Clojure Dev" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure-dev...@googlegroups.com . 
> > To post to this group, send email to cloju...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/clojure-dev. 
> > 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 Contributor Agreement process update

[Tim Visher]

(boom)

On Mon, Jun 9, 2014 at 1:23 PM, Alex Miller  wrote:
> Starting today, we have updated the Clojure Contributor Agreement process.
> The prior process which involved signing and mailing a form has been
> replaced with an online e-signing process.
>
> Existing contributors that have signed the Contributor Agreement are
> unaffected - those agreements are still in effect. New signers will use the
> online process.
>
> Information has been updated at:
> http://clojure.org/contributing
>
> As always, we welcome your contributions to the Clojure community and hope
> that we can continue to improve Clojure together!
>
> - Alex Miller, Rich Hickey, and the Clojure team
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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 Contributor Agreement process update

[Andrey Antukh]

Very nice! \o/


2014-06-09 20:57 GMT+02:00 Plínio Balduino :

> \o/
>
> On Mon, Jun 9, 2014 at 3:34 PM, Michael Klishin
>  wrote:
> > 2014-06-09 21:23 GMT+04:00 Alex Miller :
> >
> >> Starting today, we have updated the Clojure Contributor Agreement
> process.
> >> The prior process which involved signing and mailing a form has been
> >> replaced with an online e-signing process.
> >
> >
> > \o/
> > --
> > MK
> >
> > http://github.com/michaelklishin
> > http://twitter.com/michaelklishin
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Plínio Balduino]

\o/

On Mon, Jun 9, 2014 at 3:34 PM, Michael Klishin
 wrote:
> 2014-06-09 21:23 GMT+04:00 Alex Miller :
>
>> Starting today, we have updated the Clojure Contributor Agreement process.
>> The prior process which involved signing and mailing a form has been
>> replaced with an online e-signing process.
>
>
> \o/
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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 Contributor Agreement process update

[Michael Klishin]

2014-06-09 21:23 GMT+04:00 Alex Miller :

> Starting today, we have updated the Clojure Contributor Agreement process.
> The prior process which involved signing and mailing a form has been
> replaced with an online e-signing process.


\o/
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 Contributor Agreement process update

[Alex Miller]

Starting today, we have updated the Clojure Contributor Agreement process.
The prior process which involved signing and mailing a form has been
replaced with an online e-signing process.

Existing contributors that have signed the Contributor Agreement are
unaffected - those agreements are still in effect. New signers will use the
online process.

Information has been updated at:
http://clojure.org/contributing

As always, we welcome your contributions to the Clojure community and hope
that we can continue to improve Clojure together!

- Alex Miller, Rich Hickey, and the Clojure 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/d/optout.

Re: Strange update-in Behavior

[Stuart Fehr]

Ah, for some reason, I had it in my head that the value found in the map 
was the *last* argument passed to the function.

This behavior makes a lot more sense now. Thanks for the clarification!

On Thursday, May 29, 2014 11:00:58 AM UTC-6, Stuart Fehr wrote:
>
> I am not sure if this is considered a "bug" or if it is simply expected 
> behavior, so I thought I would ask the list for clarification.
>
> I have this test which passes and shows the strange behavior that I am 
> encountering:
>
> (deftest update-in-and-remove
>   ;; The leaf value becomes and empty list instead of [1 3]
>   (is (= {:mykey {:myotherkey '()}}
>  (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey] 
> remove #{2})))
>   ;; Forcing a vector results in the behavior that I would expect
>   (is (= {:mykey {:myotherkey [1 3]}}
>  (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey] 
> (comp vec (partial remove #{2}))
>
> I think this behavior is due to the use of apply in the definition of 
> update-in and I think (but haven't tested) adding a partial to the 
> non-recursive clause will fix this:
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L5687
>
> However, I don't want to submit a "fix" if this is the expected behavior. 
> Thoughts?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Strange update-in Behavior

[Ben Wolfson]

it is expected behavior, because update-in calls the supplied function with
the value it finds in the map as the first argument, so your first call
ends up being

(remove [1 2 3] #{2})

Since ([1 2 3] 2) = 3 and is truthy, the result is ().

In your second case you're using (partial remove #{2}), so the result is
'(1 3), which is then turned into a vector by vec.


On Thu, May 29, 2014 at 10:00 AM, Stuart Fehr  wrote:

> I am not sure if this is considered a "bug" or if it is simply expected
> behavior, so I thought I would ask the list for clarification.
>
> I have this test which passes and shows the strange behavior that I am
> encountering:
>
> (deftest update-in-and-remove
>   ;; The leaf value becomes and empty list instead of [1 3]
>   (is (= {:mykey {:myotherkey '()}}
>  (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey]
> remove #{2})))
>   ;; Forcing a vector results in the behavior that I would expect
>   (is (= {:mykey {:myotherkey [1 3]}}
>  (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey]
> (comp vec (partial remove #{2}))
>
> I think this behavior is due to the use of apply in the definition of
> update-in and I think (but haven't tested) adding a partial to the
> non-recursive clause will fix this:
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L5687
>
> However, I don't want to submit a "fix" if this is the expected behavior.
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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.
>



-- 
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/d/optout.

Strange update-in Behavior

[Stuart Fehr]

I am not sure if this is considered a "bug" or if it is simply expected 
behavior, so I thought I would ask the list for clarification.

I have this test which passes and shows the strange behavior that I am 
encountering:

(deftest update-in-and-remove
  ;; The leaf value becomes and empty list instead of [1 3]
  (is (= {:mykey {:myotherkey '()}}
 (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey] 
remove #{2})))
  ;; Forcing a vector results in the behavior that I would expect
  (is (= {:mykey {:myotherkey [1 3]}}
 (update-in {:mykey {:myotherkey [1 2 3]}} [:mykey :myotherkey] 
(comp vec (partial remove #{2}))

I think this behavior is due to the use of apply in the definition of 
update-in and I think (but haven't tested) adding a partial to the 
non-recursive clause will fix this:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L5687

However, I don't want to submit a "fix" if this is the expected behavior. 
Thoughts?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Andrew Chambers]

For the llvm based approach you can look at vmkit.

On Wednesday, April 30, 2014 3:39:21 AM UTC+12, Divyansh Prakash wrote:
>
> Check out my previous reply. The parrot vm provides gc and everything, But 
> still the author defines lambda primitives in c, and then builds over it.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

Check out my previous reply. The parrot vm provides gc and everything, But 
still the author defines lambda primitives in c, and then builds over it.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Gary Trakhman]

The hard part with other runtimes will be details around things like
garbage collection for the implementation of persistent data structures.

Clojurescript is a better example of how this is done since most of the
impls are implemented in the language itself, different from
clojure-proper.

Granted, printed-text compiler output sucks, but it all seems to work.

Here's the javascript emission stage:
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L206

It's been ported to gambit-scheme:
https://github.com/takeoutweight/clojure-scheme/blob/rewrite/src/clj/cljscm/compiler.clj



On Tue, Apr 29, 2014 at 10:45 AM, Divyansh Prakash <
divyanshprakas...@gmail.com> wrote:

> I looked into a port of Clojure to Parrot, and it basically does the same
> thing
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

Why not emit bytecode directly from the language?
Couldn't this potentially lead to tons of specialized optimizing macros? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

I looked into a port of Clojure to Parrot, and it basically does the same 
thing
.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

Thank you for the explanation.
What if I target a non-OO-centric VM (like Parrot or LLVM)?

I've noticed that most Lisp implementations define lambda calculus 
primitives, and then use those as the core.
I wonder what would be if we had bytecode primitives, and defined 
everything else on top of that. 
I don't know to what end, this is just an exercise.

Do you know if this has been done before?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[David Powell]

The JVM is very class-oriented.  It is basically designed for Java, and
corresponds pretty much to the things you can do in Java.  Code belongs to
methods which belong to classes, and calls are made using java method
calling conventions.  Data has to be stored in primitives, arrays, or
objects; and arrays aren't particularly to-the-metal in Java anyway.

The Byte Code Verifier keeps what you do fairly simple - eg you can't just
leave things in the stack and jump to another method.

Even if you wanted to do anything a bit different, the performance of the
JVM all comes from the assumptions made while executing the bytecodes at
runtime.  If you did anything very weird, you'd probably find that these
optimizations didn't kick in.



On Tue, Apr 29, 2014 at 9:25 AM, Divyansh Prakash <
divyanshprakas...@gmail.com> wrote:

> Why are Clojure features defined in terms of Java classes, instead of as
> bytecode primitives?
> For eg: Cons is a class containing two objects: first and rest.
> Is this only to achieve Java interoperability, or is there more to it?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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: Update

[Andrew Chambers]

Well, why write it in primitives when there is a perfectly good compiler 
from java to primitives? I dont quite understand why you think there would 
be benefit from manually writing everything with java bytecode. The JVM 
works with classes, thats how its designed, Clojure itself is just a java 
library.

On Tuesday, April 29, 2014 8:25:01 PM UTC+12, Divyansh Prakash wrote:
>
> Why are Clojure features defined in terms of Java classes, instead of as 
> bytecode primitives?
> For eg: Cons is a class containing two objects: first and rest.
> Is this only to achieve Java interoperability, or is there more to it?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

Why are Clojure features defined in terms of Java classes, instead of as 
bytecode primitives?
For eg: Cons is a class containing two objects: first and rest.
Is this only to achieve Java interoperability, or is there more to it?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

>
> Thanks!
>
 Exactly what I was looking for.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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: Update

[Gary Trakhman]

Seen: https://github.com/clojure/tools.emitter.jvm ?
Here's the actual ASM emit:
https://github.com/clojure/tools.emitter.jvm/blob/master/src/main/clojure/clojure/tools/emitter/jvm/transform.clj


On Mon, Apr 28, 2014 at 5:43 PM, Divyansh Prakash <
divyanshprakas...@gmail.com> wrote:

> ---IDEA---
> I was wondering if we could have a bytecode DSL that would map directly to
> JVM assembler, using either Jasmin  or
> Krakatau .
> Then we could define primitives using these bytecode instructions.
> For eg:
>
> (defroutine + [a b]
> (push! a)
> (push! b)
> add!
> pop!)
>
> that could be used to call:
>
> (+ 2 3) ;=> 5
>
> --
> We could define the lambda calculus primitives in the same way.
> This would be awesome because bottlenecks could be optimized by embedding
> assembly inside Lisp itself.
> We could do efficient bit-manipulation, write shader routines, and what
> not.
>
> --
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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: Update

[Divyansh Prakash]

Jasmin would be a much better choice, btw, because it could be used as a 
dependency in 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/d/optout.

Update

[Divyansh Prakash]

---IDEA---
I was wondering if we could have a bytecode DSL that would map directly to 
JVM assembler, using either Jasmin  or 
Krakatau .
Then we could define primitives using these bytecode instructions.
For eg:

(defroutine + [a b]
(push! a)
(push! b)
add!
pop!)

that could be used to call:

(+ 2 3) ;=> 5

--
We could define the lambda calculus primitives in the same way.
This would be awesome because bottlenecks could be optimized by embedding 
assembly inside Lisp itself.
We could do efficient bit-manipulation, write shader routines, and what not.

--
Thoughts?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 I update a record in a vector, matching certain criteria?

[Ivan Schuetz]

Hi,

thanks a lot! I ended putting the question in StackOverflow, yesterday, and 
also got this answer. It would have took a while until I came up with this. 
But now I understand.

For my concrete case I needed to update the record with all fields passed 
in a map. So I did:

 (commute items
  #(mapv (fn [i]
   (if (= (:id i) id)
 (merge i params)
 i))
 %)))



Am Mittwoch, 9. April 2014 03:24:21 UTC+2 schrieb Leif:
>
> Hi, Ivan.
>
> (defn set-item-name [data id newname]
>   (mapv #(if (not= (:id %) id)  ; <- NB mapv keeps it a vector 
> % ; no-op
>  (assoc % :name newname))
> data))
>
> (dosync (commute items set-item-name 1 "foo"))
>
> This really only makes sense if :id is *not* actually a primary key in 
> your data, 
>
> If, however, :id *is* a primary key, and most of the operations on the 
> data are only updating one element, you will want to follow Gary's advice 
> and change your data to
>
> {1 {:id 1 :name ...}
>  2 {:id 2 :name ...}
>  ...}
>
> I would also like to validate your feeling that this shouldn't be a 
> one-liner; you can generalize 'set-item-name', and then if you do want to 
> change the data structure later, you only have to change the general 
> function.
>
> --Leif
>
> On Tuesday, April 8, 2014 7:10:13 PM UTC-4, Ivan Schuetz wrote:
>>
>> As I said I already looked in the docs, and know these basic examples, 
>> but I don't know how to do:
>>
>> *"How can I say in a vector of records e.g. "set name of element to "foo" 
>> where id is equal 1"?"*
>>
>>
>> The remove by Id works, I posted it only to show something which might be 
>> similar to the update I'm looking for.
>>
>> I also wrote filter:
>>
>> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>>
>> This gives me the element I need to update, but I still don't know how I 
>> update this element in the vector.
>>
>>
>>
>> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>>
>>> Maybe this will help:
>>>
>>> > (update-in [[] 2 3 4] [0] (constantly 1))
>>> [1 2 3 4]
>>>
>>> > (update-in [[] 2 3 4] [2] (constantly 1))
>>> [ [ ] 2 1 4]
>>>
>>> > (update-in [[] 2 3 4] [1] (constantly 1))
>>> [ [ ] 1 3 4]
>>>
>>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>>> java.lang.IllegalArgumentException: Key must be integer
>>>
>>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>>> [ [{:a :b}] 2 3 4]
>>>
>>>
>>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz  wrote:
>>>
>>>> I would use merge to update the record with the map... but I don't know 
>>>> how to get it from filter operation. Maybe I should not solve this with 
>>>> 1-liner.
>>>>
>>>> Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:
>>>>
>>>>> Ahh dataprovider/products should be "items". Forgot to "simplify".
>>>>>
>>>>>
>>>>> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> sorry I don't get it. I just started learning Clojure.
>>>>>>
>>>>>> I did this to remove element with id 1
>>>>>>
>>>>>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>>>>>
>>>>>> From your statement I understand update-in would work for the update, 
>>>>>> but I don't know the syntax. Something like
>>>>>>
>>>>>> (commute dataprovider/products #(update-in % {:id id}  (->Item 
>>>>>> ???) ))
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>>>>>
>>>>>>>
>>>>>>>> But 1. Can't find examples with records, 2. Not sure if I can use 
>>>>>>>> it to update a different field than the one I'm using to do the query. 
>>>>>>>> In 
>>>>>>>> the examples fields seem to be the same.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>

Re: How do I update a record in a vector, matching certain criteria?

[Leif]

Hi, Ivan.

(defn set-item-name [data id newname]
  (mapv #(if (not= (:id %) id)  ; <- NB mapv keeps it a vector 
% ; no-op
 (assoc % :name newname))
data))

(dosync (commute items set-item-name 1 "foo"))

This really only makes sense if :id is *not* actually a primary key in your 
data, 

If, however, :id *is* a primary key, and most of the operations on the data 
are only updating one element, you will want to follow Gary's advice and 
change your data to

{1 {:id 1 :name ...}
 2 {:id 2 :name ...}
 ...}

I would also like to validate your feeling that this shouldn't be a 
one-liner; you can generalize 'set-item-name', and then if you do want to 
change the data structure later, you only have to change the general 
function.

--Leif

On Tuesday, April 8, 2014 7:10:13 PM UTC-4, Ivan Schuetz wrote:
>
> As I said I already looked in the docs, and know these basic examples, but 
> I don't know how to do:
>
> *"How can I say in a vector of records e.g. "set name of element to "foo" 
> where id is equal 1"?"*
>
>
> The remove by Id works, I posted it only to show something which might be 
> similar to the update I'm looking for.
>
> I also wrote filter:
>
> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>
> This gives me the element I need to update, but I still don't know how I 
> update this element in the vector.
>
>
>
> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>
>> Maybe this will help:
>>
>> > (update-in [[] 2 3 4] [0] (constantly 1))
>> [1 2 3 4]
>>
>> > (update-in [[] 2 3 4] [2] (constantly 1))
>> [ [ ] 2 1 4]
>>
>> > (update-in [[] 2 3 4] [1] (constantly 1))
>> [ [ ] 1 3 4]
>>
>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>> java.lang.IllegalArgumentException: Key must be integer
>>
>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>> [ [{:a :b}] 2 3 4]
>>
>>
>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz  wrote:
>>
>>> I would use merge to update the record with the map... but I don't know 
>>> how to get it from filter operation. Maybe I should not solve this with 
>>> 1-liner.
>>>
>>> Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:
>>>
>>>> Ahh dataprovider/products should be "items". Forgot to "simplify".
>>>>
>>>>
>>>> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>>>>
>>>>> Hi,
>>>>>
>>>>> sorry I don't get it. I just started learning Clojure.
>>>>>
>>>>> I did this to remove element with id 1
>>>>>
>>>>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>>>>
>>>>> From your statement I understand update-in would work for the update, 
>>>>> but I don't know the syntax. Something like
>>>>>
>>>>> (commute dataprovider/products #(update-in % {:id id}  (->Item 
>>>>> ???) ))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>>>>
>>>>>>
>>>>>>> But 1. Can't find examples with records, 2. Not sure if I can use it 
>>>>>>> to update a different field than the one I'm using to do the query. In 
>>>>>>> the 
>>>>>>> examples fields seem to be the same.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Leave off the last path segment and return the full updated record, 
>>>>>> not just the new field's value.
>>>>>>
>>>>>  -- 
>>> 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.

Re: How do I update a record in a vector, matching certain criteria?

[Gary Trakhman]

Ah, actually, there's one mistake in my responses, you want to change out
the element based on id, not index, in which case I'd simply recommend map
or mapv.  Just remember anytime you change one thing you have to iterate
over the whole vector, worst-case, O(n).

If you use a map of :id to record, updates are O(log32 n), which is much
better.


On Tue, Apr 8, 2014 at 7:18 PM, Gary Trakhman wrote:

> Alternatively, you could sprinkle (into [] ..) to feed the result of
> remove/filter back into a vector.
>
>
> On Tue, Apr 8, 2014 at 7:16 PM, Gary Trakhman wrote:
>
>> My response had the assumption that this is an example of an X-Y problem
>> :-).
>>
>> If you want to literally do what you said, then you can't use update-in
>> because the value at that point is a seq.
>>
>> If you have to continue in this way, for some reason, what you probably
>> want is map-indexed, which provides the index of the element as one of the
>> parameters to the mapping function.
>>
>> You could use a helper to build a function that only operates on that
>> particular element.
>>
>> I caution that you might run into a stackoverflow due to laziness if you
>> do this enough without realizing the seq.
>>
>> This just feels unidiomatic to me, though.
>>
>>
>>
>>
>>
>> On Tue, Apr 8, 2014 at 7:10 PM, Ivan Schuetz wrote:
>>
>>> As I said I already looked in the docs, and know these basic examples,
>>> but I don't know how to do:
>>>
>>> *"How can I say in a vector of records e.g. "set name of element to
>>> "foo" where id is equal 1"?"*
>>>
>>>
>>> The remove by Id works, I posted it only to show something which might
>>> be similar to the update I'm looking for.
>>>
>>> I also wrote filter:
>>>
>>> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>>>
>>> This gives me the element I need to update, but I still don't know how I
>>> update this element in the vector.
>>>
>>>
>>>
>>> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>>>
>>>> Maybe this will help:
>>>>
>>>> > (update-in [[] 2 3 4] [0] (constantly 1))
>>>> [1 2 3 4]
>>>>
>>>> > (update-in [[] 2 3 4] [2] (constantly 1))
>>>> [ [ ] 2 1 4]
>>>>
>>>> > (update-in [[] 2 3 4] [1] (constantly 1))
>>>> [ [ ] 1 3 4]
>>>>
>>>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>>>> java.lang.IllegalArgumentException: Key must be integer
>>>>
>>>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>>>> [ [{:a :b}] 2 3 4]
>>>>
>>>>
>>>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz wrote:
>>>>
>>>>> I would use merge to update the record with the map... but I don't
>>>>> know how to get it from filter operation. Maybe I should not solve this
>>>>> with 1-liner.
>>>>>
>>>>> Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:
>>>>>
>>>>>> Ahh dataprovider/products should be "items". Forgot to "simplify".
>>>>>>
>>>>>>
>>>>>> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry I don't get it. I just started learning Clojure.
>>>>>>>
>>>>>>> I did this to remove element with id 1
>>>>>>>
>>>>>>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>>>>>>
>>>>>>> From your statement I understand update-in would work for the
>>>>>>> update, but I don't know the syntax. Something like
>>>>>>>
>>>>>>> (commute dataprovider/products #(update-in % {:id id}  (->Item
>>>>>>> ???) ))
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>>>>>>
>>>>>>>>
>>>>>>>>> But 1. Can't find examples with records, 2. Not sure if I can use
>>>>>>>>> it to update a different field than the one I'm using 

Re: How do I update a record in a vector, matching certain criteria?

[Gary Trakhman]

Alternatively, you could sprinkle (into [] ..) to feed the result of
remove/filter back into a vector.


On Tue, Apr 8, 2014 at 7:16 PM, Gary Trakhman wrote:

> My response had the assumption that this is an example of an X-Y problem
> :-).
>
> If you want to literally do what you said, then you can't use update-in
> because the value at that point is a seq.
>
> If you have to continue in this way, for some reason, what you probably
> want is map-indexed, which provides the index of the element as one of the
> parameters to the mapping function.
>
> You could use a helper to build a function that only operates on that
> particular element.
>
> I caution that you might run into a stackoverflow due to laziness if you
> do this enough without realizing the seq.
>
> This just feels unidiomatic to me, though.
>
>
>
>
>
> On Tue, Apr 8, 2014 at 7:10 PM, Ivan Schuetz wrote:
>
>> As I said I already looked in the docs, and know these basic examples,
>> but I don't know how to do:
>>
>> *"How can I say in a vector of records e.g. "set name of element to "foo"
>> where id is equal 1"?"*
>>
>>
>> The remove by Id works, I posted it only to show something which might be
>> similar to the update I'm looking for.
>>
>> I also wrote filter:
>>
>> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>>
>> This gives me the element I need to update, but I still don't know how I
>> update this element in the vector.
>>
>>
>>
>> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>>
>>> Maybe this will help:
>>>
>>> > (update-in [[] 2 3 4] [0] (constantly 1))
>>> [1 2 3 4]
>>>
>>> > (update-in [[] 2 3 4] [2] (constantly 1))
>>> [ [ ] 2 1 4]
>>>
>>> > (update-in [[] 2 3 4] [1] (constantly 1))
>>> [ [ ] 1 3 4]
>>>
>>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>>> java.lang.IllegalArgumentException: Key must be integer
>>>
>>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>>> [ [{:a :b}] 2 3 4]
>>>
>>>
>>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz  wrote:
>>>
>>>> I would use merge to update the record with the map... but I don't know
>>>> how to get it from filter operation. Maybe I should not solve this with
>>>> 1-liner.
>>>>
>>>> Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:
>>>>
>>>>> Ahh dataprovider/products should be "items". Forgot to "simplify".
>>>>>
>>>>>
>>>>> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> sorry I don't get it. I just started learning Clojure.
>>>>>>
>>>>>> I did this to remove element with id 1
>>>>>>
>>>>>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>>>>>
>>>>>> From your statement I understand update-in would work for the update,
>>>>>> but I don't know the syntax. Something like
>>>>>>
>>>>>> (commute dataprovider/products #(update-in % {:id id}  (->Item
>>>>>> ???) ))
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>>>>>
>>>>>>>
>>>>>>>> But 1. Can't find examples with records, 2. Not sure if I can use
>>>>>>>> it to update a different field than the one I'm using to do the query. 
>>>>>>>> In
>>>>>>>> the examples fields seem to be the same.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Leave off the last path segment and return the full updated record,
>>>>>>> not just the new field's value.
>>>>>>>
>>>>>>  --
>>>> 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 unsubsc

Re: How do I update a record in a vector, matching certain criteria?

[Gary Trakhman]

My response had the assumption that this is an example of an X-Y problem
:-).

If you want to literally do what you said, then you can't use update-in
because the value at that point is a seq.

If you have to continue in this way, for some reason, what you probably
want is map-indexed, which provides the index of the element as one of the
parameters to the mapping function.

You could use a helper to build a function that only operates on that
particular element.

I caution that you might run into a stackoverflow due to laziness if you do
this enough without realizing the seq.

This just feels unidiomatic to me, though.





On Tue, Apr 8, 2014 at 7:10 PM, Ivan Schuetz  wrote:

> As I said I already looked in the docs, and know these basic examples, but
> I don't know how to do:
>
> *"How can I say in a vector of records e.g. "set name of element to "foo"
> where id is equal 1"?"*
>
>
> The remove by Id works, I posted it only to show something which might be
> similar to the update I'm looking for.
>
> I also wrote filter:
>
> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>
> This gives me the element I need to update, but I still don't know how I
> update this element in the vector.
>
>
>
> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>
>> Maybe this will help:
>>
>> > (update-in [[] 2 3 4] [0] (constantly 1))
>> [1 2 3 4]
>>
>> > (update-in [[] 2 3 4] [2] (constantly 1))
>> [ [ ] 2 1 4]
>>
>> > (update-in [[] 2 3 4] [1] (constantly 1))
>> [ [ ] 1 3 4]
>>
>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>> java.lang.IllegalArgumentException: Key must be integer
>>
>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>> [ [{:a :b}] 2 3 4]
>>
>>
>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz  wrote:
>>
>>> I would use merge to update the record with the map... but I don't know
>>> how to get it from filter operation. Maybe I should not solve this with
>>> 1-liner.
>>>
>>> Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:
>>>
>>>> Ahh dataprovider/products should be "items". Forgot to "simplify".
>>>>
>>>>
>>>> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>>>>
>>>>> Hi,
>>>>>
>>>>> sorry I don't get it. I just started learning Clojure.
>>>>>
>>>>> I did this to remove element with id 1
>>>>>
>>>>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>>>>
>>>>> From your statement I understand update-in would work for the update,
>>>>> but I don't know the syntax. Something like
>>>>>
>>>>> (commute dataprovider/products #(update-in % {:id id}  (->Item
>>>>> ???) ))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>>>>
>>>>>>
>>>>>>> But 1. Can't find examples with records, 2. Not sure if I can use it
>>>>>>> to update a different field than the one I'm using to do the query. In 
>>>>>>> the
>>>>>>> examples fields seem to be the same.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Leave off the last path segment and return the full updated record,
>>>>>> not just the new field's value.
>>>>>>
>>>>>  --
>>> 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