Re: meta-questions - [clojure] in front of Subject line

[Alex Baranosky]

The [clj] option is not a bad compromise.

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

[Raju Bitter]

+1

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

Re: Converting String to Hashmap

[David Powell]

On Mon, Jun 18, 2012 at 4:18 PM, Antix wrote:

> Hi Guys,
> I'm very new to clojure and searching for a way to convert a given
> String to a Hashmap as far as this is possible.
> I thought already about the use of a macro, but all the different
> quotes are a little bit confusing for me.
>
> Is it possible to create a Hashmap or some similar structure by using
> a given String.
>
> My Input-String is something like: :Name "John", :age 20, :gender
> "n"
> Is it possible to convert this to a hashmap similar to this:
> (def hashm {:Name "John", :age 20, :gender "n"  }) ?
>

Use the built in read-string function.:
(read-string (str "{" s "}")))

Don't use eval or load-string.  read-string is safer, faster, and won't hit
JVM size limits.

Also, if the input isn't trusted, you should bind *read-eval* to false, to
avoid being subject to running hostile user-supplied code:

(defn parse-map
  [s]
  (binding [*read-eval* false]
(read-string (str "{" s "}"

-- 
Dave

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

memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

Ok we've established that accessing records fields is much faster than 
using regular maps...what will happen though if we create a memoized fn 
that simply returns the map? will records still be faster? also if some 
of they keys in the map point to other functions do they need to be 
memoized as well?


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

This is really impressive!!! From 61ms it went down to 0.8ms !!! doing 
this is way faster than records I think...and since the fn I memoized 
takes no args it can't be cached more than  once yes?


Jim

ps: my second question can be considered reduntant...I meant to say that 
some of the keys in the map point to function calls (they don't return 
functions) so they can't be memoized...by the time the map is returned 
everything inside is a value...


On 19/06/12 12:46, Jim - FooBar(); wrote:
Ok we've established that accessing records fields is much faster than 
using regular maps...what will happen though if we create a memoized 
fn that simply returns the map? will records still be faster? also if 
some of they keys in the map point to other functions do they need to 
be memoized as well?


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

Is there a catch to this that I'm not seeing? It seems to work just 
fine...after all the fn always returns the same thing (which always has 
the same values in)...


Jim


On 19/06/12 12:57, Jim - FooBar(); wrote:
This is really impressive!!! From 61ms it went down to 0.8ms !!! doing 
this is way faster than records I think...and since the fn I memoized 
takes no args it can't be cached more than  once yes?


Jim

ps: my second question can be considered reduntant...I meant to say 
that some of the keys in the map point to function calls (they don't 
return functions) so they can't be memoized...by the time the map is 
returned everything inside is a value...


On 19/06/12 12:46, Jim - FooBar(); wrote:
Ok we've established that accessing records fields is much faster 
than using regular maps...what will happen though if we create a 
memoized fn that simply returns the map? will records still be 
faster? also if some of they keys in the map point to other functions 
do they need to be memoized as well?


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: memoization of an no-arg fn that returns a map?makes sense?

[Moritz Ulrich]

Where is the sense in memoizing a function with no arguments? It must
be free of side effects, or memoize would break. And if it's free of
side effects, why not just (def mymap {...}) ?

On Tue, Jun 19, 2012 at 2:03 PM, Jim - FooBar();  wrote:
> Is there a catch to this that I'm not seeing? It seems to work just
> fine...after all the fn always returns the same thing (which always has the
> same values in)...
>
> Jim
>
>
>
> On 19/06/12 12:57, Jim - FooBar(); wrote:
>>
>> This is really impressive!!! From 61ms it went down to 0.8ms !!! doing
>> this is way faster than records I think...and since the fn I memoized takes
>> no args it can't be cached more than  once yes?
>>
>> Jim
>>
>> ps: my second question can be considered reduntant...I meant to say that
>> some of the keys in the map point to function calls (they don't return
>> functions) so they can't be memoized...by the time the map is returned
>> everything inside is a value...
>>
>> On 19/06/12 12:46, Jim - FooBar(); wrote:
>>>
>>> Ok we've established that accessing records fields is much faster than
>>> using regular maps...what will happen though if we create a memoized fn that
>>> simply returns the map? will records still be faster? also if some of they
>>> keys in the map point to other functions do they need to be memoized as
>>> well?
>>>
>>> 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



-- 
Moritz Ulrich

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Tassilo Horn]

"Jim - FooBar();"  writes:

> Ok we've established that accessing records fields is much faster than
> using regular maps...

Really?

> what will happen though if we create a memoized fn that simply returns
> the map?

Well, if you memoize a fn of no args, it'll always return the same
value.  If that's really what you want, I'd rather use

  (def the-map (expr-calculating-the-map))

If it needs to be a function for some reason, then I'd use

  (def gimme-the-map (constantly (expr-calculating-the-map)))

But I don't think the above applies to your usecase.  Can it be that the
function constructs the returned map by inspecting the value of some
ref/atom or the current-phase-of-moon or so?  In that case, you can't
memoize the fn.  Example:

--8<---cut here---start->8---
user> (def gimme-random (let [r (java.util.Random.)]
 (fn [] (.nextInt r
#'user/gimme-random
user> (gimme-random)
696947893
user> (gimme-random)
-1591730151
user> (gimme-random)
459131481
user> (def memoized-gimme-random (memoize gimme-random))
#'user/memoized-gimme-random
user> (memoized-gimme-random)
-1840720068
user> (memoized-gimme-random)
-1840720068
user> (memoized-gimme-random)
-1840720068
--8<---cut here---end--->8---

Bye,
Tassilo

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 13:06, Tassilo Horn wrote:

Well, if you memoize a fn of no args, it'll always return the same
value.  If that's really what you want, I'd rather use

   (def the-map (expr-calculating-the-map))


It needs to be a fn because a couple of slots in the map call a specific 
fn that is not yet defined and I can't simply declare it so i get error 
"attempting to call unbound fn"... I also cannot rearrange the code cos 
the map is used all over the place - it needs to be at the top of the 
namespace...



If it needs to be a function for some reason, then I'd use

   (def gimme-the-map (constantly (expr-calculating-the-map)))
hmmm...when you say "(expr-calculating-the-map)" you mean the map 
literal {} or the fn I already have?how is that cheaper since i am 
calling the fn as brand new every time? is there some magic behind 
constantly?


to make things clearer here is the actual map...as i said i can't def it 
due to the call to 'starting-checkers' which needs the map to get the 
colors...so i either get a stack overflow error or a "attempting to call 
unbound fn"...


{:name 'checkers
   :players 2
   :colors (checkers-colors 'RED 'YELLOW)
   :characteristics [:color :position :rank :value]
   :board-size 32
   :total-pieces 24
   :rel-values {:soldier 1 :prince 3}
   :board-atom  current-checkers
   :record-name "Clondie24.checkers.CheckersPiece"
   :mappings   board-mappings-checkers
   :north-player-start  (starting-checkers true)
   :south-player-start  (starting-checkers false)}


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 13:06, Tassilo Horn wrote:

But I don't think the above applies to your usecase.  Can it be that the
function constructs the returned map by inspecting the value of some
ref/atom or the current-phase-of-moon or so?  In that case, you can't
memoize the fn.


yes actually a particular slot returns a var that holds an atom...do you 
mean that the same atom value will be returned forever even though the 
actual atom will have been swapped! or resetted! ?


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 13:27, Jim - FooBar(); wrote:

On 19/06/12 13:06, Tassilo Horn wrote:

But I don't think the above applies to your usecase.  Can it be that the
function constructs the returned map by inspecting the value of some
ref/atom or the current-phase-of-moon or so?  In that case, you can't
memoize the fn.


yes actually a particular slot returns a var that holds an atom...do 
you mean that the same atom value will be returned forever even though 
the actual atom will have been swapped! or resetted! ?


Jim


h I see what you mean...that specific atom slot indeed stops me from 
memoizing...all the rest return essentially constants... how about if 
wrap  current-checkers with a fn literal #(current-checkers) ?


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On the other hand I am not dereferencing the atom inside the map so i'm 
not 'inspecting it' as you said before...just returning the 
var...dereferencing happens elsewhere (when moving for example)...


Jim



On 19/06/12 13:31, Jim - FooBar(); wrote:

On 19/06/12 13:27, Jim - FooBar(); wrote:

On 19/06/12 13:06, Tassilo Horn wrote:
But I don't think the above applies to your usecase.  Can it be that 
the

function constructs the returned map by inspecting the value of some
ref/atom or the current-phase-of-moon or so?  In that case, you can't
memoize the fn.


yes actually a particular slot returns a var that holds an atom...do 
you mean that the same atom value will be returned forever even 
though the actual atom will have been swapped! or resetted! ?


Jim


h I see what you mean...that specific atom slot indeed stops me 
from memoizing...all the rest return essentially constants... how 
about if wrap  current-checkers with a fn literal #(current-checkers) ?


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: meta-questions - [clojure] in front of Subject line

[Aaron Cohen]

In gmail:
 1) click the down arrow next to "clojure" in the subject line (it has
a "Show details" tooltip).
 2) click the "filter messages from this mailing list" link next to
the mailing list
 3) This will automatically create a filter on words:
list:""
 4) Proceed to the next option "Create a filter matching this search"
 5) Apply a label, "Clojure" for instance
 6) Optionally, skip the inbox

The label in your inbox provides the exact visual indication you are
asking, without altering the subject line. In IMAP, it creates a
folder containing only those messages.

--Aaron

On Mon, Jun 18, 2012 at 11:46 PM, Andy Coolware  wrote:
> Hi,
>
> thx a lot for all  viewpoints. I am personally a bit torn. On one
> hand, when I open my gmail I have hard time to distinguish between all
> groups I am subscribed too. When you get tens of threads updated
> daily, this is really handy. However, I hate to have a redundant
> information in Subject and headers as it was pointed out. And even if
> that prefix is added,  the solution is not perfect since all my
> original posts are missing prefix too.
>
> Managing subfolders is out a question for me since I use multiple
> clients over IMAP. That would be a mess. I wish Thunderbird and gmail
> have an option to split the traffic by group in some automated fashion
> ...
>
> Cheers,
> Andy
>
> --
> 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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

For my use-case both memoize and constantly have the same effect with 
memoize being slightly faster [1]...since the atom is not being 
dereferenced in the map all is good! new states are being updated and 
logged just fine...


Jim


[1] --> without anything a move takes roughly 50-70 ms
 --> with memoization it takes roughly 0.8 -1.2 ms
--> with constantly it takes roughly 3 - 5 ms

On 19/06/12 13:37, Jim - FooBar(); wrote:
On the other hand I am not dereferencing the atom inside the map so 
i'm not 'inspecting it' as you said before...just returning the 
var...dereferencing happens elsewhere (when moving for example)...


Jim



On 19/06/12 13:31, Jim - FooBar(); wrote:

On 19/06/12 13:27, Jim - FooBar(); wrote:

On 19/06/12 13:06, Tassilo Horn wrote:
But I don't think the above applies to your usecase.  Can it be 
that the

function constructs the returned map by inspecting the value of some
ref/atom or the current-phase-of-moon or so?  In that case, you can't
memoize the fn.


yes actually a particular slot returns a var that holds an atom...do 
you mean that the same atom value will be returned forever even 
though the actual atom will have been swapped! or resetted! ?


Jim


h I see what you mean...that specific atom slot indeed stops me 
from memoizing...all the rest return essentially constants... how 
about if wrap  current-checkers with a fn literal #(current-checkers) ?


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

reloading protocols causes problems

[Jeff Rose]

Hi,
  I'm wondering if people might have advice on how to deal with the issue 
of reloading protocol definitions.  Currently in Overtone things break when 
we reload some namespaces because once a defprotocol form is re-evaluated 
the existing types that implement that protocol are no longer valid because 
they refer to the old protocol, even when it hasn't changed.  Our current 
fix is to wrap all protocols in a defonce form, but this isn't the 
prettiest solution ever.  Is it crazy to imagine that protocols could 
remain the same after a reload unless they have changed, so that this 
problem would only be caused by actually changing a protocol rather than 
just re-evaluating a defprotocol form?  I don't know enough about the 
underlying machinery in terms of java class types and compilation to know 
if this is a reasonable thing to do.  Otherwise, maybe there is another way 
to handle the issue?

Thanks,
Jeff

-- 
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 (Slim 1.4.0) and Azul don't like each other

[Edward Yang]

Hello!

Thanks for the speedy turnaround! It looks like this fix clears up the issue.

Thanks a lot,
Edward


From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Gil Tene 
[g...@azulsystems.com]
Sent: Friday, June 15, 2012 12:32 AM
To: clojure@googlegroups.com
Subject: Re: Clojure (Slim 1.4.0) and Azul don't like each other

We've tracked down the problem, and it turns out to be a semantic issue around 
forced vs. hinted initialization (or initialization avoidance) on explicit 
class loading. It appears that Clojure makes multiple Class.forName() calls on 
the same class, with the first call intended to avoid static initialization, 
and the subsequent calls forcing initialization. We believe the issue may be 
with a difference between the Zing and OpenJDK HotSpot implementations of the 
spec for these calls.

We've created and quickly tested a replacement implementation of 
Class.forName() that mirrors OpenJDK HotSpot's exact behavior, and it seems to 
resolve the Clojure startup issues in our simple test. We'll include this 
change in a coming dot release for Zing, but in the meantime, we prepared an 
override jar file that can be placed in the booth class path to test the 
behavior. I'll get that to you via e-mail.

Please test it and let us know if it resolves your issue.

-- Gil.

On Wednesday, June 13, 2012 9:26:37 AM UTC-7, Edward Z. Yang wrote:
We've been attempting to run Clojure in Azul, and not having particularly good 
luck. We got around the problem described here 
(http://www.mail-archive.com/clojure@googlegroups.com/msg17276.html) by 
switching to slim, but now we are getting this exception:

ExceptionInInitializerError: Compiler$CompilerException: 
java.lang.NoSuchFieldException: close, compiling:(clojure/core.clj:6139)

Any advice?

Cheers,
Edward

--
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: reloading protocols causes problems

[Phil Hagelberg]

Protocols necessarily make some unfortunate dynamicity trade-offs in the
name of self-hosting. If you value interactive development over execution
efficiency perhaps they are not the right choice.

-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

Re: reloading protocols causes problems

[David Nolen]

On Tue, Jun 19, 2012 at 10:49 AM, Phil Hagelberg  wrote:

> Protocols necessarily make some unfortunate dynamicity trade-offs in the
> name of self-hosting. If you value interactive development over execution
> efficiency perhaps they are not the right choice.
>
> -Phil
>
Depending on what Clojure implementation you are using of course.
ClojureScript doesn't have this problem ;)

Given my understanding of how protocols are currently implemented on
Clojure JVM (partially backed by very static Java interfaces), I don't
think you can achieve what you want. Perhaps JVM invokedynamic can help one
day?

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: reloading protocols causes problems

[Sam Aaron]

It seems that guarding the protocol declarations inside of a defonce does the 
job nicely, although it is a big fugly. It's not too bad a trade-off though, 
because we rarely, if ever, want to change a protocol definition live. My main 
concern is that it wasn't obvious what was breaking Overtone during reloads, 
and it took some real trial and error discovery to figure that it was the 
protocol declarations. Perhaps Phil is right, and they're not the best choice 
for the job - perhaps multimethods might be a better fit for our needs.

I think that at least the documentation could be improved to warn people that 
defprotocol and namespace reloading don't play well together. This thread will 
already act as a start in this area :-)

David, it's cool that ClojureScript doesn't suffer from this issue though!

Sam

---
http://sam.aaron.name


On 19 Jun 2012, at 16:35, David Nolen wrote:

> On Tue, Jun 19, 2012 at 10:49 AM, Phil Hagelberg  wrote:
> Protocols necessarily make some unfortunate dynamicity trade-offs in the name 
> of self-hosting. If you value interactive development over execution 
> efficiency perhaps they are not the right choice.
> 
> -Phil
> 
> Depending on what Clojure implementation you are using of course. 
> ClojureScript doesn't have this problem ;)
> 
> Given my understanding of how protocols are currently implemented on Clojure 
> JVM (partially backed by very static Java interfaces), I don't think you can 
> achieve what you want. Perhaps JVM invokedynamic can help one day?
> 
> 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

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Ambrose Bonnaire-Sergeant]

