Re: Clojure, floats, ints and OpenGL

[Mikera]

Hi Alex,

Just one more thing to think about: Dmitry Groshev has been doing some good 
early work on Clojure float support in the core.matrix NDArray 
implementation (basically a NumPy-style multidimensional array 
implementation backed by a single large float[] array).

The per-object overhead is probably too high for it to be useful as a 
Vertex3f replacement, but it might fit some of your use cases, particularly 
when you have a large number of float values to manipulate at the same time 
(physics, wave simulation, mesh deformation etc). It avoids the current 
Clojure limitations on float function arguments by using custom macros to 
compile all the inner loops. Quite clever stuff.

  Mike.

On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>
> Hello!
>
> With this letter I would like to receive an answer from somebody from the 
> development team (if anyone else has something to say, you're surely 
> welcome :) ).
>
> I am working for a big multimedia company and recently I have been 
> considering moving to Clojure as the main language of development. We have 
> been doing Java and Scala before, but now when I tried Clojure and see the 
> possibilities it provides, I would definitely stand for it to be our 
> ground. However, while I am so satisfied with everything - the language, 
> the community, the Java interop, there is still something that hinders and 
> makes me linger. Namely, the lack of good support of floats and ints in the 
> language. While many people would not consider it to be a huge disadvantage 
> or even notice it, things are not so bright when it comes to OpenGL.
>
> The case is that OpenGL and 3D graphics hardware in general has no support 
> for doubles or longs. Therefore, all libraries, all data and all 
> computations are meant to be performed with floats and ints (shaders too). 
> Due to the lack of good support of these data types in Clojure (for 
> example, there are no ^float and ^int typehints, float and int values can 
> only be typecasted to, all calculations always retain doubles and longs), 
> results in too many extra typecasts, which are absolutely unnecessary and 
> take too much time. So, calculations become very cumbersome, even if we do 
> not take mandatory boxing into account.
>
> Considering that such kinds of calculations are usually abuntant in the 
> aforementioned types of applications, the penalty grows really huge. I have 
> endeavoured several discussions on the IRC to find out possible 
> workarounds. Although many good proposals by many good people were made, 
> aimed at improving the situation, none of them could solve the fundamental 
> lack of the ability to manipulate 32bit primitive (or even boxed) data 
> types. That lack renders Clojure not really suitable for heavy-load OpenGL 
> applications that require somewhat extensive calculations: some kinds of 
> games, simulations, generative graphics and so on. Considering how superior 
> Clojure is to any other language available for JVM, that black spot looks 
> especially embarrasing. And I could imagine falling back to Java for fast 
> computations, just like we fall back to ASM in, say C, that is very 
> undesirable and discouraging, since we want to pick Clojure for Clojure and 
> it will be too cumbersome to make 50/50% Java/Clojure apps just to work 
> around that design decision.
>
> Therefore, while deciding if to pick Clojure as the base for our 
> development, I would like to know answers to the following questions:
>
> 1) What is the current reason for the support for these types to be 
> missing?
> 2) Are there any plans for improvement of support for floats, ints and 
> maybe, localized unboxed calculations? Or is there some advice on how to 
> enable their support?
> 3) What is you vision for Clojure + OpenGL applications?
> 4) Is it possible to request support for floats, ints and maybe shorts for 
> the language?
> 5) Is it possible to request support for localized unboxed calculations, 
> like (with-unboxed ... ) and localized float-only and int-only 
> calculations, like, say in special macros (with-floats-&-ints ... here go 
> (+) (-) and stuff ONLY with floats/ints ... ) ?
>
> Preferably, I would like to hear the answers from somebody from the 
> development team, because I have already received enough support from the 
> community, on the IRC, I appreciate it, but now I have to make a serious 
> choice for our company and I feel quite responsible for that. I also feel 
> that these questions are very important for any specialist that works with 
> OpenGL and influence Clojure acceptance for OpenGL-enabled applications 
> world-wide. Thank you.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@google

Re: Clojure, floats, ints and OpenGL

[Mikera]

On Saturday, 14 September 2013 00:36:05 UTC+8, James Reeves wrote:

> On 13 September 2013 08:54, Mikera  >wrote:
>
>> Either way, if Clojure's semantics prove to be a fundamental issue for 
>> performance, then I think it is better to start work to improve Clojure's 
>> semantics (perhaps targeting 2.0 if we think it's a really big breaking 
>> change). This would be better, 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.
>>
>
> Out of curiosity, what is the performance hit in these cases?
>

Here's a quick highly artificial benchmark I did with Caliper in Java 
(Obviously can't benchmark in Clojure since we don't have proper float 
support)

 0% Scenario{vm=java, trial=0, benchmark=Float} 267222.79 ns; σ=1629.43 ns 
@ 3 trials
50% Scenario{vm=java, trial=0, benchmark=Double} 416110.28 ns; σ=2087.75 ns 
@ 3 trials

benchmark  us linear runtime
Float 267 ===
   Double 416 ==

vm: java
trial: 0

Obviously this is just a microbenchmark, but it fits my general experience 
that floats are a reasonable bit faster than doubles, typically 20-100% 
(doubles are closer when it is pure number crunching since 64-bit CPUs are 
actually pretty good at doubles, floats have a bigger advantage when you 
are manipulating a lot of data points and hence memory bandwidth matters 
more)

Code here for those interested:
src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
 

>
> Floats obviously save memory, and I believe they're also between 15% to 
> 40% more efficient for division, at least on Intel CPUs. Is there also a 
> cost to be paid passing doubles to OpenGL? Do you know what that cost is?
>
>
I'm not exactly an expert in OpenGL, but I would make the following points:
- Many GPU applications are actually memory-bandwidth bound (the compute 
power is insane). So using floats means you can pump through 2x as much 
data to keep your GPUs busy
- Hardware and driver support is usually not on a par with floats, even if 
it is technically supported by the OpenGL API

This is an interesting article to back up the latter point: For example on 
NVidia GeForce hardware doubles are 1/8 the speed of floats
http://blog.hvidtfeldts.net/index.php/2012/07/double-precision-in-opengl-and-webgl/

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The Eclipse Public License is not a good license

[Phillip Lord]

Seriously? Your problem is that a contributor has to state that they
have added something? Why are you worried about this?

Musical Notation  writes:

