Re: Strange behavior with future

[Oskar Kvist]

Oh, now I understand! I close the stream (in the with-open) in the main 
thread before the other thread got a chance to play it.

On Monday, December 31, 2012 3:49:25 AM UTC+1, Oskar Kvist wrote:
>
> Ok, here is some more code:
>
> The line (-> in Player. .play) nil)) in the first function is what I'm 
> trying to wrap in a future. The first two functions are basically what is 
> used when trying to play a sound. The other 3 is the "main loop" part of my 
> program. I don't think anything else is relevant.
>
> (defn play-mp3 [name]
>   (with-open [in (jio/input-stream (str audiodir name ".mp3"))]
> (-> in Player. .play) nil))
>
> (defn play
>   ([words-map] (play words-map "1"))
>   ([words-map n] (let [mp3-n (min (Integer/parseInt n) (:mp3s @last-info))]
>(if (and @last-word (pos? mp3-n))
>  (play-mp3 (str @last-word mp3-n))
>  {:output "play what?"}
>
> (def cmds (let [cmds ["add" "delete" "random" "show" "help" "play"]
> cmds (zipmap cmds (map #(ns-resolve 'dictionary.core 
> (symbol %)) cmds))]
> (conj cmds ["key" pron-key] ["lookup" lookup-cmd])))
>
> (defn handle [cmd]
>   (let [[cmd & args] (str/split cmd #"\s+")
> matching (starts-with-in cmd cmds)]
> (when (= 1 (count matching))
>   (let [{:keys [output new-words-map]}
> (apply (val (first matching)) @words-atom args)]
> (if output (println output))
> (if new-words-map (reset! words-atom new-words-map
> (if (and (or (.startsWith "exit" cmd) (.startsWith "quit" cmd)) (pos? 
> (count cmd)))
>   false
>   true)))
>
>
> (defn -main [& args]
>   (def words-atom (atom (load-words)))
>   (loop []
> (print "> ") (flush)
> (let [cmd (read-line)]
>   (println)
>   (when (handle cmd)
> (println)
> (store-words @words-atom)
> (recur
>   (shutdown-agents))
>
> On Monday, December 31, 2012 12:12:09 AM UTC+1, Moritz Ulrich wrote:
>>
>> Laziness might be your problem, but that wouldn't explain (println 
>> "called") working without a deref. 
>>
>> Can you show a bit more code around this call to `future'? 
>>
>> On Sun, Dec 30, 2012 at 8:31 AM, Oskar Kvist  wrote: 
>> > Hi! 
>> > 
>> > I'm trying to play a sound in my application, using 
>> > http://www.javazoom.net/javalayer/documents.html that lib. Anyway, I 
>> tried 
>> > playing the sound in a future, so the main thread would not block while 
>> > playing, like so: (future (-> in Player. .play)). But if I don't deref 
>> the 
>> > future, the sound does not play. If I do deref it, the sound plays, but 
>> I 
>> > have to wait for it, which is what I wanted to avoid. If I do (future 
>> (do 
>> > (println "called") (-> in Player. .play))), without a deref, it prints 
>> > "called" but does still not play the sound. If I do (future (do (-> in 
>> > Player. .play) (println "called"))), without a deref, it neither prints 
>> nor 
>> > plays. What could be wrong? 
>> > 
>> > I'm using clojure 1.4.0 and `lein trampoline run -m ns/main` to run my 
>> > program. 
>> > 
>> > -- 
>> > 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 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: Strange behavior with future

[Oskar Kvist]

Ok, here is some more code:

The line (-> in Player. .play) nil)) in the first function is what I'm 
trying to wrap in a future. The first two functions are basically what is 
used when trying to play a sound. The other 3 is the "main loop" part of my 
program. I don't think anything else is relevant.

(defn play-mp3 [name]
  (with-open [in (jio/input-stream (str audiodir name ".mp3"))]
(-> in Player. .play) nil))

(defn play
  ([words-map] (play words-map "1"))
  ([words-map n] (let [mp3-n (min (Integer/parseInt n) (:mp3s @last-info))]
   (if (and @last-word (pos? mp3-n))
 (play-mp3 (str @last-word mp3-n))
 {:output "play what?"}

(def cmds (let [cmds ["add" "delete" "random" "show" "help" "play"]
cmds (zipmap cmds (map #(ns-resolve 'dictionary.core 
(symbol %)) cmds))]
(conj cmds ["key" pron-key] ["lookup" lookup-cmd])))

(defn handle [cmd]
  (let [[cmd & args] (str/split cmd #"\s+")
matching (starts-with-in cmd cmds)]
(when (= 1 (count matching))
  (let [{:keys [output new-words-map]}
(apply (val (first matching)) @words-atom args)]
(if output (println output))
(if new-words-map (reset! words-atom new-words-map
(if (and (or (.startsWith "exit" cmd) (.startsWith "quit" cmd)) (pos? 
(count cmd)))
  false
  true)))


(defn -main [& args]
  (def words-atom (atom (load-words)))
  (loop []
(print "> ") (flush)
(let [cmd (read-line)]
  (println)
  (when (handle cmd)
(println)
(store-words @words-atom)
(recur
  (shutdown-agents))

On Monday, December 31, 2012 12:12:09 AM UTC+1, Moritz Ulrich wrote:
>
> Laziness might be your problem, but that wouldn't explain (println 
> "called") working without a deref. 
>
> Can you show a bit more code around this call to `future'? 
>
> On Sun, Dec 30, 2012 at 8:31 AM, Oskar Kvist 
> > 
> wrote: 
> > Hi! 
> > 
> > I'm trying to play a sound in my application, using 
> > http://www.javazoom.net/javalayer/documents.html that lib. Anyway, I 
> tried 
> > playing the sound in a future, so the main thread would not block while 
> > playing, like so: (future (-> in Player. .play)). But if I don't deref 
> the 
> > future, the sound does not play. If I do deref it, the sound plays, but 
> I 
> > have to wait for it, which is what I wanted to avoid. If I do (future 
> (do 
> > (println "called") (-> in Player. .play))), without a deref, it prints 
> > "called" but does still not play the sound. If I do (future (do (-> in 
> > Player. .play) (println "called"))), without a deref, it neither prints 
> nor 
> > plays. What could be wrong? 
> > 
> > I'm using clojure 1.4.0 and `lein trampoline run -m ns/main` to run my 
> > program. 
> > 
> > -- 
> > 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 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: abysmal multicore performance, especially on AMD processors

[cameron]

I've posted a patch with some changes here 
(https://gist.github.com/4416803), it includes the record change here  and 
a small change to interpret-instruction, the benchmark runs > 2x the 
default as it did for Marshall.
The patch also modifies the main loop to use a thread pool instead of 
agents and allows you to set the number of threads, this might help 
diagnosing the parallel performance issue.

On the modified benchmark I'm seeing ~4x speedup with the parallel version 
on an 8 core machine and the profiler reports that the parallel version is 
using twice as much cpu time. 

I also had another look at the native calls issue & modified the clojure 
runtime to avoid most to the calls the profiler said were taking 
significantly more time in the parallel version, it did speed things up but 
only by ~6%, not the large margin the profiling results had led me to 
believe were possible, it looks like the profiler overstates these methods 
times. The modified clojure 1.5 is available here 
https://github.com/cdorrat/clojure/commit/dfb5f99eb5d0a45165978e079284bab1f25bd79f
 
if anyone's interested

YourKit is reporting that a number of clojure.core functions are taking 
longer in the parallel version than the serial and they all seem to be 
methods that have one or more instanceof or instance? calls but given the 
results above I'm not sure how much weight to give this. 

It's seems the elephant is still in the room and responsible to ~50% of the 
cpu time :)

Cameron.

On Saturday, December 22, 2012 10:57:28 AM UTC+11, Marshall 
Bockrath-Vandegrift wrote:
>
> Lee Spector > writes: 
>
> > FWIW I used records for push-states at one point but did not observe a 
> > speedup and it required much messier code, so I reverted to 
> > struct-maps. But maybe I wasn't doing the right timings. I'm curious 
> > about how you changed to records without the messiness. I'll include 
> > below my sig the way that I had to do it... maybe you can show me what 
> > you did instead. 
>
> I just double-checked, and I definitely see a >2x speedup on Josiah’s 
> benchmark.  That may still be synthetic, of course.  Here’s what I did: 
>
> (eval `(defrecord ~'PushState [~'trace ~@(map (comp symbol name) 
> push-types)])) 
> 
> (let [empty-state (map->PushState {})] 
>   (defn make-push-state 
> "Returns an empty push state." 
> [] empty-state)) 
>
> > Still, I guess the gorilla in the room, which is eating the multicore 
> > performance, hasn't yet been found. 
>
> No, not yet...  I’ve become obsessed with figuring it out though, so 
> still slogging at it. 
>
> -Marshall 
>
>

-- 
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: What would you use a #[] data literal for?

[dgrnbrg]

You can also patch the LispReader in jvm Clojure without dropping to Java. 
Here's an example of that to add a #b reader 
literal: 
https://github.com/dgrnbrg/piplin/blob/master/src/piplin/types/bits.clj#L216

On Sunday, December 30, 2012 7:38:44 AM UTC-6, Ambrose Bonnaire-Sergeant 
wrote:
>
> Jozef,
>
> How do you achieve that?
>
> Thanks,
> Ambrose
>
> On Sun, Dec 30, 2012 at 7:45 PM, Jozef Wagner 
> 
> > wrote:
>
>> I use it in Clojurescript for a custom tuple type. 
>>
>> For small number of items, deftypes are way faster to create and access 
>> than PersistentVectors. I use tuple type e.g. for returning multiple values 
>> from a function. Implementing #[] allowed me to have a compact syntax for 
>> creating and destructuring such tuples.
>>
>> (defn foo [a b] 
>>   #[(+ a b) (- a b) (* a b)])
>>
>> (defn foo []
>>   (let [#[plus minus times] (foo 1 2)]
>> (str "bla bla" plus "blaah" minus)))
>>
>> JW
>>
>> On Friday, December 28, 2012 11:15:52 PM UTC+1, vemv wrote:
>>>
>>> I was just wondering - given that we have the #() and #{} literals, why 
>>> not a #[] as well? Queues look like a good fit.
>>>
>>  -- 
>> 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 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: What would you use a #[] data literal for?

[Brandon Bloom]

Wouldn't it be better to implement this as an automatic optimization, just 
like PersistentArrayMap vs PersistentHashMap ?

fwiw, I'm cautiously in favor of #[] being used for queues.

On Sunday, December 30, 2012 3:45:24 AM UTC-8, Jozef Wagner wrote:
>
> I use it in Clojurescript for a custom tuple type. 
>
> For small number of items, deftypes are way faster to create and access 
> than PersistentVectors. I use tuple type e.g. for returning multiple values 
> from a function. Implementing #[] allowed me to have a compact syntax for 
> creating and destructuring such tuples.
>
> (defn foo [a b] 
>   #[(+ a b) (- a b) (* a b)])
>
> (defn foo []
>   (let [#[plus minus times] (foo 1 2)]
> (str "bla bla" plus "blaah" minus)))
>
> JW
>
> On Friday, December 28, 2012 11:15:52 PM UTC+1, vemv wrote:
>>
>> I was just wondering - given that we have the #() and #{} literals, why 
>> not a #[] as well? Queues look like a good fit.
>>
>

-- 
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: Strange behavior with future

[Moritz Ulrich]

Laziness might be your problem, but that wouldn't explain (println
"called") working without a deref.

Can you show a bit more code around this call to `future'?

On Sun, Dec 30, 2012 at 8:31 AM, Oskar Kvist  wrote:
> Hi!
>
> I'm trying to play a sound in my application, using
> http://www.javazoom.net/javalayer/documents.html that lib. Anyway, I tried
> playing the sound in a future, so the main thread would not block while
> playing, like so: (future (-> in Player. .play)). But if I don't deref the
> future, the sound does not play. If I do deref it, the sound plays, but I
> have to wait for it, which is what I wanted to avoid. If I do (future (do
> (println "called") (-> in Player. .play))), without a deref, it prints
> "called" but does still not play the sound. If I do (future (do (-> in
> Player. .play) (println "called"))), without a deref, it neither prints nor
> plays. What could be wrong?
>
> I'm using clojure 1.4.0 and `lein trampoline run -m ns/main` to run my
> program.
>
> --
> 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: cljs-clj interop

[Stuart Campbell]

OK, unless there's some way to set arbitrary properties on a Java object, I
guess this isn't possible...

ClojureScript:cljs.user> (aset js/Packages.clojure.lang.IFn "prototype"
(js/Object.))
"Error evaluating:" (aset js/Packages.clojure.lang.IFn "prototype"
(js/Object.)) :as "(Packages.clojure.lang.IFn[\"prototype\"] = (new
Object()));\n"
org.mozilla.javascript.EvaluatorException: Java class "clojure.lang.IFn"
has no public instance field or method named "prototype". (#9)
at :9 (anonymous)
at :9


On 31 December 2012 09:41, Stuart Campbell  wrote:

> Ah, you're right -- thanks. That leads me to another error:
>
> ClojureScript:cljs.user> (extend-type js/Packages.clojure.lang.IFn IFn
> (-invoke ([this] (.invoke this
> "Error evaluating:" (extend-type js/Packages.clojure.lang.IFn IFn (-invoke
> ([this] (.invoke this :as
> "Packages.clojure.lang.IFn.prototype.cljs$core$IFn$ =
> true;\nPackages.clojure.lang.IFn.prototype.call = (function
> (this_sym23394){\nvar this_sym23394__23395 = this;\nvar this__23396 =
> this_sym23394__23395;\nreturn
> this__23396.invoke();\n});\nPackages.clojure.lang.IFn.prototype.apply =
> (function (this_sym23392,args23393){\nreturn
> this_sym23392.call.apply(this_sym23392,[this_sym23392].concat(args23393.slice()));\n});\n"
> org.mozilla.javascript.EcmaError: TypeError: Cannot set property
> "cljs$core$IFn$" of null to "true" (#25)
> at :25 (anonymous)
> at :25 (anonymous)
> at :25
>
> I'll keep investigating.
>
> On 30 December 2012 12:31, David Nolen  wrote:
>
>> I think you've just formatted your code incorrectly. Did you try
>> something like this?
>>
>> (extend-type js/Packages.clojure.lang.IFn
>>   IFn
>>   (-invoke
>> ([this] (.invoke this))
>> ([this a] (.invoke this a)))
>>   )
>>
>>
>>  On Sat, Dec 29, 2012 at 8:22 PM, Stuart Campbell wrote:
>>
>>>  Hi all,
>>>
>>> I'm toying with a way to use Clojure objects from a Rhino-based
>>> ClojureScript environment (https://github.com/harto/rhino-bridge).
>>>
>>> I've been able to export a Clojure function into the ClojureScript
>>> environment without too much difficulty. Ideally, I'd like to be able to
>>> call that function as if it were a regular ClojureScript function.
>>>
>>> I was hoping I could do something like:
>>>
>>> (extend-type js/Packages.clojure.lang.IFn
>>>   IFn
>>>   (-invoke [this] (.invoke this))
>>>   (-invoke [this a] (.invoke this a))
>>>   ;; etc
>>>   )
>>>
>>> However, this yields an error that I don't quite understand:
>>>
>>> java.lang.UnsupportedOperationException: nth not supported on this type:
>>> Symbol
>>> at clojure.lang.RT.nthFrom(RT.java:846)
>>> at clojure.lang.RT.nth(RT.java:796)
>>> at
>>> cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486)
>>> at clojure.core$map$fn__4087.invoke(core.clj:2434)
>>>
>>> In fact, I'm not sure this will work at all, since (type) doesn't appear
>>> to work with non-native JS objects.
>>>
>>> Is the extend-type method feasible?
>>>
>>> Cheers,
>>> Stuart
>>>
>>> --
>>> 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
>
>
>

-- 
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: cljs-clj interop

[Stuart Campbell]

Ah, you're right -- thanks. That leads me to another error:

ClojureScript:cljs.user> (extend-type js/Packages.clojure.lang.IFn IFn
(-invoke ([this] (.invoke this
"Error evaluating:" (extend-type js/Packages.clojure.lang.IFn IFn (-invoke
([this] (.invoke this :as
"Packages.clojure.lang.IFn.prototype.cljs$core$IFn$ =
true;\nPackages.clojure.lang.IFn.prototype.call = (function
(this_sym23394){\nvar this_sym23394__23395 = this;\nvar this__23396 =
this_sym23394__23395;\nreturn
this__23396.invoke();\n});\nPackages.clojure.lang.IFn.prototype.apply =
(function (this_sym23392,args23393){\nreturn
this_sym23392.call.apply(this_sym23392,[this_sym23392].concat(args23393.slice()));\n});\n"
org.mozilla.javascript.EcmaError: TypeError: Cannot set property
"cljs$core$IFn$" of null to "true" (#25)
at :25 (anonymous)
at :25 (anonymous)
at :25

I'll keep investigating.

On 30 December 2012 12:31, David Nolen  wrote:

> I think you've just formatted your code incorrectly. Did you try something
> like this?
>
> (extend-type js/Packages.clojure.lang.IFn
>   IFn
>   (-invoke
> ([this] (.invoke this))
> ([this a] (.invoke this a)))
>   )
>
>
> On Sat, Dec 29, 2012 at 8:22 PM, Stuart Campbell  wrote:
>
>> Hi all,
>>
>> I'm toying with a way to use Clojure objects from a Rhino-based
>> ClojureScript environment (https://github.com/harto/rhino-bridge).
>>
>> I've been able to export a Clojure function into the ClojureScript
>> environment without too much difficulty. Ideally, I'd like to be able to
>> call that function as if it were a regular ClojureScript function.
>>
>> I was hoping I could do something like:
>>
>> (extend-type js/Packages.clojure.lang.IFn
>>   IFn
>>   (-invoke [this] (.invoke this))
>>   (-invoke [this a] (.invoke this a))
>>   ;; etc
>>   )
>>
>> However, this yields an error that I don't quite understand:
>>
>> java.lang.UnsupportedOperationException: nth not supported on this type:
>> Symbol
>> at clojure.lang.RT.nthFrom(RT.java:846)
>> at clojure.lang.RT.nth(RT.java:796)
>> at
>> cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486)
>> at clojure.core$map$fn__4087.invoke(core.clj:2434)
>>
>> In fact, I'm not sure this will work at all, since (type) doesn't appear
>> to work with non-native JS objects.
>>
>> Is the extend-type method feasible?
>>
>> Cheers,
>> Stuart
>>
>> --
>> 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

-- 
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: What would you use a #[] data literal for?

[Jozef Wagner]

By patching LispReader in Clojure, http://goo.gl/tWnkq and ClojureScript 
compiler http://goo.gl/nyKc5 . Used in closed source project, so I can use 
my own flavor of Clojure there.

JW

On Sunday, December 30, 2012 2:38:44 PM UTC+1, Ambrose Bonnaire-Sergeant 
wrote:
>
> Jozef,
>
> How do you achieve that?
>
> Thanks,
> Ambrose
>
> On Sun, Dec 30, 2012 at 7:45 PM, Jozef Wagner 
> 
> > wrote:
>
>> I use it in Clojurescript for a custom tuple type. 
>>
>> For small number of items, deftypes are way faster to create and access 
>> than PersistentVectors. I use tuple type e.g. for returning multiple values 
>> from a function. Implementing #[] allowed me to have a compact syntax for 
>> creating and destructuring such tuples.
>>
>> (defn foo [a b] 
>>   #[(+ a b) (- a b) (* a b)])
>>
>> (defn foo []
>>   (let [#[plus minus times] (foo 1 2)]
>> (str "bla bla" plus "blaah" minus)))
>>
>> JW
>>
>> On Friday, December 28, 2012 11:15:52 PM UTC+1, vemv wrote:
>>>
>>> I was just wondering - given that we have the #() and #{} literals, why 
>>> not a #[] as well? Queues look like a good fit.
>>>
>>  -- 
>> 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 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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Ben Wolfson]

If-let would be confusing if it handled multiple bindings, since you wouldn't 
know how much had succeeded when you executed the else branch. That doesn't 
apply to when-let; fortunately it's quite simple to write one that does do 
multiple bindings in terms of the existing when-let, and it would be very 
similar to the maybe monad. It still would not be the maybe monad for the same 
reason that the existing "maybe-m" in the monads library isn't actually the 
maybe monad: without a Just-like wrapper meaning "success", it's impossible to 
successfully return nil.

Sent from my iPhone

On Dec 30, 2012, at 11:56 AM, Mark Engelberg  wrote:

> On Sun, Dec 30, 2012 at 4:32 AM, Meikel Brandmeyer  wrote:
> (when-let [s (seq coll)]
>   (do-stuff-with s))
> 
> I would find when-let a lot more useful if it worked with multiple bindings, 
> e.g.,
> (when-let [x blah1
>y blah2
>z blah3]
> (+ x y z))
> should shortcut return nil if any of x, y, z evaluate to falsey.
> 
> Actually, I usually use Christophe Grand's version of when-let and if-let 
> which handle this.  I find it to be more useful that way.
> 
> Any idea why core's when-let/if-let don't behave this way?  I've been looking 
> through the monad material lately, and it seems like let is the identity 
> monad, for is the sequence monad, and when-let wants to be the maybe monad, 
> but isn't quite because it only handles one binding.  Doesn't it seem most 
> natural to let it handle multiple bindings?  What am I missing?
> -- 
> 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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Mark Engelberg]

On Sun, Dec 30, 2012 at 4:32 AM, Meikel Brandmeyer  wrote:

> (when-let [s (seq coll)]
>   (do-stuff-with s))
>

I would find when-let a lot more useful if it worked with multiple
bindings, e.g.,
(when-let [x blah1
   y blah2
   z blah3]
(+ x y z))
should shortcut return nil if any of x, y, z evaluate to falsey.

Actually, I usually use Christophe Grand's version of when-let and if-let
which handle this.  I find it to be more useful that way.

Any idea why core's when-let/if-let don't behave this way?  I've been
looking through the monad material lately, and it seems like let is the
identity monad, for is the sequence monad, and when-let wants to be the
maybe monad, but isn't quite because it only handles one binding.  Doesn't
it seem most natural to let it handle multiple bindings?  What am I missing?

-- 
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: Trouble calling Dojo grid constructor from ClojureScript

[Patrick Logan]

I don't want to bog the list down with my javascript naivete, but the full 
fix to dojo/on.js is something like this:

if (type.call && !(((typeof type) === "string") || (type instanceof 
String))){...


On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>
> ok. I've had some time to look into this now and have figured out a few 
> things.
>
> 1. This is not due to calling the DGrid constructor from clojurescript. It 
> occurs even when I call the DGrid constructor from straight javascript 
> code. So it doesn't have to do with the clojurescript code calling the 
> constructor.
>
> 2. The error goes away if I don't require cljs.core. If cljs.core is 
> required then the grid constructor ends up calling back into some code in 
> cljs.core, which is where the error occurs. 
>
> So I'm a little further down the road but still don't know exactly why 
> doing a goog.require("cljs.core") causes cljs.core to receive events from 
> the DGrid constructor. Digging in with my javascript debugger and will 
> update this as I find out more information.
>
>
>
> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>
>> Hi, 
>>
>> I'm brand new to ClojureScript and have been trying to get myself 
>> familiarized with it's javascript interop capabilities by implementing 
>> the Dojo toolkit tutorials. I've successfully implemented several of 
>> the tutorials, but now I've run into something that I can't figure out 
>> and am looking for someone to point me in the right direction. 
>>
>> I am calling the DGrid(Dojo grid) constructor using the function 
>> maingrid 
>>
>> (ns couchadmin.core 
>>   (:use [jayq.util :only [clj->js]]) 
>>   (:require [clojure.browser.repl :as repl])) 
>>
>> (defn greet [dom fx] 
>>   (let [element (.byId dom "greetingcljs")] 
>> (set! (. element -innerHTML) "Hello from Dojo using 
>> ClojureScript") 
>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node 
>> element}) 
>>
>> (defn maingrid [dom grd] 
>>   (do 
>>
>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid") 
>> (js/alert "hello world"))) 
>>
>> (defn ^:export main [] 
>>   (comment (repl/connect "http://localhost:9000/repl";)) 
>>   (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!") 
>> greet)) 
>>   (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!") 
>> maingrid)) 
>>
>>
>> When the page is loaded the grid is constructed, but afterwards I see 
>> the following javascript exception 
>>
>> Uncaught Error: No protocol method ILookup.-lookup defined for 
>> type object: [object HTMLDivElement] 
>>
>> I'm wondering what this message is indicating. Did I call the 
>> constructor incorrectly? Is this an incompatibility with Dojo? Do I 
>> need to implement ILookup somehow? Any help would be greatly 
>> appreciated. 
>>
>> Brian 
>>
>

-- 
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: Will the JVM will always likely, remain the primary Clojure implementation ?

[Softaddicts]

IDE tools also picked up the trend !

http://itsacobolworld.blogspot.ca/2012/12/free-mainframe-cobol-developer-ide.html?m=1

Happy New Year Cobol fans !

:)


> If longevity is your top most concern, I have a suggestion here:
> 
> http://www.itarchitectforumblog.com/content/application_development/cobol_dead_language_rising.html
> 
> And if you do not think it's all around us:
> 
> http://itsacobolworld.blogspot.ca/?m=1
> 
> This thing has been alive and kicking since the 60s and has it seems a bright 
> future.
> 
> However, do not expect to do anything significant under 15000 locs per code
> units (aka namespace) or to become functional any time soon   :)))
> 
> Life is made of compromises...
> 
> Luc P.
> 
> 
> > If you don't get a flood of responses, I think it is because in this thread 
> > and the one linked earlier that Leon Adler started, several different 
> > people have explained evidence that Clojure on the JVM has had active 
> > development for five years, it is open source, and no one knows of any 
> > evidence that this will change any time in the future.  That isn't the same 
> > as saying "will remain", but it is the best anyone can give you that is 
> > based on evidence and reason, rather than some other dubious methods.
> > 
> > If you believe another language will give you better assurances than that 
> > about its future target/platform, I don't see how you came to that 
> > conclusion, unless it is by making up conclusions out of thin air.
> > 
> > Andy
> > 
> > On Dec 29, 2012, at 2:58 AM, Leon Adler wrote:
> > 
> > > That's unforeseeable because, that represents a very long time.
> > > 
> > > Having said that, this statement deserves a resay...
> > > 
> > > The JVM will remain the primary target/platform for Clojure, while Oracle 
> > > remains good i.e. it doesn't get Barmy.
> > > 
> > > What say the other people?
> > > 
> > > On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote:
> > > Having read the posts all over again, can I say that the JVM will remain 
> > > the primary target/platform for Clojure, while Oracle remains good i.e. 
> > > it doesn't get Barmy ? Isn't that unforeseeable?
> > > 
> > > On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote:
> > > 
> > >  
> > > Hi, 
> > > 
> > > I have noticed that this question is randomly appearing in many minds, 
> > > and it is frequently being asked, though there is no apparent reason on 
> > > why it is asked :/ or maybe people are unable to pen down the exact 
> > > reasons, and sad to say, even myself. 
> > >  
> > > There are reasons for which I ask this question -> 
> > > People (Majority) tend to stick with the primary implementations of 
> > > certain multi-implementation software. And in the case of Clojure, the  
> > > JVM implementation is the primary implementation now.
> > >   
> > > Having a primary implementation in case of BDFL lead software helps 
> > > as a glue in the community. For example , CPython is the primary python 
> > > implementation, even if there is an existance of IronPython or JPython.
> > > 
> > > The doubts of many, including me, will be cleared by an abstract 
> > > answer... That 'many' also include the companies adopting something new, 
> > > in this particular case, adopting clojure
> > >  
> > > QUESTION
> > >  
> > > Rich Hickey chose JVM as the platform of choice when he invented Clojure. 
> > > It's 
> > > community developed set of tools and documentation grew around the JVM 
> > > (Leiningen, for example). 
> > >  
> > > From the above statements, can I say that  
> > >  
> > > the JVM will always likely, remain the primary Clojure implementation ? 
> > > 
> > > 
> > > Thank You.
> > >  
> > >   
> > >   
> > >   
> > > 
> > > -- 
> > > 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
> --
> Softaddicts sent by ibisMail from my ipad!
> 
> -- 
> 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 
> firs

Re: Clarification on setting up Clojure, Lein and Emacs on fedora

[Phil Hagelberg]

On Sat, Dec 29, 2012 at 8:46 PM, Sayth Renshaw  wrote:
> https://github.com/technomancy/clojure-mode/blob/master/doc/index.md will
> read and let you know if I find anything that could be improved.

Actually I just updated the Emacs tutorial on clojure-doc.org last
night, so this might be a better resource if you're looking for
something more in-depth:

http://clojure-doc.org/articles/tutorials/emacs.html

-Phil

-- 
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

limit keys from client JSON (select-keys but nested?)

[Huey Petersen]

Hello,

I have client providing JSON data that is read into a map.  What I'm 
wondering is what is the best way to limit the data to only keys I white 
list.

{ :user { :first "John" :last "Doe" :role "admin" } }

In this example I wouldn't want to read the role key.  I can do 
`(select-keys user [:first :last])` for this example.

My two questions are:

1) Can you do this with destructuring?  I see lots of examples of 
destructuring a map into key values, but I wasn't sure if you could 
destructure a map into another map.

2) Is there a good way of doing this with nested maps?  An example:

{ :user { :first "John" :last "Doe" :dob { :month 12 :day 30 :year 2012 
:garbage "asdf" } } }

I would want to make sure :dob only contains keys :month, :day, :year.

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

Re: What would you use a #[] data literal for?

[Ambrose Bonnaire-Sergeant]

Jozef,

How do you achieve that?

Thanks,
Ambrose

On Sun, Dec 30, 2012 at 7:45 PM, Jozef Wagner wrote:

> I use it in Clojurescript for a custom tuple type.
>
> For small number of items, deftypes are way faster to create and access
> than PersistentVectors. I use tuple type e.g. for returning multiple values
> from a function. Implementing #[] allowed me to have a compact syntax for
> creating and destructuring such tuples.
>
> (defn foo [a b]
>   #[(+ a b) (- a b) (* a b)])
>
> (defn foo []
>   (let [#[plus minus times] (foo 1 2)]
> (str "bla bla" plus "blaah" minus)))
>
> JW
>
> On Friday, December 28, 2012 11:15:52 PM UTC+1, vemv wrote:
>>
>> I was just wondering - given that we have the #() and #{} literals, why
>> not a #[] as well? Queues look like a good fit.
>>
>  --
> 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: [ANN] Hosted findfn

[Anthony Rosequist]

Whoops, forgot the link. It's http://findfn.herokuapp.com/

Since there's only one dyno, the initial load time might take a while.

On Saturday, December 29, 2012 6:51:55 PM UTC-6, Anthony Rosequist wrote:
>
> I love Anthony Grimes's (et al) findfn  
> library, 
> but it requires some local setup (mainly the JVM security config for 
> clojail), so I decided to host it on Heroku.
>
> Features:
>
>- Access to findfn from any computer with no setup.
>- If your function has two arguments, tries the original and reversed 
>orderings (searching for [1 2 3] "," => "1, 2, 3" returns join, even 
> though 
>the args are backwards).
>- For each function, includes the docstring, namespace, the version it 
>was added, and whether or not it has been deprecated.
>- Links each function to clojuredocs.org
>
> Limitations/Issues:
>
>- Non-existent error handling (it just gets stuck on the "searching" 
>screen forever if any problem happens); this definitely needs to be fixed 
>soon.
>- It's slow.
>- Only searches different orderings if you have exactly two args. I 
>originally had it searching up to 5 permutations of your args, but it was 
>exceeding Heroku's 30-second timeout.
>- Doesn't support find-arg.
>- Only searches clojure.core, clojure.string, and clojure.set.
>- Not on github yet.
>
> Let me know if you run into any issues or have any cool ideas for this.
>
> (I emailed Anthony to make sure he was fine with me using the findfn name 
> and that the attribution was good enough)
>

-- 
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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback

[Meikel Brandmeyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am 30.12.12 07:14, schrieb Laurent PETIT:
>> `when` provides an implicit `do`, so I generally try to only use
>> it when I want side-effects. (Other side-effecty forms include
>> `do`, `doseq`, `dotimes` and `when-not`.)
> 
> On the other end, using when allows you to be explicit in your
> code that there's no "else" clause

And it's quite useful when working with sequences:

(when-let [s (seq coll)]
  (do-stuff-with s))

Meikel


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ4DRBAAoJEM2sO9pIirXjPioP/jpvmSpSBm7wlsNXTgTORTXG
JhOw0ri1CUlw3Gg/zuXFuIXZBsga2kjF7LNk1TyDc5whNlU6WwVYGiVjqL/lCI2i
j372h63/pzKfw6BSnLr9pOcRM+hu70JrvDTdk+qddJlQ68v/Uex2QvxwfGQlwDc2
ogGE2xglqzSRKWJ3g3AB5ctFhbNGn6nRNcoxvSmUOL+2KkVDn5mjP/zMsG3V/anC
9yJDZf+qJk8kWzBB0YPJIAnqgmzyWFfzsqlgiafpxWG5R+Xu9+JEDFmumPgBz2jr
MLZHRSaimffiXIgW6mudLy88qoRn94tUrR9GZx/Nwx//IqqoBQn6FO+R+63BKDNK
x1oR42iG87SjQM9a6h20R+VnhD7efV2/WqZC/0ZYBW5SHh1iU9Gzip1XwrPJvi8E
8WJgEPXlj3jnyEq7PHuRsQvznPuSmULqzgtAUdl3XbkxcWvJDbCupZKChzsABu8I
JG0xVlokLhDn0lqnq74URV8tTe2P5096jgLQ6jiA940o+EUwozTn2nv+tmCN+pe8
LQF4VvCw07aizInR+qaAM1LOBMLjbA5Vjqi2b0rHwCVrGOl2tAqAAZNL610zb3Tz
nwTG1ycs8MO+eOxCWPs677jB4QesfilaQASZ50u8ZV0pRlnhDol5rH102N1pSClg
lFh4F7RhSLIDhKgZymCR
=DUpD
-END PGP SIGNATURE-

-- 
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: What would you use a #[] data literal for?

[Jozef Wagner]

I use it in Clojurescript for a custom tuple type. 

For small number of items, deftypes are way faster to create and access 
than PersistentVectors. I use tuple type e.g. for returning multiple values 
from a function. Implementing #[] allowed me to have a compact syntax for 
creating and destructuring such tuples.

(defn foo [a b] 
  #[(+ a b) (- a b) (* a b)])

(defn foo []
  (let [#[plus minus times] (foo 1 2)]
(str "bla bla" plus "blaah" minus)))

JW

On Friday, December 28, 2012 11:15:52 PM UTC+1, vemv wrote:
>
> I was just wondering - given that we have the #() and #{} literals, why 
> not a #[] as well? Queues look like a good fit.
>

-- 
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