On Tue, Jun 19, 2012 at 8:20 PM, Jim - FooBar(); wrote:

> On 19/06/12 13:06, Tassilo Horn wrote:
>
>> Well, if you memoize a fn of no args, it'll always return the same
>> value.  If that's really what you want, I'd rather use
>>
>>   (def the-map (expr-calculating-the-map))
>>
>
> It needs to be a fn because a couple of slots in the map call a specific
> fn that is not yet defined and I can't simply declare it so i get error
> "attempting to call unbound fn"... I also cannot rearrange the code cos the
> map is used all over the place - it needs to be at the top of the
> namespace...


Could you (declare the-map) and then define it after the last dependency is
defined?

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: reloading protocols causes problems

[David Nolen]

On Tue, Jun 19, 2012 at 12:14 PM, Sam Aaron  wrote:

> It seems that guarding the protocol declarations inside of a defonce does
> the job nicely, although it is a big fugly. It's not too bad a trade-off
> though, because we rarely, if ever, want to change a protocol definition
> live. My main concern is that it wasn't obvious what was breaking Overtone
> during reloads, and it took some real trial and error discovery to figure
> that it was the protocol declarations. Perhaps Phil is right, and they're
> not the best choice for the job - perhaps multimethods might be a better
> fit for our needs.
>
> I think that at least the documentation could be improved to warn people
> that defprotocol and namespace reloading don't play well together. This
> thread will already act as a start in this area :-)
>
> David, it's cool that ClojureScript doesn't suffer from this issue though!
>
> Sam
>
> ---
> http://sam.aaron.name