>> Each Contributor must identify itself as the originator of its Contribution,
>> if any, in a manner that reasonably allows subsequent Recipients to identify
>> the originator of the Contribution.
>
> That's my problem.
>
> On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:
>
>> 
>> This is an interesting thread. I think, though, it repeats what is a
>> misconception about GPL -- that you cannot produce GPL code using
>> Clojure. This isn't true, as far as I can see -- you can write GPL code
>> using any language, because it doesn't usage restrictions in GPL do not
>> percolate through a "standard interface".
>> 
>> So, for instance, my own library is covered by LGPL; it is possible to
>> link this to GPL code without problems.
>> 
>> Historically, the first GPL products (Emacs for example) were built
>> using on non GPL platforms; it is the same issue.
>> 
>> Sean Corfield  writes:
>>> Searching the archives would have turned up some _long_ threads about
>>> this where it would have been clear that the license is not going to
>>> change - as well as explaining why it is the way it is. For example:
>>> https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from
>>> 2008)
>>> 
>>> Sean
>>> 
>>> On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis
>>>  wrote:
 I think that Clojure should switch to a better license with similar spirit
 like Apache 2.0, BSD, or MIT.
 While the EPL doesn't have the evil "copyleft" requirement of GPL, and
 therefore allows and encourages commercial uses of the code, it has a
 requirement that makes it incompatible with the GPL: If you create modified
 versions of EPL-covered software, you must slap your name (or any other
 identity) on it. In my humble opinion, this restriction isn't justified.
 (All, or most, creators of modified versions will do that anyway). It may
 have been chosen uncarefully. Other permissive licenses better fulfill Rich
 Hickey's spirit.
>> 
>> -- 
>> -- 
>> 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 patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: ClojureScript 0.0-1885 (Source maps!)

[David Nolen]

Nicola Mometto also deserves quite a bit of credit, the fact that
tools.reader emits line and column information on all symbols is essential
for the accuracy of ClojureScript source maps.


On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga  wrote:

> I'm so happy for this, I've been subscribed to that issue on Jira for a
> while now, and here it is, alive and working! Just ran some demo code and
> it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you
> know about any bugs I find.
> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> >
> > The biggest change in this release thanks to Sean Grove - much improved
> source maps. You can provide a :source-map option to the compiler to name
> the source map file. Feedback on this significant enhancement welcome.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > New release version: 0.0-1885
> >
> >
> > Leiningen dependency information:
> >
> > [org.clojure/clojurescript "0.0-1885"]
> >
> >
> >
> >
> > Enhancements:
> >
> > * Accurate source maps!
> >
> >
> > Changes:
> >
> > * cljs.core/format based on goog.string/format backed out
> > * set-print-fn! no longer exported
> >
> >
> >
> > Fixes:
> > * CLJS-588: allow upstream :foreign-libs to be used
>
> --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The Eclipse Public License is not a good license

[Softaddicts]

Being filed by the NSA ? Oups, too late :)

Luc P.

> 
> Seriously? Your problem is that a contributor has to state that they
> have added something? Why are you worried about this?
> 
> Musical Notation  writes:
> 
> >> Each Contributor must identify itself as the originator of its 
> >> Contribution,
> >> if any, in a manner that reasonably allows subsequent Recipients to 
> >> identify
> >> the originator of the Contribution.
> >
> > That's my problem.
> >
> > On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) 
> > wrote:
> >
> >> 
> >> This is an interesting thread. I think, though, it repeats what is a
> >> misconception about GPL -- that you cannot produce GPL code using
> >> Clojure. This isn't true, as far as I can see -- you can write GPL code
> >> using any language, because it doesn't usage restrictions in GPL do not
> >> percolate through a "standard interface".
> >> 
> >> So, for instance, my own library is covered by LGPL; it is possible to
> >> link this to GPL code without problems.
> >> 
> >> Historically, the first GPL products (Emacs for example) were built
> >> using on non GPL platforms; it is the same issue.
> >> 
> >> Sean Corfield  writes:
> >>> Searching the archives would have turned up some _long_ threads about
> >>> this where it would have been clear that the license is not going to
> >>> change - as well as explaining why it is the way it is. For example:
> >>> https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from
> >>> 2008)
> >>> 
> >>> Sean
> >>> 
> >>> On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis
> >>>  wrote:
>  I think that Clojure should switch to a better license with similar 
>  spirit
>  like Apache 2.0, BSD, or MIT.
>  While the EPL doesn't have the evil "copyleft" requirement of GPL, and
>  therefore allows and encourages commercial uses of the code, it has a
>  requirement that makes it incompatible with the GPL: If you create 
>  modified
>  versions of EPL-covered software, you must slap your name (or any other
>  identity) on it. In my humble opinion, this restriction isn't justified.
>  (All, or most, creators of modified versions will do that anyway). It may
>  have been chosen uncarefully. Other permissive licenses better fulfill 
>  Rich
>  Hickey's spirit.
> >> 
> >> -- 
> >> -- 
> >> 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 patient with 
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> --- 
> >> You received this message because you are subscribed to the Google Groups 
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> > -- 
> 
> -- 
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   twitter: phillord
> NE1 7RU 
> 
> -- 
> -- 
> 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 patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit 

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-1885 (Source maps!)

[Sean Grove]

Yeah, tools.reader is amazing. Honestly the source map patch was just a bit
of glue between David's existing work and integrating tools.reader, the
bulk of the results are due to them.


On Mon, Sep 16, 2013 at 2:31 PM, David Nolen  wrote:

> Nicola Mometto also deserves quite a bit of credit, the fact that
> tools.reader emits line and column information on all symbols is essential
> for the accuracy of ClojureScript source maps.
>
>
> On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga wrote:
>
>> I'm so happy for this, I've been subscribed to that issue on Jira for a
>> while now, and here it is, alive and working! Just ran some demo code and
>> it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you
>> know about any bugs I find.
>> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
>> > ClojureScript, the Clojure compiler that emits JavaScript source code.
>> >
>> >
>> >
>> > The biggest change in this release thanks to Sean Grove - much improved
>> source maps. You can provide a :source-map option to the compiler to name
>> the source map file. Feedback on this significant enhancement welcome.
>> >
>> >
>> > README and source code: https://github.com/clojure/clojurescript
>> >
>> >
>> > New release version: 0.0-1885
>> >
>> >
>> > Leiningen dependency information:
>> >
>> > [org.clojure/clojurescript "0.0-1885"]
>> >
>> >
>> >
>> >
>> > Enhancements:
>> >
>> > * Accurate source maps!
>> >
>> >
>> > Changes:
>> >
>> > * cljs.core/format based on goog.string/format backed out
>> > * set-print-fn! no longer exported
>> >
>> >
>> >
>> > Fixes:
>> > * CLJS-588: allow upstream :foreign-libs to be used
>>
>> --
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure, floats, ints and OpenGL

