date:20130105

Hi.

I have some performance issues with a type inference I wrote in core.logic. 
Here is the source code 
https://github.com/timowest/symbol/blob/master/src/symbol/types.clj

It works quite well, but is too slow. I tried to profile it with VisualVM, 
but as it has mostly anonymous functions, the results were difficult to 
analyze.

Based on a few changes I made I suspect that I need to optimize the 
environment (the mapping of expressions to types) handling somehow.

Are there good alternatives to cons/lcons based handling of mappings in 
core.logic? Also if you have any general core.logic performance improvement 
tips, I'd like to hear them.

I also noticed that with big environments, I easily get 
StackOverflowErrors, any ideas how to avoid them?

Best regards,
Timo

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

core.matrix proposal

2013-01-05 Thread Mikera

Hello all,

I've been experimenting with a common API / abstraction for matrix and 
vector maths in Clojure:

  https://github.com/mikera/matrix-api

The idea is:
 - Provide a clear, consistent API for matrix and vector operations
 - Support multiple different underlying implementations (e.g. native code 
via JBLAS vs pure Java like vectorz-clj)
 - Provide a base which other libraries that need to consume matrices can 
build upon (e.g. Incanter)
 - Offer good performance while still presenting a reasonably flexible high 
level API

I think this could be very useful for the Clojure community, especially 
given the interest in big data, simulations, machine learning, 3D graphics 
etc. If it goes well and there is enough interest, I guess that this could 
form the basis for a future core.matrix library.

Comments / ideas / patches welcome.

  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

core.matrix proposal

2013-01-05 Thread Konrad Hinsen

Mikera writes:

  I think this could be very useful for the Clojure community, especially 
  given the
  interest in big data, simulations, machine learning, 3D graphics etc. If it 
  goes well
  and there is enough interest, I guess that this could form the basis for a 
  future
  core.matrix library.
  
  Comments / ideas / patches welcome.

I haven't looked at your library yet, but my immediate comment is that
I'd much prefer to have an API for N-dimensional arrays rather than
just for matrices (2d) and vectors (1d).

Konrad.

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

Re: Are strings expensive for memory on the JVM?

2013-01-05 Thread Marko Topolnik

 (swap! recent-activity concat feed @recent-activity)

 This swap! replaces the value in recent-activity with (concat 
 @recent-activity feed @recent-activity), approximately

Adding to Stephen's point, *swap!* passes the current atom state into the 
function you gave it. So the correct way would be