Looking forward to an Overtone API over WebAudio (
http://chromium.googlecode.com/svn/trunk/samples/audio/index.html) :)

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: memoization of an no-arg fn that returns a map?makes sense?

[Mark Engelberg]

I think what you really want to do is use "delay" on specific fields.  This
way, you don't need to make a function that builds the map every time, you
just define the map, replacing, for example, the :north-player-start line
with the following:

:north-player-start  (delay (starting-checkers true))

And then, instead of:
(:north-player-start my-map), do
@(:north-player-start my-map) to access that field.

This effectively memoizes the specific field that needs it, rather than the
whole map.

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

Hmmm, I hadn't thought of delay...The only problem with what you suggest 
is the fact that some fields will have to be deref-ed and some 
don't...this slightly obscures what the map represents in my case...the 
map represents a game along with all its predefined characteristics...if 
I have to deref some it seems as if there is more going on than what it 
actually is...constantly or memoize work great in my case because the 
map holds essentially constants...ok the atom is not a constant but it 
works just fine (provided that it will be deref-ed  outside the map)...


Jim

ps:the original idea was to make the map a record so i could leverage 
better access times (60 ms for a single move is not acceptable)...you 
see that map is passed around literally everywhere in the core namespace 
(depending on the game, the core engine will act differently)...In other 
words the functions in core are generic - they don't apply to a specific 
game but to any game for which you can supply a similar map...



On 19/06/12 18:32, Mark Engelberg wrote:
I think what you really want to do is use "delay" on specific fields.  
This way, you don't need to make a function that builds the map every 
time, you just define the map, replacing, for example, the 
:north-player-start line with the following:


:north-player-start  (delay (starting-checkers true))

And then, instead of:
(:north-player-start my-map), do
@(:north-player-start my-map) to access that field.

This effectively memoizes the specific field that needs it, rather 
than the whole map.

--
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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 18:32, Mark Engelberg wrote:
This effectively memoizes the specific field that needs it, rather 
than the whole map. 


but I need the whole map 'memoized' cos it's being passed to almost all  
fns in the core namespace. Since I know in advance that its values are 
constants, I certainly don't want to construct it from scratch every time...


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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

No no I tried that...the map has to be one of the first things in the 
namespace. 2 of its keys call a specific fn that itself expects the map 
as argument. everything I tried will either return 'stack overflow' (if 
I try to def/declare) or a 'attempting to call unbound fn' (If i 
defn/declare)...the only way is to have defn in both places...


Jim

On 19/06/12 13:30, Ambrose Bonnaire-Sergeant wrote:
On Tue, Jun 19, 2012 at 8:20 PM, Jim - FooBar(); > wrote:


On 19/06/12 13:06, Tassilo Horn wrote:

Well, if you memoize a fn of no args, it'll always return the same
value.  If that's really what you want, I'd rather use

  (def the-map (expr-calculating-the-map))


It needs to be a fn because a couple of slots in the map call a
specific fn that is not yet defined and I can't simply declare it
so i get error "attempting to call unbound fn"... I also cannot
rearrange the code cos the map is used all over the place - it
needs to be at the top of the namespace...


Could you (declare the-map) and then define it after the last 
dependency is defined?


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 


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

Standard alias for partial?

[JvJ]

This is not really a big deal, but I was wondering if there was a shorter 
alias for partial in the standard library.  It seems like one of those 
things that should require a single-character operator.

I usually do something like this :

(def $ partial)

I wonder if something like that could be integrated into the library...

-- 
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: Standard alias for partial?

[Jim - FooBar();]

what if you need the '$' for interop?

Jim

On 19/06/12 19:25, JvJ wrote:
This is not really a big deal, but I was wondering if there was a 
shorter alias for partial in the standard library.  It seems like one 
of those things that should require a single-character operator.


I usually do something like this :

(def $ partial)

I wonder if something like that could be integrated into the library...
--
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: Standard alias for partial?

[Jay Fields]

I use %, (def % partial)

On Tue, Jun 19, 2012 at 2:28 PM, Jim - FooBar();  wrote:
> what if you need the '$' for interop?
>
> Jim
>
>
> On 19/06/12 19:25, JvJ wrote:
>>
>> This is not really a big deal, but I was wondering if there was a shorter
>> alias for partial in the standard library.  It seems like one of those
>> things that should require a single-character operator.
>>
>> I usually do something like this :
>>
>> (def $ partial)
>>
>> I wonder if something like that could be integrated into the library...
>> --
>> 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: Standard alias for partial?

[Jim - FooBar();]

what? is it not a reserved character to denote args in function 
literals? I'm confused =-O !


Jim

On 19/06/12 19:29, Jay Fields wrote:

I use %, (def % partial)

On Tue, Jun 19, 2012 at 2:28 PM, Jim - FooBar();  wrote:

what if you need the '$' for interop?

Jim


On 19/06/12 19:25, JvJ wrote:

This is not really a big deal, but I was wondering if there was a shorter
alias for partial in the standard library.  It seems like one of those
things that should require a single-character operator.

I usually do something like this :

(def $ partial)

I wonder if something like that could be integrated into the library...
--
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: Standard alias for partial?

[Timothy Baldridge]

> I use %, (def % partial)

That works until you try to use the shorthand for anonymous functions:

(map #(inc %) [1 2 3]) ; what's this going to do?

Timothy

-- 
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: Standard alias for partial?

[Jim - FooBar();]

On 19/06/12 19:32, Timothy Baldridge wrote:

That works until you try to use the shorthand for anonymous functions:

(map #(inc %) [1 2 3]) ; what's this going to do?

Timothy


Thank you! :-)

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: Standard alias for partial?

[Jay Fields]

uh, it's going to do what you expect...

user=>  (def % partial)
#'user/%
user=> (map #(inc %) [1 2 3])
(2 3 4)


On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar();  wrote:
> On 19/06/12 19:32, Timothy Baldridge wrote:
>>
>> That works until you try to use the shorthand for anonymous functions:
>>
>> (map #(inc %) [1 2 3]) ; what's this going to do?
>>
>> Timothy
>
>
> Thank you! :-)
>
> 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

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 19:06, Jim - FooBar(); wrote:
No no I tried that...the map has to be one of the first things in the 
namespace. 2 of its keys call a specific fn that itself expects the 
map as argument. everything I tried will either return 'stack 
overflow' (if I try to def/declare) or a 'attempting to call unbound 
fn' (If i defn/declare)...the only way is to have defn in both places...


I apologise for this last statement...it is simply not true...the way I 
described it, it should alway fall into an infinite recursion causing a 
stack overflowthe fns that are called from within the map DO NOT 
expect that same map as argument! which ultimately means I can just def 
the mapsorry for any confusion...I'll be more careful!


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: Standard alias for partial?

[Timothy Baldridge]

> uh, it's going to do what you expect...
>
> user=>  (def % partial)
> #'user/%
> user=> (map #(inc %) [1 2 3])
> (2 3 4)

My point was that you have overloaded the meaning of the % symbol. If
someone says "what does % mean in clojure". You can say "it's
shorthand for the first argument in the shorthand version of the
anonymous function definition.", now you have to say "well it depends
on the scope"

Please, don't ever take reader macros and re-define them out of scope
to mean something else. It just confuses people and makes the code
harder to read.

Timothy

-- 
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: Standard alias for partial?

[Jay Fields]

I'd actually like to see %(...) become (partial ...), as I think
people associate % with anonymous functions. Which is why I chose (%
...), as it's close to what I wish we had.

I get your point though, and I don't disagree. But, this does keep
coming up, so I think a shorter syntax for partial would be nice,
whether it's %(), #&() or whatever.

Cheers, Jay

On Tue, Jun 19, 2012 at 2:52 PM, Timothy Baldridge  wrote:
>> uh, it's going to do what you expect...
>>
>> user=>  (def % partial)
>> #'user/%
>> user=> (map #(inc %) [1 2 3])
>> (2 3 4)
>
> My point was that you have overloaded the meaning of the % symbol. If
> someone says "what does % mean in clojure". You can say "it's
> shorthand for the first argument in the shorthand version of the
> anonymous function definition.", now you have to say "well it depends
> on the scope"
>
> Please, don't ever take reader macros and re-define them out of scope
> to mean something else. It just confuses people and makes the code
> harder to read.
>
> Timothy
>
> --
> 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: memoization of an no-arg fn that returns a map?makes sense?

[Mark Engelberg]

On Tue, Jun 19, 2012 at 11:02 AM, Jim - FooBar(); wrote:

> On 19/06/12 18:32, Mark Engelberg wrote:
>
>> This effectively memoizes the specific field that needs it, rather than
>> the whole map.
>>
>
> but I need the whole map 'memoized' cos it's being passed to almost all
>  fns in the core namespace. Since I know in advance that its values are
> constants, I certainly don't want to construct it from scratch every time...
>

If you def the map, it won't be constructed from scratch every time.

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Jim - FooBar();]

On 19/06/12 22:42, Mark Engelberg wrote:

If you def the map, it won't be constructed from scratch every time.


yes that is what i ended up doing...there was some confusion about 
infinite recursion but i had forgotten i had fixed that already! I do 
need to take breaks...the whole question as I phrased it originally did 
not make complete sense...


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: meta-questions - [clojure] in front of Subject line

[Andy Coolware]

So I followed the steps and it did not work:


>  3) This will automatically create a filter on words:
> list:""

however after changing filter to >>Matches:
to:(clojure.googlegroups.com) Do this: Apply label "clojure"<< all
seems to be just fine and I am a happy camper ...

Thank you,
Andy

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Meikel Brandmeyer (kotarak)]

Hi,

maybe lazymap might help you:

https://clojars.org/de.kotka/lazymap
http://bitbucket.org/kotarak/lazymap

Kind regards
Meikel

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