Re: clojure streams

[Chris Gill]

There are some stream libraries that exist, though core.async channels 
could likely be used for most things stream related.
I made one called kuroshio (https://github.com/viperscape/kuroshio) which 
solves some small trade offs I didn't want to make with other libraries, 
there is also lamina (https://github.com/ztellman/lamina) which makes use 
of java queues under the hood and is likely very fast.


On Friday, August 29, 2014 2:56:14 PM UTC-4, Greg MacDonald wrote:
>
> Hi Everyone,
>
> Does anyone know the status of clojure streams is? I would like to try 
> them out but I can't find the svn repository mentioned on the website: 
> http://clojure.org/streams. Thx!
>
> -Greg
>

-- 
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/d/optout.

Re: Clojure, floats, ints and OpenGL

[Chris Gill]

... as well core.matrix supports normalise, which I just reali*z*ed since I 
am American English. haha

On Saturday, October 19, 2013 8:05:47 AM UTC-4, Chris Gill wrote:
>
> I am in this boat as well, clojure + opengl, currently using lwjgl for 
> bindings and management. I am curious why you need float support actually, 
> what specific methods are you hoping to utilize this with? Currently I 
> create float-arrays from the loaded mesh and build the VBOs and push that 
> all the to card the one time, this would be done for every mesh or 
> combination of meshes. After that all work, for me at least, I use uniforms 
> to manipulate the scene and so far have planned to do this through 
> core.matrix to work with the uniforms-- I don't plan on using very many 
> lwjgl functions since much of it seems geared towards pre-opengl 3 stuff. 
> Performing matrix ops on 1000 objects doesn't seem out of the realm of what 
> core.matrix can handle-- it's using ndarrays and seems quick so far. So my 
> question is maybe you can skirt the issue? I don't really know your 
> scenario, but what version of openGL do you plan on supporting? Keep in 
> mind core.matrix even has some euclidean math built in such as length and 
> distance.
>
> I based this off of a c++ example so it may be wrong as of yet-- haven't 
> implemented as of now; here is normalize and lookat to fill in some more 
> functions (using core.matrix): https://gist.github.com/viperscape/7055130
>
>
> On Monday, September 9, 2013 9:43:12 AM UTC-4, 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

Re: Clojure, floats, ints and OpenGL

[Chris Gill]

I am in this boat as well, clojure + opengl, currently using lwjgl for 
bindings and management. I am curious why you need float support actually, 
what specific methods are you hoping to utilize this with? Currently I 
create float-arrays from the loaded mesh and build the VBOs and push that 
all the to card the one time, this would be done for every mesh or 
combination of meshes. After that all work, for me at least, I use uniforms 
to manipulate the scene and so far have planned to do this through 
core.matrix to work with the uniforms-- I don't plan on using very many 
lwjgl functions since much of it seems geared towards pre-opengl 3 stuff. 
Performing matrix ops on 1000 objects doesn't seem out of the realm of what 
core.matrix can handle-- it's using ndarrays and seems quick so far. So my 
question is maybe you can skirt the issue? I don't really know your 
scenario, but what version of openGL do you plan on supporting? Keep in 
mind core.matrix even has some euclidean math built in such as length and 
distance.

I based this off of a c++ example so it may be wrong as of yet-- haven't 
implemented as of now; here is normalize and lookat to fill in some more 
functions (using core.matrix): https://gist.github.com/viperscape/7055130


On Monday, September 9, 2013 9:43:12 AM UTC-4, 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 comp

Re: [ANN] Counterclockwise - Clojure plugin for Eclipse

[Chris Gill]

wow this is really polished! really great how this is standalone, and so 
small! I enjoyed using CCW in eclipse, but this is even better :D 
great work Laurent!


On Thursday, October 10, 2013 9:36:01 AM UTC-4, Laurent PETIT wrote:
>
> Hi, a new version of Counterclockwise, the Clojure plugin for the 
> Eclipse IDE, has just been released. 
>
> Hot new features 
>  
> - auto indentation as you type 
> - available as a Standalone Product: Download, Unzip, Code! 
> - many bug fixes including (hopefully) stability improvements 
>
> Install 
> = 
> - Software update site for installing into an existing Eclipse: 
> http://updatesite.ccw-ide.org/stable/ 
>
> Standalone product for: 
> - Windows 64 bits: 
>
> http://updatesite.ccw-ide.org/branch/master/master-0.20.0.STABLE001/products/ccw-win32.win32.x86_64.zip
>  
> - Windows 32 bits: 
>
> http://updatesite.ccw-ide.org/branch/master/master-0.20.0.STABLE001/products/ccw-win32.win32.x86.zip
>  
> - Linux 64 bits: 
>
> http://updatesite.ccw-ide.org/branch/master/master-0.20.0.STABLE001/products/ccw-linux.gtk.x86_64.zip
>  
> - Linux 32 bits: 
>
> http://updatesite.ccw-ide.org/branch/master/master-0.20.0.STABLE001/products/ccw-linux.gtk.x86.zip
>  
> - OS X 64 bits: 
>
> http://updatesite.ccw-ide.org/branch/master/master-0.20.0.STABLE001/products/ccw-macosx.cocoa.x86_64.zip
>  
>
> Create a folder, unzip the product inside this folder, and double 
> click on the "Counterclockwise" executable! (only pre-requisite: Java 
> 7 in your path) 
>
> Release Note 
> == 
> https://code.google.com/p/counterclockwise/wiki/ReleaseNotes#Version_0.20.0 
>
>
> Cheers, 
>
>
> -- 
> Laurent Petit 
>

-- 
-- 
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: is intellij idea a good ide for clojure development?

[Chris Gill]

I find this interesting. I've been using light table mostly, but recently I 
tried my hand at socket programming and light table flopped on this type of 
a project. I ended up using lein repl for most of my work which became a 
pain and now I'm looking at emacs with a slight kink in my lips. I'll have 
to try eclipse for clojure out, I've only ever done android in eclipse. Do 
you think something like an openGL project in clojure in eclipse with 
live-editing is a possibility? I've mostly seen this kind of stuff in emacs 
but I feel like it has less to do with emacs and more with nrepl and 
evaling..

-c

On Tuesday, January 29, 2013 1:40:33 PM UTC-5, Timo Mihaljov wrote:
>
> On 29.01.2013 16:32, Jay Fields wrote: 
> > On Tue, Jan 29, 2013 at 9:28 AM, Feng Shen > 
> wrote: 
> >> I have programming Clojure for almost 2 years, for a living. 
> >> 
> > 
> > This is probably an important part of what answer the OP is looking 
> > for. When I was doing Clojure for about 10% of my job IntelliJ was 
> > fine. Now that it's 90% of my job, I wouldn't be able to give up emacs 
> > go back to IntelliJ. 
> > 
> > If you're just looking at Clojure as a hobby and you already know 
> > IntelliJ, I wouldn't recommend switching. However, if you're going to 
> > be programming Clojure almost all of the time, I think emacs is the 
> > superior choice. 
> > 
>
> For what it's worth, I switched from Emacs to Eclipse and 
> Counterclockwise for Clojure programming. Laurent's done an excellent 
> job with it, and I even prefer his take on paredit over Emacs's 
> original. I still use Emacs for everything else, but for Clojure I find 
> Counterclockwise to be "the superior choice". 
>
>
> -- 
> Timo 
>

-- 
-- 
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: merge nested maps

[Chris Gill]

Thank you for finding and posting this! Been wracking my brain trying to 
figure out a good way to do a full map merge

On Thursday, April 25, 2013 5:26:53 PM UTC-4, Stuart Sierra wrote:
>
> Here's a way to do it from the Pedestal demo source 
> code
> :
>
> (defn deep-merge
>   "Recursively merges maps. If keys are not maps, the last value wins."
>   [& vals]
>   (if (every? map? vals)
> (apply merge-with deep-merge vals)
> (last vals)))
>
> -S
>
>
>
> On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>>
>> Hi list,
>>
>> I was searching for an "easy" way to combined nested maps, e.g. as in 
>>
>> (combine {:foo {:bar "baz"}} {:foo {:x "y"}})
>> => {:foo {:bar "baz", :x "y"}}
>>
>> I would expect that there is some core map operation to do this, but 
>> neither merge nor unify work as they simply return {:foo {:x "y"}}, and I 
>> don't see anything else. Am I missing something?
>>
>> 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.