HI, I'm looking for functionality like the "featurec" function, but I need
to be able to capture the unused keys.
Here is how "featurec" currently works:
(run* [q]
(== q {:a 1 :b 2})
(featurec q {:b 2})))
==> ({:a 1 :b 2})
However, I need to capture the keys th
This is also where I love destructuring to make the code structure more
clear:
(defn make-user-nice-name [{:keys [first_name last_name username]}]
(if (and first_name last_name)
(str first_name " " last_name)
username))
On Fri, Jan 4, 2013 at 11:26 PM, Sean Corfield wrote:
>
Seems to work just fine for me:
user> (defn make-user-nice-name [map-of-profile]
(let [user-nice-name
(if-not (or (nil? (:first_name map-of-profile)) (nil?
(:last_name map-of-profile)))
(apply str (:first_name map-of-profile) " " (:last_name
map-of-profile))
(:usernam
Seems to work for me:
user=> (make-user-nice-name { :username "bazookajoe"})
"bazookajoe"
user=> (make-user-nice-name {:first_name "Joe" :username "bazookajoe"})
"bazookajoe"
user=> (make-user-nice-name {:first_name "Joe" :last_name "Blow" :username
"bazookajoe"})
"Joe Blow"
user=> (make-user-nice
This function gives me a nicely formatted name if the user has supplied a
first_name or a last_name, however, if there is no first_name and no
last_name then I get nothing at all. But the username is there in the
record. Can someone tell me what I did wrong? Why is the username not
getting set
Post the arguments you used to start the jvm. All you probably need to do
is increase the Heap Space. If you are using the default jvm setting the
default heap space is really small. To increase the space use the
-Xmx(Size) flag.
Its using StringBuilder which is the best way to create large str
On Friday, January 4, 2013 3:37:49 AM UTC-5, Peter Taoussanis wrote:
>
> Just pushed 1.2.0 with `merge-config!` and dictionary merging (rather than
> resetting) on dev-mode changes.
I will update and give the code a try. Thanks for the fast turnaround!
As far as your first and last questions
On Jan 4, 2013 6:06 PM, "larry google groups"
wrote:
> (swap! recent-activity concat feed @recent-activity)
This swap! replaces the value in recent-activity with (concat
@recent-activity feed @recent-activity), approximately.
--
Stephen Compall
If anyone in the MSA is online, you sho
I am still somewhat new to Clojure and the JVM. I am querying a database
and trying to output some XML. For the XML, I am using this library:
https://github.com/clojure/data.xml
Apparently the database queries worked, and I was able to get the data into
an XML structure, but at some point the
On Fri, Jan 4, 2013 at 2:35 PM, Michał Marczyk wrote:
> Note that if-let -- as it currently stands, I mean -- doesn't make the
> binding available to the "else" branch (so there's no way of telling
> if the init expression turned out to be false or nil). The above would
> be a natural extension of
On Fri, Jan 4, 2013 at 11:59 AM, Marko Topolnik wrote:
> I do this regurarly:
>
> (-> x (fun1 arg1) (#(fun2 arg2 %)) ...)
>
> It works, but I still don't like it, I find that extra hash and parens
> distasteful.
>
>
Thanks for that idea. Don't know why I never thought to do that.
--
You receive
On 4 January 2013 21:45, Anthony Grimes wrote:
> Really? I didn't read the thread, but I wouldn't expect that behavior at
> all. How would you know which bindings to use given the short circuiting?
> Unless it would bind the short circuited bindings to nil, which also seems
> weird. I would absolu
Hey,
I replied in the ticket with some comments. The main issue I see is
that I'm used to the notion that IPersistentLists are things which are
not lazy and which have next/rest parts which are themselves IPLs and
this approach seems to cause that no longer to be the case. If it were
not to be the
On Friday, January 4, 2013 1:35:45 PM UTC-6, puzzler wrote:
> On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech
> > wrote:
>
>> Thanks Dave! Seems like different people expect slightly different
>> behavior.
>
>
> Are we reading the same thread? When I looked at it, it seemed that there
> was actua
That most likely is due to NUnit not being installed in lib/ properly.
--
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 wit
dmiller writes:
> Are you using ClojureCLR 1.4.x or 1.5RC1 (current master)?
Current master, I cloned the repo.
> If you are running into this problem with 1.5RC1 under Mono 3, let me know.
> This would
> be anomalous. (but the step above should make it work)
It does. I removed the con
I found CLJ-1060 [1] and added there a patch with Cons implementing
IPersistentList and (apply list args) in one-argument case of list*.
Marek
[1] http://dev.clojure.org/jira/browse/CLJ-1060
On Wednesday, December 26, 2012 9:35:25 PM UTC+1, Marek Šrank wrote:
>
> function list* doesn't return
On Friday, January 4, 2013 8:35:45 PM UTC+1, puzzler wrote:
>
> On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech
> > wrote:
>
>> Thanks Dave! Seems like different people expect slightly different
>> behavior.
>
>
> +1, I agree with points both on threading macros and on redundant
indentation due t
ok...It turns out I can answer my own question!a blog post by Brian
Carper [1] cleared it out for me...I am looking for a *custom literal* -
not a tagged literal and for that one has to patch the reader which I'm
sure is *not* a good idea! anyway it seems I 've misunderstood certain
things
On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech wrote:
> Thanks Dave! Seems like different people expect slightly different
> behavior.
Are we reading the same thread? When I looked at it, it seemed that there
was actually very broad consensus about the desirability of multiple
bindings in when-l
Greetings and all best wishes for 2013 to everyone!!! :-)
First of all, forgive me for hijacking this thread but I what I started
to do originated from this thread and so I feel it is related.
So, for the fun (and the learning) of it, I thought to create a queue
literal myself as suggested in
Hi,
I've reworked my tuple type into an ArrayVector type. Instead of using #[]
reader macro, ArrayVector replaces PersistentVector for small vectors and
falls back to PersistentVector as it grows. Fast destructuring is achieved
with ^ArrayVector hint.
See http://dev.clojure.org/jira/browse/CLJ
It could be a good idea to post the video and the slides also in some
different platform (YouTube/Vimeo for the video and something else for the
slides google doc, dropbox) just to avoid what happened with blip.tv...
It may be a even better idea to get all the video material and put all
togethe
On Fri, Jan 04, 2013 at 08:58:40AM +0100, Tassilo Horn wrote:
At least in my experience, it usually matters a lot which form actually
evaluated to nil. But it's easy to write a macro `if-let-all' or so,
which would expand into
(let [x 1 y nil z 3]
(if (and x y z)
(+ x y z)
0))
i
On Thu, Jan 03, 2013 at 11:14:30PM -0800, Evan Mezeske wrote:
Wouldn't it be more accurately named "if-and-let" if it supported that? E.g.
(if (and x y z) ...).
I can see regular if-let being useful with more than one form, just
using the last value for the conditional.
(if-let [a expr, b
Thanks Dave! Seems like different people expect slightly different behavior.
On Friday, January 4, 2013 9:34:38 PM UTC+6, daveray wrote:
>
> I don't know if it will answer your history question, but there was a
> fairly long discussion about this last year:
>
>
> https://groups.google.com/for
I don't know if it will answer your history question, but there was a
fairly long discussion about this last year:
https://groups.google.com/forum/?fromgroups=#!searchin/clojure/let-else/clojure/1g5dEvIvGYY/EWjwFGnS-rYJ
Cheers,
Dave
On Fri, Jan 4, 2013 at 7:23 AM, Edward Tsech wrote:
> Sorr
Sorry guys, I forget to mention that it should behave like "let" in Clojure
or like "let*" in Scheme.
I mean e.g.:
(if-let* [x 1 y nil z (inc y)]
(+ x y z)
0) ; => 0
;; (inc y) shouldn't be evaluated here.
Which means "and" doesn't work there.
In terms of implementation I mean smth like tha
Are you using ClojureCLR 1.4.x or 1.5RC1 (current master)?
1.4 was not set up for mono. 1.5RC1 is. In 1.5RC1, the csproj file for
Clojure.Compile.exe conditionalizes the PostBuildEvent for mono vs .net.
It works for me under Mono 2.x. I haven't tried it under Mono3.
If you are under Cloj
I don't know the history of the answer to "why", except perhaps as hinted by
Evan's answer, which is that it becomes implicit how to combine the results of
the multiple values to get the final true/false for the if condition. You
imply "and", which is a perfectly reasonable choice.
My main rea
One idea is to reserve #[] for a concept that supersedes macros.
For instance, we have yet to apply the concept of protocols to macros.
Another direction is recursive subexpansion, a la mathematica.
If you consider transformations between code and data, there are 4
possibilities:
data->data (thi
Alan Malloy writes:
> Certainly it does work the same way in JVM-Clojure:
>
> user=> (gensym)
> G__1278
> user=> (gensym)
> G__1281
> user=> (gensym)
> G__1284
> user=> (= 'G__1287 (gensym))
> true
>
> Whether that's a bug or a case of "If it breaks when you do that, then
> don't do it" isn't for
Tks for link. I'll work around it.
Leonardo Borges
www.leonardoborges.com
On Fri, Jan 4, 2013 at 12:24 PM, Stephen Compall
wrote:
> On Jan 3, 2013 6:24 AM, "Leonardo Borges"
> wrote:
>> As you can see, when using macroexpand-1, the type of the arg is
>> clojure.lang.PersistentList.
>>
>> Howe
Thanks for taking the trouble Alex - that was pretty comprehensive. I've
seen Rathore's and Nolen's (both excellent), skipped Stokke's (but only
because Catnip didn't interest me) and was looking forward to Barski (but
don't see him on the horizon though his talk was delivered a while back). I
Certainly it does work the same way in JVM-Clojure:
user=> (gensym)
G__1278
user=> (gensym)
G__1281
user=> (gensym)
G__1284
user=> (= 'G__1287 (gensym))
true
Whether that's a bug or a case of "If it breaks when you do that, then
don't do it" isn't for me to say, but I would be pretty surprised t
Just pushed 1.2.0 with `merge-config!` and dictionary merging (rather than
resetting) on dev-mode changes.
--
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
Hi Scott,
Happy to hear you're enjoying the library!
1. It seems useful to have the possibility for multiple
> libraries/namespaces to manage their own i18n complete with unique
> configurations (tower/config). I'm not in this situation right now but it
> seems like it could come up.
>
-
37 matches
Mail list logo
