dependency problem

['Alan Forrester' via Clojure]

I have been trying to use the Twitter API library by Adam Wynne:

https://github.com/adamwynne/twitter-api

and it appears to have a dependency problem.

My project.clj file looks like this

(defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.7.0"]
[twitter-api "0.7.8"]])

And when I ran "lein deps :tree” I got

[twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"]
 overrides
[twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] -> 
[commons-codec "1.9" :exclusions [org.clojure/clojure]]

What is the recommended way to deal with a problem like this?

Alan

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

AOT uberjar building broken - anyone know a workaround?

[Michael Sperber]

We have a fairly large Clojure application which we're deploying as an
uberjar.  We'd like to deploy AOT, but are running into this:

http://dev.clojure.org/jira/browse/CLJ-1544

Unless I misread, it means that AOT compilation is essentially broken.
The workaround suggest there is to only AOT the entry points, but this
slows down startup from 15s to >1min, which is hard to stomach.

Any suggestions on how to work around this?  Help would be much
appreciated!

-- 
Regards,
Mike

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

[Juan A. Ruz @tangrammer]

Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version 
required by any dep of your project
so ...

you can 
  :exclusions [org.clojure/clojure
   commons-codec]
  :dependencies [[org.clojure/clojure "1.7.0"]
 [commons-codec "1.9"]
 [twitter-api "0.7.8"]]





El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>
> I have been trying to use the Twitter API library by Adam Wynne: 
>
> https://github.com/adamwynne/twitter-api 
>
> and it appears to have a dependency problem. 
>
> My project.clj file looks like this 
>
> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT" 
>   :description "FIXME: write description" 
>   :url "http://example.com/FIXME"; 
>   :license {:name "Eclipse Public License" 
> :url "http://www.eclipse.org/legal/epl-v10.html"} 
>   :dependencies [[org.clojure/clojure "1.7.0"] 
> [twitter-api "0.7.8"]]) 
>
> And when I ran "lein deps :tree” I got 
>
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"] 
>  overrides 
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] -> 
> [commons-codec "1.9" :exclusions [org.clojure/clojure]] 
>
> What is the recommended way to deal with a problem like this? 
>
> Alan

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

Re: dependency problem

[Juan A. Ruz @tangrammer]

(sorry previous comment was sent before I wanted  :- )
Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version 
required by any dep of your project
so ...

you could exclude globally (using :exclusions)  your dependencies that are 
causing the conflict and specified later in your :dependencies 
  :exclusions [org.clojure/clojure
 commons-codec]
  :dependencies [[org.clojure/clojure "1.7.0"]
   [commons-codec "1.9"]
   [twitter-api "0.7.8"]]

or just exclude it locally
  :dependencies [[org.clojure/clojure "1.7.0"]
   [commons-codec "1.9"]
   [twitter-api "0.7.8" :exclusions 
[commons-codec]]]

Hope it works for you!
Juan

El viernes, 13 de mayo de 2016, 12:41:43 (UTC+2), Juan A. Ruz @tangrammer 
escribió:
>
> Hi Alan,
> I think you should keep commons-code 1.9 as far as is the last-version 
> required by any dep of your project
> so ...
>
> you can 
>   :exclusions [org.clojure/clojure
>commons-codec]
>   :dependencies [[org.clojure/clojure "1.7.0"]
>  [commons-codec "1.9"]
>  [twitter-api "0.7.8"]]
>
>
>
>
>
> El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>>
>> I have been trying to use the Twitter API library by Adam Wynne: 
>>
>> https://github.com/adamwynne/twitter-api 
>>
>> and it appears to have a dependency problem. 
>>
>> My project.clj file looks like this 
>>
>> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT" 
>>   :description "FIXME: write description" 
>>   :url "http://example.com/FIXME"; 
>>   :license {:name "Eclipse Public License" 
>> :url "http://www.eclipse.org/legal/epl-v10.html"} 
>>   :dependencies [[org.clojure/clojure "1.7.0"] 
>> [twitter-api "0.7.8"]]) 
>>
>> And when I ran "lein deps :tree” I got 
>>
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"] 
>>  overrides 
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] -> 
>> [commons-codec "1.9" :exclusions [org.clojure/clojure]] 
>>
>> What is the recommended way to deal with a problem like this? 
>>
>> Alan
>
>

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

Re: dependency problem

