Re: Clojure-in-CommonLisp?
Right, but what I have in mind is clojure-sitting-on-top-of-SBCL so that one can (with a suitable reimplementation thereof) use clojure's persistent data structures, protocols, deftype, etc... on top of a (somewhat more traditional?) native code-generating backend like SBCL's. There's a lot of machinery in there that solves problems that the JVM solves (in completely different ways, of course). One approach is the clojure-as-DSL such that this could work on any suitable CL system. An alternative approach would be to hack SBCL's compiler directly such that we're using the SBCL runtime and code generation bits more directly. This would be a lot of work, but might be interesting if the resulting product could have natively-compiled CL and clojure playing nicely with each other. Just a thought... Cyrus On Nov 15, 2011, at 9:09 AM, Nate Young wrote: There's also ABCL, the Common Lisp implementation that maintains the inalienable right to arm bears, written in Java and supporting interop between both Java and Lisp. http://common-lisp.net/project/armedbear/doc/abcl-user.html On 11/15/2011 09:13 AM, Dennis Crenshaw wrote: I haven't dealt with CL in quite a while, but there is this (which I was involved with in my undergrad at CofC): http://clforjava.org/ CLforJava may be helpful since it is, a totally new version of the Common Lisp language that runs on the Java Virtual Machine and is intertwined with the Java language in such a way that users of Lisp can directly access Java libraries and vice versa. Sounds familliar? :) Clojure - Java - CLforJava -- 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 -- 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-in-CommonLisp?
Tim, I've been wanting this for some time. Obviously the java interop stuff poses challenges, but the clojure data types, protocols, immutable objects, clojure syntax, etc... would make for a nice dialect of lisp to be used alongside other CL code. (I guess I'm in the small minority of folks that is much more interested in interacting with existing Common Lisp code than with existing Java libraries.) Cyrus On Nov 14, 2011, at 4:18 PM, daly wrote: It seems to me that a Clojure in Common Lisp might be the easiest non-JVM port. It would be a DSL within Common Lisp. A CL implementation would even allow rewriting the normal COND syntax. Is there an obvious reason why this would be a bad idea? Heck, it might even be possible to make the port literate :-) Tim Daly -- 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: shorter alternatives for `comp' and `partial'
I think the minimal character count for composition and partial functions in haskell are some of the reasons that haskell code is so impenetrable to non-haskell hackers. Feel free to rig up crazy unicode characters to any identifier you want in your own code, just don't ask me to read or debug any of it. On Nov 15, 2010, at 2:12 PM, Paul Hobbs wrote: Coming from Haskell, where composition and partial functions are cheap and free in terms of character count, it is actually pretty discouraging to have to spell it out in Clojure for the same effect. Some of the cases where you should be using multiple expressions in Clojure would be perfectly clear in Haskell as one expression... On Mon, Nov 15, 2010 at 11:37 AM, Sean Corfield seancorfi...@gmail.com wrote: On Mon, Nov 15, 2010 at 10:26 AM, Alan a...@malloys.org wrote: The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. Possibly because bang functions indicate Here be dragons in terms of mutating state? e.g., set! Are you really using complement a lot? I guess I would define an alias for the complement-ed function or use not in expressions... -- 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 -- 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
namespace aesthetics in chemiclj
I've been working on a library for representing molecules, atoms, chemical bonds, etc... called chemiclj ( http://github.com/slyrus/chemiclj ) and I've run into a design issue that has flummoxed me for a few weeks. I've written up a blog post that goes into more detail ( http://slyrus.github.com/2010/08/27/chemiclj-namespaces.html ) but the short version is that I'd like to be able to have an external interface, defined by things that live in defprotocols, I'd like to have a private-ish implementation of records that implement (is that the right term?) these protocols, and then I'd like to have some external helper/constructor functions for creating instances of these record types. It seemed like the clojure-y thing to do here would be to have a chemiclj.core package that defines the protocols, and to have chemiclj.atom and chemiclj.molecule for the details of atoms and molecules, respectively. But then how to get the make-atom function, for instance, defined in the chemiclj.core namespace _after_ the chemiclj.atom has been loaded? The approach I've come up with is to make a defn* macro that defines a function in the specified package: (defmacro defn* [fn-name rest] `(intern (if ~(namespace fn-name) (symbol ~(namespace fn-name)) (ns-name *ns*)) (symbol ~(name fn-name)) (fn ~(symbol (name fn-name)) ~...@rest))) and then in another ns, say chemiclj.molecule, one could do: (defn* chemiclj.core/molecular-formula [mol] (apply str (map #(str (:id (first %)) (second %)) (sort-by #(:id (first %)) (count-elements mol) which would cause molecular-formula to be defined in the chemiclj.core ns. This, along with some load forms from the core.clj lets things work as I expect/intend, but it's somewhat hacky/ugly. I was wondering if others have run into similar ordering issues brought about by protocols/records/nses and if anyone has any suggestions on what good clojure design aesthetics suggest here. Thanks, Cyrus -- 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
This still doesn't quite add up to me. What's the consequence of not alter-var-root'ing maker-var# if def-form is a defmacro? Why would def-form be a defmacro in the first place? Also, I don't think you've given the example of the actual call that gave the error, only the macroexpansion of it. Can you provide that as well? thanks, Cyrus On Sep 10, 2010, at 10:30 AM, joshua-choi wrote: I've solved the problem. I found that it only occurred when general- defmaker was called with its forms argument containing another general- defmaker call with def-form being defmacro. Thus, in the inner general- defmaker call, the *result* of (NamedRule. (delay …)) was embedded into a defmacro call, resulting in the error. The solution was to change (alter-var-root maker-var# named-rule-maker ~rule-type-kw) to (when (= '~def-form `defmacro) (alter-var-root maker-var# named-rule-maker ~rule-type-kw)) Thanks, everyone for your help. joshua-choi wrote: That ought to be correct, but I can't reconcile that with the error message. Doesn't the Can't embed object in code, maybe print-dup not defined error only appear in macros, when some object being spliced into a macro's expansion is not a basic Clojure form? Yet, you are correct, commenting out that function call in the macro does prevent the error. I don't understand it. Konrad Hinsen wrote: 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 -- 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/Scheme Style Guide
I guess much of this comes down to style. I find xml-http-request easier to read and consistent with the english language practice of using hyphens to join words in compound modifiers. But my point regarding XMLHttpRequest was regarding the seemingly arbitrary and difficult to remember (for me at least) uppercasing of the letters in XMLHttpRequest. That choice seems no more valid than XMLHTTPRequest or XmlHttpRequest, all of which I find much harder on the eyes, and more difficult to type, than xml-http-request. Cyrus On Sep 1, 2010, at 1:23 AM, Mark Engelberg wrote: On Tue, Aug 31, 2010 at 3:38 PM, Cyrus Harmon cyrushar...@gmail.com wrote: XMLHttpRequest vs. xml-http-request. I rest my case. I'm not even sure what case you're making, let alone what side you're resting for. :-/ -- 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: Lisp/Scheme Style Guide
XMLHttpRequest vs. xml-http-request. I rest my case. On Aug 31, 2010, at 3:35 PM, Mark Engelberg wrote: Speaking of style conventions, am I the only one who finds it mildly irksome that in any Clojure code, half the identifiers are lisp-style-multiword-names while the other half are javaCamlCaseMethodNames. It feels so inconsistent. I'd be happier if Clojure just moved completely to caml case (takes up less width). Thoughts? -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
I'm reminded gigamonkey's footnote about when functions get too big: A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head. [1] There are many different styles for source code, but my experience with lisp suggests that variable indentation (as provided by emacs lisp-mode or clojure-mode) and parens-not-on-their-own-line makes for much more readable code. core.clj is a good example where the code is generally readable, but I shudder to think what it would be like to read the code for doseq or destructure if each closing parenthesis were on its own line. And, as for writing code, I couldn't live without paredit. To each their own, but let's not go down the route of saying hey, you're code formatting style sucks, but I don't want to start a flame war :). Cyrus 1. http://www.gigamonkeys.com/book/practical-a-simple-database.html On Aug 18, 2010, at 6:24 PM, wwmorgan wrote: The Incanter example is confusing for the same reason that the Leiningen example from the blog post is confusing, and I don't think paren style matters at all. The functions have grown over time, they're now too big, and they need to be refactored into several smaller functions. The paren style is a red herring. core.clj is readable because its functions are short. When your code makes you want to outdent, you can take this as a signal that your function has gotten too big and needs to be refactored. - Will Morgan On Aug 18, 4:36 pm, Greg g...@kinostudios.com wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. Again, the link goes much more into depth on this. Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. - Greg Screen shot 2010-08-18 at 1.32.09 PM.png 48KViewDownload On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why
Re: Clojure 1.2 Beta 1
Going to http:// clojure.org, searching for git and following the Clojure goes git link would lead one to http://groups.google.com/group/clojure/msg/ca4fb58428052554 which suggests that the rickhickey page is the right one. Where's the announcement about git://github.com/clojure ? thanks, cyrus On Jul 15, 2010, at 10:02 AM, Jeffrey Schwab wrote: On 7/15/10 10:15 AM, Adrian Cuthbertson wrote: Apparently there's a problem with git clone http://... Should be git clone git://github.com/clojure/clojure.git Sorry for the noise. Thanks, I've been mistakenly working from git://github.com/richhickey/clojure.git ...which is apparently why I didn't see any commits since June. -- 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: Leiningen, Clojure and libraries: what am I missing?
I'm confused. Why do we need symlinks or copies at all? Why can't we just tell clojure where it's supposed to find a given projects dependencies? I'm sure the answer involves some mumbo-jumbo about classpath and what not, but surely there has to be a better alternative than whatever maven/leiningen are currently doing. Granted, I'm coming at this from a common lisp background, but I think many lisp developers are used to not just working on a single project, but working on a bunch of related projects simultaneously, including the the language/runtime environment itself. I'd like a single instance of clojure, a single clojure-contrib (I still don't understand why I had to (admittedly seamlessly) download a bunch of jars to clean the build directory), a single incanter instance, etc... Perhaps I'm missing the obvious here, but I continue to fail to understand why the clojure world is doing things this way. On a related note, why is the build system the cool kids seem to be using (leiningen) controlled by a bunch of shell scripts? Surely things like compiling .clj source files and making jars should be operations one can drive from the clojure repl, no? Oh, and on a related note, I hate being forced into the src, test, lib heirarchy... Let me put my files where I want them to go. Whatever happened to the lancet build system from Stuart Holloway's book? That seemed to make sense to me. thanks, Cyrus On Mar 11, 2010, at 1:32 PM, Phil Hagelberg wrote: On Wed, Mar 10, 2010 at 10:24 PM, Meikel Brandmeyer wrote: On Mar 11, 5:07 am, Brent Millare wrote: Since leiningen downloads everything to a local repo, can't we do away with copies and use symlinks if they are supported by the filesystem? I feel there should be an option for this. Why not adding the files from the repo directly to the classpath? Works everywhere and doesn't copy... Historically this has been because calculating the classpath couldn't be done in Clojure itself since it needed to be done before the JVM booted. Having to figure this kind of thing out in a shell script or in elisp is a headache if the rules are not simple. But now with the subclassloader approach that lein and mvn use it's less of an issue. But it would mean deprecating the pure-elisp swank launcher, and I don't know how it would affect other tools (IDEs, etc), so I'm still hesitant. I would be happy with a (simple-ish) patch to enable optionally switching to using symlinks or hard-links as this would be the lowest-impact fix, but I can't bring myself to care enough about the number of megabytes currently being wasted to code it myself; sorry. -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: Compilation-aware code?
hmm... perhaps one could have a form called something like ... oh, I dunno, maybe ... eval-when! And then one could have situations like :compile-toplevel and :load-toplevel and, maybe, :execute. Nah... that's a crazy idea; never mind... :) Cyrus On Jan 14, 2010, at 9:22 AM, ataggart wrote: Some people have had issues with c.c.logging in that it looks for a suitable logging implementation at macro-expansion-time (by simply trying to import the necessary classes), which thus also occurs during AOT compilation; the down-side is that if the desired logging lib is not on the classpath during compilation, the java.util.logging implementation gets selected into the compiled code. There are solutions to move this choice to runtime, though it adds some overhead to every invocation, even if the respective log level is disabled. It occurs to me it would be very nice indeed if I could provide alternate implementations depending on whether the clojure code was being executed as a .clj or an AOTC'd .class file. Knowing this would further allow the specification of env vars to influence the resulting code, e.g., telling c.c.logging that even though it's being AOTC'd, it can choose the logging impl right away since it's on the classpath (thus negating the performance hit of a runtime selection). Does anyone have a sense of whether or not this is possible already or, if not, worth doing? -- 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: Compilation-aware code?
I was referring to common lisp's eval-when special operator: http://www.lispworks.com/documentation/HyperSpec/Body/s_eval_w.htm cyrus On Jan 14, 2010, at 12:22 PM, ataggart wrote: I'm detecting sarcasm, but it's not clear to me what point you're trying to make. Care to be more helpful or enlightening? On Jan 14, 12:09 pm, Cyrus Harmon cyrushar...@gmail.com wrote: hmm... perhaps one could have a form called something like ... oh, I dunno, maybe ... eval-when! And then one could have situations like :compile-toplevel and :load-toplevel and, maybe, :execute. Nah... that's a crazy idea; never mind... :) Cyrus -- 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: SLIME/Swank problem with swank.util.sys/get-pid and RuntimeMXBean
I agree with Steven on this. As one who uses emacs and SLIME for both common lisp and clojure, I'd like to be able to use the current SLIME HEAD for clojure development work. I consider the fact that swank-clojure and the SLIME HEAD don't play nicely with each other to be a deficiency of swank-clojure. It may be that the right fix is to fix SLIME, but I see recommending a different mechanism of installing SLIME (via ELPA) as the fix to be an ugly hack. My personal hack-fix-of-choice is to check out version 3b3f604c396f0c5ceb8bc5a13fa41061bcc96184 from the slime git repo. It's true that this is fundamentally no better than what ELPA is doing, but at least I know what version of SLIME i need to make things work. It would be great if swank-clojure and/or slime were fixed so that the SLIME HEAD worked with swank-clojure. I don't want to have to use ELPA, or maven, or some other configuration management thing to get basic tools like an editing environment for the language up and running. Perhaps I should just bite the bullet and use the crazy configuration/package management things that the clojure community seems so enamored of (ELPA, maven, leiningen, etc...), but in the way I'm used to doing things, nothing more than the source code and a fairly simple system definition tool (like ASDF) are enough to get things done. It's not too say that there's room for improvement, but I like it when simple tools get the job done and I don't need to rely on a bunch of shell scripts, to have to modify classpaths, restart JVMs, etc... to get the code I want loaded. Perhaps I'm just ignorant of the proper clojure-y way to do things, so I'll hop off my soapbox now. cyrus On Jan 7, 2010, at 5:38 PM, Steven E. Harris wrote: Phil Hagelberg p...@hagelb.org writes: Could you try installing SLIME via ELPA as recommended in the swank-clojure readme? That will be a project I'll have to defer until the weekend, as I've never used ELPA. I use the CVS SLIME almost daily for Common Lisp work, so I'm reluctant to give it up. Also, it's not a tenable situation to fork SLIME for Clojure support. CVS head is known to have introduced incompatibilities with Clojure. Is the git repository at git://git.boinkor.net/slime.git just tracking the CVS repository, or is that the same as the ELPA-hosted one? I did try all of this with the git version and found the exact same behavior as with the CVS version. -- Steven E. Harris -- 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: SLIME REPL broken
Stefan put in words what I was thinking earlier today. For those of us that use both CL and clojure, keeping swank-clojure up to date wrt the slime HEAD is a good thing, if you ask me. It is, however, a two-way street and I would imagine that the swank-clojure implementors don't want to spend too much time chasing SLIME's tail, as it were. Keeping the clojure backend on the radar of the core SLIME development team is probably a good thing. I think it would be unfortunate if swank-clojure were to require a different SLIME emacs piece than the CL swank (and scheme48, etc...) backends. cyrus On Nov 16, 2009, at 2:15 PM, Stefan Kamphausen wrote: Hi, Phil Hagelberg wrote: Unless there are some really great features added upstream in slime, fixing swank-clojure to work with their latest changes is a low priority. this is a pity, at least for those of us, who also use Slime to do some CL hacking. For that setup it is quite common to always update to CVS head because that may be the only version working with current releases of, e.g., SBCL. Well, currently I don't really do CL stuff, it's just that I set up another machine doing lots of VC-checkouts... I could just copy an older version of Slime there. I'll take a look at it the next few days (er, evenings that is), if I find the time. No promises ;-) Over there at Slime's people are thinking, the Clojure family forked Slime, maybe that's not the worst idea. Things would probably get easier if there were only one backend to support. Best regards, Stefan -- 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: SLIME REPL broken
Heh: ;; Yeah, I'm lazy -- I'll flesh this out later Not sure if that's related to the problem, but it's amusing at least. Cyrus On Nov 15, 2009, at 6:21 AM, Stefan Kamphausen wrote: Hi, a short discussion on the SLIME mailinglist lead to the result that the arglist of a backend function in swank did change. Current checkouts of SLIME do not work with Clojure, at least if you use autodoc. http://common-lisp.net/pipermail/slime-devel/2009-November/016919.html I took a quick look at the relevant function (src/main/clojure/swank/ commands/contrib/swank_arglists.clj) in swank-clojure but it would need some diving into the code for me to help with this. Maybe someone more experienced than me can step in? Kind regards, Stefan Kamphausen -- 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
