I wonder why this can't become a language feature? Couldn't Clojure attach
the :source metadata directly to function objects (in addition to vars)? Is
there a JIRA ticket for it? I'd instant-vote for it because I know it would
make my debugging faster.
On Thursday, May 28, 2015 at 1:03:52 PM
May be you will be interested to see my toy library for prevalence in
Clojure - https://github.com/SergeyDidenko/Simple-Persistence-for-Clojure
On Sun, May 31, 2015 at 12:56 AM, Plínio Balduino pbaldu...@gmail.com
wrote:
Awesome, Klaus
Thank you
Plínio
On Sat, May 30, 2015 at 4:31 PM,
On 1 June 2015 at 00:42, Daniel doubleagen...@gmail.com wrote:
Criterium should probably be just a Dev dependency.
Okay. Fixed.
Thanks,
Alan
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Are these operations (*, +, etc) interoperable with core.matrix operations?
That may end up being pretty key for a lot of numerical users.
Chris
On Sunday, May 31, 2015 at 3:55:46 PM UTC-7, Alan Forrester wrote:
https://clojars.org/complex
https://github.com/alanforr/complex
Complex is
Hi,
Dunaj v0.5.0 has been released [1]. Dunaj lite, a library only version of
Dunaj, has been updated too [2].
Highlights of the new version
* Built on top of Clojure 1.7.0 RC1
* Changed semantics of qualified specials. The handling of special symbols
is now backwards compatible with Clojure
*
As far as I can tell, in that table isomorphic means that you can go both
from URL to route and from route to URL, whereas cljs means you can
use it from clojurescript in the browser.
I personally use bidi and its great. Because its just data, it means that
you can easily combine and compose
I recall seeing that from a while ago - weren’t they planning on rewriting
emacs effectively?
On 1 Jun 2015, at 15:55, Mikhail Malchevskiy malch...@gmail.com wrote:
https://github.com/syl20bnr/spacemacs =)
понедельник, 1 июня 2015 г., 17:05:35 UTC+3 пользователь Colin Yates написал:
Hi
On Jun 1, 2015, at 7:58 AM, nikolay.kudryavt...@gmail.com wrote:
This happens only when I use some kind of input stream(either
java.io.FileInputStream or io/input-stream wrapper). Just doing (parse-str
(slurp file)) works.
So, when I have a file containing only this:
https://github.com/syl20bnr/spacemacs =)
понедельник, 1 июня 2015 г., 17:05:35 UTC+3 пользователь Colin Yates
написал:
Hi Karsten,
Unfortunately our clients are primarily windows based and the software is
commercial. tmux - that takes me back! I have never forgotten the joy, or
found an
Great conversation starter.
Many of us had to take down that route. Eventually, we settle on a
deployment solution that works for us, and we can move on with dev'ing. I'm
sure all the answers are worthy. Please allow me to share my solution to
this problem. It may not work for everyone, but
For smaller deployments, so far I've always had a smooth ride using
nginx as reverse proxy and running the uberjar inside tmux. No other
special sauce needed, plus you get the benefit of using nginx to serve
your static assets (if there're not on a CDN already)...
On 1 June 2015 at 14:40, Colin
Hi Karsten,
Unfortunately our clients are primarily windows based and the software is
commercial. tmux - that takes me back! I have never forgotten the joy, or found
an equivalent on KDE, Gnome, Windows or OSX of a well configured xMonad, I
remember reaching for tmux as a substitute when
Thanks Daniel, I am trying to reduce the required installed software on the
client and they can’t access a maven repo from which to download unfortunately.
Hence I am looking for a ‘self contained executable’ solution.
You are yet-another-exclaimer of Boot; enough people have sung its praises
Hello.
I needed to parse and emit some xml, that has no namespaces and there
should be no extra whitespace that is added by clojure.xml.
Decided to try using clojure.data.xml. And for me it fails as soon as the
total size of an element reaches 33 symbols.
This happens only when I use some
this project is so cool. I've been playing around with noise and svg
thanks to it. Thanks Karsten!
--
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
How can I get prettier stacktraces? Would be great if it has colorized
output in the terminal (highlighting line line indicating my .clj source
code file).
I thought I'd try
[clj-stacktrace](https://github.com/mmcgrana/clj-stacktrace), and updated
my ~/.lein/profiles.clj as noted in the
I think this https://github.com/AvisoNovate/pretty is what you're looking
for.
--
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
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
Leiningen dependency information:
[org.clojure/clojurescript 0.0-3308]
This release bumps the Clojure dependecy to 1.7.0-RC1 and includes fixes
and minor
On Monday, June 1, 2015 at 2:31:46 PM UTC-4, nikolay.k...@gmail.com wrote:
I think this https://github.com/AvisoNovate/pretty is what you're
looking for.
Intriguing.
How can I get this to work automatically? I've got a project created via
`lein new app my-app`, and I want to see the pretty
I'd like my build and/or deployment process to suck in the output of `git
describe` for use as a build version in the app. What's the simplest way
to do that without writing a leiningen plugin?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Zach Tellman talks about exactly this in his conj talk from last
year https://www.youtube.com/watch?v=3oQTSP4FngY
He built a library around this that essentially gives the library user a
choice of either option: https://github.com/ztellman/manifold
On Monday, June 1, 2015 at 3:18:19 PM UTC-4,
On Monday, June 1, 2015 at 2:57:50 PM UTC-4, John Gabriele wrote:
On Monday, June 1, 2015 at 2:31:46 PM UTC-4, nikolay.k...@gmail.com wrote:
I think this https://github.com/AvisoNovate/pretty is what you're
looking for.
Intriguing.
How can I get this to work automatically? {snip}
Hm.
Greetings
I imagine most of us here would rather use core.async channels over
callbacks in their application code, particularly with more complicated
applications. But is it okay/preferable for Clojure libraries to force
their users to use core.async channels as part of an API (an event channel,
Hi Jonathon
Some combination of https://github.com/hyPiRion/lein-shell and
https://github.com/technomancy/leiningen/blob/master/doc/DEPLOY.md#releasing-simplified
may be what you need, though it depends how you want to use the results of
`git describe`.
On Tue, Jun 2, 2015 at 7:27 AM Jonathon
Does anyone know of a simple/minimal Clojure library, or just a chunk of
Clojure source code that I could cut/paste, that implements basic statistical
tests like t-tests and chi-squared tests? I don't want to use incanter but I'd
also rather not write this stuff from scratch.
Thanks,
-Lee
I'd like to add that core.async is quite a big thing, it has lots of parts
that could be implemented differently.
--
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
I would implement everything sticking to just callbacks, then create
separately requirable core.async version of API if that matters.
Ideally this should be a separate lib, but practically, it seems better to
just have a separate file.
понедельник, 1 июня 2015 г., 22:18:19 UTC+3 пользователь
I think this is one of those cases where the rules are different for
libraries than applications.
Does your lib need to pull in core.async, and does it need to be coupled to
a specific version? If it's a building block sort of lib that clojure and
the community prefers, I think the answer is no.
Thanks.
Clojure.data.xml is supposed to be lazy but there's an example in the
documentation https://github.com/clojure/data.xml that uses with-open:
(with-open [input (java.io.FileInputStream. /tmp/foo.xml)]
(parse input))
And I think I even remember that this used to work before.
Also,
Hi!
Personally I think that manifold has the same problem that core.async. So
if you are exposing your api using manifold you are forcing to someone to
use manifold. It is not bad, but is the same problem as with core.async.
And the same problem with callbacks. If you are using callbacks you are
First time caller.
Hildebrand is an asynchronous pure-Clojure (i.e. no Java AWS dependencies,
etc.) DynamoDB client written on top of httpkit. I've been developing it
for a while now, and have used it in production, but hadn't gotten around
to telling anyone about it.
That’s a fair point. Although, I think manifold does have going for it that
it’s designed to interoperate with the other abstractions we’re discussing, so
it shouldn’t be as binding as building your API around core.async would be.
On June 1, 2015 at 8:20:18 PM, Andrey Antukh (n...@niwi.nz)
As for the core.async, I think it is too personal and has too much raw
power, to be all that restricted in some logical bottleneck upon results
return from the third-party lib.
Not counting the fact it is a (a) dependency that (b) changes fast.
On Monday, June 1, 2015 at 10:18:19 PM UTC+3,
The problem with futures is that you can't attach callbacks to them, you
can only block a thread waiting on them. So futures interface quite poorly
with async libraries, hence the reason core.async was created in the first
place.
Core.async is a dependency, but it's hardly one that changes fast.
I think returning futures for asynchronous calls is a good tradition in
Clojure world.
Better than callbacks because you are leaving the threading model choice in
the hands of the caller, which is a good thing.
On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
Greetings
For people interested in using the 'futures' approach, this might be of
interest: https://github.com/leonardoborges/imminent
It's a library that implements composable futures for Clojure on top of
JVM's ForkJoin framework. It allows you to attach callbacks as well as
apply combinators such as
Why so? With a callback, someone should be waiting somewhere too, until
callback is fired.
Why not expose this choice to user. E.g. I am often waiting for the future
in the (thread ..) and returning the result to the channel,
but again, I like this to be my choice, because there are so much
One option would be to call R from Clojure. I haven't tried this, and I
don't know how well it would fit your needs.
Rincanter
http://joelboehland.com/posts/all-your-datasets-r-belong-to-us.html is
supposed to allow this. Presumably it would bypass the Incanter functions
that you don't
I'd say stick with callbacks simply because they're harder to mess up.
There's many different ways to interface with core.async. You can return a
channel, you can require a channel as an argument. You can spin up go
blocks that park, you can have pipelines, you can create a go block per
call to an
Thanks so much Marshall.
Adding -Djava.awt.headless=true to my :jvm-opts does indeed fix the
additional java process problem, so that's helpful if I don't find an
alternative to incanter.
The R options are interesting but probably not a good solution in my case; I'll
be calling these tests
40 matches
Mail list logo