(swap! recent-activity #(concat feed %))

However, you also seem to be mistaking *concat* for something it isn't: 
string concatenation. What really happens is your string gets converted 
into a *sequence of individual chars* --- and yes*, *that is *very* wasteful 
with memory: each sequence item occupies 64 bytes (on my setup: Java 7, 
Clojure 1.5).

String concatenation is achieved with the function *str*.

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

Re: ClojureCLR 1.5.0 RC 1

2013-01-05 Thread Konrad Hinsen

dmiller writes:

  That most likely is due to NUnit not being installed in lib/ properly.

Here's what I have in lib:

drwxr-xr-x  4 hinsen  staff  136 31 déc 14:54 DLR
-rw-r--r--@ 1 hinsen  staff  101 21 déc  2010 Ellipsis.gif
-rw-r--r--@ 1 hinsen  staff  1021952 18 oct 10:05 NSubstitute.dll
-rw-r--r--@ 1 hinsen  staff14927 18 oct 10:05 NSubstitute.xml
-rw-r--r--@ 1 hinsen  staff   315904 29 mar  2011 Rhino.Mocks.dll
-rw-r--r--@ 1 hinsen  staff   269056 29 mar  2011 Rhino.Mocks.xml
drwxr-xr-x  6 hinsen  staff  204  2 jan 09:49 Tree
-rw-r--r--@ 1 hinsen  staff   258048 21 déc  2010 log4net.dll
-rw-r--r--@ 1 hinsen  staff36864 22 oct 21:16 nunit-console-runner.dll
-rw-r--r--@ 1 hinsen  staff   155648 22 oct 21:16 nunit-gui-runner.dll
-rw-r--r--@ 1 hinsen  staff   151552 22 oct 21:16 nunit.core.dll
-rw-r--r--@ 1 hinsen  staff61440 22 oct 21:16 nunit.core.interfaces.dll
-rw-r--r--  1 hinsen  staff   147456  2 jan 09:49 nunit.framework.dll
-rw-r--r--@ 1 hinsen  staff90112 22 oct 21:16 nunit.uiexception.dll
-rw-r--r--@ 1 hinsen  staff   241664 22 oct 21:16 nunit.uikit.dll
-rw-r--r--@ 1 hinsen  staff   135168 22 oct 21:16 nunit.util.dll
-rw-r--r--@ 1 hinsen  staff  885 21 déc  2010 pinned.gif
-rw-r--r--@ 1 hinsen  staff  881 21 déc  2010 unpinned.gif

./DLR:
total 0
drwxr-xr-x  17 hinsen  staff  578  2 jan 09:47 2.0
drwxr-xr-x   9 hinsen  staff  306  2 jan 09:47 4.0

./DLR/2.0:
total 14488
-rw-r--r--@ 1 hinsen  staff 2916 17 oct  2010 License.html
-rw-r--r--@ 1 hinsen  staff   932864  1 oct  2010 Microsoft.Dynamic.dll
-rw-r--r--@ 1 hinsen  staff  2455040  1 oct  2010 Microsoft.Dynamic.pdb
-rw-r--r--@ 1 hinsen  staff   349573  1 oct  2010 Microsoft.Dynamic.xml
-rw-r--r--@ 1 hinsen  staff   383488  1 oct  2010 
Microsoft.Scripting.Core.dll
-rw-r--r--@ 1 hinsen  staff  1252864  1 oct  2010 
Microsoft.Scripting.Core.pdb
-rw-r--r--@ 1 hinsen  staff   826372  1 oct  2010 
Microsoft.Scripting.Core.xml
-rw-r--r--@ 1 hinsen  staff51712  1 oct  2010 
Microsoft.Scripting.Debugging.dll
-rw-r--r--@ 1 hinsen  staff   144896  1 oct  2010 
Microsoft.Scripting.Debugging.pdb
-rw-r--r--@ 1 hinsen  staff 8689  1 oct  2010 
Microsoft.Scripting.Debugging.xml
-rw-r--r--@ 1 hinsen  staff 5120  1 oct  2010 
Microsoft.Scripting.ExtensionAttribute.dll
-rw-r--r--@ 1 hinsen  staff 7680  1 oct  2010 
Microsoft.Scripting.ExtensionAttribute.pdb
-rw-r--r--@ 1 hinsen  staff   159744  1 oct  2010 Microsoft.Scripting.dll
-rw-r--r--@ 1 hinsen  staff   577024  1 oct  2010 Microsoft.Scripting.pdb
-rw-r--r--@ 1 hinsen  staff   235580  1 oct  2010 Microsoft.Scripting.xml

./DLR/4.0:
total 9040
-rw-r--r--@ 1 hinsen  staff 2916 17 oct  2010 License.html
-rw-r--r--@ 1 hinsen  staff   940032  1 oct  2010 Microsoft.Dynamic.dll
-rw-r--r--@ 1 hinsen  staff  2659840  1 oct  2010 Microsoft.Dynamic.pdb
-rw-r--r--@ 1 hinsen  staff51712  1 oct  2010 
Microsoft.Scripting.Debugging.dll
-rw-r--r--@ 1 hinsen  staff   163328  1 oct  2010 
Microsoft.Scripting.Debugging.pdb
-rw-r--r--@ 1 hinsen  staff   161280  1 oct  2010 Microsoft.Scripting.dll
-rw-r--r--@ 1 hinsen  staff   636416  1 oct  2010 Microsoft.Scripting.pdb

./Tree:
total 0
drwxr-xr-x  7 hinsen  staff  238  2 jan 09:49 Circles
drwxr-xr-x  7 hinsen  staff  238  2 jan 09:49 Classic
drwxr-xr-x  7 hinsen  staff  238  2 jan 09:49 Default
drwxr-xr-x  8 hinsen  staff  272  2 jan 09:49 Visual Studio

./Tree/Circles:
total 40
-rw-r--r--@ 1 hinsen  staff  761  1 jan  2012 Failure.jpg
-rw-r--r--@ 1 hinsen  staff  688 21 déc  2010 Ignored.jpg
-rw-r--r--@ 1 hinsen  staff  734  1 jan  2012 Inconclusive.jpg
-rw-r--r--@ 1 hinsen  staff  689 21 déc  2010 Skipped.jpg
-rw-r--r--@ 1 hinsen  staff  731 21 déc  2010 Success.jpg

./Tree/Classic:
total 40
-rw-r--r--@ 1 hinsen  staff  808 21 déc  2010 Failure.jpg
-rw-r--r--@ 1 hinsen  staff  789 21 déc  2010 Ignored.jpg
-rw-r--r--@ 1 hinsen  staff  784 21 déc  2010 Inconclusive.jpg
-rw-r--r--@ 1 hinsen  staff  689  1 jan  2012 Skipped.jpg
-rw-r--r--@ 1 hinsen  staff  768 21 déc  2010 Success.jpg

./Tree/Default:
total 40
-rw-r--r--@ 1 hinsen  staff  1445 21 déc  2010 Failure.png
-rw-r--r--@ 1 hinsen  staff   592  2 jan  2012 Ignored.png
-rw-r--r--@ 1 hinsen  staff  1436 21 déc  2010 Inconclusive.png
-rw-r--r--@ 1 hinsen  staff  1405 21 déc  2010 Skipped.png
-rw-r--r--@ 1 hinsen  staff  1439 21 déc  2010 Success.png

./Tree/Visual Studio:
total 48
-rw-r--r--@ 1 hinsen  staff   747  1 jan  2012 Failure.png
-rw-r--r--@ 1 hinsen  staff   773  1 jan  2012 Ignored.png
-rw-r--r--@ 1 hinsen  staff   782  2 jan  2012 Inconclusive.png
-rw-r--r--@ 1 hinsen  staff   687  1 jan  2012 SeriousWarning.png

Re: Are strings expensive for memory on the JVM?

About the String's expensiveness, working a lot with this kind of objects, 
it's big enough. In fact, that depends if you have a lot of small strings 
then the used memory space can become important.
For instance, the word Bazinga takes almost 60 bytes in memory (for a 
32bits JVM) in which 24 bytes are used by internal String object. That 
space is bigger in 64 bits JVM. You can have more information from Internet 
(like 
http://blog.nirav.name/2011/11/optimizing-string-memory-footprint-in.html).

Thus, when I need a lot of string chunks I often prefer use a characters 
array. It reduces the used memory footprint.



Le samedi 5 janvier 2013 00:06:48 UTC+1, larry google groups a écrit :


 I am still somewhat new to Clojure and the JVM. I am querying a database 
 and trying to output some XML. For the XML, I am using this library:

 https://github.com/clojure/data.xml

 Apparently the database queries worked, and I was able to get the data 
 into an XML structure, but at some point the data gets lost and nothing is 
 being output. I decided, for the sake of debugging, I would add in some 
 println statements and output it to the terminal. 

 I was storing the xml in an atom called recent-activity. I attempted to 
 store this as clojure.data.xml elements in a vector. I got no output so I 
 decided t switch to emit-str and store it as a string. Then suddenly I 
 got an OutOfMemory error. I found this very surprising. Are strings that 
 expensive on memory?

 The code looks like this. The first function does the query against the 
 database:

 (defn update-recent-discourse-from-this-site [db k]
   (jdbc/with-connection db
 (jdbc/with-query-results database-results
   [(str 
  SELECT
   d.id, d.description, d.created_at, 
   p.id as profile_id, p.first_name, p.last_name, 
   u.username 
  FROM discourse as d, sf_guard_user as u,  sf_guard_user_profile 
 as p 
  WHERE d.user_id=p.user_id 
  AND d.user_id=u.id 
  AND p.user_id=u.id 
  AND d.question_id = 0 
  AND d.answer_id = 0 
  AND d.discourse_id = 0 
  AND d.created_at  ? 
  ORDER BY d.created_at DESC 
  LIMIT 100 )
(das/one-month-ago-as-a-string-for-the-database)]
   (let [feed (transform-posts-into-a-feed database-results k 
 discourse)]
 (swap! recent-activity concat feed @recent-activity)

 and this function was suppose to put the content into an atom. At first I 
 did not use emit-str, but I added that on my last attempt to figure out 
 what is going on. 

 I was using conj, but then switched to concat when I switched to using 
 emit-str. 

 This is the function that formed the XML:

 (defn transform-posts-into-a-feed [database-results k 
 what-type-of-item-is-this]
   (let [site-url (make-site-url k)
 map-of-xml-elements (reduce 
  (fn [feed db-row]
(conj feed
  (xml/emit-str 
   (xml/element :item {}
(xml/element 
 :what-type-of-item-is-this {} (str what-type-of-item-is-this)) 
(xml/element :username 
 {} (str (make-user-nice-name db-row))) 
(xml/element 
 :user-profile-url {} (str (make-profile-url site-url (:profile_id 
 db-row 
(xml/element 
 :in-response-to-url {} (str (make-in-response-to-url site-url 
 what-type-of-item-is-this (:in_response_to_id db-row
(xml/element :site-url 
 {} (str  site-url))
(xml/element :title {} 
 (str  (:title db-row)))
(xml/element :item-url 
 {} (str (make-item-url site-url what-type-of-item-is-this (:id db-row 
(xml/element 
 :description {} (str (:description db-row)))
(xml/element :date {} 
 (str  (:created_at db-row)))

  [] database-results)]
 map-of-xml-elements))

 For awhile (before I used emit-str), at the end of this function, I had 
 this:

 (println (apply str   map-of-xml-elements))

 and I could see that the data in map-of-xml-elements was what I expected. 
 And yet the atom recent-activity seemed to remain empty, which I found 
 very confusing. 

 The function that basically drives this app (called from main) is the one 
 that throws an error:

 (defn iterate-through-sites-and-output-files []
   2012-11-10 - The TMA server might have 10 or 20 or more websites, each 
 with their own database config. We need to update every site.

Re: Are strings expensive for memory on the JVM?

2013-01-05 Thread Marko Topolnik


On Saturday, January 5, 2013 12:35:27 PM UTC+1, Christian Sperandio wrote:

 About the String's expensiveness, working a lot with this kind of objects, 
 it's big enough. In fact, that depends if you have a lot of small strings 
 then the used memory space can become important.
 For instance, the word Bazinga takes almost 60 bytes in memory (for a 
 32bits JVM) in which 24 bytes are used by internal String object. That 
 space is bigger in 64 bits JVM. You can have more information from Internet 
 (like 
 http://blog.nirav.name/2011/11/optimizing-string-memory-footprint-in.html
 ).

 Thus, when I need a lot of string chunks I often prefer use a characters 
 array. It reduces the used memory footprint.


It is good to know that, as of Java 7 Update 6, the String overhead has 
been reduced by two ints (should be 8 bytes): there is no more sharing of 
the *char[]* and, consequently, no more *offset* and *count* variables.

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

Re: Are strings expensive for memory on the JVM?


Fine :) It's a nice improvement.

Else, to have an idea about the memory management I found a good article 
again:

http://www.ibm.com/developerworks/java/library/j-codetoheap/index.html

It's interesting to understand the twists and turns of the JVM memory 
usage :)



On 01/05/2013 12:40 PM, Marko Topolnik wrote:


It is good to know that, as of Java 7 Update 6, the String overhead 
has been reduced by two ints (should be 8 bytes): there is no more 
sharing of the /char[]/ and, consequently, no more /offset/ and 
/count/ variables.

--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 


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

Re: Are strings expensive for memory on the JVM?

2013-01-05 Thread Aaron Cohen

On Sat, Jan 5, 2013 at 6:40 AM, Marko Topolnik marko.topol...@gmail.comwrote:

On Saturday, January 5, 2013 12:35:27 PM UTC+1, Christian Sperandio wrote:

About the String's expensiveness, working a lot with this kind of
objects, it's big enough. In fact, that depends if you have a lot of small
strings then the used memory space can become important.
For instance, the word Bazinga takes almost 60 bytes in memory (for a
32bits JVM) in which 24 bytes are used by internal String object. That
space is bigger in 64 bits JVM. You can have more information from Internet
(like http://blog.nirav.name/**2011/11/optimizing-string-**
memory-footprint-in.htmlhttp://blog.nirav.name/2011/11/optimizing-string-memory-footprint-in.html
).

Thus, when I need a lot of string chunks I often prefer use a characters
array. It reduces the used memory footprint.

It is good to know that, as of Java 7 Update 6, the String overhead has
been reduced by two ints (should be 8 bytes): there is no more sharing of
the *char[]* and, consequently, no more *offset* and *count* variables.

While it's true those fields aren't used any more, I was under the
impression at least one of those got replaced by the field used to cache
the new more-secure hashCode.

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

Clojure web server benchmarks

2013-01-05 Thread Peter Taoussanis

Hi all,

Quick post to mention that I've put up some rough benchmarks for a number 
of Clojure web 
servers: https://github.com/ptaoussanis/clojure-web-server-benchmarks.

Getting semi-reliable numbers was a real PITA, and I'm sure there's still 
plenty of room left for improvement (suggestions welcome!). Usual 
disclaimers apply: the numbers vary by hardware, by OS, by concurrency, and 
by the response size (among other things). The servers also vary 
considerably in their feature sets. Not to mention that your web server is 
seldom going to be the bottleneck when generating dynamic content. Tl;dr: 
this is all very difficult to generalize: you'll need to bench in your own 
environment with your own workloads to get an accurate picture.

Anyway I think the numbers are interesting (and pretty impressive 
all-round). Nginx can almost certainly be tweaked faster (ideas?), but I 
wouldn't have expected something like the standard Ring Jetty adapter even 
to be playing in the same ballpark - so that's nice.

I'll try keep this updated as servers are updated. And as I've mentioned on 
the GitHub page, pull-requests welcome for anything I may have missed, 
including other servers or mis-configurations, etc. Hopefully with some 
tweaking we can converge on some reasonably accurate/useful common-case 
numbers.

Cheers!

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

Issues with record and atom

Hi,

I want to define a record that represents a tree items. The idea is each 
item is a component that can have parent and children. The parent and the 
children are components too,

So, I define this record by:
(defrecord Component [name children parent])

After, I declare 2 components:
(def parent (Component. Parent (atom {}) (atom nil)))
(def child (Component. Child (atom {}) (atom nil)))

To link the parent with the child, I do:
(swap! (:children parent) assoc :a child)
(reset! (:parent child) parent)

And bang, the second call raises an exception: StackOverflowError   
java.util.regex.Pattern$BmpCharProperty.match (Pattern.java:3715)

If I reverse the code:
(reset! (:parent child) parent)
(swap! (:children parent) assoc :a child)

The reset! call passes fine but the swap! one fails with the same exception.

Where does this issue come from?

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

suggestions to improve my little queue-helper-functions?

2013-01-05 Thread Jim - FooBar();


Hi everyone,

Since i was reading about queues these days i decided to write a couple 
of functions that would include the basic queue functionality that I 
might need when working with queues in Clojure. They are pretty basic 
and I've not thoroughly tested them but they seem to behave well...I'm 
just posting them here so people can provide feedback in case they'd do 
something different...you can be as picky as you like :-) ...


(defn queue
A (FIFO) queue constructor function. Append (at the rear) with 'conj' 
and grab (at the front) with 'peek' (without removal).
 This feels more natural to use inside an atom where 'popping' can 
return the first element AND also remove it from the queue.

([] clojure.lang.PersistentQueue/EMPTY)
([x] (conj (queue) x))
([x  xs] (into (queue x) xs)) )

(defn push!
Pushes the x  xs at the rear of the queue q (managed by an atom). 
Returns the 'mutated' queue. Thread-safe operation.

([q x] (swap! q conj x))
([q x  xs]
  (swap! q #(into (conj % x) xs

(defn peek+pop!
Removes the 1st item from the queue q (managed by an atom) and returns 
it. Thread-safe operation.

[q]
(loop []
(let [[head  r :as l]  @q]
  (if (compare-and-set! q l (pop l)) head
(recur)
--

any feedback is welcome and appreciated...One thing I don't have so far 
is the ability to create queues from other data-structures (just like 
'vec') but I can see that there exists a constructor that has that 
facility so that should be easy to do...


thanks in advance :-)

Jim

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

Re: Are strings expensive for memory on the JVM?

2013-01-05 Thread Marko Topolnik



 While it's true those fields aren't used any more, I was under the 
 impression at least one of those got replaced by the field used to cache 
 the new more-secure hashCode.

 
No, there is no trace of anything having changed with the *hashCode*. 
Here's the source code: 
java.lang.Stringhttp://hg.openjdk.java.net/jdk7u/jdk7u6/jdk/file/8c2c5d63a17e/src/share/classes/java/lang/String.java.
 
It's good to keep that link around for future reference because it is 
notoriously difficult to reach.


 

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

Re: [core.logic] Performance issues

On Sat, Jan 5, 2013 at 4:38 AM, Timo Westkämper
timo.westkam...@mysema.comwrote:

 Hi.

 I have some performance issues with a type inference I wrote in
 core.logic. Here is the source code
 https://github.com/timowest/symbol/blob/master/src/symbol/types.clj


That's a neat bit of core.logic you have there :)

It works quite well, but is too slow. I tried to profile it with VisualVM,
 but as it has mostly anonymous functions, the results were difficult to
 analyze.

 Based on a few changes I made I suspect that I need to optimize the
 environment (the mapping of expressions to types) handling somehow.



Are there good alternatives to cons/lcons based handling of mappings in
 core.logic? Also if you have any general core.logic performance improvement
 tips, I'd like to hear them.


Yes encoding an environment as a list is not optimal. It may be possible to
do this properly with persistent maps via constraints. I've been a bit too
busy w/ fixing up bugs for a proper core.logic 0.8.0 release to pursue this
avenue myself. But it would look something like this:

(assoc m k0 v0 newm)
(getc newm k0 v1)

Hopefully that makes some sense.  One thought that just jumped into mind -
have you considered making your own lookupo that using tabling so you can
cache the results of the type environment lookup?


 I also noticed that with big environments, I easily get
 StackOverflowErrors, any ideas how to avoid them?


A gist that includes an example plus the stacktrace would be very
informative. This might be a simple one to fix.


 Best regards,
 Timo


This is one of the more ambitious core.logic programs I've seen. Some
examples that I could try myself would be helpful to understand the issues.

David

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

Re: Issues with record and atom

I tried by using map instead of record and I've got the same issue.

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

Re: Issues with record and atom

2013-01-05 Thread Stephen Compall

On Sat, 2013-01-05 at 08:07 -0800, Christian Sperandio wrote:
 (reset! (:parent child) parent)

I'll decompose this so you can see where the overflow actually happens:

user (def reset-result (reset! (:parent child) parent))
#'user/reset-result
user reset-result
StackOverflowError   java.util.regex.Pattern$Curly.match0 (Pattern.java:3777)

You can't print your result (the parent) because it's a circle.
Printing things with circles safely takes more code than you've written.

But rather than bothering with that, I *strongly* recommend looking into
the services of the `clojure.zip' module, included with the standard
distribution, to avoid mutable constructs and still be able to walk up
and down your tree.

-- 
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better

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

Re: [core.logic] Performance issues



On Saturday, January 5, 2013 7:19:07 PM UTC+2, David Nolen wrote:

 On Sat, Jan 5, 2013 at 4:38 AM, Timo Westkämper 
 timo.we...@mysema.comjavascript:
  wrote:

 Hi.

 I have some performance issues with a type inference I wrote in 
 core.logic. Here is the source code 
 https://github.com/timowest/symbol/blob/master/src/symbol/types.clj


 That's a neat bit of core.logic you have there :) 

 It works quite well, but is too slow. I tried to profile it with VisualVM, 
 but as it has mostly anonymous functions, the results were difficult to 
 analyze.

 Based on a few changes I made I suspect that I need to optimize the 
 environment (the mapping of expressions to types) handling somehow. 

  

 Are there good alternatives to cons/lcons based handling of mappings in 
 core.logic? Also if you have any general core.logic performance improvement 
 tips, I'd like to hear them.


 Yes encoding an environment as a list is not optimal. It may be possible 
 to do this properly with persistent maps via constraints. I've been a bit 
 too busy w/ fixing up bugs for a proper core.logic 0.8.0 release to pursue 
 this avenue myself. But it would look something like this:

 (assoc m k0 v0 newm)
 (getc newm k0 v1)


Are there or will there be goals to do this in core.logic? Having direct 
support for maps would be great.
 


 Hopefully that makes some sense.  One thought that just jumped into mind - 
 have you considered making your own lookupo that using tabling so you can 
 cache the results of the type environment lookup?


Ok, I could try that.
 

  

 I also noticed that with big environments, I easily get 
 StackOverflowErrors, any ideas how to avoid them?


 A gist that includes an example plus the stacktrace would be very 
 informative. This might be a simple one to fix.


Here is one example

(def l (range 0 2000))
(run* [q] (appendo l l q))

StackOverflowError 
clojure.lang.PersistentHashMap$ArrayNode.find 
(PersistentHashMap.java:370)
clojure.lang.PersistentHashMap$ArrayNode.find 
(PersistentHashMap.java:370)
 

  

 Best regards,
 Timo


 This is one of the more ambitious core.logic programs I've seen. Some 
 examples that I could try myself would be helpful to understand the issues.


Ok, I will try if I can extract one of those SO errors.

I also noticed that I could get significant performance gains when encoding 
certain goal usage patterns more directly like this

(defna argso
  [bindings args]
  ([[?k ?v] [?k]])
  ([[?k1 ?v1 ?k2 ?v2] [?k1 ?k2]])
  ([[?k1 ?v1 ?k2 ?v2 ?k3 ?v3] [?k1 ?k2 ?k3]])
  ([[?k ?v . ?rest] [?k . ?resta]]
(argso ?rest ?resta))
  ([[] []]))   

I suspect this means that the recursion in goals is not yet as performant 
as it could/should be?

Br,
Timo
 


 David


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

Re: [core.logic] Performance issues

On Sat, Jan 5, 2013 at 1:49 PM, Timo Westkämper
timo.westkam...@mysema.comwrote:


 Are there or will there be goals to do this in core.logic? Having direct
 support for maps would be great.


It's something I've been thinking about for a long time. So it's likely it
will appear at some point, I'm just not sure when. If somebody would be
willing to investigate it's feasibility that would be extremely helpful.


  Here is one example

 (def l (range 0 2000))
 (run* [q] (appendo l l q))


One my machine this works without a hitch. What version of core.logic are
you using?


 Ok, I will try if I can extract one of those SO errors.

 I also noticed that I could get significant performance gains when
 encoding certain goal usage patterns more directly like this

 (defna argso
   [bindings args]
   ([[?k ?v] [?k]])
   ([[?k1 ?v1 ?k2 ?v2] [?k1 ?k2]])
   ([[?k1 ?v1 ?k2 ?v2 ?k3 ?v3] [?k1 ?k2 ?k3]])
   ([[?k ?v . ?rest] [?k . ?resta]]
 (argso ?rest ?resta))
   ([[] []]))

 I suspect this means that the recursion in goals is not yet as performant
 as it could/should be?


How were you writing this goal before?

But yes, unification is eager and implemented as efficiently as I know how.
Recursive goals involve scheduling and extra unifications so things might
not happen as quickly as you like.

I do have many possible core.logic optimizations in mind but these will
need to wait. I think 0.8.0 will involve a considerable amount of shakeout
of the new constraint work. If that gets settled I could see 0.9.0 focusing
on performance optimizations.

Again, definitely interested in contributions in this area.

David

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

Re: [core.logic] Performance issues



On Saturday, January 5, 2013 9:28:21 PM UTC+2, David Nolen wrote:

 On Sat, Jan 5, 2013 at 1:49 PM, Timo Westkämper 
 timo.we...@mysema.comjavascript:
  wrote:


 Are there or will there be goals to do this in core.logic? Having direct 
 support for maps would be great.


 It's something I've been thinking about for a long time. So it's likely it 
 will appear at some point, I'm just not sure when. If somebody would be 
 willing to investigate it's feasibility that would be extremely helpful.

 

  

  Here is one example

 (def l (range 0 2000))
 (run* [q] (appendo l l q))


 One my machine this works without a hitch. What version of core.logic are 
 you using?


[org.clojure/core.logic 0.8.0-beta4]

 

 Ok, I will try if I can extract one of those SO errors.

 I also noticed that I could get significant performance gains when 
 encoding certain goal usage patterns more directly like this

 (defna argso
   [bindings args]
   ([[?k ?v] [?k]])
   ([[?k1 ?v1 ?k2 ?v2] [?k1 ?k2]])
   ([[?k1 ?v1 ?k2 ?v2 ?k3 ?v3] [?k1 ?k2 ?k3]])
   ([[?k ?v . ?rest] [?k . ?resta]]
 (argso ?rest ?resta))
   ([[] []]))   

 I suspect this means that the recursion in goals is not yet as performant 
 as it could/should be?


 How were you writing this goal before?


Before it was just the general part

(defna argso
  [bindings args]
  ([[?k ?v . ?rest] [?k . ?resta]]
(argso ?rest ?resta))
  ([[] []]))  


 But yes, unification is eager and implemented as efficiently as I know 
 how. Recursive goals involve scheduling and extra unifications so things 
 might not happen as quickly as you like.

 I do have many possible core.logic optimizations in mind but these will 
 need to wait. I think 0.8.0 will involve a considerable amount of shakeout 
 of the new constraint work. If that gets settled I could see 0.9.0 focusing 
 on performance optimizations.


Ok, good.
 


 Again, definitely interested in contributions in this area.


I am not yet strong enough with core.logic for contributions, but I will 
post more stuff as this project advances. 

Thanks for your advice.

Br,
Timo
 


 David 


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

Re: Clojure Conj Videos

2013-01-05 Thread dspiteself

I just noticed someone was posting many clojure videos on youtube. 
http://www.youtube.com/user/ClojureTVhttp://www.youtube.com/user/ClojureTV?feature=g-hist
They have playlists for conj 2010 and rich hickey talks 10 of them. They 
have a lot of videos, but it would be great to make it as near to 
comprehensive as possible and add reference to slides and referenced 
libraries.

I have been enjoying clicking watch later and enjoying them on my phone 
even when there is no internet. 


On Friday, January 4, 2013 12:52:54 PM UTC-6, Simone Mosciatti wrote:

 It could be a good idea to post the video and the slides also in some 
 different platform (YouTube/Vimeo for the video and something else for the 
 slides google doc, dropbox) just to avoid what happened with blip.tv...

 It may be a even better idea to get all the video material and put all 
 together somewhere, maybe in the main site of clojure...

 We start to have a lot of videos and organize them it start to be a good 
 idea.

 On Friday, January 4, 2013 4:45:06 AM UTC+1, Alex Miller wrote:

 The full Strange Loop video schedule is here: 
 https://thestrangeloop.com/news/strange-loop-2012-video-schedule

 Re Clojure talks, 

 Already released related in some way to Clojure and ClojureScript:
 - Nathan Marz on big data - 
 http://www.infoq.com/presentations/Complexity-Big-Data
 - Jim Weirich on Y Combinator - 
 http://www.infoq.com/presentations/Y-Combinator
 - Chris Granger on Light Table - 
 http://www.infoq.com/presentations/Learn-Tools
 - David Nolen on ClojureScript - 
 http://www.infoq.com/presentations/ClojureScript-Optimizations
 - Amit Rathore on Clojure+Datomic+Storm - 
 http://www.infoq.com/presentations/Zolodeck
 - Bodil Stokke on Catnip IDE and ClojureScript - 
 http://www.infoq.com/presentations/Catnip

 Still to be released:
 - Jason Wolfe's talk on the Prismatic Graph library is coming out week of 
 Jan 28th
 - Kevin Lynagh's talk on his ClojureScript visualization lib is week of 
 Feb 11th
 - Rich Hickey's talk is scheduled for week of Mar 18th but same one has 
 already been released on InfoQ so not sure if they'll re-release it
 - Stuart Sierra's talk on functional design patterns is week of Apr 1st

 Sorry if I missed any.

 Alex

 On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:

 I've been waiting forever for the recent Strange Loop Clojure talks to 
 be made available as well. So far I've only seen two, Amit Rathore's 
 Clojure + Datomic + Stomr = Zolodeck and David Nolen's ClojureScript - 
 Better semantics at low, low prices on InfoQ. Any one have any idea when 
 the others will be made available? 

 On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:

 Let the party begin :-)

 On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:

 Confreaks is just completing the final edits on the videos and we 
 should be releasing them soon (in a week or so?). 
 Of course, it will probably be a staggered release just to drive 
 everyone crazy ;) 

 Lynn Grogan
 Relevance

 On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:

 On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt ma...@talios.com 
 wrote: 
  
  +1 - I'm sure I've even seen any BLOGS on this years Conj let alone 
 videos. 

 http://corfield.org/blog/post.cfm/clojure-conj-2012 
 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 

 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

Re: [core.logic] Performance issues

On Sat, Jan 5, 2013 at 2:44 PM, Timo Westkämper
timo.westkam...@mysema.comwrote:

  Here is one example

 (def l (range 0 2000))
 (run* [q] (appendo l l q))


 One my machine this works without a hitch. What version of core.logic are
 you using?


 [org.clojure/core.logic 0.8.0-beta4]


I cannot reproduce this on master even if I use a larger like N=1. If I
pick a very large N it takes a very long time - but no stack overflow. Can
you test this one against master and give more specific details about your
setup? Thanks.

David

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

Re: [ANN] Tower, simple i18n library for Clojure

2013-01-05 Thread Peter Taoussanis

 

 I will update and give the code a try.  Thanks for the fast turnaround!


No problem.
 

 As far as your first and last questions, they both sort of came from the 
 same scenario I was pondering.  I was thinking about an application made 
 with many small dependencies and maybe several of them all were using tower 
 to handle translations and such.  But they don't about each other and, 
 therefor, expect to work the same regardless of whether or not there are 
 other libraries that also use tower.  Each library might want a different 
 default locale, or different mode (:dev/other), etc.  I was just thinking 
 about what happens in that case since there is but one config state in 
 the tower namespace.  Again, this isn't an issue for me I was just 
 pondering the scenario.


Hmm, let me think about this a little more. There's a number of options, 
the simplest of which is probably just to offer a dynamic binding for the 
config atom. That way each library can bind over the atom and get its own 
config.

Regarding the separate dictionary thing, I was still talking about the 
 centralized dictionary where the arbitrary keys allow easy separation of 
 the dictionary parts.  I was heading down the path where multiple sections 
 of the dictionary were created by different libraries merging in different 
 dictionaries from different resources in their own code bases (using 
 something like load-dictionary-from-map-resource!).  If one of those 
 resources changes (in dev mode) then I think we might want to just re-merge 
 that resource's contents into the dictionary, replacing just the parts 
 merged from that resource while leaving the rest of the dictionary 
 unscathed.  I was wondering if a merging version of 
 load-dictionary-from-map-resource might be useful for that situation.


I'm sort of half-following what you mean here... I think between the 1.2.0 
update and the dynamically-bindable config, you'll probably have what you 
need. Could I ask you to create an issue for this on the GitHub page, then 
I can come back to you when I've got something implemented?

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

Google+ community

2013-01-05 Thread dspiteself

I started a google plus 
communityhttps://plus.google.com/u/0/communities/102842407348588249223. 
 
I know most of the Clojure community is generally more into twitter, but I 
have been enjoying Google+ communities very much. It could be a great more 
externally visible venue for some of the conversation that happen on google 
groups. 
It also has the effect off make your search results of people and people in 
your circles and communities show up higher. 

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

Re: Google+ community

2013-01-05 Thread Denis Labaye

I just joined

On Sat, Jan 5, 2013 at 9:15 PM, dspiteself dspites...@gmail.com wrote:

 I started a google plus 
 communityhttps://plus.google.com/u/0/communities/102842407348588249223.

 I know most of the Clojure community is generally more into twitter, but I
 have been enjoying Google+ communities very much. It could be a great more
 externally visible venue for some of the conversation that happen on google
 groups.
 It also has the effect off make your search results of people and people
 in your circles and communities show up higher.

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

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

Re: [core.logic] Performance issues



On Saturday, January 5, 2013 10:02:01 PM UTC+2, David Nolen wrote:

 On Sat, Jan 5, 2013 at 2:44 PM, Timo Westkämper 
 timo.we...@mysema.comjavascript:
  wrote:

  Here is one example

 (def l (range 0 2000))
 (run* [q] (appendo l l q))


 One my machine this works without a hitch. What version of core.logic 
 are you using?


 [org.clojure/core.logic 0.8.0-beta4]


 I cannot reproduce this on master even if I use a larger like N=1. If 
 I pick a very large N it takes a very long time - but no stack overflow. 
 Can you test this one against master and give more specific details about 
 your setup? Thanks.


This should be with master in lein

user= (def l (range 0 2000))
#'user/l
user= (run* [q] (appendo l l q))
StackOverflowError   clojure.core.logic.LVar (logic.clj:1307)
user= (pst)
StackOverflowError 
clojure.core.logic.LVar (logic.clj:1307)
clojure.lang.KeywordLookupSite$1.get (KeywordLookupSite.java:45)
clojure.core.logic.LVar (logic.clj:1325)
clojure.lang.Util.equiv (Util.java:32)
clojure.lang.PersistentHashMap$BitmapIndexedNode.find 
(PersistentHashMap.java:601)
clojure.lang.PersistentHashMap$ArrayNode.find 
(PersistentHashMap.java:370)
clojure.lang.PersistentHashMap$ArrayNode.find 
(PersistentHashMap.java:370)
clojure.lang.PersistentHashMap.entryAt (PersistentHashMap.java:133)
clojure.lang.RT.find (RT.java:720)
clojure.core/find (core.clj:1432)
clojure.core.logic.Substitutions (logic.clj:1134)
clojure.core.logic/walk*/fn--2847 (logic.clj:1005)


user= *clojure-version*
{:major 1, :minor 4, :incremental 0, :qualifier nil}

java version 1.6.0_26
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)

Default JVM options. It works with larger stack size, but it would be nice, 
if this could work default settings.

Br,
Timo

 


 David 


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

Re: [core.logic] Performance issues

Thanks for the report, will look into it -
http://dev.clojure.org/jira/browse/LOGIC-99

On Sat, Jan 5, 2013 at 3:39 PM, Timo Westkämper
timo.westkam...@mysema.comwrote:

 user= (def l (range 0 2000))
 #'user/l
 user= (run* [q] (appendo l l q))
 StackOverflowError   clojure.core.logic.LVar (logic.clj:1307)
 user= (pst)
 StackOverflowError
 clojure.core.logic.LVar (logic.clj:1307)
 clojure.lang.KeywordLookupSite$1.get (KeywordLookupSite.java:45)
 clojure.core.logic.LVar (logic.clj:1325)
 clojure.lang.Util.equiv (Util.java:32)
 clojure.lang.PersistentHashMap$BitmapIndexedNode.find
 (PersistentHashMap.java:601)

 clojure.lang.PersistentHashMap$ArrayNode.find
 (PersistentHashMap.java:370)
 clojure.lang.PersistentHashMap$ArrayNode.find
 (PersistentHashMap.java:370)
 clojure.lang.PersistentHashMap.entryAt (PersistentHashMap.java:133)
 clojure.lang.RT.find (RT.java:720)
 clojure.core/find (core.clj:1432)
 clojure.core.logic.Substitutions (logic.clj:1134)
 clojure.core.logic/walk*/fn--2847 (logic.clj:1005)


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

Re: MultiMethod Interoperability with Java

2013-01-05 Thread Sean Corfield

My first thought it that this is because (class nil) = nil so even
tho' the 'correct' Java signature is matched and called, the
multi-method dispatch is still invoked under the hood.

So (String) null selects the [String] String signature, (class
valueHolder) = nil so the :default implementation is called, but I
would expect (nil? valueHolder) to be true and to have it return c.

Similarly, (Object) null selects [Object] String, but again calls the
:default implementation... although I would expect c back.

And (Integer) null selects [Integer] Integer, calls the :default
implementation and fails when it tries to return c (or more likely
d given the previous two results).

I'd add println calls to each implementation and see what valueHolder
seems to be in each case...

Sean

On Sat, Jan 5, 2013 at 12:49 AM, rjf89 robert@gmail.com wrote:
 I'm kind of new to Clojure at the moment, and have been playing around
 re-writing some utility libraries from work in Clojure for import into other
 pieces of our infrastructure. I'm having a blast using it, but I've gotten a
 bit stuck on trying to implement something with Multimethods. I have a
 multimethod dispatching based upon class – for example:

 (ns interop.core
   (:gen-class
:methods [[doSomething [String] String]
  [doSomething [Integer] Integer]
  [doSomething [Object] String]]))
 (defmulti -doSomething (fn [this valueHolder  default] (class
 valueHolder)))
 (defmethod -doSomething String [this valueHolder]
   (if (nil? valueHolder) a b))
 (defmethod -doSomething Integer [this valueHolder]
   (if (nil? valueHolder) (Integer. 1) (Integer. 2)))
 (defmethod -doSomething :default [this valueHolder]
   (if (nil? valueHolder) c d))


 If I compile and export this, and attempt to use it in a Java project, it
 works fine for most use cases:

 core c = new core();
 System.out.println(c.doSomething(new Integer(1))); // 2 -- Correct
 System.out.println(c.doSomething()); // 'b' -- Correct
 System.out.println(c.doSomething(new Object())); // 'd' -- Correct
 // System.out.println(c.doSomething(null)); // The method
 doSomething(String) is ambiguous
 System.out.println(c.doSomething((String) null)); // 'd' -- Wrong
 System.out.println(c.doSomething((Object) null)); // 'd' -- Correct
 System.out.println(c.doSomething((Integer) null)); // ClassCastExc: String
 cannot be cast to Integer


 The oddity is the last line. It looks like it's: Calling the Object =
 String implementation (marked default), but its trying to cast the result
 after the fact to an Integer (to match the Integer = Integer
 implementation). If I had to make a guess, I'd say the return type is being
 correctly matched, but the input parameter is causing the :default
 implementation to always be called. Anyone have any suggestions or ideas on
 either what I'm doing wrong, or even just whats happening behind the scenes?
 Any ideas on how to fix whats probably an egregious mistake on my behalf?

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



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

Re: [core.logic] Performance issues