Re: [ANN] Counterclockwise 0.26.0

2014-07-13 Thread casper
Nice. Keep up the awesome work :)

On Thursday, July 10, 2014 10:53:59 PM UTC+2, laurent.petit wrote:
>
> Hello, 
>
> Counterclockwise 0.26.0 has just been released.
>
> This version fixes lots of longstanding, unnerving usability issues.
>
> Please see the Changelog for detailed explanations: 
>
> Release Note
> ===
>
>
> http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_25_2_and_0_26_0
>
> Install
> ===
>
> Installation instructions:
>
> http://doc.ccw-ide.org/documentation.html#_install_counterclockwise
>
> Cheers,
>
> -- 
> Laurent Petit
>

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


Recursive definition in core.logic

2014-09-21 Thread Casper
I have been looking through core.logic tutorials and while I "get it" I 
haven't had the big epiphany yet. One thing that keeps nagging me is how to 
make a relation that isn't "fixed".

An example is https://github.com/swannodette/logic-tutorial in which there 
is defined some relations such as parent, child, son, daughter and 
granddaughter. As I see it these are all a fixed relationships in that they 
are a fixed distance from each other.

For me that leads to the question, how do we then define the relationship 
'descendant' (which would be the generalisation of child, grandchild etc)? 

Seems to me that this would involve a recursive definition, but I don't 
know how to make one like that. Any hints?

This is the relevant code from the excellent tutorial made by swannodette, 
that I linked above:

(ns logic-tutorial.tut1
  (:refer-clojure :exclude [==])
  (:use [clojure.core.logic])
  (:use [clojure.core.logic.pldb]))