['Alan Forrester' via Clojure]

On 13 May 2016, at 11:46, Juan A. Ruz @tangrammer  
wrote:

> (sorry previous comment was sent before I wanted  :- )
> Hi Alan,
> I think you should keep commons-code 1.9 as far as is the last-version 
> required by any dep of your project
> so ...
> 
> you could exclude globally (using :exclusions)  your dependencies that are 
> causing the conflict and specified later in your :dependencies 
>   :exclusions [org.clojure/clojure
>  commons-codec]
>   :dependencies [[org.clojure/clojure "1.7.0"]
>[commons-codec "1.9"]
>[twitter-api "0.7.8"]]
> 
> or just exclude it locally
>   :dependencies [[org.clojure/clojure "1.7.0"]
>[commons-codec "1.9"]
>[twitter-api "0.7.8" :exclusions [commons-codec]]]

Your second suggestion seems to have worked.

Thanks,
Alan

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

Re: changing metadata questions

[hiskennyness]

>
>
> OK, I am working with refs, let's do it!:
>
> (let [x (with-meta (ref {:a 42})
>> {:raw 17})]
>>(alter-meta! x #(update-in % [:raw] inc))
>>(meta x))
>
>
> Nope. IRef cannot be cast to IObj. ...google...google... Hunh? The :meta 
> option on ref? 
>
> [1] Why the special mechanism? 
>
> Well, when in Rome...:
>
> (let [x (ref {:a 42}
>>  :meta {:m 17})]
>>   (alter-meta! x #(assoc-in % [:m] 64))
>>   (meta x))
>> ;; => {:m 64}
>
>
> Booyow!
>
> The bad news is that the metadata is about the map, not the ref. 
>

Hmmm. The map inside the ref will change on each update, so the metadata 
would be lost. OK, on the ref it goes. But this question remains:
 

> [2] If I modify the map inside the ref and the ref's metadata at the same 
> time, will the latter "stick" even if the former gets rolled back?
>

-hk

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

[Sean Corfield]

What?
   Clojure contrib wrapper for JDBC
   org.clojure/java.jdbc 0.6.1 bug fix release
   https://github.com/clojure/java.jdbc#change-log

Release 0.6.1 on 2016-05-12 -- IMPORTANT BUG FIX!

• insert! and insert-multi! now default :transaction? to true (as they should 
have done in 0.6.0!) JDBC-128. These two functions also have improved 
docstrings to clarify the difference in behavior between inserting rows as maps 
compared to inserting rows as a series of column values.
• PostgreSQL support has been improved: java.jdbc is now tested against 
PostgreSQL locally (as well as SQLite, Apache Derby, HSQLDB, H2, MySQL, MS SQL 
Server (both MS Type 4 driver and jTDS driver). JDBC-127 and JDBC-129.

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

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood



On 5/11/16, 6:24 PM, "Sean Corfield"  wrote:
>What?
>   Clojure contrib wrapper for JDBC
>   org.clojure/java.jdbc 0.6.0 “gold” release
>   https://github.com/clojure/java.jdbc#change-log
>
>The “gold” release of java.jdbc is now available after several alpha / RC 
>builds over the past month. This release provides a cleaned up API that is 
>much more composable and consistent than the API that had evolved up through 
>the 0.5.x series of releases.
>
>To migrate to 0.6.0, I recommend you upgrade to 0.5.8 and look for the 
>DEPRECATED warnings that will appear on the console if you are using any 
>features that will break in 0.6.0.
>
>Change Log:
>
>Release 0.6.0 on 2016-05-11 -- BREAKING RELEASE! DEPRECATED FUNCTIONALITY 
>REMOVED!
>
>• NEW BUG: find-by-keys now correctly handles nil values JDBC-126. 0.6.0 / 
>2016-05-11.
>• NEW BUG: find-by-keys calls seq on :order-by to treat [] as no ORDER BY 
>clause. 0.6.0 / 2016-05-11.
>• CHANGE: db-query-with-resultset now accepts an options map and passes it to 
>prepare-statement JDBC-125. 0.6.0-rc2 / 2016-05-07.
>• CHANGE: Passing the prepare-statement options map as the first element of 
>the [sql & params] vector is no longer supported and will throw an 
>IllegalArgumentException. It was always very poorly documented and almost 
>never used, as far as I can tell.
>• OLD BUG: db-query-with-resultset no longer requires the sql-params argument 
>to be a vector: a sequence is acceptable. This is in line with other functions 
>that accept a sequence. 0.6.0-rc2 / 2016-05-07.
>• OLD BUG: db-query-with-resultset now accepts a bare SQL string or 
>PreparedStatement as the sql-params argument, when there are no parameters 
>needed. This is in line with other functions that accept SQL or a 
>PreparedStatement. 0.6.0-rc2 / 2016-05-07.
>• CHANGE: query's options map now is passed to db-query-with-resultset and 
>thus can contain options to be used to construct the PreparedStatement 
>JDBC-125. 0.6.0-rc2 / 2016-05-07.
>• NEW API: Adds get-by-id and find-by-keys convenience functions (these were 
>easy to add after the API changes in 0.6.0 and we rely very heavily on them at 
>World Singles so putting them in the core for everyone seemed reasonable). 
>0.6.0-rc1 / 2016-05-04.
>• NEW API: find-by-keys accepts an :order-by option that expects a sequence of 
>orderings; an ordering is a column name (keyword) or a map from column name 
>(keyword) to direction (:asc or :desc). 0.6.0-rc2 / 2016-05-07.
>• OLD BUG: Ensures SQL / params are actually vectors prior to destructuring 
>(this addresses an interop edge case from other languages) JDBC-124. 
>0.6.0-alpha2 / 2016-04-18.
>• NEW BUG: Fix typo in insert-multi! argument validation exception JDBC-123. 
>0.6.0-alpha2 / 2016-04-18.
>• ALL DEPRECATED FUNCTIONALITY HAS BEEN REMOVED! JDBC-118. 0.6.0-alpha1 / 
>2016-04-13
>- See changes described in versions 0.5.5 through 0.5.8 for what was deprecated
>- Use version 0.5.8 as a bridge to identify any deprecated API calls on which 
>your code relies!
>- db-transaction (deprecated in version 0.3.0) has been removed
>- The java.jdbc.deprecated namespace has been removed
>
>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)
>
>
>
>


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

Re: understanding a clojuredocs merge example

[Jason Felice]

(def baz (partial merge {:opt1 "default-1" :opt2 "default-2"}))

:)

On Thu, May 12, 2016 at 5:08 PM, hiskennyness  wrote:

>
>
> On Thursday, May 12, 2016 at 9:33:29 AM UTC-4, Michael Willis wrote:
>>
>> As long as we're cutting out unnecessary code, this is also equivalent:
>>
>> (defn baz [options]
>>(merge {:opt1 "default-1" :opt2 "default-2"} options))
>>
>>
> Heh-heh, I was going to point that out. And now baz is a crippled form of
> merge.
>
> Good examples are tough!
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: I knew that primitives were better, but this is ridiculous

[Michael Willis]

I'm also really interested in the topic of indexing a CES game engine.  At 
one point I was trying to build a game, and mine was designed with 
components being maps of entity-id -> value.  I found that it worked really 
well to quickly do things like running a function for all entities that 
have a hunger component (for example), but I soon found myself wanting to 
filter entities based on some arbitrary criteria, like "run this function 
for all coniferous trees with age greater than X".  If the environment has 
tens of thousands of trees, it would be nicer to have an index on the age, 
along with an index on the variety of trees, so that it doesn't have to 
iterate over more entities than necessary.

Every time I go to the hammock (so to speak) to think over how to design 
such a system, I realize that I'm just re-inventing the database, so I come 
away feeling like somewhere, somehow there must already exist an in-memory 
database that will suit the problem, but I haven't determined what it is 
yet.

On Thursday, May 12, 2016 at 11:51:31 PM UTC-5, James Reeves wrote:
>
> If we want improve lookup performance in a SQL database, we place an index 
> on a column, or a group of columns. The same idea can be applied to a data 
> structure we keep in memory.
>
> So if you know that you want to lookup entities by position and velocity, 
> you could have an indexing function like:
>
>   (fn [index entity]
> (when (and (:position entity) (:velocity entity))
>   (assoc-in index [:mobile (:id entity)] entity)))
>
> And then you just need a way to run that index each time an entity is 
> added to your in-memory database. Naturally you'd also need a "unindex" 
> function as well.
>
> I've written a game library called Ittyon that works along these lines.
>
> - James
>
>
> On 13 May 2016 at 00:31, JvJ > wrote:
>
>> I'm intrigued, but I don't know exactly what you mean.
>>
>> On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote:
>>>
>>> Have you considered defining specific indexes? For instance, if you know 
>>> ahead of time that you want to search for entities that have both position 
>>> and velocity, you could define an index that keys both of those values.
>>>
>>> - James
>>>
>>>
>>>
>>> On 12 May 2016 at 23:50, JvJ  wrote:
>>>
 Maybe this is a little off-topic, but on the general topic of 
 performance, other than just numerical performance, what's the best way to 
 get information/advice on how to improve it.

 I went about doing these tests (and other tests) because I'm trying to 
 create a game scripting framework in clojure, which I want to build around
 an entity-component-system architecture.  Entities are maps of 
 components, and system functions are defined to sort of "pattern match" 
 against
 entities to see if they have the required components.  (i.e. an 
 update-position function would add velocity to position, so it only 
 applies 
 to entities
 with both a position and a velocity component).

 The first step in this process is to find a way to store these so that 
 it would be as fast as possible to iterate over "all entities with this 
 set 
 of components",
 while avoiding things like filter operations.

 I started off by making cross-map , 
 which cross-indexes any entries with keys of the form [r c], where r is a 
 row and c is a column, and allows O(1) access
 of entire rows and columns.

 Still, though, the performance tests 
  
 aren't what I expected they would be, and I'm wondering how to go about 
 dealing with that.

 Again, this isn't strictly about numerical performance, but it's why 
 I'm doing these kinds of tests in the first place.

 Thanks.

 On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>
> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto  
> wrote: 
> > Fair enough, but in this case types wouldn't really have helped: the 
> author did use `Double` type hints, mistakenly assuming that would make 
> its 
> code use primitive types, which it does not since `Double` is boxed and 
> not 
> primitive. 
> > Clojure already has compile time warnings about boxed math that 
> would've helped in this case if turned on, without any need for types: 
> try 
> compiling OP's code after running `(set! *unchecked-math* 
> :warn-on-boxed)` 
>
> Thanks for the details re: double. Apologies for being annoyed/ing. 
>
> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We 
> can relive the ignominious history of "$!" in Haskell. 
>
 -- 
 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 

Re: I knew that primitives were better, but this is ridiculous

[Alan Thompson]

It sounds like DataScript may be just what you need:
https://github.com/tonsky/datascript
Alan

On Fri, May 13, 2016 at 11:50 AM, Michael Willis 
wrote:

> I'm also really interested in the topic of indexing a CES game engine.  At
> one point I was trying to build a game, and mine was designed with
> components being maps of entity-id -> value.  I found that it worked really
> well to quickly do things like running a function for all entities that
> have a hunger component (for example), but I soon found myself wanting to
> filter entities based on some arbitrary criteria, like "run this function
> for all coniferous trees with age greater than X".  If the environment has
> tens of thousands of trees, it would be nicer to have an index on the age,
> along with an index on the variety of trees, so that it doesn't have to
> iterate over more entities than necessary.
>
> Every time I go to the hammock (so to speak) to think over how to design
> such a system, I realize that I'm just re-inventing the database, so I come
> away feeling like somewhere, somehow there must already exist an in-memory
> database that will suit the problem, but I haven't determined what it is
> yet.
>
> On Thursday, May 12, 2016 at 11:51:31 PM UTC-5, James Reeves wrote:
>>
>> If we want improve lookup performance in a SQL database, we place an
>> index on a column, or a group of columns. The same idea can be applied to a
>> data structure we keep in memory.
>>
>> So if you know that you want to lookup entities by position and velocity,
>> you could have an indexing function like:
>>
>>   (fn [index entity]
>> (when (and (:position entity) (:velocity entity))
>>   (assoc-in index [:mobile (:id entity)] entity)))
>>
>> And then you just need a way to run that index each time an entity is
>> added to your in-memory database. Naturally you'd also need a "unindex"
>> function as well.
>>
>> I've written a game library called Ittyon that works along these lines.
>>
>> - James
>>
>>
>> On 13 May 2016 at 00:31, JvJ  wrote:
>>
>>> I'm intrigued, but I don't know exactly what you mean.
>>>
>>> On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote:

 Have you considered defining specific indexes? For instance, if you
 know ahead of time that you want to search for entities that have both
 position and velocity, you could define an index that keys both of those
 values.

 - James



 On 12 May 2016 at 23:50, JvJ  wrote:

> Maybe this is a little off-topic, but on the general topic of
> performance, other than just numerical performance, what's the best way to
> get information/advice on how to improve it.
>
> I went about doing these tests (and other tests) because I'm trying to
> create a game scripting framework in clojure, which I want to build around
> an entity-component-system architecture.  Entities are maps of
> components, and system functions are defined to sort of "pattern match"
> against
> entities to see if they have the required components.  (i.e. an
> update-position function would add velocity to position, so it only 
> applies
> to entities
> with both a position and a velocity component).
>
> The first step in this process is to find a way to store these so that
> it would be as fast as possible to iterate over "all entities with this 
> set
> of components",
> while avoiding things like filter operations.
>
> I started off by making cross-map ,
> which cross-indexes any entries with keys of the form [r c], where r is a
> row and c is a column, and allows O(1) access
> of entire rows and columns.
>
> Still, though, the performance tests
> 
> aren't what I expected they would be, and I'm wondering how to go about
> dealing with that.
>
> Again, this isn't strictly about numerical performance, but it's why
> I'm doing these kinds of tests in the first place.
>
> Thanks.
>
> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>>
>> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto 
>> wrote:
>> > Fair enough, but in this case types wouldn't really have helped:
>> the author did use `Double` type hints, mistakenly assuming that would 
>> make
>> its code use primitive types, which it does not since `Double` is boxed 
>> and
>> not primitive.
>> > Clojure already has compile time warnings about boxed math that
>> would've helped in this case if turned on, without any need for types: 
>> try
>> compiling OP's code after running `(set! *unchecked-math* 
>> :warn-on-boxed)`
>>
>> Thanks for the details re: double. Apologies for being annoyed/ing.
>>
>> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)?
>> We
>> can relive the ign

Re: I knew that primitives were better, but this is ridiculous

[James Reeves]

On 13 May 2016 at 19:50, Michael Willis  wrote:
>
> Every time I go to the hammock (so to speak) to think over how to design
> such a system, I realize that I'm just re-inventing the database, so I come
> away feeling like somewhere, somehow there must already exist an in-memory
> database that will suit the problem, but I haven't determined what it is
> yet.
>

This was my reason for developing Ittyon
. It's essentially an in-memory
database with arbitrary indexing and network support for games. I couldn't
find any other database which met my specific criteria, but Ittyon has many
similarities with Datomic/Datascript in its design.

- James

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

Iterate over transient map

[JvJ]

I'm implementing a data structure, cross-map 
, which cross-indexes keys with the 
structure [row column].

I'm also trying to implement a transient version to speed things up a bit. 
 However, I would like to do certain iteration operations on the transient 
itself without having to call persistent! if possible.

I realize that the transient-to-persistent conversion should ideally be 
O(1), but there are certain cases where I have to iterate over some 
structures to achieve what I'm looking for.

Is there a way to get some kind of iterator for a transient map?  I 
understand that lazy-sequences are bad for mutability, but even a 
java-style imperative iterator would be good.

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: I knew that primitives were better, but this is ridiculous

[JvJ]

Actually, I just achieved substantial performance gains with cross-map 
iteration.

Previously, if I was iterating over rows/cols, I would check each one for 
the relevant components.  Now, I do an intersection operation on the 
row/col indexes before iterating.  It works pretty well, and gives simpler 
code.

I'm also trying to boost performance of the transient cross-map, and I 
started a new thread about that if anyone has advice.

On Friday, 13 May 2016 12:47:21 UTC-7, James Reeves wrote:
>
> On 13 May 2016 at 19:50, Michael Willis 
> > wrote:
>>
>> Every time I go to the hammock (so to speak) to think over how to design 
>> such a system, I realize that I'm just re-inventing the database, so I come 
>> away feeling like somewhere, somehow there must already exist an in-memory 
>> database that will suit the problem, but I haven't determined what it is 
>> yet.
>>
>
> This was my reason for developing Ittyon 
> . It's essentially an in-memory 
> database with arbitrary indexing and network support for games. I couldn't 
> find any other database which met my specific criteria, but Ittyon has many 
> similarities with Datomic/Datascript in its design.
>
> - James 
>

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