Congrats!
On Mon, Jan 21, 2013 at 3:07 AM, James Xu wrote:
> Thanks！
>
>
> On Sunday, January 20, 2013 1:00:19 PM UTC+8, Phil Hagelberg wrote:
>>
>>
>> Greetings fellow Clojure people.
>>
>> I've just pushed out the final release of Leiningen 2.0.0. The changes
>> since the last release candidate
On Sunday, 20 January 2013 21:43:16 UTC, Sean Corfield wrote:
> On Sun, Jan 20, 2013 at 3:27 AM, Simon Brooke
> >
> wrote:
> > So I'm looking around at what is the right stack to use to build a CRUD
> web
> > application in Compojure.
> >
> > I really like Enlive, with its very clear separa
On Sunday, 20 January 2013 14:55:07 UTC, Shantanu Kumar wrote:
> > I really like Enlive, with its very clear separation of logic and
> > presentation. Are there any other libraries I should be looking at at
> the
> > templating layer, or is Enlive currently the one to go for?
>
> Enlive and Hi
On Sunday, 20 January 2013 11:27:58 UTC, Simon Brooke wrote:
>
> I've finally cleared other projects from my desk far enough that I'm about
> to start trying to reimplement the CRUD part of http://sh.scenehere.info/ in
> Clojure. I've been meaning to do this for a long time, but paying projects
hi mimmo,
>>I have no time to experiment with the validation libs already available
on the server side ...
i did that lately and found https://github.com/leonardoborges/bouncer esp.
promising.
a note regarding hiccup: ch. grand has added hiccup-like functionality to
enlive during last week
s
Hi Fanny,
> a note regarding hiccup: ch. grand has added hiccup-like functionality to
> enlive during last week
> see
> https://github.com/cgrand/enlive/commit/cc42bce0e996a29e5592f8f8528264af9da7b763
great! I'll take a look
> thanks for your useful tutorial, fanny
you're welcomei'm tryi
Dear all,
the Software Developers Journal http://sdjournal.org/ is planning
a special issue on Clojure.
Hence we would be interested in Clojure Authors who would be willing to
write
a few pages on any Clojure topic. The following topics could be of interest:
* Introduction to Clojure
* The Cl
I use Clojure primarily as a very reliable tool to aid in data
transformations, that is taking data in one application's database and
transforming it into the format needed for another applications' database.
So, my question is would a natively compiled Clojure make sense or turn the
language i
On 21/01/13 01:24, AtKaaZ wrote:
yes, your code works if you don't use the "^:const", but why doesn't
it work with ^:const when you just use the return of mapv (something
with reify?)?
Well, I just came home and tried a couple of things out...It appears
that my code *doesn't* work if I don't
A great step forward for our ecosystem, thanks!
Nils
On Sunday, January 20, 2013 6:00:19 AM UTC+1, Phil Hagelberg wrote:
>
>
> Greetings fellow Clojure people.
>
> I've just pushed out the final release of Leiningen 2.0.0. The changes
> since the last release candidate have mostly been minor bu
(Thanks for the apology Brandon. For those confused, he was responding to a
private email I sent him that said: "I feel like you read my email until
you found something to nitpick, and then ignored the rest of it.")
On Sat, Jan 19, 2013 at 5:57 PM, Brandon Bloom wrote:
> > contributions to cloju
Thanks for all the comments!
On Sunday, January 20, 2013 10:49:55 PM UTC+1, Nelson Morris wrote:
>
> Have you seen friend and its interactive-form workflow?
> https://github.com/cemerick/friend/
>
I have seen it - but I could not understand how it works. Now that you
recommended it I tried a
Could you retry using this
-XX:-UseCompressedOops
jvm arg, or use a newer jre (I think it's some bug in the jvm)
I don't have time right now to test but I'll get back on it soon
On Mon, Jan 21, 2013 at 5:38 PM, Jim - FooBar(); wrote:
> On 21/01/13 01:24, AtKaaZ wrote:
>
> yes, your code works
On 21/01/13 16:47, AtKaaZ wrote:
Could you retry using this
-XX:-UseCompressedOops
surprisingly this worked! I don't get that error anymore... I used to
have it but i thought it was completely unnecessary...I don't understand
how this affects the runtime of my program!
Jim
--
You received
On 21/01/13 17:07, Jim - FooBar(); wrote:
On 21/01/13 16:47, AtKaaZ wrote:
Could you retry using this
-XX:-UseCompressedOops
surprisingly this worked! I don't get that error anymore... I used to
have it but i thought it was completely unnecessary...I don't
understand how this affects the ru
If you haven't found a performance problem, and it's working well for your
needs, why are you interested in making the code run "natively". What
problems have you encountered that pique your intrest in this area?
Timothy
On Mon, Jan 21, 2013 at 9:29 AM, octopusgrabbus wrote:
> I use Clojure p
I've had no problems. I am just curious.
What triggered this was this morning I saw something on stackoverflow.comabout
Clojure's possibly interacting with C code, and the natively compiled
question just popped into my head.
On Monday, January 21, 2013 12:19:27 PM UTC-5, tbc++ wrote:
>
> If yo
Very nice find! Thank you for that!
I'm thinking maybe it has something to do with lazy or delayed evaluation.
I don't really understand most clojure things but I imagine if the call to
mapv would not be evaluated right when the def is read but instead only
when the mappings-8x8 is first being use
> What triggered this was this morning I saw something on
> stackoverflow.comabout Clojure's possibly interacting with C code, and the
> natively compiled
> question just popped into my head.
Could Clojure-JNA help there, or is it some other use-case?
https://github.com/Chouser/clojure-jna
Shan
our happiness was short-lived...I still get the aformentioned jvm error
even with the latest jdk/jre and 'COMPRESSED-OPS' flag, when using
^:const. This is new - I don't remember having this a month ago...it is
definitely new and I'm thinking it's the rc1 version of clojure...
At the moment t
Just making sure, but when you say " and 'COMPRESSED-OPS' flag" you mean
disabling compressed-oops aka -XX:-UseCompressedOops (note the minus) or
the enabled(as is the default) compressed oops aka -XX:+UseCompressedOops
Does it happen even if you use eval ?
On Mon, Jan 21, 2013 at 7:19 PM, Jim -
yes yes I meant 'disabling compressed oops' sorry about that! Yes it
happens when I use eval as well. If i try to go to depth 6 at once it
will crash...if i try to go to level 4 then it might not the first time
but it will at some subsequent point...very strange! anyway I've removed
the ^:const
Kern is a text-parsing library based on Parsec, the Haskell monadic
combinators library. It is useful for parsing all kinds of text: data,
program input, configuration files, DSLs, or a full-blown programming
language.
My main goal is, like the Self folks, the power of simplicity. In the ideal
Have you looked also at Parsatron (another parsec-derived library)?
https://github.com/youngnh/parsatron
I wrote some combinators for parsatron for dealing with clojure datastructures:
https://github.com/bwo/macroparser
On Mon, Jan 21, 2013 at 10:27 AM, Armando Blancas wrote:
> Kern is a text-
Thanks. I took your link and posted it as a comment on stackoverflow.
On Monday, January 21, 2013 1:15:05 PM UTC-5, Shantanu Kumar wrote:
>
> > What triggered this was this morning I saw something on
> stackoverflow.comabout Clojure's possibly interacting with C code, and the
> natively compiled
you might want to look at clj-native:
https://github.com/bagucode/clj-native
It's used, among other things, by overtone to interact with
libscsynth, the supercollider synthesis library:
https://github.com/overtone/overtone/blob/master/src/overtone/sc/machinery/server/native.clj
I don't know how
I'm pretty sure clj-native is more recent, faster, better, and more
actively maintained. I ought to update clojure-jna to say all that.
On Mon, Jan 21, 2013 at 2:21 PM, Philip Potter wrote:
> you might want to look at clj-native:
>
> https://github.com/bagucode/clj-native
>
> It's used, among ot
It is also not longer actively mantained.
https://github.com/bagucode/clj-native/issues/6#issuecomment-11930841
2013/1/21 Chouser
> I'm pretty sure clj-native is more recent, faster, better, and more
> actively maintained. I ought to update clojure-jna to say all that.
>
>
> On Mon, Jan 21, 2013
That may be the case, but it still has an active community of users.
At worst, you'll still be able to get answers to questions by asking
here; at best, someone might be able to step up and fill the role.
I can definitely help with questions.
Phil
On 21 January 2013 19:27, Bronsa wrote:
> It is
I've actually taken a peek at just about every parsing lib that has been
mentioned in this board. I've learned plenty by reading other people's
code, and also looking at how they approached the subject.
On Monday, January 21, 2013 10:32:55 AM UTC-8, Ben wrote:
>
> Have you looked also at Parsatr
Michael, I would also love it if bugs got fixed in master more quickly. I've
done some things to try to make that happen, but for all I know I've only
exacerbated the issue. I'm still searching for ways to improve that.
One thing I know at the base of all such suggestions is: I am not going to
On Mon, Jan 21, 2013 at 12:09 PM, Armando Blancas wrote:
> I've actually taken a peek at just about every parsing lib that has been
> mentioned in this board. I've learned plenty by reading other people's code,
> and also looking at how they approached the subject.
Any plans to decouple the parsi
I'm updating a set of objects stored in a map, and I feel like the way I'm
doing it right now is inefficient. Is there a better way?
(defn update-all-objects
"Updates all game objects."
(reset! *game-objects*
(into {}
(for [[k v] @*game-objects*]
[
use reduce-kv on the original map to save some intermediate vector
allocation...something similar has come up recently...
(reduce-kv #(assoc % %2 (update-object %3)) {} @game-objects)
Jim
On 21/01/13 20:21, JvJ wrote:
I'm updating a set of objects stored in a map, and I feel like the way
I'm
...or you can go all the way, skipping reset! completely:
(swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object
%3)) {} objects) ))
Jim
ps: I've not tested this but i don't see why this approach wouldn't work...
On 21/01/13 20:24, Jim - FooBar(); wrote:
use reduce-kv on t
That's it! Thanks.
On Monday, 21 January 2013 15:28:39 UTC-5, Jim foo.bar wrote:
>
> ...or you can go all the way, skipping reset! completely:
>
> (swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object
> %3)) {} objects) ))
>
> Jim
>
> ps: I've not tested this but i don't se
also, i'm sure it's a typo, but the fn you originally posted is missing
its argument vector...it won't even compile like that...
Jim
On 21/01/13 20:33, JvJ wrote:
That's it! Thanks.
On Monday, 21 January 2013 15:28:39 UTC-5, Jim foo.bar wrote:
...or you can go all the way, skipping res
Yeah I cought that. Thanks, though.
On Monday, 21 January 2013 15:35:24 UTC-5, Jim foo.bar wrote:
>
> also, i'm sure it's a typo, but the fn you originally posted is missing
> its argument vector...it won't even compile like that...
>
> Jim
>
>
> On 21/01/13 20:33, JvJ wrote:
>
> That's it!
Something like this seems a bit cleaner:
(defn apply-values
"Applies f to every value in m and passes f zero or more args"
[m f & args]
(reduce (fn [accum [k v]]
(assoc accum k (apply f v args))
{}
m))
and then:
(swap! *game-objects* apply-values
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
And since you can't have enough ways to go to Rome…
(defn update-values
[m f & args]
(reduce #(update-in %1 [%2] f args) m (keys m)))
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oops. Add a apply in front of update-in.
Am 21.01.13 22:23, schrieb Meikel Brandmeyer:
> And since you can't have enough ways to go to Rome…
>
> (defn update-values [m f & args] (reduce #(update-in %1 [%2] f
> args) m (keys m)))
>
>
>
-BEGIN
>
> Any plans to decouple the parsing combinators (more importantly the
> error messages/position tracking) from parsing text? "A seqable
> object" as in the second argument to parse is not necessarily
> something for which lines and columns make sense.
>
>
Not yet. I've decided that first t
On Mon, Jan 21, 2013 at 2:05 PM, Armando Blancas wrote:
>
> Not yet. I've decided that first the library must get really good at parsing
> text. Once I have more experience writing and using this library, that'd be
> a good goal to have. But for now it's about text.
Fair enough, though it strikes
On Jan 21, 2013 3:28 PM, "Jim - FooBar();" wrote:
> ...or you can go all the way, skipping reset! completely:
>
> (swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object
%3)) {} objects) ))
Which also has the benefit of being safe, unlike any reset!-based update.
--
Stephen Comp
Has anyone checked out fressian, the binary serialization/deserialization
used by datomic?
https://github.com/Datomic/fressian
I want to use it for clojure data but I don't think the handler list is
complete at the moment. Anyone have more fleshed out handlers, such as
vectors? Currently they
>
> I see---also fair enough. How do you implement things like return (for
> monads) or mempty (for monoids) with protocols? I assume it's the
> perceived desirability of not having to pass in a parameter
> corresponding to some concrete monad/monoid/whatever to be able to get
> the right func
On Jan 21, 2013, at 12:20, Andy Fingerhut wrote:
> If one wanted *slightly* more editorial control of what appeared
> in those doc strings, they could publish a not-very-large file of
> "new improved doc strings" and make a macro like doc and cdoc that
> shows them. Or one could even redefine doc
On Jan 21, 2013, at 4:31 PM, Rich Morin wrote:
> On Jan 21, 2013, at 12:20, Andy Fingerhut wrote:
>> If one wanted *slightly* more editorial control of what appeared
>> in those doc strings, they could publish a not-very-large file of
>> "new improved doc strings" and make a macro like doc and cd
Thanks, all. Memoize appears to be exactly what I was looking for. Is
there no end to discovering eminently useful capabilities hidden away
some place in Clojure's API?
For the moment I don't see what Meikel Brandmeyer's lazymap gives me
that memoize doesn't, but I will look into it.
--Larr
On Jan 21, 2013, at 17:06, Andy Fingerhut wrote:
> Yes, we do have the technology, and have for years now. The technology
> isn't the hard part in this case. The only barrier to entry is the
> willingness and ability to spend time, more time, and yet more time ...
I've been interested in mechani
When I discussed this approach with my spouse, she noted that
keeping documentation with source code gets in the way of a
number of issues, including internationalization. When she
worked at Apple, they had extensive discussions about this.
-r
--
http://www.cfcl.com/rdmRich Morin
ht
The flip side, of course, is that having documentation separate from code
often leads to the documentation becoming out of sync with the code.
What happens when someone renames or moves some code, but doesn't also
move the docs? What happens if they change the implementation? Will people
remembe
Yes, those things can happen, but I think they can all be handled without big
troubles. Note that Rich Morin specifically mentioned using something like
codeq to notice when particular functions change, and thus their documentation
bears re-examining. diff also works, at a file granularity rat
On Jan 21, 2013, at 23:15, Korny Sietsma wrote:
> The flip side, of course, is that having documentation separate from
> code often leads to the documentation becoming out of sync with thecode.
>
> What happens when someone renames or moves some code, but doesn't also
> move the docs? What happe
How about
(swap! game-objects (fn [objects] (into {} (for [[k v] objects] [k (apply f
v args)])))
?
For large maps, it will use a transient map and assoc! instead of assoc,
that may result in a speedup.
Laszlo
2013/1/22 Stephen Compall
> On Jan 21, 2013 3:28 PM, "Jim - FooBar();" wrote:
> >
55 matches
Mail list logo
