Re: drop-while and (pred item) returns nil?
On Fri, Sep 10, 2010 at 1:08 AM, Alan wrote: > I'm not 100% sure what you're asking, but I think I understand you, > and in that case you can refer to > http://groups.google.com/group/clojure/browse_thread/thread/9c7f726709e24c12/b2e2696b70d924f2?show_docid=b2e2696b70d924f2, > in which I ask this very question and get the answers I am looking > for. Hi Alan, That was my point exactly - the reference to nil in the docstring for drop-while. It's a bit confusing to me and I'd expect a boolean reference instead. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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: Standalone 1.2 contrib
On Fri, Sep 10, 2010 at 12:09 AM, Stuart Sierra wrote: > Do we need a direct link to the JAR on the download page? That's easy > enough. I think the easier the better for its adoption. If a single user has asked for it, I'd add it (even though others might consider what's available already as easy enough). Since it gonna be just a single link... :-) Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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: Macro problems with delay
On 10 Sep 2010, at 03:11, joshua-choi wrote:
And here is a full macro-expansion of the call at which the error
happens:
http://gist.github.com/572879
If I understand the comment ("the following form is the culprit...")
correctly, it's not the macroexpansion that fails, but the evaluation
of the resulting expression. Is that correct? In that case, it's not
really a macro problem, but a problem with a complex use case of alter-
var-root.
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
Re: Simple things should be simple
On Fri, 10 Sep 2010 01:08:06 -0400 John Newman wrote: > (use '[clojure.contrib.server-socket :only (create-server)] >'[clojure.contrib.duck-streams :only (read-lines)]) > (create-server 8080 > (fn [in out] (when-not (empty? (read-lines in)) (spit out "Hello, > World!\n" > > 4/0/0 Nah, 4/0/1 - I count the implementation language as a tool in every case. Unless you forgot the clj script and the #!/usr/bin/env clj line, so it's 5/0/2. Believe it or not, on at least one occasion I've put things on that level into production on the public internet. It met the requirements, including scalability for any foreseeable growth. I think that Java's strength is enterprise-level, highly scalable web servers make people assume that every problem must be a nail for that hammer. The thing is, out here in the real world, the vast majority of web-based applications have no need to be highly scalable. Sure, if you put an app on the public internet, you ought to be prepared for it to go viral and have a plan for serious scalability. But most web applications aren't on the public internet. Look around your own office - or even your own house. How many lan-only web serves do you have? They're never going to scale beyond the size of your company. I've got about six such running here (two for real services, two for development, and two for doing test builds on the deployment platform). And calibre, which runs a web server to transfer ebooks from my library to ebook readers. If you count the not-http-apache modules I'm working on, and the servers that speak that protocol, that adds another half dozen. Apps running on those don't need to be highly scalable, so why should someone deploying to them have to deal with such cruft? Now look for any kind of network appliance: routers, printers, NAS boxes, who knows what else. Chances are they have a web server embedded in them somewhere. There's no good reason for them to need to deal with two simultaneous connection, but most use an open source server that's a bit better than that. I've got at least five of those on my LAN, and I'd be surprised if the cable modem doesn't run one. They only way they'll get the kind of traffic that would require scalability is if someone DDoS's them. Further, they tend to run on boxes with very limited resources, so not only do they not need the overhead for scalability, but providing it is liable to make a noticeable impact on system performance elsewhere. Finally, for a real kicker, up through iPhone OS 3, Apple failed to provide a standard method to move data between the iPhone and desktop applications. So applications that wanted to do that tended to run a web server for the purpose (except for one oddball app that ran an ftp server). I had three or four of those before I switched to Android. Since Android lets apps write to disk that can be mounted via USB on your desktop, most do that - but I wouldn't be surprised if there was at least one web server lurking in the system somewhere. Even more limited resources, and slower CPUs thanks to the battery issues. And before you complain that Java's not appropriate for that environment, consider Java ME and Dalvik. Nah, web servers that simply don't need to be scalable far out number those that do. The only question is whether the curve is a bell curve or an inverse logarithm, but in either case things that need to be "highly scalable web servers" are out under the tail of the curve. The fast majority of web servers don't need that, they just need a simple way to get the code running. Which is why "simple things should be simple" is important - there are a lot more of them than there are of the others. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Using a keyword as object get method
user> (bean (java.io.File. "tmp.txt"))
{:path "tmp.txt", :parent nil, :hidden false, :parentFile
nil, :canonicalFile #, :freeSpace 0, :absoluteFile #, :class java.io.File, :name "tmp.txt", :absolutePath
"/home/akm/src/clojure/ddsolve/tmp.txt", :directory
false, :usableSpace 0, :canonicalPath "/home/akm/src/clojure/ddsolve/
tmp.txt", :absolute false, :totalSpace 0, :file false}
On Sep 9, 10:44 am, Sam Tingleff wrote:
> I'm using thrift-generated Java objects heavily inside hadoop and it
> would be nice to access object properties using keyword notation
> instead of .getPropertyX. At platform speed of course.
>
> Searching the list shows someone else interested in the same thing but
> no
> answer.http://groups.google.com/group/clojure/browse_thread/thread/15cf030ca...
>
> Any suggestions?
--
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: Macro problems with delay
Hi, On 10 Sep., 03:11, joshua-choi wrote: > I am running into a problem sometimes when I call a certain macro I > defined. This problem macro (and an associated problem function) is: > > http://gist.github.com/572875 > > I run into this error (which is at a call to the macro, but *not* at > the *first* time it's called for some reason!): > > http://gist.github.com/572824 > > And here is a full macro-expansion of the call at which the error > happens: > > http://gist.github.com/572879 > > I *cannot* figure this out. The error seems to be that there's a delay > directly being embedded in some macro's form, but the delay call in > the function that's causing the problem…is in a function! How can the > delay show up at hound.clj's compile time? I must confess, I'm not sure, what's going on. However the expansion looks suspicious. Everything is namespace qualified. One thing core does differently to your approach is using the var special form. You might try: (defmacro general-defmaker [def-form description rule-type-kw fn-name & forms] `(do (~def-form ~fn-name ~...@forms) (alter-var-root (var ~fn-name) named-rule-maker ~rule-type-kw) (var ~fn-name))) But this is just guessing. As I said above: everything is qualified. So maybe the problem is at some surrounding macro or so. Sincerely Meikel -- 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] Leiningen 1.3.1
Hi Phil, I upgraded to 1.3.1 but started to experience some problems with my our-classe-only hook. I made it return 0 since 1.3.1 expects a numeric return code from the compile task but then ended up with other problems in the jar task. I want to revert to 1.3.0 for a few days. Any idea about the recipe I should follow ? I downloaded the 1.3.0 script, cleared my local maven cache but it lein deps always install 1.3.1. I am missing a file to clear but did not figured it out yet. Any clues ? I'll investigate my problems with 1.3.1 and the compile hook later next week. Thank you, Luc P. Phil Hagelberg wrote .. > I'm pleased to announce the release of Leiningen 1.3.1. This release > fixes a few key bugs and introduces a handful of minor features. Here > are the highlights. > > Bug Fixes: > > * Performing a standalone install (a new feature of Leiningen 1.3.0) > now pulls in all transitive dependencies. > > * Unreadable input won't cause issues in the repl. > > * Huge classpaths no longer cause slowdown on boot. > > * Namespaces for test and help tasks are no longer skipped if their > first form is not a call to the ns macro. > > * Uberjar task will not proceed if compilation fails. > > New Features: > > * The shell-wrapper scripts may be customized. > > * repl task may be used outside the context of a project. > > * If :min-lein-version is set, users of an older Leiningen version > will see a warning. > > * Dependency jar types may be specified. (test, javadoc, etc.) > > * Regexes may be used to specify namespaces in :aot list. > > We also have improved Windows support with a zip file that should get > you everything you need: > > http://github.com/downloads/technomancy/leiningen/lein-win32.zip > > More details about the changes are at http://bit.ly/lein-news > > I'm particularly interested in the shell-wrapper functionality since > right now it's quite awkward to create Clojure projects that are > first-class citizens when it comes to the command-line. I think > shell-wrappers have the potential to significantly improve the > situation. I'm hoping to write up some more documentation on this, but > you can see the basics under "Shell Wrappers" near the bottom of the > tutorial: > > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > As always, thanks to the contributors who submitted patches for this > release: Shantanu Kumar, Colin Jones, Isaac Hodes, Alan Dipert, John > Sanda, and Alex Ott, as well as all 47 of you who have contributed in > the past: http://www.ohloh.net/p/leiningen/contributors > > If you'd like to be involved in the next release, I've started a > thread with a roadmap for 1.4.0 on the Leiningen mailing list: > > > http://groups.google.com/group/leiningen/browse_thread/thread/8352bbb974034bff > > Enjoy! > > -Phil > > -- > 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Thu, Sep 9, 2010 at 10:04 PM, Isaac Gouy wrote: > Is there any point speculating about this as outsiders? > > It was available - Data.HashTable seems to be copyright 2003. > > http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data.HashTable Huh ? point ? it was just a casual comment, no point was intended. And I have read some comments by Don that what is in the shoutout is way faster than Data.HashTable > > >> And Data.HashTable also use some mutable array thing so it is still not >> the idiomatic Haskell of everything is immutable. > > afaict idiomatic is everything referentially transparent not > everything immutable, as in - "I needed a halfway decent mutable > collection type – having a properly tested mutable collection that > actually performs well would be a godsend." > how can you assure that(let's put aside the under the hood things where it is done in C) if you break the assumption that value can be changed. BTW, it seems that to verteran Haskellers, the speed of Data.HashTable is not a concern to them as they said they don't see the need of that(mutable hasktable) in their usage. There seems to be a bug(as in it is slow) filed for this package for quite a while but no one even bother to attempt to improve it. -- 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: Simple things should be simple
(use '[clojure.contrib.server-socket :only (create-server)] '[clojure.contrib.duck-streams :only (read-lines)]) (create-server 8080 (fn [in out] (when-not (empty? (read-lines in)) (spit out "Hello, World!\n" 4/0/0 John On Thu, Sep 9, 2010 at 9:21 PM, Matt wrote: >> You cannot deploy a .clj script on a running Tomcat (yet). > > In the unstable 0.8 version of Conjure, you can create a war file by > simply adding leiningen-war to your dev-dependencies and running "lein > uberwar". You can then simply drop the war file into a Tomcat server. > The web.xml file is already created for you with a default > configuration which will work with your Conjure app out of the box. Of > course, if the web.xml file doesn't do what you need, you can still > edit it. > > The only reason I've not released 0.8 yet, is that I'm trying to make > deployment on Google App Engine nearly as easy. Unfortunately, Google > App Engine doesn't like all of the reflection stuff in Conjure. > > Obviously, Conjure is much slower and a lot more overhead than most of > the other solutions mentioned in this thread. > > -Matt Courtney > > > On Sep 9, 2:16 pm, Brenton wrote: >> Mike, >> >> While evaluating Clojure, just remember, you don't have use it for >> everything. When you need something simple, as in your examples, then >> use cgi. When you need to do something more complex then Clojure can >> help. >> >> You cannot deploy a .clj script on a running Tomcat (yet). When you >> install Tomcat, you have a ROOT context into which you can place .html >> and .jsp files and they will be dynamically loaded. This gives you >> about the same functionality as you would get from php and apache. >> >> Even though Clojure doesn't already have what you are looking for it >> would not be difficult to make it work. For example, you could create >> a generic web app that would have an embedded REPL as well as the >> ability to dynamically load code from external files. You would then >> just need to install Tomcat (which is easy) and drop this war into it. >> Form then on out you would just create simple .clj scripts and drop >> them into a directory. You could also connect to the REPL and >> dynamically add and remove code from the application. This hasn't been >> done yet because I don't think many people would find it useful. >> >> Clojure is new so when you see something missing, build it. That is >> why all of this other stuff is so simple, someone built it. >> >> Brenton >> >> On Sep 9, 10:40 am, Mike Meyer > >> 620...@mired.org> wrote: >> > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) >> >> > Brenton wrote: >> > > Mike, >> >> > > Your point has been made, simple things are simple. When you need to >> > > print "hello world" you don't need to bring Clojure into the picture. >> > > You could have given a much simpler example of needing to print "hello >> > > world" on the command line. echo "hello world" is much simpler than >> > > what you would need to do in Clojure. >> >> > The thing is, I'm evaluating clojure - that's what drags clojure into >> > it. If I wasn't interested in using clojure, I'd never have asked the >> > question. Printing "hello world" is just a simple, well-understood >> > example application. There are *lots* of applications worth putting on >> > the web that aren't much more complicated than that. I chose it to >> > emphasis how much extra work the environment that clojure seems to be >> > inextricably linked with adds. >> >> > > When faced with any problem to solve, you have to look at the tools >> > > you have available and then determine what the simplest solution will >> > > be. In your case, all of the software you need is already installed, >> > > configured and running. So it's simple. If you gave me a system with >> > > Tomcat installed, configured and running then I could do the exact >> > > same thing. It has nothing to do with Java, it has to do with what you >> > > are given to work with. >> >> > I thought I *gave* you all those things to work with when I said "not >> > counting the web server and whatever else it needs to be ready to run >> > applications." Could you show me (or point me to an web page showing) >> > how I'd go from a simple .clj script to an application running on >> > Tomcat that's been installed and is ready to run applications? If >> > that's as simple as the apache/cgi example, I'll be very happy. >> >> > > > -- >> > Mike Meyer http://www.mired.org/consulting.html >> > Independent Network/Unix/Perforce consultant, email for more information. >> >> > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org > > -- > 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 option
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 9, 7:19 pm, gary ng wrote: > On Thu, Sep 9, 2010 at 7:02 PM, Isaac Gouy wrote: > > iirc the Haskell programs, and the Clean programs, and the Pascal > > programs, and ... use translations of the simple hash table used by > > the C programs. > > > If I ever knew, I don't recall why the Haskell program does not use > > Data.HashTable > Could be that it wasn't there at the time it was submitted. Is there any point speculating about this as outsiders? It was available - Data.HashTable seems to be copyright 2003. http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data.HashTable > And Data.HashTable also use some mutable array thing so it is still not > the idiomatic Haskell of everything is immutable. afaict idiomatic is everything referentially transparent not everything immutable, as in - "I needed a halfway decent mutable collection type – having a properly tested mutable collection that actually performs well would be a godsend." And maybe the description for this bug report says it all - http://hackage.haskell.org/trac/ghc/ticket/3149 -- 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: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 5:25 AM, Andrew Gwozdziewycz wrote: >>> Interesting. I don't see any real difference between macros and C >>> preprocessor stuff and C++ templates at a conceptual level. I think > Of course the real difference is that in Lisp macros you are working > directly on the AST, where in C/C++ macros you're working at the > source level. Yes, that is an important difference. My comment was made in the context of the OP that perhaps those high-level conceptual similarities would help acceptance from his Java colleagues. Similar, but better. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Thu, Sep 9, 2010 at 7:02 PM, Isaac Gouy wrote: > iirc the Haskell programs, and the Clean programs, and the Pascal > programs, and ... use translations of the simple hash table used by > the C programs. > > If I ever knew, I don't recall why the Haskell program does not use > Data.HashTable > Could be that it wasn't there at the time it was submitted. And Data.HashTable also use some mutable array thing so it is still not the idiomatic Haskell of everything is immutable. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 9, 6:06 pm, gary ng wrote: > On Thu, Sep 2, 2010 at 6:07 PM, John Fingerhut > wrote: > > Some of the Haskell submissions are quite long for what they do. The > > k-nucleotide one, for example, implements a mutable hash table using > > features in Haskell that I had never seen before looking at that program. > > Did they need to write all of that code to solve the problem? No. Did they > > choose to, in order to get a much faster program that would be more > > competitive in run time versus other languages. Definitely. > > Is it the requirement for that particular program to handle hash table > (to test in place update) ? That seems to be the message I get from > the description of the program. Yes. > If that is the case, I doubt there is any choice for Haskell. iirc the Haskell programs, and the Clean programs, and the Pascal programs, and ... use translations of the simple hash table used by the C programs. If I ever knew, I don't recall why the Haskell program does not use Data.HashTable -- 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: Simple things should be simple
> You cannot deploy a .clj script on a running Tomcat (yet). In the unstable 0.8 version of Conjure, you can create a war file by simply adding leiningen-war to your dev-dependencies and running "lein uberwar". You can then simply drop the war file into a Tomcat server. The web.xml file is already created for you with a default configuration which will work with your Conjure app out of the box. Of course, if the web.xml file doesn't do what you need, you can still edit it. The only reason I've not released 0.8 yet, is that I'm trying to make deployment on Google App Engine nearly as easy. Unfortunately, Google App Engine doesn't like all of the reflection stuff in Conjure. Obviously, Conjure is much slower and a lot more overhead than most of the other solutions mentioned in this thread. -Matt Courtney On Sep 9, 2:16 pm, Brenton wrote: > Mike, > > While evaluating Clojure, just remember, you don't have use it for > everything. When you need something simple, as in your examples, then > use cgi. When you need to do something more complex then Clojure can > help. > > You cannot deploy a .clj script on a running Tomcat (yet). When you > install Tomcat, you have a ROOT context into which you can place .html > and .jsp files and they will be dynamically loaded. This gives you > about the same functionality as you would get from php and apache. > > Even though Clojure doesn't already have what you are looking for it > would not be difficult to make it work. For example, you could create > a generic web app that would have an embedded REPL as well as the > ability to dynamically load code from external files. You would then > just need to install Tomcat (which is easy) and drop this war into it. > Form then on out you would just create simple .clj scripts and drop > them into a directory. You could also connect to the REPL and > dynamically add and remove code from the application. This hasn't been > done yet because I don't think many people would find it useful. > > Clojure is new so when you see something missing, build it. That is > why all of this other stuff is so simple, someone built it. > > Brenton > > On Sep 9, 10:40 am, Mike Meyer > 620...@mired.org> wrote: > > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) > > > Brenton wrote: > > > Mike, > > > > Your point has been made, simple things are simple. When you need to > > > print "hello world" you don't need to bring Clojure into the picture. > > > You could have given a much simpler example of needing to print "hello > > > world" on the command line. echo "hello world" is much simpler than > > > what you would need to do in Clojure. > > > The thing is, I'm evaluating clojure - that's what drags clojure into > > it. If I wasn't interested in using clojure, I'd never have asked the > > question. Printing "hello world" is just a simple, well-understood > > example application. There are *lots* of applications worth putting on > > the web that aren't much more complicated than that. I chose it to > > emphasis how much extra work the environment that clojure seems to be > > inextricably linked with adds. > > > > When faced with any problem to solve, you have to look at the tools > > > you have available and then determine what the simplest solution will > > > be. In your case, all of the software you need is already installed, > > > configured and running. So it's simple. If you gave me a system with > > > Tomcat installed, configured and running then I could do the exact > > > same thing. It has nothing to do with Java, it has to do with what you > > > are given to work with. > > > I thought I *gave* you all those things to work with when I said "not > > counting the web server and whatever else it needs to be ready to run > > applications." Could you show me (or point me to an web page showing) > > how I'd go from a simple .clj script to an application running on > > Tomcat that's been installed and is ready to run applications? If > > that's as simple as the apache/cgi example, I'll be very happy. > > > > -- > > Mike Meyer http://www.mired.org/consulting.html > > Independent Network/Unix/Perforce consultant, email for more information. > > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- 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: A difficult Metaphor for Macros (especially for Java people)
alux wrote .. > Interesting discussion! > > I think about taking some of the topics into separate threads. Will > see, I'm a bit under project pressure. Wont tell you the language ;( > > But, @Luc > "pushing the advantage of Lisp > macros to the forefront is not obvious if the audience cannot compare > with another (good/simple) implementation they understand well." > > Thats why I want to use a nifty metaphor ;-) > > @all Get them to write a few thousand lines of assembler, they will quickly adopt macros believe me : > After reading all your answers and discussion, I ponder whether the > words of > @ Laurent PETIT > "second major difference is that you stay in the same language > for writing macros or non macros code in Lisp" > are really true. > > It is, of course, the same for my Java collegues, because its written > wit parentheses ;-) > But writing lambda forms - and this is what the usual functional > programming can be reduced to - and writing macros is very different. > Or is it not? > (At least to me it is.) > > (Macros ar tree transformations. I have a hunch that maybe lambda can > be seen as a special form of such tree transformations (but I'm a > newbee here). If this is true, a new foundation of lisp may be > interesting. Not in lambda calculus, but in tree transformation > grammars. But that doesnt belong to this thread. Nevertheless, > comments are welcome :) > > Thank you all, and kind regards, alux > > > On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote: > > The major thing that made me used macros as much as possible when available > > in any language was writing assembly code. Not 100 lines projects, 20,000 > > and > > above, mainly made of macro calls. > > > > That's when you realize that you need to use macros to generate instructions > > for three reasons: > > > > a) keeping the code size of the system within reasonable limits > > > > b) having the instant ability to change things "under the hood" by altering > > your macros instead of erring in the code trying to find the spots where > > you must add these new instructions you just find out you urgently need > > to > > make it work. > > > > c) to improve the code readability and maintainability by enforcing common > > patterns in the code. > > > > I was blessed to work on DEC environments where the macro processors were > > very strong and much more sophisticated than the C preprocessor. Not as > > good as Lisp but still very flexible and able to handle complex logic. > > > > For some reason, many common languages of the 70s/80s were missing this > > important feature, at least it was not in their respective standards (Cobol, > > Fortran, Pascal, ...). I think only Pl1 had some. > > > > One friend of mine in the 80s was working on a HP3000 in Cobol I think > > and that implementation had a macro processor but that was an exception > > at the time. > > > > My first impression is that they are not enough main macro implementations > > widely used these days aside from the C preprocessor which is pretty basic. > > > > The macro feature by itself is probably an strange/alien concept for many > > people today. > > > > Learning Lisp by itself is a big chunk so pushing the advantage of Lisp > > macros to the forefront is not obvious if the audience cannot compare > > with another (good/simple) implementation they understand well. > > > > Luc P. > > > > Laurent PETIT wrote .. > > > > > 2010/9/9 Andrew Gwozdziewycz : > > > > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT wrote: > > > >> Hello, > > > > > >> 2010/9/9 Sean Corfield : > > > >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava > wrote: > > > I found the easiest way to introduce macros is just to introduce them > > > as small syntactic sugaring. For example, getting rid of the explicit > > > (fn [] ...) for macros like (with-open file ...). > > > > > >>> Interesting. I don't see any real difference between macros and C > > > >>> preprocessor stuff and C++ templates at a conceptual level. I think > > > >>> Clojure macros are much cleaner, but essentially they are similar. So > > > >>> in the Java world, generics (templates) are not yet widely used > > > >>> outside the libraries and maybe that's why Java devs find macros hard > > > >>> to comprehend? > > > > > >> I think that even at the conceptual level, the differences are big: > > > > > >> a. C/C++ is a "pre-processor". It does a first pass on the code. > > > >> Only at the end is the C/C++ compiler invoked. In Lisps, there is > > > >> still this "first pass/second pass" thing, but it's at a waay finer > > > >> granularity level: the top level form. At the end of the evaluation of > > > >> each top level form, a new macro may have been defined and can be > > > >> called immediately by the next top level form. So not only is the > > > >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's > > > >> also not closed, even if rather limited), but it can be expanded > > >
Macro problems with delay
I am running into a problem sometimes when I call a certain macro I defined. This problem macro (and an associated problem function) is: http://gist.github.com/572875 I run into this error (which is at a call to the macro, but *not* at the *first* time it's called for some reason!): http://gist.github.com/572824 And here is a full macro-expansion of the call at which the error happens: http://gist.github.com/572879 I *cannot* figure this out. The error seems to be that there's a delay directly being embedded in some macro's form, but the delay call in the function that's causing the problem…is in a function! How can the delay show up at hound.clj's compile 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Thu, Sep 2, 2010 at 6:07 PM, John Fingerhut wrote: > Some of the Haskell submissions are quite long for what they do. The > k-nucleotide one, for example, implements a mutable hash table using > features in Haskell that I had never seen before looking at that program. > Did they need to write all of that code to solve the problem? No. Did they > choose to, in order to get a much faster program that would be more > competitive in run time versus other languages. Definitely. Is it the requirement for that particular program to handle hash table (to test in place update) ? That seems to be the message I get from the description of the program. If that is the case, I doubt there is any choice for Haskell. -- 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: Simple things should be simple
On Sep 9, 2010, at 7:06 PM, Luke Renn wrote: > I'm sure many here would disagree with me, but I would not recommend > Clojure for a college level Lisp course just yet. I would probably > recommend Racket or Dr. Scheme. > I've taught with Dr. Scheme but I like Clojure a lot better than Scheme! My course is being taught in an unusual context (e.g. no grades and it's project-based), so I don't think it's crazy to do it in Clojure. Still, the simpler things could be simpler, not only for the students but also for me, and I want to reinforce the view that this is a good thing to aim for. -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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
Re: Simple things should be simple
i don't know if this has been said as such, but: a) there's an inflection / transition point from "simple things" to "complex things". b) some systems are in the simple world, but when you get complex they restrict you or fall apart (rails?). vs. other systems are fine in the large, but suck for the simple (java web ecosystem?). c) does anybody know how to make the dial work smoothly all along the gamut of "simple" to "complex"? or do you require reworking of your simple thing over time to make it work in the "complex"? sincerely. -- 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: Simple things should be simple
On Sep 9, 2010, at 6:36 PM, David Nolen wrote: > > I started using Processing since version 22 (around 2003/4). Let's just > say... that it takes a lot of time and external contribution to reach the > level of documentation, stability and cross platform reliability that > Processing now has. Understood. It will take time for Clojure too. I'm just pointing out that this level of "simplicity for the simple stuff" is a worthy goal to aim for. Some others in this thread seem to think it's unimportant because real world applications aren't simple, or because we should assume that developers can handle the complexity, etc. Or maybe they don't see the complexity. In any event my aim was just to argue that it really is important and that there are some good models out there to aim for, eventually. -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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
Re: Simple things should be simple
On Thu, 9 Sep 2010 16:06:54 -0700 (PDT) Luke Renn wrote: > That was kind of my point. I would expect these kinds of questions, > examples, and objections from someone looking at Clojure/Ring to teach > with, not necessarily someone who want to deploy highly scalable web > applications. I'm curious - what makes you think "highly scalable web applications" and "simple things" have anything to do with each other? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 14:20:29 -0700 (PDT) Rainer Schuster wrote: > no this discussion is going to be ... won't say it. > > Quiz: > > - is your solution functional (regarding the requirements= Yes. > - is your solution scallable? (groing large or running > plattformindependent?) It will run on any of a large number of platforms, work with any of a large number of languages and web servers, and will work with far more clients than I ever expect to be able to connect to it. > - is your solution easily maintainable (in the sense of mutating it > some days to get complex and have 10 LOC) The chosen deployment methodology doesn't care how many LOC there are in the program being deployed. > - is it very easily testable Yup. > Why should clojure fit into your micro world of doing administrativ > scripting? Being a dev for 13 years I really don't like system that > don't fullfill my questions. I was a maintainer of a system containing > of 8.000.000 LOCs (were I was responsible for round about 300.000) I > can tell you tons of horrible stories. Because it's a programming language, and the questions I'm asking are *orthogonal* to questions about the programming language. I build medium-size distributed systems that do things like process hundreds of gigabytes of data a day, or build 10s of thousands of distinct Linux distributions over that same 24 hours. They use the same languages and technologies I'm talking about here. But - because they play well in an environment where "simple things should be simple" is an axiom, they also let me do zero-config deployment of simple applications. There's no fundamental reason clojure can't be used that way. Nuts, I've done it. I'm discovering that the Java community doesn't seem to care about this - or rather, is so used to the current situation that they find it acceptable. > Now how is this realted to your question? The right tools for the > right job. Yup. But a deployment tool and a programming language are different things. That the deployment tools available for clojure are so far out of line with the language itself is sad. > So the simplest possible hast nothing todo with the right choice, from > my point of view. > Its not only a matter of having the power at your fingertipps (in only > using 2 lines of code). Once again, that the application only takes two lines of code is immaterial. It could take two million. It's what it takes to get it deployed that's the problem. > There are even dynamic vs. static language wars. There's no winner, > there's no looser. It depends. > Be open minded and use the right tool for the right job an don't > complain about technologie x or y. Can I complain when the right tool doesn't exist? That's where I am now. There's a great language. There are some tools that are - at least at first glance - right tools for deploying enterprise applications built in that language. There don't seem to be any tools that are right for deploying simple applications. Of course, I'll continue complaining about technologies when they suck. If people don't complain about them, there's no chance of them ever getting fixed. Isn't that the point of MS's "Windows 7 is my fault" ads? > Have you ever used .NET or Mono? Yes, No, Why? Im not biased to *nix > (actually i'm running a win7 dev machin, because my job requires it) I've never looked at .NET or mono beyond looking over the C# language and deciding it didn't offer enough of an improvement over Java or C++ - neither of which I consider a suitable tool for real-world work - for it to be worthwhile. I've largely ignored Java outside of Clojure, and expect to continue doing so. I still like OO programming, and don't want to ruin that. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 4:02 PM, Mike Meyer wrote: > No, they've explained what *they* consider to be simple. That isn't > the same thing as actually *being* simple. +1 :-) -- 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: drop-while and (pred item) returns nil?
I'm not 100% sure what you're asking, but I think I understand you, and in that case you can refer to http://groups.google.com/group/clojure/browse_thread/thread/9c7f726709e24c12/b2e2696b70d924f2?show_docid=b2e2696b70d924f2, in which I ask this very question and get the answers I am looking for. On Sep 9, 3:50 pm, Miki wrote: > Boolean seems to work: > > user=> (drop-while #(< % 4) (range 10)) > (4 5 6 7 8 9) > user=> > > On Sep 9, 2:51 pm, Jacek Laskowski wrote: > > > Hi, > > > According to drop-while doc, (pred item) will return nil. It struck me > > as I thought the form would only return a boolean. Is the doc correct? > > What would be an example? > > > user=> (doc drop-while) > > - > > clojure.core/drop-while > > ([pred coll]) > > Returns a lazy sequence of the items in coll starting from the first > > item for which (pred item) returns nil. > > > Jacek > > > -- > > Jacek Laskowski > > Notatnik Projektanta Java EE -http://jaceklaskowski.pl > > -- 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: Simple things should be simple
On Sep 9, 5:53 pm, Lee Spector wrote: > On Sep 9, 2010, at 3:04 PM, Luke Renn wrote: > > > What exactly are you evaluating Clojure for? Because unless it's > > teaching elementary school children, the LOC it takes to deploy a > > hello world webapp is irrelevant. > > > Luke > > From the sidelines -- because I know little about web apps per se in any > environment -- Mike's original question resonated with me and I want to > second his call for making simple things simple. Clojure makes many important > things simple, particularly within the Clojure code itself, but for someone > new to the java That was kind of my point. I would expect these kinds of questions, examples, and objections from someone looking at Clojure/Ring to teach with, not necessarily someone who want to deploy highly scalable web applications. I'm sure many here would disagree with me, but I would not recommend Clojure for a college level Lisp course just yet. I would probably recommend Racket or Dr. Scheme. Luke -- 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: clojure-contrib master now in submodules
Weird. I'll have to look into this some more. Thanks for the report. -S On Sep 9, 6:43 pm, Brian Carper wrote: > Nope. When I use [org.clojure.contrib/complete "1.3.0-SNAPSHOT"] > without :classifier "bin", Maven dies because it can't find the > "complete" JAR file. Like this:http://gist.github.com/572306 > > When I specify [... :classifier "bin"], it downloads all 50+ contrib > JAR files, as well as "complete-1.3.0-SNAPSHOT-bin.jar". -- 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: clojure-contrib master now in submodules
On Sep 9, 7:00 pm, Aaron Cohen wrote: > I think the problem is that the "complete" pom needs to have > pom to indicate there's not an important jar > file to download. It does. That's why I'm confused. http://github.com/clojure/clojure-contrib/blob/master/modules/complete/pom.xml Admittedly, I haven't tested this yet... -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: Simple things should be simple
On Thu, 9 Sep 2010 14:01:19 -0700 (PDT) Luke Renn wrote: > On Sep 9, 4:13 pm, Mike Meyer 620...@mired.org> wrote: > > Here I thought I could save time by choosing a nice, simple example > > application that everyone would understand, rather than spending a lot > > of time explaining (or abstracting out) irrelevant details of some > > real-world application before asking the question about the overhead > > required to deploy java web apps. > The subject of the thread is Simple Things Should Be Simple. Others > in this thread have done a good job attempting to explain that they > are in fact simple so I won't continue. Perhaps you should play > around with ring and/or Compojure a bit and learn yourself. This is > something you would have to do for any serious evaluation anyway. No, they've explained what *they* consider to be simple. That isn't the same thing as actually *being* simple. > I will answer your specific question about deploying applications. Well, part of it, anyway > While creating a war file may involve some of what you conceive to be > boilerplate, it does so to simplify deployment of multiple > applications to a single server; which is exactly what you're now > asking about. How does typing the name of the namespace my code lives in three times into the web.xml "simplify deployment of multiple applications"? Clojure got this right - if I need to generate a class, the default name is the name of the namespace, which is right 20% of the time. > Download jetty, copy a war into the webapps directory and start the > server. Done. Don't like Jetty for some reason? Download tomcat, > copy the war to the webapps directory, start server. Done. Want > another app in that server, just copy the war into webapps. I'll take you at your word for it, though it isn't working yet (not sure I managed to correctly change the default port from the one that half the unprived apps in the world use, including calibre, but that's not a java issue). But there's still far more work in generating a war file than in doing the equivalent when it's well-designed. > It's the same with the scripts really. You think project.clj, lein, a > main class and running java -jar myapp.jar is silly when you can just > gcc myapp.c and run it with myapp. Sure, but that only works on a > single platform. The java -jar will work anywhere. You *really* want me to start the parade of variations of that three-line theme that would work on pretty much any platform that a jar file works on? Any interpreted language will do, though primitive platforms might require a wrapper to invoke the interpreter for them. > Like I said, you might think some things are boilerplate or > unnecessary, but they're done that way to provide benefits that are > beyond simplicity. Of course they are. Trouble is, they've ignored simplicity completely in the process. This reminds me of the config system for an ETL I dealt with once: it consisted of about 300 files of a dozen or so lines each (one file for each of the dozen or so processes that ran on each of the 25 or so machines involved). The original developers thought that was simple, but changing the config almost invariably caused something to break. In the second version, I applied a little thought to the configuration process, made the master program smart enough to choose intelligent defaults and count things itself, and reduced the same configuration to a single file - shared across all the machines - of about 30 lines. The new config system could do everything the old one did, but by making the common choices and previously entered values the defaults, it made simple configuration simple. Which meant that changing the config rarely broke things. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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] ACCU 2011 Conference Call for Proposals -- deadline approaching
Call for Proposals - ACCU 2011 April 13-16, 2011. Barcelo Oxford Hotel, Oxford, UK Submission deadline: 26th of September 2010 Email proposals to: Giovanni Asproni, confere...@accu.org http://www.accu.org/conference twitter: @accu2011 #accu2011 We invite you to propose a session for this leading software development conference. We have a long tradition of high quality sessions covering many aspects of software development, from programming languages (e.g., Java, C#, Python, Erlang, Haskell, Ruby, Groovy, C, C++, etc.), and technologies (libraries, frameworks, databases, etc.) to subjects about the wider development environment such as testing, architecture and design, development process, analysis, patterns, project management, and softer aspects such as team building, communication and leadership. Sessions may be either tutorial-based, presentations of case studies, or take the form of interactive workshops. We are always open to novel formats, so please contact us with your idea. The standard length of a session is 90 minutes, with some exceptions. In order to allow less experienced speakers to speak at the conference without the pressure of filling a full 90 minutes, we reserve a number of shorter 45 minute sessions. If you would like to run a session please let us know by emailing your proposals to confere...@accu.org by the 26th of September 2010 at the latest. Please include the following to support your proposal: * Title (a working title if necessary) * Type (tutorial, workshop, case study, etc.) * Duration (45/90 min) * Speaker name(s) * Speaker biography (max 150 words) * Description (approx 250 words) Proposals about specific products and technologies will be taken under consideration only if they are open source and available for free (at least for non-commercial use). If you are interested in talking about a proprietary technology, there is the possibility of "sponsored sessions" which are presented outside the standard conference schedule. Please, email confere...@accu.org for more information. If you are interested in knowing more about the conference you may like to consult the website for previous years' editions at http://www.accu.org/conference for background information. Speakers running one or more full 90 minute sessions receive a special conference package including free attendance, and assistance with their travel and accommodation costs. Speakers filling a 45 minute slot qualify for free conference attendance on the day of their session. The conference has always benefited from the strength of its programme. Please help us make 2011 another successful event. Giovanni Asproni Conference Chair -- 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: clojure-contrib master now in submodules
On Thu, Sep 9, 2010 at 6:43 PM, Brian Carper wrote: > On Sep 9, 3:13 pm, Stuart Sierra wrote: >> Can you clarify? Maven-aware build tools (e.g. Leiningen) should not >> be trying to downlaod the "clojure-contrib:complete" JAR file. >> Instead, referencing the "complete" project as a dependency should >> transitively give you all its dependencies. Does that not work? >> >> -S > > Nope. When I use [org.clojure.contrib/complete "1.3.0-SNAPSHOT"] > without :classifier "bin", Maven dies because it can't find the > "complete" JAR file. Like this: http://gist.github.com/572306 > > When I specify [... :classifier "bin"], it downloads all 50+ contrib > JAR files, as well as "complete-1.3.0-SNAPSHOT-bin.jar". > > --Brian > I think the problem is that the "complete" pom needs to have pom to indicate there's not an important jar file to download. -- Aaron -- 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: Simple things should be simple
no this discussion is going to be ... won't say it. Quiz: - is your solution functional (regarding the requirements= - is your solution scallable? (groing large or running plattformindependent?) - is your solution easily maintainable (in the sense of mutating it some days to get complex and have 10 LOC) - is it very easily testable Sure you stated out "for simple things". now have java installed, or .net (i'm actually a .net guy). I could complain about this solution not running on windows .. I do not. You have the choice, you make the move. Why should clojure fit into your micro world of doing administrativ scripting? Being a dev for 13 years I really don't like system that don't fullfill my questions. I was a maintainer of a system containing of 8.000.000 LOCs (were I was responsible for round about 300.000) I can tell you tons of horrible stories. Now how is this realted to your question? The right tools for the right job. I won't use any more tools, that don't fullfill my 4 questions. Why, you could ask? because of the experience going the hard way over and over again. Because some businesspeople told me to not use technologie x. Because they don't trust my expertise. In your unix consulting world this maybe the right choice. So the simplest possible hast nothing todo with the right choice, from my point of view. Its not only a matter of having the power at your fingertipps (in only using 2 lines of code). There are even dynamic vs. static language wars. There's no winner, there's no looser. It depends. Be open minded and use the right tool for the right job an don't complain about technologie x or y. Have you ever used .NET or Mono? Yes, No, Why? Im not biased to *nix (actually i'm running a win7 dev machin, because my job requires it) -- 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: drop-while and (pred item) returns nil?
Boolean seems to work: user=> (drop-while #(< % 4) (range 10)) (4 5 6 7 8 9) user=> On Sep 9, 2:51 pm, Jacek Laskowski wrote: > Hi, > > According to drop-while doc, (pred item) will return nil. It struck me > as I thought the form would only return a boolean. Is the doc correct? > What would be an example? > > user=> (doc drop-while) > - > clojure.core/drop-while > ([pred coll]) > Returns a lazy sequence of the items in coll starting from the first > item for which (pred item) returns nil. > > Jacek > > -- > Jacek Laskowski > Notatnik Projektanta Java EE -http://jaceklaskowski.pl -- 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: clojure-contrib master now in submodules
On Sep 9, 3:13 pm, Stuart Sierra wrote: > Can you clarify? Maven-aware build tools (e.g. Leiningen) should not > be trying to downlaod the "clojure-contrib:complete" JAR file. > Instead, referencing the "complete" project as a dependency should > transitively give you all its dependencies. Does that not work? > > -S Nope. When I use [org.clojure.contrib/complete "1.3.0-SNAPSHOT"] without :classifier "bin", Maven dies because it can't find the "complete" JAR file. Like this: http://gist.github.com/572306 When I specify [... :classifier "bin"], it downloads all 50+ contrib JAR files, as well as "complete-1.3.0-SNAPSHOT-bin.jar". --Brian -- 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: Simple things should be simple
On Thu, 9 Sep 2010 14:11:44 -0700 (PDT)
Luke Renn wrote:
> On Sep 9, 2:46 pm, Mike Meyer 620...@mired.org> wrote:
> > I have to compile and link it first. Not a problem. My 3/0/1 solution
> > could just as well have been:
> >
> > $ cat - > hello.c
> > main() {
> > puts("Content-type: text/plain\n\nHello world!\n") ;
> > }
> > ^D
> > $ cc hello.c
> > $ cp a.out /usr/local/apache22/cgi-bin/helloworld
> >
> > Anything even close to that for Tomcat and clj?
>
> Again, I'll just say, why is this relevant to a serious evaluation?
> How simple is it for you to add a dependency to 10 3rd party libraries
> and link against them? What if you want it to run on linux, windows,
> and OSX?
Well, the original version *would* work on all three of those
systems. And I can do that in something more suitable to large-scale
programming as well - like I said, pretty much any language that plays
well on Unix, whether it's interpreted, compiled or both. And if I
needed to link in extra dependencies, I'd use a make file, or CPAN, or
whatever was appropriate.
The thing is, the software tool/unix philosophy of "simple things
should be simple" means that I don't *have* to have a make file (or
whatever) for simple things. The Java philosophy is apparently "we'll
make sure there are no simple things".
> What you call "boilerplate" isn't boilerplate. It's there
> to make things that actually matter simple.
Doesn't matter - it keeps simple things from being simple, which is
what I'm asking about.
Of course, you're only half right - a lot of it *is* boilerplate, in
two different senses of the word. Look at just *one* example of the
*four* files I have to create to create a war file: web.xml.
Six lines right off the top that are going to be the same in *every*
application. That's boilerplate, as surely as "main() {" in my example
is. It's just that there's twice as much text there as there is in the
*entire system* above. I have to repeat the app name in three places
in the file: more boilerplate, of a more insidious nature. Yeah, if
you want to get fancy, those may wind up being different. I don't want
to get fancy, I want something simple, so why not provide a default
that works for the simple cases? The way it is now is like C++
requiring that I type variable types twice to create a variable. I'm
sure people who are used to that kind of crap consider it simple too.
Pretty much everything else in the deployment process is equally bad:
I have to tell the system things that should be the obvious defaults,
many of those defaults being things I've already told the system.
Sure, there may eventually be a leningen module to deal with all
this. And yeah, compared to what it shelters you from, leningen is a
great tool, and makes life a lot easier. But the fact that you *need*
something like leningen is as much an indication of the failure of the
underlying system as the fact that someone wrote cdecl is an
indication of the failure of C's type declaration syntax.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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: Simple things should be simple
On Thu, Sep 9, 2010 at 5:53 PM, Lee Spector wrote: > > One of my favorite examples of making the simple stuff simple is Processing > (processing.org), which can be downloaded and installed with a single > click, and allows you to make an applet with the graphical equivalent of > HelloWorld with one line of code, entered in an intuitive IDE with a few > very nice features like quick access to documentation, and a single click on > an "Export" button. I started using Processing since version 22 (around 2003/4). Let's just say... that it takes a lot of time and external contribution to reach the level of documentation, stability and cross platform reliability that Processing now has. David -- 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: clojure-contrib master now in submodules
Can you clarify? Maven-aware build tools (e.g. Leiningen) should not be trying to downlaod the "clojure-contrib:complete" JAR file. Instead, referencing the "complete" project as a dependency should transitively give you all its dependencies. Does that not work? -S On Sep 9, 3:47 pm, Brian Carper wrote: > On Aug 20, 7:22 am, Stuart Sierra wrote: > > > If you want to use ALL contrib libraries, add a dependency on group > > "org.clojure.contrib", artifact "complete", version "1.3.0-SNAPSHOT". > > This meta-library depends on all other contrib libraries. > > This doesn't work because as was pointed out on IRC today, there's > currently a "bin" classifier. You have to use: > > [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"] > > --Brian -- 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: Standalone 1.2 contrib
Yes, it's in the ZIP file, distributed through http://clojure.org/downloads It's in the ZIP file at target/clojure-contrib-1.2.0.jar You can also download it directly at http://build.clojure.org/releases/org/clojure/clojure-contrib/1.2.0/clojure-contrib-1.2.0.jar Do we need a direct link to the JAR on the download page? That's easy enough. -S On Sep 8, 3:21 pm, Sean Devlin wrote: > Is there a monolithic standalone contrib jar out there? A download & > forget type of thing? -- 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: Simple things should be simple
On Sep 9, 2010, at 3:04 PM, Luke Renn wrote: > What exactly are you evaluating Clojure for? Because unless it's > teaching elementary school children, the LOC it takes to deploy a > hello world webapp is irrelevant. > > Luke >From the sidelines -- because I know little about web apps per se in any >environment -- Mike's original question resonated with me and I want to second >his call for making simple things simple. Clojure makes many important things >simple, particularly within the Clojure code itself, but for someone new to >the java world some of trappings are really not simple (yet!) and I think it's >probably hard for those of you with more experience and all of the tools >installed and boilerplate memorized to have perspective on this. I'm not teaching elementary school but I am teaching college students with experience in a variety of languages (some know some java but some don't) and myself (some experience in a lot of languages, but the deepest experience in Lisp), and both they and I aim to do significant work in Clojure (and I think I already am, even though I'm still pretty clueless about most of the java-world stuff that gets discussed here). More than once I've seen people write that something is simple here and then found that the explanation required more steps than I would have guessed and tools that I never heard of. It's quite possible that these methods/tools are excellent and the best way to do the things eventually, but providing really simple ways to do the really simple things can really help in a lot of contexts, especially (but not only) for newcomers who may eventually enrich the community in many ways. To take one non-webapp example regarding basic tooling, it seems like Leiningen is one thing that can make many things relatively simple but since I've settled on Eclipse/CCW as my development/teaching environment to keep other things simple, and since I don't yet have any idea how to use Leiningen from within Eclipse/CCW, a lot of things aren't yet simple for me. I've posted about this on the CCW list and I expect that will lead to good things -- I've found the CCW folks to be extremely helpful so far -- but right now a lot of things aren't simple in my environment. One of my favorite examples of making the simple stuff simple is Processing (processing.org), which can be downloaded and installed with a single click, and allows you to make an applet with the graphical equivalent of HelloWorld with one line of code, entered in an intuitive IDE with a few very nice features like quick access to documentation, and a single click on an "Export" button. Then move the resulting folder to your server and your applet is live on the web. Add a little more code and you can quickly scale up to rich, interactive, and beautiful applets. If you want more you can add arbitrary java code and do many more things, although there are some limits imposed by the applet target and I guess this isn't a fully general programming platform. But I think it's a superb example of making the simple stuff simple while also allowing those who want to do more complicated things to do so. And it contrasts starkly with my experience with Clojure which, as much as I love the language itself (and I really really do), has had me fighting with classpaths, directory structures, emacs configs, tools that don't talk to each other, etc. to do a variety of things that seemed like they should have been simple. I know that Clojure and its associated tools are works in progress and I'm not complaining that things aren't instantly perfect. But I want to stress that it really is a very good thing to make the simple stuff really simple, and to remind people with more expertise that they themselves are not in a very good position to judge what's simple (because they are polluted by their expertise). -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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
drop-while and (pred item) returns nil?
Hi, According to drop-while doc, (pred item) will return nil. It struck me as I thought the form would only return a boolean. Is the doc correct? What would be an example? user=> (doc drop-while) - clojure.core/drop-while ([pred coll]) Returns a lazy sequence of the items in coll starting from the first item for which (pred item) returns nil. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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: Improved stack traces
http://github.com/clojure/clojure -- 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: Improved stack traces
I assume I'm just clueless here, but the last commit I see at http://github.com/richhickey/clojure is one from Stuart Halloway in June. Where do I find this so I can try it out? Or, what version do I have to tell leiningen I depend on - 1.2.0-snapshot, 1.3.0-snapshot, or something like that? On Sep 9, 1:58 pm, Rich Hickey wrote: > People frequently complain about Clojure's stack traces, and there are > now some enhancements in the master branch. In particular, there is a > new function in clojure.repl, pst, which prints a nicer stack trace of > the most recent (or a supplied) exception. It also has depth control. > pst is automatically available in the standard REPL. > > The single-line initial messages should also be better. > > Note as always that if you have a compilation/syntax error, the stack > can of course have nothing on it but the compiler logic itself. But > the file and line number of the code being compiled will, if > available, be in the single-line report. > > Feedback welcome, > > 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
Re: Simple things should be simple
On Sep 9, 2:46 pm, Mike Meyer wrote:
> I have to compile and link it first. Not a problem. My 3/0/1 solution
> could just as well have been:
>
> $ cat - > hello.c
> main() {
> puts("Content-type: text/plain\n\nHello world!\n") ;
> }
> ^D
> $ cc hello.c
> $ cp a.out /usr/local/apache22/cgi-bin/helloworld
>
> Anything even close to that for Tomcat and clj?
Again, I'll just say, why is this relevant to a serious evaluation?
How simple is it for you to add a dependency to 10 3rd party libraries
and link against them? What if you want it to run on linux, windows,
and OSX? What you call "boilerplate" isn't boilerplate. It's there
to make things that actually matter simple.
Luke
--
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: Simple things should be simple
On Sep 9, 4:13 pm, Mike Meyer wrote: > Here I thought I could save time by choosing a nice, simple example > application that everyone would understand, rather than spending a lot > of time explaining (or abstracting out) irrelevant details of some > real-world application before asking the question about the overhead > required to deploy java web apps. The subject of the thread is Simple Things Should Be Simple. Others in this thread have done a good job attempting to explain that they are in fact simple so I won't continue. Perhaps you should play around with ring and/or Compojure a bit and learn yourself. This is something you would have to do for any serious evaluation anyway. I will answer your specific question about deploying applications. While creating a war file may involve some of what you conceive to be boilerplate, it does so to simplify deployment of multiple applications to a single server; which is exactly what you're now asking about. Download jetty, copy a war into the webapps directory and start the server. Done. Don't like Jetty for some reason? Download tomcat, copy the war to the webapps directory, start server. Done. Want another app in that server, just copy the war into webapps. It's the same with the scripts really. You think project.clj, lein, a main class and running java -jar myapp.jar is silly when you can just gcc myapp.c and run it with myapp. Sure, but that only works on a single platform. The java -jar will work anywhere. Like I said, you might think some things are boilerplate or unnecessary, but they're done that way to provide benefits that are beyond simplicity. Best of luck to 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...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Improved stack traces
People frequently complain about Clojure's stack traces, and there are now some enhancements in the master branch. In particular, there is a new function in clojure.repl, pst, which prints a nicer stack trace of the most recent (or a supplied) exception. It also has depth control. pst is automatically available in the standard REPL. The single-line initial messages should also be better. Note as always that if you have a compilation/syntax error, the stack can of course have nothing on it but the compiler logic itself. But the file and line number of the code being compiled will, if available, be in the single-line report. Feedback welcome, 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
Re: Simple things should be simple
On 9 September 2010 19:16, Brenton wrote: > Mike, > > While evaluating Clojure, just remember, you don't have use it for > everything. When you need something simple, as in your examples, then > use cgi. When you need to do something more complex then Clojure can > help. > > You cannot deploy a .clj script on a running Tomcat (yet). When you > install Tomcat, you have a ROOT context into which you can place .html > and .jsp files and they will be dynamically loaded. This gives you > about the same functionality as you would get from php and apache. > > Even though Clojure doesn't already have what you are looking for it > would not be difficult to make it work. For example, you could create > a generic web app that would have an embedded REPL as well as the > ability to dynamically load code from external files. You would then > just need to install Tomcat (which is easy) and drop this war into it. > Form then on out you would just create simple .clj scripts and drop > them into a directory. > You could also connect to the REPL and > dynamically add and remove code from the application. Or use something like jnotify to notify your application that the directory has been changed and have it automagically load/reload the code. I did this once a few months back - if I changed my .clj file or added a new one, the app detected it and loaded it. > This hasn't been > done yet because I don't think many people would find it useful. > > Clojure is new so when you see something missing, build it. That is > why all of this other stuff is so simple, someone built it. > > Brenton > > > On Sep 9, 10:40 am, Mike Meyer 620...@mired.org> wrote: > > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) > > > > Brenton wrote: > > > Mike, > > > > > Your point has been made, simple things are simple. When you need to > > > print "hello world" you don't need to bring Clojure into the picture. > > > You could have given a much simpler example of needing to print "hello > > > world" on the command line. echo "hello world" is much simpler than > > > what you would need to do in Clojure. > > > > The thing is, I'm evaluating clojure - that's what drags clojure into > > it. If I wasn't interested in using clojure, I'd never have asked the > > question. Printing "hello world" is just a simple, well-understood > > example application. There are *lots* of applications worth putting on > > the web that aren't much more complicated than that. I chose it to > > emphasis how much extra work the environment that clojure seems to be > > inextricably linked with adds. > > > > > When faced with any problem to solve, you have to look at the tools > > > you have available and then determine what the simplest solution will > > > be. In your case, all of the software you need is already installed, > > > configured and running. So it's simple. If you gave me a system with > > > Tomcat installed, configured and running then I could do the exact > > > same thing. It has nothing to do with Java, it has to do with what you > > > are given to work with. > > > > I thought I *gave* you all those things to work with when I said "not > > counting the web server and whatever else it needs to be ready to run > > applications." Could you show me (or point me to an web page showing) > > how I'd go from a simple .clj script to an application running on > > Tomcat that's been installed and is ready to run applications? If > > that's as simple as the apache/cgi example, I'll be very happy. > > > > > -- > > Mike Meyer > http://www.mired.org/consulting.html > > Independent Network/Unix/Perforce consultant, email for more information. > > > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org > > -- > 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 > -- Daniel Kersten. Leveraging dynamic paradigms since the synergies of 1985. -- 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
Using a keyword as object get method
I'm using thrift-generated Java objects heavily inside hadoop and it would be nice to access object properties using keyword notation instead of .getPropertyX. At platform speed of course. Searching the list shows someone else interested in the same thing but no answer. http://groups.google.com/group/clojure/browse_thread/thread/15cf030cab0fc1/38d580b4492d8ef1 Any suggestions? -- 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: Simple things should be simple
On Thu, 9 Sep 2010 12:04:34 -0700 (PDT) Luke Renn wrote: > On Sep 9, 1:40 pm, Mike Meyer 620...@mired.org> wrote: > > The thing is, I'm evaluating clojure - that's what drags clojure into > > it. > What exactly are you evaluating Clojure for? Because unless it's > teaching elementary school children, the LOC it takes to deploy a > hello world webapp is irrelevant. Here I thought I could save time by choosing a nice, simple example application that everyone would understand, rather than spending a lot of time explaining (or abstracting out) irrelevant details of some real-world application before asking the question about the overhead required to deploy java web apps. Instead, I seem to be spending a lot more time explaining what "example" means. Ok, lets use a different example. I'm going to deploy a web app. Let's call it SuperDuper. It's going to take two arguments. The first argument is used to locate, lock and load a collection of data. If the data is already locked, it just spits out an error. If the data isn't locked, it uses the second argument to process the data IN A WAY FOR WHICH CLOJURE IS IDEAL, possibly changing it, and finally spits out it's a result. I expect the initial version to have to handle no more than a few hundred requests a day while we do usability testing, and decide if we want do any further development. Now, given that I have a clj file that implements (SuperDuper datalocation processingdirective), how much manure do I have to spread around it to get it to grow into a functioning web app deployed on your favorite web server? The key word is "on" - we may want to run more multiple variants, and don't want to have to deal with multiple servers. Further, if this works, we'll be working on other, similar, applications. All of which means we run one server and put applications on it, rather than putting every application on it's own server. If I wrote this in any language that plays well in the Unix environment (which lets out a lot of LISP-like languages), on most any reasonable Unix server, the answer is "Create an executable and name it properly." Java-based languages seem to have trouble with the first step (which is why I'm willing to consider *your* favorite server), much less the second one. FWIW, most of the languages I use can do the "run our own private server" hack. They usually take a little more overhead code than Ring. On the other hand, writing a rock-stupid http server that just does sockets and query parsing doesn't take a lot more overhead than Ring. But for reasons previously stated, this case is uninteresting. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
just skimming the thread all I see is mention of war files, which, well, who cares? just get ring and the ring jetty adapter, you don't even after to presume the existence of an installed webserver or servlet container. http://github.com/hiredman/place-for-things is something I have been playing with that uses ring and jetty. On Thu, Sep 9, 2010 at 12:33 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:48:36 -0700 (PDT) > Saul Hazledine wrote: > >> On Sep 9, 8:16 pm, Brenton wrote: >> > >> > Even though Clojure doesn't already have what you are looking for it >> > would not be difficult to make it work. For example, you could create >> > a generic web app that would have an embedded REPL as well as the >> > ability to dynamically load code from external files. You would then >> > just need to install Tomcat (which is easy) and drop this war into it. >> > Form then on out you would just create simple .clj scripts and drop >> > them into a directory. You could also connect to the REPL and >> > dynamically add and remove code from the application. This hasn't been >> > done yet because I don't think many people would find it useful. >> >> This would be really cool. Especially if, after playing around at the >> repl, you could call something like: >> (create-war "example.war") >> and it would produce a deployable web application using the .clj files >> you had loaded. > > Gee, that sounds like the web apps I was building a decade ago, except > it was standalone. It pretty much loaded all the code in the > deployment directory, let you telnet into a repl to poke around in the > guts of the system, including reloading modules, adding new ones, > resetting things. > > Unfortunately, times have changed, and I'm looking for better > tools. Clojure definitely a better language > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: matching with wild-cards in clojure multi-methods
On 9 September 2010 07:31, Meikel Brandmeyer wrote: > derive works with non-qualified keywords, but the contract disallows > that: Apparently the contract given in the docstring is being enforced in derive's 2-arg definition, but the "must be namespaced" parts of the assertions are missing from the 3-arg definition (the one which takes a custom hierarchy). This difference is quite unexpected. Could this be a bug? -- 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: clojure-contrib master now in submodules
On Aug 20, 7:22 am, Stuart Sierra wrote: > If you want to use ALL contrib libraries, add a dependency on group > "org.clojure.contrib", artifact "complete", version "1.3.0-SNAPSHOT". > This meta-library depends on all other contrib libraries. This doesn't work because as was pointed out on IRC today, there's currently a "bin" classifier. You have to use: [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"] --Brian -- 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: Simple things should be simple
On Thu, 9 Sep 2010 11:48:36 -0700 (PDT) Saul Hazledine wrote: > On Sep 9, 8:16 pm, Brenton wrote: > > > > Even though Clojure doesn't already have what you are looking for it > > would not be difficult to make it work. For example, you could create > > a generic web app that would have an embedded REPL as well as the > > ability to dynamically load code from external files. You would then > > just need to install Tomcat (which is easy) and drop this war into it. > > Form then on out you would just create simple .clj scripts and drop > > them into a directory. You could also connect to the REPL and > > dynamically add and remove code from the application. This hasn't been > > done yet because I don't think many people would find it useful. > > This would be really cool. Especially if, after playing around at the > repl, you could call something like: > (create-war "example.war") > and it would produce a deployable web application using the .clj files > you had loaded. Gee, that sounds like the web apps I was building a decade ago, except it was standalone. It pretty much loaded all the code in the deployment directory, let you telnet into a repl to poke around in the guts of the system, including reloading modules, adding new ones, resetting things. Unfortunately, times have changed, and I'm looking for better tools. Clojure definitely a better language http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 14:27:48 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 2:17 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > run the risk of fubaring some or all of the previous applications. > > That problem exists no matter how you do the configuration. But the > > less per-application configuration you have to do, the less likely it > > is to happen. > Also note that you have a certain bias as some us do based on prior > experience. I for one do not like Apache at all and will not shed a tear if > I never use it again for my own projects. I'd never use bash shell scripting > for anything beyond my .profile, much less writing a web app. Which is why I started with "I can do it with 0 configuration with my favorite tools installed, how close can javaland tools come to that?" It wasn't until someone asked me to demonstrate that apache and sh (god save us from bash) entered into it. Of course, the choice of apache and sh is irrelevant. I could have used pretty much any Unix web server, and pretty much any programming language which plays well in that environment, with about as much effort. There might have been some trivial changes to adopt things to some of them (compiled vs. interpreted, .cgi suffix vs cgi-bin directory, etc.), but the point remains that the underlying philosophy of this ecosystem means that simple things are simple. > Note, that if I don't know anything about apache or bash, then you have no > valid point. There is nothing simple about installing apache from scratch. > There's nothing simple about bash shell scripting. On *some* systems getting > these installed is easier, on other systems it's harder. Depending on which > tools/languages/databases (and, god forbid, which versions) I'd rather use, > it can be much, much, much harder. Which is why I *explicitly* asked people to show me how to do this using *their favorite tools*. > So enough about simplicity. What we're really talking about here is > familiarity. It's takes me no time at all to get a working Clojure web app > and running. I have no idea to do the things that you are describing as > being simple with apache, httpd.conf, and bash. No, it's not about familiarity, it's about boilerplate. You provided an example that was much better than anything I expected to find. I'd still like to see what it takes to use that to create something I can deploy on Tomcat or GlassFish or whatever, than as a standalone server. Having to run standalone servers for every little applcation - isn't simple http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: A difficult Metaphor for Macros (especially for Java people)
Interesting discussion! I think about taking some of the topics into separate threads. Will see, I'm a bit under project pressure. Wont tell you the language ;( But, @Luc "pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well." Thats why I want to use a nifty metaphor ;-) @all After reading all your answers and discussion, I ponder whether the words of @ Laurent PETIT "second major difference is that you stay in the same language for writing macros or non macros code in Lisp" are really true. It is, of course, the same for my Java collegues, because its written wit parentheses ;-) But writing lambda forms - and this is what the usual functional programming can be reduced to - and writing macros is very different. Or is it not? (At least to me it is.) (Macros ar tree transformations. I have a hunch that maybe lambda can be seen as a special form of such tree transformations (but I'm a newbee here). If this is true, a new foundation of lisp may be interesting. Not in lambda calculus, but in tree transformation grammars. But that doesnt belong to this thread. Nevertheless, comments are welcome :) Thank you all, and kind regards, alux On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote: > The major thing that made me used macros as much as possible when available > in any language was writing assembly code. Not 100 lines projects, 20,000 and > above, mainly made of macro calls. > > That's when you realize that you need to use macros to generate instructions > for three reasons: > > a) keeping the code size of the system within reasonable limits > > b) having the instant ability to change things "under the hood" by altering > your macros instead of erring in the code trying to find the spots where > you must add these new instructions you just find out you urgently need to > make it work. > > c) to improve the code readability and maintainability by enforcing common > patterns in the code. > > I was blessed to work on DEC environments where the macro processors were > very strong and much more sophisticated than the C preprocessor. Not as > good as Lisp but still very flexible and able to handle complex logic. > > For some reason, many common languages of the 70s/80s were missing this > important feature, at least it was not in their respective standards (Cobol, > Fortran, Pascal, ...). I think only Pl1 had some. > > One friend of mine in the 80s was working on a HP3000 in Cobol I think > and that implementation had a macro processor but that was an exception > at the time. > > My first impression is that they are not enough main macro implementations > widely used these days aside from the C preprocessor which is pretty basic. > > The macro feature by itself is probably an strange/alien concept for many > people today. > > Learning Lisp by itself is a big chunk so pushing the advantage of Lisp > macros to the forefront is not obvious if the audience cannot compare > with another (good/simple) implementation they understand well. > > Luc P. > > Laurent PETIT wrote .. > > > 2010/9/9 Andrew Gwozdziewycz : > > > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT > > > wrote: > > >> Hello, > > > >> 2010/9/9 Sean Corfield : > > >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava > > >>> wrote: > > I found the easiest way to introduce macros is just to introduce them > > as small syntactic sugaring. For example, getting rid of the explicit > > (fn [] ...) for macros like (with-open file ...). > > > >>> Interesting. I don't see any real difference between macros and C > > >>> preprocessor stuff and C++ templates at a conceptual level. I think > > >>> Clojure macros are much cleaner, but essentially they are similar. So > > >>> in the Java world, generics (templates) are not yet widely used > > >>> outside the libraries and maybe that's why Java devs find macros hard > > >>> to comprehend? > > > >> I think that even at the conceptual level, the differences are big: > > > >> a. C/C++ is a "pre-processor". It does a first pass on the code. > > >> Only at the end is the C/C++ compiler invoked. In Lisps, there is > > >> still this "first pass/second pass" thing, but it's at a waay finer > > >> granularity level: the top level form. At the end of the evaluation of > > >> each top level form, a new macro may have been defined and can be > > >> called immediately by the next top level form. So not only is the > > >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's > > >> also not closed, even if rather limited), but it can be expanded > > >> during the compilation of the "program". > > > > Of course the real difference is that in Lisp macros you are working > > > directly on the AST, where in C/C++ macros you're working at the > > > source level. My understanding of the C/C++ preprocessor is that it > > > more or less does a string substitution, which *may* lead to a
Re: Simple things should be simple
On Sep 9, 1:40 pm, Mike Meyer wrote: > The thing is, I'm evaluating clojure - that's what drags clojure into > it. What exactly are you evaluating Clojure for? Because unless it's teaching elementary school children, the LOC it takes to deploy a hello world webapp is irrelevant. Luke -- 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: Knowing in advance the complexity of count
Inexplicably (counted? "abcd") returns false. On Sep 9, 11:33 am, Sunil S Nandihalli wrote: > actually there is a function called > > counted? > > Sunil. > > On Thu, Sep 9, 2010 at 8:59 PM, Nicolas Oury wrote: > > Thank you very much. > > > Never looked closely at count definition. > > > I assumed it was a forawrd to .count of Counted, which explains my problem. > > > I kind of remembered the O(1) of Counted and get mixed up. > > > Best regards, > > > Nicolas. > > > On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > > > Hi, > > > > On 9 Sep., 16:45, Nicolas Oury wrote: > > > >> is it a way to do so? > > > > You can check the Counted marker interface for clojure collections. > > > But this won't cover Strings etc. More information here: > > >http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT... > > > > Sincerely > > > Meikel > > > > -- > > > 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 > > > -- > > Sent from an IBM Model M, 15 August 1989. > > > -- > > 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: Simple things should be simple
On Thu, Sep 9, 2010 at 11:17 AM, Mike Meyer wrote: > That problem exists no matter how you do the configuration. But the > less per-application configuration you have to do, the less likely it > is to happen. (i might be not-quite-following, but) no, i think the problem i mentioned explicitly doesn't exist in the case of lots of separate config files, one per application, that have duplicated content. sure, it has /another/ problem to replace the one i mentioned, but it is a different thing. in other words: i think there isn't a silver bullet. everything is about context. choose your pain. etc. sincerely. -- 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: Simple things should be simple
On Sep 9, 8:16 pm, Brenton wrote: > > Even though Clojure doesn't already have what you are looking for it > would not be difficult to make it work. For example, you could create > a generic web app that would have an embedded REPL as well as the > ability to dynamically load code from external files. You would then > just need to install Tomcat (which is easy) and drop this war into it. > Form then on out you would just create simple .clj scripts and drop > them into a directory. You could also connect to the REPL and > dynamically add and remove code from the application. This hasn't been > done yet because I don't think many people would find it useful. > This would be really cool. Especially if, after playing around at the repl, you could call something like: (create-war "example.war") and it would produce a deployable web application using the .clj files you had loaded. Saul -- 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: Simple things should be simple
On Thu, 9 Sep 2010 11:16:11 -0700 (PDT)
Brenton wrote:
> While evaluating Clojure, just remember, you don't have use it for
> everything. When you need something simple, as in your examples, then
> use cgi. When you need to do something more complex then Clojure can
> help.
The first problem with that is that this stuff seems show up
*everywhere* in Javaland. It's not just web apps, it's pretty much
anything. Second, just because a *problem* is complex and would
benefit from Clojure doesn't mean that the requirements for deployment
are complex and need more than a simple cgi (for example!) would
require. Yes, when the choice is 150 lines of C with 0 lines of config
vs. 20 lines of Clojure with with 10 lines of config, it doesn't look
so bad - but 30% of the work being overhead still sucks.
> You cannot deploy a .clj script on a running Tomcat (yet). When you
> install Tomcat, you have a ROOT context into which you can place .html
> and .jsp files and they will be dynamically loaded. This gives you
> about the same functionality as you would get from php and apache.
I didn't ask "how do I deploy a .clj script on a running Tomcat". I
asked "how do I go from a .clj script to an application running on
Tomcat"? I can't deploy a C program on running Apache server either -
I have to compile and link it first. Not a problem. My 3/0/1 solution
could just as well have been:
$ cat - > hello.c
main() {
puts("Content-type: text/plain\n\nHello world!\n") ;
}
^D
$ cc hello.c
$ cp a.out /usr/local/apache22/cgi-bin/helloworld
Anything even close to that for Tomcat and clj?
> Clojure is new so when you see something missing, build it. That is
> why all of this other stuff is so simple, someone built it.
Good advice. That's what I've been doing so far. On the other hand,
I'd rather spend my time building the things that interest me rather
than reinventing wheels for which I already have adequately round
examples. If my expectations of "adequately round" are much higher
than the communities, then I'll wind up doing to much of the latter
and not enough of the former, and will probably be happier elsewhere.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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: A difficult Metaphor for Macros (especially for Java people)
The major thing that made me used macros as much as possible when available
in any language was writing assembly code. Not 100 lines projects, 20,000 and
above, mainly made of macro calls.
That's when you realize that you need to use macros to generate instructions
for three reasons:
a) keeping the code size of the system within reasonable limits
b) having the instant ability to change things "under the hood" by altering
your macros instead of erring in the code trying to find the spots where
you must add these new instructions you just find out you urgently need to
make it work.
c) to improve the code readability and maintainability by enforcing common
patterns in the code.
I was blessed to work on DEC environments where the macro processors were
very strong and much more sophisticated than the C preprocessor. Not as
good as Lisp but still very flexible and able to handle complex logic.
For some reason, many common languages of the 70s/80s were missing this
important feature, at least it was not in their respective standards (Cobol,
Fortran, Pascal, ...). I think only Pl1 had some.
One friend of mine in the 80s was working on a HP3000 in Cobol I think
and that implementation had a macro processor but that was an exception
at the time.
My first impression is that they are not enough main macro implementations
widely used these days aside from the C preprocessor which is pretty basic.
The macro feature by itself is probably an strange/alien concept for many
people today.
Learning Lisp by itself is a big chunk so pushing the advantage of Lisp
macros to the forefront is not obvious if the audience cannot compare
with another (good/simple) implementation they understand well.
Luc P.
Laurent PETIT wrote ..
> 2010/9/9 Andrew Gwozdziewycz :
> > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT
> > wrote:
> >> Hello,
> >>
> >> 2010/9/9 Sean Corfield :
> >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava
> >>> wrote:
> I found the easiest way to introduce macros is just to introduce them
> as small syntactic sugaring. For example, getting rid of the explicit
> (fn [] ...) for macros like (with-open file ...).
> >>>
> >>> Interesting. I don't see any real difference between macros and C
> >>> preprocessor stuff and C++ templates at a conceptual level. I think
> >>> Clojure macros are much cleaner, but essentially they are similar. So
> >>> in the Java world, generics (templates) are not yet widely used
> >>> outside the libraries and maybe that's why Java devs find macros hard
> >>> to comprehend?
> >>
> >> I think that even at the conceptual level, the differences are big:
> >>
> >> a. C/C++ is a "pre-processor". It does a first pass on the code.
> >> Only at the end is the C/C++ compiler invoked. In Lisps, there is
> >> still this "first pass/second pass" thing, but it's at a waay finer
> >> granularity level: the top level form. At the end of the evaluation of
> >> each top level form, a new macro may have been defined and can be
> >> called immediately by the next top level form. So not only is the
> >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's
> >> also not closed, even if rather limited), but it can be expanded
> >> during the compilation of the "program".
> >
> > Of course the real difference is that in Lisp macros you are working
> > directly on the AST, where in C/C++ macros you're working at the
> > source level. My understanding of the C/C++ preprocessor is that it
> > more or less does a string substitution, which *may* lead to a syntax
> > errors (you often see #define X(y) do { y } while (0); to get around
> > different limitations), or undesired results, not to mention
> > unintended variable capture, etc, etc, etc.
> >
> > The fact that Lisp macros actually operate on the AST means that Lisp
> > macros can make *changes* to the AST (insert things, remove things,
> > rearrange things), and *not* just substitute FOO for BAR. This is a
> > hell of a lot more powerful.
>
> Yeah
>
> --
> 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: Simple things should be simple
On Thu, Sep 9, 2010 at 2:17 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > > run the risk of fubaring some or all of the previous applications. > > That problem exists no matter how you do the configuration. But the > less per-application configuration you have to do, the less likely it > is to happen. > > Also note that you have a certain bias as some us do based on prior experience. I for one do not like Apache at all and will not shed a tear if I never use it again for my own projects. I'd never use bash shell scripting for anything beyond my .profile, much less writing a web app. Note, that if I don't know anything about apache or bash, then you have no valid point. There is nothing simple about installing apache from scratch. There's nothing simple about bash shell scripting. On *some* systems getting these installed is easier, on other systems it's harder. Depending on which tools/languages/databases (and, god forbid, which versions) I'd rather use, it can be much, much, much harder. So enough about simplicity. What we're really talking about here is familiarity. It's takes me no time at all to get a working Clojure web app and running. I have no idea to do the things that you are describing as being simple with apache, httpd.conf, and bash. David -- 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: Simple things should be simple
On Thu, 9 Sep 2010 11:00:48 -0700 Raoul Duke wrote: > On Thu, Sep 9, 2010 at 10:07 AM, Mike Meyer > wrote: > > The difference is that that 4 lines has to be repeated *for every > > project*. Yeah, /usr/local/etc/apache/conf.d is a lot more > > complicated. But I only need to do it once, and it works for every > > application. > until you need to change it to support a new application's needs, and > run the risk of fubaring some or all of the previous applications. That problem exists no matter how you do the configuration. But the less per-application configuration you have to do, the less likely it is to happen. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
Mike, While evaluating Clojure, just remember, you don't have use it for everything. When you need something simple, as in your examples, then use cgi. When you need to do something more complex then Clojure can help. You cannot deploy a .clj script on a running Tomcat (yet). When you install Tomcat, you have a ROOT context into which you can place .html and .jsp files and they will be dynamically loaded. This gives you about the same functionality as you would get from php and apache. Even though Clojure doesn't already have what you are looking for it would not be difficult to make it work. For example, you could create a generic web app that would have an embedded REPL as well as the ability to dynamically load code from external files. You would then just need to install Tomcat (which is easy) and drop this war into it. Form then on out you would just create simple .clj scripts and drop them into a directory. You could also connect to the REPL and dynamically add and remove code from the application. This hasn't been done yet because I don't think many people would find it useful. Clojure is new so when you see something missing, build it. That is why all of this other stuff is so simple, someone built it. Brenton On Sep 9, 10:40 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) > > Brenton wrote: > > Mike, > > > Your point has been made, simple things are simple. When you need to > > print "hello world" you don't need to bring Clojure into the picture. > > You could have given a much simpler example of needing to print "hello > > world" on the command line. echo "hello world" is much simpler than > > what you would need to do in Clojure. > > The thing is, I'm evaluating clojure - that's what drags clojure into > it. If I wasn't interested in using clojure, I'd never have asked the > question. Printing "hello world" is just a simple, well-understood > example application. There are *lots* of applications worth putting on > the web that aren't much more complicated than that. I chose it to > emphasis how much extra work the environment that clojure seems to be > inextricably linked with adds. > > > When faced with any problem to solve, you have to look at the tools > > you have available and then determine what the simplest solution will > > be. In your case, all of the software you need is already installed, > > configured and running. So it's simple. If you gave me a system with > > Tomcat installed, configured and running then I could do the exact > > same thing. It has nothing to do with Java, it has to do with what you > > are given to work with. > > I thought I *gave* you all those things to work with when I said "not > counting the web server and whatever else it needs to be ready to run > applications." Could you show me (or point me to an web page showing) > how I'd go from a simple .clj script to an application running on > Tomcat that's been installed and is ready to run applications? If > that's as simple as the apache/cgi example, I'll be very happy. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 10:07 AM, Mike Meyer wrote: > The difference is that that 4 lines has to be repeated *for every > project*. Yeah, /usr/local/etc/apache/conf.d is a lot more > complicated. But I only need to do it once, and it works for every > application. until you need to change it to support a new application's needs, and run the risk of fubaring some or all of the previous 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
Re: Simple things should be simple
On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) Brenton wrote: > Mike, > > Your point has been made, simple things are simple. When you need to > print "hello world" you don't need to bring Clojure into the picture. > You could have given a much simpler example of needing to print "hello > world" on the command line. echo "hello world" is much simpler than > what you would need to do in Clojure. The thing is, I'm evaluating clojure - that's what drags clojure into it. If I wasn't interested in using clojure, I'd never have asked the question. Printing "hello world" is just a simple, well-understood example application. There are *lots* of applications worth putting on the web that aren't much more complicated than that. I chose it to emphasis how much extra work the environment that clojure seems to be inextricably linked with adds. > When faced with any problem to solve, you have to look at the tools > you have available and then determine what the simplest solution will > be. In your case, all of the software you need is already installed, > configured and running. So it's simple. If you gave me a system with > Tomcat installed, configured and running then I could do the exact > same thing. It has nothing to do with Java, it has to do with what you > are given to work with. I thought I *gave* you all those things to work with when I said "not counting the web server and whatever else it needs to be ready to run applications." Could you show me (or point me to an web page showing) how I'd go from a simple .clj script to an application running on Tomcat that's been installed and is ready to run applications? If that's as simple as the apache/cgi example, I'll be very happy. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 12:23:25 -0400 Andrew Gwozdziewycz wrote: > On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer > wrote: > > On Thu, 9 Sep 2010 11:30:51 -0400 > > Wilson MacGyver wrote: > > > >> I'm not sure what your point is. If I want to write a hello world php > >> script on a unix > >> system, but apache and mod_php weren't setup. I'd first have to install > >> them > >> and configure them. > > > > That simple things should be simple. Setting up a web server - and > > associated tools - to the point that you can install applications on > > it isn't necessarily simple, so I don't expect it to be simple. On the > > other hand, I only have to do that *once*, not once per application > > (at least, I hope I don't have to do it once per application!). > > Am I right in that what you're asking for is something akin to PHP > where you upload a jar or *.clj and it "Just Works"(tm) ? > > I want that too, but this isn't a complaint simply of clojure, it's of > web architectures in general. Exactly. Well, I'd say "java web architectures", but I'm hoping there is a simple solutions for simple applications out there. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: lisp error system in clojure
On Thu, Sep 9, 2010 at 9:21 AM, Seth wrote: > exact what i want! > Heres a nice link which describes it > > http://pragprog.com/magazines/2009-07/when-things-go-wrong If you actually use any of the continue or continue-with features in real-world code, or build any kind of error hierarchy, please let me know. These features seem very complex for how often they're used so I'd be pleased to find a simpler subset that is at least as useful. --Chouser http://joyofclojure.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
Re: Simple things should be simple
On Thu, 9 Sep 2010 09:06:33 -0700 (PDT) Paul deGrandis wrote: > I think the point is missed with this example. > > Given your hello world example, how much effort does it take you to > add URL args, make it operate like a RESTful resource, change the > route that triggers it, add user sessions, address security concerns, > template out responses, tweak those templates without touching the > code, etc. I think you've missed the point of the example. Not everything requires arguments, restful resources, session tracking, etc. If I need those things, I have no problem using a framework that gives them to me. The thing is, if I don't need them, I don't *want* to have to deal things that provide them. Simple things should be simple. Say I'm having a problem with the cpu in a web server overheating. I want to install a simple hack so I can check the temperature on my phone's browser when I'm home (or connected in through the vpn). The shell script/CGI to do this is pretty much identical to the hello world example: #!/bin/sh echo 'Content-type: text/plain\n' sysctl dev.cpu.0.temperature If I didn't have a server installed, it'd be a little bit more complicated, but not a lot. The problem is so simple I don't need to "build up" to it, but the Java world still seems to insist I have that ability - and the complexity that goes with it. Which means that simple things aren't so simple. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 16:35:15 +0100 Bruce Durling wrote: > Mike, > > If you are happy with cgi and if we posit that clojure is a compiled > language and leiningen is the same as make. The I submit the following > bit of fluff: > > At a prompt: > > $ lein new hw > $ cd hw > $ lein deps > > Then edit project.clj to look as follows: > > (defproject hw "0.0.1" > :description "The smallest hello world that will work." > :dependencies [[org.clojure/clojure "1.2.0"] > [org.clojure/clojure-contrib "1.2.0"]] > :aot [hw.core] > :main hw.core) > > Then edit hw/core.clj as follows: > > (ns hw.core > (:gen-class)) > (defn -main [& args] (println "Hello World.")) > > At a prompt: > > $ lein uberjar > > And create the following shell script hw.sh > > #! /bin/bash > java -jar hw-0.0.1-standalone.jar > > I'm sure you can wire the shell script into your apache. And this > isn't as short as a shell/python/perl script that does print or echo. > > I also fear this is descending into perl golf, but I fancied having a > crack at this anyway on a brain fried day. Yup, and I've seriously thought about something like that. Two issues: my measurements show that using a jar doesn't really improve runtime that much. The other is that, lein works sorta-kinda like make. I like make. But as I just posted, I don't use it for one-file programs or programs that don't need building. That doesn't seem to be possible with lein. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 17:15:09 +0100 Edmund Jackson wrote: > You assume the presence of a configured web server but not a text editor ? Actually, I did assume a text editor - provided any text editor would do. I chose to use my favorite simple text editor (cat) here. > The only constructive thing I can say is that the set of things that may be > considered simple in the clojure setup above is vastly greater than the > alternative you present. If the cost is a 4 line 'boilerplate' (and I'm > pointedly not going to compare that to /etc/apache/conf.d) I think its a low > price. The difference is that that 4 lines has to be repeated *for every project*. Yeah, /usr/local/etc/apache/conf.d is a lot more complicated. But I only need to do it once, and it works for every application. The thing is, I can write stand-alone servers with Unix tools as well. They're a bit longer than the clojure version, but they still require no external configuration, and just the language processor. I mean, make is a nifty tool for doing builds, but I don't bother with make files for single-file programs or programs that don't need to be built. I'd be much less happy with it if it if I was required to use it for such simple things - which seems to be where the java world is. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 12:32:27 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > Clojure great. No questions about that. WAR files, CLASSPATHs, having > > to wrap *every little command* in it's own script - that's what I'm > > looking at. > > > I've already shown that you don't need WAR files. If you really, really hate But only if I'm willing to deploy every application in it's own web server. At least as far as I can tell. And you lose the robustness of apache. > the CLASSPATH you should look at cake. It does require ruby, but it let's > you essentially write "instant-on" Clojure shell scripts as well as give you > access to things like the working shell directory if that's the way you want > to work with Clojure. > >#!/usr/bin/env cake run >(println "Hello world!") Um, #!/usr/bin/env clj (println "Hello world!") works fine for me. Better yet, if I know I have a running nailgun, I can do: #!/usr/bin/env clojure (println "Hello world!") (one of these days, I'll patch nailgun to launch itself if it can't find a server) And get much quicker responses. The question now is, how well do all these things interact with each other? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:32 PM, David Nolen wrote: > On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer > wrote: >> >> Clojure great. No questions about that. WAR files, CLASSPATHs, having >> to wrap *every little command* in it's own script - that's what I'm >> looking at. > > I've already shown that you don't need WAR files. If you really, really hate > the CLASSPATH you should look at cake. It does require ruby, but it let's > you essentially write "instant-on" Clojure shell scripts as well as give you > access to things like the working shell directory if that's the way you want > to work with Clojure. > #!/usr/bin/env cake run > (println "Hello world!") > Other people have felt your pain and have started building solutions. You > can help them out by using those solutions and giving feedback :) Woah. I knew cake did some funky build stuff, but I didn't realize you could make use of it's "global project" like that. The global project seems to amount to something like Python's site-packages or Ruby's gems, right? Just a repo of installed packages for the system? What's the reason that this couldn't be done directly in clojure? (probably not the best place to start this conversation of course) -- http://www.apgwoz.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
Re: Simple things should be simple
On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:30:51 -0400 > Wilson MacGyver wrote: > >> I'm not sure what your point is. If I want to write a hello world php >> script on a unix >> system, but apache and mod_php weren't setup. I'd first have to install them >> and configure them. > > That simple things should be simple. Setting up a web server - and > associated tools - to the point that you can install applications on > it isn't necessarily simple, so I don't expect it to be simple. On the > other hand, I only have to do that *once*, not once per application > (at least, I hope I don't have to do it once per application!). Am I right in that what you're asking for is something akin to PHP where you upload a jar or *.clj and it "Just Works"(tm) ? I want that too, but this isn't a complaint simply of clojure, it's of web architectures in general. -- http://apgwoz.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
Re: Simple things should be simple
I think the point is missed with this example. Given your hello world example, how much effort does it take you to add URL args, make it operate like a RESTful resource, change the route that triggers it, add user sessions, address security concerns, template out responses, tweak those templates without touching the code, etc. Some in that list are easy to do via the method above, others are painstaking. What you give up in simplicity, you gain in extensibility and scalability (often, not always). This is true across almost all of the primary non-functional requirements. A good framework is one that lets you build up to a problem, using only the pieces you need and minimizing the time you spend operating with the framework. The mindset in this community naturally gravitates to that solution (function and component combination), but you can find it in other frameworks/languages (Pylons is a great example). Paul On Sep 9, 8:47 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > > Edmund Jackson wrote: > > Hi Mike, > > > Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- 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: Simple things should be simple
Mike, If you are happy with cgi and if we posit that clojure is a compiled language and leiningen is the same as make. The I submit the following bit of fluff: At a prompt: $ lein new hw $ cd hw $ lein deps Then edit project.clj to look as follows: (defproject hw "0.0.1" :description "The smallest hello world that will work." :dependencies [[org.clojure/clojure "1.2.0"] [org.clojure/clojure-contrib "1.2.0"]] :aot [hw.core] :main hw.core) Then edit hw/core.clj as follows: (ns hw.core (:gen-class)) (defn -main [& args] (println "Hello World.")) At a prompt: $ lein uberjar And create the following shell script hw.sh #! /bin/bash java -jar hw-0.0.1-standalone.jar I'm sure you can wire the shell script into your apache. And this isn't as short as a shell/python/perl script that does print or echo. I also fear this is descending into perl golf, but I fancied having a crack at this anyway on a brain fried day. cheers, Bruce -- 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: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 10:04 AM, ajuc wrote:
>
>
> On 9 Wrz, 14:25, Andrew Gwozdziewycz wrote:
>> The fact that Lisp macros actually operate on the AST means that Lisp
>> macros can make *changes* to the AST (insert things, remove things,
>> rearrange things), and *not* just substitute FOO for BAR. This is a
>> hell of a lot more powerful.
>>
>> --http://www.apgwoz.com
>
> To be fair to C and C++ they allow changing AST:
>
> #define UNLESS(x,y) {if (!(x)) {y;} };
>
> This macro changes (UNLESS x y) to (if (not x) y) - this is different
> AST trees.
>
> The only difference I see is that in C you have to work with
> characters, when in lisp you work with lists, and that in C you can
> only use preprocessor directives at compile time (you can't output
> diffrent code in macro depending on the structure of its arguments),
> when in lisp you can use lisp at compile time to change what code will
> be created by macro.
Well, C preprocessor macros don't really *change* the AST, it
*affects* the source *before* it's passed to the compiler (the
compiler creates the AST). You've also stumbled on the most important
difference between the two types--those differences make Lisp style
macros far more powerful.
--
http://www.apgwoz.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
Re: lisp error system in clojure
exact what i want! Heres a nice link which describes it http://pragprog.com/magazines/2009-07/when-things-go-wrong On Sep 9, 6:20 am, Meikel Brandmeyer wrote: > Hi, > > On 9 Sep., 05:31, Seth wrote: > > > Is there any code out there which reproduces common lisp's restart > > error handling capabilities? > > I think clojure.contrib.error-kit is the closest approach. > > Sincerely > Meikel -- 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: $'s in java class member names and set!
I suspect $ is in munge because Rich and company may want to use it as a special reader character. $'s used to access inner classes work fine. I'd be fine with that as long as there's still a way to access Java identifiers with dollar signs (perhaps a special macro). On Sep 9, 3:49 am, Michał Marczyk wrote: > That's probably due to a problem with clojure.core/munge I recently > reported on the Dev list [1] -- see a proposed patch attached to my > first e-mail in that thread. I notice there still hasn't been any > response to that issue... I think I'm just going to go ahead an open a > ticket for this tonight. > > Sincerely, > Michał > > [1]http://groups.google.com/group/clojure-dev/browse_thread/thread/9caab... -- 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: Simple things should be simple
On Thu, 9 Sep 2010 11:52:30 -0400 Wilson MacGyver wrote: > How are you going to handle session? How are you going to handle > database from a echo script? What, you've never generated HTML directly from an SQL script? Any good SQL system will do that for you. All of these things are *possible* using CGI and a shell script. That doesn't mean it's desirable - I don't use the shell much for anything that requires more than two loops myself. The point is that these things aren't *required* for all applications, and I shouldn't have to deal with complexity they incur if I don't need them. Simple things should be simple. It seems to me as if once you drag java into the equation, nothing is simple. I'm trying to figure out if that's correct or not. > I mean, I can counter by just create a hello.html in apache > and put "hello world" in there. It's 1 line, 0 to deploy. And it's FAST. > It's even cached and uses no cpu time being served. Yup. And you can use SSI to do other simple things as well. I never used SSI - I pretty much detested what it did to web servers - but it was very popular, because it made *simple things simple*. > that doesn't really mean that using web dev only using html > is simple or is desirable. Actually, it simple *if you're doing simple things*. Yeah, the Java tools may rock if you're doing complicated, enterprise-style applications. Having to deal with that level of complexity to turn off my garage light before I go to bed sucks. > Having done web dev using cgi long ago, I don't think I want to go back > to that. I'm not asking you to. I'm asking if there's anything that's that simple that can be used for simple tasks if your application runs on the JVM. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
Mike, Your point has been made, simple things are simple. When you need to print "hello world" you don't need to bring Clojure into the picture. You could have given a much simpler example of needing to print "hello world" on the command line. echo "hello world" is much simpler than what you would need to do in Clojure. When faced with any problem to solve, you have to look at the tools you have available and then determine what the simplest solution will be. In your case, all of the software you need is already installed, configured and running. So it's simple. If you gave me a system with Tomcat installed, configured and running then I could do the exact same thing. It has nothing to do with Java, it has to do with what you are given to work with. For David Nolan's example above, what you are getting compared to how much code you have to write is actually quite amazing. And when you start that way, the answer to the question "What if I wanted to do X?" is usually much simpler. And I agree with everything Zach said above. Brenton On Sep 9, 9:22 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 09:03:38 -0700 (PDT) > > Zach Tellman wrote: > > Lines of code are a terrible metric for language complexity. If I > > write a function and abstract away half the code, have I made Clojure > > twice as simple? > > Ah, I'm sorry - I'm not looking at *language* complexity. I'm looking > at the complexity of the java/clojure *environment*. It seems to take > a lot non-clojure boilerplate to do *anything* in java-land than seems > reasonable to me. But I don't know javaland very well, which is why I > asked for other people's opinions. > > > If you want to really evaluate Clojure, write a non-trivial > > application and see whether the complexity is still manageable. Code > > golf doesn't tell you anything. > > Been there, done that. More than once. Well, maybe, depending on your > definition of "trivial".http://blog.mired.org/ > > Clojure great. No questions about that. WAR files, CLASSPATHs, having > to wrap *every little command* in it's own script - that's what I'm > looking at. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 2, 4:51 pm, Isaac Gouy wrote: > On Sep 1, 9:46 pm, John Fingerhut wrote: > > > Thanks to many people on this list in Aug 2009 who helped improve my code, > > to Johannes Friestad for writing a nice fast Clojure program using deftype > > for the n-body problem, to Isaac Gouy for setting up the shootout web site > > to accept Clojure submissions, and to my having more time than good sense to > > work on this, there are now Clojure programs for 5 of the 10 shootout web > > site benchmark problems. > > iirc Clojure won't show up on the summary pages until there are 7 > programs implemented. > > Nontheless I've put Clojure on the home page. > > > You can see a brief summary of results comparing > > run time, memory, and code size against "Java 6 -server" here: > > >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo... Clojure now shows up on the summary pages http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php?calc=chart&java=on&scala=on&sbcl=on&clojure=on&python3=on&jruby=on -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > Clojure great. No questions about that. WAR files, CLASSPATHs, having > to wrap *every little command* in it's own script - that's what I'm > looking at. I've already shown that you don't need WAR files. If you really, really hate the CLASSPATH you should look at cake. It does require ruby, but it let's you essentially write "instant-on" Clojure shell scripts as well as give you access to things like the working shell directory if that's the way you want to work with Clojure. #!/usr/bin/env cake run (println "Hello world!") Other people have felt your pain and have started building solutions. You can help them out by using those solutions and giving feedback :) David -- 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: Simple things should be simple
On Thu, 9 Sep 2010 09:06:49 -0700
Phil Hagelberg wrote:
> On Thu, Sep 9, 2010 at 8:38 AM, Mike Meyer
> wrote:
> > And two tools - lein and clojure itself.
> I'm not sure Clojure should be counted separately since you're not
> installing it yourself.
Installation isn't the issue, use is the issue. I have to run or
interact with clojure at some point. Since the same is true for any
implementation language, it could be dropped as well.
> > So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> > simple, but at least there's less boilerplate for the tools than there
> > is actual source code.
> Really I think your complaint boils down to not being able to modify
> the classpath at runtime. If the JVM had a real load-path like other
> lisps offer then this would be enough:
>
> (use 'ring.adapter.jetty 'ring.util.response)
> (run-jetty (constantly (response "hello world"))
>{:port 8080 :join? false})
>
> ...and we're back to three lines.
Yes, that would help. But I'm not sure that means I wouldn't have to
use lein at all? And it's more the "more lines of config than source"
than the lines of source that's an issue.
> Now I'm not defending the fact that the classpath is fixed at
> JVM-launch time--it's an awful hack that is an embarrassment to the
> awesome engineering prowess that has gone in to other parts of the
> JVM. But we do have tools to work around that flaw, and it's good to
> recognize the root of the problem rather than its symptoms.
Fair enough. But having to use those tools is what keeps simple things
from being simple.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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: Simple things should be simple
On Thu, 9 Sep 2010 09:03:38 -0700 (PDT) Zach Tellman wrote: > Lines of code are a terrible metric for language complexity. If I > write a function and abstract away half the code, have I made Clojure > twice as simple? Ah, I'm sorry - I'm not looking at *language* complexity. I'm looking at the complexity of the java/clojure *environment*. It seems to take a lot non-clojure boilerplate to do *anything* in java-land than seems reasonable to me. But I don't know javaland very well, which is why I asked for other people's opinions. > If you want to really evaluate Clojure, write a non-trivial > application and see whether the complexity is still manageable. Code > golf doesn't tell you anything. Been there, done that. More than once. Well, maybe, depending on your definition of "trivial". http://blog.mired.org/ Clojure great. No questions about that. WAR files, CLASSPATHs, having to wrap *every little command* in it's own script - that's what I'm looking at. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:30:51 -0400 >> Now it's true that there are some overhead to make sure your webapp produce >> a war file and can be deployed to ANY containers. It's not 3/1/0 as you >> claimed. > > A) I didn't claim I could do this with war files - those are a java > thing, and it's the java infrastructure that annoys me; I claimed (and > just posted the example) that I could do it with Unix tools. B) It's > 3/0/1, not 3/1/0. sorry, I should've been more clear, I meant to say that "creating war files isn't not 3/0/1 lines compared to your unix tools.". I poorly worded that. -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
On Thu, 9 Sep 2010 11:57:23 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 11:38 AM, Mike Meyer wrote: > > > Yup - the goal is simplicity. Robustness is important, but I expect > > the web server to take care of that. What I'm really expecting to lose > > here is performance. > performance? Yup: > And looking over your later post on using apache + cgi. 6, 4, 2 is for a > *very* high performance HelloWorld that can envolve sanely over time > (5000-7000 req second on a naive benchmark on a new-ish laptop). Can't say > that much about serving bash shell scripts over apache. Right. Delivering real performance isn't simple :-). The thing is, the same thing works for python, or perl, or any number of other things. Those you can switch to mod_ or an external CGI daemon running embedded or similar things to get performance. On the other hand, tossing a CGI shell script onto a heyu installation to read an outside thermometer is a perfectly reasonable thing to do. I don't expect even 10 requests a second for the temperature on my porch. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
You assume the presence of a configured web server but not a text editor ? The only constructive thing I can say is that the set of things that may be considered simple in the clojure setup above is vastly greater than the alternative you present. If the cost is a 4 line 'boilerplate' (and I'm pointedly not going to compare that to /etc/apache/conf.d) I think its a low price. On Thu, Sep 9, 2010 at 4:47 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > Edmund Jackson wrote: > > > Hi Mike, > > > > Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 8:38 AM, Mike Meyer
wrote:
> And two tools - lein and clojure itself.
I'm not sure Clojure should be counted separately since you're not
installing it yourself.
> So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> simple, but at least there's less boilerplate for the tools than there
> is actual source code.
Really I think your complaint boils down to not being able to modify
the classpath at runtime. If the JVM had a real load-path like other
lisps offer then this would be enough:
(use 'ring.adapter.jetty 'ring.util.response)
(run-jetty (constantly (response "hello world"))
{:port 8080 :join? false})
...and we're back to three lines.
Now I'm not defending the fact that the classpath is fixed at
JVM-launch time--it's an awful hack that is an embarrassment to the
awesome engineering prowess that has gone in to other parts of the
JVM. But we do have tools to work around that flaw, and it's good to
recognize the root of the problem rather than its symptoms.
-Phil
--
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: Simple things should be simple
On Thu, 9 Sep 2010 11:30:51 -0400 Wilson MacGyver wrote: > I'm not sure what your point is. If I want to write a hello world php > script on a unix > system, but apache and mod_php weren't setup. I'd first have to install them > and configure them. That simple things should be simple. Setting up a web server - and associated tools - to the point that you can install applications on it isn't necessarily simple, so I don't expect it to be simple. On the other hand, I only have to do that *once*, not once per application (at least, I hope I don't have to do it once per application!). > This is only easy these days because most linux come with apache installed, > php installed, mod_php preconfigured for you. Just one of the reasons there's nary a linux box to be found in my house. > You want something simple that requires no config, this can happen > during dev. Just write the hello world, and start the embedded jetty using > ring. David Nolan just described that. It's not bad at all. Given a shell script to launch it, it might even be usable for the projects I have in mind. It would have been a lot more impressive if leinigen hadn't made at least two incorrect assumptions about what I wanted to do in other operations that I'd have to fix. > If you really just want to serve hello world, you don't need to resort to > deploy a war file. you can just take that hello world script, start the > embeded > jetty and mod_proxy to it. That's hardly the "production way", but > then I don't know that writing a web app that prints 1 line is really > very production > either. But again, running a proxy just to wire up a simple web app takes you out of the realm of "simple". There are production web services that print a single line. Well, ok, these days they print a line or two of controls and 20 lines of advertising as well, but still wind up printing one value of interest: current temperature at some location, current stock price for some stock, current exchange rate for some currency, etc. I chose hello world because the question is more about how much overhead using even "simple" java infrastructure adds than about the application. > Now it's true that there are some overhead to make sure your webapp produce > a war file and can be deployed to ANY containers. It's not 3/1/0 as you > claimed. A) I didn't claim I could do this with war files - those are a java thing, and it's the java infrastructure that annoys me; I claimed (and just posted the example) that I could do it with Unix tools. B) It's 3/0/1, not 3/1/0. > But it's a pretty small part of the web app dev cycle in my experience. I > mean, > it's not like I spend 90% of my time writing config files and 10% of my time > writing clojure/groovy/java/(insert whatever jvm language) code, web dev or > otherwise. Of course not - you don't spend all your time doing simple projects. Nobody does. But simple projects taking 10 times as long as they should because of that still sucks. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
Lines of code are a terrible metric for language complexity. If I
write a function and abstract away half the code, have I made Clojure
twice as simple?
If you want to really evaluate Clojure, write a non-trivial
application and see whether the complexity is still manageable. Code
golf doesn't tell you anything.
Zach
On Sep 9, 8:38 am, Mike Meyer wrote:
> On Thu, 9 Sep 2010 10:59:28 -0400
>
> David Nolen wrote:
> > If you're going for simplicity over robustness and you have lein installed,
> > all you need to do is the following:
>
> > lein new nano-web
>
> Yup - the goal is simplicity. Robustness is important, but I expect
> the web server to take care of that. What I'm really expecting to lose
> here is performance.
>
> > Edit your project.clj
>
> > (defproject nano-web "1.0.0-SNAPSHOT"
> > :dependencies [[org.clojure/clojure "1.2.0"]
> > [org.clojure/clojure-contrib "1.2.0"]
> > [ring "0.2.5"]])
>
> > So far we have 4 lines to define our dependencies. Edit
> > src/core/nano_web.clj
>
> You mean src/nano_web/core.clj.
>
> > (ns nano-web.core
> > (use [ring.adapter.jetty :only [run-jetty]]
> > [ring.util.response :only [response]]))
>
> > (defn hello-world [req]
> > (response "Hello World!"))
>
> > (defonce server (run-jetty hello-world {:port 8080 :join? false}))
>
> > That's the 8 lines of actual code needed to have a full functioning web
> > application. Let's start it:
>
> The blank lines don't count, so it's six lines of code.
>
> > lein repl
> > user=> (load "nano_web/core")
>
> And two tools - lein and clojure itself.
>
> So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> simple, but at least there's less boilerplate for the tools than there
> is actual source code.
>
> Thanks for the answer.
>
> And, since I forgot, thanks to Meikel Brandmeyer for his earlier
> answer as well.
>
> --
> Mike Meyer http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
--
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: Simple things should be simple
On Thu, Sep 9, 2010 at 11:38 AM, Mike Meyer wrote: > Yup - the goal is simplicity. Robustness is important, but I expect > the web server to take care of that. What I'm really expecting to lose > here is performance. performance? > You mean src/nano_web/core.clj. > Good catch. > So we go from 3, 0, 1 to 6, 4, 2. And looking over your later post on using apache + cgi. 6, 4, 2 is for a *very* high performance HelloWorld that can envolve sanely over time (5000-7000 req second on a naive benchmark on a new-ish laptop). Can't say that much about serving bash shell scripts over apache. David -- 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: Simple things should be simple
How are you going to handle session? How are you going to handle database from a echo script? I mean, I can counter by just create a hello.html in apache and put "hello world" in there. It's 1 line, 0 to deploy. And it's FAST. It's even cached and uses no cpu time being served. that doesn't really mean that using web dev only using html is simple or is desirable. Having done web dev using cgi long ago, I don't think I want to go back to that. On Thu, Sep 9, 2010 at 11:47 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > Edmund Jackson wrote: > >> Hi Mike, >> >> Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > -- > 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 -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
On Thu, 9 Sep 2010 16:28:48 +0100 Edmund Jackson wrote: > Hi Mike, > > Could you perhaps present a counter-example of greater simplicity ? $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh #!/bin/sh echo 'Content-type: text/plain\n' echo Hello World ^D $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh Done. Three lines of source code. 0 lines of framework setup. 1 tool (sh). Pretty much the same thing works for python, perl, etc. It's about as robust as can be asked for - that's the nature of apache. Performance is going to be mediocre at best. That's the trade-off for simplicity. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Simple things should be simple
On Thu, 9 Sep 2010 10:59:28 -0400
David Nolen wrote:
> If you're going for simplicity over robustness and you have lein installed,
> all you need to do is the following:
>
> lein new nano-web
Yup - the goal is simplicity. Robustness is important, but I expect
the web server to take care of that. What I'm really expecting to lose
here is performance.
> Edit your project.clj
>
> (defproject nano-web "1.0.0-SNAPSHOT"
> :dependencies [[org.clojure/clojure "1.2.0"]
> [org.clojure/clojure-contrib "1.2.0"]
> [ring "0.2.5"]])
>
> So far we have 4 lines to define our dependencies. Edit
> src/core/nano_web.clj
You mean src/nano_web/core.clj.
> (ns nano-web.core
> (use [ring.adapter.jetty :only [run-jetty]]
>[ring.util.response :only [response]]))
>
> (defn hello-world [req]
> (response "Hello World!"))
>
> (defonce server (run-jetty hello-world {:port 8080 :join? false}))
>
> That's the 8 lines of actual code needed to have a full functioning web
> application. Let's start it:
The blank lines don't count, so it's six lines of code.
> lein repl
> user=> (load "nano_web/core")
And two tools - lein and clojure itself.
So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
simple, but at least there's less boilerplate for the tools than there
is actual source code.
Thanks for the answer.
And, since I forgot, thanks to Meikel Brandmeyer for his earlier
answer as well.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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: wrap-reload and sandbar session
Rob, Ring stores session data in an atom. Reloading re-defines the atom to be empty. Sandbar uses Ring's session store. I have made a small change to Ring in my branch which fixes this problem. See http://github.com/brentonashworth/ring/commit/ebcdb3ec8adfc5c82d5fd6031f444a105701a8e0. I don't see any problems with this change and will submit it as a patch on the Ring mailing list and see what the people over there think it. Maybe there is another way around this problem. So, the work-around would be to fork Ring. Make this change in your branch and then do lein jar && lein install. Then in your project remember to do lein clean && lein deps. This will get what you want working in development and is still compatible when you go to production. Brenton On Sep 8, 5:32 pm, Rob McBride wrote: > Hi, > > It seems that when using ring's wrap-reload to automatically load changes, > sandbar session seems to not work. Has anyone else noticed this? Is this a > possible bug? > > I've added ring's wrap-reload to session_demo.clj and the demo breaks. > > Any work arounds? I would love to be able to use wrap-reload, it is a > definite time saver. > > Thanks, > -Rob > > -- > Please avoid sending me Word or PowerPoint attachments. > Seehttp://www.gnu.org/philosophy/no-word-attachments.html -- 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: Knowing in advance the complexity of count
actually there is a function called counted? Sunil. On Thu, Sep 9, 2010 at 8:59 PM, Nicolas Oury wrote: > Thank you very much. > > Never looked closely at count definition. > > I assumed it was a forawrd to .count of Counted, which explains my problem. > > I kind of remembered the O(1) of Counted and get mixed up. > > Best regards, > > Nicolas. > > On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > > Hi, > > > > On 9 Sep., 16:45, Nicolas Oury wrote: > > > >> is it a way to do so? > > > > You can check the Counted marker interface for clojure collections. > > But this won't cover Strings etc. More information here: > > > http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L489 > > > > Sincerely > > Meikel > > > > -- > > 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 > > > > -- > Sent from an IBM Model M, 15 August 1989. > > -- > 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: Simple things should be simple
I'm not sure what your point is. If I want to write a hello world php script on a unix system, but apache and mod_php weren't setup. I'd first have to install them and configure them. This is only easy these days because most linux come with apache installed, php installed, mod_php preconfigured for you. You want something simple that requires no config, this can happen during dev. Just write the hello world, and start the embedded jetty using ring. If you really just want to serve hello world, you don't need to resort to deploy a war file. you can just take that hello world script, start the embeded jetty and mod_proxy to it. That's hardly the "production way", but then I don't know that writing a web app that prints 1 line is really very production either. Now it's true that there are some overhead to make sure your webapp produce a war file and can be deployed to ANY containers. It's not 3/1/0 as you claimed. But it's a pretty small part of the web app dev cycle in my experience. I mean, it's not like I spend 90% of my time writing config files and 10% of my time writing clojure/groovy/java/(insert whatever jvm language) code, web dev or otherwise. On Thu, Sep 9, 2010 at 11:03 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > >> Hi, >> >> I don't know what the full definition of "deploy" is, but here is an >> example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
I'm not sure what your point is. If I want to write a hello world php script on a unix system, but apache and mod_php weren't setup. I'd first have to install them and configure them. This is only easy these days because most linux come with apache installed, php installed, mod_php preconfigured for you. You want something simple that requires no config, this can happen during dev. Just write the hello world, and start the embedded jetty using ring. If you really just want to serve hello world, you don't need to resort to deploy a war file. you can just take that hello world script, start the embeded jetty and mod_proxy to it. That's hardly the "production way", but then I don't know that writing a web app that prints 1 line is really very production either. Now it's true that there are some overhead to make sure your webapp produce a war file and can be deployed to ANY containers. It's not 3/1/0 as you claimed. But it's a pretty small part of the web app dev cycle in my experience. I mean, it's not like I spend 90% of my time writing config files and 10% of my time writing clojure/groovy/java/(insert whatever jvm language) code, web dev or otherwise. On Thu, Sep 9, 2010 at 11:03 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > >> Hi, >> >> I don't know what the full definition of "deploy" is, but here is an >> example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
2010/9/9 Mike Meyer : > I've spent far more time evaluating clojure than I had expected > to. Part of the problem is that I'm of two minds. I love the language > - it seems to mix in just the right bits of LISP, data structures from > modern dynamic languages, and functional programming. > > On the other hand, I'm repelled by the java infrastructure around > it. Having been brought up on Unix systems and the software tools > approach (well, exposed to them relatively early, anyway), I'm a firm > believer that simple things should be simple, and complex things > should be possible. That's fundamental, but the Java world seems to > have forgotten it, and everything is targeted at building large > systems. If you want to do something simple, it seems you still have > to go through the dance required to do complex things. > > So, I'm asking for someone to show me I'm wrong. In particular, if I > wanted to deploy a simple web app (the classic "Hello World") on your > favorite java or clojure web framework, how many lines of text do I > have to deal with? Most importantly, how many of those are program > text, and how many are framework boilerplate(*)? Finally, how many > tools do I have to use to get it deployed(+)? > > For good Unix tools, the answers are 3, 0 and 1. Out of curiosity, can you explicit the numbers 3, 0 and 1, so that it'll be easier to see whether we're compared cats with cats ? -- 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: Knowing in advance the complexity of count
Thank you very much. Never looked closely at count definition. I assumed it was a forawrd to .count of Counted, which explains my problem. I kind of remembered the O(1) of Counted and get mixed up. Best regards, Nicolas. On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > Hi, > > On 9 Sep., 16:45, Nicolas Oury wrote: > >> is it a way to do so? > > You can check the Counted marker interface for clojure collections. > But this won't cover Strings etc. More information here: > http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L489 > > Sincerely > Meikel > > -- > 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 -- Sent from an IBM Model M, 15 August 1989. -- 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: Simple things should be simple
Hi Mike, Could you perhaps present a counter-example of greater simplicity ? Edmund On Thu, Sep 9, 2010 at 4:03 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > > > Hi, > > > > I don't know what the full definition of "deploy" is, but here is an > > example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. > >-- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > -- > 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
