Re: Enhanced Primitive Support
Richard Newman writes: > Having digested Rich's notes, pretty much the only thing that I > disagree with is the lack of automatic bignum promotion/demotion. It > seems like too much of a bad tradeoff, This nicely summarizes my thoughts. The other parts of Rich's notes seem very elegant, but I can see lack of promotion leading to problem in my own code. Some external input causing an intermediate result to overflow would certainly happen. Probably at the least convenient time possible. (Have we discarded the concept of a set of non-promoting math functions that are only used during optimization? prim-+ prim-/ etc.) Cheers, Chris Dean -- 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: Contrib Logging change
ataggart writes: > Which is why I added the arglist metadata (shown via doc): > [level fmt & args] [level throwable fmt & fmt-args] Ah, good call. I missed that. Cheers, Chris Dean -- 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: Contrib Logging change
Alex Taggart writes: > Ok here's what I threw together: http://gist.github.com/275527 > > It adds both println-style args as well as a formatting version. One downside of the new macros is that there is now one more check done at runtime for every use. There used to be just the impl-enabled? and now there is a instance? call as well. Also, I think format requires at least one arg, so (logf :debug) isn't valid. Probably should change the signature to (defmacro logf [level fmt-or-throwable & args] ...) Cheers, Chris Dean -- 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: Contrib Logging change
> I really like the clojure.contrib.logging library, but I find myself > often getting tricked into thinking it works like println: Nice idea. My $0.02: Checking the the type of the last arg seems too dwim to me, but it will certainly work. I've been thinking recently that info/warn/etc should be println or printf like and not take an exception, while log itself should be the only thing that does take an exception. That would break lots of code, so it's probably off the table. Instead, like others, I have my own macro. This one use printf semantics. For example: (flog :debug "Added %s [%s] to the write queue" (:query subject) (count msgs)) (defmacro flog [level fmt & args] "Logs a message, using clojure.contrib.logging/log after running the arguments though format. Should move this to logging.clj" `(log ~level (format ~@(cons fmt args Cheers, Chris Dean -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is it possible to implement break or return in Lisp?
CuppoJava writes: > I've always found it a little strange for exception-handling to be > treated as a special case in language design. It seems like it ought > able to be expressed in terms of some simpler elements (eg. a function Note sure exactly what you want, but you could try Lisp in Small Pieces by Christian Queinnec. If I remember right he talks about exceptions in terms of continuations. Or you could just start reading up on continuations if you're not familiar with them. Wikipedia has a call/cc page at http://en.wikipedia.org/wiki/Call-with-current-continuation Cheers, Chris Dean --~--~-~--~~~---~--~~ 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: Can (genclass) be changed to operate when not compiling?
Howard Lewis Ship writes: > It would be nice if (gen-class), when not in compile mode, would still > create a class in memory that could be referenced by class name > elsewhere in Clojure. +1 I would find this useful as well. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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: Emacs clojure mode: how to set current directory & classpath
> My biggest frustration is gettting the classpath & current directory
> set up correctly.
> I'm wondering what other people do to manage these issues.
What I do is run clojure under slime and have an external script that
creates the correct classspath and then launches clojure. The script
(called clojure) is hooked into slime using something like:
(setq slime-lisp-implementations
`((k-clj ("clojure" "--project" ,(expand-file-name "~/work/kineto")
"--no-rlwrap")
:init swank-clojure-init)
;; ...
(ccl ("/usr/local/bin/ccl"
The script makes many assumptions about what needs to be in the
classpath, but it works well for me. I don't expect the script to be
useful to anyone else, but you can look at it in
http://github.com/ctdean/clojure-launch/tree/master
It's written in Ruby and is Unix-centric.
Cheers,
Chris Dean
--~--~-~--~~~---~--~~
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: Emacs clojure-mode home?
> It looks like your patch might be incomplete; I get a void-variable: > clojure-mode-abbrev-table when I run that. So it is. Looks like I had the defs in my private startup file for some reason. Here's a corrected patch. Cheers, Chris Dean diff --git a/clojure-mode.el b/clojure-mode.el index b7b2de0..62d236a 100644 --- a/clojure-mode.el +++ b/clojure-mode.el @@ -163,6 +163,10 @@ All commands in `lisp-mode-shared-map' are inherited by this map.") (modify-syntax-entry ?^ "'" table) table)) +(defvar clojure-mode-abbrev-table nil + "Abbrev table used in clojure-mode buffers.") + +(define-abbrev-table 'clojure-mode-abbrev-table ()) (defvar clojure-prev-l/c-dir/file nil "Record last directory and file used in loading or compiling. @@ -192,6 +196,8 @@ if that value is non-nil." (lisp-mode-variables nil) (set-syntax-table clojure-mode-syntax-table) + (setq local-abbrev-table clojure-mode-abbrev-table) + (set (make-local-variable 'comment-start-skip) "\\(\\(^\\|[^\n]\\)\\(\\)*\\)\\(;+\\|#|\\) *") (set (make-local-variable 'lisp-indent-function) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Emacs clojure-mode home?
Where's the current home for the Emacs clojure-mode source? I have a one line patch I'd like to make, but don't know where to send it! Is it http://github.com/technomancy/clojure-mode/tree/master ? Anyway I'll include the patch to add a local-abbrev-table here since it is so small. Cheers, Chris Dean diff --git a/clojure-mode.el b/clojure-mode.el index b7b2de0..f9fa8ec 100644 --- a/clojure-mode.el +++ b/clojure-mode.el @@ -192,6 +192,8 @@ if that value is non-nil." (lisp-mode-variables nil) (set-syntax-table clojure-mode-syntax-table) + (setq local-abbrev-table clojure-mode-abbrev-table) + (set (make-local-variable 'comment-start-skip) "\\(\\(^\\|[^\n]\\)\\(\\)*\\)\\(;+\\|#|\\) *") (set (make-local-variable 'lisp-indent-function) --~--~-~--~~~---~--~~ 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: Code generation at runtime
Nicolas Oury writes: > So I need, to compile some expressions before I run the loop that keeps > evaluating these expressions. So there are a few solutions: Here are solutions I have used in the past on other Lisps for this sort of problem. They may (or may not) fit your situation: 1. Write the code out to an external file and load it. Not really much different that calling eval. Each file has a unique namespace that I use to keep the bookkeeping straight. 2. Create a parser that generates a series of closures. One can call this parser at run time to create a tree of functions and then call the function at the root of the tree to execute your code. Hmm, that wasn't a very clear explanation. SICP talks about this technique if you're interested. I prefer technique #2, but I've success with both. > (It's better to compile and run than to interpret, isn't it? Especially > in a tight loop executed millions of time.) BTW, Clojure doesn't have an interpreter - all the code is compiled. You could, of course write your own interpreter if that's what you mean. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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: multimethods
Konrad Hinsen writes: > But for many of Clojure's plain functions, it is not clear what their > dispatch function should be if they were to be converted to > multimethods. Indeed. It can be a non-trivial design exercise. But your clojure.contrib.generic code shows that one can make headway on the problem, especially for operators on collections which I would expect to have polymorphic behavior. > As for the performance issue, Clojure is different from most other > languages in that its built-in functions have no very special status: > they are just the values of some vars in the namespace clojure.core. > It is rather straightforward to define equivalent multimethods in > some other namespace and use those instead. Sure. It's easy to write one's own version of get et.al. What's hard to do is to get packages that you didn't write to use that version of get. You need everyone to use c.c.generic.collection or all the different libraries will have trouble interacting with each other. There is this same namespace problem in Common Lisp, if you're familiar with that package system. While it's possible to use the same names as are in the CL "core", almost no one does. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
multimethods
Recently, Chouser wrote: > Most clojure core functions are not multimethods -- partly because > they don't really need to be, and partly be cause they must be fast. I've wondered why this is for a while now. To put it another way, why have the dichotomy between multimethods and plain functions at all? CL is like this too (methods are not the same thing as plain functions), but that has a (partly) historical reason. If the issue is performance, then I understand that. But my vote as a user (not that anyone asked for my opinion!) is that I would rather have everything logically be a method and take a performance penalty. For me it's a consistency and simplicity over performance argument, although not everyone will agree. Cheers, Chris Dean --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Best way to augment core functions to support other data types?
Chouser writes: >> I suppose I could write a Java wrapper class that implements the proper >> interfaces. Either using plain old Java or the Clojure proxy/gen-class >> functions. > > That's probably the right way to go. If you've got your own object > (even if it's really just a Clojure hash-map with Tokyo Cabinet > handles in it), and you want to be able to use Clojure core functions > generally depend on specific Java interfaces that are defined in the > clojure.lang package, and wrapping a proxy around that is usually > pretty easy. That sounds fine to me, thanks! I'm going to stick to the interfaces in clojure.lang and hope that's kosher. (For example, clojure.lang.Counted) Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Best way to augment core functions to support other data types?
I'm using the embedded key/value database Tokyo Cabinet on a project. We have functions that use the database and some of the them are very similar to the core clojure functions that access a map. For example, the Tokyo Cabinet functions db-count, db-seq, and db-get correspond nicely to count, seq, and get. What's the best way to augment the function named count (.et.al.) to provide the same functionality as db-count ? It seems like I should be able to use multimethods, but don't see how that would work. I suppose I could write a Java wrapper class that implements the proper interfaces. Either using plain old Java or the Clojure proxy/gen-class functions. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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: (Potentially stupid) Question about recursion / trampoline
David Nolen writes: > The n has to be held onto to complete the computation, so the tail > call optimization cannot be performed. That's right. > ;; can be tail call optimized > (define (add-tail n) > (add-iter n 0)) > > (define (add-iter iter result) > (if (= iter 0) > result > (add-iter (- iter 1) (+ result 1 The equivalent Clojure code works with fine without blowing the stack. These sort of simple tail recursion calls work quite well in Clojure. (defn add-iter [iter result] (if (= iter 0) result (recur (- iter 1) (+ result 1 (defn add-tail [n] (add-iter n 0)) ;; Another way (defn add-loop [n] (loop [n n acc 0] (if (zero? n) acc (recur (dec n) (inc acc) I generally use loop where I would use a named let in Scheme. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 for Clojure-Mode users.
Does anyone know what the functional difference is between clojure-indent-function and common-lisp-indent-function ? Or even the cl-indent:function from slime ? I assume there is a difference, I just don't know what it is. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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: performance concerns (again)
> Simply stated, given that it stated clearly in this group that Clojure > runs, on average, slower than the JVM, is the JVM's high memory- > utilization a non-issue for the Clojure community as well? For my part, I'm relatively happy with the jvm's performance. I agree that the memory is usage is (in general) higher that I would like, but the performance of the system as a whole has been good. I don't know if this matters, but I have written large-ish systems on top of the JVM that performed well. A couple in plain-old-Java and another in a Scheme hosted on the JVM. Both used a lot of memory and we just took that into consideration when provisioning the machines. Finding a system with the best cpu-performance, memory use, libraries, community, etc is challenging and I for one am happy with the tradeoffs that Clojure has made. [1] Cheers, Chris Dean [1] Except for the lack of TCO. I hate that. Not Clojure's fault, but still irritating. --~--~-~--~~~---~--~~ 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: Launching apps
Adrian Cuthbertson writes: > For production server systems running under Linux, I've used apache > commons daemon to get java apps launched Thanks for the info. The problem (such as it is) with these solutions is that you still need to do something to attach to a repl. A repl is a requirement for us. For now I'm using hand written scripts that launch under screen. And that works for us. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Launching apps
How do folks launch their apps? For building (and maybe deploying) it seems that most people use the Java tools (ant, maven, ivy) or have a 10 line shell script. For pure Clojure code you don't even necessarily have to have a build step. But how do you launch your code in a production style setting? Historically, when using Common Lisp we would write a custom launch script for each app that started the app and ran a repl. We would run that whole thing inside screen or detachtty. We always deploy on Linux and we always have screen available. For some apps we also used to start them and use swank to get a repl, but we eventually stopped doing that in favor of the above solution. Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 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: HTTP clients in clojure
Eric Tschetter writes: > Last I checked the various clojure libraries, it seemed like noone has > publicized a set of wrappers/clojure-native implementation of an http > client. There is (slurp* url) and (reader url) in clojure.contrib.duck-streams (count (slurp* "http://google.com";)) => 4675 Cheers, Chris Dean --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
