Re: return value of use, requires?
On 2 February 2010 05:14, Raoul Duke wrote: > given keyword isn't one that is supported, > or no load target given Good point, I've updated the ticket patch to check options are valid also, so the behavior is now: user=> (use 'foo :foo :bar) java.lang.Exception: Unsupported option(s) supplied: :foo,:bar (NO_SOURCE_FILE:0) user=> (use :foo) java.lang.Exception: Unsupported option(s) supplied: :foo (NO_SOURCE_FILE:0) user=> (use) java.lang.Exception: Nothing specified to load (NO_SOURCE_FILE:0) http://www.assembla.com/spaces/clojure/tickets/253-Improve-errors-for--use---require--in-REPL Regards, Tim. -- 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: newbie question: splitting up source files
On 6 February 2010 00:52, Mike Jarmy wrote: > OK, here's a slightly more elaborate toy example that works. In this > example, foo-main.clj needs foo-a.clj, and they both need > foo-util.clj. I was expecting the (in-ns) call in foo-a to have a > ":load" keyword, just like (ns) in foo-main, but it doesn't, so I just > called (load) afterwards. > > Anyway, this will work for me. If there is a more idiomatic way to do > it, let me know. Well this works for me. Note the lack of (load "util") in foo-a.clj. Note also that "foo-util" is loaded before "foo-a" in the ns form: ; Directory structure: ; example/ ; example/foo-util.clj ; example/foo-a.clj ; example/foo.clj ; example/foo.clj (ns example.foo (:load "foo-util" "foo-a")) (defn main [] (println "hello from main") (aaa "FOO-MAIN") (util "FOO-MAIN")) (main) ; example/foo-a.clj (in-ns 'example.foo) (defn aaa [arg] (printf "hello from aaa: %s\n" arg) (util "FOO-A")) ; example/foo-util.clj (in-ns 'example.foo) (defn util [arg] (printf "hello from util: %s\n" arg)) $ java -cp /path/to/clojure.jar:. clojure.main example/foo.clj hello from main hello from aaa: FOO-MAIN hello from util: FOO-A hello from util: FOO-MAIN See also e.g. clojure.contrib.pprint which does something like the above. Whether or not this is the best way to split things up, I don't know. -- Michael Wood -- 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: newbie question: splitting up source files
P.S.: Instead of: (print (format "blah: %s\n" arg)) You could use: (printf "blah: %s\n" arg) or: (println "blah:" arg) If you want no space after the colon, you could use: (println (str "blah:" arg)) -- Michael Wood -- 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
Dutch Clojure users
Hello folks! I am from the Netherlands and I am learning Clojure now, using it at work, and loving it so far. Are there any more dutch Clojure programmers on this list so we can meet? I am also interested to know about Clojure-programmers from any country in a reasonable distance from Strasbourg. Joop Kiefte -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- 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: Dutch Clojure users
Hi, Am 06.02.2010 um 12:26 schrieb Joop Kiefte: > I am also interested to know about Clojure-programmers from any country in a > reasonable distance from Strasbourg. If you mean the Strasbourg in France: I live near Frankfurt am Main. It's a little more than 2h with the car. That could count as "reasonable distance". BTW: I'd like to remind everyone interested in the Clojure users map: http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=112691912540601337884.00045972a1deb8de0d96b 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: compiled namespaces referencing each other
OK, thanks guys On Sat, Feb 6, 2010 at 12:04 AM, ataggart wrote: > Circular references mean your namespace design is broken. > > -- > 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 for system administration
Phil Hagelberg wrote: On Thu, Feb 4, 2010 at 8:33 AM, Stuart Sierra wrote: Clojure can certainly do these things; clojure-contrib contains many file and io-related utilities. But remember that Clojure, like any Java program, takes more time to start up than "scripting" languages like Perl/Bash/Ruby/Python, so it may be less suitable for programs that you intend to run at the command-line. Also relevant is the fact that launching Clojure from the command-line is very inconvenient compared to scripting languages. If you want something simple you can just put on your path, you'll need to wrap it in a bash (or other language) script anyway to handle the classpath, etc. The combination of startup time and the need to roll your own bash script even for simple things has kept me from wanting to use Clojure as a perlish-replacement. http://martiansoftware.com/nailgun/ -- 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: Dutch Clojure users
Hello. I am unfamiliar with maps. How do I add myself to this map? - Tommy On Feb 6, 12:48 pm, Meikel Brandmeyer wrote: > Hi, > > Am 06.02.2010 um 12:26 schrieb Joop Kiefte: > > > I am also interested to know about Clojure-programmers from any country in > > a reasonable distance from Strasbourg. > > If you mean the Strasbourg in France: I live near Frankfurt am Main. It's a > little more than 2h with the car. That could count as "reasonable distance". > > BTW: I'd like to remind everyone interested in the Clojure users > map:http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=11269191254060133788... > > 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: Dutch Clojure users
On Feb 6, 2010, at 10:08 AM, Tommy wrote: > I am unfamiliar with maps. How do I add myself to this map? Figuring that out has taken me a long time on at least two occasions... The key is you need to be signed in to make changes. - At the upper right of the page is "sign in". Use that to sign in to your Google account. - A "Edit" button will appear at the top right of the left column. Press it. - There will be a few "tools" now at the upper let side of the map's display including the "add a placemark" tool. Use it to make your mark. - When you're done editing, click the "Save" and "Done" buttons near where the "Edit" button was. --Steve -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
On Feb 5, 1:47 pm, Peter Schuller wrote: > One problem is that there needs to be a convention for a clojure > "binary" that works consistently across platforms. My extremely biased opinion: Clojure is not a scripting language. The "binary" is java. System-wide classpaths are a bad idea. -SS -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
> My extremely biased opinion: Clojure is not a scripting language. One can spent a lot of time debating the definition of 'scripting language', but sure. The bigger issue though: > The "binary" is java. System-wide classpaths are a bad idea. In theory I agree with you. The concept of site-local (system wide) python paths, ruby library paths, and linker paths for C, are horribly and completely broken. (It is somewhat acceptable in the case of native libraries since they map to the underlying platform and performance optimizations such as read-only mmap:ing apply, and there is a system in place for versioning.) Unfortunately, because of the practical reality that the vast majority of the software that needs packaging for a platform are written in languages and using tools that make prohibitively problematic to try to coerce this set of arbitrary software into a world view where the system-wide stuff does not exist, all major packaging systems (debian packages, rpms AFAIK, freebsd ports, pkgsrc, etc) operate under the assumption that this is how you package software. What this means is that there tends to be a pre-existing infrastructure to handle packages that install files in some particular system-global location. Coercing a packaging system to handle a situation where the same software can be installed in multiple versions and appropriately selected by some particular version of some software that depends on other software, is problematic. I suspect that a key feature of clojure that has contributed to it's very promising level of popularity and use, is that it is comparatively easy to get going writing real software with it, and the fact that things that "should" be available, *are* available (in the form of Java libraries to some extent, but also largely due to being based on the JVM). I submit that adopting something similar to python's/ruby's system of loading code may be conducive to lowering the barrier of entry and increasing acceptance of Clojure as a platform to build on. As a developer, I have no problem with using leinigen for example (it's great!). But while an executable uberjar is extremely convenient, it does not tie into the packaging system of a platform (and there may be licensing issues with e.g. GPL libraries and re-distribution of uberjars). As a system administrator, you want to maintain some number of systems in some consistent fashion. This includes having a set of software that is supported, upgraded and maintained using a consistent tool set. Python and Ruby applications are well-behaved from this perspective. Clojure is not. This is why, even though Ruby has gems for example, there are still ports of specific ruby gems at specific versions in the FreeBSD ports tree - because that means they are suddenly integrated into the platform's packaging system. The fact that a random user can "gem install XXX" does not obviate the need for such integration. All forms of change management tend to be difficult, and software installation is a form of (particularly complicated) change management, assuming you need to keep stuff up-to-date. As a user, you want to use some piece of software without spending time figuring details out that should be left the programmer and the packagers for your platform. A project I started a few months ago, I wanted to write in Clojure. There were two major reasons why I ended up going with Python, and this is one of them (the other was POSIX Integration issues). I knew that I wanted something which the user could easily install and use using the tools that are integrated with his or her platform, without knowing anything about Java or Clojure or mucking about with things manually. Something which could just *be there* by default, as part of the regular experience of the operating system. In summary, I think one should not underestimate the importance of making sure users can just "aptitude install your-application" (substitute for whatever with freebsd//redhat/etc). Making it as easy as possible for applications writers to in turn make it as easy as possible for packagers to make that happen, is, I think, important. Having said that, this does not necessarily mean that one has to adopt the the Python/Ruby style of system-wide library paths. But I think it does mean that there needs to be some sensible way for an operating system's native packaging infrastructure to interface with the infrastructure of the language. And any random blackbox doesn't cut it; certain demands are imposed on the blackbox in order for it to play nice with the packaging infrastructure. At this time I haven't thought this through enough in the case of Clojure to offer a practical suggestion that does not involve system-wide library paths. -- / Peter Schuller -- 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
Re: Dutch Clojure users
It works fine, thank you :) On 6 Feb., 16:26, "Stephen C. Gilardi" wrote: > On Feb 6, 2010, at 10:08 AM, Tommy wrote: > > > I am unfamiliar with maps. How do I add myself to this map? > > Figuring that out has taken me a long time on at least two occasions... > > The key is you need to be signed in to make changes. > > - At the upper right of the page is "sign in". Use that to sign in to your > Google account. > > - A "Edit" button will appear at the top right of the left column. Press it. > > - There will be a few "tools" now at the upper let side of the map's > display including the "add a placemark" tool. Use it to make your mark. > > - When you're done editing, click the "Save" and "Done" buttons near where > the "Edit" button was. > > --Steve -- 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: Run expression, with particular functions replaced
On Feb 4, 8:11 pm, Bryce wrote: > I take your point; I've given up trying to actually define a function > with the expression for the moment (I'd imagine it's still possible, > just much trickier than I thought). My intention was to fake operator > overloading. For my purposes it should be enough to evaluate the > expression with substituted functions, which is very easy: > > (defmacro subFuncs [arg1 arg2] > (eval `(replace ~arg1 ~arg2)) > ) I'm not entirely sure I understand what your exact requirements are, but you can resolve most problems without resorting to eval. The easiest way to locally use a different function in place of a pre- existing one is to re-bind its symbol: user=> (+ 1 2) 3 user=> (let [+ (fn [x y] (+ x y 1))] (+ 1 2)) 4 If you need the "replacement" to work across function calls (i.e. dynamically scoped), you could use binding to re-bind the Var that stores the function: user=> (defn add [x y] (+ x y)) #'user/add (user=> (map add [1 2] [3 4]) (4 6) user=> (binding [add (fn [x y] (- x y))] (map add [1 2] [3 4])) (-2 -2) Note that I didn't use the + function directly here since the compiler would have inlined it, rendering the re-binding ineffective. The binding form is also restricted to the current thread, so beware when using things like pmap and future. Now, if your replacement requirements are really exotic and you absolutely want to write a macro, take a look at clojure.walk/prewalk- replace and postwalk-replace. -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
How about having a Clojure application 'package' set up a launcher script to launch the app with a minimal classpath, Leiningen style, based on some assumption regarding the whereabouts of versioned jars on the system? (E.g. jline-0.9.94.jar rather than jline.jar, say.) That seems to me to be preferrable by far to just dropping the whole of /usr/share/java & /usr/lib/java (for Ubuntu, or the equivalent for other platforms) on the classpath and then hoping that there are no incompatible versions of the same jars on the monster classpath this produces. Note that it will never do to have dependencies handled by a system which isn't capable of installing several versions of the same jar side-by-side... I don't know what apt / rpm / ports do about Java lib versioning, so maybe there's no problem here? Sincerely, Michał -- 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
> How about having a Clojure application 'package' set up a launcher > script to launch the app with a minimal classpath, Leiningen style, > based on some assumption regarding the whereabouts of versioned jars > on the system? (E.g. jline-0.9.94.jar rather than jline.jar, say.) Something along those lines was what I had in mind (rather than, as you say, just drop everything onto the CLASSPATH). It would not be something you want to fuss with necessarily during development, but some standard way of "building" your application in a packaging friendly manner. > Note that it will never do to have dependencies handled by a system > which isn't capable of installing several versions of the same jar > side-by-side... I don't know what apt / rpm / ports do about Java lib > versioning, so maybe there's no problem here? As far as I can tell, few Java things are packaged. I suspect because of this reason, in part. Things that are packaged tend to be those things that depend only on the JDK itself, or on very simple dependencies, or else major stuff like 'eclipse' which release engineering and huge dependency trees are not your concern. But as far as I have encountered, there is no magic solution to the multiple-versions-of-the-same-library problem that integrate with native OS packaging systems (that doesn't mean there are none). Maybe for Clojure it would indeed be more desirable to have some well-defined interface for packaging systems to use when dealing with clojure applications. It may not be entirely trivial though. For example with FreeBSD ports, the build step is expected to only depend on downloading certain well-defined and checksum controlled files from remote locations. You do not want something that arbitrarily downloads stuff during building. I'm pretty sure similar conventions exist for e.g. Debian. It's a difficult problem, and I'm not blaming Clojure. Especially since I think the Java/Clojure/Maven way of dealing with dependencies is vastly superior to the traditional way. But the practical issue remains that if I want to write some software that I want sysadmins in various situations to want to use effortlessly (in my case, a backup tool), problems like these do get in the way of choosing Clojure. Maybe uberjars are the pragmatic approach after all. But then what about GPL libraries and similar license hassles? Actually, how is this dealt with in the Maven community? -- / Peter Schuller -- 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: Dutch Clojure users
On Feb 6, 12:26 pm, Joop Kiefte wrote: > Hello folks! > > I am from the Netherlands and I am learning Clojure now, using it at work, > and loving it so far. Are there any more dutch Clojure programmers on this > list so we can meet? I am also interested to know about Clojure-programmers > from any country in a reasonable distance from Strasbourg. I'm in Brussels Raph > > Joop Kiefte > > -- > Communication is essential. So we need decent tools when communication is > lacking, when language capability is hard to acquire... > > -http://esperanto.net -http://esperanto-jongeren.nl > > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- 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: Dutch Clojure users
Hoi Joop, I live in NL. Cheers, Hubert. On Sat, Feb 6, 2010 at 12:26 PM, Joop Kiefte wrote: > Hello folks! > I am from the Netherlands and I am learning Clojure now, using it at work, > and loving it so far. Are there any more dutch Clojure programmers on this > list so we can meet? I am also interested to know about Clojure-programmers > from any country in a reasonable distance from Strasbourg. > Joop Kiefte > -- > Communication is essential. So we need decent tools when communication is > lacking, when language capability is hard to acquire... > > - http://esperanto.net - http://esperanto-jongeren.nl > > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > -- > 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: Applying arguments to Java methods.
On Feb 5, 9:44 pm, nchubrich wrote: > Is there ever any reason to use memfn as opposed to ordinary > functions, i.e. > > (def div (fn [x y] (.divide x y))) You should normally use the doted notation. I used it while experimenting with a macro that wrap Java classes, but it isn't the right way to that after all. So I really don't know of any use for 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
On Feb 6, 1:06 pm, Peter Schuller wrote: > But the practical issue > remains that if I want to write some software that I want sysadmins in > various situations to want to use effortlessly (in my case, a backup > tool), problems like these do get in the way of choosing Clojure. > > Maybe uberjars are the pragmatic approach after all. But then what > about GPL libraries and similar license hassles? I can't comment on the licensing problem, but could you expand on what exactly you don't like about packaging jars (as uberjars or separates) and distributing them as part of your application? If you distribute your app with precisely the jars you tested with, you don't have to worry about subtle incompatibilities sneaking in. Except for obviously bloated software (e.g., JBoss), Java jar files are relatively small. When you package for Debian, put the jars in /usr/share/my-awesome-app/ jars, put in a dependency on sun-java-1.x, and provide a wrapper shell script to start the whole thing (your classpath just includes the stuff you provided). For the installing admin, your package is just an "aptitude install my-awesome-app" away, and it just pulls down a JVM dependency. Simple, and fairly lightweight. I stopped using Python and Ruby and Perl partly because the packaging situation for all those languages is a horrible mess. For example, if you write a Ruby app, you are highly likely to run into trouble packaging it even for a recent distribution because your dependencies may not have been packaged or made available as rb-*.debs in the official repository. Or, rb-*.debs exist, but provide an incompatible version of the library you need. Ubuntu and Fedora may ship different versions of common gems, so you can't even code against an obvious lowest common denominator. (To make matters worse, "gem install", "easy_install", and "cpan -i" all create weird parallel universes of packages which may cause conflicts with system-provided packages. Python's virtualenv helps mitigate the problem to some extent.) C programs have it easier, because the overwhelming majority of commonly used libraries are packaged and available in recent distributions, and I have rarely had trouble with just writing against a slightly older version of a library. It's perfectly reasonable to dynamically link against libjpeg and make a note of a libjpeg dependency in the package descriptor file. In short, I think that the Java and Clojure way of packaging software make life much easier for programmers, package maintainers, and administrators, not harder. Making applications self-contained helps avoid dependency hell at packaging and deployment time, not to mention during development. It's a bit wasteful to have multiple copies of log4j or whatever floating around, but I'd rather waste a few gigabytes of disk space on duplicates than deal with system-wide classpaths. -- 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: Dutch Clojure users
There is a group of us hacking Clojure in Amsterdam and Utrecht. Where are you? Join the Amsterdam Clojurians Google group, and we'll meet for a pizza. -Jeff On Feb 6, 12:26 pm, Joop Kiefte wrote: > Hello folks! > > I am from the Netherlands and I am learning Clojure now, using it at work, > and loving it so far. Are there any more dutch Clojure programmers on this > list so we can meet? I am also interested to know about Clojure-programmers > from any country in a reasonable distance from Strasbourg. > > Joop Kiefte > > -- > Communication is essential. So we need decent tools when communication is > lacking, when language capability is hard to acquire... > > -http://esperanto.net -http://esperanto-jongeren.nl > > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- 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
question about dotimes
Hi! >>dotimes >>macro >>Usage: (dotimes bindings & body) This is from clojure api. But I don't know how to use dotimes with several bindings. I've tried to do it different ways, but I got error every time. So how to use dotimes with several bindings? -- 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: question about dotimes
In the doc for dotimes, the "bindings" are required as "name n" (see below). Hence (dotimes [i 5] ... ) is the only pattern. Check out (doseq and (for for what you're trying to do. user=> (doc dotimes) - clojure.core/dotimes ([bindings & body]) Macro bindings => name n Repeatedly executes body (presumably for side-effects) with name bound to integers from 0 through n-1. -Rgds, Adrian. On Sat, Feb 6, 2010 at 12:10 PM, Аркадий Рост wrote: > Hi! >>>dotimes >>>macro >>>Usage: (dotimes bindings & body) > This is from clojure api. > But I don't know how to use dotimes with several bindings. I've tried > to do it different ways, but I got error every time. > > So how to use dotimes with several bindings? > > -- > 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: Prepping clojure for packaging (was: Re: Clojure for system administration)
On Sat, 6 Feb 2010 18:25:47 -0800 (PST) Constantine Vetoshev wrote: > On Feb 6, 1:06 pm, Peter Schuller wrote: > > But the practical issue > > remains that if I want to write some software that I want sysadmins in > > various situations to want to use effortlessly (in my case, a backup > > tool), problems like these do get in the way of choosing Clojure. > > > > Maybe uberjars are the pragmatic approach after all. But then what > > about GPL libraries and similar license hassles? > > I can't comment on the licensing problem, but could you expand on what > exactly you don't like about packaging jars (as uberjars or separates) > and distributing them as part of your application? If you distribute > your app with precisely the jars you tested with, you don't have to > worry about subtle incompatibilities sneaking in. Except for obviously > bloated software (e.g., JBoss), Java jar files are relatively small. > When you package for Debian, put the jars in /usr/share/my-awesome-app/ > jars, put in a dependency on sun-java-1.x, and provide a wrapper shell > script to start the whole thing (your classpath just includes the > stuff you provided). For the installing admin, your package is just an > "aptitude install my-awesome-app" away, and it just pulls down a JVM > dependency. Simple, and fairly lightweight. It means that your software isn't playing well in the system. You install a duplicate copy of everything - or nearly everything - you require, basically creating a "weird parallel universe" just for your application. > I stopped using Python and Ruby and Perl partly because the packaging > situation for all those languages is a horrible mess. For example, if > you write a Ruby app, you are highly likely to run into trouble > packaging it even for a recent distribution because your dependencies > may not have been packaged or made available as rb-*.debs in the > official repository. Or, rb-*.debs exist, but provide an incompatible > version of the library you need. Ubuntu and Fedora may ship different > versions of common gems, so you can't even code against an obvious > lowest common denominator. (To make matters worse, "gem install", > "easy_install", and "cpan -i" all create weird parallel universes of > packages which may cause conflicts with system-provided packages. > Python's virtualenv helps mitigate the problem to some extent.) The first part isn't an issue with the python/ruby/perl packaging software, it's an issue with the OS packaging systems providing out-of-date or no versions of things you need. That's pretty much why I've punted on Linux as a development environment - I couldn't find a distribution that had up-to-date versions of the tools I wanted available. This second part also sounds like a problem with the OS packaging system, not python, ruby, cpan, etc. FreeBSD solves these problems by making the packaging system cpan/easy_install/etc. aware, so that when you install an OS package, it goes through those systems, and when you install something with those systems, the OS will notice them and let them satisfy the dependency on things that need it. I suspect that pkgsrc does the same, given how modular it is. > C programs have it easier, because the overwhelming majority of > commonly used libraries are packaged and available in recent > distributions, and I have rarely had trouble with just writing against > a slightly older version of a library. It's perfectly reasonable to > dynamically link against libjpeg and make a note of a libjpeg > dependency in the package descriptor file. You've had better luck than I've had. Creating a truly static binary using a modern GCC is nearly impossible, given that it wants to dynamically link part of it's support code. I inevitably find that critical shared libraries either aren't in the packaging system, or are so far out of date the author lists them as "DO NOT USE". I frequently find that even when the available tools are only a little bit out of date, critical bug fixes or features aren't available in that "slightly older library". Again, why I don't use Linux as a development platform. > In short, I think that the Java and Clojure way of packaging software > make life much easier for programmers, package maintainers, and > administrators, not harder. Making applications self-contained helps > avoid dependency hell at packaging and deployment time, not to mention > during development. It's a bit wasteful to have multiple copies of > log4j or whatever floating around, but I'd rather waste a few > gigabytes of disk space on duplicates than deal with system-wide > classpaths. I think of this as the "Windows" way of packaging, though calling it the "proprietary" way may be more accurate. That solution works for Python, Ruby, C - pretty much anything. You just bundle up every dependency you can get a license for, cram it all into the application directory, and distribute that along with a binary that arranges to use all those things. It's esse
