BTW (and I may be a little late here) - is there a plan to add keyword creation
to the API? Keywords are a pretty common part of many Clojure APIs, it would be
good to allow their creation without forcing people to use Keyword.intern().
On November 23, 2013 at 8:16:48 PM, a...@puredanger.com
Congratulations Mimmo, that's great news. I'd like to play with OpenCV at
some point, I'll definitely use this if/when I do. And yes, I totally agree
- Seesaw is the gold standard with lib wrapping IMO, it's a fantastic piece
of work.
Cheers,
Colin
On 12 December 2013 08:00, Mimmo Cosenza
wrote:
On Dec 12, 2013, at 4:01 AM, Colin Fleming colin.mailingl...@gmail.com
wrote:
Seesaw is the gold standard with lib wrapping IMO, it's a fantastic
piece of work.
thanks. I'll start to study it today and try to grab idea from there. if
anyone have any suggestion on best-practices to wrap
I've just spent some time today looking at the compiler code, and
unfortunately I think the answer is no. When a symbol is imported,
Clojure currently instantiates the Class object using Class.forName() and
stores that in the namespace's mapping. At the point the Class is
instantiated, static
I actually just wrote a long reply detailing how to type hint 'this', and
then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole Cursive codebase, I can't figure it out either.
On 23 December 2013 01:03, Jim -
never found a workaround.
Dave
On Sunday, December 22, 2013, Colin Fleming wrote:
I actually just wrote a long reply detailing how to type hint 'this', and
then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole
if the superclass method throws an exception, the proxy will be
left with the superclass call in its proxy mappings.
On 23 December 2013 16:41, Colin Fleming colin.mailingl...@gmail.comwrote:
But surely proxy-super should be designed to call protected methods? I'd
have to check but I suspect I call other
As another data point, Cursive's symbol resolution in normal code editing
is totally static - it doesn't use the REPL at all. When typing in the REPL
window, local resolution is used for the code in the editor and the REPL is
used for everything else, so that local symbols can be completed and so
That is indeed the same issue, and it even includes a patch with a test!
I've voted for this one, please consider doing the same if this issue has
caught you. Link: http://dev.clojure.org/jira/browse/CLJ-983
On 25 December 2013 13:22, Matching Socks phill.w...@gmail.com wrote:
(Re Colin's note
original binding on exception...
Jim
On 25/12/13 04:06, Colin Fleming wrote:
That is indeed the same issue, and it even includes a patch with a test!
I've voted for this one, please consider doing the same if this issue has
caught you. Link: http://dev.clojure.org/jira/browse/CLJ-983
and not in the fn that the rest of
the proxy body goes into, which will avoid IllegalAccessError but make it
so that on-the-fly modification of the proxy can't change the proxy-super
part).
On Wed, Dec 25, 2013 at 3:04 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Right, it doesn't fix your
report back if I ever get it working.
On 15 December 2013 14:05, Colin Fleming colin.mailingl...@gmail.comwrote:
I've just spent some time today looking at the compiler code, and
unfortunately I think the answer is no. When a symbol is imported,
Clojure currently instantiates the Class object
the compiler anyway, I'd go straight for a more sane extend-class
form.
On 27 December 2013 17:49, Cedric Greevey cgree...@gmail.com wrote:
On Thu, Dec 26, 2013 at 6:57 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
The problem is that your approach requires creating the proxy class
classes that needed
to be stubbed that it turned into an endless rabbit hole, so I gave up. It
may be a good solution for those who just have one or two problematic
classes, though.
On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:
In case anyone is interested
I think the error complaints are generally more about the errors when you
have something wrong in your code. Things like parsing of ns forms has
little to no error checking, and you can get some extremely obscure errors.
For example if you (or some tool) places an :import clause ahead of your NS
...@gmail.com wrote:
Definitely exciting to hear that it works. Is this something you could
propose as a patch on the Clojure JIRA?
On Friday, December 27, 2013 9:52:04 PM UTC-5, Colin Fleming wrote:
Wow, that works! You just saved me an extraordinary amount of pain -
thank you!
I had to make
Just out of interest (and I'm not trying to be combative here, I'm
genuinely curious) - it seems from many of your posts here that this is a
serious pain point for you. Why not just use another lisp? High-performance
numeric programming doesn't seem like Clojure's strong point and the error
...@hampshire.edu wrote:
On Dec 28, 2013, at 8:51 PM, Colin Fleming wrote:
Just out of interest (and I'm not trying to be combative here, I'm
genuinely curious) - it seems from many of your posts here that this is a
serious pain point for you. Why not just use another lisp? High-performance
numeric
Since Cursive (http://cursiveclojure.com) resolves everything statically
from source, ClojureScript completion and navigation works for most
symbols. There are still a lot that it doesn't know about since
cljs-specific functionality is still pretty low, so js/* symbols have no
support, and any
. I'm still working out how to
handle that but it's definitely on the roadmap.
On 8 January 2014 00:26, Alexandru Nedelcu a...@bionicspirit.com wrote:
On Mon, Jan 6, 2014 at 11:10 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Since Cursive (http://cursiveclojure.com) resolves everything
This is an interesting discussion, I've been thinking about some of these
problems as I move towards adding inspections in Cursive. arglist parsing
is a real problem in Clojure. I'd like to be able to flag invocations of
functions with bad arities in the editor, but it's very difficult. Even
defn
On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
This is an interesting discussion, I've been thinking about some of these
problems as I move towards adding inspections in Cursive. arglist parsing
is a real problem in Clojure. I'd like to be able to flag
:wrong-arity warnings
Andy
On Mon, Jan 13, 2014 at 10:22 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Interesting - but there must be some sort of magic there since otherwise
every call to defn would be flagged, since its :arglists implies it has 6
arguments. And in fact, there's
Note that you can work around the compilation problem by using a version of
Clojure patched with http://dev.clojure.org/jira/browse/CLJ-1315. Cursive
now uses and ships with such a patched version, and it works great.
On 22 February 2014 11:31, Jean Baro jfb...@gmail.com wrote:
Wow! Congrats
FWIW, in Cursive, which is a big ball of mixed Clojure + Java, I've given
up trying to use gen-class and have started using Java shims for
everything. I like it a lot more than gen-class, which I always feel like
I'm fighting. With the new Java-Clojure API in 1.6 (or the equivalent
using RT.var()
My understanding is that invokedynamic was very problematic in Java 7, but
is quite a different design and works much better in Java 8. I'd expect it
to be much more heavily optimised in Java 8 since it's used by a core Java
feature (lambdas). Unfortunately targeting Java 8 only is probably not
class access, non-Clojuresque fields, static methods etc), but simple class
extension along the lines of the existing interop support doesn't seem like
such a bad idea.
On 5 April 2014 20:20, Mikera mike.r.anderson...@gmail.com wrote:
On Saturday, 5 April 2014 08:08:13 UTC+8, Colin Fleming
There's MLj http://research.microsoft.com/en-us/um/people/nick/mlj.htm
Unfortunately MLj is almost totally bit-rotted at this stage. I made a
valiant attempt to get it going a couple of years back but it would be a
lot of work, and once you have it working it doesn't fully support SML.
It's a
Hi Leif,
This sounds like a very interesting project, please report back and let us
know how it went! I'd be very interested to know.
Cheers,
Colin
On 11 April 2014 00:53, Leif leif.poor...@gmail.com wrote:
Hi, everybody. Inspired by the SF Bay Area clojure group, ClojureBridge,
and the
you can fight it as hard as you like but you will eventually end up using
emacs, clojure-mode, cider, paredit and magit and then wonder how you ever
lived without it, but not without spending at least a month or two cursing
anything to do with emacs :).
As the developer of Cursive, I'd like
, 2014 at 2:50 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
you can fight it as hard as you like but you will eventually end up using
emacs, clojure-mode, cider, paredit and magit and then wonder how you ever
lived without it, but not without spending at least a month or two cursing
. But it absolutely is an investment.
Disclaimer - I haven't looked at any of the other editors for months if
not years.
On Friday, April 11, 2014 10:20:37 AM UTC+1, Colin Fleming wrote:
you can fight it as hard as you like but you will eventually end up using
emacs, clojure-mode, cider
gen-class really isn't suitable for doing complicated interop like
annotating fields. It's heavily oriented towards a single means of managing
state, which is a single field generally containing an atom, which in turn
contains your actual state in a map or similar. If you really need multiple
Java libraries is
idiomatic Clojure, and this is true for a lot of us using Clojure.
jbs
On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote:
gen-class really isn't suitable for doing complicated interop like
annotating fields. It's heavily oriented towards a single means
.
On Monday, April 14, 2014 7:56:21 PM UTC-5, Colin Fleming wrote:
Well, I'm a bit torn on this one. On the one hand, I'd love to have
something that meets my particular use case (of course!) which I wrote
about here: https://groups.google.com/d/topic/clojure/MznBwxZt4cY/
discussion. I think
That was what I figured. However Clojure currently makes certain kinds of
interop extremely painful, which makes it hard to integrate into existing
frameworks. I'm not proposing anything that would encourage concrete
derivation in pure Clojure programs, but I think that facilitating that
interop
Note that you could use mapv, to perform the map but return a vector
(filterv was also added at the same time).
On 16 April 2014 11:46, Kris Calabio kriscala...@gmail.com wrote:
I'm not exactly sure, but I think it's the use of 'conj'. My entities get
out of order if they are not vectors.
That's interesting. I think such a database of common errors would be an
extremely useful resource, not only for learning but also for development
of linting tools (I think this is more or less what Dynalint does right
now) and other tools. For example, I'd love to be able to flag these types
of
I think LightTable is a good choice for Clojure beginners, certainly it's
much more approachable than Emacs. Other options you might consider are
Cursive (based on IntelliJ, at http://cursiveclojure.com) or
CounterClockwise (based on Eclipse, at
https://code.google.com/p/counterclockwise) which
for CLJS/web work and Cursive/CCW for
mixed Clojure/Java projects).
On 17 April 2014 13:12, Mark Engelberg mark.engelb...@gmail.com wrote:
On Wed, Apr 16, 2014 at 6:01 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Standard disclaimer: I develop Cursive.
How's Cursive coming along
BTW I changed the website copy a little for Cursive, since much less
bravery is now required than previously. Thanks for the heads up! I'd
forgotten that was still there.
On 17 April 2014 13:12, Mark Engelberg mark.engelb...@gmail.com wrote:
On Wed, Apr 16, 2014 at 6:01 PM, Colin Fleming
I agree - I thoroughly enjoyed this.
On 30 March 2013 08:45, Alan Thompson thompson2...@gmail.com wrote:
Hey - Just saw a nice article on this in (def newsletter) . It looks like
quite a good reference on the subject.
Hi Kevin,
That message means that Clojure can't find the file containing your macros
on the classpath. Looking at it, you appear to have the macro file in your
src-cljs directory. I've never used ClojureScript, but maybe that should be
in your src directory since it's Clojure and not
This is something I noticed the other day - the reader doc states of
keywords They cannot contain '.' or name classes. Clearly most qualified
keywords will contain '.'.
On 15 April 2013 18:07, Andy Fingerhut andy.finger...@gmail.com wrote:
The description of legal symbols at
I'm pretty sure the implementation of locals clearing is all in
Compiler.java, in the LocalsBinding class. See canBeCleared in that class.
On 23 April 2013 23:37, xumingmingv xumingmi...@gmail.com wrote:
Michal, do you know any resources/links that introduce the internals of
local-clearing?
I guess you could go for a middle ground where you run a JVM instance per 8
cores or so, which would minimise your intercommunication but still reduce
your GC contention. Of course as soon as ( num-jvms 1) you have to write
all the communication and deployment code anyway so it might not be a big
I think it looks interesting because it seems like maintaining the Clojure
semantics is what also gives a lot of the cljs-js interop problems. It
seems like there would be room for a variant of ClojureScript which
maintains as much of the semantics as possible without compromising
performance or
That looks great, Tom, thanks - I'll definitely spend some time exploring
that.
Cheers,
Colin
On 3 June 2013 19:55, Tom Van Cutsem tomvc...@gmail.com wrote:
If you're the kind of person who rather reads source code than
documentation, you might also be interested in my meta-circular
Right, FWIW in my previous company we disallowed LGPL libraries because of
the clause that explicitly allows reverse engineering to substitute
different versions of the library. Of course, it's unlikely that anyone
would ever do this but it would be a support nightmare if they did, so it
was just
Interesting, I think I like this presentation better, I found the explicit
boxes in the OP a little distracting. I guess this then becomes more like
Python-style significant indentation, which might be an interesting
approach too.
On 5 June 2013 12:15, Matthew Chadwick mathn...@gmail.com wrote:
*`defprotocol` is a top-level form...*
This is interesting, and it's something I've wondered about. As far as I
can tell, there's really no distinction between top-level forms and other
forms, for example this is legal and works:
(defn define-my-functions []
(defn test-1 []
1)
(defn
*The JVM as a target is much friendlier to other languages, compared to the
CLR, in spite of the initial hype surrounding the CLR's multi-language
capabilities.*
I'm not sure this is true, Don Syme has written several times about how
difficult it would be to implement F# on the JVM - I believe
I use OSX for everything, and have for a long time. I could see myself
switching to Linux for work (although collaboration tools e.g. Skype etc
are still more difficult than on OSX, maybe hangouts helps here) but at
home it's a non-starter since I use my machine for watching movies etc, and
that's
Hi all,
This is slightly tangential to the current discussion on unnecessary type
checks - does anyone have any good links to information about the JIT
optimisations performed by Hotspot? One question I've been interested in
recently is how well it can optimise Clojure function calls. The
we're assuming it won't change) would be a huge performance win.
Cheers,
Colin
On 17 June 2013 14:38, Ben Mabey b...@benmabey.com wrote:
On Sun Jun 16 16:51:41 2013, Colin Fleming wrote:
Hi all,
This is slightly tangential to the current discussion on unnecessary
type checks - does anyone
wouldn't work anymore.
Such an optimization would have to be a deployment-time option rather than
forced.
On Mon, Jun 17, 2013 at 12:05 AM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Interesting, thanks for the pointer. I'll read up a little more on the
technicalities of invokedynamic. Can
Interesting - thanks.
On 17 June 2013 16:39, Cedric Greevey cgree...@gmail.com wrote:
On Mon, Jun 17, 2013 at 12:34 AM, Colin Fleming
colin.mailingl...@gmail.com wrote:
My bad - I assumed this didn't work anyway for non-dynamic vars, but it
does indeed work. So the only difference
Thank you for this, you just fixed a bug for me :-)
I was trying to do some tricky type hinting with definline using amolloy's
great answer http://stackoverflow.com/a/11920022 on StackOverflow. Notice
that he uses `BufferedImage and not 'BufferedImage. I stupidly figured that
this was just a typo
Hi all,
I'm having a problem where a definline'd function is not working when used
as a predicate for filtering. It seems to work sporadically - occasionally
it works, occasionally it doesn't. I'm thinking it's probably a compile
problem since it seems to work or not work consistently for each
:
There is already a symbol? predicate in core. Why are you defining your
own? Does your problem disappear when you use the one from core?
What exactly are you trying to do? I use definline quite frequently and
have never encountered such problems...
Jim
On 20/06/13 10:35, Colin Fleming wrote:
Hi all
, Jim - FooBar(); jimpil1...@gmail.com wrote:
On 20/06/13 10:59, Colin Fleming wrote:
Because this tests for something different - that the element is an
instance of ClSymbol. It's not testing the same thing as the core version.
I qualify it (psi/symbol? in the examples above) to distinguish
?)))
= false
plugin.psi/symbol?
= plugin.psi$symbol_QMARK_@4ccc75ae
((:inline (meta #'plugin.psi/symbol?)) 2)
= (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
On 20 June 2013 22:48, Colin Fleming colin.mailingl...@gmail.com wrote:
ClSymbol is a Java class. I don't get
Does anyone have an idea for what I might do to diagnose/fix this? Is this
just a misunderstanding on my part? If not I'll file a bug against
definline.
On 21 June 2013 18:04, Colin Fleming colin.mailingl...@gmail.com wrote:
So this has just happened to me again:
Clojure 1.5.1
(plugin.psi
Which version of the IntelliJ plugin are you using? You can see this by
opening the settings, selecting plugins then selecting the La Clojure
plugin. In recent versions the compiler has changed and I've had occasional
problems with it.
On 23 June 2013 02:29, Dennis Haupt d.haup...@gmail.com
Hi Mikera,
For your mutable var loop example, I think with-local-vars should do what
you want.
It would be fantastic if the Clojure compiler could optimise these cases
better, especially common higher-order use cases (like stream fusion).
Unfortunately what always seems to kill the possibility
compile-time inference: if the compiler can infer that a var is never used
dynamically, why should we pay the overhead for extra indirection / dynamic
features? The same goes for things like boxing and type casts.
On Wednesday, 10 July 2013 01:15:14 UTC+1, Colin Fleming wrote:
Hi Mikera
Thanks for the pointer to fipp, that actually looks like just what I need!
Fantastic.
On 11 July 2013 13:58, vrak...@gmail.com wrote:
This is an aside, but I wanted to add about translations...
An EDN generator is somewhat redundant from Clojure, but I usually use
fipp for standard
I'm a fan of static generators too, but one large con for a lot of people
is lack of commenting. Personally I like the article-with-no-comments
format, but it's not for everyone. You can use Disqus or similar, but it
has its own issues starting with the fact that you give all your data to
someone
As an aside from this, how problematic is AOT compilation? It seems to be
the source of many bugs (for example, my own
CLJ-1227http://dev.clojure.org/jira/browse/CLJ-1227).
Is there a list anywhere of things to watch out for when AOT compiling?
On 24 July 2013 04:06, Stuart Sierra
Laurent is correct - both the IntelliJ community edition and La Clojure are
Apache licensed.
On 26 July 2013 11:02, Laurent PETIT laurent.pe...@gmail.com wrote:
Hello Cedric,
2013/7/26 Cedric Greevey cgree...@gmail.com:
On Thu, Jul 25, 2013 at 3:05 PM, Greg g...@kinostudios.com wrote:
the most obviously missing thing is HTML/Javascript support.
On 26 July 2013 11:18, Cedric Greevey cgree...@gmail.com wrote:
On Thu, Jul 25, 2013 at 7:06 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Laurent is correct - both the IntelliJ community edition and La Clojure
are Apache
-language project, we can't
avoid using the non-clojure bits. If I had a pure clojure project, in a
team environment, I'd definitely consider it.
- Korny
On 26 July 2013 09:26, Colin Fleming colin.mailingl...@gmail.comwrote:
Nope, it's perfectly functional as long as all you want is basic
From another point of view, as a tool developer if you want to accurately
parse ns declarations it's extremely difficult. :use is a beast, and the
number of options you can potentially combine are crazy. This is mostly due
to the fact that :use combines what most people think of as :use and also
Hi all,
I was planning to wait a little longer before going public, but since it's
pretty relevant to the other IntelliJ thread going on at the moment I
thought I'd jump in. For the last couple of months of happy unemployment
I've been working on a fork of La Clojure which is now about 70%
2013 00:58, Lee Spector lspec...@hampshire.edu wrote:
On Jul 27, 2013, at 7:54 AM, Colin Fleming wrote:
One problem is that the IDE space is already fairly fractured - there's
Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some
point, and of course the current public
Thanks for all the comments, everyone. It seems like there's some interest,
anyway. Most of the features people are asking for are either already there
or close.
There are some interesting questions here, as well. I think it would be
important to have free access for people to try it out - maybe
library broken out
in a more stand-alone way, so we can develop sexy clojure apps with pure
jvm technology. Any thoughts on if that is technically doable?
On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Hi all,
I was planning to wait a little longer
, and when I do I can immediately see what's going on.
On 28 July 2013 11:00, Colin Fleming colin.mailingl...@gmail.com wrote:
I think there's a lot of scope for automatic namespace management. I'm
already doing this for Java but it's more complicated for Clojure.
Currently for Java I automatically
platform offers the current best model for a code-aware
development environment for Clojure.
I'm sure many other companies are similarly placed.
cheers
Colin.
On Saturday, July 27, 2013 11:54:58 PM UTC+12, Colin Fleming wrote:
Hi all,
I was planning to wait a little longer before going public
Shhh - despite my own prejudices, no flame wars please :-)
On 28 July 2013 12:21, Cedric Greevey cgree...@gmail.com wrote:
On Sat, Jul 27, 2013 at 7:52 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
I agree that the sweet spot for a plugin like this, especially in terms
of paying
It's true that both Laurent's and my suggestions are complicated, but we're
thinking about it from an implementer's point of view. What I currently
have from a *user's* point of view for classes is great, you just don't
think about it. I don't know how much Java development you've done, but
this
thoughts on if that is technically doable?
On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming
colin.mailingl...@gmail.com wrote:
Hi all,
I was planning to wait a little longer before going public, but since
it's pretty relevant to the other IntelliJ thread going on at the moment I
One option for people looking for an alternative VM is Avian (previous
thread herehttps://groups.google.com/d/topic/clojure/U4i4nVsYfi8/discussion),
which runs Clojure and supports native continuations and TCO. The
maintainer, Joel Dice, is an all around great guy and does a fantastic job
on the
This is great news, Nicola - thanks for all the hard work!
On 1 August 2013 04:57, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Very exciting! Keep up the great work Nicola!
Ambrose
On Thu, Aug 1, 2013 at 12:41 AM, Nicola Mometto brobro...@gmail.comwrote:
For the last
Hi Zach,
Congratulations, Nightcode looks very impressive - it looks like a worthy
Clooj successor. I'll definitely download it and check it out.
Cheers,
Colin
On 3 August 2013 07:07, Dave Ray dave...@gmail.com wrote:
In Seesaw [1] you can specify your shortcuts as menu S instead of ctrl
S
intellij's widget library broken
out in a more stand-alone way, so we can develop sexy clojure apps with
pure jvm technology. Any thoughts on if that is technically doable?
On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming
colin.ma...@gmail.comwrote:
Hi all,
I was planning to wait
I've also been interested in this for Named (a protocol for things I can
call name on), although my use-case is mostly interop with Java
frameworks.
On 31 August 2013 15:13, Mikera mike.r.anderson...@gmail.com wrote:
It would be better, I think, if metadata was attachable via a protocol
This is actually probably not a bad solution. You wouldn't even need to
rewrite, couldn't you just expand to a let?
(let [* clojure.core.matrix.*
+ clojure.core.matrix.+]
(+ ... (* ...)))
Although thinking about it, you'd have to let-bind all possible operators
every time, and the
Something that I've always wondered - why is ClojureDocs not updated? I've
never tried to contribute to it - is it particularly difficult? Is it
impossible for users to add support for new Clojure versions? If so, who
runs it? Could it be turned over to the community?
On 11 September 2013 17:55,
This is interesting - are there any other cases where forms are treated
specially at top-level?
On 20 September 2013 10:01, Gary Verhaegen gary.verhae...@gmail.com wrote:
As Meikel said in his previous mail, 'do' at the top-level is treated
specially: each form is treated as a separate
Congratulations Nicola, and thanks for all the hard work - this is a great
project!
On 23 September 2013 14:26, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Excellent work! To hear CinC is a long term project is music to my ears!
Ambrose
On Mon, Sep 23, 2013 at 4:59 AM,
I'm a little late to the party here, but I just wanted to thank you guys
for writing these posts - they're great. Thanks for emphasizing the social
aspects of software development, this is all to often forgotten.
On 13 September 2013 09:09, Michael Klishin michael.s.klis...@gmail.comwrote:
The
This is fantastic news. If anything, CinC is almost a more important
project since its applications are so broad. I'm delighted to see the
community getting behind both of these projects - congratulations Ambrose
and Nicola!
On 1 October 2013 07:02, Rich Morin r...@cfcl.com wrote:
I am
Hi everyone,
Following on from the discussion a while back about interest in a
commercial Clojure IDE, I'm pleased to announce the public Early Access
Program for Cursive (http://cursiveclojure.com). Cursive is based on the
IntelliJ platform and is mostly written in Clojure. The website is still
Hi Vjeran,
Thanks! I'm glad you're liking it. The namespace in the current REPL is
displayed at the top of the window, in the REPL tab name.
Cheers,
Colin
On 9 October 2013 07:52, vmarci...@gmail.com wrote:
Congratulations!
EAP looks promising - its already much better than La Clojure. I
Right, there should be no problem doing this - pretty much all the
editors/IDEs out there start an external process for the REPL server, and
it should be able to use any Clojure version you like, independently of the
version used by the IDE itself.
On 9 October 2013 08:21, Cedric Greevey
UTC+2, Colin Fleming wrote:
Hi Vjeran,
Thanks! I'm glad you're liking it. The namespace in the current REPL is
displayed at the top of the window, in the REPL tab name.
Cheers,
Colin
On 9 October 2013 07:52, vmar...@gmail.com wrote:
Congratulations!
EAP looks promising - its already
Yup, it's true. I suffer from this as well. When I'm compiling Cursive
normal compilation fails because a bunch of the IntelliJ classes assume the
IntelliJ platform is running and barf if it's not. I have an awful hack
which is to run the compilation within their test framework which sets up a
and brittle solution since updates to the
real classes would break the mock classes. Definitely interested in ideas
others may have.
On Saturday, October 12, 2013 4:36:31 AM UTC-4, Colin Fleming wrote:
Yup, it's true. I suffer from this as well. When I'm compiling Cursive
normal compilation fails
I've also had a lot of problems with def'ed forms. For example, if I do
this:
(def no-spacing (Spacing/createSpacing 0 0 0 false 0))
Which looks like this:
public static Spacing createSpacing(int minSpaces,
int maxSpaces,
1 - 100 of 350 matches
Mail list logo