[Tim Visher]

Hi Mikera,

I don't have a whole lot of skin in this game as, unfortunately, I
haven't run into any performance bottlenecks that I couldn't fix in a
satisfying way whilst writing Clojure.

My impression, however, is that there are some people in the community
who feel the performance limitations of some of Clojure's core design
decisions.

I've been following this discussion as it's going on and it seems like
it's winding down in the same way I've watched many such discussions
wind down in the past: "Can we please get an official word from Rich
whether this would be worth someone's time?"

That's usually where these things die.

So have you considered writing up a more formal proposal, maybe with
some very rough sketches of how you might envision implementing
things, and actually sending it to Rich (or maybe at this point Alex
Miller)? Ideally this wouldn't be something as time consuming as a
full prototype but would be more than just some thoughts scratched out
on mail.

I think he basically doesn't read this list or visit IRC anymore and
getting heard here on something like design directions for Clojure
seems like a fool's errand.

Anyway, I like being able to follow these discussions on the mailing
list and I think the mailing list is still a good place to gauge
interest and get some thoughts on design direction (Timothy's been
doing a great job lately of bringing up edge cases that may not have
been considered), but I think you'll probably never see an official
word on Clojure here.

Keep up the good work!

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Cognitect

[Rich Hickey]

I just wanted to let everyone know that Metadata Partners (the company behind 
Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This 
merger is great for Clojure, adding considerable resources and stability to its 
development and support, including new enterprise support offerings and 
reinvigorated community support. (You should read the hiring of Alex Miller as 
the first example of the latter).

I hope the availability of enterprise support for the entire platform makes it 
easier for people to introduce Clojure into their organizations.

This is a very exciting time for Clojure and the platform and ecosystem 
surrounding it. You can find out more at:

http://cognitect.com

Thanks,

Rich

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Cognitect

[Michael Fogus]

Rich and Relevance,

This is very exciting news for the Clojure community (and yourselves
I'm sure).  I for one look forward to seeing how you rock our worlds.

On Mon, Sep 16, 2013 at 9:50 AM, Rich Hickey  wrote:
> I just wanted to let everyone know that Metadata Partners (the company behind 
> Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This 
> merger is great for Clojure, adding considerable resources and stability to 
> its development and support, including new enterprise support offerings and 
> reinvigorated community support. (You should read the hiring of Alex Miller 
> as the first example of the latter).
>
> I hope the availability of enterprise support for the entire platform makes 
> it easier for people to introduce Clojure into their organizations.
>
> This is a very exciting time for Clojure and the platform and ecosystem 
> surrounding it. You can find out more at:
>
> http://cognitect.com
>
> Thanks,
>
> Rich
>
> --
> --
> 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 patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
-- http://blog.fogus.me
-- http://github.com/fogus
--

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Cognitect

[Paul deGrandis]

Congrats!  This is great news all around!

Paul


On Monday, September 16, 2013 6:50:46 AM UTC-7, Rich Hickey wrote:
>
> I just wanted to let everyone know that Metadata Partners (the company 
> behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, 
> Inc. This merger is great for Clojure, adding considerable resources and 
> stability to its development and support, including new enterprise support 
> offerings and reinvigorated community support. (You should read the hiring 
> of Alex Miller as the first example of the latter). 
>
> I hope the availability of enterprise support for the entire platform 
> makes it easier for people to introduce Clojure into their organizations. 
>
> This is a very exciting time for Clojure and the platform and ecosystem 
> surrounding it. You can find out more at: 
>
> http://cognitect.com 
>
> Thanks, 
>
> Rich

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Cognitect

[Joe Smith]

Exciting!

---
Joseph Smith
j...@uwcreations.com
@solussd






On Sep 16, 2013, at 8:50 AM, Rich Hickey  wrote:

> I just wanted to let everyone know that Metadata Partners (the company behind 
> Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This 
> merger is great for Clojure, adding considerable resources and stability to 
> its development and support, including new enterprise support offerings and 
> reinvigorated community support. (You should read the hiring of Alex Miller 
> as the first example of the latter).
> 
> I hope the availability of enterprise support for the entire platform makes 
> it easier for people to introduce Clojure into their organizations.
> 
> This is a very exciting time for Clojure and the platform and ecosystem 
> surrounding it. You can find out more at:
> 
> http://cognitect.com
> 
> Thanks,
> 
> Rich
> 
> -- 
> -- 
> 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 patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Memory leak problem

[Joachim De Beule]

Dear List,

I'm experiencing a memory leak and I don't understand why.

I have a bunch of 50 files on disk called "data-1.edn" through 
"data-50.edn". I perform the following code:

(def all-processed-data (reduce (fn [ret f] (merge ret (process-data 
(clojure.tools.reader.edn/read-string (slurp f) {} file-list))

"file-list" is a sequence of java.io.File objects pointing towards the 50 
data files.
"process-data" is a function that produces a map from the data read.

Although each individual datafile is about 100 Megabytes, the result of 
processing a datafile is a map of about 200k only, so that the map returned 
by the entire above expression is only about 10 Megabytes. Nevertheless, 
executing the above code fills up memory and eventually stops clojure from 
functioning. Why?

Thanks a lot for any suggestions!

Joachim.

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Building Trees

[Peter Mancini]

That is along the lines of my thinking. I am starting to look at zippers 
again. However much of what I need it to do either isn't documented at all 
or it was never intended to construct trees over time.

The purpose of this is to look at sequenced events and detect frequent 
patterns. These patterns can have variations. It is built from the top down 
with the most frequent events added first, the 2nd most added second, etc. 
What ends up happening is that I see A-B-C-D a lot, for example, but I also 
see A-B-D-F sometimes. I see B-D-E-F-G rarely. So what I want to do is keep 
track of each of these. The first two are variations of each other stemming 
after A-B. What I want to do is to be able to look at D and see what events 
often precede it. I see that in all of my data A, B and C precede it. 
However just by examining the counts I can determine that C does not occur 
more than random chance so I can drop that and return B, A as my set, in 
that order because I see B preceeding more than A. Big Whoop you say. But 
now lets apply this to some interesting situations. Let's say that instead 
of letters we have topics. D is part of some greater topic concept. I want 
to know what other topics predict the existence of D such that if I see 
them I think that its possible they imply D. B and A do this, according to 
this analysis. So when I tell my search engine I'm interested in D it will 
also search for B and A knowing that while D isn't mentioned by name, there 
is a possibility it is implied when B or A are present.

Concrete example. I want documents that talk about "automobiles." 
Automobile associates with things like "drivers seat" "steering wheel" 
"rear view mirror" but also with "car" "car wash" "Prius" "Ford" and other 
terms. Why is this important? Let's say I don't want a general return of 
information but I am looking for a very specific document. If I don't have 
the right keyword I have to guess. A lot. I may never guess right. So I 
need to be sure my search is augmented properly. That is what this will do. 
However the number of events I will be looking at will be in the hundreds 
of millions and for some data sets will be in the billions or greater. The 
problem will be distributed. However, for today, I just need to get this to 
work on my laptop, with an eye to the future as to how I will get this to 
work on a large network of machines. So far I have loved Functional 
Programming... right up to this problem. This one is killing me. I am going 
to examine the other suggestions here for how to do it. I am certain that 
Clojure is extremely excellent at solving this kind of problem and I am 
becoming more certain I am missing some FP concept that is preventing me 
from tapping into that power!

Solve this problem and Clojure becomes the best platform for large scale 
machine learning out there. My company has 3 complex applications up 
already making money and the bugs are 99% design issues instead of 
something not working in an expected manner. This is really fantastic and 
has me sold that Clojure was a good choice.

--Pete

On Monday, September 9, 2013 4:06:41 PM UTC-5, Laurent PETIT wrote:
>
> This is quite an interesting post, with the underlying question in my 
> mind : where to put the line between pure datastructure manipulation 
> with clojure.core only, and a datalog (datomic)/sql engine ? 
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Memory leak problem

[Andy Fingerhut]

Are you using a version of Java earlier than 7u6?  If so, this *might* be
related to the conversation from a few days ago about functions like subs,
re-find, etc. returning short strings that keep references to the longer
strings they were created from:

https://groups.google.com/forum/#!topic/clojure/PeHTCWNgrL0

Even if you are using such a Java version, I have not confirmed whether the
function clojure.tools.reader.edn/read-string returns substrings of the
input string.

One quick thing to try that might help is to call
clojure.tools.reader.edn/read on the File object f directly, without
calling slurp.  That will at least avoid the behavior of creating big
strings with the entire contents of each file.  It should also avoid the
"small substrings holding references to large original strings", if that is
indeed what you are experiencing.

Andy


On Mon, Sep 16, 2013 at 8:17 AM, Joachim De Beule <
joachim.de.be...@gmail.com> wrote:

> Dear List,
>
> I'm experiencing a memory leak and I don't understand why.
>
> I have a bunch of 50 files on disk called "data-1.edn" through
> "data-50.edn". I perform the following code:
>
> (def all-processed-data (reduce (fn [ret f] (merge ret (process-data
> (clojure.tools.reader.edn/read-string (slurp f) {} file-list))
>
> "file-list" is a sequence of java.io.File objects pointing towards the 50
> data files.
> "process-data" is a function that produces a map from the data read.
>
> Although each individual datafile is about 100 Megabytes, the result of
> processing a datafile is a map of about 200k only, so that the map returned
> by the entire above expression is only about 10 Megabytes. Nevertheless,
> executing the above code fills up memory and eventually stops clojure from
> functioning. Why?
>
> Thanks a lot for any suggestions!
>
> Joachim.
>
> --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ClojureScript] ANN: ClojureScript 0.0-1885 (Source maps!)

[Joe Smith]

I see that clojure.core/format is gone. Is there a replacement/alternative?

---
Joseph Smith
j...@uwcreations.com
@solussd






On Sep 16, 2013, at 7:31 AM, David Nolen  wrote:

> Nicola Mometto also deserves quite a bit of credit, the fact that 
> tools.reader emits line and column information on all symbols is essential 
> for the accuracy of ClojureScript source maps.
> 
> 
> On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga  wrote:
> I'm so happy for this, I've been subscribed to that issue on Jira for a while 
> now, and here it is, alive and working! Just ran some demo code and it looks 
> amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about 
> any bugs I find.
> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> >
> > The biggest change in this release thanks to Sean Grove - much improved 
> > source maps. You can provide a :source-map option to the compiler to name 
> > the source map file. Feedback on this significant enhancement welcome.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > New release version: 0.0-1885
> >
> >
> > Leiningen dependency information:
> >
> > [org.clojure/clojurescript "0.0-1885"]
> >
> >
> >
> >
> > Enhancements: 
> >
> > * Accurate source maps!
> >
> >
> > Changes:
> >
> > * cljs.core/format based on goog.string/format backed out
> > * set-print-fn! no longer exported
> >
> >
> >
> > Fixes:
> > * CLJS-588: allow upstream :foreign-libs to be used
> 
> --
> --
> 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 patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ClojureScript] ANN: ClojureScript 0.0-1885 (Source maps!)

[David Nolen]

Use goog.string.format.

David


On Mon, Sep 16, 2013 at 11:35 AM, Joe Smith  wrote:

> I see that clojure.core/format is gone. Is there a replacement/alternative?
>
> ---
> Joseph Smith
> j...@uwcreations.com
> @solussd
>
>
>
>
>
>
> On Sep 16, 2013, at 7:31 AM, David Nolen  wrote:
>
> Nicola Mometto also deserves quite a bit of credit, the fact that
> tools.reader emits line and column information on all symbols is essential
> for the accuracy of ClojureScript source maps.
>
>
> On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga wrote:
>
>> I'm so happy for this, I've been subscribed to that issue on Jira for a
>> while now, and here it is, alive and working! Just ran some demo code and
>> it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you
>> know about any bugs I find.
>> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
>> > ClojureScript, the Clojure compiler that emits JavaScript source code.
>> >
>> >
>> >
>> > The biggest change in this release thanks to Sean Grove - much improved
>> source maps. You can provide a :source-map option to the compiler to name
>> the source map file. Feedback on this significant enhancement welcome.
>> >
>> >
>> > README and source code: https://github.com/clojure/clojurescript
>> >
>> >
>> > New release version: 0.0-1885
>> >
>> >
>> > Leiningen dependency information:
>> >
>> > [org.clojure/clojurescript "0.0-1885"]
>> >
>> >
>> >
>> >
>> > Enhancements:
>> >
>> > * Accurate source maps!
>> >
>> >
>> > Changes:
>> >
>> > * cljs.core/format based on goog.string/format backed out
>> > * set-print-fn! no longer exported
>> >
>> >
>> >
>> > Fixes:
>> > * CLJS-588: allow upstream :foreign-libs to be used
>>
>> --
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>
>
>  --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Cognitect

[Jeff Heon]

Fantastic news.

Congrats to all involved!

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure, floats, ints and OpenGL

[James Reeves]

On 16 September 2013 09:03, Mikera  wrote:

>
> Obviously this is just a microbenchmark, but it fits my general experience
> that floats are a reasonable bit faster than doubles, typically 20-100%
> (doubles are closer when it is pure number crunching since 64-bit CPUs are
> actually pretty good at doubles, floats have a bigger advantage when you
> are manipulating a lot of data points and hence memory bandwidth matters
> more)
>
> Code here for those interested:
> src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
>

That's a pretty interesting result. I ran some tests of my own, based on
your code, as I wondered whether or not the time to instantiate the array
of doubles was biasing the test. My goal was to see whether or not I'd get
a similar result running an array of floats through a method that processed
doubles. (See: https://gist.github.com/weavejester/6583367)

It turns out that I get a similar result. Passing floats to a method that
takes doubles slows things down by a similar amount, unless I've somehow
botched up the test. Considering that converting between single and double
precision should be pretty cheap on the CPU, I'm surprised at the
difference.

This somewhat changes my view on things. It doesn't affect me in practice,
but I can see how someone might be frustrated by having to drop down to
Java to achieve performance for floating point calculations.

- James

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Memory leak problem

[Brian Craft]

A symptom of this would be jmap or visualvm reporting [C or char[] as the 
largest allocation, by class.


On Monday, September 16, 2013 8:40:27 AM UTC-7, Andy Fingerhut wrote:
>
> Are you using a version of Java earlier than 7u6?  If so, this *might* be 
> related to the conversation from a few days ago about functions like subs, 
> re-find, etc. returning short strings that keep references to the longer 
> strings they were created from:
>
> https://groups.google.com/forum/#!topic/clojure/PeHTCWNgrL0
>
> Even if you are using such a Java version, I have not confirmed whether 
> the function clojure.tools.reader.edn/read-string returns substrings of the 
> input string.
>
> One quick thing to try that might help is to call 
> clojure.tools.reader.edn/read on the File object f directly, without 
> calling slurp.  That will at least avoid the behavior of creating big 
> strings with the entire contents of each file.  It should also avoid the 
> "small substrings holding references to large original strings", if that is 
> indeed what you are experiencing.
>
> Andy
>
>
> On Mon, Sep 16, 2013 at 8:17 AM, Joachim De Beule 
> 
> > wrote:
>
>> Dear List,
>>
>> I'm experiencing a memory leak and I don't understand why.
>>
>> I have a bunch of 50 files on disk called "data-1.edn" through 
>> "data-50.edn". I perform the following code:
>>
>> (def all-processed-data (reduce (fn [ret f] (merge ret (process-data 
>> (clojure.tools.reader.edn/read-string (slurp f) {} file-list))
>>
>> "file-list" is a sequence of java.io.File objects pointing towards the 50 
>> data files.
>> "process-data" is a function that produces a map from the data read.
>>
>> Although each individual datafile is about 100 Megabytes, the result of 
>> processing a datafile is a map of about 200k only, so that the map returned 
>> by the entire above expression is only about 10 Megabytes. Nevertheless, 
>> executing the above code fills up memory and eventually stops clojure from 
>> functioning. Why?
>>
>> Thanks a lot for any suggestions!
>>
>> Joachim.
>>  
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Building Trees

[Mark Engelberg]

Offhand, I'd say this sounds like you need to build a Bayesian network.
I'd recommend taking this course:
https://www.coursera.org/course/pgm
which uses this book:
http://www.amazon.com/Probabilistic-Graphical-Models-Principles-Computation/dp/0262013193

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Building Trees

[Peter Mancini]

Thanks. I authored a paper on building a gaussian-bayes classifier and 
implemented it in clojure. I looked at Titan. That has a lot of things I 
like but it requires named nodes to only exist once. So, that is close but 
not quite what I want. I'm looking at Zippers again.

On Monday, September 16, 2013 1:42:24 PM UTC-5, puzzler wrote:
>
> Offhand, I'd say this sounds like you need to build a Bayesian network.  
> I'd recommend taking this course:
> https://www.coursera.org/course/pgm
> which uses this book:
>
> http://www.amazon.com/Probabilistic-Graphical-Models-Principles-Computation/dp/0262013193
>
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Weird core.async/ClojureScript issues

[David Pollak]

Howdy,

I'm using core.async and ClojureScript and I'm running into a weird
problem... basically if/when/loop constructs don't work anymore in go
blocks in ClojureScript. For example:


-- 
Telegram, Simply Beautiful CMS https://telegr.am
Lift, the simply functional web framework http://liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Weird core.async/ClojureScript not workings...

[David Pollak]

Howdy,

I'm using core.async and ClojureScript and it seems that inside a go block,
if/when/loop/while code is never executed.

For example:

  (def dog33 (go (if true (.log js/console "it's true") (.log js/console
"it's false"

prints neither "it's true" nor "it's false", but

  (def dog33 (go (do (.log js/console "it's true") (.log js/console "it's
false"

prints both.

I'm doing lein cljsbuild auto to generate the JavaScript.

Any pointers would be appreciated.

Thanks,

David

-- 
Brick Alloy http://brickalloy. 
Lift, the simply functional web framework http://liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure, floats, ints and OpenGL

[Alex Fowler]

Timothy, thank you very much for such a good explanation! I fully agree
with you. Actually, except for a few details, that is really how I thought
the things are. It is good that you describe the technical base for
problems with the issue. As well as clearified the human factor. What
you're saying is very much like what I would say if I were in your shoes.
Currently, what you're saying, is the present. In the present we make our
choices for currents. And I also agree with Mikera, that an attempt should
be taken. I would participate in it myself if I was into JVM and Clojure
internals. I plan to learn it, but it will take time.

Mikera, thanks for the reference for the library, I will have a look. Also
I strongly encourage you in the attempt and I will be happy if I can be of
any help, although, you seem to know much more than me. I agree with Tim
that some more decisive steps have to be taken into this direction.

James, ah.. yes, we did benchmarks. We use highly optimized mathematical
calculations, derived from numerical analysis. Every single instruction
matters there. Due to the nature of the calculations, the amout of casts,
however, varies from 3 to N in one computation. There can be 1 to M such
computation for a data unit. And thre can be 1 to P data units. At the end,
what worked on plain Java or Java-stylized Scala, worked that times faster,
NxMxP more instructions to be computed. Where there were 500 fps, sometimes
happen to be 480 fps and sometimes 0.01 fps. And I am not even talking
about operations on vast arrays or NIO buffers. But imagine for example,
you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and
will go back to it. Operation on each float takes, say 5 casts
double<->float in Clojure.

Also, as Mikera points out, bus speeds come into play too.

Of course, as Timothy said, why don't we go back to C for that kind of
stuff? This is a popular question in such cases. I am not going to go into
details on that, except for saying that we have mostly migrated from C to
JVM and it satisfies our requirements, while giving huge benifits. However,
we still do some things in C. To prevent arguments, here is an
article
that
somewhat describes what one can lose in computation, but does not describe
what one gains in other aspects. The loss is what can be tolerated. But
that loss for JVM is understandable. The one more loss for Clojure is
understandable too, but it can be changed. I think that the discussion
branch of Java vs C may be laid to rest.


On Mon, Sep 16, 2013 at 9:03 PM, James Reeves  wrote:

>
>
>
> On 16 September 2013 09:03, Mikera  wrote:
>
>>
>> Obviously this is just a microbenchmark, but it fits my general
>> experience that floats are a reasonable bit faster than doubles, typically
>> 20-100% (doubles are closer when it is pure number crunching since 64-bit
>> CPUs are actually pretty good at doubles, floats have a bigger advantage
>> when you are manipulating a lot of data points and hence memory bandwidth
>> matters more)
>>
>> Code here for those interested:
>> src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
>>
>
> That's a pretty interesting result. I ran some tests of my own, based on
> your code, as I wondered whether or not the time to instantiate the array
> of doubles was biasing the test. My goal was to see whether or not I'd get
> a similar result running an array of floats through a method that processed
> doubles. (See: https://gist.github.com/weavejester/6583367)
>
> It turns out that I get a similar result. Passing floats to a method that
> takes doubles slows things down by a similar amount, unless I've somehow
> botched up the test. Considering that converting between single and double
> precision should be pretty cheap on the CPU, I'm surprised at the
> difference.
>
> This somewhat changes my view on things. It doesn't affect me in practice,
> but I can see how someone might be frustrated by having to drop down to
> Java to achieve performance for floating point calculations.
>
> - James
>
> --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/H5P25eYKBj4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you 

Re: Weird core.async/ClojureScript not workings...

[David Nolen]

Which versions of ClojureScript and core.async are you using?

David


On Mon, Sep 16, 2013 at 5:25 PM, David Pollak  wrote:

> Howdy,
>
> I'm using core.async and ClojureScript and it seems that inside a go
> block, if/when/loop/while code is never executed.
>
> For example:
>
>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
> "it's false"
>
> prints neither "it's true" nor "it's false", but
>
>   (def dog33 (go (do (.log js/console "it's true") (.log js/console "it's
> false"
>
> prints both.
>
> I'm doing lein cljsbuild auto to generate the JavaScript.
>
> Any pointers would be appreciated.
>
> Thanks,
>
> David
>
> --
> Brick Alloy http://brickalloy. 
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>  --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Building Trees

[Jonah Benton]

I find your description interesting but I'm confused about what the actual
underlying problem is- is indexing and searching for data in documents
involved, or is that just an example? If the real problem is about
augmenting large document data set searches with potentially relevant
taxonomic or semantic terms...ok, but I'm not sure what that necessarily
has to do with frequent patterns in sequences/event streams? e.g. because
taxonomic or semantic associations have richer relationships than just
their location in a sequence...

On the other hand, if this is just about extracting sequences from event
streams- if it has to be done live, where you want to incrementally record
distinct sequences of events for a series of window lengths- that sounds
like you're about talking maintaining what are essentially lots of tries,
one for each distinct root? But if you can do it statically, then you're
basically just generating n-grams from the event sequence data and indexing
those?




On Mon, Sep 16, 2013 at 12:08 PM, Peter Mancini wrote:

> That is along the lines of my thinking. I am starting to look at zippers
> again. However much of what I need it to do either isn't documented at all
> or it was never intended to construct trees over time.
>
> The purpose of this is to look at sequenced events and detect frequent
> patterns. These patterns can have variations. It is built from the top down
> with the most frequent events added first, the 2nd most added second, etc.
> What ends up happening is that I see A-B-C-D a lot, for example, but I also
> see A-B-D-F sometimes. I see B-D-E-F-G rarely. So what I want to do is keep
> track of each of these. The first two are variations of each other stemming
> after A-B. What I want to do is to be able to look at D and see what events
> often precede it. I see that in all of my data A, B and C precede it.
> However just by examining the counts I can determine that C does not occur
> more than random chance so I can drop that and return B, A as my set, in
> that order because I see B preceeding more than A. Big Whoop you say. But
> now lets apply this to some interesting situations. Let's say that instead
> of letters we have topics. D is part of some greater topic concept. I want
> to know what other topics predict the existence of D such that if I see
> them I think that its possible they imply D. B and A do this, according to
> this analysis. So when I tell my search engine I'm interested in D it will
> also search for B and A knowing that while D isn't mentioned by name, there
> is a possibility it is implied when B or A are present.
>
> Concrete example. I want documents that talk about "automobiles."
> Automobile associates with things like "drivers seat" "steering wheel"
> "rear view mirror" but also with "car" "car wash" "Prius" "Ford" and other
> terms. Why is this important? Let's say I don't want a general return of
> information but I am looking for a very specific document. If I don't have
> the right keyword I have to guess. A lot. I may never guess right. So I
> need to be sure my search is augmented properly. That is what this will do.
> However the number of events I will be looking at will be in the hundreds
> of millions and for some data sets will be in the billions or greater. The
> problem will be distributed. However, for today, I just need to get this to
> work on my laptop, with an eye to the future as to how I will get this to
> work on a large network of machines. So far I have loved Functional
> Programming... right up to this problem. This one is killing me. I am going
> to examine the other suggestions here for how to do it. I am certain that
> Clojure is extremely excellent at solving this kind of problem and I am
> becoming more certain I am missing some FP concept that is preventing me
> from tapping into that power!
>
> Solve this problem and Clojure becomes the best platform for large scale
> machine learning out there. My company has 3 complex applications up
> already making money and the bugs are 99% design issues instead of
> something not working in an expected manner. This is really fantastic and
> has me sold that Clojure was a good choice.
>
> --Pete
>
>
> On Monday, September 9, 2013 4:06:41 PM UTC-5, Laurent PETIT wrote:
>>
>> This is quite an interesting post, with the underlying question in my
>> mind : where to put the line between pure datastructure manipulation
>> with clojure.core only, and a datalog (datomic)/sql engine ?
>>
>  --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Googl

Re: Clojure, floats, ints and OpenGL

[Zach Tellman]

If you're worried about NIO buffer marshalling, Vertigo [1] lets you treat 
them as native Clojure data structures.  This doesn't save you from the 
float<->double coercion for arithmetic operations, but as James said 
earlier in the thread, this tends to be insignificant.  However, if you're 
absolutely convinced this is a problem, it's pretty straightforward to 
extend the approach used in primitive-math [2] to work around this as well. 
 The current implementation hews to the standard Clojure approach of 
coercing everything to longs and doubles, but that was mostly because it 
saved me from having to do too much copy/pasting.  

I would point out, though that this:

"Where there were 500 fps, sometimes happen to be 480 fps and sometimes 
0.01 fps"

sounds an awful lot like garbage collection to me.  Type coercion has a 
fixed amount of overhead, and should have a fixed effect on the performance 
of your code. 

Zach

[1] https://github.com/ztellman/vertigo
[2] 
https://github.com/ztellman/primitive-math/blob/master/src/primitive_math/Primitives.java


On Monday, September 16, 2013 2:40:24 PM UTC-7, Alex Fowler wrote:
>
> Timothy, thank you very much for such a good explanation! I fully agree 
> with you. Actually, except for a few details, that is really how I thought 
> the things are. It is good that you describe the technical base for 
> problems with the issue. As well as clearified the human factor. What 
> you're saying is very much like what I would say if I were in your shoes. 
> Currently, what you're saying, is the present. In the present we make our 
> choices for currents. And I also agree with Mikera, that an attempt should 
> be taken. I would participate in it myself if I was into JVM and Clojure 
> internals. I plan to learn it, but it will take time.
>
> Mikera, thanks for the reference for the library, I will have a look. Also 
> I strongly encourage you in the attempt and I will be happy if I can be of 
> any help, although, you seem to know much more than me. I agree with Tim 
> that some more decisive steps have to be taken into this direction.
>
> James, ah.. yes, we did benchmarks. We use highly optimized mathematical 
> calculations, derived from numerical analysis. Every single instruction 
> matters there. Due to the nature of the calculations, the amout of casts, 
> however, varies from 3 to N in one computation. There can be 1 to M such 
> computation for a data unit. And thre can be 1 to P data units. At the end, 
> what worked on plain Java or Java-stylized Scala, worked that times faster, 
> NxMxP more instructions to be computed. Where there were 500 fps, sometimes 
> happen to be 480 fps and sometimes 0.01 fps. And I am not even talking 
> about operations on vast arrays or NIO buffers. But imagine for example, 
> you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and 
> will go back to it. Operation on each float takes, say 5 casts 
> double<->float in Clojure.
>
> Also, as Mikera points out, bus speeds come into play too.
>
> Of course, as Timothy said, why don't we go back to C for that kind of 
> stuff? This is a popular question in such cases. I am not going to go into 
> details on that, except for saying that we have mostly migrated from C to 
> JVM and it satisfies our requirements, while giving huge benifits. However, 
> we still do some things in C. To prevent arguments, here is an 
> article 
> that 
> somewhat describes what one can lose in computation, but does not describe 
> what one gains in other aspects. The loss is what can be tolerated. But 
> that loss for JVM is understandable. The one more loss for Clojure is 
> understandable too, but it can be changed. I think that the discussion 
> branch of Java vs C may be laid to rest.
>
>
> On Mon, Sep 16, 2013 at 9:03 PM, James Reeves 
> 
> > wrote:
>
>>
>>
>>
>> On 16 September 2013 09:03, Mikera > >wrote:
>>
>>>
>>> Obviously this is just a microbenchmark, but it fits my general 
>>> experience that floats are a reasonable bit faster than doubles, typically 
>>> 20-100% (doubles are closer when it is pure number crunching since 64-bit 
>>> CPUs are actually pretty good at doubles, floats have a bigger advantage 
>>> when you are manipulating a lot of data points and hence memory bandwidth 
>>> matters more)
>>>
>>> Code here for those interested:
>>> src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
>>>
>>
>> That's a pretty interesting result. I ran some tests of my own, based on 
>> your code, as I wondered whether or not the time to instantiate the array 
>> of doubles was biasing the test. My goal was to see whether or not I'd get 
>> a similar result running an array of floats through a method that processed 
>> doubles. (See: https://gist.github.com/weavejester/6583367)
>>
>> It turns out that I get a similar result. Passing floats to a method that 
>> takes doubles slows things down by a simila

Re: New Functional Programming Job Opportunities

[Zach Tellman]

If anyone has questions about working at Factual, I'm happy to answer them, 
and can be reached at zach at factual.com.  The short version, though, is 
that it's great and you should come work with us.

For some examples of Clojure we're writing and using at Factual, check out:

https://github.com/factual/skuld
https://github.com/factual/clj-leveldb
https://github.com/aphyr/merkle
https://github.com/ztellman/clj-tuple
https://github.com/ztellman/narrator

among many others.

Anyone at Strange Loop who's curious should feel free to track me down. 
 Kyle Kingsbury (better known to some as "aphyr") will be giving a talk, 
and will also happily answer any questions about Factual.

Zach

On Sunday, September 15, 2013 11:00:02 PM UTC-7, Sean Murphy wrote:
>
> Here are some functional programming job opportunities that were posted 
> recently: 
>
> Clojure Engineers Needed at Factual 
> http://functionaljobs.com/jobs/8646-clojure-engineers-needed-at-factual 
>
> Cheers, 
> Sean Murphy 
> FunctionalJobs.com 
>
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Weird core.async/ClojureScript not workings...

[David Pollak]

[org.clojure/clojurescript "0.0-1878"]
[org.clojure/core.async "0.1.222.0-83d0c2-alpha"]

[[lein-cljsbuild "0.3.2"]]


On Mon, Sep 16, 2013 at 3:32 PM, David Nolen  wrote:

> Which versions of ClojureScript and core.async are you using?
>
> David
>
>
> On Mon, Sep 16, 2013 at 5:25 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Howdy,
>>
>> I'm using core.async and ClojureScript and it seems that inside a go
>> block, if/when/loop/while code is never executed.
>>
>> For example:
>>
>>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
>> "it's false"
>>
>> prints neither "it's true" nor "it's false", but
>>
>>   (def dog33 (go (do (.log js/console "it's true") (.log js/console "it's
>> false"
>>
>> prints both.
>>
>> I'm doing lein cljsbuild auto to generate the JavaScript.
>>
>> Any pointers would be appreciated.
>>
>> Thanks,
>>
>> David
>>
>> --
>> Brick Alloy http://brickalloy. 
>> Lift, the simply functional web framework http://liftweb.net
>> Follow me: http://twitter.com/dpp
>> Blog: http://goodstuff.im
>>
>>  --
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Brick Alloy http://brickalloy.com 
Lift, the simply functional web framework http://liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Weird core.async/ClojureScript not workings...

[David Nolen]

Won't work you need core.async master. The next core.async release will fix
the issue.

David


On Tue, Sep 17, 2013 at 1:17 AM, David Pollak  wrote:

> [org.clojure/clojurescript "0.0-1878"]
> [org.clojure/core.async "0.1.222.0-83d0c2-alpha"]
>
> [[lein-cljsbuild "0.3.2"]]
>
>
> On Mon, Sep 16, 2013 at 3:32 PM, David Nolen wrote:
>
>> Which versions of ClojureScript and core.async are you using?
>>
>> David
>>
>>
>> On Mon, Sep 16, 2013 at 5:25 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Howdy,
>>>
>>> I'm using core.async and ClojureScript and it seems that inside a go
>>> block, if/when/loop/while code is never executed.
>>>
>>> For example:
>>>
>>>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
>>> "it's false"
>>>
>>> prints neither "it's true" nor "it's false", but
>>>
>>>   (def dog33 (go (do (.log js/console "it's true") (.log js/console
>>> "it's false"
>>>
>>> prints both.
>>>
>>> I'm doing lein cljsbuild auto to generate the JavaScript.
>>>
>>> Any pointers would be appreciated.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> --
>>> Brick Alloy http://brickalloy. 
>>> Lift, the simply functional web framework http://liftweb.net
>>> Follow me: http://twitter.com/dpp
>>> Blog: http://goodstuff.im
>>>
>>>  --
>>> --
>>> 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 patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Brick Alloy http://brickalloy.com 
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>  --
> --
> 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 patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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 patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure, floats, ints and OpenGL

[Jozef Wagner]

You can always fork Clojure and patch IFn.java and Compiler.java to support
floats for at least some types of functions. It probably won't be so hard.
As your case is a very specific one, this may be a viable solution.

JW


On Mon, Sep 16, 2013 at 11:40 PM, Alex Fowler wrote:

> Timothy, thank you very much for such a good explanation! I fully agree
> with you. Actually, except for a few details, that is really how I thought
> the things are. It is good that you describe the technical base for
> problems with the issue. As well as clearified the human factor. What
> you're saying is very much like what I would say if I were in your shoes.
> Currently, what you're saying, is the present. In the present we make our
> choices for currents. And I also agree with Mikera, that an attempt should
> be taken. I would participate in it myself if I was into JVM and Clojure
> internals. I plan to learn it, but it will take time.
>
> Mikera, thanks for the reference for the library, I will have a look. Also
> I strongly encourage you in the attempt and I will be happy if I can be of
> any help, although, you seem to know much more than me. I agree with Tim
> that some more decisive steps have to be taken into this direction.
>
> James, ah.. yes, we did benchmarks. We use highly optimized mathematical
> calculations, derived from numerical analysis. Every single instruction
> matters there. Due to the nature of the calculations, the amout of casts,
> however, varies from 3 to N in one computation. There can be 1 to M such
> computation for a data unit. And thre can be 1 to P data units. At the end,
> what worked on plain Java or Java-stylized Scala, worked that times faster,
> NxMxP more instructions to be computed. Where there were 500 fps, sometimes
> happen to be 480 fps and sometimes 0.01 fps. And I am not even talking
> about operations on vast arrays or NIO buffers. But imagine for example,
> you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and
> will go back to it. Operation on each float takes, say 5 casts
> double<->float in Clojure.
>
> Also, as Mikera points out, bus speeds come into play too.
>
> Of course, as Timothy said, why don't we go back to C for that kind of
> stuff? This is a popular question in such cases. I am not going to go into
> details on that, except for saying that we have mostly migrated from C to
> JVM and it satisfies our requirements, while giving huge benifits. However,
> we still do some things in C. To prevent arguments, here is an 
> article 
> that
> somewhat describes what one can lose in computation, but does not describe
> what one gains in other aspects. The loss is what can be tolerated. But
> that loss for JVM is understandable. The one more loss for Clojure is
> understandable too, but it can be changed. I think that the discussion
> branch of Java vs C may be laid to rest.
>
>
> On Mon, Sep 16, 2013 at 9:03 PM, James Reeves wrote:
>
>>
>>
>>
>> On 16 September 2013 09:03, Mikera  wrote:
>>
>>>
>>> Obviously this is just a microbenchmark, but it fits my general
>>> experience that floats are a reasonable bit faster than doubles, typically
>>> 20-100% (doubles are closer when it is pure number crunching since 64-bit
>>> CPUs are actually pretty good at doubles, floats have a bigger advantage
>>> when you are manipulating a lot of data points and hence memory bandwidth
>>> matters more)
>>>
>>> Code here for those interested:
>>> src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
>>>
>>
>> That's a pretty interesting result. I ran some tests of my own, based on
>> your code, as I wondered whether or not the time to instantiate the array
>> of doubles was biasing the test. My goal was to see whether or not I'd get
>> a similar result running an array of floats through a method that processed
>> doubles. (See: https://gist.github.com/weavejester/6583367)
>>
>> It turns out that I get a similar result. Passing floats to a method that
>> takes doubles slows things down by a similar amount, unless I've somehow
>> botched up the test. Considering that converting between single and double
>> precision should be pretty cheap on the CPU, I'm surprised at the
>> difference.
>>
>> This somewhat changes my view on things. It doesn't affect me in
>> practice, but I can see how someone might be frustrated by having to drop
>> down to Java to achieve performance for floating point calculations.
>>
>> - James
>>
>> --
>> --
>> 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 patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message b