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
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
--
Yo
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
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 names
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 wou
> 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 sho
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
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:
>>
>>
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 po
> 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
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:
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 se
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 someth
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 i
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)...
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 certain
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 dere
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))
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 conc
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
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 d
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
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.
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@goog
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
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
-->
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 fil
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
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
mem
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 sl
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
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 seem
"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 t
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
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 t
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
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
+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
cl
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 unsubs
39 matches
Mail list logo
