;t find it in the docs.
>
> Thanks,
> Jeff
>
See the find-first function in my cljutils library:
https://github.com/mikera/clojure-utils/blob/master/src/main/clojure/mikera/cljutils/find.clj
Note the initial check to see if the collection is Indexed: if it is then
it is better to search by
You've described almost exactly the state update model used in Ironclad:
https://github.com/mikera/ironclad
I'd strongly suggest taking a look at the Ironclad source if your game is
anything vaguely turn-based / strategic.
Some comments:
- A big, single immutable data structure for
On Wednesday, 22 May 2013 16:46:54 UTC+8, Daniel Wright wrote:
> Thanks everyone for your replies, in particular:
>
> Mikera: Glad to hear we're along the right lines, and thanks for the
> extra advice. I've found your blog series on Alchemy very helpful while
> cons
On Wednesday, 22 May 2013 20:35:01 UTC+8, atkaaz wrote:
> thank you very much, my search has lead me to seeking a lisp that could
> compile to machine code (mainly because i cannot accept the 20-22 sec `lein
> repl` startup time and eclipse/ccw memory consumptions - so I was hoping
> for someth
You might want to consider LibGDX:
https://code.google.com/p/libgdx/
Looks pretty flexible, can do HTML5 games with WebGL as well as Android,
iOS and desktop. It's also Java based so should be pretty easy to use from
Clojure.
On Friday, 24 May 2013 17:22:20 UTC+8, JvJ wrote:
>
> I'm thinking o
On Wednesday, 29 May 2013 02:19:41 UTC+8, Brian Craft wrote:
> Are there any existing libs for the evaluation of math expressions? For
> example, if the user enters "x + sin(y)", parse and evaluate the
> expression, given vectors of floats for x and y.
You can evaluate expressions like this ri
anyone fancies taking
that on, I'd be happy to support.
On Thursday, 30 May 2013 06:19:02 UTC+8, Brian Craft wrote:
>
> This looks useful. Is it tied to jvm?
>
> On Tuesday, May 28, 2013 6:21:30 PM UTC-7, Mikera wrote:
>>
>> On Wednesday, 29 May 2013 02:19:41 UTC+8, Brian
Hi Dmitry,
One thing I've seen quite frequently in Clojure numerical code is some ugly
code for manipulating Java arrays with areduce / aset / aget etc. It's one
of the few areas where it's genuinely easier to write code in Java at the
moment.
So it would be awesome if the Clojure NDArray coul
My setup is usually:
- Eclipse with Counterclockwise plugin
- Keep an open, running REPL at all times
- Reload namespaces when necessary (Ctrl+Alt+L)
- Run tests with clojure.test from the REPL
This avoids the startup overhead most of the time - I usually only use the
Maven / leiningen comma
Hi Plínio,
At Nuroko, we're using Clojure to develop our machine learning toolkit
(using neural networks). The code is a mix of Clojure and Java.
Some of our tools have public source code here: https://github.com/nuroko
Mike.
On Monday, 10 June 2013 22:47:25 UTC+1, Plinio Balduino wrote:
>
frameworks such as JUnit.
I maintain a small library cljunit ( https://github.com/mikera/cljunit )
which enables me to run clojure.test tests via JUnit in Eclipse, which is
extremely convenient. It would be great if this kind of functionality could
be included in future Clojure testing frameworks
Hi Jason,
Have you guys taken a look at core.matrix for any of this stuff? We're also
shooting for near-Java-parity for all of the core operations on large
double arrays.
(use 'clojure.core.matrix)
(require '[criterium.core :as c])
(let [a (double-array (range 1))]
(c/quick-bench (
On Friday, 14 June 2013 14:46:37 UTC+1, Erlis Vidal wrote:
> Hi,
>
> I'm a bit curious to know in what OS do you code. Do you prefer iOS,
> Linux, Windows? Why is that? Because the tools? The environment?
>
> Thanks!
>
I prefer Linux for the server side. Lean, fast, great tools, open source.
On Friday, 14 June 2013 18:15:34 UTC+1, Jason Wolfe wrote:
> Hey Mikera,
>
> I did look at core.matrix awhile ago, but I'll take another look.
>
> Right now, flop is just trying to make it easy to write *arbitrary*
> array operations compactly, while minimizing the cha
Clojure uses JIRA as an issue tracker:
http://dev.clojure.org/jira/browse/CLJ
See also the contributing guidelines: http://clojure.org/contributing
On Saturday, 15 June 2013 17:05:23 UTC+1, Plinio Balduino wrote:
>
> Hi there
>
> I would like to make a small contribution to Clojure and I would
Not sure who approached you, but I've also been approached by a couple of
companies in this space and they are essentially scams / not serious
publishers. For example, they apparently offer only about 16% royalty to
the author, and do essentially no vetting or quality control. The fact that
the
I agree that negative indexing (and presumably also modulo indexing for the
upper index?) is very useful. Stuff like this comes up all the time in
core.matrix
However I don't think it makes sense as a standard feature in Clojure's
low-level data constructs for several reasons:
a) It's a breakin
On Thursday, 20 June 2013 08:45:47 UTC+1, Jason Wolfe wrote:
>
> On Saturday, June 15, 2013 4:37:06 AM UTC-7, Mikera wrote:
>>
>> On Friday, 14 June 2013 18:15:34 UTC+1, Jason Wolfe wrote:
>>
>>> Hey Mikera,
>>>
>>> I did look at core.matrix awh
Mike or mikera is fine :-)
If you wanted to provide this kind of functionality, I'd normally suggest
doing it with a protocol. Something like:
(defprotocol PWrappedIndex
(get-wrapped [coll index]))
(extend-protocol PWrappedIndex
clojure.lang.Indexed
(get-wrapped [coll index]
It's not really breaking principle of least surprise if you "expect" such
functions to return sequences. A lot of people do expect this after a
little bit of Lisp experience (Clojure or otherwise)
I can see two "advantages" to having many functions return seqs:
- It's a shared abstraction, which
This is cool, thanks Zach!
Another set of mostly-isomporphic types that this could be applied to is
different matrix/array types in core.matrix. core.matrix already has
generic conversion mechanisms but they probably aren't as efficient as they
could be. I'll take a look and see if the same tec
I think that is the only way.
The good news is that this is Clojure, so you can easily wrap it in an
"object-array-cast" macro
On Tuesday, 2 July 2013 15:41:02 UTC+1, Dmitry Groshev wrote:
>
> Hello all.
>
> I have a following deftype:
>
> (deftype NDArray
> [^objects data
> ^long n
Both are somewhat problematic from a performance perspective.
I'd actually be tempted to do this in a "higher order function" style that
returns a compiled construction function for the correct argument types,
e.g. something like
(def double-builder (instantiator Double Long))
(double-builder 2
.
>
> have I completely misunderstood you? can you show a sample/overview of the
> 'instantiator' fn you're referring to?
>
> thanks,
>
> Jim
>
>
> On 04/07/13 13:04, Mikera wrote:
>
> Both are somewhat problematic from a performance perspective.
I really like the as-> macro for this kind of thing.
(as-> (something) x
(if (test1 x) (transform1 x) x)
(if (test2 x) (transform2 x) x)
(do-something-else-with x y)
(if (test3 x) (transform3 x) x))
Advantages:
- It's part of core in 1.5
- It's a macro and com
On Friday, 5 July 2013 16:52:10 UTC+1, Laurent PETIT wrote:
> 2013/7/5 Mikera >:
> > I really like the as-> macro for this kind of thing.
> >
> > (as-> (something) x
> > (if (test1 x) (transform1 x) x)
> > (if (test2 x) (transfo
My post "The Environment as a Value" might be of interest to you.
https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ
It contains a lot of similar ideas. An important point is that you don't
necessarily need an interpreter to get th
First of all, great post and a lot of great points.
I feel your pain, because I also find myself struggling a lot to make
idiomatic code fast in Clojure. Often I end up being forced to use some
pretty ugly tricks to get the performance I need. Sometimes I just end up
coding inner loops in Java
On Tuesday, 9 July 2013 17:31:21 UTC+1, puzzler wrote:
> On Tue, Jul 9, 2013 at 8:11 AM, Alexander Gunnarson <
> alexander...@gmail.com > wrote:
>
>> My idea, which is probably very naive, but one which I'm curious about,
>> is:
>>
>> *Is it possible to have some sort of set of automatic-optimizi
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,
>
> For your mutable var loop example, I think with-local-va
You could use ereduce (elementwise reduce) in core.matrix to do this.
Something like:
(let [NaN Double/NaN
[sum n] (ereduce
(fn [[acc cnt] x] (if (Double/isNaN x) [acc cnt] [(+ acc
x) (inc cnt)]))
[0 0]
[0.0 1.0 NaN 2.0 NaN 3.0 4.
Hmmm it seems to work for me:
(+ 5 (matrix [1 2 3]))
=> #
What environment and what versions of vectorz-clj / Clojure are you using?
Some of the older versions didn't support scalar to vector broadcasting so
that might be the problem
On Thursday, 11 July 2013 00:44:46 UTC+1, Brian Craft wr
Element types are dependent on the implementation. Some implementations
support arbitrary (Object) data types - this includes the default
implementation that supports Clojure persistent vectors, e.g. [1 nil :foo]
is a valid vector. Mathematical operations on such vectors use standard
functions
;0.8.0"]
> [net.mikera/vectorz-clj "0.10.0"]
>
>
> On Wednesday, July 10, 2013 5:40:41 PM UTC-7, Mikera wrote:
>>
>> Hmmm it seems to work for me:
>>
>> (+ 5 (matrix [1 2 3]))
>> => #
>>
>> What environment and what versi
This is a heavily overloaded naming space - especially when you consider
code.matrix as well, and usage of these words in mathematical / scientific
communities.
Data scientists generally expect a "vector" to be a 1D collection of
numeric values, in the same sense that a "matrix" is a 2D collec
Hi Brian,
I've released a new vectorz-clj version to Clojars which should fix the
problem:
[net.mikera/vectorz-clj "0.11.0"]
Hopefully that works for you!
On Thursday, 11 July 2013 00:44:46 UTC+1, Brian Craft wrote:
>
> Without vectorz:
>
> => (+ 5 (matrix [1 2 3]))
> [6 7 8]
>
> With vectorz:
x27;[mikera.vectorz.core :as vz])
>
> (vz/+ 5 (vec [1 2 3]))
>
>
> ClassCastException java.lang.Long cannot be cast to
> mikera.vectorz.AVector mikera.vectorz.core/clone (core.clj:38)
>
>
> Any suggestions? Is there anything else I need to do to my repl? Am I just
> misusing
thanks!
>
> Is there an element-wise matrix multiply? Maybe I can copy the code for
> the / operator.
>
>
> On Thursday, July 11, 2013 5:57:30 AM UTC-7, Mikera wrote:
>>
>> Hi Brian,
>>
>> I've released a new vectorz-clj version to Clojars whi
?
>
> Thanks!
>
> Patrick
>
> On Thursday, July 11, 2013 9:50:52 AM UTC-4, Mikera wrote:
>>
>> Ah - that is expected behaviour because you are using the specialised
>> vector-only operators in "mikera.vectorz.core". These are fast type-hinted
>>
It sounds like a great project.
I think the challenge will be the making the different pieces fit together
neatly: there are lots of somewhat-overlapping libraries and I don't think
anyone has yet figured out the right way to plug everything together - at
least in the sense that "composability"
If you want to do in in "pure functional style" then I would suggest a
single atom / ref that contains the whole game state (including monsters,
players, map, items etc.)
That's the approach I've taken in the two Clojure games I've written so
far, and it has worked pretty well. You might be int
Do you mean something like (int-array [1 2 3 4])?
This is a cast-like operation that produces a primitive array of ints,
exactly like int[] in Java. You can then use it with array operations like
"aget".
If you want to type-hint int-array parameters then you need to use
something like "^ints"
You can use vectorz-clj if you want fast double[] vector and matrix
operations on the JVM.
https://github.com/mikera/vectorz-clj
It's basically a comprehensive wrapper over almost everything you might
possibly want to do with Java double[] arrays, but wrapped up behind the
core.matrix A
On Tuesday, 23 July 2013 21:55:12 UTC+1, Sean Corfield wrote:
> On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson >
> wrote:
> > On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen
> > >
>
> > wrote:
> >> It complects require and refer ;-)
> > How so?
>
> Because use = require + refer (essentiall
On Tuesday, 23 July 2013 16:50:50 UTC+1, Greg Slepak wrote:
> I think I read somewhere that :use is no longer encouraged, but I could be
> mistaken.
>
> From what I've read, it seems like most people agree that Clojure has too
> many ways of including/importing/referencing/requiring/using thing
On Tuesday, 23 July 2013 19:17:02 UTC+1, Jozef Wagner wrote:
> +1, :use is IMO an antipattern.
>
> I hate it mainly in blogs, where they explain some new API. They :use like
> 3 namespaces and you have to guess which fn is from which ns :)
>
Hmmm perhaps I'm guilty of this.
But I find code muc
Two more releases in the ongoing crusade to bring top-class numerical
computing facilities to Clojure:
https://github.com/mikera/matrix-api
https://github.com/mikera/vectorz-clj
Key contents:
- New API function "fill!"
- First version of Dmitry's generic NDArray implementatio
This looks very useful - thanks Zach!
On Thursday, 25 July 2013 03:05:05 UTC+1, Zach Tellman wrote:
>
> https://github.com/ztellman/byte-transforms
>
> This is just a thin wrapper over byte-streams [1] and some best-in-class
> hashing and compression algorithms, but I figure there are at least a
Hi all,
We're having a design discussion in the Numerical Clojure group about how
to extend core.matrix to efficiently handle arrays of arbitrary scalar
types (out of which complex numbers represent the canonical and perhaps
most important case)
If this is an important or interesting topic for
On Saturday, 27 July 2013 03:59:55 UTC+1, Jeremy Heiler wrote:
> On July 26, 2013 at 10:39:47 AM, Jürgen Hötzel
> (jue...@hoetzel.info)
> wrote:
>
> I did some memory profiling on a Clojure Application.
>
> I wondered why 361000 clojure.lang.Symbols exist.
>
> So I did some object browsing on th
I'm always a little amused when people highlight the fragmentation of tools
as a problem, and their solution is to propose a new tool.
Just joking :-) .
Of course I'd never want to discourage innovation and investment in the
Clojure tools space. I'm one of the people who likes my tools to be O
On Monday, 29 July 2013 21:20:49 UTC+1, Joel Holdbrooks wrote:
>
> I spent some time this weekend writing a little tool for generating
> regular expressions *from known inputs*. My goal is to produce regular
> expressions that backtrack as few times as possible along with a complete
> and total
hing factor).
https://github.com/mikera/mikera/blob/master/src/main/java/mikera/engine/PersistentTreeGrid.java
It's actually a 3D grid, but you can use just 2 dimensions and keep the 3rd
set to zero.
On Friday, 2 August 2013 01:59:40 UTC+1, JvJ wrote:
>
> I'm looking for an as
I don't think there is currently a way to do this that is simultaneously:
1) Generic (dispatches on the type of all arguments)
2) Extensible (can be extended to new types at runtime)
3) Fast (about as fast as JVM dispatch allows)
Protocols give you 2) and 3). Multimethods give you 1) and 2). Custo
On Monday, 5 August 2013 09:40:04 UTC+1, Korny wrote:
> Agree that :use should be deprecated, mostly as it's quite a barrier to
> folks new to the language that you need to know 3 different parts of the ns
> macro before you start.
>
I really don't think :use was ever a significant problem for n
On Monday, 5 August 2013 11:35:22 UTC+1, Phillip Lord wrote:
> Anthony Grimes > writes:
> > I can't think of a single good reason to not deprecate :use. :require
> can
> > do everything :use could do now.
>
> Wait for it, wait for it
>
> > This isn't about whether or not (:use ..) without
On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote:
> The only time I've seen :as lead to ugly code was when it was in a DSL
> that would probably have been nicer to use if it was a data-based DSL like
> Hiccup rather than code-based.
>
It's pretty ugly to use aliases for numerical c
I'd suggest avoiding macros until you absolutely know that you need them.
Usually they aren't necessary.
Prefer writing pure functions (without side effects) - these are easier to
reason about, easier to test, simpler to write correctly and easier to plug
together / compose via higher order fun
ypes).
Store this in either an atom, an agent or a ref (depending on how you want
to handle concurrent access and updates - typically an atom is sufficient
unless you care about transactional updates to this state)
>
>
>
> On Thu, Aug 8, 2013 at 2:36 AM, Mikera
> > wrote:
&
on't know how to
>> capitalize on this rather abstract and vague notion.
>>
>> How do folks usually go about it when they have a desire to query the
>> running system about its shape and structure?
>>
>>
>>
>> On Thu, Aug 8, 2013 at 2:36 AM, Mi
them out.
>
One is Ironclad - a steampunk themed strategy game:
http://www.mikera.net/ironclad/ or https://github.com/mikera/ironclad
The other is Alchemy, a 7-day Roguelike game:
https://github.com/mikera/alchemy
Both are somewhat interesting from technical perspective in the sense that
th
On Monday, 12 August 2013 15:52:53 UTC+8, Răzvan Rotaru wrote:
> Hi,
>
> I'm curious about the general opinion on the Clojure syntax, whether
> people actually like it or just use it because it provides macros. So I
> would like to ask you to participate in a poll. Thank You.
>
>
The importance
Hi all,
I'm experimenting with core.async. Most of it is exceptionally good, but
bit I'm finding it *very* inconvenient that nil can't be sent over
channels. In particular, you can't pipe arbitrary Clojure sequences through
channels (since sequences can contain nils).
I see this as a pretty b
. I'd be curious to here what Rich & team
> considered and how they're thinking about it. However, my expectation is
> that the nil approach won't change, since it's pretty much good enough.
>
> On Thursday, August 15, 2013 10:44:48 PM UTC-4, Mikera wrote:
>&g
further wrapping.
>
> Sent from my iPhone
>
> On Aug 17, 2013, at 5:48 PM, Mikera >
> wrote:
>
> My overall sense is that the convenience of using if-let directly in a few
> use cases doesn't justify making channels fall short of being able to send
> arbitrary
I prefer to use closures / higher order functions that return a function.
Reasons:
- You typically get much better performance by returning a closure.
"partial" uses "apply", which adds a lot of overhead
- It can result in cleaner user code (partials require a bit of mental
decoding, and you can
I think a regular "let" is clearer in this kind of case.
"as->" suggests to me that multiple rebindings will happen to the name: if
that is not happening then it is confusing for readers IMHO.
The only case I can think of where "as->" makes sense and the binding only
happens once is if you are
I've found the requirement to define things in order to be a major pain in
the following reasonably common situation:
A) public API in one namespace
B) various functions used to implement public API in another namespace
A clearly depends on B. But B often needs to depend on A also: you
typicall
There's a way to reconcile all of this: if you treat the "environment as a
value" then I believe you can achieve both:
- Incremental REPL-style commands that work immediately in the current
environment
- Arbitrary declaration order in files
>From a technical perspective, the environment would c
It's an old style type hint, indicating that the function returns a value
of class "Server" (the full Java class name is probably in an :import
declaration at the top of the file)
The new style of type hint is just "^Server".
Both forms of type hint still work at present, but you should prefer
Good stuff Zach - I've certainly wanted something like this on various
occasions.
Some comments:
- core.matrix will also work with clj-tuple (because they support ISeq)
- If you made the tuples support IPersistentVector I think they would be
even more useful: it's helpful I think to see tuples
Nice idea Jozef!
Hmmm this is another example of why nil-as-end-of-channel is a slightly
problematic design decision for core.async: it makes this kind of code much
more fiddly.
On Monday, 26 August 2013 01:47:14 UTC+8, Jozef Wagner wrote:
>
> Hi,
>
> A distinctive feature of reducers is th
JarClassLoader looks cool
Aren't there some pretty severe licensing restrictions though? Looks like
it is GPLv3 or commercial license only from the website, which rules it out
of most EPL projects I think
On Tuesday, 27 August 2013 03:50:10 UTC+8, Alex Fowler wrote:
>
>
> hi, nativot is a l
Well, that's certainly a good explanation of why core.async works the way
it does now - it's a natural and sensible starting point to build on Java
Queues.
I don't think that this necessarily implies that we have to follow this
model in the future Clojure API though. The Java designers didn't a
Looks very interesting, thanks for sharing!
Could you summarise how this fits in the ecosystem relative to Storm, Aleph
etc? When should EEP be the most appropriate choice?
On Saturday, 31 August 2013 05:02:27 UTC+8, Michael Klishin wrote:
>
> On behalf of the ClojureWerkz team [1], I'm happy to
It would be better, I think, if metadata was attachable via a protocol
rather than than a wrapper: then you could just extend the protocol to any
arbitrary Java class. Wrappers are a pain to make work because of wrapping
/ unwrapping and protocols also have the advantage of being very efficient.
lso 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 >wrote:
>
>> It would be better, I think, if metadata was attachable via a pro
I was actually thinking of the case where the metadata was computed in some
way from the Java object (i.e. when it is more like read-only property). In
most of the cases where I have wanted metadata on arbitrary Java objects,
this would have been sufficient.
You probably want to go the wrapper
On Wednesday, 4 September 2013 10:00:42 UTC+8, Brian Craft wrote:
> I'm loading data files of about 1-2G, which are composed of a bunch of
> numeric data blocks. I need to store the data blocks w/o storing
> duplicates. They arrive as vectors of floats, and are stored as primitive
> byte arrays
On Wednesday, 4 September 2013 12:37:33 UTC+8, Brian Craft wrote:
>
>
>
> On Tuesday, September 3, 2013 9:14:30 PM UTC-7, Mikera wrote:
>>
>> On Wednesday, 4 September 2013 10:00:42 UTC+8, Brian Craft wrote:
>>
>>> I'm loading data files of
On Friday, 2 August 2013 12:28:51 UTC+8, CGAT wrote:
> My understanding of == is that it is intended to establish numerical
> equivalence
> across types. But I think that basic contract fails with BigDecimal. For
> instance,
>
> (== 1M 1.0M) ; => false
>
> because the scale properties of
On Wednesday, 4 September 2013 13:19:16 UTC+8, Mikera wrote:
> On Friday, 2 August 2013 12:28:51 UTC+8, CGAT wrote:
>
>> My understanding of == is that it is intended to establish numerical
>> equivalence
>> across types. But I think that basic contract fails
Hi all,
While building the API for core.matrix, I've fun into a few cases where the
"best" name is a direct clash with clojure.core.
Examples are "+", "zero?", "vector?", "=="
In many of these cases, the core.matrix behaviour is a natural extension of
the clojure.core function (i.e. it extends
lob/master/src/primitive_math.clj#L154
> [2]
> https://github.com/ztellman/primitive-math/blob/master/src/primitive_math.clj#L135
>
> On Wednesday, September 4, 2013 6:22:08 PM UTC-7, Mikera wrote:
>>
>> Hi all,
>>
>> While building the API for core.matrix, I&#x
and not spit out warnings.
And in my view (:use clojure.core.matrix) is already being very explicit:
our user wants to write numerical code in this namespace, and would like to
have all the relevant functions available :-)
>
> Sean
>
> On Wed, Sep 4, 2013 at 6:22 PM, Mikera >
Counterclockwise is great and it's definitely very actively developed.
Laurent does a fantastic job and is very responsive.
Perhaps you should be looking at the current GitHub tree rather than the
old Google Code one?
- https://github.com/laurentpetit/ccw/commits/master
On Friday, 6 September
On Friday, 6 September 2013 03:15:40 UTC+8, Sean Corfield wrote:
> On Wed, Sep 4, 2013 at 11:25 PM, Mikera >
> wrote:
> > I remember the debates :-) and I don't think there was anything like a
> > consensus that "don't do that" is the right answer.
>
On Friday, 6 September 2013 02:30:22 UTC+8, Armando Blancas wrote:
> I just think the default behaviour should be super-friendly and not spit
>> out warnings.
>>
>
> If other libs also redefine any of those operators or names, now or in
> later versions, I'd be glad to know. With last-one-in-w
+1 for supporting all the JVM primitive types properly.
It is worth noting that the benefits would extend much further than just
OpenGL, e.g.:
- int is a commonly used type in Java interop. Casting to/from it all the
time is a minor annoyance/overhead
- int is the type used for array indexing
recieve a boxed Object and thus cannot
> use == for comparison.
>
> JW
>
>
> On Mon, Sep 9, 2013 at 6:02 PM, Mikera
> > wrote:
>
>> +1 for supporting all the JVM primitive types properly.
>>
>> It is worth noting that the benefits would extend much f
state at all - you can launch several totally independent
game instances from the same REPL. If you are interested, see the "launch"
code at the bottom of this file:
https://github.com/mikera/alchemy/blob/master/src/main/clojure/mikera/alchemy/main.clj
On Tuesday, 10 September 2013 15:19:35 UTC
lised 2D and 3D transformation matrices (rotations, scaling etc.)
- Affine transformations
- core.matrix fully supported (which gives you a lot of more general
matrix/vector features with a nice Clojure API)
See: https://github.com/mikera/vectorz-clj
And core.matrix: https://github.com/mikera/matrix-api
On Friday, 13 September 2013 00:07:03 UTC+8, Christophe Grand wrote:
> As others have already said: long & double only is a restriction for
> function args. Not for interop. Not for local computations. Not for args to
> definterface methods. The reason for this restriction is the combinatorial
People *have* run into this problem a lot. People have just worked around
it. The existence of great libraries like HipHip and vectorz-clj and some
of Zach's stuff is IMHO to a large extent because people have needed high
performance operations (often involving primitives / primitive arrays /
c
tter, IMHO, than forever accepting semantics that
prevent idiomatic code from ever being truly fast. I'd rather see a bit of
breakage and fix my code when upgrading to Clojure 2.0 than be stuck with
poor performance forever.
>
> Timothy
>
>
> On Thu, Sep 12, 2013 at 8:41
namic var deref, but gain better runtime
performance and the ability to use arbitrary types / primitives (which
solves the OP's problem).
This limited-scope proposal won't effect any existing dynamic usage, so
people who like their fully mutable vars with their dynamic lookups can
kee
roposal
> needs to have a working prototype, to prove that these ideas actually work,
> until then proposals don't do much at all. Personally I don't see how the
> ideas in this proposal would work from the repl, and the repl is where most
> people do their work.
> On Sep
roposal
> needs to have a working prototype, to prove that these ideas actually work,
> until then proposals don't do much at all. Personally I don't see how the
> ideas in this proposal would work from the repl, and the repl is where most
> people do their work.
> On Sep
g your tool in by changing a single line setting the underlying
>> implementation 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 &quo
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
1 - 100 of 368 matches
Mail list logo
