Re: Easier way to run Clojure from command line?
Have you seen Leiningen? [1]. It seems like it will do what you want with lein repl, and additionally it has some nice features for acquiring dependencies and building a .jar from your project. [1] http://github.com/technomancy/leiningen#readme On May 7, 1:43 pm, Jason Smith ja...@lilypepper.com wrote: So the proscribed way to run Clojure from the command line is to type: java -cp clojure.jar clojure.main at the command prompt. How about adding *clojure.bat* to the distribution for us Windows people. A shell script for Unix would be nice too... @echo off cls java -cp %~dp0\clojure.jar clojure.main That way I don't have to know any Java, and I can just go straight to programming Clojure. Yeah, I might have to tweak the settings and add new jars (contrib, for example), but at least I have a shortcut. :-) And a place to make my Java-ish tweaks. -- 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 athttp://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: Monads in Clojure
On Nov 23, 1:15 pm, Konrad Hinsen [EMAIL PROTECTED] wrote: On 21.11.2008, at 20:10, Adam Jones wrote: The file contains the macro definitions, the definitions of three popular monads (maybe, list, state), and some illustrations of their use. Comments are welcome! Since they support mzero and mplus, aren't these equivalent to Haskell's MonadPlus? (i.e. they're a little more than *just* monads) You can define :plus and :zero if they are appropriate for a monad. If they are defined, you can use them. None of the predefined monad machinery will use them at the moment, but I plan to implement conditions, which work only if :zero is defined. In Haskell there are two different types of monads because of the type system, but the Clojure implementation doesn't use the type system at all, so :plus and :zero are simply used by convention. I've been kicking around the idea of re-implementing Haskell typeclasses on top of multimethods. Now that I think more about it, this probably wouldn't be much work. You need to find a way to store the type information with the data. That is easy if you limit yourself to a specific data structure, say a map with a key reserved for type information. But if you want to be able to use typeclasses for general Clojure data (e.g. make sequences an instance of Monad), I don't see a simple way to do it. That's the problem I've been thinking on. I'm looking for a decently sane way to build on the multimethod dispatch system here instead of explicitly relying on types. The concept probably doesn't work very well without a guaranteed unique method of identifying an object, like a data type. -Adam 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Eager map?
On Nov 17, 3:26 pm, Robert Ewald [EMAIL PROTECTED] wrote: Hello, Doing some small experiments I stumbled over map returning a lazy seq instead of performing the function. I had to convert that to a doseq. Is there any rationale for not having an eager map. Or was I just not reading the docs properly? Many of Clojure's functions that operate on seqs have this property. The idea is to capture the space efficiency of lazy list processing by default. If you really need strict evaluation, wrap the map with doall. I'm guessing that strict equivalents aren't provided to encourage the use of the lazy functions unless they absolutely aren't needed. -Adam -- Robert Ewald --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Daily Build
On Nov 17, 5:22 pm, Robert [EMAIL PROTECTED] wrote: Is there a server that tests every day if Clojure builds correctly? I pulled the latest a few days ago and couldn't get it to build (whereas the 2008-09-16 release does build for me). Having such a server would assist in determining if such problems are the user's fault (likely, in my case) or not (unlikely). So far as I've heard, no such server exists. Can you provide any more information about your problem? I'm not sure how the AOT compilation is progressing, but that has disrupted the (usually rock solid) stability of the trunk a bit. You may want to see how revision 1088 (svn co -r 1088 http://clojure.svn.sourceforge.net/svnroot/clojure/trunk) builds for you. It's the last revision before the AOT compilation project started. -Adam Robert --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: reader macros
On Nov 15, 4:52 pm, Jeff Rose [EMAIL PROTECTED] wrote: Hi, I'm finding comments talking about reader macros, but nothing about defining them. Does anyone know of an example for adding new read macros? I'd like to define a #! macro that passes over the rest of the line so we can use clojure scripts just as easily as a ruby script would be. If anyone knows another way to do this, that would be great too. According to [1], the read table is not accessible to user programs. You're trying to do shebang scripting right? You might find this [2] useful. [1] http://clojure.org/lisps [2] http://en.wikibooks.org/wiki/Clojure_Programming#Shebang_Scripting_in_Clojure -Adam Thanks, Jeff --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Weighted Edge Representation
On Oct 30, 11:01 am, Matthew D. Swank [EMAIL PROTECTED]
wrote:
On Oct 30, 8:57 am, Rich Hickey [EMAIL PROTECTED] wrote:
On Oct 29, 6:27 pm, ccahoon [EMAIL PROTECTED] wrote:
Hello,
I'm wondering what would be a good way to represent a mincut, maximum
flow problem in Clojure. A set of weighted edges makes sense to me,
but I am not sure how best to represent the edges so I can use them as
a key in a map. Pardon me for asking such a noob question on this
board. I am new to graph representations.
For example, if I have an edge (p, q) with weight 2, what is a good
way to represent that so I can access weights with the edges?
The graph libraries others have mentioned probably have a lot of nice
features, but I just wanted to say that [x y] vectors or {:x 1 :y 2}
maps make perfectly fine keys if you want to roll your own in Clojure.
Also, this simple TSP solver uses graphs:
http://groups.google.com/group/clojure/msg/df7b0f5673513b85
Rich
How are graphs with cycles represented in a purish functional
language? I guess explicit node indexing can be used instead of
references, but I would think that would get slow for large graphs.
Traversal ends up being a interpretation on node indices instead of a
simple dereference.
I have a paper [1] on my to read list that should answer just that
question. It implements a functional view of graphs for ML-family
languages, but it should be useful in Clojure as well. I'll probably
take a crack at implementing this when I have the time, but I have yet
to find time to even read the paper, so don't let my intentions stop
anyone.
-Adam
[1] http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#JFP01
Matt
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Oct 22, 6:17 am, Chouser [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 4:30 AM, Brett Morgan [EMAIL PROTECTED] wrote: I understand the lisp way is to use the reader plus macros to interpret the incoming data stream. This is hella cool in that it seriously cuts down on the amount of development work I have to do. The reader is already done, and using macros to build the tree walker? And have them applied to a stm core? Very lightweight in comparison to what I'd do traditionally. Very cool. I think that if you use read rather than load or eval on the incoming s-expressions, you'll have a lot less to worry about. Without the eval step there's no need to try to block arbitrary function calls and such, because they'll never be evaluated in the first place -- any symbols that match function call names will simply be returned from the reader as symbols. If you then want to call macroexpand on them to help process the expressions (I've got no sense of whether this would be a useful approach or not) then the only code being run would be your own macro. There'd be no way for the incoming s-expressions to define new macros or functions. Perhaps you'd still want to audit the LispReader.java code for security vulnerabilities and/or run the reader in some sort of Java sandbox, but I wouldn't be surprised if neither of these is actually necessary. --Chouser This is exactly the suggestion I was going to make. Dealing with untrusted code doesn't seem to be one of the main design considerations of Clojure. That I know of, there are no provisions to keep someone from re-defing existing functions, reaching out of their current namespace, or jumping into those aspects of Java land that are available. The safest way to handle data from the client is to keep it as data and write code to parse and react to it, anything else is setting up a creativity contest between yourself and anyone trying to break the application. If companies like Microsoft and Oracle can't win those with all of their money, a single individual doesn't stand a chance. -Adam --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
