Re: Clojure - CLR - JS - Visual Studio Extension
> > > I have made experiments with compiling ClojureScript to .NET code using the Microsoft.JScript JavaScript compiler and for a Hello World application it had a few hiccups in relation to compiling the Google closure-library (the use of future reserved keywords like "require" and "namespace" for variables/functions). I don't think getting ClojureScript to compile on the CLR it is insurmountable, but some work is needed. My end goal is to have core.logic accessible from .NET code, either by running the ClojureScript version on .NET or by porting it to Clojure CLR. If you would be wonderful if you would help. Cheers, Martin -- -- 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: Windows Installation
An alternative to GNU tools is to use the things that ship with Windows PowerShell and are on most developer's machines already, e.g. using the Invoke-RestMethod commandlet as an alternative to wget and curl. I have used PowerShell to simplify ClojureScript setup on Windows without too much trouble and I believe that it would be a simple solution for Clojure, too. Cheers, Martin -- -- 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: algebra system & core.logic
Symbolic computation sounds like a really great project! For your specific problem of sorting the dependencies, you can do a "topological sort" of the dependency graph of your equations in linear time (given there are no cyclic dependencies, otherwise it would detect the failure). There are standard algorithms to do that. It would be interesting to compare to core.logic's performance. Modelling the dependencies in core.logic is straightforward, but ordering them in linear time is not obvious to me - but I would love to see the code if you do it. All the best, Martin On Saturday, May 19, 2012 2:31:51 AM UTC+2, Brent Millare wrote: > > Is there work towards building an algebra system with core.logic? So one > could analyze mathematical expressions: compute symbolic derivatives, > simplify expressions, determine undefined variables, and other forms of > analysis. > > If there isn't, I have a good starting problem that I need help on. > > Lets say I have a bunch of equations, with the left hand side a single > variable, and the right is some expression. They are not ordered in any way > but I would like to order them, (if possible, otherwise throw useful > error), such that there isn't any dependency problems. Is there a good way > to do this with core.logic? And is the performance comparable to a hand > coded solution. Or put another way, can it do this in seconds for 500 > equations? > -- 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: WebSockets with Clojure
In our perf lab tests for a trading system we have gone up to around 10,000 concurrent connections and up to 20-40k messages per second with sub-10 millisecond latency on web sockets on a single server before things start breaking down (in this case the data is generated on another machine so the server is only connecting the web sockets to a message bus, it does not have any additional processing load). To get to that we had to navigate a number of bottlenecks such as threads switching, GC, serialization overhead and a number of other perf issues, but unless you plan on running heavy loads I don't think you need to worry about a few hundred connections. After setting up the connection, a web socket does not have a much more overhead than a normal socket, so on a "big enough box" your will most likely be I/O- bound. Our clients log in via a REST HTTP API, and get a web socket URI in the login response so we can easily spread the load over multiple WS servers if necessary. -- 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
(:key map) lookup vs accessor functions in large applications
Having evolved domain models in large Clojure projects over a long time, I've been going back and forth on maps contra accessor functions to opaque objects and I do see some merit in the latter even though they are not idiomatic Clojure. Basically, the crucial point for me is how well they work with refactoring. Renaming keys is done without compile-time support. I have to search for instances of :old-key and replace them with :key, and also remember to search for old-key if it is used in a key destructuring without the colon. Renaming accessor functions has the benefit of help from the compiler, which will tell me if the function is not defined so I can easily change the client code to use new name. Inside a module, the cost of the idiomatic way is bearable, but in large-scale programs I find it to be a bit on the limit. Essentially, the keys of a collection returned become an implicit contract between the consumers of the function and the function itself that is very hard to change. When I used scripting languages previously my standard response would be to say that the tests will tell you that it is broken, so there is no problem with the lack of compiler support. However, when data is being passed through layers with lazy data structures this calls for a higher level of integration in the tests which in turn has the potential to make them less robust. Despite all that I am still leaning towards the idiomatic way, but I would love to hear other's experiences of growing domain models in large Clojure projects over time and the design styles that favour that. Cheers, Martin -- 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: Getting Clojure into the workplace, how do you do it?
Initially I taught myself Clojure because it is a lot of fun. That
lead me to using it for prototyping a currency trading application and
since it worked well we just kept using Clojure for that. Some
customers don't care about the technology as long as the app is
earning them money.
I also looked for some other ways to demonstrate its value:
I got Clojure into some other projects simply by building tools the
projects needed very quickly (part of this is now open-source in the
form of a spreadsheet library: http://github.com/ative/docjure).
One example of this was munging data into Excel sheets for editing by
customers and re-importing the edited data into the source format done
in very little code. Clojure is like LINQ on steroids: even skeptics
find it hard to argue against succinct code like
(->> (load-workbook "spreadsheet.xlsx")
(select-sheet "Price List")
(select-columns {:A :name, :B :price}))
; Output
> [{:name "Foo Widget", :price 100}, {:name "Bar Widget", :price 200}]
Step by step things like this build up Clojure's credibility.
We are a .NET shop so I am currently looking into using Clojure reader-
macros with gen-class as a DSL to generate some of the code that goes
into our Domain-Driven Design applications as DLLs so it can still be
used from the existing VB.NET/C# code and with IntelliSense support in
Visual Studio.
This has a clear immediate benefit (less code, less work) and provides
a long-term option for gradually expanding the use of Clojure in our
enterprise .NET applications. It is also an extremely safe way to do
it, since we can use the existing test suite on the new version with
class-gen'd code replacements so it does not impose any risk (which is
good in financial applications).
Some other advice:
* Ignore Everybody (hat tip to Hugh Maccleod) - remember that there
are still people who have not tried Rails yet even if it was already
very convincing 5-6 years ago. Don't waste your time on them. In 5-10
years time they will come around and try Clojure.
* Get some experience with it as support for the projects - for
example as tooling. You gain the experience, you can demonstrate that
it works and you avoid endless discussions about "untested" technology
going into the heart of enterprise apps until you have some good cases
on hand.
* Ease it in gradually by mixing Clojure components into existing
applications.
* Be patient - Clojure is still small so you will have a huge
advantage over the mainstream the next many years by starting now.
* Don't be too patient - if you are in one of these industrial-age
organisations that favour easily replaceable labour and prohibit
learning new things that are not yet known to every other programmer
on the planet maybe it's time to move on.
Finally, look for sweet spots for functional programming - using a
parser combinator such as FnParse makes it very easy to write a parser
or create an external DSL, or you could use macros to create an
internal DSL very easily that would be difficult to do in other
languages. This would provide a good show-case.
The best selling point, however, is probably that Clojure mixes well
with the existing languages you may already use in your company (.NET
or JVM) so you can adopt it gradually. You don't have to retrain
everybody for everything in one big-bang event.
Much as I love Emacs, if only we could have Visual Studio integration
and ReSharper support for Clojure refactorings we could really have a
breakthrough in acceptance :-)
Cheers,
Martin
www.ative.dk
github.com/ative
github.com/mjul
--
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: State of Clojure web development
We have written a currency trading app in Clojure in my company. It has an embedded web server with a compojure app that provides an administration interface. 2. Which libraries or frameworks are you using? Which versions? Some relevant dependencies are: [compojure "0.4.0-SNAPSHOT"] [hiccup "0.2.1"] [ring/ring-devel "0.2.0"] [ring/ring-httpcore-adapter "0.2.0"] [ring/ring-jetty-adapter "0.2.0"] [ring/ring-servlet "0.2.0"] [commons-fileupload/commons-fileupload "1.2.1"]] 3. What made you choose Clojure to develop web applications in? What are the strengths of Clojure web development? The entire app is Clojure and Compjure/Hiccup is very powerful so we could build the web UI surprisingly quickly and in very little code. The order of magnitude simplification reminds me of switching to Rails and how it made everything prior to that look bloated and complex by comparison. Compojure is to Rails what Rails is to ASP.NET. 4. What do you think are the current weaknesses of web development in Clojure? What could be improved? At the time we needed an easy way to bind configuration information to the routes (we ended up wrapping each request with the configuration data which is a bit cumbersome). A more explicit way would be to use some kind of partial evaluation to bind the relevant settings to each route. 5. Anything else you want to comment on? Clojure and Compojure rock! Thanks for your work on the library :-) -- 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
