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.
- Is
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
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 to
Tks for link. I'll work around it.
Leonardo Borges
www.leonardoborges.com
On Fri, Jan 4, 2013 at 12:24 PM, Stephen Compall
stephen.comp...@gmail.com wrote:
On Jan 3, 2013 6:24 AM, Leonardo Borges leonardoborges...@gmail.com
wrote:
As you can see, when using macroexpand-1, the type of the
Alan Malloy a...@malloys.org 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
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
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 reason
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
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 that:
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
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:
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
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))
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
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
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
On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech edts...@gmail.com 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
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
On Friday, January 4, 2013 8:35:45 PM UTC+1, puzzler wrote:
On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech edt...@gmail.comjavascript:
wrote:
Thanks Dave! Seems like different people expect slightly different
behavior.
+1, I agree with points both on threading macros and on redundant
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 a
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
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 with
On Friday, January 4, 2013 1:35:45 PM UTC-6, puzzler wrote:
On Fri, Jan 4, 2013 at 9:02 AM, Edward Tsech edt...@gmail.comjavascript:
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
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
On 4 January 2013 21:45, Anthony Grimes disciplera...@gmail.com 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
On Fri, Jan 4, 2013 at 11:59 AM, Marko Topolnik marko.topol...@gmail.comwrote:
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.
On Fri, Jan 4, 2013 at 2:35 PM, Michał Marczyk michal.marc...@gmail.comwrote:
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
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 Jan 4, 2013 6:06 PM, larry google groups lawrencecloj...@gmail.com
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
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,
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
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
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-name {:first_name
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))
(:username
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
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 that a
36 matches
Mail list logo
