Re: Datatypes and protocols - update
On 01.12.2009, at 02:42, Rich Hickey wrote: > An updated version of the code for datatypes[1] and protocols[2] is > now available in the 'new' branch[3]. This weekend I finally got around to converting all my deftype-and- defprotocol-using code to the current Clojure new branch. It is now more compact and more readable, and the few parts where performance matters are faster. A big step forward! > Small changes include: > > - No more use of . in reify/deftype method names > - No more implicit this in reify/deftype That's the only feature that I regret a bit. It looks weird in a functional language to have functions (or something that is very similar) that have an implicit argument named outside its definition (in the :as option). Of course, one can think of it as similar to a closure over the object, but it still looks a bit weird to me. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is it possible to define ordering functions for own type?
On 07.12.2009, at 07:52, ataggart wrote: > The functions >, <, >=, <= are only for numbers (though there might be > a way to shadow them). You can use the compare function for anything > implementing the Comparable interface (which should be easier to do > when using deftype instead of defstruct). You can also use the equivalent multimethods in clojure.contrib.generic.comparison, which can be implemented for any type. 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
Multiple dispatch with Multimethods
Hello What is the idiomatic way to implement the classic collide-with function in Clojure? I would like to implement something similar to the following (pseudo code ahead): (defmulti collide-with foo) (defmethod collide-with ["asteroid" "spaceship"] (print "Boom")) (defmethod collide-with ["asteroid" any] (print " Wiiissh")) (defmethod collide-with [any "spaceship"] (print "Wooossh")) (defmethod collide-with [any any] (print "Dead Space")) The idea is to have a default function for a collision of asteroid with anything else, and of spaceship with anything else. What foo can I use? Thanks -- 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: Multiple dispatch with Multimethods
On Dec 7, 1:21 am, Tzach wrote:
> Hello
> What is the idiomatic way to implement the classic collide-with
> function in Clojure?
> I would like to implement something similar to the following (pseudo
> code ahead):
>
> (defmulti collide-with foo)
>
> (defmethod collide-with ["asteroid" "spaceship"] (print "Boom"))
> (defmethod collide-with ["asteroid" any] (print " Wiiissh"))
> (defmethod collide-with [any "spaceship"] (print "Wooossh"))
> (defmethod collide-with [any any] (print "Dead Space"))
>
> The idea is to have a default function for a collision of asteroid
> with anything else, and of spaceship with anything else.
> What foo can I use?
>
> Thanks
If order doesn't matter:
(defmulti collide-with
#(vec (filter #{"asteroid" "spaceship"} %&)))
(defmethod collide-with ["asteroid" "spaceship"] [x y] (print
"Boom"))
(defmethod collide-with ["asteroid"] [x y] (print " Wiiissh"))
(defmethod collide-with ["spaceship"] [x y] (print "Wooossh"))
(defmethod collide-with [] [x y] (print "Dead Space"))
--
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: Getting Started in Mac OS X Snow Leopard
Thanks everyone for the recommendations. 2009/12/4 Steve Purcell : > > Here's what I do (in Cocoa Emacs 23) to make 'option' work the same in Emacs > as in other OS X apps: > > (setq mac-command-modifier 'meta) > (setq mac-option-modifier 'none) > (setq default-input-method "MacOSX") Hmm, I've tried to avoid doing this since I'm used to Option being the Meta key (IIRC that's the default both in Cocoa Emacs and Aquamacs). I'm just surprised how no one seems to have a good answer for this. I've googled for it and trawled through Stack overflow and all the "solutions" are all hacks. The same issue comes up in Terminal where in the settings you can bind Option to meta (you can then use emacsy meta shortcuts like meta-f forward-word in the shell), but this will again result in # not being available. Maybe switching to a US keymap is the easiest way around this... It's just surprising to me that the hash key, which is used in so many programming languages, is broken by default on OS X in the UK. > (My full emacs config tree is here: http://github.com/purcell/emacs.d) I'll have a look. And thanks again to everyone who replied. > -Steve -- ! Lauri -- 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: Getting Started in Mac OS X Snow Leopard
I have a Macbooc Pro with Sweden keyboard so had a little different
issues here - by default not possible to type characters {[]} on
Carbon Emacs.
I solved it by adding the following to my .emacs file:
;; paredit-mode
(add-to-list 'load-path (expand-file-name "~/.emacs.d/paredit"))
(autoload 'paredit-mode "paredit"
"Minor mode for pseudo-structurally editing Lisp code."
t)
(autoload 'enable-paredit-mode "paredit")
(add-hook 'clojure-mode-hook'enable-paredit-mode)
(add-hook 'emacs-lisp-mode-hook 'enable-paredit-mode)
(when (eq system-type 'darwin)
(eval-after-load "paredit"
'(progn
(define-key paredit-mode-map (kbd "M-7")
'paredit-open-curly)
(define-key paredit-mode-map (kbd "M-8")
'paredit-open-square)
(define-key paredit-mode-map (kbd "M-9")
'paredit-close-square)
(define-key paredit-mode-map (kbd "M-0")
'paredit-close-curly
Maybe the following snippet solves your issue:
(global-set-key (kbd "M-3") (lambda (&optional n)
(interactive "p")
(insert-bracket 35 n)))
If you are using paredit mode and don't like this to be mapped
globally then this applies it only for buffers with paredit mode:
(define-key paredit-mode-map (kbd "M-3") (lambda (&optional n)
(interactive "p")
(insert-bracket 35 n)))
Lauri
On Mon, Dec 7, 2009 at 1:15 PM, Lauri Pesonen wrote:
> Thanks everyone for the recommendations.
>
> 2009/12/4 Steve Purcell :
>>
>> Here's what I do (in Cocoa Emacs 23) to make 'option' work the same in Emacs
>> as in other OS X apps:
>>
>> (setq mac-command-modifier 'meta)
>> (setq mac-option-modifier 'none)
>> (setq default-input-method "MacOSX")
>
> Hmm, I've tried to avoid doing this since I'm used to Option being the
> Meta key (IIRC that's the default both in Cocoa Emacs and Aquamacs).
>
> I'm just surprised how no one seems to have a good answer for this.
> I've googled for it and trawled through Stack overflow and all the
> "solutions" are all hacks. The same issue comes up in Terminal where
> in the settings you can bind Option to meta (you can then use emacsy
> meta shortcuts like meta-f forward-word in the shell), but this will
> again result in # not being available. Maybe switching to a US keymap
> is the easiest way around this... It's just surprising to me that the
> hash key, which is used in so many programming languages, is broken by
> default on OS X in the UK.
>
>> (My full emacs config tree is here: http://github.com/purcell/emacs.d)
>
> I'll have a look. And thanks again to everyone who replied.
>
>> -Steve
>
> --
> ! Lauri
>
> --
> 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
how is "leiningen new" intended to work?
I'm finding the behavior of leiningen new to be broken. It looks like the initial implementation isn't clear about what exactly the project name given as argument to lein new denotes. I'd like to fix this, but before i hack on a patch, I'd be curious to know how this subcommand was intended to work in the first place. It seems like lein new really needs thee pieces of information: (1) what directory should be created to contain the project? (2) what should the project's name (artifactId) be? (3) what should the project's group (groupId) be? It seems like it's trying to synthesize this out of a single piece of information:a string which can't decide if it's #1 or #2 and that's not working. Also, the otherwise empty .clj file created by lein new seems to have a mangled ns declaration. // ben Please feel free to skip the rant that follows if the above is sufficiently clear. The documentation of lein new leaves me guessing: smit...@wesley:~/w/VJS-88$ lein help new Create a new project skeleton. Thus I consult the source. The Implementation of "lein new PROJECTNAME" uses mkdirs to make the directories for PROJECTNAME, so it stands to reason that PROJECTNAME can be a path, not just a simple name. ;; leiningen/new.clj (defn new [project-name & [args]] (.mkdirs (file project-name)) ... Indeed, this appears to work, but doesn't since the clj file that's generated by default has a gibberish namespace: smit...@wesley:~/w/VJS-88$ lein new Foo/Bar Created new project: Foo/Bar smit...@wesley:~/w/VJS-88$ cat Foo/Bar/src/Foo/Bar.clj (ns Foo/Bar.core) So simple names it is: smit...@wesley:~/w/VJS-88$ lein new Foo Created new project: Foo/Bar smit...@wesley:~/w/VJS-88$ cat Foo/src/Foo.clj (ns Foo.core) But this still doesn't look right. Shouldn't the file be named Foo/src/Foo/core.clj if it's going to declare its namespace as Foo.core? How else will the classloader know where to find it? Ok, well, let's move on and build a jar. smit...@wesley:~/w/VJS-88/Foo$ lein jar [INFO] snapshot org.clojure:clojure:1.1.0-alpha-SNAPSHOT: checking for updates from internal [INFO] snapshot org.clojure:clojure-contrib:1.0-SNAPSHOT: checking for updates from internal [copy] Copying 2 files to /home/smithma/w/VJS-88/Foo/lib smit...@wesley:~/w/VJS-88/Foo$ ls classes leiningen.jar lib project.clj README src test Oh. That's odd, the JAR is named leiningen.jar, despite the fact that I've told lein that my project is named Foo. (Remember we've already established that the argument to lein isn't primarily answering the question "where do I put the project" (otherwise it would not break when given a path). Therefore, the primary meaning of the argument might logically be "what should the project be called.") But, clearly that's not it, because the project just get's called "leiningen", no matter what I ask for on the command line. Now, to cut a long story short, it took me a while to figure out that I could use a name-space qualified symbol as the project name a-la: my.group.id/artifactId to get both a sane file jar file name out of "lein jar" and a sane install location from "lein install". Is this documented somewhere? I gleaned it from the source. (of course we can't do that from the command line because we've established that slashes in that context == 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
Re: Getting Started in Mac OS X Snow Leopard
Sorry, pressed send button too fast - here is correct elisp code:
(global-set-key (kbd "M-3") (lambda (&optional n)
(interactive "p")
(let ((last-command-event 35))
(self-insert-command n
On Mon, Dec 7, 2009 at 4:02 PM, Lauri Oherd wrote:
> I have a Macbooc Pro with Sweden keyboard so had a little different
> issues here - by default not possible to type characters {[]} on
> Carbon Emacs.
> I solved it by adding the following to my .emacs file:
>
> ;; paredit-mode
> (add-to-list 'load-path (expand-file-name "~/.emacs.d/paredit"))
>
> (autoload 'paredit-mode "paredit"
> "Minor mode for pseudo-structurally editing Lisp code."
> t)
> (autoload 'enable-paredit-mode "paredit")
> (add-hook 'clojure-mode-hook 'enable-paredit-mode)
> (add-hook 'emacs-lisp-mode-hook 'enable-paredit-mode)
>
> (when (eq system-type 'darwin)
> (eval-after-load "paredit"
> '(progn
> (define-key paredit-mode-map (kbd "M-7")
> 'paredit-open-curly)
> (define-key paredit-mode-map (kbd "M-8")
> 'paredit-open-square)
> (define-key paredit-mode-map (kbd "M-9")
> 'paredit-close-square)
> (define-key paredit-mode-map (kbd "M-0")
> 'paredit-close-curly
>
> Maybe the following snippet solves your issue:
>
> (global-set-key (kbd "M-3") (lambda (&optional n)
> (interactive "p")
> (insert-bracket 35 n)))
>
> If you are using paredit mode and don't like this to be mapped
> globally then this applies it only for buffers with paredit mode:
> (define-key paredit-mode-map (kbd "M-3") (lambda (&optional n)
> (interactive "p")
> (insert-bracket 35 n)))
>
> Lauri
>
> On Mon, Dec 7, 2009 at 1:15 PM, Lauri Pesonen wrote:
>> Thanks everyone for the recommendations.
>>
>> 2009/12/4 Steve Purcell :
>>>
>>> Here's what I do (in Cocoa Emacs 23) to make 'option' work the same in
>>> Emacs as in other OS X apps:
>>>
>>> (setq mac-command-modifier 'meta)
>>> (setq mac-option-modifier 'none)
>>> (setq default-input-method "MacOSX")
>>
>> Hmm, I've tried to avoid doing this since I'm used to Option being the
>> Meta key (IIRC that's the default both in Cocoa Emacs and Aquamacs).
>>
>> I'm just surprised how no one seems to have a good answer for this.
>> I've googled for it and trawled through Stack overflow and all the
>> "solutions" are all hacks. The same issue comes up in Terminal where
>> in the settings you can bind Option to meta (you can then use emacsy
>> meta shortcuts like meta-f forward-word in the shell), but this will
>> again result in # not being available. Maybe switching to a US keymap
>> is the easiest way around this... It's just surprising to me that the
>> hash key, which is used in so many programming languages, is broken by
>> default on OS X in the UK.
>>
>>> (My full emacs config tree is here: http://github.com/purcell/emacs.d)
>>
>> I'll have a look. And thanks again to everyone who replied.
>>
>>> -Steve
>>
>> --
>> ! Lauri
>>
>> --
>> 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: Datatypes and protocols - update
On Mon, Dec 7, 2009 at 3:11 AM, Konrad Hinsen wrote: > On 01.12.2009, at 02:42, Rich Hickey wrote: > >> An updated version of the code for datatypes[1] and protocols[2] is >> now available in the 'new' branch[3]. > > This weekend I finally got around to converting all my deftype-and- > defprotocol-using code to the current Clojure new branch. It is now > more compact and more readable, and the few parts where performance > matters are faster. A big step forward! > >> Small changes include: >> >> - No more use of . in reify/deftype method names >> - No more implicit this in reify/deftype > > That's the only feature that I regret a bit. It looks weird in a > functional language to have functions (or something that is very > similar) that have an implicit argument named outside its definition > (in the :as option). Of course, one can think of it as similar to a > closure over the object, but it still looks a bit weird to me. > Yes, methods are not really functions. Thinking about them as closures over the object is a good way to go - you can see that analogy in play when you consider recur, which works with these methods, but could not rebind 'this'. The recur case sealed the deal in the decision not to include 'this' in the argument lists. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is str supposed to be able to output lazy strings?
clojure-contrib also has a str-join function, which could be helpful for joining SQL conditions: (use '[clojure.contrib.str-utils :only (str-join)]) (str-join " AND " (map identity [1 2 3])) Jim On Sun, Dec 6, 2009 at 11:03 AM, samppi wrote: > Also, you should also consider simply using the seq function, which is > what you should use when you want just to evaluate a lazy sequence: > > (str (seq (map identity [1 2 3]))) > "(1 2 3)" > > On Dec 6, 11:20 am, CuppoJava wrote: >> This is expected behavior. >> >> eg. (str (map identity [1 2 3])) >> returns "clojure.lang.lazy...@7861" >> >> The way to think about it is, (str) asks for the string representation >> of an object. The string representation of a lazy sequence in this >> case is "clojure.lang.lazy...@7861". >> >> If you want the string representations of what's inside the lazy seq, >> you can use the apply function. >> >> (apply str (map identity [1 2 3])) >> "123" >> >> Alternatively, you can convert the lazy-seq to a vector. The string >> representation for a vector shows the elements inside of it. >> >> (str (vec (map identity [1 2 3]))) >> "[1 2 3]" >> >> Hope that makes sense. >> -Patrick > > -- > 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: How to use/refer to multiple Clojure classes
> It does not look like wildcarding is supported in the ns macro and it > seems silly to explicitly nominate each class that I want to have at > my disposal. Am I thinking about this all wrong? As far as i know you have to add each of them... -- 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 development environments
That is a useful hint. Thanks - I'll check that out. On Dec 6, 6:07 am, Phil Hagelberg wrote: > "balln...@googlemail.com" writes: > > Emacs /clojure-mode: > > You need to install git to pull down the latest sources! > > You needClojureandClojure-contrib (usually you cannot dowload > > contrib but have to build it) > > You need to have ant / maven to build contrib > > You need to download Emacs > > You need to downloadclojure-mode > > You need to modify .el startup files for Emacs > > and then - how do I get to the REPL? how does this all work? Is there > > This isn't true anymore. All that's needed is to use the Emacs Lisp > package manager (http://tromey.com/elpa) to grab swank-clojure, and it > will download all the dependent elisp and precompiled jars. Currently > that's 2 manual steps, but in Emacs 24 ELPA will be included, so you > will be able to skip that step. > > You were probably working from an older tutorial if you thought you had > to go through all those steps. It's become much simpler now, though > unfortunately the old misleading docs are still out there--not a lot I > can do about that. > > -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Multiple dispatch with Multimethods
Hi, On Dec 7, 10:21 am, Tzach wrote: > (defmulti collide-with foo) > > (defmethod collide-with ["asteroid" "spaceship"] (print "Boom")) > (defmethod collide-with ["asteroid" any] (print " Wiiissh")) > (defmethod collide-with [any "spaceship"] (print "Wooossh")) > (defmethod collide-with [any any] (print "Dead Space")) > > The idea is to have a default function for a collision of asteroid > with anything else, and of spaceship with anything else. > What foo can I use? Eg. a custom hierarchy. Since there is no bottom type, you have to create it manually. Deriving Object from ::Any takes care of the Java land. For clojure land you have to derive each type from ::Any (or anything already deriving from ::Any). (def space-hierarchy (-> (make-hierarchy) (derive Object ::Any) (derive ::Spaceship ::Any) (derive ::Asteroid ::Any))) (defmulti collide-with #(vec (map type %&)) :hierarchy #'space-hierarchy) (defmethod collide-with :default [_ _] (print "Dead Space")) (defmethod collide-with [::Asteroid ::Any] [_ _] (print "Wiiissh")) (defmethod collide-with [::Any ::Spaceship] [_ _] (print "Wooosssh")) (defmethod collide-with [::Asteroid ::Spaceship] [_ _] (println "Booom!")) Maybe you have to disambiguate with prefer-method in certain cases. (I don't think, that's the case here, but I haven't tested it...) Hope this helps. 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: Getting Started in Mac OS X Snow Leopard
On 7 Dec 2009, at 11:15, Lauri Pesonen wrote: > 2009/12/4 Steve Purcell : >> >> Here's what I do (in Cocoa Emacs 23) to make 'option' work the same in Emacs >> as in other OS X apps: >> >> (setq mac-command-modifier 'meta) >> (setq mac-option-modifier 'none) >> (setq default-input-method "MacOSX") > > Hmm, I've tried to avoid doing this since I'm used to Option being the > Meta key (IIRC that's the default both in Cocoa Emacs and Aquamacs). > > I'm just surprised how no one seems to have a good answer for this. > I've googled for it and trawled through Stack overflow and all the > "solutions" are all hacks. The same issue comes up in Terminal where > in the settings you can bind Option to meta (you can then use emacsy > meta shortcuts like meta-f forward-word in the shell), but this will > again result in # not being available. Maybe switching to a US keymap > is the easiest way around this... It's just surprising to me that the > hash key, which is used in so many programming languages, is broken by > default on OS X in the UK. That's why I always either buy US keyboards for programming, or (better) use a UK keyboard with a US keymap selected in OS X. Why better? Well, you get one extra key, and the ` and ~ chars end up in a better position, next to the left shift key. But you still end up needing Option to get "£" etc. in regular Cocoa applications, and since the OS X deadkey scheme is really nice, I value being able to use that scheme in Emacs above any preferences for Emacs' Meta key. Running Emacs in Terminal is a mess, then, as you say. -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
Leiningen in Python
Hi, I've write some python script for leiningen for Windows machines without wget/curl. I expect it is nicer than as-is bourne-shell-script version of 'lein'. here is my little script: http://github.com/ageldama/configs/blob/master/lein/lein.py Thanks. -- 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 in Python
That's great. Roland Sadowski has also written a Windows-friendly lein script in PowerShell: http://gist.github.com/239210 On Dec 7, 8:15 am, "Jonghyouk, Yun" wrote: > Hi, > > I've write some python script for leiningen for Windows machines > without wget/curl. > > I expect it is nicer than as-is bourne-shell-script version of 'lein'. > > here is my little > script:http://github.com/ageldama/configs/blob/master/lein/lein.py > > Thanks. -- 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: Datatypes and protocols - update
On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey wrote: > Yes, methods are not really functions. Thinking about them as closures > over the object is a good way to go - you can see that analogy in play > when you consider recur, which works with these methods, but could not > rebind 'this'. The recur case sealed the deal in the decision not to > include 'this' in the argument lists. I had a quick play with protocols, and the biggest problem I had getting started was realising that the signature of a method definition in defprotocol was different to the signature required to implement the same method in deftype. FWIW, I found it very non-intuitive. -- Hugo Duncan -- 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: Datatypes and protocols - update
2009/12/7 Hugo Duncan > On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey > wrote: > > > Yes, methods are not really functions. Thinking about them as closures > > over the object is a good way to go - you can see that analogy in play > > when you consider recur, which works with these methods, but could not > > rebind 'this'. The recur case sealed the deal in the decision not to > > include 'this' in the argument lists. > > I had a quick play with protocols, and the biggest problem I had getting > started was realising that the signature of a method definition in > defprotocol was different to the signature required to implement the same > method in deftype. FWIW, I found it very non-intuitive. > > Hello, And now that you've got it, do you still feel this non-intuitive. Because I had the same feeling first: I thought I would never rembember how things work and why put 'this-like args there, and not there ... But now that everything "clicked in place", I feel the last status of what Rich achieved to do the most natural and intuitive. Basically, what helped me was along the lines of what Konrad said : * defprotocol and extend are "purely functional" : so you have to specify every argument, including the object the functions acts upon. * deftype with embedded protocol definition for the type, or reify, in the contrary, do not define pure functions. They define methods. You cannot get them as values and pass them around like higher-order functions, for example. And you must know this fact, it cannot be an implementation detail. So, since you know this fact, you remember that you're in a method definition (in the general sense of object oriented languages : method of a class) and, as you do with e.g. java, C#, ... , when definining methods, you do not add the target of the method as an implicit argument. The big advantage I see to this is that once you get it, you don't have anymore to remember where 'this is explicit and where it's implicit: it's intuitive. The other big advantage is that the use of recur inside these functions/methods bodies continue to match exactly the signature of the function/method (otherwise you would have had to remember that, e.g. in methods defined via deftype, you must place an explicit "this" argument in the method arg list, but not place it in the recur calls ... :-( ) HTH, -- laurent -- 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: The new deftype and multimethod dispatching
2009/12/6 Bob Hutchison > > On 6-Dec-09, at 3:46 PM, Meikel Brandmeyer wrote: > > > Hi, > > > > Am 06.12.2009 um 21:29 schrieb Bob Hutchison: > > > >> It turns out that dispatching on play.foo.Foo is the only way that > >> works. I was hoping ::f/Foo or f/Foo would work too (maybe my alias > >> is > >> wrong??). Especially since, with aliasing in the user namespace, I > >> can > >> create a play.foo.Foo using f/Foo > > > > Does the following work? > > > > (ns play.foo) > > (deftype Foo []) > > (defmulti my-print type) > > (defmethod my-print ::Foo [x] (println "Got a foo")) > > > > (in-ns 'user) > > ; Note: normally written as (require [play.foo :as f]) > > (alias 'f 'play.foo) > > (def x (f/Foo)) > > (f/my-print x) > > > Yes! Thanks! The dispatch on type rather than class is the trick. I > actually ended up writing a macro, this is *much* better. > Please note that in clojure, it's the dispatch on the class that's the "trick", not on the type ;-) > > Cheers, > Bob > > > > > Sincerely > > Meikel > > > > > Bob Hutchison > Recursive Design Inc. > http://www.recursive.ca/ > weblog: http://www.recursive.ca/hutch > > > > -- > 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: How to use/refer to multiple Clojure classes
On Nov 30, 9:21 am, Dan Kefford wrote: > OK... I'm trying to take Clojure for a spin on Project Euler problems. > I have source files for each problem that I have solved and although I > can refer to and invoke any one of them explicitly from a main class, > I cannot seem to figure out how to refer to them all at once so that I > can choose to run any one of them at runtime. Here is some code: > > main.clj > > (ns com.dankefford.projecteuler.main > (:gen-class) > (:use [com.dankefford.projecteuler.problems.1]) > ) > > (defn -main [] > (run) > ) > > 1.clj > - > (ns com.dankefford.projecteuler.problems.1 > (:gen-class) > (:use [com.dankefford.projecteuler.util arithmetic]) > ) > > (defn run [] > (print "The sum of all the multiples of 3 or 5 below 1000 is: ") > (println (reduce + (filter #(or (divides? % 3) (divides? % 5)) > (range 1 1000 > ) > > It does not look like wildcarding is supported in the ns macro and it > seems silly to explicitly nominate each class that I want to have at > my disposal. Am I thinking about this all wrong? I would suggest you start by not thinking of namespaces as classes (unless you're doing java interop stuff)/ -- 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: Datatypes and protocols - update
On Dec 7, 9:07 am, Laurent PETIT wrote: > 2009/12/7 Hugo Duncan > > > On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey > > wrote: > > > > Yes, methods are not really functions. Thinking about them as closures > > > over the object is a good way to go - you can see that analogy in play > > > when you consider recur, which works with these methods, but could not > > > rebind 'this'. The recur case sealed the deal in the decision not to > > > include 'this' in the argument lists. > > > I had a quick play with protocols, and the biggest problem I had getting > > started was realising that the signature of a method definition in > > defprotocol was different to the signature required to implement the same > > method in deftype. FWIW, I found it very non-intuitive. > > Hello, > > And now that you've got it, do you still feel this non-intuitive. > Because I had the same feeling first: I thought I would never rembember how > things work and why put 'this-like args there, and not there ... > But now that everything "clicked in place", I feel the last status of what > Rich achieved to do the most natural and intuitive. > > Basically, what helped me was along the lines of what Konrad said : > * defprotocol and extend are "purely functional" : so you have to specify > every argument, including the object the functions acts upon. > * deftype with embedded protocol definition for the type, or reify, in the > contrary, do not define pure functions. They define methods. You cannot get > them as values and pass them around like higher-order functions, for > example. And you must know this fact, it cannot be an implementation detail. > So, since you know this fact, you remember that you're in a method > definition (in the general sense of object oriented languages : method of a > class) and, as you do with e.g. java, C#, ... , when definining methods, you > do not add the target of the method as an implicit argument. > > The big advantage I see to this is that once you get it, you don't have > anymore to remember where 'this is explicit and where it's implicit: it's > intuitive. > The other big advantage is that the use of recur inside these > functions/methods bodies continue to match exactly the signature of the > function/method (otherwise you would have had to remember that, e.g. in > methods defined via deftype, you must place an explicit "this" argument in > the method arg list, but not place it in the recur calls ... :-( ) > > HTH, > > -- > laurent That was my experience as well. It started off as a gotcha (since I was copy/pasting the protocol definitions over to the deftype), but then after playing for a bit it wasn't a big deal. In all my usages so far I haven't needed to reference 'this'. The one area I am running into issues is with being able to provide a default implementation, or extending types such that I can override a method. For example, I have: (defprotocol http-resource (GET [res req resp]) (POST[res req resp]) (PUT [res req resp]) (DELETE [res req resp]) (HEAD[res req resp]) (OPTIONS [res req resp]) (TRACE [res req resp])) But I considering the usage, most of those need not be implemented per- type, and could all be defaulted to something like: (deftype resource [] http-resource (GET [req resp] (send-status! resp 405)) (POST [req resp] (send-status! resp 405)) (PUT [req resp] (send-status! resp 405)) (DELETE [req resp] (send-status! resp 405)) (HEAD [req resp] (send-status! resp 405)) (OPTIONS [req resp] (send-status! resp 405)) (TRACE [req resp] (send-status! resp 405))) Alas I can't simply extend-type since that modifies the type, instead of creating a new, modified type. And even then, methods in the extension map don't get called if the method exists directly on the type, i.e., no overriding. I'm sure my problem is simply vestigial OO thinking, but I'm not sure how to achieve the simplicity I want. The one route I tried that sort- of works is making a macro to create the types, rather than extending some extant implementation. The downside is I have to see which methods I'm being given and only provide "defaults" for the method names/arities that aren't. It might be sufficient if there was some facility for cloning another type and overriding certain methods, though I can foresee problems dealing with managing the field definitions between the original and the altered clone. -- 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: Datatypes and protocols - update
On Dec 7, 11:23 am, ataggart wrote: > On Dec 7, 9:07 am, Laurent PETIT wrote: > > > > > > > 2009/12/7 Hugo Duncan > > > > On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey > > > wrote: > > > > > Yes, methods are not really functions. Thinking about them as closures > > > > over the object is a good way to go - you can see that analogy in play > > > > when you consider recur, which works with these methods, but could not > > > > rebind 'this'. The recur case sealed the deal in the decision not to > > > > include 'this' in the argument lists. > > > > I had a quick play with protocols, and the biggest problem I had getting > > > started was realising that the signature of a method definition in > > > defprotocol was different to the signature required to implement the same > > > method in deftype. FWIW, I found it very non-intuitive. > > > Hello, > > > And now that you've got it, do you still feel this non-intuitive. > > Because I had the same feeling first: I thought I would never rembember how > > things work and why put 'this-like args there, and not there ... > > But now that everything "clicked in place", I feel the last status of what > > Rich achieved to do the most natural and intuitive. > > > Basically, what helped me was along the lines of what Konrad said : > > * defprotocol and extend are "purely functional" : so you have to specify > > every argument, including the object the functions acts upon. > > * deftype with embedded protocol definition for the type, or reify, in the > > contrary, do not define pure functions. They define methods. You cannot get > > them as values and pass them around like higher-order functions, for > > example. And you must know this fact, it cannot be an implementation detail. > > So, since you know this fact, you remember that you're in a method > > definition (in the general sense of object oriented languages : method of a > > class) and, as you do with e.g. java, C#, ... , when definining methods, you > > do not add the target of the method as an implicit argument. > > > The big advantage I see to this is that once you get it, you don't have > > anymore to remember where 'this is explicit and where it's implicit: it's > > intuitive. > > The other big advantage is that the use of recur inside these > > functions/methods bodies continue to match exactly the signature of the > > function/method (otherwise you would have had to remember that, e.g. in > > methods defined via deftype, you must place an explicit "this" argument in > > the method arg list, but not place it in the recur calls ... :-( ) > > > HTH, > > > -- > > laurent > > That was my experience as well. It started off as a gotcha (since I > was copy/pasting the protocol definitions over to the deftype), but > then after playing for a bit it wasn't a big deal. In all my usages > so far I haven't needed to reference 'this'. > > The one area I am running into issues is with being able to provide a > default implementation, or extending types such that I can override a > method. > > For example, I have: > > (defprotocol http-resource > (GET [res req resp]) > (POST [res req resp]) > (PUT [res req resp]) > (DELETE [res req resp]) > (HEAD [res req resp]) > (OPTIONS [res req resp]) > (TRACE [res req resp])) > > But I considering the usage, most of those need not be implemented per- > type, and could all be defaulted to something like: > > (deftype resource [] http-resource > (GET [req resp] (send-status! resp 405)) > (POST [req resp] (send-status! resp 405)) > (PUT [req resp] (send-status! resp 405)) > (DELETE [req resp] (send-status! resp 405)) > (HEAD [req resp] (send-status! resp 405)) > (OPTIONS [req resp] (send-status! resp 405)) > (TRACE [req resp] (send-status! resp 405))) > > Alas I can't simply extend-type since that modifies the type, instead > of creating a new, modified type. And even then, methods in the > extension map don't get called if the method exists directly on the > type, i.e., no overriding. > > I'm sure my problem is simply vestigial OO thinking, but I'm not sure > how to achieve the simplicity I want. The one route I tried that sort- > of works is making a macro to create the types, rather than extending > some extant implementation. The downside is I have to see which > methods I'm being given and only provide "defaults" for the method > names/arities that aren't. > > It might be sufficient if there was some facility for cloning another > type and overriding certain methods, though I can foresee problems > dealing with managing the field definitions between the original and > the altered clone. One idea: (defdefault name options* specs*) Similar to deftype except without any field definitions (a simplifying restriction), thus can only operate on their args. With that I could do: (defdefault base-resource http-resource (GET [req resp] (send-status! resp 405)) (POST [req resp] (send-status! resp 405)) (PUT [req resp] (send-stat
how 'bout a debug-repl?
Every time I stick a println into some Clojure code to debug it, I think to myself, "This is Lisp! I should be able to insert a repl here!" The problem is of course that Clojure's eval function doesn't know about the surrounding lexical scope. So I started asking myself, what is the simplest change I could make to Clojure to support an eval that understands that scope? Then I tried to implement it. Basically, here's what I came up with. 1. Modify the Clojure compiler so that when a flag is turned on, it stores references to the lexical scope in a dynamic var. Thus, each time the compiler creates a new lexical scope, it also emits the byte code to push a hash-map with the details onto the var. When that scope ends, the byte code for popping the hash-map off the var is emitted. 2. Then in Clojure proper, add a special version of eval that uses that var. It wraps the form being eval'ed in a "let" that emulates the original lexical scope, something like this: `(eval (let [~@(make-let-bindings (:lexical-frames (var-get (resolve context] ~form)) With those two pieces, it's straight-forward creating a "debug-repl" that understands the surrounding lexical scope. I'm pretty pleased with the results and wanted to show them off. More details here: http://georgejahad.com/clojure/debug-repl.html Thanks to the my coworkers, the "Sonian-Clojure Brain Trust", for their support and encouragement! -- 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: The new deftype and multimethod dispatching
On 7-Dec-09, at 12:17 PM, Laurent PETIT wrote: > 2009/12/6 Bob Hutchison > >> >> On 6-Dec-09, at 3:46 PM, Meikel Brandmeyer wrote: >> >>> Hi, >>> >>> Am 06.12.2009 um 21:29 schrieb Bob Hutchison: >>> It turns out that dispatching on play.foo.Foo is the only way that works. I was hoping ::f/Foo or f/Foo would work too (maybe my alias is wrong??). Especially since, with aliasing in the user namespace, I can create a play.foo.Foo using f/Foo >>> >>> Does the following work? >>> >>> (ns play.foo) >>> (deftype Foo []) >>> (defmulti my-print type) >>> (defmethod my-print ::Foo [x] (println "Got a foo")) >>> >>> (in-ns 'user) >>> ; Note: normally written as (require [play.foo :as f]) >>> (alias 'f 'play.foo) >>> (def x (f/Foo)) >>> (f/my-print x) >> >> >> Yes! Thanks! The dispatch on type rather than class is the trick. I >> actually ended up writing a macro, this is *much* better. >> > > Please note that in clojure, it's the dispatch on the class that's the > "trick", not on the type ;-) Sorry, I don't understand what you mean. Could you expand on that a bit? Thanks, Bob > > >> >> Cheers, >> Bob >> >>> >>> Sincerely >>> Meikel >>> >> >> >> Bob Hutchison >> Recursive Design Inc. >> http://www.recursive.ca/ >> weblog: http://www.recursive.ca/hutch >> >> >> >> -- >> 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 Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch -- 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: how 'bout a debug-repl?
> I'm pretty pleased with the results and wanted to show them off. More > details here: > http://georgejahad.com/clojure/debug-repl.html Pretty slick work, George! Thanks for sharing! -- 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: The new deftype and multimethod dispatching
On Dec 7, 12:37 pm, Bob Hutchison wrote: > On 7-Dec-09, at 12:17 PM, Laurent PETIT wrote: > > > > > > > 2009/12/6 Bob Hutchison > > >> On 6-Dec-09, at 3:46 PM, Meikel Brandmeyer wrote: > > >>> Hi, > > >>> Am 06.12.2009 um 21:29 schrieb Bob Hutchison: > > It turns out that dispatching on play.foo.Foo is the only way that > works. I was hoping ::f/Foo or f/Foo would work too (maybe my alias > is > wrong??). Especially since, with aliasing in the user namespace, I > can > create a play.foo.Foo using f/Foo > > >>> Does the following work? > > >>> (ns play.foo) > >>> (deftype Foo []) > >>> (defmulti my-print type) > >>> (defmethod my-print ::Foo [x] (println "Got a foo")) > > >>> (in-ns 'user) > >>> ; Note: normally written as (require [play.foo :as f]) > >>> (alias 'f 'play.foo) > >>> (def x (f/Foo)) > >>> (f/my-print x) > > >> Yes! Thanks! The dispatch on type rather than class is the trick. I > >> actually ended up writing a macro, this is *much* better. > > > Please note that in clojure, it's the dispatch on the class that's the > > "trick", not on the type ;-) > > Sorry, I don't understand what you mean. Could you expand on that a bit? > > Thanks, > Bob > > > > > > > > >> Cheers, > >> Bob > > >>> Sincerely > >>> Meikel > > >> > >> Bob Hutchison > >> Recursive Design Inc. > >>http://www.recursive.ca/ > >> weblog:http://www.recursive.ca/hutch > > >> -- > >> 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 > > > Bob Hutchison > Recursive Design Inc.http://www.recursive.ca/ > weblog:http://www.recursive.ca/hutch I think Laurent means that type should be the preferred/standard mechanism, and class reserved for sneaking over to java-land. -- 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: The new deftype and multimethod dispatching
On 7-Dec-09, at 4:16 PM, ataggart wrote: > On Dec 7, 12:37 pm, Bob Hutchison wrote: >> On 7-Dec-09, at 12:17 PM, Laurent PETIT wrote: >>> 2009/12/6 Bob Hutchison >> Yes! Thanks! The dispatch on type rather than class is the trick. I actually ended up writing a macro, this is *much* better. >> >>> Please note that in clojure, it's the dispatch on the class that's >>> the >>> "trick", not on the type ;-) >> >> Sorry, I don't understand what you mean. Could you expand on that a >> bit? >> > > I think Laurent means that type should be the preferred/standard > mechanism, and class reserved for sneaking over to java-land. Okay, that makes sense. Maybe I wasn't paying attention but it seems to me that the examples I've seen all use class. But, what I thought doesn't matter... type certainly works nicely. Cheers, Bob Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch -- 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
new API webpage format
Hi, I am writing because there seem to be missing functions in the API webpage. The only one that I know for sure at the moment is the filter 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
hyphens vs. underscores for lib names
hi, why does that translation happen? is there some java issue/requirement? thanks. -- 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: hyphens vs. underscores for lib names
> why does that translation happen? is there some java issue/ > requirement? I don't think '-' is valid in a Java class name. http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#40625 user=> (Character/isJavaIdentifierPart \-) false user=> (Character/isJavaIdentifierPart \_) true -- 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
Embedding a REPL
I've seen an example of launching a Clojure script from Java (http:// en.wikibooks.org/wiki/Clojure_Programming/ Tutorials_and_Tips#Invoking_Clojure_from_Java), but I've got an application in which I'd like to run a REPL. My app has its own JPanel for display results, and a text area for input, so I'll need to start repl with some replacement callback functions (read, print, prompt, need-prompt). I'd like to code as much as possible in Clojure, but at some point I need to pass in some Java object instances that my wrapper functions will use to perform I/ O for the repl. Has anyone done this recently? Could someone point me in the right direction for exposing Java objects into Clojure? I've tried reading main.java and RT.java looking for hints, but I'm not too smart yet about the Clojure environment, the scope of when things live, and such. Thanks in advance for any hints... Mike -- 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: Datatypes and protocols - update
On Dec 1, 9:56 pm, Rich Hickey wrote: > > There are 2 ways to make a deftype reach a protocol. First, you can > implement the protocol directly in the deftype/reify, supplying the > protocol where you do interfaces, and the methods of the protocol as > methods of the type. The type will be made to implement the protocol's > interface. The second way, for types you don't control, is to use > extend-type/class/protocol, which will create method maps and register > them with the protocol. > For the record; this means that you cannot implement two protocols directly in deftype or reify if those protocols have fns with the same names and signatures. You can, however, implement one protocol directly, and then extend it to the other, as with the following, rather silly, example: user> (ns foo) nil foo> (defprotocol Foo (write [this])) Foo foo> (ns bar) nil bar> (defprotocol Bar (write [this badger])) Bar bar> (ns me) nil me> (defprotocol Me (write [this] [this badger])) Me me> (ns user) nil user> (deftype FooMe [a b c d] foo/Foo (write [] a) bar/Bar (write [badger] b)) #'user/FooMe user> (def fm (FooMe :foo :bar :me1 :me2)) #'user/fm user> (foo/write fm) :foo user> (bar/write fm 1) :bar user> (extend-type ::FooMe me/Me (write ([this] (:c this)) ([this badger] (:d this nil user> (me/write fm) :me1 user> (me/write fm 1) :me2 user> (foo/write fm) :foo user> (bar/write fm 1) :bar user> which was unexpectedly sweet, yet totally consistent with your explanation of how it works. Rich, you _are_ the Badgers Nadgers. -Dave -- 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: The new deftype and multimethod dispatching
Hi, Am 07.12.2009 um 21:37 schrieb Bob Hutchison: >> Please note that in clojure, it's the dispatch on the class that's the >> "trick", not on the type ;-) > > Sorry, I don't understand what you mean. Could you expand on that a bit? Dispatch on the class (or interface) is sometimes the "trick" in clojure. That means a special case, which solves the problem. Eg. the print-method which causes things to be printed by print dispatches on type. Now, type recognises any type tag on the metadata of a thing. But when there is no method defined for this type, print would barf. So the default print-method simply dissocs the type tag from the metadata and retries causing basically a dispatch on the class of the underlying container. Most likely some Map or so. So dispatching on the class is here the trick. Dispatching on type the usual case. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: The new deftype and multimethod dispatching
On 7-Dec-09, at 4:05 PM, Meikel Brandmeyer wrote: > Hi, > > Am 07.12.2009 um 21:37 schrieb Bob Hutchison: > >>> Please note that in clojure, it's the dispatch on the class that's >>> the >>> "trick", not on the type ;-) >> >> Sorry, I don't understand what you mean. Could you expand on that a >> bit? > > Dispatch on the class (or interface) is sometimes the "trick" in > clojure. That means a special case, which solves the problem. Eg. > the print-method which causes things to be printed by print > dispatches on type. Now, type recognises any type tag on the > metadata of a thing. But when there is no method defined for this > type, print would barf. So the default print-method simply dissocs > the type tag from the metadata and retries causing basically a > dispatch on the class of the underlying container. Most likely some > Map or so. So dispatching on the class is here the trick. > Dispatching on type the usual case. Thanks. BTW, I'm thinking that my use of the word 'trick' might have been a mistake. Where I come from 'does the trick', 'that's the trick' and so on mean something along the line of 'that's how you get the required result', and that's what I hoped to say... I didn't mean to imply any kind of trickiness existed that would fool me into write 'class' rather than 'type'... ignorance explains that quite nicely :-) Cheers, Bob > > Sincerely > Meikel > Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch -- 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: new API webpage format
By golly, you're right. I'll take a look at why. On Dec 7, 2:14 pm, cej38 wrote: > Hi, > I am writing because there seem to be missing functions in the API > webpage. The only one that I know for sure at the moment is the > filter 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: hyphens vs. underscores for lib names
> I don't think '-' is valid in a Java class name. makes sense, and i learn something "new" every day... thanks. -- 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: Generalizing -> & ->>
On Sat, 2009-12-05 at 13:14 +0100, Konrad Hinsen wrote: > On 4 Dec 2009, at 23:23, Cliff Wells wrote: > > > What isn't clear to me is exactly what a piece of paper provides > > that an > > electronic form doesn't (aside from inconvenience). I don't see any > > A clear legal status all over the world. A signed statement on paper > is recognized everywhere. The legal status of electronic messages, > even if signed by some suitable technique, varies wildly from one > country to the other. > > It would be nice if open software could somehow escape from the legal > hassle surrounding copyright law, but I don't think this is a > realistic idea. What I'm saying is that a signed document, whether digital or on paper, provides little in the way of forgery prevention. Therefore, without witnesses (e.g. a notary) or a sworn admission of signing, a signature is largely inconsequential. Since the Clojure CAS requires nothing of the sort, it is no better than a digital signature, regardless of jurisdiction. Clearly the decision is up to Rich (it's his project, anyone who doesn't like it could easily start a clojure-community project with relaxed requirements), but frankly the current requirements are rather pointless since they provide no real protections. Regards, Cliff -- 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: how is "leiningen new" intended to work?
I am no expert at this, but this is what I have done 1. lein new mytestprj 2. go into the newly created dir and edit the project.clj and rename from 'leiningen' to mytestprj (I think this is why your jar was getting named leiningen.jar). 3. then do a 'lein deps' to copy the required libs into the lib directory 4. then do a lein install that installs mytestprj.jar. I agree that it will be nice if lein was more like 'mvn archetype:generate' and would ask all the required info and create but its a new project so go easy on it ;-) -Devender On Dec 7, 6:05 am, B Smith-Mannschott wrote: > I'm finding the behavior of leiningen new to be broken. It looks like > the initial implementation isn't clear about what exactly the project > name given as argument to lein new denotes. I'd like to fix this, but > before i hack on a patch, I'd be curious to know how this subcommand > was intended to work in the first place. > > It seems like lein new really needs thee pieces of information: > > (1) what directory should be created to contain the project? > (2) what should the project's name (artifactId) be? > (3) what should the project's group (groupId) be? > > It seems like it's trying to synthesize this out of a single piece of > information:a string which can't decide if it's #1 or #2 and that's > not working. Also, the otherwise empty .clj file created by lein new > seems to have a mangled ns declaration. > > // ben > > Please feel free to skip the rant that follows if the above is > sufficiently clear. > > The documentation of lein new leaves me guessing: > > smit...@wesley:~/w/VJS-88$ lein help new > Create a new project skeleton. > > Thus I consult the source. > > The Implementation of "lein new PROJECTNAME" uses mkdirs to make the > directories for PROJECTNAME, so it stands to reason that PROJECTNAME > can be a path, not just a simple name. > > ;; leiningen/new.clj > (defn new [project-name & [args]] > (.mkdirs (file project-name)) > ... > > Indeed, this appears to work, but doesn't since the clj file that's > generated by default has a gibberish namespace: > > smit...@wesley:~/w/VJS-88$ lein new Foo/Bar > Created new project: Foo/Bar > smit...@wesley:~/w/VJS-88$ cat Foo/Bar/src/Foo/Bar.clj > (ns Foo/Bar.core) > > So simple names it is: > > smit...@wesley:~/w/VJS-88$ lein new Foo > Created new project: Foo/Bar > smit...@wesley:~/w/VJS-88$ cat Foo/src/Foo.clj > (ns Foo.core) > > But this still doesn't look right. Shouldn't the file be named > Foo/src/Foo/core.clj if it's going to declare its namespace as > Foo.core? How else will the classloader know where to find it? > > Ok, well, let's move on and build a jar. > > smit...@wesley:~/w/VJS-88/Foo$ lein jar > [INFO] snapshot org.clojure:clojure:1.1.0-alpha-SNAPSHOT: checking for > updates from internal > [INFO] snapshot org.clojure:clojure-contrib:1.0-SNAPSHOT: checking for > updates from internal > [copy] Copying 2 files to /home/smithma/w/VJS-88/Foo/lib > smit...@wesley:~/w/VJS-88/Foo$ ls > classes leiningen.jar lib project.clj README src test > > Oh. That's odd, the JAR is named leiningen.jar, despite the fact that > I've told lein that my project is named Foo. (Remember we've already > established that the argument to lein isn't primarily answering the > question "where do I put the project" (otherwise it would not break > when given a path). Therefore, the primary meaning of the argument > might logically be "what should the project be called.") But, clearly > that's not it, because the project just get's called "leiningen", no > matter what I ask for on the command line. > > Now, to cut a long story short, it took me a while to figure out that > I could use a name-space qualified symbol as the project name a-la: > my.group.id/artifactId to get both a sane file jar file name out of > "lein jar" and a sane install location from "lein install". Is this > documented somewhere? I gleaned it from the source. (of course we > can't do that from the command line because we've established that > slashes in that context == 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
Trouble implementing Dijkstra algorithm in Clojure
Hi all, I am new to FP in general and I am trying to pick up Clojure. I am having trouble thinking in FP terms. I am trying to implement the Dijkstra algorithm for shortest paths in Graph in Clojure. If this succeeds, I will implement all the advanced graph algos I am learning in this course in Clojure and post in online. My concerns regarding implementing Dijkstra in Clojure are following: 1. The way I've learnt Dijkstra, there is a distance array and we keep on updating it if we find a shorter path. Since, things are immutable, how do I do it? 2. Does Clojure have a Priority Queue data structure inbuilt. I would need that for Dijkstra algorithm. Thanks, Ajay G. -- 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: Embedding a REPL
I think the following is “looked down upon” or “discouraged“, but I
managed to sift through how clojure itself handles its own stuff in
java and I came up with the following.
Say, that you want to set *out*, *in*, and *err* in clojure to
something from Java before starting a REPL. Here is how I passed on
these values to the clojure RT:
try {
Var.pushThreadBindings(RT.map(
RT.OUT, new OutputStreamWriter(MYout),
RT.IN, new LineNumberingPushbackReader(new InputStreamReader(MYin)),
RT.ERR, new PrintWriter(new OutputStreamWriter(MYout), true)));
main.main(new String[] {"-r"});
} catch (Exception e) {}
finally {
Var.popThreadBindings();
}
Don’t forget to import (after setting clojure.jar on the cp).
import clojure.main;
import clojure.lang.RT;
import clojure.lang.Var;
Note that the doc-string of the clojure (repl function allows for
hooks for some of what you want. You just need to look into how you
could pass on those functions for :need-
prompt, :prompt, :flush, :read in a way that clojure can digest, which
I think is just a Runnable in a map of sorts. But you’ll have to look
into that to be sure.
Regardless, I highly recommend that you separate Java from clojure
coding as mush as possible, or at least treat clojure in a functional
way when touching it from Java.
I hope this helps. If someone else has a better way, I’m all ears.
On Dec 7, 8:19 am, Mike wrote:
> I've seen an example of launching a Clojure script from Java (http://
> en.wikibooks.org/wiki/Clojure_Programming/
> Tutorials_and_Tips#Invoking_Clojure_from_Java), but I've got an
> application in which I'd like to run a REPL.
>
> My app has its own JPanel for display results, and a text area for
> input, so I'll need to start repl with some replacement callback
> functions (read, print, prompt, need-prompt). I'd like to code as
> much as possible in Clojure, but at some point I need to pass in some
> Java object instances that my wrapper functions will use to perform I/
> O for the repl.
>
> Has anyone done this recently? Could someone point me in the right
> direction for exposing Java objects into Clojure? I've tried reading
> main.java and RT.java looking for hints, but I'm not too smart yet
> about the Clojure environment, the scope of when things live, and
> such.
>
> Thanks in advance for any hints...
> Mike
--
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: new API webpage format
I still think it would be neat if there was some DHTML coolness to help narrow down the symbol names that come down the right side of the page. On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber wrote: > By golly, you're right. I'll take a look at why. > > On Dec 7, 2:14 pm, cej38 wrote: >> Hi, >> I am writing because there seem to be missing functions in the API >> webpage. The only one that I know for sure at the moment is the >> filter 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 -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: new API webpage format
Yup, I heard that the first time :-) It's coming, but not right this sec. Tom On Dec 7, 4:57 pm, Howard Lewis Ship wrote: > I still think it would be neat if there was some DHTML coolness to > help narrow down the symbol names that come down the right side of the > page. > > > > On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber wrote: > > By golly, you're right. I'll take a look at why. > > > On Dec 7, 2:14 pm, cej38 wrote: > >> Hi, > >> I am writing because there seem to be missing functions in the API > >> webpage. The only one that I know for sure at the moment is the > >> filter 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 > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Possible BUG: NPE
Hi, After git pull on new branch commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 Author: Rich Hickey Date: Mon Dec 7 16:44:41 2009 -0500 init CLEAR_SITES Got NPE in slime java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException [Thrown class java.lang.RuntimeException] Backtrace: 0: clojure.lang.LazySeq.sval(LazySeq.java:47) 1: clojure.lang.LazySeq.seq(LazySeq.java:56) 2: clojure.lang.RT.seq(RT.java:440) 3: clojure.core$seq__3970.invoke(core.clj:105) 4: clojure.core$sort__4671.invoke(core.clj:1994) 5: swank.commands.contrib.swank_fuzzy $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) 6: swank.commands.contrib.swank_fuzzy $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke (swank_fuzzy.clj:127) 8: swank.commands.contrib.swank_fuzzy $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) 9: swank.commands.contrib.swank_fuzzy $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) 10: clojure.lang.Var.invoke(Var.java:385) 11: user$eval__2042.invoke(NO_SOURCE_FILE) 12: clojure.lang.Compiler.eval(Compiler.java:5256) 13: clojure.lang.Compiler.eval(Compiler.java:5224) 14: clojure.core$eval__4688.invoke(core.clj:2036) 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) 17: clojure.lang.Var.invoke(Var.java:373) 18: clojure.lang.AFn.applyToHelper(AFn.java:182) 19: clojure.lang.Var.applyTo(Var.java:482) 20: clojure.core$apply__4058.invoke(core.clj:437) 21: swank.core$eval_from_control__401.invoke(core.clj:65) 22: swank.core$eval_loop__403.invoke(core.clj:70) 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: 179) 24: clojure.lang.AFn.applyToHelper(AFn.java:172) 25: clojure.lang.AFn.applyTo(AFn.java:164) 26: clojure.core$apply__4058.invoke(core.clj:437) 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) 28: clojure.lang.RestFn.invoke(RestFn.java:398) 29: clojure.lang.AFn.run(AFn.java:37) 30: java.lang.Thread.run(Thread.java:613) -- 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: Possible BUG: NPE
I was getting this as well, but this was before the last 3 commits to new. Did you wipe your old jars and class files and start afresh? David On Mon, Dec 7, 2009 at 8:31 PM, Feng wrote: > Hi, > > After git pull on new branch > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 > Author: Rich Hickey > Date: Mon Dec 7 16:44:41 2009 -0500 > >init CLEAR_SITES > > Got NPE in slime > > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.NullPointerException > [Thrown class java.lang.RuntimeException] > > Backtrace: > 0: clojure.lang.LazySeq.sval(LazySeq.java:47) > 1: clojure.lang.LazySeq.seq(LazySeq.java:56) > 2: clojure.lang.RT.seq(RT.java:440) > 3: clojure.core$seq__3970.invoke(core.clj:105) > 4: clojure.core$sort__4671.invoke(core.clj:1994) > 5: swank.commands.contrib.swank_fuzzy > $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) > 6: swank.commands.contrib.swank_fuzzy > $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) > 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke > (swank_fuzzy.clj:127) > 8: swank.commands.contrib.swank_fuzzy > $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) > 9: swank.commands.contrib.swank_fuzzy > $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) > 10: clojure.lang.Var.invoke(Var.java:385) > 11: user$eval__2042.invoke(NO_SOURCE_FILE) > 12: clojure.lang.Compiler.eval(Compiler.java:5256) > 13: clojure.lang.Compiler.eval(Compiler.java:5224) > 14: clojure.core$eval__4688.invoke(core.clj:2036) > 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) > 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) > 17: clojure.lang.Var.invoke(Var.java:373) > 18: clojure.lang.AFn.applyToHelper(AFn.java:182) > 19: clojure.lang.Var.applyTo(Var.java:482) > 20: clojure.core$apply__4058.invoke(core.clj:437) > 21: swank.core$eval_from_control__401.invoke(core.clj:65) > 22: swank.core$eval_loop__403.invoke(core.clj:70) > 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: > 179) > 24: clojure.lang.AFn.applyToHelper(AFn.java:172) > 25: clojure.lang.AFn.applyTo(AFn.java:164) > 26: clojure.core$apply__4058.invoke(core.clj:437) > 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) > 28: clojure.lang.RestFn.invoke(RestFn.java:398) > 29: clojure.lang.AFn.run(AFn.java:37) > 30: java.lang.Thread.run(Thread.java:613) > > -- > 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: Possible BUG: NPE
On Dec 7, 8:57 pm, David Nolen wrote: > I was getting this as well, but this was before the last 3 commits to new. > Did you wipe your old jars and class files and start afresh? > Yes, just to make sure not waste Rich's time. I did doubt and triple checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ... I use Jeff's git master clone, not Phil's branch. No magic in emacs. I load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And always start swank from console repl in screen, then M-x slime- connect. So I'm pretty sure where everything is. > David > > On Mon, Dec 7, 2009 at 8:31 PM, Feng wrote: > > Hi, > > > After git pull on new branch > > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 > > Author: Rich Hickey > > Date: Mon Dec 7 16:44:41 2009 -0500 > > > init CLEAR_SITES > > > Got NPE in slime > > > java.lang.RuntimeException: java.lang.RuntimeException: > > java.lang.RuntimeException: java.lang.RuntimeException: > > java.lang.NullPointerException > > [Thrown class java.lang.RuntimeException] > > > Backtrace: > > 0: clojure.lang.LazySeq.sval(LazySeq.java:47) > > 1: clojure.lang.LazySeq.seq(LazySeq.java:56) > > 2: clojure.lang.RT.seq(RT.java:440) > > 3: clojure.core$seq__3970.invoke(core.clj:105) > > 4: clojure.core$sort__4671.invoke(core.clj:1994) > > 5: swank.commands.contrib.swank_fuzzy > > $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) > > 6: swank.commands.contrib.swank_fuzzy > > $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) > > 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke > > (swank_fuzzy.clj:127) > > 8: swank.commands.contrib.swank_fuzzy > > $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) > > 9: swank.commands.contrib.swank_fuzzy > > $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) > > 10: clojure.lang.Var.invoke(Var.java:385) > > 11: user$eval__2042.invoke(NO_SOURCE_FILE) > > 12: clojure.lang.Compiler.eval(Compiler.java:5256) > > 13: clojure.lang.Compiler.eval(Compiler.java:5224) > > 14: clojure.core$eval__4688.invoke(core.clj:2036) > > 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) > > 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) > > 17: clojure.lang.Var.invoke(Var.java:373) > > 18: clojure.lang.AFn.applyToHelper(AFn.java:182) > > 19: clojure.lang.Var.applyTo(Var.java:482) > > 20: clojure.core$apply__4058.invoke(core.clj:437) > > 21: swank.core$eval_from_control__401.invoke(core.clj:65) > > 22: swank.core$eval_loop__403.invoke(core.clj:70) > > 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: > > 179) > > 24: clojure.lang.AFn.applyToHelper(AFn.java:172) > > 25: clojure.lang.AFn.applyTo(AFn.java:164) > > 26: clojure.core$apply__4058.invoke(core.clj:437) > > 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) > > 28: clojure.lang.RestFn.invoke(RestFn.java:398) > > 29: clojure.lang.AFn.run(AFn.java:37) > > 30: java.lang.Thread.run(Thread.java:613) > > > -- > > 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: Possible BUG: NPE
Looking at the stacktrace it looks like this is because of swank_fuzzy.clj. I can start up the SLIME Repl no problem, I see your exact same stack trace only if I try to trigger fuzzy completion via C-c TAB. David On Mon, Dec 7, 2009 at 9:24 PM, Feng wrote: > > > On Dec 7, 8:57 pm, David Nolen wrote: > > I was getting this as well, but this was before the last 3 commits to > new. > > Did you wipe your old jars and class files and start afresh? > > > > Yes, just to make sure not waste Rich's time. I did doubt and triple > checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ... > > I use Jeff's git master clone, not Phil's branch. No magic in emacs. I > load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And > always start swank from console repl in screen, then M-x slime- > connect. So I'm pretty sure where everything is. > > > David > > > > On Mon, Dec 7, 2009 at 8:31 PM, Feng wrote: > > > Hi, > > > > > After git pull on new branch > > > > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 > > > Author: Rich Hickey > > > Date: Mon Dec 7 16:44:41 2009 -0500 > > > > >init CLEAR_SITES > > > > > Got NPE in slime > > > > > java.lang.RuntimeException: java.lang.RuntimeException: > > > java.lang.RuntimeException: java.lang.RuntimeException: > > > java.lang.NullPointerException > > > [Thrown class java.lang.RuntimeException] > > > > > Backtrace: > > > 0: clojure.lang.LazySeq.sval(LazySeq.java:47) > > > 1: clojure.lang.LazySeq.seq(LazySeq.java:56) > > > 2: clojure.lang.RT.seq(RT.java:440) > > > 3: clojure.core$seq__3970.invoke(core.clj:105) > > > 4: clojure.core$sort__4671.invoke(core.clj:1994) > > > 5: swank.commands.contrib.swank_fuzzy > > > $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) > > > 6: swank.commands.contrib.swank_fuzzy > > > $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) > > > 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke > > > (swank_fuzzy.clj:127) > > > 8: swank.commands.contrib.swank_fuzzy > > > $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) > > > 9: swank.commands.contrib.swank_fuzzy > > > $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) > > > 10: clojure.lang.Var.invoke(Var.java:385) > > > 11: user$eval__2042.invoke(NO_SOURCE_FILE) > > > 12: clojure.lang.Compiler.eval(Compiler.java:5256) > > > 13: clojure.lang.Compiler.eval(Compiler.java:5224) > > > 14: clojure.core$eval__4688.invoke(core.clj:2036) > > > 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) > > > 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) > > > 17: clojure.lang.Var.invoke(Var.java:373) > > > 18: clojure.lang.AFn.applyToHelper(AFn.java:182) > > > 19: clojure.lang.Var.applyTo(Var.java:482) > > > 20: clojure.core$apply__4058.invoke(core.clj:437) > > > 21: swank.core$eval_from_control__401.invoke(core.clj:65) > > > 22: swank.core$eval_loop__403.invoke(core.clj:70) > > > 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: > > > 179) > > > 24: clojure.lang.AFn.applyToHelper(AFn.java:172) > > > 25: clojure.lang.AFn.applyTo(AFn.java:164) > > > 26: clojure.core$apply__4058.invoke(core.clj:437) > > > 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) > > > 28: clojure.lang.RestFn.invoke(RestFn.java:398) > > > 29: clojure.lang.AFn.run(AFn.java:37) > > > 30: java.lang.Thread.run(Thread.java:613) > > > > > -- > > > 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: Possible BUG: NPE
http://github.com/jochu/swank-clojure/blob/master/src/main/clojure/swank/commands/contrib/swank_fuzzy.clj#L256 Is the offending line. On Mon, Dec 7, 2009 at 9:34 PM, David Nolen wrote: > Looking at the stacktrace it looks like this is because of swank_fuzzy.clj. > I can start up the SLIME Repl no problem, I see your exact same stack trace > only if I try to trigger fuzzy completion via C-c TAB. > > David > > > On Mon, Dec 7, 2009 at 9:24 PM, Feng wrote: > >> >> >> On Dec 7, 8:57 pm, David Nolen wrote: >> > I was getting this as well, but this was before the last 3 commits to >> new. >> > Did you wipe your old jars and class files and start afresh? >> > >> >> Yes, just to make sure not waste Rich's time. I did doubt and triple >> checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ... >> >> I use Jeff's git master clone, not Phil's branch. No magic in emacs. I >> load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And >> always start swank from console repl in screen, then M-x slime- >> connect. So I'm pretty sure where everything is. >> >> > David >> > >> > On Mon, Dec 7, 2009 at 8:31 PM, Feng wrote: >> > > Hi, >> > >> > > After git pull on new branch >> > >> > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 >> > > Author: Rich Hickey >> > > Date: Mon Dec 7 16:44:41 2009 -0500 >> > >> > >init CLEAR_SITES >> > >> > > Got NPE in slime >> > >> > > java.lang.RuntimeException: java.lang.RuntimeException: >> > > java.lang.RuntimeException: java.lang.RuntimeException: >> > > java.lang.NullPointerException >> > > [Thrown class java.lang.RuntimeException] >> > >> > > Backtrace: >> > > 0: clojure.lang.LazySeq.sval(LazySeq.java:47) >> > > 1: clojure.lang.LazySeq.seq(LazySeq.java:56) >> > > 2: clojure.lang.RT.seq(RT.java:440) >> > > 3: clojure.core$seq__3970.invoke(core.clj:105) >> > > 4: clojure.core$sort__4671.invoke(core.clj:1994) >> > > 5: swank.commands.contrib.swank_fuzzy >> > > $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) >> > > 6: swank.commands.contrib.swank_fuzzy >> > > $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) >> > > 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke >> > > (swank_fuzzy.clj:127) >> > > 8: swank.commands.contrib.swank_fuzzy >> > > $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) >> > > 9: swank.commands.contrib.swank_fuzzy >> > > $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) >> > > 10: clojure.lang.Var.invoke(Var.java:385) >> > > 11: user$eval__2042.invoke(NO_SOURCE_FILE) >> > > 12: clojure.lang.Compiler.eval(Compiler.java:5256) >> > > 13: clojure.lang.Compiler.eval(Compiler.java:5224) >> > > 14: clojure.core$eval__4688.invoke(core.clj:2036) >> > > 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) >> > > 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) >> > > 17: clojure.lang.Var.invoke(Var.java:373) >> > > 18: clojure.lang.AFn.applyToHelper(AFn.java:182) >> > > 19: clojure.lang.Var.applyTo(Var.java:482) >> > > 20: clojure.core$apply__4058.invoke(core.clj:437) >> > > 21: swank.core$eval_from_control__401.invoke(core.clj:65) >> > > 22: swank.core$eval_loop__403.invoke(core.clj:70) >> > > 23: >> swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: >> > > 179) >> > > 24: clojure.lang.AFn.applyToHelper(AFn.java:172) >> > > 25: clojure.lang.AFn.applyTo(AFn.java:164) >> > > 26: clojure.core$apply__4058.invoke(core.clj:437) >> > > 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) >> > > 28: clojure.lang.RestFn.invoke(RestFn.java:398) >> > > 29: clojure.lang.AFn.run(AFn.java:37) >> > > 30: java.lang.Thread.run(Thread.java:613) >> > >> > > -- >> > > 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, v
Re: new API webpage format
While we're throwing requests at Tom, it'd be nice if the special forms were included in the api. On Dec 7, 5:21 pm, Tom Faulhaber wrote: > Yup, I heard that the first time :-) > > It's coming, but not right this sec. > > Tom > > On Dec 7, 4:57 pm, Howard Lewis Ship wrote: > > > > > I still think it would be neat if there was some DHTML coolness to > > help narrow down the symbol names that come down the right side of the > > page. > > > On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber > > wrote: > > > By golly, you're right. I'll take a look at why. > > > > On Dec 7, 2:14 pm, cej38 wrote: > > >> Hi, > > >> I am writing because there seem to be missing functions in the API > > >> webpage. The only one that I know for sure at the moment is the > > >> filter 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 > > > -- > > Howard M. Lewis Ship > > > Creator of Apache Tapestry > > > The source for Tapestry training, mentoring and support. Contact me to > > learn how I can get you up and productive in Tapestry fast! > > > (971) 678-5210http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Trouble implementing Dijkstra algorithm in Clojure
On Dec 7, 4:19 pm, ajay wrote: > Hi all, > > I am new to FP in general and I am trying to pick up Clojure. I am > having trouble thinking in FP terms. > > I am trying to implement the Dijkstra algorithm for shortest paths in > Graph in Clojure. If this succeeds, I will implement all the advanced > graph algos I am learning in this course in Clojure and post in > online. > > My concerns regarding implementing Dijkstra in Clojure are following: > > 1. The way I've learnt Dijkstra, there is a distance array and we keep > on updating it if we find a shorter path. Since, things are immutable, > how do I do it? You call functions that give you a new, modified version of the input collection. (conj [1 2 3] 4) ;=> [1 2 3 4] And you can use atoms to hold a reference to a collection. Just depends on how you want to use them. > 2. Does Clojure have a Priority Queue data structure inbuilt. I would > need that for Dijkstra algorithm. I think sorted-set or sorted-set-by should suffice. If not, you could make one or see if there's on in contrib somewhere. > > Thanks, > Ajay G. -- 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: Possible BUG: NPE
Yes, fuzzy-completion seems the only way to trigger it. For what it's worth, it did not happen if reset to commit a3e95cf5a72b22cd0728aba152d5f77603b722fc Author: Rich Hickey Date: Fri Dec 4 11:22:04 2009 -0500 update example in reify doc - Feng On Dec 7, 9:34 pm, David Nolen wrote: > Looking at the stacktrace it looks like this is because of swank_fuzzy.clj. > I can start up the SLIME Repl no problem, I see your exact same stack trace > only if I try to trigger fuzzy completion via C-c TAB. > > David > > On Mon, Dec 7, 2009 at 9:24 PM, Feng wrote: > > > On Dec 7, 8:57 pm, David Nolen wrote: > > > I was getting this as well, but this was before the last 3 commits to > > new. > > > Did you wipe your old jars and class files and start afresh? > > > Yes, just to make sure not waste Rich's time. I did doubt and triple > > checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ... > > > I use Jeff's git master clone, not Phil's branch. No magic in emacs. I > > load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And > > always start swank from console repl in screen, then M-x slime- > > connect. So I'm pretty sure where everything is. > > > > David > > > > On Mon, Dec 7, 2009 at 8:31 PM, Feng wrote: > > > > Hi, > > > > > After git pull on new branch > > > > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 > > > > Author: Rich Hickey > > > > Date: Mon Dec 7 16:44:41 2009 -0500 > > > > > init CLEAR_SITES > > > > > Got NPE in slime > > > > > java.lang.RuntimeException: java.lang.RuntimeException: > > > > java.lang.RuntimeException: java.lang.RuntimeException: > > > > java.lang.NullPointerException > > > > [Thrown class java.lang.RuntimeException] > > > > > Backtrace: > > > > 0: clojure.lang.LazySeq.sval(LazySeq.java:47) > > > > 1: clojure.lang.LazySeq.seq(LazySeq.java:56) > > > > 2: clojure.lang.RT.seq(RT.java:440) > > > > 3: clojure.core$seq__3970.invoke(core.clj:105) > > > > 4: clojure.core$sort__4671.invoke(core.clj:1994) > > > > 5: swank.commands.contrib.swank_fuzzy > > > > $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256) > > > > 6: swank.commands.contrib.swank_fuzzy > > > > $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310) > > > > 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke > > > > (swank_fuzzy.clj:127) > > > > 8: swank.commands.contrib.swank_fuzzy > > > > $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309) > > > > 9: swank.commands.contrib.swank_fuzzy > > > > $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323) > > > > 10: clojure.lang.Var.invoke(Var.java:385) > > > > 11: user$eval__2042.invoke(NO_SOURCE_FILE) > > > > 12: clojure.lang.Compiler.eval(Compiler.java:5256) > > > > 13: clojure.lang.Compiler.eval(Compiler.java:5224) > > > > 14: clojure.core$eval__4688.invoke(core.clj:2036) > > > > 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58) > > > > 16: swank.core$eval_for_emacs__468.invoke(core.clj:126) > > > > 17: clojure.lang.Var.invoke(Var.java:373) > > > > 18: clojure.lang.AFn.applyToHelper(AFn.java:182) > > > > 19: clojure.lang.Var.applyTo(Var.java:482) > > > > 20: clojure.core$apply__4058.invoke(core.clj:437) > > > > 21: swank.core$eval_from_control__401.invoke(core.clj:65) > > > > 22: swank.core$eval_loop__403.invoke(core.clj:70) > > > > 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj: > > > > 179) > > > > 24: clojure.lang.AFn.applyToHelper(AFn.java:172) > > > > 25: clojure.lang.AFn.applyTo(AFn.java:164) > > > > 26: clojure.core$apply__4058.invoke(core.clj:437) > > > > 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176) > > > > 28: clojure.lang.RestFn.invoke(RestFn.java:398) > > > > 29: clojure.lang.AFn.run(AFn.java:37) > > > > 30: java.lang.Thread.run(Thread.java:613) > > > > > -- > > > > 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 p
Re: Trouble implementing Dijkstra algorithm in Clojure
you can use recur. it calls the fn/loop it's contained in with new args. (so, with the updated array and queue) On Dec 7, 8:19 pm, ajay wrote: > Hi all, > > I am new to FP in general and I am trying to pick up Clojure. I am > having trouble thinking in FP terms. > > I am trying to implement the Dijkstra algorithm for shortest paths in > Graph in Clojure. If this succeeds, I will implement all the advanced > graph algos I am learning in this course in Clojure and post in > online. > > My concerns regarding implementing Dijkstra in Clojure are following: > > 1. The way I've learnt Dijkstra, there is a distance array and we keep > on updating it if we find a shorter path. Since, things are immutable, > how do I do it? > 2. Does Clojure have a Priority Queue data structure inbuilt. I would > need that for Dijkstra algorithm. > > Thanks, > Ajay G. -- 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: new API webpage format
inc Thanks for the hard work. On 12/7/09, ataggart wrote: > While we're throwing requests at Tom, it'd be nice if the special > forms were included in the api. > > On Dec 7, 5:21 pm, Tom Faulhaber wrote: >> Yup, I heard that the first time :-) >> >> It's coming, but not right this sec. >> >> Tom >> >> On Dec 7, 4:57 pm, Howard Lewis Ship wrote: >> >> >> >> > I still think it would be neat if there was some DHTML coolness to >> > help narrow down the symbol names that come down the right side of the >> > page. >> >> > On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber >> > wrote: >> > > By golly, you're right. I'll take a look at why. >> >> > > On Dec 7, 2:14 pm, cej38 wrote: >> > >> Hi, >> > >> I am writing because there seem to be missing functions in the API >> > >> webpage. The only one that I know for sure at the moment is the >> > >> filter 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 >> >> > -- >> > Howard M. Lewis Ship >> >> > Creator of Apache Tapestry >> >> > The source for Tapestry training, mentoring and support. Contact me to >> > learn how I can get you up and productive in Tapestry fast! >> >> > (971) 678-5210http://howardlewisship.com > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Sent from my mobile device -- 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: new API webpage format
It turns out the doc string for filter was dropped during a checkin earlier this year. I surprised no one noticed sooner (I guess everyone just knows how filter works). I have filed ticket 219 with a patch and hopefully we'll get it into 1.1. I didn't see any others missing, have you seen others? Thanks for catching that, Tom On Dec 7, 4:00 pm, Tom Faulhaber wrote: > By golly, you're right. I'll take a look at why. > > On Dec 7, 2:14 pm, cej38 wrote: > > > Hi, > > I am writing because there seem to be missing functions in the API > > webpage. The only one that I know for sure at the moment is the > > filter 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: new API webpage format
I like that too. I'll have to think about how we'd do that. On Dec 7, 8:11 pm, ataggart wrote: > While we're throwing requests at Tom, it'd be nice if the special > forms were included in the api. > > On Dec 7, 5:21 pm, Tom Faulhaber wrote: > > > Yup, I heard that the first time :-) > > > It's coming, but not right this sec. > > > Tom > > > On Dec 7, 4:57 pm, Howard Lewis Ship wrote: > > > > I still think it would be neat if there was some DHTML coolness to > > > help narrow down the symbol names that come down the right side of the > > > page. > > > > On Mon, Dec 7, 2009 at 4:00 PM, Tom Faulhaber > > > wrote: > > > > By golly, you're right. I'll take a look at why. > > > > > On Dec 7, 2:14 pm, cej38 wrote: > > > >> Hi, > > > >> I am writing because there seem to be missing functions in the API > > > >> webpage. The only one that I know for sure at the moment is the > > > >> filter 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 > > > > -- > > > Howard M. Lewis Ship > > > > Creator of Apache Tapestry > > > > The source for Tapestry training, mentoring and support. Contact me to > > > learn how I can get you up and productive in Tapestry fast! > > > > (971) 678-5210http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Multiple dispatch with Multimethods
Thanks I didn't know the costume hierarchy at all, it seems to be very useful. I understand it is coupled to the Java object hierarchy. Is there a way to create similar util for strings, as I did on my first example? On Dec 7, 12:10 pm, Meikel Brandmeyer wrote: > Hi, > > On Dec 7, 10:21 am, Tzach wrote: > > > (defmulti collide-with foo) > > > (defmethod collide-with ["asteroid" "spaceship"] (print "Boom")) > > (defmethod collide-with ["asteroid" any] (print " Wiiissh")) > > (defmethod collide-with [any "spaceship"] (print "Wooossh")) > > (defmethod collide-with [any any] (print "Dead Space")) > > > The idea is to have a default function for a collision of asteroid > > with anything else, and of spaceship with anything else. > > What foo can I use? > > Eg. a custom hierarchy. Since there is no bottom type, you have to > create it manually. Deriving Object from ::Any takes care of the Java > land. For clojure land you have to derive each type from ::Any (or > anything already deriving from ::Any). > > (def space-hierarchy > (-> (make-hierarchy) > (derive Object ::Any) > (derive ::Spaceship ::Any) > (derive ::Asteroid ::Any))) > > (defmulti collide-with > #(vec (map type %&)) > :hierarchy #'space-hierarchy) > > (defmethod collide-with :default > [_ _] > (print "Dead Space")) > > (defmethod collide-with [::Asteroid ::Any] > [_ _] > (print "Wiiissh")) > > (defmethod collide-with [::Any ::Spaceship] > [_ _] > (print "Wooosssh")) > > (defmethod collide-with [::Asteroid ::Spaceship] > [_ _] > (println "Booom!")) > > Maybe you have to disambiguate with prefer-method in certain cases. (I > don't think, that's the case here, but I haven't tested it...) > > Hope this helps. > > 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
