Convex is an open, decentralised platform for the Internet of Value - you
can use it to create secure digital assets and implement applications
involving secure value exchange using smart contracts.
You can test it out with the live REPL, documentation and sandbox at our
developer site:
l language and
it has been awesome so far (see https://github.com/mikera/enchant). Thanks
for the great work!
On Tuesday, 18 July 2017 20:48:15 UTC+8, Chas Emerick wrote:
>
> Hi all,
>
> I've been approached many, many times over the years (and more frequently
> since the
e a performance performance benefit of
> checking for `ISeq` *and* `Seqable` that I'm not aware of?
>
> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:
>>
>> Clearly not necessary from a functional perspective.
>>
>> However I believe the ordering of these t
Clearly not necessary from a functional perspective.
However I believe the ordering of these tests will affect JVM
optimisations. You want to test the common/fast cases first. And the JVM
does some clever things with caching most recently used lookups, which will
again behave differently if
Looks cool! I'm going to mine this for ideas and potentially use it. FWIW
I've also been implementing some Java functional data structures for my
language design experiments.
If anyone is interested happy to share code, my own motivations were:
- I wanted decent persistent Lists, Sets, Maps
Filtering and sorting each partition is going to be pretty expensive! If
the list is long you will be discarding most of the results anyway.
I found a recursive way to do this that is fairly efficient, by observing
that you either want to join two adjacent elements together in a partition
or
You might want to try implementing a small wrapper class that implements
ILookup.
Then you can do something like:
(:keyword (MyWrapper. my-obj))
Prefer composition over inheritance, etc.
On Wednesday, 1 March 2017 04:12:06 UTC+8, Ernesto Garcia wrote:
>
> Hi all,
>
> I am using Java class
On Tuesday, 6 December 2016 10:47:42 UTC+8, James Reeves wrote:
>
> On 6 December 2016 at 01:28, wrote:
>>
>> And the error messages are not good.
>>
>> So I was wondering: Is this a philosophical thing? Or is it an effort
>> thing? And if it is an effort thing, is there some
Given recent events, I advise caution when it comes to relying on votes to
make important decisions.
On Tuesday, 8 November 2016 23:33:43 UTC+8, Alex Miller wrote:
>
> In the spirit of the US election today, I thought I would mention voting
> on Clojure tickets. Clojure manages bugs and
In my moments of insanity / hammock time I've toyed with making a typed
variant of Clojure. Somewhat inspired by core.typed, but I feel that to be
effective a type system needs to be deeply integrated with the compiler and
standard library, not just a standalone tool.
Types would themselves be
On Thursday, 27 October 2016 22:56:42 UTC+8, JHacks wrote:
>
> I have some confusion about how the function `comp` works, especially as
> compared to the threading macro `->>`.
>
> From the book *Clojure Programming* (pages 70-71 of Chapter 2: Functional
> Programming), the following two functions
On Friday, 7 October 2016 08:25:31 UTC+8, kovasb wrote:
>
> On Thu, Oct 6, 2016 at 4:46 PM, Dragan Djuric > wrote:
>
>
>> s more harm than good. I prefer to give users one Ford model T, than let
>> them choose between 20 different horse carriages. And, if they can even
>>
the reluctance to commit to a certain API, but I don't think
> everyone will rush to commit their code to the API you release anyway, and
> the open development will certainly help both the (potential) users and
> your team (by returning free testing & feedback).
>
>
> On Tu
I've been working with a number of collaborators on a deep learning library
for Clojure.
Some key features:
- An abstract API for key machine learning functionality
- Ability to declare graphs / stacks of operations (somewhat analogous to
tensorflow)
- Support for multiple underlying
Hi all,
In the (unlikely?) event that someone else also faces the problem of
reading / importing SPSS files within Clojure, I've released a small
library that does exactly that.
https://github.com/mikera/clj-spss
Nothing fancy here: it is mostly just a Clojure wrapper for some old Open
Data
I would definitely second Tim's points. The JVM is very hard to beat once
you factor in the GC and JIT requirements.
Worth noting that persistent data structures with structural sharing are
used pretty much ubiquitously in Clojure and that these are *exactly* the
kinds of data structures that
There are two companies I'm involved with that use Clojure for IoT:
Kemuri - http://www.kemurisense.com/
Silverline - http://silverline.mobi/
Both are in the space of assisted living for the elderly, Clojure is used
mainly for the sensor data ingestion and analysis.
On Monday, 11 April 2016
On Monday, 14 March 2016 18:21:15 UTC+8, Dragan Djuric wrote:
>
>
>>>
>> There is a set of BLAS-like API functions in core.matrix already. See:
>> https://github.com/mikera/core.matrix/blob/develop/src/main/clojure/clojure/core/matrix/blas.cljc
>>
>
> Git
ing on how you count).
>
There is a set of BLAS-like API functions in core.matrix already.
See:
https://github.com/mikera/core.matrix/blob/develop/src/main/clojure/clojure/core/matrix/blas.cljc
Having said that, I don't personally think the BLAS API is a particularly
good fit for C
le are on the #data-science
channel in the Clojure slack
Or you can just file a core.matrix issue with a question: I'm usually quite
responsive with these and they may serve as a reference for future people
who run into similar questions:
https://github.com/mikera/core.matrix/issues
--
Y
On Monday, 14 March 2016 08:19:25 UTC+8, Dragan Djuric wrote:
>
> On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:
>
>> It would be great if Neanderthal simply implemented the core.matrix
>> protocols, then people could use it as a core.matrix implementation for
I have a useful library for image manipulation in Clojure, you may find it
useful:
https://github.com/mikera/imagez
New ideas / PRs gratefully received!
On Sunday, 13 March 2016 04:14:34 UTC+8, James Elliott wrote:
>
> Interesting! This is the first time I have had to drop out of C
On Friday, 11 March 2016 09:09:14 UTC+8, Dragan Djuric wrote:
>
> This is already working well for the array programming APIs (it's easy to
>> mix and match Clojure data structures, Vectorz Java-based arrays, GPU
>> backed arrays in computations).
>>
>
> While we could agree to some extent on
core.matrix maintainer here.
I think it would be great to have more work on dataframe-type support. I
think the right strategy is as follows:
a) Make use of the core.matrix Dataset protocols where possible (or add new
ones)
b) Create implementation(s) for these protocols for whatever back-end
Yeah, confirmed this is a bug in vectorz-clj. Indexing error meant that the
operator was getting applied to the first row twice, instead of once to
each row.
There is a fix and regression tests in the develop branch already, will be
fixed in next release (hopefully today if I have time)
On
Hi Sunil,
You are correct that the naive code will eagerly produce the full matrix
UxV, which may be very large :-)
I think your strategy of extracting rows and columns from U and V is the
best one. Row and column extraction for dense matrices in vectorz-clj is
very efficient since it just
Good initiative, I've filled in a response to the survey.
One thing that strikes me is that the main issue with loading time is the
time required to transitively load and compile all the referred namespaces
(which can be a lot in a big project...). This in turn may trigger class
loading of
ould be nice to pitch in there
> too.
>
> cheers,
> Bruce
>
> On Fri, Feb 5, 2016 at 10:26 AM, Mikera <mike.r.an...@gmail.com
> > wrote:
> > Hi Bruce,
> >
> > My view is that the following things should be in core.matrix
> > - Fundament
set? I'd like to know that
> any fixes we pursue would move towards the future design of incanter.
>
> cheers,
> Bruce
>
> On Thu, Feb 4, 2016 at 10:01 AM, Mikera <mike.r.an...@gmail.com
> > wrote:
> > There is the start of a dataframe-like implementation in
&
6 at 2:22 AM, Mikera <mike.r.an...@gmail.com
> > wrote:
>
>> If you are interested in data science, help with core.matrix and the
>> associated libraries is always appreciated, and we are very
>> contributor-friendly in the numerical Clojure community.
>>
>
If you are interested in data science, help with core.matrix and the
associated libraries is always appreciated, and we are very
contributor-friendly in the numerical Clojure community.
On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
>
> Hey folks!
>
> Today is the first day
There is a `pow` function in core.matrix, that computes powers over whole
arrays at the same time.
Tests / patches to improve this always welcome.
On Tuesday, 3 June 2008 16:55:15 UTC+8, Jon wrote:
>
> As I could not find a ** function in boot.clj, I wrote this one:
>
> (defn **
>
I share the same unease. I haven't quite fully been able to articulate all
the reasons, but here are the things that concern me most:
1) Completing the API for data access with the representation
This is my biggest issue. Good practice IMHO is to keep APIs abstracted
from underlying
On Monday, 1 February 2016 05:19:17 UTC+8, John Krasnay wrote:
>
> Hi all,
>
> I'm migrating an application from Java/Spring to Clojure and I'm searching
> for a good, functional approach. The app exposes a REST interface using
> compojure-api and primarily interacts with a relational database
Looks awesome, I'd definitely like to use this whenever I can guarantee
running on Java 8 or above.
Question: is there any change of having a unified time API in Clojure? That
supports both Joda time and Java time? And works with cljs? It is a bit
frustrating to have to hard-code to specific
Thanks for sharing, this is definitely something I have been interested in.
My use case is a little more specific: I'd like to be able to run a
Clojurescript test suite as part of a larger Maven build. Has anyone
managed to get something like this to work?
On Monday, 28 December 2015 05:06:23
I personally think the current approach is right. Most people don't need
arbitrary precision decimals, so it makes sense to have the fastest
implementation used as the default. This also follows the "principle of
least surprise" for people who are coming from other languages.
If someone really
On Thursday, 17 December 2015 14:59:37 UTC, Herwig Hochleitner wrote:
>
> Am 17.12.2015 02:35 schrieb "Mikera" <mike.r.an...@gmail.com
> >:
>
> > What's the plan with Tuples more broadly?
>
> Speaking as a kibitzer to the process: Suppose somebody was
On Thursday, 17 December 2015 04:34:58 UTC, Alex Miller wrote:
>
>
> On Wed, Dec 16, 2015 at 7:34 PM, Mikera <mike.r.an...@gmail.com
> > wrote:
>
>>
>> What's the plan with Tuples more broadly?
>>
>
> Don't know.
>
>
I'm willing to tak
Thanks Alex, working well for me and startup times certainly seem a bit
snappier.
I also agree that APersistentVector should not implement IMapEntry.
always seemed like a bad idea to so glad to see it rolled back.
What's the plan with Tuples more broadly? I worked on this many months ago
I agree 100% that schema is a great tool, and solves some of the problems
I still think the absence of (optional) types is a big missing piece in the
Clojure story, because of the following reasons:
1. The ideal time to check types is at compile time - you want immediate
feedback if you do
Source code using the Clisk library is here:
https://github.com/mikera/clisk/blob/develop/src/test/clojure/clisk/samples/animations.clj
Video encoding was done using the new Telegenic library which wraps JCodec:
https://github.com/mikera/telegenic
The original 2D source image was created by Roger
Personally I think nth is broken and should throw an exception when passed
nil (which should be interpreted as an empty sequence)
=> (nth nil 10)
nil
=> (nth '() 10)
IndexOutOfBoundsException clojure.lang.RT.nthFrom (RT.java:885)
=> (nth [] 10)
IndexOutOfBoundsException
er
> that I guess the dependencies will be missing (it's not an uberjar, so
> we need to build the classpath in some way).
>
> About ant, the closed issue I linked has a comment from mikera saying
> "Good spot. I just deleted the build.xml - it's an old relic, and new
game development in Clojure (with immutable
data structures, event handling etc.) then my little game Ironclad may be
interesting (it is a desktop client rather than ClojureScript however)
https://github.com/mikera/ironclad
There is also an article about building a card game (Omnigard
Go is fine for system-level programming, but I personally wouldn't use it
as a web application programming language. Ten reasons to consider.:
1. There isn't really much speed difference on micro-benchmarks between JVM
code and Go. See e.g.: http://benchmarksgame.alioth.debian.org/u64q/go.html
You can use *unchecked-math* if you want unchecked arithmetic behaviour:
=> (set! *unchecked-math* true)
true
=> (+ Long/MAX_VALUE Long/MAX_VALUE)
-2
On Friday, 4 September 2015 23:04:27 UTC+8, Ali M wrote:
>
> Ok, so to give myself a safe and consistent way to reason about this
> the addition
A few things to consider:
1. Performance is a key consideration. The speed of the compiler is a major
determinant of startup time for Clojure applications, which is very
important to many people. Having the compilker written in Java probably
helps a lot here - it is generally easier to write
cases better might help me think about what could be
done in ccw, or in clojure-maven-plugin, to remove this need.
Le samedi 8 août 2015, Mikera mike.r.an...@gmail.com javascript: a
écrit :
Has anyone found a good way to automatically keep project.clj in sync
with the official pom.xml
Has anyone found a good way to automatically keep project.clj in sync with
the official pom.xml? Maybe using the clojure-maven-plugin or similar?
I do this too for a number of libraries, but it's always a manual task and
prone to error at present
On Saturday, 8 August 2015 07:45:41 UTC+8,
If you want a free / open source alternative, then Eclipse also offers a
great environment for developing Java, Clojure and Python.
The Counterclockwise plugin for Eclipse is great - certainly has provided
everything I want in a Clojure dev environment (integrated REPL, paredit
mode, good
See:
https://github.com/clojure/test.check/commit/d4883873df73717629272d0ab71619d7e58c9c9e
On Wednesday, 29 July 2015 23:31:14 UTC+8, Mayank Jain wrote:
Nice. Any updates on this?
Is this a good idea?
On Friday, May 15, 2015 at 12:13:06 PM UTC+5:30, Mikera wrote:
Hi all,
I am doing some
Hi Alex,
1.8.0-alpha3 is breaking core.matrix at the moment.
Root cause appears to be related to how protocols are being handled when
used with Java arrays:
e.g. for the protocol implementation:
(extend-protocol mp/PImplementation
(Class/forName [Ljava.lang.Object;)
(implementation-key
It could certainly be achieved in the Clojure compiler, by allowing
(some-functional-interface .) to compile to the appropriate function
call even if it doesn't implement IFn
It would be quite a big change though and would probably have some
limitations, e.g.:
a) It probably wouldn't work
July 2015 09:53:25 UTC+8, Andrew Oberstar wrote:
Mikera, I think you're addressing a different interop concern. I'm
particularly interested in something like this:
(- (IntStream/range 0 100) (.filter odd?) (.limit 5) (.collect
Collectors/toList))
Where odd? is a normal Clojure IFn that I
On Saturday, 25 July 2015 22:50:55 UTC+8, crocket wrote:
Logging libraries seem to rely on a global config. This looks like a
dangerous state that could blow up.
I researched a little, and there seems to be reader monad and dependency
injection, all of which feel awkard.
Is there not a
On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote:
I don't think the tweets you link are the 'normal approach'. I would call
them pretty unusual in several aspects. For one, I think that for the vast
majority of Clojure tickets created, no on asks and gets Rich's comments on
Looks really nice!
Has anyone given thought to a more general time library, that can also
handle the new java.time instances? I expect that will become a standard
across many Java libraries in the future so it would be helpful to have
good interop capabilities.
On Wednesday, 15 July 2015
Can we get links? Initial design docs?
This is the first I heard of this, but sounds like something that could do
with a decent amount of community discussion and feedback if we are going
to establish a good standard.
Some properties of such library metadata I'd like to see:
1) Works equally
On Wednesday, 1 July 2015 12:55:28 UTC+1, J. Pablo Fernández wrote:
Hello Clojurists,
Today I was surprised by the result of (flatten 1) which is '(). I was
expecting '(1) or an error. Talking in some other people in #clojure @
clojurians.net, not everybody agrees that '(1) is a good
and Neanderthal could be
a great library *if and only if* it works well with the rest of the
ecosystem and you are personally willing to collaborate.
Your call.
On Monday, 22 June 2015 10:05:15 UTC+1, Dragan Djuric wrote:
On Monday, June 22, 2015 at 2:02:19 AM UTC+2, Mikera wrote
On Saturday, 20 June 2015 08:43:39 UTC+1, Dragan Djuric wrote:
On Friday, June 19, 2015 at 11:17:02 PM UTC+2, Christopher Small wrote:
I see now Dragan; you're concerned not about whether easily implementing
and swapping in/out implementations of core.matrix is possible, but whether
it can
Consider using core.matrix with vectorz-clj for operations on large
numerical arrays / vectors of doubles. It is a *lot* faster than using
Clojure vectors for this kind of scenario, plus it has a lot of helpful
array operations already defined.
(use 'clojure.core.matrix)
(def v (array :vectorz
I intended the core.matrix.stats to be used as a lightweight library as
for statistical functions of this nature, while remaining compatible with
Incanter and core.matrix. I agree something more lightweight than the whole
of Incanter is often required.
2 2 4 3 3 3 3 4 3 5 1 2 3 2 4 4 2 2 3 6 6 2 5 5 4 6 3)
So it seems to work, but is this a sane / recommended approach? Am I
relying too much on test.check internals?
mikera
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group
I agree that the problem is immutable/functional constructs per se., but I
don't think the problem is the lack of VM support either. It is possible to
get *very* fast code on the JVM.
In Clojure the issue is more that the dynamic nature of many Clojure
constructs and lack of static type
My general rule of thumb is that idiomatic Clojure is about 10x slower
than Java. So this result doesn't really surprise me.
If you want to get maximum performance, you will have to do some more
advanced / non-idiomatic things like:
- Add type hints for classes and primitive values
- Use
This is a great initiative. Would love to see an official community
organisation.
Some things I think are particularly important on the content side:
a) Maintain and improve the clojure.org website as the front page for the
community
b) Produce official user guides and documentation for Clojure
You often have to do bit of manual coercion to make things work nicely with
the whole set of possible Clojure numerical types. Fortunately there are
plenty of built-in functions in clojure.core to help you do this.
In your specific case I would do:
(.add (Complex. 1.0 2.0) (double 2))
This
of reasonable, it might be
acceptable. I am willing to explore this further.
.
On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing. The
obvious implementations that you
number type, mostly just by calling b) directly
On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
I have been thinking along the lines of mikera and Maik - and it seems
like there is no further progress here? I would like to take a crack at
creating a complex number type, but implemented
accepted.
https://github.com/mikera/core.matrix
There is also a Google Group here specifically dedicated to numerical
topics in Clojure:
https://groups.google.com/forum/#!forum/numerical-clojure
Maybe if Clojure pulls itself away from the JVM this will change. One
big problem with both python
Guess this is somewhat a personal perspective, but here are some thoughts
on testing in Clojure:
- People do a lot of automated testing in general and there are some great
testing libraries available (e.g. test.check)
- People tend not to strictly follow Test Driven Development practices.
e.g.
In that case, I would suggest writing a minimal wrapper, either in Java or
Clojure.
To get the basic sequence operations, you can simply implement the
interface clojure.lang.ISeq on the wrapper.
On Wednesday, 18 March 2015 09:17:09 UTC+8, juvenn wrote:
Thanks Niels, but what if a java class
I posted some answers on the GitHub issue:
https://github.com/mikera/core.matrix/issues/228
But in short, you should use one of the optimised implementations if you
care about performance. Clojure vectors are very flexible, but aren't
really designed for numerical performance. vectorz-clj
Looks cool, thanks for sharing!
Not sure how useful it is, but I wrote some code and a blog post a while
back about doing spectrograms in Clojure:
https://clojurefun.wordpress.com/2013/12/22/spectrograms-with-overtone/
On Monday, 9 March 2015 02:36:27 UTC+8, Steven Yi wrote:
Hi All,
I'd
Thanks for sharing Andrey!
Could you comment on how this compares with:
https://github.com/ztellman/byte-streams
Are the two complementary? Replacements?
On Monday, 2 March 2015 03:58:57 UTC+8, Andrey Antukh wrote:
Hi!
I'm happy to announce the first version of Octet library.
_octet_
still doesn't quite have the full range of bitwise functionality
as far as I'm aware
Feel free to use any of my Java bitwise code, if helpful:
https://github.com/mikera/mikera/blob/master/src/main/java/mikera/util/Bits.java
On Tuesday, 24 February 2015 02:59:32 UTC+8, danl...@gmail.com wrote
If you really care about performance then I would use a macro for code
generation and do something the following:
(defmacro appendfunc
([m keys sb]
`(do
(.append ~sb (~m ~(first keys)))
~@(for [k (next keys)]
`(do
(.append ~sb \,)
Interesting - there seems to be a very slight performance advantage to
your version on my machine (consistently about 25% faster for if-nots in a
tight loop).
I think the problem is actually with not - which isn't getting inlined
currently. If I patch not so that it is inlined, the difference
I'd be pretty interested in this too. Though not quite enough to write it
myself (I've made good enough interfaces with Swing interop).
The thought occurs that there may be quite a bit of common code that could
be shared with respect to diffing / cursors etc. that would work equally
well for
to Neanderthal. And as Mikera points out, it would be nice
if we kept the Clojure matrix API space cohesive.
--
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
It seems a little odd that there is an ArrayList override but not List.
Presumably that is there as an optimisation since ArrayList is such a
common case?
It seems to have happened in this commit for CLJ-1546, which replaces the
List override with ArrayList
Looks cool Dragan, thanks for sharing!
I would strongly encourage you to wrap this up and make it work as a
core.matrix implementation. That would considerably improve
interoperability with other libraries / tools in the Clojure numerical
space e.g. it could be used as a drop-in replacement
Very nice!
People interested in this topic may also be interested in Expresso, which
supports analysis / transformation of mathematically expressions in Clojure:
https://github.com/clojure-numerics/expresso
Extra features I would personally find interesting in this space:
- Ability to use
You have probably either hit a Clatrix bug or have some kind of version
mismatch with core.matrix - could you file an issue with the exact version
numbers you are using and code to
reproduce: https://github.com/tel/clatrix/issues ?
Note that * in clojure.core.matrix.operators is for
A few comments:
Your two pieces of code aren't really equivalent:
a) The Python code is just calculating a fibonacci number in a brute force
iterative loop.
b) The Clojure code is creating a big (infinite, lazy) data structure of
all fibonacci numbers, lazily realising the structure in memory
I'm trying to figure out how to get core.matrix to load much faster - I
think it's actually some kind of Clojure issue with protocols but I'm not
*exactly* sure what is causing
On Tuesday, 30 December 2014 05:13:24 UTC+8, Jony Hudson wrote:
@Mike Thinking out loud here ... one option would be
28, 2014 at 8:11 AM, Mikera mike.r.an...@gmail.com
javascript: wrote:
That depends if the protocols are part of your user-facing API or not - a
lot of the time I find that protocols are best hidden as implementation
details rather than exposed to users.
In core.matrix, for example, users
core.matrix isn't that big of a dependency itself - it only gets expensive
in/when you load the implementations (NDArray, vectorz-clj, Clatrix etc.).
Which should be a choice of the ultimate user.
It is possible to just depend on the protocols, but I think that risks
breakage since protocols
Very cool!
On the data representation front, would you be open to making it support
the core.matrix Dataset protocols as well as regular Clojure maps? That
would make it much easier to integrate with Incanter 2.0 etc., and
potentially avoid some copying overhead.
It should be a simple change
That depends if the protocols are part of your user-facing API or not - a
lot of the time I find that protocols are best hidden as implementation
details rather than exposed to users.
In core.matrix, for example, users never see the protocols directly: only
implementers of new matrix libraries
For most array operations (e.g. dot products on vectors), I strongly
recommend trying out the recent core.matrix implementations. We've put a
lot of effort into fast implementations and a nice clean Clojure API so I'd
love to see them used where it makes sense!
For example vectorz-clj can be
It seems to me that we will need a multi-stage pipeline with a few
different transformations available. This will give many benefits:
a) People can mix and match the components they need for the particular
project
b) We avoid unnecessary dependencies for people who don't want / can't
support
There's also Kiss, which at least has the potential to run as a
fast-loading statically-typed Clojure variant.
https://github.com/mikera/kiss
Currently I still load clojure.core for bootstrap reasons, but that's not
going to be necessary in the future (once kiss.core is complete). I may
take
How are you getting that error? Are you sure you aren't just passing a nil
parameter by accident? For example, I get the same error when I pass nil to
the clojure.java.io/reader function.
Clojure usually throws file not found exceptions where appropriate, e.g.
(use 'clojure.java.io)
(reader
I would totally support this if it makes it easier to enhance
Counterclockwise (which I love!)
Not personally aware of anyone still stuck on Eclipse 3.x
On Thursday, 4 December 2014 18:18:34 UTC+8, Laurent PETIT wrote:
Hello,
Eclipse 4.x has been around for many years now, and I'm
This is a great release, thanks!
CLJ-1529 seems to have solved a major compilation-time issue with
core.matrix
CLJ-1578 is a good start in that it stops some of the failures, but the
warnings still aren't addressed... I will open a new ticket
On Saturday, 15 November 2014 03:34:55 UTC+8,
You may find that wrapping a random number generator as a lazy sequence is
a useful approach - it is functional and works nicely in an idiomatic
clojure style where you can take as many random numbers as you need while
treating the whole sequence as an immutable value.
I have an (experimental)
To keep things simple I have found it easy to use lein uberjar and java
-jar myapp.jar. This removes the need for a separate container / app
server and it is probably the easiest choice when you are running an
embedded server such as http-kit. Configuration is virtually zero, and this
has the
1 - 100 of 364 matches
Mail list logo