(def rels
 (db
   [male 'Bob]
   [female 'Cindy]
   [parent 'John 'Cindy]
   [parent 'Jane 'Cindy]
   [parent 'John 'Bob]
   [parent 'Jane 'Bob]))

(defn child [x y]
  (parent y x))

(defn son [x y]
  (all
   (child x y)
   (male x)))

(defn daughter [x y]
  (all
   (child x y)
   (female x)))

(defn grandparent [x y]
  (fresh [z]
(parent x z)
(parent z y)))

(defn granddaughter [x y]
  (fresh [z]
(daughter x z)
(child z y)))

;; Running it

(with-db rels
(run* [q]
  (child 'Bob q)))

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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] Release 0.35.0 of Counterclockwise

2016-09-09 Thread casper
Great! I was actually fearing that CCW had been abandoned, so good to see 
you are still around (even though I am a few months late). 

And just because there is not a lot of activity in here: I still use CCW 
more or less full time, and I appreciate the work update. 

On Saturday, July 9, 2016 at 11:09:42 PM UTC+2, laurent.petit wrote:
>
> Counterclockwise, the Eclipse Clojure development tool.
>
> Counterclockwise 0.35.0 has been released.
>
> Highlights:
>
> - Eclipse Neon Support
>
> This is the first version which requires Java 8
>
> ChangeLog
> =
>
>
> http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_34_0_and_0_35_0
>
> Installation instructions
> ==
>
> http://doc.ccw-ide.org/documentation.html#_install_counterclockwise
>
> Cheers,
>
> -- 
> Laurent Petit
>

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


Transit problems with msgpack

2015-11-24 Thread Casper
 

So I have some code that is acting up when using msgpack. I have made a 
minimal example below, that shows the problem. The code returns -17 (long) 
when using :msgpack, but decodes correctly when using :json.


My impression was that :msgpack was base64 encoded and could be represented 
as a string (and logged and so on). Is that not the case, or is something 
else messing me up when I slurp the ByteArrayInputStream?


Code:


(require '[cognitect.transit :as transit])

(import [java.io ByteArrayInputStream ByteArrayOutputStream])


;; Write data to a stream

(def out (ByteArrayOutputStream.))

(transit/write (transit/writer out :msgpack) {:a [1 2]})


;; Read data from a stream -> string via slurp -> back to InputStream

(def string (slurp (ByteArrayInputStream. (.toByteArray out

(prn "Encoded string" string)

(def in (ByteArrayInputStream. 

  (.getBytes string "UTF-8")))

(def reader (transit/reader in :msgpack))

(transit/read reader)


Any idea what is going on? 


/Casper


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


Propagating data through dependencies

2014-05-15 Thread Casper
This is not strictly a Clojure question, but I'll ask it here since I am 
solving it in Clojure. I have already made one solution which works, but I 
am interested in whether there are other and better approaches.

I have a number of different products and some are dependant on others:

A <- B 
B <- C 
D

(B is depending on A, C is depending on B, D has no dependencies)

There might also be a required service or product for the above, lets 
denote them by lower case letters, which should be available at the same 
time or before the main product, and it cannot be billed after. It could be 
a modem for an internet connection.

Finally there might be a fee, lets call them fX e.g. fA if it is a fee for 
A. These should be billed at the same time as the main product but can be 
billed after.

So when you bill the customer you want to make sure that the product and 
the products it depends on are usable, delivered, provisioned (or whatever 
the case). For this we calculate a date from which we bill the customer for 
each of the products based on the date he requested the product.

So the customer might have placed the following order:

Product | Req. date | Bill date (calculated)

A   | 3 | 3
fA  | 3 | 3
B   | 2 | 4
b   | 4 | 4
C   | 1 | 4
fC  | 1 | 4
D   | 1 | 1

B and C are bumped to time 3, because they depend on A (B directly, C 
indirectly) while D stays at 1 because it has no dependencies. However 
because b was only available at 4 (maybe due being out of stock), B and 
therefore C and fC are bumped to 4

What we are currently doing is looking at this as a tree of dependencies 
and transfer the dates from the dependencies to the product if the date is 
bigger (done per product in topological order to get the right 
propagation). The problem here are the required services that need to be 
able to bump the date of the main product but also not be billed after, 
this is modeled as B -> b and then having a post action to bump b up to B 
if it was before (but this feels like a hack). There cannot be a dependency 
in both directions as the topological order then cannot be found due to a 
circular dependency.

(I hope this is making sense, I am finding it a bit hard to explain)

So my question is, what other approaches are there? 

The ones that come to mind are:
 - core.logic, however I can't figure out how to get propagation through 
multiple dependencies.
 - rule engine of some sort, like clara-rules, but again can't get the 
propagation going.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Propagating data through dependencies

2014-05-15 Thread Casper
On Thursday, May 15, 2014 11:18:31 PM UTC+2, David Pidcock wrote:

> You said b can't be billed after B. But it sounds like it can't be billed 
> before. 
>
> Say b is ready at 1,  can you bill it at 1 and then B at 2?
>
They should actually be billed at the same time (yeah, I didn't explain 
that very well). 

The problem is that the way I am currently solving it, by propagating dates 
from dependencies, can only have a dependency in one direction. So if b is 
2 and B is 1 I want B to be bumped to 2, but if b is 1 and B is 2 i want b 
to be bumped to 2 - the current solution can only support one of the two 
though, so I do the first in the main propagation and after that have a 
post action to bump all required services (lower case) to the date of their 
main product (upper case). 

This is actually what makes me want to look for another solution. Not so 
much because I want to replace the current implementation, (it works fine), 
but because I feel like there is something to be learned here for me.









 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Propagating data through dependencies

2014-05-15 Thread Casper
Yeah maybe, but both b and B should basically be billed at max of their 
associated dates, which might affect the things that depend on B. So I 
don't think b can be dropped completely.

On Thursday, May 15, 2014 11:30:35 PM UTC+2, David Pidcock wrote:
>
> If, say C cannot depend on any b directly, (I.e. C can only depend on B), 
> and your domain rules say you can only bill for all b's when you bill B, 
> then really you have a self contained sub-graph with only one bill date for 
> the root node B.
> You can simply ignore backfilling the billing date for b's and just bundle 
> them into the bill for B when you generate 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: Propagating data through dependencies

2014-05-15 Thread Casper
Nice thanks, I didn't know propaganda. I am not sure if it applies to this 
problem, but it looks interesting so I'll have a look.

On Friday, May 16, 2014 12:10:29 AM UTC+2, François Rey wrote:
>
>  I'm not sure I totally understand your use case, but somehow it sounds 
> like these libraries may be of interest to you:
> propaganda 
> prismatic 
> graph
>
> 

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


Type hints and records

2011-10-10 Thread casper
I am using a record to wrap a number of java classes, which I then
access various properties on. I am trying to avoid reflection so I
type have type hinted, however when accessing the values in the record
the type hints are lost. It might look something like this

(defrecord Rec [^Integer i])

(defn to-string [^Rec record] (.toString (:i record)))

However the to-string function gives a reflection warning, even with
the input the to function type hinted. Now I know that type hints
don't survive across function boundaries, but is there no way to get a
type hinted value from the record?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Idiomatic way to write dependency resolving algorithms?

2013-06-09 Thread Casper Clausen
Here is a similar algorithm I did for work a while back:

(defn- find-next-node [deps used-nodes]
  (some (fn [[k v]] (if (empty? (remove used-nodes v)) k)) deps))

(defn topsort
  "Takes a map of dependencies between items and performs a topological 
sort.
   E.g. (topsort  {1 [2 3] 3 [] 2 [3]}) => [3 2 1]"
  [deps]
  (loop [deps deps res []]
(if (empty? deps)
  res
  (if-let [item (find-next-node deps (set res))]
(recur (dissoc deps item) (conj res item))
(throw (Exception. (str "A circular dependency was found: " 
deps)))

I am not sure if it is optimal, but it does it without the atom which is a 
bit nicer i think. I'm also open to input for a better way of course.



On Friday, May 31, 2013 6:33:59 PM UTC+2, Alice wrote:
>
> (def graph 
>   {"a" {:dependencies ["b" "d"]} 
>"b" {:dependencies ["c" "e"]} 
>"c" {:dependencies ["d" "e"]} 
>"d" {:dependencies []} 
>"e" {:dependencies []}}) 
>
> (defn resolve-dep 
>   [graph name] 
>   (let [resolved (atom []) 
> resolved-set (atom #{}) 
> f (fn f [name] 
> (doseq [x (:dependencies (graph name))] 
>   (f x)) 
> (when-not (@resolved-set name) 
>   (swap! resolved conj name) 
>   (swap! resolved-set conj name)))] 
> (f name) 
> @resolved)) 
>
> (resolve-dep graph "a") 
> ;=> ["d" "e" "c" "b" "a"] 
>
> This code works, but not sure if it's idiomatic clojure code. 
> The use of atom feels like procedural than functional to me since 
> there's no concurrency involved at all. 
>
> Any suggestions? 
>

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




Re: Idiomatic way to write dependency resolving algorithms?

2013-06-09 Thread Casper Clausen
Also yours explodes if given a circular dependency. There is no way around 
throwing an exception, but it is always nice not to have stack overflows in 
your code:

(def graph 
  {"a" {:dependencies ["b" "d"]} 
   "b" {:dependencies ["c" "e"]} 
   "c" {:dependencies ["d" "e"]} 
   "d" {:dependencies ["c"]} 
   "e" {:dependencies []}})

(resolve-dep graph "c") => java.lang.StackOverflowError

On Sunday, June 9, 2013 10:30:51 AM UTC+2, Casper Clausen wrote:
>
> Here is a similar algorithm I did for work a while back:
>
> (defn- find-next-node [deps used-nodes]
>   (some (fn [[k v]] (if (empty? (remove used-nodes v)) k)) deps))
>
> (defn topsort
>   "Takes a map of dependencies between items and performs a topological 
> sort.
>E.g. (topsort  {1 [2 3] 3 [] 2 [3]}) => [3 2 1]"
>   [deps]
>   (loop [deps deps res []]
> (if (empty? deps)
>   res
>   (if-let [item (find-next-node deps (set res))]
> (recur (dissoc deps item) (conj res item))
> (throw (Exception. (str "A circular dependency was found: " 
> deps)))
>
> I am not sure if it is optimal, but it does it without the atom which is a 
> bit nicer i think. I'm also open to input for a better way of course.
>
>
>
> On Friday, May 31, 2013 6:33:59 PM UTC+2, Alice wrote:
>>
>> (def graph 
>>   {"a" {:dependencies ["b" "d"]} 
>>"b" {:dependencies ["c" "e"]} 
>>"c" {:dependencies ["d" "e"]} 
>>"d" {:dependencies []} 
>>"e" {:dependencies []}}) 
>>
>> (defn resolve-dep 
>>   [graph name] 
>>   (let [resolved (atom []) 
>> resolved-set (atom #{}) 
>> f (fn f [name] 
>> (doseq [x (:dependencies (graph name))] 
>>   (f x)) 
>> (when-not (@resolved-set name) 
>>   (swap! resolved conj name) 
>>   (swap! resolved-set conj name)))] 
>> (f name) 
>> @resolved)) 
>>
>> (resolve-dep graph "a") 
>> ;=> ["d" "e" "c" "b" "a"] 
>>
>> This code works, but not sure if it's idiomatic clojure code. 
>> The use of atom feels like procedural than functional to me since 
>> there's no concurrency involved at all. 
>>
>> Any suggestions? 
>>
>

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




Re: ANN swag a DSL for documenting Compojure routes using Swagger

2013-08-16 Thread Casper Clausen
Nice work. Looking forward to giving it a spin.

On Thursday, August 15, 2013 12:13:11 PM UTC+2, ronen wrote:
>
> Swagger  is a cool project 
> for documenting Restful API's, 
>
> Swag is a DSL that wraps Compojure routes enabling them to be listed and 
> described automagically without the need of maintaining json
>
> https://github.com/narkisr/swag
>
> Feedback is welcome
> Ronen
>

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


Reading namespaced keywords

2013-09-17 Thread Casper Clausen
I am reading a bunch of clojure files using the build-in reader (or 
tools.reader, it has the same problem) and I am running into a problem 
regarding namespaced keywords (is that the right term?) such as ::l/test.

=> (read-string "::l/test")
RuntimeException Invalid token: ::l/test 
 clojure.lang.Util.runtimeException (Util.java:219)

It seems that the reader requires the namespace alias 'l' to exist. This is 
a shame because in most (all?) other respects the reader is able to just 
read in the symbols even if their namespace is not loaded. So in order for 
me to read a file with a namespaced keyword I need to eval at least the ns 
form of the file, which then requires me to eval the ns forms of its 
dependencies (and so on). My code is basically building on the excellent 
codeq analyzer 
(https://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj),
 
so I am guessing this would have the same problem when running into a 
similar namespaced keyword.

So my question is how do I best get around this?

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


Re: Reading namespaced keywords

2013-09-17 Thread Casper Clausen
The double colon keyword creates a namespaced keyword and is perfectly 
valid syntax. It's just not used that often :) 

By default a keyword like ::test resolves to the current namespace like 
::current-ns/test, but you can also provide another ns which causes the 
problem when reading.

Have at look 
at 
https://github.com/clojure/core.logic/blob/0d1d545f0a81c585c7449aecb5d661120f3da568/src/main/clojure/clojure/core/logic/fd.clj
 
for instance.

On Wednesday, September 18, 2013 1:05:01 AM UTC+2, daveray wrote:
>
> Hey,
>
> You have too many colons:
>
> user=> (read-string ":l/test")
> :l/test
>
>
> Dave
>
>
>
> On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen 
> > wrote:
>
>> I am reading a bunch of clojure files using the build-in reader (or 
>> tools.reader, it has the same problem) and I am running into a problem 
>> regarding namespaced keywords (is that the right term?) such as ::l/test.
>>
>> => (read-string "::l/test")
>> RuntimeException Invalid token: ::l/test 
>>  clojure.lang.Util.runtimeException (Util.java:219)
>>
>> It seems that the reader requires the namespace alias 'l' to exist. This 
>> is a shame because in most (all?) other respects the reader is able to just 
>> read in the symbols even if their namespace is not loaded. So in order for 
>> me to read a file with a namespaced keyword I need to eval at least the ns 
>> form of the file, which then requires me to eval the ns forms of its 
>> dependencies (and so on). My code is basically building on the excellent 
>> codeq analyzer (
>> https://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj),
>>  
>> so I am guessing this would have the same problem when running into a 
>> similar namespaced keyword.
>>
>> So my question is how do I best get around this?
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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


Re: [ANN] Counterclockwise - Clojure plugin for Eclipse

2013-10-12 Thread Casper Clausen
Nice work, looking forward to using this. 

I'm wondering though, what is the best or "official" way to import a lein 
project? I've never been able to figure it out, so I always do lein pom and 
import as maven project and then convert to leiningen project. Is there a 
better way?



On Saturday, October 12, 2013 2:11:53 AM UTC+2, Steve Buikhuizen wrote:
>
> Laurent, you rock!
>
> Auto-formatting is already saving my fingers a lot of travelling.
>
> Thanks for the great work.
>

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


Re: Why is this code so slow?

2013-02-03 Thread Casper Clausen
Given that I don't know much about how scala does optimizations, I find the 
question of why the scala version is faster than the Java version even more 
interesting.

It seems to me that in Scala, the list (don't know the actual data type 
which is created) of 1 to 20 is created each time isDivisibleByAll is 
called which (probably?) creates some overhead. 

The Java version doesn't create the list for each check, but it uses an 
ArrayList where it could use an array and Integer where it could use int - 
shenedu makes that optimization in the buttom, but it only improves about 
half a second according to him.

So what's going on the Scala version?

On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote:
>
> Hello all. I'm working through the Project Euler problems in Java, 
> Scala, & Clojure (trying to learn all three?!?). I notice that for one 
> particular problem, I use--more or less--a similar algorithm for all 
> three, but the clojure code runs about 20-30 times slower than the 
> java/scala versions. Does anyone have any idea why this might be? It 
> strikes me that it might have something to do with every? but I don't 
> know because I'm a newbie with Clojure. 
>
>
> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
>  
>
> thanks, 
>
> alex 
>

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




Re: JSON escaping

2013-02-08 Thread Casper Clausen
Don't know about cheshire, but the newest version of clojure.data.json has 
a :escape-slash option which does the trick.

On Saturday, February 9, 2013 12:18:50 AM UTC+1, Jonathon McKitrick wrote:
>
> I'm generating JSON for salesforce/apex consumption, and apparently Apex 
> does not like correctly escaped JSON with backslashes.  But Cheshire (the 
> JSON library I'm using) does not seem to have an option to generate JSON 
> without escaped content.
>
> Is there a simple way to solve this problem?  I'm sure it's a simple one, 
> but I'm new to clojure, and I'm short on time to solve the issue.
>
> thanks!
>

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




Re: PersistentHashMaps coming to ClojureScript

2012-04-21 Thread Casper Clausen
Excellent! Any idea how this implementation would compare performance
wise to the java implementation if imported to Clojure?

On Apr 20, 8:36 pm, Michał Marczyk  wrote:
> It's pure ClojureScript. Hopefully a step towards CinC, yes. :-)
>
> Sincerely,
> Michał
>
> On 20 April 2012 20:32, Brent Millare  wrote:
>
>
>
>
>
>
>
> > Quick question, so does this mean we have clojure's persistent data
> > structures implemented in clojurescript or js? This would mean we are one
> > more step closer to C-in-C right?
>
> > On Friday, April 20, 2012 1:38:17 PM UTC-4, Michał Marczyk wrote:
>
> >> Since the latest PHM patch has now been merged to master (thanks,
> >> David!), I wanted to take this opportunity to note that porting all
> >> that Java code (including the transient support for PHM -- a working
> >> version of which is available for testing in its own ticket [1] -- and
> >> now the PersistentTreeMap [2]) has been completely smooth sailing.
> >> Some additions have been made to the implementation to improve
> >> performance while maintaining clarity of the code (here some excellent
> >> suggestions from David were very helpful), but the initial
> >> implementation already worked without them and client code could
> >> absolutely replicate them (by providing the requisite compiler macros
> >> in its own namespace). It's not that I expected insurmountable
> >> difficulties, but experiencing just how complete ClojureScript already
> >> is in the context of this sort of non-trivial data structure
> >> implementation task has been amazing.
>
> >> For those interested in how PHM's performance compares to that of the
> >> previously used ObjMap and HashMap copy-on-write implementations,
> >> there are some jsPerf tests linked to from the ticket [3]. There's
> >> also a TransientHM vs. PHM comparison linked to from [2].
>
> >> Sincerely,
> >> Michał
>
> >> [1]http://dev.clojure.org/jira/browse/CLJS-181
> >> [2]http://dev.clojure.org/jira/browse/CLJS-187
> >> [3]http://dev.clojure.org/jira/browse/CLJS-178
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with your
> > first post.
> > To unsubscribe from 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: Typed Clojure 0.1-alpha2

2012-04-21 Thread Casper Clausen
Looks interesting.

Personally I always thought clojure's handling of function arity is a
bit strange. I don't understand why calling a function like this

(defn testfn [one two] ...)

(test-fn 1)

is not at least a compiler warning, possibly with a switch for the
compiler for strict checking. I understand that it is not always
possible to perform this check, but why not do it when possible? It
would make clojure alot safer to use without a test suite covering
every code path.


On Apr 20, 8:50 pm, Ambrose Bonnaire-Sergeant
 wrote:
> Hi,
>
> I know there are a few people interested in trying Typed Clojure,
> so I've cut an early alpha release to give a taste.
>
> These are *very* early days, but looking through the readme will
> give you some hints as to what works in this release. Don't
> expect too much.
>
> https://github.com/frenchy64/typed-clojure
>
> Please give it a whirl, feedback welcome!
>
> Thanks,
> Ambrose

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: future with user specified ExecutorService

2012-10-27 Thread Casper Clausen
+1 That would be nice. This may not be the right place for the suggestion 
though.

On Thursday, October 25, 2012 2:43:58 PM UTC+2, Max Penet wrote:
>
> wrong commit: 
> https://github.com/mpenet/clojure/commit/9c6e47524dc21c6bdfaa9d0cc2a69377cc69cbf3
>  
>
> On Thursday, October 25, 2012 2:35:01 PM UTC+2, Max Penet wrote:
>>
>> Another enhancement proposal, would it be possible to have a future-call 
>> arity with an additional argument as the ExecutorService used. It seems to 
>> be a trivial but useful modification, but I wanted to ask here before 
>> creating a ticket for this. 
>>
>> Something like this maybe: 
>> https://github.com/mpenet/clojure/commit/e5295ac1aa49036c98a3a4e18cba974cd72483d5
>>
>> Max
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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] moderns-cljs tutorial 6

2012-11-14 Thread Casper Clausen
I just want to chime in and say good work. This exactly what I have been 
looking for as a gentle introduction to clojurescript.

If I can make one suggestion, it would be nice to have each chapter 
accompanied by a project for that chapter. It would mean a lot less copy 
and paste to follow along with the examples.

/Casper

On Tuesday, November 13, 2012 5:41:49 PM UTC+1, Mimmo Cosenza wrote:
>
> Hi all,
> I'm always a little bit afraid in announcing my small results  as a 
> clojure/cljurescript newbie to such a smart community of programmers. 
>
> I just published on github my learning efforts in the 6th tutorial on 
> clojurescript
>
> https://github.com/magomimmo/modern-cljs
>
> Hope it can help other newbies like me.
>
> Mimmo
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Type hints and records

2011-10-19 Thread Casper Clausen
Thanks, that works nicely!

Is it intended or just incidental that type hints are not retained
using the :-notation? There doesn't seem to be much advantage to not
including type hints when available.


On Oct 11, 1:02 am, Stuart Halloway  wrote:
> > I am using a record to wrap a number of java classes, which I then
> > access various properties on. I am trying to avoid reflection so I
> > type have type hinted, however when accessing the values in the record
> > the type hints are lost. It might look something like this
>
> > (defrecord Rec [^Integer i])
>
> > (defn to-string [^Rec record] (.toString (:i record)))
>
> > However the to-string function gives a reflection warning, even with
> > the input the to function type hinted. Now I know that type hints
> > don't survive across function boundaries, but is there no way to get a
> > type hinted value from the record?
>
> Treat the record as a typed thing instead of as a map (note the dot instead 
> of the colon).
>
> (defn to-string [^Rec record] (.toString (.i record)))
>
> That said, and not knowing exactly what you are doing, the following looks 
> better to me:
>
> (defrecord Rec [^int i])
> (defn to-string [^Rec record] (str (:i record)))
>
> Stu
>
> Stuart Halloway
> Clojure/corehttp://clojure.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


Re: Type hints and records

2011-10-20 Thread Casper Clausen
Thanks for the clarification.

Just to clear up any confusion, the .toString example was just the
simplest example I could think of that illustrated was I was seeing
with regards to reflection and type hints :)

On Oct 20, 4:22 am, Michael Fogus  wrote:
> Another potential option is to implement a record toString method:
>
> (defrecord Rec [^Integer i]
>   Object
>   (toString [_] (str i)))
>
> (str (Rec. 42))
> ;=> "42"

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