Re: Installing Clojure on Windows 7
I highly recommend GOW - Gnu On Windows - as a lightweight alternative to Cygwin: https://github.com/bmatzelle/gow/wiki It provides wget / curl which makes Leiningen happy - along with about a hundred common *nix commands, without the overhead of Cygwin. Sean On Sat, Jan 26, 2013 at 7:56 PM, Eric MacAdie emaca...@gmail.com wrote: OT: It looks like Gnuwin32 has not been updated in a while. When I use a Windows machine, I always install cygwin: http://cygwin.com/ You can install emacs from that. I feel like attaching a pic with the Dos Equis Most Interesting Man meme: I don't always use Windows. But when I do, I install Cygwin. - Eric MacAdie On Sat, Jan 26, 2013 at 7:22 PM, Gregory Graham gsg...@gmail.com wrote: I'm a Clojure newbie, and during Christmas break I decided to learn Clojure, and installed it on my Mac, using Emacs, Nrepl, and Leiningen 2. When I got back to work, I put the same setup on my Windows 7 machine, and the only issue was the lack of wget. So, I installed Gnuwin32, and everything works fine. I was already using git for version control, so that wasn't a problem. I will say that I had used Emacs several times in my career when working in a Unix environment, but did not like it on Windows. However, when I tried Emacs 24 on Windows a couple of weeks ago, I was pleasantly surprised, and it has now become my main editor at home and at work. -- -- 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 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 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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
Re: [ANN] Overtone 0.8.0 - Performance Ready
Thanks to everyone who worked hard to make 0.8.0 happen, especially Sam. :-) On 27 January 2013 02:00, Sam Aaron samaa...@gmail.com wrote: On 26 Jan 2013, at 20:17, Sam Aaron samaa...@gmail.com wrote: I pulled out the GUI widgets from this release as I found a number of issues with them at the last minute and want them to be super stable and polished when we release them. I should also say that these GUI widgets are currently in the MASTER branch on Github: https://github.com/overtone/overtone/tree/master/src/overtone/gui So if you want to play around with them and help polish and develop them further, then please do. Sam --- http://sam.aaron.name -- -- -- 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
Re: Natively Compiled Clojure
Timothy Baldridge writes: The important question to ask yourself (and I'll cover this in my talk), is why do you want native Clojure? ... Interop with systems - Java has one of the biggest ecosystems on the planet The Java ecosystem is big but concentrated on some application domains. Other application domains (including mine, scientific computing) rely on a native code ecosystem (C and Fortran libraries). The JVM is very bad at interop with native code when large data is involved, because the JNI puts security before efficiency. The CLR does a better job there, so those looking for native interop could explore ClojureCLR. The main problem there is the Windows-centricity of the CLR ecosystem. Even if the CLR is in theory portable, with Mono providing an implementation for Linux and MacOS, many important tools and libraries for the CLR are available only for Windows, or are a pain to use elsewhere. Konrad. -- -- 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
Minimizing the download of js code in Multipage ClojureScript webapp
Building a traditional multipage webapp and using only some cljs code on the pages requires me to put all the cljs overhead output in one single file that can be cached by the browser (in order to not have to load the same 130+ k cljs overhead for each page). I've tried creating an empty namespace containing only the overhead compilation, and then requiring it from one of my page specific cljs files. However this just spits out endless amounts of warnings. Have anyone done this before? -- -- 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
Re: Natively Compiled Clojure
Embedding in applications - Python is used very often as a scripting language in 3d apps, games, mapping software, etc. I've yet to hear of the JVM ever being used for this. Related to this, do you have any thoughts on the viability of embedding clojure-py into a C++ application for similar use cases? Seems that performance could be a concern, but sandboxing might be more straightforward. Haven't had time to try this myself yet. Thanks. On Fri, Jan 25, 2013 at 11:28 AM, Timothy Baldridge tbaldri...@gmail.com wrote: The important question to ask yourself (and I'll cover this in my talk), is why do you want native Clojure? A native implementation of Clojure will fail to deliver on several fronts: Interop with systems - Java has one of the biggest ecosystems on the planet Performance - The JVM JIT and GC are really the best that the world has to offer. Beating them in the general use case is very, very hard. However, a native clojure implementation could succeed on a few other fronts: Deterministic behavior - The JVM JIT/GC are not very deterministic, and are hard to reason about. In this area they trade off simplicity for performance. 99% of the time that is what you want. But perhaps in some cases you would like different behavior. Embedding in applications - Python is used very often as a scripting language in 3d apps, games, mapping software, etc. I've yet to hear of the JVM ever being used for this. Systems where the JVM isn't available/allowed - think iOS So while I think there is a use for a non JVM/JS implementation of Clojure, the use cases are much smaller than many think. I've gotten a bit sidetracked on the more general topic of generating native code via Clojure and LLVM lately, so while my talk will show some basic Clojure code running in the Python VM via LLVM, it will also cover the more broad concept of leveraging LLVM directly from Clojure on the JVM. The latter is a prerequisite to the former, so the library I'll be showcasing can be used for generating code for either situation. Should be fun times for all! Timothy On Fri, Jan 25, 2013 at 9:08 AM, Tony Pitluga tony.pitl...@gmail.com wrote: There are a couple projects that might be worth looking at although it seems both have not been updated in a few months. ClojureC: https://github.com/schani/clojurec Clojure-Scheme: https://github.com/takeoutweight/clojure-scheme On Fri, Jan 25, 2013 at 10:35 AM, Nahuel Greco ngr...@gmail.com wrote: Check the clojure-py2 project, they plan to use LLVM to generate native modules (as C compiled) for Python. When that objective is reached probably you will have almost all the machinery to compile python-less native binaries: http://lanyrd.com/2013/clojurewest/sccgmm/ Saludos, Nahuel Greco. On Fri, Jan 25, 2013 at 12:18 PM, Marko Kocić ma...@euptera.com wrote: On Friday, January 25, 2013 6:12:07 AM UTC+1, Mikera wrote: A natively compiled Clojure would be very very interesting (perhaps targeting LLVM?) However it would also be very hard to implement. Clojure depends on a lot of features provided by the JVM (JIT compilation, interop with Java libraries, garbage collection being the most significant ones). It would be very hard to reimplement all of these from the ground up. The JVM is already a very good host platform, why fix something that isn't broken? What about native ClojuresScript? It doesn't have to implement everything Clojure have already, and many people could consider it good enough alternative to Clojure. I could personally live without runtime macros and eval if it would gain me small and performant native executable. Arguably the effort would be better spend improving the JVM with extra features that would help Clojure (e.g. TCO). On Tuesday, 22 January 2013 00:29:54 UTC+8, octopusgrabbus wrote: I use Clojure primarily as a very reliable tool to aid in data transformations, that is taking data in one application's database and transforming it into the format needed for another applications' database. So, my question is would a natively compiled Clojure make sense or turn the language into something that was not intended? In almost all instances I have not found a problem with Clojure's execution speed so my question is not about pro or anti Java. Thanks. -- -- 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 post to this group, send email to clojure@googlegroups.com Note that posts
[ANN] core.matrix 0.0.6
Hi all, core.matrix is a new (and still experimental) library for matrix maths and numerical computing in Clojure. Key features / design goals 1. A clean, pure Clojure API 2. Works with multiple Clojure/Java/native matrix implementations (e.g. Colt, JBLAS, Vectorz, Apache Commons etc.) 3. High performance, protocol-based dispatch 4. Support for arbitrary N-dimensional arrays (like NumPy) 5. Optional support for mutable matrix types (in case you prefer raw speed to functional purity) It is still early days, but I'd like to encourage everyone interested in this field to give it try and let us know if you have any feedback. Clojars: https://clojars.org/mikera/core.matrix Examples: https://github.com/mikera/matrix-api/blob/master/src/main/clojure/core/matrix/examples.clj GitHub: https://github.com/mikera/matrix-api Discussion: https://groups.google.com/forum/?fromgroups#!forum/numerical-clojure Mike. -- -- 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
Re: Installing Clojure on Windows 7
On Saturday, January 26, 2013 7:01:34 PM UTC-8, Ravi Sundaar wrote: I am running into problems getting emacs (24.2) to work with clojure as well on windows 7. I have installed leiningen fine. Clojure (1.4.0) itself seems to be behaving. The packages seem to install fine in emacs - no problems. When I invoke nrepl-jack-in from emacs, I get an Access Denied error. No idea what that could be. There does not seem to be any discussions on this on the web. Any thoughts? Should I abandon the emacs approach on windows and choose a different editor? No, Emacs works perfectly well on Windows. What packages did you install and how did you install them? -- -- 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
Re: Natively Compiled Clojure
As far as embedding Clojure is concerned, another option is ClojureScript-Lua + LuaJit + C. I've recently started going through the CLJS-Lua source to see how viable this is. I am holding off committing any serious effort until I see the talk at Clojure/West. C + Python + ClojurePy2 could fit most of my needs (even if I have to give up some speed and memory). Paul On Sunday, January 27, 2013 7:07:31 AM UTC-8, Mark Rathwell wrote: Embedding in applications - Python is used very often as a scripting language in 3d apps, games, mapping software, etc. I've yet to hear of the JVM ever being used for this. Related to this, do you have any thoughts on the viability of embedding clojure-py into a C++ application for similar use cases? Seems that performance could be a concern, but sandboxing might be more straightforward. Haven't had time to try this myself yet. Thanks. On Fri, Jan 25, 2013 at 11:28 AM, Timothy Baldridge tbald...@gmail.com javascript: wrote: The important question to ask yourself (and I'll cover this in my talk), is why do you want native Clojure? A native implementation of Clojure will fail to deliver on several fronts: Interop with systems - Java has one of the biggest ecosystems on the planet Performance - The JVM JIT and GC are really the best that the world has to offer. Beating them in the general use case is very, very hard. However, a native clojure implementation could succeed on a few other fronts: Deterministic behavior - The JVM JIT/GC are not very deterministic, and are hard to reason about. In this area they trade off simplicity for performance. 99% of the time that is what you want. But perhaps in some cases you would like different behavior. Embedding in applications - Python is used very often as a scripting language in 3d apps, games, mapping software, etc. I've yet to hear of the JVM ever being used for this. Systems where the JVM isn't available/allowed - think iOS So while I think there is a use for a non JVM/JS implementation of Clojure, the use cases are much smaller than many think. I've gotten a bit sidetracked on the more general topic of generating native code via Clojure and LLVM lately, so while my talk will show some basic Clojure code running in the Python VM via LLVM, it will also cover the more broad concept of leveraging LLVM directly from Clojure on the JVM. The latter is a prerequisite to the former, so the library I'll be showcasing can be used for generating code for either situation. Should be fun times for all! Timothy On Fri, Jan 25, 2013 at 9:08 AM, Tony Pitluga tony.p...@gmail.comjavascript: wrote: There are a couple projects that might be worth looking at although it seems both have not been updated in a few months. ClojureC: https://github.com/schani/clojurec Clojure-Scheme: https://github.com/takeoutweight/clojure-scheme On Fri, Jan 25, 2013 at 10:35 AM, Nahuel Greco ngr...@gmail.comjavascript: wrote: Check the clojure-py2 project, they plan to use LLVM to generate native modules (as C compiled) for Python. When that objective is reached probably you will have almost all the machinery to compile python-less native binaries: http://lanyrd.com/2013/clojurewest/sccgmm/ Saludos, Nahuel Greco. On Fri, Jan 25, 2013 at 12:18 PM, Marko Kocić ma...@euptera.comjavascript: wrote: On Friday, January 25, 2013 6:12:07 AM UTC+1, Mikera wrote: A natively compiled Clojure would be very very interesting (perhaps targeting LLVM?) However it would also be very hard to implement. Clojure depends on a lot of features provided by the JVM (JIT compilation, interop with Java libraries, garbage collection being the most significant ones). It would be very hard to reimplement all of these from the ground up. The JVM is already a very good host platform, why fix something that isn't broken? What about native ClojuresScript? It doesn't have to implement everything Clojure have already, and many people could consider it good enough alternative to Clojure. I could personally live without runtime macros and eval if it would gain me small and performant native executable. Arguably the effort would be better spend improving the JVM with extra features that would help Clojure (e.g. TCO). On Tuesday, 22 January 2013 00:29:54 UTC+8, octopusgrabbus wrote: I use Clojure primarily as a very reliable tool to aid in data transformations, that is taking data in one application's database and transforming it into the format needed for another applications' database. So, my question is would a natively compiled Clojure make sense or turn the language into something that was not intended? In almost all instances I have not found a problem with Clojure's execution speed so my
Re: Installing Clojure on Windows 7
I haven't had any luck getting Light Table to work on Windows 7, and it's still in a very rough state. I wouldn't recommend it at this time. On Sat, Jan 26, 2013 at 10:56 AM, Ryan Cole r...@rycole.com wrote: It's actually pretty simple, if you decide to use leiningen and light table, the editor. All you have to do is install the JDK (decline the JRE option, when it asks) and then put leiningen and light table on your system path. You're done. Leiningen and light table will download dependencies as needed, including Clojure. Ryan -- -- 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
Re: Installing Clojure on Windows 7
I guess I don't understand what's so difficult about getting Clojure, or Light Table, to work on Windows (7). I literally just installed the JDK, put the bin directory of it on my $PATH, and with that alone, Light Table will work just fine. I then downloaded the Leiningen batch file and put it on my $PATH, as well. I only encountered one compatibility issue dealing with uberjars, but I opened a ticket for Leiningen and it was promptly fixed. I've done this with both JDK 1.6 and 1.7. As far as Light Table's state, it's definitely under development but I haven't encountered any editing tasks that it can't perform. Ryan On Sunday, January 27, 2013 2:10:01 PM UTC-6, puzzler wrote: I haven't had any luck getting Light Table to work on Windows 7, and it's still in a very rough state. I wouldn't recommend it at this time. -- -- 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
Re: Installing Clojure on Windows 7
On Sun, Jan 27, 2013 at 12:15 PM, Ryan Cole r...@rycole.com wrote: I guess I don't understand what's so difficult about getting Clojure, or Light Table, to work on Windows (7). I literally just installed the JDK, put the bin directory of it on my $PATH, and with that alone, Light Table will work just fine. I then downloaded the Leiningen batch file and put it on my $PATH, as well. I only encountered one compatibility issue dealing with uberjars, but I opened a ticket for Leiningen and it was promptly fixed. I've done this with both JDK 1.6 and 1.7. As far as Light Table's state, it's definitely under development but I haven't encountered any editing tasks that it can't perform. Ryan Glad it's working for you. On every system I've tried to run it on, opening an existing project or starting a new project causes it to hang. The instarepl, on some versions, sort of worked for a little bit. -- -- 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
Re: Minimizing the download of js code in Multipage ClojureScript webapp
I solved this problem for my web app in a different way, which might be worth considering. My entire ClojureScript project compiles to a single JS file which is used by every single page. I organized things such that each page had a cljs namespace associated with it, which has an init function. So for instance, /foo/bar.html would know to call (myapp.foo.bar/init) on load, and /baz/hello/world.html would call (myapp.baz.hello.world/init) on load. This is just one way to organize things, but it works pretty well for me. The advantage of this approach is that you only have to download the giant ball of JS once, and then it's cached for as long as you like. The disadvantage of this approach is that the giant ball is, well, pretty giant. I think that it makes sense to use the single JS file for reasonably complex apps, where your application code is small in comparison to the ClojureScript standard library. In that case, the whole JS file will not be much bigger than just the standard library itself. Of course, if your app is very large (several tens of thousands of lines of code), and you really need to get the initial JS size down, you will have to do something more sophisticated. On Sunday, January 27, 2013 4:54:59 AM UTC-8, Marcus Holst wrote: Building a traditional multipage webapp and using only some cljs code on the pages requires me to put all the cljs overhead output in one single file that can be cached by the browser (in order to not have to load the same 130+ k cljs overhead for each page). I've tried creating an empty namespace containing only the overhead compilation, and then requiring it from one of my page specific cljs files. However this just spits out endless amounts of warnings. Have anyone done this before? -- -- 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
Re: Natively Compiled Clojure
On Sun, Jan 27, 2013 at 1:31 PM, Paul deGrandis paul.degran...@gmail.com wrote: As far as embedding Clojure is concerned, another option is ClojureScript-Lua + LuaJit + C. I've recently started going through the CLJS-Lua source to see how viable this is. Thanks, I had forgotten about ClojureScript-Lua. (And hopefully the content of the clojure-py2 talk will be available afterwards, very interesting work.) -- -- 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
Re: Minimizing the download of js code in Multipage ClojureScript webapp
Thanks Evan! I actually already started along this big js blob path and was just beginning to see the problem with clashing page inits. Your solution with an init func per page will probably do just fine for me too so I'll try that now. With conditional caching on the big js file, it should only need to be loaded once per site release, so it should also be ok. On Sunday, January 27, 2013 9:37:32 PM UTC+1, Evan Mezeske wrote: I solved this problem for my web app in a different way, which might be worth considering. My entire ClojureScript project compiles to a single JS file which is used by every single page. I organized things such that each page had a cljs namespace associated with it, which has an init function. So for instance, /foo/bar.html would know to call (myapp.foo.bar/init) on load, and /baz/hello/world.html would call (myapp.baz.hello.world/init) on load. This is just one way to organize things, but it works pretty well for me. The advantage of this approach is that you only have to download the giant ball of JS once, and then it's cached for as long as you like. The disadvantage of this approach is that the giant ball is, well, pretty giant. I think that it makes sense to use the single JS file for reasonably complex apps, where your application code is small in comparison to the ClojureScript standard library. In that case, the whole JS file will not be much bigger than just the standard library itself. Of course, if your app is very large (several tens of thousands of lines of code), and you really need to get the initial JS size down, you will have to do something more sophisticated. On Sunday, January 27, 2013 4:54:59 AM UTC-8, Marcus Holst wrote: Building a traditional multipage webapp and using only some cljs code on the pages requires me to put all the cljs overhead output in one single file that can be cached by the browser (in order to not have to load the same 130+ k cljs overhead for each page). I've tried creating an empty namespace containing only the overhead compilation, and then requiring it from one of my page specific cljs files. However this just spits out endless amounts of warnings. Have anyone done this before? -- -- 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
ANN: rewryte.com uses clojure for automated writing feedback
It's been eight months in the making, but rewryte.com is live! We're using Clojure on the back-end for all our data processing. Our goal is to provide quick, automated feedback on your writing. We're in public beta, so please check us out and let us know what you think! Ron Toland -- -- 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
Re: ANN: rewryte.com uses clojure for automated writing feedback
What file format does this take? I tried pdf and it barfed. On Monday, January 28, 2013 1:04:31 AM UTC+4, Ron Toland wrote: It's been eight months in the making, but rewryte.com is live! We're using Clojure on the back-end for all our data processing. Our goal is to provide quick, automated feedback on your writing. We're in public beta, so please check us out and let us know what you think! Ron Toland -- -- 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
Re: String wrapper that supports meta-data...
On Wednesday, January 9, 2013 4:23:06 PM UTC-5, Jim foo.bar wrote: hehehe...I'm really stupid aren't I?:-[ Not at all. :) It takes time to get used to all the different ways things can be used, for example the fact that records support metadata. -S -- -- 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
Re: Minimizing the download of js code in Multipage ClojureScript webapp
Hi Marcus, I found the same solution Evan suggested to you. You can read about it here. https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-06.md and you can also define a single init function which is shared by each source cljs files by passing it the parameters you need to setup each html page differently. (A kind of abstraction to apply the DRY principle). Mimmo On Jan 27, 2013, at 10:03 PM, Marcus Holst holst.mar...@gmail.com wrote: Thanks Evan! I actually already started along this big js blob path and was just beginning to see the problem with clashing page inits. Your solution with an init func per page will probably do just fine for me too so I'll try that now. With conditional caching on the big js file, it should only need to be loaded once per site release, so it should also be ok. On Sunday, January 27, 2013 9:37:32 PM UTC+1, Evan Mezeske wrote: I solved this problem for my web app in a different way, which might be worth considering. My entire ClojureScript project compiles to a single JS file which is used by every single page. I organized things such that each page had a cljs namespace associated with it, which has an init function. So for instance, /foo/bar.html would know to call (myapp.foo.bar/init) on load, and /baz/hello/world.html would call (myapp.baz.hello.world/init) on load. This is just one way to organize things, but it works pretty well for me. The advantage of this approach is that you only have to download the giant ball of JS once, and then it's cached for as long as you like. The disadvantage of this approach is that the giant ball is, well, pretty giant. I think that it makes sense to use the single JS file for reasonably complex apps, where your application code is small in comparison to the ClojureScript standard library. In that case, the whole JS file will not be much bigger than just the standard library itself. Of course, if your app is very large (several tens of thousands of lines of code), and you really need to get the initial JS size down, you will have to do something more sophisticated. On Sunday, January 27, 2013 4:54:59 AM UTC-8, Marcus Holst wrote: Building a traditional multipage webapp and using only some cljs code on the pages requires me to put all the cljs overhead output in one single file that can be cached by the browser (in order to not have to load the same 130+ k cljs overhead for each page). I've tried creating an empty namespace containing only the overhead compilation, and then requiring it from one of my page specific cljs files. However this just spits out endless amounts of warnings. Have anyone done this before? -- -- 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 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
Re: ANN: rewryte.com uses clojure for automated writing feedback
Zack: It only accepts plain txt files at the moment. We're working on supporting other formats. :) -- -- 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
Re: Natively Compiled Clojure
Additionally, you might also consider ClojureScript itself. With a little work you could embed V8 into your application (https://developers.google.com/v8/embed). Martin Trojer just wrote a really nice blog post on embedded runtimes - http://martinsprogrammingblog.blogspot.co.uk/ All that said, for most apps where an embedded, scripting runtime is advantageous, ClojureScript-Lua +LuaJIT and PyClojure+cFFI+Python/PyPy are two very attractive options. In the best case scenario, the former delivers more speed and a smaller footprint, trading off some library and ecosystem comforts. The latter has a great ecosystem, but will be slower and have a larger memory footprint. Paul -- -- 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
Re: Natively Compiled Clojure
That's why I think it's a good idea to ask what the goals are for native Clojure. The ClojureScript and Clojure-Py options while nice both don't allow for a good concurrency story. On top of that, I'm not sure either of those would actually run on iOS. However, a pure, from-scratch option has a much smaller ecosystem to draw from. But on the upside, you're also not limited by the host VM. This means that the type system could be based purely on protocols instead of having to fit protocols into a OOP type system. These are the questions I'd like to see people answer here: what hard limits have you hit with Clojure/ClojureScript that you think could be resolved with a native Clojure implementation? Timothy Baldridge On Sun, Jan 27, 2013 at 4:32 PM, Paul deGrandis paul.degran...@gmail.comwrote: Additionally, you might also consider ClojureScript itself. With a little work you could embed V8 into your application ( https://developers.google.com/v8/embed). Martin Trojer just wrote a really nice blog post on embedded runtimes - http://martinsprogrammingblog.blogspot.co.uk/ All that said, for most apps where an embedded, scripting runtime is advantageous, ClojureScript-Lua +LuaJIT and PyClojure+cFFI+Python/PyPy are two very attractive options. In the best case scenario, the former delivers more speed and a smaller footprint, trading off some library and ecosystem comforts. The latter has a great ecosystem, but will be slower and have a larger memory footprint. Paul -- -- 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 -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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
Re: Natively Compiled Clojure
I haven't hit any hard limits at this point, but you hit on a use case where Python and Lua currently hit a sweet spot that I think would be nice to use Clojure: C/C++ systems that want to expose scripting capabilities to users (e.g. game engines, robotics systems). For these types of use cases, the ability to deploy native Clojure executables is not as important as the ability embed a low-resource runtime, the ability to call C/C++ code, the ability to sandbox the environment, etc. On Sun, Jan 27, 2013 at 6:56 PM, Timothy Baldridge tbaldri...@gmail.com wrote: That's why I think it's a good idea to ask what the goals are for native Clojure. The ClojureScript and Clojure-Py options while nice both don't allow for a good concurrency story. On top of that, I'm not sure either of those would actually run on iOS. However, a pure, from-scratch option has a much smaller ecosystem to draw from. But on the upside, you're also not limited by the host VM. This means that the type system could be based purely on protocols instead of having to fit protocols into a OOP type system. These are the questions I'd like to see people answer here: what hard limits have you hit with Clojure/ClojureScript that you think could be resolved with a native Clojure implementation? Timothy Baldridge On Sun, Jan 27, 2013 at 4:32 PM, Paul deGrandis paul.degran...@gmail.com wrote: Additionally, you might also consider ClojureScript itself. With a little work you could embed V8 into your application (https://developers.google.com/v8/embed). Martin Trojer just wrote a really nice blog post on embedded runtimes - http://martinsprogrammingblog.blogspot.co.uk/ All that said, for most apps where an embedded, scripting runtime is advantageous, ClojureScript-Lua +LuaJIT and PyClojure+cFFI+Python/PyPy are two very attractive options. In the best case scenario, the former delivers more speed and a smaller footprint, trading off some library and ecosystem comforts. The latter has a great ecosystem, but will be slower and have a larger memory footprint. Paul -- -- 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 -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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 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
Re: Natively Compiled Clojure
although I'm sure everybody's seen this, I believe it is relevant here, this clojureconj by Chris Granger https://www.youtube.com/watch?v=V1Eu9vZaDYw maybe only applies to clojurescript(that is, being slow in this case) the important stuff is at from 13:59 On Mon, Jan 28, 2013 at 1:53 AM, Mark Rathwell mark.rathw...@gmail.comwrote: I haven't hit any hard limits at this point, but you hit on a use case where Python and Lua currently hit a sweet spot that I think would be nice to use Clojure: C/C++ systems that want to expose scripting capabilities to users (e.g. game engines, robotics systems). For these types of use cases, the ability to deploy native Clojure executables is not as important as the ability embed a low-resource runtime, the ability to call C/C++ code, the ability to sandbox the environment, etc. On Sun, Jan 27, 2013 at 6:56 PM, Timothy Baldridge tbaldri...@gmail.com wrote: That's why I think it's a good idea to ask what the goals are for native Clojure. The ClojureScript and Clojure-Py options while nice both don't allow for a good concurrency story. On top of that, I'm not sure either of those would actually run on iOS. However, a pure, from-scratch option has a much smaller ecosystem to draw from. But on the upside, you're also not limited by the host VM. This means that the type system could be based purely on protocols instead of having to fit protocols into a OOP type system. These are the questions I'd like to see people answer here: what hard limits have you hit with Clojure/ClojureScript that you think could be resolved with a native Clojure implementation? Timothy Baldridge On Sun, Jan 27, 2013 at 4:32 PM, Paul deGrandis paul.degran...@gmail.com wrote: Additionally, you might also consider ClojureScript itself. With a little work you could embed V8 into your application (https://developers.google.com/v8/embed). Martin Trojer just wrote a really nice blog post on embedded runtimes - http://martinsprogrammingblog.blogspot.co.uk/ All that said, for most apps where an embedded, scripting runtime is advantageous, ClojureScript-Lua +LuaJIT and PyClojure+cFFI+Python/PyPy are two very attractive options. In the best case scenario, the former delivers more speed and a smaller footprint, trading off some library and ecosystem comforts. The latter has a great ecosystem, but will be slower and have a larger memory footprint. Paul -- -- 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 -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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 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 -- I may be wrong or incomplete. Please express any corrections / additions, they are encouraged and appreciated. At least one entity is bound to be transformed if you do ;) -- -- 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
Re: Is contributing to clojurescript is intentionally made hard ?
On Jan 20, 2013, at 7:11 PM, Andy Fingerhut wrote: On Jan 20, 2013, at 7:49 AM, Anthony Grimes wrote: In closing, I propose the following. If we're going to continuously deny people things they are accustomed to, instead of treating them like angry children having tantrums, why don't we get a response from clojure/core and have it displayed prominently somewhere would-be contributors can see it? The page should at least explain: * Why we use Jira * Why we only accept Jira patches * Why contribution processes like those adopted by organizations and companies like Mozilla are not acceptable Anthony and others: I've spent some time creating a new page that might be a start at addressing some of these questions, and perhaps could be pointed at when this topic arises again. I don't expect it gives satisfying answers to all of your questions above at this time, but it can be enhanced if desired. http://dev.clojure.org/display/design/Brief+description+of%2C+and+FAQs+about%2C+the+Clojure+contribution+process The best answer I know of for why Clojure only accepts JIRA patches is that Rich Hickey prefers them, as given on a link on that page now, and which I gave earlier in this thread. He says it saves him time compared to github pull requests, for example. If you want to know in detail *why* it saves him time, I don't have an answer for that question. The page above was renamed to be shorter. The new link is http://dev.clojure.org/display/design/Contributing+FAQ Andy -- -- 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
Re: Natively Compiled Clojure
On Monday, 28 January 2013 07:56:58 UTC+8, tbc++ wrote: That's why I think it's a good idea to ask what the goals are for native Clojure. The ClojureScript and Clojure-Py options while nice both don't allow for a good concurrency story. On top of that, I'm not sure either of those would actually run on iOS. However, a pure, from-scratch option has a much smaller ecosystem to draw from. But on the upside, you're also not limited by the host VM. This means that the type system could be based purely on protocols instead of having to fit protocols into a OOP type system. These are the questions I'd like to see people answer here: what hard limits have you hit with Clojure/ClojureScript that you think could be resolved with a native Clojure implementation? The hard limits I have hit in Clojure are around three specific areas: 1. GC latency on the JVM (usually not a problem, but can be an issue for games and realtime work) 2. Startup latency 3. Access to hardware level features (GPU access, OpenGL etc.) 1. Can be avoided by avoiding memory allocation (there are Java libraries that do this like Javaolution), but this is really hard to do in idiomatic Clojure. Even something as simple traversing a single vector as a sequence is O(n) in new object allocations. 2. Is actually more about the time taken to load / compile the Clojure core libraries than it is about the JVM. On my machine, the JVM itself starts up in about 0.1 sec which is fine for anything other than chaining thousands of script invocations. Generally I think that people who complain about JVM startup time probably have the wrong architecture - you don't spin up a new virtual server to handle every web request, do you? 3. Can be done, but it's a pain to configure Personally, I think the advantages of being on the JVM vastly outweigh the disadvantages: - Extremely fast and mature JIT compiler / GC algorithms - Huge library ecosystem - Easy portability across platforms Hence what I'd really like to see are better ways to integrate and / or generate native code within JVM Clojure. In particular: - Better ways to load / execute native code libraries at runtime - Macros / tools for accessing natively managed memory while still keeping a Clojure style - A really good JNA wrapper (clj-native seems along the right track.) - A native code compiler that can be executed at runtime. So we can actually compile to native code and run it dynamically. Possibly something based on LLVM would work well here. If we had all that, we would genuinely have the best of both worlds. -- -- 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
Re: Best Clojure Platform?
On Saturday, 26 January 2013 18:36:44 UTC+8, Zed Dominic wrote: Hi, I am a student, still trying to consider, if I should embrace Clojure as my language of choice. I have programmed in Java, C and Haskell (it brought me here) in the past, and I want to try out some list processing... Of everything I deduced on the Internet, Clojure is a JVM language, with side projects for CLR and JavaScript. Which platform should I marry to get started on? And, if I want to professionally embrace Clojure after I get a job, what Clojure platform should I count on? There is a Clojure-in-Clojure project too, I suppose; Any thoughts on that, will be helpful to me. I'd recommend starting with the main (JVM) version of Clojure first. This version is the most mature and well documented. JVM Clojure is also probably the most useful, certainly if you are thinking about the case of writing server-side code. This is because it has access to the huge JVM library ecosystem, which is particularly strong on the server. You can always try out the others once you are comfortable with the language. Indeed, Clojure on the server with ClojureScript running on the browser is a pretty compelling combination for some applications. -- -- 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
